From: Stephen Warren <swarren@wwwdotorg.org>
To: FanWu <fwu@marvell.com>
Cc: "linus.walleij@linaro.org" <linus.walleij@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"swarren@nvidia.com" <swarren@nvidia.com>,
Chao Xie <cxie4@marvell.com>, Yilu Mao <ylmao@marvell.com>,
Ning Jiang <njiang1@marvell.com>,
Xiaofan Tian <tianxf@marvell.com>, Fangsuo Wu <fswu@marvell.com>
Subject: Re: [Pinctrl] A suggestion to avoid duplicated enabling operation on a pin's setting
Date: Tue, 13 May 2014 09:42:32 -0600 [thread overview]
Message-ID: <53723D68.6010808@wwwdotorg.org> (raw)
In-Reply-To: <5371B36E.5030309@marvell.com>
On 05/12/2014 11:53 PM, FanWu wrote:
...
> About the glitch I mentioned before, I want to make myself clear.
> If there is a case like the following one:
> pinctrl-0 = <&a_grp_settingA>;
> pinctrl-1 = <&a_grp_settingB>;
> "a_grp_settingA" and "a_grp_settingB" are used to described the same
> Pin's different mux and function configuration
> In my understanding,
> When there is a need to switch Pin group state, the current code will
> disable "a_grp_settingA" first ahead of enabling "a_grp_settingB", right ?
Yes.
> Do you mean the case I mentioned will not be a glitch ?
I guess you're talking about that:
>> In the original code, the Pin setting will be changed to the
>> disabled/safe state when Pin state is switched if the old setting is not
>> existed in new state rather than directly switched to the new Pin
>> setting. Also a possible glitch?
Yes, in this case, there is no glitch. However, there is certainly a
change in HW configuration. A glitch is a temporary short-term
accidental change in output value or configuration. In the case quoted
immediately above, the change is permanent - at least until some other
state is activated later. Hence, there is no glitch. However, there
certainly is a change in HW configuration, and that could be just as
problematic, depending on the HW and exact pin configuration.
prev parent reply other threads:[~2014-05-13 15:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <534B558A.3040504@marvell.com>
[not found] ` <534F8B35.7090103@marvell.com>
[not found] ` <5366F387.4060402@marvell.com>
[not found] ` <5367CD62.7030205@wwwdotorg.org>
2014-05-07 8:02 ` [Pinctrl] A suggestion to avoid duplicated enabling operation on a pin's setting FanWu
2014-05-12 20:20 ` Stephen Warren
2014-05-13 5:53 ` FanWu
2014-05-13 15:42 ` Stephen Warren [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=53723D68.6010808@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=cxie4@marvell.com \
--cc=fswu@marvell.com \
--cc=fwu@marvell.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=njiang1@marvell.com \
--cc=swarren@nvidia.com \
--cc=tianxf@marvell.com \
--cc=ylmao@marvell.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.