Hi Feng,
[general remark - isn't it possible that you quote mails "the regular way"[1]? I'm having a hard time to distinguish the new text from the original text].
On Fri, Sep 24, 2010 at 10:43 AM, Wolfgang Denk wd@denx.de wrote:
Dear Feng Kan,
In message AANLkTin-rbM0NDqZmZKCYp45-m9S+3H_Fb7DwzzEHkUw@mail.gmail.com you wrote:
FKAN: Dear Wolfgang, is the symmetry needed here? If a user plan to use the usb, he will trigger the function. Otherwise, on a stop what value would we put it back to.
Design rules say:
Shall initialize only such peripherals used by U-Boot itself, and must deinitialize them after use. Note that especially the deinitialization is mandatory!
FKAN: I agree, thanks. However, this conflict with one of your other rule "Don't make U-Boot slow". If another software entity wish to use the GPIO after, the code would deinit to gpio state and the other init would init gpio to the same state. Essentially doubling the code doing the same thing.
The time it takes to initialize a GPIO pin is really negligible in comparision to the gain of robustness and correctness of the code. When a driver needs the pin in a certain state, it should initialize this and _not_ depend on any other piece of software. This is the well known rule of modularity[2].
Isn't this GPI reset to the initial values part of the deinitialization sequence?
FKAN: In this case, gpio is double muxed in functionality. Do we need to remember state if the gpio is tri-muxed?
I don't understand this question. The de-initialization is meant to stop functional blocks and put pins into a "conservative state", i.e. configure GPIOs as inputs so that they don't drive possible shared lines. Code using the pins will surely know which mode they need and put the pins into this mode upon initialization.
Cheers Detlev
[1] http://www.netmeister.org/news/learn2quote.html [2] http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2877537