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

[Anatolij Gustschin <agust@denx.de>]

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