2023-09-26 16:04:43

by Robert Marko

[permalink] [raw]
Subject: [PATCH] i2c: core: dont change pinmux state to GPIO during recovery setup

Ever since PXA I2C driver was moved to the generic I2C recovery, I2C has
stopped working completely on Armada 3720 if the pins are specified in DTS.

After a while it was traced down to the only difference being that PXA
driver did not change the pinmux state to GPIO before trying to acquire the
GPIO pins.
And indeed as soon as this call is removed I2C starts working.

To me it seems that this call is not required at all as devm_gpiod_get()
will result in the pinmux state being changed to GPIO via the pinmux
set_mux() op.

Fixes: 0b01392c18b9 ("i2c: pxa: move to generic GPIO recovery")
Signed-off-by: Robert Marko <[email protected]>
---
drivers/i2c/i2c-core-base.c | 7 -------
1 file changed, 7 deletions(-)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 60746652fd52..b34d939078a1 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -359,13 +359,6 @@ static int i2c_gpio_init_generic_recovery(struct i2c_adapter *adap)
if (bri->recover_bus && bri->recover_bus != i2c_generic_scl_recovery)
return 0;

- /*
- * pins might be taken as GPIO, so we should inform pinctrl about
- * this and move the state to GPIO
- */
- if (bri->pinctrl)
- pinctrl_select_state(bri->pinctrl, bri->pins_gpio);
-
/*
* if there is incomplete or no recovery information, see if generic
* GPIO recovery is available
--
2.41.0


2023-09-29 00:37:09

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH] i2c: core: dont change pinmux state to GPIO during recovery setup

On Tue, Sep 26, 2023 at 6:03 PM Robert Marko <[email protected]> wrote:

> @@ -359,13 +359,6 @@ static int i2c_gpio_init_generic_recovery(struct i2c_adapter *adap)
> if (bri->recover_bus && bri->recover_bus != i2c_generic_scl_recovery)
> return 0;
>
> - /*
> - * pins might be taken as GPIO, so we should inform pinctrl about
> - * this and move the state to GPIO
> - */
> - if (bri->pinctrl)
> - pinctrl_select_state(bri->pinctrl, bri->pins_gpio);
> -

But this might be absolutely necessary for other i2c drivers and this is
set in generic code.

My first question is: why is this platform even defining the "gpio" pin
control state for this i2c device if it is so dangerous to use?
If it can't be used, you just give it too much rope, delete the "gpio"
state for this group from the device tree: problem solved.

(This can be done with the specific /delete-node/ directive if
necessary, e.g. if you want to use the "gpio" state on other boards.)

Second: do you even want to do recovery on this platform then?
Is it necessary? What happens electronically in this case, if we don't
switch the pins to GPIO mode? Is it something akin to the "strict"
property in struct pinmux: that the GPIO block and the device can
affect the same pins at the same time? That warrants an explanation
and a comment.

If you can't delete the "gpio" pin control state, I would add a
bool pinctrl_stay_in_device_mode;
to
struct i2c_bus_recovery_info
in include/linux/i2c.h

And just:

if (bri->pinctrl && !bri->pinctrl_stay_in_device_mode)
pinctrl_select_state(bri->pinctrl, bri->pins_gpio);

(Also the switch to the "default" state further down could be
contitional !bri->pinctrl_stay_in_device_mode)

But mostly I wonder why the "gpio" pin control state is defined, if it's
not to be used.

Yours,
Linus Walleij