All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Linus Walleij <linus.walleij@linaro.org>, FanWu <fwu@marvell.com>,
	ext Tony Lindgren <tony@atomide.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stephen Warren <swarren@nvidia.com>, Chao Xie <cxie4@marvell.com>,
	ylmao@marvell.com, njiang1@marvell.com, tianxf@marvell.com,
	fswu@marvell.com
Subject: Re: [PATCH] pinctrl: add params in disable_setting for different usage
Date: Fri, 16 May 2014 13:53:11 -0600	[thread overview]
Message-ID: <53766CA7.8000507@wwwdotorg.org> (raw)
In-Reply-To: <CACRpkdaTX_SyWXrpysaJGLee+SnLPxdQQkvE-5Xy+OmHCcseVw@mail.gmail.com>

On 05/16/2014 10:21 AM, Linus Walleij wrote:
> On Wed, May 14, 2014 at 4:01 AM,  <fwu@marvell.com> wrote:
> 
>> From: Fan Wu <fwu@marvell.com>
>>
>> The patch added params in disable_setting to differ the two possible usage,
>> 1.Only want to disable the pin setting in SW aspect, param can be set to "0"
>> 2.Want to disable the pin setting in both HW and SW aspect, param can be set to "1";
>>
>> The reason why to do this is that:
>> To avoid duplicated enable_setting operation without disabling operation which will
>> let Pin's desc->mux_usecount keep being added.
>>
>> In the following case, the issue can be reproduced:
>> 1)There is a driver need to switch Pin state dynamicly, E.g. b/t "sleep" and
>> "default" state
>> 2)The Pin setting configuration in the two state is same, like the following one:
>> component a {
>>         pinctrl-names = "default", "sleep";
>>         pinctrl-0 = <&a_grp_setting &c_grp_setting>;
>>         pinctrl-1 = <&b_grp_setting &c_grp_setting>;
>> }
>> The "c_grp_setting" config node is totaly same, maybe like following one:
> 
> Hm this is a quite interesting thing if we can get it in place, but
> I need Stephen's consent, also Tony should have a look at this as
> I know he's had the same problem as you in pinctrl-single.

I only briefly looked at the patch, but it probably solves/hides the
immediate problem.

However, rather than doing this, why not just remove
pinmux_disable_setting() completely. It doesn't make sense to "disable a
mux selection" (some value is always selected in the mux register field)
any more than it does to "disable a drive strength selection". We don't
have a pinconf_disable_setting(), and couldn't really add one if we
wanted. For consistency, let's just remove pinmux_disable_setting(). Do
you agree?

  reply	other threads:[~2014-05-16 19:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-14  2:01 [PATCH] pinctrl: add params in disable_setting for different usage fwu
2014-05-16 16:21 ` Linus Walleij
2014-05-16 19:53   ` Stephen Warren [this message]
2014-05-19  2:54     ` FanWu
2014-05-19 20:55       ` Stephen Warren
2014-05-20  3:05         ` FanWu
2014-05-20 18:42           ` Stephen Warren
2014-05-21  6:21             ` FanWu
2014-05-21 22:52               ` Tony Lindgren
2014-05-23 14:10                 ` Linus Walleij

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=53766CA7.8000507@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=tony@atomide.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.