x86: apl: PCI enumeration issue

[Bin Meng]

Hi Bernhard,

On Mon, Mar 30, 2020 at 3:35 PM Bernhard Messerklinger
<bernhard.messerklinger at br-automation.com> wrote:
>
> Hi Simon, Bin,
>
> I am facing problems with the PCI enumeration at SPL loader stage.
> On our HW we have PCIe x2 port connected to a FPGA. Since SPL does pci
> enumeration before FSP-S has been called the enumeration of the second port of
> the pci x2 connection causes the system to hang.

Do you know why the 2nd port hang happens, but not the 1st port? Is
that because in order to get 2nd port working something is done in
FSP-S?

>
> In my configuration PCI 0.13.0 is a X2 port. So, if the pci_bind_bus_devices
> function wants to read the PCI_VENDOR_ID from the PCI device 0.13.1 the system
> hangs.
>
> int pci_bind_bus_devices(struct udevice *bus)
> {
>         ulong vendor, device;
>         ulong header_type;
>         pci_dev_t bdf, end;
>         bool found_multi;
>         int ret;
>
>         found_multi = false;
>         end = PCI_BDF(bus->seq, PCI_MAX_PCI_DEVICES - 1,
>                       PCI_MAX_PCI_FUNCTIONS - 1);
>         for (bdf = PCI_BDF(bus->seq, 0, 0); bdf <= end;
>              bdf += PCI_BDF(0, 0, 1)) {
>                 struct pci_child_platdata *pplat;
>                 struct udevice *dev;
>                 ulong class;
>
>                 if (!PCI_FUNC(bdf))
>                         found_multi = false;
>                 if (PCI_FUNC(bdf) && !found_multi)
>                         continue;
>
> #if defined(CONFIG_SPL_BUILD)
>                 if (PCI_DEV(bdf) == 0x13 && PCI_FUNC(bdf) == 1)
>                         continue;
> #endif
>
>                 /* Check only the first access, we don't expect problems */
>                 ret = pci_bus_read_config(bus, bdf, PCI_VENDOR_ID, &vendor,
>                                           PCI_SIZE_16);
>
> At the moment, I fixed this issue by adding an #ifdef which skips the config read
> on this device.
>
> I think a way to solve this issue could be to add a new devic-tree property
> like it's done here with "pci,no-autoconfig":
> https://lists.denx.de/pipermail/u-boot/2020-March/402276.html
>
> But i don't know if it's good to put more apollolake specific stuff into the
> pci-uclass.
>
> Maybe we should add an apollolake specific pci_uclass_post_probe override.
> This could maybe be done by adding a spcecific pci driver like pci_x86 for
> apollolake platform and override the post_probe argument of the pci_uclass.
> Then we could also move the other apollolake specific things into this driver.
>
> What do you think about this?
> Do you have better/other ideas?
>

Regards,
Bin