Hi,
On 2 April 2017 at 05:50, Konstantin Porotchkin kostap@marvell.com wrote:
Hi, Simon,
On 04/01/2017 07:23 AM, Simon Glass wrote:
External Email
Hi Konstanitin,
On 30 March 2017 at 07:58, Konstantin Porotchkin kostap@marvell.com wrote:
On 03/30/2017 04:31 PM, Stefan Roese wrote:
(adding Simon to Cc for PCI related question)
On 28.03.2017 17:36, kostap@marvell.com wrote:
From: Konstantin Porotchkin kostap@marvell.com
Add PCIe initialization at early init stage. This operation has a side effect of detecting all PCIe plug-in cards, so the operator is not obligated to issue "pci enum" command though CLI for this purpose.
I'm not sure, if this should be handled this way. Simon, how is such a default PCI scan with DM supposed to get done? Is there a way do do this automatically without the need that the user has to issue "pci enum" manually?
I was not sure either, but did not see any other way of doing so. I asked to add this change by our Robot/Jenkins automation test team.
It seems reasonable. We actually have some platforms that require PCI buses to be probed before we know what devices are in the system, and some of these are important.
For example, if your network controller is on PCI then U-Boot will not know about it (unless you have it in the device tree) until PCI is probed.
I am wondering whether we should add a uclass flag that indicates that uclass members should be automatically probed on start-up?
It would not be set for SATA, but would be for PCI.
Thank you for your explanation. So, as the bottom line - Can I leave the PCIe init call in place and remove the SATA devices walk through from this patch? In my case the PCIe devices should be initialized for detection of a network card.
I think we should add a new DM_UC_FLAG_AUTO_PROBE to uclass.h which causes U-Boot to probe all devices in that uclass. This code could be added to dm_init_and_scan(). You could set the flag for PCI. Do you want to work up a patch for that?
This is your board code so I don't have a strong opinion on exactly what you do here - but I'd prefer to figure out a generic solution.
Thanks Kosta
Also convert the SATA first device scan to a walk through all availabel SATA devices.
This should be done in a separate patch. But seeing this, won't this SATA / AHCI code be gone completely from this file, once this is converted into a "real" DM AHCI / SCSI driver (please look at my preliminary patch for this).
Will check your patch, thank you. Maybe this change has to be completely removed if Simon guide me to the right solution for automatic PCIe enumeration.
Regards, Simon
Regards, Simon