Hi Bin, On 21 January 2016 at 21:06, Bin Meng <bmeng...@gmail.com> wrote: > Hi Simon, > > On Fri, Jan 22, 2016 at 12:03 PM, Simon Glass <s...@chromium.org> wrote: >> Hi Bin, >> >> On 21 January 2016 at 20:53, Bin Meng <bmeng...@gmail.com> wrote: >>> On Fri, Jan 22, 2016 at 11:36 AM, Simon Glass <s...@chromium.org> wrote: >>>> Hi, >>>> >>>> On 21 January 2016 at 18:39, Bin Meng <bmeng...@gmail.com> wrote: >>>>> Hi Stephen, >>>>> >>>>> On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren <swar...@wwwdotorg.org> >>>>> wrote: >>>>>> From: Stephen Warren <swar...@nvidia.com> >>>>>> >>>>>> 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 <swar...@nvidia.com> >>>>>> --- >>>>>> 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. > > Even if it does not have a PCI serial, the PCI ethernet driver should > still have a chance to get PCI bus probe by calling one of these DM > PCI APIs. See an example in eth_designware.c. That's why I'd like to > know which PCI ethernet driver is this?
Well beaver uses RTL8169. But unless the driver is bound, it won't be visible to the Ethernet stack. > >> >> 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. >> > > Regards, > Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot