Merge branch 'linus' into perf/urgent
Merge reason: we need to fix a non-trivial merge conflict. Signed-off-by: Ingo Molnar <mingo@elte.hu>
This commit is contained in:
Ingo Molnar
commit
7fd52392c5
|
|
@ -7,8 +7,8 @@ Please try and keep the descriptions small enough to fit on one line.
|
|||
|
||||
Following translations are available on the WWW:
|
||||
|
||||
- Japanese, maintained by the JF Project (JF@linux.or.jp), at
|
||||
http://www.linux.or.jp/JF/
|
||||
- Japanese, maintained by the JF Project (jf@listserv.linux.or.jp), at
|
||||
http://linuxjf.sourceforge.jp/
|
||||
|
||||
00-INDEX
|
||||
- this file.
|
||||
|
|
@ -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/
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Date: 09-Jul-2007
|
|||
KernelVersion v2.6.22
|
||||
Contact: linux-wireless@vger.kernel.org
|
||||
Description: Current state of the transmitter.
|
||||
This file is deprecated and sheduled to be removed in 2014,
|
||||
This file is deprecated and scheduled to be removed in 2014,
|
||||
because its not possible to express the 'soft and hard block'
|
||||
state of the rfkill driver.
|
||||
Values: A numeric value.
|
||||
|
|
|
|||
|
|
@ -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,7 +53,7 @@ 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
|
||||
device is to be automatically aborted if there is any error.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Description:
|
|||
The name of the module that is in the kernel. This
|
||||
module name will show up either if the module is built
|
||||
directly into the kernel, or if it is loaded as a
|
||||
dyanmic module.
|
||||
dynamic module.
|
||||
|
||||
/sys/module/MODULENAME/parameters
|
||||
This directory contains individual files that are each
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -387,7 +387,7 @@ an example.
|
|||
<title>See also</title>
|
||||
<para>
|
||||
<citation>
|
||||
<ulink url="ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/journal-design.ps.gz">
|
||||
<ulink url="http://kernel.org/pub/linux/kernel/people/sct/ext3/journal-design.ps.gz">
|
||||
Journaling the Linux ext2fs Filesystem, LinuxExpo 98, Stephen Tweedie
|
||||
</ulink>
|
||||
</citation>
|
||||
|
|
|
|||
|
|
@ -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">
|
||||
|
|
|
|||
|
|
@ -22,8 +22,8 @@
|
|||
<para>
|
||||
The contents of this file are subject to the Open
|
||||
Software License version 1.1 that can be found at
|
||||
<ulink url="http://www.opensource.org/licenses/osl-1.1.txt">http://www.opensource.org/licenses/osl-1.1.txt</ulink> and is included herein
|
||||
by reference.
|
||||
<ulink url="http://fedoraproject.org/wiki/Licensing:OSL1.1">http://fedoraproject.org/wiki/Licensing:OSL1.1</ulink>
|
||||
and is included herein by reference.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -945,7 +945,7 @@ and other resources, etc.
|
|||
|
||||
<listitem>
|
||||
<para>
|
||||
!BSY && ERR after CDB tranfer starts but before the
|
||||
!BSY && ERR after CDB transfer starts but before the
|
||||
last byte of CDB is transferred. ATA/ATAPI standard states
|
||||
that "The device shall not terminate the PACKET command
|
||||
with an error before the last byte of the command packet has
|
||||
|
|
@ -1050,7 +1050,7 @@ and other resources, etc.
|
|||
to complete a command. Combined with the fact that MWDMA
|
||||
and PIO transfer errors aren't allowed to use ICRC bit up to
|
||||
ATA/ATAPI-7, it seems to imply that ABRT bit alone could
|
||||
indicate tranfer errors.
|
||||
indicate transfer errors.
|
||||
</para>
|
||||
<para>
|
||||
However, ATA/ATAPI-8 draft revision 1f removes the part
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -444,7 +444,7 @@ linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_BGR24</constant></link></para></entr
|
|||
<entry><para><link
|
||||
linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_BGR32</constant></link><footnote>
|
||||
<para>Presumably all V4L RGB formats are
|
||||
little-endian, although some drivers might interpret them according to machine endianess. V4L2 defines little-endian, big-endian and red/blue
|
||||
little-endian, although some drivers might interpret them according to machine endianness. V4L2 defines little-endian, big-endian and red/blue
|
||||
swapped variants. For details see <xref linkend="pixfmt-rgb" />.</para>
|
||||
</footnote></para></entry>
|
||||
</row>
|
||||
|
|
@ -823,7 +823,7 @@ standard); 35468950 Hz PAL and SECAM (625-line standards)</entry>
|
|||
<row>
|
||||
<entry>sample_format</entry>
|
||||
<entry>V4L2_PIX_FMT_GREY. The last four bytes (a
|
||||
machine endianess integer) contain a frame counter.</entry>
|
||||
machine endianness integer) contain a frame counter.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start[]</entry>
|
||||
|
|
@ -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.
|
||||
|
|
@ -25,7 +25,7 @@ inline (either in the code emitted directly by the compiler, or part of
|
|||
the implementation of a library call) when optimizing for a recent enough
|
||||
processor that has the necessary native support, but only if resulting
|
||||
binaries are already to be incompatible with earlier ARM processors due to
|
||||
useage of similar native instructions for other things. In other words
|
||||
usage of similar native instructions for other things. In other words
|
||||
don't make binaries unable to run on earlier processors just for the sake
|
||||
of not using these kernel helpers if your compiled code is not going to
|
||||
use new instructions for other purpose.
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
},
|
||||
};
|
||||
|
|
@ -94,11 +94,11 @@ Throttling/Upper Limit policy
|
|||
|
||||
Hierarchical Cgroups
|
||||
====================
|
||||
- Currently none of the IO control policy supports hierarhical groups. But
|
||||
cgroup interface does allow creation of hierarhical cgroups and internally
|
||||
- Currently none of the IO control policy supports hierarchical groups. But
|
||||
cgroup interface does allow creation of hierarchical cgroups and internally
|
||||
IO policies treat them as flat hierarchy.
|
||||
|
||||
So this patch will allow creation of cgroup hierarhcy but at the backend
|
||||
So this patch will allow creation of cgroup hierarchcy but at the backend
|
||||
everything will be treated as flat. So if somebody created a hierarchy like
|
||||
as follows.
|
||||
|
||||
|
|
@ -266,7 +266,7 @@ Proportional weight policy files
|
|||
- blkio.idle_time
|
||||
- Debugging aid only enabled if CONFIG_DEBUG_BLK_CGROUP=y.
|
||||
This is the amount of time spent by the IO scheduler idling for a
|
||||
given cgroup in anticipation of a better request than the exising ones
|
||||
given cgroup in anticipation of a better request than the existing ones
|
||||
from other queues/cgroups. This is in nanoseconds. If this is read
|
||||
when the cgroup is in an idling state, the stat will only report the
|
||||
idle_time accumulated till the last idle period and will not include
|
||||
|
|
@ -283,34 +283,34 @@ Throttling/Upper limit policy files
|
|||
-----------------------------------
|
||||
- blkio.throttle.read_bps_device
|
||||
- Specifies upper limit on READ rate from the device. IO rate is
|
||||
specified in bytes per second. Rules are per deivce. Following is
|
||||
specified in bytes per second. Rules are per device. Following is
|
||||
the format.
|
||||
|
||||
echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.throttle.read_bps_device
|
||||
|
||||
- blkio.throttle.write_bps_device
|
||||
- Specifies upper limit on WRITE rate to the device. IO rate is
|
||||
specified in bytes per second. Rules are per deivce. Following is
|
||||
specified in bytes per second. Rules are per device. Following is
|
||||
the format.
|
||||
|
||||
echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.throttle.write_bps_device
|
||||
|
||||
- blkio.throttle.read_iops_device
|
||||
- Specifies upper limit on READ rate from the device. IO rate is
|
||||
specified in IO per second. Rules are per deivce. Following is
|
||||
specified in IO per second. Rules are per device. Following is
|
||||
the format.
|
||||
|
||||
echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.throttle.read_iops_device
|
||||
|
||||
- blkio.throttle.write_iops_device
|
||||
- Specifies upper limit on WRITE rate to the device. IO rate is
|
||||
specified in io per second. Rules are per deivce. Following is
|
||||
specified in io per second. Rules are per device. Following is
|
||||
the format.
|
||||
|
||||
echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.throttle.write_iops_device
|
||||
|
||||
Note: If both BW and IOPS rules are specified for a device, then IO is
|
||||
subjectd to both the constraints.
|
||||
subjected to both the constraints.
|
||||
|
||||
- blkio.throttle.io_serviced
|
||||
- Number of IOs (bio) completed to/from the disk by the group (as
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -28,7 +28,7 @@ The target is named "raid" and it accepts the following parameters:
|
|||
raid6_nc RAID6 N continue
|
||||
- rotating parity N (right-to-left) with data continuation
|
||||
|
||||
Refererence: Chapter 4 of
|
||||
Reference: Chapter 4 of
|
||||
http://www.snia.org/sites/default/files/SNIA_DDF_Technical_Position_v2.0.pdf
|
||||
|
||||
<#raid_params>: The number of parameters that follow.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Introduction
|
|||
|
||||
The more-sophisticated device-mapper targets require complex metadata
|
||||
that is managed in kernel. In late 2010 we were seeing that various
|
||||
different targets were rolling their own data strutures, for example:
|
||||
different targets were rolling their own data structures, for example:
|
||||
|
||||
- Mikulas Patocka's multisnap implementation
|
||||
- Heinz Mauelshagen's thin provisioning target
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
Introduction
|
||||
============
|
||||
|
||||
This document descibes a collection of device-mapper targets that
|
||||
This document describes a collection of device-mapper targets that
|
||||
between them implement thin-provisioning and snapshots.
|
||||
|
||||
The main highlight of this implementation, compared to the previous
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -5,7 +5,7 @@ IPs present in the SoC.
|
|||
On top of that an omap_device is created to extend the platform_device
|
||||
capabilities and to allow binding with one or several hwmods.
|
||||
The hwmods will contain all the information to build the device:
|
||||
adresse range, irq lines, dma lines, interconnect, PRCM register,
|
||||
address range, irq lines, dma lines, interconnect, PRCM register,
|
||||
clock domain, input clocks.
|
||||
For the moment just point to the existing hwmod, the next step will be
|
||||
to move data from hwmod to device-tree representation.
|
||||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
prima2 "cb" evalutation board
|
||||
prima2 "cb" evaluation board
|
||||
Required root node properties:
|
||||
- compatible = "sirf,prima2-cb", "sirf,prima2";
|
||||
|
|
|
|||
|
|
@ -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,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,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>;
|
||||
};
|
||||
|
|
@ -56,7 +56,27 @@ PROPERTIES
|
|||
to the client. The presence of this property also mandates
|
||||
that any initialization related to interrupt sources shall
|
||||
be limited to sources explicitly referenced in the device tree.
|
||||
|
||||
|
||||
- big-endian
|
||||
Usage: optional
|
||||
Value type: <empty>
|
||||
If present the MPIC will be assumed to be big-endian. Some
|
||||
device-trees omit this property on MPIC nodes even when the MPIC is
|
||||
in fact big-endian, so certain boards override this property.
|
||||
|
||||
- single-cpu-affinity
|
||||
Usage: optional
|
||||
Value type: <empty>
|
||||
If present the MPIC will be assumed to only be able to route
|
||||
non-IPI interrupts to a single CPU at a time (EG: Freescale MPIC).
|
||||
|
||||
- last-interrupt-source
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Some MPICs do not correctly report the number of hardware sources
|
||||
in the global feature registers. If specified, this field will
|
||||
override the value read from MPIC_GREG_FEATURE_LAST_SRC.
|
||||
|
||||
INTERRUPT SPECIFIER DEFINITION
|
||||
|
||||
Interrupt specifiers consists of 4 cells encoded as
|
||||
|
|
|
|||
|
|
@ -6,8 +6,10 @@ Required properties:
|
|||
etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on
|
||||
the parent type.
|
||||
|
||||
- reg : should contain the address and the length of the shared message
|
||||
interrupt register set.
|
||||
- reg : It may contain one or two regions. The first region should contain
|
||||
the address and the length of the shared message interrupt register set.
|
||||
The second region should contain the address of aliased MSIIR register for
|
||||
platforms that have such an alias.
|
||||
|
||||
- msi-available-ranges: use <start count> style section to define which
|
||||
msi interrupt can be used in the 256 msi interrupts. This property is
|
||||
|
|
|
|||
|
|
@ -0,0 +1,68 @@
|
|||
TWL family of regulators
|
||||
|
||||
Required properties:
|
||||
For twl6030 regulators/LDOs
|
||||
- compatible:
|
||||
- "ti,twl6030-vaux1" for VAUX1 LDO
|
||||
- "ti,twl6030-vaux2" for VAUX2 LDO
|
||||
- "ti,twl6030-vaux3" for VAUX3 LDO
|
||||
- "ti,twl6030-vmmc" for VMMC LDO
|
||||
- "ti,twl6030-vpp" for VPP LDO
|
||||
- "ti,twl6030-vusim" for VUSIM LDO
|
||||
- "ti,twl6030-vana" for VANA LDO
|
||||
- "ti,twl6030-vcxio" for VCXIO LDO
|
||||
- "ti,twl6030-vdac" for VDAC LDO
|
||||
- "ti,twl6030-vusb" for VUSB LDO
|
||||
- "ti,twl6030-v1v8" for V1V8 LDO
|
||||
- "ti,twl6030-v2v1" for V2V1 LDO
|
||||
- "ti,twl6030-clk32kg" for CLK32KG RESOURCE
|
||||
- "ti,twl6030-vdd1" for VDD1 SMPS
|
||||
- "ti,twl6030-vdd2" for VDD2 SMPS
|
||||
- "ti,twl6030-vdd3" for VDD3 SMPS
|
||||
For twl6025 regulators/LDOs
|
||||
- compatible:
|
||||
- "ti,twl6025-ldo1" for LDO1 LDO
|
||||
- "ti,twl6025-ldo2" for LDO2 LDO
|
||||
- "ti,twl6025-ldo3" for LDO3 LDO
|
||||
- "ti,twl6025-ldo4" for LDO4 LDO
|
||||
- "ti,twl6025-ldo5" for LDO5 LDO
|
||||
- "ti,twl6025-ldo6" for LDO6 LDO
|
||||
- "ti,twl6025-ldo7" for LDO7 LDO
|
||||
- "ti,twl6025-ldoln" for LDOLN LDO
|
||||
- "ti,twl6025-ldousb" for LDOUSB LDO
|
||||
- "ti,twl6025-smps3" for SMPS3 SMPS
|
||||
- "ti,twl6025-smps4" for SMPS4 SMPS
|
||||
- "ti,twl6025-vio" for VIO SMPS
|
||||
For twl4030 regulators/LDOs
|
||||
- compatible:
|
||||
- "ti,twl4030-vaux1" for VAUX1 LDO
|
||||
- "ti,twl4030-vaux2" for VAUX2 LDO
|
||||
- "ti,twl5030-vaux2" for VAUX2 LDO
|
||||
- "ti,twl4030-vaux3" for VAUX3 LDO
|
||||
- "ti,twl4030-vaux4" for VAUX4 LDO
|
||||
- "ti,twl4030-vmmc1" for VMMC1 LDO
|
||||
- "ti,twl4030-vmmc2" for VMMC2 LDO
|
||||
- "ti,twl4030-vpll1" for VPLL1 LDO
|
||||
- "ti,twl4030-vpll2" for VPLL2 LDO
|
||||
- "ti,twl4030-vsim" for VSIM LDO
|
||||
- "ti,twl4030-vdac" for VDAC LDO
|
||||
- "ti,twl4030-vintana2" for VINTANA2 LDO
|
||||
- "ti,twl4030-vio" for VIO LDO
|
||||
- "ti,twl4030-vdd1" for VDD1 SMPS
|
||||
- "ti,twl4030-vdd2" for VDD2 SMPS
|
||||
- "ti,twl4030-vintana1" for VINTANA1 LDO
|
||||
- "ti,twl4030-vintdig" for VINTDIG LDO
|
||||
- "ti,twl4030-vusb1v5" for VUSB1V5 LDO
|
||||
- "ti,twl4030-vusb1v8" for VUSB1V8 LDO
|
||||
- "ti,twl4030-vusb3v1" for VUSB3V1 LDO
|
||||
|
||||
Optional properties:
|
||||
- Any optional property defined in bindings/regulator/regulator.txt
|
||||
|
||||
Example:
|
||||
|
||||
xyz: regulator@0 {
|
||||
compatible = "ti,twl6030-vaux1";
|
||||
regulator-min-microvolt = <1000000>;
|
||||
regulator-max-microvolt = <3000000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
ALC5632 audio CODEC
|
||||
|
||||
This device supports I2C only.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "realtek,alc5632"
|
||||
|
||||
- reg : the I2C address of the device.
|
||||
|
||||
- gpio-controller : Indicates this device is a GPIO controller.
|
||||
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and the
|
||||
second cell is used to specify optional parameters (currently unused).
|
||||
|
||||
Example:
|
||||
|
||||
alc5632: alc5632@1e {
|
||||
compatible = "realtek,alc5632";
|
||||
reg = <0x1a>;
|
||||
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
Freescale Digital Audio Mux (AUDMUX) device
|
||||
|
||||
Required properties:
|
||||
- compatible : "fsl,imx21-audmux" for AUDMUX version firstly used on i.MX21,
|
||||
or "fsl,imx31-audmux" for the version firstly used on i.MX31.
|
||||
- reg : Should contain AUDMUX registers location and length
|
||||
|
||||
Example:
|
||||
|
||||
audmux@021d8000 {
|
||||
compatible = "fsl,imx6q-audmux", "fsl,imx31-audmux";
|
||||
reg = <0x021d8000 0x4000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
NVIDIA Tegra audio complex
|
||||
|
||||
Required properties:
|
||||
- compatible : "nvidia,tegra-audio-alc5632"
|
||||
- nvidia,model : The user-visible name of this sound complex.
|
||||
- nvidia,audio-routing : A list of the connections between audio components.
|
||||
Each entry is a pair of strings, the first being the connection's sink,
|
||||
the second being the connection's source. Valid names for sources and
|
||||
sinks are the ALC5632's pins:
|
||||
|
||||
ALC5632 pins:
|
||||
|
||||
* SPK_OUTP
|
||||
* SPK_OUTN
|
||||
* HP_OUT_L
|
||||
* HP_OUT_R
|
||||
* AUX_OUT_P
|
||||
* AUX_OUT_N
|
||||
* LINE_IN_L
|
||||
* LINE_IN_R
|
||||
* PHONE_P
|
||||
* PHONE_N
|
||||
* MIC1_P
|
||||
* MIC1_N
|
||||
* MIC2_P
|
||||
* MIC2_N
|
||||
* MICBIAS1
|
||||
* DMICDAT
|
||||
|
||||
Board connectors:
|
||||
|
||||
* Headset Stereophone
|
||||
* Int Spk
|
||||
* Headset Mic
|
||||
* Digital Mic
|
||||
|
||||
- nvidia,i2s-controller : The phandle of the Tegra I2S controller
|
||||
- nvidia,audio-codec : The phandle of the ALC5632 audio codec
|
||||
|
||||
Example:
|
||||
|
||||
sound {
|
||||
compatible = "nvidia,tegra-audio-alc5632-paz00",
|
||||
"nvidia,tegra-audio-alc5632";
|
||||
|
||||
nvidia,model = "Compal PAZ00";
|
||||
|
||||
nvidia,audio-routing =
|
||||
"Int Spk", "SPK_OUTP",
|
||||
"Int Spk", "SPK_OUTN",
|
||||
"Headset Mic","MICBIAS1",
|
||||
"MIC1_N", "Headset Mic",
|
||||
"MIC1_P", "Headset Mic",
|
||||
"Headset Stereophone", "HP_OUT_R",
|
||||
"Headset Stereophone", "HP_OUT_L";
|
||||
|
||||
nvidia,i2s-controller = <&tegra_i2s1>;
|
||||
nvidia,audio-codec = <&alc5632>;
|
||||
};
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
OMAP2+ McSPI device
|
||||
|
||||
Required properties:
|
||||
- compatible :
|
||||
- "ti,omap2-spi" for OMAP2 & OMAP3.
|
||||
- "ti,omap4-spi" for OMAP4+.
|
||||
- ti,spi-num-cs : Number of chipselect supported by the instance.
|
||||
- ti,hwmods: Name of the hwmod associated to the McSPI
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
mcspi1: mcspi@1 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
compatible = "ti,omap4-mcspi";
|
||||
ti,hwmods = "mcspi1";
|
||||
ti,spi-num-cs = <4>;
|
||||
};
|
||||
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
* Energymicro efm32 UART
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "efm32,uart"
|
||||
- reg : Address and length of the register set
|
||||
- interrupts : Should contain uart interrupt
|
||||
|
||||
Example:
|
||||
|
||||
uart@0x4000c400 {
|
||||
compatible = "efm32,uart";
|
||||
reg = <0x4000c400 0x400>;
|
||||
interrupts = <15>;
|
||||
};
|
||||
|
|
@ -34,6 +34,7 @@ picochip Picochip Ltd
|
|||
powervr Imagination Technologies
|
||||
qcom Qualcomm, Inc.
|
||||
ramtron Ramtron International
|
||||
realtek Realtek Semiconductor Corp.
|
||||
samsung Samsung Semiconductor
|
||||
sbs Smart Battery System
|
||||
schindler Schindler
|
||||
|
|
|
|||
|
|
@ -169,7 +169,7 @@ it with special cases.
|
|||
|
||||
b) Entry with a flattened device-tree block. Firmware loads the
|
||||
physical address of the flattened device tree block (dtb) into r2,
|
||||
r1 is not used, but it is considered good practise to use a valid
|
||||
r1 is not used, but it is considered good practice to use a valid
|
||||
machine number as described in Documentation/arm/Booting.
|
||||
|
||||
r0 : 0
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ The slave DMA usage consists of following steps:
|
|||
struct dma_slave_config *config)
|
||||
|
||||
Please see the dma_slave_config structure definition in dmaengine.h
|
||||
for a detailed explaination of the struct members. Please note
|
||||
for a detailed explanation of the struct members. Please note
|
||||
that the 'direction' member will be going away as it duplicates the
|
||||
direction given in the prepare call.
|
||||
|
||||
|
|
|
|||
|
|
@ -271,3 +271,8 @@ IOMAP
|
|||
pcim_iounmap()
|
||||
pcim_iomap_table() : array of mapped addresses indexed by BAR
|
||||
pcim_iomap_regions() : do request_region() and iomap() on multiple BARs
|
||||
|
||||
REGULATOR
|
||||
devm_regulator_get()
|
||||
devm_regulator_put()
|
||||
devm_regulator_bulk_get()
|
||||
|
|
|
|||
|
|
@ -119,4 +119,5 @@ o Cards based on the Phillips saa7134 PCI bridge:
|
|||
- Compro Videomate DVB-T300
|
||||
- Compro Videomate DVB-T200
|
||||
- AVerMedia AVerTVHD MCE A180
|
||||
- KWorld PC150-U ATSC Hybrid
|
||||
|
||||
|
|
|
|||
|
|
@ -66,5 +66,16 @@ dd if=US290D.sys ibs=1 skip=36856 count=3976 of=dvb-usb-lme2510-s0194.fw
|
|||
For LME2510C
|
||||
dd if=US290D.sys ibs=1 skip=33152 count=3697 of=dvb-usb-lme2510c-s0194.fw
|
||||
|
||||
---------------------------------------------------------------------
|
||||
|
||||
The m88rs2000 tuner driver can be found in windows/system32/drivers
|
||||
|
||||
US2B0D.sys (dated 29 Jun 2010)
|
||||
|
||||
dd if=US2B0D.sys ibs=1 skip=34432 count=3871 of=dvb-usb-lme2510c-rs2000.fw
|
||||
|
||||
We need to modify id of rs2000 firmware or it will warm boot id 3344:1120.
|
||||
|
||||
echo -ne \\xF0\\x22 | dd conv=notrunc bs=1 count=2 seek=266 of=dvb-usb-lme2510c-rs2000.fw
|
||||
|
||||
Copy the firmware file(s) to /lib/firmware
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ dynamically enabled per-callsite.
|
|||
Dynamic debug has even more useful features:
|
||||
|
||||
* Simple query language allows turning on and off debugging statements by
|
||||
matching any combination of:
|
||||
matching any combination of 0 or 1 of:
|
||||
|
||||
- source filename
|
||||
- function name
|
||||
|
|
@ -79,31 +79,24 @@ Command Language Reference
|
|||
==========================
|
||||
|
||||
At the lexical level, a command comprises a sequence of words separated
|
||||
by whitespace characters. Note that newlines are treated as word
|
||||
separators and do *not* end a command or allow multiple commands to
|
||||
be done together. So these are all equivalent:
|
||||
by spaces or tabs. So these are all equivalent:
|
||||
|
||||
nullarbor:~ # echo -c 'file svcsock.c line 1603 +p' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
nullarbor:~ # echo -c ' file svcsock.c line 1603 +p ' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
nullarbor:~ # echo -c 'file svcsock.c\nline 1603 +p' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
|
||||
Commands are bounded by a write() system call. If you want to do
|
||||
multiple commands you need to do a separate "echo" for each, like:
|
||||
Command submissions are bounded by a write() system call.
|
||||
Multiple commands can be written together, separated by ';' or '\n'.
|
||||
|
||||
nullarbor:~ # echo 'file svcsock.c line 1603 +p' > /proc/dprintk ;\
|
||||
> echo 'file svcsock.c line 1563 +p' > /proc/dprintk
|
||||
~# echo "func pnpacpi_get_resources +p; func pnp_assign_mem +p" \
|
||||
> <debugfs>/dynamic_debug/control
|
||||
|
||||
or even like:
|
||||
If your query set is big, you can batch them too:
|
||||
|
||||
nullarbor:~ # (
|
||||
> echo 'file svcsock.c line 1603 +p' ;\
|
||||
> echo 'file svcsock.c line 1563 +p' ;\
|
||||
> ) > /proc/dprintk
|
||||
~# cat query-batch-file > <debugfs>/dynamic_debug/control
|
||||
|
||||
At the syntactical level, a command comprises a sequence of match
|
||||
specifications, followed by a flags change specification.
|
||||
|
|
@ -144,11 +137,12 @@ func
|
|||
func svc_tcp_accept
|
||||
|
||||
file
|
||||
The given string is compared against either the full
|
||||
pathname or the basename of the source file of each
|
||||
callsite. Examples:
|
||||
The given string is compared against either the full pathname, the
|
||||
src-root relative pathname, or the basename of the source file of
|
||||
each callsite. Examples:
|
||||
|
||||
file svcsock.c
|
||||
file kernel/freezer.c
|
||||
file /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c
|
||||
|
||||
module
|
||||
|
|
|
|||
|
|
@ -334,8 +334,8 @@ Sdram memory scrubbing rate:
|
|||
|
||||
Reading the file will return the actual scrubbing rate employed.
|
||||
|
||||
If configuration fails or memory scrubbing is not implemented, the value
|
||||
of the attribute file will be -1.
|
||||
If configuration fails or memory scrubbing is not implemented, accessing
|
||||
that attribute will fail.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -177,8 +177,8 @@ sgram - tells to driver that you have Gxx0 with SGRAM memory. It has no
|
|||
effect without `init'.
|
||||
sdram - tells to driver that you have Gxx0 with SDRAM memory.
|
||||
It is a default.
|
||||
inv24 - change timings parameters for 24bpp modes on Millenium and
|
||||
Millenium II. Specify this if you see strange color shadows around
|
||||
inv24 - change timings parameters for 24bpp modes on Millennium and
|
||||
Millennium II. Specify this if you see strange color shadows around
|
||||
characters.
|
||||
noinv24 - use standard timings. It is the default.
|
||||
inverse - invert colors on screen (for LCD displays)
|
||||
|
|
@ -204,9 +204,9 @@ grayscale - enable grayscale summing. It works in PSEUDOCOLOR modes (text,
|
|||
can paint colors.
|
||||
nograyscale - disable grayscale summing. It is default.
|
||||
cross4MB - enables that pixel line can cross 4MB boundary. It is default for
|
||||
non-Millenium.
|
||||
non-Millennium.
|
||||
nocross4MB - pixel line must not cross 4MB boundary. It is default for
|
||||
Millenium I or II, because of these devices have hardware
|
||||
Millennium I or II, because of these devices have hardware
|
||||
limitations which do not allow this. But this option is
|
||||
incompatible with some (if not all yet released) versions of
|
||||
XF86_FBDev.
|
||||
|
|
|
|||
|
|
@ -524,3 +524,22 @@ Files: arch/arm/mach-at91/at91cap9.c
|
|||
Why: The code is not actively maintained and platforms are now hard to find.
|
||||
Who: Nicolas Ferre <nicolas.ferre@atmel.com>
|
||||
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: Low Performance USB Block driver ("CONFIG_BLK_DEV_UB")
|
||||
When: 3.6
|
||||
Why: This driver provides support for USB storage devices like "USB
|
||||
sticks". As of now, it is deactivated in Debian, Fedora and
|
||||
Ubuntu. All current users can switch over to usb-storage
|
||||
(CONFIG_USB_STORAGE) which only drawback is the additional SCSI
|
||||
stack.
|
||||
Who: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: kmap_atomic(page, km_type)
|
||||
When: 3.5
|
||||
Why: The old kmap_atomic() with two arguments is deprecated, we only
|
||||
keep it for backward compatibility for few cycles and then drop it.
|
||||
Who: Cong Wang <amwang@redhat.com>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,10 @@ Debugfs is typically mounted with a command like:
|
|||
|
||||
mount -t debugfs none /sys/kernel/debug
|
||||
|
||||
(Or an equivalent /etc/fstab line).
|
||||
(Or an equivalent /etc/fstab line).
|
||||
The debugfs root directory is accessible by anyone by default. To
|
||||
restrict access to the tree the "uid", "gid" and "mode" mount
|
||||
options can be used.
|
||||
|
||||
Note that the debugfs API is exported GPL-only to modules.
|
||||
|
||||
|
|
@ -133,7 +136,7 @@ file.
|
|||
void __iomem *base;
|
||||
};
|
||||
|
||||
struct dentry *debugfs_create_regset32(const char *name, mode_t mode,
|
||||
struct dentry *debugfs_create_regset32(const char *name, umode_t mode,
|
||||
struct dentry *parent,
|
||||
struct debugfs_regset32 *regset);
|
||||
|
||||
|
|
|
|||
|
|
@ -308,7 +308,7 @@ min_batch_time=usec This parameter sets the commit time (as
|
|||
fast disks, at the cost of increasing latency.
|
||||
|
||||
journal_ioprio=prio The I/O priority (from 0 to 7, where 0 is the
|
||||
highest priorty) which should be used for I/O
|
||||
highest priority) which should be used for I/O
|
||||
operations submitted by kjournald2 during a
|
||||
commit operation. This defaults to 3, which is
|
||||
a slightly higher priority than the default I/O
|
||||
|
|
@ -343,7 +343,7 @@ noinit_itable Do not initialize any uninitialized inode table
|
|||
init_itable=n The lazy itable init code will wait n times the
|
||||
number of milliseconds it took to zero out the
|
||||
previous block group's inode table. This
|
||||
minimizes the impact on the systme performance
|
||||
minimizes the impact on the system performance
|
||||
while file system's inode table is being initialized.
|
||||
|
||||
discard Controls whether ext4 should issue discard/TRIM
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ be fixed.
|
|||
|
||||
The REMOVE uevent is generated at the end of an unsuccessful mount
|
||||
or at the end of a umount of the filesystem. All REMOVE uevents will
|
||||
have been preceded by at least an ADD uevent for the same fileystem,
|
||||
have been preceded by at least an ADD uevent for the same filesystem,
|
||||
and unlike the other uevents is generated automatically by the kernel's
|
||||
kobject subsystem.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,13 +4,21 @@ ID Mapper
|
|||
=========
|
||||
Id mapper is used by NFS to translate user and group ids into names, and to
|
||||
translate user and group names into ids. Part of this translation involves
|
||||
performing an upcall to userspace to request the information. Id mapper will
|
||||
user request-key to perform this upcall and cache the result. The program
|
||||
/usr/sbin/nfs.idmap should be called by request-key, and will perform the
|
||||
translation and initialize a key with the resulting information.
|
||||
performing an upcall to userspace to request the information. There are two
|
||||
ways NFS could obtain this information: placing a call to /sbin/request-key
|
||||
or by placing a call to the rpc.idmap daemon.
|
||||
|
||||
NFS will attempt to call /sbin/request-key first. If this succeeds, the
|
||||
result will be cached using the generic request-key cache. This call should
|
||||
only fail if /etc/request-key.conf is not configured for the id_resolver key
|
||||
type, see the "Configuring" section below if you wish to use the request-key
|
||||
method.
|
||||
|
||||
If the call to /sbin/request-key fails (if /etc/request-key.conf is not
|
||||
configured with the id_resolver key type), then the idmapper will ask the
|
||||
legacy rpc.idmap daemon for the id mapping. This result will be stored
|
||||
in a custom NFS idmap cache.
|
||||
|
||||
NFS_USE_NEW_IDMAPPER must be selected when configuring the kernel to use this
|
||||
feature.
|
||||
|
||||
===========
|
||||
Configuring
|
||||
|
|
|
|||
|
|
@ -53,3 +53,57 @@ lseg maintains an extra reference corresponding to the NFS_LSEG_VALID
|
|||
bit which holds it in the pnfs_layout_hdr's list. When the final lseg
|
||||
is removed from the pnfs_layout_hdr's list, the NFS_LAYOUT_DESTROYED
|
||||
bit is set, preventing any new lsegs from being added.
|
||||
|
||||
layout drivers
|
||||
--------------
|
||||
|
||||
PNFS utilizes what is called layout drivers. The STD defines 3 basic
|
||||
layout types: "files" "objects" and "blocks". For each of these types
|
||||
there is a layout-driver with a common function-vectors table which
|
||||
are called by the nfs-client pnfs-core to implement the different layout
|
||||
types.
|
||||
|
||||
Files-layout-driver code is in: fs/nfs/nfs4filelayout.c && nfs4filelayoutdev.c
|
||||
Objects-layout-deriver code is in: fs/nfs/objlayout/.. directory
|
||||
Blocks-layout-deriver code is in: fs/nfs/blocklayout/.. directory
|
||||
|
||||
objects-layout setup
|
||||
--------------------
|
||||
|
||||
As part of the full STD implementation the objlayoutdriver.ko needs, at times,
|
||||
to automatically login to yet undiscovered iscsi/osd devices. For this the
|
||||
driver makes up-calles to a user-mode script called *osd_login*
|
||||
|
||||
The path_name of the script to use is by default:
|
||||
/sbin/osd_login.
|
||||
This name can be overridden by the Kernel module parameter:
|
||||
objlayoutdriver.osd_login_prog
|
||||
|
||||
If Kernel does not find the osd_login_prog path it will zero it out
|
||||
and will not attempt farther logins. An admin can then write new value
|
||||
to the objlayoutdriver.osd_login_prog Kernel parameter to re-enable it.
|
||||
|
||||
The /sbin/osd_login is part of the nfs-utils package, and should usually
|
||||
be installed on distributions that support this Kernel version.
|
||||
|
||||
The API to the login script is as follows:
|
||||
Usage: $0 -u <URI> -o <OSDNAME> -s <SYSTEMID>
|
||||
Options:
|
||||
-u target uri e.g. iscsi://<ip>:<port>
|
||||
(allways exists)
|
||||
(More protocols can be defined in the future.
|
||||
The client does not interpret this string it is
|
||||
passed unchanged as recieved from the Server)
|
||||
-o osdname of the requested target OSD
|
||||
(Might be empty)
|
||||
(A string which denotes the OSD name, there is a
|
||||
limit of 64 chars on this string)
|
||||
-s systemid of the requested target OSD
|
||||
(Might be empty)
|
||||
(This string, if not empty is always an hex
|
||||
representation of the 20 bytes osd_system_id)
|
||||
|
||||
blocks-layout setup
|
||||
-------------------
|
||||
|
||||
TODO: Document the setup needs of the blocks layout driver
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Commands can be embedded into transaction command (which in turn has own command
|
|||
so one can extend protocol as needed without breaking backward compatibility as long
|
||||
as old commands are supported. All string lengths include tail 0 byte.
|
||||
|
||||
All commands are transferred over the network in big-endian. CPU endianess is used at the end peers.
|
||||
All commands are transferred over the network in big-endian. CPU endianness is used at the end peers.
|
||||
|
||||
@cmd - command number, which specifies command to be processed. Following
|
||||
commands are used currently:
|
||||
|
|
|
|||
|
|
@ -429,3 +429,9 @@ filemap_write_and_wait_range() so that all dirty pages are synced out properly.
|
|||
You must also keep in mind that ->fsync() is not called with i_mutex held
|
||||
anymore, so if you require i_mutex locking you must make sure to take it and
|
||||
release it yourself.
|
||||
|
||||
--
|
||||
[mandatory]
|
||||
d_alloc_root() is gone, along with a lot of bugs caused by code
|
||||
misusing it. Replacement: d_make_root(inode). The difference is,
|
||||
d_make_root() drops the reference to inode if dentry allocation fails.
|
||||
|
|
|
|||
|
|
@ -290,7 +290,7 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7)
|
|||
rsslim current limit in bytes on the rss
|
||||
start_code address above which program text can run
|
||||
end_code address below which program text can run
|
||||
start_stack address of the start of the stack
|
||||
start_stack address of the start of the main process stack
|
||||
esp current value of ESP
|
||||
eip current value of EIP
|
||||
pending bitmap of pending signals
|
||||
|
|
@ -325,7 +325,7 @@ address perms offset dev inode pathname
|
|||
a7cb1000-a7cb2000 ---p 00000000 00:00 0
|
||||
a7cb2000-a7eb2000 rw-p 00000000 00:00 0
|
||||
a7eb2000-a7eb3000 ---p 00000000 00:00 0
|
||||
a7eb3000-a7ed5000 rw-p 00000000 00:00 0
|
||||
a7eb3000-a7ed5000 rw-p 00000000 00:00 0 [stack:1001]
|
||||
a7ed5000-a8008000 r-xp 00000000 03:00 4222 /lib/libc.so.6
|
||||
a8008000-a800a000 r--p 00133000 03:00 4222 /lib/libc.so.6
|
||||
a800a000-a800b000 rw-p 00135000 03:00 4222 /lib/libc.so.6
|
||||
|
|
@ -357,11 +357,39 @@ is not associated with a file:
|
|||
|
||||
[heap] = the heap of the program
|
||||
[stack] = the stack of the main process
|
||||
[stack:1001] = the stack of the thread with tid 1001
|
||||
[vdso] = the "virtual dynamic shared object",
|
||||
the kernel system call handler
|
||||
|
||||
or if empty, the mapping is anonymous.
|
||||
|
||||
The /proc/PID/task/TID/maps is a view of the virtual memory from the viewpoint
|
||||
of the individual tasks of a process. In this file you will see a mapping marked
|
||||
as [stack] if that task sees it as a stack. This is a key difference from the
|
||||
content of /proc/PID/maps, where you will see all mappings that are being used
|
||||
as stack by all of those tasks. Hence, for the example above, the task-level
|
||||
map, i.e. /proc/PID/task/TID/maps for thread 1001 will look like this:
|
||||
|
||||
08048000-08049000 r-xp 00000000 03:00 8312 /opt/test
|
||||
08049000-0804a000 rw-p 00001000 03:00 8312 /opt/test
|
||||
0804a000-0806b000 rw-p 00000000 00:00 0 [heap]
|
||||
a7cb1000-a7cb2000 ---p 00000000 00:00 0
|
||||
a7cb2000-a7eb2000 rw-p 00000000 00:00 0
|
||||
a7eb2000-a7eb3000 ---p 00000000 00:00 0
|
||||
a7eb3000-a7ed5000 rw-p 00000000 00:00 0 [stack]
|
||||
a7ed5000-a8008000 r-xp 00000000 03:00 4222 /lib/libc.so.6
|
||||
a8008000-a800a000 r--p 00133000 03:00 4222 /lib/libc.so.6
|
||||
a800a000-a800b000 rw-p 00135000 03:00 4222 /lib/libc.so.6
|
||||
a800b000-a800e000 rw-p 00000000 00:00 0
|
||||
a800e000-a8022000 r-xp 00000000 03:00 14462 /lib/libpthread.so.0
|
||||
a8022000-a8023000 r--p 00013000 03:00 14462 /lib/libpthread.so.0
|
||||
a8023000-a8024000 rw-p 00014000 03:00 14462 /lib/libpthread.so.0
|
||||
a8024000-a8027000 rw-p 00000000 00:00 0
|
||||
a8027000-a8043000 r-xp 00000000 03:00 8317 /lib/ld-linux.so.2
|
||||
a8043000-a8044000 r--p 0001b000 03:00 8317 /lib/ld-linux.so.2
|
||||
a8044000-a8045000 rw-p 0001c000 03:00 8317 /lib/ld-linux.so.2
|
||||
aff35000-aff4a000 rw-p 00000000 00:00 0
|
||||
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
|
||||
|
||||
The /proc/PID/smaps is an extension based on maps, showing the memory
|
||||
consumption for each of the process's mappings. For each of mappings there
|
||||
|
|
|
|||
|
|
@ -0,0 +1,174 @@
|
|||
The QNX6 Filesystem
|
||||
===================
|
||||
|
||||
The qnx6fs is used by newer QNX operating system versions. (e.g. Neutrino)
|
||||
It got introduced in QNX 6.4.0 and is used default since 6.4.1.
|
||||
|
||||
Option
|
||||
======
|
||||
|
||||
mmi_fs Mount filesystem as used for example by Audi MMI 3G system
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
qnx6fs shares many properties with traditional Unix filesystems. It has the
|
||||
concepts of blocks, inodes and directories.
|
||||
On QNX it is possible to create little endian and big endian qnx6 filesystems.
|
||||
This feature makes it possible to create and use a different endianness fs
|
||||
for the target (QNX is used on quite a range of embedded systems) plattform
|
||||
running on a different endianess.
|
||||
The Linux driver handles endianness transparently. (LE and BE)
|
||||
|
||||
Blocks
|
||||
------
|
||||
|
||||
The space in the device or file is split up into blocks. These are a fixed
|
||||
size of 512, 1024, 2048 or 4096, which is decided when the filesystem is
|
||||
created.
|
||||
Blockpointers are 32bit, so the maximum space that can be adressed is
|
||||
2^32 * 4096 bytes or 16TB
|
||||
|
||||
The superblocks
|
||||
---------------
|
||||
|
||||
The superblock contains all global information about the filesystem.
|
||||
Each qnx6fs got two superblocks, each one having a 64bit serial number.
|
||||
That serial number is used to identify the "active" superblock.
|
||||
In write mode with reach new snapshot (after each synchronous write), the
|
||||
serial of the new master superblock is increased (old superblock serial + 1)
|
||||
|
||||
So basically the snapshot functionality is realized by an atomic final
|
||||
update of the serial number. Before updating that serial, all modifications
|
||||
are done by copying all modified blocks during that specific write request
|
||||
(or period) and building up a new (stable) filesystem structure under the
|
||||
inactive superblock.
|
||||
|
||||
Each superblock holds a set of root inodes for the different filesystem
|
||||
parts. (Inode, Bitmap and Longfilenames)
|
||||
Each of these root nodes holds information like total size of the stored
|
||||
data and the adressing levels in that specific tree.
|
||||
If the level value is 0, up to 16 direct blocks can be adressed by each
|
||||
node.
|
||||
Level 1 adds an additional indirect adressing level where each indirect
|
||||
adressing block holds up to blocksize / 4 bytes pointers to data blocks.
|
||||
Level 2 adds an additional indirect adressig block level (so, already up
|
||||
to 16 * 256 * 256 = 1048576 blocks that can be adressed by such a tree)a
|
||||
|
||||
Unused block pointers are always set to ~0 - regardless of root node,
|
||||
indirect adressing blocks or inodes.
|
||||
Data leaves are always on the lowest level. So no data is stored on upper
|
||||
tree levels.
|
||||
|
||||
The first Superblock is located at 0x2000. (0x2000 is the bootblock size)
|
||||
The Audi MMI 3G first superblock directly starts at byte 0.
|
||||
Second superblock position can either be calculated from the superblock
|
||||
information (total number of filesystem blocks) or by taking the highest
|
||||
device address, zeroing the last 3 bytes and then substracting 0x1000 from
|
||||
that address.
|
||||
|
||||
0x1000 is the size reserved for each superblock - regardless of the
|
||||
blocksize of the filesystem.
|
||||
|
||||
Inodes
|
||||
------
|
||||
|
||||
Each object in the filesystem is represented by an inode. (index node)
|
||||
The inode structure contains pointers to the filesystem blocks which contain
|
||||
the data held in the object and all of the metadata about an object except
|
||||
its longname. (filenames longer than 27 characters)
|
||||
The metadata about an object includes the permissions, owner, group, flags,
|
||||
size, number of blocks used, access time, change time and modification time.
|
||||
|
||||
Object mode field is POSIX format. (which makes things easier)
|
||||
|
||||
There are also pointers to the first 16 blocks, if the object data can be
|
||||
adressed with 16 direct blocks.
|
||||
For more than 16 blocks an indirect adressing in form of another tree is
|
||||
used. (scheme is the same as the one used for the superblock root nodes)
|
||||
|
||||
The filesize is stored 64bit. Inode counting starts with 1. (whilst long
|
||||
filename inodes start with 0)
|
||||
|
||||
Directories
|
||||
-----------
|
||||
|
||||
A directory is a filesystem object and has an inode just like a file.
|
||||
It is a specially formatted file containing records which associate each
|
||||
name with an inode number.
|
||||
'.' inode number points to the directory inode
|
||||
'..' inode number points to the parent directory inode
|
||||
Eeach filename record additionally got a filename length field.
|
||||
|
||||
One special case are long filenames or subdirectory names.
|
||||
These got set a filename length field of 0xff in the corresponding directory
|
||||
record plus the longfile inode number also stored in that record.
|
||||
With that longfilename inode number, the longfilename tree can be walked
|
||||
starting with the superblock longfilename root node pointers.
|
||||
|
||||
Special files
|
||||
-------------
|
||||
|
||||
Symbolic links are also filesystem objects with inodes. They got a specific
|
||||
bit in the inode mode field identifying them as symbolic link.
|
||||
The directory entry file inode pointer points to the target file inode.
|
||||
|
||||
Hard links got an inode, a directory entry, but a specific mode bit set,
|
||||
no block pointers and the directory file record pointing to the target file
|
||||
inode.
|
||||
|
||||
Character and block special devices do not exist in QNX as those files
|
||||
are handled by the QNX kernel/drivers and created in /dev independant of the
|
||||
underlaying filesystem.
|
||||
|
||||
Long filenames
|
||||
--------------
|
||||
|
||||
Long filenames are stored in a seperate adressing tree. The staring point
|
||||
is the longfilename root node in the active superblock.
|
||||
Each data block (tree leaves) holds one long filename. That filename is
|
||||
limited to 510 bytes. The first two starting bytes are used as length field
|
||||
for the actual filename.
|
||||
If that structure shall fit for all allowed blocksizes, it is clear why there
|
||||
is a limit of 510 bytes for the actual filename stored.
|
||||
|
||||
Bitmap
|
||||
------
|
||||
|
||||
The qnx6fs filesystem allocation bitmap is stored in a tree under bitmap
|
||||
root node in the superblock and each bit in the bitmap represents one
|
||||
filesystem block.
|
||||
The first block is block 0, which starts 0x1000 after superblock start.
|
||||
So for a normal qnx6fs 0x3000 (bootblock + superblock) is the physical
|
||||
address at which block 0 is located.
|
||||
|
||||
Bits at the end of the last bitmap block are set to 1, if the device is
|
||||
smaller than addressing space in the bitmap.
|
||||
|
||||
Bitmap system area
|
||||
------------------
|
||||
|
||||
The bitmap itself is devided into three parts.
|
||||
First the system area, that is split into two halfs.
|
||||
Then userspace.
|
||||
|
||||
The requirement for a static, fixed preallocated system area comes from how
|
||||
qnx6fs deals with writes.
|
||||
Each superblock got it's own half of the system area. So superblock #1
|
||||
always uses blocks from the lower half whilst superblock #2 just writes to
|
||||
blocks represented by the upper half bitmap system area bits.
|
||||
|
||||
Bitmap blocks, Inode blocks and indirect addressing blocks for those two
|
||||
tree structures are treated as system blocks.
|
||||
|
||||
The rational behind that is that a write request can work on a new snapshot
|
||||
(system area of the inactive - resp. lower serial numbered superblock) while
|
||||
at the same time there is still a complete stable filesystem structer in the
|
||||
other half of the system area.
|
||||
|
||||
When finished with writing (a sync write is completed, the maximum sync leap
|
||||
time or a filesystem sync is requested), serial of the previously inactive
|
||||
superblock atomically is increased and the fs switches over to that - then
|
||||
stable declared - superblock.
|
||||
|
||||
For all data outside the system area, blocks are just copied while writing.
|
||||
|
|
@ -297,7 +297,7 @@ the above threads) is:
|
|||
either way about the archive format, and there are alternative tools,
|
||||
such as:
|
||||
|
||||
http://freshmeat.net/projects/afio/
|
||||
http://freecode.com/projects/afio
|
||||
|
||||
2) The cpio archive format chosen by the kernel is simpler and cleaner (and
|
||||
thus easier to create and parse) than any of the (literally dozens of)
|
||||
|
|
|
|||
|
|
@ -993,7 +993,7 @@ struct dentry_operations {
|
|||
|
||||
If the 'rcu_walk' parameter is true, then the caller is doing a
|
||||
pathwalk in RCU-walk mode. Sleeping is not permitted in this mode,
|
||||
and the caller can be asked to leave it and call again by returing
|
||||
and the caller can be asked to leave it and call again by returning
|
||||
-ECHILD.
|
||||
|
||||
This function is only used if DCACHE_MANAGE_TRANSIT is set on the
|
||||
|
|
|
|||
|
|
@ -2,6 +2,10 @@ Kernel driver adm1275
|
|||
=====================
|
||||
|
||||
Supported chips:
|
||||
* Analog Devices ADM1075
|
||||
Prefix: 'adm1075'
|
||||
Addresses scanned: -
|
||||
Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1075.pdf
|
||||
* Analog Devices ADM1275
|
||||
Prefix: 'adm1275'
|
||||
Addresses scanned: -
|
||||
|
|
@ -17,13 +21,13 @@ Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
|||
Description
|
||||
-----------
|
||||
|
||||
This driver supports hardware montoring for Analog Devices ADM1275 and ADM1276
|
||||
Hot-Swap Controller and Digital Power Monitor.
|
||||
This driver supports hardware montoring for Analog Devices ADM1075, ADM1275,
|
||||
and ADM1276 Hot-Swap Controller and Digital Power Monitor.
|
||||
|
||||
ADM1275 and ADM1276 are hot-swap controllers that allow a circuit board to be
|
||||
removed from or inserted into a live backplane. They also feature current and
|
||||
voltage readback via an integrated 12-bit analog-to-digital converter (ADC),
|
||||
accessed using a PMBus interface.
|
||||
ADM1075, ADM1275, and ADM1276 are hot-swap controllers that allow a circuit
|
||||
board to be removed from or inserted into a live backplane. They also feature
|
||||
current and voltage readback via an integrated 12-bit analog-to-digital
|
||||
converter (ADC), accessed using a PMBus interface.
|
||||
|
||||
The driver is a client driver to the core PMBus driver. Please see
|
||||
Documentation/hwmon/pmbus for details on PMBus client drivers.
|
||||
|
|
@ -36,6 +40,10 @@ This driver does not auto-detect devices. You will have to instantiate the
|
|||
devices explicitly. Please see Documentation/i2c/instantiating-devices for
|
||||
details.
|
||||
|
||||
The ADM1075, unlike many other PMBus devices, does not support internal voltage
|
||||
or current scaling. Reported voltages, currents, and power are raw measurements,
|
||||
and will typically have to be scaled.
|
||||
|
||||
|
||||
Platform data support
|
||||
---------------------
|
||||
|
|
@ -51,9 +59,10 @@ The following attributes are supported. Limits are read-write, history reset
|
|||
attributes are write-only, all other attributes are read-only.
|
||||
|
||||
in1_label "vin1" or "vout1" depending on chip variant and
|
||||
configuration.
|
||||
configuration. On ADM1075, vout1 reports the voltage on
|
||||
the VAUX pin.
|
||||
in1_input Measured voltage.
|
||||
in1_min Minumum Voltage.
|
||||
in1_min Minimum Voltage.
|
||||
in1_max Maximum voltage.
|
||||
in1_min_alarm Voltage low alarm.
|
||||
in1_max_alarm Voltage high alarm.
|
||||
|
|
@ -74,3 +83,10 @@ curr1_crit Critical maximum current. Depending on the chip
|
|||
curr1_crit_alarm Critical current high alarm.
|
||||
curr1_highest Historical maximum current.
|
||||
curr1_reset_history Write any value to reset history.
|
||||
|
||||
power1_label "pin1"
|
||||
power1_input Input power.
|
||||
power1_reset_history Write any value to reset history.
|
||||
|
||||
Power attributes are supported on ADM1075 and ADM1276
|
||||
only.
|
||||
|
|
|
|||
|
|
@ -3,71 +3,50 @@ Kernel driver jc42
|
|||
|
||||
Supported chips:
|
||||
* Analog Devices ADT7408
|
||||
Prefix: 'adt7408'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheets:
|
||||
http://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf
|
||||
* Atmel AT30TS00
|
||||
Prefix: 'at30ts00'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheets:
|
||||
http://www.atmel.com/Images/doc8585.pdf
|
||||
* IDT TSE2002B3, TSE2002GB2, TS3000B3, TS3000GB2
|
||||
Prefix: 'tse2002', 'ts3000'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheets:
|
||||
http://www.idt.com/sites/default/files/documents/IDT_TSE2002B3C_DST_20100512_120303152056.pdf
|
||||
http://www.idt.com/sites/default/files/documents/IDT_TSE2002GB2A1_DST_20111107_120303145914.pdf
|
||||
http://www.idt.com/sites/default/files/documents/IDT_TS3000B3A_DST_20101129_120303152013.pdf
|
||||
http://www.idt.com/sites/default/files/documents/IDT_TS3000GB2A1_DST_20111104_120303151012.pdf
|
||||
* Maxim MAX6604
|
||||
Prefix: 'max6604'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheets:
|
||||
http://datasheets.maxim-ic.com/en/ds/MAX6604.pdf
|
||||
* Microchip MCP9804, MCP9805, MCP98242, MCP98243, MCP9843
|
||||
Prefixes: 'mcp9804', 'mcp9805', 'mcp98242', 'mcp98243', 'mcp9843'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheets:
|
||||
http://ww1.microchip.com/downloads/en/DeviceDoc/22203C.pdf
|
||||
http://ww1.microchip.com/downloads/en/DeviceDoc/21977b.pdf
|
||||
http://ww1.microchip.com/downloads/en/DeviceDoc/21996a.pdf
|
||||
http://ww1.microchip.com/downloads/en/DeviceDoc/22153c.pdf
|
||||
* NXP Semiconductors SE97, SE97B
|
||||
Prefix: 'se97'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
* NXP Semiconductors SE97, SE97B, SE98, SE98A
|
||||
Datasheets:
|
||||
http://www.nxp.com/documents/data_sheet/SE97.pdf
|
||||
http://www.nxp.com/documents/data_sheet/SE97B.pdf
|
||||
* NXP Semiconductors SE98
|
||||
Prefix: 'se98'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheets:
|
||||
http://www.nxp.com/documents/data_sheet/SE98.pdf
|
||||
http://www.nxp.com/documents/data_sheet/SE98A.pdf
|
||||
* ON Semiconductor CAT34TS02, CAT6095
|
||||
Prefix: 'cat34ts02', 'cat6095'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheet:
|
||||
http://www.onsemi.com/pub_link/Collateral/CAT34TS02-D.PDF
|
||||
http://www.onsemi.com/pub/Collateral/CAT6095-D.PDF
|
||||
* ST Microelectronics STTS424, STTS424E02
|
||||
Prefix: 'stts424'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheets:
|
||||
http://www.st.com/stonline/products/literature/ds/13447/stts424.pdf
|
||||
http://www.st.com/stonline/products/literature/ds/13448/stts424e02.pdf
|
||||
* ST Microelectronics STTS2002, STTS3000
|
||||
Prefix: 'stts2002', 'stts3000'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
* ST Microelectronics STTS424, STTS424E02, STTS2002, STTS3000
|
||||
Datasheets:
|
||||
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157556.pdf
|
||||
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157558.pdf
|
||||
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00225278.pdf
|
||||
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATA_BRIEF/CD00270920.pdf
|
||||
* JEDEC JC 42.4 compliant temperature sensor chips
|
||||
Prefix: 'jc42'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheet:
|
||||
http://www.jedec.org/sites/default/files/docs/4_01_04R19.pdf
|
||||
|
||||
Common for all chips:
|
||||
Prefix: 'jc42'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
|
||||
Author:
|
||||
Guenter Roeck <guenter.roeck@ericsson.com>
|
||||
|
||||
|
|
|
|||
|
|
@ -7,6 +7,11 @@ Supported chips:
|
|||
Addresses scanned: I2C 0x28 - 0x2f
|
||||
Datasheet: Publicly available at the National Semiconductor website
|
||||
http://www.national.com/
|
||||
* National Semiconductor LM96080
|
||||
Prefix: 'lm96080'
|
||||
Addresses scanned: I2C 0x28 - 0x2f
|
||||
Datasheet: Publicly available at the National Semiconductor website
|
||||
http://www.national.com/
|
||||
|
||||
Authors:
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
|
|
@ -17,7 +22,9 @@ Description
|
|||
|
||||
This driver implements support for the National Semiconductor LM80.
|
||||
It is described as a 'Serial Interface ACPI-Compatible Microprocessor
|
||||
System Hardware Monitor'.
|
||||
System Hardware Monitor'. The LM96080 is a more recent incarnation,
|
||||
it is pin and register compatible, with a few additional features not
|
||||
yet supported by the driver.
|
||||
|
||||
The LM80 implements one temperature sensor, two fan rotation speed sensors,
|
||||
seven voltage sensors, alarms, and some miscellaneous stuff.
|
||||
|
|
|
|||
|
|
@ -118,6 +118,10 @@ Supported chips:
|
|||
Addresses scanned: I2C 0x48 through 0x4F
|
||||
Datasheet: Publicly available at NXP website
|
||||
http://ics.nxp.com/products/interface/datasheet/sa56004x.pdf
|
||||
* GMT G781
|
||||
Prefix: 'g781'
|
||||
Addresses scanned: I2C 0x4c, 0x4d
|
||||
Datasheet: Not publicly available from GMT
|
||||
|
||||
Author: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
|
|
|
|||
|
|
@ -42,9 +42,9 @@ attributes are read-only.
|
|||
|
||||
in[1-4]_label "vout[1-4]"
|
||||
in[1-4]_input Measured voltage. From READ_VOUT register.
|
||||
in[1-4]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-4]_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-4]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in[1-4]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-4]_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-4]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in[1-4]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in[1-4]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
|
|
|
|||
|
|
@ -11,6 +11,11 @@ Supported chips:
|
|||
Prefixes: 'max34441'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34441.pdf
|
||||
* Maxim MAX34446
|
||||
PMBus Power-Supply Data Logger
|
||||
Prefixes: 'max34446'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34446.pdf
|
||||
|
||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
||||
|
||||
|
|
@ -19,8 +24,8 @@ Description
|
|||
-----------
|
||||
|
||||
This driver supports hardware montoring for Maxim MAX34440 PMBus 6-Channel
|
||||
Power-Supply Manager and MAX34441 PMBus 5-Channel Power-Supply Manager
|
||||
and Intelligent Fan Controller.
|
||||
Power-Supply Manager, MAX34441 PMBus 5-Channel Power-Supply Manager
|
||||
and Intelligent Fan Controller, and MAX34446 PMBus Power-Supply Data Logger.
|
||||
|
||||
The driver is a client driver to the core PMBus driver. Please see
|
||||
Documentation/hwmon/pmbus for details on PMBus client drivers.
|
||||
|
|
@ -33,6 +38,13 @@ This driver does not auto-detect devices. You will have to instantiate the
|
|||
devices explicitly. Please see Documentation/i2c/instantiating-devices for
|
||||
details.
|
||||
|
||||
For MAX34446, the value of the currX_crit attribute determines if current or
|
||||
voltage measurement is enabled for a given channel. Voltage measurement is
|
||||
enabled if currX_crit is set to 0; current measurement is enabled if the
|
||||
attribute is set to a positive value. Power measurement is only enabled if
|
||||
channel 1 (3) is configured for voltage measurement, and channel 2 (4) is
|
||||
configured for current measurement.
|
||||
|
||||
|
||||
Platform data support
|
||||
---------------------
|
||||
|
|
@ -48,27 +60,39 @@ attributes are read-only.
|
|||
|
||||
in[1-6]_label "vout[1-6]".
|
||||
in[1-6]_input Measured voltage. From READ_VOUT register.
|
||||
in[1-6]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-6]_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-6]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in[1-6]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-6]_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-6]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in[1-6]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in[1-6]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
in[1-6]_lcrit_alarm Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
|
||||
in[1-6]_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
|
||||
in[1-6]_lowest Historical minimum voltage.
|
||||
in[1-6]_highest Historical maximum voltage.
|
||||
in[1-6]_reset_history Write any value to reset history.
|
||||
|
||||
MAX34446 only supports in[1-4].
|
||||
|
||||
curr[1-6]_label "iout[1-6]".
|
||||
curr[1-6]_input Measured current. From READ_IOUT register.
|
||||
curr[1-6]_max Maximum current. From IOUT_OC_WARN_LIMIT register.
|
||||
curr[1-6]_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
|
||||
curr[1-6]_max_alarm Current high alarm. From IOUT_OC_WARNING status.
|
||||
curr[1-6]_crit_alarm Current critical high alarm. From IOUT_OC_FAULT status.
|
||||
curr[1-4]_average Historical average current (MAX34446 only).
|
||||
curr[1-6]_highest Historical maximum current.
|
||||
curr[1-6]_reset_history Write any value to reset history.
|
||||
|
||||
in6 and curr6 attributes only exist for MAX34440.
|
||||
MAX34446 only supports curr[1-4].
|
||||
|
||||
power[1,3]_label "pout[1,3]"
|
||||
power[1,3]_input Measured power.
|
||||
power[1,3]_average Historical average power.
|
||||
power[1,3]_highest Historical maximum power.
|
||||
|
||||
Power attributes only exist for MAX34446.
|
||||
|
||||
temp[1-8]_input Measured temperatures. From READ_TEMPERATURE_1 register.
|
||||
temp1 is the chip's internal temperature. temp2..temp5
|
||||
|
|
@ -79,7 +103,9 @@ temp[1-8]_max Maximum temperature. From OT_WARN_LIMIT register.
|
|||
temp[1-8]_crit Critical high temperature. From OT_FAULT_LIMIT register.
|
||||
temp[1-8]_max_alarm Temperature high alarm.
|
||||
temp[1-8]_crit_alarm Temperature critical high alarm.
|
||||
temp[1-8]_average Historical average temperature (MAX34446 only).
|
||||
temp[1-8]_highest Historical maximum temperature.
|
||||
temp[1-8]_reset_history Write any value to reset history.
|
||||
|
||||
temp7 and temp8 attributes only exist for MAX34440.
|
||||
MAX34446 only supports temp[1-3].
|
||||
|
|
|
|||
|
|
@ -42,9 +42,9 @@ attributes are read-only.
|
|||
|
||||
in1_label "vout1"
|
||||
in1_input Measured voltage. From READ_VOUT register.
|
||||
in1_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in1_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in1_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in1_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in1_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in1_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in1_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in1_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
|
|
|
|||
|
|
@ -3,8 +3,11 @@ Kernel driver mc13783-adc
|
|||
|
||||
Supported chips:
|
||||
* Freescale Atlas MC13783
|
||||
Prefix: 'mc13783_adc'
|
||||
Prefix: 'mc13783'
|
||||
Datasheet: http://www.freescale.com/files/rf_if/doc/data_sheet/MC13783.pdf?fsrch=1
|
||||
* Freescale Atlas MC13892
|
||||
Prefix: 'mc13892'
|
||||
Datasheet: http://cache.freescale.com/files/analog/doc/data_sheet/MC13892.pdf?fsrch=1&sr=1
|
||||
|
||||
Authors:
|
||||
Sascha Hauer <s.hauer@pengutronix.de>
|
||||
|
|
@ -13,20 +16,21 @@ Authors:
|
|||
Description
|
||||
-----------
|
||||
|
||||
The Freescale MC13783 is a Power Management and Audio Circuit. Among
|
||||
other things it contains a 10-bit A/D converter. The converter has 16
|
||||
channels which can be used in different modes.
|
||||
The A/D converter has a resolution of 2.25mV. Channels 0-4 have
|
||||
a dedicated meaning with chip internal scaling applied. Channels 5-7
|
||||
can be used as general purpose inputs or alternatively in a dedicated
|
||||
mode. Channels 12-15 are occupied by the touchscreen if it's active.
|
||||
The Freescale MC13783 and MC13892 are Power Management and Audio Circuits.
|
||||
Among other things they contain a 10-bit A/D converter. The converter has 16
|
||||
(MC13783) resp. 12 (MC13892) channels which can be used in different modes. The
|
||||
A/D converter has a resolution of 2.25mV.
|
||||
|
||||
Currently the driver only supports channels 2 and 5-15 with no alternative
|
||||
modes for channels 5-7.
|
||||
Some channels can be used as General Purpose inputs or in a dedicated mode with
|
||||
a chip internal scaling applied .
|
||||
|
||||
See this table for the meaning of the different channels and their chip
|
||||
internal scaling:
|
||||
Currently the driver only supports the Application Supply channel (BP / BPSNS),
|
||||
the General Purpose inputs and touchscreen.
|
||||
|
||||
See the following tables for the meaning of the different channels and their
|
||||
chip internal scaling:
|
||||
|
||||
MC13783:
|
||||
Channel Signal Input Range Scaling
|
||||
-------------------------------------------------------------------------------
|
||||
0 Battery Voltage (BATT) 2.50 - 4.65V -2.40V
|
||||
|
|
@ -34,7 +38,7 @@ Channel Signal Input Range Scaling
|
|||
2 Application Supply (BP) 2.50 - 4.65V -2.40V
|
||||
3 Charger Voltage (CHRGRAW) 0 - 10V / /5
|
||||
0 - 20V /10
|
||||
4 Charger Current (CHRGISNSP-CHRGISNSN) -0.25V - 0.25V x4
|
||||
4 Charger Current (CHRGISNSP-CHRGISNSN) -0.25 - 0.25V x4
|
||||
5 General Purpose ADIN5 / Battery Pack Thermistor 0 - 2.30V No
|
||||
6 General Purpose ADIN6 / Backup Voltage (LICELL) 0 - 2.30V / No /
|
||||
1.50 - 3.50V -1.20V
|
||||
|
|
@ -48,3 +52,23 @@ Channel Signal Input Range Scaling
|
|||
13 General Purpose TSX2 / Touchscreen X-plate 2 0 - 2.30V No
|
||||
14 General Purpose TSY1 / Touchscreen Y-plate 1 0 - 2.30V No
|
||||
15 General Purpose TSY2 / Touchscreen Y-plate 2 0 - 2.30V No
|
||||
|
||||
MC13892:
|
||||
Channel Signal Input Range Scaling
|
||||
-------------------------------------------------------------------------------
|
||||
0 Battery Voltage (BATT) 0 - 4.8V /2
|
||||
1 Battery Current (BATT - BATTISNSCC) -60 - 60 mV x20
|
||||
2 Application Supply (BPSNS) 0 - 4.8V /2
|
||||
3 Charger Voltage (CHRGRAW) 0 - 12V / /5
|
||||
0 - 20V /10
|
||||
4 Charger Current (CHRGISNS-BPSNS) / -0.3 - 0.3V / x4 /
|
||||
Touchscreen X-plate 1 0 - 2.4V No
|
||||
5 General Purpose ADIN5 / Battery Pack Thermistor 0 - 2.4V No
|
||||
6 General Purpose ADIN6 / Backup Voltage (LICELL) 0 - 2.4V / No
|
||||
Backup Voltage (LICELL) 0 - 3.6V x2/3
|
||||
7 General Purpose ADIN7 / UID / Die Temperature 0 - 2.4V / No /
|
||||
0 - 4.8V /2
|
||||
12 General Purpose TSX1 / Touchscreen X-plate 1 0 - 2.4V No
|
||||
13 General Purpose TSX2 / Touchscreen X-plate 2 0 - 2.4V No
|
||||
14 General Purpose TSY1 / Touchscreen Y-plate 1 0 - 2.4V No
|
||||
15 General Purpose TSY2 / Touchscreen Y-plate 2 0 - 2.4V No
|
||||
|
|
|
|||
|
|
@ -0,0 +1,22 @@
|
|||
Kernel driver MCP3021
|
||||
======================
|
||||
|
||||
Supported chips:
|
||||
* Microchip Technology MCP3021
|
||||
Prefix: 'mcp3021'
|
||||
Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/21805a.pdf
|
||||
|
||||
Author: Mingkai Hu
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the Microchip Technology MCP3021 chip.
|
||||
|
||||
The Microchip Technology Inc. MCP3021 is a successive approximation A/D
|
||||
converter (ADC) with 10-bit resolution.
|
||||
This device provides one single-ended input with very low power consumption.
|
||||
Communication to the MCP3021 is performed using a 2-wire I2C compatible
|
||||
interface. Standard (100 kHz) and Fast (400 kHz) I2C modes are available.
|
||||
The default I2C device address is 0x4d (contact the Microchip factory for
|
||||
additional address options).
|
||||
|
|
@ -15,13 +15,20 @@ Supported chips:
|
|||
http://www.onsemi.com/pub_link/Collateral/NCP4200-D.PDF
|
||||
http://www.onsemi.com/pub_link/Collateral/JUNE%202009-%20REV.%200.PDF
|
||||
* Lineage Power
|
||||
Prefixes: 'pdt003', 'pdt006', 'pdt012', 'udt020'
|
||||
Prefixes: 'mdt040', 'pdt003', 'pdt006', 'pdt012', 'udt020'
|
||||
Addresses scanned: -
|
||||
Datasheets:
|
||||
http://www.lineagepower.com/oem/pdf/PDT003A0X.pdf
|
||||
http://www.lineagepower.com/oem/pdf/PDT006A0X.pdf
|
||||
http://www.lineagepower.com/oem/pdf/PDT012A0X.pdf
|
||||
http://www.lineagepower.com/oem/pdf/UDT020A0X.pdf
|
||||
http://www.lineagepower.com/oem/pdf/MDT040A0X.pdf
|
||||
* Texas Instruments TPS40400, TPS40422
|
||||
Prefixes: 'tps40400', 'tps40422'
|
||||
Addresses scanned: -
|
||||
Datasheets:
|
||||
http://www.ti.com/lit/gpn/tps40400
|
||||
http://www.ti.com/lit/gpn/tps40422
|
||||
* Generic PMBus devices
|
||||
Prefix: 'pmbus'
|
||||
Addresses scanned: -
|
||||
|
|
|
|||
|
|
@ -16,6 +16,11 @@ Description
|
|||
SMSC SCH5627 Super I/O chips include complete hardware monitoring
|
||||
capabilities. They can monitor up to 5 voltages, 4 fans and 8 temperatures.
|
||||
|
||||
The SMSC SCH5627 hardware monitoring part also contains an integrated
|
||||
watchdog. In order for this watchdog to function some motherboard specific
|
||||
initialization most be done by the BIOS, so if the watchdog is not enabled
|
||||
by the BIOS the sch5627 driver will not register a watchdog device.
|
||||
|
||||
The hardware monitoring part of the SMSC SCH5627 is accessed by talking
|
||||
through an embedded microcontroller. An application note describing the
|
||||
protocol for communicating with the microcontroller is available upon
|
||||
|
|
|
|||
|
|
@ -26,6 +26,9 @@ temperatures. Note that the driver detects how many fan headers /
|
|||
temperature sensors are actually implemented on the motherboard, so you will
|
||||
likely see fewer temperature and fan inputs.
|
||||
|
||||
The Fujitsu Theseus hwmon solution also contains an integrated watchdog.
|
||||
This watchdog is fully supported by the sch5636 driver.
|
||||
|
||||
An application note describing the Theseus' registers, as well as an
|
||||
application note describing the protocol for communicating with the
|
||||
microcontroller is available upon request. Please mail me if you want a copy.
|
||||
|
|
|
|||
|
|
@ -70,9 +70,9 @@ attributes are read-only.
|
|||
|
||||
in[1-12]_label "vout[1-12]".
|
||||
in[1-12]_input Measured voltage. From READ_VOUT register.
|
||||
in[1-12]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-12]_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-12]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in[1-12]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-12]_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-12]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in[1-12]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in[1-12]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
|
|
@ -82,7 +82,7 @@ in[1-12]_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
|
|||
curr[1-12]_label "iout[1-12]".
|
||||
curr[1-12]_input Measured current. From READ_IOUT register.
|
||||
curr[1-12]_max Maximum current. From IOUT_OC_WARN_LIMIT register.
|
||||
curr[1-12]_lcrit Critical minumum output current. From IOUT_UC_FAULT_LIMIT
|
||||
curr[1-12]_lcrit Critical minimum output current. From IOUT_UC_FAULT_LIMIT
|
||||
register.
|
||||
curr[1-12]_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
|
||||
curr[1-12]_max_alarm Current high alarm. From IOUT_OC_WARNING status.
|
||||
|
|
|
|||
|
|
@ -54,9 +54,9 @@ attributes are read-only.
|
|||
|
||||
in1_label "vin".
|
||||
in1_input Measured voltage. From READ_VIN register.
|
||||
in1_min Minumum Voltage. From VIN_UV_WARN_LIMIT register.
|
||||
in1_min Minimum Voltage. From VIN_UV_WARN_LIMIT register.
|
||||
in1_max Maximum voltage. From VIN_OV_WARN_LIMIT register.
|
||||
in1_lcrit Critical minumum Voltage. VIN_UV_FAULT_LIMIT register.
|
||||
in1_lcrit Critical minimum Voltage. VIN_UV_FAULT_LIMIT register.
|
||||
in1_crit Critical maximum voltage. From VIN_OV_FAULT_LIMIT register.
|
||||
in1_min_alarm Voltage low alarm. From VIN_UV_WARNING status.
|
||||
in1_max_alarm Voltage high alarm. From VIN_OV_WARNING status.
|
||||
|
|
@ -65,9 +65,9 @@ in1_crit_alarm Voltage critical high alarm. From VIN_OV_FAULT status.
|
|||
|
||||
in[2-5]_label "vout[1-4]".
|
||||
in[2-5]_input Measured voltage. From READ_VOUT register.
|
||||
in[2-5]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[2-5]_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[2-5]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in[2-5]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[2-5]_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[2-5]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in[2-5]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in[2-5]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
|
|
@ -80,7 +80,7 @@ curr1_input Measured current. From READ_IIN register.
|
|||
curr[2-5]_label "iout[1-4]".
|
||||
curr[2-5]_input Measured current. From READ_IOUT register.
|
||||
curr[2-5]_max Maximum current. From IOUT_OC_WARN_LIMIT register.
|
||||
curr[2-5]_lcrit Critical minumum output current. From IOUT_UC_FAULT_LIMIT
|
||||
curr[2-5]_lcrit Critical minimum output current. From IOUT_UC_FAULT_LIMIT
|
||||
register.
|
||||
curr[2-5]_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
|
||||
curr[2-5]_max_alarm Current high alarm. From IOUT_OC_WARNING status.
|
||||
|
|
|
|||
|
|
@ -34,6 +34,14 @@ Supported chips:
|
|||
Prefix: 'zl6105'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://www.intersil.com/data/fn/fn6906.pdf
|
||||
* Intersil / Zilker Labs ZL9101M
|
||||
Prefix: 'zl9101'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://www.intersil.com/data/fn/fn7669.pdf
|
||||
* Intersil / Zilker Labs ZL9117M
|
||||
Prefix: 'zl9117'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://www.intersil.com/data/fn/fn7914.pdf
|
||||
* Ericsson BMR450, BMR451
|
||||
Prefix: 'bmr450', 'bmr451'
|
||||
Addresses scanned: -
|
||||
|
|
@ -106,7 +114,7 @@ in1_label "vin"
|
|||
in1_input Measured input voltage.
|
||||
in1_min Minimum input voltage.
|
||||
in1_max Maximum input voltage.
|
||||
in1_lcrit Critical minumum input voltage.
|
||||
in1_lcrit Critical minimum input voltage.
|
||||
in1_crit Critical maximum input voltage.
|
||||
in1_min_alarm Input voltage low alarm.
|
||||
in1_max_alarm Input voltage high alarm.
|
||||
|
|
@ -115,7 +123,7 @@ in1_crit_alarm Input voltage critical high alarm.
|
|||
|
||||
in2_label "vout1"
|
||||
in2_input Measured output voltage.
|
||||
in2_lcrit Critical minumum output Voltage.
|
||||
in2_lcrit Critical minimum output Voltage.
|
||||
in2_crit Critical maximum output voltage.
|
||||
in2_lcrit_alarm Critical output voltage critical low alarm.
|
||||
in2_crit_alarm Critical output voltage critical high alarm.
|
||||
|
|
|
|||
|
|
@ -87,11 +87,11 @@ it may have different addresses from one board to the next (manufacturer
|
|||
changing its design without notice). In this case, you can call
|
||||
i2c_new_probed_device() instead of i2c_new_device().
|
||||
|
||||
Example (from the pnx4008 OHCI driver):
|
||||
Example (from the nxp OHCI driver):
|
||||
|
||||
static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END };
|
||||
|
||||
static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev)
|
||||
static int __devinit usb_hcd_nxp_probe(struct platform_device *pdev)
|
||||
{
|
||||
(...)
|
||||
struct i2c_adapter *i2c_adap;
|
||||
|
|
@ -100,7 +100,7 @@ static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev)
|
|||
(...)
|
||||
i2c_adap = i2c_get_adapter(2);
|
||||
memset(&i2c_info, 0, sizeof(struct i2c_board_info));
|
||||
strlcpy(i2c_info.type, "isp1301_pnx", I2C_NAME_SIZE);
|
||||
strlcpy(i2c_info.type, "isp1301_nxp", I2C_NAME_SIZE);
|
||||
isp1301_i2c_client = i2c_new_probed_device(i2c_adap, &i2c_info,
|
||||
normal_i2c, NULL);
|
||||
i2c_put_adapter(i2c_adap);
|
||||
|
|
|
|||
|
|
@ -138,7 +138,7 @@ VI. Setting Parameters
|
|||
|
||||
The return value is the size in bytes of the data written into
|
||||
ops->resbuf if no errors occur. If an error occurs, -1 is returned
|
||||
and errno is set appropriatly:
|
||||
and errno is set appropriately:
|
||||
|
||||
EFAULT Invalid user space pointer was passed
|
||||
ENXIO Invalid IOP number
|
||||
|
|
@ -222,7 +222,7 @@ VIII. Downloading Software
|
|||
RETURNS
|
||||
|
||||
This function returns 0 no errors occur. If an error occurs, -1
|
||||
is returned and errno is set appropriatly:
|
||||
is returned and errno is set appropriately:
|
||||
|
||||
EFAULT Invalid user space pointer was passed
|
||||
ENXIO Invalid IOP number
|
||||
|
|
@ -264,7 +264,7 @@ IX. Uploading Software
|
|||
RETURNS
|
||||
|
||||
This function returns 0 if no errors occur. If an error occurs, -1
|
||||
is returned and errno is set appropriatly:
|
||||
is returned and errno is set appropriately:
|
||||
|
||||
EFAULT Invalid user space pointer was passed
|
||||
ENXIO Invalid IOP number
|
||||
|
|
@ -301,7 +301,7 @@ X. Removing Software
|
|||
RETURNS
|
||||
|
||||
This function returns 0 if no errors occur. If an error occurs, -1
|
||||
is returned and errno is set appropriatly:
|
||||
is returned and errno is set appropriately:
|
||||
|
||||
EFAULT Invalid user space pointer was passed
|
||||
ENXIO Invalid IOP number
|
||||
|
|
@ -325,7 +325,7 @@ X. Validating Configuration
|
|||
RETURNS
|
||||
|
||||
This function returns 0 if no erro occur. If an error occurs, -1 is
|
||||
returned and errno is set appropriatly:
|
||||
returned and errno is set appropriately:
|
||||
|
||||
ETIMEDOUT Timeout waiting for reply message
|
||||
ENXIO Invalid IOP number
|
||||
|
|
@ -360,7 +360,7 @@ XI. Configuration Dialog
|
|||
RETURNS
|
||||
|
||||
This function returns 0 if no error occur. If an error occurs, -1
|
||||
is returned and errno is set appropriatly:
|
||||
is returned and errno is set appropriately:
|
||||
|
||||
EFAULT Invalid user space pointer was passed
|
||||
ENXIO Invalid IOP number
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue