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.

/dev/i2c-x not showing up

Other Parts Discussed in Thread: DM3730

Hello,

I am running Angstrom linux on a DM3730, and I have configured the kernel to have i2c as a character device. During boot, it shows that the i2c busses are muxed and configured correctly, but it does not show up in /dev.

When I use i2cdetect -l, I get the following:

i2c-1 unknown OMAP I2C adapter N/A
i2c-2 unknown OMAP I2C adapter N/A
i2c-3 unknown OMAP I2C adapter N/A

Is there a way to manually add the i2c devices to /dev so that i2ctools can work with it?

Thank you,

    Alex Busman

  • You first have to enable the  i2c buses before you can use the devices attached to it.
    You said i2c is muxed and configured properly, but it doesn't look like so from the output. please post your bootlog related to i2c.

  • Using dmesg | grep i2c, I get the following:

    mux: Setting signal i2c2_scl.i2c2_scl 0x0118 -> 0x0100
    mux: Setting signal i2c2_sda.i2c2_sda 0x0118 -> 0x0100
    mux: Setting signal i2c3_scl.i2c3_scl 0x0118 -> 0x0100
    mux: Setting signal i2c3_sda.i2c3_sda 0x0118 -> 0x0100
    i2c_omap i2c_omap.1: bus 1 rev4.0 at 2600 kHz
    i2c_omap i2c_omap.2: bus 2 rev4.0 at 400 kHz
    i2c_omap i2c_omap.3: bus 3 rev4.0 at 100 kHz
    i2c /dev entries driver

    Is there any more information I can grab from anywhere else?

    Thanks.

  • So using mknod /dev/i2c-2 c 89 2, I managed to have the device show up. Although, when I try it with /dev/i2c-3 (with the appropriate minor number) and I do i2cdetect -r 3, I get the following error for each address it tries to probe:

    i2c_omap i2c_omap.3: controller timed out waiting for start condition to finish

    Anyway, I am making progress, but I seem to be stuck here.

    Thanks.

  • While I solved the problem of the missing /dev entry, I also solved the time out issue which was not software related. There was an I2C device with an incorrect footprint that ended up driving the I2C3-SDA line low, causing the I2C driver to assume the bus was busy.