Re: [PATCH 5/8] pinctrl-tz1090: add TZ1090 pinctrl driver

[Linus Walleij]

On Tue, May 14, 2013 at 2:22 PM, James Hogan <james.hogan@xxxxxxxxxx> wrote:

> I think that's the other way around, i.e. that's talking about mapping
> several pingroups to the same function. The next paragraph is closer to
> the problem:
>
> Documentation/pinctrl.txt
>> - PINS for a certain FUNCTION using a certain PIN GROUP on a certain
>>   PIN CONTROLLER are provided on a first-come first-serve basis, so if some
>>   other device mux setting or GPIO pin request has already taken your physical
>>   pin, you will be denied the use of it. To get (activate) a new setting, the
>>   old one has to be put (deactivated) first.
>
> In my example the tft pingroup contains all the tft pins, but I might
> want a particular pin inside that pingroup to never be controlled by the
> mux (using the per-pin mux disable (SELECT) bits).
>
> So if I use pinmux I'd have something like:
> * "tft" pingroup maps to "tft" function
> * "tft_green0" pingroup (containing individual pin inside "tft"
> pingroup) maps to "none" function to disable muxing (or the inverse,
> with each pin in use mapping to "periph" to enable muxing).
> in which case the pin has multiple muxes "controlling" it (even though
> they're sort of nested). The above paragraph seems to condemn this
> arrangement.

So if this usecase is what you want to support, why don't you just
exclude that one pin from the "tft" group and put it into another
group?

If you want it activated anyway as part of some state e.g.
"default", you can just specify multiple groups for that state.

> Or using pinconf I'd have something like:
> * "tft" pingroup maps to "tft" function
> * "tft_green0" pin (in "tft" pingroup) has pinconf "no-periph" (or the
> inverse, with each one in use having pinconf "periph")

If you want some pinconf set up for this one pin as part
of a configured state that's OK even if the pin isn't muxed
in as part of this state. muxing and config are orthogonal.

> Or modifying the pinctrl subsystem maybe something like:
> * [optional: particular named pins in] "tft" pingroup map to "tft" function
> that way enabling a mux doesn't necessarily apply to all pins in the
> group, and drivers for hardware that doesn't support partial enabling of
> the mux can reject it (I might experiment with this if I get the time).

No thanks, this will be hopeless to understand, the pinctrl
subsystem is already really hard for outsiders to understand,
let us not raise the bar even more...

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/