From 43cb7ebee2f478d3f987ad773d4e6b07fc23c631 Mon Sep 17 00:00:00 2001 From: Jordan Crouse Date: Thu, 23 Mar 2006 16:19:49 +0100 Subject: [PATCH] lm83: Add LM82 support Add LM82 temperature sensor support (similar to the LM83, but less featureful). Signed-off-by: Jordan Crouse Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/hwmon/lm83 | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/lm83 b/Documentation/hwmon/lm83 index 061d9ed8ff43..74aa7ee1a359 100644 --- a/Documentation/hwmon/lm83 +++ b/Documentation/hwmon/lm83 @@ -7,6 +7,10 @@ Supported chips: Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e Datasheet: Publicly available at the National Semiconductor website http://www.national.com/pf/LM/LM83.html + * National Semiconductor LM82 + Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e + Datasheet: Publicly available at the National Semiconductor website + http://www.national.com/pf/LM/LM82.html Author: Jean Delvare @@ -15,10 +19,11 @@ Description ----------- The LM83 is a digital temperature sensor. It senses its own temperature as -well as the temperature of up to three external diodes. It is compatible -with many other devices such as the LM84 and all other ADM1021 clones. -The main difference between the LM83 and the LM84 in that the later can -only sense the temperature of one external diode. +well as the temperature of up to three external diodes. The LM82 is +a stripped down version of the LM83 that only supports one external diode. +Both are compatible with many other devices such as the LM84 and all +other ADM1021 clones. The main difference between the LM83 and the LM84 +in that the later can only sense the temperature of one external diode. Using the adm1021 driver for a LM83 should work, but only two temperatures will be reported instead of four. @@ -36,6 +41,9 @@ Unconfirmed motherboards: Iwill MPX2 Soltek SL-75DRV5 +The LM82 is confirmed to have been found on most AMD Geode reference +designs and test platforms. + The driver has been successfully tested by Magnus Forsström, who I'd like to thank here. More testers will be of course welcome. -- cgit v1.2.2 From 59ac83677f72ea2cc25b5426e7df9589aa7a5384 Mon Sep 17 00:00:00 2001 From: Hartmut Rick Date: Thu, 23 Mar 2006 16:37:23 +0100 Subject: [PATCH] smsc47m192: New hwmon driver for SMSC LPC47M192/997 New driver (smsc47m192) which supports voltage and temperature measurement features of SMSC LPC47M192 and LPC47M997 chips. Signed-off-by: Hartmut Rick Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/hwmon/smsc47m192 | 102 ++++++++++++++++++++++++++++++++++++ Documentation/hwmon/sysfs-interface | 6 +++ 2 files changed, 108 insertions(+) create mode 100644 Documentation/hwmon/smsc47m192 (limited to 'Documentation') diff --git a/Documentation/hwmon/smsc47m192 b/Documentation/hwmon/smsc47m192 new file mode 100644 index 000000000000..45d6453cd435 --- /dev/null +++ b/Documentation/hwmon/smsc47m192 @@ -0,0 +1,102 @@ +Kernel driver smsc47m192 +======================== + +Supported chips: + * SMSC LPC47M192 and LPC47M997 + Prefix: 'smsc47m192' + Addresses scanned: I2C 0x2c - 0x2d + Datasheet: The datasheet for LPC47M192 is publicly available from + http://www.smsc.com/ + The LPC47M997 is compatible for hardware monitoring. + +Author: Hartmut Rick + Special thanks to Jean Delvare for careful checking + of the code and many helpful comments and suggestions. + + +Description +----------- + +This driver implements support for the hardware sensor capabilities +of the SMSC LPC47M192 and LPC47M997 Super-I/O chips. + +These chips support 3 temperature channels and 8 voltage inputs +as well as CPU voltage VID input. + +They do also have fan monitoring and control capabilities, but the +these features are accessed via ISA bus and are not supported by this +driver. Use the 'smsc47m1' driver for fan monitoring and control. + +Voltages and temperatures are measured by an 8-bit ADC, the resolution +of the temperatures is 1 bit per degree C. +Voltages are scaled such that the nominal voltage corresponds to +192 counts, i.e. 3/4 of the full range. Thus the available range for +each voltage channel is 0V ... 255/192*(nominal voltage), the resolution +is 1 bit per (nominal voltage)/192. +Both voltage and temperature values are scaled by 1000, the sys files +show voltages in mV and temperatures in units of 0.001 degC. + +The +12V analog voltage input channel (in4_input) is multiplexed with +bit 4 of the encoded CPU voltage. This means that you either get +a +12V voltage measurement or a 5 bit CPU VID, but not both. +The default setting is to use the pin as 12V input, and use only 4 bit VID. +This driver assumes that the information in the configuration register +is correct, i.e. that the BIOS has updated the configuration if +the motherboard has this input wired to VID4. + +The temperature and voltage readings are updated once every 1.5 seconds. +Reading them more often repeats the same values. + + +sysfs interface +--------------- + +in0_input - +2.5V voltage input +in1_input - CPU voltage input (nominal 2.25V) +in2_input - +3.3V voltage input +in3_input - +5V voltage input +in4_input - +12V voltage input (may be missing if used as VID4) +in5_input - Vcc voltage input (nominal 3.3V) + This is the supply voltage of the sensor chip itself. +in6_input - +1.5V voltage input +in7_input - +1.8V voltage input + +in[0-7]_min, +in[0-7]_max - lower and upper alarm thresholds for in[0-7]_input reading + + All voltages are read and written in mV. + +in[0-7]_alarm - alarm flags for voltage inputs + These files read '1' in case of alarm, '0' otherwise. + +temp1_input - chip temperature measured by on-chip diode +temp[2-3]_input - temperature measured by external diodes (one of these would + typically be wired to the diode inside the CPU) + +temp[1-3]_min, +temp[1-3]_max - lower and upper alarm thresholds for temperatures + +temp[1-3]_offset - temperature offset registers + The chip adds the offsets stored in these registers to + the corresponding temperature readings. + Note that temp1 and temp2 offsets share the same register, + they cannot both be different from zero at the same time. + Writing a non-zero number to one of them will reset the other + offset to zero. + + All temperatures and offsets are read and written in + units of 0.001 degC. + +temp[1-3]_alarm - alarm flags for temperature inputs, '1' in case of alarm, + '0' otherwise. +temp[2-3]_input_fault - diode fault flags for temperature inputs 2 and 3. + A fault is detected if the two pins for the corresponding + sensor are open or shorted, or any of the two is shorted + to ground or Vcc. '1' indicates a diode fault. + +cpu0_vid - CPU voltage as received from the CPU + +vrm - CPU VID standard used for decoding CPU voltage + + The *_min, *_max, *_offset and vrm files can be read and + written, all others are read-only. diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index a0d0ab24288e..2d16e1e4017d 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -218,6 +218,12 @@ temp[1-2]_crit_hyst from the critical value. Read/Write value. +temp[1-4]_offset + Temperature offset which is added to the temperature reading + by the chip. + Unit: millidegree Celsius + Read/Write value. + If there are multiple temperature sensors, temp1_* is generally the sensor inside the chip itself, reported as "motherboard temperature". temp2_* to -- cgit v1.2.2 From 400b48ecd95a7fac6b126042d37b7efe0202b582 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Thu, 23 Mar 2006 16:46:47 +0100 Subject: [PATCH] hwmon: Add sysfs interface for individual alarm files Extend the sysfs interface of hardware monitoring chips, by adding individual alarm and beep files. Contrary to the old aggregated "alarms" and "beeps" files, individual files constitute a standard way to access the status information, making it finally possible to implement a chip-independant hardware monitoring chip access library (once all drivers have been added this new interface, that is.) If future drivers need more individual files, the interface will be extended as needed at the same time these drivers are merged into the kernel tree. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/hwmon/sysfs-interface | 98 +++++++++++++++++++++++++++---------- 1 file changed, 73 insertions(+), 25 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index 2d16e1e4017d..eeb912254db4 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -252,9 +252,68 @@ curr[1-n]_input Current input value Read only. -********* -* Other * -********* +********** +* Alarms * +********** + +Each channel or limit may have an associated alarm file, containing a +boolean value. 1 means than an alarm condition exists, 0 means no alarm. + +Usually a given chip will either use channel-related alarms, or +limit-related alarms, not both. The driver should just reflect the hardware +implementation. + +in[0-n]_alarm +fan[1-n]_alarm +temp[1-n]_alarm + Channel alarm + Boolean + Read-only + +OR + +in[0-n]_min_alarm +in[0-n]_max_alarm +fan[1-n]_min_alarm +temp[1-n]_min_alarm +temp[1-n]_max_alarm +temp[1-n]_crit_alarm + Limit alarm + Boolean + Read-only + +Each input channel may have an associated fault file. This can be used +to notify open diodes, unconnected fans etc. where the hardware +supports it. When this boolean has value 1, the measurement for that +channel should not be trusted. + +in[0-n]_input_fault +fan[1-n]_input_fault +temp[1-n]_input_fault + Input fault condition + Boolean + Read-only + +Some chips also offer the possibility to get beeped when an alarm occurs: + +beep_enable Master beep enable + Boolean + Read/Write + +in[0-n]_beep +fan[1-n]_beep +temp[1-n]_beep + Channel beep + 0 to disable. + 1 to enable. + Read/write + +In theory, a chip could provide per-limit beep masking, but no such chip +was seen so far. + +Old drivers provided a different, non-standard interface to alarms and +beeps. These interface files are deprecated, but will be kept around +for compatibility reasons: alarms Alarm bitmask. Read only. @@ -265,33 +324,22 @@ alarms Alarm bitmask. if it is still valid. Generally a direct representation of a chip's internal alarm registers; there is no standard for the position - of individual bits. + of individual bits. For this reason, the use of this + interface file for new drivers is discouraged. Use + individual *_alarm and *_fault files instead. Bits are defined in kernel/include/sensors.h. -alarms_in Alarm bitmask relative to in (voltage) channels - Read only - A '1' bit means an alarm, LSB corresponds to in0 and so on - Prefered to 'alarms' for newer chips - -alarms_fan Alarm bitmask relative to fan channels - Read only - A '1' bit means an alarm, LSB corresponds to fan1 and so on - Prefered to 'alarms' for newer chips - -alarms_temp Alarm bitmask relative to temp (temperature) channels - Read only - A '1' bit means an alarm, LSB corresponds to temp1 and so on - Prefered to 'alarms' for newer chips - -beep_enable Beep/interrupt enable - 0 to disable. - 1 to enable. - Read/Write - beep_mask Bitmask for beep. - Same format as 'alarms' with the same bit locations. + Same format as 'alarms' with the same bit locations, + use discouraged for the same reason. Use individual + *_beep files instead. Read/Write + +********* +* Other * +********* + eeprom Raw EEPROM data in binary form. Read only. -- cgit v1.2.2 From 02e0c5d5c2e00374b6808a42f8eea4ea9baaa216 Mon Sep 17 00:00:00 2001 From: Rudolf Marek Date: Thu, 23 Mar 2006 16:48:09 +0100 Subject: [PATCH] i2c-piix4: Add ATI IXP200/300/400 support This patch adds the ATI IXP southbridges support to i2c-piix4, as it turned out those chips are compatible with it. Signed-off-by: Rudolf Marek Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/busses/i2c-piix4 | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4 index a1c8f581afed..6e6c905143a1 100644 --- a/Documentation/i2c/busses/i2c-piix4 +++ b/Documentation/i2c/busses/i2c-piix4 @@ -6,6 +6,8 @@ Supported adapters: Datasheet: Publicly available at the Intel website * ServerWorks OSB4, CSB5, CSB6 and HT-1000 southbridges Datasheet: Only available via NDA from ServerWorks + * ATI IXP southbridges IXP200, IXP300, IXP400 + Datasheet: Not publicly available * Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge Datasheet: Publicly available at the SMSC website http://www.smsc.com -- cgit v1.2.2 From 54aaa1ca1022d95d854315743241bb6bf59f531f Mon Sep 17 00:00:00 2001 From: Rudolf Marek Date: Tue, 25 Apr 2006 13:06:41 +0200 Subject: [PATCH] I2C: i2c-piix4: Remove the fix_hstcfg parameter This patch removes the fix_hstcfg option from the driver and related SMBus Interrupt Select register magic because now we know what are valid values for this register. This patch updates the documentation and adds new IRQ mode check so we are sure not to miss any new "unusual" value. The PCI quirk for users of fix_hstcfg was not developed because the chipset lacks of subsystem ID registers and DMI is stated "To be filled". Impact to existing systems is minimal because the problem showed up on motherboards like 10 years back. On the other hand users of newer Serverworks and HT1000 systems won't be misleaded by the message suggesting to try the fix_hstcfg any more. Signed-off-by: Rudolf Marek Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/busses/i2c-piix4 | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4 index 6e6c905143a1..10957bee7f64 100644 --- a/Documentation/i2c/busses/i2c-piix4 +++ b/Documentation/i2c/busses/i2c-piix4 @@ -23,8 +23,6 @@ Module Parameters Forcibly enable the PIIX4. DANGEROUS! * force_addr: int Forcibly enable the PIIX4 at the given address. EXTREMELY DANGEROUS! -* fix_hstcfg: int - Fix config register. Needed on some boards (Force CPCI735). Description @@ -68,7 +66,19 @@ this driver on those mainboards. The ServerWorks Southbridges, the Intel 440MX, and the Victory766 are identical to the PIIX4 in I2C/SMBus support. -A few OSB4 southbridges are known to be misconfigured by the BIOS. In this -case, you have you use the fix_hstcfg module parameter. Do not use it -unless you know you have to, because in some cases it also breaks -configuration on southbridges that don't need it. +If you own Force CPCI735 motherboard or other OSB4 based systems you may need +to change the SMBus Interrupt Select register so the SMBus controller uses +the SMI mode. + +1) Use lspci command and locate the PCI device with the SMBus controller: + 00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 4f) + The line may vary for different chipsets. Please consult the driver source + for all possible PCI ids (and lspci -n to match them). Lets assume the + device is located at 00:0f.0. +2) Now you just need to change the value in 0xD2 register. Get it first with + command: lspci -xxx -s 00:0f.0 + If the value is 0x3 then you need to change it to 0x1 + setpci -s 00:0f.0 d2.b=1 + +Please note that you don't need to do that in all cases, just when the SMBus is +not working properly. -- cgit v1.2.2 From 7aadb8f943f6f8fb48962099cfba05ad0518b0ac Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Tue, 25 Apr 2006 13:29:26 +0200 Subject: [PATCH] I2C: i2c-piix4: Fix typo in documentation Fix i2c-piix4 documentation typo. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/busses/i2c-piix4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4 index 10957bee7f64..a706ae6a1b41 100644 --- a/Documentation/i2c/busses/i2c-piix4 +++ b/Documentation/i2c/busses/i2c-piix4 @@ -63,7 +63,7 @@ The PIIX4E is just an new version of the PIIX4; it is supported as well. The PIIX/PIIX3 does not implement an SMBus or I2C bus, so you can't use this driver on those mainboards. -The ServerWorks Southbridges, the Intel 440MX, and the Victory766 are +The ServerWorks Southbridges, the Intel 440MX, and the Victory66 are identical to the PIIX4 in I2C/SMBus support. If you own Force CPCI735 motherboard or other OSB4 based systems you may need -- cgit v1.2.2 From f9ba6c04ef1dcf16f7179b7883e9751baaac218e Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Tue, 25 Apr 2006 13:37:25 +0200 Subject: [PATCH] I2C: i2c-piix4: Document the IBM problem more clearly Properly document on which systems the i2c-piix4 SMBus driver will refuse to load. Hopefully this will make it clearer for users, which were often wondering why their destop or server systems were detected as laptops. Closes bug #6429. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/busses/i2c-piix4 | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4 index a706ae6a1b41..921476333235 100644 --- a/Documentation/i2c/busses/i2c-piix4 +++ b/Documentation/i2c/busses/i2c-piix4 @@ -82,3 +82,17 @@ the SMI mode. Please note that you don't need to do that in all cases, just when the SMBus is not working properly. + + +Hardware-specific issues +------------------------ + +This driver will refuse to load on IBM systems with an Intel PIIX4 SMBus. +Some of these machines have an RFID EEPROM (24RF08) connected to the SMBus, +which can easily get corrupted due to a state machine bug. These are mostly +Thinkpad laptops, but desktop systems may also be affected. We have no list +of all affected systems, so the only safe solution was to prevent access to +the SMBus on all IBM systems (detected using DMI data.) + +For additional information, read: +http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/README.thinkpad -- cgit v1.2.2 From 5c7ae65899a4c5b05b6277f856018d1eeeb98907 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Tue, 25 Apr 2006 14:18:16 +0200 Subject: [PATCH] I2C: i2c-nforce2: Add support for the nForce4 MCP51 and MCP55 Add support for the new nForce4 MCP51 (also known as nForce 410 or 430) and nForce4 MCP55 to the i2c-nforce2 driver. Some code changes were required because the base I/O address registers have changed in these versions. Standard BARs are now being used, while the original nForce2 chips used non-standard ones. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/busses/i2c-nforce2 | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-nforce2 b/Documentation/i2c/busses/i2c-nforce2 index d751282d9b2a..cd49c428a3ab 100644 --- a/Documentation/i2c/busses/i2c-nforce2 +++ b/Documentation/i2c/busses/i2c-nforce2 @@ -7,6 +7,8 @@ Supported adapters: * nForce3 250Gb MCP 10de:00E4 * nForce4 MCP 10de:0052 * nForce4 MCP-04 10de:0034 + * nForce4 MCP51 10de:0264 + * nForce4 MCP55 10de:0368 Datasheet: not publically available, but seems to be similar to the AMD-8111 SMBus 2.0 adapter. -- cgit v1.2.2 From 9873964d6eb24bd0205394f9b791de9eddbcb855 Mon Sep 17 00:00:00 2001 From: Charles Spirakis Date: Tue, 25 Apr 2006 14:21:03 +0200 Subject: [PATCH] HWMON: w83791d: New hardware monitoring driver for the Winbond W83791D Add support for the w83791d sensor chip. The w83791d hardware is somewhere between the w83781d and the w83792d and this driver code is derived from the code that supports those chips. Signed-off-by: Charles Spirakis Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/hwmon/w83791d | 113 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 113 insertions(+) create mode 100644 Documentation/hwmon/w83791d (limited to 'Documentation') diff --git a/Documentation/hwmon/w83791d b/Documentation/hwmon/w83791d new file mode 100644 index 000000000000..83a3836289c2 --- /dev/null +++ b/Documentation/hwmon/w83791d @@ -0,0 +1,113 @@ +Kernel driver w83791d +===================== + +Supported chips: + * Winbond W83791D + Prefix: 'w83791d' + Addresses scanned: I2C 0x2c - 0x2f + Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83791Da.pdf + +Author: Charles Spirakis + +This driver was derived from the w83781d.c and w83792d.c source files. + +Credits: + w83781d.c: + Frodo Looijaard , + Philip Edelbrock , + and Mark Studebaker + w83792d.c: + Chunhao Huang , + Rudolf Marek + +Module Parameters +----------------- + +* init boolean + (default 0) + Use 'init=1' to have the driver do extra software initializations. + The default behavior is to do the minimum initialization possible + and depend on the BIOS to properly setup the chip. If you know you + have a w83791d and you're having problems, try init=1 before trying + reset=1. + +* reset boolean + (default 0) + Use 'reset=1' to reset the chip (via index 0x40, bit 7). The default + behavior is no chip reset to preserve BIOS settings. + +* 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 W83791D chip. + +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, five fan rotation speed +sensors, and ten voltage sensors. + +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 for fan 1/2/3 +and 1, 2, 4, 8, 16, 32, 64 or 128 for fan 4/5) 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 a "realtime status register". The +following bits are defined: + +bit - alarm on: +0 - Vcore +1 - VINR0 +2 - +3.3VIN +3 - 5VDD +4 - temp1 +5 - temp2 +6 - fan1 +7 - fan2 +8 - +12VIN +9 - -12VIN +10 - -5VIN +11 - fan3 +12 - chassis +13 - temp3 +14 - VINR1 +15 - reserved +16 - tart1 +17 - tart2 +18 - tart3 +19 - VSB +20 - VBAT +21 - fan4 +22 - fan5 +23 - reserved + +When an alarm goes off, you can be warned by a beeping signal through your +computer speaker. It is possible to enable all beeping globally, or only +the beeping for some alarms. + +The driver only reads the chip values each 3 seconds; reading them more +often will do no harm, but will return 'old' values. + +W83791D TODO: +--------------- +Provide a patch for per-file alarms as discussed on the mailing list +Provide a patch for smart-fan control (still need appropriate motherboard/fans) -- cgit v1.2.2 From 114cc0c0c1e98f0b8e205f91ae7b2471e0ad5325 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Tue, 25 Apr 2006 14:22:14 +0200 Subject: [PATCH] HWMON: lm83: Documentation update One more motherboard confirmed to have an LM83 temperature sensor chip. Thanks to Steven Hardy for reporting. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/hwmon/lm83 | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/lm83 b/Documentation/hwmon/lm83 index 74aa7ee1a359..f7aad1489cb0 100644 --- a/Documentation/hwmon/lm83 +++ b/Documentation/hwmon/lm83 @@ -35,6 +35,7 @@ contact us. Note that the LM90 can easily be misdetected as a LM83. Confirmed motherboards: SBS P014 + SBS PSL09 Unconfirmed motherboards: Gigabyte GA-8IK1100 -- cgit v1.2.2 From 0d0001dd956d4ae2c8739c2877fa660eec68ed5f Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Tue, 25 Apr 2006 14:23:01 +0200 Subject: [PATCH] HWMON: Improve the help text for CONFIG_HWMON Improve the help text for CONFIG_HWMON to let the users know how they pick the right hardware monitoring driver(s) for their system. Also fix a couple typos in the related documentation file and improve some parts a bit. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/hwmon/userspace-tools | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/userspace-tools b/Documentation/hwmon/userspace-tools index 2622aac65422..19900a8fe679 100644 --- a/Documentation/hwmon/userspace-tools +++ b/Documentation/hwmon/userspace-tools @@ -6,31 +6,32 @@ voltages, fans speed). They are often connected through an I2C bus, but some are also connected directly through the ISA bus. The kernel drivers make the data from the sensor chips available in the /sys -virtual filesystem. Userspace tools are then used to display or set or the -data in a more friendly manner. +virtual filesystem. Userspace tools are then used to display the measured +values or configure the chips in a more friendly manner. Lm-sensors ---------- -Core set of utilites that will allow you to obtain health information, +Core set of utilities that will allow you to obtain health information, setup monitoring limits etc. You can get them on their homepage http://www.lm-sensors.nu/ or as a package from your Linux distribution. If from website: -Get lmsensors from project web site. Please note, you need only userspace -part, so compile with "make user_install" target. +Get lm-sensors from project web site. Please note, you need only userspace +part, so compile with "make user" and install with "make user_install". General hints to get things working: 0) get lm-sensors userspace utils -1) compile all drivers in I2C section as modules in your kernel +1) compile all drivers in I2C and Hardware Monitoring sections as modules + in your kernel 2) run sensors-detect script, it will tell you what modules you need to load. 3) load them and run "sensors" command, you should see some results. 4) fix sensors.conf, labels, limits, fan divisors 5) if any more problems consult FAQ, or documentation -Other utilites --------------- +Other utilities +--------------- If you want some graphical indicators of system health look for applications like: gkrellm, ksensors, xsensors, wmtemp, wmsensors, wmgtemp, ksysguardd, -- cgit v1.2.2 From 18f98b1e3147afdb51e545cc6ff2b016c7d088a7 Mon Sep 17 00:00:00 2001 From: Peter Korsgaard Date: Sun, 4 Jun 2006 20:01:08 +0200 Subject: [PATCH] i2c: New bus driver for the OpenCores I2C controller The following patch adds support for the OpenCores I2C controller IP core (See http://www.opencores.org/projects.cgi/web/i2c/overview). Signed-off-by: Peter Korsgaard Signed-off-by: Andrew Morton Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/busses/i2c-ocores | 51 +++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 Documentation/i2c/busses/i2c-ocores (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-ocores b/Documentation/i2c/busses/i2c-ocores new file mode 100644 index 000000000000..cfcebb10d14e --- /dev/null +++ b/Documentation/i2c/busses/i2c-ocores @@ -0,0 +1,51 @@ +Kernel driver i2c-ocores + +Supported adapters: + * OpenCores.org I2C controller by Richard Herveille (see datasheet link) + Datasheet: http://www.opencores.org/projects.cgi/web/i2c/overview + +Author: Peter Korsgaard + +Description +----------- + +i2c-ocores is an i2c bus driver for the OpenCores.org I2C controller +IP core by Richard Herveille. + +Usage +----- + +i2c-ocores uses the platform bus, so you need to provide a struct +platform_device with the base address and interrupt number. The +dev.platform_data of the device should also point to a struct +ocores_i2c_platform_data (see linux/i2c-ocores.h) describing the +distance between registers and the input clock speed. + +E.G. something like: + +static struct resource ocores_resources[] = { + [0] = { + .start = MYI2C_BASEADDR, + .end = MYI2C_BASEADDR + 8, + .flags = IORESOURCE_MEM, + }, + [1] = { + .start = MYI2C_IRQ, + .end = MYI2C_IRQ, + .flags = IORESOURCE_IRQ, + }, +}; + +static struct ocores_i2c_platform_data myi2c_data = { + .regstep = 2, /* two bytes between registers */ + .clock_khz = 50000, /* input clock of 50MHz */ +}; + +static struct platform_device myi2c = { + .name = "ocores-i2c", + .dev = { + .platform_data = &myi2c_data, + }, + .num_resources = ARRAY_SIZE(ocores_resources), + .resource = ocores_resources, +}; -- cgit v1.2.2 From 057bc350992fa2ac31fcd2ff80add269bdf32a80 Mon Sep 17 00:00:00 2001 From: Rudolf Marek Date: Sun, 4 Jun 2006 20:03:39 +0200 Subject: [PATCH] hwmon: Sysfs interface documentation update, 1 of 2 This patch cleans up hwmon sysfs documentation file, plus introduces the description of DC/PWM selection for fan speed control. Signed-off-by: Rudolf Marek Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/hwmon/sysfs-interface | 181 +++++++++++++++++++++--------------- 1 file changed, 107 insertions(+), 74 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index eeb912254db4..bc59a5113d17 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -69,28 +69,37 @@ to cause an alarm) is chip-dependent. ------------------------------------------------------------------------- +[0-*] denotes any positive number starting from 0 +[1-*] denotes any positive number starting from 1 +RO read only value +RW read/write value + +Read/write values may be read-only for some chips, depending on the +hardware implementation. + ************ * Voltages * ************ -in[0-8]_min Voltage min value. +in[0-*]_min Voltage min value. Unit: millivolt - Read/Write + RW -in[0-8]_max Voltage max value. +in[0-*]_max Voltage max value. Unit: millivolt - Read/Write + RW -in[0-8]_input Voltage input value. +in[0-*]_input Voltage input value. Unit: millivolt - Read only + RO + Voltage measured on the chip pin. Actual voltage depends on the scaling resistors on the motherboard, as recommended in the chip datasheet. This varies by chip and by motherboard. Because of this variation, values are generally NOT scaled by the chip driver, and must be done by the application. However, some drivers (notably lm87 and via686a) - do scale, with various degrees of success. + do scale, because of internal resistors built into a chip. These drivers will output the actual voltage. Typical usage: @@ -104,58 +113,72 @@ in[0-8]_input Voltage input value. in7_* varies in8_* varies -cpu[0-1]_vid CPU core reference voltage. +cpu[0-*]_vid CPU core reference voltage. Unit: millivolt - Read only. + RO Not always correct. vrm Voltage Regulator Module version number. - Read only. - Two digit number, first is major version, second is - minor version. + RW (but changing it should no more be necessary) + Originally the VRM standard version multiplied by 10, but now + an arbitrary number, as not all standards have a version + number. Affects the way the driver calculates the CPU core reference voltage from the vid pins. +Also see the Alarms section for status flags associated with voltages. + ******** * Fans * ******** -fan[1-3]_min Fan minimum value +fan[1-*]_min Fan minimum value Unit: revolution/min (RPM) - Read/Write. + RW -fan[1-3]_input Fan input value. +fan[1-*]_input Fan input value. Unit: revolution/min (RPM) - Read only. + RO -fan[1-3]_div Fan divisor. +fan[1-*]_div Fan divisor. Integer value in powers of two (1, 2, 4, 8, 16, 32, 64, 128). + RW Some chips only support values 1, 2, 4 and 8. Note that this is actually an internal clock divisor, which affects the measurable speed range, not the read value. +Also see the Alarms section for status flags associated with fans. + + ******* * PWM * ******* -pwm[1-3] Pulse width modulation fan control. +pwm[1-*] Pulse width modulation fan control. Integer value in the range 0 to 255 - Read/Write + RW 255 is max or 100%. -pwm[1-3]_enable +pwm[1-*]_enable Switch PWM on and off. Not always present even if fan*_pwm is. - 0 to turn off - 1 to turn on in manual mode - 2 to turn on in automatic mode - Read/Write + 0: turn off + 1: turn on in manual mode + 2+: turn on in automatic mode + Check individual chip documentation files for automatic mode details. + RW + +pwm[1-*]_mode + 0: DC mode + 1: PWM mode + RW pwm[1-*]_auto_channels_temp Select which temperature channels affect this PWM output in auto mode. Bitfield, 1 is temp1, 2 is temp2, 4 is temp3 etc... Which values are possible depend on the chip used. + RW pwm[1-*]_auto_point[1-*]_pwm pwm[1-*]_auto_point[1-*]_temp @@ -163,6 +186,7 @@ pwm[1-*]_auto_point[1-*]_temp_hyst Define the PWM vs temperature curve. Number of trip points is chip-dependent. Use this for chips which associate trip points to PWM output channels. + RW OR @@ -172,51 +196,52 @@ temp[1-*]_auto_point[1-*]_temp_hyst Define the PWM vs temperature curve. Number of trip points is chip-dependent. Use this for chips which associate trip points to temperature channels. + RW **************** * Temperatures * **************** -temp[1-3]_type Sensor type selection. +temp[1-*]_type Sensor type selection. Integers 1 to 4 or thermistor Beta value (typically 3435) - Read/Write. + RW 1: PII/Celeron Diode 2: 3904 transistor 3: thermal diode 4: thermistor (default/unknown Beta) Not all types are supported by all chips -temp[1-4]_max Temperature max value. +temp[1-*]_max Temperature max value. Unit: millidegree Celcius - Read/Write value. + RW -temp[1-3]_min Temperature min value. +temp[1-*]_min Temperature min value. Unit: millidegree Celcius - Read/Write value. + RW -temp[1-3]_max_hyst +temp[1-*]_max_hyst Temperature hysteresis value for max limit. Unit: millidegree Celcius Must be reported as an absolute temperature, NOT a delta from the max value. - Read/Write value. + RW -temp[1-4]_input Temperature input value. +temp[1-*]_input Temperature input value. Unit: millidegree Celcius - Read only value. + RO -temp[1-4]_crit Temperature critical value, typically greater than +temp[1-*]_crit Temperature critical value, typically greater than corresponding temp_max values. Unit: millidegree Celcius - Read/Write value. + RW -temp[1-2]_crit_hyst +temp[1-*]_crit_hyst Temperature hysteresis value for critical limit. Unit: millidegree Celcius Must be reported as an absolute temperature, NOT a delta from the critical value. - Read/Write value. + RW temp[1-4]_offset Temperature offset which is added to the temperature reading @@ -231,6 +256,8 @@ temp[1-4]_offset itself, for example the thermal diode inside the CPU or a thermistor nearby. +Also see the Alarms section for status flags associated with temperatures. + ************ * Currents * @@ -239,17 +266,17 @@ temp[1-4]_offset Note that no known chip provides current measurements as of writing, so this part is theoretical, so to say. -curr[1-n]_max Current max value +curr[1-*]_max Current max value Unit: milliampere - Read/Write. + RW -curr[1-n]_min Current min value. +curr[1-*]_min Current min value. Unit: milliampere - Read/Write. + RW -curr[1-n]_input Current input value +curr[1-*]_input Current input value Unit: milliampere - Read only. + RO ********** @@ -263,50 +290,54 @@ Usually a given chip will either use channel-related alarms, or limit-related alarms, not both. The driver should just reflect the hardware implementation. -in[0-n]_alarm -fan[1-n]_alarm -temp[1-n]_alarm +in[0-*]_alarm +fan[1-*]_alarm +temp[1-*]_alarm Channel alarm - Boolean - Read-only + 0: no alarm + 1: alarm + RO OR -in[0-n]_min_alarm -in[0-n]_max_alarm -fan[1-n]_min_alarm -temp[1-n]_min_alarm -temp[1-n]_max_alarm -temp[1-n]_crit_alarm +in[0-*]_min_alarm +in[0-*]_max_alarm +fan[1-*]_min_alarm +temp[1-*]_min_alarm +temp[1-*]_max_alarm +temp[1-*]_crit_alarm Limit alarm - Boolean - Read-only + 0: no alarm + 1: alarm + RO Each input channel may have an associated fault file. This can be used to notify open diodes, unconnected fans etc. where the hardware supports it. When this boolean has value 1, the measurement for that channel should not be trusted. -in[0-n]_input_fault -fan[1-n]_input_fault -temp[1-n]_input_fault +in[0-*]_input_fault +fan[1-*]_input_fault +temp[1-*]_input_fault Input fault condition - Boolean - Read-only + 0: no fault occured + 1: fault condition + RO Some chips also offer the possibility to get beeped when an alarm occurs: beep_enable Master beep enable - Boolean - Read/Write + 0: no beeps + 1: beeps + RW -in[0-n]_beep -fan[1-n]_beep -temp[1-n]_beep +in[0-*]_beep +fan[1-*]_beep +temp[1-*]_beep Channel beep - 0 to disable. - 1 to enable. - Read/write + 0: disable + 1: enable + RW In theory, a chip could provide per-limit beep masking, but no such chip was seen so far. @@ -316,7 +347,7 @@ beeps. These interface files are deprecated, but will be kept around for compatibility reasons: alarms Alarm bitmask. - Read only. + RO Integer representation of one to four bytes. A '1' bit means an alarm. Chips should be programmed for 'comparator' mode so that @@ -333,7 +364,7 @@ beep_mask Bitmask for beep. Same format as 'alarms' with the same bit locations, use discouraged for the same reason. Use individual *_beep files instead. - Read/Write + RW ********* @@ -341,7 +372,9 @@ beep_mask Bitmask for beep. ********* eeprom Raw EEPROM data in binary form. - Read only. + RO pec Enable or disable PEC (SMBus only) - Read/Write + 0: disable + 1: enable + RW -- cgit v1.2.2 From 740e06a89fb905ee1979c57442c544afe51ed21c Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Mon, 5 Jun 2006 20:31:20 +0200 Subject: [PATCH] hwmon: Sysfs interface documentation update, 2 of 2, take 2 Reword and complete certain parts of the hwmon sysfs-interface documentation file. Hopefully this will make things clearer for new driver authors. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/hwmon/sysfs-interface | 45 ++++++++++++++++++++++++------------- 1 file changed, 29 insertions(+), 16 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index bc59a5113d17..d1d390aaf620 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -3,15 +3,15 @@ Naming and data format standards for sysfs files The libsensors library offers an interface to the raw sensors data through the sysfs interface. See libsensors documentation and source for -more further information. As of writing this document, libsensors -(from lm_sensors 2.8.3) is heavily chip-dependant. Adding or updating +further information. As of writing this document, libsensors +(from lm_sensors 2.8.3) is heavily chip-dependent. Adding or updating support for any given chip requires modifying the library's code. This is because libsensors was written for the procfs interface older kernel modules were using, which wasn't standardized enough. Recent versions of libsensors (from lm_sensors 2.8.2 and later) have support for the sysfs interface, though. -The new sysfs interface was designed to be as chip-independant as +The new sysfs interface was designed to be as chip-independent as possible. Note that motherboards vary widely in the connections to sensor chips. @@ -24,7 +24,7 @@ range using external resistors. Since the values of these resistors can change from motherboard to motherboard, the conversions cannot be hard coded into the driver and have to be done in user space. -For this reason, even if we aim at a chip-independant libsensors, it will +For this reason, even if we aim at a chip-independent libsensors, it will still require a configuration file (e.g. /etc/sensors.conf) for proper values conversion, labeling of inputs and hiding of unused inputs. @@ -39,15 +39,16 @@ If you are developing a userspace application please send us feedback on this standard. Note that this standard isn't completely established yet, so it is subject -to changes, even important ones. One more reason to use the library instead -of accessing sysfs files directly. +to changes. If you are writing a new hardware monitoring driver those +features can't seem to fit in this interface, please contact us with your +extension proposal. Keep in mind that backward compatibility must be +preserved. Each chip gets its own directory in the sysfs /sys/devices tree. To -find all sensor chips, it is easier to follow the symlinks from -/sys/i2c/devices/ +find all sensor chips, it is easier to follow the device symlinks from +/sys/class/hwmon/hwmon*. -All sysfs values are fixed point numbers. To get the true value of some -of the values, you should divide by the specified value. +All sysfs values are fixed point numbers. There is only one value per file, unlike the older /proc specification. The common scheme for files naming is: _. Usual @@ -77,6 +78,9 @@ RW read/write value Read/write values may be read-only for some chips, depending on the hardware implementation. +All entries are optional, and should only be created in a given driver +if the chip has the feature. + ************ * Voltages * ************ @@ -213,32 +217,32 @@ temp[1-*]_type Sensor type selection. Not all types are supported by all chips temp[1-*]_max Temperature max value. - Unit: millidegree Celcius + Unit: millidegree Celsius (or millivolt, see below) RW temp[1-*]_min Temperature min value. - Unit: millidegree Celcius + Unit: millidegree Celsius RW temp[1-*]_max_hyst Temperature hysteresis value for max limit. - Unit: millidegree Celcius + Unit: millidegree Celsius Must be reported as an absolute temperature, NOT a delta from the max value. RW temp[1-*]_input Temperature input value. - Unit: millidegree Celcius + Unit: millidegree Celsius RO temp[1-*]_crit Temperature critical value, typically greater than corresponding temp_max values. - Unit: millidegree Celcius + Unit: millidegree Celsius RW temp[1-*]_crit_hyst Temperature hysteresis value for critical limit. - Unit: millidegree Celcius + Unit: millidegree Celsius Must be reported as an absolute temperature, NOT a delta from the critical value. RW @@ -256,6 +260,15 @@ temp[1-4]_offset itself, for example the thermal diode inside the CPU or a thermistor nearby. +Some chips measure temperature using external thermistors and an ADC, and +report the temperature measurement as a voltage. Converting this voltage +back to a temperature (or the other way around for limits) requires +mathematical functions not available in the kernel, so the conversion +must occur in user space. For these chips, all temp* files described +above should contain values expressed in millivolt instead of millidegree +Celsius. In other words, such temperature channels are handled as voltage +channels by the driver. + Also see the Alarms section for status flags associated with temperatures. -- cgit v1.2.2 From f2b84bbcebfdbe4855bab532909eef6621999f9f Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Sun, 4 Jun 2006 20:22:24 +0200 Subject: [PATCH] abituguru: New hardware monitoring driver New hardware monitoring driver for the Abit uGuru Signed-off-by: Hans de Goede Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/hwmon/abituguru | 59 ++++++ Documentation/hwmon/abituguru-datasheet | 312 ++++++++++++++++++++++++++++++++ 2 files changed, 371 insertions(+) create mode 100644 Documentation/hwmon/abituguru create mode 100644 Documentation/hwmon/abituguru-datasheet (limited to 'Documentation') diff --git a/Documentation/hwmon/abituguru b/Documentation/hwmon/abituguru new file mode 100644 index 000000000000..69cdb527d58f --- /dev/null +++ b/Documentation/hwmon/abituguru @@ -0,0 +1,59 @@ +Kernel driver abituguru +======================= + +Supported chips: + * Abit uGuru (Hardware Monitor part only) + Prefix: 'abituguru' + Addresses scanned: ISA 0x0E0 + Datasheet: Not available, this driver is based on reverse engineering. + A "Datasheet" has been written based on the reverse engineering it + should be available in the same dir as this file under the name + abituguru-datasheet. + +Authors: + Hans de Goede , + (Initial reverse engineering done by Olle Sandberg + ) + + +Module Parameters +----------------- + +* force: bool Force detection. Note this parameter only causes the + detection to be skipped, if the uGuru can't be read + the module initialization (insmod) will still fail. +* fan_sensors: int Tell the driver how many fan speed sensors there are + on your motherboard. Default: 0 (autodetect). +* pwms: int Tell the driver how many fan speed controls (fan + pwms) your motherboard has. Default: 0 (autodetect). +* verbose: int How verbose should the driver be? (0-3): + 0 normal output + 1 + verbose error reporting + 2 + sensors type probing info\n" + 3 + retryable error reporting + Default: 2 (the driver is still in the testing phase) + +Notice if you need any of the first three options above please insmod the +driver with verbose set to 3 and mail me the output of: +dmesg | grep abituguru + + +Description +----------- + +This driver supports the hardware monitoring features of the Abit uGuru chip +found on Abit uGuru featuring motherboards (most modern Abit motherboards). + +The uGuru chip in reality is a Winbond W83L950D in disguise (despite Abit +claiming it is "a new microprocessor designed by the ABIT Engineers"). +Unfortunatly this doesn't help since the W83L950D is a generic +microcontroller with a custom Abit application running on it. + +Despite Abit not releasing any information regarding the uGuru, Olle +Sandberg has managed to reverse engineer the sensor part +of the uGuru. Without his work this driver would not have been possible. + +Known Issues +------------ + +The voltage and frequency control parts of the Abit uGuru are not supported. diff --git a/Documentation/hwmon/abituguru-datasheet b/Documentation/hwmon/abituguru-datasheet new file mode 100644 index 000000000000..aef5a9b36846 --- /dev/null +++ b/Documentation/hwmon/abituguru-datasheet @@ -0,0 +1,312 @@ +uGuru datasheet +=============== + +First of all, what I know about uGuru is no fact based on any help, hints or +datasheet from Abit. The data I have got on uGuru have I assembled through +my weak knowledge in "backwards engineering". +And just for the record, you may have noticed uGuru isn't a chip developed by +Abit, as they claim it to be. It's realy just an microprocessor (uC) created by +Winbond (W83L950D). And no, reading the manual for this specific uC or +mailing Windbond for help won't give any usefull data about uGuru, as it is +the program inside the uC that is responding to calls. + +Olle Sandberg , 2005-05-25 + + +Original version by Olle Sandberg who did the heavy lifting of the initial +reverse engineering. This version has been almost fully rewritten for clarity +and extended with write support and info on more databanks, the write support +is once again reverse engineered by Olle the additional databanks have been +reverse engineered by me. I would like to express my thanks to Olle, this +document and the Linux driver could not have been written without his efforts. + +Note: because of the lack of specs only the sensors part of the uGuru is +described here and not the CPU / RAM / etc voltage & frequency control. + +Hans de Goede , 28-01-2006 + + +Detection +========= + +As far as known the uGuru is always placed at and using the (ISA) I/O-ports +0xE0 and 0xE4, so we don't have to scan any port-range, just check what the two +ports are holding for detection. We will refer to 0xE0 as CMD (command-port) +and 0xE4 as DATA because Abit refers to them with these names. + +If DATA holds 0x00 or 0x08 and CMD holds 0x00 or 0xAC an uGuru could be +present. We have to check for two different values at data-port, because +after a reboot uGuru will hold 0x00 here, but if the driver is removed and +later on attached again data-port will hold 0x08, more about this later. + +After wider testing of the Linux kernel driver some variants of the uGuru have +turned up which will hold 0x00 instead of 0xAC at the CMD port, thus we also +have to test CMD for two different values. On these uGuru's DATA will initally +hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read +first! + +To be really sure an uGuru is present a test read of one or more register +sets should be done. + + +Reading / Writing +================= + +Addressing +---------- + +The uGuru has a number of different addressing levels. The first addressing +level we will call banks. A bank holds data for one or more sensors. The data +in a bank for a sensor is one or more bytes large. + +The number of bytes is fixed for a given bank, you should always read or write +that many bytes, reading / writing more will fail, the results when writing +less then the number of bytes for a given bank are undetermined. + +See below for all known bank addresses, numbers of sensors in that bank, +number of bytes data per sensor and contents/meaning of those bytes. + +Although both this document and the kernel driver have kept the sensor +terminoligy for the addressing within a bank this is not 100% correct, in +bank 0x24 for example the addressing within the bank selects a PWM output not +a sensor. + +Notice that some banks have both a read and a write address this is how the +uGuru determines if a read from or a write to the bank is taking place, thus +when reading you should always use the read address and when writing the +write address. The write address is always one (1) more then the read address. + + +uGuru ready +----------- + +Before you can read from or write to the uGuru you must first put the uGuru +in "ready" mode. + +To put the uGuru in ready mode first write 0x00 to DATA and then wait for DATA +to hold 0x09, DATA should read 0x09 within 250 read cycles. + +Next CMD _must_ be read and should hold 0xAC, usually CMD will hold 0xAC the +first read but sometimes it takes a while before CMD holds 0xAC and thus it +has to be read a number of times (max 50). + +After reading CMD, DATA should hold 0x08 which means that the uGuru is ready +for input. As above DATA will usually hold 0x08 the first read but not always. +This step can be skipped, but it is undetermined what happens if the uGuru has +not yet reported 0x08 at DATA and you proceed with writing a bank address. + + +Sending bank and sensor addresses to the uGuru +---------------------------------------------- + +First the uGuru must be in "ready" mode as described above, DATA should hold +0x08 indicating that the uGuru wants input, in this case the bank address. + +Next write the bank address to DATA. After the bank address has been written +wait for to DATA to hold 0x08 again indicating that it wants / is ready for +more input (max 250 reads). + +Once DATA holds 0x08 again write the sensor address to CMD. + + +Reading +------- + +First send the bank and sensor addresses as described above. +Then for each byte of data you want to read wait for DATA to hold 0x01 +which indicates that the uGuru is ready to be read (max 250 reads) and once +DATA holds 0x01 read the byte from CMD. + +Once all bytes have been read data will hold 0x09, but there is no reason to +test for this. Notice that the number of bytes is bank address dependent see +above and below. + +After completing a successfull read it is advised to put the uGuru back in +ready mode, so that it is ready for the next read / write cycle. This way +if your program / driver is unloaded and later loaded again the detection +algorithm described above will still work. + + + +Writing +------- + +First send the bank and sensor addresses as described above. +Then for each byte of data you want to write wait for DATA to hold 0x00 +which indicates that the uGuru is ready to be written (max 250 reads) and +once DATA holds 0x00 write the byte to CMD. + +Once all bytes have been written wait for DATA to hold 0x01 (max 250 reads) +don't ask why this is the way it is. + +Once DATA holds 0x01 read CMD it should hold 0xAC now. + +After completing a successfull write it is advised to put the uGuru back in +ready mode, so that it is ready for the next read / write cycle. This way +if your program / driver is unloaded and later loaded again the detection +algorithm described above will still work. + + +Gotchas +------- + +After wider testing of the Linux kernel driver some variants of the uGuru have +turned up which do not hold 0x08 at DATA within 250 reads after writing the +bank address. With these versions this happens quite frequent, using larger +timeouts doesn't help, they just go offline for a second or 2, doing some +internal callibration or whatever. Your code should be prepared to handle +this and in case of no response in this specific case just goto sleep for a +while and then retry. + + +Address Map +=========== + +Bank 0x20 Alarms (R) +-------------------- +This bank contains 0 sensors, iow the sensor address is ignored (but must be +written) just use 0. Bank 0x20 contains 3 bytes: + +Byte 0: +This byte holds the alarm flags for sensor 0-7 of Sensor Bank1, with bit 0 +corresponding to sensor 0, 1 to 1, etc. + +Byte 1: +This byte holds the alarm flags for sensor 8-15 of Sensor Bank1, with bit 0 +corresponding to sensor 8, 1 to 9, etc. + +Byte 2: +This byte holds the alarm flags for sensor 0-5 of Sensor Bank2, with bit 0 +corresponding to sensor 0, 1 to 1, etc. + + +Bank 0x21 Sensor Bank1 Values / Readings (R) +-------------------------------------------- +This bank contains 16 sensors, for each sensor it contains 1 byte. +So far the following sensors are known to be available on all motherboards: +Sensor 0 CPU temp +Sensor 1 SYS temp +Sensor 3 CPU core volt +Sensor 4 DDR volt +Sensor 10 DDR Vtt volt +Sensor 15 PWM temp + +Byte 0: +This byte holds the reading from the sensor. Sensors in Bank1 can be both +volt and temp sensors, this is motherboard specific. The uGuru however does +seem to know (be programmed with) what kindoff sensor is attached see Sensor +Bank1 Settings description. + +Volt sensors use a linear scale, a reading 0 corresponds with 0 volt and a +reading of 255 with 3494 mV. The sensors for higher voltages however are +connected through a division circuit. The currently known division circuits +in use result in ranges of: 0-4361mV, 0-6248mV or 0-14510mV. 3.3 volt sources +use the 0-4361mV range, 5 volt the 0-6248mV and 12 volt the 0-14510mV . + +Temp sensors also use a linear scale, a reading of 0 corresponds with 0 degree +Celsius and a reading of 255 with a reading of 255 degrees Celsius. + + +Bank 0x22 Sensor Bank1 Settings (R) +Bank 0x23 Sensor Bank1 Settings (W) +----------------------------------- + +This bank contains 16 sensors, for each sensor it contains 3 bytes. Each +set of 3 bytes contains the settings for the sensor with the same sensor +address in Bank 0x21 . + +Byte 0: +Alarm behaviour for the selected sensor. A 1 enables the described behaviour. +Bit 0: Give an alarm if measured temp is over the warning threshold (RW) * +Bit 1: Give an alarm if measured volt is over the max threshold (RW) ** +Bit 2: Give an alarm if measured volt is under the min threshold (RW) ** +Bit 3: Beep if alarm (RW) +Bit 4: 1 if alarm cause measured temp is over the warning threshold (R) +Bit 5: 1 if alarm cause measured volt is over the max threshold (R) +Bit 6: 1 if alarm cause measured volt is under the min threshold (R) +Bit 7: Volt sensor: Shutdown if alarm persist for more then 4 seconds (RW) + Temp sensor: Shutdown if temp is over the shutdown threshold (RW) + +* This bit is only honored/used by the uGuru if a temp sensor is connected +** This bit is only honored/used by the uGuru if a volt sensor is connected +Note with some trickery this can be used to find out what kinda sensor is +detected see the Linux kernel driver for an example with many comments on +how todo this. + +Byte 1: +Temp sensor: warning threshold (scale as bank 0x21) +Volt sensor: min threshold (scale as bank 0x21) + +Byte 2: +Temp sensor: shutdown threshold (scale as bank 0x21) +Volt sensor: max threshold (scale as bank 0x21) + + +Bank 0x24 PWM outputs for FAN's (R) +Bank 0x25 PWM outputs for FAN's (W) +----------------------------------- + +This bank contains 3 "sensors", for each sensor it contains 5 bytes. +Sensor 0 usually controls the CPU fan +Sensor 1 usually controls the NB (or chipset for single chip) fan +Sensor 2 usually controls the System fan + +Byte 0: +Flag 0x80 to enable control, Fan runs at 100% when disabled. +low nibble (temp)sensor address at bank 0x21 used for control. + +Byte 1: +0-255 = 0-12v (linear), specify voltage at which fan will rotate when under +low threshold temp (specified in byte 3) + +Byte 2: +0-255 = 0-12v (linear), specify voltage at which fan will rotate when above +high threshold temp (specified in byte 4) + +Byte 3: +Low threshold temp (scale as bank 0x21) + +byte 4: +High threshold temp (scale as bank 0x21) + + +Bank 0x26 Sensors Bank2 Values / Readings (R) +--------------------------------------------- + +This bank contains 6 sensors (AFAIK), for each sensor it contains 1 byte. +So far the following sensors are known to be available on all motherboards: +Sensor 0: CPU fan speed +Sensor 1: NB (or chipset for single chip) fan speed +Sensor 2: SYS fan speed + +Byte 0: +This byte holds the reading from the sensor. 0-255 = 0-15300 (linear) + + +Bank 0x27 Sensors Bank2 Settings (R) +Bank 0x28 Sensors Bank2 Settings (W) +------------------------------------ + +This bank contains 6 sensors (AFAIK), for each sensor it contains 2 bytes. + +Byte 0: +Alarm behaviour for the selected sensor. A 1 enables the described behaviour. +Bit 0: Give an alarm if measured rpm is under the min threshold (RW) +Bit 3: Beep if alarm (RW) +Bit 7: Shutdown if alarm persist for more then 4 seconds (RW) + +Byte 1: +min threshold (scale as bank 0x26) + + +Warning for the adventerous +=========================== + +A word of caution to those who want to experiment and see if they can figure +the voltage / clock programming out, I tried reading and only reading banks +0-0x30 with the reading code used for the sensor banks (0x20-0x28) and this +resulted in a _permanent_ reprogramming of the voltages, luckily I had the +sensors part configured so that it would shutdown my system on any out of spec +voltages which proprably safed my computer (after a reboot I managed to +immediatly enter the bios and reload the defaults). This probably means that +the read/write cycle for the non sensor part is different from the sensor part. -- cgit v1.2.2 From 62aaa288ab0425b058fd337c5135a32e8c1aeace Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Mon, 12 Jun 2006 21:48:08 +0200 Subject: [PATCH] scx200_acb: Documentation update Documentation update for the scx200_acb driver. Hopefully this will help future users. References: [lm-sensors] Support of i2c-nscacb (April, May 2005) http://lists.lm-sensors.org/pipermail/lm-sensors/2005-April/011756.html http://lists.lm-sensors.org/pipermail/lm-sensors/2005-May/012043.html [lm-sensors] making a geode i2c slave driver (April 2006) http://lists.lm-sensors.org/pipermail/lm-sensors/2006-April/015998.html Kernel bug #6445 http://bugzilla.kernel.org/show_bug.cgi?id=6445 Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/busses/scx200_acb | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/i2c/busses/scx200_acb b/Documentation/i2c/busses/scx200_acb index f50e69981ec6..7c07883d4dfc 100644 --- a/Documentation/i2c/busses/scx200_acb +++ b/Documentation/i2c/busses/scx200_acb @@ -2,14 +2,31 @@ Kernel driver scx200_acb Author: Christer Weinigel +The driver supersedes the older, never merged driver named i2c-nscacb. + Module Parameters ----------------- -* base: int +* base: up to 4 ints Base addresses for the ACCESS.bus controllers on SCx200 and SC1100 devices + By default the driver uses two base addresses 0x820 and 0x840. + If you want only one base address, specify the second as 0 so as to + override this default. + Description ----------- Enable the use of the ACCESS.bus controller on the Geode SCx200 and SC1100 processors and the CS5535 and CS5536 Geode companion devices. + +Device-specific notes +--------------------- + +The SC1100 WRAP boards are known to use base addresses 0x810 and 0x820. +If the scx200_acb driver is built into the kernel, add the following +parameter to your boot command line: + scx200_acb.base=0x810,0x820 +If the scx200_acb driver is built as a module, add the following line to +the file /etc/modprobe.conf instead: + options scx200_acb base=0x810,0x820 -- cgit v1.2.2 From d8db8f98562c1e358e42503bb920f75f15a5c6d2 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Mon, 12 Jun 2006 21:50:11 +0200 Subject: [PATCH] i2c-i801: Remove force_addr parameter i2c-i801: Remove force_addr parameter Remove the force_addr module parameter. It doesn't appear to ever have been needed, and PCI resources shouldn't be arbitrarily changed anyway. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/busses/i2c-i801 | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index fd4b2712d570..e46c23458242 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -21,8 +21,7 @@ Authors: Module Parameters ----------------- -* force_addr: int - Forcibly enable the ICH at the given address. EXTREMELY DANGEROUS! +None. Description -- cgit v1.2.2 From e1a8e913f97e36cc5a23a24a8b4717e84998f13c Mon Sep 17 00:00:00 2001 From: Kaiwan N Billimoria Date: Mon, 12 Jun 2006 22:00:05 +0200 Subject: [PATCH] lm70: New hardware monitoring driver This driver implements support for the National Semiconductor LM70 temperature sensor. The LM70 temperature sensor chip supports a single temperature sensor. It communicates with a host processor (or microcontroller) via an SPI/Microwire Bus interface. Communication with the LM70 is simple: when the temperature is to be sensed, the driver accesses the LM70 using SPI communication: 16 SCLK cycles comprise the MOSI/MISO loop. At the end of the transfer, the 11-bit 2's complement digital temperature (sent via the SIO line), is available in the driver for interpretation. This driver makes use of the kernel's in-core SPI support. Signed-off-by: Kaiwan N Billimoria Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/hwmon/lm70 | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 Documentation/hwmon/lm70 (limited to 'Documentation') diff --git a/Documentation/hwmon/lm70 b/Documentation/hwmon/lm70 new file mode 100644 index 000000000000..2bdd3feebf53 --- /dev/null +++ b/Documentation/hwmon/lm70 @@ -0,0 +1,31 @@ +Kernel driver lm70 +================== + +Supported chip: + * National Semiconductor LM70 + Datasheet: http://www.national.com/pf/LM/LM70.html + +Author: + Kaiwan N Billimoria + +Description +----------- + +This driver implements support for the National Semiconductor LM70 +temperature sensor. + +The LM70 temperature sensor chip supports a single temperature sensor. +It communicates with a host processor (or microcontroller) via an +SPI/Microwire Bus interface. + +Communication with the LM70 is simple: when the temperature is to be sensed, +the driver accesses the LM70 using SPI communication: 16 SCLK cycles +comprise the MOSI/MISO loop. At the end of the transfer, the 11-bit 2's +complement digital temperature (sent via the SIO line), is available in the +driver for interpretation. This driver makes use of the kernel's in-core +SPI support. + +Thanks to +--------- +Jean Delvare for mentoring the hwmon-side driver +development. -- cgit v1.2.2