On Sat, Jan 23, 2016 at 5:48 AM, Stephen Warren <[email protected]> wrote: > On 01/22/2016 01:32 PM, Simon Glass wrote: >> >> 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? > > > I'm puzzled why anyone would turn off that option. > > If PCI is to be used at all, it needs to be probed. The only way I'm aware > of that it can be probed today is by accidental side-effect of some board > forcibly probing some device that happens to be on a PCI bus (i.e. Bin's > case). In other case, PCI doesn't get automatically probed at boot, and I > don't see any command that allows it to be probed manually. Don't we need > this patch (or your patch linked above) in order to make PCI usable at all? > If so, why would anyone turn this off?
Ah, now I got it. This looks to me a chicken & egg issue with driver model PCI. All of PCI device drivers won't be bound/probed unless PCI host controller is probed/bus is enumerated. The DM PCI APIs in these PCI device drivers' probe routines that are supposed to trigger the PCI bus enumeration won't have a chance to be called at all. This is indeed a generic issue for all non-x86 boards as on x86 all peripherals (including the chipset itself) are on the PCI bus but non-x86 boards are not. That means: on x86 I can call a DM PCI API to configure a register in the LPC bridge (could be either in board codes, or SoC-specific codes) which triggers the PCI bus enumeration automatically, which fits the driver model lazy init philosophy quite well. But non-x86 boards won't bother calling any DM PCI APIs to program any chipset registers, as these registers are normally memory-mapped and not related to PCI. Regards, Bin _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
