I2C Drive Debugging Experience

http://blog.csdn.net/cmm20071020/article/details/7179958

upgrade a I2C drive from 2.6.21 to 2.6.39

On the internet to find a post, said the drive is divided into I2C bus, I2C equipment, bus driver to do the actual bus read and write operations, device-driven implementation for different equipment operations. First look at a post to see the overall structure, and then look at the code, understand the effect is good, this trick is with the old cat learn.

Also found a post, said from the old version of the I2C drive, upgrade to the new version, what needs to be done, is the translation of the kernel document.

Do, but I2C device-driven probe function can not be adjusted, this is based on my experience to add a device, but I2C device do not know how to add. Turned over the I2C bus code, and then colleagues found no call i2c_register_board_info. Before the old version of the driver has this i2c_register_board_info call, in Arch/arm inside a board related documents, I light attention to the contents of driver directory, to miss out.

A generic device that invokes a device on the platform_add_devices add device vs I2C bus, invokes the I2c_register_board_info add device, and adds it to a I2C separate device list structure

Adding a driver function is not the same as platform_add_devices, after adding a driver, it traverses the list of devices to see which match

Debug I2C Drive

Chip pt2314, the equipment manual says I2C address is 88, the code address is written in 44. Insmod Drive module, write bus return-6. The s3c2416 platform is used.

I2C Communication principle :

SCL clock line, SDA data cable. When idle, both lines are high.

SCL high power at ordinary times, SDA lower, indicating the starting conditions, relative to the stop condition.

After starting the condition, first send the address, then send the data, the address and data are byte by byte.

Each byte data must have the answer, the address has the ACK, the data also has the ACK.

First send MSB, for example, send the address, first sent a read-write bit, and then sent 7-bit address, 7-bit address is a byte of data low 7 bits, the highest bit is read-write bit. For example, the address of pt2314 88 (10001000), the preceding 1000100 is the address, and the last 0 is a read-write bit.

The quorum procedure is to monitor for SDA conflicts when starting the condition and sending the address. SDA output high power at ordinary times, read back is low level, indicating that there is a conflict on the bus.

oscilloscope Measurement

Need to test SCL,SDA at the same time. The oscilloscope two channel open, respectively adjust the voltage and time, the upper and lower position separately easy to observe. Set to drop along the trigger, because the SCL,SDA is usually high, so there will be a rise along the pins on the table pen point, no need to trigger. Someone take a hand, help according to the scope of the run, set to trigger all line. The pen is grounded, connected SCL,SDA, and then insmod the drive module, initiating the operation of the I2C bus. Catch the signal, the line signal is 88, but did not get ack, so I2C Adpter drive return-6 error.

I2c-tools

Later, with the I2cdetect in I2c-tools, found that there is no equipment at the beginning, Insmod Drive module error, then I2cdetect, the discovery of equipment, the original is pt2314 power supply, the need for a delay in order to work properly.

about I2C address

In this debugging, the address on the chip manual is consistent with the measurements on the I2C bus, is 88, the high 7-bit 1000100 is the address, the lowest bit 0 is read-write bit, and the Linux driver code address 44, is not a read-write bit of the I2C address, and 7-bit address stored in a byte of data in the lower 7 bits, So it seems inconsistent with the chip manual, the Adpter drive in the use of this address, will move left 1 digits, plus read-write bit.