pinctrl: st: Supply a GPIO get_direction() call-back
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> Acked-by: Maxime Coquelin <maxime.coquelin@st.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Showing
Please register or sign in to comment