Hi Stephen, On 22 January 2016 at 12:38, Stephen Warren <[email protected]> wrote: > > On 01/21/2016 09:03 PM, Simon Glass wrote: >> >> Hi Bin, >> >> On 21 January 2016 at 20:53, Bin Meng <[email protected]> wrote: >>> >>> On Fri, Jan 22, 2016 at 11:36 AM, Simon Glass <[email protected]> wrote: >>>> >>>> Hi, >>>> >>>> On 21 January 2016 at 18:39, Bin Meng <[email protected]> wrote: >>>>> >>>>> Hi Stephen, >>>>> >>>>> On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren <[email protected]> >>>>> wrote: >>>>>> >>>>>> From: Stephen Warren <[email protected]> >>>>>> >>>>>> PCI controllers should be enumerated at startup so that PCI devices >>>>>> such as Ethernet controllers are available at startup. Fix board_init_r() >>>>>> not to skip calling pci_init() when CONFIG_DM_PCI is defined, and provide >>>>>> an implementation of pci_init() for the DM case. >>>>>> >>>>> >>>>> What exact issue are you trying to fix? I posted the same question on >>>>> Simon's patch [1] before. Does your patch and Simon's fix the same >>>>> issue? >>>>> >>>>> Note I submitted a similar patch [2] last year for x86 only, to >>>>> explicitly trigger the PCI enueration. But it was not accepted. >>>>> >>>>>> Fixes: 96350f729c42 ("dm: tegra: net: Convert tegra boards to driver >>>>>> model >>>>>> for Ethernet") >>>>>> Signed-off-by: Stephen Warren <[email protected]> >>>>>> --- >>>>>> I'm not sure if relying on the side-effects of calling >>>>>> uclass_{first,ext}_device is the correct approach; is there a more >>>>>> explicit >>>>>> way to probe all PCI controllers? >>>>>> >>>>>> Arguably, perhaps we should introduce a "pci start" command instead of >>>>>> this change to be consistent with e.g. USB. However, that would be a >>>>>> regression relative to earlier versions of U-Boot. >>>>>> --- >>>>> >>>>> >>>>> [1] http://patchwork.ozlabs.org/patch/569323/ >>>>> [2] http://patchwork.ozlabs.org/patch/500246/ >>>>> >>>>> Regards, >>>>> Bin >>>> >>>> >>>> This does go against the driver-model philosophy of lazy init. I >>>> wonder if we should add this patch with a Kconfig option to enable it? >>>> Then it can be enabled only for boards that need it. >>>> >>> >>> I suspect the issue is somewhere else. On Intel Galileo with a PCI >>> ethernet, it works fine without such explicit pci init. Which PCI >>> ethernet driver does not work on Tegra? >> >> >> It could be because that board probes PCI to get its serial to work. >> >> This could be fixed on Tegra by adding an Ethernet node to the device >> tree to cause it to be probed. But I don't think that should be a >> requirement. > > > Since PCI devices are automatically probed via standard bus protocols, I > believe we shouldn't have to add them to the DT. > > However, I could accept that we should add the PCI controller to DT in order > for the controller to be probed, and when that happens, the bus should be > enumerated thus causing all the Ethernet devices to be probed. However, the > PCI controller is already in DT, and this process isn't being kicked off, so > if that's the way it's supposed to work, there's a bug there.
So what do you think about a Kconfig option that tells U-Boot that PCI must be probed after relocation? Regards, Simon _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
