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

[Stefan Agner <stefan@xxxxxxxx>]

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
callbacks.

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

i2c_generic_gpio_recovery
    -> 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.

--
Stefan
--
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