Analysis of S3C2440 driver-I2C Driver (1)

This time I will study the Code with the I2C driver in the kernel. Before going into the code, I will first briefly understand the relationship between the I2C core data structure. From this, we may be able to have a better understanding of the driver code. The design of the software data structure and the relationship between the data structures should at least describe the Organizational Relationship of the hardware physical connection. The relationship between each part of the Linux I2C framework is shown in:

 

 

 

The I2C code in the kernel can be divided into three layers:
1. i2C framework: I2C. H and i2c-core.c provide core data structure definition, I2C Adapter Driver and device driver registration, logout management for I2C framework subjects, i2C communication method upper-layer, code irrelevant to the specific adapter, the upper-Layer Code of the device address detection, etc; i2c-dev.c is used to create the I2C adapter/dev/I2C/% d device node, provides I2C Device Access methods.
2. I2C bus Adapter Driver: defines the i2c_adapter data structure of the I2C bus adapter, implements the I2C bus communication method on the I2C adapter, and describes the i2c_algorithm data structure.
3. i2C Device Driver: define the i2c_client and possible private data structure of a specific device, use the i2c_probe function of the I2C framework to register the attach_adapter method of the device, provide the possible address range of the device, and check the device address. create a callback function for the i2c_client data structure.

 

 

The main data structure of I2C is as follows:

 

1. the driver for an I2C device is described by the i2c_driver data structure and defined in include/Linux/I2C. h:

Struct i2c_driver {<br/> char name [32]; // string up to 32 bytes <br/> int ID; // ID: any value from 0xf000 to 0 xFFFF <br/> unsigned int flags; // generally, it is directly set to i2c_df_notify <br/> int (* attach_adapter) (struct i2c_adapter *); <br/> int (* detach_client) (struct i2c_client *); <br/> int (* command) (struct i2c_client * client, unsigned int cmd, void * Arg); <br/> void (* inc_use) (struct i2c_client * client); <br/> void (* dec_use) (struct i2c_client * client ); <br/>}; <br/>

 

The attach_adapter callback function is used when the I2C Device Driver Module is installed or when the I2C Adapter driver is installed.
It is called when the program module is used to detect and claim the device and assign the i2c_client data structure to the device.

 

The detach_client method is called when an adapter or device driver module is detached. It is used to log out the device from the bus and release the i2c_client and the corresponding private data structure.

 

The inc_use and dec_use functions are used to change the reference count of the I2C device driver module. Do not directly call the two methods in the i2c_driver data structure, but use the following function call path:
I2c_use_client> i2c_inc_use_client> inc_use
I2c_release_client> i2c_dec_use_client> dec_use

 

 

2. An I2C device is described by the i2c_client data structure:
Struct i2c_client {<br/> char name [32]; <br/> int ID; <br/> unsigned int flags;/* Div ., see below */<br/> unsigned int ADDR;/* chip address-note: 7bit addresses are stored in the */<br/>/* _ lower _ 7 bits of this char */<br/> struct i2c_adapter * adapter; /* the adapter we sit on */<br/> struct i2c_driver * driver;/* and our access routines */<br/> void * data; /* for the clients */<br/> int usage_count;/* How many accesses currently to the client */<br/>}; <br/>

When installing the adapter or device driver, use the attach_adapter function in the device driver i2c_driver to detect the device address. If the detection succeeds, call the callback function provided by the device driver to create the i2c_client Data Structure describing the device, and point the driver pointer to the i2c_driver data structure of the device driver. In this way, you can use the method in i2c_driver to unregister the device and control the reference count in the future.

 

 

3. An I2C adapter is described by the i2c_adapter data structure:
Struct i2c_adapter {<br/> char name [32]; <br/> unsigned int ID;/* = is algo-> ID | hwdep. struct-> ID, for registered values see below */<br/> struct i2c_algorithm * algo;/* the algorithm to access the bus */<br/> void * algo_data; <br/> void (* inc_use) (struct i2c_adapter *); <br/> void (* dec_use) (struct i2c_adapter *); <br/> int (* client_register) (struct i2c_client *); <br/> int (* client_unregister) (struct i2c_client *); <br/> void * data; /* private data for the adapter */<br/> struct semaphore lock; <br/> unsigned int flags;/* flags specifying Div. data */<br/> struct i2c_client * clients [i2c_client_max]; <br/> int client_count; <br/> int timeout; <br/> int retries; <br/> # ifdef config_proc_fs <br/>/* No need to set this when you initialize the adapter */<br/> int inode; <br/> # If linux_version_code <kernel_version (2, 1, 29) <br/> struct proc_dir_entry * proc_entry; <br/> # endif/* def config_proc_fs */<br/> };

 

The clients pointer array is designed in the i2c_adapter data structure, pointing to the i2c_client data structure of each device on the bus. A static array can be used because one I2C bus can only have i2c_clent_max devices. (if the number of related data structures is unknown, the linked list is obviously a better choice ). Lock semaphores are used to achieve mutex access to the I2C bus: the current process must first obtain the semaphores during access to any device on the I2C bus, and will not release the semaphores during the blocking wait until the I2C operation is completed.

 

 

4. The i2c_algorithm Data Structure describes the communication method of the I2C adapter:

Struct i2c_algorithm {<br/> char name [32];/* textual description */<br/> unsigned int ID; <br/> int (* master_xfer) (struct i2c_adapter * ADAP, struct i2c_msg msgs [], int num); <br/> int (* smbus_xfer) (struct i2c_adapter * ADAP, 2010addr, <br/> unsigned short flags, char read_write, <br/> u8 command, int size, Union i2c_smbus_data * data); <br/> int (* slave_send) (struct i2c_adapter *, char *, INT); <br/> int (* slave_recv) (struct i2c_adapter *, char *, INT); <br/> int (* algo_control) (struct i2c_adapter *, unsigned int, unsigned long); <br/> u32 (* functionality) (struct i2c_adapter *); <br/> };

 

The master_xfer/smbus_xfer Pointer Points to the I2C communication protocol or SMBus Communication Protocol implemented by the I2C Adapter Driver Module. The following analysis shows that when the user process accesses the I2C device through the/dev/I2C/% d device node provided by the i2c-dev, it is ultimately done by calling the method pointed to by master_xfer or smbus_xfer.

 

The slave_send/Recv function is used to implement the transfer method when the I2C adapter assumes the slave role.

 

 

Due to the consistency of the content, I recorded the data structure in an article and pasted the driver code, which makes my personal feeling messy. Therefore, I still choose to divide the I2C driver into three parts. This article discusses the data structure as the first part. In the following I2C driver article: Analysis of the S3C2440 driver -- I2C Driver (2), will go deep into the i2c-dev.c driver code. The third part is in-depth i2c-core.c to understand the actual underlying operation process.

 

Please refer to the next section for details ~

 

 

Links to this series of blog posts:

I2C drive (1) http://blog.csdn.net/jarvis_xian/archive/2011/05/27/6449939.aspx
I2C drive (2) http://blog.csdn.net/jarvis_xian/archive/2011/05/27/6451168.aspx
I2C drive (3) http://blog.csdn.net/jarvis_xian/archive/2011/05/28/6452431.aspx
I2C drive (4) http://blog.csdn.net/jarvis_xian/archive/2011/05/30/6455697.aspx