Linux below write I2C device driver-How to enumerate the generated i2c_client__linux

  i2c--2.6.34 Document: How to enumerate the generated i2c_client

============================================
Author: yuanlulu
Http://blog.csdn.net/yuanlulu


Copyright No, but reprint please retain this paragraph statement
============================================

According to their own understanding, the http://lxr.linux.no/linux+v2.6.34/Documentation/i2c/instantiating-devices is translated into the document about enumerating and establishing i2c_client. Have objections or questions please refer to the original, after all, the core of the document is the true essence. S

Method 1: Use the bus number to declare the device. defines the device's information in the initialization of the kernel. The prerequisite is that the kernel compiles to determine which I2C devices and their addresses, as well as the number of connected buses. For example, in/arch/arm/mach-xxxx/board_xxxx.c you can have such a piece of code to register the I2C device information.[CPP] View Plain copy print? static struct I2c_board_info __initdata h4_i2c_board_info[] = {            {                  i2c_ Board_info ("Isp1301_omap", 0x2d),                   .irq            = OMAP_GPIO_IRQ (125),           },           {      /* EEPROM on mainboard */                    i2c_board_info ("24c01", 0x52),                    .platform_data  = &m24c01 ,          },    &NBsp;      {      /* EEPROM on CPU card */                    i2c_board_info ("24c01", 0x57),                  . platform_data  = &m24c01,          }, };      static void __init omap_h4_init (void)   {           (...)            i2c_register_board_info (1, h4_i2c_board_info,                             array_size (h4_i2c_board_info));            (...) Once the  }  is registered, I2c_adapter scans all registered 2c_board_info and establishes a i2c_client for connecting to its own I2C device. This inWhen registering with the same name I2c_driver in 2c_board_info, I2c_client is bound to I2c_driver and I2c_driver's probe function is invoked.
Method 2: Enumerate the devices. use I2c_new_device () or I2c_new_probed_device ().Method 1 has many limitations and must be aware of the I2C bus number and physical connection when compiling the kernel. Sometimes developers are faced with an existing system that cannot modify the kernel. Or when the kernel developer porting the system, you don't know what I2C devices are or how many I2C buses there are. In this case, you need to use I2c_new_device (). Its prototype is: struct i2c_client *
I2c_new_device (struct i2c_adapter *adap, struct i2c_board_info const *info); This function will use the information provided by info to create a i2c_client and bind to the i2c_adapter that the first parameter points to. The returned parameter is a i2c_client pointer. The driver can communicate directly with the device using the i2c_client pointer. This method is a relatively simple method.
The function to get the i2c_adapter pointer is: struct i2c_adapter* i2c_get_adapter (int id);//Its argument is the I2C bus number. To be released after use: void I2c_put_adapter (struct i2c_adapter *adap);
If the address of the I2C device is not fixed, or even have different addresses on different boards, you can provide an address list for system detection. The function that should be used at this time is i2c_new_probe_device. Usage is as follows:[CPP] View Plain copy print? Example (from the pnx4008 OHCI driver):  static const unsigned short normal_i2c[] = {0x2c, 0x2d, I2c_client_end};&N Bsp static int __devinit usb_hcd_pnx4008_probe (struct platform_device *pdev)   {            (...)            struct I2c_adapter *i2c_adap;            struct I2c_board_info i2c_info;            (...)            I2c_adap = I2c_get_adapter (2);            memset (&i2c_info, 0, sizeof (struct i2c_board_info));            strlcpy (I2c_info.name, "Isp1301_pnx", i2c_name_size);            isp1301_i2c_client = I2c_new_probed_device (I2c_adap, &i2c_info,                                                         normal_i2c);            I2c_put_adapter (I2C_ADAP);           (...)  } 
I2c_new_probed_device's prototype is: struct i2c_client *
I2c_new_probed_device (struct I2c_adapter *adap,
struct I2c_board_info *info,
unsigned short const *addr_list); This function will probe the address in addr_list on the specified bus, assign the first address with ACK feedback to info->addr, and then invoke the top two arguments i2c_new_ Device Its return value is also an available i2c_client pointer.
I2c_unregister_device () can unregister the i2c_client of the I2c_new_device ()/I2c_new_probed_device () application.
Add: Driver How the developer knows a physical I2C bus number. [Root@zlg/]# cat/sys/class/i2c-dev/i2c-0/name pnx4008-i2c0 [Root@zlg/]# pnx4008-i2c1 [Root@zlg/]# cat/sys/class/i2c-dev/i2c-2/name USB-I2C

Method 3: Probes for a specific device on all I2C buses.

The limitations of Method 2 in kernel documentation and the benefits of Method 3 I didn't read it. To speak your own understanding, that is, method 2 Although multiple addresses can be probed,

However, it can only be detected on a specified bus and the first available address is detected and the probe is stopped. If the bus number is not previously determined,

or to detect multiple I2C devices at a time, you need to use Method 3.

Implementing method 3 requires two conditions:

The detect member that implements I2c_driver. This member function prototype is:

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

This function must check whether the addr field of the second parameter has its own supported address, and if so, the other members that populate the Info->type,info can also be populated, but the addr should not be modified.

Return 0 if it is, otherwise return to-enodev.

Initializes the address_list member of the I2c_driver. When I2c_driver registers, I2c_core detects all the addresses in Address_list on all registered I2c_adapter, and calls I2c_driver members after the hardware probe succeeds, Then create a i2c_client based on the detect filled info. If there are devices with the same address on two buses, then two i2c_client will be created. If more than one address in the address_list is occupied by a device, multiple i2c_client will be created.

The kernel document does not recommend this approach, perhaps because Method 3 is too powerful and flexible. Preferred methods 1 and 2.
Method 4: Enumeration from the user control. If you don't know the address of the I2C device (even the list of possible addresses) when you write the drive, you need to enter it from user space when the system is running. User space establishes and deletes i2c_client:new_device and Delete_device through two Sysfs property files. These two files are written only.
New_device has two parameters: the name (string) of the I2C device and the address (16 in number at the beginning of the 0x). Delete_device only one parameter, that is the address of the device.
Example:

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

You can see that the bus number is already specified at this time.

Add--Method 5: Call I2c_new_device () or I2c_new_probed_device () in the Attach_adapter in I2c_driver

This method is essentially similar to Method 2.

Such examples are in the/sound/ppc/keywest.c of the 2.6.34 kernel. can refer to.

Add:

The bus types for both I2c_driver and I2c_client are i2c_bus_type,i2c_client name members (corresponding to Info->type) and the names in I2c_driver in id_table

Is the basis on which they bind to each other.

 a device with the same address can be linked on different i2c_adapter, but the name of the I2C device is global, so the names of the different devices are not the same. (not necessarily the same).