Hi Bastian, On Thu, Mar 17, 2011 at 5:08 AM, <Bastian.Ruppert@xxxxxxxxxx> wrote: > 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 shorted I2C0_SCL at pin 22 of the PH146(tca416) on the baseboard. The first time it appeared to work -- the repeating messages on the console stopped. Sometime the messages started up again; I repeated the procedure but this time the messages did not stop. > 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. I was working off of v2.6.38-rc8 here. > 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. You are missing the following commit 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 This patch is an improvement to 4bba0fd8d1c6d405df666e2573e1a1f917098be0 which got to mainline a little early. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey <jon.povey@xxxxxxxxxxxxxxx> Acked-by: Troy Kisky <troy.kisky@xxxxxxxxxxxxxxxxxxx> Tested-by: Sudhakar Rajashekhara <sudhakar.raj@xxxxxx> Acked-by: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> Signed-off-by: Ben Dooks <ben-linux@xxxxxxxxx> > The alternate_i2c_clock_pulse function does not generate extra pulses on > the clock line. Ok. I made the patch from the short snip of the method you described; I was more wondering whether the patch was the same as what you've tested. > After applying this pach, i am not able to recreate the i2c bus with > shortcutting SCL to ground anymore. Yeah -- I can confirm also that with the patch applied I am unable to free the bus by shorting SCL to ground. The patch is doing more harm than good. > Are there extra Clock cycles on your EVM UI Board? I'm not sure. I'm sorry I don't have a logic analyzer available ATM. I noticed on the e2e forums that there is a reason why the PSP uses a bitbanging i2c interface -- since the 1.0v OPP makes the i2c controller unusable [1] (I've added Sekhar to the CC since he pointed out the problem in that post). I had my kernel configured to use CPU frequency scaling -- I disabled the feature but this did not fix the problem. I wonder if there is YA hardware problem with i2c on the LogicPD boards. I've noticed that when I don't have the UBI board connected then I don't get the controller timeouts. Have you tried using the bitbanging i2c driver? I suppose that using the bitbanging i2c driver would be too much CPU overhead for polling your touchscreen... Have you asked about how to implement this FDF-SCL-toggle method on the e2e forums? Best Regards, Ben Gardiner [1] https://e2e.ti.com/support/embedded/f/354/p/68559/248084.aspx#248084 --- Nanometrics Inc. http://www.nanometrics.ca -- 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
