Home ›

I2C Drivers, Part II

Issue 118

From Issue #118
February 2004

Feb 01, 2004  By Greg Kroah-Hartman
 in
Here's what has to happen to read the sensors that report the temperature, fan speed and other important system health information.
Conclusion

This two-part series of articles has explained the basics of how to write a kernel I2C bus driver, I2C algorithm driver and I2C chip driver. A lot of good information on how to write I2C drivers can be found in the Documentation/i2c directory in the kernel tree and on the Lm_sensors Web site (secure.netroedge.com/~lm78).

Greg Kroah-Hartman currently is the Linux kernel maintainer for a variety of different driver subsystems. He works for IBM, doing Linux kernel-related things, and can be reached at greg@kroah.com.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

How the adapter driver verifies the specified address

Anonymous's picture
Submitted by Anonymous (not verified) on Fri, 12/11/2009 - 17:04.

"The i2c_detect function probes the I2C adapter, looking for the different addresses specified in the addr_data structure. If a device is found, the chip_detect function then is called"

Note quite understand, how the adapter driver looks for the address specified. How does it know there is a device at the other end bus would have the address, if it does not read/write some thing from the device. But the adapter driver does not know how to read/write to the device.

RE: How the adapter driver verifies the specified address

Anonymous's picture
Submitted by Anonymous on Wed, 02/10/2010 - 08:40.

Same question here

To probe or not to probe...

Marc's picture
Submitted by Marc (not verified) on Mon, 07/06/2009 - 11:25.

kamou:

I'm currently struggling with a similar issue. I'm trying to write a driver for an image sensor which can be controlled via I2C. I'm still trying to wrap my head around how to get a character device and an I2C driver to coexist in a single device driver. I got around the whole SENSORS_INSMOD_1 macro issue by hard coding the I2C address since this is known a priori for my application. Therefore I do not call i2c_detect in the attach_adapter() callback. However, to enable probing, I found that if the normal_i2c, normal_i2c_range, normal_isa, and normal_isa_range macros are populated with proper address data, the invocation of the SENSORS_INSMOD_1 macro will set up the addr_data structure accordingly. The i2c_detect then probes only those addresses in the range specified by these arrays. When one is found the callback provided to i2c_detect (chip_detect in the article's example) is invoked to setup a client for that chip.

My question, however, is there seems to be an m:n ratio of adapters to i2c busses. I'm trying to figure out how to manage that within a single char device driver. I'm currently looking at the i2c-dev implementation, however, this uses the old style of registering character devices which I'm not familiar with so I'm not 100% sure what's going on. Does anyone have any insight and silently using an I2C chip driver from within a char device driver?

trying to write a driver for an audio chip

kamou's picture
Submitted by kamou on Thu, 03/05/2009 - 13:59.

hello !

I'm trying to write a driver for an audio chip, this chip can be controlled via i2c bus (i2c-0)

the problem is that I don't understand how I can "open" the i2c-0 in kernel space...
I tried to do as le lm75 sensor driver...but it's not better..
I know that I have to register my driver as an i2c driver with the i2c_add_driver function

does this:

static int
chip_attach_adapter(struct i2c_adapter *adapter)
{
return i2c_detect(adapter, &addr_data,
chip_detect);
}

probes every i2c bus on my board ?
and I don't understand what addr_data is or what it does,
I know it is in the SENSORS_INSMOD_1 macro
but I'm not writing a driver for a sensor, but for an audio chip...

can anyone help me understand better all this ?

Webcast
More Resources
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions