[U-Boot] [PATCH 2/5] pci: option for configurable delay between pci reset and pci bus scan

Anatolij Gustschin
2011-10-11T15:16:05Z

Hi Stefan,

On Mon, 30 May 2011 16:10:34 +0200
Stefan Roese <sr@denx.de> wrote:

> Hi Anatolij and Detlev,
>
> On Monday 30 May 2011 09:45:08 Detlev Zundel wrote:
> > >> Hm, I'm not sure I understand the situation, so please correct me. We
> > >> have a "pcidelay" variable, which is used to wait before
> > >> pci_board_init() (I'm not counting the semantically different usage in
> > >> the esd boards). This does not fit your need, so you define
> > >> pci_scan_delay which is used _after_ pci_init_board(), correct?
> > >
> > > yes, this is correct.
> > >
> > >> If this is correct, then why don't you keep your new delay also in the
> > >> pci_init() function so that the delays are easily visible on code
> > >> inspection? But wait, if this is only needed for this very board, then
> > >> why don't we put the delay into digsys pci_init_board? Actually I think
> > >> this is the best way, as on this board we always need the delay as PCI
> > >> is not hotplug.
> > >
> > > The reason for not keeping new delay in pci_init() is:
> > > pci_init_board() starts scanning the bus (calls pci_hose_scan()), so
> > > when pci_init_board() returns, it is too late, the scanning is
> > > already completed.
>
> Right. With this PCI reset "design", the current "pcidelay" option won't work
> for these platforms. Too bad.
>
> But thinking more about it, couldn't your new code location supersede the old
> one before pci_init_board()? If this really is the case (we would need to
> check with users of this "pcidelay" env variable, Mattias?), then we could
> remove the old code in pci_init() and only use your new version. We would need
> to use the old env variable name "pcidelay" though, since there are boards in
> the field already using this version.
>
> Anatolij, what do you think?

This should work, I think. I'll send a patch moving pcidelay code to
new location.

> Matthias, could you do some tests on some esd boards with the new version when
> available, to make sure that we don't break backwards compatibility?

Would be great if Matthias could test the patch.

Thanks,
Anatolij

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de