On 2 Sep 2016, at 06:21, Piotr Mienkowski <Piotr.Mienkowski(a)schmid-telecom.ch> wrote:

Hello Community,

I would like to discuss GPIO / Pinmux driver combo which I believe become overcomplicated and may be confusing for a regular user.

The current API seems to be designed around Intel Quark architecture and QMSI SDK. In Quark there are separate Pinmux and GPIO modules and so we got separate Pinmux and GPIO drivers. However, in most chipsets GPIO module takes care of both PIO (reading/writing from/to a pin) and pin muxing (connecting pin to a peripheral/PIO controller). By now the functional split between the two drivers become blurred and is overlapping.

Some examples:

At present GPIO driver defines GPIO_PUD_PULL_UP (Enable GPIO pin pull-up) to be used with gpio_pin_configure() function and Pinmux driver has pinmux_pin_pullup() function. Both are meant to do the same thing however gpio_pin_configure() will not work with Intel Quark chips and pinmux_pin_pullup() will mostly not work with other chips e.g. Freescale/NXP FRDM-K64F. Still some chipsets e.g. Atmel SAM3x implement both functions but then even for Atmel SAM3x setting pin pull-down is only possible via gpio_pin_configure() function.

pinmux_pin_input_enable() function is used by Quark chips to disable/enable input pad and gpio_pin_configure() to set pin as input or output. This is not easily rendered from the function's name/description and in fact Atmel SAM3x driver implements pinmux_pin_input_enable() to configure pin as input or output overlapping it with the same functionality provided by gpio_pin_configure().

In case of ARM based chips e.g. Atmel SAM3x, Freescale/NXP FRDM-K64F to configure pin with pull-up and connect it to external peripheral one needs to call pinmux_pin_set() which takes as an argument pin index, e.g. pin PB2, third pin on port B would have index 34 and gpio_pin_configure() which takes as an argument port and port's pin number, e.g. PB2 has number 2. So in two subsequent calls we need to use different pin values even if we operate on the same pin. While this may be convenient for Quark chips it is not for other chip families.

Currently it is not really possible to know which function should be used when and how without analyzing Zephyr's source code.

I believe that split between Pinmux and GPIO driver is not a good general solution and in case we preserve the current API it will soon become even more convoluted.

I would like to propose to phase out Pinmux driver and implement pin multiplexing in GPIO driver. That would require adding something like GPIO_FUNC_A, ..., GPIO_FUNC_D to GPIO API.

Other possibility would be to limit Pinmux driver only to architectures that really need it, like Quark chips. Having pin multiplexing available simultaneously in GPIO and Pinmux driver will be confusing for Quark users, however that's already the case with pull-up configuration.

I haven't created a Jira issue, neither RFC in Gerrit yet. At first I would like to get a quick feedback if you find my arguments sensible.

Thanks,
Piotr