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

[Maxime Coquelin <maxime.coquelin@st.com>]

On 03/18/2015 11:51 AM, Lee Jones 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@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>   drivers/pinctrl/pinctrl-st.c | 31 ++++++++++++++++++++++++++++++-
>   1 file changed, 30 insertions(+), 1 deletion(-)
>

Acked-by: Maxime Coquelin <maxime.coquelin@st.com>

Thanks,
Maxime