1. 11 Jan, 2017 7 commits
  2. 09 Jan, 2017 5 commits
    • Nishanth Menon's avatar
      pinctrl: Introduce TI IOdelay configuration driver · 003910eb
      Nishanth Menon authored
      SoC family such as DRA7 family of processors have, in addition
      to the regular muxing of pins (as done by pinctrl-single), a separate
      hardware module called IODelay which is also expected to be configured.
      The "IODelay" module has it's own register space that is independent
      of the control module and the padconf register area.
      
      With recent changes to the pinctrl framework, we can now support
      this hardware with a reasonably minimal driver by using #pinctrl-cells,
      GENERIC_PINCTRL_GROUPS and GENERIC_PINMUX_FUNCTIONS.
      
      It is advocated strongly in TI's official documentation considering
      the existing design of the DRA7 family of processors during mux or
      IODelay reconfiguration, there is a potential for a significant glitch
      which may cause functional impairment to certain hardware. It is
      hence recommended to do as little of muxing as absolutely necessary
      without I/O isolation (which can only be done in initial stages of
      bootloader).
      
      NOTE: with the system wide I/O isolation scheme present in DRA7 SoC
      family, it is not reasonable to do stop all I/O operations for every
      such pad configuration scheme. So, we will let it glitch when used in
      this mode.
      
      Even with the above limitation, certain functionality such as MMC has
      mandatory need for IODelay reconfiguration requirements, depending on
      speed of transfer. In these cases, with careful examination of usecase
      involved, the expected glitch can be controlled such that it does not
      impact functionality.
      
      In short, IODelay module support as a padconf driver being introduced
      here is not expected to do SoC wide I/O Isolation and is meant for
      a limited subset of IODelay configuration requirements that need to
      be dynamic and whose glitchy behavior will not cause functionality
      failure for that interface.
      
      IMPORTANT NOTE: we take the approach of keeping LOCK_BITs cleared
      to 0x0 at all times, even when configuring Manual IO Timing Modes.
      This is done by eliminating the LOCK_BIT=1 setting from Step
      of the Manual IO timing Mode configuration procedure. This option
      leaves the CFG_* registers unprotected from unintended writes to the
      CTRL_CORE_PAD_* registers while Manual IO Timing Modes are configured.
      
      This approach is taken to allow for a generic driver to exist in kernel
      world that has to be used carefully in required usecases.
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Signed-off-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      [tony@atomide.com: updated to use generic pinctrl functions, added
       binding documentation, updated comments]
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      003910eb
    • Tony Lindgren's avatar
      pinctrl: core: Make dt_free_map optional · 92c2b671
      Tony Lindgren authored
      If the pin controller driver is using devm_kzalloc, there may not be
      anything to do for dt_free_map. Let's make it optional to avoid
      unncessary boilerplate code.
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      92c2b671
    • Maxime Ripard's avatar
      pinctrl: sunxi: Remove old sun5i pinctrl drivers · d83bb5a4
      Maxime Ripard authored
      Now that we have a common pinctrl driver for all the sun5i SoCs, we can
      remove the old, separate drivers.
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      d83bb5a4
    • Maxime Ripard's avatar
      pinctrl: sunxi: Add common sun5i pinctrl driver · 858f559f
      Maxime Ripard authored
      The sun5i SoCs (A10s, A13, GR8) are all based on the same die fit in
      different packages. Hence, the pins and functions available are just the
      based on the same set, each SoC having a different subset.
      
      Introduce a common pinctrl driver that supports multiple variants to allow
      to put as much as we can in common.
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      858f559f
    • Maxime Ripard's avatar
      pinctrl: sunxi: Add pinctrl variants · 578db85f
      Maxime Ripard authored
      Some SoCs are either supposed to be pin compatible (A10 and A20 for
      example), or are just repackaged versions of the same die (A10s, A13, GR8).
      
      In those case, having a full blown pinctrl driver just introduces
      duplication in both data size and maintainance effort.
      
      Add a variant option to both pins and functions to be able to limit the
      pins and functions described only to a subset of the SoC we support with a
      given driver.
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      578db85f
  3. 05 Jan, 2017 1 commit
    • Jon Hunter's avatar
      pinctrl: Fix panic when pinctrl devices with hogs are unregistered · 3429fb3c
      Jon Hunter authored
      Commit df61b366af26 ('pinctrl: core: Use delayed work for hogs')
      deferred part of the registration for pinctrl devices if the pinctrl
      device has hogs. This introduced a window where if the pinctrl device
      with hogs was sucessfully registered, but then unregistered again
      (which could be caused by parent device being probe deferred) before
      the delayed work has chanced to run, then this will cause a kernel
      panic to occur because:
      
      1. The 'pctldev->p' has not yet been initialised and when unregistering
         the pinctrl device we only check to see if it is an error value, but
         now it could also be NULL.
      2. The pinctrl device may not have been added to the 'pinctrldev_list'
         list and we don't check to see if it was added before removing.
      
      Fix up the above by checking to see if the 'pctldev->p' pointer is an
      error value or NULL before putting the pinctrl device and verifying
      that the pinctrl device is present in 'pinctrldev_list' before removing.
      
      Fixes: df61b366af26 ('pinctrl: core: Use delayed work for hogs')
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      3429fb3c
  4. 03 Jan, 2017 11 commits
  5. 30 Dec, 2016 9 commits
  6. 28 Dec, 2016 3 commits
  7. 27 Dec, 2016 3 commits
  8. 26 Dec, 2016 1 commit