[PATCH v3 13/28] pci: Update to use new sequence numbers

[Simon Glass]

Hi Tim,

On Wed, 14 Apr 2021 at 06:32, Tim Harvey <tharvey at gateworks.com> wrote:
>
> On Sat, Dec 19, 2020 at 8:43 AM Simon Glass <sjg at chromium.org> wrote:
> >
> > Now that we know the sequence number at bind time, there is no need for
> > special-case code in dm_pci_hose_probe_bus().
> >
> > Note: the PCI_CAP_ID_EA code may need a look, but there are no test
> > failures so I have left it as is.
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > ---
> >
> > Changes in v3:
> > - Update PCI to use manual sequence numbering
> >
> > Changes in v2:
> > - Use the sequence number directly instead of max bus
> >
> >  drivers/pci/pci-uclass.c | 45 ++++++++++++++++++++++++----------------
> >  drivers/pci/pci_auto.c   | 10 ++++-----
> >  2 files changed, 32 insertions(+), 23 deletions(-)
> >
> > Applied to u-boot-dm/next, thanks!
>
> Hi Simon,
>
> I have a (not yet submitted) pending patch to migrate the gwventana
> board to DM_PCI / DM_ETH that this particular patch broke and I'm
> trying to understand why.
>
> The Gateworks Ventana boards have a PCIe switch where the downstream
> PERST#'s are GPIO's off the switch and a e1000 PCIe GBe device is on
> one of those downstream ports. For non-dm PCI I have a
> 'board_pci_fixup_dev' function that allows board support to configure
> the switch's GPIO and toggle downstream PERST# during enumeration.
> When I add this function to dm_pci I end up getting a data abort when
> the e1000 driver tries to initialize (after PCI enumeration).

Firstly, I think I did the PCI conversion about 6 years ago so it is
not fresh in my memory.

>
> Any idea what is causing this and what I need to do to work around it?
> Nothing in my patch deals with device sequence numbers.

An abort presumably indicates that the memory is not there, so perhaps
the e1000 is still in reset, or has been set up to appear at a
different address?

You should be abe to use 'pci hdr 0.4.0' or whatever to look at the
BARs and make sure they are value with 'md', etc.

> Additionally I feel like the best way to add support for the custom
> downstream PCI switch reset requirements is to add a UCLASS_PCI driver
> for the switch in my board support but when I attempted that solution
> I run into an issue where pci read/write's cause a prefetch abort
> because I need to use imx_pcie_dm_{read,write}_config instead of the
> default ops. I'm not quite sure how to get hold of the ops for the imx

If you write a PCI driver then you can provide the access operations
yourself....see drivers/pci for some examples. I suggest you add
subnodes to the devicetree and specify the compatible string of your
PCI switch so it picks up the right driver.

> controller to set this up properly. Furthermore if I do end up with
> that solution I later need to be able to walk the PCI bus to perform
> various dt fixups on pci device nodes - do you have an example of how
> I could walk the bus using DM_PCI?

Do you mean a breadth-first search? It is something like:

struct udevice *dev;

static void do_something(struct udevice *parent)
{
   device_foreach_child_probe(dev, parent) {
       do_something((dev);
   }

...

struct udevice *bus;
int  ret;

ret = uclass_first_device_err(UCLASS_PCI, &bus);
if (ret)
   return log_msg_ret("pci", ret);
do_something(bus);

>
> Best regards,
>
> Tim

Regards,
Simon