1. 26 Jan, 2017 10 commits
  2. 18 Jan, 2017 9 commits
  3. 17 Jan, 2017 5 commits
  4. 13 Jan, 2017 2 commits
    • Thierry Reding's avatar
      pinctrl: Initialize pinctrl_dev.node · 46daed6e
      Thierry Reding authored
      The struct pinctrl_dev's node field is not properly set up, which means
      the .prev and .next fields will be NULL. That's not something that the
      linked list code can deal with, so extra care must be taken when using
      these fields. An example of this is introduced in commit 3429fb3c
      ("pinctrl: Fix panic when pinctrl devices with hogs are unregistered")
      where list_del() is made conditional on the pinctrl device being part
      of the pinctrl device list. This is to ensure that list_del() won't
      crash upon encountering a NULL pointer in .prev and/or .next.
      
      After initializing the list head there's no need to jump through these
      extra hoops and list_del() will work unconditionally. This is because
      the initialized list head points to itself and therefore the .prev and
      .next fields can be properly dereferenced.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Acked-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Tested-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      46daed6e
    • Tony Lindgren's avatar
      pinctrl: core: Fix regression caused by delayed work for hogs · 950b0d91
      Tony Lindgren authored
      Commit df61b366af26 ("pinctrl: core: Use delayed work for hogs") caused a
      regression at least with sh-pfc that is also a GPIO controller as
      noted by Geert Uytterhoeven <geert@linux-m68k.org>.
      
      As the original pinctrl_register() has issues calling pin controller
      driver functions early before the controller has finished registering,
      we can't just revert commit df61b366af26. That would break the drivers
      using GENERIC_PINCTRL_GROUPS or GENERIC_PINMUX_FUNCTIONS.
      
      So let's fix the issue with the following steps as a single patch:
      
      1. Revert the late_init parts of commit df61b366af26.
      
         The late_init clearly won't work and we have to just give up
         on fixing pinctrl_register() for GENERIC_PINCTRL_GROUPS and
         GENERIC_PINMUX_FUNCTIONS.
      
      2. Split pinctrl_register() into two parts
      
         By splitting pinctrl_register() into pinctrl_init_controller()
         and pinctrl_create_and_start() we have better control over when
         it's safe to call pinctrl_create().
      
      3. Introduce a new pinctrl_register_and_init() function
      
         As suggested by Linus Walleij <linus.walleij@linaro.org>, we
         can just introduce a new function for the controllers that need
         pinctrl_create() called later.
      
      4. Convert the four known problem cases to use new function
      
         Let's convert pinctrl-imx, pinctrl-single, sh-pfc and ti-iodelay
         to use the new function to fix the issues. The rest of the drivers
         can be converted later. Let's also update Documentation/pinctrl.txt
         accordingly because of the known issues with pinctrl_register().
      
      Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs")
      Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Gary Bisson <gary.bisson@boundarydevices.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      950b0d91
  5. 11 Jan, 2017 6 commits
  6. 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: Rob Herring's avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: Linus Walleij's 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: Linus Walleij's 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: Linus Walleij's 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: Linus Walleij's 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: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      578db85f
  7. 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: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      3429fb3c
  8. 03 Jan, 2017 2 commits
    • Linus Walleij's avatar
      pinctrl: amd: fix compilation warning · 6ac4c1ad
      Linus Walleij authored
      3bfd4430 ("pinctrl: amd: Add support for additional GPIO")
      created the following warning:
      
      drivers/pinctrl/pinctrl-amd.c: In function 'amd_gpio_dbg_show':
      drivers/pinctrl/pinctrl-amd.c:210:3: warning: 'pin_num' may be used uninitialized in this function [-Wmaybe-uninitialized]
         for (; i < pin_num; i++) {
         ^
      drivers/pinctrl/pinctrl-amd.c:172:21: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
        unsigned int bank, i, pin_num;
                           ^
      Fix this by adding a guarding default case for illegal
      bank numbers.
      
      Cc: S-k Shyam-sundar <Shyam-sundar.S-k@amd.com>
      Cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      6ac4c1ad
    • Gary Bisson's avatar
      pinctrl: imx: use generic pinmux helpers for managing functions · 3fd6d6ad
      Gary Bisson authored
      Now using function_desc structure instead of imx_pmx_func.
      
      Also leveraging generic functions to retrieve functions count/name/groups.
      
      The imx_free_funcs function can be removed since it is now handled by
      the core driver during unregister.
      Signed-off-by: default avatarGary Bisson <gary.bisson@boundarydevices.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      3fd6d6ad