[PATCH v2 4/6] pinctrl: st: Supply a GPIO get_direction() call-back

[Linus Walleij]

On Wed, Mar 18, 2015 at 6:21 PM, Lee Jones <lee.jones at linaro.org> wrote:

> ST's hardware differentiates between GPIO mode and Pinctrl alternate
> functions.  When a pin is in GPIO mode, there are dedicated registers
> to set and obtain direction status.  However, If a pin's alternate
> function is in use then the direction is set and status is derived
> from a bunch of syscon registers.  The issue is; until now there was
> a lack of parity between the two.
>
> For example:
>
> Catting the two following information sources could result in
> conflicting information (output has been snipped for simplicity):
>
>  $ cat /sys/kernel/debug/gpio
>   GPIOs 32-39, platform/961f080.pin-controller-sbc, PIO4:
>    gpio-33  (?                   ) out hi
>
>  $ cat /sys/kernel/debug/pinctrl/<pin-controller>/pinconf-pins
>   pin 33 (PIO4[1]):[OE:0,PU:0,OD:0]
>          [retime:0,invclk:0,clknotdat:0,de:0,rt-clk:0,rt-delay:0]
>
> In this example GPIO-33 is a GPIO controlled LED, which is set for
> output, as you'd expect.  However, when the same information is
> drafted from Pinctrl, it clearly states that OE (Output Enable) is
> not set i.e. the pin is set for input.  This is because OE normally
> only represents alternate functions and has no bearing on how the
> pin operates when in Alt-0 (GPIO mode).
>
> This patch changes the current semantics and provides a parity link
> between the two subsystems.  The get_direction() call-back firstly
> determines which function a pin is operating in, then uses the
> appropriate helpers for that mode.
>
> Reported-by: Olivier Clergeaud <olivier.clergeaud at st.com>
> Acked-by: Maxime Coquelin <maxime.coquelin at st.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Patch applied.

Yours,
Linus Walleij