[PATCH] RFC: pinctrl: grab default handler with bus notifiers

[Stephen Warren]

On 11/15/2012 10:24 AM, Linus Walleij wrote:
> On Thu, Nov 15, 2012 at 3:26 PM, Thomas Petazzoni
> <thomas.petazzoni at free-electrons.com> wrote:
> 
>> At ELCE, I've discussed with one person having an interesting use case:
>> they are using the same pin for two different purposes during the
>> system operation.
>>
>> At boot time, this pin is muxed as a SPI pin and is used to program the
>> bitstream of a FPGA. This is done in Linux, through a userspace
>> application.
>>
>> Then, once it is done, this pin is remuxed as a UART pin, and used to
>> communicate with another device on the board.
> 
> This is not related to the current discussion but interesting
> anyway...
> 
>> If the pinctrl configuration is done at probe() time inside the driver
>> core, then how can this kind of use case be supported? If each driver
>> does its own muxing, we could think of letting the SPI and UART driver
>> only do their muxing when the device is opened, and remove their muxing
>> when the device is closed, so that such sharing of pins for two
>> separate functions could be supported. Is this something we want to
>> support?
> 
> This is trivial to support after this commit in the current patch
> queue:
> commit 1a78958dc212f3698fdc543857af80155cb30f7f
> pinctrl: reserve pins when states are activated
> 
> Just define function maps for both devices using the same
> pins. Since the devices need to actively release their
> pins they need to go to a state which does not mux in
> any pins, so that the pins will be free:ed.
> 
> This state can be any arbitrary string, but if so desired
> for consistency we can define something like
> #define PINCTRL_STATE_DECOUPLED "decoupled"
> in include/linux/pinctrl/pinctrl-state.h to clearly
> mark that this is a state where the device is not
> using any pins at all.

Well, you'd also need to explicitly code the pinmux logic into the UART
driver, so that the UART's default state didn't prevent the SPI driver
from temporarily acquiring the pin to program the FPGA. It's rather
nasty to put that into the UART driver, which would presumably otherwise
be completely generic and not need runtime pinmux state changes. I
wonder if interjecting a mux driver between the UART/SPI and the pins
would help here, although presumably the UART driver would still need
some way of interacting with the mux driver which wouldn't be any better...