summaryrefslogtreecommitdiff
path: root/drivers/pinctrl/ti/pinctrl-ti-iodelay.c
AgeCommit message (Collapse)Author
2017-01-18pinctrl: ti-iodelay: remove redundant pin < 0 check on unsigned intColin Ian King
pin is an unsigned int and therefore can never be < 0 so this check is redundant. Remove the check and the associated dev_err error message. Fixes CoverityScan CID#1396438 ("Unsigned compared against 0") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-01-13pinctrl: core: Fix regression caused by delayed work for hogsTony Lindgren
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: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Gary Bisson <gary.bisson@boundarydevices.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-01-09pinctrl: Introduce TI IOdelay configuration driverNishanth Menon
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: Nishanth Menon <nm@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> [tony@atomide.com: updated to use generic pinctrl functions, added binding documentation, updated comments] Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>