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:
commit
6aeedba20e
|
@ -299,6 +299,8 @@ memory-hotplug.txt
|
||||||
- Hotpluggable memory support, how to use and current status.
|
- Hotpluggable memory support, how to use and current status.
|
||||||
memory.txt
|
memory.txt
|
||||||
- info on typical Linux memory problems.
|
- info on typical Linux memory problems.
|
||||||
|
metag/
|
||||||
|
- directory with info about Linux on Meta architecture.
|
||||||
mips/
|
mips/
|
||||||
- directory with info about Linux on MIPS architecture.
|
- directory with info about Linux on MIPS architecture.
|
||||||
misc-devices/
|
misc-devices/
|
||||||
|
|
|
@ -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
|
Date: March 2012
|
||||||
KernelVersion: TBD
|
KernelVersion: TBD
|
||||||
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
|
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:
|
Attributes:
|
||||||
|
|
||||||
fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
|
fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
|
||||||
this value will change the dev_loss_tmo for all
|
this value will change the dev_loss_tmo for all
|
||||||
FCFs discovered by this controller.
|
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/link_fail: Link Error Status Block (LESB) link failure count.
|
||||||
|
|
||||||
lesb/vlink_fail: Link Error Status Block (LESB) virtual link
|
lesb/vlink_fail: Link Error Status Block (LESB) virtual link
|
||||||
|
@ -26,7 +65,7 @@ Attributes:
|
||||||
|
|
||||||
Notes: ctlr_X (global increment starting at 0)
|
Notes: ctlr_X (global increment starting at 0)
|
||||||
|
|
||||||
What: /sys/bus/fcoe/fcf_X
|
What: /sys/bus/fcoe/devices/fcf_X
|
||||||
Date: March 2012
|
Date: March 2012
|
||||||
KernelVersion: TBD
|
KernelVersion: TBD
|
||||||
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
|
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
|
||||||
|
|
52
Documentation/ABI/testing/sysfs-kernel-mm-ksm
Normal file
52
Documentation/ABI/testing/sysfs-kernel-mm-ksm
Normal 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
83
Documentation/ABI/testing/sysfs-platform-msi-laptop
Normal 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.
|
||||||
|
|
|
@ -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
|
that the mapping code will work correctly on all dma implementations without
|
||||||
any dependency on the specifics of the underlying implementation. Using the
|
any dependency on the specifics of the underlying implementation. Using the
|
||||||
returned address without checking for errors could result in failures ranging
|
returned address without checking for errors could result in failures ranging
|
||||||
from panics to silent data corruption. Couple of example of incorrect ways to
|
from panics to silent data corruption. A couple of examples of incorrect ways
|
||||||
check for errors that make assumptions about the underlying dma implementation
|
to check for errors that make assumptions about the underlying dma
|
||||||
are as follows and these are applicable to dma_map_page() as well.
|
implementation are as follows and these are applicable to dma_map_page() as
|
||||||
|
well.
|
||||||
|
|
||||||
Incorrect example 1:
|
Incorrect example 1:
|
||||||
dma_addr_t dma_handle;
|
dma_addr_t dma_handle;
|
||||||
|
@ -751,7 +752,7 @@ Example 1:
|
||||||
dma_unmap_single(dma_handle1);
|
dma_unmap_single(dma_handle1);
|
||||||
map_error_handling1:
|
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)
|
mapping error is detected in the middle)
|
||||||
|
|
||||||
dma_addr_t dma_addr;
|
dma_addr_t dma_addr;
|
||||||
|
|
|
@ -743,6 +743,10 @@ char *date;</synopsis>
|
||||||
These two operations are mandatory for GEM drivers that support DRM
|
These two operations are mandatory for GEM drivers that support DRM
|
||||||
PRIME.
|
PRIME.
|
||||||
</para>
|
</para>
|
||||||
|
<sect4>
|
||||||
|
<title>DRM PRIME Helper Functions Reference</title>
|
||||||
|
!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
|
||||||
|
</sect4>
|
||||||
</sect3>
|
</sect3>
|
||||||
<sect3 id="drm-gem-objects-mapping">
|
<sect3 id="drm-gem-objects-mapping">
|
||||||
<title>GEM Objects Mapping</title>
|
<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
|
If the parameters are deemed valid, drivers then create, initialize and
|
||||||
return an instance of struct <structname>drm_framebuffer</structname>.
|
return an instance of struct <structname>drm_framebuffer</structname>.
|
||||||
If desired the instance can be embedded in a larger driver-specific
|
If desired the instance can be embedded in a larger driver-specific
|
||||||
structure. The new instance is initialized with a call to
|
structure. Drivers must fill its <structfield>width</structfield>,
|
||||||
<function>drm_framebuffer_init</function> which takes a pointer to DRM
|
<structfield>height</structfield>, <structfield>pitches</structfield>,
|
||||||
frame buffer operations (struct
|
<structfield>offsets</structfield>, <structfield>depth</structfield>,
|
||||||
<structname>drm_framebuffer_funcs</structname>). Frame buffer operations are
|
<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>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<synopsis>int (*create_handle)(struct drm_framebuffer *fb,
|
<synopsis>int (*create_handle)(struct drm_framebuffer *fb,
|
||||||
|
@ -1022,16 +1041,16 @@ int max_width, max_height;</synopsis>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
After initializing the <structname>drm_framebuffer</structname>
|
The lifetime of a drm framebuffer is controlled with a reference count,
|
||||||
instance drivers must fill its <structfield>width</structfield>,
|
drivers can grab additional references with
|
||||||
<structfield>height</structfield>, <structfield>pitches</structfield>,
|
<function>drm_framebuffer_reference</function> </para> and drop them
|
||||||
<structfield>offsets</structfield>, <structfield>depth</structfield>,
|
again with <function>drm_framebuffer_unreference</function>. For
|
||||||
<structfield>bits_per_pixel</structfield> and
|
driver-private framebuffers for which the last reference is never
|
||||||
<structfield>pixel_format</structfield> fields from the values passed
|
dropped (e.g. for the fbdev framebuffer when the struct
|
||||||
through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
|
<structname>drm_framebuffer</structname> is embedded into the fbdev
|
||||||
should call the <function>drm_helper_mode_fill_fb_struct</function>
|
helper struct) drivers can manually clean up a framebuffer at module
|
||||||
helper function to do so.
|
unload time with
|
||||||
</para>
|
<function>drm_framebuffer_unregister_private</function>.
|
||||||
</sect2>
|
</sect2>
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>Output Polling</title>
|
<title>Output Polling</title>
|
||||||
|
@ -1043,6 +1062,22 @@ int max_width, max_height;</synopsis>
|
||||||
operation.
|
operation.
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
</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-<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>
|
</sect1>
|
||||||
|
|
||||||
<!-- Internals: kms initialization and cleanup -->
|
<!-- 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
|
without waiting for rendering or page flip to complete and must block
|
||||||
any new rendering to the frame buffer until the page flip completes.
|
any new rendering to the frame buffer until the page flip completes.
|
||||||
</para>
|
</para>
|
||||||
|
<para>
|
||||||
|
If a page flip can be successfully scheduled the driver must set the
|
||||||
|
<code>drm_crtc-<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>
|
<para>
|
||||||
If a page flip is already pending, the
|
If a page flip is already pending, the
|
||||||
<methodname>page_flip</methodname> operation must return
|
<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.
|
make its properties available to applications.
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
|
<sect2>
|
||||||
|
<title>KMS API Functions</title>
|
||||||
|
!Edrivers/gpu/drm/drm_crtc.c
|
||||||
|
</sect2>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<!-- Internals: kms helper functions -->
|
<!-- Internals: kms helper functions -->
|
||||||
|
@ -2104,6 +2149,7 @@ void intel_crt_init(struct drm_device *dev)
|
||||||
<title>fbdev Helper Functions Reference</title>
|
<title>fbdev Helper Functions Reference</title>
|
||||||
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
|
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
|
||||||
!Edrivers/gpu/drm/drm_fb_helper.c
|
!Edrivers/gpu/drm/drm_fb_helper.c
|
||||||
|
!Iinclude/drm/drm_fb_helper.h
|
||||||
</sect2>
|
</sect2>
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>Display Port Helper Functions Reference</title>
|
<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
|
!Iinclude/drm/drm_dp_helper.h
|
||||||
!Edrivers/gpu/drm/drm_dp_helper.c
|
!Edrivers/gpu/drm/drm_dp_helper.c
|
||||||
</sect2>
|
</sect2>
|
||||||
|
<sect2>
|
||||||
|
<title>EDID Helper Functions Reference</title>
|
||||||
|
!Edrivers/gpu/drm/drm_edid.c
|
||||||
|
</sect2>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<!-- Internals: vertical blanking -->
|
<!-- Internals: vertical blanking -->
|
||||||
|
|
|
@ -84,7 +84,7 @@ Added ISDB-T test originally written by Patrick Boettcher
|
||||||
|
|
||||||
|
|
||||||
<title>LINUX DVB API</title>
|
<title>LINUX DVB API</title>
|
||||||
<subtitle>Version 5.8</subtitle>
|
<subtitle>Version 5.10</subtitle>
|
||||||
<!-- ADD THE CHAPTERS HERE -->
|
<!-- ADD THE CHAPTERS HERE -->
|
||||||
<chapter id="dvb_introdution">
|
<chapter id="dvb_introdution">
|
||||||
&sub-intro;
|
&sub-intro;
|
||||||
|
|
|
@ -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>
|
<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">
|
API is to replace the ioctl's were the <link linkend="dvb-frontend-parameters">
|
||||||
struct <constant>dvb_frontend_parameters</constant></link> were used.</para>
|
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">
|
<section id="dtv-property">
|
||||||
<title>DTV property type</title>
|
<title>DTV property type</title>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
/* Reserved fields should be set to 0 */
|
/* Reserved fields should be set to 0 */
|
||||||
|
|
||||||
struct dtv_property {
|
struct dtv_property {
|
||||||
__u32 cmd;
|
__u32 cmd;
|
||||||
|
__u32 reserved[3];
|
||||||
union {
|
union {
|
||||||
__u32 data;
|
__u32 data;
|
||||||
|
struct dtv_fe_stats st;
|
||||||
struct {
|
struct {
|
||||||
__u8 data[32];
|
__u8 data[32];
|
||||||
__u32 len;
|
__u32 len;
|
||||||
|
@ -440,7 +467,7 @@ typedef enum fe_delivery_system {
|
||||||
<title><constant>DTV-ISDBT-LAYER*</constant> parameters</title>
|
<title><constant>DTV-ISDBT-LAYER*</constant> parameters</title>
|
||||||
<para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in
|
<para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in
|
||||||
ISDB-T hierarchical layers can be decoded simultaneously. For that
|
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
|
<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
|
available segments. The total number of segments over all layers has
|
||||||
to 13 in ISDB-T.</para>
|
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>
|
<para>use the special macro LNA_AUTO to set LNA auto</para>
|
||||||
</section>
|
</section>
|
||||||
</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">
|
<section id="frontend-property-terrestrial-systems">
|
||||||
<title>Properties used on terrestrial delivery systems</title>
|
<title>Properties used on terrestrial delivery systems</title>
|
||||||
<section id="dvbt-params">
|
<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-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
|
||||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="dvbt2-params">
|
<section id="dvbt2-params">
|
||||||
<title>DVB-T2 delivery system</title>
|
<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-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
|
||||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="isdbt">
|
<section id="isdbt">
|
||||||
<title>ISDB-T delivery system</title>
|
<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-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>
|
<listitem><para><link linkend="DTV-ISDBT-LAYER-TIME-INTERLEAVING"><constant>DTV_ISDBT_LAYERC_TIME_INTERLEAVING</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="atsc-params">
|
<section id="atsc-params">
|
||||||
<title>ATSC delivery system</title>
|
<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-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
|
||||||
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
|
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="atscmh-params">
|
<section id="atscmh-params">
|
||||||
<title>ATSC-MH delivery system</title>
|
<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-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>
|
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="dtmb-params">
|
<section id="dtmb-params">
|
||||||
<title>DTMB delivery system</title>
|
<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-INTERLEAVING"><constant>DTV_INTERLEAVING</constant></link></para></listitem>
|
||||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
<section id="frontend-property-cable-systems">
|
<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-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
|
||||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="dvbc-annex-b-params">
|
<section id="dvbc-annex-b-params">
|
||||||
<title>DVB-C Annex B delivery system</title>
|
<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-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
|
||||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
<section id="frontend-property-satellital-systems">
|
<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-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem>
|
||||||
<listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem>
|
<listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</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>
|
<para>Future implementations might add those two missing parameters:</para>
|
||||||
<itemizedlist mark='opencircle'>
|
<itemizedlist mark='opencircle'>
|
||||||
<listitem><para><link linkend="DTV-DISEQC-MASTER"><constant>DTV_DISEQC_MASTER</constant></link></para></listitem>
|
<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-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem>
|
||||||
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
|
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="turbo-params">
|
<section id="turbo-params">
|
||||||
<title>Turbo code delivery system</title>
|
<title>Turbo code delivery system</title>
|
||||||
|
|
|
@ -230,7 +230,7 @@ typedef enum fe_status {
|
||||||
<entry align="char">The frontend has found a DVB signal</entry>
|
<entry align="char">The frontend has found a DVB signal</entry>
|
||||||
</row><row>
|
</row><row>
|
||||||
<entry align="char">FE_HAS_VITERBI</entry>
|
<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>
|
</row><row>
|
||||||
<entry align="char">FE_HAS_SYNC</entry>
|
<entry align="char">FE_HAS_SYNC</entry>
|
||||||
<entry align="char">Syncronization bytes was found</entry>
|
<entry align="char">Syncronization bytes was found</entry>
|
||||||
|
|
|
@ -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
|
<para>Applications can make use of the <xref linkend="input-capabilities" /> and
|
||||||
<xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls
|
<xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls
|
||||||
are available for the device.</para>
|
are available for the device.</para>
|
||||||
&ENOTTY;.
|
|
||||||
<para>See <xref linkend="buffer" /> for a rationale. Probably
|
<para>See <xref linkend="buffer" /> for a rationale. Probably
|
||||||
even USB cameras follow some well known video standard. It might have
|
even USB cameras follow some well known video standard. It might have
|
||||||
been better to explicitly indicate elsewhere if a device cannot live
|
been better to explicitly indicate elsewhere if a device cannot live
|
||||||
|
|
|
@ -2477,6 +2477,22 @@ that used it. It was originally scheduled for removal in 2.6.35.
|
||||||
</orderedlist>
|
</orderedlist>
|
||||||
</section>
|
</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">
|
<section id="other">
|
||||||
<title>Relation of V4L2 to other Linux multimedia APIs</title>
|
<title>Relation of V4L2 to other Linux multimedia APIs</title>
|
||||||
|
|
||||||
|
|
|
@ -203,29 +203,6 @@ and should not be used in new drivers and applications.</entry>
|
||||||
<entry>boolean</entry>
|
<entry>boolean</entry>
|
||||||
<entry>Mirror the picture vertically.</entry>
|
<entry>Mirror the picture vertically.</entry>
|
||||||
</row>
|
</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">
|
<row id="v4l2-power-line-frequency">
|
||||||
<entry><constant>V4L2_CID_POWER_LINE_FREQUENCY</constant></entry>
|
<entry><constant>V4L2_CID_POWER_LINE_FREQUENCY</constant></entry>
|
||||||
<entry>enum</entry>
|
<entry>enum</entry>
|
||||||
|
|
|
@ -477,7 +477,7 @@ rest should be evident.</para>
|
||||||
|
|
||||||
<note>
|
<note>
|
||||||
<title>Experimental</title>
|
<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>
|
interface and may change in the future.</para>
|
||||||
</note>
|
</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
|
different or the same device (known as the importer role), or both. This
|
||||||
section describes the DMABUF importer role API in V4L2.</para>
|
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>
|
details about exporting V4L2 buffers as DMABUF file descriptors.</para>
|
||||||
|
|
||||||
<para>Input and output devices support the streaming I/O method when the
|
<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>struct timeval</entry>
|
||||||
<entry><structfield>timestamp</structfield></entry>
|
<entry><structfield>timestamp</structfield></entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry><para>For input streams this is the
|
<entry><para>For input streams this is time when the first data
|
||||||
system time (as returned by the <function>gettimeofday()</function>
|
byte was captured, as returned by the
|
||||||
function) when the first data byte was captured. For output streams
|
<function>clock_gettime()</function> function for the relevant
|
||||||
the data will not be displayed before this time, secondary to the
|
clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
|
||||||
nominal frame rate determined by the current video standard in
|
<xref linkend="buffer-flags" />. For output streams the data
|
||||||
enqueued order. Applications can for example zero this field to
|
will not be displayed before this time, secondary to the nominal
|
||||||
display frames as soon as possible. The driver stores the time at
|
frame rate determined by the current video standard in enqueued
|
||||||
which the first data byte was actually sent out in the
|
order. Applications can for example zero this field to display
|
||||||
<structfield>timestamp</structfield> field. This permits
|
frames as soon as possible. The driver stores the time at which
|
||||||
applications to monitor the drift between the video and system
|
the first data byte was actually sent out in the
|
||||||
clock.</para></entry>
|
<structfield>timestamp</structfield> field. This permits
|
||||||
|
applications to monitor the drift between the video and system
|
||||||
|
clock.</para></entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>&v4l2-timecode;</entry>
|
<entry>&v4l2-timecode;</entry>
|
||||||
|
@ -903,7 +905,7 @@ should set this to 0.</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry>__unsigned long</entry>
|
<entry>unsigned long</entry>
|
||||||
<entry><structfield>userptr</structfield></entry>
|
<entry><structfield>userptr</structfield></entry>
|
||||||
<entry>When the memory type in the containing &v4l2-buffer; is
|
<entry>When the memory type in the containing &v4l2-buffer; is
|
||||||
<constant>V4L2_MEMORY_USERPTR</constant>, this is a userspace
|
<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 this buffer has not been created by the CPU but by some DMA-capable unit,
|
||||||
in which case caches have not been used.</entry>
|
in which case caches have not been used.</entry>
|
||||||
</row>
|
</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>
|
</tbody>
|
||||||
</tgroup>
|
</tgroup>
|
||||||
</table>
|
</table>
|
||||||
|
|
|
@ -6,7 +6,7 @@
|
||||||
<refnamediv>
|
<refnamediv>
|
||||||
<refname id="V4L2-PIX-FMT-NV12M"><constant>V4L2_PIX_FMT_NV12M</constant></refname>
|
<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-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
|
<refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> and <constant>V4L2_PIX_FMT_NV21</constant> with planes
|
||||||
non contiguous in memory. </refpurpose>
|
non contiguous in memory. </refpurpose>
|
||||||
</refnamediv>
|
</refnamediv>
|
||||||
|
|
34
Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
Normal file
34
Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
Normal 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
62
Documentation/DocBook/media/v4l/pixfmt-uv8.xml
Normal 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 + 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 + 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 + 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 + 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>
|
|
@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.<
|
||||||
&sub-srggb8;
|
&sub-srggb8;
|
||||||
&sub-sbggr16;
|
&sub-sbggr16;
|
||||||
&sub-srggb10;
|
&sub-srggb10;
|
||||||
|
&sub-srggb10alaw8;
|
||||||
&sub-srggb10dpcm8;
|
&sub-srggb10dpcm8;
|
||||||
&sub-srggb12;
|
&sub-srggb12;
|
||||||
</section>
|
</section>
|
||||||
|
@ -701,6 +702,7 @@ information.</para>
|
||||||
&sub-y12;
|
&sub-y12;
|
||||||
&sub-y10b;
|
&sub-y10b;
|
||||||
&sub-y16;
|
&sub-y16;
|
||||||
|
&sub-uv8;
|
||||||
&sub-yuyv;
|
&sub-yuyv;
|
||||||
&sub-uyvy;
|
&sub-uyvy;
|
||||||
&sub-yvyu;
|
&sub-yvyu;
|
||||||
|
|
File diff suppressed because it is too large
Load diff
|
@ -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
|
(compat.xml), along with the possible impact on existing drivers and
|
||||||
applications. -->
|
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>
|
<revision>
|
||||||
<revnumber>3.6</revnumber>
|
<revnumber>3.6</revnumber>
|
||||||
<date>2012-07-02</date>
|
<date>2012-07-02</date>
|
||||||
|
@ -472,7 +482,7 @@ and discussions on the V4L mailing list.</revremark>
|
||||||
</partinfo>
|
</partinfo>
|
||||||
|
|
||||||
<title>Video for Linux Two API Specification</title>
|
<title>Video for Linux Two API Specification</title>
|
||||||
<subtitle>Revision 3.6</subtitle>
|
<subtitle>Revision 3.9</subtitle>
|
||||||
|
|
||||||
<chapter id="common">
|
<chapter id="common">
|
||||||
&sub-common;
|
&sub-common;
|
||||||
|
|
|
@ -261,6 +261,12 @@
|
||||||
<entry>This control event was triggered because the control flags
|
<entry>This control event was triggered because the control flags
|
||||||
changed.</entry>
|
changed.</entry>
|
||||||
</row>
|
</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>
|
</tbody>
|
||||||
</tgroup>
|
</tgroup>
|
||||||
</table>
|
</table>
|
||||||
|
|
|
@ -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
|
<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
|
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>
|
is no longer used to allow the associated memory to be reclaimed. </para>
|
||||||
|
|
||||||
</refsect1>
|
</refsect1>
|
||||||
<refsect1>
|
|
||||||
<section>
|
|
||||||
<title>Examples</title>
|
|
||||||
|
|
||||||
<example>
|
<refsect1>
|
||||||
<title>Exporting a buffer.</title>
|
<title>Examples</title>
|
||||||
<programlisting>
|
|
||||||
|
<example>
|
||||||
|
<title>Exporting a buffer.</title>
|
||||||
|
<programlisting>
|
||||||
int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
|
int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
|
||||||
{
|
{
|
||||||
&v4l2-exportbuffer; expbuf;
|
&v4l2-exportbuffer; expbuf;
|
||||||
|
@ -108,12 +107,12 @@ int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
|
||||||
|
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</example>
|
</example>
|
||||||
|
|
||||||
<example>
|
<example>
|
||||||
<title>Exporting a buffer using the multi-planar API.</title>
|
<title>Exporting a buffer using the multi-planar API.</title>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
|
int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
|
||||||
int dmafd[], int n_planes)
|
int dmafd[], int n_planes)
|
||||||
{
|
{
|
||||||
|
@ -137,12 +136,9 @@ int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
|
||||||
|
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</example>
|
</example>
|
||||||
</section>
|
|
||||||
</refsect1>
|
|
||||||
|
|
||||||
<refsect1>
|
|
||||||
<table pgwide="1" frame="none" id="v4l2-exportbuffer">
|
<table pgwide="1" frame="none" id="v4l2-exportbuffer">
|
||||||
<title>struct <structname>v4l2_exportbuffer</structname></title>
|
<title>struct <structname>v4l2_exportbuffer</structname></title>
|
||||||
<tgroup cols="3">
|
<tgroup cols="3">
|
||||||
|
|
|
@ -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
|
of bounds drivers can choose to take the closest valid value or return
|
||||||
an &ERANGE;, whatever seems more appropriate. However,
|
an &ERANGE;, whatever seems more appropriate. However,
|
||||||
<constant>VIDIOC_S_CTRL</constant> is a write-only ioctl, it does not
|
<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
|
<para>These ioctls work only with user controls. For other
|
||||||
control classes the &VIDIOC-G-EXT-CTRLS;, &VIDIOC-S-EXT-CTRLS; or
|
control classes the &VIDIOC-G-EXT-CTRLS;, &VIDIOC-S-EXT-CTRLS; or
|
||||||
|
@ -99,7 +101,9 @@ application.</entry>
|
||||||
<term><errorcode>EINVAL</errorcode></term>
|
<term><errorcode>EINVAL</errorcode></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The &v4l2-control; <structfield>id</structfield> is
|
<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>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
|
|
|
@ -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
|
&EINVAL;. When the value is out of bounds drivers can choose to take
|
||||||
the closest valid value or return an &ERANGE;, whatever seems more
|
the closest valid value or return an &ERANGE;, whatever seems more
|
||||||
appropriate. In the first case the new value is set in
|
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
|
<para>The driver will only set/get these controls if all control
|
||||||
values are correct. This prevents the situation where only some of the
|
values are correct. This prevents the situation where only some of the
|
||||||
|
@ -199,13 +201,46 @@ also be zero.</entry>
|
||||||
<row>
|
<row>
|
||||||
<entry>__u32</entry>
|
<entry>__u32</entry>
|
||||||
<entry><structfield>error_idx</structfield></entry>
|
<entry><structfield>error_idx</structfield></entry>
|
||||||
<entry>Set by the driver in case of an error. If it is equal
|
<entry><para>Set by the driver in case of an error. If the error is
|
||||||
to <structfield>count</structfield>, then no actual changes were made to
|
associated with a particular control, then <structfield>error_idx</structfield>
|
||||||
controls. In other words, the error was not associated with setting a particular
|
is set to the index of that control. If the error is not related to a specific
|
||||||
control. If it is another value, then only the controls up to <structfield>error_idx-1</structfield>
|
control, or the validation step failed (see below), then
|
||||||
were modified and control <structfield>error_idx</structfield> is the one that
|
<structfield>error_idx</structfield> is set to <structfield>count</structfield>.
|
||||||
caused the error. The <structfield>error_idx</structfield> value is undefined
|
The value is undefined if the ioctl returned 0 (success).</para>
|
||||||
if the ioctl returned 0 (success).</entry>
|
|
||||||
|
<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>
|
||||||
<row>
|
<row>
|
||||||
<entry>__u32</entry>
|
<entry>__u32</entry>
|
||||||
|
@ -298,8 +333,10 @@ These controls are described in <xref
|
||||||
<term><errorcode>EINVAL</errorcode></term>
|
<term><errorcode>EINVAL</errorcode></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The &v4l2-ext-control; <structfield>id</structfield>
|
<para>The &v4l2-ext-control; <structfield>id</structfield>
|
||||||
is invalid or the &v4l2-ext-controls;
|
is invalid, the &v4l2-ext-controls;
|
||||||
<structfield>ctrl_class</structfield> is invalid. This error code is
|
<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
|
also returned by the <constant>VIDIOC_S_EXT_CTRLS</constant> and
|
||||||
<constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctls if two or more
|
<constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctls if two or more
|
||||||
control values are in conflict.</para>
|
control values are in conflict.</para>
|
||||||
|
|
|
@ -76,7 +76,7 @@ make sure the strings are properly NUL-terminated.</para></entry>
|
||||||
<row>
|
<row>
|
||||||
<entry>__u8</entry>
|
<entry>__u8</entry>
|
||||||
<entry><structfield>card</structfield>[32]</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
|
For example: "Yoyodyne TV/FM". One driver may support different brands
|
||||||
or models of video hardware. This information is intended for users,
|
or models of video hardware. This information is intended for users,
|
||||||
for example in a menu of available devices. Since multiple TV cards of
|
for example in a menu of available devices. Since multiple TV cards of
|
||||||
|
|
|
@ -22,6 +22,7 @@
|
||||||
|
|
||||||
<!-- LinuxTV v4l-dvb repository. -->
|
<!-- LinuxTV v4l-dvb repository. -->
|
||||||
<!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>">
|
<!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">
|
<book id="media_api">
|
||||||
|
|
|
@ -28,11 +28,30 @@ Makefile environment are given here.
|
||||||
To create binary EDID and C source code files from the existing data
|
To create binary EDID and C source code files from the existing data
|
||||||
material, simply type "make".
|
material, simply type "make".
|
||||||
|
|
||||||
If you want to create your own EDID file, copy the file 1024x768.S and
|
If you want to create your own EDID file, copy the file 1024x768.S,
|
||||||
replace the settings with your own data. The CRC value in the last line
|
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
|
#define CRC 0x55
|
||||||
is a bit tricky. After a first version of the binary data set is
|
also 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
|
created, it must be checked with the "edid-decode" utility which will
|
||||||
most probably complain about a wrong CRC. Fortunately, the utility also
|
most probably complain about a wrong CRC. Fortunately, the utility also
|
||||||
displays the correct CRC which must then be inserted into the source
|
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
|
file. After the make procedure is repeated, the EDID data set is ready
|
||||||
|
|
|
@ -348,34 +348,40 @@ You can change this at module load time (for a module) with:
|
||||||
|
|
||||||
modprobe ipmi_si.o type=<type1>,<type2>....
|
modprobe ipmi_si.o type=<type1>,<type2>....
|
||||||
ports=<port1>,<port2>... addrs=<addr1>,<addr2>...
|
ports=<port1>,<port2>... addrs=<addr1>,<addr2>...
|
||||||
irqs=<irq1>,<irq2>... trydefaults=[0|1]
|
irqs=<irq1>,<irq2>...
|
||||||
regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,...
|
regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,...
|
||||||
regshifts=<shift1>,<shift2>,...
|
regshifts=<shift1>,<shift2>,...
|
||||||
slave_addrs=<addr1>,<addr2>,...
|
slave_addrs=<addr1>,<addr2>,...
|
||||||
force_kipmid=<enable1>,<enable2>,...
|
force_kipmid=<enable1>,<enable2>,...
|
||||||
kipmid_max_busy_us=<ustime1>,<ustime2>,...
|
kipmid_max_busy_us=<ustime1>,<ustime2>,...
|
||||||
unload_when_empty=[0|1]
|
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.
|
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
|
The si_type may be either "kcs", "smic", or "bt". If you leave it blank, it
|
||||||
defaults to "kcs".
|
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
|
use the memory address given as the address of the device. This
|
||||||
overrides si_ports.
|
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.
|
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.
|
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
|
any interfaces specified by ACPE are tried. By default, the driver
|
||||||
tries it, set this value to zero to turn this off.
|
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
|
The next three parameters have to do with register layout. The
|
||||||
registers used by the interfaces may not appear at successive
|
registers used by the interfaces may not appear at successive
|
||||||
locations and they may not be in 8-bit registers. These parameters
|
locations and they may not be in 8-bit registers. These parameters
|
||||||
|
|
|
@ -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
|
performace although this can cause the latency of some I/O to increase due
|
||||||
to more number of requests.
|
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
|
CFQ IOPS Mode for group scheduling
|
||||||
===================================
|
===================================
|
||||||
Basic CFQ design is to provide priority based time slices. Higher priority
|
Basic CFQ design is to provide priority based time slices. Higher priority
|
||||||
|
|
|
@ -4,43 +4,13 @@
|
||||||
can use a remote server as one of its block devices. So every time
|
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
|
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.
|
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 -
|
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.
|
to borrow disk space from another computer.
|
||||||
Unlike NFS, it is possible to put any filesystem on it, etc. It should
|
Unlike NFS, it is possible to put any filesystem on it, etc.
|
||||||
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.
|
|
||||||
|
|
||||||
For more information, or to download the nbd-client and nbd-server
|
For more information, or to download the nbd-client and nbd-server
|
||||||
tools, go to http://nbd.sf.net/.
|
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
|
The nbd kernel module need only be installed on the client
|
||||||
system, as the nbd-server is completely in userspace. In fact,
|
system, as the nbd-server is completely in userspace. In fact,
|
||||||
the nbd-server has been successfully ported to other operating
|
the nbd-server has been successfully ported to other operating
|
||||||
|
|
|
@ -75,7 +75,7 @@ Throttling/Upper Limit policy
|
||||||
mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
|
mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
|
||||||
|
|
||||||
- Specify a bandwidth rate on particular device for root group. The format
|
- 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
|
echo "8:16 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device
|
||||||
|
|
||||||
|
@ -94,13 +94,11 @@ Throttling/Upper Limit policy
|
||||||
|
|
||||||
Hierarchical Cgroups
|
Hierarchical Cgroups
|
||||||
====================
|
====================
|
||||||
- Currently none of the IO control policy supports hierarchical groups. But
|
- Currently only CFQ supports hierarchical groups. For throttling,
|
||||||
cgroup interface does allow creation of hierarchical cgroups and internally
|
cgroup interface does allow creation of hierarchical cgroups and
|
||||||
IO policies treat them as flat hierarchy.
|
internally it treats them as flat hierarchy.
|
||||||
|
|
||||||
So this patch will allow creation of cgroup hierarchcy but at the backend
|
If somebody created a hierarchy like as follows.
|
||||||
everything will be treated as flat. So if somebody created a hierarchy like
|
|
||||||
as follows.
|
|
||||||
|
|
||||||
root
|
root
|
||||||
/ \
|
/ \
|
||||||
|
@ -108,16 +106,20 @@ Hierarchical Cgroups
|
||||||
|
|
|
|
||||||
test3
|
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
|
pivot
|
||||||
/ / \ \
|
/ / \ \
|
||||||
root test1 test2 test3
|
root test1 test2 test3
|
||||||
|
|
||||||
Down the line we can implement hierarchical accounting/control support
|
Nesting cgroups, while allowed, isn't officially supported and blkio
|
||||||
and also introduce a new cgroup file "use_hierarchy" which will control
|
genereates warning when cgroups nest. Once throttling implements
|
||||||
whether cgroup hierarchy is viewed as flat or hierarchical by the policy..
|
hierarchy support, hierarchy will be supported and the warning will
|
||||||
This is how memory controller also has implemented the things.
|
be removed.
|
||||||
|
|
||||||
Various user visible config options
|
Various user visible config options
|
||||||
===================================
|
===================================
|
||||||
|
@ -172,6 +174,12 @@ Proportional weight policy files
|
||||||
dev weight
|
dev weight
|
||||||
8:16 300
|
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
|
- blkio.time
|
||||||
- disk time allocated to cgroup per device in milliseconds. First
|
- disk time allocated to cgroup per device in milliseconds. First
|
||||||
two fields specify the major and minor number of the device and
|
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
|
and minor number of the device and third field specifies the number
|
||||||
of times a group was dequeued from a particular device.
|
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
|
Throttling/Upper limit policy files
|
||||||
-----------------------------------
|
-----------------------------------
|
||||||
- blkio.throttle.read_bps_device
|
- blkio.throttle.read_bps_device
|
||||||
|
|
|
@ -87,6 +87,10 @@ As any static code analyzer, Coccinelle produces false
|
||||||
positives. Thus, reports must be carefully checked, and patches
|
positives. Thus, reports must be carefully checked, and patches
|
||||||
reviewed.
|
reviewed.
|
||||||
|
|
||||||
|
To enable verbose messages set the V= variable, for example:
|
||||||
|
|
||||||
|
make coccicheck MODE=report V=1
|
||||||
|
|
||||||
|
|
||||||
Using Coccinelle with a single semantic patch
|
Using Coccinelle with a single semantic patch
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
77
Documentation/device-mapper/cache-policies.txt
Normal file
77
Documentation/device-mapper/cache-policies.txt
Normal 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
243
Documentation/device-mapper/cache.txt
Normal 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
24
Documentation/devicetree/bindings/arc/interrupts.txt
Normal 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
6
Documentation/devicetree/bindings/arm/armadeus.txt
Normal 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";
|
|
@ -5,6 +5,14 @@ i.MX23 Evaluation Kit
|
||||||
Required root node properties:
|
Required root node properties:
|
||||||
- compatible = "fsl,imx23-evk", "fsl,imx23";
|
- 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
|
i.MX28 Evaluation Kit
|
||||||
Required root node properties:
|
Required root node properties:
|
||||||
- compatible = "fsl,imx28-evk", "fsl,imx28";
|
- compatible = "fsl,imx28-evk", "fsl,imx28";
|
||||||
|
|
|
@ -171,6 +171,7 @@ clocks and IDs.
|
||||||
can_sel 156
|
can_sel 156
|
||||||
can1_serial_gate 157
|
can1_serial_gate 157
|
||||||
can1_ipg_gate 158
|
can1_ipg_gate 158
|
||||||
|
owire_gate 159
|
||||||
|
|
||||||
Examples (for mx53):
|
Examples (for mx53):
|
||||||
|
|
||||||
|
|
|
@ -203,6 +203,8 @@ clocks and IDs.
|
||||||
pcie_ref 188
|
pcie_ref 188
|
||||||
pcie_ref_125m 189
|
pcie_ref_125m 189
|
||||||
enet_ref 190
|
enet_ref 190
|
||||||
|
usbphy1_gate 191
|
||||||
|
usbphy2_gate 192
|
||||||
|
|
||||||
Examples:
|
Examples:
|
||||||
|
|
||||||
|
|
|
@ -54,8 +54,13 @@ PROPERTIES
|
||||||
- compatible
|
- compatible
|
||||||
Usage: required
|
Usage: required
|
||||||
Value type: <string>
|
Value type: <string>
|
||||||
Definition: Must include "fsl,sec-v4.0". Also includes SEC
|
Definition: Must include "fsl,sec-v4.0"
|
||||||
ERA versions (optional) with which the device is compatible.
|
|
||||||
|
- fsl,sec-era
|
||||||
|
Usage: optional
|
||||||
|
Value type: <u32>
|
||||||
|
Definition: A standard property. Define the 'ERA' of the SEC
|
||||||
|
device.
|
||||||
|
|
||||||
- #address-cells
|
- #address-cells
|
||||||
Usage: required
|
Usage: required
|
||||||
|
@ -107,7 +112,8 @@ PROPERTIES
|
||||||
|
|
||||||
EXAMPLE
|
EXAMPLE
|
||||||
crypto@300000 {
|
crypto@300000 {
|
||||||
compatible = "fsl,sec-v4.0", "fsl,sec-era-v2.0";
|
compatible = "fsl,sec-v4.0";
|
||||||
|
fsl,sec-era = <2>;
|
||||||
#address-cells = <1>;
|
#address-cells = <1>;
|
||||||
#size-cells = <1>;
|
#size-cells = <1>;
|
||||||
reg = <0x300000 0x10000>;
|
reg = <0x300000 0x10000>;
|
||||||
|
|
|
@ -10,7 +10,11 @@ Required properties:
|
||||||
- interrupts: interrupt number to the cpu.
|
- interrupts: interrupt number to the cpu.
|
||||||
|
|
||||||
Optional properties:
|
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:
|
Example:
|
||||||
|
|
||||||
|
@ -18,16 +22,23 @@ Example:
|
||||||
compatible = "arm,pl330", "arm,primecell";
|
compatible = "arm,pl330", "arm,primecell";
|
||||||
reg = <0x12680000 0x1000>;
|
reg = <0x12680000 0x1000>;
|
||||||
interrupts = <99>;
|
interrupts = <99>;
|
||||||
|
#dma-cells = <1>;
|
||||||
|
#dma-channels = <8>;
|
||||||
|
#dma-requests = <32>;
|
||||||
};
|
};
|
||||||
|
|
||||||
Client drivers (device nodes requiring dma transfers from dev-to-mem or
|
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.
|
as shown below.
|
||||||
|
|
||||||
[property name] = <[phandle of the dma controller] [dma request id]>;
|
[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
|
where 'dma request id' is the dma request number which is connected
|
||||||
to the client controller. The 'property name' is recommended to be
|
to the client controller. The 'property name' 'dmas' and 'dma-names'
|
||||||
of the form <name>-dma-channel.
|
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
81
Documentation/devicetree/bindings/dma/dma.txt
Normal 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";
|
|
@ -3,15 +3,61 @@
|
||||||
Required properties:
|
Required properties:
|
||||||
- compatible: "snps,dma-spear1340"
|
- compatible: "snps,dma-spear1340"
|
||||||
- reg: Address range of the DMAC registers
|
- 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
|
- interrupt-parent: Should be the phandle for the interrupt controller
|
||||||
that services interrupts for this device
|
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:
|
Example:
|
||||||
|
|
||||||
dma@fc000000 {
|
dmahost: dma@fc000000 {
|
||||||
compatible = "snps,dma-spear1340";
|
compatible = "snps,dma-spear1340";
|
||||||
reg = <0xfc000000 0x1000>;
|
reg = <0xfc000000 0x1000>;
|
||||||
interrupt-parent = <&vic1>;
|
interrupt-parent = <&vic1>;
|
||||||
interrupts = <12>;
|
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
59
Documentation/devicetree/bindings/drm/tilcdc/panel.txt
Normal 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
18
Documentation/devicetree/bindings/drm/tilcdc/slave.txt
Normal 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
21
Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt
Normal 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
21
Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
Normal 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
20
Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
Normal 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>;
|
||||||
|
};
|
|
@ -8,6 +8,8 @@ Required properties:
|
||||||
(b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c.
|
(b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c.
|
||||||
(c) "samsung, s3c2440-hdmiphy-i2c", for s3c2440-like i2c used
|
(c) "samsung, s3c2440-hdmiphy-i2c", for s3c2440-like i2c used
|
||||||
inside HDMIPHY block found on several samsung SoCs
|
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
|
- reg: physical base address of the controller and length of memory mapped
|
||||||
region.
|
region.
|
||||||
- interrupts: interrupt number to the cpu.
|
- interrupts: interrupt number to the cpu.
|
||||||
|
|
48
Documentation/devicetree/bindings/leds/leds-pwm.txt
Normal file
48
Documentation/devicetree/bindings/leds/leds-pwm.txt
Normal 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
33
Documentation/devicetree/bindings/leds/tca6507.txt
Normal 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
16
Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
Normal 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
82
Documentation/devicetree/bindings/metag/meta-intc.txt
Normal 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
64
Documentation/devicetree/bindings/mfd/max8925.txt
Normal 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
47
Documentation/devicetree/bindings/mips/cpu_irq.txt
Normal 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
18
Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt
Normal 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>;
|
||||||
|
};
|
|
@ -6,23 +6,45 @@ Interpreted by the OF core:
|
||||||
- reg: Registers location and length.
|
- reg: Registers location and length.
|
||||||
- interrupts: Interrupts used by the MMC controller.
|
- interrupts: Interrupts used by the MMC controller.
|
||||||
|
|
||||||
Required properties:
|
|
||||||
- bus-width: Number of data lines, can be <1>, <4>, or <8>
|
|
||||||
|
|
||||||
Card detection:
|
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:
|
Only one of the properties in this section should be supplied:
|
||||||
- broken-cd: There is no card detection available; polling must be used.
|
- broken-cd: There is no card detection available; polling must be used.
|
||||||
- cd-gpios: Specify GPIOs for card detection, see gpio binding
|
- cd-gpios: Specify GPIOs for card detection, see gpio binding
|
||||||
- non-removable: non-removable slot (like eMMC); assume always present.
|
- non-removable: non-removable slot (like eMMC); assume always present.
|
||||||
|
|
||||||
Optional properties:
|
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
|
- wp-gpios: Specify GPIOs for write protection, see gpio binding
|
||||||
- cd-inverted: when present, polarity on the cd gpio line is inverted
|
- cd-inverted: when present, polarity on the CD line is inverted. See the note
|
||||||
- wp-inverted: when present, polarity on the wp gpio line is inverted
|
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
|
- max-frequency: maximum operating clock frequency
|
||||||
- no-1-8-v: when present, denotes that 1.8v card voltage is not supported on
|
- 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.
|
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:
|
Optional SDIO properties:
|
||||||
- keep-power-in-suspend: Preserves card power during a suspend/resume cycle
|
- keep-power-in-suspend: Preserves card power during a suspend/resume cycle
|
||||||
|
|
17
Documentation/devicetree/bindings/mmc/orion-sdio.txt
Normal file
17
Documentation/devicetree/bindings/mmc/orion-sdio.txt
Normal 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";
|
||||||
|
};
|
|
@ -26,8 +26,16 @@ Required Properties:
|
||||||
* bus-width: as documented in mmc core bindings.
|
* bus-width: as documented in mmc core bindings.
|
||||||
|
|
||||||
* wp-gpios: specifies the write protect gpio line. The format of the
|
* wp-gpios: specifies the write protect gpio line. The format of the
|
||||||
gpio specifier depends on the gpio controller. If the write-protect
|
gpio specifier depends on the gpio controller. If a GPIO is not used
|
||||||
line is not available, this property is optional.
|
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:
|
Optional properties:
|
||||||
|
|
||||||
|
|
20
Documentation/devicetree/bindings/mmc/tmio_mmc.txt
Normal file
20
Documentation/devicetree/bindings/mmc/tmio_mmc.txt
Normal 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
16
Documentation/devicetree/bindings/mtd/elm.txt
Normal 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>;
|
||||||
|
};
|
|
@ -26,6 +26,9 @@ file systems on embedded devices.
|
||||||
- linux,mtd-name: allow to specify the mtd name for retro capability with
|
- 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
|
physmap-flash drivers as boot loader pass the mtd partition via the old
|
||||||
device name physmap-flash.
|
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
|
For JEDEC compatible devices, the following additional properties
|
||||||
are defined:
|
are defined:
|
||||||
|
|
|
@ -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>;
|
||||||
|
};
|
|
@ -17,9 +17,20 @@ Recommended properties:
|
||||||
contains a functioning "reset control register" (i.e. the board
|
contains a functioning "reset control register" (i.e. the board
|
||||||
is wired to reset upon setting the HRESET_REQ bit in this register).
|
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 */
|
global-utilities@e0000 { /* global utilities block */
|
||||||
compatible = "fsl,mpc8548-guts";
|
compatible = "fsl,mpc8548-guts";
|
||||||
reg = <e0000 1000>;
|
reg = <e0000 1000>;
|
||||||
fsl,has-rstcr;
|
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
140
Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
Normal 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
18
Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
Normal 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>;
|
||||||
|
};
|
|
@ -3,14 +3,17 @@ VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller
|
||||||
Required properties:
|
Required properties:
|
||||||
- compatible: should be "via,vt8500-pwm"
|
- compatible: should be "via,vt8500-pwm"
|
||||||
- reg: physical base address and length of the controller's registers
|
- reg: physical base address and length of the controller's registers
|
||||||
- #pwm-cells: should be 2. The first cell specifies the per-chip index
|
- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
|
||||||
of the PWM to use and the second cell is the period in nanoseconds.
|
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
|
- clocks: phandle to the PWM source clock
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
pwm1: pwm@d8220000 {
|
pwm1: pwm@d8220000 {
|
||||||
#pwm-cells = <2>;
|
#pwm-cells = <3>;
|
||||||
compatible = "via,vt8500-pwm";
|
compatible = "via,vt8500-pwm";
|
||||||
reg = <0xd8220000 0x1000>;
|
reg = <0xd8220000 0x1000>;
|
||||||
clocks = <&clkpwm>;
|
clocks = <&clkpwm>;
|
||||||
|
|
122
Documentation/devicetree/bindings/regulator/tps65090.txt
Normal file
122
Documentation/devicetree/bindings/regulator/tps65090.txt
Normal 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
16
Documentation/devicetree/bindings/serial/lantiq_asc.txt
Normal 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
18
Documentation/devicetree/bindings/thermal/dove-thermal.txt
Normal 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>;
|
||||||
|
};
|
|
@ -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
29
Documentation/devicetree/bindings/thermal/rcar-thermal.txt
Normal 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>;
|
||||||
|
};
|
|
@ -1,10 +1,13 @@
|
||||||
Marvell Armada 370 and Armada XP Global Timers
|
Marvell Armada 370 and Armada XP Timers
|
||||||
----------------------------------------------
|
---------------------------------------
|
||||||
|
|
||||||
Required properties:
|
Required properties:
|
||||||
- compatible: Should be "marvell,armada-370-xp-timer"
|
- compatible: Should be "marvell,armada-370-xp-timer"
|
||||||
- interrupts: Should contain the list of Global Timer interrupts
|
- interrupts: Should contain the list of Global Timer interrupts and
|
||||||
- reg: Should contain the base address of the Global Timer registers
|
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
|
- clocks: clock driving the timer hardware
|
||||||
|
|
||||||
Optional properties:
|
Optional properties:
|
|
@ -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
109
Documentation/devicetree/bindings/video/display-timing.txt
Normal 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
19
Documentation/devicetree/bindings/w1/fsl-imx-owire.txt
Normal 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";
|
||||||
|
};
|
|
@ -0,0 +1,9 @@
|
||||||
|
Atmel AT91RM9200 System Timer Watchdog
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: must be "atmel,at91sam9260-wdt".
|
||||||
|
|
||||||
|
Example:
|
||||||
|
watchdog@fffffd00 {
|
||||||
|
compatible = "atmel,at91rm9200-wdt";
|
||||||
|
};
|
|
@ -7,9 +7,13 @@ Required properties:
|
||||||
- reg: physical base address of the controller and length of memory mapped
|
- reg: physical base address of the controller and length of memory mapped
|
||||||
region.
|
region.
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- timeout-sec: contains the watchdog timeout in seconds.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
watchdog@fffffd40 {
|
watchdog@fffffd40 {
|
||||||
compatible = "atmel,at91sam9260-wdt";
|
compatible = "atmel,at91sam9260-wdt";
|
||||||
reg = <0xfffffd40 0x10>;
|
reg = <0xfffffd40 0x10>;
|
||||||
|
timeout-sec = <10>;
|
||||||
};
|
};
|
||||||
|
|
|
@ -5,10 +5,15 @@ Required Properties:
|
||||||
- Compatibility : "marvell,orion-wdt"
|
- Compatibility : "marvell,orion-wdt"
|
||||||
- reg : Address of the timer registers
|
- reg : Address of the timer registers
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
|
||||||
|
- timeout-sec : Contains the watchdog timeout in seconds
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
wdt@20300 {
|
wdt@20300 {
|
||||||
compatible = "marvell,orion-wdt";
|
compatible = "marvell,orion-wdt";
|
||||||
reg = <0x20300 0x28>;
|
reg = <0x20300 0x28>;
|
||||||
|
timeout-sec = <10>;
|
||||||
status = "okay";
|
status = "okay";
|
||||||
};
|
};
|
||||||
|
|
|
@ -5,9 +5,13 @@ Required properties:
|
||||||
- reg: physical base address of the controller and length of memory mapped
|
- reg: physical base address of the controller and length of memory mapped
|
||||||
region.
|
region.
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- timeout-sec: contains the watchdog timeout in seconds.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
watchdog@4003C000 {
|
watchdog@4003C000 {
|
||||||
compatible = "nxp,pnx4008-wdt";
|
compatible = "nxp,pnx4008-wdt";
|
||||||
reg = <0x4003C000 0x1000>;
|
reg = <0x4003C000 0x1000>;
|
||||||
|
timeout-sec = <10>;
|
||||||
};
|
};
|
||||||
|
|
|
@ -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>;
|
||||||
|
};
|
|
@ -9,3 +9,6 @@ Required properties:
|
||||||
- reg : base physical address of the controller and length of memory mapped
|
- reg : base physical address of the controller and length of memory mapped
|
||||||
region.
|
region.
|
||||||
- interrupts : interrupt number to the cpu.
|
- interrupts : interrupt number to the cpu.
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- timeout-sec : contains the watchdog timeout in seconds.
|
||||||
|
|
|
@ -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)
|
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
|
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
|
3. Finish access
|
||||||
|
|
||||||
|
|
|
@ -23,7 +23,7 @@ use IO::Handle;
|
||||||
|
|
||||||
@components = ( "sp8870", "sp887x", "tda10045", "tda10046",
|
@components = ( "sp8870", "sp887x", "tda10045", "tda10046",
|
||||||
"tda10046lifeview", "av7110", "dec2000t", "dec2540t",
|
"tda10046lifeview", "av7110", "dec2000t", "dec2540t",
|
||||||
"dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
|
"dec3000s", "vp7041", "vp7049", "dibusb", "nxt2002", "nxt2004",
|
||||||
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
|
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
|
||||||
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
|
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
|
||||||
"af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
|
"af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
|
||||||
|
@ -289,6 +289,19 @@ sub vp7041 {
|
||||||
$outfile;
|
$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 {
|
sub dibusb {
|
||||||
my $url = "http://www.linuxtv.org/downloads/firmware/dvb-usb-dibusb-5.0.0.11.fw";
|
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";
|
my $outfile = "dvb-dibusb-5.0.0.11.fw";
|
||||||
|
@ -677,7 +690,7 @@ sub drxk_terratec_h5 {
|
||||||
}
|
}
|
||||||
|
|
||||||
sub drxk_terratec_htc_stick {
|
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 $zipfile = "Cinergy_HTC_Stick_Drv_5.09.1202.00_XP_Vista_7.exe";
|
||||||
my $hash = "6722a2442a05423b781721fbc069ed5e";
|
my $hash = "6722a2442a05423b781721fbc069ed5e";
|
||||||
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0);
|
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0);
|
||||||
|
|
|
@ -10,6 +10,7 @@ be able to use diff(1).
|
||||||
--------------------------- dentry_operations --------------------------
|
--------------------------- dentry_operations --------------------------
|
||||||
prototypes:
|
prototypes:
|
||||||
int (*d_revalidate)(struct dentry *, unsigned int);
|
int (*d_revalidate)(struct dentry *, unsigned int);
|
||||||
|
int (*d_weak_revalidate)(struct dentry *, unsigned int);
|
||||||
int (*d_hash)(const struct dentry *, const struct inode *,
|
int (*d_hash)(const struct dentry *, const struct inode *,
|
||||||
struct qstr *);
|
struct qstr *);
|
||||||
int (*d_compare)(const struct dentry *, const struct inode *,
|
int (*d_compare)(const struct dentry *, const struct inode *,
|
||||||
|
@ -25,6 +26,7 @@ prototypes:
|
||||||
locking rules:
|
locking rules:
|
||||||
rename_lock ->d_lock may block rcu-walk
|
rename_lock ->d_lock may block rcu-walk
|
||||||
d_revalidate: no no yes (ref-walk) maybe
|
d_revalidate: no no yes (ref-walk) maybe
|
||||||
|
d_weak_revalidate:no no yes no
|
||||||
d_hash no no no maybe
|
d_hash no no no maybe
|
||||||
d_compare: yes no no maybe
|
d_compare: yes no no maybe
|
||||||
d_delete: no yes no no
|
d_delete: no yes no no
|
||||||
|
|
|
@ -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
|
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
|
local filesystems can ignore tha argument - they are guaranteed that the
|
||||||
object doesn't exist. It's remote/distributed ones that might care...
|
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.
|
||||||
|
|
|
@ -900,6 +900,7 @@ defined:
|
||||||
|
|
||||||
struct dentry_operations {
|
struct dentry_operations {
|
||||||
int (*d_revalidate)(struct dentry *, unsigned int);
|
int (*d_revalidate)(struct dentry *, unsigned int);
|
||||||
|
int (*d_weak_revalidate)(struct dentry *, unsigned int);
|
||||||
int (*d_hash)(const struct dentry *, const struct inode *,
|
int (*d_hash)(const struct dentry *, const struct inode *,
|
||||||
struct qstr *);
|
struct qstr *);
|
||||||
int (*d_compare)(const struct dentry *, const struct inode *,
|
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
|
d_revalidate: called when the VFS needs to revalidate a dentry. This
|
||||||
is called whenever a name look-up finds a dentry in the
|
is called whenever a name look-up finds a dentry in the
|
||||||
dcache. Most filesystems leave this as NULL, because all their
|
dcache. Most local filesystems leave this as NULL, because all their
|
||||||
dentries in the dcache are valid
|
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).
|
d_revalidate may be called in rcu-walk mode (flags & LOOKUP_RCU).
|
||||||
If in rcu-walk mode, the filesystem must revalidate the dentry without
|
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
|
If a situation is encountered that rcu-walk cannot handle, return
|
||||||
-ECHILD and it will be called again in ref-walk mode.
|
-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
|
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
|
dentry passed to d_hash is the parent directory that the name is
|
||||||
to be hashed into. The inode is the dentry's inode.
|
to be hashed into. The inode is the dentry's inode.
|
||||||
|
|
|
@ -22,6 +22,8 @@ Supported adapters:
|
||||||
* Intel Panther Point (PCH)
|
* Intel Panther Point (PCH)
|
||||||
* Intel Lynx Point (PCH)
|
* Intel Lynx Point (PCH)
|
||||||
* Intel Lynx Point-LP (PCH)
|
* Intel Lynx Point-LP (PCH)
|
||||||
|
* Intel Avoton (SOC)
|
||||||
|
* Intel Wellsburg (PCH)
|
||||||
Datasheets: Publicly available at the Intel website
|
Datasheets: Publicly available at the Intel website
|
||||||
|
|
||||||
On Intel Patsburg and later chipsets, both the normal host SMBus controller
|
On Intel Patsburg and later chipsets, both the normal host SMBus controller
|
||||||
|
|
36
Documentation/i2c/busses/i2c-ismt
Normal file
36
Documentation/i2c/busses/i2c-ismt
Normal 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
|
|
@ -4,9 +4,11 @@ Supported adapters:
|
||||||
* Silicon Integrated Systems Corp (SiS)
|
* Silicon Integrated Systems Corp (SiS)
|
||||||
630 chipset (Datasheet: available at http://www.sfr-fresh.com/linux)
|
630 chipset (Datasheet: available at http://www.sfr-fresh.com/linux)
|
||||||
730 chipset
|
730 chipset
|
||||||
|
964 chipset
|
||||||
* Possible other SiS chipsets ?
|
* Possible other SiS chipsets ?
|
||||||
|
|
||||||
Author: Alexander Malysh <amalysh@web.de>
|
Author: Alexander Malysh <amalysh@web.de>
|
||||||
|
Amaury Decrême <amaury.decreme@gmail.com> - SiS964 support
|
||||||
|
|
||||||
Module Parameters
|
Module Parameters
|
||||||
-----------------
|
-----------------
|
||||||
|
@ -18,6 +20,7 @@ Module Parameters
|
||||||
* high_clock = [1|0] Forcibly set Host Master Clock to 56KHz (default,
|
* high_clock = [1|0] Forcibly set Host Master Clock to 56KHz (default,
|
||||||
what your BIOS use). DANGEROUS! This should be a bit
|
what your BIOS use). DANGEROUS! This should be a bit
|
||||||
faster, but freeze some systems (i.e. my Laptop).
|
faster, but freeze some systems (i.e. my Laptop).
|
||||||
|
SIS630/730 chip only.
|
||||||
|
|
||||||
|
|
||||||
Description
|
Description
|
||||||
|
@ -36,6 +39,12 @@ or like this:
|
||||||
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 730 Host (rev 02)
|
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 730 Host (rev 02)
|
||||||
00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
|
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.
|
in your 'lspci' output , then this driver is for your chipset.
|
||||||
|
|
||||||
Thank You
|
Thank You
|
||||||
|
|
|
@ -137,8 +137,8 @@ available for writes where the two data bytes are the other way
|
||||||
around (not SMBus compliant, but very popular.)
|
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
|
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.
|
16 bits of data to it, and reads 16 bits of data in return.
|
||||||
|
|
|
@ -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_read_word_data(struct i2c_client *client, u8 command);
|
||||||
s32 i2c_smbus_write_word_data(struct i2c_client *client,
|
s32 i2c_smbus_write_word_data(struct i2c_client *client,
|
||||||
u8 command, u16 value);
|
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,
|
s32 i2c_smbus_read_block_data(struct i2c_client *client,
|
||||||
u8 command, u8 *values);
|
u8 command, u8 *values);
|
||||||
s32 i2c_smbus_write_block_data(struct i2c_client *client,
|
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:
|
be added back later if needed:
|
||||||
|
|
||||||
s32 i2c_smbus_write_quick(struct i2c_client *client, u8 value);
|
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,
|
s32 i2c_smbus_block_process_call(struct i2c_client *client,
|
||||||
u8 command, u8 length, u8 *values);
|
u8 command, u8 length, u8 *values);
|
||||||
|
|
||||||
|
|
|
@ -388,26 +388,3 @@ config FOO
|
||||||
depends on BAR && m
|
depends on BAR && m
|
||||||
|
|
||||||
limits FOO to module (=m) or disabled (=n).
|
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.
|
|
||||||
|
|
|
@ -46,6 +46,12 @@ KCONFIG_OVERWRITECONFIG
|
||||||
If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
|
If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
|
||||||
break symlinks when .config is a symlink to somewhere else.
|
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'
|
Environment variables for '{allyes/allmod/allno/rand}config'
|
||||||
|
|
||||||
|
|
|
@ -564,6 +564,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||||
UART at the specified I/O port or MMIO address,
|
UART at the specified I/O port or MMIO address,
|
||||||
switching to the matching ttyS device later. The
|
switching to the matching ttyS device later. The
|
||||||
options are the same as for ttyS, above.
|
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
|
If the device connected to the port is not a TTY but a braille
|
||||||
device, prepend "brl," before the device type, for instance
|
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
|
is selected automatically. Check
|
||||||
Documentation/kdump/kdump.txt for further details.
|
Documentation/kdump/kdump.txt for further details.
|
||||||
|
|
||||||
|
crashkernel_low=size[KMG]
|
||||||
|
[KNL, x86] parts under 4G.
|
||||||
|
|
||||||
crashkernel=range1:size1[,range2:size2,...][@offset]
|
crashkernel=range1:size1[,range2:size2,...][@offset]
|
||||||
[KNL] Same as above, but depends on the memory
|
[KNL] Same as above, but depends on the memory
|
||||||
in the running system. The syntax of range is
|
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= [X86,SH,BLACKFIN]
|
||||||
earlyprintk=vga
|
earlyprintk=vga
|
||||||
|
earlyprintk=xen
|
||||||
earlyprintk=serial[,ttySn[,baudrate]]
|
earlyprintk=serial[,ttySn[,baudrate]]
|
||||||
earlyprintk=ttySn[,baudrate]
|
earlyprintk=ttySn[,baudrate]
|
||||||
earlyprintk=dbgp[debugController#]
|
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
|
The VGA output is eventually overwritten by the real
|
||||||
console.
|
console.
|
||||||
|
|
||||||
|
The xen output can only be used by Xen PV guests.
|
||||||
|
|
||||||
ekgdboc= [X86,KGDB] Allow early kernel console debugging
|
ekgdboc= [X86,KGDB] Allow early kernel console debugging
|
||||||
ekgdboc=kbd
|
ekgdboc=kbd
|
||||||
|
|
||||||
|
@ -970,6 +978,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||||
If specified, z/VM IUCV HVC accepts connections
|
If specified, z/VM IUCV HVC accepts connections
|
||||||
from listed z/VM user IDs only.
|
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]
|
keep_bootcon [KNL]
|
||||||
Do not unregister boot console at start. This is only
|
Do not unregister boot console at start. This is only
|
||||||
useful for debugging when something happens in the window
|
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
|
This sorting is done to get a device
|
||||||
order compatible with older (<= 2.4) kernels.
|
order compatible with older (<= 2.4) kernels.
|
||||||
nobfsort Don't sort PCI devices into breadth-first order.
|
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
|
cbiosize=nn[KMG] The fixed amount of bus space which is
|
||||||
reserved for the CardBus bridge's IO window.
|
reserved for the CardBus bridge's IO window.
|
||||||
The default value is 256 bytes.
|
The default value is 256 bytes.
|
||||||
|
@ -2244,6 +2271,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||||
the default.
|
the default.
|
||||||
off: Turn ECRC off
|
off: Turn ECRC off
|
||||||
on: Turn ECRC on.
|
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
|
realloc= Enable/disable reallocating PCI bridge resources
|
||||||
if allocations done by BIOS are too small to
|
if allocations done by BIOS are too small to
|
||||||
accommodate resources required by all child
|
accommodate resources required by all child
|
||||||
|
|
|
@ -6,5 +6,7 @@ leds-lp5521.txt
|
||||||
- notes on how to use the leds-lp5521 driver.
|
- notes on how to use the leds-lp5521 driver.
|
||||||
leds-lp5523.txt
|
leds-lp5523.txt
|
||||||
- notes on how to use the leds-lp5523 driver.
|
- notes on how to use the leds-lp5523 driver.
|
||||||
|
leds-lp55xx.txt
|
||||||
|
- description about lp55xx common driver.
|
||||||
leds-lm3556.txt
|
leds-lm3556.txt
|
||||||
- notes on how to use the leds-lm3556 driver.
|
- notes on how to use the leds-lm3556 driver.
|
||||||
|
|
|
@ -17,19 +17,8 @@ lp5521:channelx, where x is 0 .. 2
|
||||||
All three channels can be also controlled using the engine micro programs.
|
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.
|
More details of the instructions can be found from the public data sheet.
|
||||||
|
|
||||||
Control interface for the engines:
|
LP5521 has the internal program memory for running various LED patterns.
|
||||||
x is 1 .. 3
|
For the details, please refer to 'firmware' section in leds-lp55xx.txt
|
||||||
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
|
|
||||||
|
|
||||||
sysfs contains a selftest entry.
|
sysfs contains a selftest entry.
|
||||||
The test communicates with the chip and checks that
|
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'
|
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)
|
(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",
|
.name = "red",
|
||||||
.chan_nr = 0,
|
.chan_nr = 0,
|
||||||
|
@ -81,10 +70,10 @@ static void lp5521_enable(bool state)
|
||||||
/* Control of chip enable signal */
|
/* 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,
|
.led_config = lp5521_led_config,
|
||||||
.num_channels = ARRAY_SIZE(lp5521_led_config),
|
.num_channels = ARRAY_SIZE(lp5521_led_config),
|
||||||
.clock_mode = LP5521_CLOCK_EXT,
|
.clock_mode = LP55XX_CLOCK_EXT,
|
||||||
.setup_resources = lp5521_setup,
|
.setup_resources = lp5521_setup,
|
||||||
.release_resources = lp5521_release,
|
.release_resources = lp5521_release,
|
||||||
.enable = lp5521_enable,
|
.enable = lp5521_enable,
|
||||||
|
@ -105,47 +94,9 @@ example of update_config :
|
||||||
LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \
|
LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \
|
||||||
LP5521_CLK_INT)
|
LP5521_CLK_INT)
|
||||||
|
|
||||||
static struct lp5521_platform_data lp5521_pdata = {
|
static struct lp55xx_platform_data lp5521_pdata = {
|
||||||
.led_config = lp5521_led_config,
|
.led_config = lp5521_led_config,
|
||||||
.num_channels = ARRAY_SIZE(lp5521_led_config),
|
.num_channels = ARRAY_SIZE(lp5521_led_config),
|
||||||
.clock_mode = LP5521_CLOCK_INT,
|
.clock_mode = LP55XX_CLOCK_INT,
|
||||||
.update_config = LP5521_CONFIGS,
|
.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,25 +27,8 @@ c) Default
|
||||||
If both fields are NULL, 'lp5523' is used by default.
|
If both fields are NULL, 'lp5523' is used by default.
|
||||||
/sys/class/leds/lp5523:channelN (N: 0 ~ 8)
|
/sys/class/leds/lp5523:channelN (N: 0 ~ 8)
|
||||||
|
|
||||||
The chip provides 3 engines. Each engine can control channels without
|
LP5523 has the internal program memory for running various LED patterns.
|
||||||
interaction from the main CPU. Details of the micro engine code can be found
|
For the details, please refer to 'firmware' section in leds-lp55xx.txt
|
||||||
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.
|
|
||||||
|
|
||||||
Selftest uses always the current from the platform data.
|
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.
|
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",
|
.name = "D1",
|
||||||
.chan_nr = 0,
|
.chan_nr = 0,
|
||||||
|
@ -88,10 +71,10 @@ static void lp5523_enable(bool state)
|
||||||
/* Control chip enable signal */
|
/* 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,
|
.led_config = lp5523_led_config,
|
||||||
.num_channels = ARRAY_SIZE(lp5523_led_config),
|
.num_channels = ARRAY_SIZE(lp5523_led_config),
|
||||||
.clock_mode = LP5523_CLOCK_EXT,
|
.clock_mode = LP55XX_CLOCK_EXT,
|
||||||
.setup_resources = lp5523_setup,
|
.setup_resources = lp5523_setup,
|
||||||
.release_resources = lp5523_release,
|
.release_resources = lp5523_release,
|
||||||
.enable = lp5523_enable,
|
.enable = lp5523_enable,
|
||||||
|
|
118
Documentation/leds/leds-lp55xx.txt
Normal file
118
Documentation/leds/leds-lp55xx.txt
Normal 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.
|
|
@ -65,7 +65,7 @@ that had to wait on lock acquisition.
|
||||||
|
|
||||||
- CONFIGURATION
|
- CONFIGURATION
|
||||||
|
|
||||||
Lock statistics are enabled via CONFIG_LOCK_STATS.
|
Lock statistics are enabled via CONFIG_LOCK_STAT.
|
||||||
|
|
||||||
- USAGE
|
- USAGE
|
||||||
|
|
||||||
|
|
|
@ -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.
|
be identical for all nested calls to the function.
|
||||||
|
|
||||||
media_entity_pipeline_start() may return an error. In that case, it will
|
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
|
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
Loading…
Reference in a new issue