dect
/
linux-2.6
Archived
13
0
Fork 0
Code Releases Activity

Merge git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux 

Merge mainline to add prerequisite for ARM ux500 crypto support.
This commit is contained in:
Herbert Xu 2012-05-15 17:21:26 +10:00
parent 8a63b1994c 4bb2d1009f
commit b29e2679d0
2876 changed files with 113024 additions and 52901 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Documentation/00-INDEX
View 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/

75
Documentation/ABI/testing/sysfs-bus-rpmsg Normal file
View File

@ -0,0 +1,75 @@
What: /sys/bus/rpmsg/devices/.../name
Date: June 2011
KernelVersion: 3.3
Contact: Ohad Ben-Cohen <ohad@wizery.com>
Description:
Every rpmsg device is a communication channel with a remote
processor. Channels are identified with a (textual) name,
which is maximum 32 bytes long (defined as RPMSG_NAME_SIZE in
rpmsg.h).
This sysfs entry contains the name of this channel.
What: /sys/bus/rpmsg/devices/.../src
Date: June 2011
KernelVersion: 3.3
Contact: Ohad Ben-Cohen <ohad@wizery.com>
Description:
Every rpmsg device is a communication channel with a remote
processor. Channels have a local ("source") rpmsg address,
and remote ("destination") rpmsg address. When an entity
starts listening on one end of a channel, it assigns it with
a unique rpmsg address (a 32 bits integer). This way when
inbound messages arrive to this address, the rpmsg core
dispatches them to the listening entity (a kernel driver).
This sysfs entry contains the src (local) rpmsg address
of this channel. If it contains 0xffffffff, then an address
wasn't assigned (can happen if no driver exists for this
channel).
What: /sys/bus/rpmsg/devices/.../dst
Date: June 2011
KernelVersion: 3.3
Contact: Ohad Ben-Cohen <ohad@wizery.com>
Description:
Every rpmsg device is a communication channel with a remote
processor. Channels have a local ("source") rpmsg address,
and remote ("destination") rpmsg address. When an entity
starts listening on one end of a channel, it assigns it with
a unique rpmsg address (a 32 bits integer). This way when
inbound messages arrive to this address, the rpmsg core
dispatches them to the listening entity.
This sysfs entry contains the dst (remote) rpmsg address
of this channel. If it contains 0xffffffff, then an address
wasn't assigned (can happen if the kernel driver that
is attached to this channel is exposing a service to the
remote processor. This make it a local rpmsg server,
and it is listening for inbound messages that may be sent
from any remote rpmsg client; it is not bound to a single
remote entity).
What: /sys/bus/rpmsg/devices/.../announce
Date: June 2011
KernelVersion: 3.3
Contact: Ohad Ben-Cohen <ohad@wizery.com>
Description:
Every rpmsg device is a communication channel with a remote
processor. Channels are identified by a textual name (see
/sys/bus/rpmsg/devices/.../name above) and have a local
("source") rpmsg address, and remote ("destination") rpmsg
address.
A channel is first created when an entity, whether local
or remote, starts listening on it for messages (and is thus
called an rpmsg server).
When that happens, a "name service" announcement is sent
to the other processor, in order to let it know about the
creation of the channel (this way remote clients know they
can start sending messages).
This sysfs entry tells us whether the channel is a local
server channel that is announced (values are either
true or false).

17
Documentation/DocBook/kgdb.tmpl
View File

@ -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">

20
Documentation/DocBook/media/v4l/biblio.xml
View File

@ -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 &mdash; Digital Compression and Coding of Continous-Tone
Still Images &mdash; 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&nbsp;12M</abbrev>
<authorgroup>

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

@ -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>

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

@ -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>&nbsp;</entry>
<entry>enum&nbsp;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>&nbsp;</entry>
<entry>Automatically determines the best playback mode.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_STEREO</constant>&nbsp;</entry>
<entry>Stereo playback.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_LEFT</constant>&nbsp;</entry>
<entry>Left channel playback.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_RIGHT</constant>&nbsp;</entry>
<entry>Right channel playback.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_MONO</constant>&nbsp;</entry>
<entry>Mono playback.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_SWAPPED_STEREO</constant>&nbsp;</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>&nbsp;</entry>
<entry>enum&nbsp;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>&nbsp;</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>&nbsp;</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>&nbsp;</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>

8
Documentation/DocBook/media/v4l/selection-api.xml
View File

@ -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

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

@ -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;

256
Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml Normal file
View File

@ -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>

9
Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
View File

@ -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>

16
Documentation/DocBook/media/v4l/vidioc-g-jpegcomp.xml
View File

@ -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>

106
Documentation/DocBook/media/v4l/vidioc-g-selection.xml
View File

@ -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>

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

@ -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>

6
Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
View File

@ -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>

78
Documentation/backlight/lp855x-driver.txt Normal file
View File

@ -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,
},
};

182
Documentation/crc32.txt Normal file
View File

@ -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.

38
Documentation/devicetree/bindings/arm/atmel-aic.txt Normal file
View File

@ -0,0 +1,38 @@
* Advanced Interrupt Controller (AIC)
Required properties:
- compatible: Should be "atmel,<chip>-aic"
- interrupt-controller: Identifies the node as an interrupt controller.
- interrupt-parent: For single AIC system, it is an empty property.
- #interrupt-cells: The number of cells to define the interrupts. It sould be 2.
The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.
Valid combinations are 1, 2, 3, 4, 8.
Default flag for internal sources should be set to 4 (active high).
- reg: Should contain AIC registers location and length
Examples:
/*
* AIC
*/
aic: interrupt-controller@fffff000 {
compatible = "atmel,at91rm9200-aic";
interrupt-controller;
interrupt-parent;
#interrupt-cells = <2>;
reg = <0xfffff000 0x200>;
};
/*
* An interrupt generating device that is wired to an AIC.
*/
dma: dma-controller@ffffec00 {
compatible = "atmel,at91sam9g45-dma";
reg = <0xffffec00 0x200>;
interrupts = <21 4>;
};

32
Documentation/devicetree/bindings/arm/atmel-at91.txt Normal file
View File

@ -0,0 +1,32 @@
Atmel AT91 device tree bindings.
================================
PIT Timer required properties:
- compatible: Should be "atmel,at91sam9260-pit"
- reg: Should contain registers location and length
- interrupts: Should contain interrupt for the PIT which is the IRQ line
shared across all System Controller members.
TC/TCLIB Timer required properties:
- compatible: Should be "atmel,<chip>-pit".
<chip> can be "at91rm9200" or "at91sam9x5"
- reg: Should contain registers location and length
- interrupts: Should contain all interrupts for the TC block
Note that you can specify several interrupt cells if the TC
block has one interrupt per channel.
Examples:
One interrupt per TC block:
tcb0: timer@fff7c000 {
compatible = "atmel,at91rm9200-tcb";
reg = <0xfff7c000 0x100>;
interrupts = <18 4>;
};
One interrupt per TC channel in a TC block:
tcb1: timer@fffdc000 {
compatible = "atmel,at91rm9200-tcb";
reg = <0xfffdc000 0x100>;
interrupts = <26 4 27 4 28 4>;
};

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

@ -28,3 +28,25 @@ Required root node properties:
i.MX6 Quad SABRE Lite Board
Required root node properties:
- compatible = "fsl,imx6q-sabrelite", "fsl,imx6q";
Generic i.MX boards
-------------------
No iomux setup is done for these boards, so this must have been configured
by the bootloader for boards to work with the generic bindings.
i.MX27 generic board
Required root node properties:
- compatible = "fsl,imx27";
i.MX51 generic board
Required root node properties:
- compatible = "fsl,imx51";
i.MX53 generic board
Required root node properties:
- compatible = "fsl,imx53";
i.MX6q generic board
Required root node properties:
- compatible = "fsl,imx6q";

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

@ -0,0 +1,6 @@
Marvell Platforms Device Tree Bindings
----------------------------------------------------
PXA168 Aspenite Board
Required root node properties:
- compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";

27
Documentation/devicetree/bindings/arm/omap/intc.txt Normal file
View File

@ -0,0 +1,27 @@
* OMAP Interrupt Controller
OMAP2/3 are using a TI interrupt controller that can support several
configurable number of interrupts.
Main node required properties:
- compatible : should be:
"ti,omap2-intc"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 1.
The cell contains the interrupt number in the range [0-128].
- ti,intc-size: Number of interrupts handled by the interrupt controller.
- reg: physical base address and size of the intc registers map.
Example:
intc: interrupt-controller@1 {
compatible = "ti,omap2-intc";
interrupt-controller;
#interrupt-cells = <1>;
ti,intc-size = <96>;
reg = <0x48200000 0x1000>;
};

100
Documentation/devicetree/bindings/arm/tegra/emc.txt Normal file
View File

@ -0,0 +1,100 @@
Embedded Memory Controller
Properties:
- name : Should be emc
- #address-cells : Should be 1
- #size-cells : Should be 0
- compatible : Should contain "nvidia,tegra20-emc".
- reg : Offset and length of the register set for the device
- nvidia,use-ram-code : If present, the sub-nodes will be addressed
and chosen using the ramcode board selector. If omitted, only one
set of tables can be present and said tables will be used
irrespective of ram-code configuration.
Child device nodes describe the memory settings for different configurations and clock rates.
Example:
emc@7000f400 {
#address-cells = < 1 >;
#size-cells = < 0 >;
compatible = "nvidia,tegra20-emc";
reg = <0x7000f4000 0x200>;
}
Embedded Memory Controller ram-code table
If the emc node has the nvidia,use-ram-code property present, then the
next level of nodes below the emc table are used to specify which settings
apply for which ram-code settings.
If the emc node lacks the nvidia,use-ram-code property, this level is omitted
and the tables are stored directly under the emc node (see below).
Properties:
- name : Should be emc-tables
- nvidia,ram-code : the binary representation of the ram-code board strappings
for which this node (and children) are valid.
Embedded Memory Controller configuration table
This is a table containing the EMC register settings for the various
operating speeds of the memory controller. They are always located as
subnodes of the emc controller node.
There are two ways of specifying which tables to use:
* The simplest is if there is just one set of tables in the device tree,
and they will always be used (based on which frequency is used).
This is the preferred method, especially when firmware can fill in
this information based on the specific system information and just
pass it on to the kernel.
* The slightly more complex one is when more than one memory configuration
might exist on the system. The Tegra20 platform handles this during
early boot by selecting one out of possible 4 memory settings based
on a 2-pin "ram code" bootstrap setting on the board. The values of
these strappings can be read through a register in the SoC, and thus
used to select which tables to use.
Properties:
- name : Should be emc-table
- compatible : Should contain "nvidia,tegra20-emc-table".
- reg : either an opaque enumerator to tell different tables apart, or
the valid frequency for which the table should be used (in kHz).
- clock-frequency : the clock frequency for the EMC at which this
table should be used (in kHz).
- nvidia,emc-registers : a 46 word array of EMC registers to be programmed
for operation at the 'clock-frequency' setting.
The order and contents of the registers are:
RC, RFC, RAS, RP, R2W, W2R, R2P, W2P, RD_RCD, WR_RCD, RRD, REXT,
WDV, QUSE, QRST, QSAFE, RDV, REFRESH, BURST_REFRESH_NUM, PDEX2WR,
PDEX2RD, PCHG2PDEN, ACT2PDEN, AR2PDEN, RW2PDEN, TXSR, TCKE, TFAW,
TRPAB, TCLKSTABLE, TCLKSTOP, TREFBW, QUSE_EXTRA, FBIO_CFG6, ODT_WRITE,
ODT_READ, FBIO_CFG5, CFG_DIG_DLL, DLL_XFORM_DQS, DLL_XFORM_QUSE,
ZCAL_REF_CNT, ZCAL_WAIT_CNT, AUTO_CAL_INTERVAL, CFG_CLKTRIM_0,
CFG_CLKTRIM_1, CFG_CLKTRIM_2
emc-table@166000 {
reg = <166000>;
compatible = "nvidia,tegra20-emc-table";
clock-frequency = < 166000 >;
nvidia,emc-registers = < 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 >;
};
emc-table@333000 {
reg = <333000>;
compatible = "nvidia,tegra20-emc-table";
clock-frequency = < 333000 >;
nvidia,emc-registers = < 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 >;
};

19
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt Normal file
View File

@ -0,0 +1,19 @@
NVIDIA Tegra Power Management Controller (PMC)
Properties:
- name : Should be pmc
- compatible : Should contain "nvidia,tegra<chip>-pmc".
- reg : Offset and length of the register set for the device
- nvidia,invert-interrupt : If present, inverts the PMU interrupt signal.
The PMU is an external Power Management Unit, whose interrupt output
signal is fed into the PMC. This signal is optionally inverted, and then
fed into the ARM GIC. The PMC is not involved in the detection or
handling of this interrupt signal, merely its inversion.
Example:
pmc@7000f400 {
compatible = "nvidia,tegra20-pmc";
reg = <0x7000e400 0x400>;
nvidia,invert-interrupt;
};

48
Documentation/devicetree/bindings/arm/twd.txt Normal file
View File

@ -0,0 +1,48 @@
* ARM Timer Watchdog
ARM 11MP, Cortex-A5 and Cortex-A9 are often associated with a per-core
Timer-Watchdog (aka TWD), which provides both a per-cpu local timer
and watchdog.
The TWD is usually attached to a GIC to deliver its two per-processor
interrupts.
** Timer node required properties:
- compatible : Should be one of:
"arm,cortex-a9-twd-timer"
"arm,cortex-a5-twd-timer"
"arm,arm11mp-twd-timer"
- interrupts : One interrupt to each core
- reg : Specify the base address and the size of the TWD timer
register window.
Example:
twd-timer@2c000600 {
compatible = "arm,arm11mp-twd-timer"";
reg = <0x2c000600 0x20>;
interrupts = <1 13 0xf01>;
};
** Watchdog node properties:
- compatible : Should be one of:
"arm,cortex-a9-twd-wdt"
"arm,cortex-a5-twd-wdt"
"arm,arm11mp-twd-wdt"
- interrupts : One interrupt to each core
- reg : Specify the base address and the size of the TWD watchdog
register window.
Example:
twd-watchdog@2c000620 {
compatible = "arm,arm11mp-twd-wdt";
reg = <0x2c000620 0x20>;
interrupts = <1 14 0xf01>;
};

146
Documentation/devicetree/bindings/arm/vexpress.txt Normal file
View File

@ -0,0 +1,146 @@
ARM Versatile Express boards family
-----------------------------------
ARM's Versatile Express platform consists of a motherboard and one
or more daughterboards (tiles). The motherboard provides a set of
peripherals. Processor and RAM "live" on the tiles.
The motherboard and each core tile should be described by a separate
Device Tree source file, with the tile's description including
the motherboard file using a /include/ directive. As the motherboard
can be initialized in one of two different configurations ("memory
maps"), care must be taken to include the correct one.
Required properties in the root node:
- compatible value:
compatible = "arm,vexpress,<model>", "arm,vexpress";
where <model> is the full tile model name (as used in the tile's
Technical Reference Manual), eg.:
- for Coretile Express A5x2 (V2P-CA5s):
compatible = "arm,vexpress,v2p-ca5s", "arm,vexpress";
- for Coretile Express A9x4 (V2P-CA9):
compatible = "arm,vexpress,v2p-ca9", "arm,vexpress";
If a tile comes in several variants or can be used in more then one
configuration, the compatible value should be:
compatible = "arm,vexpress,<model>,<variant>", \
"arm,vexpress,<model>", "arm,vexpress";
eg:
- Coretile Express A15x2 (V2P-CA15) with Tech Chip 1:
compatible = "arm,vexpress,v2p-ca15,tc1", \
"arm,vexpress,v2p-ca15", "arm,vexpress";
- LogicTile Express 13MG (V2F-2XV6) running Cortex-A7 (3 cores) SMM:
compatible = "arm,vexpress,v2f-2xv6,ca7x3", \
"arm,vexpress,v2f-2xv6", "arm,vexpress";
Optional properties in the root node:
- tile model name (use name from the tile's Technical Reference
Manual, eg. "V2P-CA5s")
model = "<model>";
- tile's HBI number (unique ARM's board model ID, visible on the
PCB's silkscreen) in hexadecimal transcription:
arm,hbi = <0xhbi>
eg:
- for Coretile Express A5x2 (V2P-CA5s) HBI-0191:
arm,hbi = <0x191>;
- Coretile Express A9x4 (V2P-CA9) HBI-0225:
arm,hbi = <0x225>;
Top-level standard "cpus" node is required. It must contain a node
with device_type = "cpu" property for every available core, eg.:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a5";
reg = <0>;
};
};
The motherboard description file provides a single "motherboard" node
using 2 address cells corresponding to the Static Memory Bus used
between the motherboard and the tile. The first cell defines the Chip
Select (CS) line number, the second cell address offset within the CS.
All interrupt lines between the motherboard and the tile are active
high and are described using single cell.
Optional properties of the "motherboard" node:
- motherboard's memory map variant:
arm,v2m-memory-map = "<name>";
where name is one of:
- "rs1" - for RS1 map (i.a. peripherals on CS3); this map is also
referred to as "ARM Cortex-A Series memory map":
arm,v2m-memory-map = "rs1";
When this property is missing, the motherboard is using the original
memory map (also known as the "Legacy memory map", primarily used
with the original CoreTile Express A9x4) with peripherals on CS7.
Motherboard .dtsi files provide a set of labelled peripherals that
can be used to obtain required phandle in the tile's "aliases" node:
- UARTs, note that the numbers correspond to the physical connectors
on the motherboard's back panel:
v2m_serial0, v2m_serial1, v2m_serial2 and v2m_serial3
- I2C controllers:
v2m_i2c_dvi and v2m_i2c_pcie
- SP804 timers:
v2m_timer01 and v2m_timer23
Current Linux implementation requires a "arm,v2m_timer" alias
pointing at one of the motherboard's SP804 timers, if it is to be
used as the system timer. This alias should be defined in the
motherboard files.
The tile description must define "ranges", "interrupt-map-mask" and
"interrupt-map" properties to translate the motherboard's address
and interrupt space into one used by the tile's processor.
Abbreviated example:
/dts-v1/;
/ {
model = "V2P-CA5s";
arm,hbi = <0x225>;
compatible = "arm,vexpress-v2p-ca5s", "arm,vexpress";
interrupt-parent = <&gic>;
#address-cells = <1>;
#size-cells = <1>;
chosen { };
aliases {
serial0 = &v2m_serial0;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a5";
reg = <0>;
};
};
gic: interrupt-controller@2c001000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
#address-cells = <0>;
interrupt-controller;
reg = <0x2c001000 0x1000>,
<0x2c000100 0x100>;
};
motherboard {
/* CS0 is visible at 0x08000000 */
ranges = <0 0 0x08000000 0x04000000>;
interrupt-map-mask = <0 0 63>;
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = <0 0 0 &gic 0 0 4>;
};
};
/include/ "vexpress-v2m-rs1.dtsi"

30
Documentation/devicetree/bindings/dma/tegra20-apbdma.txt Normal file
View File

@ -0,0 +1,30 @@
* NVIDIA Tegra APB DMA controller
Required properties:
- compatible: Should be "nvidia,<chip>-apbdma"
- reg: Should contain DMA registers location and length. This shuld include
all of the per-channel registers.
- interrupts: Should contain all of the per-channel DMA interrupts.
Examples:
apbdma: dma@6000a000 {
compatible = "nvidia,tegra20-apbdma";
reg = <0x6000a000 0x1200>;
interrupts = < 0 136 0x04
0 137 0x04
0 138 0x04
0 139 0x04
0 140 0x04
0 141 0x04
0 142 0x04
0 143 0x04
0 144 0x04
0 145 0x04
0 146 0x04
0 147 0x04
0 148 0x04
0 149 0x04
0 150 0x04
0 151 0x04 >;
};

20
Documentation/devicetree/bindings/gpio/gpio_atmel.txt Normal file
View File

@ -0,0 +1,20 @@
* Atmel GPIO controller (PIO)
Required properties:
- compatible: "atmel,<chip>-gpio", where <chip> is at91rm9200 or at91sam9x5.
- reg: Should contain GPIO controller registers location and length
- interrupts: Should be the port interrupt shared by all the pins.
- #gpio-cells: Should be two. The first cell is the pin number and
the second cell is used to specify optional parameters (currently
unused).
- gpio-controller: Marks the device node as a GPIO controller.
Example:
pioA: gpio@fffff200 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff200 0x100>;
interrupts = <2 4>;
#gpio-cells = <2>;
gpio-controller;
};

36
Documentation/devicetree/bindings/gpio/gpio_nvidia.txt
View File

@ -1,8 +1,40 @@
NVIDIA Tegra 2 GPIO controller
NVIDIA Tegra GPIO controller
Required properties:
- compatible : "nvidia,tegra20-gpio"
- compatible : "nvidia,tegra<chip>-gpio"
- reg : Physical base address and length of the controller's registers.
- interrupts : The interrupt outputs from the controller. For Tegra20,
there should be 7 interrupts specified, and for Tegra30, there should
be 8 interrupts specified.
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters:
- bit 0 specifies polarity (0 for normal, 1 for inverted)
- gpio-controller : Marks the device node as a GPIO controller.
- #interrupt-cells : Should be 2.
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.
Valid combinations are 1, 2, 3, 4, 8.
- interrupt-controller : Marks the device node as an interrupt controller.
Example:
gpio: gpio@6000d000 {
compatible = "nvidia,tegra20-gpio";
reg = < 0x6000d000 0x1000 >;
interrupts = < 0 32 0x04
0 33 0x04
0 34 0x04
0 35 0x04
0 55 0x04
0 87 0x04
0 89 0x04 >;
#gpio-cells = <2>;
gpio-controller;
#interrupt-cells = <2>;
interrupt-controller;
};

23
Documentation/devicetree/bindings/gpio/mrvl-gpio.txt Normal file
View File

@ -0,0 +1,23 @@
* Marvell PXA GPIO controller
Required properties:
- compatible : Should be "mrvl,pxa-gpio" or "mrvl,mmp-gpio"
- reg : Address and length of the register set for the device
- interrupts : Should be the port interrupt shared by all gpio pins, if
- interrupt-name : Should be the name of irq resource.
one number.
- gpio-controller : Marks the device node as a gpio controller.
- #gpio-cells : Should be one. It is the pin number.
Example:
gpio: gpio@d4019000 {
compatible = "mrvl,mmp-gpio", "mrvl,pxa-gpio";
reg = <0xd4019000 0x1000>;
interrupts = <49>, <17>, <18>;
interrupt-name = "gpio_mux", "gpio0", "gpio1";
gpio-controller;
#gpio-cells = <1>;
interrupt-controller;
#interrupt-cells = <1>;
};

37
Documentation/devicetree/bindings/i2c/mrvl-i2c.txt Normal file
View File

@ -0,0 +1,37 @@
* I2C
Required properties :
- reg : Offset and length of the register set for the device
- compatible : should be "mrvl,mmp-twsi" where CHIP is the name of a
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
Recommended properties :
- interrupts : <a b> where a is the interrupt number and b is a
field that represents an encoding of the sense and level
information for the interrupt. This should be encoded based on
the information in section 2) depending on the type of interrupt
controller you have.
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
- mrvl,i2c-polling : Disable interrupt of i2c controller. Polling
status register of i2c controller instead.
- mrvl,i2c-fast-mode : Enable fast mode of i2c controller.
Examples:
twsi1: i2c@d4011000 {
compatible = "mrvl,mmp-twsi", "mrvl,pxa-i2c";
reg = <0xd4011000 0x1000>;
interrupts = <7>;
mrvl,i2c-fast-mode;
};
twsi2: i2c@d4025000 {
compatible = "mrvl,mmp-twsi", "mrvl,pxa-i2c";
reg = <0xd4025000 0x1000>;
interrupts = <58>;
};

19
Documentation/devicetree/bindings/i2c/sirf-i2c.txt Normal file
View File

@ -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>;
};

19
Documentation/devicetree/bindings/input/matrix-keymap.txt Normal file
View File

@ -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 >;

17
Documentation/devicetree/bindings/input/tegra-kbc.txt
View File

@ -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;
};

17
Documentation/devicetree/bindings/rtc/sa1100-rtc.txt Normal file
View File

@ -0,0 +1,17 @@
* Marvell Real Time Clock controller
Required properties:
- compatible: should be "mrvl,sa1100-rtc"
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: Should be two. The first interrupt number is the rtc alarm
interrupt and the second interrupt number is the rtc hz interrupt.
- interrupt-names: Assign name of irq resource.
Example:
rtc: rtc@d4010000 {
compatible = "mrvl,mmp-rtc";
reg = <0xd4010000 0x1000>;
interrupts = <5>, <6>;
interrupt-name = "rtc 1Hz", "rtc alarm";
};

4
Documentation/devicetree/bindings/serial/mrvl-serial.txt Normal file
View File

@ -0,0 +1,4 @@
PXA UART controller
Required properties:
- compatible : should be "mrvl,mmp-uart" or "mrvl,pxa-uart".

1
Documentation/dvb/cards.txt
View File

@ -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

11
Documentation/dvb/lmedm04.txt
View File

@ -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

4
Documentation/edac.txt
View File

@ -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.

14
Documentation/feature-removal-schedule.txt
View File

@ -513,20 +513,6 @@ Who: Bjorn Helgaas <bhelgaas@google.com>
----------------------------
What: The CAP9 SoC family will be removed
When: 3.4
Files: arch/arm/mach-at91/at91cap9.c
arch/arm/mach-at91/at91cap9_devices.c
arch/arm/mach-at91/include/mach/at91cap9.h
arch/arm/mach-at91/include/mach/at91cap9_matrix.h
arch/arm/mach-at91/include/mach/at91cap9_ddrsdr.h
arch/arm/mach-at91/board-cap9adk.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

8
Documentation/filesystems/ext4.txt
View File

@ -144,9 +144,6 @@ journal_async_commit Commit block can be written to disk without waiting
mount the device. This will enable 'journal_checksum'
internally.
journal=update Update the ext4 file system's journal to the current
format.
journal_dev=devnum When the external journal device's major/minor numbers
have changed, this option allows the user to specify
the new journal location. The journal device is
@ -356,11 +353,6 @@ nouid32 Disables 32-bit UIDs and GIDs. This is for
interoperability with older kernels which only
store and expect 16-bit values.
resize Allows to resize filesystem to the end of the last
existing block group, further resize has to be done
with resize2fs either online, or offline. It can be
used only with conjunction with remount.
block_validity This options allows to enables/disables the in-kernel
noblock_validity facility for tracking filesystem metadata blocks
within internal data structures. This allows multi-

20
Documentation/filesystems/nfs/idmapper.txt
View File

@ -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

54
Documentation/filesystems/nfs/pnfs.txt
View File

@ -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

4
Documentation/hwmon/lm90
View File

@ -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>

50
Documentation/hwmon/mc13783-adc
View File

@ -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

22
Documentation/hwmon/mcp3021 Normal file
View File

@ -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).

39
Documentation/kernel-parameters.txt
View File

@ -1086,8 +1086,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
no_x2apic_optout
BIOS x2APIC opt-out request will be ignored
inttest= [IA-64]
iomem= Disable strict checking of access to MMIO memory
strict regions from userspace.
relaxed
@ -1672,6 +1670,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
of returning the full 64-bit number.
The default is to return 64-bit inode numbers.
nfs.max_session_slots=
[NFSv4.1] Sets the maximum number of session slots
the client will attempt to negotiate with the server.
This limits the number of simultaneous RPC requests
that the client can send to the NFSv4.1 server.
Note that there is little point in setting this
value higher than the max_tcp_slot_table_limit.
nfs.nfs4_disable_idmapping=
[NFSv4] When set to the default of '1', this option
ensures that both the RPC level authentication
@ -1685,6 +1691,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
back to using the idmapper.
To turn off this behaviour, set the value to '0'.
nfs.send_implementation_id =
[NFSv4.1] Send client implementation identification
information in exchange_id requests.
If zero, no implementation identification information
will be sent.
The default is to send the implementation identification
information.
objlayoutdriver.osd_login_prog=
[NFS] [OBJLAYOUT] sets the pathname to the program which
is used to automatically discover and login into new
osd-targets. Please see:
Documentation/filesystems/pnfs.txt for more explanations
nmi_debug= [KNL,AVR32,SH] Specify one or more actions to take
when a NMI is triggered.
Format: [state][,regs][,debounce][,die]
@ -2124,8 +2145,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
the default.
off: Turn ECRC off
on: Turn ECRC on.
realloc reallocate PCI resources if allocations done by BIOS
are erroneous.
realloc= Enable/disable reallocating PCI bridge resources
if allocations done by BIOS are too small to
accommodate resources required by all child
devices.
off: Turn realloc off
on: Turn realloc on
realloc same as realloc=on
noari do not use PCIe ARI.
pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power
Management.
@ -2133,6 +2160,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
force Enable ASPM even on devices that claim not to support it.
WARNING: Forcing ASPM on may cause system lockups.
pcie_hp= [PCIE] PCI Express Hotplug driver options:
nomsi Do not use MSI for PCI Express Native Hotplug (this
makes all PCIe ports use INTx for hotplug services).
pcie_ports= [PCIE] PCIe ports handling:
auto Ask the BIOS whether or not to use native PCIe services
associated with PCIe ports (PME, hot-plug, AER). Use

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

@ -43,17 +43,23 @@ Format: 10x mA i.e 10 means 1.0 mA
example platform data:
Note: chan_nr can have values between 0 and 2.
The name of each channel can be configurable.
If the name field is not defined, the default name will be set to 'xxxx:channelN'
(XXXX : pdata->label or i2c client name, N : channel number)
static struct lp5521_led_config lp5521_led_config[] = {
{
.name = "red",
.chan_nr = 0,
.led_current = 50,
.max_current = 130,
}, {
.name = "green",
.chan_nr = 1,
.led_current = 0,
.max_current = 130,
}, {
.name = "blue",
.chan_nr = 2,
.led_current = 0,
.max_current = 130,
@ -86,3 +92,60 @@ static struct lp5521_platform_data lp5521_platform_data = {
If the current is set to 0 in the platform data, that channel is
disabled and it is not visible in the sysfs.
The 'update_config' : CONFIG register (ADDR 08h)
This value is platform-specific data.
If update_config is not defined, the CONFIG register is set with
'LP5521_PWRSAVE_EN | LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT'.
(Enable auto-powersave, set charge pump to auto, red to battery)
example of update_config :
#define LP5521_CONFIGS (LP5521_PWM_HF | LP5521_PWRSAVE_EN | \
LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \
LP5521_CLK_INT)
static struct lp5521_platform_data lp5521_pdata = {
.led_config = lp5521_led_config,
.num_channels = ARRAY_SIZE(lp5521_led_config),
.clock_mode = LP5521_CLOCK_INT,
.update_config = LP5521_CONFIGS,
};
LED patterns : LP5521 has autonomous operation without external control.
Pattern data can be defined in the platform data.
example of led pattern data :
/* RGB(50,5,0) 500ms on, 500ms off, infinite loop */
static u8 pattern_red[] = {
0x40, 0x32, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00,
};
static u8 pattern_green[] = {
0x40, 0x05, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00,
};
static struct lp5521_led_pattern board_led_patterns[] = {
{
.r = pattern_red,
.g = pattern_green,
.size_r = ARRAY_SIZE(pattern_red),
.size_g = ARRAY_SIZE(pattern_green),
},
};
static struct lp5521_platform_data lp5521_platform_data = {
.led_config = lp5521_led_config,
.num_channels = ARRAY_SIZE(lp5521_led_config),
.clock_mode = LP5521_CLOCK_EXT,
.patterns = board_led_patterns,
.num_patterns = ARRAY_SIZE(board_led_patterns),
};
Then predefined led pattern(s) can be executed via the sysfs.
To start the pattern #1,
# echo 1 > /sys/bus/i2c/devices/xxxx/led_pattern
(xxxx : i2c bus & slave address)
To end the pattern,
# echo 0 > /sys/bus/i2c/devices/xxxx/led_pattern

311
Documentation/pinctrl.txt
View File

@ -206,12 +206,21 @@ using a certain resistor value - pull up and pull down - so that the pin has a
stable value when nothing is driving the rail it is connected to, or when it's
unconnected.
For example, a platform may do this:
Pin configuration can be programmed either using the explicit APIs described
immediately below, or by adding configuration entries into the mapping table;
see section "Board/machine configuration" below.
For example, a platform may do the following to pull up a pin to VDD:
#include <linux/pinctrl/consumer.h>
ret = pin_config_set("foo-dev", "FOO_GPIO_PIN", PLATFORM_X_PULL_UP);
To pull up a pin to VDD. The pin configuration driver implements callbacks for
changing pin configuration in the pin controller ops like this:
The format and meaning of the configuration parameter, PLATFORM_X_PULL_UP
above, is entirely defined by the pin controller driver.
The pin configuration driver implements callbacks for changing pin
configuration in the pin controller ops like this:
#include <linux/pinctrl/pinctrl.h>
#include <linux/pinctrl/pinconf.h>
@ -492,14 +501,10 @@ Definitions:
{"map-i2c0", i2c0, pinctrl0, fi2c0, gi2c0}
}
Every map must be assigned a symbolic name, pin controller and function.
The group is not compulsory - if it is omitted the first group presented by
the driver as applicable for the function will be selected, which is
useful for simple cases.
The device name is present in map entries tied to specific devices. Maps
without device names are referred to as SYSTEM pinmuxes, such as can be taken
by the machine implementation on boot and not tied to any specific device.
Every map must be assigned a state name, pin controller, device and
function. The group is not compulsory - if it is omitted the first group
presented by the driver as applicable for the function will be selected,
which is useful for simple cases.
It is possible to map several groups to the same combination of device,
pin controller and function. This is for cases where a certain function on
@ -726,19 +731,19 @@ same time.
All the above functions are mandatory to implement for a pinmux driver.
Pinmux interaction with the GPIO subsystem
==========================================
Pin control interaction with the GPIO subsystem
===============================================
The public pinmux API contains two functions named pinmux_request_gpio()
and pinmux_free_gpio(). These two functions shall *ONLY* be called from
The public pinmux API contains two functions named pinctrl_request_gpio()
and pinctrl_free_gpio(). These two functions shall *ONLY* be called from
gpiolib-based drivers as part of their gpio_request() and
gpio_free() semantics. Likewise the pinmux_gpio_direction_[input|output]
gpio_free() semantics. Likewise the pinctrl_gpio_direction_[input|output]
shall only be called from within respective gpio_direction_[input|output]
gpiolib implementation.
NOTE that platforms and individual drivers shall *NOT* request GPIO pins to be
muxed in. Instead, implement a proper gpiolib driver and have that driver
request proper muxing for its pins.
controlled e.g. muxed in. Instead, implement a proper gpiolib driver and have
that driver request proper muxing and other control for its pins.
The function list could become long, especially if you can convert every
individual pin into a GPIO pin independent of any other pins, and then try
@ -747,7 +752,7 @@ the approach to define every pin as a function.
In this case, the function array would become 64 entries for each GPIO
setting and then the device functions.
For this reason there are two functions a pinmux driver can implement
For this reason there are two functions a pin control driver can implement
to enable only GPIO on an individual pin: .gpio_request_enable() and
.gpio_disable_free().
@ -762,12 +767,12 @@ gpiolib driver and the affected GPIO range, pin offset and desired direction
will be passed along to this function.
Alternatively to using these special functions, it is fully allowed to use
named functions for each GPIO pin, the pinmux_request_gpio() will attempt to
named functions for each GPIO pin, the pinctrl_request_gpio() will attempt to
obtain the function "gpioN" where "N" is the global GPIO pin number if no
special GPIO-handler is registered.
Pinmux board/machine configuration
Board/machine configuration
==================================
Boards and machines define how a certain complete running system is put
@ -775,27 +780,33 @@ together, including how GPIOs and devices are muxed, how regulators are
constrained and how the clock tree looks. Of course pinmux settings are also
part of this.
A pinmux config for a machine looks pretty much like a simple regulator
configuration, so for the example array above we want to enable i2c and
spi on the second function mapping:
A pin controller configuration for a machine looks pretty much like a simple
regulator configuration, so for the example array above we want to enable i2c
and spi on the second function mapping:
#include <linux/pinctrl/machine.h>
static const struct pinmux_map __initdata pmx_mapping[] = {
static const struct pinctrl_map __initdata mapping[] = {
{
.ctrl_dev_name = "pinctrl-foo",
.function = "spi0",
.dev_name = "foo-spi.0",
.name = PINCTRL_STATE_DEFAULT,
.type = PIN_MAP_TYPE_MUX_GROUP,
.ctrl_dev_name = "pinctrl-foo",
.data.mux.function = "spi0",
},
{
.ctrl_dev_name = "pinctrl-foo",
.function = "i2c0",
.dev_name = "foo-i2c.0",
.name = PINCTRL_STATE_DEFAULT,
.type = PIN_MAP_TYPE_MUX_GROUP,
.ctrl_dev_name = "pinctrl-foo",
.data.mux.function = "i2c0",
},
{
.ctrl_dev_name = "pinctrl-foo",
.function = "mmc0",
.dev_name = "foo-mmc.0",
.name = PINCTRL_STATE_DEFAULT,
.type = PIN_MAP_TYPE_MUX_GROUP,
.ctrl_dev_name = "pinctrl-foo",
.data.mux.function = "mmc0",
},
};
@ -805,21 +816,51 @@ must match a function provided by the pinmux driver handling this pin range.
As you can see we may have several pin controllers on the system and thus
we need to specify which one of them that contain the functions we wish
to map. The map can also use struct device * directly, so there is no
inherent need to use strings to specify .dev_name or .ctrl_dev_name, these
are for the situation where you do not have a handle to the struct device *,
for example if they are not yet instantiated or cumbersome to obtain.
to map.
You register this pinmux mapping to the pinmux subsystem by simply:
ret = pinmux_register_mappings(pmx_mapping, ARRAY_SIZE(pmx_mapping));
ret = pinctrl_register_mappings(mapping, ARRAY_SIZE(mapping));
Since the above construct is pretty common there is a helper macro to make
it even more compact which assumes you want to use pinctrl-foo and position
0 for mapping, for example:
static struct pinmux_map __initdata pmx_mapping[] = {
PINMUX_MAP("I2CMAP", "pinctrl-foo", "i2c0", "foo-i2c.0"),
static struct pinctrl_map __initdata mapping[] = {
PIN_MAP_MUX_GROUP("foo-i2c.o", PINCTRL_STATE_DEFAULT, "pinctrl-foo", NULL, "i2c0"),
};
The mapping table may also contain pin configuration entries. It's common for
each pin/group to have a number of configuration entries that affect it, so
the table entries for configuration reference an array of config parameters
and values. An example using the convenience macros is shown below:
static unsigned long i2c_grp_configs[] = {
FOO_PIN_DRIVEN,
FOO_PIN_PULLUP,
};
static unsigned long i2c_pin_configs[] = {
FOO_OPEN_COLLECTOR,
FOO_SLEW_RATE_SLOW,
};
static struct pinctrl_map __initdata mapping[] = {
PIN_MAP_MUX_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", "i2c0"),
PIN_MAP_MUX_CONFIGS_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", i2c_grp_configs),
PIN_MAP_MUX_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0scl", i2c_pin_configs),
PIN_MAP_MUX_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0sda", i2c_pin_configs),
};
Finally, some devices expect the mapping table to contain certain specific
named states. When running on hardware that doesn't need any pin controller
configuration, the mapping table must still contain those named states, in
order to explicitly indicate that the states were provided and intended to
be empty. Table entry macro PIN_MAP_DUMMY_STATE serves the purpose of defining
a named state without causing any pin controller to be programmed:
static struct pinctrl_map __initdata mapping[] = {
PIN_MAP_DUMMY_STATE("foo-i2c.0", PINCTRL_STATE_DEFAULT),
};
@ -831,81 +872,96 @@ As it is possible to map a function to different groups of pins an optional
...
{
.dev_name = "foo-spi.0",
.name = "spi0-pos-A",
.type = PIN_MAP_TYPE_MUX_GROUP,
.ctrl_dev_name = "pinctrl-foo",
.function = "spi0",
.group = "spi0_0_grp",
.dev_name = "foo-spi.0",
},
{
.dev_name = "foo-spi.0",
.name = "spi0-pos-B",
.type = PIN_MAP_TYPE_MUX_GROUP,
.ctrl_dev_name = "pinctrl-foo",
.function = "spi0",
.group = "spi0_1_grp",
.dev_name = "foo-spi.0",
},
...
This example mapping is used to switch between two positions for spi0 at
runtime, as described further below under the heading "Runtime pinmuxing".
Further it is possible to match several groups of pins to the same function
for a single device, say for example in the mmc0 example above, where you can
Further it is possible for one named state to affect the muxing of several
groups of pins, say for example in the mmc0 example above, where you can
additively expand the mmc0 bus from 2 to 4 to 8 pins. If we want to use all
three groups for a total of 2+2+4 = 8 pins (for an 8-bit MMC bus as is the
case), we define a mapping like this:
...
{
.dev_name = "foo-mmc.0",
.name = "2bit"
.type = PIN_MAP_TYPE_MUX_GROUP,
.ctrl_dev_name = "pinctrl-foo",
.function = "mmc0",
.group = "mmc0_1_grp",
.dev_name = "foo-mmc.0",
},
{
.dev_name = "foo-mmc.0",
.name = "4bit"
.type = PIN_MAP_TYPE_MUX_GROUP,
.ctrl_dev_name = "pinctrl-foo",
.function = "mmc0",
.group = "mmc0_1_grp",
.dev_name = "foo-mmc.0",
},
{
.dev_name = "foo-mmc.0",
.name = "4bit"
.type = PIN_MAP_TYPE_MUX_GROUP,
.ctrl_dev_name = "pinctrl-foo",
.function = "mmc0",
.group = "mmc0_2_grp",
.dev_name = "foo-mmc.0",
},
{
.dev_name = "foo-mmc.0",
.name = "8bit"
.type = PIN_MAP_TYPE_MUX_GROUP,
.ctrl_dev_name = "pinctrl-foo",
.function = "mmc0",
.group = "mmc0_1_grp",
.dev_name = "foo-mmc.0",
},
{
.dev_name = "foo-mmc.0",
.name = "8bit"
.type = PIN_MAP_TYPE_MUX_GROUP,
.ctrl_dev_name = "pinctrl-foo",
.function = "mmc0",
.group = "mmc0_2_grp",
.dev_name = "foo-mmc.0",
},
{
.dev_name = "foo-mmc.0",
.name = "8bit"
.type = PIN_MAP_TYPE_MUX_GROUP,
.ctrl_dev_name = "pinctrl-foo",
.function = "mmc0",
.group = "mmc0_3_grp",
.dev_name = "foo-mmc.0",
},
...
The result of grabbing this mapping from the device with something like
this (see next paragraph):
pmx = pinmux_get(&device, "8bit");
p = pinctrl_get(dev);
s = pinctrl_lookup_state(p, "8bit");
ret = pinctrl_select_state(p, s);
or more simply:
p = pinctrl_get_select(dev, "8bit");
Will be that you activate all the three bottom records in the mapping at
once. Since they share the same name, pin controller device, funcion and
once. Since they share the same name, pin controller device, function and
device, and since we allow multiple groups to match to a single device, they
all get selected, and they all get enabled and disable simultaneously by the
pinmux core.
@ -914,97 +970,111 @@ pinmux core.
Pinmux requests from drivers
============================
Generally it is discouraged to let individual drivers get and enable pinmuxes.
So if possible, handle the pinmuxes in platform code or some other place where
you have access to all the affected struct device * pointers. In some cases
where a driver needs to switch between different mux mappings at runtime
this is not possible.
Generally it is discouraged to let individual drivers get and enable pin
control. So if possible, handle the pin control in platform code or some other
place where you have access to all the affected struct device * pointers. In
some cases where a driver needs to e.g. switch between different mux mappings
at runtime this is not possible.
A driver may request a certain mux to be activated, usually just the default
mux like this:
A driver may request a certain control state to be activated, usually just the
default state like this:
#include <linux/pinctrl/pinmux.h>
#include <linux/pinctrl/consumer.h>
struct foo_state {
struct pinmux *pmx;
struct pinctrl *p;
struct pinctrl_state *s;
...
};
foo_probe()
{
/* Allocate a state holder named "state" etc */
struct pinmux pmx;
/* Allocate a state holder named "foo" etc */
struct foo_state *foo = ...;
pmx = pinmux_get(&device, NULL);
if IS_ERR(pmx)
return PTR_ERR(pmx);
pinmux_enable(pmx);
foo->p = pinctrl_get(&device);
if (IS_ERR(foo->p)) {
/* FIXME: clean up "foo" here */
return PTR_ERR(foo->p);
}
state->pmx = pmx;
foo->s = pinctrl_lookup_state(foo->p, PINCTRL_STATE_DEFAULT);
if (IS_ERR(foo->s)) {
pinctrl_put(foo->p);
/* FIXME: clean up "foo" here */
return PTR_ERR(s);
}
ret = pinctrl_select_state(foo->s);
if (ret < 0) {
pinctrl_put(foo->p);
/* FIXME: clean up "foo" here */
return ret;
}
}
foo_remove()
{
pinmux_disable(state->pmx);
pinmux_put(state->pmx);
pinctrl_put(state->p);
}
If you want to grab a specific mux mapping and not just the first one found for
this device you can specify a specific mapping name, for example in the above
example the second i2c0 setting: pinmux_get(&device, "spi0-pos-B");
This get/enable/disable/put sequence can just as well be handled by bus drivers
This get/lookup/select/put sequence can just as well be handled by bus drivers
if you don't want each and every driver to handle it and you know the
arrangement on your bus.
The semantics of the get/enable respective disable/put is as follows:
The semantics of the pinctrl APIs are:
- pinmux_get() is called in process context to reserve the pins affected with
a certain mapping and set up the pinmux core and the driver. It will allocate
a struct from the kernel memory to hold the pinmux state.
- pinctrl_get() is called in process context to obtain a handle to all pinctrl
information for a given client device. It will allocate a struct from the
kernel memory to hold the pinmux state. All mapping table parsing or similar
slow operations take place within this API.
- pinmux_enable()/pinmux_disable() is quick and can be called from fastpath
(irq context) when you quickly want to set up/tear down the hardware muxing
when running a device driver. Usually it will just poke some values into a
register.
- pinctrl_lookup_state() is called in process context to obtain a handle to a
specific state for a the client device. This operation may be slow too.
- pinmux_disable() is called in process context to tear down the pin requests
and release the state holder struct for the mux setting.
- pinctrl_select_state() programs pin controller hardware according to the
definition of the state as given by the mapping table. In theory this is a
fast-path operation, since it only involved blasting some register settings
into hardware. However, note that some pin controllers may have their
registers on a slow/IRQ-based bus, so client devices should not assume they
can call pinctrl_select_state() from non-blocking contexts.
Usually the pinmux core handled the get/put pair and call out to the device
drivers bookkeeping operations, like checking available functions and the
associated pins, whereas the enable/disable pass on to the pin controller
- pinctrl_put() frees all information associated with a pinctrl handle.
Usually the pin control core handled the get/put pair and call out to the
device drivers bookkeeping operations, like checking available functions and
the associated pins, whereas the enable/disable pass on to the pin controller
driver which takes care of activating and/or deactivating the mux setting by
quickly poking some registers.
The pins are allocated for your device when you issue the pinmux_get() call,
The pins are allocated for your device when you issue the pinctrl_get() call,
after this you should be able to see this in the debugfs listing of all pins.
System pinmux hogging
=====================
System pin control hogging
==========================
A system pinmux map entry, i.e. a pinmux setting that does not have a device
associated with it, can be hogged by the core when the pin controller is
registered. This means that the core will attempt to call pinmux_get() and
pinmux_enable() on it immediately after the pin control device has been
registered.
Pin control map entries can be hogged by the core when the pin controller
is registered. This means that the core will attempt to call pinctrl_get(),
lookup_state() and select_state() on it immediately after the pin control
device has been registered.
This is enabled by simply setting the .hog_on_boot field in the map to true,
like this:
This occurs for mapping table entries where the client device name is equal
to the pin controller device name, and the state name is PINCTRL_STATE_DEFAULT.
{
.name = "POWERMAP"
.dev_name = "pinctrl-foo",
.name = PINCTRL_STATE_DEFAULT,
.type = PIN_MAP_TYPE_MUX_GROUP,
.ctrl_dev_name = "pinctrl-foo",
.function = "power_func",
.hog_on_boot = true,
},
Since it may be common to request the core to hog a few always-applicable
mux settings on the primary pin controller, there is a convenience macro for
this:
PINMUX_MAP_PRIMARY_SYS_HOG("POWERMAP", "power_func")
PIN_MAP_MUX_GROUP_HOG_DEFAULT("pinctrl-foo", NULL /* group */, "power_func")
This gives the exact same result as the above construction.
@ -1016,32 +1086,47 @@ It is possible to mux a certain function in and out at runtime, say to move
an SPI port from one set of pins to another set of pins. Say for example for
spi0 in the example above, we expose two different groups of pins for the same
function, but with different named in the mapping as described under
"Advanced mapping" above. So we have two mappings named "spi0-pos-A" and
"spi0-pos-B".
"Advanced mapping" above. So that for an SPI device, we have two states named
"pos-A" and "pos-B".
This snippet first muxes the function in the pins defined by group A, enables
it, disables and releases it, and muxes it in on the pins defined by group B:
#include <linux/pinctrl/consumer.h>
foo_switch()
{
struct pinmux *pmx;
struct pinctrl *p;
struct pinctrl_state *s1, *s2;
/* Setup */
p = pinctrl_get(&device);
if (IS_ERR(p))
...
s1 = pinctrl_lookup_state(foo->p, "pos-A");
if (IS_ERR(s1))
...
s2 = pinctrl_lookup_state(foo->p, "pos-B");
if (IS_ERR(s2))
...
/* Enable on position A */
pmx = pinmux_get(&device, "spi0-pos-A");
if IS_ERR(pmx)
return PTR_ERR(pmx);
pinmux_enable(pmx);
ret = pinctrl_select_state(s1);
if (ret < 0)
...
/* This releases the pins again */
pinmux_disable(pmx);
pinmux_put(pmx);
...
/* Enable on position B */
pmx = pinmux_get(&device, "spi0-pos-B");
if IS_ERR(pmx)
return PTR_ERR(pmx);
pinmux_enable(pmx);
ret = pinctrl_select_state(s2);
if (ret < 0)
...
...
pinctrl_put(p);
}
The above has to be done from process context.

322
Documentation/remoteproc.txt Normal file
View File

@ -0,0 +1,322 @@
Remote Processor Framework
1. Introduction
Modern SoCs typically have heterogeneous remote processor devices in asymmetric
multiprocessing (AMP) configurations, which may be running different instances
of operating system, whether it's Linux or any other flavor of real-time OS.
OMAP4, for example, has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP.
In a typical configuration, the dual cortex-A9 is running Linux in a SMP
configuration, and each of the other three cores (two M3 cores and a DSP)
is running its own instance of RTOS in an AMP configuration.
The remoteproc framework allows different platforms/architectures to
control (power on, load firmware, power off) those remote processors while
abstracting the hardware differences, so the entire driver doesn't need to be
duplicated. In addition, this framework also adds rpmsg virtio devices
for remote processors that supports this kind of communication. This way,
platform-specific remoteproc drivers only need to provide a few low-level
handlers, and then all rpmsg drivers will then just work
(for more information about the virtio-based rpmsg bus and its drivers,
please read Documentation/rpmsg.txt).
Registration of other types of virtio devices is now also possible. Firmwares
just need to publish what kind of virtio devices do they support, and then
remoteproc will add those devices. This makes it possible to reuse the
existing virtio drivers with remote processor backends at a minimal development
cost.
2. User API
int rproc_boot(struct rproc *rproc)
- Boot a remote processor (i.e. load its firmware, power it on, ...).
If the remote processor is already powered on, this function immediately
returns (successfully).
Returns 0 on success, and an appropriate error value otherwise.
Note: to use this function you should already have a valid rproc
handle. There are several ways to achieve that cleanly (devres, pdata,
the way remoteproc_rpmsg.c does this, or, if this becomes prevalent, we
might also consider using dev_archdata for this). See also
rproc_get_by_name() below.
void rproc_shutdown(struct rproc *rproc)
- Power off a remote processor (previously booted with rproc_boot()).
In case @rproc is still being used by an additional user(s), then
this function will just decrement the power refcount and exit,
without really powering off the device.
Every call to rproc_boot() must (eventually) be accompanied by a call
to rproc_shutdown(). Calling rproc_shutdown() redundantly is a bug.
Notes:
- we're not decrementing the rproc's refcount, only the power refcount.
which means that the @rproc handle stays valid even after
rproc_shutdown() returns, and users can still use it with a subsequent
rproc_boot(), if needed.
- don't call rproc_shutdown() to unroll rproc_get_by_name(), exactly
because rproc_shutdown() _does not_ decrement the refcount of @rproc.
To decrement the refcount of @rproc, use rproc_put() (but _only_ if
you acquired @rproc using rproc_get_by_name()).
struct rproc *rproc_get_by_name(const char *name)
- Find an rproc handle using the remote processor's name, and then
boot it. If it's already powered on, then just immediately return
(successfully). Returns the rproc handle on success, and NULL on failure.
This function increments the remote processor's refcount, so always
use rproc_put() to decrement it back once rproc isn't needed anymore.
Note: currently rproc_get_by_name() and rproc_put() are not used anymore
by the rpmsg bus and its drivers. We need to scrutinize the use cases
that still need them, and see if we can migrate them to use the non
name-based boot/shutdown interface.
void rproc_put(struct rproc *rproc)
- Decrement @rproc's power refcount and shut it down if it reaches zero
(essentially by just calling rproc_shutdown), and then decrement @rproc's
validity refcount too.
After this function returns, @rproc may _not_ be used anymore, and its
handle should be considered invalid.
This function should be called _iff_ the @rproc handle was grabbed by
calling rproc_get_by_name().
3. Typical usage
#include <linux/remoteproc.h>
/* in case we were given a valid 'rproc' handle */
int dummy_rproc_example(struct rproc *my_rproc)
{
int ret;
/* let's power on and boot our remote processor */
ret = rproc_boot(my_rproc);
if (ret) {
/*
* something went wrong. handle it and leave.
*/
}
/*
* our remote processor is now powered on... give it some work
*/
/* let's shut it down now */
rproc_shutdown(my_rproc);
}
4. API for implementors
struct rproc *rproc_alloc(struct device *dev, const char *name,
const struct rproc_ops *ops,
const char *firmware, int len)
- Allocate a new remote processor handle, but don't register
it yet. Required parameters are the underlying device, the
name of this remote processor, platform-specific ops handlers,
the name of the firmware to boot this rproc with, and the
length of private data needed by the allocating rproc driver (in bytes).
This function should be used by rproc implementations during
initialization of the remote processor.
After creating an rproc handle using this function, and when ready,
implementations should then call rproc_register() to complete
the registration of the remote processor.
On success, the new rproc is returned, and on failure, NULL.
Note: _never_ directly deallocate @rproc, even if it was not registered
yet. Instead, if you just need to unroll rproc_alloc(), use rproc_free().
void rproc_free(struct rproc *rproc)
- Free an rproc handle that was allocated by rproc_alloc.
This function should _only_ be used if @rproc was only allocated,
but not registered yet.
If @rproc was already successfully registered (by calling
rproc_register()), then use rproc_unregister() instead.
int rproc_register(struct rproc *rproc)
- Register @rproc with the remoteproc framework, after it has been
allocated with rproc_alloc().
This is called by the platform-specific rproc implementation, whenever
a new remote processor device is probed.
Returns 0 on success and an appropriate error code otherwise.
Note: this function initiates an asynchronous firmware loading
context, which will look for virtio devices supported by the rproc's
firmware.
If found, those virtio devices will be created and added, so as a result
of registering this remote processor, additional virtio drivers might get
probed.
int rproc_unregister(struct rproc *rproc)
- Unregister a remote processor, and decrement its refcount.
If its refcount drops to zero, then @rproc will be freed. If not,
it will be freed later once the last reference is dropped.
This function should be called when the platform specific rproc
implementation decides to remove the rproc device. it should
_only_ be called if a previous invocation of rproc_register()
has completed successfully.
After rproc_unregister() returns, @rproc is _not_ valid anymore and
it shouldn't be used. More specifically, don't call rproc_free()
or try to directly free @rproc after rproc_unregister() returns;
none of these are needed, and calling them is a bug.
Returns 0 on success and -EINVAL if @rproc isn't valid.
5. Implementation callbacks
These callbacks should be provided by platform-specific remoteproc
drivers:
/**
* struct rproc_ops - platform-specific device handlers
* @start: power on the device and boot it
* @stop: power off the device
* @kick: kick a virtqueue (virtqueue id given as a parameter)
*/
struct rproc_ops {
int (*start)(struct rproc *rproc);
int (*stop)(struct rproc *rproc);
void (*kick)(struct rproc *rproc, int vqid);
};
Every remoteproc implementation should at least provide the ->start and ->stop
handlers. If rpmsg/virtio functionality is also desired, then the ->kick handler
should be provided as well.
The ->start() handler takes an rproc handle and should then power on the
device and boot it (use rproc->priv to access platform-specific private data).
The boot address, in case needed, can be found in rproc->bootaddr (remoteproc
core puts there the ELF entry point).
On success, 0 should be returned, and on failure, an appropriate error code.
The ->stop() handler takes an rproc handle and powers the device down.
On success, 0 is returned, and on failure, an appropriate error code.
The ->kick() handler takes an rproc handle, and an index of a virtqueue
where new message was placed in. Implementations should interrupt the remote
processor and let it know it has pending messages. Notifying remote processors
the exact virtqueue index to look in is optional: it is easy (and not
too expensive) to go through the existing virtqueues and look for new buffers
in the used rings.
6. Binary Firmware Structure
At this point remoteproc only supports ELF32 firmware binaries. However,
it is quite expected that other platforms/devices which we'd want to
support with this framework will be based on different binary formats.
When those use cases show up, we will have to decouple the binary format
from the framework core, so we can support several binary formats without
duplicating common code.
When the firmware is parsed, its various segments are loaded to memory
according to the specified device address (might be a physical address
if the remote processor is accessing memory directly).
In addition to the standard ELF segments, most remote processors would
also include a special section which we call "the resource table".
The resource table contains system resources that the remote processor
requires before it should be powered on, such as allocation of physically
contiguous memory, or iommu mapping of certain on-chip peripherals.
Remotecore will only power up the device after all the resource table's
requirement are met.
In addition to system resources, the resource table may also contain
resource entries that publish the existence of supported features
or configurations by the remote processor, such as trace buffers and
supported virtio devices (and their configurations).
The resource table begins with this header:
/**
* struct resource_table - firmware resource table header
* @ver: version number
* @num: number of resource entries
* @reserved: reserved (must be zero)
* @offset: array of offsets pointing at the various resource entries
*
* The header of the resource table, as expressed by this structure,
* contains a version number (should we need to change this format in the
* future), the number of available resource entries, and their offsets
* in the table.
*/
struct resource_table {
u32 ver;
u32 num;
u32 reserved[2];
u32 offset[0];
} __packed;
Immediately following this header are the resource entries themselves,
each of which begins with the following resource entry header:
/**
* struct fw_rsc_hdr - firmware resource entry header
* @type: resource type
* @data: resource data
*
* Every resource entry begins with a 'struct fw_rsc_hdr' header providing
* its @type. The content of the entry itself will immediately follow
* this header, and it should be parsed according to the resource type.
*/
struct fw_rsc_hdr {
u32 type;
u8 data[0];
} __packed;
Some resources entries are mere announcements, where the host is informed
of specific remoteproc configuration. Other entries require the host to
do something (e.g. allocate a system resource). Sometimes a negotiation
is expected, where the firmware requests a resource, and once allocated,
the host should provide back its details (e.g. address of an allocated
memory region).
Here are the various resource types that are currently supported:
/**
* enum fw_resource_type - types of resource entries
*
* @RSC_CARVEOUT: request for allocation of a physically contiguous
* memory region.
* @RSC_DEVMEM: request to iommu_map a memory-based peripheral.
* @RSC_TRACE: announces the availability of a trace buffer into which
* the remote processor will be writing logs.
* @RSC_VDEV: declare support for a virtio device, and serve as its
* virtio header.
* @RSC_LAST: just keep this one at the end
*
* Please note that these values are used as indices to the rproc_handle_rsc
* lookup table, so please keep them sane. Moreover, @RSC_LAST is used to
* check the validity of an index before the lookup table is accessed, so
* please update it as needed.
*/
enum fw_resource_type {
RSC_CARVEOUT = 0,
RSC_DEVMEM = 1,
RSC_TRACE = 2,
RSC_VDEV = 3,
RSC_LAST = 4,
};
For more details regarding a specific resource type, please see its
dedicated structure in include/linux/remoteproc.h.
We also expect that platform-specific resource entries will show up
at some point. When that happens, we could easily add a new RSC_PLATFORM
type, and hand those resources to the platform-specific rproc driver to handle.
7. Virtio and remoteproc
The firmware should provide remoteproc information about virtio devices
that it supports, and their configurations: a RSC_VDEV resource entry
should specify the virtio device id (as in virtio_ids.h), virtio features,
virtio config space, vrings information, etc.
When a new remote processor is registered, the remoteproc framework
will look for its resource table and will register the virtio devices
it supports. A firmware may support any number of virtio devices, and
of any type (a single remote processor can also easily support several
rpmsg virtio devices this way, if desired).
Of course, RSC_VDEV resource entries are only good enough for static
allocation of virtio devices. Dynamic allocations will also be made possible
using the rpmsg bus (similar to how we already do dynamic allocations of
rpmsg channels; read more about it in rpmsg.txt).

293
Documentation/rpmsg.txt Normal file
View File

@ -0,0 +1,293 @@
Remote Processor Messaging (rpmsg) Framework
Note: this document describes the rpmsg bus and how to write rpmsg drivers.
To learn how to add rpmsg support for new platforms, check out remoteproc.txt
(also a resident of Documentation/).
1. Introduction
Modern SoCs typically employ heterogeneous remote processor devices in
asymmetric multiprocessing (AMP) configurations, which may be running
different instances of operating system, whether it's Linux or any other
flavor of real-time OS.
OMAP4, for example, has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP.
Typically, the dual cortex-A9 is running Linux in a SMP configuration,
and each of the other three cores (two M3 cores and a DSP) is running
its own instance of RTOS in an AMP configuration.
Typically AMP remote processors employ dedicated DSP codecs and multimedia
hardware accelerators, and therefore are often used to offload CPU-intensive
multimedia tasks from the main application processor.
These remote processors could also be used to control latency-sensitive
sensors, drive random hardware blocks, or just perform background tasks
while the main CPU is idling.
Users of those remote processors can either be userland apps (e.g. multimedia
frameworks talking with remote OMX components) or kernel drivers (controlling
hardware accessible only by the remote processor, reserving kernel-controlled
resources on behalf of the remote processor, etc..).
Rpmsg is a virtio-based messaging bus that allows kernel drivers to communicate
with remote processors available on the system. In turn, drivers could then
expose appropriate user space interfaces, if needed.
When writing a driver that exposes rpmsg communication to userland, please
keep in mind that remote processors might have direct access to the
system's physical memory and other sensitive hardware resources (e.g. on
OMAP4, remote cores and hardware accelerators may have direct access to the
physical memory, gpio banks, dma controllers, i2c bus, gptimers, mailbox
devices, hwspinlocks, etc..). Moreover, those remote processors might be
running RTOS where every task can access the entire memory/devices exposed
to the processor. To minimize the risks of rogue (or buggy) userland code
exploiting remote bugs, and by that taking over the system, it is often
desired to limit userland to specific rpmsg channels (see definition below)
it can send messages on, and if possible, minimize how much control
it has over the content of the messages.
Every rpmsg device is a communication channel with a remote processor (thus
rpmsg devices are called channels). Channels are identified by a textual name
and have a local ("source") rpmsg address, and remote ("destination") rpmsg
address.
When a driver starts listening on a channel, its rx callback is bound with
a unique rpmsg local address (a 32-bit integer). This way when inbound messages
arrive, the rpmsg core dispatches them to the appropriate driver according
to their destination address (this is done by invoking the driver's rx handler
with the payload of the inbound message).
2. User API
int rpmsg_send(struct rpmsg_channel *rpdev, void *data, int len);
- sends a message across to the remote processor on a given channel.
The caller should specify the channel, the data it wants to send,
and its length (in bytes). The message will be sent on the specified
channel, i.e. its source and destination address fields will be
set to the channel's src and dst addresses.
In case there are no TX buffers available, the function will block until
one becomes available (i.e. until the remote processor consumes
a tx buffer and puts it back on virtio's used descriptor ring),
or a timeout of 15 seconds elapses. When the latter happens,
-ERESTARTSYS is returned.
The function can only be called from a process context (for now).
Returns 0 on success and an appropriate error value on failure.
int rpmsg_sendto(struct rpmsg_channel *rpdev, void *data, int len, u32 dst);
- sends a message across to the remote processor on a given channel,
to a destination address provided by the caller.
The caller should specify the channel, the data it wants to send,
its length (in bytes), and an explicit destination address.
The message will then be sent to the remote processor to which the
channel belongs, using the channel's src address, and the user-provided
dst address (thus the channel's dst address will be ignored).
In case there are no TX buffers available, the function will block until
one becomes available (i.e. until the remote processor consumes
a tx buffer and puts it back on virtio's used descriptor ring),
or a timeout of 15 seconds elapses. When the latter happens,
-ERESTARTSYS is returned.
The function can only be called from a process context (for now).
Returns 0 on success and an appropriate error value on failure.
int rpmsg_send_offchannel(struct rpmsg_channel *rpdev, u32 src, u32 dst,
void *data, int len);
- sends a message across to the remote processor, using the src and dst
addresses provided by the user.
The caller should specify the channel, the data it wants to send,
its length (in bytes), and explicit source and destination addresses.
The message will then be sent to the remote processor to which the
channel belongs, but the channel's src and dst addresses will be
ignored (and the user-provided addresses will be used instead).
In case there are no TX buffers available, the function will block until
one becomes available (i.e. until the remote processor consumes
a tx buffer and puts it back on virtio's used descriptor ring),
or a timeout of 15 seconds elapses. When the latter happens,
-ERESTARTSYS is returned.
The function can only be called from a process context (for now).
Returns 0 on success and an appropriate error value on failure.
int rpmsg_trysend(struct rpmsg_channel *rpdev, void *data, int len);
- sends a message across to the remote processor on a given channel.
The caller should specify the channel, the data it wants to send,
and its length (in bytes). The message will be sent on the specified
channel, i.e. its source and destination address fields will be
set to the channel's src and dst addresses.
In case there are no TX buffers available, the function will immediately
return -ENOMEM without waiting until one becomes available.
The function can only be called from a process context (for now).
Returns 0 on success and an appropriate error value on failure.
int rpmsg_trysendto(struct rpmsg_channel *rpdev, void *data, int len, u32 dst)
- sends a message across to the remote processor on a given channel,
to a destination address provided by the user.
The user should specify the channel, the data it wants to send,
its length (in bytes), and an explicit destination address.
The message will then be sent to the remote processor to which the
channel belongs, using the channel's src address, and the user-provided
dst address (thus the channel's dst address will be ignored).
In case there are no TX buffers available, the function will immediately
return -ENOMEM without waiting until one becomes available.
The function can only be called from a process context (for now).
Returns 0 on success and an appropriate error value on failure.
int rpmsg_trysend_offchannel(struct rpmsg_channel *rpdev, u32 src, u32 dst,
void *data, int len);
- sends a message across to the remote processor, using source and
destination addresses provided by the user.
The user should specify the channel, the data it wants to send,
its length (in bytes), and explicit source and destination addresses.
The message will then be sent to the remote processor to which the
channel belongs, but the channel's src and dst addresses will be
ignored (and the user-provided addresses will be used instead).
In case there are no TX buffers available, the function will immediately
return -ENOMEM without waiting until one becomes available.
The function can only be called from a process context (for now).
Returns 0 on success and an appropriate error value on failure.
struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_channel *rpdev,
void (*cb)(struct rpmsg_channel *, void *, int, void *, u32),
void *priv, u32 addr);
- every rpmsg address in the system is bound to an rx callback (so when
inbound messages arrive, they are dispatched by the rpmsg bus using the
appropriate callback handler) by means of an rpmsg_endpoint struct.
This function allows drivers to create such an endpoint, and by that,
bind a callback, and possibly some private data too, to an rpmsg address
(either one that is known in advance, or one that will be dynamically
assigned for them).
Simple rpmsg drivers need not call rpmsg_create_ept, because an endpoint
is already created for them when they are probed by the rpmsg bus
(using the rx callback they provide when they registered to the rpmsg bus).
So things should just work for simple drivers: they already have an
endpoint, their rx callback is bound to their rpmsg address, and when
relevant inbound messages arrive (i.e. messages which their dst address
equals to the src address of their rpmsg channel), the driver's handler
is invoked to process it.
That said, more complicated drivers might do need to allocate
additional rpmsg addresses, and bind them to different rx callbacks.
To accomplish that, those drivers need to call this function.
Drivers should provide their channel (so the new endpoint would bind
to the same remote processor their channel belongs to), an rx callback
function, an optional private data (which is provided back when the
rx callback is invoked), and an address they want to bind with the
callback. If addr is RPMSG_ADDR_ANY, then rpmsg_create_ept will
dynamically assign them an available rpmsg address (drivers should have
a very good reason why not to always use RPMSG_ADDR_ANY here).
Returns a pointer to the endpoint on success, or NULL on error.
void rpmsg_destroy_ept(struct rpmsg_endpoint *ept);
- destroys an existing rpmsg endpoint. user should provide a pointer
to an rpmsg endpoint that was previously created with rpmsg_create_ept().
int register_rpmsg_driver(struct rpmsg_driver *rpdrv);
- registers an rpmsg driver with the rpmsg bus. user should provide
a pointer to an rpmsg_driver struct, which contains the driver's
->probe() and ->remove() functions, an rx callback, and an id_table
specifying the names of the channels this driver is interested to
be probed with.
void unregister_rpmsg_driver(struct rpmsg_driver *rpdrv);
- unregisters an rpmsg driver from the rpmsg bus. user should provide
a pointer to a previously-registered rpmsg_driver struct.
Returns 0 on success, and an appropriate error value on failure.
3. Typical usage
The following is a simple rpmsg driver, that sends an "hello!" message
on probe(), and whenever it receives an incoming message, it dumps its
content to the console.
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/rpmsg.h>
static void rpmsg_sample_cb(struct rpmsg_channel *rpdev, void *data, int len,
void *priv, u32 src)
{
print_hex_dump(KERN_INFO, "incoming message:", DUMP_PREFIX_NONE,
16, 1, data, len, true);
}
static int rpmsg_sample_probe(struct rpmsg_channel *rpdev)
{
int err;
dev_info(&rpdev->dev, "chnl: 0x%x -> 0x%x\n", rpdev->src, rpdev->dst);
/* send a message on our channel */
err = rpmsg_send(rpdev, "hello!", 6);
if (err) {
pr_err("rpmsg_send failed: %d\n", err);
return err;
}
return 0;
}
static void __devexit rpmsg_sample_remove(struct rpmsg_channel *rpdev)
{
dev_info(&rpdev->dev, "rpmsg sample client driver is removed\n");
}
static struct rpmsg_device_id rpmsg_driver_sample_id_table[] = {
{ .name = "rpmsg-client-sample" },
{ },
};
MODULE_DEVICE_TABLE(rpmsg, rpmsg_driver_sample_id_table);
static struct rpmsg_driver rpmsg_sample_client = {
.drv.name = KBUILD_MODNAME,
.drv.owner = THIS_MODULE,
.id_table = rpmsg_driver_sample_id_table,
.probe = rpmsg_sample_probe,
.callback = rpmsg_sample_cb,
.remove = __devexit_p(rpmsg_sample_remove),
};
static int __init init(void)
{
return register_rpmsg_driver(&rpmsg_sample_client);
}
module_init(init);
static void __exit fini(void)
{
unregister_rpmsg_driver(&rpmsg_sample_client);
}
module_exit(fini);
Note: a similar sample which can be built and loaded can be found
in samples/rpmsg/.
4. Allocations of rpmsg channels:
At this point we only support dynamic allocations of rpmsg channels.
This is possible only with remote processors that have the VIRTIO_RPMSG_F_NS
virtio device feature set. This feature bit means that the remote
processor supports dynamic name service announcement messages.
When this feature is enabled, creation of rpmsg devices (i.e. channels)
is completely dynamic: the remote processor announces the existence of a
remote rpmsg service by sending a name service message (which contains
the name and rpmsg addr of the remote service, see struct rpmsg_ns_msg).
This message is then handled by the rpmsg bus, which in turn dynamically
creates and registers an rpmsg channel (which represents the remote service).
If/when a relevant rpmsg driver is registered, it will be immediately probed
by the bus, and can then start sending messages to the remote service.
The plan is also to add static creation of rpmsg channels via the virtio
config space, but it's not implemented yet.

1
Documentation/video4linux/CARDLIST.cx23885
View File

@ -32,3 +32,4 @@
31 -> Leadtek Winfast PxDVR3200 H XC4000 [107d:6f39]
32 -> MPX-885
33 -> Mygica X8507 [14f1:8502]
34 -> TerraTec Cinergy T PCIe Dual [153b:117e]

4
Documentation/video4linux/CARDLIST.cx88
View File

@ -59,7 +59,7 @@
58 -> Pinnacle PCTV HD 800i [11bd:0051]
59 -> DViCO FusionHDTV 5 PCI nano [18ac:d530]
60 -> Pinnacle Hybrid PCTV [12ab:1788]
61 -> Leadtek TV2000 XP Global [107d:6f18,107d:6618]
61 -> Leadtek TV2000 XP Global [107d:6f18,107d:6618,107d:6619]
62 -> PowerColor RA330 [14f1:ea3d]
63 -> Geniatech X8000-MT DVBT [14f1:8852]
64 -> DViCO FusionHDTV DVB-T PRO [18ac:db30]
@ -87,3 +87,5 @@
86 -> TeVii S464 DVB-S/S2 [d464:9022]
87 -> Leadtek WinFast DTV2000 H PLUS [107d:6f42]
88 -> Leadtek WinFast DTV1800 H (XC4000) [107d:6f38]
89 -> Leadtek TV2000 XP Global (SC4100) [107d:6f36]
90 -> Leadtek TV2000 XP Global (XC4100) [107d:6f43]

10
Documentation/video4linux/CARDLIST.em28xx
View File

@ -7,7 +7,7 @@
6 -> Terratec Cinergy 200 USB (em2800)
7 -> Leadtek Winfast USB II (em2800) [0413:6023]
8 -> Kworld USB2800 (em2800)
9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker (em2820/em2840) [1b80:e302,1b80:e304,2304:0207,2304:021a]
9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker (em2820/em2840) [1b80:e302,1b80:e304,2304:0207,2304:021a,093b:a003]
10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500]
11 -> Terratec Hybrid XS (em2880)
12 -> Kworld PVR TV 2800 RF (em2820/em2840)
@ -61,7 +61,7 @@
61 -> Pixelview PlayTV Box 4 USB 2.0 (em2820/em2840)
62 -> Gadmei TVR200 (em2820/em2840)
63 -> Kaiomy TVnPC U2 (em2860) [eb1a:e303]
64 -> Easy Cap Capture DC-60 (em2860)
64 -> Easy Cap Capture DC-60 (em2860) [1b80:e309]
65 -> IO-DATA GV-MVP/SZ (em2820/em2840) [04bb:0515]
66 -> Empire dual TV (em2880)
67 -> Terratec Grabby (em2860) [0ccd:0096,0ccd:10AF]
@ -76,7 +76,11 @@
76 -> KWorld PlusTV 340U or UB435-Q (ATSC) (em2870) [1b80:a340]
77 -> EM2874 Leadership ISDBT (em2874)
78 -> PCTV nanoStick T2 290e (em28174)
79 -> Terratec Cinergy H5 (em2884) [0ccd:10a2,0ccd:10ad]
79 -> Terratec Cinergy H5 (em2884) [0ccd:008e,0ccd:00ac,0ccd:10a2,0ccd:10ad]
80 -> PCTV DVB-S2 Stick (460e) (em28174)
81 -> Hauppauge WinTV HVR 930C (em2884) [2040:1605]
82 -> Terratec Cinergy HTC Stick (em2884) [0ccd:00b2]
83 -> Honestech Vidbox NW03 (em2860) [eb1a:5006]
84 -> MaxMedia UB425-TC (em2874) [1b80:e425]
85 -> PCTV QuatroStick (510e) (em2884) [2304:0242]
86 -> PCTV QuatroStick nano (520e) (em2884) [2013:0251]

1
Documentation/video4linux/CARDLIST.saa7134
View File

@ -187,3 +187,4 @@
186 -> Beholder BeholdTV 501 [5ace:5010]
187 -> Beholder BeholdTV 503 FM [5ace:5030]
188 -> Sensoray 811/911 [6000:0811,6000:0911]
189 -> Kworld PC150-U [17de:a134]

3
Documentation/video4linux/CARDLIST.tuner
View File

@ -78,10 +78,11 @@ tuner=77 - TCL tuner MF02GIP-5N-E
tuner=78 - Philips FMD1216MEX MK3 Hybrid Tuner
tuner=79 - Philips PAL/SECAM multi (FM1216 MK5)
tuner=80 - Philips FQ1216LME MK3 PAL/SECAM w/active loopthrough
tuner=81 - Xceive 4000 tuner
tuner=81 - Partsnic (Daewoo) PTI-5NF05
tuner=82 - Philips CU1216L
tuner=83 - NXP TDA18271
tuner=84 - Sony BTF-Pxn01Z
tuner=85 - Philips FQ1236 MK5
tuner=86 - Tena TNF5337 MFD
tuner=87 - Xceive 4000 tuner
tuner=88 - Xceive 5000C tuner

178
Documentation/video4linux/fimc.txt Normal file
View File

@ -0,0 +1,178 @@
Samsung S5P/EXYNOS4 FIMC driver
Copyright (C) 2012 Samsung Electronics Co., Ltd.
---------------------------------------------------------------------------
The FIMC (Fully Interactive Mobile Camera) device available in Samsung
SoC Application Processors is an integrated camera host interface, color
space converter, image resizer and rotator. It's also capable of capturing
data from LCD controller (FIMD) through the SoC internal writeback data
path. There are multiple FIMC instances in the SoCs (up to 4), having
slightly different capabilities, like pixel alignment constraints, rotator
availability, LCD writeback support, etc. The driver is located at
drivers/media/video/s5p-fimc directory.
1. Supported SoCs
=================
S5PC100 (mem-to-mem only), S5PV210, EXYNOS4210
2. Supported features
=====================
- camera parallel interface capture (ITU-R.BT601/565);
- camera serial interface capture (MIPI-CSI2);
- memory-to-memory processing (color space conversion, scaling, mirror
and rotation);
- dynamic pipeline re-configuration at runtime (re-attachment of any FIMC
instance to any parallel video input or any MIPI-CSI front-end);
- runtime PM and system wide suspend/resume
Not currently supported:
- LCD writeback input
- per frame clock gating (mem-to-mem)
3. Files partitioning
=====================
- media device driver
drivers/media/video/s5p-fimc/fimc-mdevice.[ch]
- camera capture video device driver
drivers/media/video/s5p-fimc/fimc-capture.c
- MIPI-CSI2 receiver subdev
drivers/media/video/s5p-fimc/mipi-csis.[ch]
- video post-processor (mem-to-mem)
drivers/media/video/s5p-fimc/fimc-core.c
- common files
drivers/media/video/s5p-fimc/fimc-core.h
drivers/media/video/s5p-fimc/fimc-reg.h
drivers/media/video/s5p-fimc/regs-fimc.h
4. User space interfaces
========================
4.1. Media device interface
The driver supports Media Controller API as defined at
http://http://linuxtv.org/downloads/v4l-dvb-apis/media_common.html
The media device driver name is "SAMSUNG S5P FIMC".
The purpose of this interface is to allow changing assignment of FIMC instances
to the SoC peripheral camera input at runtime and optionally to control internal
connections of the MIPI-CSIS device(s) to the FIMC entities.
The media device interface allows to configure the SoC for capturing image
data from the sensor through more than one FIMC instance (e.g. for simultaneous
viewfinder and still capture setup).
Reconfiguration is done by enabling/disabling media links created by the driver
during initialization. The internal device topology can be easily discovered
through media entity and links enumeration.
4.2. Memory-to-memory video node
V4L2 memory-to-memory interface at /dev/video? device node. This is standalone
video device, it has no media pads. However please note the mem-to-mem and
capture video node operation on same FIMC instance is not allowed. The driver
detects such cases but the applications should prevent them to avoid an
undefined behaviour.
4.3. Capture video node
The driver supports V4L2 Video Capture Interface as defined at:
http://linuxtv.org/downloads/v4l-dvb-apis/devices.html
At the capture and mem-to-mem video nodes only the multi-planar API is
supported. For more details see:
http://linuxtv.org/downloads/v4l-dvb-apis/planar-apis.html
4.4. Camera capture subdevs
Each FIMC instance exports a sub-device node (/dev/v4l-subdev?), a sub-device
node is also created per each available and enabled at the platform level
MIPI-CSI receiver device (currently up to two).
4.5. sysfs
In order to enable more precise camera pipeline control through the sub-device
API the driver creates a sysfs entry associated with "s5p-fimc-md" platform
device. The entry path is: /sys/platform/devices/s5p-fimc-md/subdev_conf_mode.
In typical use case there could be a following capture pipeline configuration:
sensor subdev -> mipi-csi subdev -> fimc subdev -> video node
When we configure these devices through sub-device API at user space, the
configuration flow must be from left to right, and the video node is
configured as last one.
When we don't use sub-device user space API the whole configuration of all
devices belonging to the pipeline is done at the video node driver.
The sysfs entry allows to instruct the capture node driver not to configure
the sub-devices (format, crop), to avoid resetting the subdevs' configuration
when the last configuration steps at the video node is performed.
For full sub-device control support (subdevs configured at user space before
starting streaming):
# echo "sub-dev" > /sys/platform/devices/s5p-fimc-md/subdev_conf_mode
For V4L2 video node control only (subdevs configured internally by the host
driver):
# echo "vid-dev" > /sys/platform/devices/s5p-fimc-md/subdev_conf_mode
This is a default option.
5. Device mapping to video and subdev device nodes
==================================================
There are associated two video device nodes with each device instance in
hardware - video capture and mem-to-mem and additionally a subdev node for
more precise FIMC capture subsystem control. In addition a separate v4l2
sub-device node is created per each MIPI-CSIS device.
How to find out which /dev/video? or /dev/v4l-subdev? is assigned to which
device?
You can either grep through the kernel log to find relevant information, i.e.
# dmesg | grep -i fimc
(note that udev, if present, might still have rearranged the video nodes),
or retrieve the information from /dev/media? with help of the media-ctl tool:
# media-ctl -p
6. Platform support
===================
The machine code (plat-s5p and arch/arm/mach-*) must select following options
CONFIG_S5P_DEV_FIMC0 mandatory
CONFIG_S5P_DEV_FIMC1 \
CONFIG_S5P_DEV_FIMC2 | optional
CONFIG_S5P_DEV_FIMC3 |
CONFIG_S5P_SETUP_FIMC /
CONFIG_S5P_SETUP_MIPIPHY \
CONFIG_S5P_DEV_CSIS0 | optional for MIPI-CSI interface
CONFIG_S5P_DEV_CSIS1 /
Except that, relevant s5p_device_fimc? should be registered in the machine code
in addition to a "s5p-fimc-md" platform device to which the media device driver
is bound. The "s5p-fimc-md" device instance is required even if only mem-to-mem
operation is used.
The description of sensor(s) attached to FIMC/MIPI-CSIS camera inputs should be
passed as the "s5p-fimc-md" device platform_data. The platform data structure
is defined in file include/media/s5p_fimc.h.
7. Build
========
This driver depends on following config options:
PLAT_S5P,
PM_RUNTIME,
I2C,
REGULATOR,
VIDEO_V4L2_SUBDEV_API,
If the driver is built as a loadable kernel module (CONFIG_VIDEO_SAMSUNG_S5P_FIMC=m)
two modules are created (in addition to the core v4l2 modules): s5p-fimc.ko and
optional s5p-csis.ko (MIPI-CSI receiver subdev).

1
Documentation/video4linux/gspca.txt
View File

@ -217,6 +217,7 @@ ov534_9 06f8:3003 Hercules Dualpix HD Weblog
sonixj 06f8:3004 Hercules Classic Silver
sonixj 06f8:3008 Hercules Deluxe Optical Glass
pac7302 06f8:3009 Hercules Classic Link
pac7302 06f8:301b Hercules Link
nw80x 0728:d001 AVerMedia Camguard
spca508 0733:0110 ViewQuest VQ110
spca501 0733:0401 Intel Create and Share

193
MAINTAINERS
View File

@ -163,7 +163,7 @@ M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
L: linux-serial@vger.kernel.org
W: http://serial.sourceforge.net
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
F: drivers/tty/serial/8250*
F: include/linux/serial_8250.h
@ -464,6 +464,7 @@ ALPHA PORT
M: Richard Henderson <rth@twiddle.net>
M: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
M: Matt Turner <mattst88@gmail.com>
S: Odd Fixes
L: linux-alpha@vger.kernel.org
F: arch/alpha/
@ -503,7 +504,7 @@ F: arch/x86/include/asm/geode.h
AMD IOMMU (AMD-VI)
M: Joerg Roedel <joerg.roedel@amd.com>
L: iommu@lists.linux-foundation.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/linux-2.6-iommu.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
S: Supported
F: drivers/iommu/amd_iommu*.[ch]
F: include/linux/amd-iommu.h
@ -715,6 +716,7 @@ S: Maintained
ARM/CLKDEV SUPPORT
M: Russell King <linux@arm.linux.org.uk>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/include/asm/clkdev.h
F: drivers/clk/clkdev.c
@ -784,7 +786,6 @@ M: Sascha Hauer <kernel@pengutronix.de>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.pengutronix.de/git/imx/linux-2.6.git
F: arch/arm/mach-mx*/
F: arch/arm/mach-imx/
F: arch/arm/plat-mxc/
@ -814,9 +815,12 @@ S: Maintained
ARM/H4700 (HP IPAQ HX4700) MACHINE SUPPORT
M: Philipp Zabel <philipp.zabel@gmail.com>
M: Paul Parsons <lost.distance@yahoo.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-pxa/hx4700.c
F: arch/arm/mach-pxa/include/mach/hx4700.h
F: sound/soc/pxa/hx4700.c
ARM/HP JORNADA 7XX MACHINE SUPPORT
M: Kristoffer Ericson <kristoffer.ericson@gmail.com>
@ -1502,7 +1506,7 @@ F: drivers/i2c/busses/i2c-bfin-twi.c
BLOCK LAYER
M: Jens Axboe <axboe@kernel.dk>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
S: Maintained
F: block/
@ -1640,7 +1644,7 @@ BTTV VIDEO4LINUX DRIVER
M: Mauro Carvalho Chehab <mchehab@infradead.org>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
S: Maintained
F: Documentation/video4linux/bttv/
F: drivers/media/video/bt8xx/bttv*
@ -1670,7 +1674,7 @@ F: fs/cachefiles/
CAFE CMOS INTEGRATED CAMERA CONTROLLER DRIVER
M: Jonathan Corbet <corbet@lwn.net>
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
S: Maintained
F: Documentation/video4linux/cafe_ccic
F: drivers/media/video/marvell-ccic/
@ -1841,6 +1845,7 @@ F: include/linux/cleancache.h
CLK API
M: Russell King <linux@arm.linux.org.uk>
S: Maintained
F: include/linux/clk.h
CISCO FCOE HBA DRIVER
@ -2036,7 +2041,7 @@ CX18 VIDEO4LINUX DRIVER
M: Andy Walls <awalls@md.metrocast.net>
L: ivtv-devel@ivtvdriver.org (moderated for non-subscribers)
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
W: http://linuxtv.org
W: http://www.ivtvdriver.org/index.php/Cx18
S: Maintained
@ -2109,6 +2114,13 @@ W: http://www.cyclades.com/
S: Orphan
F: drivers/net/wan/pc300*
CYTTSP TOUCHSCREEN DRIVER
M: Javier Martinez Canillas <javier@dowhile0.org>
L: linux-input@vger.kernel.org
S: Maintained
F: drivers/input/touchscreen/cyttsp*
F: include/linux/input/cyttsp.h
DAMA SLAVE for AX.25
M: Joerg Reuter <jreuter@yaina.de>
W: http://yaina.de/jreuter/
@ -2250,6 +2262,15 @@ F: Documentation/filesystems/quota.txt
F: fs/quota/
F: include/linux/quota*.h
DISPLAYLINK USB 2.0 FRAMEBUFFER DRIVER (UDLFB)
M: Bernie Thompson <bernie@plugable.com>
L: linux-fbdev@vger.kernel.org
S: Maintained
W: http://plugable.com/category/projects/udlfb/
F: drivers/video/udlfb.c
F: include/video/udlfb.h
F: Documentation/fb/udlfb.txt
DISTRIBUTED LOCK MANAGER (DLM)
M: Christine Caulfield <ccaulfie@redhat.com>
M: David Teigland <teigland@redhat.com>
@ -2334,7 +2355,7 @@ F: Documentation/blockdev/drbd/
DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
S: Supported
F: Documentation/kobject.txt
F: drivers/base/
@ -2356,7 +2377,7 @@ INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
M: Keith Packard <keithp@keithp.com>
L: intel-gfx@lists.freedesktop.org (subscribers-only)
L: dri-devel@lists.freedesktop.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux.git
S: Supported
F: drivers/gpu/drm/i915
F: include/drm/i915*
@ -2371,15 +2392,6 @@ S: Supported
F: drivers/gpu/drm/exynos
F: include/drm/exynos*
EXYNOS MIPI DISPLAY DRIVERS
M: Inki Dae <inki.dae@samsung.com>
M: Donghwa Lee <dh09.lee@samsung.com>
M: Kyungmin Park <kyungmin.park@samsung.com>
L: linux-fbdev@vger.kernel.org
S: Maintained
F: drivers/video/exynos/exynos_mipi*
F: include/video/exynos_mipi*
DSCC4 DRIVER
M: Francois Romieu <romieu@fr.zoreil.com>
L: netdev@vger.kernel.org
@ -2660,6 +2672,21 @@ M: Mimi Zohar <zohar@us.ibm.com>
S: Supported
F: security/integrity/evm/
EXYNOS DP DRIVER
M: Jingoo Han <jg1.han@samsung.com>
L: linux-fbdev@vger.kernel.org
S: Maintained
F: drivers/video/exynos/exynos_dp*
EXYNOS MIPI DISPLAY DRIVERS
M: Inki Dae <inki.dae@samsung.com>
M: Donghwa Lee <dh09.lee@samsung.com>
M: Kyungmin Park <kyungmin.park@samsung.com>
L: linux-fbdev@vger.kernel.org
S: Maintained
F: drivers/video/exynos/exynos_mipi*
F: include/video/exynos_mipi*
F71805F HARDWARE MONITORING DRIVER
M: Jean Delvare <khali@linux-fr.org>
L: lm-sensors@lm-sensors.org
@ -2944,8 +2971,8 @@ GFS2 FILE SYSTEM
M: Steven Whitehouse <swhiteho@redhat.com>
L: cluster-devel@redhat.com
W: http://sources.redhat.com/cluster/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-fixes.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-nmw.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-nmw.git
S: Supported
F: Documentation/filesystems/gfs2*.txt
F: fs/gfs2/
@ -2986,42 +3013,42 @@ F: drivers/net/ethernet/aeroflex/
GSPCA FINEPIX SUBDRIVER
M: Frank Zago <frank@zago.net>
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
S: Maintained
F: drivers/media/video/gspca/finepix.c
GSPCA GL860 SUBDRIVER
M: Olivier Lorin <o.lorin@laposte.net>
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
S: Maintained
F: drivers/media/video/gspca/gl860/
GSPCA M5602 SUBDRIVER
M: Erik Andren <erik.andren@gmail.com>
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
S: Maintained
F: drivers/media/video/gspca/m5602/
GSPCA PAC207 SONIXB SUBDRIVER
M: Hans de Goede <hdegoede@redhat.com>
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
S: Maintained
F: drivers/media/video/gspca/pac207.c
GSPCA SN9C20X SUBDRIVER
M: Brian Johnson <brijohn@gmail.com>
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
S: Maintained
F: drivers/media/video/gspca/sn9c20x.c
GSPCA T613 SUBDRIVER
M: Leandro Costantino <lcostantino@gmail.com>
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
S: Maintained
F: drivers/media/video/gspca/t613.c
@ -3029,7 +3056,7 @@ GSPCA USB WEBCAM DRIVER
M: Jean-Francois Moine <moinejf@free.fr>
W: http://moinejf.free.fr
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
S: Maintained
F: drivers/media/video/gspca/
@ -3315,7 +3342,7 @@ IDE SUBSYSTEM
M: "David S. Miller" <davem@davemloft.net>
L: linux-ide@vger.kernel.org
Q: http://patchwork.ozlabs.org/project/linux-ide/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide.git
S: Maintained
F: Documentation/ide/
F: drivers/ide/
@ -3427,7 +3454,7 @@ F: firmware/isci/
INTEL IDLE DRIVER
M: Len Brown <lenb@kernel.org>
L: linux-pm@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-idle-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git
S: Supported
F: drivers/idle/intel_idle.c
@ -3734,7 +3761,7 @@ IVTV VIDEO4LINUX DRIVER
M: Andy Walls <awalls@md.metrocast.net>
L: ivtv-devel@ivtvdriver.org (moderated for non-subscribers)
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
W: http://www.ivtvdriver.org
S: Maintained
F: Documentation/video4linux/*.ivtv
@ -3830,8 +3857,8 @@ F: fs/autofs4/
KERNEL BUILD + files below scripts/ (unless maintained elsewhere)
M: Michal Marek <mmarek@suse.cz>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6.git for-next
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6.git rc-fixes
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git for-next
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git rc-fixes
L: linux-kbuild@vger.kernel.org
S: Maintained
F: Documentation/kbuild/
@ -4211,12 +4238,14 @@ F: Documentation/hwmon/ltc4261
F: drivers/hwmon/ltc4261.c
LTP (Linux Test Project)
M: Rishikesh K Rajak <risrajak@linux.vnet.ibm.com>
M: Garrett Cooper <yanegomi@gmail.com>
M: Shubham Goyal <shubham@linux.vnet.ibm.com>
M: Mike Frysinger <vapier@gentoo.org>
M: Subrata Modak <subrata@linux.vnet.ibm.com>
M: Cyril Hrubis <chrubis@suse.cz>
M: Caspar Zhang <caspar@casparzhang.com>
M: Wanlong Gao <gaowanlong@cn.fujitsu.com>
L: ltp-list@lists.sourceforge.net (subscribers-only)
W: http://ltp.sourceforge.net/
T: git git://github.com/linux-test-project/ltp.git
T: git git://ltp.git.sourceforge.net/gitroot/ltp/ltp-dev
S: Maintained
@ -4254,7 +4283,7 @@ MAC80211
M: Johannes Berg <johannes@sipsolutions.net>
L: linux-wireless@vger.kernel.org
W: http://linuxwireless.org/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
S: Maintained
F: Documentation/networking/mac80211-injection.txt
F: include/net/mac80211.h
@ -4265,7 +4294,7 @@ M: Stefano Brivio <stefano.brivio@polimi.it>
M: Mattias Nissler <mattias.nissler@gmx.de>
L: linux-wireless@vger.kernel.org
W: http://linuxwireless.org/en/developers/Documentation/mac80211/RateControl/PID
T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
S: Maintained
F: net/mac80211/rc80211_pid*
@ -4337,7 +4366,7 @@ P: LinuxTV.org Project
L: linux-media@vger.kernel.org
W: http://linuxtv.org
Q: http://patchwork.kernel.org/project/linux-media/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
S: Maintained
F: Documentation/dvb/
F: Documentation/video4linux/
@ -4394,6 +4423,13 @@ T: git git://git.monstr.eu/linux-2.6-microblaze.git
S: Supported
F: arch/microblaze/
MICROCHANNEL ARCHITECTURE (MCA)
M: James Bottomley <James.Bottomley@HansenPartnership.com>
S: Maintained
F: Documentation/mca.txt
F: drivers/mca/
F: include/linux/mca*
MICROTEK X6 SCANNER
M: Oliver Neukum <oliver@neukum.name>
S: Maintained
@ -4409,14 +4445,6 @@ S: Supported
F: Documentation/mips/
F: arch/mips/
MISCELLANEOUS MCA-SUPPORT
M: James Bottomley <James.Bottomley@HansenPartnership.com>
S: Maintained
F: Documentation/ia64/mca.txt
F: Documentation/mca.txt
F: drivers/mca/
F: include/linux/mca*
MODULE SUPPORT
M: Rusty Russell <rusty@rustcorp.com.au>
S: Maintained
@ -4624,7 +4652,7 @@ M: James Morris <jmorris@namei.org>
M: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
M: Patrick McHardy <kaber@trash.net>
L: netdev@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
S: Maintained
F: net/ipv4/
F: net/ipv6/
@ -4640,7 +4668,7 @@ NETWORKING [WIRELESS]
M: "John W. Linville" <linville@tuxdriver.com>
L: linux-wireless@vger.kernel.org
Q: http://patchwork.kernel.org/project/linux-wireless/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
S: Maintained
F: net/mac80211/
F: net/rfkill/
@ -4653,8 +4681,8 @@ F: drivers/net/wireless/
NETWORKING DRIVERS
L: netdev@vger.kernel.org
W: http://www.linuxfoundation.org/en/Net
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
S: Odd Fixes
F: drivers/net/
F: include/linux/if_*
@ -4870,7 +4898,7 @@ F: drivers/char/pcmcia/cm4040_cs.*
OMNIVISION OV7670 SENSOR DRIVER
M: Jonathan Corbet <corbet@lwn.net>
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
S: Maintained
F: drivers/media/video/ov7670.c
@ -5045,7 +5073,7 @@ M: Helge Deller <deller@gmx.de>
L: linux-parisc@vger.kernel.org
W: http://www.parisc-linux.org/
Q: http://patchwork.kernel.org/project/linux-parisc/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kyle/parisc-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6.git
S: Maintained
F: arch/parisc/
F: drivers/parisc/
@ -5098,17 +5126,17 @@ F: Documentation/PCI/pci-error-recovery.txt
F: Documentation/powerpc/eeh-pci-error-recovery.txt
PCI SUBSYSTEM
M: Jesse Barnes <jbarnes@virtuousgeek.org>
M: Bjorn Helgaas <bhelgaas@google.com>
L: linux-pci@vger.kernel.org
Q: http://patchwork.kernel.org/project/linux-pci/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci.git
S: Supported
F: Documentation/PCI/
F: drivers/pci/
F: include/linux/pci*
PCI HOTPLUG
M: Jesse Barnes <jbarnes@virtuousgeek.org>
M: Bjorn Helgaas <bhelgaas@google.com>
L: linux-pci@vger.kernel.org
S: Supported
F: drivers/pci/hotplug
@ -5386,7 +5414,7 @@ M: Mike Isely <isely@pobox.com>
L: pvrusb2@isely.net (subscribers-only)
L: linux-media@vger.kernel.org
W: http://www.isely.net/pvrusb2/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
S: Maintained
F: Documentation/video4linux/README.pvrusb2
F: drivers/media/video/pvrusb2/
@ -5394,7 +5422,7 @@ F: drivers/media/video/pvrusb2/
PXA2xx/PXA3xx SUPPORT
M: Eric Miao <eric.y.miao@gmail.com>
M: Russell King <linux@arm.linux.org.uk>
M: Haojian Zhuang <haojian.zhuang@marvell.com>
M: Haojian Zhuang <haojian.zhuang@gmail.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
T: git git://github.com/hzhuang1/linux.git
T: git git://git.linaro.org/people/ycmiao/pxa-linux.git
@ -5409,7 +5437,7 @@ F: sound/soc/pxa
MMP SUPPORT
M: Eric Miao <eric.y.miao@gmail.com>
M: Haojian Zhuang <haojian.zhuang@marvell.com>
M: Haojian Zhuang <haojian.zhuang@gmail.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
T: git git://github.com/hzhuang1/linux.git
T: git git://git.linaro.org/people/ycmiao/pxa-linux.git
@ -5552,7 +5580,7 @@ RCUTORTURE MODULE
M: Josh Triplett <josh@freedesktop.org>
M: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
F: Documentation/RCU/torture.txt
F: kernel/rcutorture.c
@ -5577,7 +5605,7 @@ M: Dipankar Sarma <dipankar@in.ibm.com>
M: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
W: http://www.rdrop.com/users/paulmck/rclock/
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
F: Documentation/RCU/
F: include/linux/rcu*
F: include/linux/srcu*
@ -5606,6 +5634,13 @@ S: Supported
F: drivers/base/regmap/
F: include/linux/regmap.h
REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM
M: Ohad Ben-Cohen <ohad@wizery.com>
S: Maintained
F: drivers/remoteproc/
F: Documentation/remoteproc.txt
F: include/linux/remoteproc.txt
RFKILL
M: Johannes Berg <johannes@sipsolutions.net>
L: linux-wireless@vger.kernel.org
@ -5731,7 +5766,7 @@ F: drivers/mmc/host/s3cmci.*
SAA7146 VIDEO4LINUX-2 DRIVER
M: Michael Hunold <michael@mihu.de>
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
W: http://www.mihu.de/linux/saa7146
S: Maintained
F: drivers/media/common/saa7146*
@ -6036,7 +6071,8 @@ F: arch/arm/mach-s3c2410/bast-irq.c
TI DAVINCI MACHINE SUPPORT
M: Sekhar Nori <nsekhar@ti.com>
M: Kevin Hilman <khilman@ti.com>
L: davinci-linux-open-source@linux.davincidsp.com (subscribers-only)
L: davinci-linux-open-source@linux.davincidsp.com (moderated for non-subscribers)
T: git git://gitorious.org/linux-davinci/linux-davinci.git
Q: http://patchwork.kernel.org/project/linux-davinci/list/
S: Supported
F: arch/arm/mach-davinci
@ -6154,7 +6190,7 @@ F: arch/ia64/sn/
SOC-CAMERA V4L2 SUBSYSTEM
M: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
S: Maintained
F: include/media/v4l2*
F: drivers/media/video/v4l2*
@ -6226,8 +6262,8 @@ SPARC + UltraSPARC (sparc/sparc64)
M: "David S. Miller" <davem@davemloft.net>
L: sparclinux@vger.kernel.org
Q: http://patchwork.ozlabs.org/project/sparclinux/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next.git
S: Maintained
F: arch/sparc/
F: drivers/sbus/
@ -6235,8 +6271,8 @@ F: drivers/sbus/
SPARC SERIAL DRIVERS
M: "David S. Miller" <davem@davemloft.net>
L: sparclinux@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next.git
S: Maintained
F: include/linux/sunserialcore.h
F: drivers/tty/serial/suncore.c
@ -6541,7 +6577,7 @@ L: linux-scsi@vger.kernel.org
L: target-devel@vger.kernel.org
L: http://groups.google.com/group/linux-iscsi-target-dev
W: http://www.linux-iscsi.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/nab/lio-core-2.6.git master
T: git git://git.kernel.org/pub/scm/linux/kernel/git/nab/lio-core.git master
S: Supported
F: drivers/target/
F: include/target/
@ -6579,9 +6615,10 @@ F: include/linux/if_team.h
TEGRA SUPPORT
M: Colin Cross <ccross@android.com>
M: Olof Johansson <olof@lixom.net>
M: Stephen Warren <swarren@nvidia.com>
M: Stephen Warren <swarren@wwwdotorg.org>
L: linux-tegra@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git
Q: http://patchwork.ozlabs.org/project/linux-tegra/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
S: Supported
F: arch/arm/mach-tegra
@ -6732,7 +6769,7 @@ K: ^Subject:.*(?i)trivial
TTY LAYER
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
F: drivers/tty/
F: drivers/tty/serial/serial_core.c
F: include/linux/serial_core.h
@ -6900,7 +6937,7 @@ USB ET61X[12]51 DRIVER
M: Luca Risolia <luca.risolia@studio.unibo.it>
L: linux-usb@vger.kernel.org
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
W: http://www.linux-projects.org
S: Maintained
F: drivers/media/video/et61x251/
@ -7056,7 +7093,7 @@ USB SN9C1xx DRIVER
M: Luca Risolia <luca.risolia@studio.unibo.it>
L: linux-usb@vger.kernel.org
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
W: http://www.linux-projects.org
S: Maintained
F: Documentation/video4linux/sn9c102.txt
@ -7066,7 +7103,7 @@ USB SUBSYSTEM
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
L: linux-usb@vger.kernel.org
W: http://www.linux-usb.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
S: Supported
F: Documentation/usb/
F: drivers/net/usb/
@ -7092,7 +7129,7 @@ USB VIDEO CLASS
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
L: linux-uvc-devel@lists.berlios.de (subscribers-only)
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
W: http://www.ideasonboard.org/uvc/
S: Maintained
F: drivers/media/video/uvc/
@ -7101,7 +7138,7 @@ USB W996[87]CF DRIVER
M: Luca Risolia <luca.risolia@studio.unibo.it>
L: linux-usb@vger.kernel.org
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
W: http://www.linux-projects.org
S: Maintained
F: Documentation/video4linux/w9968cf.txt
@ -7130,7 +7167,7 @@ USB ZR364XX DRIVER
M: Antoine Jacquet <royale@zerezo.com>
L: linux-usb@vger.kernel.org
L: linux-media@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
W: http://royale.zerezo.com/zr364xx/
S: Maintained
F: Documentation/video4linux/zr364xx.txt
@ -7280,7 +7317,7 @@ M: Liam Girdwood <lrg@ti.com>
M: Mark Brown <broonie@opensource.wolfsonmicro.com>
W: http://opensource.wolfsonmicro.com/node/15
W: http://www.slimlogic.co.uk/?p=48
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lrg/regulator.git
S: Supported
F: drivers/regulator/
F: include/linux/regulator/

3
arch/Kconfig
View File

@ -120,6 +120,9 @@ config HAVE_KRETPROBES
config HAVE_OPTPROBES
bool
config HAVE_NMI_WATCHDOG
bool
#
# An arch should select this if it provides all these things:
#

4
arch/alpha/include/asm/mman.h
View File

@ -56,6 +56,10 @@
#define MADV_HUGEPAGE 14 /* Worth backing with hugepages */
#define MADV_NOHUGEPAGE 15 /* Not worth backing with hugepages */
#define MADV_DONTDUMP 16 /* Explicity exclude from the core dump,
overrides the coredump filter bits */
#define MADV_DODUMP 17 /* Clear the MADV_NODUMP flag */
/* compatibility flags */
#define MAP_FILE 0

7
arch/alpha/include/asm/pci.h
View File

@ -7,6 +7,7 @@
#include <linux/dma-mapping.h>
#include <asm/scatterlist.h>
#include <asm/machvec.h>
#include <asm-generic/pci-bridge.h>
/*
* The following structure is used to manage multiple PCI busses.
@ -99,12 +100,6 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
return channel ? 15 : 14;
}
extern void pcibios_resource_to_bus(struct pci_dev *, struct pci_bus_region *,
struct resource *);
extern void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
struct pci_bus_region *region);
#define pci_domain_nr(bus) ((struct pci_controller *)(bus)->sysdata)->index
static inline int pci_proc_domain(struct pci_bus *bus)

86
arch/alpha/kernel/pci.c
View File

@ -43,12 +43,10 @@ const char *const pci_mem_names[] = {
const char pci_hae0_name[] = "HAE0";
/* Indicate whether we respect the PCI setup left by console. */
/*
* Make this long-lived so that we know when shutting down
* whether we probed only or not.
* If PCI_PROBE_ONLY in pci_flags is set, we don't change any PCI resource
* assignments.
*/
int pci_probe_only;
/*
* The PCI controller list.
@ -215,7 +213,7 @@ pdev_save_srm_config(struct pci_dev *dev)
struct pdev_srm_saved_conf *tmp;
static int printed = 0;
if (!alpha_using_srm || pci_probe_only)
if (!alpha_using_srm || pci_has_flag(PCI_PROBE_ONLY))
return;
if (!printed) {
@ -242,7 +240,7 @@ pci_restore_srm_config(void)
struct pdev_srm_saved_conf *tmp;
/* No need to restore if probed only. */
if (pci_probe_only)
if (pci_has_flag(PCI_PROBE_ONLY))
return;
/* Restore SRM config. */
@ -252,47 +250,18 @@ pci_restore_srm_config(void)
}
#endif
void __devinit
pcibios_fixup_resource(struct resource *res, struct resource *root)
{
res->start += root->start;
res->end += root->start;
}
void __devinit
pcibios_fixup_device_resources(struct pci_dev *dev, struct pci_bus *bus)
{
/* Update device resources. */
struct pci_controller *hose = (struct pci_controller *)bus->sysdata;
int i;
for (i = 0; i < PCI_NUM_RESOURCES; i++) {
if (!dev->resource[i].start)
continue;
if (dev->resource[i].flags & IORESOURCE_IO)
pcibios_fixup_resource(&dev->resource[i],
hose->io_space);
else if (dev->resource[i].flags & IORESOURCE_MEM)
pcibios_fixup_resource(&dev->resource[i],
hose->mem_space);
}
}
void __devinit
pcibios_fixup_bus(struct pci_bus *bus)
{
struct pci_dev *dev = bus->self;
if (pci_probe_only && dev &&
if (pci_has_flag(PCI_PROBE_ONLY) && dev &&
(dev->class >> 8) == PCI_CLASS_BRIDGE_PCI) {
pci_read_bridge_bases(bus);
pcibios_fixup_device_resources(dev, bus);
}
list_for_each_entry(dev, &bus->devices, bus_list) {
pdev_save_srm_config(dev);
if ((dev->class >> 8) != PCI_CLASS_BRIDGE_PCI)
pcibios_fixup_device_resources(dev, bus);
}
}
@ -302,42 +271,6 @@ pcibios_update_irq(struct pci_dev *dev, int irq)
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq);
}
void
pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
struct resource *res)
{
struct pci_controller *hose = (struct pci_controller *)dev->sysdata;
unsigned long offset = 0;
if (res->flags & IORESOURCE_IO)
offset = hose->io_space->start;
else if (res->flags & IORESOURCE_MEM)
offset = hose->mem_space->start;
region->start = res->start - offset;
region->end = res->end - offset;
}
void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
struct pci_bus_region *region)
{
struct pci_controller *hose = (struct pci_controller *)dev->sysdata;
unsigned long offset = 0;
if (res->flags & IORESOURCE_IO)
offset = hose->io_space->start;
else if (res->flags & IORESOURCE_MEM)
offset = hose->mem_space->start;
res->start = region->start + offset;
res->end = region->end + offset;
}
#ifdef CONFIG_HOTPLUG
EXPORT_SYMBOL(pcibios_resource_to_bus);
EXPORT_SYMBOL(pcibios_bus_to_resource);
#endif
int
pcibios_enable_device(struct pci_dev *dev, int mask)
{
@ -374,7 +307,8 @@ pcibios_claim_one_bus(struct pci_bus *b)
if (r->parent || !r->start || !r->flags)
continue;
if (pci_probe_only || (r->flags & IORESOURCE_PCI_FIXED))
if (pci_has_flag(PCI_PROBE_ONLY) ||
(r->flags & IORESOURCE_PCI_FIXED))
pci_claim_resource(dev, i);
}
}
@ -416,8 +350,10 @@ common_init_pci(void)
hose->mem_space->end = end;
INIT_LIST_HEAD(&resources);
pci_add_resource(&resources, hose->io_space);
pci_add_resource(&resources, hose->mem_space);
pci_add_resource_offset(&resources, hose->io_space,
hose->io_space->start);
pci_add_resource_offset(&resources, hose->mem_space,
hose->mem_space->start);
bus = pci_scan_root_bus(NULL, next_busno, alpha_mv.pci_ops,
hose, &resources);

3
arch/alpha/kernel/pci_impl.h
View File

@ -173,9 +173,6 @@ extern void pci_restore_srm_config(void);
extern struct pci_controller *hose_head, **hose_tail;
extern struct pci_controller *pci_isa_hose;
/* Indicate that we trust the console to configure things properly. */
extern int pci_probe_only;
extern unsigned long alpha_agpgart_size;
extern void common_init_pci(void);

3
arch/alpha/kernel/sys_marvel.c
View File

@ -384,7 +384,8 @@ marvel_init_pci(void)
marvel_register_error_handlers();
pci_probe_only = 1;
/* Indicate that we trust the console to configure things properly */
pci_set_flags(PCI_PROBE_ONLY);
common_init_pci();
locate_and_init_vga(NULL);

3
arch/alpha/kernel/sys_titan.c
View File

@ -331,7 +331,8 @@ titan_init_pci(void)
*/
titan_late_init();
pci_probe_only = 1;
/* Indicate that we trust the console to configure things properly */
pci_set_flags(PCI_PROBE_ONLY);
common_init_pci();
SMC669_Init(0);
locate_and_init_vga(NULL);

45
arch/arm/Kconfig
View File

@ -186,6 +186,9 @@ config GENERIC_ISA_DMA
config FIQ
bool
config NEED_RET_TO_USER
bool
config ARCH_MTD_XIP
bool
@ -322,9 +325,10 @@ config ARCH_AT91
select ARCH_REQUIRE_GPIOLIB
select HAVE_CLK
select CLKDEV_LOOKUP
select IRQ_DOMAIN
help
This enables support for systems based on the Atmel AT91RM9200,
AT91SAM9 and AT91CAP9 processors.
AT91SAM9 processors.
config ARCH_BCMRING
bool "Broadcom BCMRING"
@ -479,6 +483,7 @@ config ARCH_IOP13XX
select ARCH_SUPPORTS_MSI
select VMSPLIT_1G
select NEED_MACH_MEMORY_H
select NEED_RET_TO_USER
help
Support for Intel's IOP13XX (XScale) family of processors.
@ -486,6 +491,7 @@ config ARCH_IOP32X
bool "IOP32x-based"
depends on MMU
select CPU_XSCALE
select NEED_RET_TO_USER
select PLAT_IOP
select PCI
select ARCH_REQUIRE_GPIOLIB
@ -497,6 +503,7 @@ config ARCH_IOP33X
bool "IOP33x-based"
depends on MMU
select CPU_XSCALE
select NEED_RET_TO_USER
select PLAT_IOP
select PCI
select ARCH_REQUIRE_GPIOLIB
@ -731,7 +738,6 @@ config ARCH_RPC
bool "RiscPC"
select ARCH_ACORN
select FIQ
select TIMER_ACORN
select ARCH_MAY_HAVE_PC_FDC
select HAVE_PATA_PLATFORM
select ISA_DMA_API
@ -754,31 +760,31 @@ config ARCH_SA1100
select ARCH_HAS_CPUFREQ
select CPU_FREQ
select GENERIC_CLOCKEVENTS
select HAVE_CLK
select CLKDEV_LOOKUP
select HAVE_SCHED_CLOCK
select TICK_ONESHOT
select ARCH_REQUIRE_GPIOLIB
select HAVE_IDE
select NEED_MACH_MEMORY_H
select SPARSE_IRQ
help
Support for StrongARM 11x0 based boards.
config ARCH_S3C2410
bool "Samsung S3C2410, S3C2412, S3C2413, S3C2416, S3C2440, S3C2442, S3C2443, S3C2450"
config ARCH_S3C24XX
bool "Samsung S3C24XX SoCs"
select GENERIC_GPIO
select ARCH_HAS_CPUFREQ
select HAVE_CLK
select CLKDEV_LOOKUP
select ARCH_USES_GETTIMEOFFSET
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C_RTC if RTC_CLASS
select HAVE_S3C2410_WATCHDOG if WATCHDOG
help
Samsung S3C2410X CPU based systems, such as the Simtec Electronics
BAST (<http://www.simtec.co.uk/products/EB110ITX/>), the IPAQ 1940 or
the Samsung SMDK2410 development board (and derivatives).
Note, the S3C2416 and the S3C2450 are so close that they even share
the same SoC ID code. This means that there is no separate machine
directory (no arch/arm/mach-s3c2450) as the S3C2416 was first.
Samsung S3C2410, S3C2412, S3C2413, S3C2416, S3C2440, S3C2442, S3C2443
and S3C2450 SoCs based systems, such as the Simtec Electronics BAST
(<http://www.simtec.co.uk/products/EB110ITX/>), the IPAQ 1940 or the
Samsung SMDK2410 development board (and derivatives).
config ARCH_S3C64XX
bool "Samsung S3C64XX"
@ -901,6 +907,7 @@ config ARCH_U300
config ARCH_U8500
bool "ST-Ericsson U8500 Series"
depends on MMU
select CPU_V7
select ARM_AMBA
select GENERIC_CLOCKEVENTS
@ -1066,12 +1073,10 @@ source "arch/arm/plat-s5p/Kconfig"
source "arch/arm/plat-spear/Kconfig"
if ARCH_S3C2410
source "arch/arm/mach-s3c2410/Kconfig"
source "arch/arm/mach-s3c24xx/Kconfig"
if ARCH_S3C24XX
source "arch/arm/mach-s3c2412/Kconfig"
source "arch/arm/mach-s3c2416/Kconfig"
source "arch/arm/mach-s3c2440/Kconfig"
source "arch/arm/mach-s3c2443/Kconfig"
endif
if ARCH_S3C64XX
@ -1127,6 +1132,7 @@ config PLAT_VERSATILE
config ARM_TIMER_SP804
bool
select CLKSRC_MMIO
select HAVE_SCHED_CLOCK
source arch/arm/mm/Kconfig
@ -1577,7 +1583,8 @@ config LOCAL_TIMERS
config ARCH_NR_GPIO
int
default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
default 350 if ARCH_U8500
default 355 if ARCH_U8500
default 264 if MACH_H4700
default 0
help
Maximum number of GPIOs in the system.
@ -1588,7 +1595,7 @@ source kernel/Kconfig.preempt
config HZ
int
default 200 if ARCH_EBSA110 || ARCH_S3C2410 || ARCH_S5P64X0 || \
default 200 if ARCH_EBSA110 || ARCH_S3C24XX || ARCH_S5P64X0 || \
ARCH_S5PV210 || ARCH_EXYNOS4
default OMAP_32K_TIMER_HZ if ARCH_OMAP && OMAP_32K_TIMER
default AT91_TIMER_HZ if ARCH_AT91
@ -2114,7 +2121,7 @@ config CPU_FREQ_S3C
config CPU_FREQ_S3C24XX
bool "CPUfreq driver for Samsung S3C24XX series CPUs (EXPERIMENTAL)"
depends on ARCH_S3C2410 && CPU_FREQ && EXPERIMENTAL
depends on ARCH_S3C24XX && CPU_FREQ && EXPERIMENTAL
select CPU_FREQ_S3C
help
This enables the CPUfreq driver for the Samsung S3C24XX family

172
arch/arm/Kconfig.debug
View File

@ -81,47 +81,14 @@ choice
prompt "Kernel low-level debugging port"
depends on DEBUG_LL
config DEBUG_LL_UART_NONE
bool "No low-level debugging UART"
help
Say Y here if your platform doesn't provide a UART option
below. This relies on your platform choosing the right UART
definition internally in order for low-level debugging to
work.
config DEBUG_ICEDCC
bool "Kernel low-level debugging via EmbeddedICE DCC channel"
help
Say Y here if you want the debug print routines to direct
their output to the EmbeddedICE macrocell's DCC channel using
co-processor 14. This is known to work on the ARM9 style ICE
channel and on the XScale with the PEEDI.
Note that the system will appear to hang during boot if there
is nothing connected to read from the DCC.
config AT91_DEBUG_LL_DBGU0
bool "Kernel low-level debugging on rm9200, 9260/9g20, 9261/9g10 and 9rl"
depends on HAVE_AT91_DBGU0
config AT91_DEBUG_LL_DBGU1
bool "Kernel low-level debugging on 9263, 9g45 and cap9"
bool "Kernel low-level debugging on 9263 and 9g45"
depends on HAVE_AT91_DBGU1
config DEBUG_FOOTBRIDGE_COM1
bool "Kernel low-level debugging messages via footbridge 8250 at PCI COM1"
depends on FOOTBRIDGE
help
Say Y here if you want the debug print routines to direct
their output to the 8250 at PCI COM1.
config DEBUG_DC21285_PORT
bool "Kernel low-level debugging messages via footbridge serial port"
depends on FOOTBRIDGE
help
Say Y here if you want the debug print routines to direct
their output to the serial port in the DC21285 (Footbridge).
config DEBUG_CLPS711X_UART1
bool "Kernel low-level debugging messages via UART1"
depends on ARCH_CLPS711X
@ -136,6 +103,20 @@ choice
Say Y here if you want the debug print routines to direct
their output to the second serial port on these devices.
config DEBUG_DC21285_PORT
bool "Kernel low-level debugging messages via footbridge serial port"
depends on FOOTBRIDGE
help
Say Y here if you want the debug print routines to direct
their output to the serial port in the DC21285 (Footbridge).
config DEBUG_FOOTBRIDGE_COM1
bool "Kernel low-level debugging messages via footbridge 8250 at PCI COM1"
depends on FOOTBRIDGE
help
Say Y here if you want the debug print routines to direct
their output to the 8250 at PCI COM1.
config DEBUG_HIGHBANK_UART
bool "Kernel low-level debugging messages via Highbank UART"
depends on ARCH_HIGHBANK
@ -199,61 +180,12 @@ choice
Say Y here if you want kernel low-level debugging support
on i.MX50 or i.MX53.
config DEBUG_IMX6Q_UART
bool "i.MX6Q Debug UART"
config DEBUG_IMX6Q_UART4
bool "i.MX6Q Debug UART4"
depends on SOC_IMX6Q
help
Say Y here if you want kernel low-level debugging support
on i.MX6Q.
config DEBUG_S3C_UART0
depends on PLAT_SAMSUNG
bool "Use S3C UART 0 for low-level debug"
help
Say Y here if you want the debug print routines to direct
their output to UART 0. The port must have been initialised
by the boot-loader before use.
The uncompressor code port configuration is now handled
by CONFIG_S3C_LOWLEVEL_UART_PORT.
config DEBUG_S3C_UART1
depends on PLAT_SAMSUNG
bool "Use S3C UART 1 for low-level debug"
help
Say Y here if you want the debug print routines to direct
their output to UART 1. The port must have been initialised
by the boot-loader before use.
The uncompressor code port configuration is now handled
by CONFIG_S3C_LOWLEVEL_UART_PORT.
config DEBUG_S3C_UART2
depends on PLAT_SAMSUNG
bool "Use S3C UART 2 for low-level debug"
help
Say Y here if you want the debug print routines to direct
their output to UART 2. The port must have been initialised
by the boot-loader before use.
The uncompressor code port configuration is now handled
by CONFIG_S3C_LOWLEVEL_UART_PORT.
config DEBUG_REALVIEW_STD_PORT
bool "RealView Default UART"
depends on ARCH_REALVIEW
help
Say Y here if you want the debug print routines to direct
their output to the serial port on RealView EB, PB11MP, PBA8
and PBX platforms.
config DEBUG_REALVIEW_PB1176_PORT
bool "RealView PB1176 UART"
depends on MACH_REALVIEW_PB1176
help
Say Y here if you want the debug print routines to direct
their output to the standard serial port on the RealView
PB1176 platform.
on i.MX6Q UART4.
config DEBUG_MSM_UART1
bool "Kernel low-level debugging messages via MSM UART1"
@ -292,6 +224,74 @@ choice
Say Y here if you want the debug print routines to direct
their output to the serial port on MSM 8960 devices.
config DEBUG_REALVIEW_STD_PORT
bool "RealView Default UART"
depends on ARCH_REALVIEW
help
Say Y here if you want the debug print routines to direct
their output to the serial port on RealView EB, PB11MP, PBA8
and PBX platforms.
config DEBUG_REALVIEW_PB1176_PORT
bool "RealView PB1176 UART"
depends on MACH_REALVIEW_PB1176
help
Say Y here if you want the debug print routines to direct
their output to the standard serial port on the RealView
PB1176 platform.
config DEBUG_S3C_UART0
depends on PLAT_SAMSUNG
bool "Use S3C UART 0 for low-level debug"
help
Say Y here if you want the debug print routines to direct
their output to UART 0. The port must have been initialised
by the boot-loader before use.
The uncompressor code port configuration is now handled
by CONFIG_S3C_LOWLEVEL_UART_PORT.
config DEBUG_S3C_UART1
depends on PLAT_SAMSUNG
bool "Use S3C UART 1 for low-level debug"
help
Say Y here if you want the debug print routines to direct
their output to UART 1. The port must have been initialised
by the boot-loader before use.
The uncompressor code port configuration is now handled
by CONFIG_S3C_LOWLEVEL_UART_PORT.
config DEBUG_S3C_UART2
depends on PLAT_SAMSUNG
bool "Use S3C UART 2 for low-level debug"
help
Say Y here if you want the debug print routines to direct
their output to UART 2. The port must have been initialised
by the boot-loader before use.
The uncompressor code port configuration is now handled
by CONFIG_S3C_LOWLEVEL_UART_PORT.
config DEBUG_LL_UART_NONE
bool "No low-level debugging UART"
help
Say Y here if your platform doesn't provide a UART option
below. This relies on your platform choosing the right UART
definition internally in order for low-level debugging to
work.
config DEBUG_ICEDCC
bool "Kernel low-level debugging via EmbeddedICE DCC channel"
help
Say Y here if you want the debug print routines to direct
their output to the EmbeddedICE macrocell's DCC channel using
co-processor 14. This is known to work on the ARM9 style ICE
channel and on the XScale with the PEEDI.
Note that the system will appear to hang during boot if there
is nothing connected to read from the DCC.
endchoice
config EARLY_PRINTK

3
arch/arm/Makefile
View File

@ -174,12 +174,13 @@ machine-$(CONFIG_ARCH_PRIMA2) := prima2
machine-$(CONFIG_ARCH_PXA) := pxa
machine-$(CONFIG_ARCH_REALVIEW) := realview
machine-$(CONFIG_ARCH_RPC) := rpc
machine-$(CONFIG_ARCH_S3C2410) := s3c2410 s3c2412 s3c2416 s3c2440 s3c2443
machine-$(CONFIG_ARCH_S3C24XX) := s3c24xx s3c2412 s3c2440
machine-$(CONFIG_ARCH_S3C64XX) := s3c64xx
machine-$(CONFIG_ARCH_S5P64X0) := s5p64x0
machine-$(CONFIG_ARCH_S5PC100) := s5pc100
machine-$(CONFIG_ARCH_S5PV210) := s5pv210
machine-$(CONFIG_ARCH_EXYNOS4) := exynos
machine-$(CONFIG_ARCH_EXYNOS5) := exynos
machine-$(CONFIG_ARCH_SA1100) := sa1100
machine-$(CONFIG_ARCH_SHARK) := shark
machine-$(CONFIG_ARCH_SHMOBILE) := shmobile

2
arch/arm/boot/compressed/head.S
View File

@ -58,7 +58,7 @@
add \rb, \rb, #0x00010000 @ Ser1
#endif
.endm
#elif defined(CONFIG_ARCH_S3C2410)
#elif defined(CONFIG_ARCH_S3C24XX)
.macro loadsp, rb, tmp
mov \rb, #0x50000000
add \rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT

27
arch/arm/boot/dts/am3517_mt_ventoux.dts Normal file
View File

@ -0,0 +1,27 @@
/*
* Copyright (C) 2011 Ilya Yanok, EmCraft Systems
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/dts-v1/;
/include/ "omap3.dtsi"
/ {
model = "TeeJet Mt.Ventoux";
compatible = "teejet,mt_ventoux", "ti,omap3";
memory {
device_type = "memory";
reg = <0x80000000 0x10000000>; /* 256 MB */
};
/* AM35xx doesn't have IVA */
soc {
iva {
status = "disabled";
};
};
};

68
arch/arm/boot/dts/at91sam9g20.dtsi
View File

@ -23,6 +23,11 @@
serial4 = &usart3;
serial5 = &usart4;
serial6 = &usart5;
gpio0 = &pioA;
gpio1 = &pioB;
gpio2 = &pioC;
tcb0 = &tcb0;
tcb1 = &tcb1;
};
cpus {
cpu@0 {
@ -47,24 +52,69 @@
ranges;
aic: interrupt-controller@fffff000 {
#interrupt-cells = <1>;
#interrupt-cells = <2>;
compatible = "atmel,at91rm9200-aic";
interrupt-controller;
interrupt-parent;
reg = <0xfffff000 0x200>;
};
pit: timer@fffffd30 {
compatible = "atmel,at91sam9260-pit";
reg = <0xfffffd30 0xf>;
interrupts = <1 4>;
};
tcb0: timer@fffa0000 {
compatible = "atmel,at91rm9200-tcb";
reg = <0xfffa0000 0x100>;
interrupts = <17 4 18 4 19 4>;
};
tcb1: timer@fffdc000 {
compatible = "atmel,at91rm9200-tcb";
reg = <0xfffdc000 0x100>;
interrupts = <26 4 27 4 28 4>;
};
pioA: gpio@fffff400 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff400 0x100>;
interrupts = <2 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioB: gpio@fffff600 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff600 0x100>;
interrupts = <3 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioC: gpio@fffff800 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff800 0x100>;
interrupts = <4 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
dbgu: serial@fffff200 {
compatible = "atmel,at91sam9260-usart";
reg = <0xfffff200 0x200>;
interrupts = <1>;
interrupts = <1 4>;
status = "disabled";
};
usart0: serial@fffb0000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xfffb0000 0x200>;
interrupts = <6>;
interrupts = <6 4>;
atmel,use-dma-rx;
atmel,use-dma-tx;
status = "disabled";
@ -73,7 +123,7 @@
usart1: serial@fffb4000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xfffb4000 0x200>;
interrupts = <7>;
interrupts = <7 4>;
atmel,use-dma-rx;
atmel,use-dma-tx;
status = "disabled";
@ -82,7 +132,7 @@
usart2: serial@fffb8000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xfffb8000 0x200>;
interrupts = <8>;
interrupts = <8 4>;
atmel,use-dma-rx;
atmel,use-dma-tx;
status = "disabled";
@ -91,7 +141,7 @@
usart3: serial@fffd0000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xfffd0000 0x200>;
interrupts = <23>;
interrupts = <23 4>;
atmel,use-dma-rx;
atmel,use-dma-tx;
status = "disabled";
@ -100,7 +150,7 @@
usart4: serial@fffd4000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xfffd4000 0x200>;
interrupts = <24>;
interrupts = <24 4>;
atmel,use-dma-rx;
atmel,use-dma-tx;
status = "disabled";
@ -109,7 +159,7 @@
usart5: serial@fffd8000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xfffd8000 0x200>;
interrupts = <25>;
interrupts = <25 4>;
atmel,use-dma-rx;
atmel,use-dma-tx;
status = "disabled";
@ -118,7 +168,7 @@
macb0: ethernet@fffc4000 {
compatible = "cdns,at32ap7000-macb", "cdns,macb";
reg = <0xfffc4000 0x100>;
interrupts = <21>;
interrupts = <21 4>;
status = "disabled";
};
};

37
arch/arm/boot/dts/at91sam9g25ek.dts Normal file
View File

@ -0,0 +1,37 @@
/*
* at91sam9g25ek.dts - Device Tree file for AT91SAM9G25-EK board
*
* Copyright (C) 2012 Atmel,
* 2012 Nicolas Ferre <nicolas.ferre@atmel.com>
*
* Licensed under GPLv2 or later.
*/
/dts-v1/;
/include/ "at91sam9x5.dtsi"
/include/ "at91sam9x5cm.dtsi"
/ {
model = "Atmel AT91SAM9G25-EK";
compatible = "atmel,at91sam9g25ek", "atmel,at91sam9x5ek", "atmel,at91sam9x5", "atmel,at91sam9";
chosen {
bootargs = "128M console=ttyS0,115200 mtdparts=atmel_nand:8M(bootstrap/uboot/kernel)ro,-(rootfs) root=/dev/mtdblock1 rw rootfstype=ubifs ubi.mtd=1 root=ubi0:rootfs";
};
ahb {
apb {
dbgu: serial@fffff200 {
status = "okay";
};
usart0: serial@f801c000 {
status = "okay";
};
macb0: ethernet@f802c000 {
phy-mode = "rmii";
status = "okay";
};
};
};
};

87
arch/arm/boot/dts/at91sam9g45.dtsi
View File

@ -22,6 +22,13 @@
serial2 = &usart1;
serial3 = &usart2;
serial4 = &usart3;
gpio0 = &pioA;
gpio1 = &pioB;
gpio2 = &pioC;
gpio3 = &pioD;
gpio4 = &pioE;
tcb0 = &tcb0;
tcb1 = &tcb1;
};
cpus {
cpu@0 {
@ -46,30 +53,94 @@
ranges;
aic: interrupt-controller@fffff000 {
#interrupt-cells = <1>;
#interrupt-cells = <2>;
compatible = "atmel,at91rm9200-aic";
interrupt-controller;
interrupt-parent;
reg = <0xfffff000 0x200>;
};
pit: timer@fffffd30 {
compatible = "atmel,at91sam9260-pit";
reg = <0xfffffd30 0xf>;
interrupts = <1 4>;
};
tcb0: timer@fff7c000 {
compatible = "atmel,at91rm9200-tcb";
reg = <0xfff7c000 0x100>;
interrupts = <18 4>;
};
tcb1: timer@fffd4000 {
compatible = "atmel,at91rm9200-tcb";
reg = <0xfffd4000 0x100>;
interrupts = <18 4>;
};
dma: dma-controller@ffffec00 {
compatible = "atmel,at91sam9g45-dma";
reg = <0xffffec00 0x200>;
interrupts = <21>;
interrupts = <21 4>;
};
pioA: gpio@fffff200 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff200 0x100>;
interrupts = <2 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioB: gpio@fffff400 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff400 0x100>;
interrupts = <3 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioC: gpio@fffff600 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff600 0x100>;
interrupts = <4 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioD: gpio@fffff800 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff800 0x100>;
interrupts = <5 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioE: gpio@fffffa00 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffffa00 0x100>;
interrupts = <5 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
dbgu: serial@ffffee00 {
compatible = "atmel,at91sam9260-usart";
reg = <0xffffee00 0x200>;
interrupts = <1>;
interrupts = <1 4>;
status = "disabled";
};
usart0: serial@fff8c000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xfff8c000 0x200>;
interrupts = <7>;
interrupts = <7 4>;
atmel,use-dma-rx;
atmel,use-dma-tx;
status = "disabled";
@ -78,7 +149,7 @@
usart1: serial@fff90000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xfff90000 0x200>;
interrupts = <8>;
interrupts = <8 4>;
atmel,use-dma-rx;
atmel,use-dma-tx;
status = "disabled";
@ -87,7 +158,7 @@
usart2: serial@fff94000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xfff94000 0x200>;
interrupts = <9>;
interrupts = <9 4>;
atmel,use-dma-rx;
atmel,use-dma-tx;
status = "disabled";
@ -96,7 +167,7 @@
usart3: serial@fff98000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xfff98000 0x200>;
interrupts = <10>;
interrupts = <10 4>;
atmel,use-dma-rx;
atmel,use-dma-tx;
status = "disabled";
@ -105,7 +176,7 @@
macb0: ethernet@fffbc000 {
compatible = "cdns,at32ap7000-macb", "cdns,macb";
reg = <0xfffbc000 0x100>;
interrupts = <25>;
interrupts = <25 4>;
status = "disabled";
};
};

72
arch/arm/boot/dts/at91sam9m10g45ek.dts
View File

@ -37,4 +37,76 @@
};
};
};
leds {
compatible = "gpio-leds";
d8 {
label = "d8";
gpios = <&pioD 30 0>;
linux,default-trigger = "heartbeat";
};
d6 {
label = "d6";
gpios = <&pioD 0 1>;
linux,default-trigger = "nand-disk";
};
d7 {
label = "d7";
gpios = <&pioD 31 1>;
linux,default-trigger = "mmc0";
};
};
gpio_keys {
compatible = "gpio-keys";
#address-cells = <1>;
#size-cells = <0>;
left_click {
label = "left_click";
gpios = <&pioB 6 1>;
linux,code = <272>;
gpio-key,wakeup;
};
right_click {
label = "right_click";
gpios = <&pioB 7 1>;
linux,code = <273>;
gpio-key,wakeup;
};
left {
label = "Joystick Left";
gpios = <&pioB 14 1>;
linux,code = <105>;
};
right {
label = "Joystick Right";
gpios = <&pioB 15 1>;
linux,code = <106>;
};
up {
label = "Joystick Up";
gpios = <&pioB 16 1>;
linux,code = <103>;
};
down {
label = "Joystick Down";
gpios = <&pioB 17 1>;
linux,code = <108>;
};
enter {
label = "Joystick Press";
gpios = <&pioB 18 1>;
linux,code = <28>;
};
};
};

176
arch/arm/boot/dts/at91sam9x5.dtsi Normal file
View File

@ -0,0 +1,176 @@
/*
* at91sam9x5.dtsi - Device Tree Include file for AT91SAM9x5 family SoC
* applies to AT91SAM9G15, AT91SAM9G25, AT91SAM9G35,
* AT91SAM9X25, AT91SAM9X35 SoC
*
* Copyright (C) 2012 Atmel,
* 2012 Nicolas Ferre <nicolas.ferre@atmel.com>
*
* Licensed under GPLv2 or later.
*/
/include/ "skeleton.dtsi"
/ {
model = "Atmel AT91SAM9x5 family SoC";
compatible = "atmel,at91sam9x5";
interrupt-parent = <&aic>;
aliases {
serial0 = &dbgu;
serial1 = &usart0;
serial2 = &usart1;
serial3 = &usart2;
gpio0 = &pioA;
gpio1 = &pioB;
gpio2 = &pioC;
gpio3 = &pioD;
tcb0 = &tcb0;
tcb1 = &tcb1;
};
cpus {
cpu@0 {
compatible = "arm,arm926ejs";
};
};
memory@20000000 {
reg = <0x20000000 0x10000000>;
};
ahb {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
apb {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
aic: interrupt-controller@fffff000 {
#interrupt-cells = <2>;
compatible = "atmel,at91rm9200-aic";
interrupt-controller;
interrupt-parent;
reg = <0xfffff000 0x200>;
};
pit: timer@fffffe30 {
compatible = "atmel,at91sam9260-pit";
reg = <0xfffffe30 0xf>;
interrupts = <1 4>;
};
tcb0: timer@f8008000 {
compatible = "atmel,at91sam9x5-tcb";
reg = <0xf8008000 0x100>;
interrupts = <17 4>;
};
tcb1: timer@f800c000 {
compatible = "atmel,at91sam9x5-tcb";
reg = <0xf800c000 0x100>;
interrupts = <17 4>;
};
dma0: dma-controller@ffffec00 {
compatible = "atmel,at91sam9g45-dma";
reg = <0xffffec00 0x200>;
interrupts = <20 4>;
};
dma1: dma-controller@ffffee00 {
compatible = "atmel,at91sam9g45-dma";
reg = <0xffffee00 0x200>;
interrupts = <21 4>;
};
pioA: gpio@fffff400 {
compatible = "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
reg = <0xfffff400 0x100>;
interrupts = <2 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioB: gpio@fffff600 {
compatible = "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
reg = <0xfffff600 0x100>;
interrupts = <2 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioC: gpio@fffff800 {
compatible = "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
reg = <0xfffff800 0x100>;
interrupts = <3 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioD: gpio@fffffa00 {
compatible = "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
reg = <0xfffffa00 0x100>;
interrupts = <3 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
dbgu: serial@fffff200 {
compatible = "atmel,at91sam9260-usart";
reg = <0xfffff200 0x200>;
interrupts = <1 4>;
status = "disabled";
};
usart0: serial@f801c000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xf801c000 0x200>;
interrupts = <5 4>;
atmel,use-dma-rx;
atmel,use-dma-tx;
status = "disabled";
};
usart1: serial@f8020000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xf8020000 0x200>;
interrupts = <6 4>;
atmel,use-dma-rx;
atmel,use-dma-tx;
status = "disabled";
};
usart2: serial@f8024000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xf8024000 0x200>;
interrupts = <7 4>;
atmel,use-dma-rx;
atmel,use-dma-tx;
status = "disabled";
};
macb0: ethernet@f802c000 {
compatible = "cdns,at32ap7000-macb", "cdns,macb";
reg = <0xf802c000 0x100>;
interrupts = <24 4>;
status = "disabled";
};
macb1: ethernet@f8030000 {
compatible = "cdns,at32ap7000-macb", "cdns,macb";
reg = <0xf8030000 0x100>;
interrupts = <27 4>;
status = "disabled";
};
};
};
};

29
arch/arm/boot/dts/at91sam9x5cm.dtsi Normal file
View File

@ -0,0 +1,29 @@
/*
* at91sam9x5cm.dtsi - Device Tree Include file for AT91SAM9x5 CPU Module
*
* Copyright (C) 2012 Atmel,
* 2012 Nicolas Ferre <nicolas.ferre@atmel.com>
*
* Licensed under GPLv2 or later.
*/
/ {
memory@20000000 {
reg = <0x20000000 0x8000000>;
};
leds {
compatible = "gpio-leds";
pb18 {
label = "pb18";
gpios = <&pioB 18 1>;
linux,default-trigger = "heartbeat";
};
pd21 {
label = "pd21";
gpios = <&pioD 21 0>;
};
};
};

26
arch/arm/boot/dts/exynos5250-smdk5250.dts Normal file
View File

@ -0,0 +1,26 @@
/*
* SAMSUNG SMDK5250 board device tree source
*
* Copyright (c) 2012 Samsung Electronics Co., Ltd.
* http://www.samsung.com
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/dts-v1/;
/include/ "exynos5250.dtsi"
/ {
model = "SAMSUNG SMDK5250 board based on EXYNOS5250";
compatible = "samsung,smdk5250", "samsung,exynos5250";
memory {
reg = <0x40000000 0x80000000>;
};
chosen {
bootargs = "root=/dev/ram0 rw ramdisk=8192 console=ttySAC1,115200";
};
};

413
arch/arm/boot/dts/exynos5250.dtsi Normal file
View File

@ -0,0 +1,413 @@
/*
* SAMSUNG EXYNOS5250 SoC device tree source
*
* Copyright (c) 2012 Samsung Electronics Co., Ltd.
* http://www.samsung.com
*
* SAMSUNG EXYNOS5250 SoC device nodes are listed in this file.
* EXYNOS5250 based board files can include this file and provide
* values for board specfic bindings.
*
* Note: This file does not include device nodes for all the controllers in
* EXYNOS5250 SoC. As device tree coverage for EXYNOS5250 increases,
* additional nodes can be added to this file.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/include/ "skeleton.dtsi"
/ {
compatible = "samsung,exynos5250";
interrupt-parent = <&gic>;
gic:interrupt-controller@10490000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x10490000 0x1000>, <0x10480000 0x100>;
};
watchdog {
compatible = "samsung,s3c2410-wdt";
reg = <0x101D0000 0x100>;
interrupts = <0 42 0>;
};
rtc {
compatible = "samsung,s3c6410-rtc";
reg = <0x101E0000 0x100>;
interrupts = <0 43 0>, <0 44 0>;
};
sdhci@12200000 {
compatible = "samsung,exynos4210-sdhci";
reg = <0x12200000 0x100>;
interrupts = <0 75 0>;
};
sdhci@12210000 {
compatible = "samsung,exynos4210-sdhci";
reg = <0x12210000 0x100>;
interrupts = <0 76 0>;
};
sdhci@12220000 {
compatible = "samsung,exynos4210-sdhci";
reg = <0x12220000 0x100>;
interrupts = <0 77 0>;
};
sdhci@12230000 {
compatible = "samsung,exynos4210-sdhci";
reg = <0x12230000 0x100>;
interrupts = <0 78 0>;
};
serial@12C00000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C00000 0x100>;
interrupts = <0 51 0>;
};
serial@12C10000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C10000 0x100>;
interrupts = <0 52 0>;
};
serial@12C20000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C20000 0x100>;
interrupts = <0 53 0>;
};
serial@12C30000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C30000 0x100>;
interrupts = <0 54 0>;
};
i2c@12C60000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12C60000 0x100>;
interrupts = <0 56 0>;
};
i2c@12C70000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12C70000 0x100>;
interrupts = <0 57 0>;
};
i2c@12C80000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12C80000 0x100>;
interrupts = <0 58 0>;
};
i2c@12C90000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12C90000 0x100>;
interrupts = <0 59 0>;
};
i2c@12CA0000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12CA0000 0x100>;
interrupts = <0 60 0>;
};
i2c@12CB0000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12CB0000 0x100>;
interrupts = <0 61 0>;
};
i2c@12CC0000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12CC0000 0x100>;
interrupts = <0 62 0>;
};
i2c@12CD0000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12CD0000 0x100>;
interrupts = <0 63 0>;
};
amba {
#address-cells = <1>;
#size-cells = <1>;
compatible = "arm,amba-bus";
interrupt-parent = <&gic>;
ranges;
pdma0: pdma@121A0000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x121A0000 0x1000>;
interrupts = <0 34 0>;
};
pdma1: pdma@121B0000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x121B0000 0x1000>;
interrupts = <0 35 0>;
};
mdma0: pdma@10800000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x10800000 0x1000>;
interrupts = <0 33 0>;
};
mdma1: pdma@11C10000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x11C10000 0x1000>;
interrupts = <0 124 0>;
};
};
gpio-controllers {
#address-cells = <1>;
#size-cells = <1>;
gpio-controller;
ranges;
gpa0: gpio-controller@11400000 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400000 0x20>;
#gpio-cells = <4>;
};
gpa1: gpio-controller@11400020 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400020 0x20>;
#gpio-cells = <4>;
};
gpa2: gpio-controller@11400040 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400040 0x20>;
#gpio-cells = <4>;
};
gpb0: gpio-controller@11400060 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400060 0x20>;
#gpio-cells = <4>;
};
gpb1: gpio-controller@11400080 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400080 0x20>;
#gpio-cells = <4>;
};
gpb2: gpio-controller@114000A0 {
compatible = "samsung,exynos4-gpio";
reg = <0x114000A0 0x20>;
#gpio-cells = <4>;
};
gpb3: gpio-controller@114000C0 {
compatible = "samsung,exynos4-gpio";
reg = <0x114000C0 0x20>;
#gpio-cells = <4>;
};
gpc0: gpio-controller@114000E0 {
compatible = "samsung,exynos4-gpio";
reg = <0x114000E0 0x20>;
#gpio-cells = <4>;
};
gpc1: gpio-controller@11400100 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400100 0x20>;
#gpio-cells = <4>;
};
gpc2: gpio-controller@11400120 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400120 0x20>;
#gpio-cells = <4>;
};
gpc3: gpio-controller@11400140 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400140 0x20>;
#gpio-cells = <4>;
};
gpd0: gpio-controller@11400160 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400160 0x20>;
#gpio-cells = <4>;
};
gpd1: gpio-controller@11400180 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400180 0x20>;
#gpio-cells = <4>;
};
gpy0: gpio-controller@114001A0 {
compatible = "samsung,exynos4-gpio";
reg = <0x114001A0 0x20>;
#gpio-cells = <4>;
};
gpy1: gpio-controller@114001C0 {
compatible = "samsung,exynos4-gpio";
reg = <0x114001C0 0x20>;
#gpio-cells = <4>;
};
gpy2: gpio-controller@114001E0 {
compatible = "samsung,exynos4-gpio";
reg = <0x114001E0 0x20>;
#gpio-cells = <4>;
};
gpy3: gpio-controller@11400200 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400200 0x20>;
#gpio-cells = <4>;
};
gpy4: gpio-controller@11400220 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400220 0x20>;
#gpio-cells = <4>;
};
gpy5: gpio-controller@11400240 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400240 0x20>;
#gpio-cells = <4>;
};
gpy6: gpio-controller@11400260 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400260 0x20>;
#gpio-cells = <4>;
};
gpx0: gpio-controller@11400C00 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400C00 0x20>;
#gpio-cells = <4>;
};
gpx1: gpio-controller@11400C20 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400C20 0x20>;
#gpio-cells = <4>;
};
gpx2: gpio-controller@11400C40 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400C40 0x20>;
#gpio-cells = <4>;
};
gpx3: gpio-controller@11400C60 {
compatible = "samsung,exynos4-gpio";
reg = <0x11400C60 0x20>;
#gpio-cells = <4>;
};
gpe0: gpio-controller@13400000 {
compatible = "samsung,exynos4-gpio";
reg = <0x13400000 0x20>;
#gpio-cells = <4>;
};
gpe1: gpio-controller@13400020 {
compatible = "samsung,exynos4-gpio";
reg = <0x13400020 0x20>;
#gpio-cells = <4>;
};
gpf0: gpio-controller@13400040 {
compatible = "samsung,exynos4-gpio";
reg = <0x13400040 0x20>;
#gpio-cells = <4>;
};
gpf1: gpio-controller@13400060 {
compatible = "samsung,exynos4-gpio";
reg = <0x13400060 0x20>;
#gpio-cells = <4>;
};
gpg0: gpio-controller@13400080 {
compatible = "samsung,exynos4-gpio";
reg = <0x13400080 0x20>;
#gpio-cells = <4>;
};
gpg1: gpio-controller@134000A0 {
compatible = "samsung,exynos4-gpio";
reg = <0x134000A0 0x20>;
#gpio-cells = <4>;
};
gpg2: gpio-controller@134000C0 {
compatible = "samsung,exynos4-gpio";
reg = <0x134000C0 0x20>;
#gpio-cells = <4>;
};
gph0: gpio-controller@134000E0 {
compatible = "samsung,exynos4-gpio";
reg = <0x134000E0 0x20>;
#gpio-cells = <4>;
};
gph1: gpio-controller@13400100 {
compatible = "samsung,exynos4-gpio";
reg = <0x13400100 0x20>;
#gpio-cells = <4>;
};
gpv0: gpio-controller@10D10000 {
compatible = "samsung,exynos4-gpio";
reg = <0x10D10000 0x20>;
#gpio-cells = <4>;
};
gpv1: gpio-controller@10D10020 {
compatible = "samsung,exynos4-gpio";
reg = <0x10D10020 0x20>;
#gpio-cells = <4>;
};
gpv2: gpio-controller@10D10040 {
compatible = "samsung,exynos4-gpio";
reg = <0x10D10040 0x20>;
#gpio-cells = <4>;
};
gpv3: gpio-controller@10D10060 {
compatible = "samsung,exynos4-gpio";
reg = <0x10D10060 0x20>;
#gpio-cells = <4>;
};
gpv4: gpio-controller@10D10080 {
compatible = "samsung,exynos4-gpio";
reg = <0x10D10080 0x20>;
#gpio-cells = <4>;
};
gpz: gpio-controller@03860000 {
compatible = "samsung,exynos4-gpio";
reg = <0x03860000 0x20>;
#gpio-cells = <4>;
};
};
};

8
arch/arm/boot/dts/highbank.dts
View File

@ -72,15 +72,15 @@
ranges;
timer@fff10600 {
compatible = "arm,smp-twd";
compatible = "arm,cortex-a9-twd-timer";
reg = <0xfff10600 0x20>;
interrupts = <1 13 0xf04>;
interrupts = <1 13 0xf01>;
};
watchdog@fff10620 {
compatible = "arm,cortex-a9-wdt";
compatible = "arm,cortex-a9-twd-wdt";
reg = <0xfff10620 0x20>;
interrupts = <1 14 0xf04>;
interrupts = <1 14 0xf01>;
};
intc: interrupt-controller@fff11000 {

76
arch/arm/boot/dts/imx27-phytec-phycore.dts Normal file
View File

@ -0,0 +1,76 @@
/*
* Copyright 2012 Sascha Hauer, Pengutronix
*
* The code contained herein is licensed under the GNU General Public
* License. You may obtain a copy of the GNU General Public License
* Version 2 or later at the following locations:
*
* http://www.opensource.org/licenses/gpl-license.html
* http://www.gnu.org/copyleft/gpl.html
*/
/dts-v1/;
/include/ "imx27.dtsi"
/ {
model = "Phytec pcm038";
compatible = "phytec,imx27-pcm038", "fsl,imx27";
memory {
reg = <0x0 0x0>;
};
soc {
aipi@10000000 { /* aipi */
wdog@10002000 {
status = "okay";
};
uart@1000a000 {
fsl,uart-has-rtscts;
status = "okay";
};
uart@1000b000 {
fsl,uart-has-rtscts;
status = "okay";
};
uart@1000c000 {
fsl,uart-has-rtscts;
status = "okay";
};
fec@1002b000 {
status = "okay";
};
i2c@1001d000 {
clock-frequency = <400000>;
status = "okay";
at24@4c {
compatible = "at,24c32";
pagesize = <32>;
reg = <0x52>;
};
pcf8563@51 {
compatible = "nxp,pcf8563";
reg = <0x51>;
};
lm75@4a {
compatible = "national,lm75";
reg = <0x4a>;
};
};
};
};
nor_flash@c0000000 {
compatible = "cfi-flash";
bank-width = <2>;
reg = <0xc0000000 0x02000000>;
#address-cells = <1>;
#size-cells = <1>;
};
};

217
arch/arm/boot/dts/imx27.dtsi Normal file
View File

@ -0,0 +1,217 @@
/*
* Copyright 2012 Sascha Hauer, Pengutronix
*
* The code contained herein is licensed under the GNU General Public
* License. You may obtain a copy of the GNU General Public License
* Version 2 or later at the following locations:
*
* http://www.opensource.org/licenses/gpl-license.html
* http://www.gnu.org/copyleft/gpl.html
*/
/include/ "skeleton.dtsi"
/ {
aliases {
serial0 = &uart1;
serial1 = &uart2;
serial2 = &uart3;
serial3 = &uart4;
serial4 = &uart5;
serial5 = &uart6;
};
avic: avic-interrupt-controller@e0000000 {
compatible = "fsl,imx27-avic", "fsl,avic";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x10040000 0x1000>;
};
clocks {
#address-cells = <1>;
#size-cells = <0>;
osc26m {
compatible = "fsl,imx-osc26m", "fixed-clock";
clock-frequency = <26000000>;
};
};
soc {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
interrupt-parent = <&avic>;
ranges;
aipi@10000000 { /* AIPI1 */
compatible = "fsl,aipi-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x10000000 0x10000000>;
ranges;
wdog@10002000 {
compatible = "fsl,imx27-wdt", "fsl,imx21-wdt";
reg = <0x10002000 0x4000>;
interrupts = <27>;
status = "disabled";
};
uart1: uart@1000a000 {
compatible = "fsl,imx27-uart", "fsl,imx21-uart";
reg = <0x1000a000 0x1000>;
interrupts = <20>;
status = "disabled";
};
uart2: uart@1000b000 {
compatible = "fsl,imx27-uart", "fsl,imx21-uart";
reg = <0x1000b000 0x1000>;
interrupts = <19>;
status = "disabled";
};
uart3: uart@1000c000 {
compatible = "fsl,imx27-uart", "fsl,imx21-uart";
reg = <0x1000c000 0x1000>;
interrupts = <18>;
status = "disabled";
};
uart4: uart@1000d000 {
compatible = "fsl,imx27-uart", "fsl,imx21-uart";
reg = <0x1000d000 0x1000>;
interrupts = <17>;
status = "disabled";
};
cspi1: cspi@1000e000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx27-cspi";
reg = <0x1000e000 0x1000>;
interrupts = <16>;
status = "disabled";
};
cspi2: cspi@1000f000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx27-cspi";
reg = <0x1000f000 0x1000>;
interrupts = <15>;
status = "disabled";
};
i2c1: i2c@10012000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx27-i2c", "fsl,imx1-i2c";
reg = <0x10012000 0x1000>;
interrupts = <12>;
status = "disabled";
};
gpio1: gpio@10015000 {
compatible = "fsl,imx27-gpio", "fsl,imx21-gpio";
reg = <0x10015000 0x100>;
interrupts = <8>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <1>;
};
gpio2: gpio@10015100 {
compatible = "fsl,imx27-gpio", "fsl,imx21-gpio";
reg = <0x10015100 0x100>;
interrupts = <8>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <1>;
};
gpio3: gpio@10015200 {
compatible = "fsl,imx27-gpio", "fsl,imx21-gpio";
reg = <0x10015200 0x100>;
interrupts = <8>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <1>;
};
gpio4: gpio@10015300 {
compatible = "fsl,imx27-gpio", "fsl,imx21-gpio";
reg = <0x10015300 0x100>;
interrupts = <8>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <1>;
};
gpio5: gpio@10015400 {
compatible = "fsl,imx27-gpio", "fsl,imx21-gpio";
reg = <0x10015400 0x100>;
interrupts = <8>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <1>;
};
gpio6: gpio@10015500 {
compatible = "fsl,imx27-gpio", "fsl,imx21-gpio";
reg = <0x10015500 0x100>;
interrupts = <8>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <1>;
};
cspi3: cspi@10017000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx27-cspi";
reg = <0x10017000 0x1000>;
interrupts = <6>;
status = "disabled";
};
uart5: uart@1001b000 {
compatible = "fsl,imx27-uart", "fsl,imx21-uart";
reg = <0x1001b000 0x1000>;
interrupts = <49>;
status = "disabled";
};
uart6: uart@1001c000 {
compatible = "fsl,imx27-uart", "fsl,imx21-uart";
reg = <0x1001c000 0x1000>;
interrupts = <48>;
status = "disabled";
};
i2c2: i2c@1001d000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx27-i2c", "fsl,imx1-i2c";
reg = <0x1001d000 0x1000>;
interrupts = <1>;
status = "disabled";
};
fec: fec@1002b000 {
compatible = "fsl,imx27-fec";
reg = <0x1002b000 0x4000>;
interrupts = <50>;
status = "disabled";
};
};
};
};

91
arch/arm/boot/dts/imx51-babbage.dts
View File

@ -56,8 +56,95 @@
compatible = "fsl,mc13892";
spi-max-frequency = <6000000>;
reg = <0>;
mc13xxx-irq-gpios = <&gpio1 8 0>;
fsl,mc13xxx-uses-regulator;
interrupt-parent = <&gpio1>;
interrupts = <8>;
regulators {
sw1_reg: sw1 {
regulator-min-microvolt = <600000>;
regulator-max-microvolt = <1375000>;
regulator-boot-on;
regulator-always-on;
};
sw2_reg: sw2 {
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <1850000>;
regulator-boot-on;
regulator-always-on;
};
sw3_reg: sw3 {
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1850000>;
regulator-boot-on;
regulator-always-on;
};
sw4_reg: sw4 {
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1850000>;
regulator-boot-on;
regulator-always-on;
};
vpll_reg: vpll {
regulator-min-microvolt = <1050000>;
regulator-max-microvolt = <1800000>;
regulator-boot-on;
regulator-always-on;
};
vdig_reg: vdig {
regulator-min-microvolt = <1650000>;
regulator-max-microvolt = <1650000>;
regulator-boot-on;
};
vsd_reg: vsd {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3150000>;
};
vusb2_reg: vusb2 {
regulator-min-microvolt = <2400000>;
regulator-max-microvolt = <2775000>;
regulator-boot-on;
regulator-always-on;
};
vvideo_reg: vvideo {
regulator-min-microvolt = <2775000>;
regulator-max-microvolt = <2775000>;
};
vaudio_reg: vaudio {
regulator-min-microvolt = <2300000>;
regulator-max-microvolt = <3000000>;
};
vcam_reg: vcam {
regulator-min-microvolt = <2500000>;
regulator-max-microvolt = <3000000>;
};
vgen1_reg: vgen1 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
};
vgen2_reg: vgen2 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3150000>;
regulator-always-on;
};
vgen3_reg: vgen3 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <2900000>;
regulator-always-on;
};
};
};
flash: at45db321d@1 {

14
arch/arm/boot/dts/imx6q-arm2.dts
View File

@ -36,11 +36,13 @@
usdhc@02198000 { /* uSDHC3 */
cd-gpios = <&gpio6 11 0>;
wp-gpios = <&gpio6 14 0>;
vmmc-supply = <&reg_3p3v>;
status = "okay";
};
usdhc@0219c000 { /* uSDHC4 */
fsl,card-wired;
vmmc-supply = <&reg_3p3v>;
status = "okay";
};
@ -50,6 +52,18 @@
};
};
regulators {
compatible = "simple-bus";
reg_3p3v: 3p3v {
compatible = "regulator-fixed";
regulator-name = "3P3V";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
};
leds {
compatible = "gpio-leds";

34
arch/arm/boot/dts/imx6q-sabrelite.dts
View File

@ -32,18 +32,52 @@
usdhc@02198000 { /* uSDHC3 */
cd-gpios = <&gpio7 0 0>;
wp-gpios = <&gpio7 1 0>;
vmmc-supply = <&reg_3p3v>;
status = "okay";
};
usdhc@0219c000 { /* uSDHC4 */
cd-gpios = <&gpio2 6 0>;
wp-gpios = <&gpio2 7 0>;
vmmc-supply = <&reg_3p3v>;
status = "okay";
};
uart2: uart@021e8000 {
status = "okay";
};
i2c@021a0000 { /* I2C1 */
status = "okay";
clock-frequency = <100000>;
codec: sgtl5000@0a {
compatible = "fsl,sgtl5000";
reg = <0x0a>;
VDDA-supply = <&reg_2p5v>;
VDDIO-supply = <&reg_3p3v>;
};
};
};
};
regulators {
compatible = "simple-bus";
reg_2p5v: 2p5v {
compatible = "regulator-fixed";
regulator-name = "2P5V";
regulator-min-microvolt = <2500000>;
regulator-max-microvolt = <2500000>;
regulator-always-on;
};
reg_3p3v: 3p3v {
compatible = "regulator-fixed";
regulator-name = "3P3V";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
};
};

6
arch/arm/boot/dts/imx6q.dtsi
View File

@ -88,9 +88,9 @@
ranges;
timer@00a00600 {
compatible = "arm,smp-twd";
reg = <0x00a00600 0x100>;
interrupts = <1 13 0xf4>;
compatible = "arm,cortex-a9-twd-timer";
reg = <0x00a00600 0x20>;
interrupts = <1 13 0xf01>;
};
L2: l2-cache@00a02000 {

25
arch/arm/boot/dts/kirkwood-dreamplug.dts Normal file
View File

@ -0,0 +1,25 @@
/dts-v1/;
/include/ "kirkwood.dtsi"
/ {
model = "Globalscale Technologies Dreamplug";
compatible = "globalscale,dreamplug-003-ds2001", "globalscale,dreamplug", "marvell,kirkwood-88f6281", "marvell,kirkwood";
memory {
device_type = "memory";
reg = <0x00000000 0x20000000>;
};
chosen {
bootargs = "console=ttyS0,115200n8 earlyprintk";
};
serial@f1012000 {
compatible = "ns16550a";
reg = <0xf1012000 0xff>;
reg-shift = <2>;
interrupts = <33>;
clock-frequency = <200000000>;
};
};

6
arch/arm/boot/dts/kirkwood.dtsi Normal file
View File

@ -0,0 +1,6 @@
/include/ "skeleton.dtsi"
/ {
compatible = "marvell,kirkwood";
};

9
arch/arm/boot/dts/omap3-beagle.dts
View File

@ -13,15 +13,6 @@
model = "TI OMAP3 BeagleBoard";
compatible = "ti,omap3-beagle", "ti,omap3";
/*
* Since the initial device tree board file does not create any
* devices (MMC, network...), the only way to boot is to provide a
* ramdisk.
*/
chosen {
bootargs = "root=/dev/ram0 rw console=ttyO2,115200n8 initrd=0x81600000,20M ramdisk_size=20480 no_console_suspend debug earlyprintk";
};
memory {
device_type = "memory";
reg = <0x80000000 0x20000000>; /* 512 MB */

20
arch/arm/boot/dts/omap3-evm.dts Normal file
View File

@ -0,0 +1,20 @@
/*
* Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/dts-v1/;
/include/ "omap3.dtsi"
/ {
model = "TI OMAP3 EVM (OMAP3530, AM/DM37x)";
compatible = "ti,omap3-evm", "ti,omap3";
memory {
device_type = "memory";
reg = <0x80000000 0x10000000>; /* 256 MB */
};
};

35
arch/arm/boot/dts/omap3.dtsi
View File

@ -61,34 +61,57 @@
ranges;
ti,hwmods = "l3_main";
intc: interrupt-controller@1 {
compatible = "ti,omap3-intc";
intc: interrupt-controller@48200000 {
compatible = "ti,omap2-intc";
interrupt-controller;
#interrupt-cells = <1>;
ti,intc-size = <96>;
reg = <0x48200000 0x1000>;
};
uart1: serial@0x4806a000 {
uart1: serial@4806a000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart1";
clock-frequency = <48000000>;
};
uart2: serial@0x4806c000 {
uart2: serial@4806c000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart2";
clock-frequency = <48000000>;
};
uart3: serial@0x49020000 {
uart3: serial@49020000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart3";
clock-frequency = <48000000>;
};
uart4: serial@0x49042000 {
uart4: serial@49042000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart4";
clock-frequency = <48000000>;
};
i2c1: i2c@48070000 {
compatible = "ti,omap3-i2c";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c1";
};
i2c2: i2c@48072000 {
compatible = "ti,omap3-i2c";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c2";
};
i2c3: i2c@48060000 {
compatible = "ti,omap3-i2c";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c3";
};
};
};

9
arch/arm/boot/dts/omap4-panda.dts
View File

@ -13,15 +13,6 @@
model = "TI OMAP4 PandaBoard";
compatible = "ti,omap4-panda", "ti,omap4430", "ti,omap4";
/*
* Since the initial device tree board file does not create any
* devices (MMC, network...), the only way to boot is to provide a
* ramdisk.
*/
chosen {
bootargs = "root=/dev/ram0 rw console=ttyO2,115200n8 initrd=0x81600000,20M ramdisk_size=20480 no_console_suspend debug";
};
memory {
device_type = "memory";
reg = <0x80000000 0x40000000>; /* 1 GB */

9
arch/arm/boot/dts/omap4-sdp.dts
View File

@ -13,15 +13,6 @@
model = "TI OMAP4 SDP board";
compatible = "ti,omap4-sdp", "ti,omap4430", "ti,omap4";
/*
* Since the initial device tree board file does not create any
* devices (MMC, network...), the only way to boot is to provide a
* ramdisk.
*/
chosen {
bootargs = "root=/dev/ram0 rw console=ttyO2,115200n8 initrd=0x81600000,20M ramdisk_size=20480 no_console_suspend debug";
};
memory {
device_type = "memory";
reg = <0x80000000 0x40000000>; /* 1 GB */

38
arch/arm/boot/dts/omap4.dtsi
View File

@ -99,33 +99,61 @@
gic: interrupt-controller@48241000 {
compatible = "arm,cortex-a9-gic";
interrupt-controller;
#interrupt-cells = <1>;
#interrupt-cells = <3>;
reg = <0x48241000 0x1000>,
<0x48240100 0x0100>;
};
uart1: serial@0x4806a000 {
uart1: serial@4806a000 {
compatible = "ti,omap4-uart";
ti,hwmods = "uart1";
clock-frequency = <48000000>;
};
uart2: serial@0x4806c000 {
uart2: serial@4806c000 {
compatible = "ti,omap4-uart";
ti,hwmods = "uart2";
clock-frequency = <48000000>;
};
uart3: serial@0x48020000 {
uart3: serial@48020000 {
compatible = "ti,omap4-uart";
ti,hwmods = "uart3";
clock-frequency = <48000000>;
};
uart4: serial@0x4806e000 {
uart4: serial@4806e000 {
compatible = "ti,omap4-uart";
ti,hwmods = "uart4";
clock-frequency = <48000000>;
};
i2c1: i2c@48070000 {
compatible = "ti,omap4-i2c";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c1";
};
i2c2: i2c@48072000 {
compatible = "ti,omap4-i2c";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c2";
};
i2c3: i2c@48060000 {
compatible = "ti,omap4-i2c";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c3";
};
i2c4: i2c@48350000 {
compatible = "ti,omap4-i2c";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c4";
};
};
};

38
arch/arm/boot/dts/pxa168-aspenite.dts Normal file
View File

@ -0,0 +1,38 @@
/*
* Copyright (C) 2012 Marvell Technology Group Ltd.
* Author: Haojian Zhuang <haojian.zhuang@marvell.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* publishhed by the Free Software Foundation.
*/
/dts-v1/;
/include/ "pxa168.dtsi"
/ {
model = "Marvell PXA168 Aspenite Development Board";
compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";
chosen {
bootargs = "console=ttyS0,115200 root=/dev/nfs nfsroot=192.168.1.100:/nfsroot/ ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on";
};
memory {
reg = <0x00000000 0x04000000>;
};
soc {
apb@d4000000 {
uart1: uart@d4017000 {
status = "okay";
};
twsi1: i2c@d4011000 {
status = "okay";
};
rtc: rtc@d4010000 {
status = "okay";
};
};
};
};

98
arch/arm/boot/dts/pxa168.dtsi Normal file
View File

@ -0,0 +1,98 @@
/*
* Copyright (C) 2012 Marvell Technology Group Ltd.
* Author: Haojian Zhuang <haojian.zhuang@marvell.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* publishhed by the Free Software Foundation.
*/
/include/ "skeleton.dtsi"
/ {
aliases {
serial0 = &uart1;
serial1 = &uart2;
serial2 = &uart3;
i2c0 = &twsi1;
i2c1 = &twsi2;
};
intc: intc-interrupt-controller@d4282000 {
compatible = "mrvl,mmp-intc", "mrvl,intc";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0xd4282000 0x1000>;
};
soc {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
interrupt-parent = <&intc>;
ranges;
apb@d4000000 { /* APB */
compatible = "mrvl,apb-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
reg = <0xd4000000 0x00200000>;
ranges;
uart1: uart@d4017000 {
compatible = "mrvl,mmp-uart", "mrvl,pxa-uart";
reg = <0xd4017000 0x1000>;
interrupts = <27>;
status = "disabled";
};
uart2: uart@d4018000 {
compatible = "mrvl,mmp-uart", "mrvl,pxa-uart";
reg = <0xd4018000 0x1000>;
interrupts = <28>;
status = "disabled";
};
uart3: uart@d4026000 {
compatible = "mrvl,mmp-uart", "mrvl,pxa-uart";
reg = <0xd4026000 0x1000>;
interrupts = <29>;
status = "disabled";
};
gpio: gpio@d4019000 {
compatible = "mrvl,mmp-gpio", "mrvl,pxa-gpio";
reg = <0xd4019000 0x1000>;
interrupts = <49>;
interrupt-names = "gpio_mux";
gpio-controller;
#gpio-cells = <1>;
interrupt-controller;
#interrupt-cells = <1>;
};
twsi1: i2c@d4011000 {
compatible = "mrvl,mmp-twsi", "mrvl,pxa-i2c";
reg = <0xd4011000 0x1000>;
interrupts = <7>;
mrvl,i2c-fast-mode;
status = "disabled";
};
twsi2: i2c@d4025000 {
compatible = "mrvl,mmp-twsi", "mrvl,pxa-i2c";
reg = <0xd4025000 0x1000>;
interrupts = <58>;
status = "disabled";
};
rtc: rtc@d4010000 {
compatible = "mrvl,mmp-rtc";
reg = <0xd4010000 0x1000>;
interrupts = <5 6>;
interrupt-names = "rtc 1Hz", "rtc alarm";
status = "disabled";
};
};
};
};

34
arch/arm/boot/dts/tegra-cardhu.dts
View File

@ -14,6 +14,22 @@
clock-frequency = < 408000000 >;
};
serial@70006040 {
status = "disable";
};
serial@70006200 {
status = "disable";
};
serial@70006300 {
status = "disable";
};
serial@70006400 {
status = "disable";
};
i2c@7000c000 {
clock-frequency = <100000>;
};
@ -33,4 +49,22 @@
i2c@7000d000 {
clock-frequency = <100000>;
};
sdhci@78000000 {
cd-gpios = <&gpio 69 0>; /* gpio PI5 */
wp-gpios = <&gpio 155 0>; /* gpio PT3 */
power-gpios = <&gpio 31 0>; /* gpio PD7 */
};
sdhci@78000200 {
status = "disable";
};
sdhci@78000400 {
status = "disable";
};
sdhci@78000400 {
support-8bit;
};
};

45
arch/arm/boot/dts/tegra-harmony.dts
View File

@ -10,19 +10,25 @@
reg = < 0x00000000 0x40000000 >;
};
pmc@7000f400 {
nvidia,invert-interrupt;
};
i2c@7000c000 {
clock-frequency = <400000>;
codec: wm8903@1a {
wm8903: wm8903@1a {
compatible = "wlf,wm8903";
reg = <0x1a>;
interrupts = < 347 >;
interrupt-parent = <&gpio>;
interrupts = < 187 0x04 >;
gpio-controller;
#gpio-cells = <2>;
/* 0x8000 = Not configured */
gpio-cfg = < 0x8000 0x8000 0 0x8000 0x8000 >;
micdet-cfg = <0>;
micdet-delay = <100>;
gpio-cfg = < 0xffffffff 0xffffffff 0 0xffffffff 0xffffffff >;
};
};
@ -38,13 +44,32 @@
clock-frequency = <400000>;
};
sound {
compatible = "nvidia,harmony-sound", "nvidia,tegra-wm8903";
i2s@70002a00 {
status = "disable";
};
spkr-en-gpios = <&codec 2 0>;
hp-det-gpios = <&gpio 178 0>;
int-mic-en-gpios = <&gpio 184 0>;
ext-mic-en-gpios = <&gpio 185 0>;
sound {
compatible = "nvidia,tegra-audio-wm8903-harmony",
"nvidia,tegra-audio-wm8903";
nvidia,model = "NVIDIA Tegra Harmony";
nvidia,audio-routing =
"Headphone Jack", "HPOUTR",
"Headphone Jack", "HPOUTL",
"Int Spk", "ROP",
"Int Spk", "RON",
"Int Spk", "LOP",
"Int Spk", "LON",
"Mic Jack", "MICBIAS",
"IN1L", "Mic Jack";
nvidia,i2s-controller = <&tegra_i2s1>;
nvidia,audio-codec = <&wm8903>;
nvidia,spkr-en-gpios = <&wm8903 2 0>;
nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */
nvidia,int-mic-en-gpios = <&gpio 184 0>; /*gpio PX0 */
nvidia,ext-mic-en-gpios = <&gpio 185 0>; /* gpio PX1 */
};
serial@70006000 {

57
arch/arm/boot/dts/tegra-paz00.dts
View File

@ -12,6 +12,13 @@
i2c@7000c000 {
clock-frequency = <400000>;
alc5632: alc5632@1e {
compatible = "realtek,alc5632";
reg = <0x1e>;
gpio-controller;
#gpio-cells = <2>;
};
};
i2c@7000c400 {
@ -35,6 +42,35 @@
i2c@7000d000 {
clock-frequency = <400000>;
adt7461@4c {
compatible = "adi,adt7461";
reg = <0x4c>;
};
};
i2s@70002a00 {
status = "disable";
};
sound {
compatible = "nvidia,tegra-audio-alc5632-paz00",
"nvidia,tegra-audio-alc5632";
nvidia,model = "Compal PAZ00";
nvidia,audio-routing =
"Int Spk", "SPKOUT",
"Int Spk", "SPKOUTN",
"Headset Mic", "MICBIAS1",
"MIC1", "Headset Mic",
"Headset Stereophone", "HPR",
"Headset Stereophone", "HPL",
"DMICDAT", "Digital Mic";
nvidia,audio-codec = <&alc5632>;
nvidia,i2s-controller = <&tegra_i2s1>;
nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */
};
serial@70006000 {
@ -74,4 +110,25 @@
sdhci@c8000600 {
support-8bit;
};
gpio-keys {
compatible = "gpio-keys";
power {
label = "Power";
gpios = <&gpio 79 1>; /* gpio PJ7, active low */
linux,code = <116>; /* KEY_POWER */
gpio-key,wakeup;
};
};
gpio-leds {
compatible = "gpio-leds";
wifi {
label = "wifi-led";
gpios = <&gpio 24 0>;
linux,default-trigger = "rfkill0";
};
};
};

78
arch/arm/boot/dts/tegra-seaboard.dts
View File

@ -13,6 +13,20 @@
i2c@7000c000 {
clock-frequency = <400000>;
wm8903: wm8903@1a {
compatible = "wlf,wm8903";
reg = <0x1a>;
interrupt-parent = <&gpio>;
interrupts = < 187 0x04 >;
gpio-controller;
#gpio-cells = <2>;
micdet-cfg = <0>;
micdet-delay = <100>;
gpio-cfg = < 0xffffffff 0xffffffff 0 0xffffffff 0xffffffff >;
};
};
i2c@7000c400 {
@ -32,6 +46,32 @@
};
};
i2s@70002a00 {
status = "disable";
};
sound {
compatible = "nvidia,tegra-audio-wm8903-seaboard",
"nvidia,tegra-audio-wm8903";
nvidia,model = "NVIDIA Tegra Seaboard";
nvidia,audio-routing =
"Headphone Jack", "HPOUTR",
"Headphone Jack", "HPOUTL",
"Int Spk", "ROP",
"Int Spk", "RON",
"Int Spk", "LOP",
"Int Spk", "LON",
"Mic Jack", "MICBIAS",
"IN1R", "Mic Jack";
nvidia,i2s-controller = <&tegra_i2s1>;
nvidia,audio-codec = <&wm8903>;
nvidia,spkr-en-gpios = <&wm8903 2 0>;
nvidia,hp-det-gpios = <&gpio 185 0>; /* gpio PX1 */
};
serial@70006000 {
status = "disable";
};
@ -93,4 +133,42 @@
gpio-key,wakeup;
};
};
emc@7000f400 {
emc-table@190000 {
reg = < 190000 >;
compatible = "nvidia,tegra20-emc-table";
clock-frequency = < 190000 >;
nvidia,emc-registers = < 0x0000000c 0x00000026
0x00000009 0x00000003 0x00000004 0x00000004
0x00000002 0x0000000c 0x00000003 0x00000003
0x00000002 0x00000001 0x00000004 0x00000005
0x00000004 0x00000009 0x0000000d 0x0000059f
0x00000000 0x00000003 0x00000003 0x00000003
0x00000003 0x00000001 0x0000000b 0x000000c8
0x00000003 0x00000007 0x00000004 0x0000000f
0x00000002 0x00000000 0x00000000 0x00000002
0x00000000 0x00000000 0x00000083 0xa06204ae
0x007dc010 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 >;
};
emc-table@380000 {
reg = < 380000 >;
compatible = "nvidia,tegra20-emc-table";
clock-frequency = < 380000 >;
nvidia,emc-registers = < 0x00000017 0x0000004b
0x00000012 0x00000006 0x00000004 0x00000005
0x00000003 0x0000000c 0x00000006 0x00000006
0x00000003 0x00000001 0x00000004 0x00000005
0x00000004 0x00000009 0x0000000d 0x00000b5f
0x00000000 0x00000003 0x00000003 0x00000006
0x00000006 0x00000001 0x00000011 0x000000c8
0x00000003 0x0000000e 0x00000007 0x0000000f
0x00000002 0x00000000 0x00000000 0x00000002
0x00000000 0x00000000 0x00000083 0xe044048b
0x007d8010 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 >;
};
};
};

12
arch/arm/boot/dts/tegra-trimslice.dts
View File

@ -26,6 +26,18 @@
status = "disable";
};
i2s@70002800 {
status = "disable";
};
i2s@70002a00 {
status = "disable";
};
das@70000c00 {
status = "disable";
};
serial@70006000 {
clock-frequency = < 216000000 >;
};

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