Hello, [...] > > > > After some action on the touchscreen, there are communication errors > > on the i2c, and the bus stalled. > > In this state the SDA line is hold low and the driver gives repeatedly > > the following messages: > > > > tps6507x 1-0048: ADC result 1 read failed > > i2c_davinci i2c_davinci.1: controller timed out > > i2c_davinci i2c_davinci.1: initiating i2c bus recovery > > i2c_davinci i2c_davinci.1: controller timed out > > i2c_davinci i2c_davinci.1: initiating i2c bus recovery > > tps6507x 1-0048: TSC mode read failed > > i2c_davinci i2c_davinci.1: controller timed out > > i2c_davinci i2c_davinci.1: initiating i2c bus recovery > > i2c_davinci i2c_davinci.1: controller timed out > > i2c_davinci i2c_davinci.1: initiating i2c bus recovery > > tps6507x 1-0048: TSC mode read failed > > [...] > > I am also observing 'controller timed out' messages on v2.6.38-rc8 on > the da850evm with the UI Board connected (the char-lcd one, no the > touchscreen). > > The addresses 0x20 and 0x21 can be seen in the error output below > which I believe indicates that the slave(s) hanging the bus are the > gpio expanders on the baseboard and UI board. > > [...] > pca953x 1-0020: failed reading register > i2c_davinci i2c_davinci.1: controller timed out > i2c_davinci i2c_davinci.1: initiating i2c bus recovery > pca953x 1-0021: failed reading register > i2c_davinci i2c_davinci.1: controller timed out > i2c_davinci i2c_davinci.1: initiating i2c bus recovery > [...] > > The messages repeat with a mix of 0x20 and 0x21 > > When I revert: > c5b4afec8e669bbe265daea24037fccfc42c4fe3 i2c-davinci: Fix TX setup > for more SoCs > 4bba0fd8d1c6d405df666e2573e1a1f917098be0 i2c-davinci: Fix race when > setting up for TX > > (CC'd the author, Jon Povey) -- I get the occasional: > > i2c_davinci i2c_davinci.1: abnormal termination buf_len=-1 > pca953x 1-0020: failed reading register > i2c_davinci i2c_davinci.1: initiating i2c bus recovery > > but not the long repeating string as before. > > I'm guessing there is some incompatibility between the recovery > procedure implemented by Philby John and the fix for the setup race > implemented by Jon Povey -- but I don't know enough about the drivers > to say what that might be. > Have you tested to recover the i2c bus by adding some SCL pulses manually (Shorten SCL to ground)? I tried your patch: > Ben Gardiner <bengardiner@xxxxxxxxxxxxxx> > 15.03.2011 22:08 [...] > I tried the following patch based on the description of the steps you took to > recover the bus. Is there anything you can add? I still get lots of > 'controller timed out' errors. > > Best Regards, > > Ben Gardiner > > Nanometrics Inc. > http://www.nanometrics.ca > > --- > > diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/ > i2c-davinci.c > index 5795c83..52e5e60 100644 > --- a/drivers/i2c/busses/i2c-davinci.c > +++ b/drivers/i2c/busses/i2c-davinci.c > @@ -89,6 +89,7 @@ > #define DAVINCI_I2C_MDR_XA BIT(8) > #define DAVINCI_I2C_MDR_RM BIT(7) > #define DAVINCI_I2C_MDR_IRS BIT(5) > +#define DAVINCI_I2C_MDR_FDF BIT(3) > > #define DAVINCI_I2C_IMR_AAS BIT(6) > #define DAVINCI_I2C_IMR_SCD BIT(5) > @@ -149,6 +150,36 @@ static void generic_i2c_clock_pulse(unsigned int scl_pin) > } > } > > +static void alternate_i2c_clock_pulse(struct davinci_i2c_dev *dev) > +{ > + u32 flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); > + /* free data format mode */ > + flag |= DAVINCI_I2C_MDR_FDF; > + /* receive byte */ > + flag &= ~DAVINCI_I2C_MDR_TRX; > + /* repeat */ > + flag |= DAVINCI_I2C_MDR_RM; > + > + /* > + * Write mode register first as needed for correct behaviour > + * on OMAP-L138, but don't set STT yet to avoid a race with XRDY > + * occuring before we have loaded DXR > + */ > + davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag); > + > + /* Disable receive and transmit interrupts */ > + flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_IMR_REG); > + flag &= ~DAVINCI_I2C_IMR_RRDY; > + flag &= ~DAVINCI_I2C_IMR_XRDY; > + davinci_i2c_write_reg(dev, DAVINCI_I2C_IMR_REG, flag); > + > + /* Set STT to begin transmit now DXR is loaded */ > + flag |= DAVINCI_I2C_MDR_STT; > + davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag); > + > + udelay(40*9); > +} > + > /* This routine does i2c bus recovery as specified in the > * i2c protocol Rev. 03 section 3.16 titled "Bus clear" > */ > @@ -163,8 +194,10 @@ static void i2c_recover_bus(struct davinci_i2c_dev *dev) > flag |= DAVINCI_I2C_MDR_NACK; > /* write the data into mode register */ > davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag); > - if (pdata) > + if (pdata->scl_pin) > generic_i2c_clock_pulse(pdata->scl_pin); > + else > + alternate_i2c_clock_pulse(dev); > /* Send STOP */ > flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); > flag |= DAVINCI_I2C_MDR_STP; It seems we are working on different trees. git log drivers/i2c/busses/i2c-davinci.c gives me the following output. commit c5b4afec8e669bbe265daea24037fccfc42c4fe3 Author: Jon Povey <jon.povey@xxxxxxxxxxxxxxx> Date: Tue Oct 12 13:47:05 2010 +0900 i2c-davinci: Fix TX setup for more SoCs [...] commit 4bba0fd8d1c6d405df666e2573e1a1f917098be0 Author: Jon Povey <jon.povey@xxxxxxxxxxxxxxx> Date: Fri Sep 17 12:02:11 2010 +0900 i2c-davinci: Fix race when setting up for TX [...] commit 8574faf9a5ae71fdd84c6413779a9b076138eb9e Author: Philby John <pjohn@xxxxxxxxxxxxx> [...] ...so the patch doesn ´t apply smooth. I put your changes in manually. The alternate_i2c_clock_pulse function does not generate extra pulses on the clock line. After applying this pach, i am not able to recreate the i2c bus with shortcutting SCL to ground anymore. Are there extra Clock cycles on your EVM UI Board? Regards, Bastian. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
