I2c-2.6.34 documentation: How to enumerate the generation of i2c_client

========================================================== ====
Author: yuanlulu

Http://blog.csdn.net/yuanlulu

No copyright, but please keep this statement for reprinting
========================================================== ====

According to your own understanding, translated. If you have any objection or doubt, refer to the original article. After all, the kernel documentation is the essence. S

 

Method 1: use the bus number to declare the device.

Define device information during kernel initialization. The premise is that the kernel has determined which I2C devices are connected to their addresses during compilation, and the number of the connected bus.

For example, you can use this code in/ARCH/ARM/Mach-xxxx/board_xxxx.c to register the I2C device information. Static struct i2c_board_info _ initdata h4_i2c_board_info [] ={< br/>{< br/> i2c_board_info ("isp1301_omap", 0x2d), <br/>. IRQ = omap_gpio_irq (125), <br/>}, <br/> {/* EEPROM on mainboard */<br/> i2c_board_info ("24c01", 0x52 ), <br/>. platform_data = & m24c01, <br/>}, <br/> {/* EEPROM on CPU card */<br/> i2c_board_info ("24c01", 0x57 ), <br/>. platform_data = & m24c01, <br/>}, <br/>}; </P> <p> static void _ init omap_h4_init (void) <br/>{< br/> (...) <br/> i2c_register_board_info (1, h4_i2c_board_info, <br/> array_size (h4_i2c_board_info); <br/> (...) <br/>}< br/>

After registration, the i2c_adapter scans all registered 2c_board_info and creates an i2c_client for the I2C device connected to it. In this way, when i2c_driver with the same name in 2c_board_info is registered, i2c_client is bound to i2c_driver, And the probe function of i2c_driver is called.
Method 2: Enumerate devices. Use i2c_new_device () or i2c_new_probed_device ().Method 1 has many limitations. You must know the I2C bus number and physical connection when compiling the kernel. Sometimes developers are faced with an existing system and cannot modify the kernel. Or kernel developers do not know which I2C devices or how many I2C buses are there when porting the system. In this case, i2c_new_device () is required. Its prototype is: struct i2c_client *
I2c_new_device (struct i2c_adapter * ADAP, struct i2c_board_info const * info); this function uses the information provided by info to create an i2c_client and bind it with the i2c_adapter to which the first parameter points. The returned parameter is an i2c_client pointer. You can directly use the i2c_client pointer to communicate with the device. This method is relatively simple.
The function for getting the i2c_adapter pointer is: struct i2c_adapter * i2c_get_adapter (int id); // Its parameter is the I2C bus number. Release after use: void i2c_put_adapter (struct i2c_adapter * ADAP );
If the IP address of the I2C device is not fixed, or even has different addresses on different boards, you can provide an address list for the system to detect. In this case, the i2c_new_probe_device function should be used .. The usage is as follows: Example (from the pnx4008 OHCI driver): <br/> static const unsigned short normal_i2c [] = {0x2c, 0x2d, i2c_client_end }; <br/> static int _ devinit usb_hcd_pnx4008_probe (struct platform_device * pdev) <br/>{< br/> (...) <br/> struct i2c_adapter * i2c_adap; <br/> struct i2c_board_info i2c_info; <br/> (...) <br/> i2c_adap = i2c_get_adapter (2); <br/> memset (& i2c_info, 0, sizeof (struct i2c_board_info); <br/> strlcpy (i2c_info.name, "isp1301_pnx", i2c_name_size); <br/> response = callback (i2c_adap, & i2c_info, <br/> normal_i2c); <br/> i2c_put_adapter (i2c_adap ); <br/> (...) <br/>}< br/>

The prototype of i2c_new_probed_device is: struct i2c_client *
I2c_new_probed_device (struct i2c_adapter * ADAP,
Struct i2c_board_info * info,
Unsigned short const * addr_list); this function detects the address in addr_list on the specified bus and assigns the first address with Ack feedback to Info-> ADDR, then call i2c_new_device using the first two parameters. Its return value is also an available i2c_client pointer.
I2c_unregister_device () can cancel i2c_new_device ()/i2c_new_probed_device () applied for i2c_client.
Supplement: How do drivers know the number of a physical I2C bus? [Root @ zlg
/] # Cat/sys/class/i2c-dev/i2c-0/namePNX4008-I2C0 [root @ zlg/] # Cat/sys/class/i2c-dev/i2c-1/namePNX4008-I2C1 [root @ zlg/] # Cat /sys/class/i2c-dev/i2c-2/nameUSB-I2C

Method 3: Test specific devices on all I2C buses.

I have not understood the limits of method 2 and the benefits of method 3 in the kernel documentation. Let's talk about your understanding, that is, although method 2 can detect multiple addresses,

But it can only be detected on a specified bus, and the first available address is detected to stop the probe. If you are not sure about the bus number,

Or you can use method 3 to detect multiple I2C devices at a time.

Implementation Method 3 requires two conditions:

* ***** Implement the detect Member of the i2c_driver. The prototype of this member function is:

int (*detect)(struct i2c_client *, int kind, struct i2c_board_info *);

This function must check whether the ADDR field of the second parameter supports the address itself. If yes, it must be filled with info-> type at least. Other members of info can also be filled, however, ADDR should not be modified.

If yes, 0 is returned; otherwise,-enodev is returned.

* ***** Initialize the address_list member of i2c_driver. When i2c_driver is registered, i2c_core detects all addresses in address_list on all registered i2c_adapters. After the hardware detects the addresses successfully, it calls the detect member of i2c_driver, then, an i2c_client is created based on the info filled by detect. If two devices have the same IP address on the bus, two i2c_clients are created respectively. If multiple addresses in address_list are occupied by devices, multiple i2c_clients are created.

Maybe because method 3 is too powerful and flexible, this method is not recommended in the kernel documentation. Methods 1 and 2 are preferred.
Method 4: enumeration from user controls.If you cannot know the address of the I2C device when writing the driver (even the list of possible addresses is unknown), you need to enter the address from the user space after the system runs. The user space uses two sysfs attribute files to create and delete i2c_client: new_device and delete_device. Both files are only written.
New_device has two parameters: I2C device name (string) and address (hexadecimal number starting with 0x ). Delete_device has only one parameter, that is, the device address.
Example:

# echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device

You can see that the bus number has been specified.

 
Supplement -- Method 5: Call i2c_new_device () or i2c_new_probed_device () in attach_adapter of i2c_driver ()
This method is essentially similar to method 2.
This example is in/sound/PPC/keywest. C of kernel 2.6.34. For more information, see.
Supplement:
The bus types of i2c_driver and i2c_client are i2c_bus_type. The name of the i2c_client name Member (corresponding to Info-> type) and the id_table name in i2c_driver
Is the basis for their mutual binding.
Devices with the same address can be attached to different i2c_adapters, but the name of I2C devices is global. Therefore, different devices must have different names. (Not the same ).