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

On Tue, Sep 27, 2016 at 2:26 AM, Stefan Agner wrote: > + /* Only change pad configuration if pad is still a GPIO */ > + if (reg & (0x7 << 20)) > + return; > + > + /* Clear IBE/OBE/PUE to disable the pin (Hi-Z) */ > reg &= ~0x7; >

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

On Tue, Sep 27, 2016 at 2:26 AM, Stefan Agner wrote: > + /* Only change pad configuration if pad is still a GPIO */ > + if (reg & (0x7 << 20)) > + return; > + > + /* Clear IBE/OBE/PUE to disable the pin (Hi-Z) */ > reg &= ~0x7; > writel(reg,

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

On Thu, Sep 29, 2016 at 6:33 PM, Stefan Agner wrote: > On 2016-09-27 21:14, Viresh Kumar wrote: >> On 27-09-16, 20:38, Stefan Agner wrote: >>> The i.MX I2C driver touches the pinctrl in its prepare/unprepare >>> callbacks. >>> >>> So, on a i.MX or Vybrid, the call chain looks

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

On Thu, Sep 29, 2016 at 6:33 PM, Stefan Agner wrote: > On 2016-09-27 21:14, Viresh Kumar wrote: >> On 27-09-16, 20:38, Stefan Agner wrote: >>> 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: >>> >>>

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

On 29-09-16, 15:16, Vladimir Zapolskiy wrote: > If you look at the top I agree that this solution may be only one platform > specific, but it fixes the broken driver of i.MX I2C bus controller. Yeah, I saw that.. > Why do you get an impression that it looks like a hack? Because we have to

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

On 29-09-16, 15:16, Vladimir Zapolskiy wrote: > If you look at the top I agree that this solution may be only one platform > specific, but it fixes the broken driver of i.MX I2C bus controller. Yeah, I saw that.. > Why do you get an impression that it looks like a hack? Because we have to

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

On 29-09-16, 09:33, Stefan Agner wrote: > You need to differentiate between Vybrid and i.MX: > > Vybrid muxes a pin to GPIO on gpio_request_one (via .gpio_request_enable > callback) > i.MX does not mux a pin as GPIO on its own, but needs to be muxed > explicitly. That has been always the case...

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

On 29-09-16, 09:33, Stefan Agner wrote: > You need to differentiate between Vybrid and i.MX: > > Vybrid muxes a pin to GPIO on gpio_request_one (via .gpio_request_enable > callback) > i.MX does not mux a pin as GPIO on its own, but needs to be muxed > explicitly. That has been always the case...

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

On 2016-09-27 21:14, Viresh Kumar wrote: > On 27-09-16, 20:38, Stefan Agner wrote: >> 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

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

On 2016-09-27 21:14, Viresh Kumar wrote: > On 27-09-16, 20:38, Stefan Agner wrote: >> 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

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

On 09/29/2016 09:46 AM, Viresh Kumar wrote: On 28-09-16, 15:07, Vladimir Zapolskiy wrote: I would expect that the change below improves the situation, but I didn't perform any tests and here the core change is governed by the accepted i.MX i2c bus driver specific changes, thus conceptually it

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

On 09/29/2016 09:46 AM, Viresh Kumar wrote: On 28-09-16, 15:07, Vladimir Zapolskiy wrote: I would expect that the change below improves the situation, but I didn't perform any tests and here the core change is governed by the accepted i.MX i2c bus driver specific changes, thus conceptually it

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

On 28-09-16, 15:07, Vladimir Zapolskiy wrote: > I would expect that the change below improves the situation, but I didn't > perform any tests and here the core change is governed by the accepted > i.MX i2c bus driver specific changes, thus conceptually it may be incorrect: > > diff --git

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

On 28-09-16, 15:07, Vladimir Zapolskiy wrote: > I would expect that the change below improves the situation, but I didn't > perform any tests and here the core change is governed by the accepted > i.MX i2c bus driver specific changes, thus conceptually it may be incorrect: > > diff --git

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

On 09/28/2016 06:38 AM, Stefan Agner wrote: 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

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

On 09/28/2016 06:38 AM, Stefan Agner wrote: 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

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

On 27-09-16, 20:38, Stefan Agner wrote: > 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 > ->

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

On 27-09-16, 20:38, Stefan Agner wrote: > 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 > ->

Re: [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

Re: [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

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

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

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

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

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

On 09/27/2016 10:34 PM, Stefan Agner wrote: On 2016-09-27 11:17, Vladimir Zapolskiy wrote: Hi Stefan, On 09/27/2016 07:37 PM, Stefan Agner wrote: On 2016-09-27 05:12, Vladimir Zapolskiy wrote: Hi Stefan, On 09/27/2016 03:26 AM, Stefan Agner wrote: If a GPIO gets freed after selecting a new

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

On 09/27/2016 10:34 PM, Stefan Agner wrote: On 2016-09-27 11:17, Vladimir Zapolskiy wrote: Hi Stefan, On 09/27/2016 07:37 PM, Stefan Agner wrote: On 2016-09-27 05:12, Vladimir Zapolskiy wrote: Hi Stefan, On 09/27/2016 03:26 AM, Stefan Agner wrote: If a GPIO gets freed after selecting a new

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

On 2016-09-27 11:17, Vladimir Zapolskiy wrote: > Hi Stefan, > > On 09/27/2016 07:37 PM, Stefan Agner wrote: >> On 2016-09-27 05:12, Vladimir Zapolskiy wrote: >>> Hi Stefan, >>> >>> On 09/27/2016 03:26 AM, Stefan Agner wrote: If a GPIO gets freed after selecting a new pinctrl configuration

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

On 2016-09-27 11:17, Vladimir Zapolskiy wrote: > Hi Stefan, > > On 09/27/2016 07:37 PM, Stefan Agner wrote: >> On 2016-09-27 05:12, Vladimir Zapolskiy wrote: >>> Hi Stefan, >>> >>> On 09/27/2016 03:26 AM, Stefan Agner wrote: If a GPIO gets freed after selecting a new pinctrl configuration

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

Hi Stefan, On 09/27/2016 07:37 PM, Stefan Agner wrote: On 2016-09-27 05:12, Vladimir Zapolskiy wrote: 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

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

Hi Stefan, On 09/27/2016 07:37 PM, Stefan Agner wrote: On 2016-09-27 05:12, Vladimir Zapolskiy wrote: 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

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

On 2016-09-27 05:12, Vladimir Zapolskiy wrote: > 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 >

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

On 2016-09-27 05:12, Vladimir Zapolskiy wrote: > 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 >

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

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

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

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

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

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 --- This turned out to be problematic when

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

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 --- This turned out to be problematic when using the I2C GPIO