You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge commit 'v2.6.39-rc7' into sched/core
This commit is contained in:
Ingo Molnar
@@ -294,6 +294,7 @@
|
|||||||
<!ENTITY sub-srggb10 SYSTEM "v4l/pixfmt-srggb10.xml">
|
<!ENTITY sub-srggb10 SYSTEM "v4l/pixfmt-srggb10.xml">
|
||||||
<!ENTITY sub-srggb8 SYSTEM "v4l/pixfmt-srggb8.xml">
|
<!ENTITY sub-srggb8 SYSTEM "v4l/pixfmt-srggb8.xml">
|
||||||
<!ENTITY sub-y10 SYSTEM "v4l/pixfmt-y10.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-pixfmt SYSTEM "v4l/pixfmt.xml">
|
||||||
<!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml">
|
<!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml">
|
||||||
<!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">
|
<!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">
|
||||||
|
|||||||
@@ -34,7 +34,7 @@
|
|||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term><parameter>request</parameter></term>
|
<term><parameter>request</parameter></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>MEDIA_IOC_ENUM_LINKS</para>
|
<para>MEDIA_IOC_SETUP_LINK</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
|
|||||||
@@ -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 × 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 + 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 + 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 + 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 + 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>
|
||||||
@@ -696,6 +696,7 @@ information.</para>
|
|||||||
&sub-packed-yuv;
|
&sub-packed-yuv;
|
||||||
&sub-grey;
|
&sub-grey;
|
||||||
&sub-y10;
|
&sub-y10;
|
||||||
|
&sub-y12;
|
||||||
&sub-y16;
|
&sub-y16;
|
||||||
&sub-yuyv;
|
&sub-yuyv;
|
||||||
&sub-uyvy;
|
&sub-uyvy;
|
||||||
|
|||||||
@@ -456,6 +456,23 @@
|
|||||||
<entry>b<subscript>1</subscript></entry>
|
<entry>b<subscript>1</subscript></entry>
|
||||||
<entry>b<subscript>0</subscript></entry>
|
<entry>b<subscript>0</subscript></entry>
|
||||||
</row>
|
</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">
|
<row id="V4L2-MBUS-FMT-SGRBG8-1X8">
|
||||||
<entry>V4L2_MBUS_FMT_SGRBG8_1X8</entry>
|
<entry>V4L2_MBUS_FMT_SGRBG8_1X8</entry>
|
||||||
<entry>0x3002</entry>
|
<entry>0x3002</entry>
|
||||||
@@ -473,6 +490,23 @@
|
|||||||
<entry>g<subscript>1</subscript></entry>
|
<entry>g<subscript>1</subscript></entry>
|
||||||
<entry>g<subscript>0</subscript></entry>
|
<entry>g<subscript>0</subscript></entry>
|
||||||
</row>
|
</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">
|
<row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8">
|
||||||
<entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry>
|
<entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry>
|
||||||
<entry>0x300b</entry>
|
<entry>0x300b</entry>
|
||||||
@@ -2159,6 +2193,31 @@
|
|||||||
<entry>u<subscript>1</subscript></entry>
|
<entry>u<subscript>1</subscript></entry>
|
||||||
<entry>u<subscript>0</subscript></entry>
|
<entry>u<subscript>0</subscript></entry>
|
||||||
</row>
|
</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">
|
<row id="V4L2-MBUS-FMT-UYVY8-1X16">
|
||||||
<entry>V4L2_MBUS_FMT_UYVY8_1X16</entry>
|
<entry>V4L2_MBUS_FMT_UYVY8_1X16</entry>
|
||||||
<entry>0x200f</entry>
|
<entry>0x200f</entry>
|
||||||
|
|||||||
@@ -52,8 +52,10 @@ Brief summary of control files.
|
|||||||
tasks # attach a task(thread) and show list of threads
|
tasks # attach a task(thread) and show list of threads
|
||||||
cgroup.procs # show list of processes
|
cgroup.procs # show list of processes
|
||||||
cgroup.event_control # an interface for event_fd()
|
cgroup.event_control # an interface for event_fd()
|
||||||
memory.usage_in_bytes # show current memory(RSS+Cache) usage.
|
memory.usage_in_bytes # show current res_counter usage for memory
|
||||||
memory.memsw.usage_in_bytes # show current memory+Swap usage
|
(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.limit_in_bytes # set/show limit of memory usage
|
||||||
memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
|
memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
|
||||||
memory.failcnt # show the number of memory usage hits limits
|
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.
|
You can reset failcnt by writing 0 to failcnt file.
|
||||||
# echo 0 > .../memory.failcnt
|
# 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
|
6. Hierarchy support
|
||||||
|
|
||||||
The memory controller supports a deep hierarchy and hierarchical accounting.
|
The memory controller supports a deep hierarchy and hierarchical accounting.
|
||||||
|
|||||||
@@ -66,10 +66,10 @@ trick is to ensure that any needed memory allocations are done before
|
|||||||
entering atomic context, using:
|
entering atomic context, using:
|
||||||
|
|
||||||
int flex_array_prealloc(struct flex_array *array, unsigned int start,
|
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
|
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
|
flex_array_put() call on an element in that range is guaranteed not to
|
||||||
block.
|
block.
|
||||||
|
|
||||||
|
|||||||
+19
-17
@@ -14,10 +14,6 @@ Supported chips:
|
|||||||
Prefix: 'gl523sm'
|
Prefix: 'gl523sm'
|
||||||
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
||||||
Datasheet:
|
Datasheet:
|
||||||
* Intel Xeon Processor
|
|
||||||
Prefix: - any other - may require 'force_adm1021' parameter
|
|
||||||
Addresses scanned: none
|
|
||||||
Datasheet: Publicly available at Intel website
|
|
||||||
* Maxim MAX1617
|
* Maxim MAX1617
|
||||||
Prefix: 'max1617'
|
Prefix: 'max1617'
|
||||||
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
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
|
ADM1021-clones do faster measurements, but there is really no good reason
|
||||||
for that.
|
for that.
|
||||||
|
|
||||||
Xeon support
|
|
||||||
------------
|
|
||||||
|
|
||||||
Some Xeon processors have real max1617, adm1021, or compatible chips
|
Netburst-based Xeon support
|
||||||
within them, with two temperature sensors.
|
---------------------------
|
||||||
|
|
||||||
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
|
If you have such an old Xeon, and you get two valid temperatures when
|
||||||
appear valid, then things are good.
|
loading the adm1021 module, then things are good.
|
||||||
|
|
||||||
If the adm1021 module doesn't load, you should try this:
|
If nothing happens when loading the adm1021 module, and you are certain
|
||||||
modprobe adm1021 force_adm1021=BUS,ADDRESS
|
that your specific Xeon processor model includes compatible sensors, you
|
||||||
ADDRESS can only be 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e.
|
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
|
Previous generations of the Xeon processor (based on Pentium II/III)
|
||||||
adm1021-compatible chips, or two single-temperature sensors, at distinct
|
didn't have these sensors. Next generations of Xeon processors (533 MHz
|
||||||
addresses.
|
FSB and faster) lost them, until the Core-based generation which
|
||||||
|
introduced integrated digital thermal sensors. These are supported by
|
||||||
|
the coretemp driver.
|
||||||
|
|||||||
@@ -32,6 +32,16 @@ Supported chips:
|
|||||||
Addresses scanned: I2C 0x4c and 0x4d
|
Addresses scanned: I2C 0x4c and 0x4d
|
||||||
Datasheet: Publicly available at the ON Semiconductor website
|
Datasheet: Publicly available at the ON Semiconductor website
|
||||||
http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461
|
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
|
* Maxim MAX6646
|
||||||
Prefix: 'max6646'
|
Prefix: 'max6646'
|
||||||
Addresses scanned: I2C 0x4d
|
Addresses scanned: I2C 0x4d
|
||||||
@@ -149,7 +159,7 @@ ADM1032:
|
|||||||
* ALERT is triggered by open remote sensor.
|
* ALERT is triggered by open remote sensor.
|
||||||
* SMBus PEC support for Write Byte and Receive Byte transactions.
|
* SMBus PEC support for Write Byte and Receive Byte transactions.
|
||||||
|
|
||||||
ADT7461:
|
ADT7461, ADT7461A, NCT1008:
|
||||||
* Extended temperature range (breaks compatibility)
|
* Extended temperature range (breaks compatibility)
|
||||||
* Lower resolution for remote temperature
|
* 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
|
Only the local hysteresis can be set from user-space, and the same delta
|
||||||
applies to the remote hysteresis.
|
applies to the remote hysteresis.
|
||||||
|
|
||||||
The lm90 driver will not update its values more frequently than every
|
The lm90 driver will not update its values more frequently than configured with
|
||||||
other second; reading them more often will do no harm, but will return
|
the update_interval attribute; reading them more often will do no harm, but will
|
||||||
'old' values.
|
return 'old' values.
|
||||||
|
|
||||||
SMBus Alert Support
|
SMBus Alert Support
|
||||||
-------------------
|
-------------------
|
||||||
@@ -205,11 +215,12 @@ SMBus Alert Support
|
|||||||
This driver has basic support for SMBus alert. When an alert is received,
|
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 status register is read and the faulty temperature channel is logged.
|
||||||
|
|
||||||
The Analog Devices chips (ADM1032 and ADT7461) do not implement the SMBus
|
The Analog Devices chips (ADM1032, ADT7461 and ADT7461A) and ON
|
||||||
alert protocol properly so additional care is needed: the ALERT output is
|
Semiconductor chips (NCT1008) do not implement the SMBus alert protocol
|
||||||
disabled when an alert is received, and is re-enabled only when the alarm
|
properly so additional care is needed: the ALERT output is disabled when
|
||||||
is gone. Otherwise the chip would block alerts from other chips in the bus
|
an alert is received, and is re-enabled only when the alarm is gone.
|
||||||
as long as the alarm is active.
|
Otherwise the chip would block alerts from other chips in the bus as long
|
||||||
|
as the alarm is active.
|
||||||
|
|
||||||
PEC Support
|
PEC Support
|
||||||
-----------
|
-----------
|
||||||
|
|||||||
@@ -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.
|
||||||
@@ -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.
|
||||||
@@ -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.
|
||||||
@@ -13,26 +13,6 @@ Supported chips:
|
|||||||
Prefix: 'ltc2978'
|
Prefix: 'ltc2978'
|
||||||
Addresses scanned: -
|
Addresses scanned: -
|
||||||
Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf
|
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
|
* Generic PMBus devices
|
||||||
Prefix: 'pmbus'
|
Prefix: 'pmbus'
|
||||||
Addresses scanned: -
|
Addresses scanned: -
|
||||||
@@ -175,11 +155,13 @@ currX_crit Critical maximum current.
|
|||||||
From IIN_OC_FAULT_LIMIT or IOUT_OC_FAULT_LIMIT register.
|
From IIN_OC_FAULT_LIMIT or IOUT_OC_FAULT_LIMIT register.
|
||||||
currX_alarm Current high alarm.
|
currX_alarm Current high alarm.
|
||||||
From IIN_OC_WARNING or IOUT_OC_WARNING status.
|
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.
|
currX_lcrit_alarm Output current critical low alarm.
|
||||||
From IOUT_UC_FAULT status.
|
From IOUT_UC_FAULT status.
|
||||||
currX_crit_alarm Current critical high alarm.
|
currX_crit_alarm Current critical high alarm.
|
||||||
From IIN_OC_FAULT or IOUT_OC_FAULT status.
|
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_input Measured power. From READ_PIN or READ_POUT register.
|
||||||
powerX_cap Output power cap. From POUT_MAX 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.
|
From POUT_OP_FAULT status.
|
||||||
powerX_label "pin" or "poutY"
|
powerX_label "pin" or "poutY"
|
||||||
|
|
||||||
tempX_input Measured tempererature.
|
tempX_input Measured temperature.
|
||||||
From READ_TEMPERATURE_X register.
|
From READ_TEMPERATURE_X register.
|
||||||
tempX_min Mimimum tempererature. From UT_WARN_LIMIT register.
|
tempX_min Mimimum temperature. From UT_WARN_LIMIT register.
|
||||||
tempX_max Maximum tempererature. From OT_WARN_LIMIT register.
|
tempX_max Maximum temperature. From OT_WARN_LIMIT register.
|
||||||
tempX_lcrit Critical low tempererature.
|
tempX_lcrit Critical low temperature.
|
||||||
From UT_FAULT_LIMIT register.
|
From UT_FAULT_LIMIT register.
|
||||||
tempX_crit Critical high tempererature.
|
tempX_crit Critical high temperature.
|
||||||
From OT_FAULT_LIMIT register.
|
From OT_FAULT_LIMIT register.
|
||||||
tempX_min_alarm Chip temperature low alarm. Set by comparing
|
tempX_min_alarm Chip temperature low alarm. Set by comparing
|
||||||
READ_TEMPERATURE_X with UT_WARN_LIMIT if
|
READ_TEMPERATURE_X with UT_WARN_LIMIT if
|
||||||
|
|||||||
@@ -150,8 +150,8 @@ in8_crit_alarm Channel F critical alarm
|
|||||||
in9_crit_alarm AIN1 critical alarm
|
in9_crit_alarm AIN1 critical alarm
|
||||||
in10_crit_alarm AIN2 critical alarm
|
in10_crit_alarm AIN2 critical alarm
|
||||||
|
|
||||||
temp1_input Chip tempererature
|
temp1_input Chip temperature
|
||||||
temp1_min Mimimum chip tempererature
|
temp1_min Mimimum chip temperature
|
||||||
temp1_max Maximum chip tempererature
|
temp1_max Maximum chip temperature
|
||||||
temp1_crit Critical chip tempererature
|
temp1_crit Critical chip temperature
|
||||||
temp1_crit_alarm Temperature critical alarm
|
temp1_crit_alarm Temperature critical alarm
|
||||||
|
|||||||
@@ -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.
|
||||||
@@ -552,6 +552,16 @@ also have
|
|||||||
within the array where IO will be blocked. This is currently
|
within the array where IO will be blocked. This is currently
|
||||||
only supported for raid4/5/6.
|
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
|
Each active md device may also have attributes specific to the
|
||||||
personality module that manages it.
|
personality module that manages it.
|
||||||
|
|||||||
@@ -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
|
The result is forwarded to the ADC capture FIFO (thus to the standard capture
|
||||||
PCM device).
|
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
|
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.
|
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.
|
The result samples are forwarded to the front DAC PCM slots of the AC97 codec.
|
||||||
|
|
||||||
name='Music Capture Volume',index=0
|
name='Synth Capture Volume',index=0
|
||||||
name='Music Capture Switch',index=0
|
name='Synth Capture Switch',index=0
|
||||||
|
|
||||||
These controls are used to attenuate samples for left and right MIDI FX-bus
|
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.
|
accumulator. ALSA uses accumulators 4 and 5 for left and right PCM.
|
||||||
|
|||||||
@@ -37,7 +37,7 @@ Generic scaling / cropping scheme
|
|||||||
-1'-
|
-1'-
|
||||||
|
|
||||||
In the above chart minuses and slashes represent "real" data amounts, points and
|
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.
|
mapped back onto the client's source plane.
|
||||||
|
|
||||||
Such a configuration can be produced by user requests:
|
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:
|
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
|
2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at
|
||||||
current sensor scales onto input window - this is user S_CROP:
|
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
|
4. Calculate sensor output window by applying combined scales to real input
|
||||||
window:
|
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.
|
5. Apply iterative sensor S_FMT for sensor output window.
|
||||||
|
|
||||||
|
|||||||
@@ -12,6 +12,7 @@ CONTENTS
|
|||||||
4. Application Programming Interface (API)
|
4. Application Programming Interface (API)
|
||||||
5. Example Execution Scenarios
|
5. Example Execution Scenarios
|
||||||
6. Guidelines
|
6. Guidelines
|
||||||
|
7. Debugging
|
||||||
|
|
||||||
|
|
||||||
1. Introduction
|
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
|
* Unless work items are expected to consume a huge amount of CPU
|
||||||
cycles, using a bound wq is usually beneficial due to the increased
|
cycles, using a bound wq is usually beneficial due to the increased
|
||||||
level of locality in wq operations and work item execution.
|
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.
|
||||||
|
|||||||
+18
-16
@@ -151,6 +151,7 @@ S: Maintained
|
|||||||
F: drivers/net/hamradio/6pack.c
|
F: drivers/net/hamradio/6pack.c
|
||||||
|
|
||||||
8169 10/100/1000 GIGABIT ETHERNET DRIVER
|
8169 10/100/1000 GIGABIT ETHERNET DRIVER
|
||||||
|
M: Realtek linux nic maintainers <nic_swsd@realtek.com>
|
||||||
M: Francois Romieu <romieu@fr.zoreil.com>
|
M: Francois Romieu <romieu@fr.zoreil.com>
|
||||||
L: netdev@vger.kernel.org
|
L: netdev@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
@@ -1031,12 +1032,13 @@ W: http://www.fluff.org/ben/linux/
|
|||||||
S: Maintained
|
S: Maintained
|
||||||
F: arch/arm/mach-s3c64xx/
|
F: arch/arm/mach-s3c64xx/
|
||||||
|
|
||||||
ARM/S5P ARM ARCHITECTURES
|
ARM/S5P EXYNOS ARM ARCHITECTURES
|
||||||
M: Kukjin Kim <kgene.kim@samsung.com>
|
M: Kukjin Kim <kgene.kim@samsung.com>
|
||||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||||
L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
|
L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: arch/arm/mach-s5p*/
|
F: arch/arm/mach-s5p*/
|
||||||
|
F: arch/arm/mach-exynos*/
|
||||||
|
|
||||||
ARM/SAMSUNG MOBILE MACHINE SUPPORT
|
ARM/SAMSUNG MOBILE MACHINE SUPPORT
|
||||||
M: Kyungmin Park <kyungmin.park@samsung.com>
|
M: Kyungmin Park <kyungmin.park@samsung.com>
|
||||||
@@ -2807,7 +2809,7 @@ GPIO SUBSYSTEM
|
|||||||
M: Grant Likely <grant.likely@secretlab.ca>
|
M: Grant Likely <grant.likely@secretlab.ca>
|
||||||
S: Maintained
|
S: Maintained
|
||||||
T: git git://git.secretlab.ca/git/linux-2.6.git
|
T: git git://git.secretlab.ca/git/linux-2.6.git
|
||||||
F: Documentation/gpio/gpio.txt
|
F: Documentation/gpio.txt
|
||||||
F: drivers/gpio/
|
F: drivers/gpio/
|
||||||
F: include/linux/gpio*
|
F: include/linux/gpio*
|
||||||
|
|
||||||
@@ -5395,7 +5397,7 @@ F: drivers/media/video/*7146*
|
|||||||
F: include/media/*7146*
|
F: include/media/*7146*
|
||||||
|
|
||||||
SAMSUNG AUDIO (ASoC) DRIVERS
|
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)
|
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||||
S: Supported
|
S: Supported
|
||||||
F: sound/soc/samsung
|
F: sound/soc/samsung
|
||||||
@@ -6554,7 +6556,7 @@ S: Maintained
|
|||||||
F: drivers/usb/host/uhci*
|
F: drivers/usb/host/uhci*
|
||||||
|
|
||||||
USB "USBNET" DRIVER FRAMEWORK
|
USB "USBNET" DRIVER FRAMEWORK
|
||||||
M: David Brownell <dbrownell@users.sourceforge.net>
|
M: Oliver Neukum <oneukum@suse.de>
|
||||||
L: netdev@vger.kernel.org
|
L: netdev@vger.kernel.org
|
||||||
W: http://www.linux-usb.org/usbnet
|
W: http://www.linux-usb.org/usbnet
|
||||||
S: Maintained
|
S: Maintained
|
||||||
@@ -6920,6 +6922,18 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86.
|
|||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/platform/x86
|
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
|
XEN NETWORK BACKEND DRIVER
|
||||||
M: Ian Campbell <ian.campbell@citrix.com>
|
M: Ian Campbell <ian.campbell@citrix.com>
|
||||||
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
|
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
|
||||||
@@ -6941,18 +6955,6 @@ S: Supported
|
|||||||
F: arch/x86/xen/*swiotlb*
|
F: arch/x86/xen/*swiotlb*
|
||||||
F: drivers/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
|
XFS FILESYSTEM
|
||||||
P: Silicon Graphics Inc
|
P: Silicon Graphics Inc
|
||||||
M: Alex Elder <aelder@sgi.com>
|
M: Alex Elder <aelder@sgi.com>
|
||||||
|
|||||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user