Re: [PATCH v2] pinctrl: add support for group and pinmux states

[Linus Walleij]

On Sat, Jan 7, 2012 at 12:45 AM, Stephen Warren <swarren@xxxxxxxxxx> wrote:

> Linus Walleij wrote at Monday, January 02, 2012 4:36 AM:

> The main issue I see is that:
>
> * With the current pin mux API, the driver is simply defining what the
> SoC can do, and the mapping table (outside the driver) is selecting which
> of those things to do. There's zero knowledge (or need) of board-specific
> data in the pin mux driver.
>
> * With your proposal for pin configuration, the driver still of course
> defines what the SoC can do since it must implement it, but also the
> (e.g. platform) data that defines which of those things to do is now
> Handled by the driver rather than the pinctrl/pinconfig core.
>
> That seems like a needless semantic difference.

I'm  buying this and the following argument. I need to come up with
something better. Apparently this idea of states need to be paired
with a proper state configuration table like you suggest, so no
shortcuts (I was hoping to do one, then the other) I will have to
code it all in one go.

One minor thing:

> IIRC, I was talking about two different kinds of states.
>
> The PIN_GROUP_STATE_* you quoted above are individual pin group states.
>
> The "standard states" in the second chunk I wrote above was regarding
> states of an entire device (a pmx entry I think)

They were to use the same states.

Since a PMX corresponds to one or more groups these are easy
to couple, that's what it's all about. So setting the state of a pmx just
falls through to the state of it's mapped in groups. And if these
share the same syntax, it's a quick thing to do.

This will work with string-named states too I think, we'll see.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/