linux下I2C驱动

linux下I2C驱动（－）

by good02xaut

最近的一段时间，总结一下linux下开发I2C设备驱动的要点。内容随想，没有多加整理。

I2C协议规定了主机和从机的概念，在驱动中采用的多是适配器（主机）和设备(从机）。

首先，i2c规定

Bus -> Algorithm 算法
Adapter 适配器
Device -> Driver
Client 从机设备

1。适配器是不是设备？

从总线结构上看，adapter提供的是一种虚拟总线，既可以作为设备看待，又可以不作为设备看待。举例说明：

s3c2410处理内部含有I2C控制器，因此可以提供I2C BUS。

I2C－controller在硬件的构造上是一个独立的设备，可以完成I2C的总线操作。然而换个角度，当BUS上没有从设备时，I2C-controller是虚无存在的。因此，总线从计算机体系结构上看，是虚拟的概念，只有总线上挂载设备后，总线的存在才有意义。

针对linux编写驱动时，adapter需要/dev下面的设备节点嘛?通常“不”！

adapter驱动的任务是提供bus支持，而不是针对某一个具体设备，所以完全没有必要提供设备节点。

当在I2c bus上挂载24c02 eeprom后，可以通过eeprom的驱动提供的/dev/设备节点访问。

有时候，为了方便调试，或者在设备驱动没有编写情况下访问设备，那么就必须提供adapter设备节点。

adapter驱动由于没有提供register_char节点的功能，因此，这部分需要drivers/i2c/i2c-dev.c完成。

i2c-dev.c提供了一个虚拟设备节点，也就是adapter的节点。主设备号89

2。适配器的算法

适配器为什么采用算法，我不清楚。但是既然有了这个概念，在编写驱动时，就要分清楚了。

内核提供了几种通用的算法：

Algorithm drivers
-----------------

i2c-algo-8xx: An algorithm for CPM's I2C device in Motorola 8xx processors (NOT BUILT BY DEFAULT)
i2c-algo-bit: A bit-banging algorithm
i2c-algo-pcf: A PCF 8584 style algorithm
i2c-algo-ppc405: An algorithm for the I2C device in IBM 405xx processors (NOT BUILT BY DEFAULT)
这里只描述i2c-algo-bit一种，其他的自行查看代码。

i2c-algo-bit算法提供了一种通用操作。对于所有的位模拟I2c总线adapter适用。举例如下：

s3c2410处理器，虽然可以使用内部iic，但这里采用IO模拟说明算法的存在意义。

P1,P2提供了I2C总线的SDA,SCL。

通过对P1,P2的置高置低，很容易构造I2C启动信号，停止信号，发送数据等等所有的I2C功能。

这部分代码在没有算法时，需要作者编写。现在好了，有了i2c-algo-bit算法，只要提供置高置低接口，剩下的就可以有算法来完成了。

当然，对于使用了2410内部iic控制器，那算法又如何呢?算法完全可以有作者提供，而不是使用上面列举的4种。算法的内容，就是发生接收数据的代码实现部分。

4中核心的数据结构：

3.1 i2c_algorithm解析

Algorithm代表了当前I2C adapter的行为特征，必须能够描述adapter的所有传输行为。

struct i2c_algorithm {

char name[32]; //算法名称

unsigned int id; //算法ID

//master_xfer提供的是i2c_transfer实现部分。更多的I2C adapter工作于I2C总线主机模式。

int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg msgs[],

int num);

// smbus_xfer提供i2c_smbus_xfer的实现部分。只有I2C adapter工作于SMBus模式，需要提供。也就是说，I2C adapter必须指定I2C还是SMBus其中的一个。

int (*smbus_xfer) (struct i2c_adapter *adap, u16 addr,

unsigned short flags, char read_write,

u8 command, int size, union i2c_smbus_data * data);

/* 从机模式，通常adapter不会做从机*/

int (*slave_send)(struct i2c_adapter *,char*,int);

int (*slave_recv)(struct i2c_adapter *,char*,int);

/* 类似于ioctl，实现一些设定控制功能 */

int (*algo_control)(struct i2c_adapter *, unsigned int, unsigned long);

/* I2C adapter的功能函数，用户自己定义*/

u32 (*functionality) (struct i2c_adapter *);

};

基于标准I2C bus的adapter采用的algorithm必须提供master_xfer以描述总线的行为。

3.2 struct i2c_adapter解析

struct i2c_adapter {

char name[32]; /* 适配器的名字*/

unsigned int id;/* == is algo->id | hwdep.struct->id, */

/* for registered values see below */

struct i2c_algorithm *algo;/* adapter对应的算法*/

void *algo_data; /*使用标准算法时，提供算法需要的特殊函数入口*/

/* --- These may be NULL, but should increase the module use count */

void (*inc_use)(struct i2c_adapter *);

void (*dec_use)(struct i2c_adapter *);

/* --- administration stuff. */

int (*client_register)(struct i2c_client *);

int (*client_unregister)(struct i2c_client *);

void *data; /* private data for the adapter */

/* some data fields that are used by all types */

/* these data fields are readonly to the public */

/* and can be set via the i2c_ioctl call */

/* data fields that are valid for all devices */

struct semaphore lock;

unsigned int flags;/* flags specifying div. data */

struct i2c_client *clients[I2C_CLIENT_MAX]; //adapter对应的I2C bus上的client列表

int client_count;

int timeout; //超时时间

int retries; //重试次数

#ifdef CONFIG_PROC_FS

/* No need to set this when you initialize the adapter */

int inode;

#endif /* def CONFIG_PROC_FS */

}

如何给adapter选择合适的algorithm？内核已经提供了若干标准的algorithm，当我们使用标准algorithm时，必须提供algo_data入口。多数情况，adapter需要的algorithm都是自定义的，这是algo_data可以为空。

3.3 i2c_driver解析

struct i2c_driver {

char name[32]; //驱动的名称

int id; //驱动的ID

unsigned int flags; /* div., see below */

/* 寻找当前client对应的adapter是否存在。

若存在，调用i2c_attach_client更新adapter的client

*/

int (*attach_adapter)(struct i2c_adapter *);

/* tells the driver that a client is about to be deleted & gives it

* the chance to remove its private data. Also, if the client struct

* has been dynamically allocated by the driver in the function above,

* it must be freed here.

*/

int (*detach_client)(struct i2c_client *);

/* a ioctl like command that can be used to perform specific functions

* with the device.

*/

int (*command)(struct i2c_client *client,unsigned int cmd, void *arg);

/* These two are mainly used for bookkeeping & dynamic unloading of

* kernel modules. inc_use tells the driver that a client is being

* used by another module & that it should increase its ref. counter.

* dec_use is the inverse operation.

* NB: Make sure you have no circular dependencies, or else you get a

* deadlock when trying to unload the modules.

* You should use the i2c_{inc,dec}_use_client functions instead of

* calling this function directly.

*/

void (*inc_use)(struct i2c_client *client);

void (*dec_use)(struct i2c_client *client);

};

3.4 i2c_client解析

/*

* i2c_client identifies a single device (i.e. chip) that is connected to an

* i2c bus. The behaviour is defined by the routines of the driver. This

* function is mainly used for lookup & other admin. functions.

*/

struct i2c_client {

char name[32]; //client 名字

int id; //client ID

unsigned int flags; /* div., see below */

unsigned int addr; /* client地址: 7bit */

/* addresses are stored in the */

/* _LOWER_ 7 bits of this char */

/* addr: unsigned int to make lm_sensors i2c-isa adapter work

more cleanly. It does not take any more memory space, due to

alignment considerations */

struct i2c_adapter *adapter; /* client所在I2C bus对应的adapter */

struct i2c_driver *driver; /* client 使用的驱动 */

void *data; /* for the clients */

int usage_count; /* How many accesses currently */

/* to the client */

};

PC上支持器件列表，client：
来自http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/chips/SUMMARY

SUMMARY OF SUPPORTED CHIPS
2 ==========================
3
4 This is a summary of the sensor and non-sensor chips supported by this
5 package. It lists the features of each supported chip. For further
6 information on a particular driver, see the documentation in this
7 directory.
8
9 To determine what chips you have in your system, run 'sensors-detect'.
10
11 If your sensor chip is not detected by sensors-detect, please contact us
12 (see http://www.lm-sensors.org/wiki/AuthorsAndContributors). Only contact us
13 if you know for sure that your system includes a sensor chip (for
14 example if you have technical documentation mentioning it, or if the
15 BIOS setup screen presents monitoring values, or if you can get
16 hardware monitoring to work using a different OS). Do *not* contact us
17 if you have no proof that your system includes sensors. Such systems
18 tend to be rare these days, but do still exist. This is especially true
19 of laptops. If there are no sensors, there's nothing we can do.
20
21 If you contact us, please include the following in your mail:
22 - The output of (as root) 'sensors-detect'. Make sure you unloaded
23 every chip driver beforehand (check that the sensors-detect script
24 does not complain that it couldn't probe some I2C addresses on any
25 given bus).
26 - Dumps of the chips that might be hardware monitoring chips. To get
27 these, follow the following steps:
28 1* Run 'i2cdetect -l'. This will list all available I2C (or SMBus)
29 busses on your system.
30 2* For each bus listed, run (as root) 'i2cdetect N' where N is the
31 bus number.
32 3* For each bus, if there is anything in the ranges 0x20-0x2f or
33 0x48-0x4f, dump the contents of that chip with (as root)
34 'i2cdump N 0xXX', where N is the bus number and XX is the
35 responsive address. Chips in other address ranges are way less
36 likely to be hardware monitoring chips. In particular, do not
37 send dumps of addresses 0x08, 0x0c, 0x10, 0x30-0x37, 0x42, 0x44,
38 0x50-0x5f, 0x61 and 0x69. These are *not* hadware monitoring
39 chips.
40 - The part numbers of the chips on your motherboard you think are the
41 sensor chips.
42
43 -----------------------------------------------------------------------------
44
45 SUPPORTED SENSOR CHIPS
46 ----------------------
47
48 Included Sensors Controls Busses
49 ---------------------- ------- -----------
50 Driver Chips #temp #vin #fanin pwm/dac I2C ISA
51 ---------------------------------------------------------------------
52 adm1021
53 adm1021 2 - - - yes no
54 adm1021a 2 - - - yes no
55 adm1023 2 - - - yes no
56 gl523sm 2 - - - yes no
57 lm84 2 - - - yes no
58 max1617 2 - - - yes no
59 max1617a 2 - - - yes no
60 tc1068 2 - - - yes no
61 tcm1617 2 - - - yes no
62 thmc10 2 - - - yes no
63 mc1066 2 - - - yes no
64 (xeon - no detection - requires force_adm1021 parameter)
65 xeon 1 - - - yes no
66 (the following chips are detected as a max1617)
67 ne1617 2 - - - yes no
68 ne1617a 2 - - - yes no
69
70 adm1024
71 adm1024 3 6 - 1 dac yes no
72
73 adm1025
74 adm1025 2 6 - - yes no
75 ne1619 2 6 - - yes no
76
77 adm1026
78 adm1026 3 17 8 2 pwm+dac yes no
79
80 adm1031
81 adm1030 2 - 1 1 pwm yes no
82 adm1031 3 - 2 2 pwm yes no
83
84 adm9240
85 adm9240 1 6 2 1 dac yes no
86 ds1780 1 6 2 1 dac yes no
87 lm81 1 6 2 1 dac yes no
88
89 asb100
90 asb100 4 7 3 1 yes no
91
92 bmcsensors
93 bmcsensors ? ? ? - no no
94
95 ds1621
96 ds1621 1 - - - yes no
97 (the following chip is detected as a ds1621)
98 ds1625 1 - - - yes no
99
100 f71805f
101 f71805f 9 3 3 - no yes
102
103 fscher
104 fscher 3 3 3 - yes no
105
106 fscpos
107 fscpos 3 3 3 - yes no
108
109 fscscy
110 fscscy 4 3 6 - yes no
111
112 gl518sm
113 gl518sm (r00) 1 1-4 2 - yes no
114 gl518sm (r80) 1 4 2 - yes no
115
116 gl520sm
117 gl520sm 1-2 4-5 2 - yes no
118
119 it87
120 it8712 3 8 3 3 pwm yes yes
121 (the following are reported as an "it87")
122 it8705 3 8 3 3 pwm yes yes
123 sis950 3 8 3 3 pwm yes yes
124
125 lm63
126 lm63 2 - 1 1 pwm yes no
127
128 lm75
129 lm75 1 - - - yes no
130 (the following chips are detected as an lm75)
131 ds75 1 - - - yes no
132 ds1775 1 - - - yes no
133 max6625 1 - - - yes no
134 max6626 1 - - - yes no
135 tcn75 1 - - - yes no
136
137 lm78
138 lm78 1 7 3 - yes yes
139 lm78-j 1 7 3 - yes yes
140 lm79 1 7 3 - yes yes
141
142 lm80
143 lm80 1 7 2 - yes no
144
145 lm83
146 lm83 4 - - - yes no
147 lm82 2 - - - yes no
148
149 lm85
150 lm85 3 5 4 3 pwm yes no
151 adm1027 3 5 4 3 pwm yes no
152 adt7463 3 5 4 3 pwm yes no
153 emc6d100 3 8 4 3 pwm yes no
154 (emc6d101 is reported as emc6d100)
155 emc6d101 3 8 4 3 pwm yes no
156 emc6d102 3 8 4 3 pwm yes no
157
158 lm87
159 lm87 2-3 6-8 0-2 1 pwm yes no
160
161 lm90
162 lm90 2 - - - yes no
163 lm99 2 - - - yes no
164 lm86 2 - - - yes no
165 adm1032 2 - - - yes no
166 max6657 2 - - - yes no
167 (lm89 is detected as an lm99)
168 lm89 2 - - - yes no
169 (max6658 and max6659 are detected as a max6657)
170 max6658 2 - - - yes no
171 max6659 2 - - - yes no
172 (adt7461 only works in ADM1032 compatibility mode)
173 adt7461 2 - - - yes no
174
175 lm92
176 (all are reported as an "lm92")
177 lm92 1 - - - yes no
178 max6633 1 - - - yes no
179 max6634 1 - - - yes no
180 max6635 1 - - - yes no
181 (lm76 needs force parameter)
182 lm76 1 - - - yes no
183
184 max1619
185 max1619 2 - - - yes no
186
187 max6650
188 (all are reported as a "max6650")
189 max6650 - - 1 1 pwm yes no
190 max6651 - - 4 1 pwm yes no
191
192 maxilife
193 maxilife-as 5 4 3 - yes no
194 maxilife-co 5 4 3 - yes no
195 maxilife-cg 5 4 3 - yes no
196
197 mtp008
198 mtp008 3 7 3 3 pwm yes no
199
200 pc87360
201 pc87360 - - 2 2 pwm no yes (LPC)
202 pc87363 - - 2 2 pwm no yes (LPC)
203 pc87364 - - 3 3 pwm no yes (LPC)
204 pc87365 2 11 3 3 pwm no yes (LPC)
205 pc87366 3-4 11 3 3 pwm no yes (LPC)
206
207 sis5595
208 sis5595 0-1 4-5 2 - no yes
209
210 smartbatt
211 smartbatt 1 1 - - yes no
212
213 smsc47m1
214 (all are reported as a "smsc47m1")
215 smsc47b27x - - 2 2 no yes (LPC)
216 smsc47m10x - - 2 2 no yes (LPC)
217 smsc47m112 - - 2 2 no yes (LPC)
218 smsc47m13x - - 2 2 no yes (LPC)
219 smsc47m14x - - 2 2 no yes (LPC)
220 smsc47m15x - - 2 2 no yes (LPC)
221 smsc47m192 - - 2 2 no yes (LPC)
222 smsc47m997 - - 2 2 no yes (LPC)
223
224 thmc50
225 adm1022 3 2 - 1 dac yes no
226 thmc50 3 2 - 1 dac yes no
227
228 via686a
229 via686a 3 5 2 - no yes
230 vt8231 3 5 2 - no yes
231
232 vt1211
233 vt1211 2-7 1-6 2 2 no yes (LPC)
234
235 vt8231
236 vt8231 2-7 2-7 2 2 no yes
237
238 w83627hf
239 w83627hf 3 9 3 2 pwm no yes (LPC)
240 w83627thf 3 7 3 3 dac no yes (LPC)
241 w83637hf 3 7 2 3 pwm no yes (LPC)
242 w83687thf 3 7 3 3 pw/da no yes (LPC)
243 w83697hf 2 8 2 2 pwm no yes (LPC)
244
245 w83781d
246 as99127f 3 7 3 - yes no
247 w83781d 3 7 3 - yes yes
248 w83782d 3 9 3 2-4 pwm yes yes
249 w83783s 1-2 5-6 3 2 pwm yes no
250 w83791d 3 10 5 5 pwm yes no
251 w83627hf 3 9 3 2 pwm yes yes (LPC)
252
253 w83l785ts
254 w83l785ts 1 - - - yes no
255
256 w83792d
257 w83792d 3 9 7 3 pwm yes no
258
259 xeontemp
260 xeontemp 1 - - - yes no
261
262
263
264 SUPPORTED NON-SENSOR CHIPS
265 --------------------------
266
267 Driver Chips
268 ------ -----
269
270 bmcsensors
271 An interface to an IPMI BMC (Baseboard management controller)
272
273 bt869
274 bt869 video modulator chip
275
276 ddcmon
277 DDC-compliant monitor integrated eeproms - reads locations only
278
279 ds1307
280 real-time clock
281
282 eeprom
283 Memory SPD (serial presence detect) eeproms - reads locations only
284 Xeon scratch eeproms - reads locations only
285
286 ltc1710
287 ltc1710 two switches only
288
289 matorb
290 Matrix Orbital LCD displays
291
292 pca9540
293 2-channel I2C multiplexer
294
295 pcf8574 & pcf8574a
296 Simple eight-bit parallel I/O
297
298 pcf8591
299 Quad A/D + one D/A
300
301 saa1064
302 4-digit LED-driver
303
304 smbus-arp
305 An SMBus 2.0 ARP client
306
307
308 -----------------------------------------------------------------------------
309
310 COMPANY ID LIST
311 ---------------
312
313 Many SMBus chips have a company ID at location 0x3E or 0xFE.
314
315 Here is a partial list.
316 This may help identify a chip after doing a 'i2cdump [bus] [address]'.
317
318 0x00 National (on LM84)
319 0x01 National
320 0x12C3 Asus (at 0x4F)
321 0x1934 Fintek (at 0x5D-0x5E)
322 0x23 Analog Devices
323 0x41 Analog Devices (also at 0x16)
324 0x49 TI
325 0x4D Maxim
326 0x54 On Semi
327 0x54 Microchip (at 0x7)
328 0x5C SMSC
329 0x5D SMSC
330 0x55 SMSC
331 0x5CA3 Winbond (at 0x4F)
332 0x61 Andigilog
333 0x90 ITE (at 0x58)
334 0xA1 Philips (at 0x05 too)
335 0xA3 Winbond (at 0x4F)
336 0xAC Myson (at 0x58)
337 0xC3 Asus (at 0x4F)
338 0xDA Dallas
339
340 [A-Z]{3} at 0x00-0x02: Fujitsu-Siemens
341
342
343 ------------------
344 Copyright (c) 2001-2005 The lm_sensors group

如何编写一个linux的I2C驱动，包括adapter和client。

来源http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/developers/new_drivers

1 These are the steps you should follow to write a new driver and
2 submit it to us so that it will be applied cleanly to our package.
3 See at the bottom for adding new chip support to an existing driver.
4
5 Don't be intimidated by the list, it's just here so we don't
6 forget anything.
7 We are more than happy to help you with any part of the process.
8
9 There are two types of drivers, chip and bus.
10 Steps which apply to only one type of driver are noted.
11
12 These instructions are for 2.4-kernel-compatible drivers.
13 If you wish to write a driver for 2.6 only, not all of the following
14 steps apply.
15
16 ---------------------------------------------------------------------
17
18 * Check our "New Drivers" page for status!!
19
20 * Contact us.
21 You are of course free to write your own drivers, but it is smart to
22 check first nobody else is already working on it, in case the
23 New Drivers page is out of date.
24 Tell us it's OK to put your name on the "New Drivers" page.
25
26 * Consider subscribing to the mailing list.
27
28 * Check out our latest code from SVN.
29 You should use this as a base for your development.
30 See instructions on our download page.
31
32 * Write the new driver.
33 If you write a driver for a device that is similar to one we already
34 support, use the other device driver as a template. If you don't know
35 which one to use, either ask us or use the following defaults.
36 For a chip driver, use lm78.c as template. For an SMBus-only adapter,
37 use i2c-piix4.c. Use i2c-via.c for an I2C-level adapter ('bit banger').
38 Usually, we make all prefixes start with the driver name. This is not
39 really necessary, as these symbols will not be exported anyway. But by
40 doing this, you are sure you do not shadow any global kernel names.
41
42 * A quick note about conversions. The conversions which are specified
43 in the sensor chip datasheet and which *cannot* vary from one board to
44 the next are performed by the driver. If other conversions are
45 necessary, they are performed in user-space.
46
47 * Meet Kernel coding standards. 良好的内核编码规则
48 See Documentation/CodingStyle in the kernel source.
49 Be sure and use 8 column tabs.
50 Also, please do not use // comments.
51 Also, please do not go past column 80.
52 Also, please use C99 struct initializers {.foo = blat}
53 Please do this _before_ you check in your driver.
54
55 * Meet /proc naming standards in the ctl_table (for chip drivers only).
56 See doc/developers/proc for information. Please do not deviate from
57 this without discussion.
58
59 * Add the driver to the Module.mk (the makefile).
60 Usually, you can just add it to KERNEL{CHIPS,DRIVERS}TARGETS in the
61 Module.mk file in the directory itself. Put it at the beginning,
62 where the comment says to put drivers NOT included in mkpatch.
63
64 * Make sure it compiles cleanly.
65 Check compilation with 'make DEBUG=1' if you use debugging
66 information. Remember, things put between #ifdef DEBUG #endif may never
67 stop the driver from functioning; they should just output additional
68 information.
69
70 * Check for external symbols.
71 'nm --extern --defined' should only output symbols starting with __module,
72 cleanup_module, init_module and some kernel versioning symbols. Mark all
73 other symbols as static in your source file.
74
75 * Test the module.
76 Test with a recent 2.4 kernel.
77 For bus drivers, use i2cdetect and i2cdump. For i2cdump, test all supported
78 bus access modes (see i2cdump man page).
79 For chip drivers, cat all files in applicable /proc or /sys directory
80 and check for problems. Write all supported settings.
81 Check ALARM indications.
82
83 * Add detection information to prog/detect/sensors-detect.
84 This is a perl script that automatically detects what chips and adapters
85 are present. Contact us if you need help.
86
87 * Add chip information to lib/chips.{c,h} (for chip drivers only).
88 Until you have done this, the chip will be invisible for user-level
89 programs which use libsensors. Use standard names in lib/chips.c;
90 see also the comments in etc/sensors.conf.eg for help.
91 Contact us if you need more assistance.
92
93 * Be sure that SYSCTL and ALARM definitions in the driver are bracketed
94 by the special comments so that the kernel/include/sensors.h
95 file, which is generated automatically, contains your definitions.
96 (for chip drivers only)
97
98 * Add a procedure to prog/sensors/chips.[ch] (for chip drivers only).
99 This is a function specific for your driver that
100 makes the included 'sensors' program pretty-print your chip information.
101
102 * Add an line for the procedure in the matches[] table in
103 prog/sensors/main.c (for chip drivers only).
104 This tells sensors to call your new procedure when the chip name matches.
105
106 * Add entries to etc/sensors.conf.eg (for chip drivers only).
107 If needed, you can set defaults here.
108
109 * Test the userspace apps (sensors-detect and sensors).
110 Test setting limits with sensors -s.
111
112 * Add the name of the device to the README file.
113
114 * Add your name to the CONTRIBUTORS file.
115
116 * Add entries to the CHANGES file. Please keep in alphabetical order.
117
118 * Write a doc/chips/xxx or doc/busses/xxx file.
119
120 * Add entry to doc/chips/SUMMARY (for chip drivers only).
121
122 * Clearly specify licensing and copyright.
123 Make sure the GPL boilerplate and your name
124 (or if applicable your company's name) is at the top of the
125 new driver so we know you are giving it to us under the GPL.
126
127 * Submit the changes to us.
128 Do a 'svn update' to get in sync (things will have changed since
129 you started), then submit the changes to us as a patch against SVN.
130
131 * If you want to have your driver integrated to Linux 2.6, you have to
132 port your driver to the new sysfs interface. Once done and preferably
133 after testing, submit a patch to our mailing list: see
134 http://www.lm-sensors.org/wiki/AuthorsAndContributors
135 Make sure to check the current status for your driver first:
136 http://www.lm-sensors.org/wiki/Kernel2.6
137 http://www.lm-sensors.org/wiki/Devices
138
139 ---------------------------------------------------------------------
140 Checklist for us to do on the webpage:
141
142 * Add entry to 'supported drivers' page
143
144 * Update entry on 'new drivers' page
145
146 ---------------------------------------------------------------------
147 Checklist for mkpatch support, after the driver is tested and stable:
148
149 * Add .c file to mkpatch/FILES.
150
151 * Add makefile entry in mkpatch/mkpatch.pl (2 places - old and new formats).
152 (don't bother with old format, obsolete)
153
154 * Add config help to mkpatch/mkpatch.pl.
155
156 * Add config entry to mkpatch/Config.in (chip drivers only)
157
158 * Add config entry in mkpatch/mkpatch.pl (bus drivers only)
159
160 * Move .o reference in kernel/[chips,busses]/Module.mk
161 from first to second section.
162
163
164 ---------------------------------------------------------------------
165 Checklist for _adding_ support for a chip to an _existing_ driver:
166
167 * Make the changes to the driver itself.
168
169 * Add detection information to prog/detect/sensors-detect.
170
171 * Add a strncmp() call for the new prefix in prog/sensors/main.c
172 (chip drivers only).
173
174 * Add entries for the new prefix to etc/sensors.conf.eg (chip drivers only).
175
176 * Update config help in mkpatch/mkpatch.pl.
177
178 * Update config entry in mkpatch/Config.in (chip drivers only)
179
180 * Update config entry in mkpatch/mkpatch.pl (bus drivers only)
181
182 * Update doc/[chips,busses]/xxx file
183
184 * Update doc/chips/SUMMARY file (chip drivers only)
185
186 * Update list in README
187
188 * Submit the changes as a patch or check them in
189
190 * Update entry on 'new drivers' page

I2C驱动的一个典型应用，读取DDR RAM上的EEPROM。

来源http://www.lm-sensors.org/wiki/decode-dimms

Memory Serial Presence Detect Decoder

By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner,
Jean Delvare and others
Version 2.10.1
Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/1-0050

Guessing DIMM is in bank 1
SPD EEPROM Information
EEPROM Checksum of bytes 0-62 OK (0x98)
# of bytes written to SDRAM EEPROM 128
Total number of bytes in EEPROM 256
Fundamental Memory type DDR SDRAM
SPD Revision 0.0
Memory Characteristics
Maximum module speed 400MHz (PC3200)
Size 512 MB
tCL-tRCD-tRP-tRAS 2.5-3-3-8
Supported CAS Latencies 2.5, 2
Supported CS Latencies 0
Supported WE Latencies 1
Minimum Cycle Time (CAS 2.5) 5 ns
Maximum Access Time (CAS 2.5) 0.6 ns
Minimum Cycle Time (CAS 2) 6 ns
Maximum Access Time (CAS 2) 0.7 ns
Manufacturing Information
Manufacturer Kingston
Manufacturing Location Code 0x01
Part Number K
Manufacturing Date 0x050A
Assembly Serial Number 0x1A197C54

Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/1-0051

Guessing DIMM is in bank 2
SPD EEPROM Information
EEPROM Checksum of bytes 0-62 OK (0x26)
# of bytes written to SDRAM EEPROM 128
Total number of bytes in EEPROM 256
Fundamental Memory type DDR SDRAM
SPD Revision 1.0
Memory Characteristics
Maximum module speed 333MHz (PC2700)
Size 256 MB
tCL-tRCD-tRP-tRAS 2.5-3-3-7
Supported CAS Latencies 2.5, 2
Supported CS Latencies 0
Supported WE Latencies 1
Minimum Cycle Time (CAS 2.5) 6 ns
Maximum Access Time (CAS 2.5) 0.7 ns
Minimum Cycle Time (CAS 2) 7.5 ns
Maximum Access Time (CAS 2) 0.7 ns
Manufacturing Information
Manufacturer Samsung
Manufacturing Location Code 0x02
Part Number M3 68L3223ETN-CB3
Revision Code 0x4E45
Manufacturing Date 2005-W30
Assembly Serial Number 0xF4040DCD

Number of SDRAM DIMMs detected and decoded: 2

This is a design for version 2 of our smbus and lm_sensors module. This
2 document is Copyright (c) 1998, 1999 by Frodo Looijaard. You may freely copy and
3 distribute it, as long as you recognize me as the author, and mark any
4 changes you make as being your own, and distribute this notice with it.
5
6 Document version 1.0, 19981101.
7 1.1, 19981111.
8 1.2, 19981118.
9 1.3, 19981126.
10
11 NOTE: THIS IS BY NOW SOMEWHAT OUTDATED. SORRY.
12
13
14 Object oriented approach
15 ========================
16
17 The i2c module structs contain callback functions and data fields. In the
18 i2c module, these structures are only referenced by pointers. This makes
19 it easy to extend these structs to contain additional information or
20 callback functions. For those familiar with object oriented languages,
21 you can see the smbus and isa structures as an object extension of the i2c
22 structures.
23
24 To make this clearer, I will show in an example how this is done. Note
25 that I have simplified some things here, so this example does not
26 correspond to an actual struct found in one of the modules.
27
28 In the i2c module, you can find a struct somewhat like this:
29
30 struct i2c_adapter {
31 char name[32];
32 int (*detach_client) (struct i2c_client *);
33 struct i2c_adapter *next;
34 }
35
36 We have a plain data field (name), a call-back function which needs one
37 parameter (a pointer to a i2c_client struct), and a data field which is
38 a pointer to the next adapter.
39
40 Now we want to extend this structure. We need another data field,
41 containing a number of flags. We will call this new structure smbus_adapter.
42 A few other things change too:
43
44 struct smbus_adapter {
45 char name[32];
46 int (*detach_client) (struct smbus_client *);
47 struct smbus_adapter *next;
48 unsigned int flags;
49 }
50
51 So we copy all existing fields. The next field still points to the next
52 adapter - but it is now of type smbus_adapter, not i2c_adapter. And the
53 call-back function takes now a parameter of type pointer to smbus_client.
54 And there is a new data field, called flags.
55
56 Now examine this function definition:
57
58 int fully_detach_i2c_client (struct i2c_client * client)
59 {
60 res = 0;
61 struct i2c_adapter *current_adapter = first_adapter; /* a global var. */
62 while (current_adapter) {
63 res |= (current_adapter -> detach_client) (client);
64 current_adapter = current_adapter -> next;
65 }
66 return res;
67 }
68
69 This function detaches a client from all adapters. Nice. But now comes the
70 Big Trick(tm): we can still use this function for smbus_adapters!
71
72 int fully_detach_smbus_client (struct smbus_client * client)
73 {
74 return fully_detach_i2c_client( (struct i2c_client *) client);
75 }
76
77 All we needed here was a simple typecast. Datapointers remain datapointers,
78 so this can safely be done. And because we use call-back functions, the
79 actual function called to detach a client from a single adapter might
80 be the same, or different, depending on what function was put in
81 client->detach_client!
82
83 It gets even better. The i2c module stores internally all registered
84 adapters. But it stores pointers to the i2c_adapter struct, not the
85 structs themselves! So there is an array:
86
87 #define I2C_ADAPTER_MAX 32
88 struct i2c_adapter *adapters[I2C_ADAPTER_MAX];
89 /* this is an array of pointers to structs, not vice versa! */
90
91 So, an element of this array might in fact point to a smbus_adapter, instead
92 of an i2c_adapter! If you know this for sure, you might use a typecast and
93 access the additional fields. In the meantime, the i2c internal
94 administration remains valid.
95
96 We have to thank Simon Vogl and Gerd Knorr for the way they implemented
97 their i2c module. Any other way would have made this approach impossible,
98 and basing anything upon their module much more difficult.
99
100 Limitations
101 -----------
102
103 Extending the adapter and algorithm structures in this way is quite safe.
104 They are only allocated on places where the code knows that they are
105 'special'. Extending the driver or client structures depending on a
106 specific adapter/algorithm type is *very* *dangerous*. A driver/client
107 module would need to be aware of every special adapter/algorithm in
108 order to allocate itself! For the ISA bus, it has to be aware of this
109 anyway, so it is safe to do; on other places, think twice first!
110
111
112 Module overview
113 ===============
114
115 All in all, lots of modules will be stacked on each other. Too bad, but
116 that is the only way to cleanly implement everything. Note that in a
117 specific situation, only a few modules may need to be loaded. isa.o,
118 for example, does not depend on smbus.o (in the sense that you can load
119 sensor.o without loading smbus.o). A specific bus driver, though, will
120 depend on many of them.
121
122 Generally:
123 isa.o depends on nothing (actually, on i2c.o, to keep the code small)
124 smbus.o depends on nothing (actually, on i2c.o, to keep the code small)
125 i2c.o depends on nothing.
126
127 A non-i2c SMBus bus driver depends only on smbus.o
128 A i2c bus driver depends only on i2c.o
129
130 A sensor chip driver depends either on isa.o or smbus.o, or both.
131 A SMBus chip driver depends only on smbus.o
132 A I2C chip driver depends only on i2c.o
133
134 We may need a sensor.o module, to act as a central point for sensor
135 modules. At this moment, it seems not really necessary, but this may
136 change.
137
138 We will need an enhanced i2c-dev.o module, to add SMBus access to I2C
139 /dev entries.
140
141
142 isa.o
143 ISA bus handling.
144 Encapsulates ISA bus access within the i2c structures.
145 Unites I2C adapters and the ISA bus.
146 Defines variables isa_algorithm and isa_adapter.
147
148 smbus.o
149 Main SMBus handling.
150 Encapsulates SMBus access within the smbus structures.
151 Unites I2C adapters and SMBus hosts (like the PIIX4).
152 Emulates SMBus access on pure I2C adapters.
153 Defines variable smbus_algorithm.
154
155 piix4.o
156 SMBus adapter driver for the PIIX4 SMBus host.
157 Defines variable piix4_adapter (based on smbus_algorithm).
158
159 FOO.o
160 Adapter driver for FOO SMBus host
161 Defines variable FOO_adapter (based on smbus_algorithm).
162
163 i2c-core.o (From Simon Vogl)
164 Main i2c handling.
165
166 ????.o
167 I2C adapter driver
168 Implementing a class of I2C busses
169
170
171 A chip driver (typically defined in its own module) can be hooked on all
172 these levels:
173 * If it is a sensor chip, it should be hooked to isa.o or smbus.o
174 * A pure ISA chip should be hooked to isa.o
175 * A pure SMBus chip should be hooked to smbus.o
176 * An I2C chip should be hooked to i2c.o
177 It can be difficult to decide whether a specific chip should be hooked to
178 smbus.o or i2c.o. A good deciding question is, 'could it be connected to
179 a PIIX4?'
180
181
182 Module i2c.o
183 ============
184
185 This is Simon Vogl's i2c module (this one is different from the i2c module
186 included in kernels around 2.1.120!).
187
188 A driver
189 --------
190
191 struct i2c_driver {
192 char name[32];
193 int id;
194 unsigned int flags;
195 int (* attach_adapter) (struct i2c_adapter *);
196 int (* detach_client) (struct i2c_client *);
197 int (* command) (struct i2c_client *, unsigned int cmd, void *arg);
198 void (* inc_use) (struct i2c_client *);
199 void (* dec_use) (struct i2c_client *);
200 }
201
202 A driver tells us how we should handle a specific type of i2c chip. An
203 instance of such a chip is called a 'client'. An example would be the LM75
204 module: it would contain only one driver, which tells us how to handle the
205 LM75; but each detected LM75 would be a separate client (which would be
206 dynamically allocated).
207
208
209 A description of the above struct:
210 name: The name of this driver
211 id: A unique driver identifier
212 flags: Flags to set certain kinds of behaviour. Most notably, DF_NOTIFY
213 will notify the driver when a new i2c bus is detected, so it can
214 try to detect chips on it.
215 attach_adapter: A call-back function which is called if a new adapter (bus)
216 is found. This allows us to do our detection stuff on the new adapter,
217 and register new clients.
218 detach_client: A call-back function which is called if a specific client
219 which uses this driver should be disallocated. If a specific sensor module
220 is removed, for instance, this function would be called for each registered
221 client.
222 command: A generic call-back function to communicate in a driver-dependent
223 way with a specific client. This should only be seldom needed.
224 inc_use: Can be called to add one to an internal 'use' counter. This can be
225 used to control when it is safe to remove this module, for example.
226
227
228 A client
229 --------
230
231 struct i2c_client {
232 char name[32];
233 int id;
234 unsigned int flags;
235 unsigned char addr;
236 struct i2c_adapter *adapter;
237 struct i2c_driver *driver;
238 void *data;
239 }
240
241 A client is a specific sensor chip. Its operation is controlled by a driver
242 (which describes a type of sensor chip), and it is connected to an adapter
243 (a bus).
244
245 A description of the above struct:
246 name: The name of this client
247 id: A unique client id
248 flags: Flags to set certain kinds of behaviour (not very important)
249 addr: The client address. 10-bit addresses are a bit of a kludge right now.
250 adapter: A pointer to the adapter this client is on.
251 driver: A pointer to the driver this client uses.
252 data: Additional, client-dependent data
253
254
255 An algorithm
256 ------------
257
258 struct i2c_algorithm {
259 char name[32];
260 unsigned int id;
261 int (* master_xfer) (struct i2c_adapter *adap, struct i2c_msg msgs[],
262 int num);
263 int (* slave_send) (struct i2c_adapter *,char *, int);
264 int (* slave_recv) (struct i2c_adapter *,char *, int);
265 int (* algo_control) (struct i2c_adapter *, unsigned int, unsigned long);
266 int (* client_register) (struct i2c_client *);
267 int (* client_unregister) (struct i2c_client *);
268 }
269
270 An algorithm describes how a certain class of i2c busses can be accessed.
271
272 A description of the above struct:
273 name: The name of this algorithm
274 id: A unique algorithm id
275 master_xfer: Transfer a bunch of messages through a specific i2c bus.
276 slave_send: Send a message as if we are a slave device
277 slave_recv: Receive a message as if we are a slave device
278 client_register: Register a new client
279 client_unregister: Unregister a client
280
281
282 An adapter
283 ----------
284
285 struct i2c_adapter {
286 char name[32];
287 unsigned int id;
288 struct i2c_algorithm *algo;
289 void *data;
290 #ifdef SPINLOCK
291 spinlock_t lock;
292 unsigned long lockflags;
293 #else
294 struct semaphore lock;
295 #endif
296 unsigned int flags;
297 struct i2c_client *clients[I2C_CLIENT_MAX];
298 int client_count;
299 int timeout;
300 int retries;
301 }
302
303 An adapter is a specific i2c bus. How to access it is defined in the
304 algorithm associated with it.
305
306 A description of the above struct:
307 name: The name of this adapter
308 id: A unique adapter id
309 algo: The algorithm through which this bus must be accessed
310 data: Adapter specific data
311 lock, lockflags: To lock out simultaneous adapter access
312 flags: Modifiers for adapter operation
313 clients: All currently connected clients
314 client_count: The number of currently connected clients
315 timeout, retries: Internal variables (unimportant here).
316
317
318 Access functions
319 ----------------
320
321 All these functions are defined extern.
322
323 int i2c_master_send(struct i2c_client *,const char *, int);
324 int i2c_master_recv(struct i2c_client *,char *, int);
325 int i2c_transfer(struct i2c_adapter *,struct i2c_msg [], int num);
326
327 These function respectively send one message to a client, receive one message
328 from a client, or transmit a bunch of messages. struct i2c_msg contains
329 an i2c address to communicate with, and can both read from and write to this
330 address.
331
332
333 int i2c_slave_send(struct i2c_client *, char *, int);
334 int i2c_slave_recv(struct i2c_client *, char *, int);
335
336 Communicate with another master as if the normal master is a common slave
337 device.
338
339
340 Administration functions
341 ------------------------
342
343 int i2c_add_algorithm(struct i2c_algorithm *);
344 int i2c_del_algorithm(struct i2c_algorithm *);
345
346 The i2c_{add,del}_algorithm functions must be called whenever a new module
347 is inserted with this driver in it, by the module initialization function.
348
349
350 int i2c_add_adapter(struct i2c_adapter *);
351 int i2c_del_adapter(struct i2c_adapter *);
352
353 The i2c_{add,del}_adapter functions must be called if you have detected
354 a specific bus. It triggers driver->attach_adapter (add, for each driver
355 present) or driver->detach_client (del, for each registered client on
356 this adapter).
357
358
359 int i2c_add_driver(struct i2c_driver *);
360 int i2c_del_driver(struct i2c_driver *);
361
362 The i2c_{add,del}_driver functions must be called whenever a new module is
363 inserted with a chip driver in it, by the module initialization function.
364
365
366 int i2c_attach_client(struct i2c_client *);
367 int i2c_detach_client(struct i2c_client *);
368
369 The i2c_{attach,detach}_client functions must be called if you have detected
370 a single chip.
371
372
373 Module smbus.o
374 ==============
375
376 This module offers support for SMBus operation. An SMBus adapter can either
377 accept SMBus commands (like the PIIX4), or be in fact an I2C driver. In
378 the last case, all SMBus commands will be expressed through I2C primitives.
379 This means that any I2C adapter driver will automatically be a SMBus
380 driver.
381
382 At this point, it should be noted that there can only be one System
383 Management Bus in a given system (is this really true, by the way?). This
384 means there must be some way of selecting which of the many possible adapters
385 is in fact *the* SMBus. For now, I will ignore this problem. Later on,
386 we can add a hook somewhere in the i2c module to help us decide this.
387
388 This module consists in fact of three separate parts: first of all, it extends
389 all i2c structs to accomodate the new smbus fields. Second, it defines a
390 new algorithm (smbus_algorithm), that will be used by all non-i2c adapters.
391 Finally, it implements a new access function that sends or receives SMBus
392 commands; these are either translated into I2C commands or sent to the
393 SMBus driver.
394
395
396 A driver, client and algorithm
397 ------------------------------
398
399 We will not need to extend i2c_driver, i2c_client or i2c_adapter. This means
400 that struct smbus_driver is exactly the same as struct i2c_driver, and
401 struct smbus_client is the same as struct i2c_client, and smbus_adapter is
402 the same as struct i2c_adapter. We *will* define the smbus_* variants, and
403 use them within this module, so it should be easy to extend them after all.
404
405 Note that at this moment, 10 bit SMBus addresses seem to be only
406 partially supported by the i2c module. We will ignore this issue for
407 now.
408
409
410 An adapter
411 ------------
412
413 struct smbus_adapter {
414 char name[32];
415 unsigned int id;
416 struct smbus_algorithm *algo;
417 void *data;
418 #ifdef SPINLOCK
419 spinlock_t lock;
420 unsigned long lockflags;
421 #else
422 struct semaphore lock;
423 #endif
424 unsigned int flags;
425 struct smbus_client *clients[I2C_CLIENT_MAX];
426 int client_count;
427 int timeout;
428 int retries;
429
430 /* Here ended i2c_adapter */
431 s32 (* smbus_access) (__u8 addr, char read_write,
432 __u8 command, int size, union smbus_data * data);
433 }
434
435 A description of the above struct:
436 smbus_access: A function to access the SMBus. It is only used for non-i2c
437 smbus adapters.
438
439
440 Access functions
441 ----------------
442
443 All these functions are defined extern.
444
445 The i2c access function should not be used within SMBus chip drivers, as
446 they might not be defined (for the PIIX4, for example). Instead, use the
447 following general access function, or one of the easier functions based
448 on it:
449
450 int smbus_access (struct i2c_adapter *, __u8 addr, char read_write,
451 __u8 command, int size, union smbus_data * data);
452
453 There are specific SMBus registration functions too, like the i2c ones.
454 They are fully compatiable with each other; just substitute 'smbus' for
455 'i2c' everywhere in the i2c description.
456
457 int i2c_is_smbus_client(struct i2c_client *);
458 int i2c_is_smbus_adapter(struct i2c_adapter *);
459
460 Decide whether this client, or adapter, is (on) a non-I2C SMBus. Usually
461 not needed, but it is nice anyway to be able to decide this.
462
463
464 Module isa.o
465 ============
466
467 This module implements a new algorithm and a specific adapter for the
468 (single) ISA bus in your computer. This makes writing drivers for chips
469 that can be both on ISA and SMBus much easier.
470
471 Note that this module does *not* in any way depend on smbus.o (previous
472 versions of this document still assumed it would be build upon it; this
473 is no longer true).
474
475
476 A driver, adapter or algorithm
477 ------------------------------
478
479 We will not need to extend i2c_driver, i2c_adapter or i2c_algorithm. This
480 means that struct isa_driver is exactly the same as struct i2c_driver,
481 struct isa_adapter is the same as struct i2c_adapter and struct isa_algorithm
482 is the same as struct isa_driver. We *will* define the isa_* variants, and
483 use them within this module, so it should be easy to extend them after all.
484
485
486 A client
487 --------
488
489 struct isa_client {
490 char name[32];
491 int id;
492 unsigned int flags;
493 unsigned char addr;
494 struct isa_adapter *adapter;
495 struct isa_driver *driver;
496 void *data;
497
498 unsigned int isa_addr;
499 }
500
501 A client is a specific sensor chip. Its operation is controlled by a driver
502 (which describes a type of sensor chip), and it is connected to an adapter
503 (a bus, the (single) ISA bus here).
504
505 A description of the above struct:
506 isa_addr: ISA addresses do not fit in the i2c-compatible addr field, so
507 we needed a new field.
508
509
510 Access functions
511 ----------------
512
513 All these functions are defined extern.
514
515 In case of the ISA bus, the master_xfer, slave_send and slave_recv hooks
516 will be NULL, because these functions make no sense. It is regrettably
517 not easy to create an access abstraction in which both ISA bus access
518 and SMBus access are united. See below for examples how you can solve
519 this problem.
520
521 The most imporant additional access function:
522
523 int i2c_is_isa_client(struct i2c_client *);
524 int i2c_is_isa_adapter(struct i2c_adapter *);
525
526 Decide whether this client, or adapter, is (on) the ISA bus. This is
527 important, because it determines whether we can use the SMBus access
528 routines.
529
530 As an example, I will here implement our old LM78 access function:
531
532 /* The SMBus locks itself, but ISA access must be locked explicitly!
533 We ignore the LM78 BUSY flag at this moment - it could lead to deadlocks,
534 would slow down the LM78 access and should not be necessary.
535 There are some ugly typecasts here, but the good new is - they should
536 nowhere else be necessary! */
537 int lm78_read_value(struct i2c_client *client, u8 reg)
538 {
539 int res;
540 if (i2c_is_isa_client(client)) {
541 down((struct semaphore *) (client->data));
542 outb_p(reg,(((struct isa_client *) client)->isa_addr) +
543 LM78_ADDR_REG_OFFSET);
544 res = inb_p((((struct isa_client *) client)->isa_addr) +
545 LM78_DATA_REG_OFFSET);
546 up((struct semaphore *) (client->data));
547 return res;
548 } else
549 return smbus_read_byte_data(client->adapter,client->addr, reg);
550 }