Sekhar,
On Tue, Aug 3, 2010 at 12:43 PM, Nori, Sekhar <[email protected]> wrote: > Hi Nicolas, > > On Tue, Aug 03, 2010 at 01:21:14, Nicolas Luna wrote: > > Hi Sekhar, > > > > Yes there is an other device on the bus, but I removed it and I > > decreased the clock to 20khz. I cannot go below because the i2c seems > > not to work. It does solved the problem. > > > > I modified the driver to add a while(1) when it got an abnormal > > termination. I notified that every time the driver makes this error, I > > can see a clock stretch (with a scope) on the last i2c frame. > > > > - The PMIC (tps65070) is rated to work at 400khz, but even at 20khz it > > seems to need more time to response when it is addressed to much. I > > modified the touchscreen polling period to 100 msec and I still got > > errors. Maybe if the touchscreen driver was working by interruption that > > would leave a chance to the PMIC. > > It should be possible to use an interrupt on a correctly wired hardware. > Can you try getting the interrupt mode working? Hopefully Todd or others > from list can help out in case you run into issues. > I'll see what I can do. > > > > > - Why the i2c driver do not handles clock stretching? > > It should and seems like there is a 1 second time out the driver has > waiting for transfer to complete. How long does the clock stretch in > your case? Please see DAVINCI_I2C_TIMEOUT in > drivers/i2c/busses/i2c-davinci.c > I already tried to change the I2C delay to more than 1 second and my conclusion is that 1 second is really enough because even with more I had errors. I think that the delay is not the problem there is something else when the driver wait for completion. The max stretch I got was not more than 30 msec (when using 30msec polling period). I think that this is due to the polling period. The touchscreen driver send an other request to the PMIC even if the last one didn't finished. *To summarize:* 1- The touchscreen driver should not send an other request if the last one is not finish. (Interrupts could solve that issue) 2- It's sometime a little long to get a response from the PMIC (I dont know exacly but it's more than 100msec) let see what TPS hardware person will say. > > > - On a test there was 2 successive reads to register 02h with a delay of > > 85 msec between. The first went right but while the next read, the salve > > put the clock low to stretch it. It sounds like a problem to me because > > the chip was not receiving a lot of messages and it stretched the clock. > > I cannot find any place in the datasheet that is talking about that > > issue. > > Not sure regarding this. This will likely need some TPS hardware person to > analyze. Can you please post your observations to the PMU forum at: > http://e2e.ti.com/support/power_management/pmu/f/200.aspx > > Done. > Thanks, > Sekhar > > Nicolas
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
