pinctrl: group/pin identity mapping

Hi All,

I'm trying to implement pinctrl support for our new cortex based SoC. Our driver should provide support for pinctrl/pinmux/pinconf combination without device tree handling at the moment.
However, I'm afraid I misunderstand how groups relate to muxed pins and I'd like to hear your suggestions.

Here's the HW: our I/O pins subsystem allows us to multiplex every controllable pins using up to 4 mutually exclusive functions, i.e. there is no notion of pin GROUP multiplexing at the HW level (one register per pin is available to setup multiplexing and other electronic properties like drive strength, pull up/down...).

Hi All,

I'm trying to implement pinctrl support for our new cortex based SoC. Our driver should provide support for pinctrl/pinmux/pinconf combination without device tree handling at the moment.
However, I'm afraid I misunderstand how groups relate to muxed pins and I'd like to hear your suggestions.

Here's the HW: our I/O pins subsystem allows us to multiplex every controllable pins using up to 4 mutually exclusive functions, i.e. there is no notion of pin GROUP multiplexing at the HW level (one register per pin is available to setup multiplexing and other electronic properties like drive strength, pull up/down...).

However, it seems the pinctrl subsystem requires the driver to provide pin groups for pinmux implementation.
So my question is: having no notion of HW pin groups whatsoever, should I:

1) implement a software/logical group that would arbitrarily gather multiple HW pins in a platform dependent manner ?

2) perform an identity mapping between HW pin and software/logical group with up to 4 groups/HW pins per pinmux function ?

3) anything else ? any way to bypass the pinctrl group logic to directly assign pins rather than groups to pinmux functions ?

Quoted 18 lines · Gr?gor Boirie

Hi All,

I'm trying to implement pinctrl support for our new cortex based SoC. Our driver should provide support for pinctrl/pinmux/pinconf combination without device tree handling at the moment.
However, I'm afraid I misunderstand how groups relate to muxed pins and I'd like to hear your suggestions.

Here's the HW: our I/O pins subsystem allows us to multiplex every controllable pins using up to 4 mutually exclusive functions, i.e. there is no notion of pin GROUP multiplexing at the HW level (one register per pin is available to setup multiplexing and other electronic properties like drive strength, pull up/down...).

However, it seems the pinctrl subsystem requires the driver to provide pin groups for pinmux implementation.
So my question is: having no notion of HW pin groups whatsoever, should I:

Quoted 8 lines

1) implement a software/logical group that would arbitrarily gather multiple HW pins in a platform dependent manner ?

2) perform an identity mapping between HW pin and software/logical group with up to 4 groups/HW pins per pinmux function ?

3) anything else ? any way to bypass the pinctrl group logic to directly assign pins rather than groups to pinmux functions ?

Here's my take.

pinctrl originally (early during design) only supported per-pin muxing. This didn't work for Tegra (since it really has register fields that affect muxing of multiple pins at once; groups), so I requested allowing per-group muxing as well. We ended up only allowing per-group muxing and dropped per-pin muxing:-( So, /my/ intention was to only use groups for true groups in HW.

However, many others have taken this group muxing capability and used it for a different purpose; to define SW-only groups that end up affecting HW registers/fields and hence multiple pins at once, e.g. a group for for each of the possible mux locations for e.g. HW module UART A , which contain s of the pins used for that mux option.

So, you have two choices:

a) (Like Tegra30): Define a group for each pin, that contains just that one pin. This will allow you to pick the mux option for each pin individually (since there's a group per pin) in the pinctrl mapping table. In my (personal) opinion (which is evidently rarely shared), this is the correct approach, since the pinctrl driver directly models the HW capabilities. Also, if/when pinctrl re-gains the capability to request mux options per-pin in addition to per-group, the conversion will likely be quite trivial if you want to do so.

b) For each HW module, for each set of pins it makes sense to use for that HW module (i.e. all the different sets of pins it can be mux'd to), create a group for those pins. Many pins will be in multiple different semi-arbitrarily overlapping groups. I personally call these "virtual groups" since they don't correspond 1:1 with HW registers/fields. Create a function for each HW module. Allow each HW module's function to be mux'd onto each of the groups you created for it. There are probably quite a few existing examples of this in drivers/pinctrl.

Hope this helps!