Skip to content
  • Linus Walleij's avatar
    pinctrl: reserve pins when states are activated · 1a78958d
    Linus Walleij authored
    
    
    This switches the way that pins are reserved for multiplexing:
    
    We used to do this when the map was parsed, at the creation of
    the settings inside the pinctrl handle, in pinmux_map_to_setting().
    
    However this does not work for us, because we want to use the
    same set of pins with different devices at different times: the
    current code assumes that the pin groups in a pinmux state will
    only be used with one single device, albeit different groups can
    be active at different times. For example if a single I2C driver
    block is used to drive two different busses located on two
    pin groups A and B, then the pins for all possible states of a
    function are reserved when fetching the pinctrl handle: the
    I2C bus can choose either set A or set B by a mux state at
    runtime, but all pins in both group A and B (the superset) are
    effectively reserved for that I2C function and mapped to the
    device. Another device can never get in and use the pins in
    group A, even if the device/function is using group B at the
    moment.
    
    Instead: let use reserve the pins when the state is activated
    and drop them when the state is disabled, i.e. when we move to
    another state. This way different devices/functions can use the
    same pins at different times.
    
    We know that this is an odd way of doing things, but we really
    need to switch e.g. an SD-card slot to become a tracing output
    sink at runtime: we plug in a special "tracing card" then mux
    the pins that used to be an SD slot around to the tracing
    unit and push out tracing data there instead of SD-card
    traffic.
    
    As a side effect pinmux_free_setting() is unused but the stubs
    are kept for future additions of code.
    
    Cc: Patrice Chotard <patrice.chotard@st.com>
    Cc: Loic Pallardy <loic.pallardy@st.com>
    Acked-by: default avatarStephen Warren <swarren@nvidia.com>
    Tested-by: default avatarJean Nicolas Graux <jean-nicolas.graux@stericsson.com>
    Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
    1a78958d