Chapter 8: Writing I2C Device Drivers

I2C stands for Inter-Integrated Circuit. It is a serial, multi-master, and asynchronous bus invented by Philips (now NXP), though multi-master mode is not widely used. I2C is a two-wire bus, respectively named Serial Data (SDA) and Serial Clock (SCL, or SCK). An I2C device is a chip that interacts with another device via an I2C bus. On this bus, both SDA and SCL are open-drain/open collectors, meaning that each can drive its output low, but neither can drive its output high without having pull-up resistors. SCL is generated by the master to synchronize data (carried by SDA) transfer over the bus. Both the slave and master can send data (not at the same time, of course), thus making SDA a bidirectional line. That said, the SCL signal is also bidirectional since the slave can stretch the clock by keeping the SCL line low. The bus is controlled by the master, which in our case is part of the System on Chip (SoC). This bus is frequently used in embedded...

I2C framework abstractions in the Linux kernel

The Linux kernel I2C framework is made up of a few data structures, with the most important being as follows:

• i2c_adapter: Used to abstract the I2C master device. It is used to identify a physical I2C bus.
• i2c_algorithm: This abstracts the I2C bus transaction interface. Here, transaction means to transfer, such as read or write operations.
• i2c_client: Used to abstract a slave device sitting on the I2C bus.
• i2c_driver: The driver of the slave device. It contains a set of specific driving functions to deal with the device.
• i2c_msg: This is the low-level representation of one segment of an I2C transaction. This data structure defines the device address, the transaction flags (if it's a transmit or receive, for example), a pointer to the data to send/receive, and the size of the data.

Since the scope of this chapter is limited to slave device drivers, we will focus on the last three data structures. However...

The I2C driver abstraction and architecture

The struct i2c_driver structure, as we saw in the previous section, contains the driving methods that are needed to handle the I2C devices it is responsible for. Once added to the bus, the device will need to be probed, which makes the i2c_driver.probe_new method the entry point of the driver.

Probing the I2C device

The probe() callback in the struct i2c_driver structure is invoked any time an I2C device is instantiated on the bus and claims this driver. It is responsible for the following tasks:

• Checking whether the I2C bus controller (the I2C adapter) supports the functionalities needed by the device using the i2c_check_functionality() function
• Checking whether the device is the one we expected
• Initializing the device
• Setting up device-specific data if necessary
• Registering with the appropriate kernel frameworks

Formerly, the probing callback was assigned to the probe element of struct i2c_driver and...

How not to write I2C device drivers

Deciding not to write the device driver consists of writing the appropriate user code to deal with the underlying hardware. Though it is user code, the kernel always intervenes to ease the development process. I2C adapters are exposed by the kernel in the user space as character devices in the form of /dev/i2c-<X>, where <X> is the bus number. Once you have opened the character device file that corresponds to the adapter your device sits on, there is a series of commands you can execute.

First, the required headers for dealing with I2C devices from the user space are as follows:

#include <linux/i2c-dev.h>
#include <i2c/smbus.h>
#include <linux/i2c.h>

The following are the possible commands:

• ioctl(file, I2C_FUNCS, unsigned long *funcs): This command is probably the first command you should issue. It is the equivalent of i2c_check_functionality() in the kernel, which returns the necessary adapter functionality...

Summary

In this chapter, we looked at I2C device drivers. Now, it's time for you to pick any I2C device on the market and write the corresponding driver, along with the necessary device tree support. This chapter talked about the kernel I2C core and its associated API, including device tree support, to give you the necessary skills to talk with I2C devices. You should now be able to write efficient probe functions and register them with the kernel I2C core.

In the next chapter, we will use the skills we have learned in this chapter to develop an SPI device driver.