On Thu, Sep 1, 2011 at 9:43 PM, Stephen Warren wrote:
> Looking forward a little, I expect that different SoCs have such a
> different set of biasing/driver-strength/... options that actually having
> some formalized semantic representation of what those options are doesn't
> make sense; all we n
Linus Walleij wrote at Thursday, September 01, 2011 3:13 AM:
...
> I will need Arnds or similars advice on it so we don't
> grow a lib/mysql into the kernel with this kind of
> schemes and get slammed for overcomplicating
> things when trying to merge the beast.
I /think/ the whole multi-row thing
Damn gmail punished me when writing the reply, sent by mistake :-(
And I intended to post v6 first.
These parts were being typed as I screwed up:
On Thu, Sep 1, 2011 at 10:59 AM, Linus Walleij wrote:
> function and group names shall match what is
> presented from the pin controller driver.
>
>
On Mon, Aug 29, 2011 at 11:32 PM, Stephen Warren wrote:
> 1) There is still a 1:1 correspondence between what a function in the
> pinmux core<->driver interface, and the pinmux mapping table. I believe
> we need a 1:n correspondence.
Yes I know that, but the positions were never
about solving th
Hi Linus,
This is looking really great! A couple of pedantic nits inline, but
with the gpio ranges support I think this covers all of the bases that
we need from pin control, so thanks!
Jamie
On Mon, Aug 29, 2011 at 11:10:01AM +0200, Linus Walleij wrote:
[...]
> diff --git a/drivers/pinctrl/M
> +Interaction with the GPIO subsystem
> +===
> +
> +The GPIO drivers may want to perform operations of various types on the
> same
> +physical pins that are also registered as GPIO pins.
> +
> +Since the pin controller subsystem have its pinspace local to the pin
>
Linus Walleij wrote at Monday, August 29, 2011 3:10 AM:
> This creates a subsystem for handling of pin control devices.
> These are devices that control different aspects of package
> pins.
...
> - Defined a "position" for each function, so the pin controller now
> tracks a function in a certain
