提交 7547a3e8 编写于 作者: D Dmitry Torokhov

Merge commit 'linus' into next

要显示的变更太多。

To preserve performance only 1000 of 1000+ files are displayed.
What: /sys/bus/pci/drivers/qla2xxx/.../devices/*
Date: September 2009
Contact: QLogic Linux Driver <linux-driver@qlogic.com>
Description: qla2xxx-udev.sh currently looks for uevent CHANGE events to
signal a firmware-dump has been generated by the driver and is
ready for retrieval.
Users: qla2xxx-udev.sh. Proposed changes should be mailed to
linux-driver@qlogic.com
......@@ -8,7 +8,7 @@ Description:
1 - major number
2 - minor mumber
3 - device name
4 - reads completed succesfully
4 - reads completed successfully
5 - reads merged
6 - sectors read
7 - time spent reading (ms)
......
......@@ -4,7 +4,7 @@ Contact: Jerome Marchand <jmarchan@redhat.com>
Description:
The /sys/block/<disk>/stat files displays the I/O
statistics of disk <disk>. They contain 11 fields:
1 - reads completed succesfully
1 - reads completed successfully
2 - reads merged
3 - sectors read
4 - time spent reading (ms)
......
......@@ -144,3 +144,16 @@ Description:
Write a 1 to force the device to disconnect
(equivalent to unplugging a wired USB device).
What: /sys/bus/usb/drivers/.../remove_id
Date: November 2009
Contact: CHENG Renquan <rqcheng@smu.edu.sg>
Description:
Writing a device ID to this file will remove an ID
that was dynamically added via the new_id sysfs entry.
The format for the device ID is:
idVendor idProduct. After successfully
removing an ID, the driver will no longer support the
device. This is useful to ensure auto probing won't
match the driver to the device. For example:
# echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id
......@@ -23,3 +23,16 @@ Description:
Since this relates to security (specifically, the
lifetime of PTKs and GTKs) it should not be changed
from the default.
What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_phy_rate
Date: August 2009
KernelVersion: 2.6.32
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The maximum PHY rate to use for all connected devices.
This is only of limited use for testing and
development as the hardware's automatic rate
adaptation is better then this simple control.
Refer to [ECMA-368] section 10.3.1.1 for the value to
use.
......@@ -62,6 +62,21 @@ Description: CPU topology files that describe kernel limits related to
See Documentation/cputopology.txt for more information.
What: /sys/devices/system/cpu/probe
/sys/devices/system/cpu/release
Date: November 2009
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Dynamic addition and removal of CPU's. This is not hotplug
removal, this is meant complete removal/addition of the CPU
from the system.
probe: writes to this file will dynamically add a CPU to the
system. Information written to the file to add CPU's is
architecture specific.
release: writes to this file dynamically remove a CPU from
the system. Information writtento the file to remove CPU's
is architecture specific.
What: /sys/devices/system/cpu/cpu#/node
Date: October 2009
......@@ -136,6 +151,24 @@ Description: Discover cpuidle policy and mechanism
See files in Documentation/cpuidle/ for more information.
What: /sys/devices/system/cpu/cpu#/cpufreq/*
Date: pre-git history
Contact: cpufreq@vger.kernel.org
Description: Discover and change clock speed of CPUs
Clock scaling allows you to change the clock speed of the
CPUs on the fly. This is a nice method to save battery
power, because the lower the clock speed, the less power
the CPU consumes.
There are many knobs to tweak in this directory.
See files in Documentation/cpu-freq/ for more information.
In particular, read Documentation/cpu-freq/user-guide.txt
to learn how to control the knobs.
What: /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X
Date: August 2008
KernelVersion: 2.6.27
......
......@@ -45,8 +45,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The alloc_fastpath file is read-only and specifies how many
objects have been allocated using the fast path.
The alloc_fastpath file shows how many objects have been
allocated using the fast path. It can be written to clear the
current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/alloc_from_partial
......@@ -55,9 +56,10 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The alloc_from_partial file is read-only and specifies how
many times a cpu slab has been full and it has been refilled
by using a slab from the list of partially used slabs.
The alloc_from_partial file shows how many times a cpu slab has
been full and it has been refilled by using a slab from the list
of partially used slabs. It can be written to clear the current
count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/alloc_refill
......@@ -66,9 +68,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The alloc_refill file is read-only and specifies how many
times the per-cpu freelist was empty but there were objects
available as the result of remote cpu frees.
The alloc_refill file shows how many times the per-cpu freelist
was empty but there were objects available as the result of
remote cpu frees. It can be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/alloc_slab
......@@ -77,8 +79,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The alloc_slab file is read-only and specifies how many times
a new slab had to be allocated from the page allocator.
The alloc_slab file is shows how many times a new slab had to
be allocated from the page allocator. It can be written to
clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/alloc_slowpath
......@@ -87,9 +90,10 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The alloc_slowpath file is read-only and specifies how many
objects have been allocated using the slow path because of a
refill or allocation from a partial or new slab.
The alloc_slowpath file shows how many objects have been
allocated using the slow path because of a refill or
allocation from a partial or new slab. It can be written to
clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/cache_dma
......@@ -117,10 +121,11 @@ KernelVersion: 2.6.31
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file cpuslab_flush is read-only and specifies how many
times a cache's cpu slabs have been flushed as the result of
destroying or shrinking a cache, a cpu going offline, or as
the result of forcing an allocation from a certain node.
The file cpuslab_flush shows how many times a cache's cpu slabs
have been flushed as the result of destroying or shrinking a
cache, a cpu going offline, or as the result of forcing an
allocation from a certain node. It can be written to clear the
current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/ctor
......@@ -139,8 +144,8 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file deactivate_empty is read-only and specifies how many
times an empty cpu slab was deactivated.
The deactivate_empty file shows how many times an empty cpu slab
was deactivated. It can be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/deactivate_full
......@@ -149,8 +154,8 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file deactivate_full is read-only and specifies how many
times a full cpu slab was deactivated.
The deactivate_full file shows how many times a full cpu slab
was deactivated. It can be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/deactivate_remote_frees
......@@ -159,9 +164,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file deactivate_remote_frees is read-only and specifies how
many times a cpu slab has been deactivated and contained free
objects that were freed remotely.
The deactivate_remote_frees file shows how many times a cpu slab
has been deactivated and contained free objects that were freed
remotely. It can be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/deactivate_to_head
......@@ -170,9 +175,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file deactivate_to_head is read-only and specifies how
many times a partial cpu slab was deactivated and added to the
head of its node's partial list.
The deactivate_to_head file shows how many times a partial cpu
slab was deactivated and added to the head of its node's partial
list. It can be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/deactivate_to_tail
......@@ -181,9 +186,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file deactivate_to_tail is read-only and specifies how
many times a partial cpu slab was deactivated and added to the
tail of its node's partial list.
The deactivate_to_tail file shows how many times a partial cpu
slab was deactivated and added to the tail of its node's partial
list. It can be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/destroy_by_rcu
......@@ -201,9 +206,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file free_add_partial is read-only and specifies how many
times an object has been freed in a full slab so that it had to
added to its node's partial list.
The free_add_partial file shows how many times an object has
been freed in a full slab so that it had to added to its node's
partial list. It can be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/free_calls
......@@ -222,9 +227,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The free_fastpath file is read-only and specifies how many
objects have been freed using the fast path because it was an
object from the cpu slab.
The free_fastpath file shows how many objects have been freed
using the fast path because it was an object from the cpu slab.
It can be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/free_frozen
......@@ -233,9 +238,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The free_frozen file is read-only and specifies how many
objects have been freed to a frozen slab (i.e. a remote cpu
slab).
The free_frozen file shows how many objects have been freed to
a frozen slab (i.e. a remote cpu slab). It can be written to
clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/free_remove_partial
......@@ -244,9 +249,10 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file free_remove_partial is read-only and specifies how
many times an object has been freed to a now-empty slab so
that it had to be removed from its node's partial list.
The free_remove_partial file shows how many times an object has
been freed to a now-empty slab so that it had to be removed from
its node's partial list. It can be written to clear the current
count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/free_slab
......@@ -255,8 +261,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The free_slab file is read-only and specifies how many times an
empty slab has been freed back to the page allocator.
The free_slab file shows how many times an empty slab has been
freed back to the page allocator. It can be written to clear
the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/free_slowpath
......@@ -265,9 +272,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The free_slowpath file is read-only and specifies how many
objects have been freed using the slow path (i.e. to a full or
partial slab).
The free_slowpath file shows how many objects have been freed
using the slow path (i.e. to a full or partial slab). It can
be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/hwcache_align
......@@ -346,10 +353,10 @@ KernelVersion: 2.6.26
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file order_fallback is read-only and specifies how many
times an allocation of a new slab has not been possible at the
cache's order and instead fallen back to its minimum possible
order.
The order_fallback file shows how many times an allocation of a
new slab has not been possible at the cache's order and instead
fallen back to its minimum possible order. It can be written to
clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/partial
......
......@@ -214,7 +214,7 @@ most specific mask.
Here is pseudo-code showing how this might be done:
#define PLAYBACK_ADDRESS_BITS DMA_BIT_MASK(32)
#define RECORD_ADDRESS_BITS 0x00ffffff
#define RECORD_ADDRESS_BITS DMA_BIT_MASK(24)
struct my_sound_card *card;
struct pci_dev *pdev;
......@@ -224,14 +224,14 @@ Here is pseudo-code showing how this might be done:
card->playback_enabled = 1;
} else {
card->playback_enabled = 0;
printk(KERN_WARN "%s: Playback disabled due to DMA limitations.\n",
printk(KERN_WARNING "%s: Playback disabled due to DMA limitations.\n",
card->name);
}
if (!pci_set_dma_mask(pdev, RECORD_ADDRESS_BITS)) {
card->record_enabled = 1;
} else {
card->record_enabled = 0;
printk(KERN_WARN "%s: Record disabled due to DMA limitations.\n",
printk(KERN_WARNING "%s: Record disabled due to DMA limitations.\n",
card->name);
}
......
......@@ -29,6 +29,14 @@
<revhistory>
<!-- Put document revisions here, newest first. -->
<revision>
<revnumber>2.0.2</revnumber>
<date>2009-10-25</date>
<authorinitials>mcc</authorinitials>
<revremark>
documents FE_SET_FRONTEND_TUNE_MODE and FE_DISHETWORK_SEND_LEGACY_CMD ioctls.
</revremark>
</revision>
<revision>
<revnumber>2.0.1</revnumber>
<date>2009-09-16</date>
......@@ -85,3 +93,8 @@ Added ISDB-T test originally written by Patrick Boettcher
&sub-examples;
</chapter>
<!-- END OF CHAPTERS -->
<appendix id="frontend_h">
<title>DVB Frontend Header File</title>
&sub-frontend-h;
</appendix>
<section id="FE_GET_PROPERTY">
<title>FE_GET_PROPERTY/FE_SET_PROPERTY</title>
<section id="isdbt">
<title>ISDB-T frontend</title>
<para>This section describes shortly what are the possible parameters in the Linux
DVB-API called "S2API" and now DVB API 5 in order to tune an ISDB-T/ISDB-Tsb
demodulator:</para>
<para>This ISDB-T/ISDB-Tsb API extension should reflect all information
needed to tune any ISDB-T/ISDB-Tsb hardware. Of course it is possible
that some very sophisticated devices won't need certain parameters to
tune.</para>
<para>The information given here should help application writers to know how
to handle ISDB-T and ISDB-Tsb hardware using the Linux DVB-API.</para>
<para>The details given here about ISDB-T and ISDB-Tsb are just enough to
basically show the dependencies between the needed parameter values,
but surely some information is left out. For more detailed information
see the following documents:</para>
<para>ARIB STD-B31 - "Transmission System for Digital Terrestrial
Television Broadcasting" and</para>
<para>ARIB TR-B14 - "Operational Guidelines for Digital Terrestrial
Television Broadcasting".</para>
<para>In order to read this document one has to have some knowledge the
channel structure in ISDB-T and ISDB-Tsb. I.e. it has to be known to
the reader that an ISDB-T channel consists of 13 segments, that it can
have up to 3 layer sharing those segments, and things like that.</para>
<para>Parameters used by ISDB-T and ISDB-Tsb.</para>
<section id="isdbt-parms">
<title>Parameters that are common with DVB-T and ATSC</title>
<section id="isdbt-freq">
<title><constant>DTV_FREQUENCY</constant></title>
<para>Central frequency of the channel.</para>
<para>For ISDB-T the channels are usally transmitted with an offset of 143kHz. E.g. a
valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
the channel which is 6MHz.</para>
<para>As in ISDB-Tsb the channel consists of only one or three segments the
frequency step is 429kHz, 3*429 respectively. As for ISDB-T the
central frequency of the channel is expected.</para>
</section>
<section id="isdbt-bw">
<title><constant>DTV_BANDWIDTH_HZ</constant> (optional)</title>
<para>Possible values:</para>
<para>For ISDB-T it should be always 6000000Hz (6MHz)</para>
<para>For ISDB-Tsb it can vary depending on the number of connected segments</para>
<para>Note: Hardware specific values might be given here, but standard
applications should not bother to set a value to this field as
standard demods are ignoring it anyway.</para>
<para>Bandwidth in ISDB-T is fixed (6MHz) or can be easily derived from
other parameters (DTV_ISDBT_SB_SEGMENT_IDX,
DTV_ISDBT_SB_SEGMENT_COUNT).</para>
</section>
<section id="isdbt-delivery-sys">
<title><constant>DTV_DELIVERY_SYSTEM</constant></title>
<para>Possible values: <constant>SYS_ISDBT</constant></para>
</section>
<section id="isdbt-tx-mode">
<title><constant>DTV_TRANSMISSION_MODE</constant></title>
<para>ISDB-T supports three carrier/symbol-size: 8K, 4K, 2K. It is called
'mode' in the standard: Mode 1 is 2K, mode 2 is 4K, mode 3 is 8K</para>
<para>Possible values: <constant>TRANSMISSION_MODE_2K</constant>, <constant>TRANSMISSION_MODE_8K</constant>,
<constant>TRANSMISSION_MODE_AUTO</constant>, <constant>TRANSMISSION_MODE_4K</constant></para>
<para>If <constant>DTV_TRANSMISSION_MODE</constant> is set the <constant>TRANSMISSION_MODE_AUTO</constant> the
hardware will try to find the correct FFT-size (if capable) and will
use TMCC to fill in the missing parameters.</para>
<para><constant>TRANSMISSION_MODE_4K</constant> is added at the same time as the other new parameters.</para>
</section>
<section id="isdbt-guard-interval">
<title><constant>DTV_GUARD_INTERVAL</constant></title>
<para>Possible values: <constant>GUARD_INTERVAL_1_32</constant>, <constant>GUARD_INTERVAL_1_16</constant>, <constant>GUARD_INTERVAL_1_8</constant>,
<constant>GUARD_INTERVAL_1_4</constant>, <constant>GUARD_INTERVAL_AUTO</constant></para>
<para>If <constant>DTV_GUARD_INTERVAL</constant> is set the <constant>GUARD_INTERVAL_AUTO</constant> the hardware will
try to find the correct guard interval (if capable) and will use TMCC to fill
in the missing parameters.</para>
</section>
</section>
<section id="isdbt-new-parms">
<title>ISDB-T only parameters</title>
<section id="isdbt-part-rec">
<title><constant>DTV_ISDBT_PARTIAL_RECEPTION</constant></title>
<para><constant>If DTV_ISDBT_SOUND_BROADCASTING</constant> is '0' this bit-field represents whether
the channel is in partial reception mode or not.</para>
<para>If '1' <constant>DTV_ISDBT_LAYERA_*</constant> values are assigned to the center segment and
<constant>DTV_ISDBT_LAYERA_SEGMENT_COUNT</constant> has to be '1'.</para>
<para>If in addition <constant>DTV_ISDBT_SOUND_BROADCASTING</constant> is '1'
<constant>DTV_ISDBT_PARTIAL_RECEPTION</constant> represents whether this ISDB-Tsb channel
is consisting of one segment and layer or three segments and two layers.</para>
<para>Possible values: 0, 1, -1 (AUTO)</para>
</section>
<section id="isdbt-sound-bcast">
<title><constant>DTV_ISDBT_SOUND_BROADCASTING</constant></title>
<para>This field represents whether the other DTV_ISDBT_*-parameters are
referring to an ISDB-T and an ISDB-Tsb channel. (See also
<constant>DTV_ISDBT_PARTIAL_RECEPTION</constant>).</para>
<para>Possible values: 0, 1, -1 (AUTO)</para>
</section>
<section id="isdbt-sb-ch-id">
<title><constant>DTV_ISDBT_SB_SUBCHANNEL_ID</constant></title>
<para>This field only applies if <constant>DTV_ISDBT_SOUND_BROADCASTING</constant> is '1'.</para>
<para>(Note of the author: This might not be the correct description of the
<constant>SUBCHANNEL-ID</constant> in all details, but it is my understanding of the technical
background needed to program a device)</para>
<para>An ISDB-Tsb channel (1 or 3 segments) can be broadcasted alone or in a
set of connected ISDB-Tsb channels. In this set of channels every
channel can be received independently. The number of connected
ISDB-Tsb segment can vary, e.g. depending on the frequency spectrum
bandwidth available.</para>
<para>Example: Assume 8 ISDB-Tsb connected segments are broadcasted. The
broadcaster has several possibilities to put those channels in the
air: Assuming a normal 13-segment ISDB-T spectrum he can align the 8
segments from position 1-8 to 5-13 or anything in between.</para>
<para>The underlying layer of segments are subchannels: each segment is
consisting of several subchannels with a predefined IDs. A sub-channel
is used to help the demodulator to synchronize on the channel.</para>
<para>An ISDB-T channel is always centered over all sub-channels. As for
the example above, in ISDB-Tsb it is no longer as simple as that.</para>
<para><constant>The DTV_ISDBT_SB_SUBCHANNEL_ID</constant> parameter is used to give the
sub-channel ID of the segment to be demodulated.</para>
<para>Possible values: 0 .. 41, -1 (AUTO)</para>
</section>
<section id="isdbt-sb-seg-idx">
<title><constant>DTV_ISDBT_SB_SEGMENT_IDX</constant></title>
<para>This field only applies if <constant>DTV_ISDBT_SOUND_BROADCASTING</constant> is '1'.</para>
<para><constant>DTV_ISDBT_SB_SEGMENT_IDX</constant> gives the index of the segment to be
demodulated for an ISDB-Tsb channel where several of them are
transmitted in the connected manner.</para>
<para>Possible values: 0 .. <constant>DTV_ISDBT_SB_SEGMENT_COUNT</constant> - 1</para>
<para>Note: This value cannot be determined by an automatic channel search.</para>
</section>
<section id="isdbt-sb-seg-cnt">
<title><constant>DTV_ISDBT_SB_SEGMENT_COUNT</constant></title>
<para>This field only applies if <constant>DTV_ISDBT_SOUND_BROADCASTING</constant> is '1'.</para>
<para><constant>DTV_ISDBT_SB_SEGMENT_COUNT</constant> gives the total count of connected ISDB-Tsb
channels.</para>
<para>Possible values: 1 .. 13</para>
<para>Note: This value cannot be determined by an automatic channel search.</para>
</section>
<section id="isdb-hierq-layers">
<title>Hierarchical layers</title>
<para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in
ISDB-T hierarchical layers can be decoded simultaneously. For that
reason a ISDB-T demodulator has 3 viterbi and 3 reed-solomon-decoders.</para>
<para>ISDB-T has 3 hierarchical layers which each can use a part of the
available segments. The total number of segments over all layers has
to 13 in ISDB-T.</para>
<section id="isdbt-layer-ena">
<title><constant>DTV_ISDBT_LAYER_ENABLED</constant></title>
<para>Hierarchical reception in ISDB-T is achieved by enabling or disabling
layers in the decoding process. Setting all bits of
<constant>DTV_ISDBT_LAYER_ENABLED</constant> to '1' forces all layers (if applicable) to be
demodulated. This is the default.</para>
<para>If the channel is in the partial reception mode
(<constant>DTV_ISDBT_PARTIAL_RECEPTION</constant> = 1) the central segment can be decoded
independently of the other 12 segments. In that mode layer A has to
have a <constant>SEGMENT_COUNT</constant> of 1.</para>
<para>In ISDB-Tsb only layer A is used, it can be 1 or 3 in ISDB-Tsb
according to <constant>DTV_ISDBT_PARTIAL_RECEPTION</constant>. <constant>SEGMENT_COUNT</constant> must be filled
accordingly.</para>
<para>Possible values: 0x1, 0x2, 0x4 (|-able)</para>
<para><constant>DTV_ISDBT_LAYER_ENABLED[0:0]</constant> - layer A</para>
<para><constant>DTV_ISDBT_LAYER_ENABLED[1:1]</constant> - layer B</para>
<para><constant>DTV_ISDBT_LAYER_ENABLED[2:2]</constant> - layer C</para>
<para><constant>DTV_ISDBT_LAYER_ENABLED[31:3]</constant> unused</para>
</section>
<section id="isdbt-layer-fec">
<title><constant>DTV_ISDBT_LAYER*_FEC</constant></title>
<para>Possible values: <constant>FEC_AUTO</constant>, <constant>FEC_1_2</constant>, <constant>FEC_2_3</constant>, <constant>FEC_3_4</constant>, <constant>FEC_5_6</constant>, <constant>FEC_7_8</constant></para>
</section>
<section id="isdbt-layer-mod">
<title><constant>DTV_ISDBT_LAYER*_MODULATION</constant></title>
<para>Possible values: <constant>QAM_AUTO</constant>, QP<constant>SK, QAM_16</constant>, <constant>QAM_64</constant>, <constant>DQPSK</constant></para>
<para>Note: If layer C is <constant>DQPSK</constant> layer B has to be <constant>DQPSK</constant>. If layer B is <constant>DQPSK</constant>
and <constant>DTV_ISDBT_PARTIAL_RECEPTION</constant>=0 layer has to be <constant>DQPSK</constant>.</para>
</section>
<section id="isdbt-layer-seg-cnt">
<title><constant>DTV_ISDBT_LAYER*_SEGMENT_COUNT</constant></title>
<para>Possible values: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, -1 (AUTO)</para>
<para>Note: Truth table for <constant>DTV_ISDBT_SOUND_BROADCASTING</constant> and
<constant>DTV_ISDBT_PARTIAL_RECEPTION</constant> and <constant>LAYER</constant>*_SEGMENT_COUNT</para>
<informaltable id="isdbt-layer_seg-cnt-table">
<tgroup cols="6">
<tbody>
<row>
<entry>PR</entry>
<entry>SB</entry>
<entry>Layer A width</entry>
<entry>Layer B width</entry>
<entry>Layer C width</entry>
<entry>total width</entry>
</row>
<row>
<entry>0</entry>
<entry>0</entry>
<entry>1 .. 13</entry>
<entry>1 .. 13</entry>
<entry>1 .. 13</entry>
<entry>13</entry>
</row>
<row>
<entry>1</entry>
<entry>0</entry>
<entry>1</entry>
<entry>1 .. 13</entry>
<entry>1 .. 13</entry>
<entry>13</entry>
</row>
<row>
<entry>0</entry>
<entry>1</entry>
<entry>1</entry>
<entry>0</entry>
<entry>0</entry>
<entry>1</entry>
</row>
<row>
<entry>1</entry>
<entry>1</entry>
<entry>1</entry>
<entry>2</entry>
<entry>0</entry>
<entry>13</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</section>
<section id="isdbt_layer_t_interl">
<title><constant>DTV_ISDBT_LAYER*_TIME_INTERLEAVING</constant></title>
<para>Possible values: 0, 1, 2, 3, -1 (AUTO)</para>
<para>Note: The real inter-leaver depth-names depend on the mode (fft-size); the values
here are referring to what can be found in the TMCC-structure -
independent of the mode.</para>
</section>
</section>
</section>
</section>
</section>
<programlisting>
/*
* frontend.h
*
* Copyright (C) 2000 Marcus Metzler &lt;marcus@convergence.de&gt;
* Ralph Metzler &lt;ralph@convergence.de&gt;
* Holger Waechtler &lt;holger@convergence.de&gt;
* Andre Draszik &lt;ad@convergence.de&gt;
* for convergence integrated media GmbH
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public License
* as published by the Free Software Foundation; either version 2.1
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
*/
#ifndef _DVBFRONTEND_H_
#define _DVBFRONTEND_H_
#include &lt;linux/types.h&gt;
typedef enum fe_type {
FE_QPSK,
FE_QAM,
FE_OFDM,
FE_ATSC
} fe_type_t;
typedef enum fe_caps {
FE_IS_STUPID = 0,
FE_CAN_INVERSION_AUTO = 0x1,
FE_CAN_FEC_1_2 = 0x2,
FE_CAN_FEC_2_3 = 0x4,
FE_CAN_FEC_3_4 = 0x8,
FE_CAN_FEC_4_5 = 0x10,
FE_CAN_FEC_5_6 = 0x20,
FE_CAN_FEC_6_7 = 0x40,
FE_CAN_FEC_7_8 = 0x80,
FE_CAN_FEC_8_9 = 0x100,
FE_CAN_FEC_AUTO = 0x200,
FE_CAN_QPSK = 0x400,
FE_CAN_QAM_16 = 0x800,
FE_CAN_QAM_32 = 0x1000,
FE_CAN_QAM_64 = 0x2000,
FE_CAN_QAM_128 = 0x4000,
FE_CAN_QAM_256 = 0x8000,
FE_CAN_QAM_AUTO = 0x10000,
FE_CAN_TRANSMISSION_MODE_AUTO = 0x20000,
FE_CAN_BANDWIDTH_AUTO = 0x40000,
FE_CAN_GUARD_INTERVAL_AUTO = 0x80000,
FE_CAN_HIERARCHY_AUTO = 0x100000,
FE_CAN_8VSB = 0x200000,
FE_CAN_16VSB = 0x400000,
FE_HAS_EXTENDED_CAPS = 0x800000, /* We need more bitspace for newer APIs, indicate this. */
FE_CAN_2G_MODULATION = 0x10000000, /* frontend supports "2nd generation modulation" (DVB-S2) */
FE_NEEDS_BENDING = 0x20000000, /* not supported anymore, don't use (frontend requires frequency bending) */
FE_CAN_RECOVER = 0x40000000, /* frontend can recover from a cable unplug automatically */
FE_CAN_MUTE_TS = 0x80000000 /* frontend can stop spurious TS data output */
} fe_caps_t;
struct dvb_frontend_info {
char name[128];
fe_type_t type;
__u32 frequency_min;
__u32 frequency_max;
__u32 frequency_stepsize;
__u32 frequency_tolerance;
__u32 symbol_rate_min;
__u32 symbol_rate_max;
__u32 symbol_rate_tolerance; /* ppm */
__u32 notifier_delay; /* DEPRECATED */
fe_caps_t caps;
};
/**
* Check out the DiSEqC bus spec available on http://www.eutelsat.org/ for
* the meaning of this struct...
*/
struct dvb_diseqc_master_cmd {
__u8 msg [6]; /* { framing, address, command, data [3] } */
__u8 msg_len; /* valid values are 3...6 */
};
struct dvb_diseqc_slave_reply {
__u8 msg [4]; /* { framing, data [3] } */
__u8 msg_len; /* valid values are 0...4, 0 means no msg */
int timeout; /* return from ioctl after timeout ms with */
}; /* errorcode when no message was received */
typedef enum fe_sec_voltage {
SEC_VOLTAGE_13,
SEC_VOLTAGE_18,
SEC_VOLTAGE_OFF
} fe_sec_voltage_t;
typedef enum fe_sec_tone_mode {
SEC_TONE_ON,
SEC_TONE_OFF
} fe_sec_tone_mode_t;
typedef enum fe_sec_mini_cmd {
SEC_MINI_A,
SEC_MINI_B
} fe_sec_mini_cmd_t;
typedef enum fe_status {
FE_HAS_SIGNAL = 0x01, /* found something above the noise level */
FE_HAS_CARRIER = 0x02, /* found a DVB signal */
FE_HAS_VITERBI = 0x04, /* FEC is stable */
FE_HAS_SYNC = 0x08, /* found sync bytes */
FE_HAS_LOCK = 0x10, /* everything's working... */
FE_TIMEDOUT = 0x20, /* no lock within the last ~2 seconds */
FE_REINIT = 0x40 /* frontend was reinitialized, */
} fe_status_t; /* application is recommended to reset */
/* DiSEqC, tone and parameters */
typedef enum fe_spectral_inversion {
INVERSION_OFF,
INVERSION_ON,
INVERSION_AUTO
} fe_spectral_inversion_t;
typedef enum fe_code_rate {
FEC_NONE = 0,
FEC_1_2,
FEC_2_3,
FEC_3_4,
FEC_4_5,
FEC_5_6,
FEC_6_7,
FEC_7_8,
FEC_8_9,
FEC_AUTO,
FEC_3_5,
FEC_9_10,
} fe_code_rate_t;
typedef enum fe_modulation {
QPSK,
QAM_16,
QAM_32,
QAM_64,
QAM_128,
QAM_256,
QAM_AUTO,
VSB_8,
VSB_16,
PSK_8,
APSK_16,
APSK_32,
DQPSK,
} fe_modulation_t;
typedef enum fe_transmit_mode {
TRANSMISSION_MODE_2K,
TRANSMISSION_MODE_8K,
TRANSMISSION_MODE_AUTO,
TRANSMISSION_MODE_4K
} fe_transmit_mode_t;
typedef enum fe_bandwidth {
BANDWIDTH_8_MHZ,
BANDWIDTH_7_MHZ,
BANDWIDTH_6_MHZ,
BANDWIDTH_AUTO
} fe_bandwidth_t;
typedef enum fe_guard_interval {
GUARD_INTERVAL_1_32,
GUARD_INTERVAL_1_16,
GUARD_INTERVAL_1_8,
GUARD_INTERVAL_1_4,
GUARD_INTERVAL_AUTO
} fe_guard_interval_t;
typedef enum fe_hierarchy {
HIERARCHY_NONE,
HIERARCHY_1,
HIERARCHY_2,
HIERARCHY_4,
HIERARCHY_AUTO
} fe_hierarchy_t;
struct dvb_qpsk_parameters {
__u32 symbol_rate; /* symbol rate in Symbols per second */
fe_code_rate_t fec_inner; /* forward error correction (see above) */
};
struct dvb_qam_parameters {
__u32 symbol_rate; /* symbol rate in Symbols per second */
fe_code_rate_t fec_inner; /* forward error correction (see above) */
fe_modulation_t modulation; /* modulation type (see above) */
};
struct dvb_vsb_parameters {
fe_modulation_t modulation; /* modulation type (see above) */
};
struct dvb_ofdm_parameters {
fe_bandwidth_t bandwidth;
fe_code_rate_t code_rate_HP; /* high priority stream code rate */
fe_code_rate_t code_rate_LP; /* low priority stream code rate */
fe_modulation_t constellation; /* modulation type (see above) */
fe_transmit_mode_t transmission_mode;
fe_guard_interval_t guard_interval;
fe_hierarchy_t hierarchy_information;
};
struct dvb_frontend_parameters {
__u32 frequency; /* (absolute) frequency in Hz for QAM/OFDM/ATSC */
/* intermediate frequency in kHz for QPSK */
fe_spectral_inversion_t inversion;
union {
struct dvb_qpsk_parameters qpsk;
struct dvb_qam_parameters qam;
struct dvb_ofdm_parameters ofdm;
struct dvb_vsb_parameters vsb;
} u;
};
struct dvb_frontend_event {
fe_status_t status;
struct dvb_frontend_parameters parameters;
};
/* S2API Commands */
#define DTV_UNDEFINED 0
#define DTV_TUNE 1
#define DTV_CLEAR 2
#define DTV_FREQUENCY 3
#define DTV_MODULATION 4
#define DTV_BANDWIDTH_HZ 5
#define DTV_INVERSION 6
#define DTV_DISEQC_MASTER 7
#define DTV_SYMBOL_RATE 8
#define DTV_INNER_FEC 9
#define DTV_VOLTAGE 10
#define DTV_TONE 11
#define DTV_PILOT 12
#define DTV_ROLLOFF 13
#define DTV_DISEQC_SLAVE_REPLY 14
/* Basic enumeration set for querying unlimited capabilities */
#define DTV_FE_CAPABILITY_COUNT 15
#define DTV_FE_CAPABILITY 16
#define DTV_DELIVERY_SYSTEM 17
/* ISDB-T and ISDB-Tsb */
#define DTV_ISDBT_PARTIAL_RECEPTION 18
#define DTV_ISDBT_SOUND_BROADCASTING 19
#define DTV_ISDBT_SB_SUBCHANNEL_ID 20
#define DTV_ISDBT_SB_SEGMENT_IDX 21
#define DTV_ISDBT_SB_SEGMENT_COUNT 22
#define DTV_ISDBT_LAYERA_FEC 23
#define DTV_ISDBT_LAYERA_MODULATION 24
#define DTV_ISDBT_LAYERA_SEGMENT_COUNT 25
#define DTV_ISDBT_LAYERA_TIME_INTERLEAVING 26
#define DTV_ISDBT_LAYERB_FEC 27
#define DTV_ISDBT_LAYERB_MODULATION 28
#define DTV_ISDBT_LAYERB_SEGMENT_COUNT 29
#define DTV_ISDBT_LAYERB_TIME_INTERLEAVING 30
#define DTV_ISDBT_LAYERC_FEC 31
#define DTV_ISDBT_LAYERC_MODULATION 32
#define DTV_ISDBT_LAYERC_SEGMENT_COUNT 33
#define DTV_ISDBT_LAYERC_TIME_INTERLEAVING 34
#define DTV_API_VERSION 35
#define DTV_CODE_RATE_HP 36
#define DTV_CODE_RATE_LP 37
#define DTV_GUARD_INTERVAL 38
#define DTV_TRANSMISSION_MODE 39
#define DTV_HIERARCHY 40
#define DTV_ISDBT_LAYER_ENABLED 41
#define DTV_ISDBS_TS_ID 42
#define DTV_MAX_COMMAND DTV_ISDBS_TS_ID
typedef enum fe_pilot {
PILOT_ON,
PILOT_OFF,
PILOT_AUTO,
} fe_pilot_t;
typedef enum fe_rolloff {
ROLLOFF_35, /* Implied value in DVB-S, default for DVB-S2 */
ROLLOFF_20,
ROLLOFF_25,
ROLLOFF_AUTO,
} fe_rolloff_t;
typedef enum fe_delivery_system {
SYS_UNDEFINED,
SYS_DVBC_ANNEX_AC,
SYS_DVBC_ANNEX_B,
SYS_DVBT,
SYS_DSS,
SYS_DVBS,
SYS_DVBS2,
SYS_DVBH,
SYS_ISDBT,
SYS_ISDBS,
SYS_ISDBC,
SYS_ATSC,
SYS_ATSCMH,
SYS_DMBTH,
SYS_CMMB,
SYS_DAB,
} fe_delivery_system_t;
struct dtv_cmds_h {
char *name; /* A display name for debugging purposes */
__u32 cmd; /* A unique ID */
/* Flags */
__u32 set:1; /* Either a set or get property */
__u32 buffer:1; /* Does this property use the buffer? */
__u32 reserved:30; /* Align */
};
struct dtv_property {
__u32 cmd;
__u32 reserved[3];
union {
__u32 data;
struct {
__u8 data[32];
__u32 len;
__u32 reserved1[3];
void *reserved2;
} buffer;
} u;
int result;
} __attribute__ ((packed));
/* num of properties cannot exceed DTV_IOCTL_MAX_MSGS per ioctl */
#define DTV_IOCTL_MAX_MSGS 64
struct dtv_properties {
__u32 num;
struct dtv_property *props;
};
#define <link linkend="FE_GET_PROPERTY">FE_SET_PROPERTY</link> _IOW('o', 82, struct dtv_properties)
#define <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link> _IOR('o', 83, struct dtv_properties)
/**
* When set, this flag will disable any zigzagging or other "normal" tuning
* behaviour. Additionally, there will be no automatic monitoring of the lock
* status, and hence no frontend events will be generated. If a frontend device
* is closed, this flag will be automatically turned off when the device is
* reopened read-write.
*/
#define FE_TUNE_MODE_ONESHOT 0x01
#define <link linkend="FE_GET_INFO">FE_GET_INFO</link> _IOR('o', 61, struct dvb_frontend_info)
#define <link linkend="FE_DISEQC_RESET_OVERLOAD">FE_DISEQC_RESET_OVERLOAD</link> _IO('o', 62)
#define <link linkend="FE_DISEQC_SEND_MASTER_CMD">FE_DISEQC_SEND_MASTER_CMD</link> _IOW('o', 63, struct dvb_diseqc_master_cmd)
#define <link linkend="FE_DISEQC_RECV_SLAVE_REPLY">FE_DISEQC_RECV_SLAVE_REPLY</link> _IOR('o', 64, struct dvb_diseqc_slave_reply)
#define <link linkend="FE_DISEQC_SEND_BURST">FE_DISEQC_SEND_BURST</link> _IO('o', 65) /* fe_sec_mini_cmd_t */
#define <link linkend="FE_SET_TONE">FE_SET_TONE</link> _IO('o', 66) /* fe_sec_tone_mode_t */
#define <link linkend="FE_SET_VOLTAGE">FE_SET_VOLTAGE</link> _IO('o', 67) /* fe_sec_voltage_t */
#define <link linkend="FE_ENABLE_HIGH_LNB_VOLTAGE">FE_ENABLE_HIGH_LNB_VOLTAGE</link> _IO('o', 68) /* int */
#define <link linkend="FE_READ_STATUS">FE_READ_STATUS</link> _IOR('o', 69, fe_status_t)
#define <link linkend="FE_READ_BER">FE_READ_BER</link> _IOR('o', 70, __u32)
#define <link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link> _IOR('o', 71, __u16)
#define <link linkend="FE_READ_SNR">FE_READ_SNR</link> _IOR('o', 72, __u16)
#define <link linkend="FE_READ_UNCORRECTED_BLOCKS">FE_READ_UNCORRECTED_BLOCKS</link> _IOR('o', 73, __u32)
#define <link linkend="FE_SET_FRONTEND">FE_SET_FRONTEND</link> _IOW('o', 76, struct dvb_frontend_parameters)
#define <link linkend="FE_GET_FRONTEND">FE_GET_FRONTEND</link> _IOR('o', 77, struct dvb_frontend_parameters)
#define <link linkend="FE_SET_FRONTEND_TUNE_MODE">FE_SET_FRONTEND_TUNE_MODE</link> _IO('o', 81) /* unsigned int */
#define <link linkend="FE_GET_EVENT">FE_GET_EVENT</link> _IOR('o', 78, struct dvb_frontend_event)
#define <link linkend="FE_DISHNETWORK_SEND_LEGACY_CMD">FE_DISHNETWORK_SEND_LEGACY_CMD</link> _IO('o', 80) /* unsigned int */
#endif /*_DVBFRONTEND_H_*/
</programlisting>
<section id="isdbt">
<title>ISDB-T frontend</title>
<para>This section describes shortly what are the possible parameters in the Linux
DVB-API called "S2API" and now DVB API 5 in order to tune an ISDB-T/ISDB-Tsb
demodulator:</para>
<para>This ISDB-T/ISDB-Tsb API extension should reflect all information
needed to tune any ISDB-T/ISDB-Tsb hardware. Of course it is possible
that some very sophisticated devices won't need certain parameters to
tune.</para>
<para>The information given here should help application writers to know how
to handle ISDB-T and ISDB-Tsb hardware using the Linux DVB-API.</para>
<para>The details given here about ISDB-T and ISDB-Tsb are just enough to
basically show the dependencies between the needed parameter values,
but surely some information is left out. For more detailed information
see the following documents:</para>
<para>ARIB STD-B31 - "Transmission System for Digital Terrestrial
Television Broadcasting" and</para>
<para>ARIB TR-B14 - "Operational Guidelines for Digital Terrestrial
Television Broadcasting".</para>
<para>In order to read this document one has to have some knowledge the
channel structure in ISDB-T and ISDB-Tsb. I.e. it has to be known to
the reader that an ISDB-T channel consists of 13 segments, that it can
have up to 3 layer sharing those segments, and things like that.</para>
<para>Parameters used by ISDB-T and ISDB-Tsb.</para>
<section id="isdbt-parms">
<title>Parameters that are common with DVB-T and ATSC</title>
<section id="isdbt-freq">
<title><constant>DTV_FREQUENCY</constant></title>
<para>Central frequency of the channel.</para>
<para>For ISDB-T the channels are usally transmitted with an offset of 143kHz. E.g. a
valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
the channel which is 6MHz.</para>
<para>As in ISDB-Tsb the channel consists of only one or three segments the
frequency step is 429kHz, 3*429 respectively. As for ISDB-T the
central frequency of the channel is expected.</para>
</section>
<section id="isdbt-bw">
<title><constant>DTV_BANDWIDTH_HZ</constant> (optional)</title>
<para>Possible values:</para>
<para>For ISDB-T it should be always 6000000Hz (6MHz)</para>
<para>For ISDB-Tsb it can vary depending on the number of connected segments</para>
<para>Note: Hardware specific values might be given here, but standard
applications should not bother to set a value to this field as
standard demods are ignoring it anyway.</para>
<para>Bandwidth in ISDB-T is fixed (6MHz) or can be easily derived from
other parameters (DTV_ISDBT_SB_SEGMENT_IDX,
DTV_ISDBT_SB_SEGMENT_COUNT).</para>
</section>
<section id="isdbt-delivery-sys">
<title><constant>DTV_DELIVERY_SYSTEM</constant></title>
<para>Possible values: <constant>SYS_ISDBT</constant></para>
</section>
<section id="isdbt-tx-mode">
<title><constant>DTV_TRANSMISSION_MODE</constant></title>
<para>ISDB-T supports three carrier/symbol-size: 8K, 4K, 2K. It is called
'mode' in the standard: Mode 1 is 2K, mode 2 is 4K, mode 3 is 8K</para>
<para>Possible values: <constant>TRANSMISSION_MODE_2K</constant>, <constant>TRANSMISSION_MODE_8K</constant>,
<constant>TRANSMISSION_MODE_AUTO</constant>, <constant>TRANSMISSION_MODE_4K</constant></para>
<para>If <constant>DTV_TRANSMISSION_MODE</constant> is set the <constant>TRANSMISSION_MODE_AUTO</constant> the
hardware will try to find the correct FFT-size (if capable) and will
use TMCC to fill in the missing parameters.</para>
<para><constant>TRANSMISSION_MODE_4K</constant> is added at the same time as the other new parameters.</para>
</section>
<section id="isdbt-guard-interval">
<title><constant>DTV_GUARD_INTERVAL</constant></title>
<para>Possible values: <constant>GUARD_INTERVAL_1_32</constant>, <constant>GUARD_INTERVAL_1_16</constant>, <constant>GUARD_INTERVAL_1_8</constant>,
<constant>GUARD_INTERVAL_1_4</constant>, <constant>GUARD_INTERVAL_AUTO</constant></para>
<para>If <constant>DTV_GUARD_INTERVAL</constant> is set the <constant>GUARD_INTERVAL_AUTO</constant> the hardware will
try to find the correct guard interval (if capable) and will use TMCC to fill
in the missing parameters.</para>
</section>
</section>
<section id="isdbt-new-parms">
<title>ISDB-T only parameters</title>
<section id="isdbt-part-rec">
<title><constant>DTV_ISDBT_PARTIAL_RECEPTION</constant></title>
<para><constant>If DTV_ISDBT_SOUND_BROADCASTING</constant> is '0' this bit-field represents whether
the channel is in partial reception mode or not.</para>
<para>If '1' <constant>DTV_ISDBT_LAYERA_*</constant> values are assigned to the center segment and
<constant>DTV_ISDBT_LAYERA_SEGMENT_COUNT</constant> has to be '1'.</para>
<para>If in addition <constant>DTV_ISDBT_SOUND_BROADCASTING</constant> is '1'
<constant>DTV_ISDBT_PARTIAL_RECEPTION</constant> represents whether this ISDB-Tsb channel
is consisting of one segment and layer or three segments and two layers.</para>
<para>Possible values: 0, 1, -1 (AUTO)</para>
</section>
<section id="isdbt-sound-bcast">
<title><constant>DTV_ISDBT_SOUND_BROADCASTING</constant></title>
<para>This field represents whether the other DTV_ISDBT_*-parameters are
referring to an ISDB-T and an ISDB-Tsb channel. (See also
<constant>DTV_ISDBT_PARTIAL_RECEPTION</constant>).</para>
<para>Possible values: 0, 1, -1 (AUTO)</para>
</section>
<section id="isdbt-sb-ch-id">
<title><constant>DTV_ISDBT_SB_SUBCHANNEL_ID</constant></title>
<para>This field only applies if <constant>DTV_ISDBT_SOUND_BROADCASTING</constant> is '1'.</para>
<para>(Note of the author: This might not be the correct description of the
<constant>SUBCHANNEL-ID</constant> in all details, but it is my understanding of the technical
background needed to program a device)</para>
<para>An ISDB-Tsb channel (1 or 3 segments) can be broadcasted alone or in a
set of connected ISDB-Tsb channels. In this set of channels every
channel can be received independently. The number of connected
ISDB-Tsb segment can vary, e.g. depending on the frequency spectrum
bandwidth available.</para>
<para>Example: Assume 8 ISDB-Tsb connected segments are broadcasted. The
broadcaster has several possibilities to put those channels in the
air: Assuming a normal 13-segment ISDB-T spectrum he can align the 8
segments from position 1-8 to 5-13 or anything in between.</para>
<para>The underlying layer of segments are subchannels: each segment is
consisting of several subchannels with a predefined IDs. A sub-channel
is used to help the demodulator to synchronize on the channel.</para>
<para>An ISDB-T channel is always centered over all sub-channels. As for
the example above, in ISDB-Tsb it is no longer as simple as that.</para>
<para><constant>The DTV_ISDBT_SB_SUBCHANNEL_ID</constant> parameter is used to give the
sub-channel ID of the segment to be demodulated.</para>
<para>Possible values: 0 .. 41, -1 (AUTO)</para>
</section>
<section id="isdbt-sb-seg-idx">
<title><constant>DTV_ISDBT_SB_SEGMENT_IDX</constant></title>
<para>This field only applies if <constant>DTV_ISDBT_SOUND_BROADCASTING</constant> is '1'.</para>
<para><constant>DTV_ISDBT_SB_SEGMENT_IDX</constant> gives the index of the segment to be
demodulated for an ISDB-Tsb channel where several of them are
transmitted in the connected manner.</para>
<para>Possible values: 0 .. <constant>DTV_ISDBT_SB_SEGMENT_COUNT</constant> - 1</para>
<para>Note: This value cannot be determined by an automatic channel search.</para>
</section>
<section id="isdbt-sb-seg-cnt">
<title><constant>DTV_ISDBT_SB_SEGMENT_COUNT</constant></title>
<para>This field only applies if <constant>DTV_ISDBT_SOUND_BROADCASTING</constant> is '1'.</para>
<para><constant>DTV_ISDBT_SB_SEGMENT_COUNT</constant> gives the total count of connected ISDB-Tsb
channels.</para>
<para>Possible values: 1 .. 13</para>
<para>Note: This value cannot be determined by an automatic channel search.</para>
</section>
<section id="isdb-hierq-layers">
<title>Hierarchical layers</title>
<para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in
ISDB-T hierarchical layers can be decoded simultaneously. For that
reason a ISDB-T demodulator has 3 viterbi and 3 reed-solomon-decoders.</para>
<para>ISDB-T has 3 hierarchical layers which each can use a part of the
available segments. The total number of segments over all layers has
to 13 in ISDB-T.</para>
<section id="isdbt-layer-ena">
<title><constant>DTV_ISDBT_LAYER_ENABLED</constant></title>
<para>Hierarchical reception in ISDB-T is achieved by enabling or disabling
layers in the decoding process. Setting all bits of
<constant>DTV_ISDBT_LAYER_ENABLED</constant> to '1' forces all layers (if applicable) to be
demodulated. This is the default.</para>
<para>If the channel is in the partial reception mode
(<constant>DTV_ISDBT_PARTIAL_RECEPTION</constant> = 1) the central segment can be decoded
independently of the other 12 segments. In that mode layer A has to
have a <constant>SEGMENT_COUNT</constant> of 1.</para>
<para>In ISDB-Tsb only layer A is used, it can be 1 or 3 in ISDB-Tsb
according to <constant>DTV_ISDBT_PARTIAL_RECEPTION</constant>. <constant>SEGMENT_COUNT</constant> must be filled
accordingly.</para>
<para>Possible values: 0x1, 0x2, 0x4 (|-able)</para>
<para><constant>DTV_ISDBT_LAYER_ENABLED[0:0]</constant> - layer A</para>
<para><constant>DTV_ISDBT_LAYER_ENABLED[1:1]</constant> - layer B</para>
<para><constant>DTV_ISDBT_LAYER_ENABLED[2:2]</constant> - layer C</para>
<para><constant>DTV_ISDBT_LAYER_ENABLED[31:3]</constant> unused</para>
</section>
<section id="isdbt-layer-fec">
<title><constant>DTV_ISDBT_LAYER*_FEC</constant></title>
<para>Possible values: <constant>FEC_AUTO</constant>, <constant>FEC_1_2</constant>, <constant>FEC_2_3</constant>, <constant>FEC_3_4</constant>, <constant>FEC_5_6</constant>, <constant>FEC_7_8</constant></para>
</section>
<section id="isdbt-layer-mod">
<title><constant>DTV_ISDBT_LAYER*_MODULATION</constant></title>
<para>Possible values: <constant>QAM_AUTO</constant>, QP<constant>SK, QAM_16</constant>, <constant>QAM_64</constant>, <constant>DQPSK</constant></para>
<para>Note: If layer C is <constant>DQPSK</constant> layer B has to be <constant>DQPSK</constant>. If layer B is <constant>DQPSK</constant>
and <constant>DTV_ISDBT_PARTIAL_RECEPTION</constant>=0 layer has to be <constant>DQPSK</constant>.</para>
</section>
<section id="isdbt-layer-seg-cnt">
<title><constant>DTV_ISDBT_LAYER*_SEGMENT_COUNT</constant></title>
<para>Possible values: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, -1 (AUTO)</para>
<para>Note: Truth table for <constant>DTV_ISDBT_SOUND_BROADCASTING</constant> and
<constant>DTV_ISDBT_PARTIAL_RECEPTION</constant> and <constant>LAYER</constant>*_SEGMENT_COUNT</para>
<informaltable id="isdbt-layer_seg-cnt-table">
<tgroup cols="6">
<tbody>
<row>
<entry>PR</entry>
<entry>SB</entry>
<entry>Layer A width</entry>
<entry>Layer B width</entry>
<entry>Layer C width</entry>
<entry>total width</entry>
</row>
<row>
<entry>0</entry>
<entry>0</entry>
<entry>1 .. 13</entry>
<entry>1 .. 13</entry>
<entry>1 .. 13</entry>
<entry>13</entry>
</row>
<row>
<entry>1</entry>
<entry>0</entry>
<entry>1</entry>
<entry>1 .. 13</entry>
<entry>1 .. 13</entry>
<entry>13</entry>
</row>
<row>
<entry>0</entry>
<entry>1</entry>
<entry>1</entry>
<entry>0</entry>
<entry>0</entry>
<entry>1</entry>
</row>
<row>
<entry>1</entry>
<entry>1</entry>
<entry>1</entry>
<entry>2</entry>
<entry>0</entry>
<entry>13</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</section>
<section id="isdbt_layer_t_interl">
<title><constant>DTV_ISDBT_LAYER*_TIME_INTERLEAVING</constant></title>
<para>Possible values: 0, 1, 2, 3, -1 (AUTO)</para>
<para>Note: The real inter-leaver depth-names depend on the mode (fft-size); the values
here are referring to what can be found in the TMCC-structure -
independent of the mode.</para>
</section>
</section>
</section>
</section>
......@@ -417,8 +417,8 @@ desc->chip->end();
</para>
<para>
To make use of the split implementation, replace the call to
__do_IRQ by a call to desc->chip->handle_irq() and associate
the appropriate handler function to desc->chip->handle_irq().
__do_IRQ by a call to desc->handle_irq() and associate
the appropriate handler function to desc->handle_irq().
In most cases the generic handler implementations should
be sufficient.
</para>
......
......@@ -352,7 +352,7 @@ asmlinkage long sys_mycall(int arg)
</para>
<programlisting>
if (signal_pending())
if (signal_pending(current))
return -ERESTARTSYS;
</programlisting>
......
......@@ -280,7 +280,7 @@
<!ENTITY sub-v4l2 SYSTEM "v4l/v4l2.xml">
<!ENTITY sub-intro SYSTEM "dvb/intro.xml">
<!ENTITY sub-frontend SYSTEM "dvb/frontend.xml">
<!ENTITY sub-isdbt SYSTEM "dvb/isdbt.xml">
<!ENTITY sub-dvbproperty SYSTEM "dvb/dvbproperty.xml">
<!ENTITY sub-demux SYSTEM "dvb/demux.xml">
<!ENTITY sub-video SYSTEM "dvb/video.xml">
<!ENTITY sub-audio SYSTEM "dvb/audio.xml">
......@@ -288,6 +288,7 @@
<!ENTITY sub-net SYSTEM "dvb/net.xml">
<!ENTITY sub-kdapi SYSTEM "dvb/kdapi.xml">
<!ENTITY sub-examples SYSTEM "dvb/examples.xml">
<!ENTITY sub-frontend-h SYSTEM "dvb/frontend.h.xml">
<!ENTITY sub-dvbapi SYSTEM "dvb/dvbapi.xml">
<!ENTITY sub-media SYSTEM "media.xml">
<!ENTITY sub-media-entities SYSTEM "media-entities.tmpl">
......
......@@ -362,7 +362,7 @@ module_exit(board_cleanup);
<sect1 id="Multiple_chip_control">
<title>Multiple chip control</title>
<para>
The nand driver can control chip arrays. Therefor the
The nand driver can control chip arrays. Therefore the
board driver must provide an own select_chip function. This
function must (de)select the requested chip.
The function pointer in the nand_chip structure must
......
......@@ -86,4 +86,9 @@
!Iinclude/trace/events/irq.h
</chapter>
<chapter id="signal">
<title>SIGNAL</title>
!Iinclude/trace/events/signal.h
</chapter>
</book>
......@@ -280,11 +280,29 @@ minimum value disables backlight compensation.</entry>
<constant>V4L2_COLORFX_BW</constant> (1) and
<constant>V4L2_COLORFX_SEPIA</constant> (2).</entry>
</row>
<row>
<entry><constant>V4L2_CID_ROTATE</constant></entry>
<entry>integer</entry>
<entry>Rotates the image by specified angle. Common angles are 90,
270 and 180. Rotating the image to 90 and 270 will reverse the height
and width of the display window. It is necessary to set the new height and
width of the picture using the &VIDIOC-S-FMT; ioctl according to
the rotation angle selected.</entry>
</row>
<row>
<entry><constant>V4L2_CID_BG_COLOR</constant></entry>
<entry>integer</entry>
<entry>Sets the background color on the current output device.
Background color needs to be specified in the RGB24 format. The
supplied 32 bit value is interpreted as bits 0-7 Red color information,
bits 8-15 Green color information, bits 16-23 Blue color
information and bits 24-31 must be zero.</entry>
</row>
<row>
<entry><constant>V4L2_CID_LASTP1</constant></entry>
<entry></entry>
<entry>End of the predefined control IDs (currently
<constant>V4L2_CID_COLORFX</constant> + 1).</entry>
<constant>V4L2_CID_BG_COLOR</constant> + 1).</entry>
</row>
<row>
<entry><constant>V4L2_CID_PRIVATE_BASE</constant></entry>
......
......@@ -770,6 +770,11 @@ kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm
<entry>'S920'</entry>
<entry>YUV 4:2:0 format of the gspca sn9c20x driver.</entry>
</row>
<row id="V4L2-PIX-FMT-STV0680">
<entry><constant>V4L2_PIX_FMT_STV0680</constant></entry>
<entry>'S680'</entry>
<entry>Bayer format of the gspca stv0680 driver.</entry>
</row>
<row id="V4L2-PIX-FMT-WNVA">
<entry><constant>V4L2_PIX_FMT_WNVA</constant></entry>
<entry>'WNVA'</entry>
......
......@@ -363,6 +363,7 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
#define <link linkend="V4L2-PIX-FMT-OV511">V4L2_PIX_FMT_OV511</link> v4l2_fourcc('O', '5', '1', '1') /* ov511 JPEG */
#define <link linkend="V4L2-PIX-FMT-OV518">V4L2_PIX_FMT_OV518</link> v4l2_fourcc('O', '5', '1', '8') /* ov518 JPEG */
#define <link linkend="V4L2-PIX-FMT-TM6000">V4L2_PIX_FMT_TM6000</link> v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */
#define <link linkend="V4L2-PIX-FMT-STV0680">V4L2_PIX_FMT_STV0680</link> v4l2_fourcc('S', '6', '8', '0') /* stv0680 bayer */
/*
* F O R M A T E N U M E R A T I O N
......@@ -492,7 +493,7 @@ struct <link linkend="v4l2-jpegcompression">v4l2_jpegcompression</link> {
* you do, leave them untouched.
* Inluding less markers will make the
* resulting code smaller, but there will
* be fewer aplications which can read it.
* be fewer applications which can read it.
* The presence of the APP and COM marker
* is influenced by APP_len and COM_len
* ONLY, not by this property! */
......@@ -565,6 +566,7 @@ struct <link linkend="v4l2-framebuffer">v4l2_framebuffer</link> {
#define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010
#define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020
#define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040
#define V4L2_FBUF_CAP_SRC_CHROMAKEY 0x0080
/* Flags for the 'flags' field. */
#define V4L2_FBUF_FLAG_PRIMARY 0x0001
#define V4L2_FBUF_FLAG_OVERLAY 0x0002
......@@ -572,6 +574,7 @@ struct <link linkend="v4l2-framebuffer">v4l2_framebuffer</link> {
#define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008
#define V4L2_FBUF_FLAG_GLOBAL_ALPHA 0x0010
#define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020
#define V4L2_FBUF_FLAG_SRC_CHROMAKEY 0x0040
struct <link linkend="v4l2-clip">v4l2_clip</link> {
struct <link linkend="v4l2-rect">v4l2_rect</link> c;
......@@ -914,8 +917,10 @@ enum <link linkend="v4l2-colorfx">v4l2_colorfx</link> {
#define V4L2_CID_AUTOBRIGHTNESS (V4L2_CID_BASE+32)
#define V4L2_CID_BAND_STOP_FILTER (V4L2_CID_BASE+33)
#define V4L2_CID_ROTATE (V4L2_CID_BASE+34)
#define V4L2_CID_BG_COLOR (V4L2_CID_BASE+35)
/* last CID + 1 */
#define V4L2_CID_LASTP1 (V4L2_CID_BASE+34)
#define V4L2_CID_LASTP1 (V4L2_CID_BASE+36)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
......
......@@ -336,6 +336,13 @@ alpha value. Alpha blending makes no sense for destructive overlays.</entry>
inverted alpha channel of the framebuffer or VGA signal. Alpha
blending makes no sense for destructive overlays.</entry>
</row>
<row>
<entry><constant>V4L2_FBUF_CAP_SRC_CHROMAKEY</constant></entry>
<entry>0x0080</entry>
<entry>The device supports Source Chroma-keying. Framebuffer pixels
with the chroma-key colors are replaced by video pixels, which is exactly opposite of
<constant>V4L2_FBUF_CAP_CHROMAKEY</constant></entry>
</row>
</tbody>
</tgroup>
</table>
......@@ -411,6 +418,16 @@ images, but with an inverted alpha value. The blend function is:
output = framebuffer pixel * (1 - alpha) + video pixel * alpha. The
actual alpha depth depends on the framebuffer pixel format.</entry>
</row>
<row>
<entry><constant>V4L2_FBUF_FLAG_SRC_CHROMAKEY</constant></entry>
<entry>0x0040</entry>
<entry>Use source chroma-keying. The source chroma-key color is
determined by the <structfield>chromakey</structfield> field of
&v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see <xref
linkend="overlay" /> and <xref linkend="osd" />.
Both chroma-keying are mutual exclusive to each other, so same
<structfield>chromakey</structfield> field of &v4l2-window; is being used.</entry>
</row>
</tbody>
</tgroup>
</table>
......
......@@ -5318,7 +5318,7 @@ struct _snd_pcm_runtime {
pages of the given size and map them onto the virtually contiguous
memory. The virtual pointer is addressed in runtime-&gt;dma_area.
The physical address (runtime-&gt;dma_addr) is set to zero,
because the buffer is physically non-contigous.
because the buffer is physically non-contiguous.
The physical address table is set up in sgbuf-&gt;table.
You can get the physical address at a certain offset via
<function>snd_pcm_sgbuf_get_addr()</function>.
......
CONFIG_RCU_TRACE debugfs Files and Formats
The rcupreempt and rcutree implementations of RCU provide debugfs trace
output that summarizes counters and state. This information is useful for
debugging RCU itself, and can sometimes also help to debug abuses of RCU.
Note that the rcuclassic implementation of RCU does not provide debugfs
trace output.
The following sections describe the debugfs files and formats for
preemptable RCU (rcupreempt) and hierarchical RCU (rcutree).
Preemptable RCU debugfs Files and Formats
This implementation of RCU provides three debugfs files under the
top-level directory RCU: rcu/rcuctrs (which displays the per-CPU
counters used by preemptable RCU) rcu/rcugp (which displays grace-period
counters), and rcu/rcustats (which internal counters for debugging RCU).
The output of "cat rcu/rcuctrs" looks as follows:
CPU last cur F M
0 5 -5 0 0
1 -1 0 0 0
2 0 1 0 0
3 0 1 0 0
4 0 1 0 0
5 0 1 0 0
6 0 2 0 0
7 0 -1 0 0
8 0 1 0 0
ggp = 26226, state = waitzero
The per-CPU fields are as follows:
o "CPU" gives the CPU number. Offline CPUs are not displayed.
o "last" gives the value of the counter that is being decremented
for the current grace period phase. In the example above,
the counters sum to 4, indicating that there are still four
RCU read-side critical sections still running that started
before the last counter flip.
o "cur" gives the value of the counter that is currently being
both incremented (by rcu_read_lock()) and decremented (by
rcu_read_unlock()). In the example above, the counters sum to
1, indicating that there is only one RCU read-side critical section
still running that started after the last counter flip.
o "F" indicates whether RCU is waiting for this CPU to acknowledge
a counter flip. In the above example, RCU is not waiting on any,
which is consistent with the state being "waitzero" rather than
"waitack".
o "M" indicates whether RCU is waiting for this CPU to execute a
memory barrier. In the above example, RCU is not waiting on any,
which is consistent with the state being "waitzero" rather than
"waitmb".
o "ggp" is the global grace-period counter.
o "state" is the RCU state, which can be one of the following:
o "idle": there is no grace period in progress.
o "waitack": RCU just incremented the global grace-period
counter, which has the effect of reversing the roles of
the "last" and "cur" counters above, and is waiting for
all the CPUs to acknowledge the flip. Once the flip has
been acknowledged, CPUs will no longer be incrementing
what are now the "last" counters, so that their sum will
decrease monotonically down to zero.
o "waitzero": RCU is waiting for the sum of the "last" counters
to decrease to zero.
o "waitmb": RCU is waiting for each CPU to execute a memory
barrier, which ensures that instructions from a given CPU's
last RCU read-side critical section cannot be reordered
with instructions following the memory-barrier instruction.
The output of "cat rcu/rcugp" looks as follows:
oldggp=48870 newggp=48873
Note that reading from this file provokes a synchronize_rcu(). The
"oldggp" value is that of "ggp" from rcu/rcuctrs above, taken before
executing the synchronize_rcu(), and the "newggp" value is also the
"ggp" value, but taken after the synchronize_rcu() command returns.
The output of "cat rcu/rcugp" looks as follows:
na=1337955 nl=40 wa=1337915 wl=44 da=1337871 dl=0 dr=1337871 di=1337871
1=50989 e1=6138 i1=49722 ie1=82 g1=49640 a1=315203 ae1=265563 a2=49640
z1=1401244 ze1=1351605 z2=49639 m1=5661253 me1=5611614 m2=49639
These are counters tracking internal preemptable-RCU events, however,
some of them may be useful for debugging algorithms using RCU. In
particular, the "nl", "wl", and "dl" values track the number of RCU
callbacks in various states. The fields are as follows:
o "na" is the total number of RCU callbacks that have been enqueued
since boot.
o "nl" is the number of RCU callbacks waiting for the previous
grace period to end so that they can start waiting on the next
grace period.
o "wa" is the total number of RCU callbacks that have started waiting
for a grace period since boot. "na" should be roughly equal to
"nl" plus "wa".
o "wl" is the number of RCU callbacks currently waiting for their
grace period to end.
o "da" is the total number of RCU callbacks whose grace periods
have completed since boot. "wa" should be roughly equal to
"wl" plus "da".
o "dr" is the total number of RCU callbacks that have been removed
from the list of callbacks ready to invoke. "dr" should be roughly
equal to "da".
o "di" is the total number of RCU callbacks that have been invoked
since boot. "di" should be roughly equal to "da", though some
early versions of preemptable RCU had a bug so that only the
last CPU's count of invocations was displayed, rather than the
sum of all CPU's counts.
o "1" is the number of calls to rcu_try_flip(). This should be
roughly equal to the sum of "e1", "i1", "a1", "z1", and "m1"
described below. In other words, the number of times that
the state machine is visited should be equal to the sum of the
number of times that each state is visited plus the number of
times that the state-machine lock acquisition failed.
o "e1" is the number of times that rcu_try_flip() was unable to
acquire the fliplock.
o "i1" is the number of calls to rcu_try_flip_idle().
o "ie1" is the number of times rcu_try_flip_idle() exited early
due to the calling CPU having no work for RCU.
o "g1" is the number of times that rcu_try_flip_idle() decided
to start a new grace period. "i1" should be roughly equal to
"ie1" plus "g1".
o "a1" is the number of calls to rcu_try_flip_waitack().
o "ae1" is the number of times that rcu_try_flip_waitack() found
that at least one CPU had not yet acknowledge the new grace period
(AKA "counter flip").
o "a2" is the number of time rcu_try_flip_waitack() found that
all CPUs had acknowledged. "a1" should be roughly equal to
"ae1" plus "a2". (This particular output was collected on
a 128-CPU machine, hence the smaller-than-usual fraction of
calls to rcu_try_flip_waitack() finding all CPUs having already
acknowledged.)
o "z1" is the number of calls to rcu_try_flip_waitzero().
o "ze1" is the number of times that rcu_try_flip_waitzero() found
that not all of the old RCU read-side critical sections had
completed.
o "z2" is the number of times that rcu_try_flip_waitzero() finds
the sum of the counters equal to zero, in other words, that
all of the old RCU read-side critical sections had completed.
The value of "z1" should be roughly equal to "ze1" plus
"z2".
o "m1" is the number of calls to rcu_try_flip_waitmb().
o "me1" is the number of times that rcu_try_flip_waitmb() finds
that at least one CPU has not yet executed a memory barrier.
o "m2" is the number of times that rcu_try_flip_waitmb() finds that
all CPUs have executed a memory barrier.
The rcutree implementation of RCU provides debugfs trace output that
summarizes counters and state. This information is useful for debugging
RCU itself, and can sometimes also help to debug abuses of RCU.
The following sections describe the debugfs files and formats.
Hierarchical RCU debugfs Files and Formats
......@@ -210,9 +35,10 @@ rcu_bh:
6 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=859/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
7 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=3761/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
The first section lists the rcu_data structures for rcu, the second for
rcu_bh. Each section has one line per CPU, or eight for this 8-CPU system.
The fields are as follows:
The first section lists the rcu_data structures for rcu_sched, the second
for rcu_bh. Note that CONFIG_TREE_PREEMPT_RCU kernels will have an
additional section for rcu_preempt. Each section has one line per CPU,
or eight for this 8-CPU system. The fields are as follows:
o The number at the beginning of each line is the CPU number.
CPUs numbers followed by an exclamation mark are offline,
......@@ -223,9 +49,9 @@ o The number at the beginning of each line is the CPU number.
o "c" is the count of grace periods that this CPU believes have
completed. CPUs in dynticks idle mode may lag quite a ways
behind, for example, CPU 4 under "rcu" above, which has slept
through the past 25 RCU grace periods. It is not unusual to
see CPUs lagging by thousands of grace periods.
behind, for example, CPU 4 under "rcu_sched" above, which has
slept through the past 25 RCU grace periods. It is not unusual
to see CPUs lagging by thousands of grace periods.
o "g" is the count of grace periods that this CPU believes have
started. Again, CPUs in dynticks idle mode may lag behind.
......@@ -308,8 +134,10 @@ The output of "cat rcu/rcugp" looks as follows:
rcu_sched: completed=33062 gpnum=33063
rcu_bh: completed=464 gpnum=464
Again, this output is for both "rcu" and "rcu_bh". The fields are
taken from the rcu_state structure, and are as follows:
Again, this output is for both "rcu_sched" and "rcu_bh". Note that
kernels built with CONFIG_TREE_PREEMPT_RCU will have an additional
"rcu_preempt" line. The fields are taken from the rcu_state structure,
and are as follows:
o "completed" is the number of grace periods that have completed.
It is comparable to the "c" field from rcu/rcudata in that a
......@@ -324,23 +152,24 @@ o "gpnum" is the number of grace periods that have started. It is
If these two fields are equal (as they are for "rcu_bh" above),
then there is no grace period in progress, in other words, RCU
is idle. On the other hand, if the two fields differ (as they
do for "rcu" above), then an RCU grace period is in progress.
do for "rcu_sched" above), then an RCU grace period is in progress.
The output of "cat rcu/rcuhier" looks as follows, with very long lines:
c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6
1/1 0:127 ^0
3/3 0:35 ^0 0/0 36:71 ^1 0/0 72:107 ^2 0/0 108:127 ^3
3/3f 0:5 ^0 2/3 6:11 ^1 0/0 12:17 ^2 0/0 18:23 ^3 0/0 24:29 ^4 0/0 30:35 ^5 0/0 36:41 ^0 0/0 42:47 ^1 0/0 48:53 ^2 0/0 54:59 ^3 0/0 60:65 ^4 0/0 66:71 ^5 0/0 72:77 ^0 0/0 78:83 ^1 0/0 84:89 ^2 0/0 90:95 ^3 0/0 96:101 ^4 0/0 102:107 ^5 0/0 108:113 ^0 0/0 114:119 ^1 0/0 120:125 ^2 0/0 126:127 ^3
c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6 oqlen=0
1/1 .>. 0:127 ^0
3/3 .>. 0:35 ^0 0/0 .>. 36:71 ^1 0/0 .>. 72:107 ^2 0/0 .>. 108:127 ^3
3/3f .>. 0:5 ^0 2/3 .>. 6:11 ^1 0/0 .>. 12:17 ^2 0/0 .>. 18:23 ^3 0/0 .>. 24:29 ^4 0/0 .>. 30:35 ^5 0/0 .>. 36:41 ^0 0/0 .>. 42:47 ^1 0/0 .>. 48:53 ^2 0/0 .>. 54:59 ^3 0/0 .>. 60:65 ^4 0/0 .>. 66:71 ^5 0/0 .>. 72:77 ^0 0/0 .>. 78:83 ^1 0/0 .>. 84:89 ^2 0/0 .>. 90:95 ^3 0/0 .>. 96:101 ^4 0/0 .>. 102:107 ^5 0/0 .>. 108:113 ^0 0/0 .>. 114:119 ^1 0/0 .>. 120:125 ^2 0/0 .>. 126:127 ^3
rcu_bh:
c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0
0/1 0:127 ^0
0/3 0:35 ^0 0/0 36:71 ^1 0/0 72:107 ^2 0/0 108:127 ^3
0/3f 0:5 ^0 0/3 6:11 ^1 0/0 12:17 ^2 0/0 18:23 ^3 0/0 24:29 ^4 0/0 30:35 ^5 0/0 36:41 ^0 0/0 42:47 ^1 0/0 48:53 ^2 0/0 54:59 ^3 0/0 60:65 ^4 0/0 66:71 ^5 0/0 72:77 ^0 0/0 78:83 ^1 0/0 84:89 ^2 0/0 90:95 ^3 0/0 96:101 ^4 0/0 102:107 ^5 0/0 108:113 ^0 0/0 114:119 ^1 0/0 120:125 ^2 0/0 126:127 ^3
c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0 oqlen=0
0/1 .>. 0:127 ^0
0/3 .>. 0:35 ^0 0/0 .>. 36:71 ^1 0/0 .>. 72:107 ^2 0/0 .>. 108:127 ^3
0/3f .>. 0:5 ^0 0/3 .>. 6:11 ^1 0/0 .>. 12:17 ^2 0/0 .>. 18:23 ^3 0/0 .>. 24:29 ^4 0/0 .>. 30:35 ^5 0/0 .>. 36:41 ^0 0/0 .>. 42:47 ^1 0/0 .>. 48:53 ^2 0/0 .>. 54:59 ^3 0/0 .>. 60:65 ^4 0/0 .>. 66:71 ^5 0/0 .>. 72:77 ^0 0/0 .>. 78:83 ^1 0/0 .>. 84:89 ^2 0/0 .>. 90:95 ^3 0/0 .>. 96:101 ^4 0/0 .>. 102:107 ^5 0/0 .>. 108:113 ^0 0/0 .>. 114:119 ^1 0/0 .>. 120:125 ^2 0/0 .>. 126:127 ^3
This is once again split into "rcu" and "rcu_bh" portions. The fields are
as follows:
This is once again split into "rcu_sched" and "rcu_bh" portions,
and CONFIG_TREE_PREEMPT_RCU kernels will again have an additional
"rcu_preempt" section. The fields are as follows:
o "c" is exactly the same as "completed" under rcu/rcugp.
......@@ -372,6 +201,11 @@ o "fqlh" is the number of calls to force_quiescent_state() that
exited immediately (without even being counted in nfqs above)
due to contention on ->fqslock.
o "oqlen" is the number of callbacks on the "orphan" callback
list. RCU callbacks are placed on this list by CPUs going
offline, and are "adopted" either by the CPU helping the outgoing
CPU or by the next rcu_barrier*() call, whichever comes first.
o Each element of the form "1/1 0:127 ^0" represents one struct
rcu_node. Each line represents one level of the hierarchy, from
root to leaves. It is best to think of the rcu_data structures
......@@ -379,7 +213,7 @@ o Each element of the form "1/1 0:127 ^0" represents one struct
might be either one, two, or three levels of rcu_node structures,
depending on the relationship between CONFIG_RCU_FANOUT and
CONFIG_NR_CPUS.
o The numbers separated by the "/" are the qsmask followed
by the qsmaskinit. The qsmask will have one bit
set for each entity in the next lower level that
......@@ -389,10 +223,19 @@ o Each element of the form "1/1 0:127 ^0" represents one struct
The value of qsmaskinit is assigned to that of qsmask
at the beginning of each grace period.
For example, for "rcu", the qsmask of the first entry
of the lowest level is 0x14, meaning that we are still
waiting for CPUs 2 and 4 to check in for the current
grace period.
For example, for "rcu_sched", the qsmask of the first
entry of the lowest level is 0x14, meaning that we
are still waiting for CPUs 2 and 4 to check in for the
current grace period.
o The characters separated by the ">" indicate the state
of the blocked-tasks lists. A "T" preceding the ">"
indicates that at least one task blocked in an RCU
read-side critical section blocks the current grace
period, while a "." preceding the ">" indicates otherwise.
The character following the ">" indicates similarly for
the next grace period. A "T" should appear in this
field only for rcu-preempt.
o The numbers separated by the ":" are the range of CPUs
served by this struct rcu_node. This can be helpful
......@@ -431,8 +274,9 @@ rcu_bh:
6 np=120834 qsp=9902 cbr=0 cng=0 gpc=6 gps=3 nf=2 nn=110921
7 np=144888 qsp=26336 cbr=0 cng=0 gpc=8 gps=2 nf=0 nn=118542
As always, this is once again split into "rcu" and "rcu_bh" portions.
The fields are as follows:
As always, this is once again split into "rcu_sched" and "rcu_bh"
portions, with CONFIG_TREE_PREEMPT_RCU kernels having an additional
"rcu_preempt" section. The fields are as follows:
o "np" is the number of times that __rcu_pending() has been invoked
for the corresponding flavor of RCU.
......
......@@ -830,7 +830,7 @@ sched: Critical sections Grace period Barrier
SRCU: Critical sections Grace period Barrier
srcu_read_lock synchronize_srcu N/A
srcu_read_unlock
srcu_read_unlock synchronize_srcu_expedited
SRCU: Initialization/cleanup
init_srcu_struct
......
OMAP2/3 Display Subsystem
-------------------------
This is an almost total rewrite of the OMAP FB driver in drivers/video/omap
(let's call it DSS1). The main differences between DSS1 and DSS2 are DSI,
TV-out and multiple display support, but there are lots of small improvements
also.
The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB,
panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live
currently side by side, you can choose which one to use.
Features
--------
Working and tested features include:
- MIPI DPI (parallel) output
- MIPI DSI output in command mode
- MIPI DBI (RFBI) output
- SDI output
- TV output
- All pieces can be compiled as a module or inside kernel
- Use DISPC to update any of the outputs
- Use CPU to update RFBI or DSI output
- OMAP DISPC planes
- RGB16, RGB24 packed, RGB24 unpacked
- YUV2, UYVY
- Scaling
- Adjusting DSS FCK to find a good pixel clock
- Use DSI DPLL to create DSS FCK
Tested boards include:
- OMAP3 SDP board
- Beagle board
- N810
omapdss driver
--------------
The DSS driver does not itself have any support for Linux framebuffer, V4L or
such like the current ones, but it has an internal kernel API that upper level
drivers can use.
The DSS driver models OMAP's overlays, overlay managers and displays in a
flexible way to enable non-common multi-display configuration. In addition to
modelling the hardware overlays, omapdss supports virtual overlays and overlay
managers. These can be used when updating a display with CPU or system DMA.
Panel and controller drivers
----------------------------
The drivers implement panel or controller specific functionality and are not
usually visible to users except through omapfb driver. They register
themselves to the DSS driver.
omapfb driver
-------------
The omapfb driver implements arbitrary number of standard linux framebuffers.
These framebuffers can be routed flexibly to any overlays, thus allowing very
dynamic display architecture.
The driver exports some omapfb specific ioctls, which are compatible with the
ioctls in the old driver.
The rest of the non standard features are exported via sysfs. Whether the final
implementation will use sysfs, or ioctls, is still open.
V4L2 drivers
------------
V4L2 is being implemented in TI.
From omapdss point of view the V4L2 drivers should be similar to framebuffer
driver.
Architecture
--------------------
Some clarification what the different components do:
- Framebuffer is a memory area inside OMAP's SRAM/SDRAM that contains the
pixel data for the image. Framebuffer has width and height and color
depth.
- Overlay defines where the pixels are read from and where they go on the
screen. The overlay may be smaller than framebuffer, thus displaying only
part of the framebuffer. The position of the overlay may be changed if
the overlay is smaller than the display.
- Overlay manager combines the overlays in to one image and feeds them to
display.
- Display is the actual physical display device.
A framebuffer can be connected to multiple overlays to show the same pixel data
on all of the overlays. Note that in this case the overlay input sizes must be
the same, but, in case of video overlays, the output size can be different. Any
framebuffer can be connected to any overlay.
An overlay can be connected to one overlay manager. Also DISPC overlays can be
connected only to DISPC overlay managers, and virtual overlays can be only
connected to virtual overlays.
An overlay manager can be connected to one display. There are certain
restrictions which kinds of displays an overlay manager can be connected:
- DISPC TV overlay manager can be only connected to TV display.
- Virtual overlay managers can only be connected to DBI or DSI displays.
- DISPC LCD overlay manager can be connected to all displays, except TV
display.
Sysfs
-----
The sysfs interface is mainly used for testing. I don't think sysfs
interface is the best for this in the final version, but I don't quite know
what would be the best interfaces for these things.
The sysfs interface is divided to two parts: DSS and FB.
/sys/class/graphics/fb? directory:
mirror 0=off, 1=on
rotate Rotation 0-3 for 0, 90, 180, 270 degrees
rotate_type 0 = DMA rotation, 1 = VRFB rotation
overlays List of overlay numbers to which framebuffer pixels go
phys_addr Physical address of the framebuffer
virt_addr Virtual address of the framebuffer
size Size of the framebuffer
/sys/devices/platform/omapdss/overlay? directory:
enabled 0=off, 1=on
input_size width,height (ie. the framebuffer size)
manager Destination overlay manager name
name
output_size width,height
position x,y
screen_width width
global_alpha global alpha 0-255 0=transparent 255=opaque
/sys/devices/platform/omapdss/manager? directory:
display Destination display
name
alpha_blending_enabled 0=off, 1=on
trans_key_enabled 0=off, 1=on
trans_key_type gfx-destination, video-source
trans_key_value transparency color key (RGB24)
default_color default background color (RGB24)
/sys/devices/platform/omapdss/display? directory:
ctrl_name Controller name
mirror 0=off, 1=on
update_mode 0=off, 1=auto, 2=manual
enabled 0=off, 1=on
name
rotate Rotation 0-3 for 0, 90, 180, 270 degrees
timings Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw)
When writing, two special timings are accepted for tv-out:
"pal" and "ntsc"
panel_name
tear_elim Tearing elimination 0=off, 1=on
There are also some debugfs files at <debugfs>/omapdss/ which show information
about clocks and registers.
Examples
--------
The following definitions have been made for the examples below:
ovl0=/sys/devices/platform/omapdss/overlay0
ovl1=/sys/devices/platform/omapdss/overlay1
ovl2=/sys/devices/platform/omapdss/overlay2
mgr0=/sys/devices/platform/omapdss/manager0
mgr1=/sys/devices/platform/omapdss/manager1
lcd=/sys/devices/platform/omapdss/display0
dvi=/sys/devices/platform/omapdss/display1
tv=/sys/devices/platform/omapdss/display2
fb0=/sys/class/graphics/fb0
fb1=/sys/class/graphics/fb1
fb2=/sys/class/graphics/fb2
Default setup on OMAP3 SDP
--------------------------
Here's the default setup on OMAP3 SDP board. All planes go to LCD. DVI
and TV-out are not in use. The columns from left to right are:
framebuffers, overlays, overlay managers, displays. Framebuffers are
handled by omapfb, and the rest by the DSS.
FB0 --- GFX -\ DVI
FB1 --- VID1 --+- LCD ---- LCD
FB2 --- VID2 -/ TV ----- TV
Example: Switch from LCD to DVI
----------------------
w=`cat $dvi/timings | cut -d "," -f 2 | cut -d "/" -f 1`
h=`cat $dvi/timings | cut -d "," -f 3 | cut -d "/" -f 1`
echo "0" > $lcd/enabled
echo "" > $mgr0/display
fbset -fb /dev/fb0 -xres $w -yres $h -vxres $w -vyres $h
# at this point you have to switch the dvi/lcd dip-switch from the omap board
echo "dvi" > $mgr0/display
echo "1" > $dvi/enabled
After this the configuration looks like:
FB0 --- GFX -\ -- DVI
FB1 --- VID1 --+- LCD -/ LCD
FB2 --- VID2 -/ TV ----- TV
Example: Clone GFX overlay to LCD and TV
-------------------------------
w=`cat $tv/timings | cut -d "," -f 2 | cut -d "/" -f 1`
h=`cat $tv/timings | cut -d "," -f 3 | cut -d "/" -f 1`
echo "0" > $ovl0/enabled
echo "0" > $ovl1/enabled
echo "" > $fb1/overlays
echo "0,1" > $fb0/overlays
echo "$w,$h" > $ovl1/output_size
echo "tv" > $ovl1/manager
echo "1" > $ovl0/enabled
echo "1" > $ovl1/enabled
echo "1" > $tv/enabled
After this the configuration looks like (only relevant parts shown):
FB0 +-- GFX ---- LCD ---- LCD
\- VID1 ---- TV ---- TV
Misc notes
----------
OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator.
Using DSI DPLL to generate pixel clock it is possible produce the pixel clock
of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI.
Rotation and mirroring currently only supports RGB565 and RGB8888 modes. VRFB
does not support mirroring.
VRFB rotation requires much more memory than non-rotated framebuffer, so you
probably need to increase your vram setting before using VRFB rotation. Also,
many applications may not work with VRFB if they do not pay attention to all
framebuffer parameters.
Kernel boot arguments
---------------------
vram=<size>
- Amount of total VRAM to preallocate. For example, "10M". omapfb
allocates memory for framebuffers from VRAM.
omapfb.mode=<display>:<mode>[,...]
- Default video mode for specified displays. For example,
"dvi:800x400MR-24@60". See drivers/video/modedb.c.
There are also two special modes: "pal" and "ntsc" that
can be used to tv out.
omapfb.vram=<fbnum>:<size>[@<physaddr>][,...]
- VRAM allocated for a framebuffer. Normally omapfb allocates vram
depending on the display size. With this you can manually allocate
more or define the physical address of each framebuffer. For example,
"1:4M" to allocate 4M for fb1.
omapfb.debug=<y|n>
- Enable debug printing. You have to have OMAPFB debug support enabled
in kernel config.
omapfb.test=<y|n>
- Draw test pattern to framebuffer whenever framebuffer settings change.
You need to have OMAPFB debug support enabled in kernel config.
omapfb.vrfb=<y|n>
- Use VRFB rotation for all framebuffers.
omapfb.rotate=<angle>
- Default rotation applied to all framebuffers.
0 - 0 degree rotation
1 - 90 degree rotation
2 - 180 degree rotation
3 - 270 degree rotation
omapfb.mirror=<y|n>
- Default mirror for all framebuffers. Only works with DMA rotation.
omapdss.def_disp=<display>
- Name of default display, to which all overlays will be connected.
Common examples are "lcd" or "tv".
omapdss.debug=<y|n>
- Enable debug printing. You have to have DSS debug support enabled in
kernel config.
TODO
----
DSS locking
Error checking
- Lots of checks are missing or implemented just as BUG()
System DMA update for DSI
- Can be used for RGB16 and RGB24P modes. Probably not for RGB24U (how
to skip the empty byte?)
OMAP1 support
- Not sure if needed
......@@ -55,4 +55,4 @@ Maintainers
This board is maintained by Simtec Electronics.
(c) 2004 Ben Dooks, Simtec Electronics
Copyright 2004 Ben Dooks, Simtec Electronics
......@@ -134,4 +134,4 @@ Authour
Ben Dooks, 03 October 2004
(c) 2004 Ben Dooks, Simtec Electronics
Copyright 2004 Ben Dooks, Simtec Electronics
......@@ -299,4 +299,4 @@ Port Contributors
Document Author
---------------
Ben Dooks, (c) 2004-2005,2006 Simtec Electronics
Ben Dooks, Copyright 2004-2006 Simtec Electronics
......@@ -117,4 +117,4 @@ ATA
Document Author
---------------
Ben Dooks, (c) 2006 Simtec Electronics
Ben Dooks, Copyright 2006 Simtec Electronics
......@@ -18,4 +18,4 @@ Camera Interface
Document Author
---------------
Ben Dooks, (c) 2006 Simtec Electronics
Ben Dooks, Copyright 2006 Simtec Electronics
......@@ -133,5 +133,5 @@ Configuration
Document Author
---------------
Ben Dooks, (c) 2004 Simtec Electronics
Ben Dooks, Copyright 2004 Simtec Electronics
......@@ -90,4 +90,4 @@ Platform Data
Document Author
---------------
Ben Dooks, (c) 2005 Simtec Electronics
Ben Dooks, Copyright 2005 Simtec Electronics
此差异已折叠。
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
version="1.0"
width="210mm"
height="297mm"
viewBox="0 0 21000 29700"
id="svg2"
style="fill-rule:evenodd">
<defs
id="defs4" />
<g
id="Default"
style="visibility:visible">
<desc
id="desc176">Master slide</desc>
</g>
<path
d="M 11999,19601 L 11899,19301 L 12099,19301 L 11999,19601 z"
id="path189"
style="fill:#008000;visibility:visible" />
<path
d="M 11999,18801 L 11999,19361"
id="path193"
style="fill:none;stroke:#008000;visibility:visible" />
<path
d="M 7999,21401 L 7899,21101 L 8099,21101 L 7999,21401 z"
id="path205"
style="fill:#008000;visibility:visible" />
<path
d="M 7999,20601 L 7999,21161"
id="path209"
style="fill:none;stroke:#008000;visibility:visible" />
<path
d="M 11999,18801 L 11685,18840 L 11724,18644 L 11999,18801 z"
id="path221"
style="fill:#008000;visibility:visible" />
<path
d="M 7999,18001 L 11764,18754"
id="path225"
style="fill:none;stroke:#008000;visibility:visible" />
<text
x="-3023.845"
y="1106.8124"
transform="matrix(0.9895258,-0.1443562,0.1443562,0.9895258,0,0)"
id="text243"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="6115.1553 6344.1553 6555.1553 6784.1553 6962.1553 7051.1553 7228.1553 7457.1553 7635.1553 7813.1553 7885.1553"
y="21390.812"
id="tspan245">RSDataReply</tspan>
</text>
<path
d="M 7999,20601 L 8281,20458 L 8311,20655 L 7999,20601 z"
id="path255"
style="fill:#008000;visibility:visible" />
<path
d="M 11999,20001 L 8236,20565"
id="path259"
style="fill:none;stroke:#008000;visibility:visible" />
<text
x="3502.5356"
y="-2184.6621"
transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,0,0)"
id="text277"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="12321.536 12550.536 12761.536 12990.536 13168.536 13257.536 13434.536 13663.536 13841.536 14019.536 14196.536 14374.536 14535.536"
y="15854.338"
id="tspan279">RSDataRequest</tspan>
</text>
<text
id="text293"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="4034 4263 4440 4703 4881 5042 5219 5397 5503 5681 5842 6003 6180 6341 6519 6625 6803 6980 7158 7336 7497 7586 7692"
y="17807"
id="tspan295">w_make_resync_request()</tspan>
</text>
<text
id="text309"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="12199 12305 12483 12644 12821 12893 13054 13232 13410 13638 13816 13905 14083 14311 14489 14667 14845 15023 15184 15272 15378"
y="18806"
id="tspan311">receive_DataRequest()</tspan>
</text>
<text
id="text325"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="12199 12377 12483 12660 12838 13016 13194 13372 13549 13621 13799 13977 14083 14261 14438 14616 14794 14955 15133 15294 15399"
y="19606"
id="tspan327">drbd_endio_read_sec()</tspan>
</text>
<text
id="text341"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="12191 12420 12597 12775 12953 13131 13309 13486 13664 13770 13931 14109 14287 14375 14553 14731 14837 15015 15192 15298"
y="20007"
id="tspan343">w_e_end_rsdata_req()</tspan>
</text>
<text
id="text357"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="4444 4550 4728 4889 5066 5138 5299 5477 5655 5883 6095 6324 6501 6590 6768 6997 7175 7352 7424 7585 7691"
y="20507"
id="tspan359">receive_RSDataReply()</tspan>
</text>
<text
id="text373"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="4457 4635 4741 4918 5096 5274 5452 5630 5807 5879 6057 6235 6464 6569 6641 6730 6908 7086 7247 7425 7585 7691"
y="21407"
id="tspan375">drbd_endio_write_sec()</tspan>
</text>
<text
id="text389"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="4647 4825 5003 5180 5358 5536 5714 5820 5997 6158 6319 6497 6658 6836 7013 7085 7263 7424 7585 7691"
y="21907"
id="tspan391">e_end_resync_block()</tspan>
</text>
<path
d="M 11999,22601 L 11685,22640 L 11724,22444 L 11999,22601 z"
id="path401"
style="fill:#000080;visibility:visible" />
<path
d="M 7999,21801 L 11764,22554"
id="path405"
style="fill:none;stroke:#000080;visibility:visible" />
<text
x="4290.3008"
y="-2369.6162"
transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,0,0)"
id="text423"
style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded">
<tspan
x="13610.301 13911.301 14016.301 14088.301 14177.301 14355.301 14567.301 14728.301"
y="19573.385"
id="tspan425">WriteAck</tspan>
</text>
<text
id="text439"
style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded">
<tspan
x="12199 12377 12555 12644 12821 13033 13105 13283 13444 13604 13816 13977 14138 14244"
y="22559"
id="tspan441">got_BlockAck()</tspan>
</text>
<text
id="text455"
style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="7999 8304 8541 8753 8964 9201 9413 9531 9769 9862 10099 10310 10522 10734 10852 10971 11208 11348 11585 11822"
y="16877"
id="tspan457">Resync blocks, 4-32K</tspan>
</text>
<path
d="M 12000,7601 L 11900,7301 L 12100,7301 L 12000,7601 z"
id="path467"
style="fill:#008000;visibility:visible" />
<path
d="M 12000,6801 L 12000,7361"
id="path471"
style="fill:none;stroke:#008000;visibility:visible" />
<path
d="M 12000,6801 L 11686,6840 L 11725,6644 L 12000,6801 z"
id="path483"
style="fill:#008000;visibility:visible" />
<path
d="M 8000,6001 L 11765,6754"
id="path487"
style="fill:none;stroke:#008000;visibility:visible" />
<text
x="-1288.1796"
y="1279.7666"
transform="matrix(0.9895258,-0.1443562,0.1443562,0.9895258,0,0)"
id="text505"
style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded">
<tspan
x="8174.8208 8475.8203 8580.8203 8652.8203 8741.8203 8919.8203 9131.8203 9292.8203"
y="9516.7666"
id="tspan507">WriteAck</tspan>
</text>
<path
d="M 8000,8601 L 8282,8458 L 8312,8655 L 8000,8601 z"
id="path517"
style="fill:#000080;visibility:visible" />
<path
d="M 12000,8001 L 8237,8565"
id="path521"
style="fill:none;stroke:#000080;visibility:visible" />
<text
x="1065.6655"
y="-2097.7664"
transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,0,0)"
id="text539"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="10682.666 10911.666 11088.666 11177.666"
y="4107.2339"
id="tspan541">Data</tspan>
</text>
<text
id="text555"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="4746 4924 5030 5207 5385 5563 5826 6003 6164 6342 6520 6626 6803 6981 7159 7337 7498 7587 7692"
y="5505"
id="tspan557">drbd_make_request()</tspan>
</text>
<text
id="text571"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="12200 12306 12484 12645 12822 12894 13055 13233 13411 13639 13817 13906 14084 14190"
y="6806"
id="tspan573">receive_Data()</tspan>
</text>
<text
id="text587"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="12200 12378 12484 12661 12839 13017 13195 13373 13550 13622 13800 13978 14207 14312 14384 14473 14651 14829 14990 15168 15328 15434"
y="7606"
id="tspan589">drbd_endio_write_sec()</tspan>
</text>
<text
id="text603"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="12192 12370 12548 12725 12903 13081 13259 13437 13509 13686 13847 14008 14114"
y="8007"
id="tspan605">e_end_block()</tspan>
</text>
<text
id="text619"
style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded">
<tspan
x="5647 5825 6003 6092 6269 6481 6553 6731 6892 7052 7264 7425 7586 7692"
y="8606"
id="tspan621">got_BlockAck()</tspan>
</text>
<text
id="text635"
style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="8000 8305 8542 8779 9016 9109 9346 9486 9604 9956 10049 10189 10328 10565 10705 10942 11179 11298 11603 11742 11835 11954 12191 12310 12428 12665 12902 13139 13279 13516 13753"
y="4877"
id="tspan637">Regular mirrored write, 512-32K</tspan>
</text>
<text
id="text651"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="5381 5610 5787 5948 6126 6304 6482 6659 6837 7015 7087 7265 7426 7587 7692"
y="6003"
id="tspan653">w_send_dblock()</tspan>
</text>
<path
d="M 8000,6800 L 7900,6500 L 8100,6500 L 8000,6800 z"
id="path663"
style="fill:#008000;visibility:visible" />
<path
d="M 8000,6000 L 8000,6560"
id="path667"
style="fill:none;stroke:#008000;visibility:visible" />
<text
id="text683"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="4602 4780 4886 5063 5241 5419 5597 5775 5952 6024 6202 6380 6609 6714 6786 6875 7053 7231 7409 7515 7587 7692"
y="6905"
id="tspan685">drbd_endio_write_pri()</tspan>
</text>
<path
d="M 12000,13602 L 11900,13302 L 12100,13302 L 12000,13602 z"
id="path695"
style="fill:#008000;visibility:visible" />
<path
d="M 12000,12802 L 12000,13362"
id="path699"
style="fill:none;stroke:#008000;visibility:visible" />
<path
d="M 12000,12802 L 11686,12841 L 11725,12645 L 12000,12802 z"
id="path711"
style="fill:#008000;visibility:visible" />
<path
d="M 8000,12002 L 11765,12755"
id="path715"
style="fill:none;stroke:#008000;visibility:visible" />
<text
x="-2155.5266"
y="1201.5964"
transform="matrix(0.9895258,-0.1443562,0.1443562,0.9895258,0,0)"
id="text733"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="7202.4736 7431.4736 7608.4736 7697.4736 7875.4736 8104.4736 8282.4736 8459.4736 8531.4736"
y="15454.597"
id="tspan735">DataReply</tspan>
</text>
<path
d="M 8000,14602 L 8282,14459 L 8312,14656 L 8000,14602 z"
id="path745"
style="fill:#008000;visibility:visible" />
<path
d="M 12000,14002 L 8237,14566"
id="path749"
style="fill:none;stroke:#008000;visibility:visible" />
<text
x="2280.3804"
y="-2103.2141"
transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,0,0)"
id="text767"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="11316.381 11545.381 11722.381 11811.381 11989.381 12218.381 12396.381 12573.381 12751.381 12929.381 13090.381"
y="9981.7861"
id="tspan769">DataRequest</tspan>
</text>
<text
id="text783"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="4746 4924 5030 5207 5385 5563 5826 6003 6164 6342 6520 6626 6803 6981 7159 7337 7498 7587 7692"
y="11506"
id="tspan785">drbd_make_request()</tspan>
</text>
<text
id="text799"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="12200 12306 12484 12645 12822 12894 13055 13233 13411 13639 13817 13906 14084 14312 14490 14668 14846 15024 15185 15273 15379"
y="12807"
id="tspan801">receive_DataRequest()</tspan>
</text>
<text
id="text815"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="12200 12378 12484 12661 12839 13017 13195 13373 13550 13622 13800 13978 14084 14262 14439 14617 14795 14956 15134 15295 15400"
y="13607"
id="tspan817">drbd_endio_read_sec()</tspan>
</text>
<text
id="text831"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="12192 12421 12598 12776 12954 13132 13310 13487 13665 13843 14021 14110 14288 14465 14571 14749 14927 15033"
y="14008"
id="tspan833">w_e_end_data_req()</tspan>
</text>
<g
id="g835"
style="visibility:visible">
<desc
id="desc837">Drawing</desc>
<text
id="text847"
style="font-size:318px;font-weight:400;fill:#008000;font-family:Helvetica embedded">
<tspan
x="4885 4991 5169 5330 5507 5579 5740 5918 6096 6324 6502 6591 6769 6997 7175 7353 7425 7586 7692"
y="14607"
id="tspan849">receive_DataReply()</tspan>
</text>
</g>
<text
id="text863"
style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="8000 8305 8398 8610 8821 8914 9151 9363 9575 9693 9833 10070 10307 10544 10663 10781 11018 11255 11493 11632 11869 12106"
y="10878"
id="tspan865">Diskless read, 512-32K</tspan>
</text>
<text
id="text879"
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="5029 5258 5435 5596 5774 5952 6130 6307 6413 6591 6769 6947 7125 7230 7408 7586 7692"
y="12004"
id="tspan881">w_send_read_req()</tspan>
</text>
<text
id="text895"
style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="6961 7266 7571 7854 8159 8278 8515 8633 8870 9107 9226 9463 9581 9700 9793 10030"
y="2806"
id="tspan897">DRBD 8 data flow</tspan>
</text>
<path
d="M 3900,5300 L 3700,5300 L 3700,7000 L 3900,7000"
id="path907"
style="fill:none;stroke:#000000;visibility:visible" />
<path
d="M 3900,17600 L 3700,17600 L 3700,22000 L 3900,22000"
id="path919"
style="fill:none;stroke:#000000;visibility:visible" />
<path
d="M 16100,20000 L 16300,20000 L 16300,18500 L 16100,18500"
id="path931"
style="fill:none;stroke:#000000;visibility:visible" />
<text
id="text947"
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="2126 2304 2376 2554 2731 2909 3087 3159 3337 3515 3587 3764 3870"
y="5202"
id="tspan949">al_begin_io()</tspan>
</text>
<text
id="text963"
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="1632 1810 1882 2060 2220 2398 2661 2839 2910 3088 3177 3355 3533 3605 3783 3888"
y="7331"
id="tspan965">al_complete_io()</tspan>
</text>
<text
id="text979"
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="2126 2232 2393 2571 2748 2926 3104 3176 3354 3531 3603 3781 3887"
y="17431"
id="tspan981">rs_begin_io()</tspan>
</text>
<text
id="text995"
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="1626 1732 1893 2071 2231 2409 2672 2849 2921 3099 3188 3366 3544 3616 3793 3899"
y="22331"
id="tspan997">rs_complete_io()</tspan>
</text>
<text
id="text1011"
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="16027 16133 16294 16472 16649 16827 17005 17077 17255 17432 17504 17682 17788"
y="18402"
id="tspan1013">rs_begin_io()</tspan>
</text>
<text
id="text1027"
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
<tspan
x="16115 16221 16382 16560 16720 16898 17161 17338 17410 17588 17677 17855 18033 18105 18282 18388"
y="20331"
id="tspan1029">rs_complete_io()</tspan>
</text>
</svg>
Description
DRBD is a shared-nothing, synchronously replicated block device. It
is designed to serve as a building block for high availability
clusters and in this context, is a "drop-in" replacement for shared
storage. Simplistically, you could see it as a network RAID 1.
Please visit http://www.drbd.org to find out more.
The here included files are intended to help understand the implementation
DRBD-8.3-data-packets.svg, DRBD-data-packets.svg
relates some functions, and write packets.
conn-states-8.dot, disk-states-8.dot, node-states-8.dot
The sub graphs of DRBD's state transitions
digraph conn_states {
StandAllone -> WFConnection [ label = "ioctl_set_net()" ]
WFConnection -> Unconnected [ label = "unable to bind()" ]
WFConnection -> WFReportParams [ label = "in connect() after accept" ]
WFReportParams -> StandAllone [ label = "checks in receive_param()" ]
WFReportParams -> Connected [ label = "in receive_param()" ]
WFReportParams -> WFBitMapS [ label = "sync_handshake()" ]
WFReportParams -> WFBitMapT [ label = "sync_handshake()" ]
WFBitMapS -> SyncSource [ label = "receive_bitmap()" ]
WFBitMapT -> SyncTarget [ label = "receive_bitmap()" ]
SyncSource -> Connected
SyncTarget -> Connected
SyncSource -> PausedSyncS
SyncTarget -> PausedSyncT
PausedSyncS -> SyncSource
PausedSyncT -> SyncTarget
Connected -> WFConnection [ label = "* on network error" ]
}
digraph disk_states {
Diskless -> Inconsistent [ label = "ioctl_set_disk()" ]
Diskless -> Consistent [ label = "ioctl_set_disk()" ]
Diskless -> Outdated [ label = "ioctl_set_disk()" ]
Consistent -> Outdated [ label = "receive_param()" ]
Consistent -> UpToDate [ label = "receive_param()" ]
Consistent -> Inconsistent [ label = "start resync" ]
Outdated -> Inconsistent [ label = "start resync" ]
UpToDate -> Inconsistent [ label = "ioctl_replicate" ]
Inconsistent -> UpToDate [ label = "resync completed" ]
Consistent -> Failed [ label = "io completion error" ]
Outdated -> Failed [ label = "io completion error" ]
UpToDate -> Failed [ label = "io completion error" ]
Inconsistent -> Failed [ label = "io completion error" ]
Failed -> Diskless [ label = "sending notify to peer" ]
}
// vim: set sw=2 sts=2 :
digraph {
rankdir=BT
bgcolor=white
node [shape=plaintext]
node [fontcolor=black]
StandAlone [ style=filled,fillcolor=gray,label=StandAlone ]
node [fontcolor=lightgray]
Unconnected [ label=Unconnected ]
CommTrouble [ shape=record,
label="{communication loss|{Timeout|BrokenPipe|NetworkFailure}}" ]
node [fontcolor=gray]
subgraph cluster_try_connect {
label="try to connect, handshake"
rank=max
WFConnection [ label=WFConnection ]
WFReportParams [ label=WFReportParams ]
}
TearDown [ label=TearDown ]
Connected [ label=Connected,style=filled,fillcolor=green,fontcolor=black ]
node [fontcolor=lightblue]
StartingSyncS [ label=StartingSyncS ]
StartingSyncT [ label=StartingSyncT ]
subgraph cluster_bitmap_exchange {
node [fontcolor=red]
fontcolor=red
label="new application (WRITE?) requests blocked\lwhile bitmap is exchanged"
WFBitMapT [ label=WFBitMapT ]
WFSyncUUID [ label=WFSyncUUID ]
WFBitMapS [ label=WFBitMapS ]
}
node [fontcolor=blue]
cluster_resync [ shape=record,label="{<any>resynchronisation process running\l'concurrent' application requests allowed|{{<T>PausedSyncT\nSyncTarget}|{<S>PausedSyncS\nSyncSource}}}" ]
node [shape=box,fontcolor=black]
// drbdadm [label="drbdadm connect"]
// handshake [label="drbd_connect()\ndrbd_do_handshake\ndrbd_sync_handshake() etc."]
// comm_error [label="communication trouble"]
//
// edges
// --------------------------------------
StandAlone -> Unconnected [ label="drbdadm connect" ]
Unconnected -> StandAlone [ label="drbdadm disconnect\lor serious communication trouble" ]
Unconnected -> WFConnection [ label="receiver thread is started" ]
WFConnection -> WFReportParams [ headlabel="accept()\land/or \lconnect()\l" ]
WFReportParams -> StandAlone [ label="during handshake\lpeers do not agree\labout something essential" ]
WFReportParams -> Connected [ label="data identical\lno sync needed",color=green,fontcolor=green ]
WFReportParams -> WFBitMapS
WFReportParams -> WFBitMapT
WFBitMapT -> WFSyncUUID [minlen=0.1,constraint=false]
WFBitMapS -> cluster_resync:S
WFSyncUUID -> cluster_resync:T
edge [color=green]
cluster_resync:any -> Connected [ label="resnyc done",fontcolor=green ]
edge [color=red]
WFReportParams -> CommTrouble
Connected -> CommTrouble
cluster_resync:any -> CommTrouble
edge [color=black]
CommTrouble -> Unconnected [label="receiver thread is stopped" ]
}
digraph node_states {
Secondary -> Primary [ label = "ioctl_set_state()" ]
Primary -> Secondary [ label = "ioctl_set_state()" ]
}
digraph peer_states {
Secondary -> Primary [ label = "recv state packet" ]
Primary -> Secondary [ label = "recv state packet" ]
Primary -> Unknown [ label = "connection lost" ]
Secondary -> Unknown [ label = "connection lost" ]
Unknown -> Primary [ label = "connected" ]
Unknown -> Secondary [ label = "connected" ]
}
Block IO Controller
===================
Overview
========
cgroup subsys "blkio" implements the block io controller. There seems to be
a need of various kinds of IO control policies (like proportional BW, max BW)
both at leaf nodes as well as at intermediate nodes in a storage hierarchy.
Plan is to use the same cgroup based management interface for blkio controller
and based on user options switch IO policies in the background.
In the first phase, this patchset implements proportional weight time based
division of disk policy. It is implemented in CFQ. Hence this policy takes
effect only on leaf nodes when CFQ is being used.
HOWTO
=====
You can do a very simple testing of running two dd threads in two different
cgroups. Here is what you can do.
- Enable group scheduling in CFQ
CONFIG_CFQ_GROUP_IOSCHED=y
- Compile and boot into kernel and mount IO controller (blkio).
mount -t cgroup -o blkio none /cgroup
- Create two cgroups
mkdir -p /cgroup/test1/ /cgroup/test2
- Set weights of group test1 and test2
echo 1000 > /cgroup/test1/blkio.weight
echo 500 > /cgroup/test2/blkio.weight
- Create two same size files (say 512MB each) on same disk (file1, file2) and
launch two dd threads in different cgroup to read those files.
sync
echo 3 > /proc/sys/vm/drop_caches
dd if=/mnt/sdb/zerofile1 of=/dev/null &
echo $! > /cgroup/test1/tasks
cat /cgroup/test1/tasks
dd if=/mnt/sdb/zerofile2 of=/dev/null &
echo $! > /cgroup/test2/tasks
cat /cgroup/test2/tasks
- At macro level, first dd should finish first. To get more precise data, keep
on looking at (with the help of script), at blkio.disk_time and
blkio.disk_sectors files of both test1 and test2 groups. This will tell how
much disk time (in milli seconds), each group got and how many secotors each
group dispatched to the disk. We provide fairness in terms of disk time, so
ideally io.disk_time of cgroups should be in proportion to the weight.
Various user visible config options
===================================
CONFIG_CFQ_GROUP_IOSCHED
- Enables group scheduling in CFQ. Currently only 1 level of group
creation is allowed.
CONFIG_DEBUG_CFQ_IOSCHED
- Enables some debugging messages in blktrace. Also creates extra
cgroup file blkio.dequeue.
Config options selected automatically
=====================================
These config options are not user visible and are selected/deselected
automatically based on IO scheduler configuration.
CONFIG_BLK_CGROUP
- Block IO controller. Selected by CONFIG_CFQ_GROUP_IOSCHED.
CONFIG_DEBUG_BLK_CGROUP
- Debug help. Selected by CONFIG_DEBUG_CFQ_IOSCHED.
Details of cgroup files
=======================
- blkio.weight
- Specifies per cgroup weight.
Currently allowed range of weights is from 100 to 1000.
- blkio.time
- disk time allocated to cgroup per device in milliseconds. First
two fields specify the major and minor number of the device and
third field specifies the disk time allocated to group in
milliseconds.
- blkio.sectors
- number of sectors transferred to/from disk by the group. First
two fields specify the major and minor number of the device and
third field specifies the number of sectors transferred by the
group to/from the device.
- blkio.dequeue
- Debugging aid only enabled if CONFIG_DEBUG_CFQ_IOSCHED=y. This
gives the statistics about how many a times a group was dequeued
from service tree of the device. First two fields specify the major
and minor number of the device and third field specifies the number
of times a group was dequeued from a particular device.
CFQ sysfs tunable
=================
/sys/block/<disk>/queue/iosched/group_isolation
If group_isolation=1, it provides stronger isolation between groups at the
expense of throughput. By default group_isolation is 0. In general that
means that if group_isolation=0, expect fairness for sequential workload
only. Set group_isolation=1 to see fairness for random IO workload also.
Generally CFQ will put random seeky workload in sync-noidle category. CFQ
will disable idling on these queues and it does a collective idling on group
of such queues. Generally these are slow moving queues and if there is a
sync-noidle service tree in each group, that group gets exclusive access to
disk for certain period. That means it will bring the throughput down if
group does not have enough IO to drive deeper queue depths and utilize disk
capacity to the fullest in the slice allocated to it. But the flip side is
that even a random reader should get better latencies and overall throughput
if there are lots of sequential readers/sync-idle workload running in the
system.
If group_isolation=0, then CFQ automatically moves all the random seeky queues
in the root group. That means there will be no service differentiation for
that kind of workload. This leads to better throughput as we do collective
idling on root sync-noidle tree.
By default one should run with group_isolation=0. If that is not sufficient
and one wants stronger isolation between groups, then set group_isolation=1
but this will come at cost of reduced throughput.
What works
==========
- Currently only sync IO queues are support. All the buffered writes are
still system wide and not per group. Hence we will not see service
differentiation between buffered writes between groups.
......@@ -92,9 +92,9 @@ policy->cpuinfo.max_freq - the minimum and maximum frequency
(in kHz) which is supported by
this CPU
policy->cpuinfo.transition_latency the time it takes on this CPU to
switch between two frequencies (if
appropriate, else specify
CPUFREQ_ETERNAL)
switch between two frequencies in
nanoseconds (if appropriate, else
specify CPUFREQ_ETERNAL)
policy->cur The current operating frequency of
this CPU (if appropriate)
......
......@@ -203,6 +203,17 @@ scaling_cur_freq : Current frequency of the CPU as determined by
the frequency the kernel thinks the CPU runs
at.
bios_limit : If the BIOS tells the OS to limit a CPU to
lower frequencies, the user can read out the
maximum available frequency from this file.
This typically can happen through (often not
intended) BIOS settings, restrictions
triggered through a service processor or other
BIOS/HW based implementations.
This does not cover thermal ACPI limitations
which can be detected through the generic
thermal driver.
If you have selected the "userspace" governor which allows you to
set the CPU operating frequency to a specific value, you can read out
the current frequency in
......
......@@ -49,6 +49,12 @@ maxcpus=n Restrict boot time cpus to n. Say if you have 4 cpus, using
additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets
cpu_possible_map = cpu_present_map + additional_cpus
cede_offline={"off","on"} Use this option to disable/enable putting offlined
processors to an extended H_CEDE state on
supported pseries platforms.
If nothing is specified,
cede_offline is set to "on".
(*) Option valid only for following architectures
- ia64
......
......@@ -65,6 +65,7 @@ aicdb.h*
asm-offsets.h
asm_offsets.h
autoconf.h*
av_permissions.h
bbootsect
bin2c
binkernel.spec
......@@ -95,12 +96,14 @@ docproc
elf2ecoff
elfconfig.h*
fixdep
flask.h
fore200e_mkfirm
fore200e_pca_fw.c*
gconf
gen-devlist
gen_crc32table
gen_init_cpio
genheaders
genksyms
*_gray256.c
ihex2fw
......
......@@ -85,7 +85,7 @@ http://www.linuxtv.org/wiki/index.php/DVB_USB
- moved transfer control (pid filter, fifo control) from usb driver to frontend, it seems
better settled there (added xfer_ops-struct)
- created a common files for frontends (mc/p/mb)
2004-09-28 - added support for a new device (Unkown, vendor ID is Hyper-Paltek)
2004-09-28 - added support for a new device (Unknown, vendor ID is Hyper-Paltek)
2004-09-20 - added support for a new device (Compro DVB-U2000), thanks
to Amaury Demol for reporting
- changed usb TS transfer method (several urbs, stopping transfer
......
......@@ -80,7 +80,7 @@ is:
broken_parity_status
as is located in /sys/devices/pci<XXX>/0000:XX:YY.Z directorys for
as is located in /sys/devices/pci<XXX>/0000:XX:YY.Z directories for
PCI devices.
FUTURE HARDWARE SCANNING
......@@ -288,9 +288,8 @@ Total UE count that had no information attribute fileY:
'ue_noinfo_count'
This attribute file displays the number of UEs that
have occurred have occurred with no informations as to which DIMM
slot is having errors.
This attribute file displays the number of UEs that have occurred
with no information as to which DIMM slot is having errors.
Total Correctable Errors count attribute file:
......
......@@ -6,6 +6,21 @@ be removed from this file.
---------------------------
What: USER_SCHED
When: 2.6.34
Why: USER_SCHED was implemented as a proof of concept for group scheduling.
The effect of USER_SCHED can already be achieved from userspace with
the help of libcgroup. The removal of USER_SCHED will also simplify
the scheduler code with the removal of one major ifdef. There are also
issues USER_SCHED has with USER_NS. A decision was taken not to fix
those and instead remove USER_SCHED. Also new group scheduling
features will not be implemented for USER_SCHED.
Who: Dhaval Giani <dhaval@linux.vnet.ibm.com>
---------------------------
What: PRISM54
When: 2.6.34
......@@ -276,13 +291,6 @@ Who: Michael Buesch <mb@bu3sch.de>
---------------------------
What: usedac i386 kernel parameter
When: 2.6.27
Why: replaced by allowdac and no dac combination
Who: Glauber Costa <gcosta@redhat.com>
---------------------------
What: print_fn_descriptor_symbol()
When: October 2009
Why: The %pF vsprintf format provides the same functionality in a
......@@ -302,18 +310,6 @@ Who: ocfs2-devel@oss.oracle.com
---------------------------
What: SCTP_GET_PEER_ADDRS_NUM_OLD, SCTP_GET_PEER_ADDRS_OLD,
SCTP_GET_LOCAL_ADDRS_NUM_OLD, SCTP_GET_LOCAL_ADDRS_OLD
When: June 2009
Why: A newer version of the options have been introduced in 2005 that
removes the limitions of the old API. The sctp library has been
converted to use these new options at the same time. Any user
space app that directly uses the old options should convert to using
the new options.
Who: Vlad Yasevich <vladislav.yasevich@hp.com>
---------------------------
What: Ability for non root users to shm_get hugetlb pages based on mlock
resource limits
When: 2.6.31
......@@ -404,15 +400,6 @@ Who: Alex Chiang <achiang@hp.com>
---------------------------
What: i2c-voodoo3 driver
When: October 2009
Why: Superseded by tdfxfb. I2C/DDC support used to live in a separate
driver but this caused driver conflicts.
Who: Jean Delvare <khali@linux-fr.org>
Krzysztof Helt <krzysztof.h1@wp.pl>
---------------------------
What: CONFIG_RFKILL_INPUT
When: 2.6.33
Why: Should be implemented in userspace, policy daemon.
......@@ -489,3 +476,10 @@ Why: With the recent innovations in CPU hardware acceleration technologies
Who: Alok N Kataria <akataria@vmware.com>
----------------------------
What: adt7473 hardware monitoring driver
When: February 2010
Why: Obsoleted by the adt7475 driver.
Who: Jean Delvare <khali@linux-fr.org>
---------------------------
......@@ -36,6 +36,8 @@ dnotify.txt
- info about directory notification in Linux.
ecryptfs.txt
- docs on eCryptfs: stacked cryptographic filesystem for Linux.
exofs.txt
- info, usage, mount options, design about EXOFS.
ext2.txt
- info, mount options and specifications for the Ext2 filesystem.
ext3.txt
......
......@@ -60,13 +60,13 @@ USAGE
mkfs.exofs --pid=65536 --format /dev/osd0
The --format is optional if not specified no OSD_FORMAT will be
preformed and a clean file system will be created in the specified pid,
The --format is optional. If not specified, no OSD_FORMAT will be
performed and a clean file system will be created in the specified pid,
in the available space of the target. (Use --format=size_in_meg to limit
the total LUN space available)
If pid already exist it will be deleted and a new one will be created in it's
place. Be careful.
If pid already exists, it will be deleted and a new one will be created in
its place. Be careful.
An exofs lives inside a single OSD partition. You can create multiple exofs
filesystems on the same device using multiple pids.
......@@ -81,7 +81,7 @@ USAGE
7. For reference (See do-exofs example script):
do-exofs start - an example of how to perform the above steps.
do-exofs stop - an example of how to unmount the file system.
do-exofs stop - an example of how to unmount the file system.
do-exofs format - an example of how to format and mkfs a new exofs.
8. Extra compilation flags (uncomment in fs/exofs/Kbuild):
......@@ -104,8 +104,8 @@ Where:
exofs specific options: Options are separated by commas (,)
pid=<integer> - The partition number to mount/create as
container of the filesystem.
This option is mandatory
to=<integer> - Timeout in ticks for a single command
This option is mandatory.
to=<integer> - Timeout in ticks for a single command.
default is (60 * HZ) [for debugging only]
===============================================================================
......@@ -116,7 +116,7 @@ DESIGN
with a special ID (defined in common.h).
Information included in the file system control block is used to fill the
in-memory superblock structure at mount time. This object is created before
the file system is used by mkexofs.c It contains information such as:
the file system is used by mkexofs.c. It contains information such as:
- The file system's magic number
- The next inode number to be allocated
......@@ -134,8 +134,8 @@ DESIGN
attributes. This applies to both regular files and other types (directories,
device files, symlinks, etc.).
* Credentials are generated per object (inode and superblock) when they is
created in memory (read off disk or created). The credential works for all
* Credentials are generated per object (inode and superblock) when they are
created in memory (read from disk or created). The credential works for all
operations and is used as long as the object remains in memory.
* Async OSD operations are used whenever possible, but the target may execute
......@@ -145,7 +145,8 @@ DESIGN
from executing in reverse order:
- The following are handled with the OBJ_CREATED and OBJ_2BCREATED
flags. OBJ_CREATED is set when we know the object exists on the OSD -
in create's callback function, and when we successfully do a read_inode.
in create's callback function, and when we successfully do a
read_inode.
OBJ_2BCREATED is set in the beginning of the create function, so we
know that we should wait.
- create/delete: delete should wait until the object is created
......
......@@ -32,8 +32,8 @@ journal_dev=devnum When the external journal device's major/minor numbers
identified through its new major/minor numbers encoded
in devnum.
noload Don't load the journal on mounting. Note that this forces
mount of inconsistent filesystem, which can lead to
norecovery Don't load the journal on mounting. Note that this forces
noload mount of inconsistent filesystem, which can lead to
various problems.
data=journal All data are committed into the journal prior to being
......
......@@ -153,8 +153,8 @@ journal_dev=devnum When the external journal device's major/minor numbers
identified through its new major/minor numbers encoded
in devnum.
noload Don't load the journal on mounting. Note that
if the filesystem was not unmounted cleanly,
norecovery Don't load the journal on mounting. Note that
noload if the filesystem was not unmounted cleanly,
skipping the journal replay will lead to the
filesystem containing inconsistencies that can
lead to any number of problems.
......@@ -353,6 +353,12 @@ noauto_da_alloc replacing existing files via patterns such as
system crashes before the delayed allocation
blocks are forced to disk.
discard Controls whether ext4 should issue discard/TRIM
nodiscard(*) commands to the underlying block device when
blocks are freed. This is useful for SSD devices
and sparse/thinly-provisioned LUNs, but it is off
by default until sufficient testing has been done.
Data Mode
=========
There are 3 different data modes:
......
......@@ -49,8 +49,7 @@ Mount options
NILFS2 supports the following mount options:
(*) == default
barrier=on(*) This enables/disables barriers. barrier=off disables
it, barrier=on enables it.
nobarrier Disables barriers.
errors=continue(*) Keep going on a filesystem error.
errors=remount-ro Remount the filesystem read-only on an error.
errors=panic Panic and halt the machine if an error occurs.
......@@ -71,6 +70,10 @@ order=strict Apply strict in-order semantics that preserves sequence
blocks. That means, it is guaranteed that no
overtaking of events occurs in the recovered file
system after a crash.
norecovery Disable recovery of the filesystem on mount.
This disables every write access on the device for
read-only mounts or snapshots. This option will fail
for r/w mounts on an unclean volume.
NILFS2 usage
============
......
......@@ -1072,7 +1072,8 @@ second). The meanings of the columns are as follows, from left to right:
- irq: servicing interrupts
- softirq: servicing softirqs
- steal: involuntary wait
- guest: running a guest
- guest: running a normal guest
- guest_nice: running a niced guest
The "intr" line gives counts of interrupts serviced since boot time, for each
of the possible system interrupts. The first column is the total of all
......@@ -1088,8 +1089,8 @@ The "processes" line gives the number of processes and threads created, which
includes (but is not limited to) those created by calls to the fork() and
clone() system calls.
The "procs_running" line gives the number of processes currently running on
CPUs.
The "procs_running" line gives the total number of threads that are
running or ready to run (i.e., the total number of runnable threads).
The "procs_blocked" line gives the number of processes currently blocked,
waiting for I/O to complete.
......
......@@ -472,7 +472,7 @@ __sync_single_inode) to check if ->writepages has been successful in
writing out the whole address_space.
The Writeback tag is used by filemap*wait* and sync_page* functions,
via wait_on_page_writeback_range, to wait for all writeback to
via filemap_fdatawait_range, to wait for all writeback to
complete. While waiting ->sync_page (if defined) will be called on
each page that is found to require writeback.
......
......@@ -380,7 +380,7 @@ rare; use gpiochip_remove() when it is unavoidable.
Most often a gpio_chip is part of an instance-specific structure with state
not exposed by the GPIO interfaces, such as addressing, power management,
and more. Chips such as codecs will have complex non-GPIO state,
and more. Chips such as codecs will have complex non-GPIO state.
Any debugfs dump method should normally ignore signals which haven't been
requested as GPIOs. They can use gpiochip_is_requested(), which returns
......@@ -531,7 +531,7 @@ and have the following read/write attributes:
This file exists only if the pin can be configured as an
interrupt generating input pin.
GPIO controllers have paths like /sys/class/gpio/chipchip42/ (for the
GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the
controller implementing GPIOs starting at #42) and have the following
read-only attributes:
......
......@@ -9,6 +9,8 @@ Supported chips:
Author: Darrick J. Wong
This driver is depreacted, please use the adt7475 driver instead.
Description
-----------
......
This describes the interface for the ADT7475 driver:
(there are 4 fans, numbered fan1 to fan4):
fanX_input Read the current speed of the fan (in RPMs)
fanX_min Read/write the minimum speed of the fan. Dropping
below this sets an alarm.
(there are three PWMs, numbered pwm1 to pwm3):
pwmX Read/write the current duty cycle of the PWM. Writes
only have effect when auto mode is turned off (see
below). Range is 0 - 255.
pwmX_enable Fan speed control method:
0 - No control (fan at full speed)
1 - Manual fan speed control (using pwm[1-*])
2 - Automatic fan speed control
pwmX_auto_channels_temp Select which channels affect this PWM
1 - TEMP1 controls PWM
2 - TEMP2 controls PWM
4 - TEMP3 controls PWM
6 - TEMP2 and TEMP3 control PWM
7 - All three inputs control PWM
pwmX_freq Read/write the PWM frequency in Hz. The number
should be one of the following:
11 Hz
14 Hz
22 Hz
29 Hz
35 Hz
44 Hz
58 Hz
88 Hz
pwmX_auto_point1_pwm Read/write the minimum PWM duty cycle in automatic mode
pwmX_auto_point2_pwm Read/write the maximum PWM duty cycle in automatic mode
(there are three temperature settings numbered temp1 to temp3):
tempX_input Read the current temperature. The value is in milli
degrees of Celsius.
tempX_max Read/write the upper temperature limit - exceeding this
will cause an alarm.
tempX_min Read/write the lower temperature limit - exceeding this
will cause an alarm.
tempX_offset Read/write the temperature adjustment offset
tempX_crit Read/write the THERM limit for remote1.
tempX_crit_hyst Set the temperature value below crit where the
fans will stay on - this helps drive the temperature
low enough so it doesn't stay near the edge and
cause THERM to keep tripping.
tempX_auto_point1_temp Read/write the minimum temperature where the fans will
turn on in automatic mode.
tempX_auto_point2_temp Read/write the maximum temperature over which the fans
will run in automatic mode. tempX_auto_point1_temp
and tempX_auto_point2_temp together define the
range of automatic control.
tempX_alarm Read a 1 if the max/min alarm is set
tempX_fault Read a 1 if either temp1 or temp3 diode has a fault
(There are two voltage settings, in1 and in2):
inX_input Read the current voltage on VCC. Value is in
millivolts.
inX_min read/write the minimum voltage limit.
Dropping below this causes an alarm.
inX_max read/write the maximum voltage limit.
Exceeding this causes an alarm.
inX_alarm Read a 1 if the max/min alarm is set.
Kernel driver adt7475
=====================
Supported chips:
* Analog Devices ADT7473
Prefix: 'adt7473'
Addresses scanned: I2C 0x2C, 0x2D, 0x2E
Datasheet: Publicly available at the On Semiconductors website
* Analog Devices ADT7475
Prefix: 'adt7475'
Addresses scanned: I2C 0x2E
Datasheet: Publicly available at the On Semiconductors website
* Analog Devices ADT7476
Prefix: 'adt7476'
Addresses scanned: I2C 0x2C, 0x2D, 0x2E
Datasheet: Publicly available at the On Semiconductors website
* Analog Devices ADT7490
Prefix: 'adt7490'
Addresses scanned: I2C 0x2C, 0x2D, 0x2E
Datasheet: Publicly available at the On Semiconductors website
Authors:
Jordan Crouse
Hans de Goede
Darrick J. Wong (documentation)
Jean Delvare
Description
-----------
This driver implements support for the Analog Devices ADT7473, ADT7475,
ADT7476 and ADT7490 chip family. The ADT7473 and ADT7475 differ only in
minor details. The ADT7476 has additional features, including extra voltage
measurement inputs and VID support. The ADT7490 also has additional
features, including extra voltage measurement inputs and PECI support. All
the supported chips will be collectively designed by the name "ADT747x" in
the rest of this document.
The ADT747x uses the 2-wire interface compatible with the SMBus 2.0
specification. Using an analog to digital converter it measures three (3)
temperatures and two (2) or more voltages. It has four (4) 16-bit counters
for measuring fan speed. There are three (3) PWM outputs that can be used
to control fan speed.
A sophisticated control system for the PWM outputs is designed into the
ADT747x that allows fan speed to be adjusted automatically based on any of the
three temperature sensors. Each PWM output is individually adjustable and
programmable. Once configured, the ADT747x will adjust the PWM outputs in
response to the measured temperatures without further host intervention.
This feature can also be disabled for manual control of the PWM's.
Each of the measured inputs (voltage, temperature, fan speed) has
corresponding high/low limit values. The ADT747x will signal an ALARM if
any measured value exceeds either limit.
The ADT747x samples all inputs continuously. The driver will not read
the registers more often than once every other second. Further,
configuration data is only read once per minute.
Chip Differences Summary
------------------------
ADT7473:
* 2 voltage inputs
* system acoustics optimizations (not implemented)
ADT7475:
* 2 voltage inputs
ADT7476:
* 5 voltage inputs
* VID support
ADT7490:
* 6 voltage inputs
* 1 Imon input (not implemented)
* PECI support (not implemented)
* 2 GPIO pins (not implemented)
* system acoustics optimizations (not implemented)
Special Features
----------------
The ADT747x has a 10-bit ADC and can therefore measure temperatures
with a resolution of 0.25 degree Celsius. Temperature readings can be
configured either for two's complement format or "Offset 64" format,
wherein 64 is subtracted from the raw value to get the temperature value.
The datasheet is very detailed and describes a procedure for determining
an optimal configuration for the automatic PWM control.
Fan Speed Control
-----------------
The driver exposes two trip points per PWM channel.
point1: Set the PWM speed at the lower temperature bound
point2: Set the PWM speed at the higher temperature bound
The ADT747x will scale the PWM linearly between the lower and higher PWM
speed when the temperature is between the two temperature boundaries.
Temperature boundaries are associated to temperature channels rather than
PWM outputs, and a given PWM output can be controlled by several temperature
channels. As a result, the ADT747x may compute more than one PWM value
for a channel at a given time, in which case the maximum value (fastest
fan speed) is applied. PWM values range from 0 (off) to 255 (full speed).
Fan speed may be set to maximum when the temperature sensor associated with
the PWM control exceeds temp#_max.
Notes
-----
The nVidia binary driver presents an ADT7473 chip via an on-card i2c bus.
Unfortunately, they fail to set the i2c adapter class, so this driver may
fail to find the chip until the nvidia driver is patched.
......@@ -14,6 +14,10 @@ Supported chips:
Prefix: 'f71882fg'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Available from the Fintek website
* Fintek F71889FG
Prefix: 'f71889fg'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Should become available on the Fintek website soon
* Fintek F8000
Prefix: 'f8000'
Addresses scanned: none, address read from Super I/O config space
......@@ -51,6 +55,12 @@ supported. The right one to use depends on external circuitry on the
motherboard, so the driver assumes that the BIOS set the method
properly.
Note that the lowest numbered temperature zone trip point corresponds to
to the border between the highest and one but highest temperature zones, and
vica versa. So the temperature zone trip points 1-4 (or 1-2) go from high temp
to low temp! This is how things are implemented in the IC, and the driver
mimicks this.
There are 2 modes to specify the speed of the fan, PWM duty cycle (or DC
voltage) mode, where 0-100% duty cycle (0-100% of 12V) is specified. And RPM
mode where the actual RPM of the fan (as measured) is controlled and the speed
......
......@@ -86,7 +86,6 @@ The IT8712F and IT8716F additionally feature VID inputs, used to report
the Vcore voltage of the processor. The early IT8712F have 5 VID pins,
the IT8716F and late IT8712F have 6. They are shared with other functions
though, so the functionality may not be available on a given system.
The driver dumbly assume it is there.
The IT8718F and IT8720F also features VID inputs (up to 8 pins) but the value
is stored in the Super-I/O configuration space. Due to technical limitations,
......
Kernel driver mc13783-adc
=========================
Supported chips:
* Freescale Atlas MC13783
Prefix: 'mc13783_adc'
Datasheet: http://www.freescale.com/files/rf_if/doc/data_sheet/MC13783.pdf?fsrch=1
Authors:
Sascha Hauer <s.hauer@pengutronix.de>
Luotao Fu <l.fu@pengutronix.de>
Description
-----------
The Freescale MC13783 is a Power Management and Audio Circuit. Among
other things it contains a 10-bit A/D converter. The converter has 16
channels which can be used in different modes.
The A/D converter has a resolution of 2.25mV. Channels 0-4 have
a dedicated meaning with chip internal scaling applied. Channels 5-7
can be used as general purpose inputs or alternatively in a dedicated
mode. Channels 12-15 are occupied by the touchscreen if it's active.
Currently the driver only supports channels 2 and 5-15 with no alternative
modes for channels 5-7.
See this table for the meaning of the different channels and their chip
internal scaling:
Channel Signal Input Range Scaling
-------------------------------------------------------------------------------
0 Battery Voltage (BATT) 2.50 - 4.65V -2.40V
1 Battery Current (BATT - BATTISNS) -50 - 50 mV x20
2 Application Supply (BP) 2.50 - 4.65V -2.40V
3 Charger Voltage (CHRGRAW) 0 - 10V / /5
0 - 20V /10
4 Charger Current (CHRGISNSP-CHRGISNSN) -0.25V - 0.25V x4
5 General Purpose ADIN5 / Battery Pack Thermistor 0 - 2.30V No
6 General Purpose ADIN6 / Backup Voltage (LICELL) 0 - 2.30V / No /
1.50 - 3.50V -1.20V
7 General Purpose ADIN7 / UID / Die Temperature 0 - 2.30V / No /
0 - 2.55V / x0.9 / No
8 General Purpose ADIN8 0 - 2.30V No
9 General Purpose ADIN9 0 - 2.30V No
10 General Purpose ADIN10 0 - 2.30V No
11 General Purpose ADIN11 0 - 2.30V No
12 General Purpose TSX1 / Touchscreen X-plate 1 0 - 2.30V No
13 General Purpose TSX2 / Touchscreen X-plate 2 0 - 2.30V No
14 General Purpose TSY1 / Touchscreen Y-plate 1 0 - 2.30V No
15 General Purpose TSY2 / Touchscreen Y-plate 2 0 - 2.30V No
......@@ -225,8 +225,6 @@ pwm[1-*]_auto_point[1-*]_temp_hyst
to PWM output channels.
RW
OR
temp[1-*]_auto_point[1-*]_pwm
temp[1-*]_auto_point[1-*]_temp
temp[1-*]_auto_point[1-*]_temp_hyst
......@@ -235,6 +233,15 @@ temp[1-*]_auto_point[1-*]_temp_hyst
to temperature channels.
RW
There is a third case where trip points are associated to both PWM output
channels and temperature channels: the PWM values are associated to PWM
output channels while the temperature values are associated to temperature
channels. In that case, the result is determined by the mapping between
temperature inputs and PWM outputs. When several temperature inputs are
mapped to a given PWM output, this leads to several candidate PWM values.
The actual result is up to the chip, but in general the highest candidate
value (fastest fan speed) wins.
****************
* Temperatures *
......
......@@ -32,8 +32,6 @@ Authors:
Module Parameters
-----------------
* force_addr: int
Initialize the ISA address of the sensors
* force_i2c: int
Initialize the I2C address of the sensors
* init: int
......@@ -70,3 +68,30 @@ doesn't help, you may just ignore the bogus VID reading with no harm done.
For further information on this driver see the w83781d driver documentation.
[1] http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/vid
Forcing the address
-------------------
The driver used to have a module parameter named force_addr, which could
be used to force the base I/O address of the hardware monitoring block.
This was meant as a workaround for mainboards with a broken BIOS. This
module parameter is gone for technical reasons. If you need this feature,
you can obtain the same result by using the isaset tool (part of
lm-sensors) before loading the driver:
# Enter the Super I/O config space
isaset -y -f 0x2e 0x87
isaset -y -f 0x2e 0x87
# Select the hwmon logical device
isaset -y 0x2e 0x2f 0x07 0x0b
# Set the base I/O address (to 0x290 in this example)
isaset -y 0x2e 0x2f 0x60 0x02
isaset -y 0x2e 0x2f 0x61 0x90
# Exit the Super-I/O config space
isaset -y -f 0x2e 0xaa
The above sequence assumes a Super-I/O config space at 0x2e/0x2f, but
0x4e/0x4f is also possible.
Kernel driver i2c-voodoo3
Supported adapters:
* 3dfx Voodoo3 based cards
* Voodoo Banshee based cards
Authors:
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>,
Ralph Metzler <rjkm@thp.uni-koeln.de>,
Mark D. Studebaker <mdsxyz123@yahoo.com>
Main contact: Philip Edelbrock <phil@netroedge.com>
The code is based upon Ralph's test code (he did the hard stuff ;')
Description
-----------
The 3dfx Voodoo3 chip contains two I2C interfaces (aka a I2C 'master' or
'host').
The first interface is used for DDC (Data Display Channel) which is a
serial channel through the VGA monitor connector to a DDC-compliant
monitor. This interface is defined by the Video Electronics Standards
Association (VESA). The standards are available for purchase at
http://www.vesa.org .
The second interface is a general-purpose I2C bus. The intent by 3dfx was
to allow manufacturers to add extra chips to the video card such as a
TV-out chip such as the BT869 or possibly even I2C based temperature
sensors like the ADM1021 or LM75.
Stability
---------
Seems to be stable on the test machine, but needs more testing on other
machines. Simultaneous accesses of the DDC and I2C busses may cause errors.
Supported Devices
-----------------
Specifically, this driver was written and tested on the '3dfx Voodoo3 AGP
3000' which has a tv-out feature (s-video or composite). According to the
docs and discussions, this code should work for any Voodoo3 based cards as
well as Voodoo Banshee based cards. The DDC interface has been tested on a
Voodoo Banshee card.
Issues
------
Probably many, but it seems to work OK on my system. :')
External Device Connection
--------------------------
The digital video input jumpers give availability to the I2C bus.
Specifically, pins 13 and 25 (bottom row middle, and bottom right-end) are
the I2C clock and I2C data lines, respectively. +5V and GND are probably
also easily available making the addition of extra I2C/SMBus devices easy
to implement.
......@@ -2,9 +2,9 @@ MODULE: i2c-stub
DESCRIPTION:
This module is a very simple fake I2C/SMBus driver. It implements four
types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, and
(r/w) word data.
This module is a very simple fake I2C/SMBus driver. It implements five
types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, (r/w)
word data, and (r/w) I2C block data.
You need to provide chip addresses as a module parameter when loading this
driver, which will then only react to SMBus commands to these addresses.
......@@ -21,8 +21,8 @@ EEPROMs, among others.
The typical use-case is like this:
1. load this module
2. use i2cset (from lm_sensors project) to pre-load some data
3. load the target sensors chip driver module
2. use i2cset (from the i2c-tools project) to pre-load some data
3. load the target chip driver module
4. observe its behavior in the kernel log
There's a script named i2c-stub-from-dump in the i2c-tools package which
......@@ -33,6 +33,12 @@ PARAMETERS:
int chip_addr[10]:
The SMBus addresses to emulate chips at.
unsigned long functionality:
Functionality override, to disable some commands. See I2C_FUNC_*
constants in <linux/i2c.h> for the suitable values. For example,
value 0x1f0000 would only enable the quick, byte and byte data
commands.
CAVEATS:
If your target driver polls some byte or word waiting for it to change, the
......
I2C device driver binding control from user-space
=================================================
Up to kernel 2.6.32, many i2c drivers used helper macros provided by
<linux/i2c.h> which created standard module parameters to let the user
control how the driver would probe i2c buses and attach to devices. These
parameters were known as "probe" (to let the driver probe for an extra
address), "force" (to forcibly attach the driver to a given device) and
"ignore" (to prevent a driver from probing a given address).
With the conversion of the i2c subsystem to the standard device driver
binding model, it became clear that these per-module parameters were no
longer needed, and that a centralized implementation was possible. The new,
sysfs-based interface is described in the documentation file
"instantiating-devices", section "Method 4: Instantiate from user-space".
Below is a mapping from the old module parameters to the new interface.
Attaching a driver to an I2C device
-----------------------------------
Old method (module parameters):
# modprobe <driver> probe=1,0x2d
# modprobe <driver> force=1,0x2d
# modprobe <driver> force_<device>=1,0x2d
New method (sysfs interface):
# echo <device> 0x2d > /sys/bus/i2c/devices/i2c-1/new_device
Preventing a driver from attaching to an I2C device
---------------------------------------------------
Old method (module parameters):
# modprobe <driver> ignore=1,0x2f
New method (sysfs interface):
# echo dummy 0x2f > /sys/bus/i2c/devices/i2c-1/new_device
# modprobe <driver>
Of course, it is important to instantiate the "dummy" device before loading
the driver. The dummy device will be handled by i2c-core itself, preventing
other drivers from binding to it later on. If there is a real device at the
problematic address, and you want another driver to bind to it, then simply
pass the name of the device in question instead of "dummy".
此差异已折叠。
此差异已折叠。
此差异已折叠。
......@@ -304,7 +304,7 @@ static void *map_zeroed_pages(unsigned int num)
addr = mmap(NULL, getpagesize() * num,
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, fd, 0);
if (addr == MAP_FAILED)
err(1, "Mmaping %u pages of /dev/zero", num);
err(1, "Mmapping %u pages of /dev/zero", num);
/*
* One neat mmap feature is that you can close the fd, and it
......
......@@ -62,8 +62,20 @@ applicable).
It also tracks 4 contention points per class. A contention point is a call site
that had to wait on lock acquisition.
- CONFIGURATION
Lock statistics are enabled via CONFIG_LOCK_STATS.
- USAGE
Enable collection of statistics:
# echo 1 >/proc/sys/kernel/lock_stat
Disable collection of statistics:
# echo 0 >/proc/sys/kernel/lock_stat
Look at the current lock statistics:
( line numbers not part of actual output, done for clarity in the explanation
......
此差异已折叠。
Linux Ethernet Bonding Driver HOWTO
Latest update: 12 November 2007
Latest update: 23 September 2009
Initial release : Thomas Davis <tadavis at lbl.gov>
Corrections, HA extensions : 2000/10/03-15 :
......@@ -614,6 +614,46 @@ primary
The primary option is only valid for active-backup mode.
primary_reselect
Specifies the reselection policy for the primary slave. This
affects how the primary slave is chosen to become the active slave
when failure of the active slave or recovery of the primary slave
occurs. This option is designed to prevent flip-flopping between
the primary slave and other slaves. Possible values are:
always or 0 (default)
The primary slave becomes the active slave whenever it
comes back up.
better or 1
The primary slave becomes the active slave when it comes
back up, if the speed and duplex of the primary slave is
better than the speed and duplex of the current active
slave.
failure or 2
The primary slave becomes the active slave only if the
current active slave fails and the primary slave is up.
The primary_reselect setting is ignored in two cases:
If no slaves are active, the first slave to recover is
made the active slave.
When initially enslaved, the primary slave is always made
the active slave.
Changing the primary_reselect policy via sysfs will cause an
immediate selection of the best active slave according to the new
policy. This may or may not result in a change of the active
slave, depending upon the circumstances.
This option was added for bonding version 3.6.0.
updelay
Specifies the time, in milliseconds, to wait before enabling a
......
......@@ -257,6 +257,8 @@ characters, each representing a particular tainted value.
10: 'W' if a warning has previously been issued by the kernel.
11: 'C' if a staging driver has been loaded.
The primary reason for the 'Tainted: ' string is to tell kernel
debuggers if this is a clean kernel or if anything unusual has
occurred. Tainting is permanent: even if an offending module is
......
......@@ -104,7 +104,7 @@ to set the limit to 500mA when supplying power.
Consumers can control their supply current limit by calling :-
int regulator_set_current_limit(regulator, min_uV, max_uV);
int regulator_set_current_limit(regulator, min_uA, max_uA);
Where min_uA and max_uA are the minimum and maximum acceptable current limit in
microamps.
......
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册