Testing pci_mvebu.c with Kirkwood SoCs

[Tony Dinh]

Also probably a new Kirkwood udevice is needed in
drivers/usb/host/xhci-mvebu.c (if armada-380-xhci is not appropriate).

static const struct udevice_id xhci_usb_ids[] = {
        { .compatible = "marvell,armada3700-xhci" },
        { .compatible = "marvell,armada-380-xhci" },
        { .compatible = "marvell,armada-8k-xhci" },
        { }
};

But I guess the fact that it works during board_late_init must be
because of a generic USB_XHCI driver being used?

Thanks,
Tony

On Fri, Nov 12, 2021 at 1:46 PM Tony Dinh <mibodhi at gmail.com> wrote:
>
> Hi Stefan & Pali,
>
> On Fri, Nov 12, 2021 at 7:06 AM Pali Rohár <pali at kernel.org> wrote:
> >
> > On Friday 12 November 2021 15:36:31 Stefan Roese wrote:
> > > On 11/11/21 22:10, Pali Rohár wrote:
> > > > On Wednesday 10 November 2021 16:04:20 Tony Dinh wrote:
> > > > > I've also tried mdelay(3000), just to be sure. The result was the same
> > > > > hang in 'usb start'.
> > > >
> > > > Ok. So put pci_init() into board_late_init().
> > > >
> > > > There are some more cleanup and fixes patches for pci_mvebu.c on mailing
> > > > list. After they are merged I will prepare and send final PCI Kirkwood
> > > > patch for testing.
> > >
> > > Chiming in a bit late in this discussion:
> > >
> > > Is an explicit call to pci_init() necessary in this Kirwood case? IIRC,
> > > the DM infrastructure should make sure that all device are probed - but
> > > only when really needed. So if you don't need PCI in the boot process
> > > at all, then it's not probed at all. Or if you set CONFIG_PCI_PNP this
> > > will be done always. Then there should be no need for the additional
> > > "pci enum".
> >
> > CONFIG_PCI_PNP probe and initialize all devices behind host bridge.
> > CONFIG_PCI_INIT_R probe and initialize host bridge (this is done by
> > calling pci_init()). Based on tests (see discussion in this thread) it
> > looks like that CONFIG_PCI_INIT_R calls pci_init() too early and
> > initialization is failing. So unsetting CONFIG_PCI_INIT_R and calling
> > pci_init() manually from board_late_init() (which is called later than
> > CONFIG_PCI_INIT_R) seems to fix these issues. No idea why...
> > > I might be missing something - did not check in depth.
>
> I think this must be the problem. Sorry I've missed this:
>
> config USB_XHCI_MVEBU
>         bool "MVEBU USB 3.0 support"
>         default y
>         depends on ARCH_MVEBU
>         select DM_REGULATOR
>         help
>           Choose this option to add support for USB 3.0 driver on mvebu
>           SoCs, which includes Armada8K, Armada3700 and other Armada
>           family SoCs.
>
> So I'll need rebuild with "depends on (ARCH_MVEBU || ARCH_KIRKWOOD)"
> and do some more testing.
>
> Thanks,
> Tony
>
> > >
> > > Thanks,
> > > Stefan