Hi Linus, On 15/05/13 20:07, Linus Walleij wrote: > 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? 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
