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.

Linux/TMS320DM8148: Probing for i2c addresses before registering bus in board file

Part Number: TMS320DM8148

Tool/software: Linux

Hello,

I have an i2c device that could be one of two addresses (0x4a or 0x4b). There are no other hardware means to determine what the address is. I need to be able to determine in the linux board file which address is the correct one before calling omap_register_i2c_bus, but I am lost as to how to do this.

Is there a method to probe these addresses before calling the omap_register_i2c_bus function? I have read the following documentation, but it seems so far removed from what the TI81XX porting guide is saying to do to initialize i2c devices:

Additionally, I have tried to arrange my code as follows, but it seems to only work with one device or the other depending on which address comes first in the array:

static struct i2c_board_info __initdata my_i2c_boardinfo[] = {
{
I2C_BOARD_INFO("my_i2c_dev", 0x4a),
.flags = I2C_CLIENT_WAKE,
.irq = OMAP_GPIO_IRQ(118),
.platform_data = &my_data,
},
{
I2C_BOARD_INFO("my_i2c_dev", 0x4b),
.flags = I2C_CLIENT_WAKE,
.irq = OMAP_GPIO_IRQ(118),
.platform_data = &my_data,
},
};

...

omap_register_i2c_bus(2, 400, my_i2c_boardinfo,ARRAY_SIZE(my_i2c_boardinfo));

Any assistance is greatly appreciated.

Thanks,

Will Bates

  • Hi William,

    I made a search but I am not able to find a way to determine the i2c addr in linux kernel by SW. In the link you sent, is stated:

    Unlike PCI or USB devices, I2C devices are not enumerated at the hardware level. Instead, the software must know which devices are connected on each I2C bus segment, and what address these devices are using. For this reason, the kernel code must instantiate I2C devices explicitly.

     

    For any detailed software support, please contact the partners recommended below.

    Regards,
    Pavel

  • Okay, so we are going to go about this another way: We will instead use the i2c_probe function in u-boot to probe the lines and pass the result of that into the kernel from u-boot.

    Unfortunately, the I2C1 line was not operable in u-boot for some reason. I set the config values and i2c control register base values to enable multiple i2c buses, but still was getting hung up trying to swap to i2c1. Fortunately, I ran across the following answer:

    e2e.ti.com/.../570162

    Basically the i2c1 and i2c3 bus clocks were not started by default. Turning them on fixed my issue.