lkml.org 
[lkml]   [2016]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO
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

\
 
 \ /
  Last update: 2016-09-28 05:44    [W:0.103 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site