public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kevin Bracey <kevin@bracey.fi>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Kyungmin Park" <kmpark@infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Stephen Warren" <swarren@wwwdotorg.org>,
	"Tomasz Figa" <t.figa@samsung.com>,
	"Doug Anderson" <dianders@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Kukjin Kim" <kgene.kim@samsung.com>,
	"Thomas Abraham" <thomas.abraham@linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>
Subject: Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
Date: Mon, 25 Nov 2013 22:01:42 +0200	[thread overview]
Message-ID: <5293ACA6.7060403@bracey.fi> (raw)
In-Reply-To: <CACRpkdbyjm0X9RX+8WjqQxBPyRjBOAunkqVcO-0KUd1PTdGavA@mail.gmail.com>

On 25/11/2013 16:34, Linus Walleij wrote:
> On Wed, Nov 20, 2013 at 1:02 AM, Kyungmin Park <kmpark@infradead.org> wrote:
>> On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>> I think that last point should be addressed by having a driver that owns
>>> the GPIO set it to the desired output level, and the implementation of
>> Some pins are not connected (NC). At that cases, there's no drivers to
>> handle it. To reduce power leakage, it sets proper configuration with
>> values instead of reset values.
> This is correspondant to the PIN_CONFIG_OUTPUT from
> include/linux/pinctrl/pinconf-generic.h

Indeed it is - I was waiting for someone to point that out. Now we've 
got there...

I've been working on extending the shmobile PFC driver to provide 
"gpio-mode" and implement PIN_CONFIG_OUTPUT as described by 
Documentation/pinctrl.txt, primarily to handle sleep states, but I have 
begun to wonder about the initial state problem, as discussed here.

As far as I can see, we can't currently specify "fallback" states for 
pins, which is one of Tomasz' key requirements.

We can specify "hog" states, and we can specify "default for a driver", 
but not "default before/in absence of a driver" or "sleep in absence of 
a driver". Having a hog precludes any finer driver control, AFAICT.

Some of our existing pre-pinconf board files have a "unused pins" table 
which is used to claim and pull GPIOs. I've converted that to "hog" 
pinconf, but that only works because the table omits all pins used by 
drivers. And, unsurprisingly, that's been error-prone; if those tables 
originally covered all unused pins, they don't any more.

I'd like confidence that we can get every pin into the correct state by 
having a fully-populated table containing all pins, that can be used 
regardless of which drivers start. I think what we're lacking is a "weak 
hog". Whatever you call that. :)

That would also specify the state to fallback to when a group is 
released (where we currently do pinmux_disable_setting).

Thoughts?

Kevin



  reply	other threads:[~2013-11-25 21:19 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-19 17:15 [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc Tomasz Figa
2013-11-19 18:46 ` Stephen Warren
2013-11-19 18:59   ` Doug Anderson
2013-11-19 19:16     ` Stephen Warren
2013-11-20  0:02       ` Kyungmin Park
2013-11-20  0:07         ` Stephen Warren
2013-11-20 12:51           ` Mark Brown
2013-11-25 14:34         ` Linus Walleij
2013-11-25 20:01           ` Kevin Bracey [this message]
2013-11-26  0:30             ` Tomasz Figa
2013-12-03  9:31               ` Linus Walleij
2013-12-03  9:33                 ` Tomasz Figa
2013-12-03  9:29             ` Linus Walleij
2013-12-05 15:07               ` Mark Brown
2013-12-05 15:11                 ` Tomasz Figa
2013-12-05 16:49                   ` Kevin Bracey
2013-12-05 17:03                     ` Tomasz Figa
2013-12-05 18:00                   ` Mark Brown
2013-12-09 10:22                 ` Linus Walleij
2013-12-09 17:04                   ` Mark Brown
2013-12-05 23:54               ` Stephen Warren
2013-12-09 12:57                 ` Linus Walleij
2013-11-20 14:57     ` Tomasz Figa
2013-11-20 13:38   ` Tomasz Figa

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=5293ACA6.7060403@bracey.fi \
    --to=kevin@bracey.fi \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=heiko@sntech.de \
    --cc=kgene.kim@samsung.com \
    --cc=kmpark@infradead.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=swarren@wwwdotorg.org \
    --cc=t.figa@samsung.com \
    --cc=thomas.abraham@linaro.org \
    /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