1. 29 Mar, 2023 4 commits
    • Linus Walleij's avatar
      Merge branch 'ib-qcom-quad-spi' into devel · 2a6ac65c
      Linus Walleij authored
      2a6ac65c
    • Douglas Anderson's avatar
      pinctrl: qcom: Support OUTPUT_ENABLE; deprecate INPUT_ENABLE · e49eabe3
      Douglas Anderson authored
      The Qualcomm pinctrl driver has been violating the documented meaning
      of PIN_CONFIG_INPUT_ENABLE. That documentation says:
      
        Note that this does not affect the pin's ability to drive output.
      
      ...yet the Qualcomm driver's sole action when asked to "enable input"
      on a pin is to disable its output.
      
      The Qualcomm driver's implementation stems from the fact that
      "output-disable" is a "new" property from 2017. It was introduced in
      commit 42556242 ("pinctrl: generic: Add output-enable
      property"). The "input-enable" handling in Qualcomm drivers is from
      2015 introduced in commit 407f5e39 ("pinctrl: qcom: handle
      input-enable pinconf property").
      
      Let's change the Qualcomm driver to move us in the right direction. As
      part of this:
      1. We'll now support PIN_CONFIG_OUTPUT_ENABLE
      2. We'll still support using PIN_CONFIG_INPUT_ENABLE to disable a
         pin's output (in violation of the docs) with a big comment in the
         code. This is needed because old device trees have "input-enable"
         in them and, in some cases, people might need the old
         behavior. While we could programmatically change all old device
         trees, it doesn't really hurt to keep supporting the old behavior
         and we're _supposed_ to try to be compatible with old device trees
         anyway.
      
      It can also be noted that the PIN_CONFIG_INPUT_ENABLE handling code
      seems to have purposefully ignored its argument. That means that old
      boards that had _either_ "input-disable" or "input-enable" in them
      would have had the effect of disabling a pin's output. While we could
      change this behavior, since we're only leaving the
      PIN_CONFIG_INPUT_ENABLE there for backward compatibility we might as
      well be fully backward compatible.
      
      NOTE: despite the fact that we'll still support
      PIN_CONFIG_INPUT_ENABLE for _setting_ config, we take it away from
      msm_config_group_get(). This appears to be only used for populating
      debugfs and fixing debugfs to "output enabled" where relevant instead
      of "input enabled" makes more sense and has more truthiness.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarBjorn Andersson <andersson@kernel.org>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Link: https://lore.kernel.org/r/20230323102605.8.Id740ae6a993f9313b58add6b10f6a92795d510d4@changeidSigned-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      e49eabe3
    • Douglas Anderson's avatar
      dt-bindings: pinctrl: qcom: Add output-enable · 988a9eab
      Douglas Anderson authored
      In the patch ("dt-bindings: pinctrl: qcom: tlmm should use
      output-disable, not input-enable") we allowed setting "output-disable"
      for TLMM pinctrl states. Let's also add "output-enable".
      
      At first blush this seems a needless thing to do. Specifically:
      - In Linux (and presumably any other OSes using the same device trees)
        the GPIO/pinctrl driver knows to automatically enable the output
        when a GPIO is changed to an output. Thus in most cases specifying
        "output-enable" is superfluous and should be avoided.
      - If we need to set a pin's default state we already have
        "output-high" and "output-low" and these properties already imply
        "output-enabled" (at least on the Linux Qualcomm TLMM driver).
      
      However, there is one instance where "output-enable" seems like it
      could be useful: sleep states. It's not uncommon to want to configure
      pins as inputs (with appropriate pulls) when the driver controlling
      them is in a low power state. Then we want the pins back to outputs
      when the driver wants things running normally. To accomplish this we'd
      want to be able to use "output-enable". Then the "default" state could
      have "output-enable" and the "sleep" state could have
      "output-disable".
      
      NOTE: in all instances I'm aware of, we'd only want to use
      "output-enable" on pins that are configured as "gpio". The Qualcomm
      documentation that I have access to says that "output-enable" only
      does something useful when in GPIO mode.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Link: https://lore.kernel.org/r/20230323102605.7.I7874c00092115c45377c2a06f7f133356956686e@changeidSigned-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      988a9eab
    • Douglas Anderson's avatar
      dt-bindings: pinctrl: qcom: tlmm should use output-disable, not input-enable · c4a48b0d
      Douglas Anderson authored
      As evidenced by the Qualcomm TLMM Linux driver, the TLMM IP block in
      Qualcomm SoCs has a bit to enable/disable the output for a pin that's
      configured as a GPIO but _not_ a bit to enable/disable an input
      buffer. Current device trees that are specifying "input-enable" for
      pins managed by TLMM are either doing so needlessly or are using it to
      mean "output-disable".
      
      Presumably the current convention of using "input-enable" to mean
      "output-disable" stems from the fact that "output-disable" is a "new"
      property from 2017. It was introduced in commit 42556242
      ("pinctrl: generic: Add output-enable property"). The "input-enable"
      handling in Qualcomm drivers is from 2015 introduced in commit
      407f5e39 ("pinctrl: qcom: handle input-enable pinconf property").
      
      Given that there's no other use for "input-enable" for TLMM, we can
      still handle old device trees in code, but let's encourage people to
      move to the proper / documented property by updating the bindings.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Link: https://lore.kernel.org/r/20230323102605.6.I291ce0ba2c6ea80b341659c4f75a567a76dd7ca6@changeidSigned-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      c4a48b0d
  2. 27 Mar, 2023 6 commits
  3. 23 Mar, 2023 1 commit
  4. 19 Mar, 2023 28 commits
  5. 16 Mar, 2023 1 commit