From: Detlev Zundel <dzu@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ppc44x: config GPIOs for USB on canyonlands board
Date: Tue, 28 Sep 2010 16:16:05 +0200 [thread overview]
Message-ID: <m2iq1qkl7e.fsf@ohwell.denx.de> (raw)
In-Reply-To: <AANLkTinZjq+-odBZaUQrVStcpENS7woM_h_Ug2p8-5Cy@mail.gmail.com> (Feng Kan's message of "Fri, 24 Sep 2010 15:43:21 -0700")
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
--
A statistician can have his head in an oven and his feet in ice, and
he will say that on the average he feels fine.
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
prev parent reply other threads:[~2010-09-28 14:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-23 14:21 [U-Boot] [PATCH] ppc44x: config GPIOs for USB on canyonlands board Rupjyoti Sarmah
2010-09-23 18:56 ` Wolfgang Denk
2010-09-24 11:36 ` Rupjyoti Sarmah
2010-09-24 17:26 ` Feng Kan
2010-09-24 17:43 ` Wolfgang Denk
2010-09-24 22:43 ` Feng Kan
2010-09-28 14:16 ` Detlev Zundel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2iq1qkl7e.fsf@ohwell.denx.de \
--to=dzu@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox