pinmux: pin group ownership

Looking at this change, if pinmux_enable_setting() is called but .get_group_pins() is not defined, then num_pins will be 0. If this is the case then pin_request() is not called to allocate the pins in the group (because no pins are defined for the group). So that makes sense.

However, I am trying to understand then, if the pinmux driver will protect against another device attempting to use the same group for a different function when already in-use?

For example, if you have the two functions i2c0 and uart0 mapped to pin group A, but no pins are defined for group A, will pinmux prevent someone attempting to configure both functions on the same group at the same time?

I did not see anywhere that sets a usecount for a group (ie. allocates the group) but only for a pin.

Quoted 14 lines · Jon Hunter

Looking at this change, if pinmux_enable_setting() is called but .get_group_pins() is not defined, then num_pins will be 0. If this is the case then pin_request() is not called to allocate the pins in the group (because no pins are defined for the group). So that makes sense.

However, I am trying to understand then, if the pinmux driver will protect against another device attempting to use the same group for a different function when already in-use?

For example, if you have the two functions i2c0 and uart0 mapped to pin group A, but no pins are defined for group A, will pinmux prevent someone attempting to configure both functions on the same group at the same time?

Quoted 2 lines

I did not see anywhere that sets a usecount for a group (ie. allocates the group) but only for a pin.

The usecount are done on individual pins, not groups.

In the devel tree you can even set the pinmux_ops.strict to disallow GPIOs and other functions to share a pin.

Quoted 1 line

The usecount are done on individual pins, not groups.

Thanks for confirming. With regard to the change e5b3b2d9ed202697a937c282f9c4d93b1e3e0848, IIUC then this allows devices not to define any pins but just groups. Probably because from some devices (such as berlin) pinmux'ing is always done at the group level.

If this is the case then it would appear that there is no protection against two devices trying to use the same group. Is this correct?

Quoted 2 lines

In the devel tree you can even set the pinmux_ops.strict to disallow GPIOs and other functions to share a pin.

Thanks, however, I don't think that this helps in this case because pin_request() would not be called by pinmux_enable_setting() as num_pins = 0.

On Tue, May 12, 2015 at 1:53 PM, Jon Hunter <[email protected]> wrote:

[Me]:

Quoted 6 lines

Quoted 1 line

The usecount are done on individual pins, not groups.

Thanks for confirming. With regard to the change e5b3b2d9ed202697a937c282f9c4d93b1e3e0848, IIUC then this allows devices not to define any pins but just groups. Probably because from some devices (such as berlin) pinmux'ing is always done at the group level.

That's correct.

Quoted 2 lines

If this is the case then it would appear that there is no protection against two devices trying to use the same group. Is this correct?

Seems like so... darn you found a loophole.

Quoted 6 lines

Quoted 2 lines

In the devel tree you can even set the pinmux_ops.strict to disallow GPIOs and other functions to share a pin.

Thanks, however, I don't think that this helps in this case because pin_request() would not be called by pinmux_enable_setting() as num_pins = 0.

You're right.

The implementation assumes collissions happen at pin level, not group level.

I wonder if there are enough devices out there with this problem that we need to check for it?

If so I would opt to create a bool .group_only property on pinmux_ops like we created .strict so that we can avoid all pin-specific code on such pin controllers.

But I don't know it it's worth it for these few pin controllers :/

On the U300 there is only group selection, but the datasheet helpfully defined all pins anyway so I could handle collissions on the pin level. This is the ideal solution if possible.