On Thu, Nov 09, 2023 at 09:04:29PM +0100, Linus Walleij wrote: > Hi Robert! > > Thanks for getting back on this issue. > > On Thu, Nov 9, 2023 at 8:10 PM Robert Marko <robert.marko@xxxxxxxxxx> wrote: > > > Yes, I2C recovery is required on this board as otherwise the I2C bus will > > get stuck after a certain number of SFP module plug/unplug events or > > sometimes even just randomly, I2C recovery allows the bus to recover > > and continue working. > > OK makes sense. > > > Maybe my commit message was confusing, so I will try and explain further. > > I2C recovery did work on Armada 3720 just fine until the driver was converted > > to use the generic I2C recovery which is now part of the I2C core. > > > > After it was converted to it, the I2C bus completely stopped working > > on Armada 3720 > > if I2C recovery is enabled by making the recovery pinctrl available in DTS. > > Shouldn't we just revert that patch until we can figure this out then? Note that when I wrote the i2c-pxa recovery code (which was developed and tested on Armada 3720 - the uDPU) it had to work... when the suggestion came up to implement generic recovery, I stated: http://archive.lwn.net:8080/linux-kernel/20200705210942.GA1055@kunai/T/#mf7f862fcd53245f14fb650d33c29cf139d41039d > > I then spent quite a while trying to bisect the exact change that > > causes this issue > > in the conversion as code is almost identical to what the driver was > > doing previously, > > and have bisected it down to pinctrl_select_state(bri->pinctrl, > > bri->pins_gpio) being > > called before SDA and SCL pins are obtained via devm_gpiod_get(). Yes, indeed. That's because the pinctrl internals get confused. I sent you an email about it on 6th December 2019 "pinctrl states vs pinmux vs gpio (i2c bus recovery)" which is why i2c-pxa did things the way it did in my commit "i2c: pxa: implement generic i2c bus recovery". -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
