Hi Stefan, On 09/27/2016 03:26 AM, Stefan Agner wrote:
If a GPIO gets freed after selecting a new pinctrl configuration the driver should not change pinctrl anymore. Otherwise this will likely lead to a unusable pin configuration for > the newly selected pinctrl. Signed-off-by: Stefan Agner <stefan@xxxxxxxx> --- This turned out to be problematic when using the I2C GPIO bus recovery functionality. After muxing back to I2C, the GPIO is being freed, which cased I2C to stop working completely.
IMHO this recent "i.MX I2C GPIO bus recovery" feature is kind of a hack, for example I believe it breaks I2C bus driver initialization on i.MX31 boards, where today there is no pinctrl driver at all. IMHO something like I've partially described in the recent "Requesting as a GPIO a pin already used through pinctrl" topic should be done here. Could you consider to add another pinctrl-1 group with alternative GPIO line mux/config settings to an i2c controller device node and apply it, when you need a bus recovery? You may find references how this kind of dynamic pinctrl management is done within mmc/sd subsystem. By the way did I miss a patch, which falls back to mux settings on .gpio_disable_free call for non-Vybrid platforms? -- With best wishes, Vladimir -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
