Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO

From: Stefan Agner
Date: Tue Sep 27 2016 - 23:44:04 EST

On 2016-09-27 19:00, Viresh Kumar wrote:
> On 27-09-16, 12:34, Stefan Agner wrote:
>> Added Viresh Kumar to the discussion, he implemented the I2C recovery
>> functions.
>> Yes, reordering the pinctrl/gpio_free calls would fix the problem too.
>> However, I guess there is no explicit rule to that ("request/free GPIOs
>> only when they are muxed as GPIO"), so I think of it that the issue is
>> actually in the pinctrl driver.
>> On top of that it is not entirely trivial to reorder the calls the way
>> i2c_generic_gpio_recovery and i2c_generic_recovery are set up right now.
> AFAICT, these routines don't touch the muxing part at all. Perhaps it is done
> internally by the GPIO calls. Can you please elaborate the exact change you are
> hinting towards here ?

The i.MX I2C driver touches the pinctrl in its prepare/unprepare

So, on a i.MX or Vybrid, the call chain looks like this:

-> i2c_get_gpios_for_recovery
-> gpio_request_one
-> i2c_generic_recovery
-> prepare_recovery (i2c_imx_prepare_recovery)
-> pinctrl_select_state [gpio]
-> unprepare_recovery (i2c_imx_unprepare_recovery)
-> pinctrl_select_state [default]
-> i2c_put_gpios_for_recovery
-> gpio_free

And for the pinctrl/GPIO driver of Vybrid this is actually a problem
because gpio_free disables the output driver of the pad, and when that
happens after the (I2C) default pinctrl state gets selected the pad is
no longer active.