Message-ID: <CACRpkdaaUmze+W1n4NkApTX0Se1VJAmD+AJSm36QbsKVDzdnRA@mail.gmail.com>
Date:	Thu, 20 Oct 2011 16:43:30 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
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 4:18 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Thu, Oct 20, 2011 at 04:04:47PM +0200, Linus Walleij wrote:

>> I think (and of course this may be completely wrong, but it's my
>> working hypthesis) that the things that software wants to do to
>> pins are:
>
> 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?

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
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.

And the same could probably be said about why the clock
framework insist on expressing frequencies in Hz
including all the trouble with using clk_round_rate() if all my
SoC drivers doing clk_get_rate() and clk_set_rate() already know
very well that rate 0x54 is the frequency it wants to set.

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?

>> Yet again, can I have some examples of what
>> PIN_CONFIG_USER may *actually* be, which would be
>> absolutely impossible to express in some neutral way, and
>> ridiculous to have in the generic enum?
>
> 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.)

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?

On a related key we have the part that gpiolib is handling already,
setting a pin to input or output and driving it low or high -
I have no plans to model that through the pinconfig API by
exposing some PIN_CONFIG_SET_OUTPUT,
PIN_CONFIG_SET_INPUT, PIN_CONFIG_DRIVE_HIGH,
PIN_CONFIG_DRIVE_LOW, that would be madness, what we
do is of course expose a struct gpio_chip interface for that
stuff and register to gpiolib.

Thus it might be that pins should express their voltage domain
switches as a regulator rather than trying to do it in pin control?

Yours,
Linus Walleij
--
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