-----Original Message-----
From: Piotr Mienkowski [mailto:Piotr.Mienkowski(a)schmid-telecom.ch]
Sent: Friday, September 2, 2016 3:22 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Proposal to streamline GPIO, Pinmux driver API

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

Some confusion does exist when these APIs are used across platforms.
But, for QUARK, the boundary is clear and there is no overlapping;
Combining them into one is not conceptually right.