• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 1129 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP-L138 hardware I2C

Clifton Barnes
Prodigy 155 points
Other Parts Discussed in Thread: OMAP-L138, OMAP-L137, TPS65070

I noticed that the DaVinci-PSP-SDK-03.20.00.11 release for the OMAP-L138 uses the GPIO bit bang I2C driver instead of the hardware I2C driver.  The board file for the OMAP-L137, however, uses the hardware I2C driver.  Also, the Linux davinci git kernel has the OMAP-L138 using the hardware I2C driver.  Is there a reason why the PSP release is using the big bang I2C driver?  Is there a problem with the hardware or the hardware driver for the OMAP-L138?

 

Thanks,

Clif

  • 0
    TI__Expert 6385 points

    Hi Clif,

    This is because of a hardware issue in Logic PD SOM. There is no issue with OMAP-L138 SoC I2C hardware. Here is the note regarding this from the release notes:

    SDOCM00067843 DA850: When TPS65070 PMIC is configured for an output voltage of 1.0V, I2C bus becomes un-unsable This is an issue with EVM hardware. To workaround this issue, the release uses gpio based bit-banging i2c driver in Linux kernel.


    Thanks,

    Sekhar

  • 0 in reply to Sekhar Nori
    Prodigy 215 points

    This is a year-and-a-half late, but I just successfully upgraded/reverted (depending on your point of view) to the I2C device operation.  I found that the bit-banged I2C was 3-4 times slower than the I2C device operation.  The patch is relatively simple and involves changes to only board_da850_evm.c and da850.c.  If anyone is interested, reply back and I can supply the changes.

  • 0 in reply to dswag89
    Expert 1930 points

    i am interested. please supply the changes.

  • 0 in reply to dswag89
    TI__Expert 5170 points

    Hi,

    Are you not seeing any issues when you reverted the I2C bit bang driver? Please share the changes with me. I can test it thoroughly on the EVM for many scenarios and then you can submit this patch to community.

    Regards, Sudhakar

  • 0 in reply to Sudhakar Rajashekhara
    Prodigy 215 points

    I am not seeing any issues, as I run the PMIC at the standard 1.2V, running the OMAP at 300MHz.  The TI issue noted above (SDOCM00067843) indicates that the problem only shows up with a 1.0V PMIC output voltage.  I'm not sure how many implementations out there run this, but I can't imagine that it represents "the majority" of developers.  I've attached a patch representing the changes to switch between bit-bang I2C and I2C device mode.  I have only tested/verified the I2C device mode, but think I have correctly "keyed" the switch based on the CONFIG_I2C_GPIO flag.  This patch is based on a 2.6.33 Kernel, as distributed from TimeSys, but expect it will be largely portable to other Kernel revs.  I kept the changes as minimal as I could, hoping it will port to a wider array of code.  As a heavy user of the I2C bus, I do however recommend the additional change to speed up the I2C bus for both cases.  For the bit-bang I2C path, change da850_gpio_i2c_pdata.udelay to 1 (from 2).  For the I2C device mode, change da850_evm_i2c_0_pdata.bus_freq to 400 (from 100).  I'm not sure if I'm doing it correctly, but I'm attempting to attach a zipped patch file containing the changes.

    4454.linux-2.6.33-i2c.zip

    Feel free to contact me for any further questions/comments.

    Dan

  • 0 in reply to dswag89
    Prodigy 215 points

    Sudhakar,

    Follow-up note: I was ignoring this yesterday while I was trying to get my kernel boot speed up, but now it bothers me.  I get a very rare error message from the driver:

     i2c_davinci i2c_davinci.1: abnormal termination buf_len=-1

     A Google search reveals that this is/may be tied up with the SOM buffer problem and/or various I2C driver patches.  The odd thing, though, is that I have been using the 2.6.32-rc6 Kernel for the past two years (which uses I2C device mode) and have never witnessed this error message.  As part of my effort to "fall back" to I2C device mode with the 2.6.33 Kernel, I looked at i2c-davinci.c some (diff-ed the two versions I had from 2.6.32-rc6 and 2.6.33).  I recall at least one code change that I worried about... there was an "order of events" change in one of the driver functions that concerned me.

     I don't really have any question, but wanted to throw this note your way to see if you have any response/thoughts on the subject.