armbian/linux-rockchip
0
0
Fork 0
mirror of https://github.com/armbian/linux-rockchip.git synced 2026-01-06 11:08:10 -08:00
Code Issues Packages Projects Releases Wiki Activity

Merge commit 'v2.6.39' into for-2.6.40/core

Browse Source 
Since for-2.6.40/core was forked off the 2.6.39 devel tree, we've
had churn in the core area that makes it difficult to handle
patches for eg cfq or blk-throttle. Instead of requiring that they
be based in older versions with bugs that have been fixed later
in the rc cycle, merge in 2.6.39 final.

Also fixes up conflicts in the below files.

Conflicts:
	drivers/block/paride/pcd.c
	drivers/cdrom/viocd.c
	drivers/ide/ide-cd.c

Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
This commit is contained in:
Jens Axboe
2011-05-20 20:33:15 +02:00
parent d70d0711ed 61c4f2c81c
commit 698567f3fa
802 changed files with 8483 additions and 4484 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
Documentation/DocBook/media-entities.tmpl
View File

@@ -294,6 +294,7 @@
<!ENTITY sub-srggb10 SYSTEM "v4l/pixfmt-srggb10.xml">
<!ENTITY sub-srggb8 SYSTEM "v4l/pixfmt-srggb8.xml">
<!ENTITY sub-y10 SYSTEM "v4l/pixfmt-y10.xml">
<!ENTITY sub-y12 SYSTEM "v4l/pixfmt-y12.xml">
<!ENTITY sub-pixfmt SYSTEM "v4l/pixfmt.xml">
<!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml">
<!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">

2
Documentation/DocBook/v4l/media-ioc-setup-link.xml
View File

@@ -34,7 +34,7 @@
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>MEDIA_IOC_ENUM_LINKS</para>
<para>MEDIA_IOC_SETUP_LINK</para>
</listitem>
</varlistentry>
<varlistentry>

79
Documentation/DocBook/v4l/pixfmt-y12.xml Normal file
View File

@@ -0,0 +1,79 @@
<refentry id="V4L2-PIX-FMT-Y12">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Y12 ('Y12 ')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Y12</constant></refname>
<refpurpose>Grey-scale image</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a grey-scale image with a depth of 12 bits per pixel. Pixels
are stored in 16-bit words with unused high bits padded with 0. The least
significant byte is stored at lower memory addresses (little-endian).</para>
<example>
<title><constant>V4L2_PIX_FMT_Y12</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="9" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00low</subscript></entry>
<entry>Y'<subscript>00high</subscript></entry>
<entry>Y'<subscript>01low</subscript></entry>
<entry>Y'<subscript>01high</subscript></entry>
<entry>Y'<subscript>02low</subscript></entry>
<entry>Y'<subscript>02high</subscript></entry>
<entry>Y'<subscript>03low</subscript></entry>
<entry>Y'<subscript>03high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>10low</subscript></entry>
<entry>Y'<subscript>10high</subscript></entry>
<entry>Y'<subscript>11low</subscript></entry>
<entry>Y'<subscript>11high</subscript></entry>
<entry>Y'<subscript>12low</subscript></entry>
<entry>Y'<subscript>12high</subscript></entry>
<entry>Y'<subscript>13low</subscript></entry>
<entry>Y'<subscript>13high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Y'<subscript>20low</subscript></entry>
<entry>Y'<subscript>20high</subscript></entry>
<entry>Y'<subscript>21low</subscript></entry>
<entry>Y'<subscript>21high</subscript></entry>
<entry>Y'<subscript>22low</subscript></entry>
<entry>Y'<subscript>22high</subscript></entry>
<entry>Y'<subscript>23low</subscript></entry>
<entry>Y'<subscript>23high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Y'<subscript>30low</subscript></entry>
<entry>Y'<subscript>30high</subscript></entry>
<entry>Y'<subscript>31low</subscript></entry>
<entry>Y'<subscript>31high</subscript></entry>
<entry>Y'<subscript>32low</subscript></entry>
<entry>Y'<subscript>32high</subscript></entry>
<entry>Y'<subscript>33low</subscript></entry>
<entry>Y'<subscript>33high</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

1
Documentation/DocBook/v4l/pixfmt.xml
View File

@@ -696,6 +696,7 @@ information.</para>
&sub-packed-yuv;
&sub-grey;
&sub-y10;
&sub-y12;
&sub-y16;
&sub-yuyv;
&sub-uyvy;

59
Documentation/DocBook/v4l/subdev-formats.xml
View File

@@ -456,6 +456,23 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGBRG8-1X8">
<entry>V4L2_MBUS_FMT_SGBRG8_1X8</entry>
<entry>0x3013</entry>
<entry></entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>g<subscript>7</subscript></entry>
<entry>g<subscript>6</subscript></entry>
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGRBG8-1X8">
<entry>V4L2_MBUS_FMT_SGRBG8_1X8</entry>
<entry>0x3002</entry>
@@ -473,6 +490,23 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SRGGB8-1X8">
<entry>V4L2_MBUS_FMT_SRGGB8_1X8</entry>
<entry>0x3014</entry>
<entry></entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>r<subscript>7</subscript></entry>
<entry>r<subscript>6</subscript></entry>
<entry>r<subscript>5</subscript></entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8">
<entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry>
<entry>0x300b</entry>
@@ -2159,6 +2193,31 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-Y12-1X12">
<entry>V4L2_MBUS_FMT_Y12_1X12</entry>
<entry>0x2013</entry>
<entry></entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>11</subscript></entry>
<entry>y<subscript>10</subscript></entry>
<entry>y<subscript>9</subscript></entry>
<entry>y<subscript>8</subscript></entry>
<entry>y<subscript>7</subscript></entry>
<entry>y<subscript>6</subscript></entry>
<entry>y<subscript>5</subscript></entry>
<entry>y<subscript>4</subscript></entry>
<entry>y<subscript>3</subscript></entry>
<entry>y<subscript>2</subscript></entry>
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY8-1X16">
<entry>V4L2_MBUS_FMT_UYVY8_1X16</entry>
<entry>0x200f</entry>

15
Documentation/cgroups/memory.txt
View File

@@ -52,8 +52,10 @@ Brief summary of control files.
tasks # attach a task(thread) and show list of threads
cgroup.procs # show list of processes
cgroup.event_control # an interface for event_fd()
memory.usage_in_bytes # show current memory(RSS+Cache) usage.
memory.memsw.usage_in_bytes # show current memory+Swap usage
memory.usage_in_bytes # show current res_counter usage for memory
(See 5.5 for details)
memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap
(See 5.5 for details)
memory.limit_in_bytes # set/show limit of memory usage
memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
memory.failcnt # show the number of memory usage hits limits
@@ -453,6 +455,15 @@ memory under it will be reclaimed.
You can reset failcnt by writing 0 to failcnt file.
# echo 0 > .../memory.failcnt
5.5 usage_in_bytes
For efficiency, as other kernel components, memory cgroup uses some optimization
to avoid unnecessary cacheline false sharing. usage_in_bytes is affected by the
method and doesn't show 'exact' value of memory(and swap) usage, it's an fuzz
value for efficient access. (Of course, when necessary, it's synchronized.)
If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP)
value in memory.stat(see 5.2).
6. Hierarchy support
The memory controller supports a deep hierarchy and hierarchical accounting.

4
Documentation/flexible-arrays.txt
View File

@@ -66,10 +66,10 @@ trick is to ensure that any needed memory allocations are done before
entering atomic context, using:
int flex_array_prealloc(struct flex_array *array, unsigned int start,
unsigned int end, gfp_t flags);
unsigned int nr_elements, gfp_t flags);
This function will ensure that memory for the elements indexed in the range
defined by start and end has been allocated. Thereafter, a
defined by start and nr_elements has been allocated. Thereafter, a
flex_array_put() call on an element in that range is guaranteed not to
block.

36
Documentation/hwmon/adm1021
View File

@@ -14,10 +14,6 @@ Supported chips:
Prefix: 'gl523sm'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet:
* Intel Xeon Processor
Prefix: - any other - may require 'force_adm1021' parameter
Addresses scanned: none
Datasheet: Publicly available at Intel website
* Maxim MAX1617
Prefix: 'max1617'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
@@ -91,21 +87,27 @@ will do no harm, but will return 'old' values. It is possible to make
ADM1021-clones do faster measurements, but there is really no good reason
for that.
Xeon support
------------
Some Xeon processors have real max1617, adm1021, or compatible chips
within them, with two temperature sensors.
Netburst-based Xeon support
---------------------------
Other Xeons have chips with only one sensor.
Some Xeon processors based on the Netburst (early Pentium 4, from 2001 to
2003) microarchitecture had real MAX1617, ADM1021, or compatible chips
within them, with two temperature sensors. Other Xeon processors of this
era (with 400 MHz FSB) had chips with only one temperature sensor.
If you have a Xeon, and the adm1021 module loads, and both temperatures
appear valid, then things are good.
If you have such an old Xeon, and you get two valid temperatures when
loading the adm1021 module, then things are good.
If the adm1021 module doesn't load, you should try this:
modprobe adm1021 force_adm1021=BUS,ADDRESS
ADDRESS can only be 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e.
If nothing happens when loading the adm1021 module, and you are certain
that your specific Xeon processor model includes compatible sensors, you
will have to explicitly instantiate the sensor chips from user-space. See
method 4 in Documentation/i2c/instantiating-devices. Possible slave
addresses are 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e. It is likely that
only temp2 will be correct and temp1 will have to be ignored.
If you have dual Xeons you may have appear to have two separate
adm1021-compatible chips, or two single-temperature sensors, at distinct
addresses.
Previous generations of the Xeon processor (based on Pentium II/III)
didn't have these sensors. Next generations of Xeon processors (533 MHz
FSB and faster) lost them, until the Core-based generation which
introduced integrated digital thermal sensors. These are supported by
the coretemp driver.

29
Documentation/hwmon/lm90
View File

@@ -32,6 +32,16 @@ Supported chips:
Addresses scanned: I2C 0x4c and 0x4d
Datasheet: Publicly available at the ON Semiconductor website
http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461
* Analog Devices ADT7461A
Prefix: 'adt7461a'
Addresses scanned: I2C 0x4c and 0x4d
Datasheet: Publicly available at the ON Semiconductor website
http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461A
* ON Semiconductor NCT1008
Prefix: 'nct1008'
Addresses scanned: I2C 0x4c and 0x4d
Datasheet: Publicly available at the ON Semiconductor website
http://www.onsemi.com/PowerSolutions/product.do?id=NCT1008
* Maxim MAX6646
Prefix: 'max6646'
Addresses scanned: I2C 0x4d
@@ -149,7 +159,7 @@ ADM1032:
* ALERT is triggered by open remote sensor.
* SMBus PEC support for Write Byte and Receive Byte transactions.
ADT7461:
ADT7461, ADT7461A, NCT1008:
* Extended temperature range (breaks compatibility)
* Lower resolution for remote temperature
@@ -195,9 +205,9 @@ are exported, one for each channel, but these values are of course linked.
Only the local hysteresis can be set from user-space, and the same delta
applies to the remote hysteresis.
The lm90 driver will not update its values more frequently than every
other second; reading them more often will do no harm, but will return
'old' values.
The lm90 driver will not update its values more frequently than configured with
the update_interval attribute; reading them more often will do no harm, but will
return 'old' values.
SMBus Alert Support
-------------------
@@ -205,11 +215,12 @@ SMBus Alert Support
This driver has basic support for SMBus alert. When an alert is received,
the status register is read and the faulty temperature channel is logged.
The Analog Devices chips (ADM1032 and ADT7461) do not implement the SMBus
alert protocol properly so additional care is needed: the ALERT output is
disabled when an alert is received, and is re-enabled only when the alarm
is gone. Otherwise the chip would block alerts from other chips in the bus
as long as the alarm is active.
The Analog Devices chips (ADM1032, ADT7461 and ADT7461A) and ON
Semiconductor chips (NCT1008) do not implement the SMBus alert protocol
properly so additional care is needed: the ALERT output is disabled when
an alert is received, and is re-enabled only when the alarm is gone.
Otherwise the chip would block alerts from other chips in the bus as long
as the alarm is active.
PEC Support
-----------

62
Documentation/hwmon/max16064 Normal file
View File

@@ -0,0 +1,62 @@
Kernel driver max16064
======================
Supported chips:
* Maxim MAX16064
Prefix: 'max16064'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Description
-----------
This driver supports hardware montoring for Maxim MAX16064 Quad Power-Supply
Controller with Active-Voltage Output Control and PMBus Interface.
The driver is a client driver to the core PMBus driver.
Please see Documentation/hwmon/pmbus for details on PMBus client drivers.
Usage Notes
-----------
This driver does not auto-detect devices. You will have to instantiate the
devices explicitly. Please see Documentation/i2c/instantiating-devices for
details.
Platform data support
---------------------
The driver supports standard PMBus driver platform data.
Sysfs entries
-------------
The following attributes are supported. Limits are read-write; all other
attributes are read-only.
in[1-4]_label "vout[1-4]"
in[1-4]_input Measured voltage. From READ_VOUT register.
in[1-4]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
in[1-4]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
in[1-4]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
in[1-4]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
in[1-4]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
in[1-4]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
in[1-4]_lcrit_alarm Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
in[1-4]_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
temp1_input Measured temperature. From READ_TEMPERATURE_1 register.
temp1_max Maximum temperature. From OT_WARN_LIMIT register.
temp1_crit Critical high temperature. From OT_FAULT_LIMIT register.
temp1_max_alarm Chip temperature high alarm. Set by comparing
READ_TEMPERATURE_1 with OT_WARN_LIMIT if TEMP_OT_WARNING
status is set.
temp1_crit_alarm Chip temperature critical high alarm. Set by comparing
READ_TEMPERATURE_1 with OT_FAULT_LIMIT if TEMP_OT_FAULT
status is set.

79
Documentation/hwmon/max34440 Normal file
View File

@@ -0,0 +1,79 @@
Kernel driver max34440
======================
Supported chips:
* Maxim MAX34440
Prefixes: 'max34440'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34440.pdf
* Maxim MAX34441
PMBus 5-Channel Power-Supply Manager and Intelligent Fan Controller
Prefixes: 'max34441'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34441.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Description
-----------
This driver supports hardware montoring for Maxim MAX34440 PMBus 6-Channel
Power-Supply Manager and MAX34441 PMBus 5-Channel Power-Supply Manager
and Intelligent Fan Controller.
The driver is a client driver to the core PMBus driver. Please see
Documentation/hwmon/pmbus for details on PMBus client drivers.
Usage Notes
-----------
This driver does not auto-detect devices. You will have to instantiate the
devices explicitly. Please see Documentation/i2c/instantiating-devices for
details.
Platform data support
---------------------
The driver supports standard PMBus driver platform data.
Sysfs entries
-------------
The following attributes are supported. Limits are read-write; all other
attributes are read-only.
in[1-6]_label "vout[1-6]".
in[1-6]_input Measured voltage. From READ_VOUT register.
in[1-6]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
in[1-6]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
in[1-6]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
in[1-6]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
in[1-6]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
in[1-6]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
in[1-6]_lcrit_alarm Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
in[1-6]_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
curr[1-6]_label "iout[1-6]".
curr[1-6]_input Measured current. From READ_IOUT register.
curr[1-6]_max Maximum current. From IOUT_OC_WARN_LIMIT register.
curr[1-6]_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
curr[1-6]_max_alarm Current high alarm. From IOUT_OC_WARNING status.
curr[1-6]_crit_alarm Current critical high alarm. From IOUT_OC_FAULT status.
in6 and curr6 attributes only exist for MAX34440.
temp[1-8]_input Measured temperatures. From READ_TEMPERATURE_1 register.
temp1 is the chip's internal temperature. temp2..temp5
are remote I2C temperature sensors. For MAX34441, temp6
is a remote thermal-diode sensor. For MAX34440, temp6..8
are remote I2C temperature sensors.
temp[1-8]_max Maximum temperature. From OT_WARN_LIMIT register.
temp[1-8]_crit Critical high temperature. From OT_FAULT_LIMIT register.
temp[1-8]_max_alarm Temperature high alarm.
temp[1-8]_crit_alarm Temperature critical high alarm.
temp7 and temp8 attributes only exist for MAX34440.

69
Documentation/hwmon/max8688 Normal file
View File

@@ -0,0 +1,69 @@
Kernel driver max8688
=====================
Supported chips:
* Maxim MAX8688
Prefix: 'max8688'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Description
-----------
This driver supports hardware montoring for Maxim MAX8688 Digital Power-Supply
Controller/Monitor with PMBus Interface.
The driver is a client driver to the core PMBus driver. Please see
Documentation/hwmon/pmbus for details on PMBus client drivers.
Usage Notes
-----------
This driver does not auto-detect devices. You will have to instantiate the
devices explicitly. Please see Documentation/i2c/instantiating-devices for
details.
Platform data support
---------------------
The driver supports standard PMBus driver platform data.
Sysfs entries
-------------
The following attributes are supported. Limits are read-write; all other
attributes are read-only.
in1_label "vout1"
in1_input Measured voltage. From READ_VOUT register.
in1_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
in1_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
in1_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
in1_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
in1_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
in1_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
in1_lcrit_alarm Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
in1_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
curr1_label "iout1"
curr1_input Measured current. From READ_IOUT register.
curr1_max Maximum current. From IOUT_OC_WARN_LIMIT register.
curr1_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
curr1_max_alarm Current high alarm. From IOUT_OC_WARN_LIMIT register.
curr1_crit_alarm Current critical high alarm. From IOUT_OC_FAULT status.
temp1_input Measured temperature. From READ_TEMPERATURE_1 register.
temp1_max Maximum temperature. From OT_WARN_LIMIT register.
temp1_crit Critical high temperature. From OT_FAULT_LIMIT register.
temp1_max_alarm Chip temperature high alarm. Set by comparing
READ_TEMPERATURE_1 with OT_WARN_LIMIT if TEMP_OT_WARNING
status is set.
temp1_crit_alarm Chip temperature critical high alarm. Set by comparing
READ_TEMPERATURE_1 with OT_FAULT_LIMIT if TEMP_OT_FAULT
status is set.

34
Documentation/hwmon/pmbus
View File

@@ -13,26 +13,6 @@ Supported chips:
Prefix: 'ltc2978'
Addresses scanned: -
Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf
* Maxim MAX16064
Quad Power-Supply Controller
Prefix: 'max16064'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf
* Maxim MAX34440
PMBus 6-Channel Power-Supply Manager
Prefixes: 'max34440'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34440.pdf
* Maxim MAX34441
PMBus 5-Channel Power-Supply Manager and Intelligent Fan Controller
Prefixes: 'max34441'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34441.pdf
* Maxim MAX8688
Digital Power-Supply Controller/Monitor
Prefix: 'max8688'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf
* Generic PMBus devices
Prefix: 'pmbus'
Addresses scanned: -
@@ -175,11 +155,13 @@ currX_crit Critical maximum current.
From IIN_OC_FAULT_LIMIT or IOUT_OC_FAULT_LIMIT register.
currX_alarm Current high alarm.
From IIN_OC_WARNING or IOUT_OC_WARNING status.
currX_max_alarm Current high alarm.
From IIN_OC_WARN_LIMIT or IOUT_OC_WARN_LIMIT status.
currX_lcrit_alarm Output current critical low alarm.
From IOUT_UC_FAULT status.
currX_crit_alarm Current critical high alarm.
From IIN_OC_FAULT or IOUT_OC_FAULT status.
currX_label "iin" or "vinY"
currX_label "iin" or "ioutY"
powerX_input Measured power. From READ_PIN or READ_POUT register.
powerX_cap Output power cap. From POUT_MAX register.
@@ -193,13 +175,13 @@ powerX_crit_alarm Output power critical high alarm.
From POUT_OP_FAULT status.
powerX_label "pin" or "poutY"
tempX_input Measured tempererature.
tempX_input Measured temperature.
From READ_TEMPERATURE_X register.
tempX_min Mimimum tempererature. From UT_WARN_LIMIT register.
tempX_max Maximum tempererature. From OT_WARN_LIMIT register.
tempX_lcrit Critical low tempererature.
tempX_min Mimimum temperature. From UT_WARN_LIMIT register.
tempX_max Maximum temperature. From OT_WARN_LIMIT register.
tempX_lcrit Critical low temperature.
From UT_FAULT_LIMIT register.
tempX_crit Critical high tempererature.
tempX_crit Critical high temperature.
From OT_FAULT_LIMIT register.
tempX_min_alarm Chip temperature low alarm. Set by comparing
READ_TEMPERATURE_X with UT_WARN_LIMIT if

8
Documentation/hwmon/smm665
View File

@@ -150,8 +150,8 @@ in8_crit_alarm Channel F critical alarm
in9_crit_alarm AIN1 critical alarm
in10_crit_alarm AIN2 critical alarm
temp1_input Chip tempererature
temp1_min Mimimum chip tempererature
temp1_max Maximum chip tempererature
temp1_crit Critical chip tempererature
temp1_input Chip temperature
temp1_min Mimimum chip temperature
temp1_max Maximum chip temperature
temp1_crit Critical chip temperature
temp1_crit_alarm Temperature critical alarm

109
Documentation/hwmon/submitting-patches Normal file
View File

@@ -0,0 +1,109 @@
How to Get Your Patch Accepted Into the Hwmon Subsystem
-------------------------------------------------------
This text is is a collection of suggestions for people writing patches or
drivers for the hwmon subsystem. Following these suggestions will greatly
increase the chances of your change being accepted.
1. General
----------
* It should be unnecessary to mention, but please read and follow
Documentation/SubmitChecklist
Documentation/SubmittingDrivers
Documentation/SubmittingPatches
Documentation/CodingStyle
* If your patch generates checkpatch warnings, please refrain from explanations
such as "I don't like that coding style". Keep in mind that each unnecessary
warning helps hiding a real problem. If you don't like the kernel coding
style, don't write kernel drivers.
* Please test your patch thoroughly. We are not your test group.
Sometimes a patch can not or not completely be tested because of missing
hardware. In such cases, you should test-build the code on at least one
architecture. If run-time testing was not achieved, it should be written
explicitly below the patch header.
* If your patch (or the driver) is affected by configuration options such as
CONFIG_SMP or CONFIG_HOTPLUG, make sure it compiles for all configuration
variants.
2. Adding functionality to existing drivers
-------------------------------------------
* Make sure the documentation in Documentation/hwmon/<driver_name> is up to
date.
* Make sure the information in Kconfig is up to date.
* If the added functionality requires some cleanup or structural changes, split
your patch into a cleanup part and the actual addition. This makes it easier
to review your changes, and to bisect any resulting problems.
* Never mix bug fixes, cleanup, and functional enhancements in a single patch.
3. New drivers
--------------
* Running your patch or driver file(s) through checkpatch does not mean its
formatting is clean. If unsure about formatting in your new driver, run it
through Lindent. Lindent is not perfect, and you may have to do some minor
cleanup, but it is a good start.
* Consider adding yourself to MAINTAINERS.
* Document the driver in Documentation/hwmon/<driver_name>.
* Add the driver to Kconfig and Makefile in alphabetical order.
* Make sure that all dependencies are listed in Kconfig. For new drivers, it
is most likely prudent to add a dependency on EXPERIMENTAL.
* Avoid forward declarations if you can. Rearrange the code if necessary.
* Avoid calculations in macros and macro-generated functions. While such macros
may save a line or so in the source, it obfuscates the code and makes code
review more difficult. It may also result in code which is more complicated
than necessary. Use inline functions or just regular functions instead.
* If the driver has a detect function, make sure it is silent. Debug messages
and messages printed after a successful detection are acceptable, but it
must not print messages such as "Chip XXX not found/supported".
Keep in mind that the detect function will run for all drivers supporting an
address if a chip is detected on that address. Unnecessary messages will just
pollute the kernel log and not provide any value.
* Provide a detect function if and only if a chip can be detected reliably.
* Avoid writing to chip registers in the detect function. If you have to write,
only do it after you have already gathered enough data to be certain that the
detection is going to be successful.
Keep in mind that the chip might not be what your driver believes it is, and
writing to it might cause a bad misconfiguration.
* Make sure there are no race conditions in the probe function. Specifically,
completely initialize your chip first, then create sysfs entries and register
with the hwmon subsystem.
* Do not provide support for deprecated sysfs attributes.
* Do not create non-standard attributes unless really needed. If you have to use
non-standard attributes, or you believe you do, discuss it on the mailing list
first. Either case, provide a detailed explanation why you need the
non-standard attribute(s).
Standard attributes are specified in Documentation/hwmon/sysfs-interface.
* When deciding which sysfs attributes to support, look at the chip's
capabilities. While we do not expect your driver to support everything the
chip may offer, it should at least support all limits and alarms.
* Last but not least, please check if a driver for your chip already exists
before starting to write a new driver. Especially for temperature sensors,
new chips are often variants of previously released chips. In some cases,
a presumably new chip may simply have been relabeled.

10
Documentation/md.txt
View File

@@ -552,6 +552,16 @@ also have
within the array where IO will be blocked. This is currently
only supported for raid4/5/6.
sync_min
sync_max
The two values, given as numbers of sectors, indicate a range
withing the array where 'check'/'repair' will operate. Must be
a multiple of chunk_size. When it reaches "sync_max" it will
pause, rather than complete.
You can use 'select' or 'poll' on "sync_completed" to wait for
that number to reach sync_max. Then you can either increase
"sync_max", or can write 'idle' to "sync_action".
Each active md device may also have attributes specific to the
personality module that manages it.

6
Documentation/sound/alsa/SB-Live-mixer.txt
View File

@@ -87,14 +87,14 @@ accumulator. ALSA uses accumulators 0 and 1 for left and right PCM.
The result is forwarded to the ADC capture FIFO (thus to the standard capture
PCM device).
name='Music Playback Volume',index=0
name='Synth Playback Volume',index=0
This control is used to attenuate samples for left and right MIDI FX-bus
accumulators. ALSA uses accumulators 4 and 5 for left and right MIDI samples.
The result samples are forwarded to the front DAC PCM slots of the AC97 codec.
name='Music Capture Volume',index=0
name='Music Capture Switch',index=0
name='Synth Capture Volume',index=0
name='Synth Capture Switch',index=0
These controls are used to attenuate samples for left and right MIDI FX-bus
accumulator. ALSA uses accumulators 4 and 5 for left and right PCM.

6
Documentation/video4linux/sh_mobile_ceu_camera.txt
View File

@@ -37,7 +37,7 @@ Generic scaling / cropping scheme
-1'-
In the above chart minuses and slashes represent "real" data amounts, points and
accents represent "useful" data, basically, CEU scaled amd cropped output,
accents represent "useful" data, basically, CEU scaled and cropped output,
mapped back onto the client's source plane.
Such a configuration can be produced by user requests:
@@ -65,7 +65,7 @@ Do not touch input rectangle - it is already optimal.
1. Calculate current sensor scales:
scale_s = ((3') - (3)) / ((2') - (2))
scale_s = ((2') - (2)) / ((3') - (3))
2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at
current sensor scales onto input window - this is user S_CROP:
@@ -80,7 +80,7 @@ window:
4. Calculate sensor output window by applying combined scales to real input
window:
width_s_out = ((2') - (2)) / scale_comb
width_s_out = ((7') - (7)) = ((2') - (2)) / scale_comb
5. Apply iterative sensor S_FMT for sensor output window.

40
Documentation/workqueue.txt
View File

@@ -12,6 +12,7 @@ CONTENTS
4. Application Programming Interface (API)
5. Example Execution Scenarios
6. Guidelines
7. Debugging
1. Introduction
@@ -379,3 +380,42 @@ If q1 has WQ_CPU_INTENSIVE set,
* Unless work items are expected to consume a huge amount of CPU
cycles, using a bound wq is usually beneficial due to the increased
level of locality in wq operations and work item execution.
7. Debugging
Because the work functions are executed by generic worker threads
there are a few tricks needed to shed some light on misbehaving
workqueue users.
Worker threads show up in the process list as:
root 5671 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/0:1]
root 5672 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/1:2]
root 5673 0.0 0.0 0 0 ? S 12:12 0:00 [kworker/0:0]
root 5674 0.0 0.0 0 0 ? S 12:13 0:00 [kworker/1:0]
If kworkers are going crazy (using too much cpu), there are two types
of possible problems:
1. Something beeing scheduled in rapid succession
2. A single work item that consumes lots of cpu cycles
The first one can be tracked using tracing:
$ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace_pipe > out.txt
(wait a few secs)
^C
If something is busy looping on work queueing, it would be dominating
the output and the offender can be determined with the work item
function.
For the second type of problems it should be possible to just check
the stack trace of the offending worker thread.
$ cat /proc/THE_OFFENDING_KWORKER/stack
The work item's function should be trivially visible in the stack
trace.

114
MAINTAINERS
View File

@@ -151,6 +151,7 @@ S: Maintained
F: drivers/net/hamradio/6pack.c
8169 10/100/1000 GIGABIT ETHERNET DRIVER
M: Realtek linux nic maintainers <nic_swsd@realtek.com>
M: Francois Romieu <romieu@fr.zoreil.com>
L: netdev@vger.kernel.org
S: Maintained
@@ -1031,12 +1032,13 @@ W: http://www.fluff.org/ben/linux/
S: Maintained
F: arch/arm/mach-s3c64xx/
ARM/S5P ARM ARCHITECTURES
ARM/S5P EXYNOS ARM ARCHITECTURES
M: Kukjin Kim <kgene.kim@samsung.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-s5p*/
F: arch/arm/mach-exynos*/
ARM/SAMSUNG MOBILE MACHINE SUPPORT
M: Kyungmin Park <kyungmin.park@samsung.com>
@@ -2807,42 +2809,23 @@ GPIO SUBSYSTEM
M: Grant Likely <grant.likely@secretlab.ca>
S: Maintained
T: git git://git.secretlab.ca/git/linux-2.6.git
F: Documentation/gpio/gpio.txt
F: Documentation/gpio.txt
F: drivers/gpio/
F: include/linux/gpio*
GRE DEMULTIPLEXER DRIVER
M: Dmitry Kozlov <xeb@mail.ru>
L: netdev@vger.kernel.org
S: Maintained
F: net/ipv4/gre.c
F: include/net/gre.h
GRETH 10/100/1G Ethernet MAC device driver
M: Kristoffer Glembo <kristoffer@gaisler.com>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/greth*
HARD DRIVE ACTIVE PROTECTION SYSTEM (HDAPS) DRIVER
M: Frank Seidel <frank@f-seidel.de>
L: platform-driver-x86@vger.kernel.org
W: http://www.kernel.org/pub/linux/kernel/people/fseidel/hdaps/
S: Maintained
F: drivers/platform/x86/hdaps.c
HWPOISON MEMORY FAILURE HANDLING
M: Andi Kleen <andi@firstfloor.org>
L: linux-mm@kvack.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-mce-2.6.git hwpoison
S: Maintained
F: mm/memory-failure.c
F: mm/hwpoison-inject.c
HYPERVISOR VIRTUAL CONSOLE DRIVER
L: linuxppc-dev@lists.ozlabs.org
S: Odd Fixes
F: drivers/tty/hvc/
iSCSI BOOT FIRMWARE TABLE (iBFT) DRIVER
M: Peter Jones <pjones@redhat.com>
M: Konrad Rzeszutek Wilk <konrad@kernel.org>
S: Maintained
F: drivers/firmware/iscsi_ibft*
GSPCA FINEPIX SUBDRIVER
M: Frank Zago <frank@zago.net>
L: linux-media@vger.kernel.org
@@ -2893,6 +2876,26 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
S: Maintained
F: drivers/media/video/gspca/
HARD DRIVE ACTIVE PROTECTION SYSTEM (HDAPS) DRIVER
M: Frank Seidel <frank@f-seidel.de>
L: platform-driver-x86@vger.kernel.org
W: http://www.kernel.org/pub/linux/kernel/people/fseidel/hdaps/
S: Maintained
F: drivers/platform/x86/hdaps.c
HWPOISON MEMORY FAILURE HANDLING
M: Andi Kleen <andi@firstfloor.org>
L: linux-mm@kvack.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-mce-2.6.git hwpoison
S: Maintained
F: mm/memory-failure.c
F: mm/hwpoison-inject.c
HYPERVISOR VIRTUAL CONSOLE DRIVER
L: linuxppc-dev@lists.ozlabs.org
S: Odd Fixes
F: drivers/tty/hvc/
HARDWARE MONITORING
M: Jean Delvare <khali@linux-fr.org>
M: Guenter Roeck <guenter.roeck@ericsson.com>
@@ -3476,6 +3479,12 @@ F: Documentation/isapnp.txt
F: drivers/pnp/isapnp/
F: include/linux/isapnp.h
iSCSI BOOT FIRMWARE TABLE (iBFT) DRIVER
M: Peter Jones <pjones@redhat.com>
M: Konrad Rzeszutek Wilk <konrad@kernel.org>
S: Maintained
F: drivers/firmware/iscsi_ibft*
ISCSI
M: Mike Christie <michaelc@cs.wisc.edu>
L: open-iscsi@googlegroups.com
@@ -4987,6 +4996,13 @@ F: Documentation/pps/
F: drivers/pps/
F: include/linux/pps*.h
PPTP DRIVER
M: Dmitry Kozlov <xeb@mail.ru>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/pptp.c
W: http://sourceforge.net/projects/accel-pptp
PREEMPTIBLE KERNEL
M: Robert Love <rml@tech9.net>
L: kpreempt-tech@lists.sourceforge.net
@@ -5395,7 +5411,7 @@ F: drivers/media/video/*7146*
F: include/media/*7146*
SAMSUNG AUDIO (ASoC) DRIVERS
M: Jassi Brar <jassi.brar@samsung.com>
M: Jassi Brar <jassisinghbrar@gmail.com>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Supported
F: sound/soc/samsung
@@ -6554,7 +6570,7 @@ S: Maintained
F: drivers/usb/host/uhci*
USB "USBNET" DRIVER FRAMEWORK
M: David Brownell <dbrownell@users.sourceforge.net>
M: Oliver Neukum <oneukum@suse.de>
L: netdev@vger.kernel.org
W: http://www.linux-usb.org/usbnet
S: Maintained
@@ -6920,6 +6936,18 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86.
S: Maintained
F: drivers/platform/x86
XEN HYPERVISOR INTERFACE
M: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
L: virtualization@lists.linux-foundation.org
S: Supported
F: arch/x86/xen/
F: drivers/*/xen-*front.c
F: drivers/xen/
F: arch/x86/include/asm/xen/
F: include/xen/
XEN NETWORK BACKEND DRIVER
M: Ian Campbell <ian.campbell@citrix.com>
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
@@ -6941,18 +6969,6 @@ S: Supported
F: arch/x86/xen/*swiotlb*
F: drivers/xen/*swiotlb*
XEN HYPERVISOR INTERFACE
M: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
L: virtualization@lists.linux-foundation.org
S: Supported
F: arch/x86/xen/
F: drivers/*/xen-*front.c
F: drivers/xen/
F: arch/x86/include/asm/xen/
F: include/xen/
XFS FILESYSTEM
P: Silicon Graphics Inc
M: Alex Elder <aelder@sgi.com>
@@ -7022,20 +7038,6 @@ M: "Maciej W. Rozycki" <macro@linux-mips.org>
S: Maintained
F: drivers/tty/serial/zs.*
GRE DEMULTIPLEXER DRIVER
M: Dmitry Kozlov <xeb@mail.ru>
L: netdev@vger.kernel.org
S: Maintained
F: net/ipv4/gre.c
F: include/net/gre.h
PPTP DRIVER
M: Dmitry Kozlov <xeb@mail.ru>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/pptp.c
W: http://sourceforge.net/projects/accel-pptp
THE REST
M: Linus Torvalds <torvalds@linux-foundation.org>
L: linux-kernel@vger.kernel.org

Some files were not shown because too many files have changed in this diff Show More