diff options
author | Russell King <rmk+kernel@arm.linux.org.uk> | 2009-09-24 21:22:33 +0100 |
---|---|---|
committer | Russell King <rmk+kernel@arm.linux.org.uk> | 2009-09-24 21:22:33 +0100 |
commit | baea7b946f00a291b166ccae7fcfed6c01530cc6 (patch) | |
tree | 4aa275fbdbec9c7b9b4629e8bee2bbecd3c6a6af /Documentation/hwmon | |
parent | ae19ffbadc1b2100285a5b5b3d0a4e0a11390904 (diff) | |
parent | 94e0fb086fc5663c38bbc0fe86d698be8314f82f (diff) |
Merge branch 'origin' into for-linus
Conflicts:
MAINTAINERS
Diffstat (limited to 'Documentation/hwmon')
-rw-r--r-- | Documentation/hwmon/acpi_power_meter | 51 | ||||
-rw-r--r-- | Documentation/hwmon/coretemp | 4 | ||||
-rw-r--r-- | Documentation/hwmon/fscher | 169 | ||||
-rw-r--r-- | Documentation/hwmon/hpfall.c | 115 | ||||
-rw-r--r-- | Documentation/hwmon/pc87427 | 2 | ||||
-rw-r--r-- | Documentation/hwmon/wm831x | 37 | ||||
-rw-r--r-- | Documentation/hwmon/wm8350 | 26 |
7 files changed, 198 insertions, 206 deletions
diff --git a/Documentation/hwmon/acpi_power_meter b/Documentation/hwmon/acpi_power_meter new file mode 100644 index 00000000000..c80399a00c5 --- /dev/null +++ b/Documentation/hwmon/acpi_power_meter @@ -0,0 +1,51 @@ +Kernel driver power_meter +========================= + +This driver talks to ACPI 4.0 power meters. + +Supported systems: + * Any recent system with ACPI 4.0. + Prefix: 'power_meter' + Datasheet: http://acpi.info/, section 10.4. + +Author: Darrick J. Wong + +Description +----------- + +This driver implements sensor reading support for the power meters exposed in +the ACPI 4.0 spec (Chapter 10.4). These devices have a simple set of +features--a power meter that returns average power use over a configurable +interval, an optional capping mechanism, and a couple of trip points. The +sysfs interface conforms with the specification outlined in the "Power" section +of Documentation/hwmon/sysfs-interface. + +Special Features +---------------- + +The power[1-*]_is_battery knob indicates if the power supply is a battery. +Both power[1-*]_average_{min,max} must be set before the trip points will work. +When both of them are set, an ACPI event will be broadcast on the ACPI netlink +socket and a poll notification will be sent to the appropriate +power[1-*]_average sysfs file. + +The power[1-*]_{model_number, serial_number, oem_info} fields display arbitrary +strings that ACPI provides with the meter. The measures/ directory contains +symlinks to the devices that this meter measures. + +Some computers have the ability to enforce a power cap in hardware. If this is +the case, the power[1-*]_cap and related sysfs files will appear. When the +average power consumption exceeds the cap, an ACPI event will be broadcast on +the netlink event socket and a poll notification will be sent to the +appropriate power[1-*]_alarm file to indicate that capping has begun, and the +hardware has taken action to reduce power consumption. Most likely this will +result in reduced performance. + +There are a few other ACPI notifications that can be sent by the firmware. In +all cases the ACPI event will be broadcast on the ACPI netlink event socket as +well as sent as a poll notification to a sysfs file. The events are as +follows: + +power[1-*]_cap will be notified if the firmware changes the power cap. +power[1-*]_interval will be notified if the firmware changes the averaging +interval. diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp index dbbe6c7025b..92267b62db5 100644 --- a/Documentation/hwmon/coretemp +++ b/Documentation/hwmon/coretemp @@ -4,7 +4,9 @@ Kernel driver coretemp Supported chips: * All Intel Core family Prefix: 'coretemp' - CPUID: family 0x6, models 0xe, 0xf, 0x16, 0x17 + CPUID: family 0x6, models 0xe (Pentium M DC), 0xf (Core 2 DC 65nm), + 0x16 (Core 2 SC 65nm), 0x17 (Penryn 45nm), + 0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield) Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide http://softwarecommunity.intel.com/Wiki/Mobility/720.htm diff --git a/Documentation/hwmon/fscher b/Documentation/hwmon/fscher deleted file mode 100644 index 64031659aff..00000000000 --- a/Documentation/hwmon/fscher +++ /dev/null @@ -1,169 +0,0 @@ -Kernel driver fscher -==================== - -Supported chips: - * Fujitsu-Siemens Hermes chip - Prefix: 'fscher' - Addresses scanned: I2C 0x73 - -Authors: - Reinhard Nissl <rnissl@gmx.de> based on work - from Hermann Jung <hej@odn.de>, - Frodo Looijaard <frodol@dds.nl>, - Philip Edelbrock <phil@netroedge.com> - -Description ------------ - -This driver implements support for the Fujitsu-Siemens Hermes chip. It is -described in the 'Register Set Specification BMC Hermes based Systemboard' -from Fujitsu-Siemens. - -The Hermes chip implements a hardware-based system management, e.g. for -controlling fan speed and core voltage. There is also a watchdog counter on -the chip which can trigger an alarm and even shut the system down. - -The chip provides three temperature values (CPU, motherboard and -auxiliary), three voltage values (+12V, +5V and battery) and three fans -(power supply, CPU and auxiliary). - -Temperatures are measured in degrees Celsius. The resolution is 1 degree. - -Fan rotation speeds are reported in RPM (rotations per minute). The value -can be divided by a programmable divider (1, 2 or 4) which is stored on -the chip. - -Voltage sensors (also known as "in" sensors) report their values in volts. - -All values are reported as final values from the driver. There is no need -for further calculations. - - -Detailed description --------------------- - -Below you'll find a single line description of all the bit values. With -this information, you're able to decode e. g. alarms, wdog, etc. To make -use of the watchdog, you'll need to set the watchdog time and enable the -watchdog. After that it is necessary to restart the watchdog time within -the specified period of time, or a system reset will occur. - -* revision - READING & 0xff = 0x??: HERMES revision identification - -* alarms - READING & 0x80 = 0x80: CPU throttling active - READING & 0x80 = 0x00: CPU running at full speed - - READING & 0x10 = 0x10: software event (see control:1) - READING & 0x10 = 0x00: no software event - - READING & 0x08 = 0x08: watchdog event (see wdog:2) - READING & 0x08 = 0x00: no watchdog event - - READING & 0x02 = 0x02: thermal event (see temp*:1) - READING & 0x02 = 0x00: no thermal event - - READING & 0x01 = 0x01: fan event (see fan*:1) - READING & 0x01 = 0x00: no fan event - - READING & 0x13 ! 0x00: ALERT LED is flashing - -* control - READING & 0x01 = 0x01: software event - READING & 0x01 = 0x00: no software event - - WRITING & 0x01 = 0x01: set software event - WRITING & 0x01 = 0x00: clear software event - -* watchdog_control - READING & 0x80 = 0x80: power off on watchdog event while thermal event - READING & 0x80 = 0x00: watchdog power off disabled (just system reset enabled) - - READING & 0x40 = 0x40: watchdog timebase 60 seconds (see also wdog:1) - READING & 0x40 = 0x00: watchdog timebase 2 seconds - - READING & 0x10 = 0x10: watchdog enabled - READING & 0x10 = 0x00: watchdog disabled - - WRITING & 0x80 = 0x80: enable "power off on watchdog event while thermal event" - WRITING & 0x80 = 0x00: disable "power off on watchdog event while thermal event" - - WRITING & 0x40 = 0x40: set watchdog timebase to 60 seconds - WRITING & 0x40 = 0x00: set watchdog timebase to 2 seconds - - WRITING & 0x20 = 0x20: disable watchdog - - WRITING & 0x10 = 0x10: enable watchdog / restart watchdog time - -* watchdog_state - READING & 0x02 = 0x02: watchdog system reset occurred - READING & 0x02 = 0x00: no watchdog system reset occurred - - WRITING & 0x02 = 0x02: clear watchdog event - -* watchdog_preset - READING & 0xff = 0x??: configured watch dog time in units (see wdog:3 0x40) - - WRITING & 0xff = 0x??: configure watch dog time in units - -* in* (0: +5V, 1: +12V, 2: onboard 3V battery) - READING: actual voltage value - -* temp*_status (1: CPU sensor, 2: onboard sensor, 3: auxiliary sensor) - READING & 0x02 = 0x02: thermal event (overtemperature) - READING & 0x02 = 0x00: no thermal event - - READING & 0x01 = 0x01: sensor is working - READING & 0x01 = 0x00: sensor is faulty - - WRITING & 0x02 = 0x02: clear thermal event - -* temp*_input (1: CPU sensor, 2: onboard sensor, 3: auxiliary sensor) - READING: actual temperature value - -* fan*_status (1: power supply fan, 2: CPU fan, 3: auxiliary fan) - READING & 0x04 = 0x04: fan event (fan fault) - READING & 0x04 = 0x00: no fan event - - WRITING & 0x04 = 0x04: clear fan event - -* fan*_div (1: power supply fan, 2: CPU fan, 3: auxiliary fan) - Divisors 2,4 and 8 are supported, both for reading and writing - -* fan*_pwm (1: power supply fan, 2: CPU fan, 3: auxiliary fan) - READING & 0xff = 0x00: fan may be switched off - READING & 0xff = 0x01: fan must run at least at minimum speed (supply: 6V) - READING & 0xff = 0xff: fan must run at maximum speed (supply: 12V) - READING & 0xff = 0x??: fan must run at least at given speed (supply: 6V..12V) - - WRITING & 0xff = 0x00: fan may be switched off - WRITING & 0xff = 0x01: fan must run at least at minimum speed (supply: 6V) - WRITING & 0xff = 0xff: fan must run at maximum speed (supply: 12V) - WRITING & 0xff = 0x??: fan must run at least at given speed (supply: 6V..12V) - -* fan*_input (1: power supply fan, 2: CPU fan, 3: auxiliary fan) - READING: actual RPM value - - -Limitations ------------ - -* Measuring fan speed -It seems that the chip counts "ripples" (typical fans produce 2 ripples per -rotation while VERAX fans produce 18) in a 9-bit register. This register is -read out every second, then the ripple prescaler (2, 4 or 8) is applied and -the result is stored in the 8 bit output register. Due to the limitation of -the counting register to 9 bits, it is impossible to measure a VERAX fan -properly (even with a prescaler of 8). At its maximum speed of 3500 RPM the -fan produces 1080 ripples per second which causes the counting register to -overflow twice, leading to only 186 RPM. - -* Measuring input voltages -in2 ("battery") reports the voltage of the onboard lithium battery and not -+3.3V from the power supply. - -* Undocumented features -Fujitsu-Siemens Computers has not documented all features of the chip so -far. Their software, System Guard, shows that there are a still some -features which cannot be controlled by this implementation. diff --git a/Documentation/hwmon/hpfall.c b/Documentation/hwmon/hpfall.c index bbea1ccfd46..681ec22b9d0 100644 --- a/Documentation/hwmon/hpfall.c +++ b/Documentation/hwmon/hpfall.c @@ -16,6 +16,34 @@ #include <stdint.h> #include <errno.h> #include <signal.h> +#include <sys/mman.h> +#include <sched.h> + +char unload_heads_path[64]; + +int set_unload_heads_path(char *device) +{ + char devname[64]; + + if (strlen(device) <= 5 || strncmp(device, "/dev/", 5) != 0) + return -EINVAL; + strncpy(devname, device + 5, sizeof(devname)); + + snprintf(unload_heads_path, sizeof(unload_heads_path), + "/sys/block/%s/device/unload_heads", devname); + return 0; +} +int valid_disk(void) +{ + int fd = open(unload_heads_path, O_RDONLY); + if (fd < 0) { + perror(unload_heads_path); + return 0; + } + + close(fd); + return 1; +} void write_int(char *path, int i) { @@ -40,7 +68,7 @@ void set_led(int on) void protect(int seconds) { - write_int("/sys/block/sda/device/unload_heads", seconds*1000); + write_int(unload_heads_path, seconds*1000); } int on_ac(void) @@ -57,45 +85,62 @@ void ignore_me(void) { protect(0); set_led(0); - } -int main(int argc, char* argv[]) +int main(int argc, char **argv) { - int fd, ret; + int fd, ret; + struct sched_param param; + + if (argc == 1) + ret = set_unload_heads_path("/dev/sda"); + else if (argc == 2) + ret = set_unload_heads_path(argv[1]); + else + ret = -EINVAL; + + if (ret || !valid_disk()) { + fprintf(stderr, "usage: %s <device> (default: /dev/sda)\n", + argv[0]); + exit(1); + } + + fd = open("/dev/freefall", O_RDONLY); + if (fd < 0) { + perror("/dev/freefall"); + return EXIT_FAILURE; + } - fd = open("/dev/freefall", O_RDONLY); - if (fd < 0) { - perror("open"); - return EXIT_FAILURE; - } + daemon(0, 0); + param.sched_priority = sched_get_priority_max(SCHED_FIFO); + sched_setscheduler(0, SCHED_FIFO, ¶m); + mlockall(MCL_CURRENT|MCL_FUTURE); signal(SIGALRM, ignore_me); - for (;;) { - unsigned char count; - - ret = read(fd, &count, sizeof(count)); - alarm(0); - if ((ret == -1) && (errno == EINTR)) { - /* Alarm expired, time to unpark the heads */ - continue; - } - - if (ret != sizeof(count)) { - perror("read"); - break; - } - - protect(21); - set_led(1); - if (1 || on_ac() || lid_open()) { - alarm(2); - } else { - alarm(20); - } - } - - close(fd); - return EXIT_SUCCESS; + for (;;) { + unsigned char count; + + ret = read(fd, &count, sizeof(count)); + alarm(0); + if ((ret == -1) && (errno == EINTR)) { + /* Alarm expired, time to unpark the heads */ + continue; + } + + if (ret != sizeof(count)) { + perror("read"); + break; + } + + protect(21); + set_led(1); + if (1 || on_ac() || lid_open()) + alarm(2); + else + alarm(20); + } + + close(fd); + return EXIT_SUCCESS; } diff --git a/Documentation/hwmon/pc87427 b/Documentation/hwmon/pc87427 index d1ebbe510f3..db5cc1227a8 100644 --- a/Documentation/hwmon/pc87427 +++ b/Documentation/hwmon/pc87427 @@ -34,5 +34,5 @@ Fan rotation speeds are reported as 14-bit values from a gated clock signal. Speeds down to 83 RPM can be measured. An alarm is triggered if the rotation speed drops below a programmable -limit. Another alarm is triggered if the speed is too low to to be measured +limit. Another alarm is triggered if the speed is too low to be measured (including stalled or missing fan). diff --git a/Documentation/hwmon/wm831x b/Documentation/hwmon/wm831x new file mode 100644 index 00000000000..24f47d8f6a4 --- /dev/null +++ b/Documentation/hwmon/wm831x @@ -0,0 +1,37 @@ +Kernel driver wm831x-hwmon +========================== + +Supported chips: + * Wolfson Microelectronics WM831x PMICs + Prefix: 'wm831x' + Datasheet: + http://www.wolfsonmicro.com/products/WM8310 + http://www.wolfsonmicro.com/products/WM8311 + http://www.wolfsonmicro.com/products/WM8312 + +Authors: Mark Brown <broonie@opensource.wolfsonmicro.com> + +Description +----------- + +The WM831x series of PMICs include an AUXADC which can be used to +monitor a range of system operating parameters, including the voltages +of the major supplies within the system. Currently the driver provides +reporting of all the input values but does not provide any alarms. + +Voltage Monitoring +------------------ + +Voltages are sampled by a 12 bit ADC. Voltages in milivolts are 1.465 +times the ADC value. + +Temperature Monitoring +---------------------- + +Temperatures are sampled by a 12 bit ADC. Chip and battery temperatures +are available. The chip temperature is calculated as: + + Degrees celsius = (512.18 - data) / 1.0983 + +while the battery temperature calculation will depend on the NTC +thermistor component. diff --git a/Documentation/hwmon/wm8350 b/Documentation/hwmon/wm8350 new file mode 100644 index 00000000000..98f923bd2e9 --- /dev/null +++ b/Documentation/hwmon/wm8350 @@ -0,0 +1,26 @@ +Kernel driver wm8350-hwmon +========================== + +Supported chips: + * Wolfson Microelectronics WM835x PMICs + Prefix: 'wm8350' + Datasheet: + http://www.wolfsonmicro.com/products/WM8350 + http://www.wolfsonmicro.com/products/WM8351 + http://www.wolfsonmicro.com/products/WM8352 + +Authors: Mark Brown <broonie@opensource.wolfsonmicro.com> + +Description +----------- + +The WM835x series of PMICs include an AUXADC which can be used to +monitor a range of system operating parameters, including the voltages +of the major supplies within the system. Currently the driver provides +simple access to these major supplies. + +Voltage Monitoring +------------------ + +Voltages are sampled by a 12 bit ADC. For the internal supplies the ADC +is referenced to the system VRTC. |