• Lee Jones's avatar
    pinctrl: st: Supply a GPIO get_direction() call-back · 1e702ec2
    Lee Jones authored
    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: default avatarOlivier Clergeaud <olivier.clergeaud@st.com>
    Acked-by: default avatarMaxime Coquelin <maxime.coquelin@st.com>
    Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
    Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
    1e702ec2
pinctrl-st.c 48.6 KB