drivers: gpio: gpio_cc13xx_cc26xx: Add drive strength configurability

[statropy]

Add support for the GPIO_DS_ALT_LOW and GPIO_DS_ALT_HIGH gpio flags.

Fixes #30219

Signed-off-by: Erik Larson erik@statropy.com

[pabigot]

The implementation doesn't seem to fit with the intent of distinguishing low and high drive strengths.

[pabigot]

This doesn't seem right. The device supports minimum, medium, and maximum drive strength, along with "auto" which is based on battery voltage. This selects auto if no drive strength is specified, and max if either low or high is specified.

Why isn't this something like:

switch (flags & (GPIO_DS_ALT_HIGH | GPIO_DS_ALT_LOW)) {
  default:
  case 0:
    config |= IOC_CURRENT_2MA | IOC_STRENGTH_AUTO;
    break;
  case GPIO_DS_ALT_LOW:
    config |= IOC_CURRENT_2MA | IOC_STRENGTH_MIN;
    // or return -ENOTSUP if lower than standard doesn't make sense.
    break;
  case GPIO_DS_ALT_HIGH:
    config |= IOC_CURRENT_8MA | IOC_STRENGTH_MAX;
    break;
  case GPIO_DS_ALT_HIGH | GPIO_DS_ALT_LOW:
    return -ENOTSUP;
    break;
 }

[statropy]

Thanks for looking at this. I was confused at the flags at first, also thinking the flags were for Low or High drive strength, but according to https://docs.zephyrproject.org/apidoc/latest/drivers_2gpio_8h.html the flags are for low output state and high output state. Since the cc13xx/cc26xx doesn't allow setting drive strength based on output state (and really I had never come across that before in a microcontroller), I chose to use the higher drive strength if either flag is set.

[statropy]

I suppose it could require both flags to be set, otherwise return -ENOTSUP?

[pabigot]

Ugh. I'd forgotten that. This is what happens when generic API is designed based on special functionality supported by only one vendor's peripherals.

OK, you can leave it to require either both or neither flag, error if only one selected, but add a comment explaining why that's the right thing to do (much like what you wrote above). Hopefully 8mA/MAX is acceptable to everybody who wants an alternative drive strength on this SoC.

[statropy]

I took a little bit different path and added GPIO_DS_DFLT and GPIO_DS_ALT flags to gpio.h. Those flags are an OR of the high/low flags. Since that would be the mode supported by most hardware, it makes sense to have those flags available so this confusion doesn't happen again. The output-state-specific flags are still available, but not required for non-supporting hardware.

[pabigot]

The addition of the new flags must be in a distinct commit not coupled to the cc13xx/26xx driver change.

You can do that, but that would call for community review as it's something that all GPIO driver maintainers should review and determine whether it makes sense, or whether there's a better way to deal with it.

If you just stick with a defensible interpretation of how to apply the existing flags you have a better chance of getting the driver change in.

[pabigot]

Seems reasonable now, thanks.

Could you take it out of draft?