>
> > -----Original Message-----
> > From: Robert Hancock <robert.hancock@xxxxxxxxxx>
> > Sent: Saturday, January 8, 2022 3:55 AM
> > To: Shubhrajyoti Datta <shubhraj@xxxxxxxxxx>; wsa@xxxxxxxxxx
> > Cc: Michal Simek <michals@xxxxxxxxxx>; chiragp@xxxxxxxxxx; git
> > <git@xxxxxxxxxx>; linux-i2c@xxxxxxxxxxxxxxx
> > Subject: Re: [PATCH v2] i2c: cadence: Add standard bus recovery
> > support
> >
> > On Mon, 2021-11-29 at 13:00 +0100, Wolfram Sang wrote:
> > > On Mon, Nov 29, 2021 at 02:31:16PM +0530, Shubhrajyoti Datta wrote:
> > > > From: Robert Hancock <robert.hancock@xxxxxxxxxx>
> > > >
> > > > Hook up the standard GPIO/pinctrl-based recovery support for this
> > > > driver.
> > > >
> > > > Based on a patch "i2c: cadence: Recover bus after controller reset"
> > > > by Chirag Parekh in the Xilinx kernel Git tree, but simplified to
> > > > make use of more common code.
> > >
> > > Guys, sorry for the long delay.
> > >
> > > > if (time_left == 0) {
> > > > + i2c_recover_bus(adap);
> > >
> > > According to I2C specs, recovery should be done at the beginning of
> > > a transfer when SDA is detected low. I think this makes sense
> > > because other issues may have stalled the bus as well (e.g. broken
> bootloader).
> > > Makes sense?
> >
> > It looks like on the start of a transfer in cdns_i2c_master_xfer, if
> > the controller reports "bus active" it just bails out with EAGAIN:
> >
> > /* Check if the bus is free */
> > if (cdns_i2c_readreg(CDNS_I2C_SR_OFFSET) & CDNS_I2C_SR_BA) {
> > ret = -EAGAIN;
> > goto out;
> > }
> >
> > I'm not sure exactly what the BA flag indicates (the Xilinx
> > documentation just says "ongoing transfer on the I2C bus"), so we'd
> > have to distinguish between the case of another master doing a
> > transfer and the bus actually being hung up.
> > I'm not sure it's clear from the public documentation how to do this?
> >
> > That might be another improvement that could be added in once the bus
> > recovery functionality is in place?
>
> I think this can be moved to a wait till the bus is not active with a sufficient
> timeout.
> And on timeout we assume that the bus is stuck.
>
> If you all agree I will send implement and send the next version.
Please let me know if this approach is fine.
>
> >
> > --
> > Robert Hancock
> > Senior Hardware Designer, Calian Advanced Technologies
> www.calian.com
