summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/feature-removal-schedule.txt9
-rw-r--r--Documentation/hwmon/abituguru31
-rw-r--r--Documentation/hwmon/abituguru365
-rw-r--r--Documentation/hwmon/dme1737257
-rw-r--r--Documentation/hwmon/f71805f35
-rw-r--r--Documentation/hwmon/it879
-rw-r--r--Documentation/hwmon/lm9036
-rw-r--r--Documentation/hwmon/lm93412
-rw-r--r--Documentation/hwmon/smsc47b3977
-rw-r--r--Documentation/hwmon/sysfs-interface15
-rw-r--r--Documentation/hwmon/w83627ehf6
-rw-r--r--Documentation/kbuild/makefiles.txt14
-rw-r--r--Documentation/sound/alsa/ALSA-Configuration.txt75
-rw-r--r--Documentation/sound/alsa/Audiophile-Usb.txt242
-rw-r--r--Documentation/sound/alsa/OSS-Emulation.txt15
15 files changed, 1083 insertions, 145 deletions
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index a9941544ed8e..a5cb7839a679 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -164,15 +164,6 @@ Who: Kay Sievers <kay.sievers@suse.de>
---------------------------
-What: i2c-isa
-When: December 2006
-Why: i2c-isa is a non-sense and doesn't fit in the device driver
- model. Drivers relying on it are better implemented as platform
- drivers.
-Who: Jean Delvare <khali@linux-fr.org>
-
----------------------------
-
What: i2c_adapter.list
When: July 2007
Why: Superfluous, this list duplicates the one maintained by the driver
diff --git a/Documentation/hwmon/abituguru b/Documentation/hwmon/abituguru
index b2c0d61b39a2..87ffa0f5ec70 100644
--- a/Documentation/hwmon/abituguru
+++ b/Documentation/hwmon/abituguru
@@ -2,7 +2,7 @@ Kernel driver abituguru
=======================
Supported chips:
- * Abit uGuru revision 1-3 (Hardware Monitor part only)
+ * Abit uGuru revision 1 & 2 (Hardware Monitor part only)
Prefix: 'abituguru'
Addresses scanned: ISA 0x0E0
Datasheet: Not available, this driver is based on reverse engineering.
@@ -20,8 +20,8 @@ Supported chips:
uGuru 2.1.0.0 ~ 2.1.2.8 (AS8, AV8, AA8, AG8, AA8XE, AX8)
uGuru 2.2.0.0 ~ 2.2.0.6 (AA8 Fatal1ty)
uGuru 2.3.0.0 ~ 2.3.0.9 (AN8)
- uGuru 3.0.0.0 ~ 3.0.1.2 (AW8, AL8, NI8)
- uGuru 4.xxxxx? (AT8 32X) (2)
+ uGuru 3.0.0.0 ~ 3.0.x.x (AW8, AL8, AT8, NI8 SLI, AT8 32X, AN8 32X,
+ AW9D-MAX) (2)
1) For revisions 2 and 3 uGuru's the driver can autodetect the
sensortype (Volt or Temp) for bank1 sensors, for revision 1 uGuru's
this doesnot always work. For these uGuru's the autodection can
@@ -30,8 +30,9 @@ Supported chips:
bank1_types=1,1,0,0,0,0,0,2,0,0,0,0,2,0,0,1
You may also need to specify the fan_sensors option for these boards
fan_sensors=5
- 2) The current version of the abituguru driver is known to NOT work
- on these Motherboards
+ 2) There is a seperate abituguru3 driver for these motherboards,
+ the abituguru (without the 3 !) driver will not work on these
+ motherboards (and visa versa)!
Authors:
Hans de Goede <j.w.r.degoede@hhs.nl>,
@@ -43,8 +44,10 @@ 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.
+ detection to be skipped, and thus the insmod to
+ succeed. If the uGuru can't be read the actual hwmon
+ driver will not load and thus no hwmon device will get
+ registered.
* bank1_types: int[] Bank1 sensortype autodetection override:
-1 autodetect (default)
0 volt sensor
@@ -69,13 +72,15 @@ 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).
+This driver supports the hardware monitoring features of the first and
+second revision 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.
+The first and second revision of 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 <ollebull@gmail.com> has managed to reverse engineer the sensor part
diff --git a/Documentation/hwmon/abituguru3 b/Documentation/hwmon/abituguru3
new file mode 100644
index 000000000000..fa598aac22fa
--- /dev/null
+++ b/Documentation/hwmon/abituguru3
@@ -0,0 +1,65 @@
+Kernel driver abituguru3
+========================
+
+Supported chips:
+ * Abit uGuru revision 3 (Hardware Monitor part, reading only)
+ Prefix: 'abituguru3'
+ Addresses scanned: ISA 0x0E0
+ Datasheet: Not available, this driver is based on reverse engineering.
+ Note:
+ The uGuru is a microcontroller with onboard firmware which programs
+ it to behave as a hwmon IC. There are many different revisions of the
+ firmware and thus effectivly many different revisions of the uGuru.
+ Below is an incomplete list with which revisions are used for which
+ Motherboards:
+ uGuru 1.00 ~ 1.24 (AI7, KV8-MAX3, AN7)
+ uGuru 2.0.0.0 ~ 2.0.4.2 (KV8-PRO)
+ uGuru 2.1.0.0 ~ 2.1.2.8 (AS8, AV8, AA8, AG8, AA8XE, AX8)
+ uGuru 2.3.0.0 ~ 2.3.0.9 (AN8)
+ uGuru 3.0.0.0 ~ 3.0.x.x (AW8, AL8, AT8, NI8 SLI, AT8 32X, AN8 32X,
+ AW9D-MAX)
+ The abituguru3 driver is only for revison 3.0.x.x motherboards,
+ this driver will not work on older motherboards. For older
+ motherboards use the abituguru (without the 3 !) driver.
+
+Authors:
+ Hans de Goede <j.w.r.degoede@hhs.nl>,
+ (Initial reverse engineering done by Louis Kruger)
+
+
+Module Parameters
+-----------------
+
+* force: bool Force detection. Note this parameter only causes the
+ detection to be skipped, and thus the insmod to
+ succeed. If the uGuru can't be read the actual hwmon
+ driver will not load and thus no hwmon device will get
+ registered.
+* verbose: bool Should the driver be verbose?
+ 0/off/false normal output
+ 1/on/true + verbose error reporting (default)
+ Default: 1 (the driver is still in the testing phase)
+
+Description
+-----------
+
+This driver supports the hardware monitoring features of the third revision of
+the Abit uGuru chip, found on recent Abit uGuru featuring motherboards.
+
+The 3rd revision of the uGuru chip in reality is a Winbond W83L951G.
+Unfortunatly this doesn't help since the W83L951G is a generic microcontroller
+with a custom Abit application running on it.
+
+Despite Abit not releasing any information regarding the uGuru revision 3,
+Louis Kruger 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,
+neither is writing any of the sensor settings and writing / reading the
+fanspeed control registers (FanEQ)
+
+If you encounter any problems please mail me <j.w.r.degoede@hhs.nl> and
+include the output of: "dmesg | grep abituguru"
diff --git a/Documentation/hwmon/dme1737 b/Documentation/hwmon/dme1737
new file mode 100644
index 000000000000..1a0f3d64ab80
--- /dev/null
+++ b/Documentation/hwmon/dme1737
@@ -0,0 +1,257 @@
+Kernel driver dme1737
+=====================
+
+Supported chips:
+ * SMSC DME1737 and compatibles (like Asus A8000)
+ Prefix: 'dme1737'
+ Addresses scanned: I2C 0x2c, 0x2d, 0x2e
+ Datasheet: Provided by SMSC upon request and under NDA
+
+Authors:
+ Juerg Haefliger <juergh@gmail.com>
+
+
+Module Parameters
+-----------------
+
+* force_start: bool Enables the monitoring of voltage, fan and temp inputs
+ and PWM output control functions. Using this parameter
+ shouldn't be required since the BIOS usually takes care
+ of this.
+
+Note that there is no need to use this parameter if the driver loads without
+complaining. The driver will say so if it is necessary.
+
+
+Description
+-----------
+
+This driver implements support for the hardware monitoring capabilities of the
+SMSC DME1737 and Asus A8000 (which are the same) Super-I/O chips. This chip
+features monitoring of 3 temp sensors temp[1-3] (2 remote diodes and 1
+internal), 7 voltages in[0-6] (6 external and 1 internal) and 6 fan speeds
+fan[1-6]. Additionally, the chip implements 5 PWM outputs pwm[1-3,5-6] for
+controlling fan speeds both manually and automatically.
+
+Fan[3-6] and pwm[3,5-6] are optional features and their availability is
+dependent on the configuration of the chip. The driver will detect which
+features are present during initialization and create the sysfs attributes
+accordingly.
+
+
+Voltage Monitoring
+------------------
+
+The voltage inputs are sampled with 12-bit resolution and have internal
+scaling resistors. The values returned by the driver therefore reflect true
+millivolts and don't need scaling. The voltage inputs are mapped as follows
+(the last column indicates the input ranges):
+
+ in0: +5VTR (+5V standby) 0V - 6.64V
+ in1: Vccp (processor core) 0V - 3V
+ in2: VCC (internal +3.3V) 0V - 4.38V
+ in3: +5V 0V - 6.64V
+ in4: +12V 0V - 16V
+ in5: VTR (+3.3V standby) 0V - 4.38V
+ in6: Vbat (+3.0V) 0V - 4.38V
+
+Each voltage input has associated min and max limits which trigger an alarm
+when crossed.
+
+
+Temperature Monitoring
+----------------------
+
+Temperatures are measured with 12-bit resolution and reported in millidegree
+Celsius. The chip also features offsets for all 3 temperature inputs which -
+when programmed - get added to the input readings. The chip does all the
+scaling by itself and the driver therefore reports true temperatures that don't
+need any user-space adjustments. The temperature inputs are mapped as follows
+(the last column indicates the input ranges):
+
+ temp1: Remote diode 1 (3904 type) temperature -127C - +127C
+ temp2: DME1737 internal temperature -127C - +127C
+ temp3: Remote diode 2 (3904 type) temperature -127C - +127C
+
+Each temperature input has associated min and max limits which trigger an alarm
+when crossed. Additionally, each temperature input has a fault attribute that
+returns 1 when a faulty diode or an unconnected input is detected and 0
+otherwise.
+
+
+Fan Monitoring
+--------------
+
+Fan RPMs are measured with 16-bit resolution. The chip provides inputs for 6
+fan tachometers. All 6 inputs have an associated min limit which triggers an
+alarm when crossed. Fan inputs 1-4 provide type attributes that need to be set
+to the number of pulses per fan revolution that the connected tachometer
+generates. Supported values are 1, 2, and 4. Fan inputs 5-6 only support fans
+that generate 2 pulses per revolution. Fan inputs 5-6 also provide a max
+attribute that needs to be set to the maximum attainable RPM (fan at 100% duty-
+cycle) of the input. The chip adjusts the sampling rate based on this value.
+
+
+PWM Output Control
+------------------
+
+This chip features 5 PWM outputs. PWM outputs 1-3 are associated with fan
+inputs 1-3 and PWM outputs 5-6 are associated with fan inputs 5-6. PWM outputs
+1-3 can be configured to operate either in manual or automatic mode by setting
+the appropriate enable attribute accordingly. PWM outputs 5-6 can only operate
+in manual mode, their enable attributes are therefore read-only. When set to
+manual mode, the fan speed is set by writing the duty-cycle value to the
+appropriate PWM attribute. In automatic mode, the PWM attribute returns the
+current duty-cycle as set by the fan controller in the chip. All PWM outputs
+support the setting of the output frequency via the freq attribute.
+
+In automatic mode, the chip supports the setting of the PWM ramp rate which
+defines how fast the PWM output is adjusting to changes of the associated
+temperature input. Associating PWM outputs to temperature inputs is done via
+temperature zones. The chip features 3 zones whose assignments to temperature
+inputs is static and determined during initialization. These assignments can
+be retrieved via the zone[1-3]_auto_channels_temp attributes. Each PWM output
+is assigned to one (or hottest of multiple) temperature zone(s) through the
+pwm[1-3]_auto_channels_zone attributes. Each PWM output has 3 distinct output
+duty-cycles: full, low, and min. Full is internally hard-wired to 255 (100%)
+and low and min can be programmed via pwm[1-3]_auto_point1_pwm and
+pwm[1-3]_auto_pwm_min, respectively. The thermal thresholds of the zones are
+programmed via zone[1-3]_auto_point[1-3]_temp and
+zone[1-3]_auto_point1_temp_hyst:
+
+ pwm[1-3]_auto_point2_pwm full-speed duty-cycle (255, i.e., 100%)
+ pwm[1-3]_auto_point1_pwm low-speed duty-cycle
+ pwm[1-3]_auto_pwm_min min-speed duty-cycle
+
+ zone[1-3]_auto_point3_temp full-speed temp (all outputs)
+ zone[1-3]_auto_point2_temp full-speed temp
+ zone[1-3]_auto_point1_temp low-speed temp
+ zone[1-3]_auto_point1_temp_hyst min-speed temp
+
+The chip adjusts the output duty-cycle linearly in the range of auto_point1_pwm
+to auto_point2_pwm if the temperature of the associated zone is between
+auto_point1_temp and auto_point2_temp. If the temperature drops below the
+auto_point1_temp_hyst value, the output duty-cycle is set to the auto_pwm_min
+value which only supports two values: 0 or auto_point1_pwm. That means that the
+fan either turns completely off or keeps spinning with the low-speed
+duty-cycle. If any of the temperatures rise above the auto_point3_temp value,
+all PWM outputs are set to 100% duty-cycle.
+
+Following is another representation of how the chip sets the output duty-cycle
+based on the temperature of the associated thermal zone:
+
+ Duty-Cycle Duty-Cycle
+ Temperature Rising Temp Falling Temp
+ ----------- ----------- ------------
+ full-speed full-speed full-speed
+
+ < linearly adjusted duty-cycle >
+
+ low-speed low-speed low-speed
+ min-speed low-speed
+ min-speed min-speed min-speed
+ min-speed min-speed
+
+
+Sysfs Attributes
+----------------
+
+Following is a list of all sysfs attributes that the driver provides, their
+permissions and a short description:
+
+Name Perm Description
+---- ---- -----------
+cpu0_vid RO CPU core reference voltage in
+ millivolts.
+vrm RW Voltage regulator module version
+ number.
+
+in[0-6]_input RO Measured voltage in millivolts.
+in[0-6]_min RW Low limit for voltage input.
+in[0-6]_max RW High limit for voltage input.
+in[0-6]_alarm RO Voltage input alarm. Returns 1 if
+ voltage input is or went outside the
+ associated min-max range, 0 otherwise.
+
+temp[1-3]_input RO Measured temperature in millidegree
+ Celsius.
+temp[1-3]_min RW Low limit for temp input.
+temp[1-3]_max RW High limit for temp input.
+temp[1-3]_offset RW Offset for temp input. This value will
+ be added by the chip to the measured
+ temperature.
+temp[1-3]_alarm RO Alarm for temp input. Returns 1 if temp
+ input is or went outside the associated
+ min-max range, 0 otherwise.
+temp[1-3]_fault RO Temp input fault. Returns 1 if the chip
+ detects a faulty thermal diode or an
+ unconnected temp input, 0 otherwise.
+
+zone[1-3]_auto_channels_temp RO Temperature zone to temperature input
+ mapping. This attribute is a bitfield
+ and supports the following values:
+ 1: temp1
+ 2: temp2
+ 4: temp3
+zone[1-3]_auto_point1_temp_hyst RW Auto PWM temp point1 hysteresis. The
+ output of the corresponding PWM is set
+ to the pwm_auto_min value if the temp
+ falls below the auto_point1_temp_hyst
+ value.
+zone[1-3]_auto_point[1-3]_temp RW Auto PWM temp points. Auto_point1 is
+ the low-speed temp, auto_point2 is the
+ full-speed temp, and auto_point3 is the
+ temp at which all PWM outputs are set
+ to full-speed (100% duty-cycle).
+
+fan[1-6]_input RO Measured fan speed in RPM.
+fan[1-6]_min RW Low limit for fan input.
+fan[1-6]_alarm RO Alarm for fan input. Returns 1 if fan
+ input is or went below the associated
+ min value, 0 otherwise.
+fan[1-4]_type RW Type of attached fan. Expressed in
+ number of pulses per revolution that
+ the fan generates. Supported values are
+ 1, 2, and 4.
+fan[5-6]_max RW Max attainable RPM at 100% duty-cycle.
+ Required for chip to adjust the
+ sampling rate accordingly.
+
+pmw[1-3,5-6] RO/RW Duty-cycle of PWM output. Supported
+ values are 0-255 (0%-100%). Only
+ writeable if the associated PWM is in
+ manual mode.
+pwm[1-3]_enable RW Enable of PWM outputs 1-3. Supported
+ values are:
+ 0: turned off (output @ 100%)
+ 1: manual mode
+ 2: automatic mode
+pwm[5-6]_enable RO Enable of PWM outputs 5-6. Always
+ returns 1 since these 2 outputs are
+ hard-wired to manual mode.
+pmw[1-3,5-6]_freq RW Frequency of PWM output. Supported
+ values are in the range 11Hz-30000Hz
+ (default is 25000Hz).
+pmw[1-3]_ramp_rate RW Ramp rate of PWM output. Determines how
+ fast the PWM duty-cycle will change
+ when the PWM is in automatic mode.
+ Expressed in ms per PWM step. Supported
+ values are in the range 0ms-206ms
+ (default is 0, which means the duty-
+ cycle changes instantly).
+pwm[1-3]_auto_channels_zone RW PWM output to temperature zone mapping.
+ This attribute is a bitfield and
+ supports the following values:
+ 1: zone1
+ 2: zone2
+ 4: zone3
+ 6: highest of zone[2-3]
+ 7: highest of zone[1-3]
+pwm[1-3]_auto_pwm_min RW Auto PWM min pwm. Minimum PWM duty-
+ cycle. Supported values are 0 or
+ auto_point1_pwm.
+pwm[1-3]_auto_point1_pwm RW Auto PWM pwm point. Auto_point1 is the
+ low-speed duty-cycle.
+pwm[1-3]_auto_point2_pwm RO Auto PWM pwm point. Auto_point2 is the
+ full-speed duty-cycle which is hard-
+ wired to 255 (100% duty-cycle).
diff --git a/Documentation/hwmon/f71805f b/Documentation/hwmon/f71805f
index bfd0f154959c..94e0d2cbd3d2 100644
--- a/Documentation/hwmon/f71805f
+++ b/Documentation/hwmon/f71805f
@@ -5,11 +5,11 @@ Supported chips:
* Fintek F71805F/FG
Prefix: 'f71805f'
Addresses scanned: none, address read from Super I/O config space
- Datasheet: Provided by Fintek on request
+ Datasheet: Available from the Fintek website
* Fintek F71872F/FG
Prefix: 'f71872f'
Addresses scanned: none, address read from Super I/O config space
- Datasheet: Provided by Fintek on request
+ Datasheet: Available from the Fintek website
Author: Jean Delvare <khali@linux-fr.org>
@@ -128,7 +128,9 @@ it.
When the PWM method is used, you can select the operating frequency,
from 187.5 kHz (default) to 31 Hz. The best frequency depends on the
fan model. As a rule of thumb, lower frequencies seem to give better
-control, but may generate annoying high-pitch noise. Fintek recommends
+control, but may generate annoying high-pitch noise. So a frequency just
+above the audible range, such as 25 kHz, may be a good choice; if this
+doesn't give you good linear control, try reducing it. Fintek recommends
not going below 1 kHz, as the fan tachometers get confused by lower
frequencies as well.
@@ -136,16 +138,23 @@ When the DC method is used, Fintek recommends not going below 5 V, which
corresponds to a pwm value of 106 for the driver. The driver doesn't
enforce this limit though.
-Three different fan control modes are supported:
+Three different fan control modes are supported; the mode number is written
+to the pwm<n>_enable file.
-* Manual mode
- You ask for a specific PWM duty cycle or DC voltage.
+* 1: Manual mode
+ You ask for a specific PWM duty cycle or DC voltage by writing to the
+ pwm<n> file.
-* Fan speed mode
- You ask for a specific fan speed. This mode assumes that pwm1
- corresponds to fan1, pwm2 to fan2 and pwm3 to fan3.
+* 2: Temperature mode
+ You define 3 temperature/fan speed trip points using the
+ pwm<n>_auto_point<m>_temp and _fan files. These define a staircase
+ relationship between temperature and fan speed with two additional points
+ interpolated between the values that you define. When the temperature
+ is below auto_point1_temp the fan is switched off.
-* Temperature mode
- You define 3 temperature/fan speed trip points, and the fan speed is
- adjusted depending on the measured temperature, using interpolation.
- This mode is not yet supported by the driver.
+* 3: Fan speed mode
+ You ask for a specific fan speed by writing to the fan<n>_target file.
+
+Both of the automatic modes require that pwm1 corresponds to fan1, pwm2 to
+fan2 and pwm3 to fan3. Temperature mode also requires that temp1 corresponds
+to pwm1 and fan1, etc.
diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87
index c0528d6f9ace..81ecc7e41c50 100644
--- a/Documentation/hwmon/it87
+++ b/Documentation/hwmon/it87
@@ -12,11 +12,12 @@ Supported chips:
Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: Publicly available at the ITE website
http://www.ite.com.tw/
- * IT8716F
+ * IT8716F/IT8726F
Prefix: 'it8716'
Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: Publicly available at the ITE website
http://www.ite.com.tw/product_info/file/pc/IT8716F_V0.3.ZIP
+ http://www.ite.com.tw/product_info/file/pc/IT8726F_V0.3.pdf
* IT8718F
Prefix: 'it8718'
Addresses scanned: from Super I/O config space (8 I/O ports)
@@ -68,7 +69,7 @@ Description
-----------
This driver implements support for the IT8705F, IT8712F, IT8716F,
-IT8718F and SiS950 chips.
+IT8718F, IT8726F and SiS950 chips.
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
joysticks and other miscellaneous stuff. For hardware monitoring, they
@@ -97,6 +98,10 @@ clock divider mess) but not compatible with the older chips and
revisions. For now, the driver only uses the 16-bit mode on the
IT8716F and IT8718F.
+The IT8726F is just bit enhanced IT8716F with additional hardware
+for AMD power sequencing. Therefore the chip will appear as IT8716F
+to userspace applications.
+
Temperatures are measured in degrees Celsius. An alarm is triggered once
when the Overtemperature Shutdown limit is crossed.
diff --git a/Documentation/hwmon/lm90 b/Documentation/hwmon/lm90
index 438cb24cee5b..aa4a0ec20081 100644
--- a/Documentation/hwmon/lm90
+++ b/Documentation/hwmon/lm90
@@ -48,6 +48,18 @@ Supported chips:
Addresses scanned: I2C 0x4c, 0x4d (unsupported 0x4e)
Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
+ * Maxim MAX6680
+ Prefix: 'max6680'
+ Addresses scanned: I2C 0x18, 0x19, 0x1a, 0x29, 0x2a, 0x2b,
+ 0x4c, 0x4d and 0x4e
+ Datasheet: Publicly available at the Maxim website
+ http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3370
+ * Maxim MAX6681
+ Prefix: 'max6680'
+ Addresses scanned: I2C 0x18, 0x19, 0x1a, 0x29, 0x2a, 0x2b,
+ 0x4c, 0x4d and 0x4e
+ Datasheet: Publicly available at the Maxim website
+ http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3370
Author: Jean Delvare <khali@linux-fr.org>
@@ -59,11 +71,15 @@ Description
The LM90 is a digital temperature sensor. It senses its own temperature as
well as the temperature of up to one external diode. It is compatible
with many other devices such as the LM86, the LM89, the LM99, the ADM1032,
-the MAX6657, MAX6658 and the MAX6659 all of which are supported by this driver.
-Note that there is no easy way to differentiate between the last three
-variants. The extra address and features of the MAX6659 are not supported by
-this driver. Additionally, the ADT7461 is supported if found in ADM1032
-compatibility mode.
+the MAX6657, MAX6658, MAX6659, MAX6680 and the MAX6681 all of which are
+supported by this driver.
+
+Note that there is no easy way to differentiate between the MAX6657,
+MAX6658 and MAX6659 variants. The extra address and features of the
+MAX6659 are not supported by this driver. The MAX6680 and MAX6681 only
+differ in their pinout, therefore they obviously can't (and don't need to)
+be distinguished. Additionally, the ADT7461 is supported if found in
+ADM1032 compatibility mode.
The specificity of this family of chipsets over the ADM1021/LM84
family is that it features critical limits with hysteresis, and an
@@ -93,18 +109,22 @@ ADM1032:
* ALERT is triggered by open remote sensor.
* SMBus PEC support for Write Byte and Receive Byte transactions.
-ADT7461
+ADT7461:
* Extended temperature range (breaks compatibility)
* Lower resolution for remote temperature
MAX6657 and MAX6658:
* Remote sensor type selection
-MAX6659
+MAX6659:
* Selectable address
* Second critical temperature limit
* Remote sensor type selection
+MAX6680 and MAX6681:
+ * Selectable address
+ * Remote sensor type selection
+
All temperature values are given in degrees Celsius. Resolution
is 1.0 degree for the local temperature, 0.125 degree for the remote
temperature.
@@ -141,7 +161,7 @@ SMBus Read Byte, and PEC will work properly.
Additionally, the ADM1032 doesn't support SMBus Send Byte with PEC.
Instead, it will try to write the PEC value to the register (because the
SMBus Send Byte transaction with PEC is similar to a Write Byte transaction
-without PEC), which is not what we want. Thus, PEC is explicitely disabled
+without PEC), which is not what we want. Thus, PEC is explicitly disabled
on SMBus Send Byte transactions in the lm90 driver.
PEC on byte data transactions represents a significant increase in bandwidth
diff --git a/Documentation/hwmon/lm93 b/Documentation/hwmon/lm93
new file mode 100644
index 000000000000..4e4a1dc1d2da
--- /dev/null
+++ b/Documentation/hwmon/lm93
@@ -0,0 +1,412 @@
+Kernel driver lm93
+==================
+
+Supported chips:
+ * National Semiconductor LM93
+ Prefix 'lm93'
+ Addresses scanned: I2C 0x2c-0x2e
+ Datasheet: http://www.national.com/ds.cgi/LM/LM93.pdf
+
+Author:
+ Mark M. Hoffman <mhoffman@lightlink.com>
+ Ported to 2.6 by Eric J. Bowersox <ericb@aspsys.com>
+ Adapted to 2.6.20 by Carsten Emde <ce@osadl.org>
+ Modified for mainline integration by Hans J. Koch <hjk@linutronix.de>
+
+Module Parameters
+-----------------
+
+(specific to LM93)
+* init: integer
+ Set to non-zero to force some initializations (default is 0).
+* disable_block: integer
+ A "0" allows SMBus block data transactions if the host supports them. A "1"
+ disables SMBus block data transactions. The default is 0.
+* vccp_limit_type: integer array (2)
+ Configures in7 and in8 limit type, where 0 means absolute and non-zero
+ means relative. "Relative" here refers to "Dynamic Vccp Monitoring using
+ VID" from the datasheet. It greatly simplifies the interface to allow
+ only one set of limits (absolute or relative) to be in operation at a
+ time (even though the hardware is capable of enabling both). There's
+ not a compelling use case for enabling both at once, anyway. The default
+ is "0,0".
+* vid_agtl: integer
+ A "0" configures the VID pins for V(ih) = 2.1V min, V(il) = 0.8V max.
+ A "1" configures the VID pins for V(ih) = 0.8V min, V(il) = 0.4V max.
+ (The latter setting is referred to as AGTL+ Compatible in the datasheet.)
+ I.e. this parameter controls the VID pin input thresholds; if your VID
+ inputs are not working, try changing this. The default value is "0".
+
+(common among sensor drivers)
+* force: short array (min = 1, max = 48)
+ List of adapter,address pairs to assume to be present. Autodetection
+ of the target device will still be attempted. Use one of the more
+ specific force directives below if this doesn't detect the device.
+* force_lm93: short array (min = 1, max = 48)
+ List of adapter,address pairs which are unquestionably assumed to contain
+ a 'lm93' chip
+* ignore: short array (min = 1, max = 48)
+ List of adapter,address pairs not to scan
+* ignore_range: short array (min = 1, max = 48)
+ List of adapter,start-addr,end-addr triples not to scan
+* probe: short array (min = 1, max = 48)
+ List of adapter,address pairs to scan additionally
+* probe_range: short array (min = 1, max = 48)
+ List of adapter,start-addr,end-addr triples to scan additionally
+
+
+Hardware Description
+--------------------
+
+(from the datasheet)
+
+The LM93, hardware monitor, has a two wire digital interface compatible with
+SMBus 2.0. Using an 8-bit ADC, the LM93 measures the temperature of two remote
+diode connected transistors as well as its own die and 16 power supply
+voltages. To set fan speed, the LM93 has two PWM outputs that are each
+controlled by up to four temperature zones. The fancontrol algorithm is lookup
+table based. The LM93 includes a digital filter that can be invoked to smooth
+temperature readings for better control of fan speed. The LM93 has four
+tachometer inputs to measure fan speed. Limit and status registers for all
+measured values are included. The LM93 builds upon the functionality of
+previous motherboard management ASICs and uses some of the LM85 s features
+(i.e. smart tachometer mode). It also adds measurement and control support
+for dynamic Vccp monitoring and PROCHOT. It is designed to monitor a dual
+processor Xeon class motherboard with a minimum of external components.
+
+
+Driver Description
+------------------
+
+This driver implements support for the National Semiconductor LM93.
+
+
+User Interface
+--------------
+
+#PROCHOT:
+
+The LM93 can monitor two #PROCHOT signals. The results are found in the
+sysfs files prochot1, prochot2, prochot1_avg, prochot2_avg, prochot1_max,
+and prochot2_max. prochot1_max and prochot2_max contain the user limits
+for #PROCHOT1 and #PROCHOT2, respectively. prochot1 and prochot2 contain
+the current readings for the most recent complete time interval. The
+value of prochot1_avg and prochot2_avg is something like a 2 period
+exponential moving average (but not quite - check the datasheet). Note
+that this third value is calculated by the chip itself. All values range
+from 0-255 where 0 indicates no throttling, and 255 indicates > 99.6%.
+
+The monitoring intervals for the two #PROCHOT signals is also configurable.
+These intervals can be found in the sysfs files prochot1_interval and
+prochot2_interval. The values in these files specify the intervals for
+#P1_PROCHOT and #P2_PROCHOT, respectively. Selecting a value not in this
+list will cause the driver to use the next largest interval. The available
+intervals are:
+
+#PROCHOT intervals: 0.73, 1.46, 2.9, 5.8, 11.7, 23.3, 46.6, 93.2, 186, 372
+
+It is possible to configure the LM93 to logically short the two #PROCHOT
+signals. I.e. when #P1_PROCHOT is asserted, the LM93 will automatically
+assert #P2_PROCHOT, and vice-versa. This mode is enabled by writing a
+non-zero integer to the sysfs file prochot_short.
+
+The LM93 can also override the #PROCHOT pins by driving a PWM signal onto
+one or both of them. When overridden, the signal has a period of 3.56 mS,
+a minimum pulse width of 5 clocks (at 22.5kHz => 6.25% duty cycle), and
+a maximum pulse width of 80 clocks (at 22.5kHz => 99.88% duty cycle).
+
+The sysfs files prochot1_override and prochot2_override contain boolean
+intgers which enable or disable the override function for #P1_PROCHOT and
+#P2_PROCHOT, respectively. The sysfs file prochot_override_duty_cycle
+contains a value controlling the duty cycle for the PWM signal used when
+the override function is enabled. This value ranges from 0 to 15, with 0
+indicating minimum duty cycle and 15 indicating maximum.
+
+#VRD_HOT:
+
+The LM93 can monitor two #VRD_HOT signals. The results are found in the
+sysfs files vrdhot1 and vrdhot2. There is one value per file: a boolean for
+which 1 indicates #VRD_HOT is asserted and 0 indicates it is negated. These
+files are read-only.
+
+Smart Tach Mode:
+
+(from the datasheet)
+
+ If a fan is driven using a low-side drive PWM, the tachometer
+ output of the fan is corrupted. The LM93 includes smart tachometer
+ circuitry that allows an accurate tachometer reading to be
+ achieved despite the signal corruption. In smart tach mode all
+ four signals are measured within 4 seconds.
+
+Smart tach mode is enabled by the driver by writing 1 or 2 (associating the
+the fan tachometer with a pwm) to the sysfs file fan<n>_smart_tach. A zero
+will disable the function for that fan. Note that Smart tach mode cannot be
+enabled if the PWM output frequency is 22500 Hz (see below).
+
+Manual PWM:
+
+The LM93 has a fixed or override mode for the two PWM outputs (although, there
+are still some conditions that will override even this mode - see section
+15.10.6 of the datasheet for details.) The sysfs files pwm1_override
+and pwm2_override are used to enable this mode; each is a boolean integer
+where 0 disables and 1 enables the manual control mode. The sysfs files pwm1
+and pwm2 are used to set the manual duty cycle; each is an integer (0-255)
+where 0 is 0% duty cycle, and 255 is 100%. Note that the duty cycle values
+are constrained by the hardware. Selecting a value which is not available
+will cause the driver to use the next largest value. Also note: when manual
+PWM mode is disabled, the value of pwm1 and pwm2 indicates the current duty
+cycle chosen by the h/w.
+
+PWM Output Frequency:
+
+The LM93 supports several different frequencies for the PWM output channels.
+The sysfs files pwm1_freq and pwm2_freq are used to select the frequency. The
+frequency values are constrained by the hardware. Selecting a value which is
+not available will cause the driver to use the next largest value. Also note
+that this parameter has implications for the Smart Tach Mode (see above).
+
+PWM Output Frequencies: 12, 36, 48, 60, 72, 84, 96, 22500 (h/w default)
+
+Automatic PWM:
+
+The LM93 is capable of complex automatic fan control, with many different
+points of configuration. To start, each PWM output can be bound to any
+combination of eight control sources. The final PWM is the largest of all
+individual control sources to which the PWM output is bound.
+
+The eight control sources are: temp1-temp4 (aka "zones" in the datasheet),
+#PROCHOT 1 & 2, and #VRDHOT 1 & 2. The bindings are expressed as a bitmask
+in the sysfs files pwm<n>_auto_channels, where a "1" enables the binding, and
+ a "0" disables it. The h/w default is 0x0f (all temperatures bound).
+
+ 0x01 - Temp 1
+ 0x02 - Temp 2
+ 0x04 - Temp 3
+ 0x08 - Temp 4
+ 0x10 - #PROCHOT 1
+ 0x20 - #PROCHOT 2
+ 0x40 - #VRDHOT 1
+ 0x80 - #VRDHOT 2
+
+The function y = f(x) takes a source temperature x to a PWM output y. This
+function of the LM93 is derived from a base temperature and a table of 12
+temperature offsets. The base temperature is expressed in degrees C in the
+sysfs files temp<n>_auto_base. The offsets are expressed in cumulative
+degrees C, with the value of offset <i> for temperature value <n> being
+contained in the file temp<n>_auto_offset<i>. E.g. if the base temperature
+is 40C:
+
+ offset # temp<n>_auto_offset<i> range pwm
+ 1 0 - 25.00%
+ 2 0 - 28.57%
+ 3 1 40C - 41C 32.14%
+ 4 1 41C - 42C 35.71%
+ 5 2 42C - 44C 39.29%
+ 6 2 44C - 46C 42.86%
+ 7 2 48C - 50C 46.43%
+ 8 2 50C - 52C 50.00%
+ 9 2 52C - 54C 53.57%
+ 10 2 54C - 56C 57.14%
+ 11 2 56C - 58C 71.43%
+ 12 2 58C - 60C 85.71%
+ > 60C 100.00%
+
+Valid offsets are in the range 0C <= x <= 7.5C in 0.5C increments.
+
+There is an independent base temperature for each temperature channel. Note,
+however, there are only two tables of offsets: one each for temp[12] and
+temp[34]. Therefore, any change to e.g. temp1_auto_offset<i> will also
+affect temp2_auto_offset<i>.
+
+The LM93 can also apply hysteresis to the offset table, to prevent unwanted
+oscillation between two steps in the offsets table. These values are found in
+the sysfs files temp<n>_auto_offset_hyst. The value in this file has the
+same representation as in temp<n>_auto_offset<i>.
+
+If a temperature reading falls below the base value for that channel, the LM93
+will use the minimum PWM value. These values are found in the sysfs files
+temp<n>_auto_pwm_min. Note, there are only two minimums: one each for temp[12]
+and temp[34]. Therefore, any change to e.g. temp1_auto_pwm_min will also
+affect temp2_auto_pwm_min.
+
+PWM Spin-Up Cycle:
+
+A spin-up cycle occurs when a PWM output is commanded from 0% duty cycle to
+some value > 0%. The LM93 supports a minimum duty cycle during spin-up. These
+values are found in the sysfs files pwm<n>_auto_spinup_min. The value in this
+file has the same representation as other PWM duty cycle values. The
+duration of the spin-up cycle is also configurable. These values are found in
+the sysfs files pwm<n>_auto_spinup_time. The value in this file is
+the spin-up time in seconds. The available spin-up times are constrained by
+the hardware. Selecting a value which is not available will cause the driver
+to use the next largest value.
+
+Spin-up Durations: 0 (disabled, h/w default), 0.1, 0.25, 0.4, 0.7, 1.0,
+ 2.0, 4.0
+
+#PROCHOT and #VRDHOT PWM Ramping:
+
+If the #PROCHOT or #VRDHOT signals are asserted while bound to a PWM output
+channel, the LM93 will ramp the PWM output up to 100% duty cycle in discrete
+steps. The duration of each step is configurable. There are two files, with
+one value each in seconds: pwm_auto_prochot_ramp and pwm_auto_vrdhot_ramp.
+The available ramp times are constrained by the hardware. Selecting a value
+which is not available will cause the driver to use the next largest value.
+
+Ramp Times: 0 (disabled, h/w default) to 0.75 in 0.05 second intervals
+
+Fan Boost:
+
+For each temperature channel, there is a boost temperature: if the channel
+exceeds this limit, the LM93 will immediately drive both PWM outputs to 100%.
+This limit is expressed in degrees C in the sysfs files temp<n>_auto_boost.
+There is also a hysteresis temperature for this function: after the boost
+limit is reached, the temperature channel must drop below this value before
+the boost function is disabled. This temperature is also expressed in degrees
+C in the sysfs files temp<n>_auto_boost_hyst.
+
+GPIO Pins:
+
+The LM93 can monitor the logic level of four dedicated GPIO pins as well as the
+four tach input pins. GPIO0-GPIO3 correspond to (fan) tach 1-4, respectively.
+All eight GPIOs are read by reading the bitmask in the sysfs file gpio. The
+LSB is GPIO0, and the MSB is GPIO7.
+
+
+LM93 Unique sysfs Files
+-----------------------
+
+ file description
+ -------------------------------------------------------------
+
+ prochot<n> current #PROCHOT %
+
+ prochot<n>_avg moving average #PROCHOT %
+
+ prochot<n>_max limit #PROCHOT %
+
+ prochot_short enable or disable logical #PROCHOT pin short
+
+ prochot<n>_override force #PROCHOT assertion as PWM
+
+ prochot_override_duty_cycle
+ duty cycle for the PWM signal used when
+ #PROCHOT is overridden
+
+ prochot<n>_interval #PROCHOT PWM sampling interval
+
+ vrdhot<n> 0 means negated, 1 means asserted
+
+ fan<n>_smart_tach enable or disable smart tach mode
+
+ pwm<n>_auto_channels select control sources for PWM outputs
+
+ pwm<n>_auto_spinup_min minimum duty cycle during spin-up
+
+ pwm<n>_auto_spinup_time duration of spin-up
+
+ pwm_auto_prochot_ramp ramp time per step when #PROCHOT asserted
+
+ pwm_auto_vrdhot_ramp ramp time per step when #VRDHOT asserted
+
+ temp<n>_auto_base temperature channel base
+
+ temp<n>_auto_offset[1-12]
+ temperature channel offsets
+
+ temp<n>_auto_offset_hyst
+ temperature channel offset hysteresis
+
+ temp<n>_auto_boost temperature channel boost (PWMs to 100%) limit
+
+ temp<n>_auto_boost_hyst temperature channel boost hysteresis
+
+ gpio input state of 8 GPIO pins; read-only
+
+
+Sample Configuration File
+-------------------------
+
+Here is a sample LM93 chip config for sensors.conf:
+
+---------- cut here ----------
+chip "lm93-*"
+
+# VOLTAGE INPUTS
+
+ # labels and scaling based on datasheet recommendations
+ label in1 "+12V1"
+ compute in1 @ * 12.945, @ / 12.945
+ set in1_min 12 * 0.90
+ set in1_max 12 * 1.10
+
+ label in2 "+12V2"
+ compute in2 @ * 12.945, @ / 12.945
+ set in2_min 12 * 0.90
+ set in2_max 12 * 1.10
+
+ label in3 "+12V3"
+ compute in3 @ * 12.945, @ / 12.945
+ set in3_min 12 * 0.90
+ set in3_max 12 * 1.10
+
+ label in4 "FSB_Vtt"
+
+ label in5 "3GIO"
+
+ label in6 "ICH_Core"
+
+ label in7 "Vccp1"
+
+ label in8 "Vccp2"
+
+ label in9 "+3.3V"
+ set in9_min 3.3 * 0.90
+ set in9_max 3.3 * 1.10
+
+ label in10 "+5V"
+ set in10_min 5.0 * 0.90
+ set in10_max 5.0 * 1.10
+
+ label in11 "SCSI_Core"
+
+ label in12 "Mem_Core"
+
+ label in13 "Mem_Vtt"
+
+ label in14 "Gbit_Core"
+
+ # Assuming R1/R2 = 4.1143, and 3.3V reference
+ # -12V = (4.1143 + 1) * (@ - 3.3) + 3.3
+ label in15 "-12V"
+ compute in15 @ * 5.1143 - 13.57719, (@ + 13.57719) / 5.1143
+ set in15_min -12 * 0.90
+ set in15_max -12 * 1.10
+
+ label in16 "+3.3VSB"
+ set in16_min 3.3 * 0.90
+ set in16_max 3.3 * 1.10
+
+# TEMPERATURE INPUTS
+
+ label temp1 "CPU1"
+ label temp2 "CPU2"
+ label temp3 "LM93"
+
+# TACHOMETER INPUTS
+
+ label fan1 "Fan1"
+ set fan1_min 3000
+ label fan2 "Fan2"
+ set fan2_min 3000
+ label fan3 "Fan3"
+ set fan3_min 3000
+ label fan4 "Fan4"
+ set fan4_min 3000
+
+# PWM OUTPUTS
+
+ label pwm1 "CPU1"
+ label pwm2 "CPU2"
+
diff --git a/Documentation/hwmon/smsc47b397 b/Documentation/hwmon/smsc47b397
index 20682f15ae41..3a43b6948924 100644
--- a/Documentation/hwmon/smsc47b397
+++ b/Documentation/hwmon/smsc47b397
@@ -4,6 +4,7 @@ Kernel driver smsc47b397
Supported chips:
* SMSC LPC47B397-NC
* SMSC SCH5307-NS
+ * SMSC SCH5317
Prefix: 'smsc47b397'
Addresses scanned: none, address read from Super I/O config space
Datasheet: In this file
@@ -18,8 +19,8 @@ The following specification describes the SMSC LPC47B397-NC[1] sensor chip
provided by Craig Kelly (In-Store Broadcast Network) and edited/corrected
by Mark M. Hoffman <mhoffman@lightlink.com>.
-[1] And SMSC SCH5307-NS, which has a different device ID but is otherwise
-compatible.
+[1] And SMSC SCH5307-NS and SCH5317, which have different device IDs but are
+otherwise compatible.
* * * * *
@@ -131,7 +132,7 @@ OUT DX,AL
The registers of interest for identifying the SIO on the dc7100 are Device ID
(0x20) and Device Rev (0x21).
-The Device ID will read 0x6F (for SCH5307-NS, 0x81)
+The Device ID will read 0x6F (0x81 for SCH5307-NS, and 0x85 for SCH5317)
The Device Rev currently reads 0x01
Obtaining the HWM Base Address.
diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface
index a9a18ad0d17a..b3a9e1b9dbda 100644
--- a/Documentation/hwmon/sysfs-interface
+++ b/Documentation/hwmon/sysfs-interface
@@ -172,11 +172,10 @@ pwm[1-*] Pulse width modulation fan control.
255 is max or 100%.
pwm[1-*]_enable
- Switch PWM on and off.
- Not always present even if pwmN is.
- 0: turn off
- 1: turn on in manual mode
- 2+: turn on in automatic mode
+ Fan speed control method:
+ 0: no fan speed control (i.e. fan at full speed)
+ 1: manual fan speed control enabled (using pwm[1-*])
+ 2+: automatic fan speed control enabled
Check individual chip documentation files for automatic mode
details.
RW
@@ -343,9 +342,9 @@ 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-*]_input_fault
-fan[1-*]_input_fault
-temp[1-*]_input_fault
+in[0-*]_fault
+fan[1-*]_fault
+temp[1-*]_fault
Input fault condition
0: no fault occured
1: fault condition
diff --git a/Documentation/hwmon/w83627ehf b/Documentation/hwmon/w83627ehf
index 030fac6cec7a..ccc2bcb61068 100644
--- a/Documentation/hwmon/w83627ehf
+++ b/Documentation/hwmon/w83627ehf
@@ -22,9 +22,9 @@ This driver implements support for the Winbond W83627EHF, W83627EHG, and
W83627DHG super I/O chips. We will refer to them collectively as Winbond chips.
The chips implement three temperature sensors, five fan rotation
-speed sensors, ten analog voltage sensors (only nine for the 627DHG), alarms
-with beep warnings (control unimplemented), and some automatic fan regulation
-strategies (plus manual fan control mode).
+speed sensors, ten analog voltage sensors (only nine for the 627DHG), one
+VID (6 pins), alarms with beep warnings (control unimplemented), and
+some automatic fan regulation strategies (plus manual fan control mode).
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
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index bb5306e9a5c3..e08ef8759a07 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -501,6 +501,20 @@ more details, with real examples.
The third parameter may be a text as in this example, but it may also
be an expanded variable or a macro.
+ cc-fullversion
+ cc-fullversion is useful when the exact version of gcc is needed.
+ One typical use-case is when a specific GCC version is broken.
+ cc-fullversion points out a more specific version than cc-version does.
+
+ Example:
+ #arch/powerpc/Makefile
+ $(Q)if test "$(call cc-fullversion)" = "040200" ; then \
+ echo -n '*** GCC-4.2.0 cannot compile the 64-bit powerpc ' ; \
+ false ; \
+ fi
+
+ In this example for a specific GCC version the build will error out explaining
+ to the user why it stops.
=== 4 Host Program support
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt
index 355ff0a2bb7c..241e26c4ff92 100644
--- a/Documentation/sound/alsa/ALSA-Configuration.txt
+++ b/Documentation/sound/alsa/ALSA-Configuration.txt
@@ -467,7 +467,12 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
above explicitly.
The power-management is supported.
-
+
+ Module snd-cs5530
+ _________________
+
+ Module for Cyrix/NatSemi Geode 5530 chip.
+
Module snd-cs5535audio
----------------------
@@ -759,6 +764,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
model - force the model name
position_fix - Fix DMA pointer (0 = auto, 1 = none, 2 = POSBUF, 3 = FIFO size)
+ probe_mask - Bitmask to probe codecs (default = -1, meaning all slots)
single_cmd - Use single immediate commands to communicate with
codecs (for debugging only)
enable_msi - Enable Message Signaled Interrupt (MSI) (default = off)
@@ -803,6 +809,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
hp-3013 HP machines (3013-variant)
fujitsu Fujitsu S7020
acer Acer TravelMate
+ will Will laptops (PB V7900)
+ replacer Replacer 672V
basic fixed pin assignment (old default model)
auto auto-config reading BIOS (default)
@@ -811,16 +819,31 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
hp-bpc HP xw4400/6400/8400/9400 laptops
hp-bpc-d7000 HP BPC D7000
benq Benq ED8
+ benq-t31 Benq T31
hippo Hippo (ATI) with jack detection, Sony UX-90s
hippo_1 Hippo (Benq) with jack detection
+ sony-assamd Sony ASSAMD
basic fixed pin assignment w/o SPDIF
auto auto-config reading BIOS (default)
+ ALC268
+ 3stack 3-stack model
+ auto auto-config reading BIOS (default)
+
+ ALC662
+ 3stack-dig 3-stack (2-channel) with SPDIF
+ 3stack-6ch 3-stack (6-channel)
+ 3stack-6ch-dig 3-stack (6-channel) with SPDIF
+ 6stack-dig 6-stack with SPDIF
+ lenovo-101e Lenovo laptop
+ auto auto-config reading BIOS (default)
+
ALC882/885
3stack-dig 3-jack with SPDIF I/O
6stack-dig 6-jack digital with SPDIF I/O
arima Arima W820Di1
macpro MacPro support
+ imac24 iMac 24'' with jack detection
w2jc ASUS W2JC
auto auto-config reading BIOS (default)
@@ -832,9 +855,15 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
6stack-dig-demo 6-jack digital for Intel demo board
acer Acer laptops (Travelmate 3012WTMi, Aspire 5600, etc)
medion Medion Laptops
+ medion-md2 Medion MD2
targa-dig Targa/MSI
targa-2ch-dig Targs/MSI with 2-channel
laptop-eapd 3-jack with SPDIF I/O and EAPD (Clevo M540JE, M550JE)
+ lenovo-101e Lenovo 101E
+ lenovo-nb0763 Lenovo NB0763
+ lenovo-ms7195-dig Lenovo MS7195
+ 6stack-hp HP machines with 6stack (Nettle boards)
+ 3stack-hp HP machines with 3stack (Lucknow, Samba boards)
auto auto-config reading BIOS (default)
ALC861/660
@@ -853,7 +882,9 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
3stack-dig 3-jack with SPDIF OUT
6stack-dig 6-jack with SPDIF OUT
3stack-660 3-jack (for ALC660VD)
+ 3stack-660-digout 3-jack with SPDIF OUT (for ALC660VD)
lenovo Lenovo 3000 C200
+ dallas Dallas laptops
auto auto-config reading BIOS (default)
CMI9880
@@ -864,12 +895,26 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
allout 5-jack in back, 2-jack in front, SPDIF out
auto auto-config reading BIOS (default)
+ AD1882
+ 3stack 3-stack mode (default)
+ 6stack 6-stack mode
+
+ AD1884
+ N/A
+
AD1981
basic 3-jack (default)
hp HP nx6320
thinkpad Lenovo Thinkpad T60/X60/Z60
toshiba Toshiba U205
+ AD1983
+ N/A
+
+ AD1984
+ basic default configuration
+ thinkpad Lenovo Thinkpad T61/X61
+
AD1986A
6stack 6-jack, separate surrounds (default)
3stack 3-stack, shared surrounds
@@ -907,11 +952,18 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
ref Reference board
3stack D945 3stack
5stack D945 5stack + SPDIF
- macmini Intel Mac Mini
- macbook Intel Mac Book
- macbook-pro-v1 Intel Mac Book Pro 1st generation
- macbook-pro Intel Mac Book Pro 2nd generation
- imac-intel Intel iMac
+ dell Dell XPS M1210
+ intel-mac-v1 Intel Mac Type 1
+ intel-mac-v2 Intel Mac Type 2
+ intel-mac-v3 Intel Mac Type 3
+ intel-mac-v4 Intel Mac Type 4
+ intel-mac-v5 Intel Mac Type 5
+ macmini Intel Mac Mini (equivalent with type 3)
+ macbook Intel Mac Book (eq. type 5)
+ macbook-pro-v1 Intel Mac Book Pro 1st generation (eq. type 3)
+ macbook-pro Intel Mac Book Pro 2nd generation (eq. type 3)
+ imac-intel Intel iMac (eq. type 2)
+ imac-intel-20 Intel iMac (newer version) (eq. type 3)
STAC9202/9250/9251
ref Reference board, base config
@@ -956,6 +1008,17 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
from the irq. Remember this is a last resort, and should be
avoided as much as possible...
+ MORE NOTES ON "azx_get_response timeout" PROBLEMS:
+ On some hardwares, you may need to add a proper probe_mask option
+ to avoid the "azx_get_response timeout" problem above, instead.
+ This occurs when the access to non-existing or non-working codec slot
+ (likely a modem one) causes a stall of the communication via HD-audio
+ bus. You can see which codec slots are probed by enabling
+ CONFIG_SND_DEBUG_DETECT, or simply from the file name of the codec
+ proc files. Then limit the slots to probe by probe_mask option.
+ For example, probe_mask=1 means to probe only the first slot, and
+ probe_mask=4 means only the third slot.
+
The power-management is supported.
Module snd-hdsp
diff --git a/Documentation/sound/alsa/Audiophile-Usb.txt b/Documentation/sound/alsa/Audiophile-Usb.txt
index e40cce83327c..2ad5e6306c44 100644
--- a/Documentation/sound/alsa/Audiophile-Usb.txt
+++ b/Documentation/sound/alsa/Audiophile-Usb.txt
@@ -1,4 +1,4 @@
- Guide to using M-Audio Audiophile USB with ALSA and Jack v1.3
+ Guide to using M-Audio Audiophile USB with ALSA and Jack v1.5
========================================================
Thibault Le Meur <Thibault.LeMeur@supelec.fr>
@@ -6,8 +6,19 @@
This document is a guide to using the M-Audio Audiophile USB (tm) device with
ALSA and JACK.
+History
+=======
+* v1.4 - Thibault Le Meur (2007-07-11)
+ - Added Low Endianness nature of 16bits-modes
+ found by Hakan Lennestal <Hakan.Lennestal@brfsodrahamn.se>
+ - Modifying document structure
+* v1.5 - Thibault Le Meur (2007-07-12)
+ - Added AC3/DTS passthru info
+
+
1 - Audiophile USB Specs and correct usage
==========================================
+
This part is a reminder of important facts about the functions and limitations
of the device.
@@ -25,18 +36,18 @@ The device has 4 audio interfaces, and 2 MIDI ports:
The internal DAC/ADC has the following characteristics:
* sample depth of 16 or 24 bits
* sample rate from 8kHz to 96kHz
-* Two ports can't use different sample depths at the same time. Moreover, the
-Audiophile USB documentation gives the following Warning: "Please exit any
-audio application running before switching between bit depths"
+* Two interfaces can't use different sample depths at the same time.
+Moreover, the Audiophile USB documentation gives the following Warning:
+"Please exit any audio application running before switching between bit depths"
Due to the USB 1.1 bandwidth limitation, a limited number of interfaces can be
activated at the same time depending on the audio mode selected:
- * 16-bit/48kHz ==> 4 channels in/4 channels out
+ * 16-bit/48kHz ==> 4 channels in + 4 channels out
- Ai+Ao+Di+Do
- * 24-bit/48kHz ==> 4 channels in/2 channels out,
- or 2 channels in/4 channels out
+ * 24-bit/48kHz ==> 4 channels in + 2 channels out,
+ or 2 channels in + 4 channels out
- Ai+Ao+Do or Ai+Di+Ao or Ai+Di+Do or Di+Ao+Do
- * 24-bit/96kHz ==> 2 channels in, or 2 channels out (half duplex only)
+ * 24-bit/96kHz ==> 2 channels in _or_ 2 channels out (half duplex only)
- Ai or Ao or Di or Do
Important facts about the Digital interface:
@@ -52,44 +63,56 @@ source is connected
synchronization error (for instance sound played at an odd sample rate)
-2 - Audiophile USB support in ALSA
-==================================
+2 - Audiophile USB MIDI support in ALSA
+=======================================
-2.1 - MIDI ports
-----------------
-The Audiophile USB MIDI ports will be automatically supported once the
+The Audiophile USB MIDI ports will be automatically supported once the
following modules have been loaded:
* snd-usb-audio
* snd-seq-midi
No additional setting is required.
-2.2 - Audio ports
------------------
+
+3 - Audiophile USB Audio support in ALSA
+========================================
Audio functions of the Audiophile USB device are handled by the snd-usb-audio
module. This module can work in a default mode (without any device-specific
parameter), or in an "advanced" mode with the device-specific parameter called
"device_setup".
-2.2.1 - Default Alsa driver mode
-
-The default behavior of the snd-usb-audio driver is to parse the device
-capabilities at startup and enable all functions inside the device (including
-all ports at any supported sample rates and sample depths). This approach
-has the advantage to let the driver easily switch from sample rates/depths
-automatically according to the need of the application claiming the device.
-
-In this case the Audiophile ports are mapped to alsa pcm devices in the
-following way (I suppose the device's index is 1):
+3.1 - Default Alsa driver mode
+------------------------------
+
+The default behavior of the snd-usb-audio driver is to list the device
+capabilities at startup and activate the required mode when required
+by the applications: for instance if the user is recording in a
+24bit-depth-mode and immediately after wants to switch to a 16bit-depth mode,
+the snd-usb-audio module will reconfigure the device on the fly.
+
+This approach has the advantage to let the driver automatically switch from sample
+rates/depths automatically according to the user's needs. However, those who
+are using the device under windows know that this is not how the device is meant to
+work: under windows applications must be closed before using the m-audio control
+panel to switch the device working mode. Thus as we'll see in next section, this
+Default Alsa driver mode can lead to device misconfigurations.
+
+Let's get back to the Default Alsa driver mode for now. In this case the
+Audiophile interfaces are mapped to alsa pcm devices in the following
+way (I suppose the device's index is 1):
* hw:1,0 is Ao in playback and Di in capture
* hw:1,1 is Do in playback and Ai in capture
* hw:1,2 is Do in AC3/DTS passthrough mode
-You must note as well that the device uses Big Endian byte encoding so that
-supported audio format are S16_BE for 16-bit depth modes and S24_3BE for
-24-bits depth mode. One exception is the hw:1,2 port which is Little Endian
-compliant and thus uses S16_LE.
+In this mode, the device uses Big Endian byte-encoding so that
+supported audio format are S16_BE for 16-bit depth modes and S24_3BE for
+24-bits depth mode.
+
+One exception is the hw:1,2 port which was reported to be Little Endian
+compliant (supposedly supporting S16_LE) but processes in fact only S16_BE streams.
+This has been fixed in kernel 2.6.23 and above and now the hw:1,2 interface
+is reported to be big endian in this default driver mode.
Examples:
* playing a S24_3BE encoded raw file to the Ao port
@@ -98,22 +121,26 @@ Examples:
% arecord -D hw:1,1 -c2 -t raw -r48000 -fS24_3BE test.raw
* playing a S16_BE encoded raw file to the Do port
% aplay -D hw:1,1 -c2 -t raw -r48000 -fS16_BE test.raw
+ * playing an ac3 sample file to the Do port
+ % aplay -D hw:1,2 --channels=6 ac3_S16_BE_encoded_file.raw
-If you're happy with the default Alsa driver setup and don't experience any
+If you're happy with the default Alsa driver mode and don't experience any
issue with this mode, then you can skip the following chapter.
-2.2.2 - Advanced module setup
+3.2 - Advanced module setup
+---------------------------
Due to the hardware constraints described above, the device initialization made
by the Alsa driver in default mode may result in a corrupted state of the
device. For instance, a particularly annoying issue is that the sound captured
-from the Ai port sounds distorted (as if boosted with an excessive high volume
-gain).
+from the Ai interface sounds distorted (as if boosted with an excessive high
+volume gain).
For people having this problem, the snd-usb-audio module has a new module
-parameter called "device_setup".
+parameter called "device_setup" (this parameter was introduced in kernel
+release 2.6.17)
-2.2.2.1 - Initializing the working mode of the Audiophile USB
+3.2.1 - Initializing the working mode of the Audiophile USB
As far as the Audiophile USB device is concerned, this value let the user
specify:
@@ -121,33 +148,57 @@ specify:
* the sample rate
* whether the Di port is used or not
-Here is a list of supported device_setup values for this device:
- * device_setup=0x00 (or omitted)
- - Alsa driver default mode
- - maintains backward compatibility with setups that do not use this
- parameter by not introducing any change
- - results sometimes in corrupted sound as described earlier
+When initialized with "device_setup=0x00", the snd-usb-audio module has
+the same behaviour as when the parameter is omitted (see paragraph "Default
+Alsa driver mode" above)
+
+Others modes are described in the following subsections.
+
+3.2.1.1 - 16-bit modes
+
+The two supported modes are:
+
* device_setup=0x01
- 16bits 48kHz mode with Di disabled
- Ai,Ao,Do can be used at the same time
- hw:1,0 is not available in capture mode
- hw:1,2 is not available
+
* device_setup=0x11
- 16bits 48kHz mode with Di enabled
- Ai,Ao,Di,Do can be used at the same time
- hw:1,0 is available in capture mode
- hw:1,2 is not available
+
+In this modes the device operates only at 16bits-modes. Before kernel 2.6.23,
+the devices where reported to be Big-Endian when in fact they were Little-Endian
+so that playing a file was a matter of using:
+ % aplay -D hw:1,1 -c2 -t raw -r48000 -fS16_BE test_S16_LE.raw
+where "test_S16_LE.raw" was in fact a little-endian sample file.
+
+Thanks to Hakan Lennestal (who discovered the Little-Endiannes of the device in
+these modes) a fix has been committed (expected in kernel 2.6.23) and
+Alsa now reports Little-Endian interfaces. Thus playing a file now is as simple as
+using:
+ % aplay -D hw:1,1 -c2 -t raw -r48000 -fS16_LE test_S16_LE.raw
+
+3.2.1.2 - 24-bit modes
+
+The three supported modes are:
+
* device_setup=0x09
- 24bits 48kHz mode with Di disabled
- Ai,Ao,Do can be used at the same time
- hw:1,0 is not available in capture mode
- hw:1,2 is not available
+
* device_setup=0x19
- 24bits 48kHz mode with Di enabled
- 3 ports from {Ai,Ao,Di,Do} can be used at the same time
- hw:1,0 is available in capture mode and an active digital source must be
connected to Di
- hw:1,2 is not available
+
* device_setup=0x0D or 0x10
- 24bits 96kHz mode
- Di is enabled by default for this mode but does not need to be connected
@@ -155,34 +206,64 @@ Here is a list of supported device_setup values for this device:
- Only 1 port from {Ai,Ao,Di,Do} can be used at the same time
- hw:1,0 is available in captured mode
- hw:1,2 is not available
+
+In these modes the device is only Big-Endian compliant (see "Default Alsa driver
+mode" above for an aplay command example)
+
+3.2.1.3 - AC3 w/ DTS passthru mode
+
+Thanks to Hakan Lennestal, I now have a report saying that this mode works.
+
* device_setup=0x03
- 16bits 48kHz mode with only the Do port enabled
- - AC3 with DTS passthru (not tested)
+ - AC3 with DTS passthru
- Caution with this setup the Do port is mapped to the pcm device hw:1,0
-2.2.2.2 - Setting and switching configurations with the device_setup parameter
+The command line used to playback the AC3/DTS encoded .wav-files in this mode:
+ % aplay -D hw:1,0 --channels=6 ac3_S16_LE_encoded_file.raw
+
+3.2.2 - How to use the device_setup parameter
+----------------------------------------------
The parameter can be given:
+
* By manually probing the device (as root):
# modprobe -r snd-usb-audio
# modprobe snd-usb-audio index=1 device_setup=0x09
+
* Or while configuring the modules options in your modules configuration file
- For Fedora distributions, edit the /etc/modprobe.conf file:
alias snd-card-1 snd-usb-audio
options snd-usb-audio index=1 device_setup=0x09
-IMPORTANT NOTE WHEN SWITCHING CONFIGURATION:
--------------------------------------------
- * You may need to _first_ initialize the module with the correct device_setup
- parameter and _only_after_ turn on the Audiophile USB device
- * This is especially true when switching the sample depth:
+CAUTION when initializaing the device
+-------------------------------------
+
+ * Correct initialization on the device requires that device_setup is given to
+ the module BEFORE the device is turned on. So, if you use the "manual probing"
+ method described above, take care to power-on the device AFTER this initialization.
+
+ * Failing to respect this will lead in a misconfiguration of the device. In this case
+ turn off the device, unproble the snd-usb-audio module, then probe it again with
+ correct device_setup parameter and then (and only then) turn on the device again.
+
+ * If you've correctly initialized the device in a valid mode and then want to switch
+ to another mode (possibly with another sample-depth), please use also the following
+ procedure:
- first turn off the device
- de-register the snd-usb-audio module (modprobe -r)
- change the device_setup parameter by changing the device_setup
option in /etc/modprobe.conf
- turn on the device
+ * A workaround for this last issue has been applied to kernel 2.6.23, but it may not
+ be enough to ensure the 'stability' of the device initialization.
-2.2.2.3 - Audiophile USB's device_setup structure
+3.2.3 - Technical details for hackers
+-------------------------------------
+This section is for hackers, wanting to understand details about the device
+internals and how Alsa supports it.
+
+3.2.3.1 - Audiophile USB's device_setup structure
If you want to understand the device_setup magic numbers for the Audiophile
USB, you need some very basic understanding of binary computation. However,
@@ -228,12 +309,12 @@ Caution:
- choosing b2 will prepare all interfaces for 24bits/96kHz but you'll
only be able to use one at the same time
-2.2.3 - USB implementation details for this device
+3.2.3.2 - USB implementation details for this device
You may safely skip this section if you're not interested in driver
-development.
+hacking.
-This section describes some internal aspects of the device and summarize the
+This section describes some internal aspects of the device and summarizes the
data I got by usb-snooping the windows and Linux drivers.
The M-Audio Audiophile USB has 7 USB Interfaces:
@@ -293,43 +374,45 @@ parse_audio_endpoints function uses a quirk called
"audiophile_skip_setting_quirk" in order to prevent AltSettings not
corresponding to device_setup from being registered in the driver.
-3 - Audiophile USB and Jack support
+4 - Audiophile USB and Jack support
===================================
This section deals with support of the Audiophile USB device in Jack.
-The main issue regarding this support is that the device is Big Endian
-compliant.
-3.1 - Using the plug alsa plugin
---------------------------------
+There are 2 main potential issues when using Jackd with the device:
+* support for Big-Endian devices in 24-bit modes
+* support for 4-in / 4-out channels
+
+4.1 - Direct support in Jackd
+-----------------------------
-Jack doesn't directly support big endian devices. Thus, one way to have support
-for this device with Alsa is to use the Alsa "plug" converter.
+Jack supports big endian devices only in recent versions (thanks to
+Andreas Steinmetz for his first big-endian patch). I can't remember
+extacly when this support was released into jackd, let's just say that
+with jackd version 0.103.0 it's almost ok (just a small bug is affecting
+16bits Big-Endian devices, but since you've read carefully the above
+paragraphs, you're now using kernel >= 2.6.23 and your 16bits devices
+are now Little Endians ;-) ).
+
+You can run jackd with the following command for playback with Ao and
+record with Ai:
+ % jackd -R -dalsa -Phw:1,0 -r48000 -p128 -n2 -D -Chw:1,1
+
+4.2 - Using Alsa plughw
+-----------------------
+If you don't have a recent Jackd installed, you can downgrade to using
+the Alsa "plug" converter.
For instance here is one way to run Jack with 2 playback channels on Ao and 2
capture channels from Ai:
% jackd -R -dalsa -dplughw:1 -r48000 -p256 -n2 -D -Cplughw:1,1
-
However you may see the following warning message:
"You appear to be using the ALSA software "plug" layer, probably a result of
using the "default" ALSA device. This is less efficient than it could be.
Consider using a hardware device instead rather than using the plug layer."
-3.2 - Patching alsa to use direct pcm device
---------------------------------------------
-A patch for Jack by Andreas Steinmetz adds support for Big Endian devices.
-However it has not been included in the CVS tree.
-
-You can find it at the following URL:
-http://sourceforge.net/tracker/index.php?func=detail&aid=1289682&group_id=39687&
-atid=425939
-
-After having applied the patch you can run jackd with the following command
-line:
- % jackd -R -dalsa -Phw:1,0 -r48000 -p128 -n2 -D -Chw:1,1
-
-3.2 - Getting 2 input and/or output interfaces in Jack
+4.3 - Getting 2 input and/or output interfaces in Jack
------------------------------------------------------
As you can see, starting the Jack server this way will only enable 1 stereo
@@ -339,6 +422,7 @@ This is due to the following restrictions:
* Jack can only open one capture device and one playback device at a time
* The Audiophile USB is seen as 2 (or three) Alsa devices: hw:1,0, hw:1,1
(and optionally hw:1,2)
+
If you want to get Ai+Di and/or Ao+Do support with Jack, you would need to
combine the Alsa devices into one logical "complex" device.
@@ -348,13 +432,11 @@ It is related to another device (ice1712) but can be adapted to suit
the Audiophile USB.
Enabling multiple Audiophile USB interfaces for Jackd will certainly require:
-* patching Jack with the previously mentioned "Big Endian" patch
-* patching Jackd with the MMAP_COMPLEX patch (see the ice1712 page)
-* patching the alsa-lib/src/pcm/pcm_multi.c file (see the ice1712 page)
+* Making sure your Jackd version has the MMAP_COMPLEX patch (see the ice1712 page)
+* (maybe) patching the alsa-lib/src/pcm/pcm_multi.c file (see the ice1712 page)
* define a multi device (combination of hw:1,0 and hw:1,1) in your .asoundrc
file
* start jackd with this device
-I had no success in testing this for now, but this may be due to my OS
-configuration. If you have any success with this kind of setup, please
-drop me an email.
+I had no success in testing this for now, if you have any success with this kind
+of setup, please drop me an email.
diff --git a/Documentation/sound/alsa/OSS-Emulation.txt b/Documentation/sound/alsa/OSS-Emulation.txt
index ec2a02541d5b..bfa0c9aacb4b 100644
--- a/Documentation/sound/alsa/OSS-Emulation.txt
+++ b/Documentation/sound/alsa/OSS-Emulation.txt
@@ -278,6 +278,21 @@ current mixer configuration by reading and writing the whole file
image.
+Duplex Streams
+==============
+
+Note that when attempting to use a single device file for playback and
+capture, the OSS API provides no way to set the format, sample rate or
+number of channels different in each direction. Thus
+ io_handle = open("device", O_RDWR)
+will only function correctly if the values are the same in each direction.
+
+To use different values in the two directions, use both
+ input_handle = open("device", O_RDONLY)
+ output_handle = open("device", O_WRONLY)
+and set the values for the corresponding handle.
+
+
Unsupported Features
====================
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-19 15:52:48 +0000