- 论坛徽章:
- 0
|
linux i2c driver
=============================================================================
from: http://www.linuxjournal.com/article/7136
I2C Drivers, Part I
December 1st, 2003 by
Greg Kroah-Hartman
in
Software
The
I2C bus helps you monitor the health of your system. Here's how to
develop a driver that will get you all the hardware info you need to
know.
Average:
Select ratingCancel ratingPoorOkayGoodGreatAwesome
Cancel rating
Poor
Okay
Good
Great
Awesome
Your rating: None Average: 3.9 (12 votes)
In the June and August 2003 issues of Linux Journal,
my column covered the Linux kernel driver model, and the I2C subsystem
was used as an example. This month, we discuss what the I2C subsystem
does and how to write a driver for it.
I2C is the name for a two-wire serial bus protocol originally
developed by Phillips. It commonly is used in embedded systems
so different components can communicate; PC motherboards use I2C to talk to
different sensor chips. Those sensors typically report back fan speeds,
processor temperatures and a whole raft of system hardware information.
The protocol also is used in some RAM chips to report information about
the DIMM itself back to the operating system.
The I2C kernel code has lived outside of the main kernel tree for much
of its development life—it originally was written back in the 2.0
days. The 2.4 kernel contains a bit of I2C support, mainly for some video
drivers. With the 2.6 kernel, a large portion of the I2C code has made
it into the main kernel tree, thanks to the effort of a number of kernel
developers who changed the interfaces to be more acceptable to the
kernel community. A few drivers still live only in
the external CVS tree and have not been moved into the main
kernel.org tree, but it is only a matter of time before they, too, are ported.
The I2C kernel code is broken up into a number of logical pieces: the
I2C core, I2C bus drivers, I2C algorithm drivers and I2C chip drivers.
We ignore how the I2C core operates in this article and focus instead on
how to write a bus and algorithm driver. In Part II, we will cover how
to write an I2C chip driver.
I2C Bus Drivers
An I2C bus driver is described by a
struct named i2c_adapter, which is defined in the
include/linux/i2c.h file. Only the following fields
need to be set up by the bus driver:
struct module *owner; —set to the value (THIS_MODULE) that
allows the proper module reference counting.
unsigned int class; —the type of I2C class devices that this driver
supports. Usually this is set to the value I2C_ADAP_CLASS_SMBUS.
struct i2c_algorithm *algo; —a pointer to the struct i2c_algorithm
structure that describes the way data is transferred through this I2C
bus controller. More information on this structure is provided below.
char name[I2C_NAME_SIZE]; —set to a descriptive name of the I2C
bus driver. This value shows up in the sysfs filename associated with this I2C adapter.
The code below comes from an example I2C adapter driver called
tiny_i2c_adap.c, available from the Linux Journal FTP
site [
ftp.ssc.com/pub/lj/listings/issue116/7136.tgz
] and shows how the
struct i2c_adapter is set up:
static struct i2c_adapter tiny_adapter = {
.owner = THIS_MODULE,
.class = I2C_ADAP_CLASS_SMBUS,
.algo = &tiny_algorithm,
.name = "tiny adapter",
};
To register this I2C adapter, the driver calls the function
i2c_add_adapter with a pointer to the
struct i2c_adapter:
retval = i2c_add_adapter(&tiny_adapter);
If the I2C adapter lives on a type of device that has a
struct device associated with it, such as a PCI or
USB device, then before the call to
i2c_add_adapter, the adapter device's parent pointer
should be set to that device. This pointer configuration can be seen in the following line
from the drivers/i2c/busses/i2c-piix4.c driver:
/* set up sysfs linkage to our parent device */
piix4_adapter.dev.parent = &dev->dev;
If this parent pointer is not set up, the I2C adapter is
positioned on the legacy bus and shows up in the
sysfs tree at /sys/devices/legacy.
Here is what happens to our example driver when it is registered:
$ tree /sys/devices/legacy/
/sys/devices/legacy/
|-- detach_state
|-- floppy0
| |-- detach_state
| `-- power
| `-- state
|-- i2c-0
| |-- detach_state
| |-- name
| `-- power
| `-- state
`-- power
`-- state
As discussed in the previous kernel driver model columns, the
I2C adapter also shows up in the
/sys/class/i2c-adapter directory:
$ tree /sys/class/i2c-adapter/
/sys/class/i2c-adapter/
`-- i2c-0
|-- device -> ../../../devices/legacy/i2c-0
`-- driver -> ../../../bus/i2c/drivers/i2c_adapter
To unregister an I2C adapter, the driver should call the function
i2c_del_adapter with a pointer to the struct i2c_adapter, like this:
i2c_del_adapter(&tiny_adapter);
I2C Algorithm Drivers
An I2C algorithm is used by the I2C bus driver to talk to the
I2C bus. Most I2C bus drivers define their own I2C
algorithms and use them, as they are tied closely to how the bus driver talks
to that specific type of hardware. For some classes of I2C bus drivers,
a number of I2C algorithm drivers already have been written. Examples
of these are ITE adapters found in
drivers/i2c/i2c-algo-ite.c, IBM PPC 405 adapters found in
drivers/i2c/i2c-algo-ibm_ocp.c and a generic
I2C bit shift algorithm found in drivers/i2c/i2c-algo-bit.c. All of
these already written algorithms have their own functions with which an I2C bus
driver needs to register to use.
For more information on these, please see all of the
drivers/i2c/i2c-algo-*.c files in the kernel tree.
For our example driver, we are going to create our own I2C algorithm
driver. An algorithm driver is defined by a
struct i2c_algorithm structure and is defined in the
include/linux/i2c.h file. Here is a
description of some of the commonly used fields:
char name[32];: the name of the algorithm.
unsigned int id;: description of the type of algorithm this
structure defines. These different types are
defined in the include/linux/i2c-id.h file and
start with the characters I2C_ALGO_.
int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg msgs[], int num);:
a function pointer to be set if this
algorithm driver can do I2C direct-level accesses.
If it is set, this function is called whenever
an I2C chip driver wants to communicate with the chip
device. If it is set to NULL, the
smbus_xfer function is used instead.
int (*smbus_xfer) (struct i2c_adapter *adap, u16 addr, unsigned short flags,
char read_write, u8 command, int size, union i2c_smbus_data *data);:
a function pointer to be set if this
algorithm driver can do SMB bus accesses. Most PCI-based I2C bus drivers are able to do this, and
they should set this function pointer. If it is set,
this function is called whenever an I2C chip
driver wants to communicate with the chip device.
If it is set to NULL, the master_xfer
function is used instead.
u32 (*functionality) (struct i2c_adapter *);: a function pointer called by
the I2C core to determine what kind of reads and writes the I2C
adapter driver can do.
In our example I2C adapter driver, the i2c_adapter structure referenced
the tiny_algorithm variable. That structure is
defined as the following:
static struct i2c_algorithm tiny_algorithm = {
.name = "tiny algorithm",
.id = I2C_ALGO_SMBUS,
.smbus_xfer = tiny_access,
.functionality = tiny_func,
};
The tiny_func function is small and tells the
I2C core what types of I2C messages this algorithm can support. For
this driver, we want to be able to support a few different I2C message
types:
static u32 tiny_func(struct i2c_adapter *adapter)
{
return I2C_FUNC_SMBUS_QUICK |
I2C_FUNC_SMBUS_BYTE |
I2C_FUNC_SMBUS_BYTE_DATA |
I2C_FUNC_SMBUS_WORD_DATA |
I2C_FUNC_SMBUS_BLOCK_DATA;
}
All of the different I2C message types are defined in
include/linux/i2c.h and start with the characters
I2C_FUNC_.
The tiny_access function is called when an I2C
client driver wants to talk to the I2C bus. Our example function is quite
simple; it merely logs all of the requests the I2C chip driver
makes to the syslog and reports success back to the caller. This log
allows you to see all of the different addresses and data types that an
I2C chip driver may request. The implementation looks like:
static s32 tiny_access(struct i2c_adapter *adap,
u16 addr,
unsigned short flags,
char read_write,
u8 command,
int size,
union i2c_smbus_data *data)
{
int i, len;
dev_info(&adap->dev, "%s was called with the "
"following parameters:\n",
__FUNCTION__);
dev_info(&adap->dev, "addr = %.4x\n", addr);
dev_info(&adap->dev, "flags = %.4x\n", flags);
dev_info(&adap->dev, "read_write = %s\n",
read_write == I2C_SMBUS_WRITE ?
"write" : "read");
dev_info(&adap->dev, "command = %d\n",
command);
switch (size) {
case I2C_SMBUS_PROC_CALL:
dev_info(&adap->dev,
"size = I2C_SMBUS_PROC_CALL\n");
break;
case I2C_SMBUS_QUICK:
dev_info(&adap->dev,
"size = I2C_SMBUS_QUICK\n");
break;
case I2C_SMBUS_BYTE:
dev_info(&adap->dev,
"size = I2C_SMBUS_BYTE\n");
break;
case I2C_SMBUS_BYTE_DATA:
dev_info(&adap->dev,
"size = I2C_SMBUS_BYTE_DATA\n");
if (read_write == I2C_SMBUS_WRITE)
dev_info(&adap->dev,
"data = %.2x\n", data->byte);
break;
case I2C_SMBUS_WORD_DATA:
dev_info(&adap->dev,
"size = I2C_SMBUS_WORD_DATA\n");
if (read_write == I2C_SMBUS_WRITE)
dev_info(&adap->dev,
"data = %.4x\n", data->word);
break;
case I2C_SMBUS_BLOCK_DATA:
dev_info(&adap->dev,
"size = I2C_SMBUS_BLOCK_DATA\n");
if (read_write == I2C_SMBUS_WRITE) {
dev_info(&adap->dev, "data = %.4x\n",
data->word);
len = data->block[0];
if (len 32)
len = 32;
for (i = 1; i dev,
"data->block[%d] = %x\n",
i, data->block);
}
break;
}
return 0;
}
Now that the tiny_i2c_adap driver is built and loaded, what can it do?
On its own, it cannot do anything. An I2C bus driver needs an I2C client driver in
order to do anything besides sit in the
sysfs tree. So, if the lm75
I2C client driver is loaded, it tries to use the
tiny_i2c_adap driver to find the chip for which it was
written:
$ modprobe lm75
$ tree /sys/bus/i2c/
/sys/bus/i2c/
|-- devices
| |-- 0-0048 -> ../../../devices/legacy/i2c-0/0-0048
| |-- 0-0049 -> ../../../devices/legacy/i2c-0/0-0049
| |-- 0-004a -> ../../../devices/legacy/i2c-0/0-004a
| |-- 0-004b -> ../../../devices/legacy/i2c-0/0-004b
| |-- 0-004c -> ../../../devices/legacy/i2c-0/0-004c
| |-- 0-004d -> ../../../devices/legacy/i2c-0/0-004d
| |-- 0-004e -> ../../../devices/legacy/i2c-0/0-004e
| `-- 0-004f -> ../../../devices/legacy/i2c-0/0-004f
`-- drivers
|-- i2c_adapter
`-- lm75
|-- 0-0048 -> ../../../../devices/legacy/i2c-0/0-0048
|-- 0-0049 -> ../../../../devices/legacy/i2c-0/0-0049
|-- 0-004a -> ../../../../devices/legacy/i2c-0/0-004a
|-- 0-004b -> ../../../../devices/legacy/i2c-0/0-004b
|-- 0-004c -> ../../../../devices/legacy/i2c-0/0-004c
|-- 0-004d -> ../../../../devices/legacy/i2c-0/0-004d
|-- 0-004e -> ../../../../devices/legacy/i2c-0/0-004e
`-- 0-004f -> ../../../../devices/legacy/i2c-0/0-004f
Because the tiny_i2c_adap driver responds with a
success to every read and write request it is asked to accomplish,
the lm75 I2C chip driver thinks it has found an lm75 chip at every known possible I2C address for this chip.
This abundance of addresses is why I2C devices 0-0048 through 0-004f have been created. If we
look at the directory for one of these devices, the sensor files for this
chip driver are shown:
$ tree /sys/devices/legacy/i2c-0/0-0048/
/sys/devices/legacy/i2c-0/0-0048/
|-- detach_state
|-- name
|-- power
| `-- state
|-- temp_input
|-- temp_max
`-- temp_min
The detach_state file and
power directory is created by the kernel driver core
and is used for power management. It is not created by the
lm75 driver. The functions of the other files in this directory are
described below.
If we ask the lm75 driver for the current
value of temp_max, we receive the following:
$ cat /sys/devices/legacy/i2c-0/0-0048/temp_max
1000
To get that value, the lm75 driver asked the
tiny_i2c_adap driver to read some addresses on the
I2C bus. This request is shown in the syslog:
$ dmesg
i2c_adapter i2c-0: tiny_access was called with the following parameters:
i2c_adapter i2c-0: addr = 0048
i2c_adapter i2c-0: flags = 0000
i2c_adapter i2c-0: read_write = read
i2c_adapter i2c-0: command = 0
i2c_adapter i2c-0: size = I2C_SMBUS_WORD_DATA
i2c_adapter i2c-0: tiny_access was called with the following parameters:
i2c_adapter i2c-0: addr = 0048
i2c_adapter i2c-0: flags = 0000
i2c_adapter i2c-0: read_write = read
i2c_adapter i2c-0: command = 3
i2c_adapter i2c-0: size = I2C_SMBUS_WORD_DATA
i2c_adapter i2c-0: tiny_access was called with the following parameters:
i2c_adapter i2c-0: addr = 0048
i2c_adapter i2c-0: flags = 0000
i2c_adapter i2c-0: read_write = read
i2c_adapter i2c-0: command = 2
i2c_adapter i2c-0: size = I2C_SMBUS_WORD_DATA
The log file shows that the tiny_access function was
called three times. The first command wanted to read a word of data
from register 0 out of the device with the address 0048. The second and
third reads asked for register 3 and register 2 from the same device.
The commands match up with the following code from the
drivers/i2c/chips/lm75.c file in the
lm75_update_client function:
data->temp_input = lm75_read_value(client,
LM75_REG_TEMP);
data->temp_max = lm75_read_value(client,
LM75_REG_TEMP_OS);
data->temp_hyst = lm75_read_value(client,
LM75_REG_TEMP_HYST);
The lm75_read_value function in that same file
contains the following code:
/* All registers are word-sized, except for the
configuration register. LM75 uses a high-byte
first convention, which is exactly opposite to
the usual practice. */
static int lm75_read_value(struct i2c_client
*client, u8 reg)
{
if (reg == LM75_REG_CONF)
return i2c_smbus_read_byte_data(client,
reg);
else
return swap_bytes(
i2c_smbus_read_word_data(client,
reg));
}
Therefore, when the lm75 driver wants to read the value of
the max temperature, it calls the lm75_read_value
function with the register number, which then calls the I2C core
function i2c_smbus_read_word_data. That I2C core
function looks up on which I2C bus the client device is, and then it calls
the I2C algorithm associated with that specific I2C bus to do the data
transfer. This is the method, then, by which our tiny_i2c_adap driver is
asked to complete the transfer.
If this same sysfs file is written to, the lm75
driver asks the tiny_i2c_adap driver to write some
data to a specific address on the I2C bus in the same way the read was
requested. This request also is shown in the syslog:
$ echo 300 > /sys/devices/legacy/i2c-0/0-0048/temp_max
$ dmesg
i2c_adapter i2c-0: tiny_access was called with the following parameters:
i2c_adapter i2c-0: addr = 0048
i2c_adapter i2c-0: flags = 0000
i2c_adapter i2c-0: read_write = write
i2c_adapter i2c-0: command = 3
i2c_adapter i2c-0: size = I2C_SMBUS_WORD_DATA
i2c_adapter i2c-0: data = 8000
Conclusion
This month we covered the basics of the I2C driver subsystem and explained
how to write a simple I2C bus and I2C algorithm driver that work
with any existing I2C client driver. The complete driver, dmn-09-i2c-adap.c,
is available from the Linux Journal FTP site at
ftp.ssc.com/pub/lj/listings/issue116/7136.tgz
.
In Part II, we will cover how to
write an I2C chip driver.
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
.
__________________________
hr {border: solid 1px #ccc}
.small {font-size: .8em}
Special Magazine Offer -- Free Gift with Subscription
Receive a free digital copy of Linux Journal's System Administration Special Edition as well as instant online access to current and past issues.
CLICK HERE for offer
Linux Journal: delivering readers the advice and inspiration they need to get the most out of their Linux systems since 1994.
Printer-friendly version
![]()
Delicious
![]()
Digg
![]()
Reddit
![]()
Newsvine
![]()
Technorati
Comment viewing options
Flat list - collapsedFlat list - expandedThreaded list - collapsedThreaded list - expanded
Date - newest firstDate - oldest first
10 comments per page30 comments per page50 comments per page70 comments per page90 comments per page150 comments per page200 comments per page250 comments per page300 comments per page
Select your preferred way to display the comments and click "Save settings" to activate your changes.
![]()
trying to write a driver for an audio chip
On March 5th, 2009
kamou
says:
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 ?
reply
Post new comment
Please note that comments may not a
=============================================================================
from: http://www.linuxjournal.com/article/7252
I2C Drivers, Part II
February 1st, 2004 by
Greg Kroah-Hartman
in
Software
Here's
what has to happen to read the sensors that report the temperature, fan
speed and other important system health information.
Average:
Select ratingCancel ratingPoorOkayGoodGreatAwesome
Cancel rating
Poor
Okay
Good
Great
Awesome
Your rating: None Average: 4.8 (4 votes)
In my last column [LJ, December 2003], we discussed
how I2C bus drivers and I2C
algorithm drivers work. We also described how to make a tiny dummy I2C
bus driver. This month, we discuss how an I2C chip driver
works and provide an example of one in action.
An I2C chip driver controls the process of talking to an individual I2C device
that lives on an I2C bus. I2C chip devices usually monitor
a number of different physical devices on a motherboard, such as
the different fan speeds, temperature values and voltages.
The struct i2c_driver structure describes a
I2C chip driver. This structure is defined in the
include/linux/i2c.h file. Only the following
fields are necessary to create a working chip driver:
struct module *owner; — set to the value
THIS_MODULE that allows the proper module reference
counting.
char name[I2C_NAME_SIZE]; — set to a descriptive
name of the I2C chip driver.
This value shows up in the sysfs
file name created for every I2C chip device.
unsigned int flags; — set to the value
I2C_DF_NOTIFY
in order for the chip driver to
be notified of any new I2C
devices loaded after
this driver is loaded. This
field probably will go away
soon, as almost all drivers set
this field.
int (*attach_adapter)(struct i2c_adapter *); —
called whenever a new I2C bus driver is loaded in the system.
This function is described in more detail below.
int (*detach_client)(struct i2c_client *); —
called
when the i2c_client device is to
be removed from the system. More information about this
function is provided below.
The following code is from an example I2C chip driver called
tiny_i2c_chip.c., which is available from the Linux Journal FTP site [
ftp.ssc.com/pub/lj/listings/issue118/7252.tgz
]. It shows how the
struct i2c_driver structure is set up:
static struct i2c_driver chip_driver = {
.owner = THIS_MODULE,
.name = "tiny_chip",
.flags = I2C_DF_NOTIFY,
.attach_adapter = chip_attach_adapter,
.detach_client = chip_detach_client,
};
Registering a Chip Driver
To register this I2C chip driver, the function
i2c_add_driver should be called with a
pointer to the struct i2c_driver:
static int __init tiny_init(void)
{
return i2c_add_driver(&chip_driver);
}
To unregister the I2C chip driver, the
i2c_del_driver function should be called with
the same pointer to the struct i2c_driver:
static void __exit tiny_exit(void)
{
i2c_del_driver(&chip_driver);
}
After the I2C chip driver is registered, the
attach_adapter function callback is
called when an I2C bus driver is loaded. This function checks to see if any
I2C devices are on this I2C bus to which the client driver wants to
attach. Almost all I2C chip drivers call the core I2C
function i2c_detect to determine
this. For example, the tiny_i2c_chip.c driver does this:
static int
chip_attach_adapter(struct i2c_adapter *adapter)
{
return i2c_detect(adapter, &addr_data,
chip_detect);
}
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.
If you look closely at the source code, you
cannot find the addr_data structure
anywhere. The reason for this is it is created by the
SENSORS_INSMOD_1 macro. This macro is
defined in the include/linux/i2c-sensor.h
file and is quite complicated. It sets up a static variable
called addr_data based on the number of
different types of chips that this driver supports and the
addresses at which these chips typically are present. It then
provides the ability to override these values by using module
parameters. An I2C chip driver must provide the variables
normal_i2c, normal_i2c_range, normal_isa and
normal_isa_range. These variables define the
i2c smbus and i2c isa addresses this chip driver supports.
They are an array of addresses, all terminated by either the special
value I2C_CLIENT_END or
I2C_CLIENT_ISA_END.
Usually a specific type of I2C chip shows up in
only a limited
range of addresses. The tiny_i2c_client.c
driver defines these variables as:
static unsigned short normal_i2c[] =
{ I2C_CLIENT_END };
static unsigned short normal_i2c_range[] =
{ 0x00, 0xff, I2C_CLIENT_END };
static unsigned int normal_isa[] =
{ I2C_CLIENT_ISA_END };
static unsigned int normal_isa_range[] =
{ I2C_CLIENT_ISA_END };
The normal_i2c_range variable specifies that
we can find this chip device at any I2C smbus address. This
allows us to test this driver on almost any I2C bus driver.
What to Do When the Chip Is Found
In the tiny_i2c_chip.c driver, when an I2C
chip device is found, the function
chip_detect is called by the I2C core.
This function is declared with the following parameters:
static int
chip_detect(struct i2c_adapter *adapter,
int address, int kind);
The adapter variable is the I2C adapter
structure on which this chip is located. The
address variable contains the address where
the chip was found, and the kind variable
indicates what kind of chip was found. The
kind variable usually is ignored, but some I2C chip
drivers support different kinds of I2C chips, so this variable
can be used to determine the type of chip present.
This function is responsible for creating a
struct i2c_client structure that then is
registered with the I2C core. The I2C core uses that
structure as an individual I2C chip device. To create this
structure, the chip_detect function does the
following:
struct i2c_client *new_client = NULL;
struct chip_data *data = NULL;
int err = 0;
new_client = kmalloc(sizeof(*new_client),
GFP_KERNEL);
if (!new_client) {
err = -ENOMEM;
goto error;
}
memset(new_client, 0x00, sizeof(*new_client));
data = kmalloc(sizeof(*data), GFP_KERNEL);
if (!data) {
err = -ENOMEM;
goto error;
}
memset(data, 0x00, sizeof(*data));
i2c_set_clientdata(new_client, data);
new_client->addr = address;
new_client->adapter = adapter;
new_client->driver = &chip_driver;
new_client->flags = 0;
strncpy(new_client->name, "tiny_chip",
I2C_NAME_SIZE);
First, the struct i2c_client structure and a
separate local data structure (called
struct chip_data) are created and initialized
to zero. It is important that the i2c_client structure is
initialized to zero, as the lower levels of the kernel driver
core require this in order to work properly. After the memory
is allocated successfully, some fields in the
struct i2c_client are set to point to this
specific device and this specific driver. Notably, the
addr, adapter and driver variables must be initialized. The
name of the struct i2c_client also must be
set if it is to show up properly in the sysfs tree for this I2C
device.
After the struct i2c_client structure is
initialized, it must be registered with the I2C core. This is
done with a call to the i2c_attach_client
function:
/* Tell the I2C layer a new client has arrived */
err = i2c_attach_client(new_client);
if (err)
goto error;
When this function returns, with no errors reported, the I2C
chip device is set up properly in the kernel.
I2C and sysfs
In the 2.0, 2.2 and 2.4 kernels, the I2C code would place the
I2C chip devices in the /proc/bus/i2c directory. In the 2.6
kernel, all I2C chip devices and adapters show up in the sysfs
filesystem. I2C chip devices can be found at
/sys/bus/i2c/devices, listed by their adapter
address and chip address. For example, the tiny_i2c_chip
driver loaded on a machine might produce the following sysfs
tree structure:
$ tree /sys/bus/i2c/
/sys/bus/i2c/
|-- devices
| |-- 0-0009 -> ../../../devices/pci0000:00/0000:00:06.0/i2c-0/0-0009
| |-- 0-000a -> ../../../devices/pci0000:00/0000:00:06.0/i2c-0/0-000a
| |-- 0-000b -> ../../../devices/pci0000:00/0000:00:06.0/i2c-0/0-000b
| `-- 0-0019 -> ../../../devices/pci0000:00/0000:00:06.0/i2c-0/0-0019
`-- drivers
|-- i2c_adapter
`-- tiny_chip
|-- 0-0009 -> ../../../../devices/pci0000:00/0000:00:06.0/i2c-0/0-0009
|-- 0-000a -> ../../../../devices/pci0000:00/0000:00:06.0/i2c-0/0-000a
|-- 0-000b -> ../../../../devices/pci0000:00/0000:00:06.0/i2c-0/0-000b
`-- 0-0019 -> ../../../../devices/pci0000:00/0000:00:06.0/i2c-0/0-0019
This shows four different I2C chip devices, all controlled by the
same tiny_chip driver. The controlling
driver can be located by looking at the devices in the
/sys/bus/i2c/drivers directory or by looking
in the directory of the chip device itself and reading the
name file:
$ cat /sys/devices/pci0000\:00/0000\:00\:06.0/i2c-0/0-0009/name
tiny_chip
All I2C chip drivers export the different sensor values through
sysfs files within the I2C chip device directory. These filenames are
standardized, along with the units in which the values are
expressed, and are documented within the kernel tree in the
file Documentation/i2c/sysfs-interface (Table 1).
Table 1. Sensor Values Exported through sysfs Files
temp_max[1-3]Temperature max value.
Fixed point value in form XXXXX and should be divided by
1,000 to get degrees Celsius.
Read/Write value.temp_min[1-3]Temperature min or hysteresis value.
Fixed point value in form XXXXX and should be divided by
1,000 to get degrees Celsius. This is preferably a
hysteresis value, reported as an absolute temperature,
not a delta from the max value. Read/Write value.temp_input[1-3]Temperature input value. Read-only value.
As the information in Table 1 shows, there is only one value per file.
All files are readable and some can be written to by
users with the proper privileges.
The tiny_i2c_chip.c driver emulates an I2C
chip device that can report temperature values. It creates the
files, temp_max1,
temp_min1 and temp_input1
in sysfs. The values it returns when these files are read
from is incremented every time the file is read to show how to
access different unique chip values.
In order to create a file in sysfs, the
DEVICE_ATTR macro is used:
static DEVICE_ATTR(temp_max, S_IWUSR | S_IRUGO,
show_temp_max, set_temp_max);
static DEVICE_ATTR(temp_min, S_IWUSR | S_IRUGO,
show_temp_hyst, set_temp_hyst);
static DEVICE_ATTR(temp_input, S_IRUGO,
show_temp_input, NULL);
This macro creates a structure that then is passed to the
function device_create_file at the end of the
chip_detect function:
/* Register sysfs files */
device_create_file(&new_client->dev,
&dev_attr_temp_max);
device_create_file(&new_client->dev,
&dev_attr_temp_min);
device_create_file(&new_client->dev,
&dev_attr_temp_input);
That call creates the sysfs files for the device:
/sys/devices/pci0000:00/0000:00:06.0/i2c-0/0-0009
|-- detach_state
|-- name
|-- power
| `-- state
|-- temp_input
|-- temp_max
`-- temp_min
The file name is created by the I2C core, and
the files detach_state and
power/state are created by the driver core.
But, let's go back to the DEVICE_ATTR macro. That
macro wants to know the name of the file to be created, the mode
of the file to be created, the name of the function to be called
when the file is read from and the name of the function to be
called when the file is written to. For the file
temp_max, this declaration was:
static DEVICE_ATTR(temp_max, S_IWUSR | S_IRUGO,
show_temp_max, set_temp_max);
The function called when the file is read from is
show_temp_max. This is defined, as are many
sysfs files, with another macro that creates a function:
#define show(value) \
static ssize_t \
show_##value(struct device *dev, char *buf) \
{ \
struct i2c_client *client = to_i2c_client(dev);\
struct chip_data *data = \
i2c_get_clientdata(client); \
\
chip_update_client(client); \
return sprintf(buf, "%d\n", data->value); \
}
show(temp_max);
show(temp_hyst);
show(temp_input);
The reason this function is created with a macro is that it is
quite simple to create other sysfs files that do almost the same
thing, with different names and that read from different variables,
without having to duplicate code. This single macro creates
three different functions to read from three different
variables from the struct chip_data
structure.
In this function, the struct device * is
converted into a struct i2c_client *. Then
the private struct chip_data * is obtained
from the struct i2c_client *. After that the
chip data is updated with a call to
chip_update_client. From there, the variable
that has been asked for is printed into a buffer and returned to
the driver core, which then returns it to the user:
$ cat /sys/devices/pci0000:00/0000:00:06.0/i2c-0/0-0009/temp_input
1
The chip_update_client increments all values
by one every time it is called:
static void
chip_update_client(struct i2c_client *client)
{
struct chip_data *data =
i2c_get_clientdata(client);
down(&data->update_lock);
dev_dbg(&client->dev, "%s\n", __FUNCTION__);
++data->temp_input;
++data->temp_max;
++data->temp_hyst;
data->last_updated = jiffies;
data->valid = 1;
up(&data->update_lock);
}
So, all subsequent requests for this value are different:
$ cat /sys/devices/pci0000:00/0000:00:06.0/i2c-0/0-0009/temp_input
2
$ cat /sys/devices/pci0000:00/0000:00:06.0/i2c-0/0-0009/temp_input
3
The set_temp_max function also is created
from a macro to allow variables to be written to:
#define set(value, reg) \
static ssize_t \
set_##value(struct device *dev, \
const char *buf, size_t count) \
{ \
struct i2c_client *client = to_i2c_client(dev);\
struct chip_data *data = \
i2c_get_clientdata(client); \
int temp = simple_strtoul(buf, NULL, 10); \
\
down(&data->update_lock); \
data->value = temp; \
up(&data->update_lock); \
return count; \
}
set(temp_max, REG_TEMP_OS);
set(temp_hyst, REG_TEMP_HYST);
Just like the show functions, this function
converts the struct device * to a
struct i2c_client *, and then the private
struct chip_data * is found. The data
the user provides then is turned into a number with a call to
simple_strtoul and is saved into the
proper variable:
$ cat /sys/devices/pci0000:00/0000:00:06.0/i2c-0/0-0009/temp_max
1
$ echo 41 > /sys/devices/pci0000:00/0000:00:06.0/i2c-0/0-0009/temp_max
$ cat /sys/devices/pci0000:00/0000:00:06.0/i2c-0/0-0009/temp_max
42
Cleaning Up
When the I2C chip device is removed from the system, either
by the I2C bus driver being unloaded or by the I2C chip driver being
unloaded, the I2C core calls the
detatch_client function specified in
the struct i2c_driver structure. This usually is
a simple function, as can be seen in the example
driver's implementation:
static int chip_detach_client(struct i2c_client *client)
{
struct chip_data *data = i2c_get_clientdata(client);
int err;
err = i2c_detach_client(client);
if (err) {
dev_err(&client->dev,
"Client deregistration failed, "
"client not detached.\n");
return err;
}
kfree(client);
kfree(data);
return 0;
}
As the i2c_attach_client function was called
to register the struct i2c_client structure
with the I2C core, the i2c_detach_client
function must be called to unregister it. If that function
succeeds, the memory the driver has allocated for the I2C
device then needs to be freed before returning from the function.
This example driver does not specifically remove the sysfs files
from the sysfs core. This step is done automatically
in the driver core within the
i2c_detach_client function. But if the
author would like, the file can be removed manually by a call to
device_remove_file.
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
.
__________________________
hr {border: solid 1px #ccc}
.small {font-size: .8em}
Special Magazine Offer -- Free Gift with Subscription
Receive a free digital copy of Linux Journal's System Administration Special Edition as well as instant online access to current and past issues.
CLICK HERE for offer
Linux Journal: delivering readers the advice and inspiration they need to get the most out of their Linux systems since 1994.
Printer-friendly version
![]()
Delicious
![]()
Digg
![]()
Reddit
![]()
Newsvine
![]()
Technorati
Comment viewing options
Flat list - collapsedFlat list - expandedThreaded list - collapsedThreaded list - expanded
Date - newest firstDate - oldest first
10 comments per page30 comments per page50 comments per page70 comments per page90 comments per page150 comments per page200 comments per page250 comments per page300 comments per page
Select your preferred way to display the comments and click "Save settings" to activate your changes.
![]()
trying to write a driver for an audio chip
On March 5th, 2009
kamou
says:
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 ?
reply
Post new comment
Please note that comments may not appear immediately, so there is no need to repost your comment.
=============================================================================
from: http://i2c.wiki.kernel.org/index.php/Linux_2.6_I2C_development_FAQ
Linux 2.6 I2C development FAQ
From Linux i2c Wiki
Jump to:
navigation
,
search
This is an attempt to describe how the I2C support in Linux 2.6 is being developed.
Contents [
hide
]
Mailing list
We have set up an
i2c mailing list
.
Everything related to I2C support in Linux should be discussed there.
If you want to be involved in the development of the I2C support in
Linux, or want to help somehow, please subscribe. Note that you do not
need to be subscribed in order to post on this list.
As is usually the case for open-source development lists, the
following rules apply: no binary attachments, no large attachments, no
HTML mail, inline patches are preferred (but not mandatory), remember
that most people are contributing on their free time.
Bugs, fixes and improvements
Bugs can be reported in
bugzilla
(category Drivers, component I2C), or directly on the
i2c mailing list
.
Proposed fixes and improvements should be posted to the mailing
list, as patches against either the latest Linus' tree or the latest
linux-next tree. Some i2c drivers have a dedicated maintainer, so check
the MAINTAINERS file first and make sure to include the dedicated
maintainer in the discussion if there is one. That person is much more
likely to be able to help as he/she knows his/her driver better.
New I2C bus drivers
If you want to contribute a new I2C bus driver, please first make
sure that support doesn't exist for it yet. We don't want to maintain
two I2C bus drivers for the same hardware.
General-purpose I2C bus drivers live under drivers/i2c/busses,
documentation for these is under Documentation/i2c/busses. There is no
guide available on how to write a new I2C bus driver, so the easiest
way is to read the code of another driver (preferably for a device not
too different from yours) and do something similar in your own driver.
If your I2C bus is software-driven, you don't have to write a
full-fledged I2C bus driver. We have a generic driver (i2c-algo-bit)
for bit-banged I2C, on top of which your driver can be built quickly.
New I2C bus drivers should be posted as patches, including changes to the Kconfig and Makefile files.
New I2C chip drivers
I2C chip drivers are, in general, better handled by dedicated groups:
- RTC (real-time clock) drivers belong to the rtc subsystem
- Audio drivers belong to the sound subsystem (
ALSA project
)
- Hardware monitoring (sensors) drivers belong to the hwmon subsystem (
lm-sensors project
)
- Video drivers belong to the media subsystem (
LinuxTV project
)
- I/O expander drivers belong to the gpio subsystem
Only drivers which don't fit in any of these categories should be posted to, and discussed on, the i2c mailing list.
How to get my new driver merged?
It is highly recommended that you find someone willing to do a first
public review of your patch, just to get the most obvious problems
cleared up. That person doesn't need to be an i2c expert (although if
you can find one, even better.) As a rule of thumb, the easier you make
it for the busy kernel maintainers, the more likely they are to review
and merge your patch quickly.
Where do all the patches go?
Once a patch has been accepted, you get to wait for the merge window
of the next kernel version. The merge window lasts for 2 weeks after
the previous kernel version has been released. In the meantime, pending
i2c patches are maintained as a
patch series
using
quilt
. These patches are included in
linux-next
. This gives them some additional testing, and as a result, patches may be adjusted or even rejected if problems are reported.
When the merge window opens, the pending patch series is converted to a temporary
git
tree, from which Linus pulls. A
summary of the pulled patches
is posted to the i2c mailing list.
What about this i2c SVN repository hosted on lm-sensors.org?
That repository holds a modified version of the Linux 2.4 i2c
subsystem, which was needed to use lm-sensors on Linux 2.4. It has
nothing to do with the current i2c developments. For Linux 2.6, the
development happens directly in the Linux kernel tree, there is no
external repository.
Where do I get the i2c user-space tools (i2cdetect, i2cdump...)?
The i2c user-space tools have been part of the lm-sensors package for a long time, but they now have their own
SVN development tree and package
, surprisingly named i2c-tools.
=============================================================================
from: http://voxel.at/prj/i2c/
I²C-Bus for Linux
![]()
Hi and welcome to the I²C-Bus for Linux Homepage!
News (or olds, as you like)
I have implemented the original i2c driver that you can find now in the
Linux core, but have not been actively developing it over the last years due
to other obligations and limited time (sadly). Nevertheless, the project is very
active, as you can see in the LKML, and the lm-sensors group has taken over
development, so please ask there for chip support and other driver information.
Here
is a link to the group
and the i2c subsystem documentation page that explains the driver structure.
Intro: What's it do?
The I²C-Bus is a simple 2-wire bus that allows micro-controllers and
computers to connect to specialized IC's like videotext-decoders, DTMF generators,
and many others. There is also a wide range of other I²C-bus chips
that offer a more wide-range application like ad/da converters, switches,
digital potentiometers et. al. Most of the frame grabber and TV tuner cards
on the market use the bus, as another example.
The Software
- Finally! The driver has made it into the current development kernel:
If you download a kernel >= 2.3.34, you get it nicely integrated in the
main source tree :)
The CVS tree is of course in sync with the kernel sources, and should
only be used if you need a driver for older kernels (2.2,2.0), or if you'd
like to experiment - you'll find the latest changes there before they
are stable enough to enter the kernel.
- The CVS-Sourcetree is up - thanks to the LM-Sensors developers! You can
get the latest sources of the i2c bus driver from their cvs-Server.
For details look at their
download page!
If you want to have write access to the repository, please contact Philip
Edelbrock
phil@netroedge.com
.
What needs to be done? - TODO:
- [color="#ff8000"]New:
Rolf Offermanns
has a Terratec Radio card and needs a driver for it! If anyone volonteers
to write it, he donates a radio card - contact either me or him for it.
The Hardware
Hans Berglund
wrote the driver for the Elektor board
Bit-banging adapters: These are quite common on different adapter boards, like many frame grabber cards, and the like.
- Philips parallel port adapter The device used by Philips,
consisting of one TTL chip and some resistors to convert the
signals for the parallel port.
- PCF 8584 on EPP port A clever design developed by
Johan Van Driessche
: A PCF 8584
interface adapter sitting on an EPP port, note his additional
line drivers that result in better pulse shapes.
If you'd like to build this beast,
here's the schematic
If you have questions, here's
a word from the designer
.
- Velleman K8000
Velleman K8000
parallel port interface
- ELV parallel port adapter
Other specialized hardware includes:
- SAA7146(A) Support by Gerd Knorr
----------------------------------------------------------------------------->
In former versions of this project page, I divided adapters into two groups:
Those using the bit-banging algorithm and others, which use the PCF 8584 I²C-Bus
controller. This division is still true, but needs additions, as other hardware
types have been implemented by various people, like support for SMBus-controllers,
or for the SAAA7146.
Therefore, here's a new division into several groups that show different
application areas of adapters:
- [color="#006448"]Commercial I2C Controllers
You don't want to solder on your motherboard? Then these are for you....
- Totalphase
produces an I²C/SPI Host Adapter that connects to the USB bus and comes
with Windows and Linux software libraries. For more information have a
look at
their website
.
- [color="#006448"]Multimedia adapters
Have a look at your graphics card - I bet you find a tuner, eeprom or some other i2c-device.
- BTTV
-based boards and other cards supported by the
video4linux
developers, they are currently porting the existing code to support my
i2c modules.
- [color="#006448"]System Management
- LM-Sensors Have a look at the lm-sensors package, there are
already a lot of hardware types (i.e. motherboards) supported - go to
their
homepage
for details.
- [color="#006448"]Experimental adapters
For all the experimenters, there are several ways to get new busses to your box:
- Philips parallel port adapter The device used by Philips, consisting
of one TTL chip and some resistors to convert the signals for the parallel
port. - LM75-demoboard sent out by National Semiconductors. Here's
a patch
by
David Armstron
for this little device. The patch is against 2.4.1, but should be easily merged with other versions as well. - PCF 8584 on EPP port A clever design developed by Johan
Van Driessche: A PCF 8584 interface adapter sitting on an EPP port,
note his additional line drivers that result in better pulse shapes.
If you'd like to build this beast, here's
the schematic. You may also read some comments on the circuit: a
word from the designer.
- Pybe's PCF8584 ISA-Bus adapter:
http://www.IAE.nl/users/pybe/weather/isa8584.htm
- Hans
Berglund wrote the driver for the Elektor board - Velleman K8000 Velleman
K8000 parallel port interface - ELV parallel port adapter
This list is by no means complete - tell me if you want to see something
mentioned.
Documentation
Here you'll find some useful documents regarding the driver and the i2c-bus
in general.
- Linux-i2c mailing list: send mail to
[email=majordomo@tk.uni-linz.ac.at?body=subscribe%20linux-i2c]majordomo@tk.uni-linz.ac.at[/email]
with a line saying
subscribe linux-i2c
to sign up to the mailing list!
- Pybe Faber has written an excellent page clarifying the structure
of my driver. Thanks, Pybe!
- The
I2C-Bus Specification by Philips Semiconductors (this is a local copy) -
Victor Himpe
has his most
comprehensive FAQ online. -
Le bus I2C
- a FAQ for all the french speaking people around - I wrote an article for the German Linux
Magazin. You can read my
online version
, but
keep in mind that it covers the old version of the driver!
Links of interest
In this section, you'll all sorts of links to different places around the
world, that deal with the same topic. Just what makes Hypertext worthwile
:)
- You can also send me an e-mail if you like:
[email=vogl+i2c_at_soft.uni-linz.ac.at]Replace the _at_ in the address, please[/email]
Although the driver is GPL'ed, donation of hardware is recommended, as I
have only limited resources to test the code.
Projects
Matthias Prinke
developed a PCB-Version
of the parallel port adapter, you can get the postscript files of the layout
here
.
He also wrote a program to display text on a LCD-display over a PCF 8574
(
lcdtext-1.1.tgz
)-
- Useful newsgroups for more general electronic questions:
For other hardware-related stuff, have a look into my
bookmarks
last modified: 28 12 99
[url=javascript:f%20=%20window.open('/reWeb/re.php3?rew=4375b5cb549bc1f7&page=/prj/i2c/','reweb','menubar=false,resizable=yes,width=400,height=130');f.focus();]
![]()
Look at related sites[/url]
Projects
(up)
![]()
![]()
=============================================================================
from: www.lm-sensors.org
![]()
Search:
Wiki Navigation
Lm_sensors - Linux hardware monitoring
¶
About this project
¶
This is the home page for the effort of building and providing some
essential tools for monitoring the hardware health of Linux systems
containing hardware health monitoring hardware such as the LM78 and
LM75.
Read more here.
This ongoing project includes general libraries and hardware-specific
software. Much of the work done could not have been done without the
many knowledgable programmers who laid down the foundation.
Call to Device Manufacturers: Our efforts are now
concentrated on adding support for new devices. If you wish to send us
samples, datasheets, or project donations (hardware, software, etc.),
please drop us an
email
.
Starting points
¶
Latest news
¶
- February 28th, 2009: 3.1.0 Released! This release includes
many improvements
, in particular to libsensors and sensors-detect. Get it from the
Download
page. Check the top of the
CHANGES
file for a detailed list of user-visible changes.
- January 26th, 2009: SVN branches renamed. We
have renamed the SVN branches to better reflect their current state.
The old trunk is now known as branch lm-sensors-2.10 and is in
maintenance mode, while the old branch lm-sensors-3.0.0, where all the
development was happening, is now known as trunk. Use
svn switch
to update your local repositories.
- December 16th, 2008: 2.10.8 Released! Get it from the
Download
page. Check the top of the
CHANGES
file for a detailed list of user-visible changes. This release solves a
minor compatibility issue with kernel 2.6.28 (only affecting users of
the it87 driver.)
- October 27th, 2008: The i2c mailing list is
moving
to
kernel.org
.
- September 28th, 2008: 3.0.3 Released! This is a maintenance release with improvements to sensors-detect and pwmconfig. Get it from the
Download
page. Check the top of the
CHANGES
file for a detailed list of user-visible changes.
- July 1st, 2008: 2.10.7 Released! Get it from the
Download
page. Check the top of the
CHANGES
file for a detailed list of user-visible changes. This release solves a compatibility issue with kernel 2.6.26.
- May 18th, 2008: 3.0.2 Released! This release
adds support for virtual hardware monitoring devices, and should
prevent the hardware issues that had been reported in the past few
weeks when running sensors-detect. Upgrading is highly recommended. Get
it from the
Download
page. Check the top of the
CHANGES
file for a detailed list of user-visible changes.
- May 12th, 2008: Note to Sapphire AM2RD790 and DFI Lanparty UT 790FX owners: we have had a report that
running sensors-detect on a Sapphire AM2RD790-based system could kill the CPU
. The same problem was also reported on a
DFI Lanparty UT 790FX
, which is essentially the same motherboard. Please
read this
before running sensors-detect on these boards.
- March 6th, 2008: 2.10.6 Released! This is a maintenance release for the legacy branch. It includes all the fixes we gathered in the past 5 months. See the
CHANGES
document for details.
- January 28th, 2008: 3.0.1 Released! Check the top of the
CHANGES
file for a detailed list of user-visible changes. The most important change is certainly the fact that
libsensors no longer depends on libsysfs
. This change made the library initialization 4 times faster, amongst other benefits. Get it from the
Download
page.
Older news are
archived
.
Other projects
¶
=============================================================================
=============================================================================
=============================================================================
=============================================================================
本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/47395/showart_1889674.html |
|
免费注册
发表于 2009-04-03 15:46