Merge branch 'master' into for-next
Merge with latest Linus' tree, as I have incoming patches that fix code that is newer than current HEAD of for-next. Conflicts: drivers/net/ethernet/realtek/r8169.c
This commit is contained in:
Jiri Kosina
commit
e75d660672
|
|
@ -104,6 +104,8 @@ cpuidle/
|
|||
- info on CPU_IDLE, CPU idle state management subsystem.
|
||||
cputopology.txt
|
||||
- documentation on how CPU topology info is exported via sysfs.
|
||||
crc32.txt
|
||||
- brief tutorial on CRC computation
|
||||
cris/
|
||||
- directory with info about Linux on CRIS architecture.
|
||||
crypto/
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
What: devfs
|
||||
Date: July 2005 (scheduled), finally removed in kernel v2.6.18
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
devfs has been unmaintained for a number of years, has unfixable
|
||||
races, contains a naming policy within the kernel that is
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
What: /sys/bus/usb/drivers/usbtmc/devices/*/interface_capabilities
|
||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/device_capabilities
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
These files show the various USB TMC capabilities as described
|
||||
by the device itself. The full description of the bitfields
|
||||
|
|
@ -15,7 +15,7 @@ Description:
|
|||
What: /sys/bus/usb/drivers/usbtmc/devices/*/usb488_interface_capabilities
|
||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/usb488_device_capabilities
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
These files show the various USB TMC capabilities as described
|
||||
by the device itself. The full description of the bitfields
|
||||
|
|
@ -29,7 +29,7 @@ Description:
|
|||
|
||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/TermChar
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
This file is the TermChar value to be sent to the USB TMC
|
||||
device as described by the document, "Universal Serial Bus Test
|
||||
|
|
@ -42,7 +42,7 @@ Description:
|
|||
|
||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/TermCharEnabled
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
This file determines if the TermChar is to be sent to the
|
||||
device on every transaction or not. For more details about
|
||||
|
|
@ -53,9 +53,9 @@ Description:
|
|||
|
||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/auto_abort
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
This file determines if the the transaction of the USB TMC
|
||||
This file determines if the transaction of the USB TMC
|
||||
device is to be automatically aborted if there is any error.
|
||||
For more details about this, please see the document,
|
||||
"Universal Serial Bus Test and Measurement Class Specification
|
||||
|
|
|
|||
|
|
@ -0,0 +1,16 @@
|
|||
What: /sys/kernel/debug/olpc-ec/cmd
|
||||
Date: Dec 2011
|
||||
KernelVersion: 3.4
|
||||
Contact: devel@lists.laptop.org
|
||||
Description:
|
||||
|
||||
A generic interface for executing OLPC Embedded Controller commands and
|
||||
reading their responses.
|
||||
|
||||
To execute a command, write data with the format: CC:N A A A A
|
||||
CC is the (hex) command, N is the count of expected reply bytes, and A A A A
|
||||
are optional (hex) arguments.
|
||||
|
||||
To read the response (if any), read from the generic node after executing
|
||||
a command. Hex reply bytes will be returned, *whether or not* they came from
|
||||
the immediately previous command.
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
What: /sys/block/dm-<num>/dm/name
|
||||
Date: January 2009
|
||||
KernelVersion: 2.6.29
|
||||
Contact: dm-devel@redhat.com
|
||||
Description: Device-mapper device name.
|
||||
Read-only string containing mapped device name.
|
||||
Users: util-linux, device-mapper udev rules
|
||||
|
||||
What: /sys/block/dm-<num>/dm/uuid
|
||||
Date: January 2009
|
||||
KernelVersion: 2.6.29
|
||||
Contact: dm-devel@redhat.com
|
||||
Description: Device-mapper device UUID.
|
||||
Read-only string containing DM-UUID or empty string
|
||||
if DM-UUID is not set.
|
||||
Users: util-linux, device-mapper udev rules
|
||||
|
||||
What: /sys/block/dm-<num>/dm/suspended
|
||||
Date: June 2009
|
||||
KernelVersion: 2.6.31
|
||||
Contact: dm-devel@redhat.com
|
||||
Description: Device-mapper device suspend state.
|
||||
Contains the value 1 while the device is suspended.
|
||||
Otherwise it contains 0. Read-only attribute.
|
||||
Users: util-linux, device-mapper udev rules
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
Where: /sys/bus/event_source/devices/<dev>/format
|
||||
Date: January 2012
|
||||
Kernel Version: 3.3
|
||||
Contact: Jiri Olsa <jolsa@redhat.com>
|
||||
Description:
|
||||
Attribute group to describe the magic bits that go into
|
||||
perf_event_attr::config[012] for a particular pmu.
|
||||
Each attribute of this group defines the 'hardware' bitmask
|
||||
we want to export, so that userspace can deal with sane
|
||||
name/value pairs.
|
||||
|
||||
Example: 'config1:1,6-10,44'
|
||||
Defines contents of attribute that occupies bits 1,6-10,44 of
|
||||
perf_event_attr::config1.
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
What: /sys/bus/rpmsg/devices/.../name
|
||||
Date: June 2011
|
||||
KernelVersion: 3.3
|
||||
Contact: Ohad Ben-Cohen <ohad@wizery.com>
|
||||
Description:
|
||||
Every rpmsg device is a communication channel with a remote
|
||||
processor. Channels are identified with a (textual) name,
|
||||
which is maximum 32 bytes long (defined as RPMSG_NAME_SIZE in
|
||||
rpmsg.h).
|
||||
|
||||
This sysfs entry contains the name of this channel.
|
||||
|
||||
What: /sys/bus/rpmsg/devices/.../src
|
||||
Date: June 2011
|
||||
KernelVersion: 3.3
|
||||
Contact: Ohad Ben-Cohen <ohad@wizery.com>
|
||||
Description:
|
||||
Every rpmsg device is a communication channel with a remote
|
||||
processor. Channels have a local ("source") rpmsg address,
|
||||
and remote ("destination") rpmsg address. When an entity
|
||||
starts listening on one end of a channel, it assigns it with
|
||||
a unique rpmsg address (a 32 bits integer). This way when
|
||||
inbound messages arrive to this address, the rpmsg core
|
||||
dispatches them to the listening entity (a kernel driver).
|
||||
|
||||
This sysfs entry contains the src (local) rpmsg address
|
||||
of this channel. If it contains 0xffffffff, then an address
|
||||
wasn't assigned (can happen if no driver exists for this
|
||||
channel).
|
||||
|
||||
What: /sys/bus/rpmsg/devices/.../dst
|
||||
Date: June 2011
|
||||
KernelVersion: 3.3
|
||||
Contact: Ohad Ben-Cohen <ohad@wizery.com>
|
||||
Description:
|
||||
Every rpmsg device is a communication channel with a remote
|
||||
processor. Channels have a local ("source") rpmsg address,
|
||||
and remote ("destination") rpmsg address. When an entity
|
||||
starts listening on one end of a channel, it assigns it with
|
||||
a unique rpmsg address (a 32 bits integer). This way when
|
||||
inbound messages arrive to this address, the rpmsg core
|
||||
dispatches them to the listening entity.
|
||||
|
||||
This sysfs entry contains the dst (remote) rpmsg address
|
||||
of this channel. If it contains 0xffffffff, then an address
|
||||
wasn't assigned (can happen if the kernel driver that
|
||||
is attached to this channel is exposing a service to the
|
||||
remote processor. This make it a local rpmsg server,
|
||||
and it is listening for inbound messages that may be sent
|
||||
from any remote rpmsg client; it is not bound to a single
|
||||
remote entity).
|
||||
|
||||
What: /sys/bus/rpmsg/devices/.../announce
|
||||
Date: June 2011
|
||||
KernelVersion: 3.3
|
||||
Contact: Ohad Ben-Cohen <ohad@wizery.com>
|
||||
Description:
|
||||
Every rpmsg device is a communication channel with a remote
|
||||
processor. Channels are identified by a textual name (see
|
||||
/sys/bus/rpmsg/devices/.../name above) and have a local
|
||||
("source") rpmsg address, and remote ("destination") rpmsg
|
||||
address.
|
||||
|
||||
A channel is first created when an entity, whether local
|
||||
or remote, starts listening on it for messages (and is thus
|
||||
called an rpmsg server).
|
||||
|
||||
When that happens, a "name service" announcement is sent
|
||||
to the other processor, in order to let it know about the
|
||||
creation of the channel (this way remote clients know they
|
||||
can start sending messages).
|
||||
|
||||
This sysfs entry tells us whether the channel is a local
|
||||
server channel that is announced (values are either
|
||||
true or false).
|
||||
|
|
@ -182,3 +182,14 @@ Description:
|
|||
USB2 hardware LPM is enabled for the device. Developer can
|
||||
write y/Y/1 or n/N/0 to the file to enable/disable the
|
||||
feature.
|
||||
|
||||
What: /sys/bus/usb/devices/.../removable
|
||||
Date: February 2012
|
||||
Contact: Matthew Garrett <mjg@redhat.com>
|
||||
Description:
|
||||
Some information about whether a given USB device is
|
||||
physically fixed to the platform can be inferred from a
|
||||
combination of hub decriptor bits and platform-specific data
|
||||
such as ACPI. This file will read either "removable" or
|
||||
"fixed" if the information is available, and "unknown"
|
||||
otherwise.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
What: /sys/class/
|
||||
Date: Febuary 2006
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
The /sys/class directory will consist of a group of
|
||||
subdirectories describing individual classes of devices
|
||||
|
|
|
|||
|
|
@ -65,6 +65,13 @@ Description:
|
|||
Defines the penalty which will be applied to an
|
||||
originator message's tq-field on every hop.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/routing_algo
|
||||
Date: Dec 2011
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Description:
|
||||
Defines the routing procotol this mesh instance
|
||||
uses to find the optimal paths through the mesh.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/vis_mode
|
||||
Date: May 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
What: /sys/devices
|
||||
Date: February 2006
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
The /sys/devices tree contains a snapshot of the
|
||||
internal state of the kernel device tree. Devices will
|
||||
|
|
|
|||
|
|
@ -165,3 +165,21 @@ Description:
|
|||
|
||||
Not all drivers support this attribute. If it isn't supported,
|
||||
attempts to read or write it will yield I/O errors.
|
||||
|
||||
What: /sys/devices/.../power/pm_qos_latency_us
|
||||
Date: March 2012
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Description:
|
||||
The /sys/devices/.../power/pm_qos_resume_latency_us attribute
|
||||
contains the PM QoS resume latency limit for the given device,
|
||||
which is the maximum allowed time it can take to resume the
|
||||
device, after it has been suspended at run time, from a resume
|
||||
request to the moment the device will be ready to process I/O,
|
||||
in microseconds. If it is equal to 0, however, this means that
|
||||
the PM QoS resume latency may be arbitrary.
|
||||
|
||||
Not all drivers support this attribute. If it isn't supported,
|
||||
it is not present.
|
||||
|
||||
This attribute has no effect on system-wide suspend/resume and
|
||||
hibernation.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,58 @@
|
|||
What: /sys/devices/socX
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
The /sys/devices/ directory contains a sub-directory for each
|
||||
System-on-Chip (SoC) device on a running platform. Information
|
||||
regarding each SoC can be obtained by reading sysfs files. This
|
||||
functionality is only available if implemented by the platform.
|
||||
|
||||
The directory created for each SoC will also house information
|
||||
about devices which are commonly contained in /sys/devices/platform.
|
||||
It has been agreed that if an SoC device exists, its supported
|
||||
devices would be better suited to appear as children of that SoC.
|
||||
|
||||
What: /sys/devices/socX/machine
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
Read-only attribute common to all SoCs. Contains the SoC machine
|
||||
name (e.g. Ux500).
|
||||
|
||||
What: /sys/devices/socX/family
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
Read-only attribute common to all SoCs. Contains SoC family name
|
||||
(e.g. DB8500).
|
||||
|
||||
What: /sys/devices/socX/soc_id
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
Read-only attribute supported by most SoCs. In the case of
|
||||
ST-Ericsson's chips this contains the SoC serial number.
|
||||
|
||||
What: /sys/devices/socX/revision
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
Read-only attribute supported by most SoCs. Contains the SoC's
|
||||
manufacturing revision number.
|
||||
|
||||
What: /sys/devices/socX/process
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
Read-only attribute supported ST-Ericsson's silicon. Contains the
|
||||
the process by which the silicon chip was manufactured.
|
||||
|
||||
What: /sys/bus/soc
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
The /sys/bus/soc/ directory contains the usual sub-folders
|
||||
expected under most buses. /sys/bus/soc/devices is of particular
|
||||
interest, as it contains a symlink for each SoC device found on
|
||||
the system. Each symlink points back into the aforementioned
|
||||
/sys/devices/socX devices.
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
What: /sys/devices/platform/samsung/performance_level
|
||||
Date: January 1, 2010
|
||||
KernelVersion: 2.6.33
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description: Some Samsung laptops have different "performance levels"
|
||||
that are can be modified by a function key, and by this
|
||||
sysfs file. These values don't always make a whole lot
|
||||
|
|
@ -17,3 +17,21 @@ Description: Some Samsung laptops have different "performance levels"
|
|||
Specifically, not all support the "overclock" option,
|
||||
and it's still unknown if this value even changes
|
||||
anything, other than making the user feel a bit better.
|
||||
|
||||
What: /sys/devices/platform/samsung/battery_life_extender
|
||||
Date: December 1, 2011
|
||||
KernelVersion: 3.3
|
||||
Contact: Corentin Chary <corentin.chary@gmail.com>
|
||||
Description: Max battery charge level can be modified, battery cycle
|
||||
life can be extended by reducing the max battery charge
|
||||
level.
|
||||
0 means normal battery mode (100% charge)
|
||||
1 means battery life extender mode (80% charge)
|
||||
|
||||
What: /sys/devices/platform/samsung/usb_charge
|
||||
Date: December 1, 2011
|
||||
KernelVersion: 3.3
|
||||
Contact: Corentin Chary <corentin.chary@gmail.com>
|
||||
Description: Use your USB ports to charge devices, even
|
||||
when your laptop is powered off.
|
||||
1 means enabled, 0 means disabled.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,23 @@
|
|||
What: /sys/firmware/acpi/bgrt/
|
||||
Date: January 2012
|
||||
Contact: Matthew Garrett <mjg@redhat.com>
|
||||
Description:
|
||||
The BGRT is an ACPI 5.0 feature that allows the OS
|
||||
to obtain a copy of the firmware boot splash and
|
||||
some associated metadata. This is intended to be used
|
||||
by boot splash applications in order to interact with
|
||||
the firmware boot splash in order to avoid jarring
|
||||
transitions.
|
||||
|
||||
image: The image bitmap. Currently a 32-bit BMP.
|
||||
status: 1 if the image is valid, 0 if firmware invalidated it.
|
||||
type: 0 indicates image is in BMP format.
|
||||
version: The version of the BGRT. Currently 1.
|
||||
xoffset: The number of pixels between the left of the screen
|
||||
and the left edge of the image.
|
||||
yoffset: The number of pixels between the top of the screen
|
||||
and the top edge of the image.
|
||||
|
||||
What: /sys/firmware/acpi/interrupts/
|
||||
Date: February 2008
|
||||
Contact: Len Brown <lenb@kernel.org>
|
||||
|
|
|
|||
|
|
@ -1,11 +0,0 @@
|
|||
What: /sys/kernel/mm/cleancache/
|
||||
Date: April 2011
|
||||
Contact: Dan Magenheimer <dan.magenheimer@oracle.com>
|
||||
Description:
|
||||
/sys/kernel/mm/cleancache/ contains a number of files which
|
||||
record a count of various cleancache operations
|
||||
(sum across all filesystems):
|
||||
succ_gets
|
||||
failed_gets
|
||||
puts
|
||||
flushes
|
||||
|
|
@ -793,6 +793,35 @@ own custom mode, or may have some other magic method for making indentation
|
|||
work correctly.
|
||||
|
||||
|
||||
Chapter 19: Inline assembly
|
||||
|
||||
In architecture-specific code, you may need to use inline assembly to interface
|
||||
with CPU or platform functionality. Don't hesitate to do so when necessary.
|
||||
However, don't use inline assembly gratuitously when C can do the job. You can
|
||||
and should poke hardware from C when possible.
|
||||
|
||||
Consider writing simple helper functions that wrap common bits of inline
|
||||
assembly, rather than repeatedly writing them with slight variations. Remember
|
||||
that inline assembly can use C parameters.
|
||||
|
||||
Large, non-trivial assembly functions should go in .S files, with corresponding
|
||||
C prototypes defined in C header files. The C prototypes for assembly
|
||||
functions should use "asmlinkage".
|
||||
|
||||
You may need to mark your asm statement as volatile, to prevent GCC from
|
||||
removing it if GCC doesn't notice any side effects. You don't always need to
|
||||
do so, though, and doing so unnecessarily can limit optimization.
|
||||
|
||||
When writing a single inline assembly statement containing multiple
|
||||
instructions, put each instruction on a separate line in a separate quoted
|
||||
string, and end each string except the last with \n\t to properly indent the
|
||||
next instruction in the assembly output:
|
||||
|
||||
asm ("magic %reg1, #42\n\t"
|
||||
"more_magic %reg2, %reg3"
|
||||
: /* outputs */ : /* inputs */ : /* clobbers */);
|
||||
|
||||
|
||||
|
||||
Appendix I: References
|
||||
|
||||
|
|
|
|||
|
|
@ -31,3 +31,21 @@ may be weakly ordered, that is that reads and writes may pass each other.
|
|||
Since it is optional for platforms to implement DMA_ATTR_WEAK_ORDERING,
|
||||
those that do not will simply ignore the attribute and exhibit default
|
||||
behavior.
|
||||
|
||||
DMA_ATTR_WRITE_COMBINE
|
||||
----------------------
|
||||
|
||||
DMA_ATTR_WRITE_COMBINE specifies that writes to the mapping may be
|
||||
buffered to improve performance.
|
||||
|
||||
Since it is optional for platforms to implement DMA_ATTR_WRITE_COMBINE,
|
||||
those that do not will simply ignore the attribute and exhibit default
|
||||
behavior.
|
||||
|
||||
DMA_ATTR_NON_CONSISTENT
|
||||
-----------------------
|
||||
|
||||
DMA_ATTR_NON_CONSISTENT lets the platform to choose to return either
|
||||
consistent or non-consistent memory as it sees fit. By using this API,
|
||||
you are guaranteeing to the platform that you have all the correct and
|
||||
necessary sync points for this memory in the driver.
|
||||
|
|
|
|||
|
|
@ -129,7 +129,6 @@
|
|||
!Finclude/net/cfg80211.h cfg80211_pmksa
|
||||
!Finclude/net/cfg80211.h cfg80211_send_rx_auth
|
||||
!Finclude/net/cfg80211.h cfg80211_send_auth_timeout
|
||||
!Finclude/net/cfg80211.h __cfg80211_auth_canceled
|
||||
!Finclude/net/cfg80211.h cfg80211_send_rx_assoc
|
||||
!Finclude/net/cfg80211.h cfg80211_send_assoc_timeout
|
||||
!Finclude/net/cfg80211.h cfg80211_send_deauth
|
||||
|
|
|
|||
|
|
@ -446,4 +446,21 @@ X!Idrivers/video/console/fonts.c
|
|||
!Edrivers/i2c/i2c-core.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="hsi">
|
||||
<title>High Speed Synchronous Serial Interface (HSI)</title>
|
||||
|
||||
<para>
|
||||
High Speed Synchronous Serial Interface (HSI) is a
|
||||
serial interface mainly used for connecting application
|
||||
engines (APE) with cellular modem engines (CMT) in cellular
|
||||
handsets.
|
||||
|
||||
HSI provides multiplexing for up to 16 logical channels,
|
||||
low-latency and full duplex communication.
|
||||
</para>
|
||||
|
||||
!Iinclude/linux/hsi/hsi.h
|
||||
!Edrivers/hsi/hsi.c
|
||||
</chapter>
|
||||
|
||||
</book>
|
||||
|
|
|
|||
|
|
@ -361,6 +361,23 @@
|
|||
<para>It is possible to use this option with kgdboc on a tty that is not a system console.
|
||||
</para>
|
||||
</para>
|
||||
</sect1>
|
||||
<sect1 id="kgdbreboot">
|
||||
<title>Run time parameter: kgdbreboot</title>
|
||||
<para> The kgdbreboot feature allows you to change how the debugger
|
||||
deals with the reboot notification. You have 3 choices for the
|
||||
behavior. The default behavior is always set to 0.</para>
|
||||
<orderedlist>
|
||||
<listitem><para>echo -1 > /sys/module/debug_core/parameters/kgdbreboot</para>
|
||||
<para>Ignore the reboot notification entirely.</para>
|
||||
</listitem>
|
||||
<listitem><para>echo 0 > /sys/module/debug_core/parameters/kgdbreboot</para>
|
||||
<para>Send the detach message to any attached debugger client.</para>
|
||||
</listitem>
|
||||
<listitem><para>echo 1 > /sys/module/debug_core/parameters/kgdbreboot</para>
|
||||
<para>Enter the debugger on reboot notify.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter id="usingKDB">
|
||||
|
|
|
|||
|
|
@ -128,6 +128,26 @@ url="http://www.ijg.org">http://www.ijg.org</ulink>)</corpauthor>
|
|||
<subtitle>Version 1.02</subtitle>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="itu-t81">
|
||||
<abbrev>ITU-T.81</abbrev>
|
||||
<authorgroup>
|
||||
<corpauthor>International Telecommunication Union
|
||||
(<ulink url="http://www.itu.int">http://www.itu.int</ulink>)</corpauthor>
|
||||
</authorgroup>
|
||||
<title>ITU-T Recommendation T.81
|
||||
"Information Technology — Digital Compression and Coding of Continous-Tone
|
||||
Still Images — Requirements and Guidelines"</title>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="w3c-jpeg-jfif">
|
||||
<abbrev>W3C JPEG JFIF</abbrev>
|
||||
<authorgroup>
|
||||
<corpauthor>The World Wide Web Consortium (<ulink
|
||||
url="http://www.w3.org/Graphics/JPEG">http://www.w3.org</ulink>)</corpauthor>
|
||||
</authorgroup>
|
||||
<title>JPEG JFIF</title>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="smpte12m">
|
||||
<abbrev>SMPTE 12M</abbrev>
|
||||
<authorgroup>
|
||||
|
|
|
|||
|
|
@ -2393,6 +2393,20 @@ details.</para>
|
|||
to the <link linkend="control">User controls class</link>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Added the device_caps field to struct v4l2_capabilities and added the new
|
||||
V4L2_CAP_DEVICE_CAPS capability.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.4</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Added <link linkend="jpeg-controls">JPEG compression control
|
||||
class</link>.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
|
|
|
|||
|
|
@ -1284,6 +1284,49 @@ values are:</entry>
|
|||
capturing. This is not done by muting audio hardware, which can still
|
||||
produce a slight hiss, but in the encoder itself, guaranteeing a fixed
|
||||
and reproducible audio bitstream. 0 = unmuted, 1 = muted.</entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row id="v4l2-mpeg-audio-dec-playback">
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK</constant> </entry>
|
||||
<entry>enum v4l2_mpeg_audio_dec_playback</entry>
|
||||
</row><row><entry spanname="descr">Determines how monolingual audio should be played back.
|
||||
Possible values are:</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_AUTO</constant> </entry>
|
||||
<entry>Automatically determines the best playback mode.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_STEREO</constant> </entry>
|
||||
<entry>Stereo playback.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_LEFT</constant> </entry>
|
||||
<entry>Left channel playback.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_RIGHT</constant> </entry>
|
||||
<entry>Right channel playback.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_MONO</constant> </entry>
|
||||
<entry>Mono playback.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_SWAPPED_STEREO</constant> </entry>
|
||||
<entry>Stereo playback with swapped left and right channels.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row id="v4l2-mpeg-audio-dec-multilingual-playback">
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK</constant> </entry>
|
||||
<entry>enum v4l2_mpeg_audio_dec_playback</entry>
|
||||
</row><row><entry spanname="descr">Determines how multilingual audio should be played back.</entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row id="v4l2-mpeg-video-encoding">
|
||||
|
|
@ -1447,6 +1490,22 @@ of the video. The supplied 32-bit integer is interpreted as follows (bit
|
|||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row id="v4l2-mpeg-video-dec-pts">
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_DEC_PTS</constant> </entry>
|
||||
<entry>integer64</entry>
|
||||
</row><row><entry spanname="descr">This read-only control returns the
|
||||
33-bit video Presentation Time Stamp as defined in ITU T-REC-H.222.0 and ISO/IEC 13818-1 of
|
||||
the currently displayed frame. This is the same PTS as is used in &VIDIOC-DECODER-CMD;.</entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row id="v4l2-mpeg-video-dec-frame">
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_DEC_FRAME</constant> </entry>
|
||||
<entry>integer64</entry>
|
||||
</row><row><entry spanname="descr">This read-only control returns the
|
||||
frame counter of the frame that is currently displayed (decoded). This value is reset to 0 whenever
|
||||
the decoder is started.</entry>
|
||||
</row>
|
||||
|
||||
|
||||
<row><entry></entry></row>
|
||||
|
|
@ -3377,6 +3436,167 @@ interface and may change in the future.</para>
|
|||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</section>
|
||||
|
||||
<section id="jpeg-controls">
|
||||
<title>JPEG Control Reference</title>
|
||||
<para>The JPEG class includes controls for common features of JPEG
|
||||
encoders and decoders. Currently it includes features for codecs
|
||||
implementing progressive baseline DCT compression process with
|
||||
Huffman entrophy coding.</para>
|
||||
<table pgwide="1" frame="none" id="jpeg-control-id">
|
||||
<title>JPEG Control IDs</title>
|
||||
|
||||
<tgroup cols="4">
|
||||
<colspec colname="c1" colwidth="1*" />
|
||||
<colspec colname="c2" colwidth="6*" />
|
||||
<colspec colname="c3" colwidth="2*" />
|
||||
<colspec colname="c4" colwidth="6*" />
|
||||
<spanspec namest="c1" nameend="c2" spanname="id" />
|
||||
<spanspec namest="c2" nameend="c4" spanname="descr" />
|
||||
<thead>
|
||||
<row>
|
||||
<entry spanname="id" align="left">ID</entry>
|
||||
<entry align="left">Type</entry>
|
||||
</row><row rowsep="1"><entry spanname="descr" align="left">Description</entry>
|
||||
</row>
|
||||
</thead>
|
||||
<tbody valign="top">
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_JPEG_CLASS</constant> </entry>
|
||||
<entry>class</entry>
|
||||
</row><row><entry spanname="descr">The JPEG class descriptor. Calling
|
||||
&VIDIOC-QUERYCTRL; for this control will return a description of this
|
||||
control class.
|
||||
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_JPEG_CHROMA_SUBSAMPLING</constant></entry>
|
||||
<entry>menu</entry>
|
||||
</row>
|
||||
<row id="jpeg-chroma-subsampling-control">
|
||||
<entry spanname="descr">The chroma subsampling factors describe how
|
||||
each component of an input image is sampled, in respect to maximum
|
||||
sample rate in each spatial dimension. See <xref linkend="itu-t81"/>,
|
||||
clause A.1.1. for more details. The <constant>
|
||||
V4L2_CID_JPEG_CHROMA_SUBSAMPLING</constant> control determines how
|
||||
Cb and Cr components are downsampled after coverting an input image
|
||||
from RGB to Y'CbCr color space.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_JPEG_CHROMA_SUBSAMPLING_444</constant>
|
||||
</entry><entry>No chroma subsampling, each pixel has
|
||||
Y, Cr and Cb values.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_JPEG_CHROMA_SUBSAMPLING_422</constant>
|
||||
</entry><entry>Horizontally subsample Cr, Cb components
|
||||
by a factor of 2.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_JPEG_CHROMA_SUBSAMPLING_420</constant>
|
||||
</entry><entry>Subsample Cr, Cb components horizontally
|
||||
and vertically by 2.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_JPEG_CHROMA_SUBSAMPLING_411</constant>
|
||||
</entry><entry>Horizontally subsample Cr, Cb components
|
||||
by a factor of 4.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_JPEG_CHROMA_SUBSAMPLING_410</constant>
|
||||
</entry><entry>Subsample Cr, Cb components horizontally
|
||||
by 4 and vertically by 2.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY</constant>
|
||||
</entry><entry>Use only luminance component.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_JPEG_RESTART_INTERVAL</constant>
|
||||
</entry><entry>integer</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">
|
||||
The restart interval determines an interval of inserting RSTm
|
||||
markers (m = 0..7). The purpose of these markers is to additionally
|
||||
reinitialize the encoder process, in order to process blocks of
|
||||
an image independently.
|
||||
For the lossy compression processes the restart interval unit is
|
||||
MCU (Minimum Coded Unit) and its value is contained in DRI
|
||||
(Define Restart Interval) marker. If <constant>
|
||||
V4L2_CID_JPEG_RESTART_INTERVAL</constant> control is set to 0,
|
||||
DRI and RSTm markers will not be inserted.
|
||||
</entry>
|
||||
</row>
|
||||
<row id="jpeg-quality-control">
|
||||
<entry spanname="id"><constant>V4L2_CID_JPEG_COMPRESION_QUALITY</constant></entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">
|
||||
<constant>V4L2_CID_JPEG_COMPRESION_QUALITY</constant> control
|
||||
determines trade-off between image quality and size.
|
||||
It provides simpler method for applications to control image quality,
|
||||
without a need for direct reconfiguration of luminance and chrominance
|
||||
quantization tables.
|
||||
|
||||
In cases where a driver uses quantization tables configured directly
|
||||
by an application, using interfaces defined elsewhere, <constant>
|
||||
V4L2_CID_JPEG_COMPRESION_QUALITY</constant> control should be set
|
||||
by driver to 0.
|
||||
|
||||
<para>The value range of this control is driver-specific. Only
|
||||
positive, non-zero values are meaningful. The recommended range
|
||||
is 1 - 100, where larger values correspond to better image quality.
|
||||
</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row id="jpeg-active-marker-control">
|
||||
<entry spanname="id"><constant>V4L2_CID_JPEG_ACTIVE_MARKER</constant></entry>
|
||||
<entry>bitmask</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Specify which JPEG markers are included
|
||||
in compressed stream. This control is valid only for encoders.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_JPEG_ACTIVE_MARKER_APP0</constant></entry>
|
||||
<entry>Application data segment APP<subscript>0</subscript>.</entry>
|
||||
</row><row>
|
||||
<entry><constant>V4L2_JPEG_ACTIVE_MARKER_APP1</constant></entry>
|
||||
<entry>Application data segment APP<subscript>1</subscript>.</entry>
|
||||
</row><row>
|
||||
<entry><constant>V4L2_JPEG_ACTIVE_MARKER_COM</constant></entry>
|
||||
<entry>Comment segment.</entry>
|
||||
</row><row>
|
||||
<entry><constant>V4L2_JPEG_ACTIVE_MARKER_DQT</constant></entry>
|
||||
<entry>Quantization tables segment.</entry>
|
||||
</row><row>
|
||||
<entry><constant>V4L2_JPEG_ACTIVE_MARKER_DHT</constant></entry>
|
||||
<entry>Huffman tables segment.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
<para>For more details about JPEG specification, refer
|
||||
to <xref linkend="itu-t81"/>, <xref linkend="jfif"/>,
|
||||
<xref linkend="w3c-jpeg-jfif"/>.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -52,6 +52,10 @@ cropping and composing rectangles have the same size.</para>
|
|||
</textobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
|
||||
For complete list of the available selection targets see table <xref
|
||||
linkend="v4l2-sel-target"/>
|
||||
|
||||
</section>
|
||||
|
||||
<section>
|
||||
|
|
@ -186,7 +190,7 @@ V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target.</para>
|
|||
|
||||
<section>
|
||||
|
||||
<title>Scaling control.</title>
|
||||
<title>Scaling control</title>
|
||||
|
||||
<para>An application can detect if scaling is performed by comparing the width
|
||||
and the height of rectangles obtained using <constant> V4L2_SEL_TGT_CROP_ACTIVE
|
||||
|
|
@ -200,7 +204,7 @@ the scaling ratios using these values.</para>
|
|||
|
||||
<section>
|
||||
|
||||
<title>Comparison with old cropping API.</title>
|
||||
<title>Comparison with old cropping API</title>
|
||||
|
||||
<para>The selection API was introduced to cope with deficiencies of previous
|
||||
<link linkend="crop"> API </link>, that was designed to control simple capture
|
||||
|
|
|
|||
|
|
@ -127,6 +127,22 @@ structs, ioctls) must be noted in more detail in the history chapter
|
|||
(compat.xml), along with the possible impact on existing drivers and
|
||||
applications. -->
|
||||
|
||||
<revision>
|
||||
<revnumber>3.4</revnumber>
|
||||
<date>2012-01-25</date>
|
||||
<authorinitials>sn</authorinitials>
|
||||
<revremark>Added <link linkend="jpeg-controls">JPEG compression
|
||||
control class.</link>
|
||||
</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>3.3</revnumber>
|
||||
<date>2012-01-11</date>
|
||||
<authorinitials>hv</authorinitials>
|
||||
<revremark>Added device_caps field to struct v4l2_capabilities.</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>3.2</revnumber>
|
||||
<date>2011-08-26</date>
|
||||
|
|
@ -417,7 +433,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||
</partinfo>
|
||||
|
||||
<title>Video for Linux Two API Specification</title>
|
||||
<subtitle>Revision 3.2</subtitle>
|
||||
<subtitle>Revision 3.3</subtitle>
|
||||
|
||||
<chapter id="common">
|
||||
&sub-common;
|
||||
|
|
@ -473,6 +489,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||
&sub-cropcap;
|
||||
&sub-dbg-g-chip-ident;
|
||||
&sub-dbg-g-register;
|
||||
&sub-decoder-cmd;
|
||||
&sub-dqevent;
|
||||
&sub-encoder-cmd;
|
||||
&sub-enumaudio;
|
||||
|
|
|
|||
|
|
@ -0,0 +1,256 @@
|
|||
<refentry id="vidioc-decoder-cmd">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_DECODER_CMD</refname>
|
||||
<refname>VIDIOC_TRY_DECODER_CMD</refname>
|
||||
<refpurpose>Execute an decoder command</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>struct v4l2_decoder_cmd *<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>&fd;</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
|
||||
<para>This is an <link linkend="experimental">experimental</link>
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
<para>These ioctls control an audio/video (usually MPEG-) decoder.
|
||||
<constant>VIDIOC_DECODER_CMD</constant> sends a command to the
|
||||
decoder, <constant>VIDIOC_TRY_DECODER_CMD</constant> can be used to
|
||||
try a command without actually executing it. To send a command applications
|
||||
must initialize all fields of a &v4l2-decoder-cmd; and call
|
||||
<constant>VIDIOC_DECODER_CMD</constant> or <constant>VIDIOC_TRY_DECODER_CMD</constant>
|
||||
with a pointer to this structure.</para>
|
||||
|
||||
<para>The <structfield>cmd</structfield> field must contain the
|
||||
command code. Some commands use the <structfield>flags</structfield> field for
|
||||
additional information.
|
||||
</para>
|
||||
|
||||
<para>A <function>write</function>() or &VIDIOC-STREAMON; call sends an implicit
|
||||
START command to the decoder if it has not been started yet.
|
||||
</para>
|
||||
|
||||
<para>A <function>close</function>() or &VIDIOC-STREAMOFF; call of a streaming
|
||||
file descriptor sends an implicit immediate STOP command to the decoder, and all
|
||||
buffered data is discarded.</para>
|
||||
|
||||
<para>These ioctls are optional, not all drivers may support
|
||||
them. They were introduced in Linux 3.3.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-decoder-cmd">
|
||||
<title>struct <structname>v4l2_decoder_cmd</structname></title>
|
||||
<tgroup cols="5">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>cmd</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>The decoder command, see <xref linkend="decoder-cmds" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>flags</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>Flags to go with the command. If no flags are defined for
|
||||
this command, drivers and applications must set this field to zero.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>union</entry>
|
||||
<entry>(anonymous)</entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>struct</entry>
|
||||
<entry><structfield>start</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Structure containing additional data for the
|
||||
<constant>V4L2_DEC_CMD_START</constant> command.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__s32</entry>
|
||||
<entry><structfield>speed</structfield></entry>
|
||||
<entry>Playback speed and direction. The playback speed is defined as
|
||||
<structfield>speed</structfield>/1000 of the normal speed. So 1000 is normal playback.
|
||||
Negative numbers denote reverse playback, so -1000 does reverse playback at normal
|
||||
speed. Speeds -1, 0 and 1 have special meanings: speed 0 is shorthand for 1000
|
||||
(normal playback). A speed of 1 steps just one frame forward, a speed of -1 steps
|
||||
just one frame back.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>format</structfield></entry>
|
||||
<entry>Format restrictions. This field is set by the driver, not the
|
||||
application. Possible values are <constant>V4L2_DEC_START_FMT_NONE</constant> if
|
||||
there are no format restrictions or <constant>V4L2_DEC_START_FMT_GOP</constant>
|
||||
if the decoder operates on full GOPs (<wordasword>Group Of Pictures</wordasword>).
|
||||
This is usually the case for reverse playback: the decoder needs full GOPs, which
|
||||
it can then play in reverse order. So to implement reverse playback the application
|
||||
must feed the decoder the last GOP in the video file, then the GOP before that, etc. etc.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>struct</entry>
|
||||
<entry><structfield>stop</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Structure containing additional data for the
|
||||
<constant>V4L2_DEC_CMD_STOP</constant> command.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u64</entry>
|
||||
<entry><structfield>pts</structfield></entry>
|
||||
<entry>Stop playback at this <structfield>pts</structfield> or immediately
|
||||
if the playback is already past that timestamp. Leave to 0 if you want to stop after the
|
||||
last frame was decoded.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>struct</entry>
|
||||
<entry><structfield>raw</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>data</structfield>[16]</entry>
|
||||
<entry>Reserved for future extensions. Drivers and
|
||||
applications must set the array to zero.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table pgwide="1" frame="none" id="decoder-cmds">
|
||||
<title>Decoder Commands</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_DEC_CMD_START</constant></entry>
|
||||
<entry>0</entry>
|
||||
<entry>Start the decoder. When the decoder is already
|
||||
running or paused, this command will just change the playback speed.
|
||||
That means that calling <constant>V4L2_DEC_CMD_START</constant> when
|
||||
the decoder was paused will <emphasis>not</emphasis> resume the decoder.
|
||||
You have to explicitly call <constant>V4L2_DEC_CMD_RESUME</constant> for that.
|
||||
This command has one flag:
|
||||
<constant>V4L2_DEC_CMD_START_MUTE_AUDIO</constant>. If set, then audio will
|
||||
be muted when playing back at a non-standard speed.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_DEC_CMD_STOP</constant></entry>
|
||||
<entry>1</entry>
|
||||
<entry>Stop the decoder. When the decoder is already stopped,
|
||||
this command does nothing. This command has two flags:
|
||||
if <constant>V4L2_DEC_CMD_STOP_TO_BLACK</constant> is set, then the decoder will
|
||||
set the picture to black after it stopped decoding. Otherwise the last image will
|
||||
repeat. If <constant>V4L2_DEC_CMD_STOP_IMMEDIATELY</constant> is set, then the decoder
|
||||
stops immediately (ignoring the <structfield>pts</structfield> value), otherwise it
|
||||
will keep decoding until timestamp >= pts or until the last of the pending data from
|
||||
its internal buffers was decoded.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_DEC_CMD_PAUSE</constant></entry>
|
||||
<entry>2</entry>
|
||||
<entry>Pause the decoder. When the decoder has not been
|
||||
started yet, the driver will return an &EPERM;. When the decoder is
|
||||
already paused, this command does nothing. This command has one flag:
|
||||
if <constant>V4L2_DEC_CMD_PAUSE_TO_BLACK</constant> is set, then set the
|
||||
decoder output to black when paused.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_DEC_CMD_RESUME</constant></entry>
|
||||
<entry>3</entry>
|
||||
<entry>Resume decoding after a PAUSE command. When the
|
||||
decoder has not been started yet, the driver will return an &EPERM;.
|
||||
When the decoder is already running, this command does nothing. No
|
||||
flags are defined for this command.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The <structfield>cmd</structfield> field is invalid.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EPERM</errorcode></term>
|
||||
<listitem>
|
||||
<para>The application sent a PAUSE or RESUME command when
|
||||
the decoder was not running.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -74,15 +74,16 @@ only used by the STOP command and contains one bit: If the
|
|||
encoding will continue until the end of the current <wordasword>Group
|
||||
Of Pictures</wordasword>, otherwise it will stop immediately.</para>
|
||||
|
||||
<para>A <function>read</function>() call sends a START command to
|
||||
the encoder if it has not been started yet. After a STOP command,
|
||||
<para>A <function>read</function>() or &VIDIOC-STREAMON; call sends an implicit
|
||||
START command to the encoder if it has not been started yet. After a STOP command,
|
||||
<function>read</function>() calls will read the remaining data
|
||||
buffered by the driver. When the buffer is empty,
|
||||
<function>read</function>() will return zero and the next
|
||||
<function>read</function>() call will restart the encoder.</para>
|
||||
|
||||
<para>A <function>close</function>() call sends an immediate STOP
|
||||
to the encoder, and all buffered data is discarded.</para>
|
||||
<para>A <function>close</function>() or &VIDIOC-STREAMOFF; call of a streaming
|
||||
file descriptor sends an implicit immediate STOP to the encoder, and all buffered
|
||||
data is discarded.</para>
|
||||
|
||||
<para>These ioctls are optional, not all drivers may support
|
||||
them. They were introduced in Linux 2.6.21.</para>
|
||||
|
|
|
|||
|
|
@ -57,6 +57,11 @@
|
|||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>These ioctls are <emphasis role="bold">deprecated</emphasis>.
|
||||
New drivers and applications should use <link linkend="jpeg-controls">
|
||||
JPEG class controls</link> for image quality and JPEG markers control.
|
||||
</para>
|
||||
|
||||
<para>[to do]</para>
|
||||
|
||||
<para>Ronald Bultje elaborates:</para>
|
||||
|
|
@ -86,7 +91,10 @@ to add them.</para>
|
|||
<row>
|
||||
<entry>int</entry>
|
||||
<entry><structfield>quality</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Deprecated. If <link linkend="jpeg-quality-control"><constant>
|
||||
V4L2_CID_JPEG_IMAGE_QUALITY</constant></link> control is exposed by
|
||||
a driver applications should use it instead and ignore this field.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>int</entry>
|
||||
|
|
@ -116,7 +124,11 @@ to add them.</para>
|
|||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>jpeg_markers</structfield></entry>
|
||||
<entry>See <xref linkend="jpeg-markers" />.</entry>
|
||||
<entry>See <xref linkend="jpeg-markers"/>. Deprecated.
|
||||
If <link linkend="jpeg-active-marker-control"><constant>
|
||||
V4L2_CID_JPEG_ACTIVE_MARKER</constant></link> control
|
||||
is exposed by a driver applications should use it instead
|
||||
and ignore this field.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
|
|||
|
|
@ -58,43 +58,43 @@
|
|||
|
||||
<para>The ioctls are used to query and configure selection rectangles.</para>
|
||||
|
||||
<para> To query the cropping (composing) rectangle set <structfield>
|
||||
&v4l2-selection;::type </structfield> to the respective buffer type. Do not
|
||||
use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE
|
||||
<para> To query the cropping (composing) rectangle set &v4l2-selection;
|
||||
<structfield> type </structfield> field to the respective buffer type.
|
||||
Do not use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE
|
||||
</constant> instead of <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
|
||||
</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of
|
||||
<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is
|
||||
setting <structfield> &v4l2-selection;::target </structfield> to value
|
||||
<constant> V4L2_SEL_TGT_CROP_ACTIVE </constant> (<constant>
|
||||
setting the value of &v4l2-selection; <structfield>target</structfield> field
|
||||
to <constant> V4L2_SEL_TGT_CROP_ACTIVE </constant> (<constant>
|
||||
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant>). Please refer to table <xref
|
||||
linkend="v4l2-sel-target" /> or <xref linkend="selection-api" /> for additional
|
||||
targets. Fields <structfield> &v4l2-selection;::flags </structfield> and
|
||||
<structfield> &v4l2-selection;::reserved </structfield> are ignored and they
|
||||
must be filled with zeros. The driver fills the rest of the structure or
|
||||
targets. The <structfield>flags</structfield> and <structfield>reserved
|
||||
</structfield> fields of &v4l2-selection; are ignored and they must be filled
|
||||
with zeros. The driver fills the rest of the structure or
|
||||
returns &EINVAL; if incorrect buffer type or target was used. If cropping
|
||||
(composing) is not supported then the active rectangle is not mutable and it is
|
||||
always equal to the bounds rectangle. Finally, structure <structfield>
|
||||
&v4l2-selection;::r </structfield> is filled with the current cropping
|
||||
always equal to the bounds rectangle. Finally, the &v4l2-rect;
|
||||
<structfield>r</structfield> rectangle is filled with the current cropping
|
||||
(composing) coordinates. The coordinates are expressed in driver-dependent
|
||||
units. The only exception are rectangles for images in raw formats, whose
|
||||
coordinates are always expressed in pixels. </para>
|
||||
|
||||
<para> To change the cropping (composing) rectangle set <structfield>
|
||||
&v4l2-selection;::type </structfield> to the respective buffer type. Do not
|
||||
<para> To change the cropping (composing) rectangle set the &v4l2-selection;
|
||||
<structfield>type</structfield> field to the respective buffer type. Do not
|
||||
use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE
|
||||
</constant> instead of <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
|
||||
</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of
|
||||
<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is
|
||||
setting <structfield> &v4l2-selection;::target </structfield> to value
|
||||
<constant> V4L2_SEL_TGT_CROP_ACTIVE </constant> (<constant>
|
||||
setting the value of &v4l2-selection; <structfield>target</structfield> to
|
||||
<constant>V4L2_SEL_TGT_CROP_ACTIVE</constant> (<constant>
|
||||
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant>). Please refer to table <xref
|
||||
linkend="v4l2-sel-target" /> or <xref linkend="selection-api" /> for additional
|
||||
targets. Set desired active area into the field <structfield>
|
||||
&v4l2-selection;::r </structfield>. Field <structfield>
|
||||
&v4l2-selection;::reserved </structfield> is ignored and must be filled with
|
||||
zeros. The driver may adjust the rectangle coordinates. An application may
|
||||
introduce constraints to control rounding behaviour. Set the field
|
||||
<structfield> &v4l2-selection;::flags </structfield> to one of values:
|
||||
targets. The &v4l2-rect; <structfield>r</structfield> rectangle need to be
|
||||
set to the desired active area. Field &v4l2-selection; <structfield> reserved
|
||||
</structfield> is ignored and must be filled with zeros. The driver may adjust
|
||||
coordinates of the requested rectangle. An application may
|
||||
introduce constraints to control rounding behaviour. The &v4l2-selection;
|
||||
<structfield>flags</structfield> field must be set to one of the following:
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
|
|
@ -129,7 +129,7 @@ and vertical offset and sizes are chosen according to following priority:
|
|||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Satisfy constraints from <structfield>&v4l2-selection;::flags</structfield>.</para>
|
||||
<para>Satisfy constraints from &v4l2-selection; <structfield>flags</structfield>.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Adjust width, height, left, and top to hardware limits and alignments.</para>
|
||||
|
|
@ -145,7 +145,7 @@ and vertical offset and sizes are chosen according to following priority:
|
|||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
On success the field <structfield> &v4l2-selection;::r </structfield> contains
|
||||
On success the &v4l2-rect; <structfield>r</structfield> field contains
|
||||
the adjusted rectangle. When the parameters are unsuitable the application may
|
||||
modify the cropping (composing) or image parameters and repeat the cycle until
|
||||
satisfactory parameters have been negotiated. If constraints flags have to be
|
||||
|
|
@ -162,38 +162,38 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
|
|||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_TGT_CROP_ACTIVE</constant></entry>
|
||||
<entry>0</entry>
|
||||
<entry>area that is currently cropped by hardware</entry>
|
||||
<entry>0x0000</entry>
|
||||
<entry>The area that is currently cropped by hardware.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_TGT_CROP_DEFAULT</constant></entry>
|
||||
<entry>1</entry>
|
||||
<entry>suggested cropping rectangle that covers the "whole picture"</entry>
|
||||
<entry>0x0001</entry>
|
||||
<entry>Suggested cropping rectangle that covers the "whole picture".</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_TGT_CROP_BOUNDS</constant></entry>
|
||||
<entry>2</entry>
|
||||
<entry>limits for the cropping rectangle</entry>
|
||||
<entry>0x0002</entry>
|
||||
<entry>Limits for the cropping rectangle.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_TGT_COMPOSE_ACTIVE</constant></entry>
|
||||
<entry>256</entry>
|
||||
<entry>area to which data are composed by hardware</entry>
|
||||
<entry>0x0100</entry>
|
||||
<entry>The area to which data is composed by hardware.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_TGT_COMPOSE_DEFAULT</constant></entry>
|
||||
<entry>257</entry>
|
||||
<entry>suggested composing rectangle that covers the "whole picture"</entry>
|
||||
<entry>0x0101</entry>
|
||||
<entry>Suggested composing rectangle that covers the "whole picture".</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_TGT_COMPOSE_BOUNDS</constant></entry>
|
||||
<entry>258</entry>
|
||||
<entry>limits for the composing rectangle</entry>
|
||||
<entry>0x0102</entry>
|
||||
<entry>Limits for the composing rectangle.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_TGT_COMPOSE_PADDED</constant></entry>
|
||||
<entry>259</entry>
|
||||
<entry>the active area and all padding pixels that are inserted or modified by the hardware</entry>
|
||||
<entry>0x0103</entry>
|
||||
<entry>The active area and all padding pixels that are inserted or modified by hardware.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
@ -209,12 +209,14 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
|
|||
<row>
|
||||
<entry><constant>V4L2_SEL_FLAG_GE</constant></entry>
|
||||
<entry>0x00000001</entry>
|
||||
<entry>indicate that adjusted rectangle must contain a rectangle from <structfield>&v4l2-selection;::r</structfield></entry>
|
||||
<entry>Indicates that the adjusted rectangle must contain the original
|
||||
&v4l2-selection; <structfield>r</structfield> rectangle.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_FLAG_LE</constant></entry>
|
||||
<entry>0x00000002</entry>
|
||||
<entry>indicate that adjusted rectangle must be inside a rectangle from <structfield>&v4l2-selection;::r</structfield></entry>
|
||||
<entry>Indicates that the adjusted rectangle must be inside the original
|
||||
&v4l2-rect; <structfield>r</structfield> rectangle.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
@ -245,27 +247,29 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
|
|||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry>Type of the buffer (from &v4l2-buf-type;)</entry>
|
||||
<entry>Type of the buffer (from &v4l2-buf-type;).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>target</structfield></entry>
|
||||
<entry>used to select between <link linkend="v4l2-sel-target"> cropping and composing rectangles </link></entry>
|
||||
<entry>Used to select between <link linkend="v4l2-sel-target"> cropping
|
||||
and composing rectangles</link>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>flags</structfield></entry>
|
||||
<entry>control over coordinates adjustments, refer to <link linkend="v4l2-sel-flags">selection flags</link></entry>
|
||||
<entry>Flags controlling the selection rectangle adjustments, refer to
|
||||
<link linkend="v4l2-sel-flags">selection flags</link>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-rect;</entry>
|
||||
<entry><structfield>r</structfield></entry>
|
||||
<entry>selection rectangle</entry>
|
||||
<entry>The selection rectangle.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved[9]</structfield></entry>
|
||||
<entry>Reserved fields for future use</entry>
|
||||
<entry>Reserved fields for future use.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
@ -278,24 +282,24 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
|
|||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The buffer <structfield> &v4l2-selection;::type </structfield>
|
||||
or <structfield> &v4l2-selection;::target </structfield> is not supported, or
|
||||
the <structfield> &v4l2-selection;::flags </structfield> are invalid.</para>
|
||||
<para>Given buffer type <structfield>type</structfield> or
|
||||
the selection target <structfield>target</structfield> is not supported,
|
||||
or the <structfield>flags</structfield> argument is not valid.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ERANGE</errorcode></term>
|
||||
<listitem>
|
||||
<para>it is not possible to adjust a rectangle <structfield>
|
||||
&v4l2-selection;::r </structfield> that satisfies all contraints from
|
||||
<structfield> &v4l2-selection;::flags </structfield>.</para>
|
||||
<para>It is not possible to adjust &v4l2-rect; <structfield>
|
||||
r</structfield> rectangle to satisfy all contraints given in the
|
||||
<structfield>flags</structfield> argument.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EBUSY</errorcode></term>
|
||||
<listitem>
|
||||
<para>it is not possible to apply change of selection rectangle at the moment.
|
||||
Usually because streaming is in progress.</para>
|
||||
<para>It is not possible to apply change of the selection rectangle
|
||||
at the moment. Usually because streaming is in progress.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
|
|
|||
|
|
@ -124,12 +124,35 @@ printf ("Version: %u.%u.%u\n",
|
|||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>capabilities</structfield></entry>
|
||||
<entry>Device capabilities, see <xref
|
||||
linkend="device-capabilities" />.</entry>
|
||||
<entry>Available capabilities of the physical device as a whole, see <xref
|
||||
linkend="device-capabilities" />. The same physical device can export
|
||||
multiple devices in /dev (e.g. /dev/videoX, /dev/vbiY and /dev/radioZ).
|
||||
The <structfield>capabilities</structfield> field should contain a union
|
||||
of all capabilities available around the several V4L2 devices exported
|
||||
to userspace.
|
||||
For all those devices the <structfield>capabilities</structfield> field
|
||||
returns the same set of capabilities. This allows applications to open
|
||||
just one of the devices (typically the video device) and discover whether
|
||||
video, vbi and/or radio are also supported.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[4]</entry>
|
||||
<entry><structfield>device_caps</structfield></entry>
|
||||
<entry>Device capabilities of the opened device, see <xref
|
||||
linkend="device-capabilities" />. Should contain the available capabilities
|
||||
of that specific device node. So, for example, <structfield>device_caps</structfield>
|
||||
of a radio device will only contain radio related capabilities and
|
||||
no video or vbi capabilities. This field is only set if the <structfield>capabilities</structfield>
|
||||
field contains the <constant>V4L2_CAP_DEVICE_CAPS</constant> capability.
|
||||
Only the <structfield>capabilities</structfield> field can have the
|
||||
<constant>V4L2_CAP_DEVICE_CAPS</constant> capability, <structfield>device_caps</structfield>
|
||||
will never set <constant>V4L2_CAP_DEVICE_CAPS</constant>.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[3]</entry>
|
||||
<entry>Reserved for future extensions. Drivers must set
|
||||
this array to zero.</entry>
|
||||
</row>
|
||||
|
|
@ -276,6 +299,13 @@ linkend="async">asynchronous</link> I/O methods.</entry>
|
|||
<entry>The device supports the <link
|
||||
linkend="mmap">streaming</link> I/O method.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CAP_DEVICE_CAPS</constant></entry>
|
||||
<entry>0x80000000</entry>
|
||||
<entry>The driver fills the <structfield>device_caps</structfield>
|
||||
field. This capability can only appear in the <structfield>capabilities</structfield>
|
||||
field and never in the <structfield>device_caps</structfield> field.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -96,8 +96,8 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
|
|||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[7]</entry>
|
||||
<entry>Reserved for future extensions. Drivers and
|
||||
applications must set the array to zero.</entry>
|
||||
<entry>Reserved for future extensions. Applications
|
||||
must set the array to zero.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
@ -112,7 +112,7 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
|
|||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The <structfield>tuner</structfield> index is out of
|
||||
bounds or the value in the <structfield>type</structfield> field is
|
||||
bounds, the wrap_around value is not supported or the value in the <structfield>type</structfield> field is
|
||||
wrong.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,44 @@
|
|||
/*
|
||||
1024x768.S: EDID data set for standard 1024x768 60 Hz monitor
|
||||
|
||||
Copyright (C) 2011 Carsten Emde <C.Emde@osadl.org>
|
||||
|
||||
This program is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU General Public License
|
||||
as published by the Free Software Foundation; either version 2
|
||||
of the License, or (at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
*/
|
||||
|
||||
/* EDID */
|
||||
#define VERSION 1
|
||||
#define REVISION 3
|
||||
|
||||
/* Display */
|
||||
#define CLOCK 65000 /* kHz */
|
||||
#define XPIX 1024
|
||||
#define YPIX 768
|
||||
#define XY_RATIO XY_RATIO_4_3
|
||||
#define XBLANK 320
|
||||
#define YBLANK 38
|
||||
#define XOFFSET 8
|
||||
#define XPULSE 144
|
||||
#define YOFFSET (63+3)
|
||||
#define YPULSE (63+6)
|
||||
#define DPI 72
|
||||
#define VFREQ 60 /* Hz */
|
||||
#define TIMING_NAME "Linux XGA"
|
||||
#define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
|
||||
#define HSYNC_POL 0
|
||||
#define VSYNC_POL 0
|
||||
#define CRC 0x55
|
||||
|
||||
#include "edid.S"
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
/*
|
||||
1280x1024.S: EDID data set for standard 1280x1024 60 Hz monitor
|
||||
|
||||
Copyright (C) 2011 Carsten Emde <C.Emde@osadl.org>
|
||||
|
||||
This program is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU General Public License
|
||||
as published by the Free Software Foundation; either version 2
|
||||
of the License, or (at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
*/
|
||||
|
||||
/* EDID */
|
||||
#define VERSION 1
|
||||
#define REVISION 3
|
||||
|
||||
/* Display */
|
||||
#define CLOCK 108000 /* kHz */
|
||||
#define XPIX 1280
|
||||
#define YPIX 1024
|
||||
#define XY_RATIO XY_RATIO_5_4
|
||||
#define XBLANK 408
|
||||
#define YBLANK 42
|
||||
#define XOFFSET 48
|
||||
#define XPULSE 112
|
||||
#define YOFFSET (63+1)
|
||||
#define YPULSE (63+3)
|
||||
#define DPI 72
|
||||
#define VFREQ 60 /* Hz */
|
||||
#define TIMING_NAME "Linux SXGA"
|
||||
#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
|
||||
#define HSYNC_POL 1
|
||||
#define VSYNC_POL 1
|
||||
#define CRC 0xa0
|
||||
|
||||
#include "edid.S"
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
/*
|
||||
1680x1050.S: EDID data set for standard 1680x1050 60 Hz monitor
|
||||
|
||||
Copyright (C) 2012 Carsten Emde <C.Emde@osadl.org>
|
||||
|
||||
This program is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU General Public License
|
||||
as published by the Free Software Foundation; either version 2
|
||||
of the License, or (at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
*/
|
||||
|
||||
/* EDID */
|
||||
#define VERSION 1
|
||||
#define REVISION 3
|
||||
|
||||
/* Display */
|
||||
#define CLOCK 146250 /* kHz */
|
||||
#define XPIX 1680
|
||||
#define YPIX 1050
|
||||
#define XY_RATIO XY_RATIO_16_10
|
||||
#define XBLANK 560
|
||||
#define YBLANK 39
|
||||
#define XOFFSET 104
|
||||
#define XPULSE 176
|
||||
#define YOFFSET (63+3)
|
||||
#define YPULSE (63+6)
|
||||
#define DPI 96
|
||||
#define VFREQ 60 /* Hz */
|
||||
#define TIMING_NAME "Linux WSXGA"
|
||||
#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
|
||||
#define HSYNC_POL 1
|
||||
#define VSYNC_POL 1
|
||||
#define CRC 0x26
|
||||
|
||||
#include "edid.S"
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
/*
|
||||
1920x1080.S: EDID data set for standard 1920x1080 60 Hz monitor
|
||||
|
||||
Copyright (C) 2012 Carsten Emde <C.Emde@osadl.org>
|
||||
|
||||
This program is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU General Public License
|
||||
as published by the Free Software Foundation; either version 2
|
||||
of the License, or (at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
*/
|
||||
|
||||
/* EDID */
|
||||
#define VERSION 1
|
||||
#define REVISION 3
|
||||
|
||||
/* Display */
|
||||
#define CLOCK 148500 /* kHz */
|
||||
#define XPIX 1920
|
||||
#define YPIX 1080
|
||||
#define XY_RATIO XY_RATIO_16_9
|
||||
#define XBLANK 280
|
||||
#define YBLANK 45
|
||||
#define XOFFSET 88
|
||||
#define XPULSE 44
|
||||
#define YOFFSET (63+4)
|
||||
#define YPULSE (63+5)
|
||||
#define DPI 96
|
||||
#define VFREQ 60 /* Hz */
|
||||
#define TIMING_NAME "Linux FHD"
|
||||
#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
|
||||
#define HSYNC_POL 1
|
||||
#define VSYNC_POL 1
|
||||
#define CRC 0x05
|
||||
|
||||
#include "edid.S"
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
In the good old days when graphics parameters were configured explicitly
|
||||
in a file called xorg.conf, even broken hardware could be managed.
|
||||
|
||||
Today, with the advent of Kernel Mode Setting, a graphics board is
|
||||
either correctly working because all components follow the standards -
|
||||
or the computer is unusable, because the screen remains dark after
|
||||
booting or it displays the wrong area. Cases when this happens are:
|
||||
- The graphics board does not recognize the monitor.
|
||||
- The graphics board is unable to detect any EDID data.
|
||||
- The graphics board incorrectly forwards EDID data to the driver.
|
||||
- The monitor sends no or bogus EDID data.
|
||||
- A KVM sends its own EDID data instead of querying the connected monitor.
|
||||
Adding the kernel parameter "nomodeset" helps in most cases, but causes
|
||||
restrictions later on.
|
||||
|
||||
As a remedy for such situations, the kernel configuration item
|
||||
CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to provide an
|
||||
individually prepared or corrected EDID data set in the /lib/firmware
|
||||
directory from where it is loaded via the firmware interface. The code
|
||||
(see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for
|
||||
commonly used screen resolutions (1024x768, 1280x1024, 1680x1050,
|
||||
1920x1080) as binary blobs, but the kernel source tree does not contain
|
||||
code to create these data. In order to elucidate the origin of the
|
||||
built-in binary EDID blobs and to facilitate the creation of individual
|
||||
data for a specific misbehaving monitor, commented sources and a
|
||||
Makefile environment are given here.
|
||||
|
||||
To create binary EDID and C source code files from the existing data
|
||||
material, simply type "make".
|
||||
|
||||
If you want to create your own EDID file, copy the file 1024x768.S and
|
||||
replace the settings with your own data. The CRC value in the last line
|
||||
#define CRC 0x55
|
||||
is a bit tricky. After a first version of the binary data set is
|
||||
created, it must be be checked with the "edid-decode" utility which will
|
||||
most probably complain about a wrong CRC. Fortunately, the utility also
|
||||
displays the correct CRC which must then be inserted into the source
|
||||
file. After the make procedure is repeated, the EDID data set is ready
|
||||
to be used.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
|
||||
SOURCES := $(wildcard [0-9]*x[0-9]*.S)
|
||||
|
||||
BIN := $(patsubst %.S, %.bin, $(SOURCES))
|
||||
|
||||
IHEX := $(patsubst %.S, %.bin.ihex, $(SOURCES))
|
||||
|
||||
CODE := $(patsubst %.S, %.c, $(SOURCES))
|
||||
|
||||
all: $(BIN) $(IHEX) $(CODE)
|
||||
|
||||
clean:
|
||||
@rm -f *.o *.bin.ihex *.bin *.c
|
||||
|
||||
%.o: %.S
|
||||
@cc -c $^
|
||||
|
||||
%.bin: %.o
|
||||
@objcopy -Obinary $^ $@
|
||||
|
||||
%.bin.ihex: %.o
|
||||
@objcopy -Oihex $^ $@
|
||||
@dos2unix $@ 2>/dev/null
|
||||
|
||||
%.c: %.bin
|
||||
@echo "{" >$@; hexdump -f hex $^ >>$@; echo "};" >>$@
|
||||
|
|
@ -0,0 +1,261 @@
|
|||
/*
|
||||
edid.S: EDID data template
|
||||
|
||||
Copyright (C) 2012 Carsten Emde <C.Emde@osadl.org>
|
||||
|
||||
This program is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU General Public License
|
||||
as published by the Free Software Foundation; either version 2
|
||||
of the License, or (at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
*/
|
||||
|
||||
|
||||
/* Manufacturer */
|
||||
#define MFG_LNX1 'L'
|
||||
#define MFG_LNX2 'N'
|
||||
#define MFG_LNX3 'X'
|
||||
#define SERIAL 0
|
||||
#define YEAR 2012
|
||||
#define WEEK 5
|
||||
|
||||
/* EDID 1.3 standard definitions */
|
||||
#define XY_RATIO_16_10 0b00
|
||||
#define XY_RATIO_4_3 0b01
|
||||
#define XY_RATIO_5_4 0b10
|
||||
#define XY_RATIO_16_9 0b11
|
||||
|
||||
#define mfgname2id(v1,v2,v3) \
|
||||
((((v1-'@')&0x1f)<<10)+(((v2-'@')&0x1f)<<5)+((v3-'@')&0x1f))
|
||||
#define swap16(v1) ((v1>>8)+((v1&0xff)<<8))
|
||||
#define msbs2(v1,v2) ((((v1>>8)&0x0f)<<4)+((v2>>8)&0x0f))
|
||||
#define msbs4(v1,v2,v3,v4) \
|
||||
(((v1&0x03)>>2)+((v2&0x03)>>4)+((v3&0x03)>>6)+((v4&0x03)>>8))
|
||||
#define pixdpi2mm(pix,dpi) ((pix*25)/dpi)
|
||||
#define xsize pixdpi2mm(XPIX,DPI)
|
||||
#define ysize pixdpi2mm(YPIX,DPI)
|
||||
|
||||
.data
|
||||
|
||||
/* Fixed header pattern */
|
||||
header: .byte 0x00,0xff,0xff,0xff,0xff,0xff,0xff,0x00
|
||||
|
||||
mfg_id: .word swap16(mfgname2id(MFG_LNX1, MFG_LNX2, MFG_LNX3))
|
||||
|
||||
prod_code: .word 0
|
||||
|
||||
/* Serial number. 32 bits, little endian. */
|
||||
serial_number: .long SERIAL
|
||||
|
||||
/* Week of manufacture */
|
||||
week: .byte WEEK
|
||||
|
||||
/* Year of manufacture, less 1990. (1990-2245)
|
||||
If week=255, it is the model year instead */
|
||||
year: .byte YEAR-1990
|
||||
|
||||
version: .byte VERSION /* EDID version, usually 1 (for 1.3) */
|
||||
revision: .byte REVISION /* EDID revision, usually 3 (for 1.3) */
|
||||
|
||||
/* If Bit 7=1 Digital input. If set, the following bit definitions apply:
|
||||
Bits 6-1 Reserved, must be 0
|
||||
Bit 0 Signal is compatible with VESA DFP 1.x TMDS CRGB,
|
||||
1 pixel per clock, up to 8 bits per color, MSB aligned,
|
||||
If Bit 7=0 Analog input. If clear, the following bit definitions apply:
|
||||
Bits 6-5 Video white and sync levels, relative to blank
|
||||
00=+0.7/-0.3 V; 01=+0.714/-0.286 V;
|
||||
10=+1.0/-0.4 V; 11=+0.7/0 V
|
||||
Bit 4 Blank-to-black setup (pedestal) expected
|
||||
Bit 3 Separate sync supported
|
||||
Bit 2 Composite sync (on HSync) supported
|
||||
Bit 1 Sync on green supported
|
||||
Bit 0 VSync pulse must be serrated when somposite or
|
||||
sync-on-green is used. */
|
||||
video_parms: .byte 0x6d
|
||||
|
||||
/* Maximum horizontal image size, in centimetres
|
||||
(max 292 cm/115 in at 16:9 aspect ratio) */
|
||||
max_hor_size: .byte xsize/10
|
||||
|
||||
/* Maximum vertical image size, in centimetres.
|
||||
If either byte is 0, undefined (e.g. projector) */
|
||||
max_vert_size: .byte ysize/10
|
||||
|
||||
/* Display gamma, minus 1, times 100 (range 1.00-3.5 */
|
||||
gamma: .byte 120
|
||||
|
||||
/* Bit 7 DPMS standby supported
|
||||
Bit 6 DPMS suspend supported
|
||||
Bit 5 DPMS active-off supported
|
||||
Bits 4-3 Display type: 00=monochrome; 01=RGB colour;
|
||||
10=non-RGB multicolour; 11=undefined
|
||||
Bit 2 Standard sRGB colour space. Bytes 25-34 must contain
|
||||
sRGB standard values.
|
||||
Bit 1 Preferred timing mode specified in descriptor block 1.
|
||||
Bit 0 GTF supported with default parameter values. */
|
||||
dsp_features: .byte 0xea
|
||||
|
||||
/* Chromaticity coordinates. */
|
||||
/* Red and green least-significant bits
|
||||
Bits 7-6 Red x value least-significant 2 bits
|
||||
Bits 5-4 Red y value least-significant 2 bits
|
||||
Bits 3-2 Green x value lst-significant 2 bits
|
||||
Bits 1-0 Green y value least-significant 2 bits */
|
||||
red_green_lsb: .byte 0x5e
|
||||
|
||||
/* Blue and white least-significant 2 bits */
|
||||
blue_white_lsb: .byte 0xc0
|
||||
|
||||
/* Red x value most significant 8 bits.
|
||||
0-255 encodes 0-0.996 (255/256); 0-0.999 (1023/1024) with lsbits */
|
||||
red_x_msb: .byte 0xa4
|
||||
|
||||
/* Red y value most significant 8 bits */
|
||||
red_y_msb: .byte 0x59
|
||||
|
||||
/* Green x and y value most significant 8 bits */
|
||||
green_x_y_msb: .byte 0x4a,0x98
|
||||
|
||||
/* Blue x and y value most significant 8 bits */
|
||||
blue_x_y_msb: .byte 0x25,0x20
|
||||
|
||||
/* Default white point x and y value most significant 8 bits */
|
||||
white_x_y_msb: .byte 0x50,0x54
|
||||
|
||||
/* Established timings */
|
||||
/* Bit 7 720x400 @ 70 Hz
|
||||
Bit 6 720x400 @ 88 Hz
|
||||
Bit 5 640x480 @ 60 Hz
|
||||
Bit 4 640x480 @ 67 Hz
|
||||
Bit 3 640x480 @ 72 Hz
|
||||
Bit 2 640x480 @ 75 Hz
|
||||
Bit 1 800x600 @ 56 Hz
|
||||
Bit 0 800x600 @ 60 Hz */
|
||||
estbl_timing1: .byte 0x00
|
||||
|
||||
/* Bit 7 800x600 @ 72 Hz
|
||||
Bit 6 800x600 @ 75 Hz
|
||||
Bit 5 832x624 @ 75 Hz
|
||||
Bit 4 1024x768 @ 87 Hz, interlaced (1024x768)
|
||||
Bit 3 1024x768 @ 60 Hz
|
||||
Bit 2 1024x768 @ 72 Hz
|
||||
Bit 1 1024x768 @ 75 Hz
|
||||
Bit 0 1280x1024 @ 75 Hz */
|
||||
estbl_timing2: .byte ESTABLISHED_TIMINGS_BITS
|
||||
|
||||
/* Bit 7 1152x870 @ 75 Hz (Apple Macintosh II)
|
||||
Bits 6-0 Other manufacturer-specific display mod */
|
||||
estbl_timing3: .byte 0x00
|
||||
|
||||
/* Standard timing */
|
||||
/* X resolution, less 31, divided by 8 (256-2288 pixels) */
|
||||
std_xres: .byte (XPIX/8)-31
|
||||
/* Y resolution, X:Y pixel ratio
|
||||
Bits 7-6 X:Y pixel ratio: 00=16:10; 01=4:3; 10=5:4; 11=16:9.
|
||||
Bits 5-0 Vertical frequency, less 60 (60-123 Hz) */
|
||||
std_vres: .byte (XY_RATIO<<6)+VFREQ-60
|
||||
.fill 7,2,0x0101 /* Unused */
|
||||
|
||||
descriptor1:
|
||||
/* Pixel clock in 10 kHz units. (0.-655.35 MHz, little-endian) */
|
||||
clock: .word CLOCK/10
|
||||
|
||||
/* Horizontal active pixels 8 lsbits (0-4095) */
|
||||
x_act_lsb: .byte XPIX&0xff
|
||||
/* Horizontal blanking pixels 8 lsbits (0-4095)
|
||||
End of active to start of next active. */
|
||||
x_blk_lsb: .byte XBLANK&0xff
|
||||
/* Bits 7-4 Horizontal active pixels 4 msbits
|
||||
Bits 3-0 Horizontal blanking pixels 4 msbits */
|
||||
x_msbs: .byte msbs2(XPIX,XBLANK)
|
||||
|
||||
/* Vertical active lines 8 lsbits (0-4095) */
|
||||
y_act_lsb: .byte YPIX&0xff
|
||||
/* Vertical blanking lines 8 lsbits (0-4095) */
|
||||
y_blk_lsb: .byte YBLANK&0xff
|
||||
/* Bits 7-4 Vertical active lines 4 msbits
|
||||
Bits 3-0 Vertical blanking lines 4 msbits */
|
||||
y_msbs: .byte msbs2(YPIX,YBLANK)
|
||||
|
||||
/* Horizontal sync offset pixels 8 lsbits (0-1023) From blanking start */
|
||||
x_snc_off_lsb: .byte XOFFSET&0xff
|
||||
/* Horizontal sync pulse width pixels 8 lsbits (0-1023) */
|
||||
x_snc_pls_lsb: .byte XPULSE&0xff
|
||||
/* Bits 7-4 Vertical sync offset lines 4 lsbits -63)
|
||||
Bits 3-0 Vertical sync pulse width lines 4 lsbits -63) */
|
||||
y_snc_lsb: .byte ((YOFFSET-63)<<4)+(YPULSE-63)
|
||||
/* Bits 7-6 Horizontal sync offset pixels 2 msbits
|
||||
Bits 5-4 Horizontal sync pulse width pixels 2 msbits
|
||||
Bits 3-2 Vertical sync offset lines 2 msbits
|
||||
Bits 1-0 Vertical sync pulse width lines 2 msbits */
|
||||
xy_snc_msbs: .byte msbs4(XOFFSET,XPULSE,YOFFSET,YPULSE)
|
||||
|
||||
/* Horizontal display size, mm, 8 lsbits (0-4095 mm, 161 in) */
|
||||
x_dsp_size: .byte xsize&0xff
|
||||
|
||||
/* Vertical display size, mm, 8 lsbits (0-4095 mm, 161 in) */
|
||||
y_dsp_size: .byte ysize&0xff
|
||||
|
||||
/* Bits 7-4 Horizontal display size, mm, 4 msbits
|
||||
Bits 3-0 Vertical display size, mm, 4 msbits */
|
||||
dsp_size_mbsb: .byte msbs2(xsize,ysize)
|
||||
|
||||
/* Horizontal border pixels (each side; total is twice this) */
|
||||
x_border: .byte 0
|
||||
/* Vertical border lines (each side; total is twice this) */
|
||||
y_border: .byte 0
|
||||
|
||||
/* Bit 7 Interlaced
|
||||
Bits 6-5 Stereo mode: 00=No stereo; other values depend on bit 0:
|
||||
Bit 0=0: 01=Field sequential, sync=1 during right; 10=similar,
|
||||
sync=1 during left; 11=4-way interleaved stereo
|
||||
Bit 0=1 2-way interleaved stereo: 01=Right image on even lines;
|
||||
10=Left image on even lines; 11=side-by-side
|
||||
Bits 4-3 Sync type: 00=Analog composite; 01=Bipolar analog composite;
|
||||
10=Digital composite (on HSync); 11=Digital separate
|
||||
Bit 2 If digital separate: Vertical sync polarity (1=positive)
|
||||
Other types: VSync serrated (HSync during VSync)
|
||||
Bit 1 If analog sync: Sync on all 3 RGB lines (else green only)
|
||||
Digital: HSync polarity (1=positive)
|
||||
Bit 0 2-way line-interleaved stereo, if bits 4-3 are not 00. */
|
||||
features: .byte 0x18+(VSYNC_POL<<2)+(HSYNC_POL<<1)
|
||||
|
||||
descriptor2: .byte 0,0 /* Not a detailed timing descriptor */
|
||||
.byte 0 /* Must be zero */
|
||||
.byte 0xff /* Descriptor is monitor serial number (text) */
|
||||
.byte 0 /* Must be zero */
|
||||
start1: .ascii "Linux #0"
|
||||
end1: .byte 0x0a /* End marker */
|
||||
.fill 12-(end1-start1), 1, 0x20 /* Padded spaces */
|
||||
descriptor3: .byte 0,0 /* Not a detailed timing descriptor */
|
||||
.byte 0 /* Must be zero */
|
||||
.byte 0xfd /* Descriptor is monitor range limits */
|
||||
.byte 0 /* Must be zero */
|
||||
start2: .byte VFREQ-1 /* Minimum vertical field rate (1-255 Hz) */
|
||||
.byte VFREQ+1 /* Maximum vertical field rate (1-255 Hz) */
|
||||
.byte (CLOCK/(XPIX+XBLANK))-1 /* Minimum horizontal line rate
|
||||
(1-255 kHz) */
|
||||
.byte (CLOCK/(XPIX+XBLANK))+1 /* Maximum horizontal line rate
|
||||
(1-255 kHz) */
|
||||
.byte (CLOCK/10000)+1 /* Maximum pixel clock rate, rounded up
|
||||
to 10 MHz multiple (10-2550 MHz) */
|
||||
.byte 0 /* No extended timing information type */
|
||||
end2: .byte 0x0a /* End marker */
|
||||
.fill 12-(end2-start2), 1, 0x20 /* Padded spaces */
|
||||
descriptor4: .byte 0,0 /* Not a detailed timing descriptor */
|
||||
.byte 0 /* Must be zero */
|
||||
.byte 0xfc /* Descriptor is text */
|
||||
.byte 0 /* Must be zero */
|
||||
start3: .ascii TIMING_NAME
|
||||
end3: .byte 0x0a /* End marker */
|
||||
.fill 12-(end3-start3), 1, 0x20 /* Padded spaces */
|
||||
extensions: .byte 0 /* Number of extensions to follow */
|
||||
checksum: .byte CRC /* Sum of all bytes must be 0 */
|
||||
|
|
@ -0,0 +1 @@
|
|||
"\t" 8/1 "0x%02x, " "\n"
|
||||
|
|
@ -0,0 +1,117 @@
|
|||
irq_domain interrupt number mapping library
|
||||
|
||||
The current design of the Linux kernel uses a single large number
|
||||
space where each separate IRQ source is assigned a different number.
|
||||
This is simple when there is only one interrupt controller, but in
|
||||
systems with multiple interrupt controllers the kernel must ensure
|
||||
that each one gets assigned non-overlapping allocations of Linux
|
||||
IRQ numbers.
|
||||
|
||||
The irq_alloc_desc*() and irq_free_desc*() APIs provide allocation of
|
||||
irq numbers, but they don't provide any support for reverse mapping of
|
||||
the controller-local IRQ (hwirq) number into the Linux IRQ number
|
||||
space.
|
||||
|
||||
The irq_domain library adds mapping between hwirq and IRQ numbers on
|
||||
top of the irq_alloc_desc*() API. An irq_domain to manage mapping is
|
||||
preferred over interrupt controller drivers open coding their own
|
||||
reverse mapping scheme.
|
||||
|
||||
irq_domain also implements translation from Device Tree interrupt
|
||||
specifiers to hwirq numbers, and can be easily extended to support
|
||||
other IRQ topology data sources.
|
||||
|
||||
=== irq_domain usage ===
|
||||
An interrupt controller driver creates and registers an irq_domain by
|
||||
calling one of the irq_domain_add_*() functions (each mapping method
|
||||
has a different allocator function, more on that later). The function
|
||||
will return a pointer to the irq_domain on success. The caller must
|
||||
provide the allocator function with an irq_domain_ops structure with
|
||||
the .map callback populated as a minimum.
|
||||
|
||||
In most cases, the irq_domain will begin empty without any mappings
|
||||
between hwirq and IRQ numbers. Mappings are added to the irq_domain
|
||||
by calling irq_create_mapping() which accepts the irq_domain and a
|
||||
hwirq number as arguments. If a mapping for the hwirq doesn't already
|
||||
exist then it will allocate a new Linux irq_desc, associate it with
|
||||
the hwirq, and call the .map() callback so the driver can perform any
|
||||
required hardware setup.
|
||||
|
||||
When an interrupt is received, irq_find_mapping() function should
|
||||
be used to find the Linux IRQ number from the hwirq number.
|
||||
|
||||
If the driver has the Linux IRQ number or the irq_data pointer, and
|
||||
needs to know the associated hwirq number (such as in the irq_chip
|
||||
callbacks) then it can be directly obtained from irq_data->hwirq.
|
||||
|
||||
=== Types of irq_domain mappings ===
|
||||
There are several mechanisms available for reverse mapping from hwirq
|
||||
to Linux irq, and each mechanism uses a different allocation function.
|
||||
Which reverse map type should be used depends on the use case. Each
|
||||
of the reverse map types are described below:
|
||||
|
||||
==== Linear ====
|
||||
irq_domain_add_linear()
|
||||
|
||||
The linear reverse map maintains a fixed size table indexed by the
|
||||
hwirq number. When a hwirq is mapped, an irq_desc is allocated for
|
||||
the hwirq, and the IRQ number is stored in the table.
|
||||
|
||||
The Linear map is a good choice when the maximum number of hwirqs is
|
||||
fixed and a relatively small number (~ < 256). The advantages of this
|
||||
map are fixed time lookup for IRQ numbers, and irq_descs are only
|
||||
allocated for in-use IRQs. The disadvantage is that the table must be
|
||||
as large as the largest possible hwirq number.
|
||||
|
||||
The majority of drivers should use the linear map.
|
||||
|
||||
==== Tree ====
|
||||
irq_domain_add_tree()
|
||||
|
||||
The irq_domain maintains a radix tree map from hwirq numbers to Linux
|
||||
IRQs. When an hwirq is mapped, an irq_desc is allocated and the
|
||||
hwirq is used as the lookup key for the radix tree.
|
||||
|
||||
The tree map is a good choice if the hwirq number can be very large
|
||||
since it doesn't need to allocate a table as large as the largest
|
||||
hwirq number. The disadvantage is that hwirq to IRQ number lookup is
|
||||
dependent on how many entries are in the table.
|
||||
|
||||
Very few drivers should need this mapping. At the moment, powerpc
|
||||
iseries is the only user.
|
||||
|
||||
==== No Map ===-
|
||||
irq_domain_add_nomap()
|
||||
|
||||
The No Map mapping is to be used when the hwirq number is
|
||||
programmable in the hardware. In this case it is best to program the
|
||||
Linux IRQ number into the hardware itself so that no mapping is
|
||||
required. Calling irq_create_direct_mapping() will allocate a Linux
|
||||
IRQ number and call the .map() callback so that driver can program the
|
||||
Linux IRQ number into the hardware.
|
||||
|
||||
Most drivers cannot use this mapping.
|
||||
|
||||
==== Legacy ====
|
||||
irq_domain_add_legacy()
|
||||
irq_domain_add_legacy_isa()
|
||||
|
||||
The Legacy mapping is a special case for drivers that already have a
|
||||
range of irq_descs allocated for the hwirqs. It is used when the
|
||||
driver cannot be immediately converted to use the linear mapping. For
|
||||
example, many embedded system board support files use a set of #defines
|
||||
for IRQ numbers that are passed to struct device registrations. In that
|
||||
case the Linux IRQ numbers cannot be dynamically assigned and the legacy
|
||||
mapping should be used.
|
||||
|
||||
The legacy map assumes a contiguous range of IRQ numbers has already
|
||||
been allocated for the controller and that the IRQ number can be
|
||||
calculated by adding a fixed offset to the hwirq number, and
|
||||
visa-versa. The disadvantage is that it requires the interrupt
|
||||
controller to manage IRQ allocations and it requires an irq_desc to be
|
||||
allocated for every hwirq, even if it is unused.
|
||||
|
||||
The legacy map should only be used if fixed IRQ mappings must be
|
||||
supported. For example, ISA controllers would use the legacy map for
|
||||
mapping Linux IRQs 0-15 so that existing ISA drivers get the correct IRQ
|
||||
numbers.
|
||||
|
|
@ -1,3 +1,3 @@
|
|||
obj-m := DocBook/ accounting/ auxdisplay/ connector/ \
|
||||
filesystems/ filesystems/configfs/ ia64/ laptops/ networking/ \
|
||||
pcmcia/ spi/ timers/ vm/ watchdog/src/
|
||||
pcmcia/ spi/ timers/ watchdog/src/
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -180,6 +180,20 @@ over a rather long period of time, but improvements are always welcome!
|
|||
operations that would not normally be undertaken while a real-time
|
||||
workload is running.
|
||||
|
||||
In particular, if you find yourself invoking one of the expedited
|
||||
primitives repeatedly in a loop, please do everyone a favor:
|
||||
Restructure your code so that it batches the updates, allowing
|
||||
a single non-expedited primitive to cover the entire batch.
|
||||
This will very likely be faster than the loop containing the
|
||||
expedited primitive, and will be much much easier on the rest
|
||||
of the system, especially to real-time workloads running on
|
||||
the rest of the system.
|
||||
|
||||
In addition, it is illegal to call the expedited forms from
|
||||
a CPU-hotplug notifier, or while holding a lock that is acquired
|
||||
by a CPU-hotplug notifier. Failing to observe this restriction
|
||||
will result in deadlock.
|
||||
|
||||
7. If the updater uses call_rcu() or synchronize_rcu(), then the
|
||||
corresponding readers must use rcu_read_lock() and
|
||||
rcu_read_unlock(). If the updater uses call_rcu_bh() or
|
||||
|
|
|
|||
|
|
@ -12,14 +12,38 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
|
|||
This kernel configuration parameter defines the period of time
|
||||
that RCU will wait from the beginning of a grace period until it
|
||||
issues an RCU CPU stall warning. This time period is normally
|
||||
ten seconds.
|
||||
sixty seconds.
|
||||
|
||||
RCU_SECONDS_TILL_STALL_RECHECK
|
||||
This configuration parameter may be changed at runtime via the
|
||||
/sys/module/rcutree/parameters/rcu_cpu_stall_timeout, however
|
||||
this parameter is checked only at the beginning of a cycle.
|
||||
So if you are 30 seconds into a 70-second stall, setting this
|
||||
sysfs parameter to (say) five will shorten the timeout for the
|
||||
-next- stall, or the following warning for the current stall
|
||||
(assuming the stall lasts long enough). It will not affect the
|
||||
timing of the next warning for the current stall.
|
||||
|
||||
This macro defines the period of time that RCU will wait after
|
||||
issuing a stall warning until it issues another stall warning
|
||||
for the same stall. This time period is normally set to three
|
||||
times the check interval plus thirty seconds.
|
||||
Stall-warning messages may be enabled and disabled completely via
|
||||
/sys/module/rcutree/parameters/rcu_cpu_stall_suppress.
|
||||
|
||||
CONFIG_RCU_CPU_STALL_VERBOSE
|
||||
|
||||
This kernel configuration parameter causes the stall warning to
|
||||
also dump the stacks of any tasks that are blocking the current
|
||||
RCU-preempt grace period.
|
||||
|
||||
RCU_CPU_STALL_INFO
|
||||
|
||||
This kernel configuration parameter causes the stall warning to
|
||||
print out additional per-CPU diagnostic information, including
|
||||
information on scheduling-clock ticks and RCU's idle-CPU tracking.
|
||||
|
||||
RCU_STALL_DELAY_DELTA
|
||||
|
||||
Although the lockdep facility is extremely useful, it does add
|
||||
some overhead. Therefore, under CONFIG_PROVE_RCU, the
|
||||
RCU_STALL_DELAY_DELTA macro allows five extra seconds before
|
||||
giving an RCU CPU stall warning message.
|
||||
|
||||
RCU_STALL_RAT_DELAY
|
||||
|
||||
|
|
@ -64,6 +88,54 @@ INFO: rcu_bh_state detected stalls on CPUs/tasks: { } (detected by 4, 2502 jiffi
|
|||
|
||||
This is rare, but does happen from time to time in real life.
|
||||
|
||||
If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
|
||||
more information is printed with the stall-warning message, for example:
|
||||
|
||||
INFO: rcu_preempt detected stall on CPU
|
||||
0: (63959 ticks this GP) idle=241/3fffffffffffffff/0
|
||||
(t=65000 jiffies)
|
||||
|
||||
In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
|
||||
printed:
|
||||
|
||||
INFO: rcu_preempt detected stall on CPU
|
||||
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer=-1
|
||||
(t=65000 jiffies)
|
||||
|
||||
The "(64628 ticks this GP)" indicates that this CPU has taken more
|
||||
than 64,000 scheduling-clock interrupts during the current stalled
|
||||
grace period. If the CPU was not yet aware of the current grace
|
||||
period (for example, if it was offline), then this part of the message
|
||||
indicates how many grace periods behind the CPU is.
|
||||
|
||||
The "idle=" portion of the message prints the dyntick-idle state.
|
||||
The hex number before the first "/" is the low-order 12 bits of the
|
||||
dynticks counter, which will have an even-numbered value if the CPU is
|
||||
in dyntick-idle mode and an odd-numbered value otherwise. The hex
|
||||
number between the two "/"s is the value of the nesting, which will
|
||||
be a small positive number if in the idle loop and a very large positive
|
||||
number (as shown above) otherwise.
|
||||
|
||||
For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the
|
||||
CPU is not in the process of trying to force itself into dyntick-idle
|
||||
state, the "." indicates that the CPU has not given up forcing RCU
|
||||
into dyntick-idle mode (it would be "H" otherwise), and the "timer=-1"
|
||||
indicates that the CPU has not recented forced RCU into dyntick-idle
|
||||
mode (it would otherwise indicate the number of microseconds remaining
|
||||
in this forced state).
|
||||
|
||||
|
||||
Multiple Warnings From One Stall
|
||||
|
||||
If a stall lasts long enough, multiple stall-warning messages will be
|
||||
printed for it. The second and subsequent messages are printed at
|
||||
longer intervals, so that the time between (say) the first and second
|
||||
message will be about three times the interval between the beginning
|
||||
of the stall and the first message.
|
||||
|
||||
|
||||
What Causes RCU CPU Stall Warnings?
|
||||
|
||||
So your kernel printed an RCU CPU stall warning. The next question is
|
||||
"What caused it?" The following problems can result in RCU CPU stall
|
||||
warnings:
|
||||
|
|
@ -128,4 +200,5 @@ is occurring, which will usually be in the function nearest the top of
|
|||
that portion of the stack which remains the same from trace to trace.
|
||||
If you can reliably trigger the stall, ftrace can be quite helpful.
|
||||
|
||||
RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE.
|
||||
RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE
|
||||
and with RCU's event tracing.
|
||||
|
|
|
|||
|
|
@ -69,6 +69,13 @@ onoff_interval
|
|||
CPU-hotplug operations regardless of what value is
|
||||
specified for onoff_interval.
|
||||
|
||||
onoff_holdoff The number of seconds to wait until starting CPU-hotplug
|
||||
operations. This would normally only be used when
|
||||
rcutorture was built into the kernel and started
|
||||
automatically at boot time, in which case it is useful
|
||||
in order to avoid confusing boot-time code with CPUs
|
||||
coming and going.
|
||||
|
||||
shuffle_interval
|
||||
The number of seconds to keep the test threads affinitied
|
||||
to a particular subset of the CPUs, defaults to 3 seconds.
|
||||
|
|
@ -79,6 +86,24 @@ shutdown_secs The number of seconds to run the test before terminating
|
|||
zero, which disables test termination and system shutdown.
|
||||
This capability is useful for automated testing.
|
||||
|
||||
stall_cpu The number of seconds that a CPU should be stalled while
|
||||
within both an rcu_read_lock() and a preempt_disable().
|
||||
This stall happens only once per rcutorture run.
|
||||
If you need multiple stalls, use modprobe and rmmod to
|
||||
repeatedly run rcutorture. The default for stall_cpu
|
||||
is zero, which prevents rcutorture from stalling a CPU.
|
||||
|
||||
Note that attempts to rmmod rcutorture while the stall
|
||||
is ongoing will hang, so be careful what value you
|
||||
choose for this module parameter! In addition, too-large
|
||||
values for stall_cpu might well induce failures and
|
||||
warnings in other parts of the kernel. You have been
|
||||
warned!
|
||||
|
||||
stall_cpu_holdoff
|
||||
The number of seconds to wait after rcutorture starts
|
||||
before stalling a CPU. Defaults to 10 seconds.
|
||||
|
||||
stat_interval The number of seconds between output of torture
|
||||
statistics (via printk()). Regardless of the interval,
|
||||
statistics are printed when the module is unloaded.
|
||||
|
|
@ -271,11 +296,13 @@ The following script may be used to torture RCU:
|
|||
#!/bin/sh
|
||||
|
||||
modprobe rcutorture
|
||||
sleep 100
|
||||
sleep 3600
|
||||
rmmod rcutorture
|
||||
dmesg | grep torture:
|
||||
|
||||
The output can be manually inspected for the error flag of "!!!".
|
||||
One could of course create a more elaborate script that automatically
|
||||
checked for such errors. The "rmmod" command forces a "SUCCESS" or
|
||||
"FAILURE" indication to be printk()ed.
|
||||
checked for such errors. The "rmmod" command forces a "SUCCESS",
|
||||
"FAILURE", or "RCU_HOTPLUG" indication to be printk()ed. The first
|
||||
two are self-explanatory, while the last indicates that while there
|
||||
were no RCU failures, CPU-hotplug problems were detected.
|
||||
|
|
|
|||
|
|
@ -33,23 +33,23 @@ rcu/rcuboost:
|
|||
The output of "cat rcu/rcudata" looks as follows:
|
||||
|
||||
rcu_sched:
|
||||
0 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=545/1/0 df=50 of=0 ri=0 ql=163 qs=NRW. kt=0/W/0 ktl=ebc3 b=10 ci=153737 co=0 ca=0
|
||||
1 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=967/1/0 df=58 of=0 ri=0 ql=634 qs=NRW. kt=0/W/1 ktl=58c b=10 ci=191037 co=0 ca=0
|
||||
2 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1081/1/0 df=175 of=0 ri=0 ql=74 qs=N.W. kt=0/W/2 ktl=da94 b=10 ci=75991 co=0 ca=0
|
||||
3 c=20942 g=20943 pq=1 pgp=20942 qp=1 dt=1846/0/0 df=404 of=0 ri=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=72261 co=0 ca=0
|
||||
4 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=369/1/0 df=83 of=0 ri=0 ql=48 qs=N.W. kt=0/W/4 ktl=e0e7 b=10 ci=128365 co=0 ca=0
|
||||
5 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=381/1/0 df=64 of=0 ri=0 ql=169 qs=NRW. kt=0/W/5 ktl=fb2f b=10 ci=164360 co=0 ca=0
|
||||
6 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1037/1/0 df=183 of=0 ri=0 ql=62 qs=N.W. kt=0/W/6 ktl=d2ad b=10 ci=65663 co=0 ca=0
|
||||
7 c=20897 g=20897 pq=1 pgp=20896 qp=0 dt=1572/0/0 df=382 of=0 ri=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0
|
||||
0 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=545/1/0 df=50 of=0 ql=163 qs=NRW. kt=0/W/0 ktl=ebc3 b=10 ci=153737 co=0 ca=0
|
||||
1 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=967/1/0 df=58 of=0 ql=634 qs=NRW. kt=0/W/1 ktl=58c b=10 ci=191037 co=0 ca=0
|
||||
2 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1081/1/0 df=175 of=0 ql=74 qs=N.W. kt=0/W/2 ktl=da94 b=10 ci=75991 co=0 ca=0
|
||||
3 c=20942 g=20943 pq=1 pgp=20942 qp=1 dt=1846/0/0 df=404 of=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=72261 co=0 ca=0
|
||||
4 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=369/1/0 df=83 of=0 ql=48 qs=N.W. kt=0/W/4 ktl=e0e7 b=10 ci=128365 co=0 ca=0
|
||||
5 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=381/1/0 df=64 of=0 ql=169 qs=NRW. kt=0/W/5 ktl=fb2f b=10 ci=164360 co=0 ca=0
|
||||
6 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1037/1/0 df=183 of=0 ql=62 qs=N.W. kt=0/W/6 ktl=d2ad b=10 ci=65663 co=0 ca=0
|
||||
7 c=20897 g=20897 pq=1 pgp=20896 qp=0 dt=1572/0/0 df=382 of=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0
|
||||
rcu_bh:
|
||||
0 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=545/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0
|
||||
1 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=967/1/0 df=3 of=0 ri=1 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0
|
||||
2 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1081/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0
|
||||
3 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1846/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0
|
||||
4 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=369/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0
|
||||
5 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=381/1/0 df=4 of=0 ri=1 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0
|
||||
6 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1037/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0
|
||||
7 c=1474 g=1474 pq=1 pgp=1473 qp=0 dt=1572/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0
|
||||
0 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=545/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0
|
||||
1 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=967/1/0 df=3 of=0 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0
|
||||
2 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1081/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0
|
||||
3 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1846/0/0 df=8 of=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0
|
||||
4 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=369/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0
|
||||
5 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=381/1/0 df=4 of=0 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0
|
||||
6 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1037/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0
|
||||
7 c=1474 g=1474 pq=1 pgp=1473 qp=0 dt=1572/0/0 df=8 of=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0
|
||||
|
||||
The first section lists the rcu_data structures for rcu_sched, the second
|
||||
for rcu_bh. Note that CONFIG_TREE_PREEMPT_RCU kernels will have an
|
||||
|
|
@ -119,10 +119,6 @@ o "of" is the number of times that some other CPU has forced a
|
|||
CPU is offline when it is really alive and kicking) is a fatal
|
||||
error, so it makes sense to err conservatively.
|
||||
|
||||
o "ri" is the number of times that RCU has seen fit to send a
|
||||
reschedule IPI to this CPU in order to get it to report a
|
||||
quiescent state.
|
||||
|
||||
o "ql" is the number of RCU callbacks currently residing on
|
||||
this CPU. This is the total number of callbacks, regardless
|
||||
of what state they are in (new, waiting for grace period to
|
||||
|
|
|
|||
|
|
@ -53,6 +53,14 @@ directory apei/einj. The following files are provided.
|
|||
This file is used to set the second error parameter value. Effect of
|
||||
parameter depends on error_type specified.
|
||||
|
||||
- notrigger
|
||||
The EINJ mechanism is a two step process. First inject the error, then
|
||||
perform some actions to trigger it. Setting "notrigger" to 1 skips the
|
||||
trigger phase, which *may* allow the user to cause the error in some other
|
||||
context by a simple access to the cpu, memory location, or device that is
|
||||
the target of the error injection. Whether this actually works depends
|
||||
on what operations the BIOS actually includes in the trigger phase.
|
||||
|
||||
BIOS versions based in the ACPI 4.0 specification have limited options
|
||||
to control where the errors are injected. Your BIOS may support an
|
||||
extension (enabled with the param_extension=1 module parameter, or
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ CREATING DEVICE NODES
|
|||
sh Documentation/aoe/mkshelf.sh /dev/etherd 0
|
||||
|
||||
There is also an autoload script that shows how to edit
|
||||
/etc/modprobe.conf to ensure that the aoe module is loaded when
|
||||
/etc/modprobe.d/aoe.conf to ensure that the aoe module is loaded when
|
||||
necessary.
|
||||
|
||||
USING DEVICE NODES
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
#!/bin/sh
|
||||
# set aoe to autoload by installing the
|
||||
# aliases in /etc/modprobe.conf
|
||||
# aliases in /etc/modprobe.d/
|
||||
|
||||
f=/etc/modprobe.conf
|
||||
f=/etc/modprobe.d/aoe.conf
|
||||
|
||||
if test ! -r $f || test ! -w $f; then
|
||||
echo "cannot configure $f for module autoloading" 1>&2
|
||||
|
|
|
|||
|
|
@ -0,0 +1,78 @@
|
|||
Kernel driver lp855x
|
||||
====================
|
||||
|
||||
Backlight driver for LP855x ICs
|
||||
|
||||
Supported chips:
|
||||
Texas Instruments LP8550, LP8551, LP8552, LP8553 and LP8556
|
||||
|
||||
Author: Milo(Woogyom) Kim <milo.kim@ti.com>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
* Brightness control
|
||||
|
||||
Brightness can be controlled by the pwm input or the i2c command.
|
||||
The lp855x driver supports both cases.
|
||||
|
||||
* Device attributes
|
||||
|
||||
1) bl_ctl_mode
|
||||
Backlight control mode.
|
||||
Value : pwm based or register based
|
||||
|
||||
2) chip_id
|
||||
The lp855x chip id.
|
||||
Value : lp8550/lp8551/lp8552/lp8553/lp8556
|
||||
|
||||
Platform data for lp855x
|
||||
------------------------
|
||||
|
||||
For supporting platform specific data, the lp855x platform data can be used.
|
||||
|
||||
* name : Backlight driver name. If it is not defined, default name is set.
|
||||
* mode : Brightness control mode. PWM or register based.
|
||||
* device_control : Value of DEVICE CONTROL register.
|
||||
* initial_brightness : Initial value of backlight brightness.
|
||||
* pwm_data : Platform specific pwm generation functions.
|
||||
Only valid when brightness is pwm input mode.
|
||||
Functions should be implemented by PWM driver.
|
||||
- pwm_set_intensity() : set duty of PWM
|
||||
- pwm_get_intensity() : get current duty of PWM
|
||||
* load_new_rom_data :
|
||||
0 : use default configuration data
|
||||
1 : update values of eeprom or eprom registers on loading driver
|
||||
* size_program : Total size of lp855x_rom_data.
|
||||
* rom_data : List of new eeprom/eprom registers.
|
||||
|
||||
example 1) lp8552 platform data : i2c register mode with new eeprom data
|
||||
|
||||
#define EEPROM_A5_ADDR 0xA5
|
||||
#define EEPROM_A5_VAL 0x4f /* EN_VSYNC=0 */
|
||||
|
||||
static struct lp855x_rom_data lp8552_eeprom_arr[] = {
|
||||
{EEPROM_A5_ADDR, EEPROM_A5_VAL},
|
||||
};
|
||||
|
||||
static struct lp855x_platform_data lp8552_pdata = {
|
||||
.name = "lcd-bl",
|
||||
.mode = REGISTER_BASED,
|
||||
.device_control = I2C_CONFIG(LP8552),
|
||||
.initial_brightness = INITIAL_BRT,
|
||||
.load_new_rom_data = 1,
|
||||
.size_program = ARRAY_SIZE(lp8552_eeprom_arr),
|
||||
.rom_data = lp8552_eeprom_arr,
|
||||
};
|
||||
|
||||
example 2) lp8556 platform data : pwm input mode with default rom data
|
||||
|
||||
static struct lp855x_platform_data lp8556_pdata = {
|
||||
.mode = PWM_BASED,
|
||||
.device_control = PWM_CONFIG(LP8556),
|
||||
.initial_brightness = INITIAL_BRT,
|
||||
.pwm_data = {
|
||||
.pwm_set_intensity = platform_pwm_set_intensity,
|
||||
.pwm_get_intensity = platform_pwm_get_intensity,
|
||||
},
|
||||
};
|
||||
|
|
@ -49,7 +49,7 @@ you can put:
|
|||
|
||||
options floppy omnibook messages
|
||||
|
||||
in /etc/modprobe.conf.
|
||||
in a configuration file in /etc/modprobe.d/.
|
||||
|
||||
|
||||
The floppy driver related options are:
|
||||
|
|
|
|||
|
|
@ -558,8 +558,7 @@ Each subsystem may export the following methods. The only mandatory
|
|||
methods are create/destroy. Any others that are null are presumed to
|
||||
be successful no-ops.
|
||||
|
||||
struct cgroup_subsys_state *create(struct cgroup_subsys *ss,
|
||||
struct cgroup *cgrp)
|
||||
struct cgroup_subsys_state *create(struct cgroup *cgrp)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called to create a subsystem state object for a cgroup. The
|
||||
|
|
@ -574,7 +573,7 @@ identified by the passed cgroup object having a NULL parent (since
|
|||
it's the root of the hierarchy) and may be an appropriate place for
|
||||
initialization code.
|
||||
|
||||
void destroy(struct cgroup_subsys *ss, struct cgroup *cgrp)
|
||||
void destroy(struct cgroup *cgrp)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
The cgroup system is about to destroy the passed cgroup; the subsystem
|
||||
|
|
@ -585,7 +584,7 @@ cgroup->parent is still valid. (Note - can also be called for a
|
|||
newly-created cgroup if an error occurs after this subsystem's
|
||||
create() method has been called for the new cgroup).
|
||||
|
||||
int pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp);
|
||||
int pre_destroy(struct cgroup *cgrp);
|
||||
|
||||
Called before checking the reference count on each subsystem. This may
|
||||
be useful for subsystems which have some extra references even if
|
||||
|
|
@ -593,8 +592,7 @@ there are not tasks in the cgroup. If pre_destroy() returns error code,
|
|||
rmdir() will fail with it. From this behavior, pre_destroy() can be
|
||||
called multiple times against a cgroup.
|
||||
|
||||
int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
||||
struct cgroup_taskset *tset)
|
||||
int can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called prior to moving one or more tasks into a cgroup; if the
|
||||
|
|
@ -615,8 +613,7 @@ fork. If this method returns 0 (success) then this should remain valid
|
|||
while the caller holds cgroup_mutex and it is ensured that either
|
||||
attach() or cancel_attach() will be called in future.
|
||||
|
||||
void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
||||
struct cgroup_taskset *tset)
|
||||
void cancel_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called when a task attach operation has failed after can_attach() has succeeded.
|
||||
|
|
@ -625,23 +622,22 @@ function, so that the subsystem can implement a rollback. If not, not necessary.
|
|||
This will be called only about subsystems whose can_attach() operation have
|
||||
succeeded. The parameters are identical to can_attach().
|
||||
|
||||
void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
||||
struct cgroup_taskset *tset)
|
||||
void attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called after the task has been attached to the cgroup, to allow any
|
||||
post-attachment activity that requires memory allocations or blocking.
|
||||
The parameters are identical to can_attach().
|
||||
|
||||
void fork(struct cgroup_subsy *ss, struct task_struct *task)
|
||||
void fork(struct task_struct *task)
|
||||
|
||||
Called when a task is forked into a cgroup.
|
||||
|
||||
void exit(struct cgroup_subsys *ss, struct task_struct *task)
|
||||
void exit(struct task_struct *task)
|
||||
|
||||
Called during task exit.
|
||||
|
||||
int populate(struct cgroup_subsys *ss, struct cgroup *cgrp)
|
||||
int populate(struct cgroup *cgrp)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called after creation of a cgroup to allow a subsystem to populate
|
||||
|
|
@ -651,7 +647,7 @@ include/linux/cgroup.h for details). Note that although this
|
|||
method can return an error code, the error code is currently not
|
||||
always handled well.
|
||||
|
||||
void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp)
|
||||
void post_clone(struct cgroup *cgrp)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called during cgroup_create() to do any parameter
|
||||
|
|
@ -659,7 +655,7 @@ initialization which might be required before a task could attach. For
|
|||
example in cpusets, no task may attach before 'cpus' and 'mems' are set
|
||||
up.
|
||||
|
||||
void bind(struct cgroup_subsys *ss, struct cgroup *root)
|
||||
void bind(struct cgroup *root)
|
||||
(cgroup_mutex and ss->hierarchy_mutex held by caller)
|
||||
|
||||
Called when a cgroup subsystem is rebound to a different hierarchy
|
||||
|
|
|
|||
|
|
@ -217,7 +217,7 @@ and name space for cpusets, with a minimum of additional kernel code.
|
|||
|
||||
The cpus and mems files in the root (top_cpuset) cpuset are
|
||||
read-only. The cpus file automatically tracks the value of
|
||||
cpu_online_map using a CPU hotplug notifier, and the mems file
|
||||
cpu_online_mask using a CPU hotplug notifier, and the mems file
|
||||
automatically tracks the value of node_states[N_HIGH_MEMORY]--i.e.,
|
||||
nodes with memory--using the cpuset_track_online_nodes() hook.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,233 @@
|
|||
The Common Clk Framework
|
||||
Mike Turquette <mturquette@ti.com>
|
||||
|
||||
This document endeavours to explain the common clk framework details,
|
||||
and how to port a platform over to this framework. It is not yet a
|
||||
detailed explanation of the clock api in include/linux/clk.h, but
|
||||
perhaps someday it will include that information.
|
||||
|
||||
Part 1 - introduction and interface split
|
||||
|
||||
The common clk framework is an interface to control the clock nodes
|
||||
available on various devices today. This may come in the form of clock
|
||||
gating, rate adjustment, muxing or other operations. This framework is
|
||||
enabled with the CONFIG_COMMON_CLK option.
|
||||
|
||||
The interface itself is divided into two halves, each shielded from the
|
||||
details of its counterpart. First is the common definition of struct
|
||||
clk which unifies the framework-level accounting and infrastructure that
|
||||
has traditionally been duplicated across a variety of platforms. Second
|
||||
is a common implementation of the clk.h api, defined in
|
||||
drivers/clk/clk.c. Finally there is struct clk_ops, whose operations
|
||||
are invoked by the clk api implementation.
|
||||
|
||||
The second half of the interface is comprised of the hardware-specific
|
||||
callbacks registered with struct clk_ops and the corresponding
|
||||
hardware-specific structures needed to model a particular clock. For
|
||||
the remainder of this document any reference to a callback in struct
|
||||
clk_ops, such as .enable or .set_rate, implies the hardware-specific
|
||||
implementation of that code. Likewise, references to struct clk_foo
|
||||
serve as a convenient shorthand for the implementation of the
|
||||
hardware-specific bits for the hypothetical "foo" hardware.
|
||||
|
||||
Tying the two halves of this interface together is struct clk_hw, which
|
||||
is defined in struct clk_foo and pointed to within struct clk. This
|
||||
allows easy for navigation between the two discrete halves of the common
|
||||
clock interface.
|
||||
|
||||
Part 2 - common data structures and api
|
||||
|
||||
Below is the common struct clk definition from
|
||||
include/linux/clk-private.h, modified for brevity:
|
||||
|
||||
struct clk {
|
||||
const char *name;
|
||||
const struct clk_ops *ops;
|
||||
struct clk_hw *hw;
|
||||
char **parent_names;
|
||||
struct clk **parents;
|
||||
struct clk *parent;
|
||||
struct hlist_head children;
|
||||
struct hlist_node child_node;
|
||||
...
|
||||
};
|
||||
|
||||
The members above make up the core of the clk tree topology. The clk
|
||||
api itself defines several driver-facing functions which operate on
|
||||
struct clk. That api is documented in include/linux/clk.h.
|
||||
|
||||
Platforms and devices utilizing the common struct clk use the struct
|
||||
clk_ops pointer in struct clk to perform the hardware-specific parts of
|
||||
the operations defined in clk.h:
|
||||
|
||||
struct clk_ops {
|
||||
int (*prepare)(struct clk_hw *hw);
|
||||
void (*unprepare)(struct clk_hw *hw);
|
||||
int (*enable)(struct clk_hw *hw);
|
||||
void (*disable)(struct clk_hw *hw);
|
||||
int (*is_enabled)(struct clk_hw *hw);
|
||||
unsigned long (*recalc_rate)(struct clk_hw *hw,
|
||||
unsigned long parent_rate);
|
||||
long (*round_rate)(struct clk_hw *hw, unsigned long,
|
||||
unsigned long *);
|
||||
int (*set_parent)(struct clk_hw *hw, u8 index);
|
||||
u8 (*get_parent)(struct clk_hw *hw);
|
||||
int (*set_rate)(struct clk_hw *hw, unsigned long);
|
||||
void (*init)(struct clk_hw *hw);
|
||||
};
|
||||
|
||||
Part 3 - hardware clk implementations
|
||||
|
||||
The strength of the common struct clk comes from its .ops and .hw pointers
|
||||
which abstract the details of struct clk from the hardware-specific bits, and
|
||||
vice versa. To illustrate consider the simple gateable clk implementation in
|
||||
drivers/clk/clk-gate.c:
|
||||
|
||||
struct clk_gate {
|
||||
struct clk_hw hw;
|
||||
void __iomem *reg;
|
||||
u8 bit_idx;
|
||||
...
|
||||
};
|
||||
|
||||
struct clk_gate contains struct clk_hw hw as well as hardware-specific
|
||||
knowledge about which register and bit controls this clk's gating.
|
||||
Nothing about clock topology or accounting, such as enable_count or
|
||||
notifier_count, is needed here. That is all handled by the common
|
||||
framework code and struct clk.
|
||||
|
||||
Let's walk through enabling this clk from driver code:
|
||||
|
||||
struct clk *clk;
|
||||
clk = clk_get(NULL, "my_gateable_clk");
|
||||
|
||||
clk_prepare(clk);
|
||||
clk_enable(clk);
|
||||
|
||||
The call graph for clk_enable is very simple:
|
||||
|
||||
clk_enable(clk);
|
||||
clk->ops->enable(clk->hw);
|
||||
[resolves to...]
|
||||
clk_gate_enable(hw);
|
||||
[resolves struct clk gate with to_clk_gate(hw)]
|
||||
clk_gate_set_bit(gate);
|
||||
|
||||
And the definition of clk_gate_set_bit:
|
||||
|
||||
static void clk_gate_set_bit(struct clk_gate *gate)
|
||||
{
|
||||
u32 reg;
|
||||
|
||||
reg = __raw_readl(gate->reg);
|
||||
reg |= BIT(gate->bit_idx);
|
||||
writel(reg, gate->reg);
|
||||
}
|
||||
|
||||
Note that to_clk_gate is defined as:
|
||||
|
||||
#define to_clk_gate(_hw) container_of(_hw, struct clk_gate, clk)
|
||||
|
||||
This pattern of abstraction is used for every clock hardware
|
||||
representation.
|
||||
|
||||
Part 4 - supporting your own clk hardware
|
||||
|
||||
When implementing support for a new type of clock it only necessary to
|
||||
include the following header:
|
||||
|
||||
#include <linux/clk-provider.h>
|
||||
|
||||
include/linux/clk.h is included within that header and clk-private.h
|
||||
must never be included from the code which implements the operations for
|
||||
a clock. More on that below in Part 5.
|
||||
|
||||
To construct a clk hardware structure for your platform you must define
|
||||
the following:
|
||||
|
||||
struct clk_foo {
|
||||
struct clk_hw hw;
|
||||
... hardware specific data goes here ...
|
||||
};
|
||||
|
||||
To take advantage of your data you'll need to support valid operations
|
||||
for your clk:
|
||||
|
||||
struct clk_ops clk_foo_ops {
|
||||
.enable = &clk_foo_enable;
|
||||
.disable = &clk_foo_disable;
|
||||
};
|
||||
|
||||
Implement the above functions using container_of:
|
||||
|
||||
#define to_clk_foo(_hw) container_of(_hw, struct clk_foo, hw)
|
||||
|
||||
int clk_foo_enable(struct clk_hw *hw)
|
||||
{
|
||||
struct clk_foo *foo;
|
||||
|
||||
foo = to_clk_foo(hw);
|
||||
|
||||
... perform magic on foo ...
|
||||
|
||||
return 0;
|
||||
};
|
||||
|
||||
Below is a matrix detailing which clk_ops are mandatory based upon the
|
||||
hardware capbilities of that clock. A cell marked as "y" means
|
||||
mandatory, a cell marked as "n" implies that either including that
|
||||
callback is invalid or otherwise uneccesary. Empty cells are either
|
||||
optional or must be evaluated on a case-by-case basis.
|
||||
|
||||
clock hardware characteristics
|
||||
-----------------------------------------------------------
|
||||
| gate | change rate | single parent | multiplexer | root |
|
||||
|------|-------------|---------------|-------------|------|
|
||||
.prepare | | | | | |
|
||||
.unprepare | | | | | |
|
||||
| | | | | |
|
||||
.enable | y | | | | |
|
||||
.disable | y | | | | |
|
||||
.is_enabled | y | | | | |
|
||||
| | | | | |
|
||||
.recalc_rate | | y | | | |
|
||||
.round_rate | | y | | | |
|
||||
.set_rate | | y | | | |
|
||||
| | | | | |
|
||||
.set_parent | | | n | y | n |
|
||||
.get_parent | | | n | y | n |
|
||||
| | | | | |
|
||||
.init | | | | | |
|
||||
-----------------------------------------------------------
|
||||
|
||||
Finally, register your clock at run-time with a hardware-specific
|
||||
registration function. This function simply populates struct clk_foo's
|
||||
data and then passes the common struct clk parameters to the framework
|
||||
with a call to:
|
||||
|
||||
clk_register(...)
|
||||
|
||||
See the basic clock types in drivers/clk/clk-*.c for examples.
|
||||
|
||||
Part 5 - static initialization of clock data
|
||||
|
||||
For platforms with many clocks (often numbering into the hundreds) it
|
||||
may be desirable to statically initialize some clock data. This
|
||||
presents a problem since the definition of struct clk should be hidden
|
||||
from everyone except for the clock core in drivers/clk/clk.c.
|
||||
|
||||
To get around this problem struct clk's definition is exposed in
|
||||
include/linux/clk-private.h along with some macros for more easily
|
||||
initializing instances of the basic clock types. These clocks must
|
||||
still be initialized with the common clock framework via a call to
|
||||
__clk_init.
|
||||
|
||||
clk-private.h must NEVER be included by code which implements struct
|
||||
clk_ops callbacks, nor must it be included by any logic which pokes
|
||||
around inside of struct clk at run-time. To do so is a layering
|
||||
violation.
|
||||
|
||||
To better enforce this policy, always follow this simple rule: any
|
||||
statically initialized clock data MUST be defined in a separate file
|
||||
from the logic that implements its ops. Basically separate the logic
|
||||
from the data and all is well.
|
||||
|
|
@ -47,7 +47,7 @@ maxcpus=n Restrict boot time cpus to n. Say if you have 4 cpus, using
|
|||
other cpus later online, read FAQ's for more info.
|
||||
|
||||
additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets
|
||||
cpu_possible_map = cpu_present_map + additional_cpus
|
||||
cpu_possible_mask = cpu_present_mask + additional_cpus
|
||||
|
||||
cede_offline={"off","on"} Use this option to disable/enable putting offlined
|
||||
processors to an extended H_CEDE state on
|
||||
|
|
@ -64,11 +64,11 @@ should only rely on this to count the # of cpus, but *MUST* not rely
|
|||
on the apicid values in those tables for disabled apics. In the event
|
||||
BIOS doesn't mark such hot-pluggable cpus as disabled entries, one could
|
||||
use this parameter "additional_cpus=x" to represent those cpus in the
|
||||
cpu_possible_map.
|
||||
cpu_possible_mask.
|
||||
|
||||
possible_cpus=n [s390,x86_64] use this to set hotpluggable cpus.
|
||||
This option sets possible_cpus bits in
|
||||
cpu_possible_map. Thus keeping the numbers of bits set
|
||||
cpu_possible_mask. Thus keeping the numbers of bits set
|
||||
constant even if the machine gets rebooted.
|
||||
|
||||
CPU maps and such
|
||||
|
|
@ -76,7 +76,7 @@ CPU maps and such
|
|||
[More on cpumaps and primitive to manipulate, please check
|
||||
include/linux/cpumask.h that has more descriptive text.]
|
||||
|
||||
cpu_possible_map: Bitmap of possible CPUs that can ever be available in the
|
||||
cpu_possible_mask: Bitmap of possible CPUs that can ever be available in the
|
||||
system. This is used to allocate some boot time memory for per_cpu variables
|
||||
that aren't designed to grow/shrink as CPUs are made available or removed.
|
||||
Once set during boot time discovery phase, the map is static, i.e no bits
|
||||
|
|
@ -84,13 +84,13 @@ are added or removed anytime. Trimming it accurately for your system needs
|
|||
upfront can save some boot time memory. See below for how we use heuristics
|
||||
in x86_64 case to keep this under check.
|
||||
|
||||
cpu_online_map: Bitmap of all CPUs currently online. Its set in __cpu_up()
|
||||
cpu_online_mask: Bitmap of all CPUs currently online. Its set in __cpu_up()
|
||||
after a cpu is available for kernel scheduling and ready to receive
|
||||
interrupts from devices. Its cleared when a cpu is brought down using
|
||||
__cpu_disable(), before which all OS services including interrupts are
|
||||
migrated to another target CPU.
|
||||
|
||||
cpu_present_map: Bitmap of CPUs currently present in the system. Not all
|
||||
cpu_present_mask: Bitmap of CPUs currently present in the system. Not all
|
||||
of them may be online. When physical hotplug is processed by the relevant
|
||||
subsystem (e.g ACPI) can change and new bit either be added or removed
|
||||
from the map depending on the event is hot-add/hot-remove. There are currently
|
||||
|
|
@ -99,22 +99,22 @@ at which time hotplug is disabled.
|
|||
|
||||
You really dont need to manipulate any of the system cpu maps. They should
|
||||
be read-only for most use. When setting up per-cpu resources almost always use
|
||||
cpu_possible_map/for_each_possible_cpu() to iterate.
|
||||
cpu_possible_mask/for_each_possible_cpu() to iterate.
|
||||
|
||||
Never use anything other than cpumask_t to represent bitmap of CPUs.
|
||||
|
||||
#include <linux/cpumask.h>
|
||||
|
||||
for_each_possible_cpu - Iterate over cpu_possible_map
|
||||
for_each_online_cpu - Iterate over cpu_online_map
|
||||
for_each_present_cpu - Iterate over cpu_present_map
|
||||
for_each_possible_cpu - Iterate over cpu_possible_mask
|
||||
for_each_online_cpu - Iterate over cpu_online_mask
|
||||
for_each_present_cpu - Iterate over cpu_present_mask
|
||||
for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask.
|
||||
|
||||
#include <linux/cpu.h>
|
||||
get_online_cpus() and put_online_cpus():
|
||||
|
||||
The above calls are used to inhibit cpu hotplug operations. While the
|
||||
cpu_hotplug.refcount is non zero, the cpu_online_map will not change.
|
||||
cpu_hotplug.refcount is non zero, the cpu_online_mask will not change.
|
||||
If you merely need to avoid cpus going away, you could also use
|
||||
preempt_disable() and preempt_enable() for those sections.
|
||||
Just remember the critical section cannot call any
|
||||
|
|
|
|||
|
|
@ -36,6 +36,7 @@ drwxr-xr-x 2 root root 0 Feb 8 10:42 state3
|
|||
/sys/devices/system/cpu/cpu0/cpuidle/state0:
|
||||
total 0
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 desc
|
||||
-rw-r--r-- 1 root root 4096 Feb 8 10:42 disable
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 latency
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 power
|
||||
|
|
@ -45,6 +46,7 @@ total 0
|
|||
/sys/devices/system/cpu/cpu0/cpuidle/state1:
|
||||
total 0
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 desc
|
||||
-rw-r--r-- 1 root root 4096 Feb 8 10:42 disable
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 latency
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 power
|
||||
|
|
@ -54,6 +56,7 @@ total 0
|
|||
/sys/devices/system/cpu/cpu0/cpuidle/state2:
|
||||
total 0
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 desc
|
||||
-rw-r--r-- 1 root root 4096 Feb 8 10:42 disable
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 latency
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 power
|
||||
|
|
@ -63,6 +66,7 @@ total 0
|
|||
/sys/devices/system/cpu/cpu0/cpuidle/state3:
|
||||
total 0
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 desc
|
||||
-rw-r--r-- 1 root root 4096 Feb 8 10:42 disable
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 latency
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 power
|
||||
|
|
@ -72,6 +76,7 @@ total 0
|
|||
|
||||
|
||||
* desc : Small description about the idle state (string)
|
||||
* disable : Option to disable this idle state (bool)
|
||||
* latency : Latency to exit out of this idle state (in microseconds)
|
||||
* name : Name of the idle state (string)
|
||||
* power : Power consumed while in this idle state (in milliwatts)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,182 @@
|
|||
A brief CRC tutorial.
|
||||
|
||||
A CRC is a long-division remainder. You add the CRC to the message,
|
||||
and the whole thing (message+CRC) is a multiple of the given
|
||||
CRC polynomial. To check the CRC, you can either check that the
|
||||
CRC matches the recomputed value, *or* you can check that the
|
||||
remainder computed on the message+CRC is 0. This latter approach
|
||||
is used by a lot of hardware implementations, and is why so many
|
||||
protocols put the end-of-frame flag after the CRC.
|
||||
|
||||
It's actually the same long division you learned in school, except that
|
||||
- We're working in binary, so the digits are only 0 and 1, and
|
||||
- When dividing polynomials, there are no carries. Rather than add and
|
||||
subtract, we just xor. Thus, we tend to get a bit sloppy about
|
||||
the difference between adding and subtracting.
|
||||
|
||||
Like all division, the remainder is always smaller than the divisor.
|
||||
To produce a 32-bit CRC, the divisor is actually a 33-bit CRC polynomial.
|
||||
Since it's 33 bits long, bit 32 is always going to be set, so usually the
|
||||
CRC is written in hex with the most significant bit omitted. (If you're
|
||||
familiar with the IEEE 754 floating-point format, it's the same idea.)
|
||||
|
||||
Note that a CRC is computed over a string of *bits*, so you have
|
||||
to decide on the endianness of the bits within each byte. To get
|
||||
the best error-detecting properties, this should correspond to the
|
||||
order they're actually sent. For example, standard RS-232 serial is
|
||||
little-endian; the most significant bit (sometimes used for parity)
|
||||
is sent last. And when appending a CRC word to a message, you should
|
||||
do it in the right order, matching the endianness.
|
||||
|
||||
Just like with ordinary division, you proceed one digit (bit) at a time.
|
||||
Each step of the division you take one more digit (bit) of the dividend
|
||||
and append it to the current remainder. Then you figure out the
|
||||
appropriate multiple of the divisor to subtract to being the remainder
|
||||
back into range. In binary, this is easy - it has to be either 0 or 1,
|
||||
and to make the XOR cancel, it's just a copy of bit 32 of the remainder.
|
||||
|
||||
When computing a CRC, we don't care about the quotient, so we can
|
||||
throw the quotient bit away, but subtract the appropriate multiple of
|
||||
the polynomial from the remainder and we're back to where we started,
|
||||
ready to process the next bit.
|
||||
|
||||
A big-endian CRC written this way would be coded like:
|
||||
for (i = 0; i < input_bits; i++) {
|
||||
multiple = remainder & 0x80000000 ? CRCPOLY : 0;
|
||||
remainder = (remainder << 1 | next_input_bit()) ^ multiple;
|
||||
}
|
||||
|
||||
Notice how, to get at bit 32 of the shifted remainder, we look
|
||||
at bit 31 of the remainder *before* shifting it.
|
||||
|
||||
But also notice how the next_input_bit() bits we're shifting into
|
||||
the remainder don't actually affect any decision-making until
|
||||
32 bits later. Thus, the first 32 cycles of this are pretty boring.
|
||||
Also, to add the CRC to a message, we need a 32-bit-long hole for it at
|
||||
the end, so we have to add 32 extra cycles shifting in zeros at the
|
||||
end of every message,
|
||||
|
||||
These details lead to a standard trick: rearrange merging in the
|
||||
next_input_bit() until the moment it's needed. Then the first 32 cycles
|
||||
can be precomputed, and merging in the final 32 zero bits to make room
|
||||
for the CRC can be skipped entirely. This changes the code to:
|
||||
|
||||
for (i = 0; i < input_bits; i++) {
|
||||
remainder ^= next_input_bit() << 31;
|
||||
multiple = (remainder & 0x80000000) ? CRCPOLY : 0;
|
||||
remainder = (remainder << 1) ^ multiple;
|
||||
}
|
||||
|
||||
With this optimization, the little-endian code is particularly simple:
|
||||
for (i = 0; i < input_bits; i++) {
|
||||
remainder ^= next_input_bit();
|
||||
multiple = (remainder & 1) ? CRCPOLY : 0;
|
||||
remainder = (remainder >> 1) ^ multiple;
|
||||
}
|
||||
|
||||
The most significant coefficient of the remainder polynomial is stored
|
||||
in the least significant bit of the binary "remainder" variable.
|
||||
The other details of endianness have been hidden in CRCPOLY (which must
|
||||
be bit-reversed) and next_input_bit().
|
||||
|
||||
As long as next_input_bit is returning the bits in a sensible order, we don't
|
||||
*have* to wait until the last possible moment to merge in additional bits.
|
||||
We can do it 8 bits at a time rather than 1 bit at a time:
|
||||
for (i = 0; i < input_bytes; i++) {
|
||||
remainder ^= next_input_byte() << 24;
|
||||
for (j = 0; j < 8; j++) {
|
||||
multiple = (remainder & 0x80000000) ? CRCPOLY : 0;
|
||||
remainder = (remainder << 1) ^ multiple;
|
||||
}
|
||||
}
|
||||
|
||||
Or in little-endian:
|
||||
for (i = 0; i < input_bytes; i++) {
|
||||
remainder ^= next_input_byte();
|
||||
for (j = 0; j < 8; j++) {
|
||||
multiple = (remainder & 1) ? CRCPOLY : 0;
|
||||
remainder = (remainder >> 1) ^ multiple;
|
||||
}
|
||||
}
|
||||
|
||||
If the input is a multiple of 32 bits, you can even XOR in a 32-bit
|
||||
word at a time and increase the inner loop count to 32.
|
||||
|
||||
You can also mix and match the two loop styles, for example doing the
|
||||
bulk of a message byte-at-a-time and adding bit-at-a-time processing
|
||||
for any fractional bytes at the end.
|
||||
|
||||
To reduce the number of conditional branches, software commonly uses
|
||||
the byte-at-a-time table method, popularized by Dilip V. Sarwate,
|
||||
"Computation of Cyclic Redundancy Checks via Table Look-Up", Comm. ACM
|
||||
v.31 no.8 (August 1998) p. 1008-1013.
|
||||
|
||||
Here, rather than just shifting one bit of the remainder to decide
|
||||
in the correct multiple to subtract, we can shift a byte at a time.
|
||||
This produces a 40-bit (rather than a 33-bit) intermediate remainder,
|
||||
and the correct multiple of the polynomial to subtract is found using
|
||||
a 256-entry lookup table indexed by the high 8 bits.
|
||||
|
||||
(The table entries are simply the CRC-32 of the given one-byte messages.)
|
||||
|
||||
When space is more constrained, smaller tables can be used, e.g. two
|
||||
4-bit shifts followed by a lookup in a 16-entry table.
|
||||
|
||||
It is not practical to process much more than 8 bits at a time using this
|
||||
technique, because tables larger than 256 entries use too much memory and,
|
||||
more importantly, too much of the L1 cache.
|
||||
|
||||
To get higher software performance, a "slicing" technique can be used.
|
||||
See "High Octane CRC Generation with the Intel Slicing-by-8 Algorithm",
|
||||
ftp://download.intel.com/technology/comms/perfnet/download/slicing-by-8.pdf
|
||||
|
||||
This does not change the number of table lookups, but does increase
|
||||
the parallelism. With the classic Sarwate algorithm, each table lookup
|
||||
must be completed before the index of the next can be computed.
|
||||
|
||||
A "slicing by 2" technique would shift the remainder 16 bits at a time,
|
||||
producing a 48-bit intermediate remainder. Rather than doing a single
|
||||
lookup in a 65536-entry table, the two high bytes are looked up in
|
||||
two different 256-entry tables. Each contains the remainder required
|
||||
to cancel out the corresponding byte. The tables are different because the
|
||||
polynomials to cancel are different. One has non-zero coefficients from
|
||||
x^32 to x^39, while the other goes from x^40 to x^47.
|
||||
|
||||
Since modern processors can handle many parallel memory operations, this
|
||||
takes barely longer than a single table look-up and thus performs almost
|
||||
twice as fast as the basic Sarwate algorithm.
|
||||
|
||||
This can be extended to "slicing by 4" using 4 256-entry tables.
|
||||
Each step, 32 bits of data is fetched, XORed with the CRC, and the result
|
||||
broken into bytes and looked up in the tables. Because the 32-bit shift
|
||||
leaves the low-order bits of the intermediate remainder zero, the
|
||||
final CRC is simply the XOR of the 4 table look-ups.
|
||||
|
||||
But this still enforces sequential execution: a second group of table
|
||||
look-ups cannot begin until the previous groups 4 table look-ups have all
|
||||
been completed. Thus, the processor's load/store unit is sometimes idle.
|
||||
|
||||
To make maximum use of the processor, "slicing by 8" performs 8 look-ups
|
||||
in parallel. Each step, the 32-bit CRC is shifted 64 bits and XORed
|
||||
with 64 bits of input data. What is important to note is that 4 of
|
||||
those 8 bytes are simply copies of the input data; they do not depend
|
||||
on the previous CRC at all. Thus, those 4 table look-ups may commence
|
||||
immediately, without waiting for the previous loop iteration.
|
||||
|
||||
By always having 4 loads in flight, a modern superscalar processor can
|
||||
be kept busy and make full use of its L1 cache.
|
||||
|
||||
Two more details about CRC implementation in the real world:
|
||||
|
||||
Normally, appending zero bits to a message which is already a multiple
|
||||
of a polynomial produces a larger multiple of that polynomial. Thus,
|
||||
a basic CRC will not detect appended zero bits (or bytes). To enable
|
||||
a CRC to detect this condition, it's common to invert the CRC before
|
||||
appending it. This makes the remainder of the message+crc come out not
|
||||
as zero, but some fixed non-zero value. (The CRC of the inversion
|
||||
pattern, 0xffffffff.)
|
||||
|
||||
The same problem applies to zero bits prepended to the message, and a
|
||||
similar solution is used. Instead of starting the CRC computation with
|
||||
a remainder of 0, an initial remainder of all ones is used. As long as
|
||||
you start the same way on decoding, it doesn't make a difference.
|
||||
|
|
@ -75,10 +75,12 @@ less sharing than average you'll need a larger-than-average metadata device.
|
|||
|
||||
As a guide, we suggest you calculate the number of bytes to use in the
|
||||
metadata device as 48 * $data_dev_size / $data_block_size but round it up
|
||||
to 2MB if the answer is smaller. The largest size supported is 16GB.
|
||||
to 2MB if the answer is smaller. If you're creating large numbers of
|
||||
snapshots which are recording large amounts of change, you may find you
|
||||
need to increase this.
|
||||
|
||||
If you're creating large numbers of snapshots which are recording large
|
||||
amounts of change, you may need find you need to increase this.
|
||||
The largest size supported is 16GB: If the device is larger,
|
||||
a warning will be issued and the excess space will not be used.
|
||||
|
||||
Reloading a pool table
|
||||
----------------------
|
||||
|
|
@ -167,6 +169,38 @@ ii) Using an internal snapshot.
|
|||
|
||||
dmsetup create snap --table "0 2097152 thin /dev/mapper/pool 1"
|
||||
|
||||
External snapshots
|
||||
------------------
|
||||
|
||||
You can use an external _read only_ device as an origin for a
|
||||
thinly-provisioned volume. Any read to an unprovisioned area of the
|
||||
thin device will be passed through to the origin. Writes trigger
|
||||
the allocation of new blocks as usual.
|
||||
|
||||
One use case for this is VM hosts that want to run guests on
|
||||
thinly-provisioned volumes but have the base image on another device
|
||||
(possibly shared between many VMs).
|
||||
|
||||
You must not write to the origin device if you use this technique!
|
||||
Of course, you may write to the thin device and take internal snapshots
|
||||
of the thin volume.
|
||||
|
||||
i) Creating a snapshot of an external device
|
||||
|
||||
This is the same as creating a thin device.
|
||||
You don't mention the origin at this stage.
|
||||
|
||||
dmsetup message /dev/mapper/pool 0 "create_thin 0"
|
||||
|
||||
ii) Using a snapshot of an external device.
|
||||
|
||||
Append an extra parameter to the thin target specifying the origin:
|
||||
|
||||
dmsetup create snap --table "0 2097152 thin /dev/mapper/pool 0 /dev/image"
|
||||
|
||||
N.B. All descendants (internal snapshots) of this snapshot require the
|
||||
same extra origin parameter.
|
||||
|
||||
Deactivation
|
||||
------------
|
||||
|
||||
|
|
@ -189,7 +223,13 @@ i) Constructor
|
|||
<low water mark (blocks)> [<number of feature args> [<arg>]*]
|
||||
|
||||
Optional feature arguments:
|
||||
- 'skip_block_zeroing': skips the zeroing of newly-provisioned blocks.
|
||||
|
||||
skip_block_zeroing: Skip the zeroing of newly-provisioned blocks.
|
||||
|
||||
ignore_discard: Disable discard support.
|
||||
|
||||
no_discard_passdown: Don't pass discards down to the underlying
|
||||
data device, but just remove the mapping.
|
||||
|
||||
Data block size must be between 64KB (128 sectors) and 1GB
|
||||
(2097152 sectors) inclusive.
|
||||
|
|
@ -237,16 +277,6 @@ iii) Messages
|
|||
|
||||
Deletes a thin device. Irreversible.
|
||||
|
||||
trim <dev id> <new size in sectors>
|
||||
|
||||
Delete mappings from the end of a thin device. Irreversible.
|
||||
You might want to use this if you're reducing the size of
|
||||
your thinly-provisioned device. In many cases, due to the
|
||||
sharing of blocks between devices, it is not possible to
|
||||
determine in advance how much space 'trim' will release. (In
|
||||
future a userspace tool might be able to perform this
|
||||
calculation.)
|
||||
|
||||
set_transaction_id <current id> <new id>
|
||||
|
||||
Userland volume managers, such as LVM, need a way to
|
||||
|
|
@ -262,7 +292,7 @@ iii) Messages
|
|||
|
||||
i) Constructor
|
||||
|
||||
thin <pool dev> <dev id>
|
||||
thin <pool dev> <dev id> [<external origin dev>]
|
||||
|
||||
pool dev:
|
||||
the thin-pool device, e.g. /dev/mapper/my_pool or 253:0
|
||||
|
|
@ -271,6 +301,11 @@ i) Constructor
|
|||
the internal device identifier of the device to be
|
||||
activated.
|
||||
|
||||
external origin dev:
|
||||
an optional block device outside the pool to be treated as a
|
||||
read-only snapshot origin: reads to unprovisioned areas of the
|
||||
thin target will be mapped to this device.
|
||||
|
||||
The pool doesn't store any size against the thin devices. If you
|
||||
load a thin target that is smaller than you've been using previously,
|
||||
then you'll have no access to blocks mapped beyond the end. If you
|
||||
|
|
|
|||
|
|
@ -0,0 +1,194 @@
|
|||
dm-verity
|
||||
==========
|
||||
|
||||
Device-Mapper's "verity" target provides transparent integrity checking of
|
||||
block devices using a cryptographic digest provided by the kernel crypto API.
|
||||
This target is read-only.
|
||||
|
||||
Construction Parameters
|
||||
=======================
|
||||
<version> <dev> <hash_dev> <hash_start>
|
||||
<data_block_size> <hash_block_size>
|
||||
<num_data_blocks> <hash_start_block>
|
||||
<algorithm> <digest> <salt>
|
||||
|
||||
<version>
|
||||
This is the version number of the on-disk format.
|
||||
|
||||
0 is the original format used in the Chromium OS.
|
||||
The salt is appended when hashing, digests are stored continuously and
|
||||
the rest of the block is padded with zeros.
|
||||
|
||||
1 is the current format that should be used for new devices.
|
||||
The salt is prepended when hashing and each digest is
|
||||
padded with zeros to the power of two.
|
||||
|
||||
<dev>
|
||||
This is the device containing the data the integrity of which needs to be
|
||||
checked. It may be specified as a path, like /dev/sdaX, or a device number,
|
||||
<major>:<minor>.
|
||||
|
||||
<hash_dev>
|
||||
This is the device that that supplies the hash tree data. It may be
|
||||
specified similarly to the device path and may be the same device. If the
|
||||
same device is used, the hash_start should be outside of the dm-verity
|
||||
configured device size.
|
||||
|
||||
<data_block_size>
|
||||
The block size on a data device. Each block corresponds to one digest on
|
||||
the hash device.
|
||||
|
||||
<hash_block_size>
|
||||
The size of a hash block.
|
||||
|
||||
<num_data_blocks>
|
||||
The number of data blocks on the data device. Additional blocks are
|
||||
inaccessible. You can place hashes to the same partition as data, in this
|
||||
case hashes are placed after <num_data_blocks>.
|
||||
|
||||
<hash_start_block>
|
||||
This is the offset, in <hash_block_size>-blocks, from the start of hash_dev
|
||||
to the root block of the hash tree.
|
||||
|
||||
<algorithm>
|
||||
The cryptographic hash algorithm used for this device. This should
|
||||
be the name of the algorithm, like "sha1".
|
||||
|
||||
<digest>
|
||||
The hexadecimal encoding of the cryptographic hash of the root hash block
|
||||
and the salt. This hash should be trusted as there is no other authenticity
|
||||
beyond this point.
|
||||
|
||||
<salt>
|
||||
The hexadecimal encoding of the salt value.
|
||||
|
||||
Theory of operation
|
||||
===================
|
||||
|
||||
dm-verity is meant to be setup as part of a verified boot path. This
|
||||
may be anything ranging from a boot using tboot or trustedgrub to just
|
||||
booting from a known-good device (like a USB drive or CD).
|
||||
|
||||
When a dm-verity device is configured, it is expected that the caller
|
||||
has been authenticated in some way (cryptographic signatures, etc).
|
||||
After instantiation, all hashes will be verified on-demand during
|
||||
disk access. If they cannot be verified up to the root node of the
|
||||
tree, the root hash, then the I/O will fail. This should identify
|
||||
tampering with any data on the device and the hash data.
|
||||
|
||||
Cryptographic hashes are used to assert the integrity of the device on a
|
||||
per-block basis. This allows for a lightweight hash computation on first read
|
||||
into the page cache. Block hashes are stored linearly-aligned to the nearest
|
||||
block the size of a page.
|
||||
|
||||
Hash Tree
|
||||
---------
|
||||
|
||||
Each node in the tree is a cryptographic hash. If it is a leaf node, the hash
|
||||
is of some block data on disk. If it is an intermediary node, then the hash is
|
||||
of a number of child nodes.
|
||||
|
||||
Each entry in the tree is a collection of neighboring nodes that fit in one
|
||||
block. The number is determined based on block_size and the size of the
|
||||
selected cryptographic digest algorithm. The hashes are linearly-ordered in
|
||||
this entry and any unaligned trailing space is ignored but included when
|
||||
calculating the parent node.
|
||||
|
||||
The tree looks something like:
|
||||
|
||||
alg = sha256, num_blocks = 32768, block_size = 4096
|
||||
|
||||
[ root ]
|
||||
/ . . . \
|
||||
[entry_0] [entry_1]
|
||||
/ . . . \ . . . \
|
||||
[entry_0_0] . . . [entry_0_127] . . . . [entry_1_127]
|
||||
/ ... \ / . . . \ / \
|
||||
blk_0 ... blk_127 blk_16256 blk_16383 blk_32640 . . . blk_32767
|
||||
|
||||
|
||||
On-disk format
|
||||
==============
|
||||
|
||||
Below is the recommended on-disk format. The verity kernel code does not
|
||||
read the on-disk header. It only reads the hash blocks which directly
|
||||
follow the header. It is expected that a user-space tool will verify the
|
||||
integrity of the verity_header and then call dmsetup with the correct
|
||||
parameters. Alternatively, the header can be omitted and the dmsetup
|
||||
parameters can be passed via the kernel command-line in a rooted chain
|
||||
of trust where the command-line is verified.
|
||||
|
||||
The on-disk format is especially useful in cases where the hash blocks
|
||||
are on a separate partition. The magic number allows easy identification
|
||||
of the partition contents. Alternatively, the hash blocks can be stored
|
||||
in the same partition as the data to be verified. In such a configuration
|
||||
the filesystem on the partition would be sized a little smaller than
|
||||
the full-partition, leaving room for the hash blocks.
|
||||
|
||||
struct superblock {
|
||||
uint8_t signature[8]
|
||||
"verity\0\0";
|
||||
|
||||
uint8_t version;
|
||||
1 - current format
|
||||
|
||||
uint8_t data_block_bits;
|
||||
log2(data block size)
|
||||
|
||||
uint8_t hash_block_bits;
|
||||
log2(hash block size)
|
||||
|
||||
uint8_t pad1[1];
|
||||
zero padding
|
||||
|
||||
uint16_t salt_size;
|
||||
big-endian salt size
|
||||
|
||||
uint8_t pad2[2];
|
||||
zero padding
|
||||
|
||||
uint32_t data_blocks_hi;
|
||||
big-endian high 32 bits of the 64-bit number of data blocks
|
||||
|
||||
uint32_t data_blocks_lo;
|
||||
big-endian low 32 bits of the 64-bit number of data blocks
|
||||
|
||||
uint8_t algorithm[16];
|
||||
cryptographic algorithm
|
||||
|
||||
uint8_t salt[384];
|
||||
salt (the salt size is specified above)
|
||||
|
||||
uint8_t pad3[88];
|
||||
zero padding to 512-byte boundary
|
||||
}
|
||||
|
||||
Directly following the header (and with sector number padded to the next hash
|
||||
block boundary) are the hash blocks which are stored a depth at a time
|
||||
(starting from the root), sorted in order of increasing index.
|
||||
|
||||
Status
|
||||
======
|
||||
V (for Valid) is returned if every check performed so far was valid.
|
||||
If any check failed, C (for Corruption) is returned.
|
||||
|
||||
Example
|
||||
=======
|
||||
|
||||
Setup a device:
|
||||
dmsetup create vroot --table \
|
||||
"0 2097152 "\
|
||||
"verity 1 /dev/sda1 /dev/sda2 4096 4096 2097152 1 "\
|
||||
"4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 "\
|
||||
"1234000000000000000000000000000000000000000000000000000000000000"
|
||||
|
||||
A command line tool veritysetup is available to compute or verify
|
||||
the hash tree or activate the kernel driver. This is available from
|
||||
the LVM2 upstream repository and may be supplied as a package called
|
||||
device-mapper-verity-tools:
|
||||
git://sources.redhat.com/git/lvm2
|
||||
http://sourceware.org/git/?p=lvm2.git
|
||||
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/verity?cvsroot=lvm2
|
||||
|
||||
veritysetup -a vroot /dev/sda1 /dev/sda2 \
|
||||
4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
* Advanced Interrupt Controller (AIC)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "atmel,<chip>-aic"
|
||||
- interrupt-controller: Identifies the node as an interrupt controller.
|
||||
- interrupt-parent: For single AIC system, it is an empty property.
|
||||
- #interrupt-cells: The number of cells to define the interrupts. It sould be 2.
|
||||
The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
|
||||
The second cell is used to specify flags:
|
||||
bits[3:0] trigger type and level flags:
|
||||
1 = low-to-high edge triggered.
|
||||
2 = high-to-low edge triggered.
|
||||
4 = active high level-sensitive.
|
||||
8 = active low level-sensitive.
|
||||
Valid combinations are 1, 2, 3, 4, 8.
|
||||
Default flag for internal sources should be set to 4 (active high).
|
||||
- reg: Should contain AIC registers location and length
|
||||
|
||||
Examples:
|
||||
/*
|
||||
* AIC
|
||||
*/
|
||||
aic: interrupt-controller@fffff000 {
|
||||
compatible = "atmel,at91rm9200-aic";
|
||||
interrupt-controller;
|
||||
interrupt-parent;
|
||||
#interrupt-cells = <2>;
|
||||
reg = <0xfffff000 0x200>;
|
||||
};
|
||||
|
||||
/*
|
||||
* An interrupt generating device that is wired to an AIC.
|
||||
*/
|
||||
dma: dma-controller@ffffec00 {
|
||||
compatible = "atmel,at91sam9g45-dma";
|
||||
reg = <0xffffec00 0x200>;
|
||||
interrupts = <21 4>;
|
||||
};
|
||||
|
|
@ -0,0 +1,92 @@
|
|||
Atmel AT91 device tree bindings.
|
||||
================================
|
||||
|
||||
PIT Timer required properties:
|
||||
- compatible: Should be "atmel,at91sam9260-pit"
|
||||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain interrupt for the PIT which is the IRQ line
|
||||
shared across all System Controller members.
|
||||
|
||||
TC/TCLIB Timer required properties:
|
||||
- compatible: Should be "atmel,<chip>-pit".
|
||||
<chip> can be "at91rm9200" or "at91sam9x5"
|
||||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain all interrupts for the TC block
|
||||
Note that you can specify several interrupt cells if the TC
|
||||
block has one interrupt per channel.
|
||||
|
||||
Examples:
|
||||
|
||||
One interrupt per TC block:
|
||||
tcb0: timer@fff7c000 {
|
||||
compatible = "atmel,at91rm9200-tcb";
|
||||
reg = <0xfff7c000 0x100>;
|
||||
interrupts = <18 4>;
|
||||
};
|
||||
|
||||
One interrupt per TC channel in a TC block:
|
||||
tcb1: timer@fffdc000 {
|
||||
compatible = "atmel,at91rm9200-tcb";
|
||||
reg = <0xfffdc000 0x100>;
|
||||
interrupts = <26 4 27 4 28 4>;
|
||||
};
|
||||
|
||||
RSTC Reset Controller required properties:
|
||||
- compatible: Should be "atmel,<chip>-rstc".
|
||||
<chip> can be "at91sam9260" or "at91sam9g45"
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
Example:
|
||||
|
||||
rstc@fffffd00 {
|
||||
compatible = "atmel,at91sam9260-rstc";
|
||||
reg = <0xfffffd00 0x10>;
|
||||
};
|
||||
|
||||
RAMC SDRAM/DDR Controller required properties:
|
||||
- compatible: Should be "atmel,at91sam9260-sdramc",
|
||||
"atmel,at91sam9g45-ddramc",
|
||||
- reg: Should contain registers location and length
|
||||
For at91sam9263 and at91sam9g45 you must specify 2 entries.
|
||||
|
||||
Examples:
|
||||
|
||||
ramc0: ramc@ffffe800 {
|
||||
compatible = "atmel,at91sam9g45-ddramc";
|
||||
reg = <0xffffe800 0x200>;
|
||||
};
|
||||
|
||||
ramc0: ramc@ffffe400 {
|
||||
compatible = "atmel,at91sam9g45-ddramc";
|
||||
reg = <0xffffe400 0x200
|
||||
0xffffe600 0x200>;
|
||||
};
|
||||
|
||||
SHDWC Shutdown Controller
|
||||
|
||||
required properties:
|
||||
- compatible: Should be "atmel,<chip>-shdwc".
|
||||
<chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5".
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
optional properties:
|
||||
- atmel,wakeup-mode: String, operation mode of the wakeup mode.
|
||||
Supported values are: "none", "high", "low", "any".
|
||||
- atmel,wakeup-counter: Counter on Wake-up 0 (between 0x0 and 0xf).
|
||||
|
||||
optional at91sam9260 properties:
|
||||
- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
|
||||
|
||||
optional at91sam9rl properties:
|
||||
- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up.
|
||||
- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
|
||||
|
||||
optional at91sam9x5 properties:
|
||||
- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up.
|
||||
|
||||
Example:
|
||||
|
||||
rstc@fffffd00 {
|
||||
compatible = "atmel,at91sam9260-rstc";
|
||||
reg = <0xfffffd00 0x10>;
|
||||
};
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
* Power Management Controller (PMC)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "atmel,at91rm9200-pmc"
|
||||
- reg: Should contain PMC registers location and length
|
||||
|
||||
Examples:
|
||||
pmc: pmc@fffffc00 {
|
||||
compatible = "atmel,at91rm9200-pmc";
|
||||
reg = <0xfffffc00 0x100>;
|
||||
};
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
* Samsung Exynos Power Domains
|
||||
|
||||
Exynos processors include support for multiple power domains which are used
|
||||
to gate power to one or more peripherals on the processor.
|
||||
|
||||
Required Properties:
|
||||
- compatiable: should be one of the following.
|
||||
* samsung,exynos4210-pd - for exynos4210 type power domain.
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
||||
Optional Properties:
|
||||
- samsung,exynos4210-pd-off: Specifies that the power domain is in turned-off
|
||||
state during boot and remains to be turned-off until explicitly turned-on.
|
||||
|
||||
Example:
|
||||
|
||||
lcd0: power-domain-lcd0 {
|
||||
compatible = "samsung,exynos4210-pd";
|
||||
reg = <0x10023C00 0x10>;
|
||||
};
|
||||
|
|
@ -28,3 +28,25 @@ Required root node properties:
|
|||
i.MX6 Quad SABRE Lite Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6q-sabrelite", "fsl,imx6q";
|
||||
|
||||
Generic i.MX boards
|
||||
-------------------
|
||||
|
||||
No iomux setup is done for these boards, so this must have been configured
|
||||
by the bootloader for boards to work with the generic bindings.
|
||||
|
||||
i.MX27 generic board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx27";
|
||||
|
||||
i.MX51 generic board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx51";
|
||||
|
||||
i.MX53 generic board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx53";
|
||||
|
||||
i.MX6q generic board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6q";
|
||||
|
|
|
|||
|
|
@ -0,0 +1,6 @@
|
|||
Marvell Platforms Device Tree Bindings
|
||||
----------------------------------------------------
|
||||
|
||||
PXA168 Aspenite Board
|
||||
Required root node properties:
|
||||
- compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
* OMAP Interrupt Controller
|
||||
|
||||
OMAP2/3 are using a TI interrupt controller that can support several
|
||||
configurable number of interrupts.
|
||||
|
||||
Main node required properties:
|
||||
|
||||
- compatible : should be:
|
||||
"ti,omap2-intc"
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
interrupt source. The type shall be a <u32> and the value shall be 1.
|
||||
|
||||
The cell contains the interrupt number in the range [0-128].
|
||||
- ti,intc-size: Number of interrupts handled by the interrupt controller.
|
||||
- reg: physical base address and size of the intc registers map.
|
||||
|
||||
Example:
|
||||
|
||||
intc: interrupt-controller@1 {
|
||||
compatible = "ti,omap2-intc";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
ti,intc-size = <96>;
|
||||
reg = <0x48200000 0x1000>;
|
||||
};
|
||||
|
||||
|
|
@ -41,3 +41,9 @@ Boards:
|
|||
|
||||
- OMAP4 PandaBoard : Low cost community board
|
||||
compatible = "ti,omap4-panda", "ti,omap4430"
|
||||
|
||||
- OMAP3 EVM : Software Developement Board for OMAP35x, AM/DM37x
|
||||
compatible = "ti,omap3-evm", "ti,omap3"
|
||||
|
||||
- AM335X EVM : Software Developement Board for AM335x
|
||||
compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,8 @@
|
|||
ST SPEAr Platforms Device Tree Bindings
|
||||
---------------------------------------
|
||||
|
||||
Boards with the ST SPEAr600 SoC shall have the following properties:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible = "st,spear600";
|
||||
|
|
@ -0,0 +1,100 @@
|
|||
Embedded Memory Controller
|
||||
|
||||
Properties:
|
||||
- name : Should be emc
|
||||
- #address-cells : Should be 1
|
||||
- #size-cells : Should be 0
|
||||
- compatible : Should contain "nvidia,tegra20-emc".
|
||||
- reg : Offset and length of the register set for the device
|
||||
- nvidia,use-ram-code : If present, the sub-nodes will be addressed
|
||||
and chosen using the ramcode board selector. If omitted, only one
|
||||
set of tables can be present and said tables will be used
|
||||
irrespective of ram-code configuration.
|
||||
|
||||
Child device nodes describe the memory settings for different configurations and clock rates.
|
||||
|
||||
Example:
|
||||
|
||||
emc@7000f400 {
|
||||
#address-cells = < 1 >;
|
||||
#size-cells = < 0 >;
|
||||
compatible = "nvidia,tegra20-emc";
|
||||
reg = <0x7000f4000 0x200>;
|
||||
}
|
||||
|
||||
|
||||
Embedded Memory Controller ram-code table
|
||||
|
||||
If the emc node has the nvidia,use-ram-code property present, then the
|
||||
next level of nodes below the emc table are used to specify which settings
|
||||
apply for which ram-code settings.
|
||||
|
||||
If the emc node lacks the nvidia,use-ram-code property, this level is omitted
|
||||
and the tables are stored directly under the emc node (see below).
|
||||
|
||||
Properties:
|
||||
|
||||
- name : Should be emc-tables
|
||||
- nvidia,ram-code : the binary representation of the ram-code board strappings
|
||||
for which this node (and children) are valid.
|
||||
|
||||
|
||||
|
||||
Embedded Memory Controller configuration table
|
||||
|
||||
This is a table containing the EMC register settings for the various
|
||||
operating speeds of the memory controller. They are always located as
|
||||
subnodes of the emc controller node.
|
||||
|
||||
There are two ways of specifying which tables to use:
|
||||
|
||||
* The simplest is if there is just one set of tables in the device tree,
|
||||
and they will always be used (based on which frequency is used).
|
||||
This is the preferred method, especially when firmware can fill in
|
||||
this information based on the specific system information and just
|
||||
pass it on to the kernel.
|
||||
|
||||
* The slightly more complex one is when more than one memory configuration
|
||||
might exist on the system. The Tegra20 platform handles this during
|
||||
early boot by selecting one out of possible 4 memory settings based
|
||||
on a 2-pin "ram code" bootstrap setting on the board. The values of
|
||||
these strappings can be read through a register in the SoC, and thus
|
||||
used to select which tables to use.
|
||||
|
||||
Properties:
|
||||
- name : Should be emc-table
|
||||
- compatible : Should contain "nvidia,tegra20-emc-table".
|
||||
- reg : either an opaque enumerator to tell different tables apart, or
|
||||
the valid frequency for which the table should be used (in kHz).
|
||||
- clock-frequency : the clock frequency for the EMC at which this
|
||||
table should be used (in kHz).
|
||||
- nvidia,emc-registers : a 46 word array of EMC registers to be programmed
|
||||
for operation at the 'clock-frequency' setting.
|
||||
The order and contents of the registers are:
|
||||
RC, RFC, RAS, RP, R2W, W2R, R2P, W2P, RD_RCD, WR_RCD, RRD, REXT,
|
||||
WDV, QUSE, QRST, QSAFE, RDV, REFRESH, BURST_REFRESH_NUM, PDEX2WR,
|
||||
PDEX2RD, PCHG2PDEN, ACT2PDEN, AR2PDEN, RW2PDEN, TXSR, TCKE, TFAW,
|
||||
TRPAB, TCLKSTABLE, TCLKSTOP, TREFBW, QUSE_EXTRA, FBIO_CFG6, ODT_WRITE,
|
||||
ODT_READ, FBIO_CFG5, CFG_DIG_DLL, DLL_XFORM_DQS, DLL_XFORM_QUSE,
|
||||
ZCAL_REF_CNT, ZCAL_WAIT_CNT, AUTO_CAL_INTERVAL, CFG_CLKTRIM_0,
|
||||
CFG_CLKTRIM_1, CFG_CLKTRIM_2
|
||||
|
||||
emc-table@166000 {
|
||||
reg = <166000>;
|
||||
compatible = "nvidia,tegra20-emc-table";
|
||||
clock-frequency = < 166000 >;
|
||||
nvidia,emc-registers = < 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||
0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||
0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||
0 0 0 0 >;
|
||||
};
|
||||
|
||||
emc-table@333000 {
|
||||
reg = <333000>;
|
||||
compatible = "nvidia,tegra20-emc-table";
|
||||
clock-frequency = < 333000 >;
|
||||
nvidia,emc-registers = < 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||
0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||
0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||
0 0 0 0 >;
|
||||
};
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
NVIDIA Tegra Power Management Controller (PMC)
|
||||
|
||||
Properties:
|
||||
- name : Should be pmc
|
||||
- compatible : Should contain "nvidia,tegra<chip>-pmc".
|
||||
- reg : Offset and length of the register set for the device
|
||||
- nvidia,invert-interrupt : If present, inverts the PMU interrupt signal.
|
||||
The PMU is an external Power Management Unit, whose interrupt output
|
||||
signal is fed into the PMC. This signal is optionally inverted, and then
|
||||
fed into the ARM GIC. The PMC is not involved in the detection or
|
||||
handling of this interrupt signal, merely its inversion.
|
||||
|
||||
Example:
|
||||
|
||||
pmc@7000f400 {
|
||||
compatible = "nvidia,tegra20-pmc";
|
||||
reg = <0x7000e400 0x400>;
|
||||
nvidia,invert-interrupt;
|
||||
};
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
* ARM Timer Watchdog
|
||||
|
||||
ARM 11MP, Cortex-A5 and Cortex-A9 are often associated with a per-core
|
||||
Timer-Watchdog (aka TWD), which provides both a per-cpu local timer
|
||||
and watchdog.
|
||||
|
||||
The TWD is usually attached to a GIC to deliver its two per-processor
|
||||
interrupts.
|
||||
|
||||
** Timer node required properties:
|
||||
|
||||
- compatible : Should be one of:
|
||||
"arm,cortex-a9-twd-timer"
|
||||
"arm,cortex-a5-twd-timer"
|
||||
"arm,arm11mp-twd-timer"
|
||||
|
||||
- interrupts : One interrupt to each core
|
||||
|
||||
- reg : Specify the base address and the size of the TWD timer
|
||||
register window.
|
||||
|
||||
Example:
|
||||
|
||||
twd-timer@2c000600 {
|
||||
compatible = "arm,arm11mp-twd-timer"";
|
||||
reg = <0x2c000600 0x20>;
|
||||
interrupts = <1 13 0xf01>;
|
||||
};
|
||||
|
||||
** Watchdog node properties:
|
||||
|
||||
- compatible : Should be one of:
|
||||
"arm,cortex-a9-twd-wdt"
|
||||
"arm,cortex-a5-twd-wdt"
|
||||
"arm,arm11mp-twd-wdt"
|
||||
|
||||
- interrupts : One interrupt to each core
|
||||
|
||||
- reg : Specify the base address and the size of the TWD watchdog
|
||||
register window.
|
||||
|
||||
Example:
|
||||
|
||||
twd-watchdog@2c000620 {
|
||||
compatible = "arm,arm11mp-twd-wdt";
|
||||
reg = <0x2c000620 0x20>;
|
||||
interrupts = <1 14 0xf01>;
|
||||
};
|
||||
|
|
@ -0,0 +1,146 @@
|
|||
ARM Versatile Express boards family
|
||||
-----------------------------------
|
||||
|
||||
ARM's Versatile Express platform consists of a motherboard and one
|
||||
or more daughterboards (tiles). The motherboard provides a set of
|
||||
peripherals. Processor and RAM "live" on the tiles.
|
||||
|
||||
The motherboard and each core tile should be described by a separate
|
||||
Device Tree source file, with the tile's description including
|
||||
the motherboard file using a /include/ directive. As the motherboard
|
||||
can be initialized in one of two different configurations ("memory
|
||||
maps"), care must be taken to include the correct one.
|
||||
|
||||
Required properties in the root node:
|
||||
- compatible value:
|
||||
compatible = "arm,vexpress,<model>", "arm,vexpress";
|
||||
where <model> is the full tile model name (as used in the tile's
|
||||
Technical Reference Manual), eg.:
|
||||
- for Coretile Express A5x2 (V2P-CA5s):
|
||||
compatible = "arm,vexpress,v2p-ca5s", "arm,vexpress";
|
||||
- for Coretile Express A9x4 (V2P-CA9):
|
||||
compatible = "arm,vexpress,v2p-ca9", "arm,vexpress";
|
||||
If a tile comes in several variants or can be used in more then one
|
||||
configuration, the compatible value should be:
|
||||
compatible = "arm,vexpress,<model>,<variant>", \
|
||||
"arm,vexpress,<model>", "arm,vexpress";
|
||||
eg:
|
||||
- Coretile Express A15x2 (V2P-CA15) with Tech Chip 1:
|
||||
compatible = "arm,vexpress,v2p-ca15,tc1", \
|
||||
"arm,vexpress,v2p-ca15", "arm,vexpress";
|
||||
- LogicTile Express 13MG (V2F-2XV6) running Cortex-A7 (3 cores) SMM:
|
||||
compatible = "arm,vexpress,v2f-2xv6,ca7x3", \
|
||||
"arm,vexpress,v2f-2xv6", "arm,vexpress";
|
||||
|
||||
Optional properties in the root node:
|
||||
- tile model name (use name from the tile's Technical Reference
|
||||
Manual, eg. "V2P-CA5s")
|
||||
model = "<model>";
|
||||
- tile's HBI number (unique ARM's board model ID, visible on the
|
||||
PCB's silkscreen) in hexadecimal transcription:
|
||||
arm,hbi = <0xhbi>
|
||||
eg:
|
||||
- for Coretile Express A5x2 (V2P-CA5s) HBI-0191:
|
||||
arm,hbi = <0x191>;
|
||||
- Coretile Express A9x4 (V2P-CA9) HBI-0225:
|
||||
arm,hbi = <0x225>;
|
||||
|
||||
Top-level standard "cpus" node is required. It must contain a node
|
||||
with device_type = "cpu" property for every available core, eg.:
|
||||
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a5";
|
||||
reg = <0>;
|
||||
};
|
||||
};
|
||||
|
||||
The motherboard description file provides a single "motherboard" node
|
||||
using 2 address cells corresponding to the Static Memory Bus used
|
||||
between the motherboard and the tile. The first cell defines the Chip
|
||||
Select (CS) line number, the second cell address offset within the CS.
|
||||
All interrupt lines between the motherboard and the tile are active
|
||||
high and are described using single cell.
|
||||
|
||||
Optional properties of the "motherboard" node:
|
||||
- motherboard's memory map variant:
|
||||
arm,v2m-memory-map = "<name>";
|
||||
where name is one of:
|
||||
- "rs1" - for RS1 map (i.a. peripherals on CS3); this map is also
|
||||
referred to as "ARM Cortex-A Series memory map":
|
||||
arm,v2m-memory-map = "rs1";
|
||||
When this property is missing, the motherboard is using the original
|
||||
memory map (also known as the "Legacy memory map", primarily used
|
||||
with the original CoreTile Express A9x4) with peripherals on CS7.
|
||||
|
||||
Motherboard .dtsi files provide a set of labelled peripherals that
|
||||
can be used to obtain required phandle in the tile's "aliases" node:
|
||||
- UARTs, note that the numbers correspond to the physical connectors
|
||||
on the motherboard's back panel:
|
||||
v2m_serial0, v2m_serial1, v2m_serial2 and v2m_serial3
|
||||
- I2C controllers:
|
||||
v2m_i2c_dvi and v2m_i2c_pcie
|
||||
- SP804 timers:
|
||||
v2m_timer01 and v2m_timer23
|
||||
|
||||
Current Linux implementation requires a "arm,v2m_timer" alias
|
||||
pointing at one of the motherboard's SP804 timers, if it is to be
|
||||
used as the system timer. This alias should be defined in the
|
||||
motherboard files.
|
||||
|
||||
The tile description must define "ranges", "interrupt-map-mask" and
|
||||
"interrupt-map" properties to translate the motherboard's address
|
||||
and interrupt space into one used by the tile's processor.
|
||||
|
||||
Abbreviated example:
|
||||
|
||||
/dts-v1/;
|
||||
|
||||
/ {
|
||||
model = "V2P-CA5s";
|
||||
arm,hbi = <0x225>;
|
||||
compatible = "arm,vexpress-v2p-ca5s", "arm,vexpress";
|
||||
interrupt-parent = <&gic>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
chosen { };
|
||||
|
||||
aliases {
|
||||
serial0 = &v2m_serial0;
|
||||
};
|
||||
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a5";
|
||||
reg = <0>;
|
||||
};
|
||||
};
|
||||
|
||||
gic: interrupt-controller@2c001000 {
|
||||
compatible = "arm,cortex-a9-gic";
|
||||
#interrupt-cells = <3>;
|
||||
#address-cells = <0>;
|
||||
interrupt-controller;
|
||||
reg = <0x2c001000 0x1000>,
|
||||
<0x2c000100 0x100>;
|
||||
};
|
||||
|
||||
motherboard {
|
||||
/* CS0 is visible at 0x08000000 */
|
||||
ranges = <0 0 0x08000000 0x04000000>;
|
||||
interrupt-map-mask = <0 0 63>;
|
||||
/* Active high IRQ 0 is connected to GIC's SPI0 */
|
||||
interrupt-map = <0 0 0 &gic 0 0 4>;
|
||||
};
|
||||
};
|
||||
|
||||
/include/ "vexpress-v2m-rs1.dtsi"
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
* NVIDIA Tegra APB DMA controller
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "nvidia,<chip>-apbdma"
|
||||
- reg: Should contain DMA registers location and length. This shuld include
|
||||
all of the per-channel registers.
|
||||
- interrupts: Should contain all of the per-channel DMA interrupts.
|
||||
|
||||
Examples:
|
||||
|
||||
apbdma: dma@6000a000 {
|
||||
compatible = "nvidia,tegra20-apbdma";
|
||||
reg = <0x6000a000 0x1200>;
|
||||
interrupts = < 0 136 0x04
|
||||
0 137 0x04
|
||||
0 138 0x04
|
||||
0 139 0x04
|
||||
0 140 0x04
|
||||
0 141 0x04
|
||||
0 142 0x04
|
||||
0 143 0x04
|
||||
0 144 0x04
|
||||
0 145 0x04
|
||||
0 146 0x04
|
||||
0 147 0x04
|
||||
0 148 0x04
|
||||
0 149 0x04
|
||||
0 150 0x04
|
||||
0 151 0x04 >;
|
||||
};
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
OMAP GPIO controller bindings
|
||||
|
||||
Required properties:
|
||||
- compatible:
|
||||
- "ti,omap2-gpio" for OMAP2 controllers
|
||||
- "ti,omap3-gpio" for OMAP3 controllers
|
||||
- "ti,omap4-gpio" for OMAP4 controllers
|
||||
- #gpio-cells : Should be two.
|
||||
- first cell is the pin number
|
||||
- second cell is used to specify optional parameters (unused)
|
||||
- gpio-controller : Marks the device node as a GPIO controller.
|
||||
- #interrupt-cells : Should be 2.
|
||||
- interrupt-controller: Mark the device node as an interrupt controller
|
||||
The first cell is the GPIO number.
|
||||
The second cell is used to specify flags:
|
||||
bits[3:0] trigger type and level flags:
|
||||
1 = low-to-high edge triggered.
|
||||
2 = high-to-low edge triggered.
|
||||
4 = active high level-sensitive.
|
||||
8 = active low level-sensitive.
|
||||
|
||||
OMAP specific properties:
|
||||
- ti,hwmods: Name of the hwmod associated to the GPIO:
|
||||
"gpio<X>", <X> being the 1-based instance number from the HW spec
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
gpio4: gpio4 {
|
||||
compatible = "ti,omap4-gpio";
|
||||
ti,hwmods = "gpio4";
|
||||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
};
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
twl4030 GPIO controller bindings
|
||||
|
||||
Required properties:
|
||||
- compatible:
|
||||
- "ti,twl4030-gpio" for twl4030 GPIO controller
|
||||
- #gpio-cells : Should be two.
|
||||
- first cell is the pin number
|
||||
- second cell is used to specify optional parameters (unused)
|
||||
- gpio-controller : Marks the device node as a GPIO controller.
|
||||
- #interrupt-cells : Should be 2.
|
||||
- interrupt-controller: Mark the device node as an interrupt controller
|
||||
The first cell is the GPIO number.
|
||||
The second cell is not used.
|
||||
|
||||
Example:
|
||||
|
||||
twl_gpio: gpio {
|
||||
compatible = "ti,twl4030-gpio";
|
||||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
};
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
* Atmel GPIO controller (PIO)
|
||||
|
||||
Required properties:
|
||||
- compatible: "atmel,<chip>-gpio", where <chip> is at91rm9200 or at91sam9x5.
|
||||
- reg: Should contain GPIO controller registers location and length
|
||||
- interrupts: Should be the port interrupt shared by all the pins.
|
||||
- #gpio-cells: Should be two. The first cell is the pin number and
|
||||
the second cell is used to specify optional parameters (currently
|
||||
unused).
|
||||
- gpio-controller: Marks the device node as a GPIO controller.
|
||||
|
||||
Example:
|
||||
pioA: gpio@fffff200 {
|
||||
compatible = "atmel,at91rm9200-gpio";
|
||||
reg = <0xfffff200 0x100>;
|
||||
interrupts = <2 4>;
|
||||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
};
|
||||
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
Device-Tree bindings for i2c gpio driver
|
||||
|
||||
Required properties:
|
||||
- compatible = "i2c-gpio";
|
||||
- gpios: sda and scl gpio
|
||||
|
||||
|
||||
Optional properties:
|
||||
- i2c-gpio,sda-open-drain: sda as open drain
|
||||
- i2c-gpio,scl-open-drain: scl as open drain
|
||||
- i2c-gpio,scl-output-only: scl as output only
|
||||
- i2c-gpio,delay-us: delay between GPIO operations (may depend on each platform)
|
||||
- i2c-gpio,timeout-ms: timeout to get data
|
||||
|
||||
Example nodes:
|
||||
|
||||
i2c@0 {
|
||||
compatible = "i2c-gpio";
|
||||
gpios = <&pioA 23 0 /* sda */
|
||||
&pioA 24 0 /* scl */
|
||||
>;
|
||||
i2c-gpio,sda-open-drain;
|
||||
i2c-gpio,scl-open-drain;
|
||||
i2c-gpio,delay-us = <2>; /* ~100 kHz */
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
rv3029c2@56 {
|
||||
compatible = "rv3029c2";
|
||||
reg = <0x56>;
|
||||
};
|
||||
};
|
||||
|
|
@ -1,8 +1,40 @@
|
|||
NVIDIA Tegra 2 GPIO controller
|
||||
NVIDIA Tegra GPIO controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "nvidia,tegra20-gpio"
|
||||
- compatible : "nvidia,tegra<chip>-gpio"
|
||||
- reg : Physical base address and length of the controller's registers.
|
||||
- interrupts : The interrupt outputs from the controller. For Tegra20,
|
||||
there should be 7 interrupts specified, and for Tegra30, there should
|
||||
be 8 interrupts specified.
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and the
|
||||
second cell is used to specify optional parameters:
|
||||
- bit 0 specifies polarity (0 for normal, 1 for inverted)
|
||||
- gpio-controller : Marks the device node as a GPIO controller.
|
||||
- #interrupt-cells : Should be 2.
|
||||
The first cell is the GPIO number.
|
||||
The second cell is used to specify flags:
|
||||
bits[3:0] trigger type and level flags:
|
||||
1 = low-to-high edge triggered.
|
||||
2 = high-to-low edge triggered.
|
||||
4 = active high level-sensitive.
|
||||
8 = active low level-sensitive.
|
||||
Valid combinations are 1, 2, 3, 4, 8.
|
||||
- interrupt-controller : Marks the device node as an interrupt controller.
|
||||
|
||||
Example:
|
||||
|
||||
gpio: gpio@6000d000 {
|
||||
compatible = "nvidia,tegra20-gpio";
|
||||
reg = < 0x6000d000 0x1000 >;
|
||||
interrupts = < 0 32 0x04
|
||||
0 33 0x04
|
||||
0 34 0x04
|
||||
0 35 0x04
|
||||
0 55 0x04
|
||||
0 87 0x04
|
||||
0 89 0x04 >;
|
||||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -7,9 +7,9 @@ Each LED is represented as a sub-node of the gpio-leds device. Each
|
|||
node's name represents the name of the corresponding LED.
|
||||
|
||||
LED sub-node properties:
|
||||
- gpios : Should specify the LED's GPIO, see "Specifying GPIO information
|
||||
for devices" in Documentation/devicetree/booting-without-of.txt. Active
|
||||
low LEDs should be indicated using flags in the GPIO specifier.
|
||||
- gpios : Should specify the LED's GPIO, see "gpios property" in
|
||||
Documentation/devicetree/gpio.txt. Active low LEDs should be
|
||||
indicated using flags in the GPIO specifier.
|
||||
- label : (optional) The label for this LED. If omitted, the label is
|
||||
taken from the node name (excluding the unit address).
|
||||
- linux,default-trigger : (optional) This parameter, if present, is a
|
||||
|
|
|
|||
|
|
@ -0,0 +1,23 @@
|
|||
* Marvell PXA GPIO controller
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "mrvl,pxa-gpio" or "mrvl,mmp-gpio"
|
||||
- reg : Address and length of the register set for the device
|
||||
- interrupts : Should be the port interrupt shared by all gpio pins, if
|
||||
- interrupt-name : Should be the name of irq resource.
|
||||
one number.
|
||||
- gpio-controller : Marks the device node as a gpio controller.
|
||||
- #gpio-cells : Should be one. It is the pin number.
|
||||
|
||||
Example:
|
||||
|
||||
gpio: gpio@d4019000 {
|
||||
compatible = "mrvl,mmp-gpio", "mrvl,pxa-gpio";
|
||||
reg = <0xd4019000 0x1000>;
|
||||
interrupts = <49>, <17>, <18>;
|
||||
interrupt-name = "gpio_mux", "gpio0", "gpio1";
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
};
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
GPIO controller on CE4100 / Sodaville SoCs
|
||||
==========================================
|
||||
|
||||
The bindings for CE4100's GPIO controller match the generic description
|
||||
which is covered by the gpio.txt file in this folder.
|
||||
|
||||
The only additional property is the intel,muxctl property which holds the
|
||||
value which is written into the MUXCNTL register.
|
||||
|
||||
There is no compatible property for now because the driver is probed via
|
||||
PCI id (vendor 0x8086 device 0x2e67).
|
||||
|
||||
The interrupt specifier consists of two cells encoded as follows:
|
||||
- <1st cell>: The interrupt-number that identifies the interrupt source.
|
||||
- <2nd cell>: The level-sense information, encoded as follows:
|
||||
4 - active high level-sensitive
|
||||
8 - active low level-sensitive
|
||||
|
||||
Example of the GPIO device and one user:
|
||||
|
||||
pcigpio: gpio@b,1 {
|
||||
/* two cells for GPIO and interrupt */
|
||||
#gpio-cells = <2>;
|
||||
#interrupt-cells = <2>;
|
||||
compatible = "pci8086,2e67.2",
|
||||
"pci8086,2e67",
|
||||
"pciclassff0000",
|
||||
"pciclassff00";
|
||||
|
||||
reg = <0x15900 0x0 0x0 0x0 0x0>;
|
||||
/* Interrupt line of the gpio device */
|
||||
interrupts = <15 1>;
|
||||
/* It is an interrupt and GPIO controller itself */
|
||||
interrupt-controller;
|
||||
gpio-controller;
|
||||
intel,muxctl = <0>;
|
||||
};
|
||||
|
||||
testuser@20 {
|
||||
compatible = "example,testuser";
|
||||
/* User the 11th GPIO line as an active high triggered
|
||||
* level interrupt
|
||||
*/
|
||||
interrupts = <11 8>;
|
||||
interrupt-parent = <&pcigpio>;
|
||||
/* Use this GPIO also with the gpio functions */
|
||||
gpios = <&pcigpio 11 0>;
|
||||
};
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
* I2C
|
||||
|
||||
Required properties :
|
||||
|
||||
- reg : Offset and length of the register set for the device
|
||||
- compatible : should be "mrvl,mmp-twsi" where CHIP is the name of a
|
||||
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
|
||||
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
|
||||
as shown in the example below.
|
||||
|
||||
Recommended properties :
|
||||
|
||||
- interrupts : <a b> where a is the interrupt number and b is a
|
||||
field that represents an encoding of the sense and level
|
||||
information for the interrupt. This should be encoded based on
|
||||
the information in section 2) depending on the type of interrupt
|
||||
controller you have.
|
||||
- interrupt-parent : the phandle for the interrupt controller that
|
||||
services interrupts for this device.
|
||||
- mrvl,i2c-polling : Disable interrupt of i2c controller. Polling
|
||||
status register of i2c controller instead.
|
||||
- mrvl,i2c-fast-mode : Enable fast mode of i2c controller.
|
||||
|
||||
Examples:
|
||||
twsi1: i2c@d4011000 {
|
||||
compatible = "mrvl,mmp-twsi", "mrvl,pxa-i2c";
|
||||
reg = <0xd4011000 0x1000>;
|
||||
interrupts = <7>;
|
||||
mrvl,i2c-fast-mode;
|
||||
};
|
||||
|
||||
twsi2: i2c@d4025000 {
|
||||
compatible = "mrvl,mmp-twsi", "mrvl,pxa-i2c";
|
||||
reg = <0xd4025000 0x1000>;
|
||||
interrupts = <58>;
|
||||
};
|
||||
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
I2C for SiRFprimaII platforms
|
||||
|
||||
Required properties :
|
||||
- compatible : Must be "sirf,prima2-i2c"
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- interrupts: interrupt number to the cpu.
|
||||
|
||||
Optional properties:
|
||||
- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz.
|
||||
The absence of the propoerty indicates the default frequency 100 kHz.
|
||||
|
||||
Examples :
|
||||
|
||||
i2c0: i2c@b00e0000 {
|
||||
compatible = "sirf,prima2-i2c";
|
||||
reg = <0xb00e0000 0x10000>;
|
||||
interrupts = <24>;
|
||||
};
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
A simple common binding for matrix-connected key boards. Currently targeted at
|
||||
defining the keys in the scope of linux key codes since that is a stable and
|
||||
standardized interface at this time.
|
||||
|
||||
Required properties:
|
||||
- linux,keymap: an array of packed 1-cell entries containing the equivalent
|
||||
of row, column and linux key-code. The 32-bit big endian cell is packed
|
||||
as:
|
||||
row << 24 | column << 16 | key-code
|
||||
|
||||
Optional properties:
|
||||
Some users of this binding might choose to specify secondary keymaps for
|
||||
cases where there is a modifier key such as a Fn key. Proposed names
|
||||
for said properties are "linux,fn-keymap" or with another descriptive
|
||||
word for the modifier other from "Fn".
|
||||
|
||||
Example:
|
||||
linux,keymap = < 0x00030012
|
||||
0x0102003a >;
|
||||
|
|
@ -3,16 +3,21 @@
|
|||
Required properties:
|
||||
- compatible: "nvidia,tegra20-kbc"
|
||||
|
||||
Optional properties:
|
||||
- debounce-delay: delay in milliseconds per row scan for debouncing
|
||||
- repeat-delay: delay in milliseconds before repeat starts
|
||||
- ghost-filter: enable ghost filtering for this device
|
||||
- wakeup-source: configure keyboard as a wakeup source for suspend/resume
|
||||
Optional properties, in addition to those specified by the shared
|
||||
matrix-keyboard bindings:
|
||||
|
||||
- linux,fn-keymap: a second keymap, same specification as the
|
||||
matrix-keyboard-controller spec but to be used when the KEY_FN modifier
|
||||
key is pressed.
|
||||
- nvidia,debounce-delay-ms: delay in milliseconds per row scan for debouncing
|
||||
- nvidia,repeat-delay-ms: delay in milliseconds before repeat starts
|
||||
- nvidia,ghost-filter: enable ghost filtering for this device
|
||||
- nvidia,wakeup-source: configure keyboard as a wakeup source for suspend/resume
|
||||
|
||||
Example:
|
||||
|
||||
keyboard: keyboard {
|
||||
compatible = "nvidia,tegra20-kbc";
|
||||
reg = <0x7000e200 0x100>;
|
||||
ghost-filter;
|
||||
nvidia,ghost-filter;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,33 @@
|
|||
* TI Highspeed MMC host controller for OMAP
|
||||
|
||||
The Highspeed MMC Host Controller on TI OMAP family
|
||||
provides an interface for MMC, SD, and SDIO types of memory cards.
|
||||
|
||||
Required properties:
|
||||
- compatible:
|
||||
Should be "ti,omap2-hsmmc", for OMAP2 controllers
|
||||
Should be "ti,omap3-hsmmc", for OMAP3 controllers
|
||||
Should be "ti,omap4-hsmmc", for OMAP4 controllers
|
||||
- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1
|
||||
- reg : should contain hsmmc registers location and length
|
||||
|
||||
Optional properties:
|
||||
ti,dual-volt: boolean, supports dual voltage cards
|
||||
<supply-name>-supply: phandle to the regulator device tree node
|
||||
"supply-name" examples are "vmmc", "vmmc_aux" etc
|
||||
ti,bus-width: Number of data lines, default assumed is 1 if the property is missing.
|
||||
cd-gpios: GPIOs for card detection
|
||||
wp-gpios: GPIOs for write protection
|
||||
ti,non-removable: non-removable slot (like eMMC)
|
||||
ti,needs-special-reset: Requires a special softreset sequence
|
||||
|
||||
Example:
|
||||
mmc1: mmc@0x4809c000 {
|
||||
compatible = "ti,omap4-hsmmc";
|
||||
reg = <0x4809c000 0x400>;
|
||||
ti,hwmods = "mmc1";
|
||||
ti,dual-volt;
|
||||
ti,bus-width = <4>;
|
||||
vmmc-supply = <&vmmc>; /* phandle to regulator node */
|
||||
ti,non-removable;
|
||||
};
|
||||
|
|
@ -4,5 +4,5 @@ Required properties:
|
|||
- compatible : must be "arm,versatile-flash";
|
||||
- bank-width : width in bytes of flash interface.
|
||||
|
||||
Optional properties:
|
||||
- Subnode partition map from mtd flash binding
|
||||
The device tree may optionally contain sub-nodes describing partitions of the
|
||||
address space. See partition.txt for more detail.
|
||||
|
|
|
|||
|
|
@ -3,6 +3,9 @@
|
|||
Required properties:
|
||||
- compatible : "atmel,<model>", "atmel,<series>", "atmel,dataflash".
|
||||
|
||||
The device tree may optionally contain sub-nodes describing partitions of the
|
||||
address space. See partition.txt for more detail.
|
||||
|
||||
Example:
|
||||
|
||||
flash@1 {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,41 @@
|
|||
Atmel NAND flash
|
||||
|
||||
Required properties:
|
||||
- compatible : "atmel,at91rm9200-nand".
|
||||
- reg : should specify localbus address and size used for the chip,
|
||||
and if availlable the ECC.
|
||||
- atmel,nand-addr-offset : offset for the address latch.
|
||||
- atmel,nand-cmd-offset : offset for the command latch.
|
||||
- #address-cells, #size-cells : Must be present if the device has sub-nodes
|
||||
representing partitions.
|
||||
|
||||
- gpios : specifies the gpio pins to control the NAND device. detect is an
|
||||
optional gpio and may be set to 0 if not present.
|
||||
|
||||
Optional properties:
|
||||
- nand-ecc-mode : String, operation mode of the NAND ecc mode, soft by default.
|
||||
Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
|
||||
"soft_bch".
|
||||
- nand-bus-width : 8 or 16 bus width if not present 8
|
||||
- nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
|
||||
|
||||
Examples:
|
||||
nand0: nand@40000000,0 {
|
||||
compatible = "atmel,at91rm9200-nand";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x40000000 0x10000000
|
||||
0xffffe800 0x200
|
||||
>;
|
||||
atmel,nand-addr-offset = <21>; /* ale */
|
||||
atmel,nand-cmd-offset = <22>; /* cle */
|
||||
nand-on-flash-bbt;
|
||||
nand-ecc-mode = "soft";
|
||||
gpios = <&pioC 13 0 /* rdy */
|
||||
&pioC 14 0 /* nce */
|
||||
0 /* cd */
|
||||
>;
|
||||
partition@0 {
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
@ -19,6 +19,10 @@ Optional properties:
|
|||
read registers (tR). Required if property "gpios" is not used
|
||||
(R/B# pins not connected).
|
||||
|
||||
Each flash chip described may optionally contain additional sub-nodes
|
||||
describing partitions of the address space. See partition.txt for more
|
||||
detail.
|
||||
|
||||
Examples:
|
||||
|
||||
upm@1,0 {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,33 @@
|
|||
* FSMC NAND
|
||||
|
||||
Required properties:
|
||||
- compatible : "st,spear600-fsmc-nand"
|
||||
- reg : Address range of the mtd chip
|
||||
- reg-names: Should contain the reg names "fsmc_regs" and "nand_data"
|
||||
- st,ale-off : Chip specific offset to ALE
|
||||
- st,cle-off : Chip specific offset to CLE
|
||||
|
||||
Optional properties:
|
||||
- bank-width : Width (in bytes) of the device. If not present, the width
|
||||
defaults to 1 byte
|
||||
- nand-skip-bbtscan: Indicates the the BBT scanning should be skipped
|
||||
|
||||
Example:
|
||||
|
||||
fsmc: flash@d1800000 {
|
||||
compatible = "st,spear600-fsmc-nand";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0xd1800000 0x1000 /* FSMC Register */
|
||||
0xd2000000 0x4000>; /* NAND Base */
|
||||
reg-names = "fsmc_regs", "nand_data";
|
||||
st,ale-off = <0x20000>;
|
||||
st,cle-off = <0x10000>;
|
||||
|
||||
bank-width = <1>;
|
||||
nand-skip-bbtscan;
|
||||
|
||||
partition@0 {
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
@ -25,6 +25,9 @@ Optional properties:
|
|||
GPIO state and before and after command byte writes, this register will be
|
||||
read to ensure that the GPIO accesses have completed.
|
||||
|
||||
The device tree may optionally contain sub-nodes describing partitions of the
|
||||
address space. See partition.txt for more detail.
|
||||
|
||||
Examples:
|
||||
|
||||
gpio-nand@1,0 {
|
||||
|
|
|
|||
|
|
@ -23,27 +23,8 @@ are defined:
|
|||
- vendor-id : Contains the flash chip's vendor id (1 byte).
|
||||
- device-id : Contains the flash chip's device id (1 byte).
|
||||
|
||||
In addition to the information on the mtd bank itself, the
|
||||
device tree may optionally contain additional information
|
||||
describing partitions of the address space. This can be
|
||||
used on platforms which have strong conventions about which
|
||||
portions of a flash are used for what purposes, but which don't
|
||||
use an on-flash partition table such as RedBoot.
|
||||
|
||||
Each partition is represented as a sub-node of the mtd device.
|
||||
Each node's name represents the name of the corresponding
|
||||
partition of the mtd device.
|
||||
|
||||
Flash partitions
|
||||
- reg : The partition's offset and size within the mtd bank.
|
||||
- label : (optional) The label / name for this partition.
|
||||
If omitted, the label is taken from the node name (excluding
|
||||
the unit address).
|
||||
- read-only : (optional) This parameter, if present, is a hint to
|
||||
Linux that this partition should only be mounted
|
||||
read-only. This is usually used for flash partitions
|
||||
containing early-boot firmware images or data which should not
|
||||
be clobbered.
|
||||
The device tree may optionally contain sub-nodes describing partitions of the
|
||||
address space. See partition.txt for more detail.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,7 @@
|
|||
* MTD generic binding
|
||||
|
||||
- nand-ecc-mode : String, operation mode of the NAND ecc mode.
|
||||
Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
|
||||
"soft_bch".
|
||||
- nand-bus-width : 8 or 16 bus width if not present 8
|
||||
- nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
Representing flash partitions in devicetree
|
||||
|
||||
Partitions can be represented by sub-nodes of an mtd device. This can be used
|
||||
on platforms which have strong conventions about which portions of a flash are
|
||||
used for what purposes, but which don't use an on-flash partition table such
|
||||
as RedBoot.
|
||||
|
||||
#address-cells & #size-cells must both be present in the mtd device and be
|
||||
equal to 1.
|
||||
|
||||
Required properties:
|
||||
- reg : The partition's offset and size within the mtd bank.
|
||||
|
||||
Optional properties:
|
||||
- label : The label / name for this partition. If omitted, the label is taken
|
||||
from the node name (excluding the unit address).
|
||||
- read-only : This parameter, if present, is a hint to Linux that this
|
||||
partition should only be mounted read-only. This is usually used for flash
|
||||
partitions containing early-boot firmware images or data which should not be
|
||||
clobbered.
|
||||
|
||||
Examples:
|
||||
|
||||
|
||||
flash@0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
partition@0 {
|
||||
label = "u-boot";
|
||||
reg = <0x0000000 0x100000>;
|
||||
read-only;
|
||||
};
|
||||
|
||||
uimage@100000 {
|
||||
reg = <0x0100000 0x200000>;
|
||||
};
|
||||
];
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
* SPEAr SMI
|
||||
|
||||
Required properties:
|
||||
- compatible : "st,spear600-smi"
|
||||
- reg : Address range of the mtd chip
|
||||
- #address-cells, #size-cells : Must be present if the device has sub-nodes
|
||||
representing partitions.
|
||||
- interrupt-parent: Should be the phandle for the interrupt controller
|
||||
that services interrupts for this device
|
||||
- interrupts: Should contain the STMMAC interrupts
|
||||
- clock-rate : Functional clock rate of SMI in Hz
|
||||
|
||||
Optional properties:
|
||||
- st,smi-fast-mode : Flash supports read in fast mode
|
||||
|
||||
Example:
|
||||
|
||||
smi: flash@fc000000 {
|
||||
compatible = "st,spear600-smi";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0xfc000000 0x1000>;
|
||||
interrupt-parent = <&vic1>;
|
||||
interrupts = <12>;
|
||||
clock-rate = <50000000>; /* 50MHz */
|
||||
|
||||
flash@f8000000 {
|
||||
st,smi-fast-mode;
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
* STMicroelectronics 10/100/1000 Ethernet driver (GMAC)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "st,spear600-gmac"
|
||||
- reg: Address and length of the register set for the device
|
||||
- interrupt-parent: Should be the phandle for the interrupt controller
|
||||
that services interrupts for this device
|
||||
- interrupts: Should contain the STMMAC interrupts
|
||||
- interrupt-names: Should contain the interrupt names "macirq"
|
||||
"eth_wake_irq" if this interrupt is supported in the "interrupts"
|
||||
property
|
||||
- phy-mode: String, operation mode of the PHY interface.
|
||||
Supported values are: "mii", "rmii", "gmii", "rgmii".
|
||||
|
||||
Optional properties:
|
||||
- mac-address: 6 bytes, mac address
|
||||
|
||||
Examples:
|
||||
|
||||
gmac0: ethernet@e0800000 {
|
||||
compatible = "st,spear600-gmac";
|
||||
reg = <0xe0800000 0x8000>;
|
||||
interrupt-parent = <&vic1>;
|
||||
interrupts = <24 23>;
|
||||
interrupt-names = "macirq", "eth_wake_irq";
|
||||
mac-address = [000000000000]; /* Filled in by U-Boot */
|
||||
phy-mode = "gmii";
|
||||
};
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
max17042_battery
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Required properties :
|
||||
- compatible : "maxim,max17042"
|
||||
|
||||
Optional properties :
|
||||
- maxim,rsns-microohm : Resistance of rsns resistor in micro Ohms
|
||||
(datasheet-recommended value is 10000).
|
||||
Defining this property enables current-sense functionality.
|
||||
|
||||
Example:
|
||||
|
||||
battery-charger@36 {
|
||||
compatible = "maxim,max17042";
|
||||
reg = <0x36>;
|
||||
maxim,rsns-microohm = <10000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,63 @@
|
|||
* FSL MPIC Message Registers
|
||||
|
||||
This binding specifies what properties must be available in the device tree
|
||||
representation of the message register blocks found in some FSL MPIC
|
||||
implementations.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Specifies the compatibility list for the message register
|
||||
block. The type shall be <string-list> and the value shall be of the form
|
||||
"fsl,mpic-v<version>-msgr", where <version> is the version number of
|
||||
the MPIC containing the message registers.
|
||||
|
||||
- reg: Specifies the base physical address(s) and size(s) of the
|
||||
message register block's addressable register space. The type shall be
|
||||
<prop-encoded-array>.
|
||||
|
||||
- interrupts: Specifies a list of interrupt-specifiers which are available
|
||||
for receiving interrupts. Interrupt-specifier consists of two cells: first
|
||||
cell is interrupt-number and second cell is level-sense. The type shall be
|
||||
<prop-encoded-array>.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- mpic-msgr-receive-mask: Specifies what registers in the containing block
|
||||
are allowed to receive interrupts. The value is a bit mask where a set
|
||||
bit at bit 'n' indicates that message register 'n' can receive interrupts.
|
||||
Note that "bit 'n'" is numbered from LSB for PPC hardware. The type shall
|
||||
be <u32>. If not present, then all of the message registers in the block
|
||||
are available.
|
||||
|
||||
Aliases:
|
||||
|
||||
An alias should be created for every message register block. They are not
|
||||
required, though. However, a particular implementation of this binding
|
||||
may require aliases to be present. Aliases are of the form
|
||||
'mpic-msgr-block<n>', where <n> is an integer specifying the block's number.
|
||||
Numbers shall start at 0.
|
||||
|
||||
Example:
|
||||
|
||||
aliases {
|
||||
mpic-msgr-block0 = &mpic_msgr_block0;
|
||||
mpic-msgr-block1 = &mpic_msgr_block1;
|
||||
};
|
||||
|
||||
mpic_msgr_block0: mpic-msgr-block@41400 {
|
||||
compatible = "fsl,mpic-v3.1-msgr";
|
||||
reg = <0x41400 0x200>;
|
||||
// Message registers 0 and 2 in this block can receive interrupts on
|
||||
// sources 0xb0 and 0xb2, respectively.
|
||||
interrupts = <0xb0 2 0xb2 2>;
|
||||
mpic-msgr-receive-mask = <0x5>;
|
||||
};
|
||||
|
||||
mpic_msgr_block1: mpic-msgr-block@42400 {
|
||||
compatible = "fsl,mpic-v3.1-msgr";
|
||||
reg = <0x42400 0x200>;
|
||||
// Message registers 0 and 2 in this block can receive interrupts on
|
||||
// sources 0xb4 and 0xb6, respectively.
|
||||
interrupts = <0xb4 2 0xb6 2>;
|
||||
mpic-msgr-receive-mask = <0x5>;
|
||||
};
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue