Message ID | 1612710687-56493-2-git-send-email-bmeng.cn@gmail.com |
---|---|
State | Superseded |
Delegated to: | Priyanka Jain |
Headers | show |
Series | ppc: qemu: Convert qemu-ppce500 to driver model | expand |
Hi Bin, On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote: > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242. > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") > changes 'struct pci_controller'.regions from pre-allocated array of > regions to dynamically allocated, which unfortunately broken lots of > boards that still use the non-DM PCI driver. > > We may update every non-DM PCI board codes to do the dynamical > allocation of PCI regions but that's a lot of work (e.g.: almost > all Freescale PowerPC boards are broken now and need to be fixed). > Let's do the easy way. No one has noticed since July, apparently. I think it would be better to disable PCI on these boards, until either someone migrates them or they are removed. The PCI deadline was about 18 months ago. Tom, do you know the situation here? > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com> > --- > > drivers/pci/pci-uclass.c | 14 ++++++-------- > include/pci.h | 4 +++- > 2 files changed, 9 insertions(+), 9 deletions(-) Regards, Simon
On Sun, Feb 07, 2021 at 08:33:50AM -0700, Simon Glass wrote: > Hi Bin, > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242. > > > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") > > changes 'struct pci_controller'.regions from pre-allocated array of > > regions to dynamically allocated, which unfortunately broken lots of > > boards that still use the non-DM PCI driver. > > > > We may update every non-DM PCI board codes to do the dynamical > > allocation of PCI regions but that's a lot of work (e.g.: almost > > all Freescale PowerPC boards are broken now and need to be fixed). > > Let's do the easy way. > > No one has noticed since July, apparently. I think it would be better > to disable PCI on these boards, until either someone migrates them or > they are removed. The PCI deadline was about 18 months ago. > > Tom, do you know the situation here? I want to hear what Priyanka has to say, as there's been an effort a few times on NXP's part to remove boards they don't want to maintain anymore. Outside of that, I do keep meaning to, but not quite finding the time to, pick a random well-past migration deadline, make it fatal, and then go start removing boards. I think I'll go pick a not-PCI (as some number of PowerPC ones will fail, and that's not as interesting until Priyanka can chime in) one right now and see what fails there.
Hi Simon, On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote: > > Hi Bin, > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242. > > > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") > > changes 'struct pci_controller'.regions from pre-allocated array of > > regions to dynamically allocated, which unfortunately broken lots of > > boards that still use the non-DM PCI driver. > > > > We may update every non-DM PCI board codes to do the dynamical > > allocation of PCI regions but that's a lot of work (e.g.: almost > > all Freescale PowerPC boards are broken now and need to be fixed). > > Let's do the easy way. > > No one has noticed since July, apparently. I think it would be better > to disable PCI on these boards, until either someone migrates them or > they are removed. The PCI deadline was about 18 months ago. > Yep, but I'd like to keep this revert instead of just fixing the qemu-ppce500 here, to give people a chance to test their original non-DM version of PCI driver before the DM conversion. Once all boards have converted to DM PCI, we can revert this revert patch again. > Tom, do you know the situation here? > > > > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com> > > --- > > > > drivers/pci/pci-uclass.c | 14 ++++++-------- > > include/pci.h | 4 +++- > > 2 files changed, 9 insertions(+), 9 deletions(-) Regards, Bin
On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote: > Hi Simon, > > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote: > > > > Hi Bin, > > > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242. > > > > > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") > > > changes 'struct pci_controller'.regions from pre-allocated array of > > > regions to dynamically allocated, which unfortunately broken lots of > > > boards that still use the non-DM PCI driver. > > > > > > We may update every non-DM PCI board codes to do the dynamical > > > allocation of PCI regions but that's a lot of work (e.g.: almost > > > all Freescale PowerPC boards are broken now and need to be fixed). > > > Let's do the easy way. > > > > No one has noticed since July, apparently. I think it would be better > > to disable PCI on these boards, until either someone migrates them or > > they are removed. The PCI deadline was about 18 months ago. > > > > Yep, but I'd like to keep this revert instead of just fixing the > qemu-ppce500 here, to give people a chance to test their original > non-DM version of PCI driver before the DM conversion. > > Once all boards have converted to DM PCI, we can revert this revert patch again. I'm not quite sure as a number of PowerPC boards did convert. I will see what's left, on top of the series I'm currently testing that deals with LIBATA+AHCI (and in turn kills off some PowerPC stuff).
Hi Bin, On Tue, 9 Feb 2021 at 17:47, Bin Meng <bmeng.cn@gmail.com> wrote: > > Hi Simon, > > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote: > > > > Hi Bin, > > > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242. > > > > > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") > > > changes 'struct pci_controller'.regions from pre-allocated array of > > > regions to dynamically allocated, which unfortunately broken lots of > > > boards that still use the non-DM PCI driver. > > > > > > We may update every non-DM PCI board codes to do the dynamical > > > allocation of PCI regions but that's a lot of work (e.g.: almost > > > all Freescale PowerPC boards are broken now and need to be fixed). > > > Let's do the easy way. > > > > No one has noticed since July, apparently. I think it would be better > > to disable PCI on these boards, until either someone migrates them or > > they are removed. The PCI deadline was about 18 months ago. > > > > Yep, but I'd like to keep this revert instead of just fixing the > qemu-ppce500 here, to give people a chance to test their original > non-DM version of PCI driver before the DM conversion. > > Once all boards have converted to DM PCI, we can revert this revert patch again. I'm fine with that if Tom is. But deleting unmaintained code is always another option! > > > Tom, do you know the situation here? > > Regards, Simon
Hi Simon, Bin & Tom, On 10.02.21 06:10, Simon Glass wrote: > Hi Bin, > > On Tue, 9 Feb 2021 at 17:47, Bin Meng <bmeng.cn@gmail.com> wrote: >> >> Hi Simon, >> >> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote: >>> >>> Hi Bin, >>> >>> On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote: >>>> >>>> This reverts commit e002474158d1054a7a2ff9a66149384c639ff242. >>>> >>>> Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") >>>> changes 'struct pci_controller'.regions from pre-allocated array of >>>> regions to dynamically allocated, which unfortunately broken lots of >>>> boards that still use the non-DM PCI driver. >>>> >>>> We may update every non-DM PCI board codes to do the dynamical >>>> allocation of PCI regions but that's a lot of work (e.g.: almost >>>> all Freescale PowerPC boards are broken now and need to be fixed). >>>> Let's do the easy way. >>> >>> No one has noticed since July, apparently. I think it would be better >>> to disable PCI on these boards, until either someone migrates them or >>> they are removed. The PCI deadline was about 18 months ago. >>> >> >> Yep, but I'd like to keep this revert instead of just fixing the >> qemu-ppce500 here, to give people a chance to test their original >> non-DM version of PCI driver before the DM conversion. >> >> Once all boards have converted to DM PCI, we can revert this revert patch again. > > I'm fine with that if Tom is. But deleting unmaintained code is always > another option! Sorry for chiming in this late in this discussion. If we decide to revert this patch, this will break OcteonTX/TX2 support. As we need a higher value for the PCI regions here. Originally we just increased MAX_PCI_REGIONS to 10. This dynamic allocation superseeded this change. This increase might introduce size issues on other platforms though. So please keep this in mind that with the revert the value of MAX_PCI_REGIONS needs to get increased to 10 - at least for Octeon TX. Thanks, Stefan
On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote: > Hi Simon, > > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote: > > > > Hi Bin, > > > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242. > > > > > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") > > > changes 'struct pci_controller'.regions from pre-allocated array of > > > regions to dynamically allocated, which unfortunately broken lots of > > > boards that still use the non-DM PCI driver. > > > > > > We may update every non-DM PCI board codes to do the dynamical > > > allocation of PCI regions but that's a lot of work (e.g.: almost > > > all Freescale PowerPC boards are broken now and need to be fixed). > > > Let's do the easy way. > > > > No one has noticed since July, apparently. I think it would be better > > to disable PCI on these boards, until either someone migrates them or > > they are removed. The PCI deadline was about 18 months ago. > > > > Yep, but I'd like to keep this revert instead of just fixing the > qemu-ppce500 here, to give people a chance to test their original > non-DM version of PCI driver before the DM conversion. > > Once all boards have converted to DM PCI, we can revert this revert patch again. > > > Tom, do you know the situation here? So, I made a lack of DM_PCI migration be fatal and got a build done here: https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348 Of note, MIPS malta fails, so I had to drop that from pytest to complete the world build. There's then a handful of ARM boards, another large chunk of PowerPC, and then a few others such as r7780mp. SH is the big what to do here to me, other than PowerPC, as other than r2dplus everything is missing the main "convert to DM" migration deadline as well.
On 2/10/21 3:13 PM, Tom Rini wrote: > On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote: >> Hi Simon, >> >> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote: >>> >>> Hi Bin, >>> >>> On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote: >>>> >>>> This reverts commit e002474158d1054a7a2ff9a66149384c639ff242. >>>> >>>> Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") >>>> changes 'struct pci_controller'.regions from pre-allocated array of >>>> regions to dynamically allocated, which unfortunately broken lots of >>>> boards that still use the non-DM PCI driver. >>>> >>>> We may update every non-DM PCI board codes to do the dynamical >>>> allocation of PCI regions but that's a lot of work (e.g.: almost >>>> all Freescale PowerPC boards are broken now and need to be fixed). >>>> Let's do the easy way. >>> >>> No one has noticed since July, apparently. I think it would be better >>> to disable PCI on these boards, until either someone migrates them or >>> they are removed. The PCI deadline was about 18 months ago. >>> >> >> Yep, but I'd like to keep this revert instead of just fixing the >> qemu-ppce500 here, to give people a chance to test their original >> non-DM version of PCI driver before the DM conversion. >> >> Once all boards have converted to DM PCI, we can revert this revert patch again. >> >>> Tom, do you know the situation here? > > So, I made a lack of DM_PCI migration be fatal and got a build done > here: > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348 > > Of note, MIPS malta fails, so I had to drop that from pytest to complete > the world build. There's then a handful of ARM boards, another large > chunk of PowerPC, and then a few others such as r7780mp. SH is the big > what to do here to me, other than PowerPC, as other than r2dplus > everything is missing the main "convert to DM" migration deadline as > well. Anything SH except r2dplus is likely dead.
On Wed, Feb 10, 2021 at 03:27:22PM +0100, Marek Vasut wrote: > On 2/10/21 3:13 PM, Tom Rini wrote: > > On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote: > > > Hi Simon, > > > > > > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote: > > > > > > > > Hi Bin, > > > > > > > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242. > > > > > > > > > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") > > > > > changes 'struct pci_controller'.regions from pre-allocated array of > > > > > regions to dynamically allocated, which unfortunately broken lots of > > > > > boards that still use the non-DM PCI driver. > > > > > > > > > > We may update every non-DM PCI board codes to do the dynamical > > > > > allocation of PCI regions but that's a lot of work (e.g.: almost > > > > > all Freescale PowerPC boards are broken now and need to be fixed). > > > > > Let's do the easy way. > > > > > > > > No one has noticed since July, apparently. I think it would be better > > > > to disable PCI on these boards, until either someone migrates them or > > > > they are removed. The PCI deadline was about 18 months ago. > > > > > > > > > > Yep, but I'd like to keep this revert instead of just fixing the > > > qemu-ppce500 here, to give people a chance to test their original > > > non-DM version of PCI driver before the DM conversion. > > > > > > Once all boards have converted to DM PCI, we can revert this revert patch again. > > > > > > > Tom, do you know the situation here? > > > > So, I made a lack of DM_PCI migration be fatal and got a build done > > here: > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348 > > > > Of note, MIPS malta fails, so I had to drop that from pytest to complete > > the world build. There's then a handful of ARM boards, another large > > chunk of PowerPC, and then a few others such as r7780mp. SH is the big > > what to do here to me, other than PowerPC, as other than r2dplus > > everything is missing the main "convert to DM" migration deadline as > > well. > > Anything SH except r2dplus is likely dead. Shall I send a series to remove most of the boards then?
On 2/10/21 3:48 PM, Tom Rini wrote: > On Wed, Feb 10, 2021 at 03:27:22PM +0100, Marek Vasut wrote: >> On 2/10/21 3:13 PM, Tom Rini wrote: >>> On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote: >>>> Hi Simon, >>>> >>>> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote: >>>>> >>>>> Hi Bin, >>>>> >>>>> On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>> >>>>>> This reverts commit e002474158d1054a7a2ff9a66149384c639ff242. >>>>>> >>>>>> Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") >>>>>> changes 'struct pci_controller'.regions from pre-allocated array of >>>>>> regions to dynamically allocated, which unfortunately broken lots of >>>>>> boards that still use the non-DM PCI driver. >>>>>> >>>>>> We may update every non-DM PCI board codes to do the dynamical >>>>>> allocation of PCI regions but that's a lot of work (e.g.: almost >>>>>> all Freescale PowerPC boards are broken now and need to be fixed). >>>>>> Let's do the easy way. >>>>> >>>>> No one has noticed since July, apparently. I think it would be better >>>>> to disable PCI on these boards, until either someone migrates them or >>>>> they are removed. The PCI deadline was about 18 months ago. >>>>> >>>> >>>> Yep, but I'd like to keep this revert instead of just fixing the >>>> qemu-ppce500 here, to give people a chance to test their original >>>> non-DM version of PCI driver before the DM conversion. >>>> >>>> Once all boards have converted to DM PCI, we can revert this revert patch again. >>>> >>>>> Tom, do you know the situation here? >>> >>> So, I made a lack of DM_PCI migration be fatal and got a build done >>> here: >>> https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348 >>> >>> Of note, MIPS malta fails, so I had to drop that from pytest to complete >>> the world build. There's then a handful of ARM boards, another large >>> chunk of PowerPC, and then a few others such as r7780mp. SH is the big >>> what to do here to me, other than PowerPC, as other than r2dplus >>> everything is missing the main "convert to DM" migration deadline as >>> well. >> >> Anything SH except r2dplus is likely dead. > > Shall I send a series to remove most of the boards then? You can.
Hi Tom, On Wed, Feb 10, 2021 at 10:13 PM Tom Rini <trini@konsulko.com> wrote: > > On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote: > > Hi Simon, > > > > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote: > > > > > > Hi Bin, > > > > > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242. > > > > > > > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") > > > > changes 'struct pci_controller'.regions from pre-allocated array of > > > > regions to dynamically allocated, which unfortunately broken lots of > > > > boards that still use the non-DM PCI driver. > > > > > > > > We may update every non-DM PCI board codes to do the dynamical > > > > allocation of PCI regions but that's a lot of work (e.g.: almost > > > > all Freescale PowerPC boards are broken now and need to be fixed). > > > > Let's do the easy way. > > > > > > No one has noticed since July, apparently. I think it would be better > > > to disable PCI on these boards, until either someone migrates them or > > > they are removed. The PCI deadline was about 18 months ago. > > > > > > > Yep, but I'd like to keep this revert instead of just fixing the > > qemu-ppce500 here, to give people a chance to test their original > > non-DM version of PCI driver before the DM conversion. > > > > Once all boards have converted to DM PCI, we can revert this revert patch again. > > > > > Tom, do you know the situation here? > > So, I made a lack of DM_PCI migration be fatal and got a build done > here: > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348 > > Of note, MIPS malta fails, so I had to drop that from pytest to complete > the world build. There's then a handful of ARM boards, another large > chunk of PowerPC, and then a few others such as r7780mp. SH is the big > what to do here to me, other than PowerPC, as other than r2dplus > everything is missing the main "convert to DM" migration deadline as > well. What should we do for this patch? If the plan is to drop all boards that are not converted to DM PCI in 2021.04, I can drop this revert patch in v2. Regards, Bin
On Sun, Feb 14, 2021 at 12:53:29PM +0800, Bin Meng wrote: > Hi Tom, > > On Wed, Feb 10, 2021 at 10:13 PM Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote: > > > Hi Simon, > > > > > > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote: > > > > > > > > Hi Bin, > > > > > > > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242. > > > > > > > > > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") > > > > > changes 'struct pci_controller'.regions from pre-allocated array of > > > > > regions to dynamically allocated, which unfortunately broken lots of > > > > > boards that still use the non-DM PCI driver. > > > > > > > > > > We may update every non-DM PCI board codes to do the dynamical > > > > > allocation of PCI regions but that's a lot of work (e.g.: almost > > > > > all Freescale PowerPC boards are broken now and need to be fixed). > > > > > Let's do the easy way. > > > > > > > > No one has noticed since July, apparently. I think it would be better > > > > to disable PCI on these boards, until either someone migrates them or > > > > they are removed. The PCI deadline was about 18 months ago. > > > > > > > > > > Yep, but I'd like to keep this revert instead of just fixing the > > > qemu-ppce500 here, to give people a chance to test their original > > > non-DM version of PCI driver before the DM conversion. > > > > > > Once all boards have converted to DM PCI, we can revert this revert patch again. > > > > > > > Tom, do you know the situation here? > > > > So, I made a lack of DM_PCI migration be fatal and got a build done > > here: > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348 > > > > Of note, MIPS malta fails, so I had to drop that from pytest to complete > > the world build. There's then a handful of ARM boards, another large > > chunk of PowerPC, and then a few others such as r7780mp. SH is the big > > what to do here to me, other than PowerPC, as other than r2dplus > > everything is missing the main "convert to DM" migration deadline as > > well. > > What should we do for this patch? > > If the plan is to drop all boards that are not converted to DM PCI in > 2021.04, I can drop this revert patch in v2. I've posted the patch to drop the SH boards. Daniel, what about Malta? I guess maybe the next steps are I need to pull in the already acked board removal patches I've posted and then do another posting of "remove these boards now" and see what shakes out.
On 2/14/21 3:35 PM, Tom Rini wrote: > On Sun, Feb 14, 2021 at 12:53:29PM +0800, Bin Meng wrote: >> Hi Tom, >> >> On Wed, Feb 10, 2021 at 10:13 PM Tom Rini <trini@konsulko.com> wrote: >>> >>> On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote: >>>> Hi Simon, >>>> >>>> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote: >>>>> >>>>> Hi Bin, >>>>> >>>>> On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>> >>>>>> This reverts commit e002474158d1054a7a2ff9a66149384c639ff242. >>>>>> >>>>>> Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") >>>>>> changes 'struct pci_controller'.regions from pre-allocated array of >>>>>> regions to dynamically allocated, which unfortunately broken lots of >>>>>> boards that still use the non-DM PCI driver. >>>>>> >>>>>> We may update every non-DM PCI board codes to do the dynamical >>>>>> allocation of PCI regions but that's a lot of work (e.g.: almost >>>>>> all Freescale PowerPC boards are broken now and need to be fixed). >>>>>> Let's do the easy way. >>>>> >>>>> No one has noticed since July, apparently. I think it would be better >>>>> to disable PCI on these boards, until either someone migrates them or >>>>> they are removed. The PCI deadline was about 18 months ago. >>>>> >>>> >>>> Yep, but I'd like to keep this revert instead of just fixing the >>>> qemu-ppce500 here, to give people a chance to test their original >>>> non-DM version of PCI driver before the DM conversion. >>>> >>>> Once all boards have converted to DM PCI, we can revert this revert patch again. >>>> >>>>> Tom, do you know the situation here? >>> >>> So, I made a lack of DM_PCI migration be fatal and got a build done >>> here: >>> https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348 >>> >>> Of note, MIPS malta fails, so I had to drop that from pytest to complete >>> the world build. There's then a handful of ARM boards, another large >>> chunk of PowerPC, and then a few others such as r7780mp. SH is the big >>> what to do here to me, other than PowerPC, as other than r2dplus >>> everything is missing the main "convert to DM" migration deadline as >>> well. >> >> What should we do for this patch? >> >> If the plan is to drop all boards that are not converted to DM PCI in >> 2021.04, I can drop this revert patch in v2. > > I've posted the patch to drop the SH boards. Daniel, what about Malta? Malta should be fixed, since it's mips used in CI. > I guess maybe the next steps are I need to pull in the already acked > board removal patches I've posted and then do another posting of "remove > these boards now" and see what shakes out. Yeah
On Sun, Feb 14, 2021 at 03:44:26PM +0100, Marek Vasut wrote: > On 2/14/21 3:35 PM, Tom Rini wrote: > > On Sun, Feb 14, 2021 at 12:53:29PM +0800, Bin Meng wrote: > > > Hi Tom, > > > > > > On Wed, Feb 10, 2021 at 10:13 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote: > > > > > Hi Simon, > > > > > > > > > > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote: > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > > > > > > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242. > > > > > > > > > > > > > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") > > > > > > > changes 'struct pci_controller'.regions from pre-allocated array of > > > > > > > regions to dynamically allocated, which unfortunately broken lots of > > > > > > > boards that still use the non-DM PCI driver. > > > > > > > > > > > > > > We may update every non-DM PCI board codes to do the dynamical > > > > > > > allocation of PCI regions but that's a lot of work (e.g.: almost > > > > > > > all Freescale PowerPC boards are broken now and need to be fixed). > > > > > > > Let's do the easy way. > > > > > > > > > > > > No one has noticed since July, apparently. I think it would be better > > > > > > to disable PCI on these boards, until either someone migrates them or > > > > > > they are removed. The PCI deadline was about 18 months ago. > > > > > > > > > > > > > > > > Yep, but I'd like to keep this revert instead of just fixing the > > > > > qemu-ppce500 here, to give people a chance to test their original > > > > > non-DM version of PCI driver before the DM conversion. > > > > > > > > > > Once all boards have converted to DM PCI, we can revert this revert patch again. > > > > > > > > > > > Tom, do you know the situation here? > > > > > > > > So, I made a lack of DM_PCI migration be fatal and got a build done > > > > here: > > > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348 > > > > > > > > Of note, MIPS malta fails, so I had to drop that from pytest to complete > > > > the world build. There's then a handful of ARM boards, another large > > > > chunk of PowerPC, and then a few others such as r7780mp. SH is the big > > > > what to do here to me, other than PowerPC, as other than r2dplus > > > > everything is missing the main "convert to DM" migration deadline as > > > > well. > > > > > > What should we do for this patch? > > > > > > If the plan is to drop all boards that are not converted to DM PCI in > > > 2021.04, I can drop this revert patch in v2. > > > > I've posted the patch to drop the SH boards. Daniel, what about Malta? > > Malta should be fixed, since it's mips used in CI. There's also qemu_mips* in CI, so it depends on what Daniel thinks is the right overall answer here.
Am Sonntag, den 14.02.2021, 09:52 -0500 schrieb Tom Rini: ... > > > > > > > > > > > > > Tom, do you know the situation here? > > > > > > > > > > So, I made a lack of DM_PCI migration be fatal and got a > > > > > build done > > > > > here: > > > > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348 > > > > > > > > > > Of note, MIPS malta fails, so I had to drop that from pytest > > > > > to complete > > > > > the world build. There's then a handful of ARM boards, > > > > > another large > > > > > chunk of PowerPC, and then a few others such as r7780mp. SH > > > > > is the big > > > > > what to do here to me, other than PowerPC, as other than > > > > > r2dplus > > > > > everything is missing the main "convert to DM" migration > > > > > deadline as > > > > > well. > > > > > > > > What should we do for this patch? > > > > > > > > If the plan is to drop all boards that are not converted to DM > > > > PCI in > > > > 2021.04, I can drop this revert patch in v2. > > > > > > I've posted the patch to drop the SH boards. Daniel, what about > > > Malta? > > > > Malta should be fixed, since it's mips used in CI. > > There's also qemu_mips* in CI, so it depends on what Daniel thinks is > the right overall answer here. > Malta is the MIPS reference board physically as well as in Qemu. qemu_mips is actually deprecated and is going to be removed from Qemu sooner or later. That's why I added Malta to CI with the goal to remove qemu_mips. The problem with MIPS and DM_PCI is that there are some generic issues with memory mapping and CONFIG_SYS_SDRAM_BASE being used as virtual address. Actually I have a pending patch queue from Paul Burton for Malta for converting to DM_PCI, but that requires resolving the generic issues with some refactoring for all MIPS boards. It's still on my TODO list ;) Until I can spare enough time to resolve all issues, I could try to disable the PCI driver in Malta defconfig and mark the driver as broken in Kconfig. This way we can avoid removing the whole board.
On Sun, Feb 14, 2021 at 08:12:16PM +0100, Daniel Schwierzeck wrote: > Am Sonntag, den 14.02.2021, 09:52 -0500 schrieb Tom Rini: > > ... > > > > > > > > > > > > > > > > Tom, do you know the situation here? > > > > > > > > > > > > So, I made a lack of DM_PCI migration be fatal and got a > > > > > > build done > > > > > > here: > > > > > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348 > > > > > > > > > > > > Of note, MIPS malta fails, so I had to drop that from pytest > > > > > > to complete > > > > > > the world build. There's then a handful of ARM boards, > > > > > > another large > > > > > > chunk of PowerPC, and then a few others such as r7780mp. SH > > > > > > is the big > > > > > > what to do here to me, other than PowerPC, as other than > > > > > > r2dplus > > > > > > everything is missing the main "convert to DM" migration > > > > > > deadline as > > > > > > well. > > > > > > > > > > What should we do for this patch? > > > > > > > > > > If the plan is to drop all boards that are not converted to DM > > > > > PCI in > > > > > 2021.04, I can drop this revert patch in v2. > > > > > > > > I've posted the patch to drop the SH boards. Daniel, what about > > > > Malta? > > > > > > Malta should be fixed, since it's mips used in CI. > > > > There's also qemu_mips* in CI, so it depends on what Daniel thinks is > > the right overall answer here. > > > > Malta is the MIPS reference board physically as well as in Qemu. > qemu_mips is actually deprecated and is going to be removed from Qemu > sooner or later. That's why I added Malta to CI with the goal to remove > qemu_mips. > > The problem with MIPS and DM_PCI is that there are some generic issues > with memory mapping and CONFIG_SYS_SDRAM_BASE being used as virtual > address. Actually I have a pending patch queue from Paul Burton for > Malta for converting to DM_PCI, but that requires resolving the generic > issues with some refactoring for all MIPS boards. It's still on my TODO > list ;) > > Until I can spare enough time to resolve all issues, I could try to > disable the PCI driver in Malta defconfig and mark the driver as broken > in Kconfig. This way we can avoid removing the whole board. Thanks for explaining. Yes, lets go that route for now.
Hi Tom, On Mon, Feb 15, 2021 at 4:30 AM Tom Rini <trini@konsulko.com> wrote: > > On Sun, Feb 14, 2021 at 08:12:16PM +0100, Daniel Schwierzeck wrote: > > Am Sonntag, den 14.02.2021, 09:52 -0500 schrieb Tom Rini: > > > > ... > > > > > > > > > > > > > > > > > > > Tom, do you know the situation here? > > > > > > > > > > > > > > So, I made a lack of DM_PCI migration be fatal and got a > > > > > > > build done > > > > > > > here: > > > > > > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348 > > > > > > > > > > > > > > Of note, MIPS malta fails, so I had to drop that from pytest > > > > > > > to complete > > > > > > > the world build. There's then a handful of ARM boards, > > > > > > > another large > > > > > > > chunk of PowerPC, and then a few others such as r7780mp. SH > > > > > > > is the big > > > > > > > what to do here to me, other than PowerPC, as other than > > > > > > > r2dplus > > > > > > > everything is missing the main "convert to DM" migration > > > > > > > deadline as > > > > > > > well. > > > > > > > > > > > > What should we do for this patch? > > > > > > > > > > > > If the plan is to drop all boards that are not converted to DM > > > > > > PCI in > > > > > > 2021.04, I can drop this revert patch in v2. > > > > > > > > > > I've posted the patch to drop the SH boards. Daniel, what about > > > > > Malta? > > > > > > > > Malta should be fixed, since it's mips used in CI. > > > > > > There's also qemu_mips* in CI, so it depends on what Daniel thinks is > > > the right overall answer here. > > > > > > > Malta is the MIPS reference board physically as well as in Qemu. > > qemu_mips is actually deprecated and is going to be removed from Qemu > > sooner or later. That's why I added Malta to CI with the goal to remove > > qemu_mips. > > > > The problem with MIPS and DM_PCI is that there are some generic issues > > with memory mapping and CONFIG_SYS_SDRAM_BASE being used as virtual > > address. Actually I have a pending patch queue from Paul Burton for > > Malta for converting to DM_PCI, but that requires resolving the generic > > issues with some refactoring for all MIPS boards. It's still on my TODO > > list ;) > > > > Until I can spare enough time to resolve all issues, I could try to > > disable the PCI driver in Malta defconfig and mark the driver as broken > > in Kconfig. This way we can avoid removing the whole board. > > Thanks for explaining. Yes, lets go that route for now. To make this series not to depend on board removal series, I will drop this revert patch in v2, and fix the non-DM PCI driver of mpc85xx instead. Regards, Bin
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c index ba65f47..8a94ea2 100644 --- a/drivers/pci/pci-uclass.c +++ b/drivers/pci/pci-uclass.c @@ -907,7 +907,6 @@ static void decode_regions(struct pci_controller *hose, ofnode parent_node, int cells_per_record; struct bd_info *bd; const u32 *prop; - int max_regions; int len; int i; @@ -927,13 +926,7 @@ static void decode_regions(struct pci_controller *hose, ofnode parent_node, hose->region_count = 0; debug("%s: len=%d, cells_per_record=%d\n", __func__, len, cells_per_record); - - /* Dynamically allocate the regions array */ - max_regions = len / cells_per_record + CONFIG_NR_DRAM_BANKS; - hose->regions = (struct pci_region *) - calloc(1, max_regions * sizeof(struct pci_region)); - - for (i = 0; i < max_regions; i++, len -= cells_per_record) { + for (i = 0; i < MAX_PCI_REGIONS; i++, len -= cells_per_record) { u64 pci_addr, addr, size; int space_code; u32 flags; @@ -987,6 +980,11 @@ static void decode_regions(struct pci_controller *hose, ofnode parent_node, return; for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) { + if (hose->region_count == MAX_PCI_REGIONS) { + pr_err("maximum number of regions parsed, aborting\n"); + break; + } + if (bd->bi_dram[i].size) { pci_set_region(hose->regions + hose->region_count++, bd->bi_dram[i].start, diff --git a/include/pci.h b/include/pci.h index 5f36537..64dff55 100644 --- a/include/pci.h +++ b/include/pci.h @@ -610,6 +610,8 @@ extern void pci_cfgfunc_do_nothing(struct pci_controller* hose, pci_dev_t dev, extern void pci_cfgfunc_config_device(struct pci_controller* hose, pci_dev_t dev, struct pci_config_table *); +#define MAX_PCI_REGIONS 7 + #define INDIRECT_TYPE_NO_PCIE_LINK 1 /** @@ -650,7 +652,7 @@ struct pci_controller { * for PCI controllers and a separate UCLASS (or perhaps * UCLASS_PCI_GENERIC) is used for bridges. */ - struct pci_region *regions; + struct pci_region regions[MAX_PCI_REGIONS]; int region_count; struct pci_config_table *config_table;
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242. Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") changes 'struct pci_controller'.regions from pre-allocated array of regions to dynamically allocated, which unfortunately broken lots of boards that still use the non-DM PCI driver. We may update every non-DM PCI board codes to do the dynamical allocation of PCI regions but that's a lot of work (e.g.: almost all Freescale PowerPC boards are broken now and need to be fixed). Let's do the easy way. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> --- drivers/pci/pci-uclass.c | 14 ++++++-------- include/pci.h | 4 +++- 2 files changed, 9 insertions(+), 9 deletions(-)