1. 23 Jun, 2016 1 commit
  2. 20 Apr, 2016 1 commit
  3. 27 Oct, 2015 1 commit
    • Douglas Anderson's avatar
      drivers/pinctrl: Add the concept of an "init" state · ef0eebc0
      Douglas Anderson authored
      For pinctrl the "default" state is applied to pins before the driver's
      probe function is called.  This is normally a sensible thing to do,
      but in some cases can cause problems.  That's because the pins will
      change state before the driver is given a chance to program how those
      pins should behave.
      As an example you might have a regulator that is controlled by a PWM
      (output high = high voltage, output low = low voltage).  The firmware
      might leave this pin as driven high.  If we allow the driver core to
      reconfigure this pin as a PWM pin before the PWM's probe function runs
      then you might end up running at too low of a voltage while we probe.
      Let's introudce a new "init" state.  If this is defined we'll set
      pinctrl to this state before probe and then "default" after probe
      (unless the driver explicitly changed states already).
      An alternative idea that was thought of was to use the pre-existing
      "sleep" or "idle" states and add a boolean property that we should
      start in that mode.  This was not done because the "init" state is
      needed for correctness and those other states are only present (and
      only transitioned in to and out of) when (optional) power management
      is enabled.
      Changes in v3:
      - Moved declarations to pinctrl/devinfo.h
      - Fixed author/SoB
      Changes in v2:
      - Added comment to pinctrl_init_done() as per Linus W.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Tested-by: default avatarCaesar Wang <wxt@rock-chips.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  4. 02 Oct, 2015 1 commit
  5. 01 Jun, 2015 2 commits
  6. 06 May, 2015 3 commits
  7. 05 Mar, 2015 1 commit
  8. 14 Jan, 2015 2 commits
  9. 11 Jan, 2015 2 commits
    • Soren Brinkmann's avatar
      pinctrl: pinconf-generic: Allow driver to specify DT params · dd4d01f7
      Soren Brinkmann authored
      Additionally to the generic DT parameters, allow drivers to provide
      driver-specific DT parameters to be used with the generic parser
      To achieve this 'struct pinctrl_desc' is extended to pass custom pinconf
      option to the core. In order to pass this kind of information, the
      related data structures - 'struct pinconf_generic_dt_params',
      'pin_config_item' - are moved from pinconf internals to the
      pinconf-generic header.
      Additionally pinconfg-generic is refactored to not only iterate over the
      generic pinconf parameters but also take the parameters into account
      that are provided through the driver's 'struct pinctrl_desc'.
      In particular 'pinconf_generic_parse_dt_config()' and
      'pinconf_generic_dump' helpers are split into two parts each. In order
      to have a more generic helper that can be used to process the generic
      parameters as well as the driver-specific ones.
       - fix typo
       - add missing documentation for @conf_items member in struct
       - rebase to pinctrl/devel: conflict in abx500
       - rename _pinconf_generic_dump() to pinconf_generic_dump_one()
       - removed '_' from _parse_dt_cfg()
       - removed BUG_ONs, error condition is handled in if statements
       - removed pinconf_generic_dump_group() & pinconf_generic_dump_pin
         - fixed up corresponding call sites
         - renamed pinconf_generic_dump() to pinconf_generic_dump_pins()
         - added kernel-doc to pinconf_generic_dump_pins()
       - add kernel-doc
       - more verbose commit message
      Signed-off-by: default avatarSoren Brinkmann <soren.brinkmann@xilinx.com>
      Tested-by: default avatarAndreas Färber <afaerber@suse.de>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
    • Soren Brinkmann's avatar
      pinctrl: pinconf-generic: Infer map type from DT property · 31c89c95
      Soren Brinkmann authored
      With the new 'groups' property, the DT parser can infer the map type
      from the fact whether 'pins' or 'groups' is used to specify the pin
      group to work on.
      To maintain backwards compatibitliy with current usage of the DT
      binding, this is only done when PIN_MAP_TYPE_INVALID is passed to the
      parsing function as type.
      Also, a new helper 'pinconf_generic_dt_node_to_map_all()' is introduced,
      which can be used by drivers as generic callback for dt_node_to_map() to
      leverage the new feature.
      Changes since v2:
       - rename dt_pin_specifier to subnode_target_type
       - add additional comment in header file explaining passing an invalid
         map type
       - mention map_all() helper in commit message
      Changes since RFC v2:
       - none
      Signed-off-by: default avatarSoren Brinkmann <soren.brinkmann@xilinx.com>
      Tested-by: default avatarAndreas Färber <afaerber@suse.de>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  10. 04 Sep, 2014 2 commits
  11. 11 Jul, 2014 1 commit
    • Fan Wu's avatar
      pinctrl: avoid duplicated calling enable_pinmux_setting for a pin · 2243a87d
      Fan Wu authored
      What the patch does:
      1. Call pinmux_disable_setting ahead of pinmux_enable_setting
        each time pinctrl_select_state is called
      2. Remove the HW disable operation in pinmux_disable_setting function.
      3. Remove the disable ops in struct pinmux_ops
      4. Remove all the disable ops users in current code base.
      1. Great thanks for the suggestion from Linus, Tony Lindgren and
         Stephen Warren and Everyone that shared comments on this patch.
      2. The patch also includes comment fixes from Stephen Warren.
      The reason why we do this:
      1. To avoid duplicated calling of the enable_setting operation
         without disabling operation inbetween which will let the pin
         descriptor desc->mux_usecount increase monotonously.
      2. The HW pin disable operation is not useful for any of the
         existing platforms.
         And this can be used to avoid the HW glitch after using the
         item #1 modification.
      In the following case, the issue can be reproduced:
      1. There is a driver that need to switch pin state dynamically,
         e.g. between "sleep" and "default" state
      2. The pin setting configuration in a DTS node may be like this:
        component a {
      	pinctrl-names = "default", "sleep";
      	pinctrl-0 = <&a_grp_setting &c_grp_setting>;
      	pinctrl-1 = <&b_grp_setting &c_grp_setting>;
        The "c_grp_setting" config node is totally identical, maybe like
        following one:
        c_grp_setting: c_grp_setting {
      	pinctrl-single,pins = <GPIO48 AF6>;
      3. When switching the pin state in the following official pinctrl
      	pin = pinctrl_get();
      	state = pinctrl_lookup_state(wanted_state);
      Test Result:
      1. The switch is completed as expected, that is: the device's
         pin configuration is changed according to the description in the
         "wanted_state" group setting
      2. The "desc->mux_usecount" of the corresponding pins in "c_group"
         is increased without being decreased, because the "desc" is for
         each physical pin while the setting is for each setting node
         in the DTS.
         Thus, if the "c_grp_setting" in pinctrl-0 is not disabled ahead
         of enabling "c_grp_setting" in pinctrl-1, the desc->mux_usecount
         will keep increasing without any chance to be decreased.
      According to the comments in the original code, only the setting,
      in old state but not in new state, will be "disabled" (calling
      pinmux_disable_setting), which is correct logic but not intact. We
      still need consider case that the setting is in both old state
      and new state. We can do this in the following two ways:
      1. Avoid to "enable"(calling pinmux_enable_setting) the "same pin
         setting" repeatedly
      2. "Disable"(calling pinmux_disable_setting) the "same pin setting",
         actually two setting instances, ahead of enabling them.
      1. The solution #2 is better because it can avoid too much
      2. If we disable all of the settings in the old state and one of
         the setting(s) exist in the new state, the pins mux function
         change may happen when some SoC vendors defined the
         in their DTS file.
         old_setting => disabled_setting => new_setting.
      3. In the pinmux framework, when a pin state is switched, the
         setting in the old state should be marked as "disabled".
      1. To Remove the HW disabling operation to above the glitch mentioned
      2. Handle the issue mentioned above by disabling all of the settings
         in old state and then enable the all of the settings in new state.
      Signed-off-by: default avatarFan Wu <fwu@marvell.com>
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarPatrice Chotard <patrice.chotard@st.com>
      Acked-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Acked-by: default avatarMaxime Coquelin <maxime.coquelin@st.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  12. 16 Jan, 2014 1 commit
  13. 16 Dec, 2013 1 commit
  14. 03 Dec, 2013 1 commit
  15. 16 Oct, 2013 1 commit
  16. 28 Aug, 2013 1 commit
  17. 23 Aug, 2013 1 commit
  18. 15 Aug, 2013 1 commit
    • Linus Walleij's avatar
      pinctrl: add includes and ifdefs for non-DT builds · 0d74d4a1
      Linus Walleij authored
      Commit e81c8f18
      "pinctrl: pinconf-generic: add generic APIs for mapping pinctrl node"
      Added function prototypes with implicit dependencies
      on other header files causing build warnings like this:
      In file included from
      warning: 'struct device_node' declared inside parameter list [enabled
      by default]
         unsigned *reserved_maps, unsigned *num_maps);
      warning: its scope is only this definition or declaration, which is
      probably not what you want [enabled by default]
      warning: 'struct pinctrl_dev' declared inside parameter list [enabled
      by default]
      warning: 'struct device_node' declared inside parameter list [enabled
      by default]
         unsigned *num_maps);
      Let's just add ifdefs for non-DT systems (the actual code is
      already ifdefed) and #include <linux/device.h> to get the
      most important structs and forward-declare the pinctrl
      core structs.
      Reported-by: default avatarOlof Johansson <olof@lixom.net>
      Cc: Laxman Dewangan <ldewangan@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  19. 14 Aug, 2013 1 commit
  20. 25 Jun, 2013 3 commits
  21. 18 Jun, 2013 1 commit
  22. 17 Jun, 2013 4 commits
  23. 16 Jun, 2013 3 commits
  24. 14 May, 2013 1 commit
  25. 19 Apr, 2013 1 commit
    • Laurent Meunier's avatar
      pinctrl/pinconfig: add debug interface · f07512e6
      Laurent Meunier authored
      This update adds a debugfs interface to modify a pin configuration
      for a given state in the pinctrl map. This allows to modify the
      configuration for a non-active state, typically sleep state.
      This configuration is not applied right away, but only when the state
      will be entered.
      This solution is mandated for us by HW validation: in order
      to test and verify several pin configurations during sleep without
      recompiling the software.
      Change log in this patch set;
      Take into account latest feedback from Stephen Warren:
      - stale comments update
      - improved code efficiency and readibility
      - limit size of global variable pinconf_dbg_conf
      - remove req_type as it can easily be added later when
      add/delete requests support is implemented
      Signed-off-by: default avatarLaurent Meunier <laurent.meunier@st.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  26. 06 Mar, 2013 1 commit
  27. 15 Feb, 2013 1 commit