Message-ID: <20111020154244.GA26083@opensource.wolfsonmicro.com>
Date:	Thu, 20 Oct 2011 16:42:44 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Barry Song <21cnbao@...il.com>,
	Shawn Guo <shawn.guo@...escale.com>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	linux-kernel@...r.kernel.org, Stephen Warren <swarren@...dia.com>,
	Linaro Dev <linaro-dev@...ts.linaro.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	David Brown <davidb@...eaurora.org>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [PATCH 2/2] pinctrl: add a generic control interface

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists