public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Barry Song <21cnbao@gmail.com>,
	Shawn Guo <shawn.guo@freescale.com>,
	Linus Walleij <linus.walleij@stericsson.com>,
	linux-kernel@vger.kernel.org, Stephen Warren <swarren@nvidia.com>,
	Linaro Dev <linaro-dev@lists.linaro.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	David Brown <davidb@codeaurora.org>,
	Grant Likely <grant.likely@secretlab.ca>
Subject: Re: [PATCH 2/2] pinctrl: add a generic control interface
Date: Thu, 20 Oct 2011 16:42:44 +0100	[thread overview]
Message-ID: <20111020154244.GA26083@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CACRpkdaaUmze+W1n4NkApTX0Se1VJAmD+AJSm36QbsKVDzdnRA@mail.gmail.com>

On Thu, Oct 20, 2011 at 04:43:30PM +0200, Linus Walleij wrote:
> On Thu, Oct 20, 2011 at 4:18 PM, Mark Brown

> > The other question is if it's worth bouncing through too much of an
> > abstraction layer when both ends of the API are fixed.

> If drivers doing pinctrl are used in more than one SoC
> both ends aren't fixed. But maybe I'm wrong in assuming that
> such things exist?

There's definitely drivers that will be used over multiple SoCs,
although I'm not sure what the overlap is between them and devices that
need to fiddle with their pin settings at runtime (and how much of the
pin settings they can usefully fiddle with).

> I bet someone made a claim about regulators in its
> infancy, "I just want to communicate to the regulator to set
> voltage number 0x14, the framework shouldn't care what

Not really, actually - with regulators there's a blatantly obvious
abstraction layer to set up as they're physically distinct devices.

> voltage that actually is." The selectors is a good compromise
> that unify expressing voltages and currents with fixed
> discrete steps actually, that is why I like it so much.

That's mostly just a reflection of the reality of how one interacts with
devices of course - at the end of the day you have to translate the
settings into a register write so...

> So there is some lesson abou abstraction to be learned
> here, and the question is, whatever it is that pin control
> is passing around, should the core or anyone else really
> care, or should it be opaque in difference from regulators
> and clocks?

Yes, much of this depends on how much generic drivers (as opposed to
SoCs or boards) are going to need to know about their pin configuration
and talk about it to something else.

> > One fun example is that we have some devices with pins which have
> > runtime controllable voltage domains, there's no obvious SI unit mapping
> > for those.

> If you mean they can only be switched on or off yes,
> they rather need some ON vs OFF parameter setting without
> any unit argument. The unit argument is already optional for a few
> parameters.

> (If you mean you can control the voltage I guess Volt is a nice
> derived SI unit, but I guess you can't since you put the claim
> that way.)

Neither of these things.  As with all pins these are referenced to
particular supply voltages but fairly unusually these devices are able
to change the supply the pin is referenced to.  This changes the level
that outputs are driven at and the levels used for identification of
logic levels on input.

> In Ux500 we model our power domain switches as regulators,
> does such a property even belong in pin control? Is there
> one power domain switch per pin you mean, or a power switch
> for a whole group of pins?

This isn't an on/off control and in this cae it's per pin.

  reply	other threads:[~2011-10-20 15:42 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-19 16:21 [PATCH 2/2] pinctrl: add a generic control interface Linus Walleij
2011-10-19 23:04 ` Stephen Warren
2011-10-20  2:45   ` Shawn Guo
2011-10-20 13:44     ` Linus Walleij
2011-10-20 18:41       ` Stephen Warren
2011-10-20 13:46     ` Linus Walleij
2011-10-20 10:24   ` Linus Walleij
2011-10-20 18:46     ` Stephen Warren
2011-10-20  2:31 ` Shawn Guo
2011-10-20  9:17   ` Barry Song
2011-10-20 13:10     ` Shawn Guo
2011-10-20 14:18       ` Linus Walleij
2011-10-23  8:51         ` Shawn Guo
2011-10-25  4:49           ` Stephen Warren
2011-10-20 14:04     ` Linus Walleij
2011-10-20 14:18       ` Mark Brown
2011-10-20 14:43         ` Linus Walleij
2011-10-20 15:42           ` Mark Brown [this message]
2011-10-21 12:28             ` Linus Walleij
2011-10-21 12:30               ` Mark Brown
2011-10-21 12:51                 ` Linus Walleij
2011-10-21 12:55                   ` Mark Brown
2011-10-21 12:57                     ` Linus Walleij
2011-10-21 15:24                       ` Mark Brown
2011-10-20 17:26   ` Stephen Warren
2011-10-23  8:25     ` Shawn Guo
2011-10-25  4:43       ` Stephen Warren

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=20111020154244.GA26083@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=21cnbao@gmail.com \
    --cc=davidb@codeaurora.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linaro-dev@lists.linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawn.guo@freescale.com \
    --cc=swarren@nvidia.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