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

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

[Stephen Warren]

From: Stephen Warren <swarren@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.

Fixes: 96350f729c42 ("dm: tegra: net: Convert tegra boards to driver model
for Ethernet")
Signed-off-by: Stephen Warren <swarren@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.
---
 common/board_r.c         |  2 --
 drivers/pci/pci-uclass.c | 15 +++++++++++++++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/common/board_r.c b/common/board_r.c
index 75ee43e2d76e..e5029aff1e96 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -249,9 +249,7 @@ static int initr_unlock_ram_in_cache(void)
 #ifdef CONFIG_PCI
 static int initr_pci(void)
 {
-#ifndef CONFIG_DM_PCI
 	pci_init();
-#endif
 
 	return 0;
 }
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 685df9d274e4..f51f08289d66 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -1247,3 +1247,18 @@ U_BOOT_DRIVER(pci_generic_drv) = {
 	.id		= UCLASS_PCI_GENERIC,
 	.of_match	= pci_generic_ids,
 };
+
+void pci_init(void)
+{
+	struct udevice *bus;
+
+	/*
+	 * Enumerate all known controller devices. Enumeration has the side-
+	 * effect of probing them, so PCIe devices will be enumerated too.
+	 */
+	for (uclass_first_device(UCLASS_PCI, &bus);
+	     bus;
+	     uclass_next_device(&bus)) {
+		;
+	}
+}
-- 
2.7.0

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

[Tom Rini]

On Thu, Jan 21, 2016 at 04:35:33PM -0700, Stephen Warren wrote:

> From: Stephen Warren <swarren@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.
> 
> Fixes: 96350f729c42 ("dm: tegra: net: Convert tegra boards to driver model
> for Ethernet")
> Signed-off-by: Stephen Warren <swarren@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.

So it's a good discussion to have.  In the U-Boot world, can we have
cases where we need PCI up before we could reasonably make use of
CONFIG_PREBOOT to ensure the board is in a good enough state to use for
most use cases?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160121/7afe059d/attachment.sig>

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

[Bin Meng]

Hi Stephen,

On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> From: Stephen Warren <swarren@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@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

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

[Simon Glass]

Hi,

On 21 January 2016 at 18:39, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Stephen,
>
> On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> From: Stephen Warren <swarren@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@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.

Regards
Simon

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

[Bin Meng]

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

Regards,
Bin

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

[Simon Glass]

Hi Bin,

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

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,
Simon

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

[Bin Meng]

Hi Simon,

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

>
> 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] [PATCH] pci: restore initialization for DM_PCI

[Simon Glass]

Hi Bin,

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

[Stephen Warren]

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

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

[Simon Glass]

Hi Stephen,

On 22 January 2016 at 12:38, Stephen Warren <swarren@wwwdotorg.org> wrote:
>
> On 01/21/2016 09:03 PM, Simon Glass wrote:
>>
>> Hi Bin,
>>
>> On 21 January 2016 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>
>>> On Fri, Jan 22, 2016 at 11:36 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 21 January 2016 at 18:39, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>
>>>>> Hi Stephen,
>>>>>
>>>>> On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>>>>
>>>>>> From: Stephen Warren <swarren@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@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.
>>
>> 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] [PATCH] pci: restore initialization for DM_PCI

[Stephen Warren]

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

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

[Simon Glass]

Hi Stephen,

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

We try to probe devices only when used. E.g. on beaver, if you are not
net-booting, you actually don't need PCI.

I think a command is a good idea. I also think a Kconfig option to
auto-probe PCI is worth adding. But I'm not keen on manually probing
it by default for all PCI boards.

Regards,
Simon

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

[Stephen Warren]

On 01/22/2016 02:50 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 22 January 2016 at 14:48, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 01/22/2016 01:32 PM, Simon Glass wrote:
>>>
>>> Hi Stephen,
>>>
>>> On 22 January 2016 at 12:38, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>>
>>>>
>>>> On 01/21/2016 09:03 PM, Simon Glass wrote:
>>>>>
>>>>>
>>>>> Hi Bin,
>>>>>
>>>>> On 21 January 2016 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 22, 2016 at 11:36 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 21 January 2016 at 18:39, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Stephen,
>>>>>>>>
>>>>>>>> On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren
>>>>>>>> <swarren@wwwdotorg.org> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> From: Stephen Warren <swarren@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@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.
>>>>>
>>>>> 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?
>
> We try to probe devices only when used. E.g. on beaver, if you are not
> net-booting, you actually don't need PCI.

Are you saying that the first network command I execute in U-Boot should 
probe Ethernet device and hence PCI devices right now in the current 
U-Boot code?

That doesn't work right now. If it did work, that would probably be OK.

If not, I don't see how mentioning the lazy probing is relevant.

> I think a command is a good idea. I also think a Kconfig option to
> auto-probe PCI is worth adding. But I'm not keen on manually probing
> it by default for all PCI boards.

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

[Simon Glass]

Hi Stephen,

On 22 January 2016 at 14:58, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 01/22/2016 02:50 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 22 January 2016 at 14:48, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>
>>> On 01/22/2016 01:32 PM, Simon Glass wrote:
>>>>
>>>>
>>>> Hi Stephen,
>>>>
>>>> On 22 January 2016 at 12:38, Stephen Warren <swarren@wwwdotorg.org>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 01/21/2016 09:03 PM, Simon Glass wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Bin,
>>>>>>
>>>>>> On 21 January 2016 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 22, 2016 at 11:36 AM, Simon Glass <sjg@chromium.org>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 21 January 2016 at 18:39, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Stephen,
>>>>>>>>>
>>>>>>>>> On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren
>>>>>>>>> <swarren@wwwdotorg.org> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> From: Stephen Warren <swarren@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@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.
>>>>>>
>>>>>> 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?
>>
>>
>> We try to probe devices only when used. E.g. on beaver, if you are not
>> net-booting, you actually don't need PCI.
>
>
> Are you saying that the first network command I execute in U-Boot should
> probe Ethernet device and hence PCI devices right now in the current U-Boot
> code?
>
> That doesn't work right now. If it did work, that would probably be OK.

Two options:
- Add a 'pci start' command to your script
- Enable the PCI auto-probe Kconfig option

Boards can then choose which they prefer.

>
> If not, I don't see how mentioning the lazy probing is relevant.
>
>
>> I think a command is a good idea. I also think a Kconfig option to
>> auto-probe PCI is worth adding. But I'm not keen on manually probing
>> it by default for all PCI boards.

Regards,
Simon

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

[Stephen Warren]

On 01/22/2016 03:00 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 22 January 2016 at 14:58, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 01/22/2016 02:50 PM, Simon Glass wrote:
>>>
>>> Hi Stephen,
>>>
>>> On 22 January 2016 at 14:48, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>>
>>>> On 01/22/2016 01:32 PM, Simon Glass wrote:
>>>>>
>>>>>
>>>>> Hi Stephen,
>>>>>
>>>>> On 22 January 2016 at 12:38, Stephen Warren <swarren@wwwdotorg.org>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 01/21/2016 09:03 PM, Simon Glass wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi Bin,
>>>>>>>
>>>>>>> On 21 January 2016 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jan 22, 2016 at 11:36 AM, Simon Glass <sjg@chromium.org>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 21 January 2016 at 18:39, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Stephen,
>>>>>>>>>>
>>>>>>>>>> On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren
>>>>>>>>>> <swarren@wwwdotorg.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> From: Stephen Warren <swarren@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@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.
>>>>>>>
>>>>>>> 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?
>>>
>>>
>>> We try to probe devices only when used. E.g. on beaver, if you are not
>>> net-booting, you actually don't need PCI.
>>
>>
>> Are you saying that the first network command I execute in U-Boot should
>> probe Ethernet device and hence PCI devices right now in the current U-Boot
>> code?
>>
>> That doesn't work right now. If it did work, that would probably be OK.
>
> Two options:
> - Add a 'pci start' command to your script
> - Enable the PCI auto-probe Kconfig option
>
> Boards can then choose which they prefer.

I see there's already a "pci enum" command that can be enabled:

#ifdef CONFIG_SYS_LONGHELP
static char pci_help_text[] =
	"[bus] [long]\n"
	"    - short or long list of PCI devices on bus 'bus'\n"
#ifdef CONFIG_CMD_PCI_ENUM
	"pci enum\n"
	"    - re-enumerate PCI buses\n"
#endif

I'm tempted to re-enable that for DM, by making the implementation of 
pci_init() exist even with CONFIG_DM_PCI, then enhance 
config_distro_bootcmd.h to have it run "pci enum" any time before it 
might touch a PCI device, similar to the existing USB and SCSI 
enumeration support.

The only wart is that the command help text currently says 
"*re-*enumerate PCI buses" rather than just "enumerate PCI buses", which 
implies the semantics would always cause an enumeration even on the 
second/... execution, whereas it'd be simpler to have it work like "usb 
start", i.e. perform enumeration the first time but be a no-op any 
second/... time. Am I reading too much into the help text? If not, 
should I just rename the command to "pci start" for the DM case? I'm not 
sure if PCI hotplug is something we'll need to deal with; that'd be the 
only time the different semantics were particular useful.

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

[Simon Glass]

Hi Stephen,

On 25 January 2016 at 10:11, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 01/22/2016 03:00 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 22 January 2016 at 14:58, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>
>>> On 01/22/2016 02:50 PM, Simon Glass wrote:
>>>>
>>>>
>>>> Hi Stephen,
>>>>
>>>> On 22 January 2016 at 14:48, Stephen Warren <swarren@wwwdotorg.org>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 01/22/2016 01:32 PM, Simon Glass wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Stephen,
>>>>>>
>>>>>> On 22 January 2016 at 12:38, Stephen Warren <swarren@wwwdotorg.org>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 01/21/2016 09:03 PM, Simon Glass wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Bin,
>>>>>>>>
>>>>>>>> On 21 January 2016 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Jan 22, 2016 at 11:36 AM, Simon Glass <sjg@chromium.org>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 21 January 2016 at 18:39, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi Stephen,
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren
>>>>>>>>>>> <swarren@wwwdotorg.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> From: Stephen Warren <swarren@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@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.
>>>>>>>>
>>>>>>>> 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?
>>>>
>>>>
>>>>
>>>> We try to probe devices only when used. E.g. on beaver, if you are not
>>>> net-booting, you actually don't need PCI.
>>>
>>>
>>>
>>> Are you saying that the first network command I execute in U-Boot should
>>> probe Ethernet device and hence PCI devices right now in the current
>>> U-Boot
>>> code?
>>>
>>> That doesn't work right now. If it did work, that would probably be OK.
>>
>>
>> Two options:
>> - Add a 'pci start' command to your script
>> - Enable the PCI auto-probe Kconfig option
>>
>> Boards can then choose which they prefer.
>
>
> I see there's already a "pci enum" command that can be enabled:
>
> #ifdef CONFIG_SYS_LONGHELP
> static char pci_help_text[] =
>         "[bus] [long]\n"
>         "    - short or long list of PCI devices on bus 'bus'\n"
> #ifdef CONFIG_CMD_PCI_ENUM
>         "pci enum\n"
>         "    - re-enumerate PCI buses\n"
> #endif
>
> I'm tempted to re-enable that for DM, by making the implementation of
> pci_init() exist even with CONFIG_DM_PCI, then enhance
> config_distro_bootcmd.h to have it run "pci enum" any time before it might
> touch a PCI device, similar to the existing USB and SCSI enumeration
> support.
>
> The only wart is that the command help text currently says "*re-*enumerate
> PCI buses" rather than just "enumerate PCI buses", which implies the
> semantics would always cause an enumeration even on the second/...
> execution, whereas it'd be simpler to have it work like "usb start", i.e.
> perform enumeration the first time but be a no-op any second/... time. Am I
> reading too much into the help text? If not, should I just rename the
> command to "pci start" for the DM case? I'm not sure if PCI hotplug is
> something we'll need to deal with; that'd be the only time the different
> semantics were particular useful.

I'd suggest making 'pci enum' do the enumeration in the driver model
case, and it will only do this once. You can update the help. I don't
believe we found anyone interested in the current functionality so it
can die when things move to DM.

On the other hand, if we do want to implement it, it would involve
device_remove() and device_unbind() calls on the PCI controllers,
which would recursively cause them all to be deleted. This is
problematic since we'd then need to re-bind the controllers so that
that device tree PCI devices are bound in pci_uclass_post_bind(). So
IMO it is more complexity than it is worth.

The message in the code is ready for your action:

printf("This command is not yet supported with driver model\n");

Regards,
Simon

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

[Bin Meng]

On Sat, Jan 23, 2016 at 5:48 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 01/22/2016 01:32 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 22 January 2016 at 12:38, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>
>>>
>>> On 01/21/2016 09:03 PM, Simon Glass wrote:
>>>>
>>>>
>>>> Hi Bin,
>>>>
>>>> On 21 January 2016 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>
>>>>>
>>>>> On Fri, Jan 22, 2016 at 11:36 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 21 January 2016 at 18:39, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi Stephen,
>>>>>>>
>>>>>>> On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren
>>>>>>> <swarren@wwwdotorg.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> From: Stephen Warren <swarren@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@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.
>>>>
>>>> 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] [PATCH] pci: restore initialization for DM_PCI

[Stephen Warren]

On 01/21/2016 06:39 PM, Bin Meng wrote:
> Hi Stephen,
>
> On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> From: Stephen Warren <swarren@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?
...
 > [1] http://patchwork.ozlabs.org/patch/569323/

Oh, I hadn't seen that patch. That patch seems to only probe the first 
PCI controller/port, which still leaves all the other controllers/ports 
non-operational.

The issue is this: The PCI driver never gets probed. This used to happen 
because all Ethernet drivers were probed, and the Ethernet drivers would 
call into PCI APIs to determine if PCI devices exist, which would then 
trigger the PCI driver to be probed.

However with the current code-base, nothing probes the PCI controller 
driver, so the entire bus enumeration process never happens. Since 
there's no way (e.g. shell command) to force the PCI device/driver to 
probe, it's currently impossible to use any PCI device.

This patch restores the original behaviour of probing all PCI 
controllers automatically at boot.

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

[Thierry Reding]

On Thu, Jan 21, 2016 at 04:35:33PM -0700, Stephen Warren wrote:
> From: Stephen Warren <swarren@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.
> 
> Fixes: 96350f729c42 ("dm: tegra: net: Convert tegra boards to driver model
> for Ethernet")
> Signed-off-by: Stephen Warren <swarren@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.

I think a command should work fine. Given that some boards might rely on
the existing behaviour, perhaps this could be controlled via a
configuration option. Another alternative might be to move the call to
pci_init() into board files. Then boards can choose to integrate the new
"pci start" command into their boot commands and remove the pci_init()
call at that point to preserve compatibility.

> ---
>  common/board_r.c         |  2 --
>  drivers/pci/pci-uclass.c | 15 +++++++++++++++
>  2 files changed, 15 insertions(+), 2 deletions(-)

Either way, this change restores network support on Jetson TK1, so

Tested-by: Thierry Reding <treding@nvidia.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160122/2927e641/attachment.sig>