hollalinux
/
linux-sg2042
mirror of https://github.com/sophgo/linux-riscv.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge tag v3.9-rc1 into for-3.9/upstream-fixes 

This is done so that I am able to apply fix for commit
0322bd3980 ("usb hid quirks for Masterkit MA901 usb radio") which
went into 3.9-rc1.
This commit is contained in:
Jiri Kosina 2013-03-29 15:12:10 +01:00
parent 4c43755506 6dbe51c251
commit 6aeedba20e
5087 changed files with 223787 additions and 84477 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Documentation/00-INDEX
View File

@ -299,6 +299,8 @@ memory-hotplug.txt
- Hotpluggable memory support, how to use and current status.
memory.txt
- info on typical Linux memory problems.
metag/
- directory with info about Linux on Meta architecture.
mips/
- directory with info about Linux on MIPS architecture.
misc-devices/

45
Documentation/ABI/testing/sysfs-bus-fcoe
View File

@ -1,14 +1,53 @@
What: /sys/bus/fcoe/ctlr_X
What: /sys/bus/fcoe/
Date: August 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
Description: The FCoE bus. Attributes in this directory are control interfaces.
Attributes:
ctlr_create: 'FCoE Controller' instance creation interface. Writing an
<ifname> to this file will allocate and populate sysfs with a
fcoe_ctlr_device (ctlr_X). The user can then configure any
per-port settings and finally write to the fcoe_ctlr_device's
'start' attribute to begin the kernel's discovery and login
process.
ctlr_destroy: 'FCoE Controller' instance removal interface. Writing a
fcoe_ctlr_device's sysfs name to this file will log the
fcoe_ctlr_device out of the fabric or otherwise connected
FCoE devices. It will also free all kernel memory allocated
for this fcoe_ctlr_device and any structures associated
with it, this includes the scsi_host.
What: /sys/bus/fcoe/devices/ctlr_X
Date: March 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
Description: 'FCoE Controller' instances on the fcoe bus
Description: 'FCoE Controller' instances on the fcoe bus.
The FCoE Controller now has a three stage creation process.
1) Write interface name to ctlr_create 2) Configure the FCoE
Controller (ctlr_X) 3) Enable the FCoE Controller to begin
discovery and login. The FCoE Controller is destroyed by
writing it's name, i.e. ctlr_X to the ctlr_delete file.
Attributes:
fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
this value will change the dev_loss_tmo for all
FCFs discovered by this controller.
mode: Display or change the FCoE Controller's mode. Possible
modes are 'Fabric' and 'VN2VN'. If a FCoE Controller
is started in 'Fabric' mode then FIP FCF discovery is
initiated and ultimately a fabric login is attempted.
If a FCoE Controller is started in 'VN2VN' mode then
FIP VN2VN discovery and login is performed. A FCoE
Controller only supports one mode at a time.
enabled: Whether an FCoE controller is enabled or disabled.
0 if disabled, 1 if enabled. Writing either 0 or 1
to this file will enable or disable the FCoE controller.
lesb/link_fail: Link Error Status Block (LESB) link failure count.
lesb/vlink_fail: Link Error Status Block (LESB) virtual link
@ -26,7 +65,7 @@ Attributes:
Notes: ctlr_X (global increment starting at 0)
What: /sys/bus/fcoe/fcf_X
What: /sys/bus/fcoe/devices/fcf_X
Date: March 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org

52
Documentation/ABI/testing/sysfs-kernel-mm-ksm Normal file
View File

@ -0,0 +1,52 @@
What: /sys/kernel/mm/ksm
Date: September 2009
KernelVersion: 2.6.32
Contact: Linux memory management mailing list <linux-mm@kvack.org>
Description: Interface for Kernel Samepage Merging (KSM)
What: /sys/kernel/mm/ksm/full_scans
What: /sys/kernel/mm/ksm/pages_shared
What: /sys/kernel/mm/ksm/pages_sharing
What: /sys/kernel/mm/ksm/pages_to_scan
What: /sys/kernel/mm/ksm/pages_unshared
What: /sys/kernel/mm/ksm/pages_volatile
What: /sys/kernel/mm/ksm/run
What: /sys/kernel/mm/ksm/sleep_millisecs
Date: September 2009
Contact: Linux memory management mailing list <linux-mm@kvack.org>
Description: Kernel Samepage Merging daemon sysfs interface
full_scans: how many times all mergeable areas have been
scanned.
pages_shared: how many shared pages are being used.
pages_sharing: how many more sites are sharing them i.e. how
much saved.
pages_to_scan: how many present pages to scan before ksmd goes
to sleep.
pages_unshared: how many pages unique but repeatedly checked
for merging.
pages_volatile: how many pages changing too fast to be placed
in a tree.
run: write 0 to disable ksm, read 0 while ksm is disabled.
write 1 to run ksm, read 1 while ksm is running.
write 2 to disable ksm and unmerge all its pages.
sleep_millisecs: how many milliseconds ksm should sleep between
scans.
See Documentation/vm/ksm.txt for more information.
What: /sys/kernel/mm/ksm/merge_across_nodes
Date: January 2013
KernelVersion: 3.9
Contact: Linux memory management mailing list <linux-mm@kvack.org>
Description: Control merging pages across different NUMA nodes.
When it is set to 0 only pages from the same node are merged,
otherwise pages from all nodes can be merged together (default).

83
Documentation/ABI/testing/sysfs-platform-msi-laptop Normal file
View File

@ -0,0 +1,83 @@
What: /sys/devices/platform/msi-laptop-pf/lcd_level
Date: Oct 2006
KernelVersion: 2.6.19
Contact: "Lennart Poettering <mzxreary@0pointer.de>"
Description:
Screen brightness: contains a single integer in the range 0..8.
What: /sys/devices/platform/msi-laptop-pf/auto_brightness
Date: Oct 2006
KernelVersion: 2.6.19
Contact: "Lennart Poettering <mzxreary@0pointer.de>"
Description:
Enable automatic brightness control: contains either 0 or 1. If
set to 1 the hardware adjusts the screen brightness
automatically when the power cord is plugged/unplugged.
What: /sys/devices/platform/msi-laptop-pf/wlan
Date: Oct 2006
KernelVersion: 2.6.19
Contact: "Lennart Poettering <mzxreary@0pointer.de>"
Description:
WLAN subsystem enabled: contains either 0 or 1.
What: /sys/devices/platform/msi-laptop-pf/bluetooth
Date: Oct 2006
KernelVersion: 2.6.19
Contact: "Lennart Poettering <mzxreary@0pointer.de>"
Description:
Bluetooth subsystem enabled: contains either 0 or 1. Please
note that this file is constantly 0 if no Bluetooth hardware is
available.
What: /sys/devices/platform/msi-laptop-pf/touchpad
Date: Nov 2012
KernelVersion: 3.8
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
Description:
Contains either 0 or 1 and indicates if touchpad is turned on.
Touchpad state can only be toggled by pressing Fn+F3.
What: /sys/devices/platform/msi-laptop-pf/turbo_mode
Date: Nov 2012
KernelVersion: 3.8
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
Description:
Contains either 0 or 1 and indicates if turbo mode is turned
on. In turbo mode power LED is orange and processor is
overclocked. Turbo mode is available only if charging. It is
only possible to toggle turbo mode state by pressing Fn+F10,
and there is a few seconds cooldown between subsequent toggles.
If user presses Fn+F10 too frequent, turbo mode state is not
changed.
What: /sys/devices/platform/msi-laptop-pf/eco_mode
Date: Nov 2012
KernelVersion: 3.8
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
Description:
Contains either 0 or 1 and indicates if ECO mode is turned on.
In ECO mode power LED is green and userspace should do some
powersaving actions. ECO mode is available only on battery
power. ECO mode can only be toggled by pressing Fn+F10.
What: /sys/devices/platform/msi-laptop-pf/turbo_cooldown
Date: Nov 2012
KernelVersion: 3.8
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
Description:
Contains value in range 0..3:
* 0 -> Turbo mode is off
* 1 -> Turbo mode is on, cannot be turned off yet
* 2 -> Turbo mode is off, cannot be turned on yet
* 3 -> Turbo mode is on
What: /sys/devices/platform/msi-laptop-pf/auto_fan
Date: Nov 2012
KernelVersion: 3.8
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
Description:
Contains either 0 or 1 and indicates if fan speed is controlled
automatically (1) or fan runs at maximal speed (0). Can be
toggled in software.

9
Documentation/DMA-API-HOWTO.txt
View File

@ -488,9 +488,10 @@ will invoke the generic mapping error check interface. Doing so will ensure
that the mapping code will work correctly on all dma implementations without
any dependency on the specifics of the underlying implementation. Using the
returned address without checking for errors could result in failures ranging
from panics to silent data corruption. Couple of example of incorrect ways to
check for errors that make assumptions about the underlying dma implementation
are as follows and these are applicable to dma_map_page() as well.
from panics to silent data corruption. A couple of examples of incorrect ways
to check for errors that make assumptions about the underlying dma
implementation are as follows and these are applicable to dma_map_page() as
well.
Incorrect example 1:
dma_addr_t dma_handle;
@ -751,7 +752,7 @@ Example 1:
dma_unmap_single(dma_handle1);
map_error_handling1:
Example 2: (if buffers are allocated a loop, unmap all mapped buffers when
Example 2: (if buffers are allocated in a loop, unmap all mapped buffers when
mapping error is detected in the middle)
dma_addr_t dma_addr;

78
Documentation/DocBook/drm.tmpl
View File

@ -743,6 +743,10 @@ char *date;</synopsis>
These two operations are mandatory for GEM drivers that support DRM
PRIME.
</para>
<sect4>
<title>DRM PRIME Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
</sect4>
</sect3>
<sect3 id="drm-gem-objects-mapping">
<title>GEM Objects Mapping</title>
@ -978,10 +982,25 @@ int max_width, max_height;</synopsis>
If the parameters are deemed valid, drivers then create, initialize and
return an instance of struct <structname>drm_framebuffer</structname>.
If desired the instance can be embedded in a larger driver-specific
structure. The new instance is initialized with a call to
<function>drm_framebuffer_init</function> which takes a pointer to DRM
frame buffer operations (struct
<structname>drm_framebuffer_funcs</structname>). Frame buffer operations are
structure. Drivers must fill its <structfield>width</structfield>,
<structfield>height</structfield>, <structfield>pitches</structfield>,
<structfield>offsets</structfield>, <structfield>depth</structfield>,
<structfield>bits_per_pixel</structfield> and
<structfield>pixel_format</structfield> fields from the values passed
through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
should call the <function>drm_helper_mode_fill_fb_struct</function>
helper function to do so.
</para>
<para>
The initailization of the new framebuffer instance is finalized with a
call to <function>drm_framebuffer_init</function> which takes a pointer
to DRM frame buffer operations (struct
<structname>drm_framebuffer_funcs</structname>). Note that this function
publishes the framebuffer and so from this point on it can be accessed
concurrently from other threads. Hence it must be the last step in the
driver's framebuffer initialization sequence. Frame buffer operations
are
<itemizedlist>
<listitem>
<synopsis>int (*create_handle)(struct drm_framebuffer *fb,
@ -1022,16 +1041,16 @@ int max_width, max_height;</synopsis>
</itemizedlist>
</para>
<para>
After initializing the <structname>drm_framebuffer</structname>
instance drivers must fill its <structfield>width</structfield>,
<structfield>height</structfield>, <structfield>pitches</structfield>,
<structfield>offsets</structfield>, <structfield>depth</structfield>,
<structfield>bits_per_pixel</structfield> and
<structfield>pixel_format</structfield> fields from the values passed
through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
should call the <function>drm_helper_mode_fill_fb_struct</function>
helper function to do so.
</para>
The lifetime of a drm framebuffer is controlled with a reference count,
drivers can grab additional references with
<function>drm_framebuffer_reference</function> </para> and drop them
again with <function>drm_framebuffer_unreference</function>. For
driver-private framebuffers for which the last reference is never
dropped (e.g. for the fbdev framebuffer when the struct
<structname>drm_framebuffer</structname> is embedded into the fbdev
helper struct) drivers can manually clean up a framebuffer at module
unload time with
<function>drm_framebuffer_unregister_private</function>.
</sect2>
<sect2>
<title>Output Polling</title>
@ -1043,6 +1062,22 @@ int max_width, max_height;</synopsis>
operation.
</para>
</sect2>
<sect2>
<title>Locking</title>
<para>
Beside some lookup structures with their own locking (which is hidden
behind the interface functions) most of the modeset state is protected
by the <code>dev-&lt;mode_config.lock</code> mutex and additionally
per-crtc locks to allow cursor updates, pageflips and similar operations
to occur concurrently with background tasks like output detection.
Operations which cross domains like a full modeset always grab all
locks. Drivers there need to protect resources shared between crtcs with
additional locking. They also need to be careful to always grab the
relevant crtc locks if a modset functions touches crtc state, e.g. for
load detection (which does only grab the <code>mode_config.lock</code>
to allow concurrent screen updates on live crtcs).
</para>
</sect2>
</sect1>
<!-- Internals: kms initialization and cleanup -->
@ -1125,6 +1160,12 @@ int max_width, max_height;</synopsis>
without waiting for rendering or page flip to complete and must block
any new rendering to the frame buffer until the page flip completes.
</para>
<para>
If a page flip can be successfully scheduled the driver must set the
<code>drm_crtc-&lt;fb</code> field to the new framebuffer pointed to
by <code>fb</code>. This is important so that the reference counting
on framebuffers stays balanced.
</para>
<para>
If a page flip is already pending, the
<methodname>page_flip</methodname> operation must return
@ -1609,6 +1650,10 @@ void intel_crt_init(struct drm_device *dev)
make its properties available to applications.
</para>
</sect2>
<sect2>
<title>KMS API Functions</title>
!Edrivers/gpu/drm/drm_crtc.c
</sect2>
</sect1>
<!-- Internals: kms helper functions -->
@ -2104,6 +2149,7 @@ void intel_crt_init(struct drm_device *dev)
<title>fbdev Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
!Edrivers/gpu/drm/drm_fb_helper.c
!Iinclude/drm/drm_fb_helper.h
</sect2>
<sect2>
<title>Display Port Helper Functions Reference</title>
@ -2111,6 +2157,10 @@ void intel_crt_init(struct drm_device *dev)
!Iinclude/drm/drm_dp_helper.h
!Edrivers/gpu/drm/drm_dp_helper.c
</sect2>
<sect2>
<title>EDID Helper Functions Reference</title>
!Edrivers/gpu/drm/drm_edid.c
</sect2>
</sect1>
<!-- Internals: vertical blanking -->

2
Documentation/DocBook/media/dvb/dvbapi.xml
View File

@ -84,7 +84,7 @@ Added ISDB-T test originally written by Patrick Boettcher
<title>LINUX DVB API</title>
<subtitle>Version 5.8</subtitle>
<subtitle>Version 5.10</subtitle>
<!-- ADD THE CHAPTERS HERE -->
<chapter id="dvb_introdution">
&sub-intro;

180
Documentation/DocBook/media/dvb/dvbproperty.xml
View File

@ -7,14 +7,41 @@ the capability ioctls weren't implemented yet via the new way.</para>
<para>The typical usage for the <constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant>
API is to replace the ioctl's were the <link linkend="dvb-frontend-parameters">
struct <constant>dvb_frontend_parameters</constant></link> were used.</para>
<section id="dtv-stats">
<title>DTV stats type</title>
<programlisting>
struct dtv_stats {
__u8 scale; /* enum fecap_scale_params type */
union {
__u64 uvalue; /* for counters and relative scales */
__s64 svalue; /* for 1/1000 dB measures */
};
} __packed;
</programlisting>
</section>
<section id="dtv-fe-stats">
<title>DTV stats type</title>
<programlisting>
#define MAX_DTV_STATS 4
struct dtv_fe_stats {
__u8 len;
struct dtv_stats stat[MAX_DTV_STATS];
} __packed;
</programlisting>
</section>
<section id="dtv-property">
<title>DTV property type</title>
<programlisting>
/* Reserved fields should be set to 0 */
struct dtv_property {
__u32 cmd;
__u32 reserved[3];
union {
__u32 data;
struct dtv_fe_stats st;
struct {
__u8 data[32];
__u32 len;
@ -440,7 +467,7 @@ typedef enum fe_delivery_system {
<title><constant>DTV-ISDBT-LAYER*</constant> parameters</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>
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>
@ -850,6 +877,147 @@ enum fe_interleaving {
<para>use the special macro LNA_AUTO to set LNA auto</para>
</section>
</section>
<section id="frontend-stat-properties">
<title>Frontend statistics indicators</title>
<para>The values are returned via <constant>dtv_property.stat</constant>.
If the property is supported, <constant>dtv_property.stat.len</constant> is bigger than zero.</para>
<para>For most delivery systems, <constant>dtv_property.stat.len</constant>
will be 1 if the stats is supported, and the properties will
return a single value for each parameter.</para>
<para>It should be noticed, however, that new OFDM delivery systems
like ISDB can use different modulation types for each group of
carriers. On such standards, up to 3 groups of statistics can be
provided, and <constant>dtv_property.stat.len</constant> is updated
to reflect the "global" metrics, plus one metric per each carrier
group (called "layer" on ISDB).</para>
<para>So, in order to be consistent with other delivery systems, the first
value at <link linkend="dtv-stats"><constant>dtv_property.stat.dtv_stats</constant></link>
array refers to the global metric. The other elements of the array
represent each layer, starting from layer A(index 1),
layer B (index 2) and so on.</para>
<para>The number of filled elements are stored at <constant>dtv_property.stat.len</constant>.</para>
<para>Each element of the <constant>dtv_property.stat.dtv_stats</constant> array consists on two elements:</para>
<itemizedlist mark='opencircle'>
<listitem><para><constant>svalue</constant> or <constant>uvalue</constant>, where
<constant>svalue</constant> is for signed values of the measure (dB measures)
and <constant>uvalue</constant> is for unsigned values (counters, relative scale)</para></listitem>
<listitem><para><constant>scale</constant> - Scale for the value. It can be:</para>
<section id = "fecap-scale-params">
<itemizedlist mark='bullet'>
<listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - The parameter is supported by the frontend, but it was not possible to collect it (could be a transitory or permanent condition)</para></listitem>
<listitem><para><constant>FE_SCALE_DECIBEL</constant> - parameter is a signed value, measured in 1/1000 dB</para></listitem>
<listitem><para><constant>FE_SCALE_RELATIVE</constant> - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.</para></listitem>
<listitem><para><constant>FE_SCALE_COUNTER</constant> - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.</para></listitem>
</itemizedlist>
</section>
</listitem>
</itemizedlist>
<section id="DTV-STAT-SIGNAL-STRENGTH">
<title><constant>DTV_STAT_SIGNAL_STRENGTH</constant></title>
<para>Indicates the signal strength level at the analog part of the tuner or of the demod.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_DECIBEL</constant> - signal strength is in 0.0001 dBm units, power measured in miliwatts. This value is generally negative.</listitem>
<listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for power (actually, 0 to 65535).</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-CNR">
<title><constant>DTV_STAT_CNR</constant></title>
<para>Indicates the Signal to Noise ratio for the main carrier.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_DECIBEL</constant> - Signal/Noise ratio is in 0.0001 dB units.</listitem>
<listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0 to 65535).</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-PRE-ERROR-BIT-COUNT">
<title><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></title>
<para>Measures the number of bit errors before the forward error correction (FEC) on the inner coding block (before Viterbi, LDPC or other inner code).</para>
<para>This measure is taken during the same interval as <constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant>.</para>
<para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
<link linkend="DTV-STAT-PRE-TOTAL-BIT-COUNT"><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></link>.</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before the inner coding.</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-PRE-TOTAL-BIT-COUNT">
<title><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></title>
<para>Measures the amount of bits received before the inner code block, during the same period as
<link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
<para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
<link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link>.</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-POST-ERROR-BIT-COUNT">
<title><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></title>
<para>Measures the number of bit errors after the forward error correction (FEC) done by inner code block (after Viterbi, LDPC or other inner code).</para>
<para>This measure is taken during the same interval as <constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant>.</para>
<para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
<link linkend="DTV-STAT-POST-TOTAL-BIT-COUNT"><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></link>.</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted after the inner coding.</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-POST-TOTAL-BIT-COUNT">
<title><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></title>
<para>Measures the amount of bits received after the inner coding, during the same period as
<link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
<para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
<link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link>.</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-ERROR-BLOCK-COUNT">
<title><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></title>
<para>Measures the number of block errors after the outer forward error correction coding (after Reed-Solomon or other outer code).</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after the outer coding.</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-TOTAL-BLOCK-COUNT">
<title><constant>DTV-STAT_TOTAL_BLOCK_COUNT</constant></title>
<para>Measures the total number of blocks received during the same period as
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link> measurement was taken.</para>
<para>It can be used to calculate the PER indicator, by dividing
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>
by <link linkend="DTV-STAT-TOTAL-BLOCK-COUNT"><constant>DTV-STAT-TOTAL-BLOCK-COUNT</constant></link>.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of blocks counted while measuring
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>.</listitem>
</itemizedlist>
</section>
</section>
<section id="frontend-property-terrestrial-systems">
<title>Properties used on terrestrial delivery systems</title>
<section id="dvbt-params">
@ -871,6 +1039,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="dvbt2-params">
<title>DVB-T2 delivery system</title>
@ -895,6 +1064,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="isdbt">
<title>ISDB-T delivery system</title>
@ -948,6 +1118,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-ISDBT-LAYER-SEGMENT-COUNT"><constant>DTV_ISDBT_LAYERC_SEGMENT_COUNT</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ISDBT-LAYER-TIME-INTERLEAVING"><constant>DTV_ISDBT_LAYERC_TIME_INTERLEAVING</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="atsc-params">
<title>ATSC delivery system</title>
@ -961,6 +1132,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="atscmh-params">
<title>ATSC-MH delivery system</title>
@ -988,6 +1160,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="dtmb-params">
<title>DTMB delivery system</title>
@ -1007,6 +1180,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-INTERLEAVING"><constant>DTV_INTERLEAVING</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
</section>
<section id="frontend-property-cable-systems">
@ -1028,6 +1202,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="dvbc-annex-b-params">
<title>DVB-C Annex B delivery system</title>
@ -1043,6 +1218,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
</section>
<section id="frontend-property-satellital-systems">
@ -1062,6 +1238,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
<para>Future implementations might add those two missing parameters:</para>
<itemizedlist mark='opencircle'>
<listitem><para><link linkend="DTV-DISEQC-MASTER"><constant>DTV_DISEQC_MASTER</constant></link></para></listitem>
@ -1077,6 +1254,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem>
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="turbo-params">
<title>Turbo code delivery system</title>

2
Documentation/DocBook/media/dvb/frontend.xml
View File

@ -230,7 +230,7 @@ typedef enum fe_status {
<entry align="char">The frontend has found a DVB signal</entry>
</row><row>
<entry align="char">FE_HAS_VITERBI</entry>
<entry align="char">The frontend FEC code is stable</entry>
<entry align="char">The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable</entry>
</row><row>
<entry align="char">FE_HAS_SYNC</entry>
<entry align="char">Syncronization bytes was found</entry>

2
Documentation/DocBook/media/v4l/common.xml
View File

@ -609,7 +609,7 @@ to zero and the <constant>VIDIOC_G_STD</constant>,
<para>Applications can make use of the <xref linkend="input-capabilities" /> and
<xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls
are available for the device.</para>
&ENOTTY;.
<para>See <xref linkend="buffer" /> for a rationale. Probably
even USB cameras follow some well known video standard. It might have
been better to explicitly indicate elsewhere if a device cannot live

16
Documentation/DocBook/media/v4l/compat.xml
View File

@ -2477,6 +2477,22 @@ that used it. It was originally scheduled for removal in 2.6.35.
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.9</title>
<orderedlist>
<listitem>
<para>Added timestamp types to
<structfield>flags</structfield> field in
<structname>v4l2_buffer</structname>. See <xref
linkend="buffer-flags" />.</para>
</listitem>
<listitem>
<para>Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control event
changes flag. See <xref linkend="changes-flags"/>.</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>

23
Documentation/DocBook/media/v4l/controls.xml
View File

@ -203,29 +203,6 @@ and should not be used in new drivers and applications.</entry>
<entry>boolean</entry>
<entry>Mirror the picture vertically.</entry>
</row>
<row>
<entry><constant>V4L2_CID_HCENTER_DEPRECATED</constant> (formerly <constant>V4L2_CID_HCENTER</constant>)</entry>
<entry>integer</entry>
<entry>Horizontal image centering. This control is
deprecated. New drivers and applications should use the <link
linkend="camera-controls">Camera class controls</link>
<constant>V4L2_CID_PAN_ABSOLUTE</constant>,
<constant>V4L2_CID_PAN_RELATIVE</constant> and
<constant>V4L2_CID_PAN_RESET</constant> instead.</entry>
</row>
<row>
<entry><constant>V4L2_CID_VCENTER_DEPRECATED</constant>
(formerly <constant>V4L2_CID_VCENTER</constant>)</entry>
<entry>integer</entry>
<entry>Vertical image centering. Centering is intended to
<emphasis>physically</emphasis> adjust cameras. For image cropping see
<xref linkend="crop" />, for clipping <xref linkend="overlay" />. This
control is deprecated. New drivers and applications should use the
<link linkend="camera-controls">Camera class controls</link>
<constant>V4L2_CID_TILT_ABSOLUTE</constant>,
<constant>V4L2_CID_TILT_RELATIVE</constant> and
<constant>V4L2_CID_TILT_RESET</constant> instead.</entry>
</row>
<row id="v4l2-power-line-frequency">
<entry><constant>V4L2_CID_POWER_LINE_FREQUENCY</constant></entry>
<entry>enum</entry>

59
Documentation/DocBook/media/v4l/io.xml
View File

@ -477,7 +477,7 @@ rest should be evident.</para>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
@ -488,7 +488,7 @@ DMA buffer from userspace using a file descriptor previously exported for a
different or the same device (known as the importer role), or both. This
section describes the DMABUF importer role API in V4L2.</para>
<para>Refer to <link linked="vidioc-expbuf"> DMABUF exporting </link> for
<para>Refer to <link linkend="vidioc-expbuf">DMABUF exporting</link> for
details about exporting V4L2 buffers as DMABUF file descriptors.</para>
<para>Input and output devices support the streaming I/O method when the
@ -741,17 +741,19 @@ applications when an output stream.</entry>
<entry>struct timeval</entry>
<entry><structfield>timestamp</structfield></entry>
<entry></entry>
<entry><para>For input streams this is the
system time (as returned by the <function>gettimeofday()</function>
function) when the first data byte was captured. For output streams
the data will not be displayed before this time, secondary to the
nominal frame rate determined by the current video standard in
enqueued order. Applications can for example zero this field to
display frames as soon as possible. The driver stores the time at
which the first data byte was actually sent out in the
<structfield>timestamp</structfield> field. This permits
applications to monitor the drift between the video and system
clock.</para></entry>
<entry><para>For input streams this is time when the first data
byte was captured, as returned by the
<function>clock_gettime()</function> function for the relevant
clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
<xref linkend="buffer-flags" />. For output streams the data
will not be displayed before this time, secondary to the nominal
frame rate determined by the current video standard in enqueued
order. Applications can for example zero this field to display
frames as soon as possible. The driver stores the time at which
the first data byte was actually sent out in the
<structfield>timestamp</structfield> field. This permits
applications to monitor the drift between the video and system
clock.</para></entry>
</row>
<row>
<entry>&v4l2-timecode;</entry>
@ -903,7 +905,7 @@ should set this to 0.</entry>
</row>
<row>
<entry></entry>
<entry>__unsigned long</entry>
<entry>unsigned long</entry>
<entry><structfield>userptr</structfield></entry>
<entry>When the memory type in the containing &v4l2-buffer; is
<constant>V4L2_MEMORY_USERPTR</constant>, this is a userspace
@ -1114,6 +1116,35 @@ Typically applications shall use this flag for output buffers if the data
in this buffer has not been created by the CPU but by some DMA-capable unit,
in which case caches have not been used.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
<entry>0xe000</entry>
<entry>Mask for timestamp types below. To test the
timestamp type, mask out bits not belonging to timestamp
type by performing a logical and operation with buffer
flags and timestamp mask.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
<entry>0x0000</entry>
<entry>Unknown timestamp type. This type is used by
drivers before Linux 3.9 and may be either monotonic (see
below) or realtime (wall clock). Monotonic clock has been
favoured in embedded systems whereas most of the drivers
use the realtime clock. Either kinds of timestamps are
available in user space via
<function>clock_gettime(2)</function> using clock IDs
<constant>CLOCK_MONOTONIC</constant> and
<constant>CLOCK_REALTIME</constant>, respectively.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry>
<entry>0x2000</entry>
<entry>The buffer timestamp has been taken from the
<constant>CLOCK_MONOTONIC</constant> clock. To access the
same clock outside V4L2, use
<function>clock_gettime(2)</function> .</entry>
</row>
</tbody>
</tgroup>
</table>

2
Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
View File

@ -6,7 +6,7 @@
<refnamediv>
<refname id="V4L2-PIX-FMT-NV12M"><constant>V4L2_PIX_FMT_NV12M</constant></refname>
<refname id="V4L2-PIX-FMT-NV21M"><constant>V4L2_PIX_FMT_NV21M</constant></refname>
<refname id="V4L2-PIX-FMT-NV12MT_16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
<refname id="V4L2-PIX-FMT-NV12MT-16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> and <constant>V4L2_PIX_FMT_NV21</constant> with planes
non contiguous in memory. </refpurpose>
</refnamediv>

34
Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml Normal file
View File

@ -0,0 +1,34 @@
<refentry>
<refmeta>
<refentrytitle>
V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-SBGGR10ALAW8">
<constant>V4L2_PIX_FMT_SBGGR10ALAW8</constant>
</refname>
<refname id="V4L2-PIX-FMT-SGBRG10ALAW8">
<constant>V4L2_PIX_FMT_SGBRG10ALAW8</constant>
</refname>
<refname id="V4L2-PIX-FMT-SGRBG10ALAW8">
<constant>V4L2_PIX_FMT_SGRBG10ALAW8</constant>
</refname>
<refname id="V4L2-PIX-FMT-SRGGB10ALAW8">
<constant>V4L2_PIX_FMT_SRGGB10ALAW8</constant>
</refname>
<refpurpose>10-bit Bayer formats compressed to 8 bits</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>The following four pixel formats are raw sRGB / Bayer
formats with 10 bits per color compressed to 8 bits each,
using the A-LAW algorithm. Each color component consumes 8
bits of memory. In other respects this format is similar to
<xref linkend="V4L2-PIX-FMT-SRGGB8"></xref>.</para>
</refsect1>
</refentry>

62
Documentation/DocBook/media/v4l/pixfmt-uv8.xml Normal file
View File

@ -0,0 +1,62 @@
<refentry id="V4L2-PIX-FMT-UV8">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_UV8 ('UV8')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_UV8</constant></refname>
<refpurpose>UV plane interleaved</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>In this format there is no Y plane, Only CbCr plane. ie
(UV interleaved)</para>
<example>
<title>
<constant>V4L2_PIX_FMT_UV8</constant>
pixel image
</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;4:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cr<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
<entry>Cr<subscript>21</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;12:</entry>
<entry>Cb<subscript>30</subscript></entry>
<entry>Cr<subscript>30</subscript></entry>
<entry>Cb<subscript>31</subscript></entry>
<entry>Cr<subscript>31</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

2
Documentation/DocBook/media/v4l/pixfmt.xml
View File

@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.<
&sub-srggb8;
&sub-sbggr16;
&sub-srggb10;
&sub-srggb10alaw8;
&sub-srggb10dpcm8;
&sub-srggb12;
</section>
@ -701,6 +702,7 @@ information.</para>
&sub-y12;
&sub-y10b;
&sub-y16;
&sub-uv8;
&sub-yuyv;
&sub-uyvy;
&sub-yvyu;

938
Documentation/DocBook/media/v4l/subdev-formats.xml
View File

File diff suppressed because it is too large Load Diff

12
Documentation/DocBook/media/v4l/v4l2.xml
View File

@ -139,6 +139,16 @@ structs, ioctls) must be noted in more detail in the history chapter
(compat.xml), along with the possible impact on existing drivers and
applications. -->
<revision>
<revnumber>3.9</revnumber>
<date>2012-12-03</date>
<authorinitials>sa, sn</authorinitials>
<revremark>Added timestamp types to v4l2_buffer.
Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control
event changes flag, see <xref linkend="changes-flags"/>.
</revremark>
</revision>
<revision>
<revnumber>3.6</revnumber>
<date>2012-07-02</date>
@ -472,7 +482,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 3.6</subtitle>
<subtitle>Revision 3.9</subtitle>
<chapter id="common">
&sub-common;

6
Documentation/DocBook/media/v4l/vidioc-dqevent.xml
View File

@ -261,6 +261,12 @@
<entry>This control event was triggered because the control flags
changed.</entry>
</row>
<row>
<entry><constant>V4L2_EVENT_CTRL_CH_RANGE</constant></entry>
<entry>0x0004</entry>
<entry>This control event was triggered because the minimum,
maximum, step or the default value of the control changed.</entry>
</row>
</tbody>
</tgroup>
</table>

30
Documentation/DocBook/media/v4l/vidioc-expbuf.xml
View File

@ -83,15 +83,14 @@ descriptor. The application may pass it to other DMABUF-aware devices. Refer to
<link linkend="dmabuf">DMABUF importing</link> for details about importing
DMABUF files into V4L2 nodes. It is recommended to close a DMABUF file when it
is no longer used to allow the associated memory to be reclaimed. </para>
</refsect1>
<refsect1>
<section>
<title>Examples</title>
<example>
<title>Exporting a buffer.</title>
<programlisting>
<refsect1>
<title>Examples</title>
<example>
<title>Exporting a buffer.</title>
<programlisting>
int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
{
&v4l2-exportbuffer; expbuf;
@ -108,12 +107,12 @@ int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
return 0;
}
</programlisting>
</example>
</programlisting>
</example>
<example>
<title>Exporting a buffer using the multi-planar API.</title>
<programlisting>
<example>
<title>Exporting a buffer using the multi-planar API.</title>
<programlisting>
int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
int dmafd[], int n_planes)
{
@ -137,12 +136,9 @@ int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
return 0;
}
</programlisting>
</example>
</section>
</refsect1>
</programlisting>
</example>
<refsect1>
<table pgwide="1" frame="none" id="v4l2-exportbuffer">
<title>struct <structname>v4l2_exportbuffer</structname></title>
<tgroup cols="3">

8
Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml
View File

@ -64,7 +64,9 @@ return an &EINVAL;. When the <structfield>value</structfield> is out
of bounds drivers can choose to take the closest valid value or return
an &ERANGE;, whatever seems more appropriate. However,
<constant>VIDIOC_S_CTRL</constant> is a write-only ioctl, it does not
return the actual new value.</para>
return the actual new value. If the <structfield>value</structfield>
is inappropriate for the control (e.g. if it refers to an unsupported
menu index of a menu control), then &EINVAL; is returned as well.</para>
<para>These ioctls work only with user controls. For other
control classes the &VIDIOC-G-EXT-CTRLS;, &VIDIOC-S-EXT-CTRLS; or
@ -99,7 +101,9 @@ application.</entry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-control; <structfield>id</structfield> is
invalid.</para>
invalid or the <structfield>value</structfield> is inappropriate for
the given control (i.e. if a menu item is selected that is not supported
by the driver according to &VIDIOC-QUERYMENU;).</para>
</listitem>
</varlistentry>
<varlistentry>

57
Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
View File

@ -106,7 +106,9 @@ value or if an error is returned.</para>
&EINVAL;. When the value is out of bounds drivers can choose to take
the closest valid value or return an &ERANGE;, whatever seems more
appropriate. In the first case the new value is set in
&v4l2-ext-control;.</para>
&v4l2-ext-control;. If the new control value is inappropriate (e.g. the
given menu index is not supported by the menu control), then this will
also result in an &EINVAL; error.</para>
<para>The driver will only set/get these controls if all control
values are correct. This prevents the situation where only some of the
@ -199,13 +201,46 @@ also be zero.</entry>
<row>
<entry>__u32</entry>
<entry><structfield>error_idx</structfield></entry>
<entry>Set by the driver in case of an error. If it is equal
to <structfield>count</structfield>, then no actual changes were made to
controls. In other words, the error was not associated with setting a particular
control. If it is another value, then only the controls up to <structfield>error_idx-1</structfield>
were modified and control <structfield>error_idx</structfield> is the one that
caused the error. The <structfield>error_idx</structfield> value is undefined
if the ioctl returned 0 (success).</entry>
<entry><para>Set by the driver in case of an error. If the error is
associated with a particular control, then <structfield>error_idx</structfield>
is set to the index of that control. If the error is not related to a specific
control, or the validation step failed (see below), then
<structfield>error_idx</structfield> is set to <structfield>count</structfield>.
The value is undefined if the ioctl returned 0 (success).</para>
<para>Before controls are read from/written to hardware a validation step
takes place: this checks if all controls in the list are valid controls,
if no attempt is made to write to a read-only control or read from a write-only
control, and any other up-front checks that can be done without accessing the
hardware. The exact validations done during this step are driver dependent
since some checks might require hardware access for some devices, thus making
it impossible to do those checks up-front. However, drivers should make a
best-effort to do as many up-front checks as possible.</para>
<para>This check is done to avoid leaving the hardware in an inconsistent state due
to easy-to-avoid problems. But it leads to another problem: the application needs to
know whether an error came from the validation step (meaning that the hardware
was not touched) or from an error during the actual reading from/writing to hardware.</para>
<para>The, in hindsight quite poor, solution for that is to set <structfield>error_idx</structfield>
to <structfield>count</structfield> if the validation failed. This has the
unfortunate side-effect that it is not possible to see which control failed the
validation. If the validation was successful and the error happened while
accessing the hardware, then <structfield>error_idx</structfield> is less than
<structfield>count</structfield> and only the controls up to
<structfield>error_idx-1</structfield> were read or written correctly, and the
state of the remaining controls is undefined.</para>
<para>Since <constant>VIDIOC_TRY_EXT_CTRLS</constant> does not access hardware
there is also no need to handle the validation step in this special way,
so <structfield>error_idx</structfield> will just be set to the control that
failed the validation step instead of to <structfield>count</structfield>.
This means that if <constant>VIDIOC_S_EXT_CTRLS</constant> fails with
<structfield>error_idx</structfield> set to <structfield>count</structfield>,
then you can call <constant>VIDIOC_TRY_EXT_CTRLS</constant> to try to discover
the actual control that failed the validation step. Unfortunately, there
is no <constant>TRY</constant> equivalent for <constant>VIDIOC_G_EXT_CTRLS</constant>.
</para></entry>
</row>
<row>
<entry>__u32</entry>
@ -298,8 +333,10 @@ These controls are described in <xref
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-ext-control; <structfield>id</structfield>
is invalid or the &v4l2-ext-controls;
<structfield>ctrl_class</structfield> is invalid. This error code is
is invalid, the &v4l2-ext-controls;
<structfield>ctrl_class</structfield> is invalid, or the &v4l2-ext-control;
<structfield>value</structfield> was inappropriate (e.g. the given menu
index is not supported by the driver). This error code is
also returned by the <constant>VIDIOC_S_EXT_CTRLS</constant> and
<constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctls if two or more
control values are in conflict.</para>

2
Documentation/DocBook/media/v4l/vidioc-querycap.xml
View File

@ -76,7 +76,7 @@ make sure the strings are properly NUL-terminated.</para></entry>
<row>
<entry>__u8</entry>
<entry><structfield>card</structfield>[32]</entry>
<entry>Name of the device, a NUL-terminated ASCII string.
<entry>Name of the device, a NUL-terminated UTF-8 string.
For example: "Yoyodyne TV/FM". One driver may support different brands
or models of video hardware. This information is intended for users,
for example in a menu of available devices. Since multiple TV cards of

1
Documentation/DocBook/media_api.tmpl
View File

@ -22,6 +22,7 @@
<!-- LinuxTV v4l-dvb repository. -->
<!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>">
<!ENTITY dash-ent-10 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
]>
<book id="media_api">

27
Documentation/EDID/HOWTO.txt
View File

@ -28,11 +28,30 @@ Makefile environment are given here.
To create binary EDID and C source code files from the existing data
material, simply type "make".
If you want to create your own EDID file, copy the file 1024x768.S and
replace the settings with your own data. The CRC value in the last line
If you want to create your own EDID file, copy the file 1024x768.S,
replace the settings with your own data and add a new target to the
Makefile. Please note that the EDID data structure expects the timing
values in a different way as compared to the standard X11 format.
X11:
HTimings: hdisp hsyncstart hsyncend htotal
VTimings: vdisp vsyncstart vsyncend vtotal
EDID:
#define XPIX hdisp
#define XBLANK htotal-hdisp
#define XOFFSET hsyncstart-hdisp
#define XPULSE hsyncend-hsyncstart
#define YPIX vdisp
#define YBLANK vtotal-vdisp
#define YOFFSET (63+(vsyncstart-vdisp))
#define YPULSE (63+(vsyncend-vsyncstart))
The CRC value in the last line
#define CRC 0x55
is a bit tricky. After a first version of the binary data set is
created, it must be be checked with the "edid-decode" utility which will
also is a bit tricky. After a first version of the binary data set is
created, it must be checked with the "edid-decode" utility which will
most probably complain about a wrong CRC. Fortunately, the utility also
displays the correct CRC which must then be inserted into the source
file. After the make procedure is repeated, the EDID data set is ready

18
Documentation/IPMI.txt
View File

@ -348,34 +348,40 @@ You can change this at module load time (for a module) with:
modprobe ipmi_si.o type=<type1>,<type2>....
ports=<port1>,<port2>... addrs=<addr1>,<addr2>...
irqs=<irq1>,<irq2>... trydefaults=[0|1]
irqs=<irq1>,<irq2>...
regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,...
regshifts=<shift1>,<shift2>,...
slave_addrs=<addr1>,<addr2>,...
force_kipmid=<enable1>,<enable2>,...
kipmid_max_busy_us=<ustime1>,<ustime2>,...
unload_when_empty=[0|1]
trydefaults=[0|1] trydmi=[0|1] tryacpi=[0|1]
tryplatform=[0|1] trypci=[0|1]
Each of these except si_trydefaults is a list, the first item for the
Each of these except try... items is a list, the first item for the
first interface, second item for the second interface, etc.
The si_type may be either "kcs", "smic", or "bt". If you leave it blank, it
defaults to "kcs".
If you specify si_addrs as non-zero for an interface, the driver will
If you specify addrs as non-zero for an interface, the driver will
use the memory address given as the address of the device. This
overrides si_ports.
If you specify si_ports as non-zero for an interface, the driver will
If you specify ports as non-zero for an interface, the driver will
use the I/O port given as the device address.
If you specify si_irqs as non-zero for an interface, the driver will
If you specify irqs as non-zero for an interface, the driver will
attempt to use the given interrupt for the device.
si_trydefaults sets whether the standard IPMI interface at 0xca2 and
trydefaults sets whether the standard IPMI interface at 0xca2 and
any interfaces specified by ACPE are tried. By default, the driver
tries it, set this value to zero to turn this off.
The other try... items disable discovery by their corresponding
names. These are all enabled by default, set them to zero to disable
them. The tryplatform disables openfirmware.
The next three parameters have to do with register layout. The
registers used by the interfaces may not appear at successive
locations and they may not be in 8-bit registers. These parameters

58
Documentation/block/cfq-iosched.txt
View File

@ -102,6 +102,64 @@ processing of request. Therefore, increasing the value can imporve the
performace although this can cause the latency of some I/O to increase due
to more number of requests.
CFQ Group scheduling
====================
CFQ supports blkio cgroup and has "blkio." prefixed files in each
blkio cgroup directory. It is weight-based and there are four knobs
for configuration - weight[_device] and leaf_weight[_device].
Internal cgroup nodes (the ones with children) can also have tasks in
them, so the former two configure how much proportion the cgroup as a
whole is entitled to at its parent's level while the latter two
configure how much proportion the tasks in the cgroup have compared to
its direct children.
Another way to think about it is assuming that each internal node has
an implicit leaf child node which hosts all the tasks whose weight is
configured by leaf_weight[_device]. Let's assume a blkio hierarchy
composed of five cgroups - root, A, B, AA and AB - with the following
weights where the names represent the hierarchy.
weight leaf_weight
root : 125 125
A : 500 750
B : 250 500
AA : 500 500
AB : 1000 500
root never has a parent making its weight is meaningless. For backward
compatibility, weight is always kept in sync with leaf_weight. B, AA
and AB have no child and thus its tasks have no children cgroup to
compete with. They always get 100% of what the cgroup won at the
parent level. Considering only the weights which matter, the hierarchy
looks like the following.
root
/ | \
A B leaf
500 250 125
/ | \
AA AB leaf
500 1000 750
If all cgroups have active IOs and competing with each other, disk
time will be distributed like the following.
Distribution below root. The total active weight at this level is
A:500 + B:250 + C:125 = 875.
root-leaf : 125 / 875 =~ 14%
A : 500 / 875 =~ 57%
B(-leaf) : 250 / 875 =~ 28%
A has children and further distributes its 57% among the children and
the implicit leaf node. The total active weight at this level is
AA:500 + AB:1000 + A-leaf:750 = 2250.
A-leaf : ( 750 / 2250) * A =~ 19%
AA(-leaf) : ( 500 / 2250) * A =~ 12%
AB(-leaf) : (1000 / 2250) * A =~ 25%
CFQ IOPS Mode for group scheduling
===================================
Basic CFQ design is to provide priority based time slices. Higher priority

38
Documentation/blockdev/nbd.txt
View File

@ -4,43 +4,13 @@
can use a remote server as one of its block devices. So every time
the client computer wants to read, e.g., /dev/nb0, it sends a
request over TCP to the server, which will reply with the data read.
This can be used for stations with low disk space (or even diskless -
if you boot from floppy) to borrow disk space from another computer.
Unlike NFS, it is possible to put any filesystem on it, etc. It should
even be possible to use NBD as a root filesystem (I've never tried),
but it requires a user-level program to be in the initrd to start.
It also allows you to run block-device in user land (making server
and client physically the same computer, communicating using loopback).
Current state: It currently works. Network block device is stable.
I originally thought that it was impossible to swap over TCP. It
turned out not to be true - swapping over TCP now works and seems
to be deadlock-free, but it requires heavy patches into Linux's
network layer.
This can be used for stations with low disk space (or even diskless)
to borrow disk space from another computer.
Unlike NFS, it is possible to put any filesystem on it, etc.
For more information, or to download the nbd-client and nbd-server
tools, go to http://nbd.sf.net/.
Howto: To setup nbd, you can simply do the following:
First, serve a device or file from a remote server:
nbd-server <port-number> <device-or-file-to-serve-to-client>
e.g.,
root@server1 # nbd-server 1234 /dev/sdb1
(serves sdb1 partition on TCP port 1234)
Then, on the local (client) system:
nbd-client <server-name-or-IP> <server-port-number> /dev/nb[0-n]
e.g.,
root@client1 # nbd-client server1 1234 /dev/nb0
(creates the nb0 device on client1)
The nbd kernel module need only be installed on the client
system, as the nbd-server is completely in userspace. In fact,
the nbd-server has been successfully ported to other operating

37
Documentation/cgroups/blkio-controller.txt
View File

@ -75,7 +75,7 @@ Throttling/Upper Limit policy
mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
- Specify a bandwidth rate on particular device for root group. The format
for policy is "<major>:<minor> <byes_per_second>".
for policy is "<major>:<minor> <bytes_per_second>".
echo "8:16 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device
@ -94,13 +94,11 @@ Throttling/Upper Limit policy
Hierarchical Cgroups
====================
- Currently none of the IO control policy supports hierarchical groups. But
cgroup interface does allow creation of hierarchical cgroups and internally
IO policies treat them as flat hierarchy.
- Currently only CFQ supports hierarchical groups. For throttling,
cgroup interface does allow creation of hierarchical cgroups and
internally it treats them as flat hierarchy.
So this patch will allow creation of cgroup hierarchcy but at the backend
everything will be treated as flat. So if somebody created a hierarchy like
as follows.
If somebody created a hierarchy like as follows.
root
/ \
@ -108,16 +106,20 @@ Hierarchical Cgroups
|
test3
CFQ and throttling will practically treat all groups at same level.
CFQ will handle the hierarchy correctly but and throttling will
practically treat all groups at same level. For details on CFQ
hierarchy support, refer to Documentation/block/cfq-iosched.txt.
Throttling will treat the hierarchy as if it looks like the
following.
pivot
/ / \ \
root test1 test2 test3
Down the line we can implement hierarchical accounting/control support
and also introduce a new cgroup file "use_hierarchy" which will control
whether cgroup hierarchy is viewed as flat or hierarchical by the policy..
This is how memory controller also has implemented the things.
Nesting cgroups, while allowed, isn't officially supported and blkio
genereates warning when cgroups nest. Once throttling implements
hierarchy support, hierarchy will be supported and the warning will
be removed.
Various user visible config options
===================================
@ -172,6 +174,12 @@ Proportional weight policy files
dev weight
8:16 300
- blkio.leaf_weight[_device]
- Equivalents of blkio.weight[_device] for the purpose of
deciding how much weight tasks in the given cgroup has while
competing with the cgroup's child cgroups. For details,
please refer to Documentation/block/cfq-iosched.txt.
- blkio.time
- disk time allocated to cgroup per device in milliseconds. First
two fields specify the major and minor number of the device and
@ -279,6 +287,11 @@ Proportional weight policy files
and minor number of the device and third field specifies the number
of times a group was dequeued from a particular device.
- blkio.*_recursive
- Recursive version of various stats. These files show the
same information as their non-recursive counterparts but
include stats from all the descendant cgroups.
Throttling/Upper limit policy files
-----------------------------------
- blkio.throttle.read_bps_device

4
Documentation/coccinelle.txt
View File

@ -87,6 +87,10 @@ As any static code analyzer, Coccinelle produces false
positives. Thus, reports must be carefully checked, and patches
reviewed.
To enable verbose messages set the V= variable, for example:
make coccicheck MODE=report V=1
Using Coccinelle with a single semantic patch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

77
Documentation/device-mapper/cache-policies.txt Normal file
View File

@ -0,0 +1,77 @@
Guidance for writing policies
=============================
Try to keep transactionality out of it. The core is careful to
avoid asking about anything that is migrating. This is a pain, but
makes it easier to write the policies.
Mappings are loaded into the policy at construction time.
Every bio that is mapped by the target is referred to the policy.
The policy can return a simple HIT or MISS or issue a migration.
Currently there's no way for the policy to issue background work,
e.g. to start writing back dirty blocks that are going to be evicte
soon.
Because we map bios, rather than requests it's easy for the policy
to get fooled by many small bios. For this reason the core target
issues periodic ticks to the policy. It's suggested that the policy
doesn't update states (eg, hit counts) for a block more than once
for each tick. The core ticks by watching bios complete, and so
trying to see when the io scheduler has let the ios run.
Overview of supplied cache replacement policies
===============================================
multiqueue
----------
This policy is the default.
The multiqueue policy has two sets of 16 queues: one set for entries
waiting for the cache and another one for those in the cache.
Cache entries in the queues are aged based on logical time. Entry into
the cache is based on variable thresholds and queue selection is based
on hit count on entry. The policy aims to take different cache miss
costs into account and to adjust to varying load patterns automatically.
Message and constructor argument pairs are:
'sequential_threshold <#nr_sequential_ios>' and
'random_threshold <#nr_random_ios>'.
The sequential threshold indicates the number of contiguous I/Os
required before a stream is treated as sequential. The random threshold
is the number of intervening non-contiguous I/Os that must be seen
before the stream is treated as random again.
The sequential and random thresholds default to 512 and 4 respectively.
Large, sequential ios are probably better left on the origin device
since spindles tend to have good bandwidth. The io_tracker counts
contiguous I/Os to try to spot when the io is in one of these sequential
modes.
cleaner
-------
The cleaner writes back all dirty blocks in a cache to decommission it.
Examples
========
The syntax for a table is:
cache <metadata dev> <cache dev> <origin dev> <block size>
<#feature_args> [<feature arg>]*
<policy> <#policy_args> [<policy arg>]*
The syntax to send a message using the dmsetup command is:
dmsetup message <mapped device> 0 sequential_threshold 1024
dmsetup message <mapped device> 0 random_threshold 8
Using dmsetup:
dmsetup create blah --table "0 268435456 cache /dev/sdb /dev/sdc \
/dev/sdd 512 0 mq 4 sequential_threshold 1024 random_threshold 8"
creates a 128GB large mapped device named 'blah' with the
sequential threshold set to 1024 and the random_threshold set to 8.

243
Documentation/device-mapper/cache.txt Normal file
View File

@ -0,0 +1,243 @@
Introduction
============
dm-cache is a device mapper target written by Joe Thornber, Heinz
Mauelshagen, and Mike Snitzer.
It aims to improve performance of a block device (eg, a spindle) by
dynamically migrating some of its data to a faster, smaller device
(eg, an SSD).
This device-mapper solution allows us to insert this caching at
different levels of the dm stack, for instance above the data device for
a thin-provisioning pool. Caching solutions that are integrated more
closely with the virtual memory system should give better performance.
The target reuses the metadata library used in the thin-provisioning
library.
The decision as to what data to migrate and when is left to a plug-in
policy module. Several of these have been written as we experiment,
and we hope other people will contribute others for specific io
scenarios (eg. a vm image server).
Glossary
========
Migration - Movement of the primary copy of a logical block from one
device to the other.
Promotion - Migration from slow device to fast device.
Demotion - Migration from fast device to slow device.
The origin device always contains a copy of the logical block, which
may be out of date or kept in sync with the copy on the cache device
(depending on policy).
Design
======
Sub-devices
-----------
The target is constructed by passing three devices to it (along with
other parameters detailed later):
1. An origin device - the big, slow one.
2. A cache device - the small, fast one.
3. A small metadata device - records which blocks are in the cache,
which are dirty, and extra hints for use by the policy object.
This information could be put on the cache device, but having it
separate allows the volume manager to configure it differently,
e.g. as a mirror for extra robustness.
Fixed block size
----------------
The origin is divided up into blocks of a fixed size. This block size
is configurable when you first create the cache. Typically we've been
using block sizes of 256k - 1024k.
Having a fixed block size simplifies the target a lot. But it is
something of a compromise. For instance, a small part of a block may be
getting hit a lot, yet the whole block will be promoted to the cache.
So large block sizes are bad because they waste cache space. And small
block sizes are bad because they increase the amount of metadata (both
in core and on disk).
Writeback/writethrough
----------------------
The cache has two modes, writeback and writethrough.
If writeback, the default, is selected then a write to a block that is
cached will go only to the cache and the block will be marked dirty in
the metadata.
If writethrough is selected then a write to a cached block will not
complete until it has hit both the origin and cache devices. Clean
blocks should remain clean.
A simple cleaner policy is provided, which will clean (write back) all
dirty blocks in a cache. Useful for decommissioning a cache.
Migration throttling
--------------------
Migrating data between the origin and cache device uses bandwidth.
The user can set a throttle to prevent more than a certain amount of
migration occuring at any one time. Currently we're not taking any
account of normal io traffic going to the devices. More work needs
doing here to avoid migrating during those peak io moments.
For the time being, a message "migration_threshold <#sectors>"
can be used to set the maximum number of sectors being migrated,
the default being 204800 sectors (or 100MB).
Updating on-disk metadata
-------------------------
On-disk metadata is committed every time a REQ_SYNC or REQ_FUA bio is
written. If no such requests are made then commits will occur every
second. This means the cache behaves like a physical disk that has a
write cache (the same is true of the thin-provisioning target). If
power is lost you may lose some recent writes. The metadata should
always be consistent in spite of any crash.
The 'dirty' state for a cache block changes far too frequently for us
to keep updating it on the fly. So we treat it as a hint. In normal
operation it will be written when the dm device is suspended. If the
system crashes all cache blocks will be assumed dirty when restarted.
Per-block policy hints
----------------------
Policy plug-ins can store a chunk of data per cache block. It's up to
the policy how big this chunk is, but it should be kept small. Like the
dirty flags this data is lost if there's a crash so a safe fallback
value should always be possible.
For instance, the 'mq' policy, which is currently the default policy,
uses this facility to store the hit count of the cache blocks. If
there's a crash this information will be lost, which means the cache
may be less efficient until those hit counts are regenerated.
Policy hints affect performance, not correctness.
Policy messaging
----------------
Policies will have different tunables, specific to each one, so we
need a generic way of getting and setting these. Device-mapper
messages are used. Refer to cache-policies.txt.
Discard bitset resolution
-------------------------
We can avoid copying data during migration if we know the block has
been discarded. A prime example of this is when mkfs discards the
whole block device. We store a bitset tracking the discard state of
blocks. However, we allow this bitset to have a different block size
from the cache blocks. This is because we need to track the discard
state for all of the origin device (compare with the dirty bitset
which is just for the smaller cache device).
Target interface
================
Constructor
-----------
cache <metadata dev> <cache dev> <origin dev> <block size>
<#feature args> [<feature arg>]*
<policy> <#policy args> [policy args]*
metadata dev : fast device holding the persistent metadata
cache dev : fast device holding cached data blocks
origin dev : slow device holding original data blocks
block size : cache unit size in sectors
#feature args : number of feature arguments passed
feature args : writethrough. (The default is writeback.)
policy : the replacement policy to use
#policy args : an even number of arguments corresponding to
key/value pairs passed to the policy
policy args : key/value pairs passed to the policy
E.g. 'sequential_threshold 1024'
See cache-policies.txt for details.
Optional feature arguments are:
writethrough : write through caching that prohibits cache block
content from being different from origin block content.
Without this argument, the default behaviour is to write
back cache block contents later for performance reasons,
so they may differ from the corresponding origin blocks.
A policy called 'default' is always registered. This is an alias for
the policy we currently think is giving best all round performance.
As the default policy could vary between kernels, if you are relying on
the characteristics of a specific policy, always request it by name.
Status
------
<#used metadata blocks>/<#total metadata blocks> <#read hits> <#read misses>
<#write hits> <#write misses> <#demotions> <#promotions> <#blocks in cache>
<#dirty> <#features> <features>* <#core args> <core args>* <#policy args>
<policy args>*
#used metadata blocks : Number of metadata blocks used
#total metadata blocks : Total number of metadata blocks
#read hits : Number of times a READ bio has been mapped
to the cache
#read misses : Number of times a READ bio has been mapped
to the origin
#write hits : Number of times a WRITE bio has been mapped
to the cache
#write misses : Number of times a WRITE bio has been
mapped to the origin
#demotions : Number of times a block has been removed
from the cache
#promotions : Number of times a block has been moved to
the cache
#blocks in cache : Number of blocks resident in the cache
#dirty : Number of blocks in the cache that differ
from the origin
#feature args : Number of feature args to follow
feature args : 'writethrough' (optional)
#core args : Number of core arguments (must be even)
core args : Key/value pairs for tuning the core
e.g. migration_threshold
#policy args : Number of policy arguments to follow (must be even)
policy args : Key/value pairs
e.g. 'sequential_threshold 1024
Messages
--------
Policies will have different tunables, specific to each one, so we
need a generic way of getting and setting these. Device-mapper
messages are used. (A sysfs interface would also be possible.)
The message format is:
<key> <value>
E.g.
dmsetup message my_cache 0 sequential_threshold 1024
Examples
========
The test suite can be found here:
https://github.com/jthornber/thinp-test-suite
dmsetup create my_cache --table '0 41943040 cache /dev/mapper/metadata \
/dev/mapper/ssd /dev/mapper/origin 512 1 writeback default 0'
dmsetup create my_cache --table '0 41943040 cache /dev/mapper/metadata \
/dev/mapper/ssd /dev/mapper/origin 1024 1 writeback \
mq 4 sequential_threshold 1024 random_threshold 8'

24
Documentation/devicetree/bindings/arc/interrupts.txt Normal file
View File

@ -0,0 +1,24 @@
* ARC700 incore Interrupt Controller
The core interrupt controller provides 32 prioritised interrupts (2 levels)
to ARC700 core.
Properties:
- compatible: "snps,arc700-intc"
- interrupt-controller: This is an interrupt controller.
- #interrupt-cells: Must be <1>.
Single Cell "interrupts" property of a device specifies the IRQ number
between 0 to 31
intc accessed via the special ARC AUX register interface, hence "reg" property
is not specified.
Example:
intc: interrupt-controller {
compatible = "snps,arc700-intc";
interrupt-controller;
#interrupt-cells = <1>;
};

6
Documentation/devicetree/bindings/arm/armadeus.txt Normal file
View File

@ -0,0 +1,6 @@
Armadeus i.MX Platforms Device Tree Bindings
-----------------------------------------------
APF51: i.MX51 based module.
Required root node properties:
- compatible = "armadeus,imx51-apf51", "fsl,imx51";

8
Documentation/devicetree/bindings/arm/fsl.txt
View File

@ -5,6 +5,14 @@ i.MX23 Evaluation Kit
Required root node properties:
- compatible = "fsl,imx23-evk", "fsl,imx23";
i.MX25 Product Development Kit
Required root node properties:
- compatible = "fsl,imx25-pdk", "fsl,imx25";
i.MX27 Product Development Kit
Required root node properties:
- compatible = "fsl,imx27-pdk", "fsl,imx27";
i.MX28 Evaluation Kit
Required root node properties:
- compatible = "fsl,imx28-evk", "fsl,imx28";

1
Documentation/devicetree/bindings/clock/imx5-clock.txt
View File

@ -171,6 +171,7 @@ clocks and IDs.
can_sel 156
can1_serial_gate 157
can1_ipg_gate 158
owire_gate 159
Examples (for mx53):

2
Documentation/devicetree/bindings/clock/imx6q-clock.txt
View File

@ -203,6 +203,8 @@ clocks and IDs.
pcie_ref 188
pcie_ref_125m 189
enet_ref 190
usbphy1_gate 191
usbphy2_gate 192
Examples:

12
Documentation/devicetree/bindings/crypto/fsl-sec4.txt
View File

@ -54,8 +54,13 @@ PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,sec-v4.0". Also includes SEC
ERA versions (optional) with which the device is compatible.
Definition: Must include "fsl,sec-v4.0"
- fsl,sec-era
Usage: optional
Value type: <u32>
Definition: A standard property. Define the 'ERA' of the SEC
device.
- #address-cells
Usage: required
@ -107,7 +112,8 @@ PROPERTIES
EXAMPLE
crypto@300000 {
compatible = "fsl,sec-v4.0", "fsl,sec-era-v2.0";
compatible = "fsl,sec-v4.0";
fsl,sec-era = <2>;
#address-cells = <1>;
#size-cells = <1>;
reg = <0x300000 0x10000>;

21
Documentation/devicetree/bindings/dma/arm-pl330.txt
View File

@ -10,7 +10,11 @@ Required properties:
- interrupts: interrupt number to the cpu.
Optional properties:
- dma-coherent : Present if dma operations are coherent
- dma-coherent : Present if dma operations are coherent
- #dma-cells: must be <1>. used to represent the number of integer
cells in the dmas property of client device.
- dma-channels: contains the total number of DMA channels supported by the DMAC
- dma-requests: contains the total number of DMA requests supported by the DMAC
Example:
@ -18,16 +22,23 @@ Example:
compatible = "arm,pl330", "arm,primecell";
reg = <0x12680000 0x1000>;
interrupts = <99>;
#dma-cells = <1>;
#dma-channels = <8>;
#dma-requests = <32>;
};
Client drivers (device nodes requiring dma transfers from dev-to-mem or
mem-to-dev) should specify the DMA channel numbers using a two-value pair
mem-to-dev) should specify the DMA channel numbers and dma channel names
as shown below.
[property name] = <[phandle of the dma controller] [dma request id]>;
[property name] = <[dma channel name]>
where 'dma request id' is the dma request number which is connected
to the client controller. The 'property name' is recommended to be
of the form <name>-dma-channel.
to the client controller. The 'property name' 'dmas' and 'dma-names'
as required by the generic dma device tree binding helpers. The dma
names correspond 1:1 with the dma request ids in the dmas property.
Example: tx-dma-channel = <&pdma0 12>;
Example: dmas = <&pdma0 12
&pdma1 11>;
dma-names = "tx", "rx";

81
Documentation/devicetree/bindings/dma/dma.txt Normal file
View File

@ -0,0 +1,81 @@
* Generic DMA Controller and DMA request bindings
Generic binding to provide a way for a driver using DMA Engine to retrieve the
DMA request or channel information that goes from a hardware device to a DMA
controller.
* DMA controller
Required property:
- #dma-cells: Must be at least 1. Used to provide DMA controller
specific information. See DMA client binding below for
more details.
Optional properties:
- dma-channels: Number of DMA channels supported by the controller.
- dma-requests: Number of DMA requests signals supported by the
controller.
Example:
dma: dma@48000000 {
compatible = "ti,omap-sdma";
reg = <0x48000000 0x1000>;
interrupts = <0 12 0x4
0 13 0x4
0 14 0x4
0 15 0x4>;
#dma-cells = <1>;
dma-channels = <32>;
dma-requests = <127>;
};
* DMA client
Client drivers should specify the DMA property using a phandle to the controller
followed by DMA controller specific data.
Required property:
- dmas: List of one or more DMA specifiers, each consisting of
- A phandle pointing to DMA controller node
- A number of integer cells, as determined by the
#dma-cells property in the node referenced by phandle
containing DMA controller specific information. This
typically contains a DMA request line number or a
channel number, but can contain any data that is used
required for configuring a channel.
- dma-names: Contains one identifier string for each DMA specifier in
the dmas property. The specific strings that can be used
are defined in the binding of the DMA client device.
Multiple DMA specifiers can be used to represent
alternatives and in this case the dma-names for those
DMA specifiers must be identical (see examples).
Examples:
1. A device with one DMA read channel, one DMA write channel:
i2c1: i2c@1 {
...
dmas = <&dma 2 /* read channel */
&dma 3>; /* write channel */
dma-names = "rx", "tx";
...
};
2. A single read-write channel with three alternative DMA controllers:
dmas = <&dma1 5
&dma2 7
&dma3 2>;
dma-names = "rx-tx", "rx-tx", "rx-tx";
3. A device with three channels, one of which has two alternatives:
dmas = <&dma1 2 /* read channel */
&dma1 3 /* write channel */
&dma2 0 /* error read */
&dma3 0>; /* alternative error read */
dma-names = "rx", "tx", "error", "error";

50
Documentation/devicetree/bindings/dma/snps-dma.txt
View File

@ -3,15 +3,61 @@
Required properties:
- compatible: "snps,dma-spear1340"
- reg: Address range of the DMAC registers
- interrupt: Should contain the DMAC interrupt number
- dma-channels: Number of channels supported by hardware
- dma-requests: Number of DMA request lines supported, up to 16
- dma-masters: Number of AHB masters supported by the controller
- #dma-cells: must be <3>
- chan_allocation_order: order of allocation of channel, 0 (default): ascending,
1: descending
- chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1:
increase from chan n->0
- block_size: Maximum block size supported by the controller
- data_width: Maximum data width supported by hardware per AHB master
(0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
Optional properties:
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
- interrupt: Should contain the DMAC interrupt number
- is_private: The device channels should be marked as private and not for by the
general purpose DMA channel allocator. False if not passed.
Example:
dma@fc000000 {
dmahost: dma@fc000000 {
compatible = "snps,dma-spear1340";
reg = <0xfc000000 0x1000>;
interrupt-parent = <&vic1>;
interrupts = <12>;
dma-channels = <8>;
dma-requests = <16>;
dma-masters = <2>;
#dma-cells = <3>;
chan_allocation_order = <1>;
chan_priority = <1>;
block_size = <0xfff>;
data_width = <3 3 0 0>;
};
DMA clients connected to the Designware DMA controller must use the format
described in the dma.txt file, using a four-cell specifier for each channel.
The four cells in order are:
1. A phandle pointing to the DMA controller
2. The DMA request line number
3. Source master for transfers on allocated channel
4. Destination master for transfers on allocated channel
Example:
serial@e0000000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0xe0000000 0x1000>;
interrupts = <0 35 0x4>;
status = "disabled";
dmas = <&dmahost 12 0 1>,
<&dmahost 13 0 1 0>;
dma-names = "rx", "rx";
};

59
Documentation/devicetree/bindings/drm/tilcdc/panel.txt Normal file
View File

@ -0,0 +1,59 @@
Device-Tree bindings for tilcdc DRM generic panel output driver
Required properties:
- compatible: value should be "ti,tilcdc,panel".
- panel-info: configuration info to configure LCDC correctly for the panel
- ac-bias: AC Bias Pin Frequency
- ac-bias-intrpt: AC Bias Pin Transitions per Interrupt
- dma-burst-sz: DMA burst size
- bpp: Bits per pixel
- fdd: FIFO DMA Request Delay
- sync-edge: Horizontal and Vertical Sync Edge: 0=rising 1=falling
- sync-ctrl: Horizontal and Vertical Sync: Control: 0=ignore
- raster-order: Raster Data Order Select: 1=Most-to-least 0=Least-to-most
- fifo-th: DMA FIFO threshold
- display-timings: typical videomode of lcd panel. Multiple video modes
can be listed if the panel supports multiple timings, but the 'native-mode'
should be the preferred/default resolution. Refer to
Documentation/devicetree/bindings/video/display-timing.txt for display
timing binding details.
Recommended properties:
- pinctrl-names, pinctrl-0: the pincontrol settings to configure
muxing properly for pins that connect to TFP410 device
Example:
/* Settings for CDTech_S035Q01 / LCD3 cape: */
lcd3 {
compatible = "ti,tilcdc,panel";
pinctrl-names = "default";
pinctrl-0 = <&bone_lcd3_cape_lcd_pins>;
panel-info {
ac-bias = <255>;
ac-bias-intrpt = <0>;
dma-burst-sz = <16>;
bpp = <16>;
fdd = <0x80>;
sync-edge = <0>;
sync-ctrl = <1>;
raster-order = <0>;
fifo-th = <0>;
};
display-timings {
native-mode = <&timing0>;
timing0: 320x240 {
hactive = <320>;
vactive = <240>;
hback-porch = <21>;
hfront-porch = <58>;
hsync-len = <47>;
vback-porch = <11>;
vfront-porch = <23>;
vsync-len = <2>;
clock-frequency = <8000000>;
hsync-active = <0>;
vsync-active = <0>;
};
};
};

18
Documentation/devicetree/bindings/drm/tilcdc/slave.txt Normal file
View File

@ -0,0 +1,18 @@
Device-Tree bindings for tilcdc DRM encoder slave output driver
Required properties:
- compatible: value should be "ti,tilcdc,slave".
- i2c: the phandle for the i2c device the encoder slave is connected to
Recommended properties:
- pinctrl-names, pinctrl-0: the pincontrol settings to configure
muxing properly for pins that connect to TFP410 device
Example:
hdmi {
compatible = "ti,tilcdc,slave";
i2c = <&i2c0>;
pinctrl-names = "default";
pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
};

21
Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt Normal file
View File

@ -0,0 +1,21 @@
Device-Tree bindings for tilcdc DRM TFP410 output driver
Required properties:
- compatible: value should be "ti,tilcdc,tfp410".
- i2c: the phandle for the i2c device to use for DDC
Recommended properties:
- pinctrl-names, pinctrl-0: the pincontrol settings to configure
muxing properly for pins that connect to TFP410 device
- powerdn-gpio: the powerdown GPIO, pulled low to power down the
TFP410 device (for DPMS_OFF)
Example:
dvicape {
compatible = "ti,tilcdc,tfp410";
i2c = <&i2c2>;
pinctrl-names = "default";
pinctrl-0 = <&bone_dvi_cape_dvi_00A1_pins>;
powerdn-gpio = <&gpio2 31 0>;
};

21
Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt Normal file
View File

@ -0,0 +1,21 @@
Device-Tree bindings for tilcdc DRM driver
Required properties:
- compatible: value should be "ti,am33xx-tilcdc".
- interrupts: the interrupt number
- reg: base address and size of the LCDC device
Recommended properties:
- interrupt-parent: the phandle for the interrupt controller that
services interrupts for this device.
- ti,hwmods: Name of the hwmod associated to the LCDC
Example:
fb: fb@4830e000 {
compatible = "ti,am33xx-tilcdc";
reg = <0x4830e000 0x1000>;
interrupt-parent = <&intc>;
interrupts = <36>;
ti,hwmods = "lcdc";
};

20
Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt Normal file
View File

@ -0,0 +1,20 @@
Broadcom BCM2835 I2C controller
Required properties:
- compatible : Should be "brcm,bcm2835-i2c".
- reg: Should contain register location and length.
- interrupts: Should contain interrupt.
- clocks : The clock feeding the I2C controller.
Recommended properties:
- clock-frequency : desired I2C bus clock frequency in Hz.
Example:
i2c@20205000 {
compatible = "brcm,bcm2835-i2c";
reg = <0x7e205000 0x1000>;
interrupts = <2 21>;
clocks = <&clk_i2c>;
clock-frequency = <100000>;
};

2
Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
View File

@ -8,6 +8,8 @@ Required properties:
(b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c.
(c) "samsung, s3c2440-hdmiphy-i2c", for s3c2440-like i2c used
inside HDMIPHY block found on several samsung SoCs
(d) "samsung, exynos5440-i2c", for s3c2440-like i2c used
on EXYNOS5440 which does not need GPIO configuration.
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt number to the cpu.

48
Documentation/devicetree/bindings/leds/leds-pwm.txt Normal file
View File

@ -0,0 +1,48 @@
LED connected to PWM
Required properties:
- compatible : should be "pwm-leds".
Each LED is represented as a sub-node of the pwm-leds device. Each
node's name represents the name of the corresponding LED.
LED sub-node properties:
- pwms : PWM property to point to the PWM device (phandle)/port (id) and to
specify the period time to be used: <&phandle id period_ns>;
- pwm-names : (optional) Name to be used by the PWM subsystem for the PWM device
For the pwms and pwm-names property please refer to:
Documentation/devicetree/bindings/pwm/pwm.txt
- max-brightness : Maximum brightness possible for the LED
- label : (optional)
see Documentation/devicetree/bindings/leds/common.txt
- linux,default-trigger : (optional)
see Documentation/devicetree/bindings/leds/common.txt
Example:
twl_pwm: pwm {
/* provides two PWMs (id 0, 1 for PWM1 and PWM2) */
compatible = "ti,twl6030-pwm";
#pwm-cells = <2>;
};
twl_pwmled: pwmled {
/* provides one PWM (id 0 for Charing indicator LED) */
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};
pwmleds {
compatible = "pwm-leds";
kpad {
label = "omap4::keypad";
pwms = <&twl_pwm 0 7812500>;
max-brightness = <127>;
};
charging {
label = "omap4:green:chrg";
pwms = <&twl_pwmled 0 7812500>;
max-brightness = <255>;
};
};

33
Documentation/devicetree/bindings/leds/tca6507.txt Normal file
View File

@ -0,0 +1,33 @@
LEDs conected to tca6507
Required properties:
- compatible : should be : "ti,tca6507".
Each led is represented as a sub-node of the ti,tca6507 device.
LED sub-node properties:
- label : (optional) see Documentation/devicetree/bindings/leds/common.txt
- reg : number of LED line (could be from 0 to 6)
- linux,default-trigger : (optional)
see Documentation/devicetree/bindings/leds/common.txt
Examples:
tca6507@45 {
compatible = "ti,tca6507";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x45>;
led0: red-aux@0 {
label = "red:aux";
reg = <0x0>;
};
led1: green-aux@1 {
label = "green:aux";
reg = <0x5>;
linux,default-trigger = "default-on";
};
};

16
Documentation/devicetree/bindings/media/gpio-ir-receiver.txt Normal file
View File

@ -0,0 +1,16 @@
Device-Tree bindings for GPIO IR receiver
Required properties:
- compatible: should be "gpio-ir-receiver".
- gpios: specifies GPIO used for IR signal reception.
Optional properties:
- linux,rc-map-name: Linux specific remote control map name.
Example node:
ir: ir-receiver {
compatible = "gpio-ir-receiver";
gpios = <&gpio0 19 1>;
linux,rc-map-name = "rc-rc6-mce";
};

82
Documentation/devicetree/bindings/metag/meta-intc.txt Normal file
View File

@ -0,0 +1,82 @@
* Meta External Trigger Controller Binding
This binding specifies what properties must be available in the device tree
representation of a Meta external trigger controller.
Required properties:
- compatible: Specifies the compatibility list for the interrupt controller.
The type shall be <string> and the value shall include "img,meta-intc".
- num-banks: Specifies the number of interrupt banks (each of which can
handle 32 interrupt sources).
- interrupt-controller: The presence of this property identifies the node
as an interupt controller. No property value shall be defined.
- #interrupt-cells: Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 2.
- #address-cells: Specifies the number of cells needed to encode an
address. The type shall be <u32> and the value shall be 0. As such,
'interrupt-map' nodes do not have to specify a parent unit address.
Optional properties:
- no-mask: The controller doesn't have any mask registers.
* Interrupt Specifier Definition
Interrupt specifiers consists of 2 cells encoded as follows:
- <1st-cell>: The interrupt-number that identifies the interrupt source.
- <2nd-cell>: The Linux interrupt flags containing level-sense information,
encoded as follows:
1 = edge triggered
4 = level-sensitive
* Examples
Example 1:
/*
* Meta external trigger block
*/
intc: intc {
// This is an interrupt controller node.
interrupt-controller;
// No address cells so that 'interrupt-map' nodes which
// reference this interrupt controller node do not need a parent
// address specifier.
#address-cells = <0>;
// Two cells to encode interrupt sources.
#interrupt-cells = <2>;
// Number of interrupt banks
num-banks = <2>;
// No HWMASKEXT is available (specify on Chorus2 and Comet ES1)
no-mask;
// Compatible with Meta hardware trigger block.
compatible = "img,meta-intc";
};
Example 2:
/*
* An interrupt generating device that is wired to a Meta external
* trigger block.
*/
uart1: uart@0x02004c00 {
// Interrupt source '5' that is level-sensitive.
// Note that there are only two cells as specified in the
// interrupt parent's '#interrupt-cells' property.
interrupts = <5 4 /* level */>;
// The interrupt controller that this device is wired to.
interrupt-parent = <&intc>;
};

64
Documentation/devicetree/bindings/mfd/max8925.txt Normal file
View File

@ -0,0 +1,64 @@
* Maxim max8925 Power Management IC
Required parent device properties:
- compatible : "maxim,max8925"
- reg : the I2C slave address for the max8925 chip
- interrupts : IRQ line for the max8925 chip
- interrupt-controller: describes the max8925 as an interrupt
controller (has its own domain)
- #interrupt-cells : should be 1.
- The cell is the max8925 local IRQ number
Optional parent device properties:
- maxim,tsc-irq: there are 2 IRQ lines for max8925, one is indicated in
interrupts property, the other is indicated here.
max8925 consists of a large and varied group of sub-devices:
Device Supply Names Description
------ ------------ -----------
max8925-onkey : : On key
max8925-rtc : : RTC
max8925-regulator : : Regulators
max8925-backlight : : Backlight
max8925-touch : : Touchscreen
max8925-power : : Charger
Example:
pmic: max8925@3c {
compatible = "maxim,max8925";
reg = <0x3c>;
interrupts = <1>;
interrupt-parent = <&intcmux4>;
interrupt-controller;
#interrupt-cells = <1>;
maxim,tsc-irq = <0>;
regulators {
SDV1 {
regulator-min-microvolt = <637500>;
regulator-max-microvolt = <1425000>;
regulator-boot-on;
regulator-always-on;
};
LDO1 {
regulator-min-microvolt = <750000>;
regulator-max-microvolt = <3900000>;
regulator-boot-on;
regulator-always-on;
};
};
backlight {
maxim,max8925-dual-string = <0>;
};
charger {
batt-detect = <0>;
topoff-threshold = <1>;
fast-charge = <7>;
no-temp-support = <0>;
no-insert-detect = <0>;
};
};

47
Documentation/devicetree/bindings/mips/cpu_irq.txt Normal file
View File

@ -0,0 +1,47 @@
MIPS CPU interrupt controller
On MIPS the mips_cpu_intc_init() helper can be used to initialize the 8 CPU
IRQs from a devicetree file and create a irq_domain for IRQ controller.
With the irq_domain in place we can describe how the 8 IRQs are wired to the
platforms internal interrupt controller cascade.
Below is an example of a platform describing the cascade inside the devicetree
and the code used to load it inside arch_init_irq().
Required properties:
- compatible : Should be "mti,cpu-interrupt-controller"
Example devicetree:
cpu-irq: cpu-irq@0 {
#address-cells = <0>;
interrupt-controller;
#interrupt-cells = <1>;
compatible = "mti,cpu-interrupt-controller";
};
intc: intc@200 {
compatible = "ralink,rt2880-intc";
reg = <0x200 0x100>;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&cpu-irq>;
interrupts = <2>;
};
Example platform irq.c:
static struct of_device_id __initdata of_irq_ids[] = {
{ .compatible = "mti,cpu-interrupt-controller", .data = mips_cpu_intc_init },
{ .compatible = "ralink,rt2880-intc", .data = intc_of_init },
{},
};
void __init arch_init_irq(void)
{
of_irq_init(of_irq_ids);
}

18
Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt Normal file
View File

@ -0,0 +1,18 @@
Broadcom BCM2835 SDHCI controller
This file documents differences between the core properties described
by mmc.txt and the properties that represent the BCM2835 controller.
Required properties:
- compatible : Should be "brcm,bcm2835-sdhci".
- clocks : The clock feeding the SDHCI controller.
Example:
sdhci: sdhci {
compatible = "brcm,bcm2835-sdhci";
reg = <0x7e300000 0x100>;
interrupts = <2 30>;
clocks = <&clk_mmc>;
bus-width = <4>;
};

34
Documentation/devicetree/bindings/mmc/mmc.txt
View File

@ -6,23 +6,45 @@ Interpreted by the OF core:
- reg: Registers location and length.
- interrupts: Interrupts used by the MMC controller.
Required properties:
- bus-width: Number of data lines, can be <1>, <4>, or <8>
Card detection:
If no property below is supplied, standard SDHCI card detect is used.
If no property below is supplied, host native card detect is used.
Only one of the properties in this section should be supplied:
- broken-cd: There is no card detection available; polling must be used.
- cd-gpios: Specify GPIOs for card detection, see gpio binding
- non-removable: non-removable slot (like eMMC); assume always present.
Optional properties:
- bus-width: Number of data lines, can be <1>, <4>, or <8>. The default
will be <1> if the property is absent.
- wp-gpios: Specify GPIOs for write protection, see gpio binding
- cd-inverted: when present, polarity on the cd gpio line is inverted
- wp-inverted: when present, polarity on the wp gpio line is inverted
- cd-inverted: when present, polarity on the CD line is inverted. See the note
below for the case, when a GPIO is used for the CD line
- wp-inverted: when present, polarity on the WP line is inverted. See the note
below for the case, when a GPIO is used for the WP line
- max-frequency: maximum operating clock frequency
- no-1-8-v: when present, denotes that 1.8v card voltage is not supported on
this system, even if the controller claims it is.
- cap-sd-highspeed: SD high-speed timing is supported
- cap-mmc-highspeed: MMC high-speed timing is supported
- cap-power-off-card: powering off the card is safe
- cap-sdio-irq: enable SDIO IRQ signalling on this interface
*NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
polarity properties, we have to fix the meaning of the "normal" and "inverted"
line levels. We choose to follow the SDHCI standard, which specifies both those
lines as "active low." Therefore, using the "cd-inverted" property means, that
the CD line is active high, i.e. it is high, when a card is inserted. Similar
logic applies to the "wp-inverted" property.
CD and WP lines can be implemented on the hardware in one of two ways: as GPIOs,
specified in cd-gpios and wp-gpios properties, or as dedicated pins. Polarity of
dedicated pins can be specified, using *-inverted properties. GPIO polarity can
also be specified using the OF_GPIO_ACTIVE_LOW flag. This creates an ambiguity
in the latter case. We choose to use the XOR logic for GPIO CD and WP lines.
This means, the two properties are "superimposed," for example leaving the
OF_GPIO_ACTIVE_LOW flag clear and specifying the respective *-inverted
property results in a double-inversion and actually means the "normal" line
polarity is in effect.
Optional SDIO properties:
- keep-power-in-suspend: Preserves card power during a suspend/resume cycle

17
Documentation/devicetree/bindings/mmc/orion-sdio.txt Normal file
View File

@ -0,0 +1,17 @@
* Marvell orion-sdio controller
This file documents differences between the core properties in mmc.txt
and the properties used by the orion-sdio driver.
- compatible: Should be "marvell,orion-sdio"
- clocks: reference to the clock of the SDIO interface
Example:
mvsdio@d00d4000 {
compatible = "marvell,orion-sdio";
reg = <0xd00d4000 0x200>;
interrupts = <54>;
clocks = <&gateclk 17>;
status = "disabled";
};

12
Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
View File

@ -26,8 +26,16 @@ Required Properties:
* bus-width: as documented in mmc core bindings.
* wp-gpios: specifies the write protect gpio line. The format of the
gpio specifier depends on the gpio controller. If the write-protect
line is not available, this property is optional.
gpio specifier depends on the gpio controller. If a GPIO is not used
for write-protect, this property is optional.
* disable-wp: If the wp-gpios property isn't present then (by default)
we'd assume that the write protect is hooked up directly to the
controller's special purpose write protect line (accessible via
the WRTPRT register). However, it's possible that we simply don't
want write protect. In that case specify 'disable-wp'.
NOTE: This property is not required for slots known to always
connect to eMMC or SDIO cards.
Optional properties:

20
Documentation/devicetree/bindings/mmc/tmio_mmc.txt Normal file
View File

@ -0,0 +1,20 @@
* Toshiba Mobile IO SD/MMC controller
The tmio-mmc driver doesn't probe its devices actively, instead its binding to
devices is managed by either MFD drivers or by the sh_mobile_sdhi platform
driver. Those drivers supply the tmio-mmc driver with platform data, that either
describe hardware capabilities, known to them, or are obtained by them from
their own platform data or from their DT information. In the latter case all
compulsory and any optional properties, common to all SD/MMC drivers, as
described in mmc.txt, can be used. Additionally the following tmio_mmc-specific
optional bindings can be used.
Optional properties:
- toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
When used with Renesas SDHI hardware, the following compatibility strings
configure various model-specific properties:
"renesas,sh7372-sdhi": (default) compatible with SH7372
"renesas,r8a7740-sdhi": compatible with R8A7740: certain MMC/SD commands have to
wait for the interface to become idle.

16
Documentation/devicetree/bindings/mtd/elm.txt Normal file
View File

@ -0,0 +1,16 @@
Error location module
Required properties:
- compatible: Must be "ti,am33xx-elm"
- reg: physical base address and size of the registers map.
- interrupts: Interrupt number for the elm.
Optional properties:
- ti,hwmods: Name of the hwmod associated to the elm
Example:
elm: elm@0 {
compatible = "ti,am3352-elm";
reg = <0x48080000 0x2000>;
interrupts = <4>;
};

3
Documentation/devicetree/bindings/mtd/mtd-physmap.txt
View File

@ -26,6 +26,9 @@ file systems on embedded devices.
- linux,mtd-name: allow to specify the mtd name for retro capability with
physmap-flash drivers as boot loader pass the mtd partition via the old
device name physmap-flash.
- use-advanced-sector-protection: boolean to enable support for the
advanced sector protection (Spansion: PPB - Persistent Protection
Bits) locking.
For JEDEC compatible devices, the following additional properties
are defined:

18
Documentation/devicetree/bindings/power_supply/max8925_batter.txt Normal file
View File

@ -0,0 +1,18 @@
max8925-battery bindings
~~~~~~~~~~~~~~~~
Optional properties :
- batt-detect: whether support battery detect
- topoff-threshold: set charging current in topoff mode
- fast-charge: set charging current in fast mode
- no-temp-support: whether support temperature protection detect
- no-insert-detect: whether support insert detect
Example:
charger {
batt-detect = <0>;
topoff-threshold = <1>;
fast-charge = <7>;
no-temp-support = <0>;
no-insert-detect = <0>;
};

13
Documentation/devicetree/bindings/powerpc/fsl/guts.txt
View File

@ -17,9 +17,20 @@ Recommended properties:
contains a functioning "reset control register" (i.e. the board
is wired to reset upon setting the HRESET_REQ bit in this register).
Example:
- fsl,liodn-bits : Indicates the number of defined bits in the LIODN
registers, for those SOCs that have a PAMU device.
Examples:
global-utilities@e0000 { /* global utilities block */
compatible = "fsl,mpc8548-guts";
reg = <e0000 1000>;
fsl,has-rstcr;
};
guts: global-utilities@e0000 {
compatible = "fsl,qoriq-device-config-1.0";
reg = <0xe0000 0xe00>;
fsl,has-rstcr;
#sleep-cells = <1>;
fsl,liodn-bits = <12>;
};

140
Documentation/devicetree/bindings/powerpc/fsl/pamu.txt Normal file
View File

@ -0,0 +1,140 @@
Freescale Peripheral Management Access Unit (PAMU) Device Tree Binding
DESCRIPTION
The PAMU is an I/O MMU that provides device-to-memory access control and
address translation capabilities.
Required properties:
- compatible : <string>
First entry is a version-specific string, such as
"fsl,pamu-v1.0". The second is "fsl,pamu".
- ranges : <prop-encoded-array>
A standard property. Utilized to describe the memory mapped
I/O space utilized by the controller. The size should
be set to the total size of the register space of all
physically present PAMU controllers. For example, for
PAMU v1.0, on an SOC that has five PAMU devices, the size
is 0x5000.
- interrupts : <prop-encoded-array>
Interrupt mappings. The first tuple is the normal PAMU
interrupt, used for reporting access violations. The second
is for PAMU hardware errors, such as PAMU operation errors
and ECC errors.
- #address-cells: <u32>
A standard property.
- #size-cells : <u32>
A standard property.
Optional properties:
- reg : <prop-encoded-array>
A standard property. It represents the CCSR registers of
all child PAMUs combined. Include it to provide support
for legacy drivers.
- interrupt-parent : <phandle>
Phandle to interrupt controller
Child nodes:
Each child node represents one PAMU controller. Each SOC device that is
connected to a specific PAMU device should have a "fsl,pamu-phandle" property
that links to the corresponding specific child PAMU controller.
- reg : <prop-encoded-array>
A standard property. Specifies the physical address and
length (relative to the parent 'ranges' property) of this
PAMU controller's configuration registers. The size should
be set to the size of this PAMU controllers's register space.
For PAMU v1.0, this size is 0x1000.
- fsl,primary-cache-geometry
: <prop-encoded-array>
Two cells that specify the geometry of the primary PAMU
cache. The first is the number of cache lines, and the
second is the number of "ways". For direct-mapped caches,
specify a value of 1.
- fsl,secondary-cache-geometry
: <prop-encoded-array>
Two cells that specify the geometry of the secondary PAMU
cache. The first is the number of cache lines, and the
second is the number of "ways". For direct-mapped caches,
specify a value of 1.
Device nodes:
Devices that have LIODNs need to specify links to the parent PAMU controller
(the actual PAMU controller that this device is connected to) and a pointer to
the LIODN register, if applicable.
- fsl,iommu-parent
: <phandle>
Phandle to the single, specific PAMU controller node to which
this device is connect. The PAMU topology is represented in
the device tree to assist code that dynamically determines the
best LIODN values to minimize PAMU cache thrashing.
- fsl,liodn-reg : <prop-encoded-array>
Two cells that specify the location of the LIODN register
for this device. Required for devices that have a single
LIODN. The first cell is a phandle to a node that contains
the registers where the LIODN is to be set. The second is
the offset from the first "reg" resource of the node where
the specific LIODN register is located.
Example:
iommu@20000 {
compatible = "fsl,pamu-v1.0", "fsl,pamu";
reg = <0x20000 0x5000>;
ranges = <0 0x20000 0x5000>;
#address-cells = <1>;
#size-cells = <1>;
interrupts = <
24 2 0 0
16 2 1 30>;
pamu0: pamu@0 {
reg = <0 0x1000>;
fsl,primary-cache-geometry = <32 1>;
fsl,secondary-cache-geometry = <128 2>;
};
pamu1: pamu@1000 {
reg = <0x1000 0x1000>;
fsl,primary-cache-geometry = <32 1>;
fsl,secondary-cache-geometry = <128 2>;
};
pamu2: pamu@2000 {
reg = <0x2000 0x1000>;
fsl,primary-cache-geometry = <32 1>;
fsl,secondary-cache-geometry = <128 2>;
};
pamu3: pamu@3000 {
reg = <0x3000 0x1000>;
fsl,primary-cache-geometry = <32 1>;
fsl,secondary-cache-geometry = <128 2>;
};
pamu4: pamu@4000 {
reg = <0x4000 0x1000>;
fsl,primary-cache-geometry = <32 1>;
fsl,secondary-cache-geometry = <128 2>;
};
};
guts: global-utilities@e0000 {
compatible = "fsl,qoriq-device-config-1.0";
reg = <0xe0000 0xe00>;
fsl,has-rstcr;
#sleep-cells = <1>;
fsl,liodn-bits = <12>;
};
/include/ "qoriq-dma-0.dtsi"
dma@100300 {
fsl,iommu-parent = <&pamu0>;
fsl,liodn-reg = <&guts 0x584>; /* DMA2LIODNR */
};

18
Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt Normal file
View File

@ -0,0 +1,18 @@
Atmel TCB PWM controller
Required properties:
- compatible: should be "atmel,tcb-pwm"
- #pwm-cells: Should be 3. The first cell specifies the per-chip index
of the PWM to use, the second cell is the period in nanoseconds and
bit 0 in the third cell is used to encode the polarity of PWM output.
Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity &
set to 0 for normal polarity.
- tc-block: The Timer Counter block to use as a PWM chip.
Example:
pwm {
compatible = "atmel,tcb-pwm";
#pwm-cells = <3>;
tc-block = <1>;
};

9
Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
View File

@ -3,14 +3,17 @@ VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller
Required properties:
- compatible: should be "via,vt8500-pwm"
- reg: physical base address and length of the controller's registers
- #pwm-cells: should be 2. The first cell specifies the per-chip index
of the PWM to use and the second cell is the period in nanoseconds.
- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
First cell specifies the per-chip index of the PWM to use, the second
cell is the period in nanoseconds and bit 0 in the third cell is used to
encode the polarity of PWM output. Set bit 0 of the third in PWM specifier
to 1 for inverse polarity & set to 0 for normal polarity.
- clocks: phandle to the PWM source clock
Example:
pwm1: pwm@d8220000 {
#pwm-cells = <2>;
#pwm-cells = <3>;
compatible = "via,vt8500-pwm";
reg = <0xd8220000 0x1000>;
clocks = <&clkpwm>;

122
Documentation/devicetree/bindings/regulator/tps65090.txt Normal file
View File

@ -0,0 +1,122 @@
TPS65090 regulators
Required properties:
- compatible: "ti,tps65090"
- reg: I2C slave address
- interrupts: the interrupt outputs of the controller
- regulators: A node that houses a sub-node for each regulator within the
device. Each sub-node is identified using the node's name, with valid
values listed below. The content of each sub-node is defined by the
standard binding for regulators; see regulator.txt.
dcdc[1-3], fet[1-7] and ldo[1-2] respectively.
- vsys[1-3]-supply: The input supply for DCDC[1-3] respectively.
- infet[1-7]-supply: The input supply for FET[1-7] respectively.
- vsys-l[1-2]-supply: The input supply for LDO[1-2] respectively.
Optional properties:
- ti,enable-ext-control: This is applicable for DCDC1, DCDC2 and DCDC3.
If DCDCs are externally controlled then this property should be there.
- "dcdc-ext-control-gpios: This is applicable for DCDC1, DCDC2 and DCDC3.
If DCDCs are externally controlled and if it is from GPIO then GPIO
number should be provided. If it is externally controlled and no GPIO
entry then driver will just configure this rails as external control
and will not provide any enable/disable APIs.
Each regulator is defined using the standard binding for regulators.
Example:
tps65090@48 {
compatible = "ti,tps65090";
reg = <0x48>;
interrupts = <0 88 0x4>;
vsys1-supply = <&some_reg>;
vsys2-supply = <&some_reg>;
vsys3-supply = <&some_reg>;
infet1-supply = <&some_reg>;
infet2-supply = <&some_reg>;
infet3-supply = <&some_reg>;
infet4-supply = <&some_reg>;
infet5-supply = <&some_reg>;
infet6-supply = <&some_reg>;
infet7-supply = <&some_reg>;
vsys_l1-supply = <&some_reg>;
vsys_l2-supply = <&some_reg>;
regulators {
dcdc1 {
regulator-name = "dcdc1";
regulator-boot-on;
regulator-always-on;
ti,enable-ext-control;
dcdc-ext-control-gpios = <&gpio 10 0>;
};
dcdc2 {
regulator-name = "dcdc2";
regulator-boot-on;
regulator-always-on;
};
dcdc3 {
regulator-name = "dcdc3";
regulator-boot-on;
regulator-always-on;
};
fet1 {
regulator-name = "fet1";
regulator-boot-on;
regulator-always-on;
};
fet2 {
regulator-name = "fet2";
regulator-boot-on;
regulator-always-on;
};
fet3 {
regulator-name = "fet3";
regulator-boot-on;
regulator-always-on;
};
fet4 {
regulator-name = "fet4";
regulator-boot-on;
regulator-always-on;
};
fet5 {
regulator-name = "fet5";
regulator-boot-on;
regulator-always-on;
};
fet6 {
regulator-name = "fet6";
regulator-boot-on;
regulator-always-on;
};
fet7 {
regulator-name = "fet7";
regulator-boot-on;
regulator-always-on;
};
ldo1 {
regulator-name = "ldo1";
regulator-boot-on;
regulator-always-on;
};
ldo2 {
regulator-name = "ldo2";
regulator-boot-on;
regulator-always-on;
};
};
};

16
Documentation/devicetree/bindings/serial/lantiq_asc.txt Normal file
View File

@ -0,0 +1,16 @@
Lantiq SoC ASC serial controller
Required properties:
- compatible : Should be "lantiq,asc"
- reg : Address and length of the register set for the device
- interrupts: the 3 (tx rx err) interrupt numbers. The interrupt specifier
depends on the interrupt-parent interrupt controller.
Example:
asc1: serial@E100C00 {
compatible = "lantiq,asc";
reg = <0xE100C00 0x400>;
interrupt-parent = <&icu0>;
interrupts = <112 113 114>;
};

18
Documentation/devicetree/bindings/thermal/dove-thermal.txt Normal file
View File

@ -0,0 +1,18 @@
* Dove Thermal
This driver is for Dove SoCs which contain a thermal sensor.
Required properties:
- compatible : "marvell,dove-thermal"
- reg : Address range of the thermal registers
The reg properties should contain two ranges. The first is for the
three Thermal Manager registers, while the second range contains the
Thermal Diode Control Registers.
Example:
thermal@10078 {
compatible = "marvell,dove-thermal";
reg = <0xd001c 0x0c>, <0xd005c 0x08>;
};

15
Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt Normal file
View File

@ -0,0 +1,15 @@
* Kirkwood Thermal
This version is for Kirkwood 88F8262 & 88F6283 SoCs. Other kirkwoods
don't contain a thermal sensor.
Required properties:
- compatible : "marvell,kirkwood-thermal"
- reg : Address range of the thermal registers
Example:
thermal@10078 {
compatible = "marvell,kirkwood-thermal";
reg = <0x10078 0x4>;
};

29
Documentation/devicetree/bindings/thermal/rcar-thermal.txt Normal file
View File

@ -0,0 +1,29 @@
* Renesas R-Car Thermal
Required properties:
- compatible : "renesas,rcar-thermal"
- reg : Address range of the thermal registers.
The 1st reg will be recognized as common register
if it has "interrupts".
Option properties:
- interrupts : use interrupt
Example (non interrupt support):
thermal@e61f0100 {
compatible = "renesas,rcar-thermal";
reg = <0xe61f0100 0x38>;
};
Example (interrupt support):
thermal@e61f0000 {
compatible = "renesas,rcar-thermal";
reg = <0xe61f0000 0x14
0xe61f0100 0x38
0xe61f0200 0x38
0xe61f0300 0x38>;
interrupts = <0 69 4>;
};

11
Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt → Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
View File

@ -1,10 +1,13 @@
Marvell Armada 370 and Armada XP Global Timers
----------------------------------------------
Marvell Armada 370 and Armada XP Timers
---------------------------------------
Required properties:
- compatible: Should be "marvell,armada-370-xp-timer"
- interrupts: Should contain the list of Global Timer interrupts
- reg: Should contain the base address of the Global Timer registers
- interrupts: Should contain the list of Global Timer interrupts and
then local timer interrupts
- reg: Should contain location and length for timers register. First
pair for the Global Timer registers, second pair for the
local/private timers.
- clocks: clock driving the timer hardware
Optional properties:

10
Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt Normal file
View File

@ -0,0 +1,10 @@
88pm860x-backlight bindings
Optional properties:
- maxim,max8925-dual-string: whether support dual string
Example:
backlights {
maxim,max8925-dual-string = <0>;
};

109
Documentation/devicetree/bindings/video/display-timing.txt Normal file
View File

@ -0,0 +1,109 @@
display-timing bindings
=======================
display-timings node
--------------------
required properties:
- none
optional properties:
- native-mode: The native mode for the display, in case multiple modes are
provided. When omitted, assume the first node is the native.
timing subnode
--------------
required properties:
- hactive, vactive: display resolution
- hfront-porch, hback-porch, hsync-len: horizontal display timing parameters
in pixels
vfront-porch, vback-porch, vsync-len: vertical display timing parameters in
lines
- clock-frequency: display clock in Hz
optional properties:
- hsync-active: hsync pulse is active low/high/ignored
- vsync-active: vsync pulse is active low/high/ignored
- de-active: data-enable pulse is active low/high/ignored
- pixelclk-active: with
- active high = drive pixel data on rising edge/
sample data on falling edge
- active low = drive pixel data on falling edge/
sample data on rising edge
- ignored = ignored
- interlaced (bool): boolean to enable interlaced mode
- doublescan (bool): boolean to enable doublescan mode
All the optional properties that are not bool follow the following logic:
<1>: high active
<0>: low active
omitted: not used on hardware
There are different ways of describing the capabilities of a display. The
devicetree representation corresponds to the one commonly found in datasheets
for displays. If a display supports multiple signal timings, the native-mode
can be specified.
The parameters are defined as:
+----------+-------------------------------------+----------+-------+
| | ↑ | | |
| | |vback_porch | | |
| | ↓ | | |
+----------#######################################----------+-------+
| # ↑ # | |
| # | # | |
| hback # | # hfront | hsync |
| porch # | hactive # porch | len |
|<-------->#<-------+--------------------------->#<-------->|<----->|
| # | # | |
| # |vactive # | |
| # | # | |
| # ↓ # | |
+----------#######################################----------+-------+
| | ↑ | | |
| | |vfront_porch | | |
| | ↓ | | |
+----------+-------------------------------------+----------+-------+
| | ↑ | | |
| | |vsync_len | | |
| | ↓ | | |
+----------+-------------------------------------+----------+-------+
Example:
display-timings {
native-mode = <&timing0>;
timing0: 1080p24 {
/* 1920x1080p24 */
clock-frequency = <52000000>;
hactive = <1920>;
vactive = <1080>;
hfront-porch = <25>;
hback-porch = <25>;
hsync-len = <25>;
vback-porch = <2>;
vfront-porch = <2>;
vsync-len = <2>;
hsync-active = <1>;
};
};
Every required property also supports the use of ranges, so the commonly used
datasheet description with minimum, typical and maximum values can be used.
Example:
timing1: timing {
/* 1920x1080p24 */
clock-frequency = <148500000>;
hactive = <1920>;
vactive = <1080>;
hsync-len = <0 44 60>;
hfront-porch = <80 88 95>;
hback-porch = <100 148 160>;
vfront-porch = <0 4 6>;
vback-porch = <0 36 50>;
vsync-len = <0 5 6>;
};

19
Documentation/devicetree/bindings/w1/fsl-imx-owire.txt Normal file
View File

@ -0,0 +1,19 @@
* Freescale i.MX One wire bus master controller
Required properties:
- compatible : should be "fsl,imx21-owire"
- reg : Address and length of the register set for the device
Optional properties:
- clocks : phandle of clock that supplies the module (required if platform
clock bindings use device tree)
Example:
- From imx53.dtsi:
owire: owire@63fa4000 {
compatible = "fsl,imx53-owire", "fsl,imx21-owire";
reg = <0x63fa4000 0x4000>;
clocks = <&clks 159>;
status = "disabled";
};

9
Documentation/devicetree/bindings/watchdog/atmel-at91rm9200-wdt.txt Normal file
View File

@ -0,0 +1,9 @@
Atmel AT91RM9200 System Timer Watchdog
Required properties:
- compatible: must be "atmel,at91sam9260-wdt".
Example:
watchdog@fffffd00 {
compatible = "atmel,at91rm9200-wdt";
};

4
Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
View File

@ -7,9 +7,13 @@ Required properties:
- reg: physical base address of the controller and length of memory mapped
region.
Optional properties:
- timeout-sec: contains the watchdog timeout in seconds.
Example:
watchdog@fffffd40 {
compatible = "atmel,at91sam9260-wdt";
reg = <0xfffffd40 0x10>;
timeout-sec = <10>;
};

5
Documentation/devicetree/bindings/watchdog/marvel.txt
View File

@ -5,10 +5,15 @@ Required Properties:
- Compatibility : "marvell,orion-wdt"
- reg : Address of the timer registers
Optional properties:
- timeout-sec : Contains the watchdog timeout in seconds
Example:
wdt@20300 {
compatible = "marvell,orion-wdt";
reg = <0x20300 0x28>;
timeout-sec = <10>;
status = "okay";
};

4
Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt
View File

@ -5,9 +5,13 @@ Required properties:
- reg: physical base address of the controller and length of memory mapped
region.
Optional properties:
- timeout-sec: contains the watchdog timeout in seconds.
Example:
watchdog@4003C000 {
compatible = "nxp,pnx4008-wdt";
reg = <0x4003C000 0x1000>;
timeout-sec = <10>;
};

13
Documentation/devicetree/bindings/watchdog/qca-ar7130-wdt.txt Normal file
View File

@ -0,0 +1,13 @@
* Qualcomm Atheros AR7130 Watchdog Timer (WDT) Controller
Required properties:
- compatible: must be "qca,ar7130-wdt"
- reg: physical base address of the controller and length of memory mapped
region.
Example:
wdt@18060008 {
compatible = "qca,ar9330-wdt", "qca,ar7130-wdt";
reg = <0x18060008 0x8>;
};

3
Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
View File

@ -9,3 +9,6 @@ Required properties:
- reg : base physical address of the controller and length of memory mapped
region.
- interrupts : interrupt number to the cpu.
Optional properties:
- timeout-sec : contains the watchdog timeout in seconds.

6
Documentation/dma-buf-sharing.txt
View File

@ -302,7 +302,11 @@ Access to a dma_buf from the kernel context involves three steps:
void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
The vmap call can fail if there is no vmap support in the exporter, or if it
runs out of vmalloc space. Fallback to kmap should be implemented.
runs out of vmalloc space. Fallback to kmap should be implemented. Note that
the dma-buf layer keeps a reference count for all vmap access and calls down
into the exporter's vmap function only when no vmapping exists, and only
unmaps it once. Protection against concurrent vmap/vunmap calls is provided
by taking the dma_buf->lock mutex.
3. Finish access

17
Documentation/dvb/get_dvb_firmware
View File

@ -23,7 +23,7 @@ use IO::Handle;
@components = ( "sp8870", "sp887x", "tda10045", "tda10046",
"tda10046lifeview", "av7110", "dec2000t", "dec2540t",
"dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
"dec3000s", "vp7041", "vp7049", "dibusb", "nxt2002", "nxt2004",
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
"af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
@ -289,6 +289,19 @@ sub vp7041 {
$outfile;
}
sub vp7049 {
my $fwfile = "dvb-usb-vp7049-0.95.fw";
my $url = "http://ao2.it/sites/default/files/blog/2012/11/06/linux-support-digicom-digitune-s-vp7049-udtt7049/$fwfile";
my $hash = "5609fd295168aea88b25ff43a6f79c36";
checkstandard();
wgetfile($fwfile, $url);
verify($fwfile, $hash);
$fwfile;
}
sub dibusb {
my $url = "http://www.linuxtv.org/downloads/firmware/dvb-usb-dibusb-5.0.0.11.fw";
my $outfile = "dvb-dibusb-5.0.0.11.fw";
@ -677,7 +690,7 @@ sub drxk_terratec_h5 {
}
sub drxk_terratec_htc_stick {
my $url = "http://ftp.terratec.de/Receiver/Cinergy_HTC_Stick/Updates/";
my $url = "http://ftp.terratec.de/Receiver/Cinergy_HTC_Stick/Updates/History/";
my $zipfile = "Cinergy_HTC_Stick_Drv_5.09.1202.00_XP_Vista_7.exe";
my $hash = "6722a2442a05423b781721fbc069ed5e";
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0);

2
Documentation/filesystems/Locking
View File

@ -10,6 +10,7 @@ be able to use diff(1).
--------------------------- dentry_operations --------------------------
prototypes:
int (*d_revalidate)(struct dentry *, unsigned int);
int (*d_weak_revalidate)(struct dentry *, unsigned int);
int (*d_hash)(const struct dentry *, const struct inode *,
struct qstr *);
int (*d_compare)(const struct dentry *, const struct inode *,
@ -25,6 +26,7 @@ prototypes:
locking rules:
rename_lock ->d_lock may block rcu-walk
d_revalidate: no no yes (ref-walk) maybe
d_weak_revalidate:no no yes no
d_hash no no no maybe
d_compare: yes no no maybe
d_delete: no yes no no

4
Documentation/filesystems/porting
View File

@ -441,3 +441,7 @@ d_make_root() drops the reference to inode if dentry allocation fails.
two, it gets "is it an O_EXCL or equivalent?" boolean argument. Note that
local filesystems can ignore tha argument - they are guaranteed that the
object doesn't exist. It's remote/distributed ones that might care...
--
[mandatory]
FS_REVAL_DOT is gone; if you used to have it, add ->d_weak_revalidate()
in your dentry operations instead.

24
Documentation/filesystems/vfs.txt
View File

@ -900,6 +900,7 @@ defined:
struct dentry_operations {
int (*d_revalidate)(struct dentry *, unsigned int);
int (*d_weak_revalidate)(struct dentry *, unsigned int);
int (*d_hash)(const struct dentry *, const struct inode *,
struct qstr *);
int (*d_compare)(const struct dentry *, const struct inode *,
@ -915,8 +916,13 @@ struct dentry_operations {
d_revalidate: called when the VFS needs to revalidate a dentry. This
is called whenever a name look-up finds a dentry in the
dcache. Most filesystems leave this as NULL, because all their
dentries in the dcache are valid
dcache. Most local filesystems leave this as NULL, because all their
dentries in the dcache are valid. Network filesystems are different
since things can change on the server without the client necessarily
being aware of it.
This function should return a positive value if the dentry is still
valid, and zero or a negative error code if it isn't.
d_revalidate may be called in rcu-walk mode (flags & LOOKUP_RCU).
If in rcu-walk mode, the filesystem must revalidate the dentry without
@ -927,6 +933,20 @@ struct dentry_operations {
If a situation is encountered that rcu-walk cannot handle, return
-ECHILD and it will be called again in ref-walk mode.
d_weak_revalidate: called when the VFS needs to revalidate a "jumped" dentry.
This is called when a path-walk ends at dentry that was not acquired by
doing a lookup in the parent directory. This includes "/", "." and "..",
as well as procfs-style symlinks and mountpoint traversal.
In this case, we are less concerned with whether the dentry is still
fully correct, but rather that the inode is still valid. As with
d_revalidate, most local filesystems will set this to NULL since their
dcache entries are always valid.
This function has the same return code semantics as d_revalidate.
d_weak_revalidate is only called after leaving rcu-walk mode.
d_hash: called when the VFS adds a dentry to the hash table. The first
dentry passed to d_hash is the parent directory that the name is
to be hashed into. The inode is the dentry's inode.

2
Documentation/i2c/busses/i2c-i801
View File

@ -22,6 +22,8 @@ Supported adapters:
* Intel Panther Point (PCH)
* Intel Lynx Point (PCH)
* Intel Lynx Point-LP (PCH)
* Intel Avoton (SOC)
* Intel Wellsburg (PCH)
Datasheets: Publicly available at the Intel website
On Intel Patsburg and later chipsets, both the normal host SMBus controller

36
Documentation/i2c/busses/i2c-ismt Normal file
View File

@ -0,0 +1,36 @@
Kernel driver i2c-ismt
Supported adapters:
* Intel S12xx series SOCs
Authors:
Bill Brown <bill.e.brown@intel.com>
Module Parameters
-----------------
* bus_speed (unsigned int)
Allows changing of the bus speed. Normally, the bus speed is set by the BIOS
and never needs to be changed. However, some SMBus analyzers are too slow for
monitoring the bus during debug, thus the need for this module parameter.
Specify the bus speed in kHz.
Available bus frequency settings:
0 no change
80 kHz
100 kHz
400 kHz
1000 kHz
Description
-----------
The S12xx series of SOCs have a pair of integrated SMBus 2.0 controllers
targeted primarily at the microserver and storage markets.
The S12xx series contain a pair of PCI functions. An output of lspci will show
something similar to the following:
00:13.0 System peripheral: Intel Corporation Centerton SMBus 2.0 Controller 0
00:13.1 System peripheral: Intel Corporation Centerton SMBus 2.0 Controller 1

9
Documentation/i2c/busses/i2c-sis630
View File

@ -4,9 +4,11 @@ Supported adapters:
* Silicon Integrated Systems Corp (SiS)
630 chipset (Datasheet: available at http://www.sfr-fresh.com/linux)
730 chipset
964 chipset
* Possible other SiS chipsets ?
Author: Alexander Malysh <amalysh@web.de>
Amaury Decrême <amaury.decreme@gmail.com> - SiS964 support
Module Parameters
-----------------
@ -18,6 +20,7 @@ Module Parameters
* high_clock = [1|0] Forcibly set Host Master Clock to 56KHz (default,
what your BIOS use). DANGEROUS! This should be a bit
faster, but freeze some systems (i.e. my Laptop).
SIS630/730 chip only.
Description
@ -36,6 +39,12 @@ or like this:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 730 Host (rev 02)
00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
or like this:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 760/M760 Host (rev 02)
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO]
LPC Controller (rev 36)
in your 'lspci' output , then this driver is for your chipset.
Thank You

4
Documentation/i2c/smbus-protocol
View File

@ -137,8 +137,8 @@ available for writes where the two data bytes are the other way
around (not SMBus compliant, but very popular.)
SMBus Process Call: i2c_smbus_process_call()
=============================================
SMBus Process Call:
===================
This command selects a device register (through the Comm byte), sends
16 bits of data to it, and reads 16 bits of data in return.

4
Documentation/i2c/writing-clients
View File

@ -365,8 +365,6 @@ in terms of it. Never use this function directly!
s32 i2c_smbus_read_word_data(struct i2c_client *client, u8 command);
s32 i2c_smbus_write_word_data(struct i2c_client *client,
u8 command, u16 value);
s32 i2c_smbus_process_call(struct i2c_client *client,
u8 command, u16 value);
s32 i2c_smbus_read_block_data(struct i2c_client *client,
u8 command, u8 *values);
s32 i2c_smbus_write_block_data(struct i2c_client *client,
@ -381,6 +379,8 @@ These ones were removed from i2c-core because they had no users, but could
be added back later if needed:
s32 i2c_smbus_write_quick(struct i2c_client *client, u8 value);
s32 i2c_smbus_process_call(struct i2c_client *client,
u8 command, u16 value);
s32 i2c_smbus_block_process_call(struct i2c_client *client,
u8 command, u8 length, u8 *values);

23
Documentation/kbuild/kconfig-language.txt
View File

@ -388,26 +388,3 @@ config FOO
depends on BAR && m
limits FOO to module (=m) or disabled (=n).
Kconfig symbol existence
~~~~~~~~~~~~~~~~~~~~~~~~
The following two methods produce the same kconfig symbol dependencies
but differ greatly in kconfig symbol existence (production) in the
generated config file.
case 1:
config FOO
tristate "about foo"
depends on BAR
vs. case 2:
if BAR
config FOO
tristate "about foo"
endif
In case 1, the symbol FOO will always exist in the config file (given
no other dependencies). In case 2, the symbol FOO will only exist in
the config file if BAR is enabled.

6
Documentation/kbuild/kconfig.txt
View File

@ -46,6 +46,12 @@ KCONFIG_OVERWRITECONFIG
If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
break symlinks when .config is a symlink to somewhere else.
CONFIG_
--------------------------------------------------
If you set CONFIG_ in the environment, Kconfig will prefix all symbols
with its value when saving the configuration, instead of using the default,
"CONFIG_".
______________________________________________________________________
Environment variables for '{allyes/allmod/allno/rand}config'

33
Documentation/kernel-parameters.txt
View File

@ -564,6 +564,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later. The
options are the same as for ttyS, above.
hvc<n> Use the hypervisor console device <n>. This is for
both Xen and PowerPC hypervisors.
If the device connected to the port is not a TTY but a braille
device, prepend "brl," before the device type, for instance
@ -594,6 +596,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
is selected automatically. Check
Documentation/kdump/kdump.txt for further details.
crashkernel_low=size[KMG]
[KNL, x86] parts under 4G.
crashkernel=range1:size1[,range2:size2,...][@offset]
[KNL] Same as above, but depends on the memory
in the running system. The syntax of range is
@ -754,6 +759,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
earlyprintk= [X86,SH,BLACKFIN]
earlyprintk=vga
earlyprintk=xen
earlyprintk=serial[,ttySn[,baudrate]]
earlyprintk=ttySn[,baudrate]
earlyprintk=dbgp[debugController#]
@ -771,6 +777,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
The VGA output is eventually overwritten by the real
console.
The xen output can only be used by Xen PV guests.
ekgdboc= [X86,KGDB] Allow early kernel console debugging
ekgdboc=kbd
@ -970,6 +978,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
If specified, z/VM IUCV HVC accepts connections
from listed z/VM user IDs only.
hwthread_map= [METAG] Comma-separated list of Linux cpu id to
hardware thread id mappings.
Format: <cpu>:<hwthread>
keep_bootcon [KNL]
Do not unregister boot console at start. This is only
useful for debugging when something happens in the window
@ -2223,6 +2235,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
This sorting is done to get a device
order compatible with older (<= 2.4) kernels.
nobfsort Don't sort PCI devices into breadth-first order.
pcie_bus_tune_off Disable PCIe MPS (Max Payload Size)
tuning and use the BIOS-configured MPS defaults.
pcie_bus_safe Set every device's MPS to the largest value
supported by all devices below the root complex.
pcie_bus_perf Set device MPS to the largest allowable MPS
based on its parent bus. Also set MRRS (Max
Read Request Size) to the largest supported
value (no larger than the MPS that the device
or bus can support) for best performance.
pcie_bus_peer2peer Set every device's MPS to 128B, which
every device is guaranteed to support. This
configuration allows peer-to-peer DMA between
any pair of devices, possibly at the cost of
reduced performance. This also guarantees
that hot-added devices will work.
cbiosize=nn[KMG] The fixed amount of bus space which is
reserved for the CardBus bridge's IO window.
The default value is 256 bytes.
@ -2244,6 +2271,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
the default.
off: Turn ECRC off
on: Turn ECRC on.
hpiosize=nn[KMG] The fixed amount of bus space which is
reserved for hotplug bridge's IO window.
Default size is 256 bytes.
hpmemsize=nn[KMG] The fixed amount of bus space which is
reserved for hotplug bridge's memory window.
Default size is 2 megabytes.
realloc= Enable/disable reallocating PCI bridge resources
if allocations done by BIOS are too small to
accommodate resources required by all child

2
Documentation/leds/00-INDEX
View File

@ -6,5 +6,7 @@ leds-lp5521.txt
- notes on how to use the leds-lp5521 driver.
leds-lp5523.txt
- notes on how to use the leds-lp5523 driver.
leds-lp55xx.txt
- description about lp55xx common driver.
leds-lm3556.txt
- notes on how to use the leds-lm3556 driver.

63
Documentation/leds/leds-lp5521.txt
View File

@ -17,19 +17,8 @@ lp5521:channelx, where x is 0 .. 2
All three channels can be also controlled using the engine micro programs.
More details of the instructions can be found from the public data sheet.
Control interface for the engines:
x is 1 .. 3
enginex_mode : disabled, load, run
enginex_load : store program (visible only in engine load mode)
Example (start to blink the channel 2 led):
cd /sys/class/leds/lp5521:channel2/device
echo "load" > engine3_mode
echo "037f4d0003ff6000" > engine3_load
echo "run" > engine3_mode
stop the engine:
echo "disabled" > engine3_mode
LP5521 has the internal program memory for running various LED patterns.
For the details, please refer to 'firmware' section in leds-lp55xx.txt
sysfs contains a selftest entry.
The test communicates with the chip and checks that
@ -47,7 +36,7 @@ The name of each channel can be configurable.
If the name field is not defined, the default name will be set to 'xxxx:channelN'
(XXXX : pdata->label or i2c client name, N : channel number)
static struct lp5521_led_config lp5521_led_config[] = {
static struct lp55xx_led_config lp5521_led_config[] = {
{
.name = "red",
.chan_nr = 0,
@ -81,10 +70,10 @@ static void lp5521_enable(bool state)
/* Control of chip enable signal */
}
static struct lp5521_platform_data lp5521_platform_data = {
static struct lp55xx_platform_data lp5521_platform_data = {
.led_config = lp5521_led_config,
.num_channels = ARRAY_SIZE(lp5521_led_config),
.clock_mode = LP5521_CLOCK_EXT,
.clock_mode = LP55XX_CLOCK_EXT,
.setup_resources = lp5521_setup,
.release_resources = lp5521_release,
.enable = lp5521_enable,
@ -105,47 +94,9 @@ example of update_config :
LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \
LP5521_CLK_INT)
static struct lp5521_platform_data lp5521_pdata = {
static struct lp55xx_platform_data lp5521_pdata = {
.led_config = lp5521_led_config,
.num_channels = ARRAY_SIZE(lp5521_led_config),
.clock_mode = LP5521_CLOCK_INT,
.clock_mode = LP55XX_CLOCK_INT,
.update_config = LP5521_CONFIGS,
};
LED patterns : LP5521 has autonomous operation without external control.
Pattern data can be defined in the platform data.
example of led pattern data :
/* RGB(50,5,0) 500ms on, 500ms off, infinite loop */
static u8 pattern_red[] = {
0x40, 0x32, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00,
};
static u8 pattern_green[] = {
0x40, 0x05, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00,
};
static struct lp5521_led_pattern board_led_patterns[] = {
{
.r = pattern_red,
.g = pattern_green,
.size_r = ARRAY_SIZE(pattern_red),
.size_g = ARRAY_SIZE(pattern_green),
},
};
static struct lp5521_platform_data lp5521_platform_data = {
.led_config = lp5521_led_config,
.num_channels = ARRAY_SIZE(lp5521_led_config),
.clock_mode = LP5521_CLOCK_EXT,
.patterns = board_led_patterns,
.num_patterns = ARRAY_SIZE(board_led_patterns),
};
Then predefined led pattern(s) can be executed via the sysfs.
To start the pattern #1,
# echo 1 > /sys/bus/i2c/devices/xxxx/led_pattern
(xxxx : i2c bus & slave address)
To end the pattern,
# echo 0 > /sys/bus/i2c/devices/xxxx/led_pattern

27
Documentation/leds/leds-lp5523.txt
View File

@ -27,25 +27,8 @@ c) Default
If both fields are NULL, 'lp5523' is used by default.
/sys/class/leds/lp5523:channelN (N: 0 ~ 8)
The chip provides 3 engines. Each engine can control channels without
interaction from the main CPU. Details of the micro engine code can be found
from the public data sheet. Leds can be muxed to different channels.
Control interface for the engines:
x is 1 .. 3
enginex_mode : disabled, load, run
enginex_load : microcode load (visible only in load mode)
enginex_leds : led mux control (visible only in load mode)
cd /sys/class/leds/lp5523:channel2/device
echo "load" > engine3_mode
echo "9d80400004ff05ff437f0000" > engine3_load
echo "111111111" > engine3_leds
echo "run" > engine3_mode
sysfs contains a selftest entry. It measures each channel
voltage level and checks if it looks reasonable. If the level is too high,
the led is missing; if the level is too low, there is a short circuit.
LP5523 has the internal program memory for running various LED patterns.
For the details, please refer to 'firmware' section in leds-lp55xx.txt
Selftest uses always the current from the platform data.
@ -58,7 +41,7 @@ Example platform data:
Note - chan_nr can have values between 0 and 8.
static struct lp5523_led_config lp5523_led_config[] = {
static struct lp55xx_led_config lp5523_led_config[] = {
{
.name = "D1",
.chan_nr = 0,
@ -88,10 +71,10 @@ static void lp5523_enable(bool state)
/* Control chip enable signal */
}
static struct lp5523_platform_data lp5523_platform_data = {
static struct lp55xx_platform_data lp5523_platform_data = {
.led_config = lp5523_led_config,
.num_channels = ARRAY_SIZE(lp5523_led_config),
.clock_mode = LP5523_CLOCK_EXT,
.clock_mode = LP55XX_CLOCK_EXT,
.setup_resources = lp5523_setup,
.release_resources = lp5523_release,
.enable = lp5523_enable,

118
Documentation/leds/leds-lp55xx.txt Normal file
View File

@ -0,0 +1,118 @@
LP5521/LP5523/LP55231 Common Driver
===================================
Authors: Milo(Woogyom) Kim <milo.kim@ti.com>
Description
-----------
LP5521, LP5523/55231 have common features as below.
Register access via the I2C
Device initialization/deinitialization
Create LED class devices for multiple output channels
Device attributes for user-space interface
Program memory for running LED patterns
The LP55xx common driver provides these features using exported functions.
lp55xx_init_device() / lp55xx_deinit_device()
lp55xx_register_leds() / lp55xx_unregister_leds()
lp55xx_regsister_sysfs() / lp55xx_unregister_sysfs()
( Driver Structure Data )
In lp55xx common driver, two different data structure is used.
o lp55xx_led
control multi output LED channels such as led current, channel index.
o lp55xx_chip
general chip control such like the I2C and platform data.
For example, LP5521 has maximum 3 LED channels.
LP5523/55231 has 9 output channels.
lp55xx_chip for LP5521 ... lp55xx_led #1
lp55xx_led #2
lp55xx_led #3
lp55xx_chip for LP5523 ... lp55xx_led #1
lp55xx_led #2
.
.
lp55xx_led #9
( Chip Dependent Code )
To support device specific configurations, special structure
'lpxx_device_config' is used.
Maximum number of channels
Reset command, chip enable command
Chip specific initialization
Brightness control register access
Setting LED output current
Program memory address access for running patterns
Additional device specific attributes
( Firmware Interface )
LP55xx family devices have the internal program memory for running
various LED patterns.
This pattern data is saved as a file in the user-land or
hex byte string is written into the memory through the I2C.
LP55xx common driver supports the firmware interface.
LP55xx chips have three program engines.
To load and run the pattern, the programming sequence is following.
(1) Select an engine number (1/2/3)
(2) Mode change to load
(3) Write pattern data into selected area
(4) Mode change to run
The LP55xx common driver provides simple interfaces as below.
select_engine : Select which engine is used for running program
run_engine : Start program which is loaded via the firmware interface
firmware : Load program data
For example, run blinking pattern in engine #1 of LP5521
echo 1 > /sys/bus/i2c/devices/xxxx/select_engine
echo 1 > /sys/class/firmware/lp5521/loading
echo "4000600040FF6000" > /sys/class/firmware/lp5521/data
echo 0 > /sys/class/firmware/lp5521/loading
echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
For example, run blinking pattern in engine #3 of LP55231
echo 3 > /sys/bus/i2c/devices/xxxx/select_engine
echo 1 > /sys/class/firmware/lp55231/loading
echo "9d0740ff7e0040007e00a0010000" > /sys/class/firmware/lp55231/data
echo 0 > /sys/class/firmware/lp55231/loading
echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
To start blinking patterns in engine #2 and #3 simultaneously,
for idx in 2 3
do
echo $idx > /sys/class/leds/red/device/select_engine
sleep 0.1
echo 1 > /sys/class/firmware/lp5521/loading
echo "4000600040FF6000" > /sys/class/firmware/lp5521/data
echo 0 > /sys/class/firmware/lp5521/loading
done
echo 1 > /sys/class/leds/red/device/run_engine
Here is another example for LP5523.
echo 2 > /sys/bus/i2c/devices/xxxx/select_engine
echo 1 > /sys/class/firmware/lp5523/loading
echo "9d80400004ff05ff437f0000" > /sys/class/firmware/lp5523/data
echo 0 > /sys/class/firmware/lp5523/loading
echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
As soon as 'loading' is set to 0, registered callback is called.
Inside the callback, the selected engine is loaded and memory is updated.
To run programmed pattern, 'run_engine' attribute should be enabled.
( 'run_engine' and 'firmware_cb' )
The sequence of running the program data is common.
But each device has own specific register addresses for commands.
To support this, 'run_engine' and 'firmware_cb' are configurable in each driver.
run_engine : Control the selected engine
firmware_cb : The callback function after loading the firmware is done.
Chip specific commands for loading and updating program memory.

2
Documentation/lockstat.txt
View File

@ -65,7 +65,7 @@ that had to wait on lock acquisition.
- CONFIGURATION
Lock statistics are enabled via CONFIG_LOCK_STATS.
Lock statistics are enabled via CONFIG_LOCK_STAT.
- USAGE

2
Documentation/media-framework.txt
View File

@ -336,7 +336,7 @@ Calls to media_entity_pipeline_start() can be nested. The pipeline pointer must
be identical for all nested calls to the function.
media_entity_pipeline_start() may return an error. In that case, it will
clean up any the changes it did by itself.
clean up any of the changes it did by itself.
When stopping the stream, drivers must notify the entities with

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