> > Hi Bastian, Hello Ben, [...] > >> > > > > 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. > Sometimes, when a slave "holds" the SDA it need some drive through i2c clock. > > 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> > Ok. > > 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). > Yes, i saw this post before, but our chip is driving 1.2V and we still have our problems. > 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. > I have some effects here, too. We have a i2c repeater solded on our board (PCA9515AD). With this repeater i can reproduce the errer pretty fast. Without this repeater solded on, the mean time before failure is much higher. I can produce the error pretty fast with the ts_test tool. Without any userland tool using the touchscreen info or with the tool evtest, i can see the i2c action on the oscilloscope but it is hard to produce the error. What does this indicate to? Is it possible that userland can influence the kernel driver timing to promote the error? > 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... > Yes, the bitbanging driver gives me "boiled NACK" errors or so sometimes, but the system do not stall. (In my opinion, bitbanging is not the elegant way to do i2c). > Have you asked about how to implement this FDF-SCL-toggle method on > the e2e forums? No, i did not. > Best Regards, > Ben Gardiner > 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
