On Thu, Jan 5, 2017 at 7:54 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > From: Nishanth Menon <nm@xxxxxx> > > 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@xxxxxx> > Signed-off-by: Lokesh Vutla <lokeshvutla@xxxxxx> > [tony@xxxxxxxxxxx: updated to use generic pinctrl functions, added > binding documentation, updated comments] > Acked-by: Rob Herring <robh@xxxxxxxxxx> > Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx> Oh what a hardware mess. But very nicely isolated now. Patch applied! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
