Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | This is a small guide for those who want to write kernel drivers for I2C |
| 2 | or SMBus devices. |
| 3 | |
| 4 | To set up a driver, you need to do several things. Some are optional, and |
| 5 | some things can be done slightly or completely different. Use this as a |
| 6 | guide, not as a rule book! |
| 7 | |
| 8 | |
| 9 | General remarks |
| 10 | =============== |
| 11 | |
| 12 | Try to keep the kernel namespace as clean as possible. The best way to |
| 13 | do this is to use a unique prefix for all global symbols. This is |
| 14 | especially important for exported symbols, but it is a good idea to do |
| 15 | it for non-exported symbols too. We will use the prefix `foo_' in this |
| 16 | tutorial, and `FOO_' for preprocessor variables. |
| 17 | |
| 18 | |
| 19 | The driver structure |
| 20 | ==================== |
| 21 | |
| 22 | Usually, you will implement a single driver structure, and instantiate |
| 23 | all clients from it. Remember, a driver structure contains general access |
| 24 | routines, a client structure specific information like the actual I2C |
| 25 | address. |
| 26 | |
| 27 | static struct i2c_driver foo_driver = { |
| 28 | .owner = THIS_MODULE, |
| 29 | .name = "Foo version 2.3 driver", |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 30 | .flags = I2C_DF_NOTIFY, |
| 31 | .attach_adapter = &foo_attach_adapter, |
| 32 | .detach_client = &foo_detach_client, |
| 33 | .command = &foo_command /* may be NULL */ |
| 34 | } |
| 35 | |
| 36 | The name can be chosen freely, and may be upto 40 characters long. Please |
| 37 | use something descriptive here. |
| 38 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 39 | Don't worry about the flags field; just put I2C_DF_NOTIFY into it. This |
| 40 | means that your driver will be notified when new adapters are found. |
| 41 | This is almost always what you want. |
| 42 | |
| 43 | All other fields are for call-back functions which will be explained |
| 44 | below. |
| 45 | |
| 46 | There use to be two additional fields in this structure, inc_use et dec_use, |
| 47 | for module usage count, but these fields were obsoleted and removed. |
| 48 | |
| 49 | |
| 50 | Extra client data |
| 51 | ================= |
| 52 | |
| 53 | The client structure has a special `data' field that can point to any |
| 54 | structure at all. You can use this to keep client-specific data. You |
| 55 | do not always need this, but especially for `sensors' drivers, it can |
| 56 | be very useful. |
| 57 | |
| 58 | An example structure is below. |
| 59 | |
| 60 | struct foo_data { |
| 61 | struct semaphore lock; /* For ISA access in `sensors' drivers. */ |
| 62 | int sysctl_id; /* To keep the /proc directory entry for |
| 63 | `sensors' drivers. */ |
| 64 | enum chips type; /* To keep the chips type for `sensors' drivers. */ |
| 65 | |
| 66 | /* Because the i2c bus is slow, it is often useful to cache the read |
| 67 | information of a chip for some time (for example, 1 or 2 seconds). |
| 68 | It depends of course on the device whether this is really worthwhile |
| 69 | or even sensible. */ |
| 70 | struct semaphore update_lock; /* When we are reading lots of information, |
| 71 | another process should not update the |
| 72 | below information */ |
| 73 | char valid; /* != 0 if the following fields are valid. */ |
| 74 | unsigned long last_updated; /* In jiffies */ |
| 75 | /* Add the read information here too */ |
| 76 | }; |
| 77 | |
| 78 | |
| 79 | Accessing the client |
| 80 | ==================== |
| 81 | |
| 82 | Let's say we have a valid client structure. At some time, we will need |
| 83 | to gather information from the client, or write new information to the |
| 84 | client. How we will export this information to user-space is less |
| 85 | important at this moment (perhaps we do not need to do this at all for |
| 86 | some obscure clients). But we need generic reading and writing routines. |
| 87 | |
| 88 | I have found it useful to define foo_read and foo_write function for this. |
| 89 | For some cases, it will be easier to call the i2c functions directly, |
| 90 | but many chips have some kind of register-value idea that can easily |
| 91 | be encapsulated. Also, some chips have both ISA and I2C interfaces, and |
| 92 | it useful to abstract from this (only for `sensors' drivers). |
| 93 | |
| 94 | The below functions are simple examples, and should not be copied |
| 95 | literally. |
| 96 | |
| 97 | int foo_read_value(struct i2c_client *client, u8 reg) |
| 98 | { |
| 99 | if (reg < 0x10) /* byte-sized register */ |
| 100 | return i2c_smbus_read_byte_data(client,reg); |
| 101 | else /* word-sized register */ |
| 102 | return i2c_smbus_read_word_data(client,reg); |
| 103 | } |
| 104 | |
| 105 | int foo_write_value(struct i2c_client *client, u8 reg, u16 value) |
| 106 | { |
| 107 | if (reg == 0x10) /* Impossible to write - driver error! */ { |
| 108 | return -1; |
| 109 | else if (reg < 0x10) /* byte-sized register */ |
| 110 | return i2c_smbus_write_byte_data(client,reg,value); |
| 111 | else /* word-sized register */ |
| 112 | return i2c_smbus_write_word_data(client,reg,value); |
| 113 | } |
| 114 | |
| 115 | For sensors code, you may have to cope with ISA registers too. Something |
| 116 | like the below often works. Note the locking! |
| 117 | |
| 118 | int foo_read_value(struct i2c_client *client, u8 reg) |
| 119 | { |
| 120 | int res; |
| 121 | if (i2c_is_isa_client(client)) { |
| 122 | down(&(((struct foo_data *) (client->data)) -> lock)); |
| 123 | outb_p(reg,client->addr + FOO_ADDR_REG_OFFSET); |
| 124 | res = inb_p(client->addr + FOO_DATA_REG_OFFSET); |
| 125 | up(&(((struct foo_data *) (client->data)) -> lock)); |
| 126 | return res; |
| 127 | } else |
| 128 | return i2c_smbus_read_byte_data(client,reg); |
| 129 | } |
| 130 | |
| 131 | Writing is done the same way. |
| 132 | |
| 133 | |
| 134 | Probing and attaching |
| 135 | ===================== |
| 136 | |
| 137 | Most i2c devices can be present on several i2c addresses; for some this |
| 138 | is determined in hardware (by soldering some chip pins to Vcc or Ground), |
| 139 | for others this can be changed in software (by writing to specific client |
| 140 | registers). Some devices are usually on a specific address, but not always; |
| 141 | and some are even more tricky. So you will probably need to scan several |
| 142 | i2c addresses for your clients, and do some sort of detection to see |
| 143 | whether it is actually a device supported by your driver. |
| 144 | |
| 145 | To give the user a maximum of possibilities, some default module parameters |
| 146 | are defined to help determine what addresses are scanned. Several macros |
| 147 | are defined in i2c.h to help you support them, as well as a generic |
| 148 | detection algorithm. |
| 149 | |
| 150 | You do not have to use this parameter interface; but don't try to use |
Jean Delvare | 2ed2dc3 | 2005-07-31 21:42:02 +0200 | [diff] [blame^] | 151 | function i2c_probe() if you don't. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 152 | |
| 153 | NOTE: If you want to write a `sensors' driver, the interface is slightly |
| 154 | different! See below. |
| 155 | |
| 156 | |
| 157 | |
| 158 | Probing classes (i2c) |
| 159 | --------------------- |
| 160 | |
| 161 | All parameters are given as lists of unsigned 16-bit integers. Lists are |
| 162 | terminated by I2C_CLIENT_END. |
| 163 | The following lists are used internally: |
| 164 | |
| 165 | normal_i2c: filled in by the module writer. |
| 166 | A list of I2C addresses which should normally be examined. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 167 | probe: insmod parameter. |
| 168 | A list of pairs. The first value is a bus number (-1 for any I2C bus), |
| 169 | the second is the address. These addresses are also probed, as if they |
| 170 | were in the 'normal' list. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 171 | ignore: insmod parameter. |
| 172 | A list of pairs. The first value is a bus number (-1 for any I2C bus), |
| 173 | the second is the I2C address. These addresses are never probed. |
| 174 | This parameter overrules 'normal' and 'probe', but not the 'force' lists. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 175 | force: insmod parameter. |
| 176 | A list of pairs. The first value is a bus number (-1 for any I2C bus), |
| 177 | the second is the I2C address. A device is blindly assumed to be on |
| 178 | the given address, no probing is done. |
| 179 | |
Jean Delvare | b3d5496 | 2005-04-02 20:31:02 +0200 | [diff] [blame] | 180 | Fortunately, as a module writer, you just have to define the `normal_i2c' |
| 181 | parameter. The complete declaration could look like this: |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 182 | |
Jean Delvare | b3d5496 | 2005-04-02 20:31:02 +0200 | [diff] [blame] | 183 | /* Scan 0x37, and 0x48 to 0x4f */ |
| 184 | static unsigned short normal_i2c[] = { 0x37, 0x48, 0x49, 0x4a, 0x4b, 0x4c, |
| 185 | 0x4d, 0x4e, 0x4f, I2C_CLIENT_END }; |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 186 | |
| 187 | /* Magic definition of all other variables and things */ |
| 188 | I2C_CLIENT_INSMOD; |
| 189 | |
Jean Delvare | b3d5496 | 2005-04-02 20:31:02 +0200 | [diff] [blame] | 190 | Note that you *have* to call the defined variable `normal_i2c', |
| 191 | without any prefix! |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 192 | |
| 193 | |
| 194 | Probing classes (sensors) |
| 195 | ------------------------- |
| 196 | |
| 197 | If you write a `sensors' driver, you use a slightly different interface. |
Jean Delvare | 5071860 | 2005-07-20 00:02:32 +0200 | [diff] [blame] | 198 | Also, we use a enum of chip types. Don't forget to include `sensors.h'. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 199 | |
| 200 | The following lists are used internally. They are all lists of integers. |
| 201 | |
Jean Delvare | 5071860 | 2005-07-20 00:02:32 +0200 | [diff] [blame] | 202 | normal_i2c: filled in by the module writer. Terminated by I2C_CLIENT_END. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 203 | A list of I2C addresses which should normally be examined. |
Jean Delvare | 5071860 | 2005-07-20 00:02:32 +0200 | [diff] [blame] | 204 | probe: insmod parameter. Initialize this list with I2C_CLIENT_END values. |
| 205 | A list of pairs. The first value is a bus number (ANY_I2C_BUS for any |
| 206 | I2C bus), the second is the address. These addresses are also probed, |
| 207 | as if they were in the 'normal' list. |
| 208 | ignore: insmod parameter. Initialize this list with I2C_CLIENT_END values. |
| 209 | A list of pairs. The first value is a bus number (ANY_I2C_BUS for any |
| 210 | I2C bus), the second is the I2C address. These addresses are never |
| 211 | probed. This parameter overrules 'normal' and 'probe', but not the |
| 212 | 'force' lists. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 213 | |
| 214 | Also used is a list of pointers to sensors_force_data structures: |
| 215 | force_data: insmod parameters. A list, ending with an element of which |
| 216 | the force field is NULL. |
| 217 | Each element contains the type of chip and a list of pairs. |
Jean Delvare | 5071860 | 2005-07-20 00:02:32 +0200 | [diff] [blame] | 218 | The first value is a bus number (ANY_I2C_BUS for any I2C bus), the |
| 219 | second is the address. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 220 | These are automatically translated to insmod variables of the form |
| 221 | force_foo. |
| 222 | |
| 223 | So we have a generic insmod variabled `force', and chip-specific variables |
| 224 | `force_CHIPNAME'. |
| 225 | |
Jean Delvare | b3d5496 | 2005-04-02 20:31:02 +0200 | [diff] [blame] | 226 | Fortunately, as a module writer, you just have to define the `normal_i2c' |
Jean Delvare | 5071860 | 2005-07-20 00:02:32 +0200 | [diff] [blame] | 227 | parameter, and define what chip names are used. The complete declaration |
| 228 | could look like this: |
Jean Delvare | b3d5496 | 2005-04-02 20:31:02 +0200 | [diff] [blame] | 229 | /* Scan i2c addresses 0x37, and 0x48 to 0x4f */ |
| 230 | static unsigned short normal_i2c[] = { 0x37, 0x48, 0x49, 0x4a, 0x4b, 0x4c, |
| 231 | 0x4d, 0x4e, 0x4f, I2C_CLIENT_END }; |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 232 | |
| 233 | /* Define chips foo and bar, as well as all module parameters and things */ |
| 234 | SENSORS_INSMOD_2(foo,bar); |
| 235 | |
| 236 | If you have one chip, you use macro SENSORS_INSMOD_1(chip), if you have 2 |
| 237 | you use macro SENSORS_INSMOD_2(chip1,chip2), etc. If you do not want to |
| 238 | bother with chip types, you can use SENSORS_INSMOD_0. |
| 239 | |
| 240 | A enum is automatically defined as follows: |
| 241 | enum chips { any_chip, chip1, chip2, ... } |
| 242 | |
| 243 | |
| 244 | Attaching to an adapter |
| 245 | ----------------------- |
| 246 | |
| 247 | Whenever a new adapter is inserted, or for all adapters if the driver is |
| 248 | being registered, the callback attach_adapter() is called. Now is the |
| 249 | time to determine what devices are present on the adapter, and to register |
| 250 | a client for each of them. |
| 251 | |
| 252 | The attach_adapter callback is really easy: we just call the generic |
| 253 | detection function. This function will scan the bus for us, using the |
| 254 | information as defined in the lists explained above. If a device is |
| 255 | detected at a specific address, another callback is called. |
| 256 | |
| 257 | int foo_attach_adapter(struct i2c_adapter *adapter) |
| 258 | { |
| 259 | return i2c_probe(adapter,&addr_data,&foo_detect_client); |
| 260 | } |
| 261 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 262 | Remember, structure `addr_data' is defined by the macros explained above, |
| 263 | so you do not have to define it yourself. |
| 264 | |
Jean Delvare | 2ed2dc3 | 2005-07-31 21:42:02 +0200 | [diff] [blame^] | 265 | The i2c_probe function will call the foo_detect_client |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 266 | function only for those i2c addresses that actually have a device on |
| 267 | them (unless a `force' parameter was used). In addition, addresses that |
| 268 | are already in use (by some other registered client) are skipped. |
| 269 | |
| 270 | |
| 271 | The detect client function |
| 272 | -------------------------- |
| 273 | |
Jean Delvare | 2ed2dc3 | 2005-07-31 21:42:02 +0200 | [diff] [blame^] | 274 | The detect client function is called by i2c_probe. The `kind' parameter |
| 275 | contains -1 for a probed detection, 0 for a forced detection, or a positive |
| 276 | number for a forced detection with a chip type forced. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 277 | |
| 278 | Below, some things are only needed if this is a `sensors' driver. Those |
| 279 | parts are between /* SENSORS ONLY START */ and /* SENSORS ONLY END */ |
| 280 | markers. |
| 281 | |
| 282 | This function should only return an error (any value != 0) if there is |
| 283 | some reason why no more detection should be done anymore. If the |
| 284 | detection just fails for this address, return 0. |
| 285 | |
| 286 | For now, you can ignore the `flags' parameter. It is there for future use. |
| 287 | |
| 288 | int foo_detect_client(struct i2c_adapter *adapter, int address, |
| 289 | unsigned short flags, int kind) |
| 290 | { |
| 291 | int err = 0; |
| 292 | int i; |
| 293 | struct i2c_client *new_client; |
| 294 | struct foo_data *data; |
| 295 | const char *client_name = ""; /* For non-`sensors' drivers, put the real |
| 296 | name here! */ |
| 297 | |
| 298 | /* Let's see whether this adapter can support what we need. |
| 299 | Please substitute the things you need here! |
| 300 | For `sensors' drivers, add `! is_isa &&' to the if statement */ |
| 301 | if (!i2c_check_functionality(adapter,I2C_FUNC_SMBUS_WORD_DATA | |
| 302 | I2C_FUNC_SMBUS_WRITE_BYTE)) |
| 303 | goto ERROR0; |
| 304 | |
| 305 | /* SENSORS ONLY START */ |
| 306 | const char *type_name = ""; |
| 307 | int is_isa = i2c_is_isa_adapter(adapter); |
| 308 | |
Jean Delvare | 02ff982 | 2005-07-20 00:05:33 +0200 | [diff] [blame] | 309 | /* Do this only if the chip can additionally be found on the ISA bus |
| 310 | (hybrid chip). */ |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 311 | |
Jean Delvare | 02ff982 | 2005-07-20 00:05:33 +0200 | [diff] [blame] | 312 | if (is_isa) { |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 313 | |
| 314 | /* Discard immediately if this ISA range is already used */ |
| 315 | if (check_region(address,FOO_EXTENT)) |
| 316 | goto ERROR0; |
| 317 | |
| 318 | /* Probe whether there is anything on this address. |
| 319 | Some example code is below, but you will have to adapt this |
| 320 | for your own driver */ |
| 321 | |
| 322 | if (kind < 0) /* Only if no force parameter was used */ { |
| 323 | /* We may need long timeouts at least for some chips. */ |
| 324 | #define REALLY_SLOW_IO |
| 325 | i = inb_p(address + 1); |
| 326 | if (inb_p(address + 2) != i) |
| 327 | goto ERROR0; |
| 328 | if (inb_p(address + 3) != i) |
| 329 | goto ERROR0; |
| 330 | if (inb_p(address + 7) != i) |
| 331 | goto ERROR0; |
| 332 | #undef REALLY_SLOW_IO |
| 333 | |
| 334 | /* Let's just hope nothing breaks here */ |
| 335 | i = inb_p(address + 5) & 0x7f; |
| 336 | outb_p(~i & 0x7f,address+5); |
| 337 | if ((inb_p(address + 5) & 0x7f) != (~i & 0x7f)) { |
| 338 | outb_p(i,address+5); |
| 339 | return 0; |
| 340 | } |
| 341 | } |
| 342 | } |
| 343 | |
| 344 | /* SENSORS ONLY END */ |
| 345 | |
| 346 | /* OK. For now, we presume we have a valid client. We now create the |
| 347 | client structure, even though we cannot fill it completely yet. |
| 348 | But it allows us to access several i2c functions safely */ |
| 349 | |
| 350 | /* Note that we reserve some space for foo_data too. If you don't |
| 351 | need it, remove it. We do it here to help to lessen memory |
| 352 | fragmentation. */ |
| 353 | if (! (new_client = kmalloc(sizeof(struct i2c_client) + |
| 354 | sizeof(struct foo_data), |
| 355 | GFP_KERNEL))) { |
| 356 | err = -ENOMEM; |
| 357 | goto ERROR0; |
| 358 | } |
| 359 | |
| 360 | /* This is tricky, but it will set the data to the right value. */ |
| 361 | client->data = new_client + 1; |
| 362 | data = (struct foo_data *) (client->data); |
| 363 | |
| 364 | new_client->addr = address; |
| 365 | new_client->data = data; |
| 366 | new_client->adapter = adapter; |
| 367 | new_client->driver = &foo_driver; |
| 368 | new_client->flags = 0; |
| 369 | |
| 370 | /* Now, we do the remaining detection. If no `force' parameter is used. */ |
| 371 | |
| 372 | /* First, the generic detection (if any), that is skipped if any force |
| 373 | parameter was used. */ |
| 374 | if (kind < 0) { |
| 375 | /* The below is of course bogus */ |
| 376 | if (foo_read(new_client,FOO_REG_GENERIC) != FOO_GENERIC_VALUE) |
| 377 | goto ERROR1; |
| 378 | } |
| 379 | |
| 380 | /* SENSORS ONLY START */ |
| 381 | |
| 382 | /* Next, specific detection. This is especially important for `sensors' |
| 383 | devices. */ |
| 384 | |
| 385 | /* Determine the chip type. Not needed if a `force_CHIPTYPE' parameter |
| 386 | was used. */ |
| 387 | if (kind <= 0) { |
| 388 | i = foo_read(new_client,FOO_REG_CHIPTYPE); |
| 389 | if (i == FOO_TYPE_1) |
| 390 | kind = chip1; /* As defined in the enum */ |
| 391 | else if (i == FOO_TYPE_2) |
| 392 | kind = chip2; |
| 393 | else { |
| 394 | printk("foo: Ignoring 'force' parameter for unknown chip at " |
| 395 | "adapter %d, address 0x%02x\n",i2c_adapter_id(adapter),address); |
| 396 | goto ERROR1; |
| 397 | } |
| 398 | } |
| 399 | |
| 400 | /* Now set the type and chip names */ |
| 401 | if (kind == chip1) { |
| 402 | type_name = "chip1"; /* For /proc entry */ |
| 403 | client_name = "CHIP 1"; |
| 404 | } else if (kind == chip2) { |
| 405 | type_name = "chip2"; /* For /proc entry */ |
| 406 | client_name = "CHIP 2"; |
| 407 | } |
| 408 | |
| 409 | /* Reserve the ISA region */ |
| 410 | if (is_isa) |
| 411 | request_region(address,FOO_EXTENT,type_name); |
| 412 | |
| 413 | /* SENSORS ONLY END */ |
| 414 | |
| 415 | /* Fill in the remaining client fields. */ |
| 416 | strcpy(new_client->name,client_name); |
| 417 | |
| 418 | /* SENSORS ONLY BEGIN */ |
| 419 | data->type = kind; |
| 420 | /* SENSORS ONLY END */ |
| 421 | |
| 422 | data->valid = 0; /* Only if you use this field */ |
| 423 | init_MUTEX(&data->update_lock); /* Only if you use this field */ |
| 424 | |
| 425 | /* Any other initializations in data must be done here too. */ |
| 426 | |
| 427 | /* Tell the i2c layer a new client has arrived */ |
| 428 | if ((err = i2c_attach_client(new_client))) |
| 429 | goto ERROR3; |
| 430 | |
| 431 | /* SENSORS ONLY BEGIN */ |
| 432 | /* Register a new directory entry with module sensors. See below for |
| 433 | the `template' structure. */ |
| 434 | if ((i = i2c_register_entry(new_client, type_name, |
| 435 | foo_dir_table_template,THIS_MODULE)) < 0) { |
| 436 | err = i; |
| 437 | goto ERROR4; |
| 438 | } |
| 439 | data->sysctl_id = i; |
| 440 | |
| 441 | /* SENSORS ONLY END */ |
| 442 | |
| 443 | /* This function can write default values to the client registers, if |
| 444 | needed. */ |
| 445 | foo_init_client(new_client); |
| 446 | return 0; |
| 447 | |
| 448 | /* OK, this is not exactly good programming practice, usually. But it is |
| 449 | very code-efficient in this case. */ |
| 450 | |
| 451 | ERROR4: |
| 452 | i2c_detach_client(new_client); |
| 453 | ERROR3: |
| 454 | ERROR2: |
| 455 | /* SENSORS ONLY START */ |
| 456 | if (is_isa) |
| 457 | release_region(address,FOO_EXTENT); |
| 458 | /* SENSORS ONLY END */ |
| 459 | ERROR1: |
| 460 | kfree(new_client); |
| 461 | ERROR0: |
| 462 | return err; |
| 463 | } |
| 464 | |
| 465 | |
| 466 | Removing the client |
| 467 | =================== |
| 468 | |
| 469 | The detach_client call back function is called when a client should be |
| 470 | removed. It may actually fail, but only when panicking. This code is |
| 471 | much simpler than the attachment code, fortunately! |
| 472 | |
| 473 | int foo_detach_client(struct i2c_client *client) |
| 474 | { |
| 475 | int err,i; |
| 476 | |
| 477 | /* SENSORS ONLY START */ |
| 478 | /* Deregister with the `i2c-proc' module. */ |
| 479 | i2c_deregister_entry(((struct lm78_data *)(client->data))->sysctl_id); |
| 480 | /* SENSORS ONLY END */ |
| 481 | |
| 482 | /* Try to detach the client from i2c space */ |
Jean Delvare | 7bef559 | 2005-07-27 22:14:49 +0200 | [diff] [blame] | 483 | if ((err = i2c_detach_client(client))) |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 484 | return err; |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 485 | |
Jean Delvare | 02ff982 | 2005-07-20 00:05:33 +0200 | [diff] [blame] | 486 | /* HYBRID SENSORS CHIP ONLY START */ |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 487 | if i2c_is_isa_client(client) |
| 488 | release_region(client->addr,LM78_EXTENT); |
Jean Delvare | 02ff982 | 2005-07-20 00:05:33 +0200 | [diff] [blame] | 489 | /* HYBRID SENSORS CHIP ONLY END */ |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 490 | |
| 491 | kfree(client); /* Frees client data too, if allocated at the same time */ |
| 492 | return 0; |
| 493 | } |
| 494 | |
| 495 | |
| 496 | Initializing the module or kernel |
| 497 | ================================= |
| 498 | |
| 499 | When the kernel is booted, or when your foo driver module is inserted, |
| 500 | you have to do some initializing. Fortunately, just attaching (registering) |
| 501 | the driver module is usually enough. |
| 502 | |
| 503 | /* Keep track of how far we got in the initialization process. If several |
| 504 | things have to initialized, and we fail halfway, only those things |
| 505 | have to be cleaned up! */ |
| 506 | static int __initdata foo_initialized = 0; |
| 507 | |
| 508 | static int __init foo_init(void) |
| 509 | { |
| 510 | int res; |
| 511 | printk("foo version %s (%s)\n",FOO_VERSION,FOO_DATE); |
| 512 | |
| 513 | if ((res = i2c_add_driver(&foo_driver))) { |
| 514 | printk("foo: Driver registration failed, module not inserted.\n"); |
| 515 | foo_cleanup(); |
| 516 | return res; |
| 517 | } |
| 518 | foo_initialized ++; |
| 519 | return 0; |
| 520 | } |
| 521 | |
| 522 | void foo_cleanup(void) |
| 523 | { |
| 524 | if (foo_initialized == 1) { |
| 525 | if ((res = i2c_del_driver(&foo_driver))) { |
| 526 | printk("foo: Driver registration failed, module not removed.\n"); |
| 527 | return; |
| 528 | } |
| 529 | foo_initialized --; |
| 530 | } |
| 531 | } |
| 532 | |
| 533 | /* Substitute your own name and email address */ |
| 534 | MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>" |
| 535 | MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices"); |
| 536 | |
| 537 | module_init(foo_init); |
| 538 | module_exit(foo_cleanup); |
| 539 | |
| 540 | Note that some functions are marked by `__init', and some data structures |
| 541 | by `__init_data'. Hose functions and structures can be removed after |
| 542 | kernel booting (or module loading) is completed. |
| 543 | |
| 544 | Command function |
| 545 | ================ |
| 546 | |
| 547 | A generic ioctl-like function call back is supported. You will seldom |
| 548 | need this. You may even set it to NULL. |
| 549 | |
| 550 | /* No commands defined */ |
| 551 | int foo_command(struct i2c_client *client, unsigned int cmd, void *arg) |
| 552 | { |
| 553 | return 0; |
| 554 | } |
| 555 | |
| 556 | |
| 557 | Sending and receiving |
| 558 | ===================== |
| 559 | |
| 560 | If you want to communicate with your device, there are several functions |
| 561 | to do this. You can find all of them in i2c.h. |
| 562 | |
| 563 | If you can choose between plain i2c communication and SMBus level |
| 564 | communication, please use the last. All adapters understand SMBus level |
| 565 | commands, but only some of them understand plain i2c! |
| 566 | |
| 567 | |
| 568 | Plain i2c communication |
| 569 | ----------------------- |
| 570 | |
| 571 | extern int i2c_master_send(struct i2c_client *,const char* ,int); |
| 572 | extern int i2c_master_recv(struct i2c_client *,char* ,int); |
| 573 | |
| 574 | These routines read and write some bytes from/to a client. The client |
| 575 | contains the i2c address, so you do not have to include it. The second |
| 576 | parameter contains the bytes the read/write, the third the length of the |
| 577 | buffer. Returned is the actual number of bytes read/written. |
| 578 | |
| 579 | extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg, |
| 580 | int num); |
| 581 | |
| 582 | This sends a series of messages. Each message can be a read or write, |
| 583 | and they can be mixed in any way. The transactions are combined: no |
| 584 | stop bit is sent between transaction. The i2c_msg structure contains |
| 585 | for each message the client address, the number of bytes of the message |
| 586 | and the message data itself. |
| 587 | |
| 588 | You can read the file `i2c-protocol' for more information about the |
| 589 | actual i2c protocol. |
| 590 | |
| 591 | |
| 592 | SMBus communication |
| 593 | ------------------- |
| 594 | |
| 595 | extern s32 i2c_smbus_xfer (struct i2c_adapter * adapter, u16 addr, |
| 596 | unsigned short flags, |
| 597 | char read_write, u8 command, int size, |
| 598 | union i2c_smbus_data * data); |
| 599 | |
| 600 | This is the generic SMBus function. All functions below are implemented |
| 601 | in terms of it. Never use this function directly! |
| 602 | |
| 603 | |
| 604 | extern s32 i2c_smbus_write_quick(struct i2c_client * client, u8 value); |
| 605 | extern s32 i2c_smbus_read_byte(struct i2c_client * client); |
| 606 | extern s32 i2c_smbus_write_byte(struct i2c_client * client, u8 value); |
| 607 | extern s32 i2c_smbus_read_byte_data(struct i2c_client * client, u8 command); |
| 608 | extern s32 i2c_smbus_write_byte_data(struct i2c_client * client, |
| 609 | u8 command, u8 value); |
| 610 | extern s32 i2c_smbus_read_word_data(struct i2c_client * client, u8 command); |
| 611 | extern s32 i2c_smbus_write_word_data(struct i2c_client * client, |
| 612 | u8 command, u16 value); |
| 613 | extern s32 i2c_smbus_write_block_data(struct i2c_client * client, |
| 614 | u8 command, u8 length, |
| 615 | u8 *values); |
| 616 | |
| 617 | These ones were removed in Linux 2.6.10 because they had no users, but could |
| 618 | be added back later if needed: |
| 619 | |
| 620 | extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client * client, |
| 621 | u8 command, u8 *values); |
| 622 | extern s32 i2c_smbus_read_block_data(struct i2c_client * client, |
| 623 | u8 command, u8 *values); |
| 624 | extern s32 i2c_smbus_write_i2c_block_data(struct i2c_client * client, |
| 625 | u8 command, u8 length, |
| 626 | u8 *values); |
| 627 | extern s32 i2c_smbus_process_call(struct i2c_client * client, |
| 628 | u8 command, u16 value); |
| 629 | extern s32 i2c_smbus_block_process_call(struct i2c_client *client, |
| 630 | u8 command, u8 length, |
| 631 | u8 *values) |
| 632 | |
| 633 | All these transactions return -1 on failure. The 'write' transactions |
| 634 | return 0 on success; the 'read' transactions return the read value, except |
| 635 | for read_block, which returns the number of values read. The block buffers |
| 636 | need not be longer than 32 bytes. |
| 637 | |
| 638 | You can read the file `smbus-protocol' for more information about the |
| 639 | actual SMBus protocol. |
| 640 | |
| 641 | |
| 642 | General purpose routines |
| 643 | ======================== |
| 644 | |
| 645 | Below all general purpose routines are listed, that were not mentioned |
| 646 | before. |
| 647 | |
| 648 | /* This call returns a unique low identifier for each registered adapter, |
| 649 | * or -1 if the adapter was not registered. |
| 650 | */ |
| 651 | extern int i2c_adapter_id(struct i2c_adapter *adap); |
| 652 | |
| 653 | |
| 654 | The sensors sysctl/proc interface |
| 655 | ================================= |
| 656 | |
| 657 | This section only applies if you write `sensors' drivers. |
| 658 | |
| 659 | Each sensors driver creates a directory in /proc/sys/dev/sensors for each |
| 660 | registered client. The directory is called something like foo-i2c-4-65. |
| 661 | The sensors module helps you to do this as easily as possible. |
| 662 | |
| 663 | The template |
| 664 | ------------ |
| 665 | |
| 666 | You will need to define a ctl_table template. This template will automatically |
| 667 | be copied to a newly allocated structure and filled in where necessary when |
| 668 | you call sensors_register_entry. |
| 669 | |
| 670 | First, I will give an example definition. |
| 671 | static ctl_table foo_dir_table_template[] = { |
| 672 | { FOO_SYSCTL_FUNC1, "func1", NULL, 0, 0644, NULL, &i2c_proc_real, |
| 673 | &i2c_sysctl_real,NULL,&foo_func }, |
| 674 | { FOO_SYSCTL_FUNC2, "func2", NULL, 0, 0644, NULL, &i2c_proc_real, |
| 675 | &i2c_sysctl_real,NULL,&foo_func }, |
| 676 | { FOO_SYSCTL_DATA, "data", NULL, 0, 0644, NULL, &i2c_proc_real, |
| 677 | &i2c_sysctl_real,NULL,&foo_data }, |
| 678 | { 0 } |
| 679 | }; |
| 680 | |
| 681 | In the above example, three entries are defined. They can either be |
| 682 | accessed through the /proc interface, in the /proc/sys/dev/sensors/* |
| 683 | directories, as files named func1, func2 and data, or alternatively |
| 684 | through the sysctl interface, in the appropriate table, with identifiers |
| 685 | FOO_SYSCTL_FUNC1, FOO_SYSCTL_FUNC2 and FOO_SYSCTL_DATA. |
| 686 | |
| 687 | The third, sixth and ninth parameters should always be NULL, and the |
| 688 | fourth should always be 0. The fifth is the mode of the /proc file; |
| 689 | 0644 is safe, as the file will be owned by root:root. |
| 690 | |
| 691 | The seventh and eighth parameters should be &i2c_proc_real and |
| 692 | &i2c_sysctl_real if you want to export lists of reals (scaled |
| 693 | integers). You can also use your own function for them, as usual. |
| 694 | Finally, the last parameter is the call-back to gather the data |
| 695 | (see below) if you use the *_proc_real functions. |
| 696 | |
| 697 | |
| 698 | Gathering the data |
| 699 | ------------------ |
| 700 | |
| 701 | The call back functions (foo_func and foo_data in the above example) |
| 702 | can be called in several ways; the operation parameter determines |
| 703 | what should be done: |
| 704 | |
| 705 | * If operation == SENSORS_PROC_REAL_INFO, you must return the |
| 706 | magnitude (scaling) in nrels_mag; |
| 707 | * If operation == SENSORS_PROC_REAL_READ, you must read information |
| 708 | from the chip and return it in results. The number of integers |
| 709 | to display should be put in nrels_mag; |
| 710 | * If operation == SENSORS_PROC_REAL_WRITE, you must write the |
| 711 | supplied information to the chip. nrels_mag will contain the number |
| 712 | of integers, results the integers themselves. |
| 713 | |
| 714 | The *_proc_real functions will display the elements as reals for the |
| 715 | /proc interface. If you set the magnitude to 2, and supply 345 for |
| 716 | SENSORS_PROC_REAL_READ, it would display 3.45; and if the user would |
| 717 | write 45.6 to the /proc file, it would be returned as 4560 for |
| 718 | SENSORS_PROC_REAL_WRITE. A magnitude may even be negative! |
| 719 | |
| 720 | An example function: |
| 721 | |
| 722 | /* FOO_FROM_REG and FOO_TO_REG translate between scaled values and |
| 723 | register values. Note the use of the read cache. */ |
| 724 | void foo_in(struct i2c_client *client, int operation, int ctl_name, |
| 725 | int *nrels_mag, long *results) |
| 726 | { |
| 727 | struct foo_data *data = client->data; |
| 728 | int nr = ctl_name - FOO_SYSCTL_FUNC1; /* reduce to 0 upwards */ |
| 729 | |
| 730 | if (operation == SENSORS_PROC_REAL_INFO) |
| 731 | *nrels_mag = 2; |
| 732 | else if (operation == SENSORS_PROC_REAL_READ) { |
| 733 | /* Update the readings cache (if necessary) */ |
| 734 | foo_update_client(client); |
| 735 | /* Get the readings from the cache */ |
| 736 | results[0] = FOO_FROM_REG(data->foo_func_base[nr]); |
| 737 | results[1] = FOO_FROM_REG(data->foo_func_more[nr]); |
| 738 | results[2] = FOO_FROM_REG(data->foo_func_readonly[nr]); |
| 739 | *nrels_mag = 2; |
| 740 | } else if (operation == SENSORS_PROC_REAL_WRITE) { |
| 741 | if (*nrels_mag >= 1) { |
| 742 | /* Update the cache */ |
| 743 | data->foo_base[nr] = FOO_TO_REG(results[0]); |
| 744 | /* Update the chip */ |
| 745 | foo_write_value(client,FOO_REG_FUNC_BASE(nr),data->foo_base[nr]); |
| 746 | } |
| 747 | if (*nrels_mag >= 2) { |
| 748 | /* Update the cache */ |
| 749 | data->foo_more[nr] = FOO_TO_REG(results[1]); |
| 750 | /* Update the chip */ |
| 751 | foo_write_value(client,FOO_REG_FUNC_MORE(nr),data->foo_more[nr]); |
| 752 | } |
| 753 | } |
| 754 | } |