public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox