diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/hwmon/lm78 | 7 | ||||
| -rw-r--r-- | Documentation/hwmon/w83792d | 174 | ||||
| -rw-r--r-- | Documentation/i2c/chips/max6875 | 94 | ||||
| -rw-r--r-- | Documentation/i2c/functionality | 2 | ||||
| -rw-r--r-- | Documentation/i2c/porting-clients | 25 | ||||
| -rw-r--r-- | Documentation/i2c/writing-clients | 114 |
6 files changed, 290 insertions, 126 deletions
diff --git a/Documentation/hwmon/lm78 b/Documentation/hwmon/lm78 index 357086ed7f6..fd5dc7a19f0 100644 --- a/Documentation/hwmon/lm78 +++ b/Documentation/hwmon/lm78 @@ -2,16 +2,11 @@ Kernel driver lm78 ================== Supported chips: - * National Semiconductor LM78 + * National Semiconductor LM78 / LM78-J Prefix: 'lm78' Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports) Datasheet: Publicly available at the National Semiconductor website http://www.national.com/ - * National Semiconductor LM78-J - Prefix: 'lm78-j' - Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports) - Datasheet: Publicly available at the National Semiconductor website - http://www.national.com/ * National Semiconductor LM79 Prefix: 'lm79' Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports) diff --git a/Documentation/hwmon/w83792d b/Documentation/hwmon/w83792d new file mode 100644 index 00000000000..8171c285bb5 --- /dev/null +++ b/Documentation/hwmon/w83792d @@ -0,0 +1,174 @@ +Kernel driver w83792d +===================== + +Supported chips: + * Winbond W83792D + Prefix: 'w83792d' + Addresses scanned: I2C 0x2c - 0x2f + Datasheet: http://www.winbond.com.tw/E-WINBONDHTM/partner/PDFresult.asp?Pname=1035 + +Author: Chunhao Huang +Contact: DZShen <DZShen@Winbond.com.tw> + + +Module Parameters +----------------- + +* init int + (default 1) + Use 'init=0' to bypass initializing the chip. + Try this if your computer crashes when you load the module. + +* force_subclients=bus,caddr,saddr,saddr + This is used to force the i2c addresses for subclients of + a certain chip. Example usage is `force_subclients=0,0x2f,0x4a,0x4b' + to force the subclients of chip 0x2f on bus 0 to i2c addresses + 0x4a and 0x4b. + + +Description +----------- + +This driver implements support for the Winbond W83792AD/D. + +Detection of the chip can sometimes be foiled because it can be in an +internal state that allows no clean access (Bank with ID register is not +currently selected). If you know the address of the chip, use a 'force' +parameter; this will put it into a more well-behaved state first. + +The driver implements three temperature sensors, seven fan rotation speed +sensors, nine voltage sensors, and two automatic fan regulation +strategies called: Smart Fan I (Thermal Cruise mode) and Smart Fan II. +Automatic fan control mode is possible only for fan1-fan3. Fan4-fan7 can run +synchronized with selected fan (fan1-fan3). This functionality and manual PWM +control for fan4-fan7 is not yet implemented. + +Temperatures are measured in degrees Celsius and measurement resolution is 1 +degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when +the temperature gets higher than the Overtemperature Shutdown value; it stays +on until the temperature falls below the Hysteresis value. + +Fan rotation speeds are reported in RPM (rotations per minute). An alarm is +triggered if the rotation speed has dropped below a programmable limit. Fan +readings can be divided by a programmable divider (1, 2, 4, 8, 16, 32, 64 or +128) to give the readings more range or accuracy. + +Voltage sensors (also known as IN sensors) report their values in millivolts. +An alarm is triggered if the voltage has crossed a programmable minimum +or maximum limit. + +Alarms are provided as output from "realtime status register". Following bits +are defined: + +bit - alarm on: +0 - in0 +1 - in1 +2 - temp1 +3 - temp2 +4 - temp3 +5 - fan1 +6 - fan2 +7 - fan3 +8 - in2 +9 - in3 +10 - in4 +11 - in5 +12 - in6 +13 - VID change +14 - chassis +15 - fan7 +16 - tart1 +17 - tart2 +18 - tart3 +19 - in7 +20 - in8 +21 - fan4 +22 - fan5 +23 - fan6 + +Tart will be asserted while target temperature cannot be achieved after 3 minutes +of full speed rotation of corresponding fan. + +In addition to the alarms described above, there is a CHAS alarm on the chips +which triggers if your computer case is open (This one is latched, contrary +to realtime alarms). + +The chips only update values each 3 seconds; reading them more often will +do no harm, but will return 'old' values. + + +W83792D PROBLEMS +---------------- +Known problems: + - This driver is only for Winbond W83792D C version device, there + are also some motherboards with B version W83792D device. The + calculation method to in6-in7(measured value, limits) is a little + different between C and B version. C or B version can be identified + by CR[0x49h]. + - The function of vid and vrm has not been finished, because I'm NOT + very familiar with them. Adding support is welcome. + - The function of chassis open detection needs more tests. + - If you have ASUS server board and chip was not found: Then you will + need to upgrade to latest (or beta) BIOS. If it does not help please + contact us. + +Fan control +----------- + +Manual mode +----------- + +Works as expected. You just need to specify desired PWM/DC value (fan speed) +in appropriate pwm# file. + +Thermal cruise +-------------- + +In this mode, W83792D provides the Smart Fan system to automatically control +fan speed to keep the temperatures of CPU and the system within specific +range. At first a wanted temperature and interval must be set. This is done +via thermal_cruise# file. The tolerance# file serves to create T +- tolerance +interval. The fan speed will be lowered as long as the current temperature +remains below the thermal_cruise# +- tolerance# value. Once the temperature +exceeds the high limit (T+tolerance), the fan will be turned on with a +specific speed set by pwm# and automatically controlled its PWM duty cycle +with the temperature varying. Three conditions may occur: + +(1) If the temperature still exceeds the high limit, PWM duty +cycle will increase slowly. + +(2) If the temperature goes below the high limit, but still above the low +limit (T-tolerance), the fan speed will be fixed at the current speed because +the temperature is in the target range. + +(3) If the temperature goes below the low limit, PWM duty cycle will decrease +slowly to 0 or a preset stop value until the temperature exceeds the low +limit. (The preset stop value handling is not yet implemented in driver) + +Smart Fan II +------------ + +W83792D also provides a special mode for fan. Four temperature points are +available. When related temperature sensors detects the temperature in preset +temperature region (sf2_point@_fan# +- tolerance#) it will cause fans to run +on programmed value from sf2_level@_fan#. You need to set four temperatures +for each fan. + + +/sys files +---------- + +pwm[1-3] - this file stores PWM duty cycle or DC value (fan speed) in range: + 0 (stop) to 255 (full) +pwm[1-3]_enable - this file controls mode of fan/temperature control: + * 0 Disabled + * 1 Manual mode + * 2 Smart Fan II + * 3 Thermal Cruise +pwm[1-3]_mode - Select PWM of DC mode + * 0 DC + * 1 PWM +thermal_cruise[1-3] - Selects the desired temperature for cruise (degC) +tolerance[1-3] - Value in degrees of Celsius (degC) for +- T +sf2_point[1-4]_fan[1-3] - four temperature points for each fan for Smart Fan II +sf2_level[1-3]_fan[1-3] - three PWM/DC levels for each fan for Smart Fan II diff --git a/Documentation/i2c/chips/max6875 b/Documentation/i2c/chips/max6875 index b02002898a0..96fec562a8e 100644 --- a/Documentation/i2c/chips/max6875 +++ b/Documentation/i2c/chips/max6875 @@ -4,22 +4,13 @@ Kernel driver max6875 Supported chips: * Maxim MAX6874, MAX6875 Prefix: 'max6875' - Addresses scanned: 0x50, 0x52 + Addresses scanned: None (see below) Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6874-MAX6875.pdf Author: Ben Gardner <bgardner@wabtec.com> -Module Parameters ------------------ - -* allow_write int - Set to non-zero to enable write permission: - *0: Read only - 1: Read and write - - Description ----------- @@ -33,34 +24,85 @@ registers. The Maxim MAX6874 is a similar, mostly compatible device, with more intputs and outputs: - vin gpi vout MAX6874 6 4 8 MAX6875 4 3 5 -MAX6874 chips can have four different addresses (as opposed to only two for -the MAX6875). The additional addresses (0x54 and 0x56) are not probed by -this driver by default, but the probe module parameter can be used if -needed. - -See the datasheet for details on how to program the EEPROM. +See the datasheet for more information. Sysfs entries ------------- -eeprom_user - 512 bytes of user-defined EEPROM space. Only writable if - allow_write was set and register 0x43 is 0. - -eeprom_config - 70 bytes of config EEPROM. Note that changes will not get - loaded into register space until a power cycle or device reset. - -reg_config - 70 bytes of register space. Any changes take affect immediately. +eeprom - 512 bytes of user-defined EEPROM space. General Remarks --------------- -A typical application will require that the EEPROMs be programmed once and -never altered afterwards. +Valid addresses for the MAX6875 are 0x50 and 0x52. +Valid addresses for the MAX6874 are 0x50, 0x52, 0x54 and 0x56. +The driver does not probe any address, so you must force the address. + +Example: +$ modprobe max6875 force=0,0x50 + +The MAX6874/MAX6875 ignores address bit 0, so this driver attaches to multiple +addresses. For example, for address 0x50, it also reserves 0x51. +The even-address instance is called 'max6875', the odd one is 'max6875 subclient'. + + +Programming the chip using i2c-dev +---------------------------------- + +Use the i2c-dev interface to access and program the chips. +Reads and writes are performed differently depending on the address range. + +The configuration registers are at addresses 0x00 - 0x45. +Use i2c_smbus_write_byte_data() to write a register and +i2c_smbus_read_byte_data() to read a register. +The command is the register number. + +Examples: +To write a 1 to register 0x45: + i2c_smbus_write_byte_data(fd, 0x45, 1); + +To read register 0x45: + value = i2c_smbus_read_byte_data(fd, 0x45); + + +The configuration EEPROM is at addresses 0x8000 - 0x8045. +The user EEPROM is at addresses 0x8100 - 0x82ff. + +Use i2c_smbus_write_word_data() to write a byte to EEPROM. + +The command is the upper byte of the address: 0x80, 0x81, or 0x82. +The data word is the lower part of the address or'd with data << 8. + cmd = address >> 8; + val = (address & 0xff) | (data << 8); + +Example: +To write 0x5a to address 0x8003: + i2c_smbus_write_word_data(fd, 0x80, 0x5a03); + + +Reading data from the EEPROM is a little more complicated. +Use i2c_smbus_write_byte_data() to set the read address and then +i2c_smbus_read_byte() or i2c_smbus_read_i2c_block_data() to read the data. + +Example: +To read data starting at offset 0x8100, first set the address: + i2c_smbus_write_byte_data(fd, 0x81, 0x00); + +And then read the data + value = i2c_smbus_read_byte(fd); + + or + + count = i2c_smbus_read_i2c_block_data(fd, 0x84, buffer); + +The block read should read 16 bytes. +0x84 is the block read command. + +See the datasheet for more details. diff --git a/Documentation/i2c/functionality b/Documentation/i2c/functionality index 8a78a95ae04..41ffefbdc60 100644 --- a/Documentation/i2c/functionality +++ b/Documentation/i2c/functionality @@ -115,7 +115,7 @@ CHECKING THROUGH /DEV If you try to access an adapter from a userspace program, you will have to use the /dev interface. You will still have to check whether the functionality you need is supported, of course. This is done using -the I2C_FUNCS ioctl. An example, adapted from the lm_sensors i2c_detect +the I2C_FUNCS ioctl. An example, adapted from the lm_sensors i2cdetect program, is below: int file; diff --git a/Documentation/i2c/porting-clients b/Documentation/i2c/porting-clients index a7adbdd9ea8..4849dfd6961 100644 --- a/Documentation/i2c/porting-clients +++ b/Documentation/i2c/porting-clients @@ -1,4 +1,4 @@ -Revision 4, 2004-03-30 +Revision 5, 2005-07-29 Jean Delvare <khali@linux-fr.org> Greg KH <greg@kroah.com> @@ -17,20 +17,22 @@ yours for best results. Technical changes: -* [Includes] Get rid of "version.h". Replace <linux/i2c-proc.h> with - <linux/i2c-sensor.h>. Includes typically look like that: +* [Includes] Get rid of "version.h" and <linux/i2c-proc.h>. + Includes typically look like that: #include <linux/module.h> #include <linux/init.h> #include <linux/slab.h> #include <linux/i2c.h> - #include <linux/i2c-sensor.h> - #include <linux/i2c-vid.h> /* if you need VRM support */ + #include <linux/hwmon.h> /* for hardware monitoring drivers */ + #include <linux/hwmon-sysfs.h> + #include <linux/hwmon-vid.h> /* if you need VRM support */ #include <asm/io.h> /* if you have I/O operations */ Please respect this inclusion order. Some extra headers may be required for a given driver (e.g. "lm75.h"). -* [Addresses] SENSORS_I2C_END becomes I2C_CLIENT_END, SENSORS_ISA_END - becomes I2C_CLIENT_ISA_END. +* [Addresses] SENSORS_I2C_END becomes I2C_CLIENT_END, ISA addresses + are no more handled by the i2c core. + SENSORS_INSMOD_<n> becomes I2C_CLIENT_INSMOD_<n>. * [Client data] Get rid of sysctl_id. Try using standard names for register values (for example, temp_os becomes temp_max). You're @@ -66,13 +68,15 @@ Technical changes: if (!(adapter->class & I2C_CLASS_HWMON)) return 0; ISA-only drivers of course don't need this. + Call i2c_probe() instead of i2c_detect(). * [Detect] As mentioned earlier, the flags parameter is gone. The type_name and client_name strings are replaced by a single name string, which will be filled with a lowercase, short string (typically the driver name, e.g. "lm75"). In i2c-only drivers, drop the i2c_is_isa_adapter check, it's - useless. + useless. Same for isa-only drivers, as the test would always be + true. Only hybrid drivers (which are quite rare) still need it. The errorN labels are reduced to the number needed. If that number is 2 (i2c-only drivers), it is advised that the labels are named exit and exit_free. For i2c+isa drivers, labels should be named @@ -86,6 +90,8 @@ Technical changes: device_create_file. Move the driver initialization before any sysfs file creation. Drop client->id. + Drop any 24RF08 corruption prevention you find, as this is now done + at the i2c-core level, and doing it twice voids it. * [Init] Limits must not be set by the driver (can be done later in user-space). Chip should not be reset default (although a module @@ -93,7 +99,8 @@ Technical changes: limited to the strictly necessary steps. * [Detach] Get rid of data, remove the call to - i2c_deregister_entry. + i2c_deregister_entry. Do not log an error message if + i2c_detach_client fails, as i2c-core will now do it for you. * [Update] Don't access client->data directly, use i2c_get_clientdata(client) instead. diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 91664be91ff..077275722a7 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients @@ -148,15 +148,15 @@ are defined in i2c.h to help you support them, as well as a generic detection algorithm. You do not have to use this parameter interface; but don't try to use -function i2c_probe() (or i2c_detect()) if you don't. +function i2c_probe() if you don't. NOTE: If you want to write a `sensors' driver, the interface is slightly different! See below. -Probing classes (i2c) ---------------------- +Probing classes +--------------- All parameters are given as lists of unsigned 16-bit integers. Lists are terminated by I2C_CLIENT_END. @@ -171,12 +171,18 @@ The following lists are used internally: ignore: insmod parameter. A list of pairs. The first value is a bus number (-1 for any I2C bus), the second is the I2C address. These addresses are never probed. - This parameter overrules 'normal' and 'probe', but not the 'force' lists. + This parameter overrules the 'normal_i2c' list only. force: insmod parameter. A list of pairs. The first value is a bus number (-1 for any I2C bus), the second is the I2C address. A device is blindly assumed to be on the given address, no probing is done. +Additionally, kind-specific force lists may optionally be defined if +the driver supports several chip kinds. They are grouped in a +NULL-terminated list of pointers named forces, those first element if the +generic force list mentioned above. Each additional list correspond to an +insmod parameter of the form force_<kind>. + Fortunately, as a module writer, you just have to define the `normal_i2c' parameter. The complete declaration could look like this: @@ -186,66 +192,17 @@ parameter. The complete declaration could look like this: /* Magic definition of all other variables and things */ I2C_CLIENT_INSMOD; + /* Or, if your driver supports, say, 2 kind of devices: */ + I2C_CLIENT_INSMOD_2(foo, bar); + +If you use the multi-kind form, an enum will be defined for you: + enum chips { any_chip, foo, bar, ... } +You can then (and certainly should) use it in the driver code. Note that you *have* to call the defined variable `normal_i2c', without any prefix! -Probing classes (sensors) -------------------------- - -If you write a `sensors' driver, you use a slightly different interface. -As well as I2C addresses, we have to cope with ISA addresses. Also, we -use a enum of chip types. Don't forget to include `sensors.h'. - -The following lists are used internally. They are all lists of integers. - - normal_i2c: filled in by the module writer. Terminated by SENSORS_I2C_END. - A list of I2C addresses which should normally be examined. - normal_isa: filled in by the module writer. Terminated by SENSORS_ISA_END. - A list of ISA addresses which should normally be examined. - probe: insmod parameter. Initialize this list with SENSORS_I2C_END values. - A list of pairs. The first value is a bus number (SENSORS_ISA_BUS for - the ISA bus, -1 for any I2C bus), the second is the address. These - addresses are also probed, as if they were in the 'normal' list. - ignore: insmod parameter. Initialize this list with SENSORS_I2C_END values. - A list of pairs. The first value is a bus number (SENSORS_ISA_BUS for - the ISA bus, -1 for any I2C bus), the second is the I2C address. These - addresses are never probed. This parameter overrules 'normal' and - 'probe', but not the 'force' lists. - -Also used is a list of pointers to sensors_force_data structures: - force_data: insmod parameters. A list, ending with an element of which - the force field is NULL. - Each element contains the type of chip and a list of pairs. - The first value is a bus number (SENSORS_ISA_BUS for the ISA bus, - -1 for any I2C bus), the second is the address. - These are automatically translated to insmod variables of the form - force_foo. - -So we have a generic insmod variabled `force', and chip-specific variables -`force_CHIPNAME'. - -Fortunately, as a module writer, you just have to define the `normal_i2c' -and `normal_isa' parameters, and define what chip names are used. -The complete declaration could look like this: - /* Scan i2c addresses 0x37, and 0x48 to 0x4f */ - static unsigned short normal_i2c[] = { 0x37, 0x48, 0x49, 0x4a, 0x4b, 0x4c, - 0x4d, 0x4e, 0x4f, I2C_CLIENT_END }; - /* Scan ISA address 0x290 */ - static unsigned int normal_isa[] = {0x0290,SENSORS_ISA_END}; - - /* Define chips foo and bar, as well as all module parameters and things */ - SENSORS_INSMOD_2(foo,bar); - -If you have one chip, you use macro SENSORS_INSMOD_1(chip), if you have 2 -you use macro SENSORS_INSMOD_2(chip1,chip2), etc. If you do not want to -bother with chip types, you can use SENSORS_INSMOD_0. - -A enum is automatically defined as follows: - enum chips { any_chip, chip1, chip2, ... } - - Attaching to an adapter ----------------------- @@ -264,17 +221,10 @@ detected at a specific address, another callback is called. return i2c_probe(adapter,&addr_data,&foo_detect_client); } -For `sensors' drivers, use the i2c_detect function instead: - - int foo_attach_adapter(struct i2c_adapter *adapter) - { - return i2c_detect(adapter,&addr_data,&foo_detect_client); - } - Remember, structure `addr_data' is defined by the macros explained above, so you do not have to define it yourself. -The i2c_probe or i2c_detect function will call the foo_detect_client +The i2c_probe function will call the foo_detect_client function only for those i2c addresses that actually have a device on them (unless a `force' parameter was used). In addition, addresses that are already in use (by some other registered client) are skipped. @@ -283,19 +233,18 @@ are already in use (by some other registered client) are skipped. The detect client function -------------------------- -The detect client function is called by i2c_probe or i2c_detect. -The `kind' parameter contains 0 if this call is due to a `force' -parameter, and -1 otherwise (for i2c_detect, it contains 0 if -this call is due to the generic `force' parameter, and the chip type -number if it is due to a specific `force' parameter). +The detect client function is called by i2c_probe. The `kind' parameter +contains -1 for a probed detection, 0 for a forced detection, or a positive +number for a forced detection with a chip type forced. Below, some things are only needed if this is a `sensors' driver. Those parts are between /* SENSORS ONLY START */ and /* SENSORS ONLY END */ markers. -This function should only return an error (any value != 0) if there is -some reason why no more detection should be done anymore. If the -detection just fails for this address, return 0. +Returning an error different from -ENODEV in a detect function will cause +the detection to stop: other addresses and adapters won't be scanned. +This should only be done on fatal or internal errors, such as a memory +shortage or i2c_attach_client failing. For now, you can ignore the `flags' parameter. It is there for future use. @@ -320,11 +269,10 @@ For now, you can ignore the `flags' parameter. It is there for future use. const char *type_name = ""; int is_isa = i2c_is_isa_adapter(adapter); - if (is_isa) { + /* Do this only if the chip can additionally be found on the ISA bus + (hybrid chip). */ - /* If this client can't be on the ISA bus at all, we can stop now - (call `goto ERROR0'). But for kicks, we will assume it is all - right. */ + if (is_isa) { /* Discard immediately if this ISA range is already used */ if (check_region(address,FOO_EXTENT)) @@ -495,15 +443,13 @@ much simpler than the attachment code, fortunately! /* SENSORS ONLY END */ /* Try to detach the client from i2c space */ - if ((err = i2c_detach_client(client))) { - printk("foo.o: Client deregistration failed, client not detached.\n"); + if ((err = i2c_detach_client(client))) return err; - } - /* SENSORS ONLY START */ + /* HYBRID SENSORS CHIP ONLY START */ if i2c_is_isa_client(client) release_region(client->addr,LM78_EXTENT); - /* SENSORS ONLY END */ + /* HYBRID SENSORS CHIP ONLY END */ kfree(client); /* Frees client data too, if allocated at the same time */ return 0; |