Testing pci_mvebu.c with Kirkwood SoCs

[Pali Rohár]

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.
> 
> Thanks,
> Stefan