[U-Boot] [PATCH] pci: restore initialization for DM_PCI

[Simon Glass]

Hi Bin,

On 21 January 2016 at 21:06, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Simon,
>
> On Fri, Jan 22, 2016 at 12:03 PM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Bin,
>>
>> On 21 January 2016 at 20:53, Bin Meng <bmeng.cn at gmail.com> wrote:
>>> On Fri, Jan 22, 2016 at 11:36 AM, Simon Glass <sjg at chromium.org> wrote:
>>>> Hi,
>>>>
>>>> On 21 January 2016 at 18:39, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>>> Hi Stephen,
>>>>>
>>>>> On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>>>> From: Stephen Warren <swarren at 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 <swarren at 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