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

[James Hogan <james.hogan@imgtec.com>]

Hi Linus,

On 15/05/13 20:07, Linus Walleij wrote:
> On Tue, May 14, 2013 at 2:22 PM, James Hogan <james.hogan@imgtec.com> 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?

It's a very board specific thing (that was just one example). To
generalise your suggestion would make all muxing pingroups contain no
pins (which is perhaps accurate since the thing that's muxed by the
group is a set of internal signals that may be muxed out to pins via the
SELECT bits).

Cheers
James