RE: [PATCH v2] i2c: cadence: Add standard bus recovery support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----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.
 
> 
> --
> Robert Hancock
> Senior Hardware Designer, Calian Advanced Technologies www.calian.com




[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux