本文共 43961 字,大约阅读时间需要 146 分钟。
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:
来自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 ). 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。
来源
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 135 Make sure to check the current status for your driver first: 136 137 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' pageI2C驱动的一个典型应用,读取DDR RAM上的EEPROM。
来源
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-0050Guessing 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 0x1A197C54Decoding 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 0xF4040DCDNumber 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 }转载地址:http://dvoqj.baihongyu.com/