From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Mon, 30 May 2011 16:10:34 +0200 Subject: [U-Boot] [PATCH 2/5] pci: option for configurable delay between pci reset and pci bus scan In-Reply-To: References: <1306505304-9593-1-git-send-email-agust@denx.de> <20110527184348.2dfb025e@wker> Message-ID: <201105301610.34813.sr@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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? 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? Best regards, Stefan -- 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