mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2025-01-09 06:33:34 +00:00
Merge git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
Pulled mainline in order to get the UAPI infrastructure already merged before I pull in David Howells's UAPI trees for networking. Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
commit
8dd9117cc7
@ -270,8 +270,6 @@ preempt-locking.txt
|
||||
- info on locking under a preemptive kernel.
|
||||
printk-formats.txt
|
||||
- how to get printk format specifiers right
|
||||
prio_tree.txt
|
||||
- info on radix-priority-search-tree use for indexing vmas.
|
||||
ramoops.txt
|
||||
- documentation of the ramoops oops/panic logging module.
|
||||
rbtree.txt
|
||||
|
@ -1,22 +0,0 @@
|
||||
What: /proc/<pid>/oom_adj
|
||||
When: August 2012
|
||||
Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's
|
||||
badness heuristic used to determine which task to kill when the kernel
|
||||
is out of memory.
|
||||
|
||||
The badness heuristic has since been rewritten since the introduction of
|
||||
this tunable such that its meaning is deprecated. The value was
|
||||
implemented as a bitshift on a score generated by the badness()
|
||||
function that did not have any precise units of measure. With the
|
||||
rewrite, the score is given as a proportion of available memory to the
|
||||
task allocating pages, so using a bitshift which grows the score
|
||||
exponentially is, thus, impossible to tune with fine granularity.
|
||||
|
||||
A much more powerful interface, /proc/<pid>/oom_score_adj, was
|
||||
introduced with the oom killer rewrite that allows users to increase or
|
||||
decrease the badness score linearly. This interface will replace
|
||||
/proc/<pid>/oom_adj.
|
||||
|
||||
A warning will be emitted to the kernel log if an application uses this
|
||||
deprecated interface. After it is printed once, future warnings will be
|
||||
suppressed until the kernel is rebooted.
|
@ -25,6 +25,10 @@ client_id
|
||||
|
||||
The ceph unique client id that was assigned for this specific session.
|
||||
|
||||
features
|
||||
|
||||
A hexadecimal encoding of the feature bits for this image.
|
||||
|
||||
major
|
||||
|
||||
The block device major number.
|
||||
@ -33,6 +37,11 @@ name
|
||||
|
||||
The name of the rbd image.
|
||||
|
||||
image_id
|
||||
|
||||
The unique id for the rbd image. (For rbd image format 1
|
||||
this is empty.)
|
||||
|
||||
pool
|
||||
|
||||
The name of the storage pool where this rbd image resides.
|
||||
@ -57,12 +66,6 @@ current_snap
|
||||
|
||||
The current snapshot for which the device is mapped.
|
||||
|
||||
create_snap
|
||||
|
||||
Create a snapshot:
|
||||
|
||||
$ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_create
|
||||
|
||||
snap_*
|
||||
|
||||
A directory per each snapshot
|
||||
@ -79,4 +82,7 @@ snap_size
|
||||
|
||||
The size of the image when this snapshot was taken.
|
||||
|
||||
snap_features
|
||||
|
||||
A hexadecimal encoding of the feature bits for this snapshot.
|
||||
|
||||
|
17
Documentation/ABI/testing/sysfs-devices-firmware_node
Normal file
17
Documentation/ABI/testing/sysfs-devices-firmware_node
Normal file
@ -0,0 +1,17 @@
|
||||
What: /sys/devices/.../firmware_node/
|
||||
Date: September 2012
|
||||
Contact: <>
|
||||
Description:
|
||||
The /sys/devices/.../firmware_node directory contains attributes
|
||||
allowing the user space to check and modify some firmware
|
||||
related properties of given device.
|
||||
|
||||
What: /sys/devices/.../firmware_node/description
|
||||
Date: September 2012
|
||||
Contact: Lance Ortiz <lance.ortiz@hp.com>
|
||||
Description:
|
||||
The /sys/devices/.../firmware/description attribute contains a string
|
||||
that describes the device as provided by the _STR method in the ACPI
|
||||
namespace. This attribute is read-only. If the device does not have
|
||||
an _STR method associated with it in the ACPI namespace, this
|
||||
attribute is not present.
|
@ -96,3 +96,16 @@ Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
The maximum number of megabytes the writeback code will
|
||||
try to write out before move on to another inode.
|
||||
|
||||
What: /sys/fs/ext4/<disk>/extent_max_zeroout_kb
|
||||
Date: August 2012
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
The maximum number of kilobytes which will be zeroed
|
||||
out in preference to creating a new uninitialized
|
||||
extent when manipulating an inode's extent tree. Note
|
||||
that using a larger value will increase the
|
||||
variability of time necessary to complete a random
|
||||
write operation (since a 4k random write might turn
|
||||
into a much larger write due to the zeroout
|
||||
operation).
|
||||
|
@ -300,7 +300,7 @@ $(MEDIA_OBJ_DIR)/media-entities.tmpl: $(MEDIA_OBJ_DIR)/v4l2.xml
|
||||
@( \
|
||||
for ident in $(IOCTLS) ; do \
|
||||
entity=`echo $$ident | tr _ -` ; \
|
||||
id=`grep "<refname>$$ident" $(MEDIA_OBJ_DIR)/vidioc-*.xml | sed -r s,"^.*/(.*).xml.*","\1",` ; \
|
||||
id=`grep "<refname>$$ident" $(MEDIA_OBJ_DIR)/vidioc-*.xml $(MEDIA_OBJ_DIR)/media-ioc-*.xml | sed -r s,"^.*/(.*).xml.*","\1",` ; \
|
||||
echo "<!ENTITY $$entity \"<link" \
|
||||
"linkend='$$id'><constant>$$ident</constant></link>\">" \
|
||||
>>$@ ; \
|
||||
|
@ -1,12 +1,16 @@
|
||||
<title>DVB Audio Device</title>
|
||||
<para>The DVB audio device controls the MPEG2 audio decoder of the DVB hardware. It
|
||||
can be accessed through <emphasis role="tt">/dev/dvb/adapter0/audio0</emphasis>. Data types and and
|
||||
ioctl definitions can be accessed by including <emphasis role="tt">linux/dvb/video.h</emphasis> in your
|
||||
ioctl definitions can be accessed by including <emphasis role="tt">linux/dvb/audio.h</emphasis> in your
|
||||
application.
|
||||
</para>
|
||||
<para>Please note that some DVB cards don’t have their own MPEG decoder, which results in
|
||||
the omission of the audio and video device.
|
||||
</para>
|
||||
<para>
|
||||
These ioctls were also used by V4L2 to control MPEG decoders implemented in V4L2. The use
|
||||
of these ioctls for that purpose has been made obsolete and proper V4L2 ioctls or controls
|
||||
have been created to replace that functionality.</para>
|
||||
|
||||
<section id="audio_data_types">
|
||||
<title>Audio Data Types</title>
|
||||
@ -558,6 +562,8 @@ role="subsection"><title>AUDIO_SELECT_SOURCE</title>
|
||||
role="subsection"><title>AUDIO_SET_MUTE</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2
|
||||
&VIDIOC-DECODER-CMD; with the <constant>V4L2_DEC_CMD_START_MUTE_AUDIO</constant> flag instead.</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl call asks the audio device to mute the stream that is currently being
|
||||
@ -730,6 +736,8 @@ role="subsection"><title>AUDIO_SET_BYPASS_MODE</title>
|
||||
role="subsection"><title>AUDIO_CHANNEL_SELECT</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2
|
||||
<constant>V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK</constant> control instead.</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl call asks the Audio Device to select the requested channel if possible.</para>
|
||||
@ -772,6 +780,109 @@ role="subsection"><title>AUDIO_CHANNEL_SELECT</title>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
|
||||
</section><section id="AUDIO_BILINGUAL_CHANNEL_SELECT"
|
||||
role="subsection"><title>AUDIO_BILINGUAL_CHANNEL_SELECT</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<para>This ioctl is obsolete. Do not use in new drivers. It has been replaced by
|
||||
the V4L2 <constant>V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK</constant> control
|
||||
for MPEG decoders controlled through V4L2.</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl call asks the Audio Device to select the requested channel for bilingual streams if possible.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request =
|
||||
AUDIO_BILINGUAL_CHANNEL_SELECT, audio_channel_select_t);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals AUDIO_BILINGUAL_CHANNEL_SELECT for this
|
||||
command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>audio_channel_select_t
|
||||
ch</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Select the output format of the audio (mono left/right,
|
||||
stereo).</para>
|
||||
</entry>
|
||||
</row>
|
||||
</tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
|
||||
</section><section id="AUDIO_GET_PTS"
|
||||
role="subsection"><title>AUDIO_GET_PTS</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<para>This ioctl is obsolete. Do not use in new drivers. If you need this functionality,
|
||||
then please contact the linux-media mailing list (&v4l-ml;).</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl call asks the Audio Device to return the current PTS timestamp.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request =
|
||||
AUDIO_GET_PTS, __u64 *pts);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals AUDIO_GET_PTS for this
|
||||
command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>__u64 *pts
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Returns the 33-bit timestamp as defined in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
|
||||
</para>
|
||||
<para>
|
||||
The PTS should belong to the currently played
|
||||
frame if possible, but may also be a value close to it
|
||||
like the PTS of the last decoded frame or the last PTS
|
||||
extracted by the PES parser.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
|
||||
</section><section id="AUDIO_GET_STATUS"
|
||||
role="subsection"><title>AUDIO_GET_STATUS</title>
|
||||
<para>DESCRIPTION
|
||||
|
@ -226,4 +226,357 @@ typedef struct ca_pid {
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="CA_RESET"
|
||||
role="subsection"><title>CA_RESET</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl is undocumented. Documentation is welcome.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(fd, int request = CA_RESET);
|
||||
</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals CA_RESET for this command.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
</section>
|
||||
|
||||
<section id="CA_GET_CAP"
|
||||
role="subsection"><title>CA_GET_CAP</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl is undocumented. Documentation is welcome.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(fd, int request = CA_GET_CAP,
|
||||
ca_caps_t *);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals CA_GET_CAP for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>ca_caps_t *
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Undocumented.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
</section>
|
||||
|
||||
<section id="CA_GET_SLOT_INFO"
|
||||
role="subsection"><title>CA_GET_SLOT_INFO</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl is undocumented. Documentation is welcome.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(fd, int request = CA_GET_SLOT_INFO,
|
||||
ca_slot_info_t *);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals CA_GET_SLOT_INFO for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>ca_slot_info_t *
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Undocumented.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
</section>
|
||||
|
||||
<section id="CA_GET_DESCR_INFO"
|
||||
role="subsection"><title>CA_GET_DESCR_INFO</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl is undocumented. Documentation is welcome.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(fd, int request = CA_GET_DESCR_INFO,
|
||||
ca_descr_info_t *);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals CA_GET_DESCR_INFO for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>ca_descr_info_t *
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Undocumented.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
</section>
|
||||
|
||||
<section id="CA_GET_MSG"
|
||||
role="subsection"><title>CA_GET_MSG</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl is undocumented. Documentation is welcome.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(fd, int request = CA_GET_MSG,
|
||||
ca_msg_t *);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals CA_GET_MSG for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>ca_msg_t *
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Undocumented.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
</section>
|
||||
|
||||
<section id="CA_SEND_MSG"
|
||||
role="subsection"><title>CA_SEND_MSG</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl is undocumented. Documentation is welcome.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(fd, int request = CA_SEND_MSG,
|
||||
ca_msg_t *);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals CA_SEND_MSG for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>ca_msg_t *
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Undocumented.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
</section>
|
||||
|
||||
<section id="CA_SET_DESCR"
|
||||
role="subsection"><title>CA_SET_DESCR</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl is undocumented. Documentation is welcome.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(fd, int request = CA_SET_DESCR,
|
||||
ca_descr_t *);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals CA_SET_DESCR for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>ca_descr_t *
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Undocumented.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
</section>
|
||||
|
||||
<section id="CA_SET_PID"
|
||||
role="subsection"><title>CA_SET_PID</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl is undocumented. Documentation is welcome.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(fd, int request = CA_SET_PID,
|
||||
ca_pid_t *);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals CA_SET_PID for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>ca_pid_t *
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Undocumented.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
</section>
|
||||
|
||||
</section>
|
||||
|
@ -899,4 +899,232 @@ typedef enum {
|
||||
<para>Invalid stc number.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
</section></section>
|
||||
</section>
|
||||
|
||||
<section id="DMX_GET_PES_PIDS"
|
||||
role="subsection"><title>DMX_GET_PES_PIDS</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl is undocumented. Documentation is welcome.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(fd, int request = DMX_GET_PES_PIDS,
|
||||
__u16[5]);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals DMX_GET_PES_PIDS for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>__u16[5]
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Undocumented.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
</section>
|
||||
|
||||
<section id="DMX_GET_CAPS"
|
||||
role="subsection"><title>DMX_GET_CAPS</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl is undocumented. Documentation is welcome.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(fd, int request = DMX_GET_CAPS,
|
||||
dmx_caps_t *);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals DMX_GET_CAPS for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>dmx_caps_t *
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Undocumented.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
</section>
|
||||
|
||||
<section id="DMX_SET_SOURCE"
|
||||
role="subsection"><title>DMX_SET_SOURCE</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl is undocumented. Documentation is welcome.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(fd, int request = DMX_SET_SOURCE,
|
||||
dmx_source_t *);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals DMX_SET_SOURCE for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>dmx_source_t *
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Undocumented.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
</section>
|
||||
|
||||
<section id="DMX_ADD_PID"
|
||||
role="subsection"><title>DMX_ADD_PID</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl is undocumented. Documentation is welcome.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(fd, int request = DMX_ADD_PID,
|
||||
__u16 *);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals DMX_ADD_PID for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>__u16 *
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Undocumented.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
</section>
|
||||
|
||||
<section id="DMX_REMOVE_PID"
|
||||
role="subsection"><title>DMX_REMOVE_PID</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl is undocumented. Documentation is welcome.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(fd, int request = DMX_REMOVE_PID,
|
||||
__u16 *);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals DMX_REMOVE_PID for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>__u16 *
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Undocumented.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
</section>
|
||||
|
||||
|
||||
</section>
|
||||
|
@ -28,7 +28,7 @@
|
||||
<holder>Convergence GmbH</holder>
|
||||
</copyright>
|
||||
<copyright>
|
||||
<year>2009-2011</year>
|
||||
<year>2009-2012</year>
|
||||
<holder>Mauro Carvalho Chehab</holder>
|
||||
</copyright>
|
||||
|
||||
@ -84,7 +84,7 @@ Added ISDB-T test originally written by Patrick Boettcher
|
||||
|
||||
|
||||
<title>LINUX DVB API</title>
|
||||
<subtitle>Version 5.2</subtitle>
|
||||
<subtitle>Version 5.8</subtitle>
|
||||
<!-- ADD THE CHAPTERS HERE -->
|
||||
<chapter id="dvb_introdution">
|
||||
&sub-intro;
|
||||
|
@ -194,6 +194,7 @@ get/set up to 64 properties. The actual meaning of each property is described on
|
||||
APSK_16,
|
||||
APSK_32,
|
||||
DQPSK,
|
||||
QAM_4_NR,
|
||||
} fe_modulation_t;
|
||||
</programlisting>
|
||||
</section>
|
||||
@ -265,6 +266,7 @@ typedef enum fe_code_rate {
|
||||
FEC_AUTO,
|
||||
FEC_3_5,
|
||||
FEC_9_10,
|
||||
FEC_2_5,
|
||||
} fe_code_rate_t;
|
||||
</programlisting>
|
||||
<para>which correspond to error correction rates of 1/2, 2/3, etc.,
|
||||
@ -351,7 +353,7 @@ typedef enum fe_delivery_system {
|
||||
SYS_ISDBC,
|
||||
SYS_ATSC,
|
||||
SYS_ATSCMH,
|
||||
SYS_DMBTH,
|
||||
SYS_DTMB,
|
||||
SYS_CMMB,
|
||||
SYS_DAB,
|
||||
SYS_DVBT2,
|
||||
@ -567,28 +569,33 @@ typedef enum fe_delivery_system {
|
||||
<title><constant>DTV_ATSCMH_RS_FRAME_MODE</constant></title>
|
||||
<para>RS frame mode.</para>
|
||||
<para>Possible values are:</para>
|
||||
<para id="atscmh-rs-frame-mode">
|
||||
<programlisting>
|
||||
typedef enum atscmh_rs_frame_mode {
|
||||
ATSCMH_RSFRAME_PRI_ONLY = 0,
|
||||
ATSCMH_RSFRAME_PRI_SEC = 1,
|
||||
} atscmh_rs_frame_mode_t;
|
||||
</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-RS-FRAME-ENSEMBLE">
|
||||
<title><constant>DTV_ATSCMH_RS_FRAME_ENSEMBLE</constant></title>
|
||||
<para>RS frame ensemble.</para>
|
||||
<para>Possible values are:</para>
|
||||
<para id="atscmh-rs-frame-ensemble">
|
||||
<programlisting>
|
||||
typedef enum atscmh_rs_frame_ensemble {
|
||||
ATSCMH_RSFRAME_ENS_PRI = 0,
|
||||
ATSCMH_RSFRAME_ENS_SEC = 1,
|
||||
} atscmh_rs_frame_ensemble_t;
|
||||
</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-RS-CODE-MODE-PRI">
|
||||
<title><constant>DTV_ATSCMH_RS_CODE_MODE_PRI</constant></title>
|
||||
<para>RS code mode (primary).</para>
|
||||
<para>Possible values are:</para>
|
||||
<para id="atscmh-rs-code-mode">
|
||||
<programlisting>
|
||||
typedef enum atscmh_rs_code_mode {
|
||||
ATSCMH_RSCODE_211_187 = 0,
|
||||
@ -596,6 +603,7 @@ typedef enum atscmh_rs_code_mode {
|
||||
ATSCMH_RSCODE_235_187 = 2,
|
||||
} atscmh_rs_code_mode_t;
|
||||
</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-RS-CODE-MODE-SEC">
|
||||
<title><constant>DTV_ATSCMH_RS_CODE_MODE_SEC</constant></title>
|
||||
@ -613,23 +621,27 @@ typedef enum atscmh_rs_code_mode {
|
||||
<title><constant>DTV_ATSCMH_SCCC_BLOCK_MODE</constant></title>
|
||||
<para>Series Concatenated Convolutional Code Block Mode.</para>
|
||||
<para>Possible values are:</para>
|
||||
<para id="atscmh-sccc-block-mode">
|
||||
<programlisting>
|
||||
typedef enum atscmh_sccc_block_mode {
|
||||
ATSCMH_SCCC_BLK_SEP = 0,
|
||||
ATSCMH_SCCC_BLK_COMB = 1,
|
||||
} atscmh_sccc_block_mode_t;
|
||||
</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-SCCC-CODE-MODE-A">
|
||||
<title><constant>DTV_ATSCMH_SCCC_CODE_MODE_A</constant></title>
|
||||
<para>Series Concatenated Convolutional Code Rate.</para>
|
||||
<para>Possible values are:</para>
|
||||
<para id="atscmh-sccc-code-mode">
|
||||
<programlisting>
|
||||
typedef enum atscmh_sccc_code_mode {
|
||||
ATSCMH_SCCC_CODE_HLF = 0,
|
||||
ATSCMH_SCCC_CODE_QTR = 1,
|
||||
} atscmh_sccc_code_mode_t;
|
||||
</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-SCCC-CODE-MODE-B">
|
||||
<title><constant>DTV_ATSCMH_SCCC_CODE_MODE_B</constant></title>
|
||||
@ -725,6 +737,9 @@ typedef enum fe_guard_interval {
|
||||
GUARD_INTERVAL_1_128,
|
||||
GUARD_INTERVAL_19_128,
|
||||
GUARD_INTERVAL_19_256,
|
||||
GUARD_INTERVAL_PN420,
|
||||
GUARD_INTERVAL_PN595,
|
||||
GUARD_INTERVAL_PN945,
|
||||
} fe_guard_interval_t;
|
||||
</programlisting>
|
||||
|
||||
@ -733,6 +748,7 @@ typedef enum fe_guard_interval {
|
||||
try to find the correct guard interval (if capable) and will use TMCC to fill
|
||||
in the missing parameters.</para>
|
||||
<para>2) Intervals 1/128, 19/128 and 19/256 are used only for DVB-T2 at present</para>
|
||||
<para>3) DTMB specifies PN420, PN595 and PN945.</para>
|
||||
</section>
|
||||
<section id="DTV-TRANSMISSION-MODE">
|
||||
<title><constant>DTV_TRANSMISSION_MODE</constant></title>
|
||||
@ -749,6 +765,8 @@ typedef enum fe_transmit_mode {
|
||||
TRANSMISSION_MODE_1K,
|
||||
TRANSMISSION_MODE_16K,
|
||||
TRANSMISSION_MODE_32K,
|
||||
TRANSMISSION_MODE_C1,
|
||||
TRANSMISSION_MODE_C3780,
|
||||
} fe_transmit_mode_t;
|
||||
</programlisting>
|
||||
<para>Notes:</para>
|
||||
@ -760,6 +778,7 @@ typedef enum fe_transmit_mode {
|
||||
use TMCC to fill in the missing parameters.</para>
|
||||
<para>3) DVB-T specifies 2K and 8K as valid sizes.</para>
|
||||
<para>4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K.</para>
|
||||
<para>5) DTMB specifies C1 and C3780.</para>
|
||||
</section>
|
||||
<section id="DTV-HIERARCHY">
|
||||
<title><constant>DTV_HIERARCHY</constant></title>
|
||||
@ -774,17 +793,28 @@ typedef enum fe_hierarchy {
|
||||
} fe_hierarchy_t;
|
||||
</programlisting>
|
||||
</section>
|
||||
<section id="DTV-ISDBS-TS-ID">
|
||||
<title><constant>DTV_ISDBS_TS_ID</constant></title>
|
||||
<para>Currently unused.</para>
|
||||
<section id="DTV-STREAM-ID">
|
||||
<title><constant>DTV_STREAM_ID</constant></title>
|
||||
<para>DVB-S2, DVB-T2 and ISDB-S support the transmission of several
|
||||
streams on a single transport stream.
|
||||
This property enables the DVB driver to handle substream filtering,
|
||||
when supported by the hardware.
|
||||
By default, substream filtering is disabled.
|
||||
</para><para>
|
||||
For DVB-S2 and DVB-T2, the valid substream id range is from 0 to 255.
|
||||
</para><para>
|
||||
For ISDB, the valid substream id range is from 1 to 65535.
|
||||
</para><para>
|
||||
To disable it, you should use the special macro NO_STREAM_ID_FILTER.
|
||||
</para><para>
|
||||
Note: any value outside the id range also disables filtering.
|
||||
</para>
|
||||
</section>
|
||||
<section id="DTV-DVBT2-PLP-ID">
|
||||
<title><constant>DTV_DVBT2_PLP_ID</constant></title>
|
||||
<para>DVB-T2 supports Physical Layer Pipes (PLP) to allow transmission of
|
||||
many data types via a single multiplex. The API will soon support this
|
||||
at which point this section will be expanded.</para>
|
||||
<section id="DTV-DVBT2-PLP-ID-LEGACY">
|
||||
<title><constant>DTV_DVBT2_PLP_ID_LEGACY</constant></title>
|
||||
<para>Obsolete, replaced with DTV_STREAM_ID.</para>
|
||||
</section>
|
||||
<section id="DTV_ENUM_DELSYS">
|
||||
<section id="DTV-ENUM-DELSYS">
|
||||
<title><constant>DTV_ENUM_DELSYS</constant></title>
|
||||
<para>A Multi standard frontend needs to advertise the delivery systems provided.
|
||||
Applications need to enumerate the provided delivery systems, before using
|
||||
@ -796,6 +826,29 @@ typedef enum fe_hierarchy {
|
||||
FE_GET_INFO. In the case of a legacy frontend, the result is just the same
|
||||
as with FE_GET_INFO, but in a more structured format </para>
|
||||
</section>
|
||||
<section id="DTV-INTERLEAVING">
|
||||
<title><constant>DTV_INTERLEAVING</constant></title>
|
||||
<para id="fe-interleaving">Interleaving mode</para>
|
||||
<programlisting>
|
||||
enum fe_interleaving {
|
||||
INTERLEAVING_NONE,
|
||||
INTERLEAVING_AUTO,
|
||||
INTERLEAVING_240,
|
||||
INTERLEAVING_720,
|
||||
};
|
||||
</programlisting>
|
||||
</section>
|
||||
<section id="DTV-LNA">
|
||||
<title><constant>DTV_LNA</constant></title>
|
||||
<para>Low-noise amplifier.</para>
|
||||
<para>Hardware might offer controllable LNA which can be set manually
|
||||
using that parameter. Usually LNA could be found only from
|
||||
terrestrial devices if at all.</para>
|
||||
<para>Possible values: 0, 1, LNA_AUTO</para>
|
||||
<para>0, LNA off</para>
|
||||
<para>1, LNA on</para>
|
||||
<para>use the special macro LNA_AUTO to set LNA auto</para>
|
||||
</section>
|
||||
</section>
|
||||
<section id="frontend-property-terrestrial-systems">
|
||||
<title>Properties used on terrestrial delivery systems</title>
|
||||
@ -816,6 +869,7 @@ typedef enum fe_hierarchy {
|
||||
<listitem><para><link linkend="DTV-GUARD-INTERVAL"><constant>DTV_GUARD_INTERVAL</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-TRANSMISSION-MODE"><constant>DTV_TRANSMISSION_MODE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="dvbt2-params">
|
||||
@ -838,7 +892,8 @@ typedef enum fe_hierarchy {
|
||||
<listitem><para><link linkend="DTV-GUARD-INTERVAL"><constant>DTV_GUARD_INTERVAL</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-TRANSMISSION-MODE"><constant>DTV_TRANSMISSION_MODE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-DVBT2-PLP-ID"><constant>DTV_DVBT2_PLP_ID</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="isdbt">
|
||||
@ -925,13 +980,32 @@ typedef enum fe_hierarchy {
|
||||
<listitem><para><link linkend="DTV-ATSCMH-PRC"><constant>DTV_ATSCMH_PRC</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-RS-FRAME-MODE"><constant>DTV_ATSCMH_RS_FRAME_MODE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-RS-FRAME-ENSEMBLE"><constant>DTV_ATSCMH_RS_FRAME_ENSEMBLE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-CODE-MODE-PRI"><constant>DTV_ATSCMH_CODE_MODE_PRI</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-CODE-MODE-SEC"><constant>DTV_ATSCMH_CODE_MODE_SEC</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-RS-CODE-MODE-PRI"><constant>DTV_ATSCMH_RS_CODE_MODE_PRI</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-RS-CODE-MODE-SEC"><constant>DTV_ATSCMH_RS_CODE_MODE_SEC</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-SCCC-BLOCK-MODE"><constant>DTV_ATSCMH_SCCC_BLOCK_MODE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-A"><constant>DTV_ATSCMH_SCCC_CODE_MODE_A</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-B"><constant>DTV_ATSCMH_SCCC_CODE_MODE_B</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-A"><constant>DTV_ATSCMH_SCCC_CODE_MODE_A</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-B"><constant>DTV_ATSCMH_SCCC_CODE_MODE_B</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="dtmb-params">
|
||||
<title>DTMB delivery system</title>
|
||||
<para>The following parameters are valid for DTMB:</para>
|
||||
<itemizedlist mark='opencircle'>
|
||||
<listitem><para><link linkend="DTV-API-VERSION"><constant>DTV_API_VERSION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-DELIVERY-SYSTEM"><constant>DTV_DELIVERY_SYSTEM</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-TUNE"><constant>DTV_TUNE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-CLEAR"><constant>DTV_CLEAR</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-FREQUENCY"><constant>DTV_FREQUENCY</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-GUARD-INTERVAL"><constant>DTV_GUARD_INTERVAL</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-TRANSMISSION-MODE"><constant>DTV_TRANSMISSION_MODE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-INTERLEAVING"><constant>DTV_INTERLEAVING</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</section>
|
||||
@ -952,6 +1026,7 @@ typedef enum fe_hierarchy {
|
||||
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-SYMBOL-RATE"><constant>DTV_SYMBOL_RATE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="dvbc-annex-b-params">
|
||||
@ -966,6 +1041,7 @@ typedef enum fe_hierarchy {
|
||||
<listitem><para><link linkend="DTV-FREQUENCY"><constant>DTV_FREQUENCY</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</section>
|
||||
@ -999,6 +1075,7 @@ typedef enum fe_hierarchy {
|
||||
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-PILOT"><constant>DTV_PILOT</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="turbo-params">
|
||||
@ -1021,7 +1098,7 @@ typedef enum fe_hierarchy {
|
||||
<listitem><para><link linkend="DTV-SYMBOL-RATE"><constant>DTV_SYMBOL_RATE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ISDBS-TS-ID"><constant>DTV_ISDBS_TS_ID</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</section>
|
||||
|
@ -66,7 +66,7 @@ supported via the new <link linkend="FE_GET_SET_PROPERTY">FE_GET_PROPERTY/FE_GET
|
||||
|
||||
<para>The usage of this field is deprecated, as it doesn't report all supported standards, and
|
||||
will provide an incomplete information for frontends that support multiple delivery systems.
|
||||
Please use <link linkend="DTV_ENUM_DELSYS">DTV_ENUM_DELSYS</link> instead.</para>
|
||||
Please use <link linkend="DTV-ENUM-DELSYS">DTV_ENUM_DELSYS</link> instead.</para>
|
||||
</section>
|
||||
|
||||
<section id="fe-caps-t">
|
||||
@ -101,6 +101,7 @@ a specific frontend type.</para>
|
||||
FE_CAN_8VSB = 0x200000,
|
||||
FE_CAN_16VSB = 0x400000,
|
||||
FE_HAS_EXTENDED_CAPS = 0x800000,
|
||||
FE_CAN_MULTISTREAM = 0x4000000,
|
||||
FE_CAN_TURBO_FEC = 0x8000000,
|
||||
FE_CAN_2G_MODULATION = 0x10000000,
|
||||
FE_NEEDS_BENDING = 0x20000000,
|
||||
@ -207,19 +208,45 @@ spec.</para>
|
||||
<para>Several functions of the frontend device use the fe_status data type defined
|
||||
by</para>
|
||||
<programlisting>
|
||||
typedef enum fe_status {
|
||||
FE_HAS_SIGNAL = 0x01, /⋆ found something above the noise level ⋆/
|
||||
FE_HAS_CARRIER = 0x02, /⋆ found a DVB signal ⋆/
|
||||
FE_HAS_VITERBI = 0x04, /⋆ FEC is stable ⋆/
|
||||
FE_HAS_SYNC = 0x08, /⋆ found sync bytes ⋆/
|
||||
FE_HAS_LOCK = 0x10, /⋆ everything's working... ⋆/
|
||||
FE_TIMEDOUT = 0x20, /⋆ no lock within the last ~2 seconds ⋆/
|
||||
FE_REINIT = 0x40 /⋆ frontend was reinitialized, ⋆/
|
||||
} fe_status_t; /⋆ application is recommned to reset ⋆/
|
||||
typedef enum fe_status {
|
||||
FE_HAS_SIGNAL = 0x01,
|
||||
FE_HAS_CARRIER = 0x02,
|
||||
FE_HAS_VITERBI = 0x04,
|
||||
FE_HAS_SYNC = 0x08,
|
||||
FE_HAS_LOCK = 0x10,
|
||||
FE_TIMEDOUT = 0x20,
|
||||
FE_REINIT = 0x40,
|
||||
} fe_status_t;
|
||||
</programlisting>
|
||||
<para>to indicate the current state and/or state changes of the frontend hardware.
|
||||
<para>to indicate the current state and/or state changes of the frontend hardware:
|
||||
</para>
|
||||
|
||||
<informaltable><tgroup cols="2"><tbody>
|
||||
<row>
|
||||
<entry align="char">FE_HAS_SIGNAL</entry>
|
||||
<entry align="char">The frontend has found something above the noise level</entry>
|
||||
</row><row>
|
||||
<entry align="char">FE_HAS_CARRIER</entry>
|
||||
<entry align="char">The frontend has found a DVB signal</entry>
|
||||
</row><row>
|
||||
<entry align="char">FE_HAS_VITERBI</entry>
|
||||
<entry align="char">The frontend FEC code is stable</entry>
|
||||
</row><row>
|
||||
<entry align="char">FE_HAS_SYNC</entry>
|
||||
<entry align="char">Syncronization bytes was found</entry>
|
||||
</row><row>
|
||||
<entry align="char">FE_HAS_LOCK</entry>
|
||||
<entry align="char">The DVB were locked and everything is working</entry>
|
||||
</row><row>
|
||||
<entry align="char">FE_TIMEDOUT</entry>
|
||||
<entry align="char">no lock within the last about 2 seconds</entry>
|
||||
</row><row>
|
||||
<entry align="char">FE_REINIT</entry>
|
||||
<entry align="char">The frontend was reinitialized, application is
|
||||
recommended to reset DiSEqC, tone and parameters</entry>
|
||||
</row>
|
||||
</tbody></tgroup></informaltable>
|
||||
|
||||
</section>
|
||||
|
||||
<section id="dvb-frontend-parameters">
|
||||
@ -238,7 +265,7 @@ and to add newer delivery systems.</para>
|
||||
<constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant></link> instead, in
|
||||
order to be able to support the newer System Delivery like DVB-S2, DVB-T2,
|
||||
DVB-C2, ISDB, etc.</para>
|
||||
<para>All kinds of parameters are combined as an union in the FrontendParameters structure:</para>
|
||||
<para>All kinds of parameters are combined as an union in the FrontendParameters structure:
|
||||
<programlisting>
|
||||
struct dvb_frontend_parameters {
|
||||
uint32_t frequency; /⋆ (absolute) frequency in Hz for QAM/OFDM ⋆/
|
||||
@ -251,12 +278,13 @@ struct dvb_frontend_parameters {
|
||||
struct dvb_vsb_parameters vsb;
|
||||
} u;
|
||||
};
|
||||
</programlisting>
|
||||
</programlisting></para>
|
||||
<para>In the case of QPSK frontends the <constant>frequency</constant> field specifies the intermediate
|
||||
frequency, i.e. the offset which is effectively added to the local oscillator frequency (LOF) of
|
||||
the LNB. The intermediate frequency has to be specified in units of kHz. For QAM and
|
||||
OFDM frontends the <constant>frequency</constant> specifies the absolute frequency and is given in Hz.
|
||||
</para>
|
||||
|
||||
<section id="dvb-qpsk-parameters">
|
||||
<title>QPSK parameters</title>
|
||||
<para>For satellite QPSK frontends you have to use the <constant>dvb_qpsk_parameters</constant> structure:</para>
|
||||
@ -321,8 +349,8 @@ itself.
|
||||
<section id="fe-code-rate-t">
|
||||
<title>frontend code rate</title>
|
||||
<para>The possible values for the <constant>fec_inner</constant> field used on
|
||||
<link refend="dvb-qpsk-parameters"><constant>struct dvb_qpsk_parameters</constant></link> and
|
||||
<link refend="dvb-qam-parameters"><constant>struct dvb_qam_parameters</constant></link> are:
|
||||
<link linkend="dvb-qpsk-parameters"><constant>struct dvb_qpsk_parameters</constant></link> and
|
||||
<link linkend="dvb-qam-parameters"><constant>struct dvb_qam_parameters</constant></link> are:
|
||||
</para>
|
||||
<programlisting>
|
||||
typedef enum fe_code_rate {
|
||||
@ -347,9 +375,9 @@ detection.
|
||||
<section id="fe-modulation-t">
|
||||
<title>frontend modulation type for QAM, OFDM and VSB</title>
|
||||
<para>For cable and terrestrial frontends, e. g. for
|
||||
<link refend="dvb-qam-parameters"><constant>struct dvb_qpsk_parameters</constant></link>,
|
||||
<link refend="dvb-ofdm-parameters"><constant>struct dvb_qam_parameters</constant></link> and
|
||||
<link refend="dvb-vsb-parameters"><constant>struct dvb_qam_parameters</constant></link>,
|
||||
<link linkend="dvb-qam-parameters"><constant>struct dvb_qpsk_parameters</constant></link>,
|
||||
<link linkend="dvb-ofdm-parameters"><constant>struct dvb_qam_parameters</constant></link> and
|
||||
<link linkend="dvb-vsb-parameters"><constant>struct dvb_qam_parameters</constant></link>,
|
||||
it needs to specify the quadrature modulation mode which can be one of the following:
|
||||
</para>
|
||||
<programlisting>
|
||||
@ -370,8 +398,8 @@ it needs to specify the quadrature modulation mode which can be one of the follo
|
||||
} fe_modulation_t;
|
||||
</programlisting>
|
||||
</section>
|
||||
<para>Finally, there are several more parameters for OFDM:
|
||||
</para>
|
||||
<section>
|
||||
<title>More OFDM parameters</title>
|
||||
<section id="fe-transmit-mode-t">
|
||||
<title>Number of carriers per channel</title>
|
||||
<programlisting>
|
||||
@ -427,6 +455,7 @@ typedef enum fe_hierarchy {
|
||||
} fe_hierarchy_t;
|
||||
</programlisting>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
</section>
|
||||
|
||||
|
@ -205,7 +205,7 @@ a partial path like:</para>
|
||||
additional include file <emphasis
|
||||
role="tt">linux/dvb/version.h</emphasis> exists, which defines the
|
||||
constant <emphasis role="tt">DVB_API_VERSION</emphasis>. This document
|
||||
describes <emphasis role="tt">DVB_API_VERSION 5.4</emphasis>.
|
||||
describes <emphasis role="tt">DVB_API_VERSION 5.8</emphasis>.
|
||||
</para>
|
||||
|
||||
</section>
|
||||
|
@ -2,7 +2,7 @@
|
||||
<para>The kernel demux API defines a driver-internal interface for registering low-level,
|
||||
hardware specific driver to a hardware independent demux layer. It is only of interest for
|
||||
DVB device driver writers. The header file for this API is named <emphasis role="tt">demux.h</emphasis> and located in
|
||||
<emphasis role="tt">drivers/media/dvb/dvb-core</emphasis>.
|
||||
<emphasis role="tt">drivers/media/dvb-core</emphasis>.
|
||||
</para>
|
||||
<para>Maintainer note: This section must be reviewed. It is probably out of date.
|
||||
</para>
|
||||
|
@ -26,4 +26,131 @@ struct dvb_net_if {
|
||||
<title>DVB net Function Calls</title>
|
||||
<para>To be written…
|
||||
</para>
|
||||
|
||||
<section id="NET_ADD_IF"
|
||||
role="subsection"><title>NET_ADD_IF</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl is undocumented. Documentation is welcome.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(fd, int request = NET_ADD_IF,
|
||||
struct dvb_net_if *if);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals NET_ADD_IF for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>struct dvb_net_if *if
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Undocumented.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
</section>
|
||||
|
||||
<section id="NET_REMOVE_IF"
|
||||
role="subsection"><title>NET_REMOVE_IF</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl is undocumented. Documentation is welcome.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(fd, int request = NET_REMOVE_IF);
|
||||
</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals NET_REMOVE_IF for this command.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
</section>
|
||||
|
||||
<section id="NET_GET_IF"
|
||||
role="subsection"><title>NET_GET_IF</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl is undocumented. Documentation is welcome.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(fd, int request = NET_GET_IF,
|
||||
struct dvb_net_if *if);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals NET_GET_IF for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>struct dvb_net_if *if
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Undocumented.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
</section>
|
||||
</section>
|
||||
|
@ -15,6 +15,10 @@ the audio and video device as well as the video4linux device.
|
||||
<para>The ioctls that deal with SPUs (sub picture units) and navigation packets are only
|
||||
supported on some MPEG decoders made for DVD playback.
|
||||
</para>
|
||||
<para>
|
||||
These ioctls were also used by V4L2 to control MPEG decoders implemented in V4L2. The use
|
||||
of these ioctls for that purpose has been made obsolete and proper V4L2 ioctls or controls
|
||||
have been created to replace that functionality.</para>
|
||||
<section id="video_types">
|
||||
<title>Video Data Types</title>
|
||||
|
||||
@ -55,7 +59,7 @@ typedef enum {
|
||||
</section>
|
||||
|
||||
<section id="video-stream-source-t">
|
||||
<title>video stream source</title>
|
||||
<title>video_stream_source_t</title>
|
||||
<para>The video stream source is set through the VIDEO_SELECT_SOURCE call and can take
|
||||
the following values, depending on whether we are replaying from an internal (demuxer) or
|
||||
external (user write) source.
|
||||
@ -76,7 +80,7 @@ call.
|
||||
</section>
|
||||
|
||||
<section id="video-play-state-t">
|
||||
<title>video play state</title>
|
||||
<title>video_play_state_t</title>
|
||||
<para>The following values can be returned by the VIDEO_GET_STATUS call representing the
|
||||
state of video playback.
|
||||
</para>
|
||||
@ -90,9 +94,9 @@ typedef enum {
|
||||
</section>
|
||||
|
||||
<section id="video-command">
|
||||
<title>struct video_command</title>
|
||||
<para>The structure must be zeroed before use by the application
|
||||
This ensures it can be extended safely in the future.</para>
|
||||
<title>struct video-command</title>
|
||||
<programlisting>
|
||||
struct video_command {
|
||||
__u32 cmd;
|
||||
@ -121,7 +125,7 @@ struct video_command {
|
||||
</section>
|
||||
|
||||
<section id="video-size-t">
|
||||
<title>struct video_size-t</title>
|
||||
<title>video_size_t</title>
|
||||
<programlisting>
|
||||
typedef struct {
|
||||
int w;
|
||||
@ -217,7 +221,7 @@ bits set according to the hardwares capabilities.
|
||||
</section>
|
||||
|
||||
<section id="video-system">
|
||||
<title>video system</title>
|
||||
<title>video_system_t</title>
|
||||
<para>A call to VIDEO_SET_SYSTEM sets the desired video system for TV output. The
|
||||
following system types can be set:
|
||||
</para>
|
||||
@ -263,7 +267,7 @@ call expects the following format for that information:
|
||||
|
||||
</section>
|
||||
<section id="video-spu">
|
||||
<title>video SPU</title>
|
||||
<title>struct video_spu</title>
|
||||
<para>Calling VIDEO_SET_SPU deactivates or activates SPU decoding, according to the
|
||||
following format:
|
||||
</para>
|
||||
@ -277,12 +281,12 @@ following format:
|
||||
|
||||
</section>
|
||||
<section id="video-spu-palette">
|
||||
<title>video SPU palette</title>
|
||||
<title>struct video_spu_palette</title>
|
||||
<para>The following structure is used to set the SPU palette by calling VIDEO_SPU_PALETTE:
|
||||
</para>
|
||||
<programlisting>
|
||||
typedef
|
||||
struct video_spu_palette{
|
||||
struct video_spu_palette {
|
||||
int length;
|
||||
uint8_t ⋆palette;
|
||||
} video_spu_palette_t;
|
||||
@ -290,13 +294,13 @@ following format:
|
||||
|
||||
</section>
|
||||
<section id="video-navi-pack">
|
||||
<title>video NAVI pack</title>
|
||||
<title>struct video_navi_pack</title>
|
||||
<para>In order to get the navigational data the following structure has to be passed to the ioctl
|
||||
VIDEO_GET_NAVI:
|
||||
</para>
|
||||
<programlisting>
|
||||
typedef
|
||||
struct video_navi_pack{
|
||||
struct video_navi_pack {
|
||||
int length; /⋆ 0 ... 1024 ⋆/
|
||||
uint8_t data[1024];
|
||||
} video_navi_pack_t;
|
||||
@ -305,7 +309,7 @@ VIDEO_GET_NAVI:
|
||||
|
||||
|
||||
<section id="video-attributes-t">
|
||||
<title>video attributes</title>
|
||||
<title>video_attributes_t</title>
|
||||
<para>The following attributes can be set by a call to VIDEO_SET_ATTRIBUTES:
|
||||
</para>
|
||||
<programlisting>
|
||||
@ -541,6 +545,8 @@ VIDEO_GET_NAVI:
|
||||
role="subsection"><title>VIDEO_STOP</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2
|
||||
&VIDIOC-DECODER-CMD; instead.</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl call asks the Video Device to stop playing the current stream.
|
||||
@ -598,6 +604,8 @@ role="subsection"><title>VIDEO_STOP</title>
|
||||
role="subsection"><title>VIDEO_PLAY</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2
|
||||
&VIDIOC-DECODER-CMD; instead.</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl call asks the Video Device to start playing a video stream from the
|
||||
@ -634,6 +642,8 @@ role="subsection"><title>VIDEO_PLAY</title>
|
||||
role="subsection"><title>VIDEO_FREEZE</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2
|
||||
&VIDIOC-DECODER-CMD; instead.</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl call suspends the live video stream being played. Decoding
|
||||
@ -674,6 +684,8 @@ role="subsection"><title>VIDEO_FREEZE</title>
|
||||
role="subsection"><title>VIDEO_CONTINUE</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2
|
||||
&VIDIOC-DECODER-CMD; instead.</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl call restarts decoding and playing processes of the video stream
|
||||
@ -710,6 +722,9 @@ role="subsection"><title>VIDEO_CONTINUE</title>
|
||||
role="subsection"><title>VIDEO_SELECT_SOURCE</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<para>This ioctl is for DVB devices only. This ioctl was also supported by the
|
||||
V4L2 ivtv driver, but that has been replaced by the ivtv-specific
|
||||
<constant>IVTV_IOC_PASSTHROUGH_MODE</constant> ioctl.</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl call informs the video device which source shall be used for the input
|
||||
@ -845,10 +860,160 @@ role="subsection"><title>VIDEO_GET_STATUS</title>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
|
||||
</section><section id="VIDEO_GET_FRAME_COUNT"
|
||||
role="subsection"><title>VIDEO_GET_FRAME_COUNT</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<para>This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders this
|
||||
ioctl has been replaced by the <constant>V4L2_CID_MPEG_VIDEO_DEC_FRAME</constant> control.</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl call asks the Video Device to return the number of displayed frames
|
||||
since the decoder was started.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request =
|
||||
VIDEO_GET_FRAME_COUNT, __u64 *pts);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals VIDEO_GET_FRAME_COUNT for this
|
||||
command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>__u64 *pts
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Returns the number of frames displayed since the decoder was started.
|
||||
</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
|
||||
</section><section id="VIDEO_GET_PTS"
|
||||
role="subsection"><title>VIDEO_GET_PTS</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<para>This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders this
|
||||
ioctl has been replaced by the <constant>V4L2_CID_MPEG_VIDEO_DEC_PTS</constant> control.</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl call asks the Video Device to return the current PTS timestamp.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request =
|
||||
VIDEO_GET_PTS, __u64 *pts);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals VIDEO_GET_PTS for this
|
||||
command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>__u64 *pts
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Returns the 33-bit timestamp as defined in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
|
||||
</para>
|
||||
<para>
|
||||
The PTS should belong to the currently played
|
||||
frame if possible, but may also be a value close to it
|
||||
like the PTS of the last decoded frame or the last PTS
|
||||
extracted by the PES parser.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
|
||||
</section><section id="VIDEO_GET_FRAME_RATE"
|
||||
role="subsection"><title>VIDEO_GET_FRAME_RATE</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl call asks the Video Device to return the current framerate.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request =
|
||||
VIDEO_GET_FRAME_RATE, unsigned int *rate);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals VIDEO_GET_FRAME_RATE for this
|
||||
command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>unsigned int *rate
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Returns the framerate in number of frames per 1000 seconds.
|
||||
</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
|
||||
</section><section id="VIDEO_GET_EVENT"
|
||||
role="subsection"><title>VIDEO_GET_EVENT</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<para>This ioctl is for DVB devices only. To get events from a V4L2 decoder use the V4L2
|
||||
&VIDIOC-DQEVENT; ioctl instead.</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl call returns an event of type video_event if available. If an event is
|
||||
@ -914,6 +1079,152 @@ role="subsection"><title>VIDEO_GET_EVENT</title>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
||||
</section><section id="VIDEO_COMMAND"
|
||||
role="subsection"><title>VIDEO_COMMAND</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<para>This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders this
|
||||
ioctl has been replaced by the &VIDIOC-DECODER-CMD; ioctl.</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl commands the decoder. The <constant>video_command</constant> struct
|
||||
is a subset of the <constant>v4l2_decoder_cmd</constant> struct, so refer to the
|
||||
&VIDIOC-DECODER-CMD; documentation for more information.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request =
|
||||
VIDEO_COMMAND, struct video_command *cmd);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals VIDEO_COMMAND for this
|
||||
command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>struct video_command *cmd
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Commands the decoder.
|
||||
</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
|
||||
</section><section id="VIDEO_TRY_COMMAND"
|
||||
role="subsection"><title>VIDEO_TRY_COMMAND</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<para>This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders this
|
||||
ioctl has been replaced by the &VIDIOC-TRY-DECODER-CMD; ioctl.</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl tries a decoder command. The <constant>video_command</constant> struct
|
||||
is a subset of the <constant>v4l2_decoder_cmd</constant> struct, so refer to the
|
||||
&VIDIOC-TRY-DECODER-CMD; documentation for more information.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request =
|
||||
VIDEO_TRY_COMMAND, struct video_command *cmd);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals VIDEO_TRY_COMMAND for this
|
||||
command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>struct video_command *cmd
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Try a decoder command.
|
||||
</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
|
||||
</section><section id="VIDEO_GET_SIZE"
|
||||
role="subsection"><title>VIDEO_GET_SIZE</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl returns the size and aspect ratio.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request =
|
||||
VIDEO_GET_SIZE, video_size_t *size);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals VIDEO_GET_SIZE for this
|
||||
command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>video_size_t *size
|
||||
</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Returns the size and aspect ratio.
|
||||
</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
&return-value-dvb;
|
||||
|
||||
</section><section id="VIDEO_SET_DISPLAY_FORMAT"
|
||||
role="subsection"><title>VIDEO_SET_DISPLAY_FORMAT</title>
|
||||
<para>DESCRIPTION
|
||||
|
@ -178,23 +178,23 @@ Signal - NTSC for Studio Applications"</title>
|
||||
1125-Line High-Definition Production"</title>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="en50067">
|
||||
<abbrev>EN 50067</abbrev>
|
||||
<biblioentry id="iec62106">
|
||||
<abbrev>IEC 62106</abbrev>
|
||||
<authorgroup>
|
||||
<corpauthor>European Committee for Electrotechnical Standardization
|
||||
(<ulink url="http://www.cenelec.eu">http://www.cenelec.eu</ulink>)</corpauthor>
|
||||
<corpauthor>International Electrotechnical Commission
|
||||
(<ulink url="http://www.iec.ch">http://www.iec.ch</ulink>)</corpauthor>
|
||||
</authorgroup>
|
||||
<title>Specification of the radio data system (RDS) for VHF/FM sound broadcasting
|
||||
in the frequency range from 87,5 to 108,0 MHz</title>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="nrsc4">
|
||||
<abbrev>NRSC-4</abbrev>
|
||||
<abbrev>NRSC-4-B</abbrev>
|
||||
<authorgroup>
|
||||
<corpauthor>National Radio Systems Committee
|
||||
(<ulink url="http://www.nrscstandards.org">http://www.nrscstandards.org</ulink>)</corpauthor>
|
||||
</authorgroup>
|
||||
<title>NRSC-4: United States RBDS Standard</title>
|
||||
<title>NRSC-4-B: United States RBDS Standard</title>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="iso12232">
|
||||
@ -226,4 +226,44 @@ in the frequency range from 87,5 to 108,0 MHz</title>
|
||||
<title>VESA and Industry Standards and Guidelines for Computer Display Monitor Timing (DMT)</title>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="vesaedid">
|
||||
<abbrev>EDID</abbrev>
|
||||
<authorgroup>
|
||||
<corpauthor>Video Electronics Standards Association
|
||||
(<ulink url="http://www.vesa.org">http://www.vesa.org</ulink>)</corpauthor>
|
||||
</authorgroup>
|
||||
<title>VESA Enhanced Extended Display Identification Data Standard</title>
|
||||
<subtitle>Release A, Revision 2</subtitle>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="hdcp">
|
||||
<abbrev>HDCP</abbrev>
|
||||
<authorgroup>
|
||||
<corpauthor>Digital Content Protection LLC
|
||||
(<ulink url="http://www.digital-cp.com">http://www.digital-cp.com</ulink>)</corpauthor>
|
||||
</authorgroup>
|
||||
<title>High-bandwidth Digital Content Protection System</title>
|
||||
<subtitle>Revision 1.3</subtitle>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="hdmi">
|
||||
<abbrev>HDMI</abbrev>
|
||||
<authorgroup>
|
||||
<corpauthor>HDMI Licensing LLC
|
||||
(<ulink url="http://www.hdmi.org">http://www.hdmi.org</ulink>)</corpauthor>
|
||||
</authorgroup>
|
||||
<title>High-Definition Multimedia Interface</title>
|
||||
<subtitle>Specification Version 1.4a</subtitle>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="dp">
|
||||
<abbrev>DP</abbrev>
|
||||
<authorgroup>
|
||||
<corpauthor>Video Electronics Standards Association
|
||||
(<ulink url="http://www.vesa.org">http://www.vesa.org</ulink>)</corpauthor>
|
||||
</authorgroup>
|
||||
<title>VESA DisplayPort Standard</title>
|
||||
<subtitle>Version 1, Revision 2</subtitle>
|
||||
</biblioentry>
|
||||
|
||||
</bibliography>
|
||||
|
@ -564,7 +564,7 @@ automatically.</para>
|
||||
<para>To query and select the standard used by the current video
|
||||
input or output applications call the &VIDIOC-G-STD; and
|
||||
&VIDIOC-S-STD; ioctl, respectively. The <emphasis>received</emphasis>
|
||||
standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note parameter of all these ioctls is a pointer to a &v4l2-std-id; type (a standard set), <emphasis>not</emphasis> an index into the standard enumeration.<footnote>
|
||||
standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note that the parameter of all these ioctls is a pointer to a &v4l2-std-id; type (a standard set), <emphasis>not</emphasis> an index into the standard enumeration.<footnote>
|
||||
<para>An alternative to the current scheme is to use pointers
|
||||
to indices as arguments of <constant>VIDIOC_G_STD</constant> and
|
||||
<constant>VIDIOC_S_STD</constant>, the &v4l2-input; and
|
||||
@ -588,30 +588,28 @@ switch to a standard by &v4l2-std-id;.</para>
|
||||
</footnote> Drivers must implement all video standard ioctls
|
||||
when the device has one or more video inputs or outputs.</para>
|
||||
|
||||
<para>Special rules apply to USB cameras where the notion of video
|
||||
standards makes little sense. More generally any capture device,
|
||||
output devices accordingly, which is <itemizedlist>
|
||||
<para>Special rules apply to devices such as USB cameras where the notion of video
|
||||
standards makes little sense. More generally for any capture or output device
|
||||
which is: <itemizedlist>
|
||||
<listitem>
|
||||
<para>incapable of capturing fields or frames at the nominal
|
||||
rate of the video standard, or</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>where <link linkend="buffer">timestamps</link> refer
|
||||
to the instant the field or frame was received by the driver, not the
|
||||
capture time, or</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>where <link linkend="buffer">sequence numbers</link>
|
||||
refer to the frames received by the driver, not the captured
|
||||
frames.</para>
|
||||
<para>that does not support the video standard formats at all.</para>
|
||||
</listitem>
|
||||
</itemizedlist> Here the driver shall set the
|
||||
<structfield>std</structfield> field of &v4l2-input; and &v4l2-output;
|
||||
to zero, the <constant>VIDIOC_G_STD</constant>,
|
||||
to zero and the <constant>VIDIOC_G_STD</constant>,
|
||||
<constant>VIDIOC_S_STD</constant>,
|
||||
<constant>VIDIOC_QUERYSTD</constant> and
|
||||
<constant>VIDIOC_ENUMSTD</constant> ioctls shall return the
|
||||
&EINVAL;.<footnote>
|
||||
&ENOTTY;.<footnote>
|
||||
<para>See <xref linkend="buffer" /> for a rationale.</para>
|
||||
<para>Applications can make use of the <xref linkend="input-capabilities" /> and
|
||||
<xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls
|
||||
are available for the device.</para>
|
||||
&ENOTTY;.
|
||||
<para>See <xref linkend="buffer" /> for a rationale. Probably
|
||||
even USB cameras follow some well known video standard. It might have
|
||||
been better to explicitly indicate elsewhere if a device cannot live
|
||||
@ -626,9 +624,9 @@ up to normal expectations, instead of this exception.</para>
|
||||
&v4l2-standard; standard;
|
||||
|
||||
if (-1 == ioctl (fd, &VIDIOC-G-STD;, &std_id)) {
|
||||
/* Note when VIDIOC_ENUMSTD always returns EINVAL this
|
||||
/* Note when VIDIOC_ENUMSTD always returns ENOTTY this
|
||||
is no video device or it falls under the USB exception,
|
||||
and VIDIOC_G_STD returning EINVAL is no error. */
|
||||
and VIDIOC_G_STD returning ENOTTY is no error. */
|
||||
|
||||
perror ("VIDIOC_G_STD");
|
||||
exit (EXIT_FAILURE);
|
||||
|
@ -1476,7 +1476,7 @@ follows.<informaltable>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_TYPE_PRIVATE_BASE</constant></entry>
|
||||
<entry><constant>V4L2_BUF_TYPE_PRIVATE</constant></entry>
|
||||
<entry><constant>V4L2_BUF_TYPE_PRIVATE</constant> (but this is deprecated)</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
@ -2468,21 +2468,9 @@ that used it. It was originally scheduled for removal in 2.6.35.
|
||||
<structfield>reserved2</structfield> and removed
|
||||
<constant>V4L2_BUF_FLAG_INPUT</constant>.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.6</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Added V4L2_CAP_VIDEO_M2M and V4L2_CAP_VIDEO_M2M_MPLANE capabilities.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.6</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Added support for frequency band enumerations: &VIDIOC-ENUM-FREQ-BANDS;.</para>
|
||||
</listitem>
|
||||
@ -2567,29 +2555,6 @@ and may change in the future.</para>
|
||||
<para>Video Output Overlay (OSD) Interface, <xref
|
||||
linkend="osd" />.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY</constant>,
|
||||
&v4l2-buf-type;, <xref linkend="v4l2-buf-type" />.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><constant>V4L2_CAP_VIDEO_OUTPUT_OVERLAY</constant>,
|
||||
&VIDIOC-QUERYCAP; ioctl, <xref linkend="device-capabilities" />.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>&VIDIOC-ENUM-FRAMESIZES; and
|
||||
&VIDIOC-ENUM-FRAMEINTERVALS; ioctls.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>&VIDIOC-G-ENC-INDEX; ioctl.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>&VIDIOC-ENCODER-CMD; and &VIDIOC-TRY-ENCODER-CMD;
|
||||
ioctls.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>&VIDIOC-DECODER-CMD; and &VIDIOC-TRY-DECODER-CMD;
|
||||
ioctls.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>&VIDIOC-DBG-G-REGISTER; and &VIDIOC-DBG-S-REGISTER;
|
||||
ioctls.</para>
|
||||
@ -2614,10 +2579,6 @@ ioctls.</para>
|
||||
<para>Sub-device selection API: &VIDIOC-SUBDEV-G-SELECTION;
|
||||
and &VIDIOC-SUBDEV-S-SELECTION; ioctls.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><link linkend="v4l2-auto-focus-area"><constant>
|
||||
V4L2_CID_AUTO_FOCUS_AREA</constant></link> control.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Support for frequency band enumeration: &VIDIOC-ENUM-FREQ-BANDS; ioctl.</para>
|
||||
</listitem>
|
||||
|
@ -3505,7 +3505,7 @@ This encodes up to 31 pre-defined programme types.</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Sets the Programme Service name (PS_NAME) for transmission.
|
||||
It is intended for static display on a receiver. It is the primary aid to listeners in programme service
|
||||
identification and selection. In Annex E of <xref linkend="en50067" />, the RDS specification,
|
||||
identification and selection. In Annex E of <xref linkend="iec62106" />, the RDS specification,
|
||||
there is a full description of the correct character encoding for Programme Service name strings.
|
||||
Also from RDS specification, PS is usually a single eight character text. However, it is also possible
|
||||
to find receivers which can scroll strings sized as 8 x N characters. So, this control must be configured
|
||||
@ -3519,7 +3519,7 @@ with steps of 8 characters. The result is it must always contain a string with s
|
||||
what is being broadcasted. RDS Radio Text can be applied when broadcaster wishes to transmit longer PS names,
|
||||
programme-related information or any other text. In these cases, RadioText should be used in addition to
|
||||
<constant>V4L2_CID_RDS_TX_PS_NAME</constant>. The encoding for Radio Text strings is also fully described
|
||||
in Annex E of <xref linkend="en50067" />. The length of Radio Text strings depends on which RDS Block is being
|
||||
in Annex E of <xref linkend="iec62106" />. The length of Radio Text strings depends on which RDS Block is being
|
||||
used to transmit it, either 32 (2A block) or 64 (2B block). However, it is also possible
|
||||
to find receivers which can scroll strings sized as 32 x N or 64 x N characters. So, this control must be configured
|
||||
with steps of 32 or 64 characters. The result is it must always contain a string with size multiple of 32 or 64. </entry>
|
||||
@ -3650,7 +3650,7 @@ manually or automatically if set to zero. Unit, range and step are driver-specif
|
||||
</table>
|
||||
|
||||
<para>For more details about RDS specification, refer to
|
||||
<xref linkend="en50067" /> document, from CENELEC.</para>
|
||||
<xref linkend="iec62106" /> document, from CENELEC.</para>
|
||||
</section>
|
||||
|
||||
<section id="flash-controls">
|
||||
@ -3717,232 +3717,231 @@ interface and may change in the future.</para>
|
||||
use case involving camera or individually.
|
||||
</para>
|
||||
|
||||
|
||||
<table pgwide="1" frame="none" id="flash-control-id">
|
||||
<title>Flash 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_FLASH_CLASS</constant></entry>
|
||||
<entry>class</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">The FLASH class descriptor.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_LED_MODE</constant></entry>
|
||||
<entry>menu</entry>
|
||||
</row>
|
||||
<row id="v4l2-flash-led-mode">
|
||||
<entry spanname="descr">Defines the mode of the flash LED,
|
||||
the high-power white LED attached to the flash controller.
|
||||
Setting this control may not be possible in presence of
|
||||
some faults. See V4L2_CID_FLASH_FAULT.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_LED_MODE_NONE</constant></entry>
|
||||
<entry>Off.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_LED_MODE_FLASH</constant></entry>
|
||||
<entry>Flash mode.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_LED_MODE_TORCH</constant></entry>
|
||||
<entry>Torch mode. See V4L2_CID_FLASH_TORCH_INTENSITY.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_SOURCE</constant></entry>
|
||||
<entry>menu</entry>
|
||||
</row>
|
||||
<row id="v4l2-flash-strobe-source"><entry
|
||||
spanname="descr">Defines the source of the flash LED
|
||||
strobe.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_STROBE_SOURCE_SOFTWARE</constant></entry>
|
||||
<entry>The flash strobe is triggered by using
|
||||
the V4L2_CID_FLASH_STROBE control.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_STROBE_SOURCE_EXTERNAL</constant></entry>
|
||||
<entry>The flash strobe is triggered by an
|
||||
external source. Typically this is a sensor,
|
||||
which makes it possible to synchronises the
|
||||
flash strobe start to exposure start.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_STROBE</constant></entry>
|
||||
<entry>button</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Strobe flash. Valid when
|
||||
V4L2_CID_FLASH_LED_MODE is set to
|
||||
V4L2_FLASH_LED_MODE_FLASH and V4L2_CID_FLASH_STROBE_SOURCE
|
||||
is set to V4L2_FLASH_STROBE_SOURCE_SOFTWARE. Setting this
|
||||
control may not be possible in presence of some faults.
|
||||
See V4L2_CID_FLASH_FAULT.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_STOP</constant></entry>
|
||||
<entry>button</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Stop flash strobe immediately.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_STATUS</constant></entry>
|
||||
<entry>boolean</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Strobe status: whether the flash
|
||||
is strobing at the moment or not. This is a read-only
|
||||
control.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_TIMEOUT</constant></entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Hardware timeout for flash. The
|
||||
flash strobe is stopped after this period of time has
|
||||
passed from the start of the strobe.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_INTENSITY</constant></entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Intensity of the flash strobe when
|
||||
the flash LED is in flash mode
|
||||
(V4L2_FLASH_LED_MODE_FLASH). The unit should be milliamps
|
||||
(mA) if possible.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_TORCH_INTENSITY</constant></entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Intensity of the flash LED in
|
||||
torch mode (V4L2_FLASH_LED_MODE_TORCH). The unit should be
|
||||
milliamps (mA) if possible. Setting this control may not
|
||||
be possible in presence of some faults. See
|
||||
V4L2_CID_FLASH_FAULT.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_INDICATOR_INTENSITY</constant></entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Intensity of the indicator LED.
|
||||
The indicator LED may be fully independent of the flash
|
||||
LED. The unit should be microamps (uA) if possible.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_FAULT</constant></entry>
|
||||
<entry>bitmask</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Faults related to the flash. The
|
||||
faults tell about specific problems in the flash chip
|
||||
itself or the LEDs attached to it. Faults may prevent
|
||||
further use of some of the flash controls. In particular,
|
||||
V4L2_CID_FLASH_LED_MODE is set to V4L2_FLASH_LED_MODE_NONE
|
||||
if the fault affects the flash LED. Exactly which faults
|
||||
have such an effect is chip dependent. Reading the faults
|
||||
resets the control and returns the chip to a usable state
|
||||
if possible.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_FAULT_OVER_VOLTAGE</constant></entry>
|
||||
<entry>Flash controller voltage to the flash LED
|
||||
has exceeded the limit specific to the flash
|
||||
controller.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_FAULT_TIMEOUT</constant></entry>
|
||||
<entry>The flash strobe was still on when
|
||||
the timeout set by the user ---
|
||||
V4L2_CID_FLASH_TIMEOUT control --- has expired.
|
||||
Not all flash controllers may set this in all
|
||||
such conditions.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_FAULT_OVER_TEMPERATURE</constant></entry>
|
||||
<entry>The flash controller has overheated.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_FAULT_SHORT_CIRCUIT</constant></entry>
|
||||
<entry>The short circuit protection of the flash
|
||||
controller has been triggered.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_FAULT_OVER_CURRENT</constant></entry>
|
||||
<entry>Current in the LED power supply has exceeded the limit
|
||||
specific to the flash controller.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_FAULT_INDICATOR</constant></entry>
|
||||
<entry>The flash controller has detected a short or open
|
||||
circuit condition on the indicator LED.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_CHARGE</constant></entry>
|
||||
<entry>boolean</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Enable or disable charging of the xenon
|
||||
flash capacitor.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_READY</constant></entry>
|
||||
<entry>boolean</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Is the flash ready to strobe?
|
||||
Xenon flashes require their capacitors charged before
|
||||
strobing. LED flashes often require a cooldown period
|
||||
after strobe during which another strobe will not be
|
||||
possible. This is a read-only control.</entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</section>
|
||||
|
||||
</section>
|
||||
|
||||
<table pgwide="1" frame="none" id="flash-control-id">
|
||||
<title>Flash 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_FLASH_CLASS</constant></entry>
|
||||
<entry>class</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">The FLASH class descriptor.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_LED_MODE</constant></entry>
|
||||
<entry>menu</entry>
|
||||
</row>
|
||||
<row id="v4l2-flash-led-mode">
|
||||
<entry spanname="descr">Defines the mode of the flash LED,
|
||||
the high-power white LED attached to the flash controller.
|
||||
Setting this control may not be possible in presence of
|
||||
some faults. See V4L2_CID_FLASH_FAULT.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_LED_MODE_NONE</constant></entry>
|
||||
<entry>Off.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_LED_MODE_FLASH</constant></entry>
|
||||
<entry>Flash mode.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_LED_MODE_TORCH</constant></entry>
|
||||
<entry>Torch mode. See V4L2_CID_FLASH_TORCH_INTENSITY.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_SOURCE</constant></entry>
|
||||
<entry>menu</entry>
|
||||
</row>
|
||||
<row id="v4l2-flash-strobe-source"><entry
|
||||
spanname="descr">Defines the source of the flash LED
|
||||
strobe.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_STROBE_SOURCE_SOFTWARE</constant></entry>
|
||||
<entry>The flash strobe is triggered by using
|
||||
the V4L2_CID_FLASH_STROBE control.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_STROBE_SOURCE_EXTERNAL</constant></entry>
|
||||
<entry>The flash strobe is triggered by an
|
||||
external source. Typically this is a sensor,
|
||||
which makes it possible to synchronises the
|
||||
flash strobe start to exposure start.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_STROBE</constant></entry>
|
||||
<entry>button</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Strobe flash. Valid when
|
||||
V4L2_CID_FLASH_LED_MODE is set to
|
||||
V4L2_FLASH_LED_MODE_FLASH and V4L2_CID_FLASH_STROBE_SOURCE
|
||||
is set to V4L2_FLASH_STROBE_SOURCE_SOFTWARE. Setting this
|
||||
control may not be possible in presence of some faults.
|
||||
See V4L2_CID_FLASH_FAULT.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_STOP</constant></entry>
|
||||
<entry>button</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Stop flash strobe immediately.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_STATUS</constant></entry>
|
||||
<entry>boolean</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Strobe status: whether the flash
|
||||
is strobing at the moment or not. This is a read-only
|
||||
control.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_TIMEOUT</constant></entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Hardware timeout for flash. The
|
||||
flash strobe is stopped after this period of time has
|
||||
passed from the start of the strobe.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_INTENSITY</constant></entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Intensity of the flash strobe when
|
||||
the flash LED is in flash mode
|
||||
(V4L2_FLASH_LED_MODE_FLASH). The unit should be milliamps
|
||||
(mA) if possible.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_TORCH_INTENSITY</constant></entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Intensity of the flash LED in
|
||||
torch mode (V4L2_FLASH_LED_MODE_TORCH). The unit should be
|
||||
milliamps (mA) if possible. Setting this control may not
|
||||
be possible in presence of some faults. See
|
||||
V4L2_CID_FLASH_FAULT.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_INDICATOR_INTENSITY</constant></entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Intensity of the indicator LED.
|
||||
The indicator LED may be fully independent of the flash
|
||||
LED. The unit should be microamps (uA) if possible.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_FAULT</constant></entry>
|
||||
<entry>bitmask</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Faults related to the flash. The
|
||||
faults tell about specific problems in the flash chip
|
||||
itself or the LEDs attached to it. Faults may prevent
|
||||
further use of some of the flash controls. In particular,
|
||||
V4L2_CID_FLASH_LED_MODE is set to V4L2_FLASH_LED_MODE_NONE
|
||||
if the fault affects the flash LED. Exactly which faults
|
||||
have such an effect is chip dependent. Reading the faults
|
||||
resets the control and returns the chip to a usable state
|
||||
if possible.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_FAULT_OVER_VOLTAGE</constant></entry>
|
||||
<entry>Flash controller voltage to the flash LED
|
||||
has exceeded the limit specific to the flash
|
||||
controller.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_FAULT_TIMEOUT</constant></entry>
|
||||
<entry>The flash strobe was still on when
|
||||
the timeout set by the user ---
|
||||
V4L2_CID_FLASH_TIMEOUT control --- has expired.
|
||||
Not all flash controllers may set this in all
|
||||
such conditions.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_FAULT_OVER_TEMPERATURE</constant></entry>
|
||||
<entry>The flash controller has overheated.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_FAULT_SHORT_CIRCUIT</constant></entry>
|
||||
<entry>The short circuit protection of the flash
|
||||
controller has been triggered.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_FAULT_OVER_CURRENT</constant></entry>
|
||||
<entry>Current in the LED power supply has exceeded the limit
|
||||
specific to the flash controller.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FLASH_FAULT_INDICATOR</constant></entry>
|
||||
<entry>The flash controller has detected a short or open
|
||||
circuit condition on the indicator LED.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_CHARGE</constant></entry>
|
||||
<entry>boolean</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Enable or disable charging of the xenon
|
||||
flash capacitor.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_FLASH_READY</constant></entry>
|
||||
<entry>boolean</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Is the flash ready to strobe?
|
||||
Xenon flashes require their capacitors charged before
|
||||
strobing. LED flashes often require a cooldown period
|
||||
after strobe during which another strobe will not be
|
||||
possible. This is a read-only control.</entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</section>
|
||||
|
||||
<section id="jpeg-controls">
|
||||
@ -4274,4 +4273,165 @@ interface and may change in the future.</para>
|
||||
</table>
|
||||
|
||||
</section>
|
||||
|
||||
<section id="dv-controls">
|
||||
<title>Digital Video Control Reference</title>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
|
||||
<para>This is an <link
|
||||
linkend="experimental">experimental</link> interface and may
|
||||
change in the future.</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
The Digital Video control class is intended to control receivers
|
||||
and transmitters for <ulink url="http://en.wikipedia.org/wiki/Vga">VGA</ulink>,
|
||||
<ulink url="http://en.wikipedia.org/wiki/Digital_Visual_Interface">DVI</ulink>
|
||||
(Digital Visual Interface), HDMI (<xref linkend="hdmi" />) and DisplayPort (<xref linkend="dp" />).
|
||||
These controls are generally expected to be private to the receiver or transmitter
|
||||
subdevice that implements them, so they are only exposed on the
|
||||
<filename>/dev/v4l-subdev*</filename> device node.
|
||||
</para>
|
||||
|
||||
<para>Note that these devices can have multiple input or output pads which are
|
||||
hooked up to e.g. HDMI connectors. Even though the subdevice will receive or
|
||||
transmit video from/to only one of those pads, the other pads can still be
|
||||
active when it comes to EDID (Extended Display Identification Data,
|
||||
<xref linkend="vesaedid" />) and HDCP (High-bandwidth Digital Content
|
||||
Protection System, <xref linkend="hdcp" />) processing, allowing the device
|
||||
to do the fairly slow EDID/HDCP handling in advance. This allows for quick
|
||||
switching between connectors.</para>
|
||||
|
||||
<para>These pads appear in several of the controls in this section as
|
||||
bitmasks, one bit for each pad. Bit 0 corresponds to pad 0, bit 1 to pad 1,
|
||||
etc. The maximum value of the control is the set of valid pads.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="dv-control-id">
|
||||
<title>Digital Video 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_DV_CLASS</constant></entry>
|
||||
<entry>class</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">The Digital Video class descriptor.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_DV_TX_HOTPLUG</constant></entry>
|
||||
<entry>bitmask</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Many connectors have a hotplug pin which is high
|
||||
if EDID information is available from the source. This control shows the
|
||||
state of the hotplug pin as seen by the transmitter.
|
||||
Each bit corresponds to an output pad on the transmitter. If an output pad
|
||||
does not have an associated hotplug pin, then the bit for that pad will be 0.
|
||||
This read-only control is applicable to DVI-D, HDMI and DisplayPort connectors.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_DV_TX_RXSENSE</constant></entry>
|
||||
<entry>bitmask</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Rx Sense is the detection of pull-ups on the TMDS
|
||||
clock lines. This normally means that the sink has left/entered standby (i.e.
|
||||
the transmitter can sense that the receiver is ready to receive video).
|
||||
Each bit corresponds to an output pad on the transmitter. If an output pad
|
||||
does not have an associated Rx Sense, then the bit for that pad will be 0.
|
||||
This read-only control is applicable to DVI-D and HDMI devices.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_DV_TX_EDID_PRESENT</constant></entry>
|
||||
<entry>bitmask</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">When the transmitter sees the hotplug signal from the
|
||||
receiver it will attempt to read the EDID. If set, then the transmitter has read
|
||||
at least the first block (= 128 bytes).
|
||||
Each bit corresponds to an output pad on the transmitter. If an output pad
|
||||
does not support EDIDs, then the bit for that pad will be 0.
|
||||
This read-only control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_DV_TX_MODE</constant></entry>
|
||||
<entry id="v4l2-dv-tx-mode">enum v4l2_dv_tx_mode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">HDMI transmitters can transmit in DVI-D mode (just video)
|
||||
or in HDMI mode (video + audio + auxiliary data). This control selects which mode
|
||||
to use: V4L2_DV_TX_MODE_DVI_D or V4L2_DV_TX_MODE_HDMI.
|
||||
This control is applicable to HDMI connectors.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_DV_TX_RGB_RANGE</constant></entry>
|
||||
<entry id="v4l2-dv-rgb-range">enum v4l2_dv_rgb_range</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Select the quantization range for RGB output. V4L2_DV_RANGE_AUTO
|
||||
follows the RGB quantization range specified in the standard for the video interface
|
||||
(ie. <xref linkend="cea861" /> for HDMI). V4L2_DV_RANGE_LIMITED and V4L2_DV_RANGE_FULL override the standard
|
||||
to be compatible with sinks that have not implemented the standard correctly
|
||||
(unfortunately quite common for HDMI and DVI-D). Full range allows all possible values to be
|
||||
used whereas limited range sets the range to (16 << (N-8)) - (235 << (N-8))
|
||||
where N is the number of bits per component.
|
||||
This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_DV_RX_POWER_PRESENT</constant></entry>
|
||||
<entry>bitmask</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Detects whether the receiver receives power from the source
|
||||
(e.g. HDMI carries 5V on one of the pins). This is often used to power an eeprom
|
||||
which contains EDID information, such that the source can read the EDID even if
|
||||
the sink is in standby/power off.
|
||||
Each bit corresponds to an input pad on the transmitter. If an input pad
|
||||
cannot detect whether power is present, then the bit for that pad will be 0.
|
||||
This read-only control is applicable to DVI-D, HDMI and DisplayPort connectors.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_DV_RX_RGB_RANGE</constant></entry>
|
||||
<entry>enum v4l2_dv_rgb_range</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="descr">Select the quantization range for RGB input. V4L2_DV_RANGE_AUTO
|
||||
follows the RGB quantization range specified in the standard for the video interface
|
||||
(ie. <xref linkend="cea861" /> for HDMI). V4L2_DV_RANGE_LIMITED and V4L2_DV_RANGE_FULL override the standard
|
||||
to be compatible with sources that have not implemented the standard correctly
|
||||
(unfortunately quite common for HDMI and DVI-D). Full range allows all possible values to be
|
||||
used whereas limited range sets the range to (16 << (N-8)) - (235 << (N-8))
|
||||
where N is the number of bits per component.
|
||||
This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
|
||||
</entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
</section>
|
||||
</section>
|
||||
|
@ -1,13 +1,6 @@
|
||||
<title>Video Output Overlay Interface</title>
|
||||
<subtitle>Also known as On-Screen Display (OSD)</subtitle>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
|
||||
<para>This is an <link linkend="experimental">experimental</link>
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
<para>Some video output devices can overlay a framebuffer image onto
|
||||
the outgoing video signal. Applications can set up such an overlay
|
||||
using this interface, which borrows structures and ioctls of the <link
|
||||
|
@ -6,7 +6,7 @@ information, on an inaudible audio subcarrier of a radio program. This
|
||||
interface is aimed at devices capable of receiving and/or transmitting RDS
|
||||
information.</para>
|
||||
|
||||
<para>For more information see the core RDS standard <xref linkend="en50067" />
|
||||
<para>For more information see the core RDS standard <xref linkend="iec62106" />
|
||||
and the RBDS standard <xref linkend="nrsc4" />.</para>
|
||||
|
||||
<para>Note that the RBDS standard as is used in the USA is almost identical
|
||||
|
@ -374,29 +374,29 @@
|
||||
rectangle --- if it is supported by the hardware.</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>Sink pad format. The user configures the sink pad
|
||||
<listitem><para>Sink pad format. The user configures the sink pad
|
||||
format. This format defines the parameters of the image the
|
||||
entity receives through the pad for further processing.</listitem>
|
||||
entity receives through the pad for further processing.</para></listitem>
|
||||
|
||||
<listitem>Sink pad actual crop selection. The sink pad crop
|
||||
defines the crop performed to the sink pad format.</listitem>
|
||||
<listitem><para>Sink pad actual crop selection. The sink pad crop
|
||||
defines the crop performed to the sink pad format.</para></listitem>
|
||||
|
||||
<listitem>Sink pad actual compose selection. The size of the
|
||||
<listitem><para>Sink pad actual compose selection. The size of the
|
||||
sink pad compose rectangle defines the scaling ratio compared
|
||||
to the size of the sink pad crop rectangle. The location of
|
||||
the compose rectangle specifies the location of the actual
|
||||
sink compose rectangle in the sink compose bounds
|
||||
rectangle.</listitem>
|
||||
rectangle.</para></listitem>
|
||||
|
||||
<listitem>Source pad actual crop selection. Crop on the source
|
||||
<listitem><para>Source pad actual crop selection. Crop on the source
|
||||
pad defines crop performed to the image in the sink compose
|
||||
bounds rectangle.</listitem>
|
||||
bounds rectangle.</para></listitem>
|
||||
|
||||
<listitem>Source pad format. The source pad format defines the
|
||||
<listitem><para>Source pad format. The source pad format defines the
|
||||
output pixel format of the subdev, as well as the other
|
||||
parameters with the exception of the image width and height.
|
||||
Width and height are defined by the size of the source pad
|
||||
actual crop selection.</listitem>
|
||||
actual crop selection.</para></listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>Accessing any of the above rectangles not supported by the
|
||||
|
@ -6,6 +6,15 @@
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<!-- Keep it ordered alphabetically -->
|
||||
<row>
|
||||
<entry>EAGAIN (aka EWOULDBLOCK)</entry>
|
||||
<entry>The ioctl can't be handled because the device is in state where
|
||||
it can't perform it. This could happen for example in case where
|
||||
device is sleeping and ioctl is performed to query statistics.
|
||||
It is also returned when the ioctl would need to wait
|
||||
for an event, but the device was opened in non-blocking mode.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>EBADF</entry>
|
||||
<entry>The file descriptor is not a valid.</entry>
|
||||
@ -50,22 +59,12 @@
|
||||
that this request would overcommit the usb bandwidth reserved
|
||||
for periodic transfers (up to 80% of the USB bandwidth).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>ENOSYS or EOPNOTSUPP</entry>
|
||||
<entry>Function not available for this device (dvb API only. Will likely
|
||||
be replaced anytime soon by ENOTTY).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>EPERM</entry>
|
||||
<entry>Permission denied. Can be returned if the device needs write
|
||||
permission, or some special capabilities is needed
|
||||
(e. g. root)</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>EWOULDBLOCK</entry>
|
||||
<entry>Operation would block. Used when the ioctl would need to wait
|
||||
for an event, but the device was opened in non-blocking mode.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
@ -613,8 +613,8 @@ field is independent of the <structfield>timestamp</structfield> and
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>sequence</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Set by the driver, counting the frames in the
|
||||
sequence.</entry>
|
||||
<entry>Set by the driver, counting the frames (not fields!) in
|
||||
sequence. This field is set for both input and output devices.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="hspan"><para>In <link
|
||||
@ -685,18 +685,14 @@ memory, set by the application. See <xref linkend="userp" /> for details.
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved2</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>A place holder for future extensions and custom
|
||||
(driver defined) buffer types
|
||||
<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher. Applications
|
||||
<entry>A place holder for future extensions. Applications
|
||||
should set this to 0.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>A place holder for future extensions and custom
|
||||
(driver defined) buffer types
|
||||
<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher. Applications
|
||||
<entry>A place holder for future extensions. Applications
|
||||
should set this to 0.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
@ -827,14 +823,7 @@ should set this to 0.</entry>
|
||||
<entry><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY</constant></entry>
|
||||
<entry>8</entry>
|
||||
<entry>Buffer for video output overlay (OSD), see <xref
|
||||
linkend="osd" />. Status: <link
|
||||
linkend="experimental">Experimental</link>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_TYPE_PRIVATE</constant></entry>
|
||||
<entry>0x80</entry>
|
||||
<entry>This and higher values are reserved for custom
|
||||
(driver defined) buffer types.</entry>
|
||||
linkend="osd" />.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
@ -22,8 +22,7 @@
|
||||
with 10 bits per colour compressed to 8 bits each, using DPCM
|
||||
compression. DPCM, differential pulse-code modulation, is lossy.
|
||||
Each colour component consumes 8 bits of memory. In other respects
|
||||
this format is similar to <xref
|
||||
linkend="pixfmt-srggb10">.</xref></para>
|
||||
this format is similar to <xref linkend="pixfmt-srggb10" />.</para>
|
||||
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
154
Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml
Normal file
154
Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml
Normal file
@ -0,0 +1,154 @@
|
||||
<refentry id="V4L2-PIX-FMT-YVU420M">
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname> <constant>V4L2_PIX_FMT_YVU420M</constant></refname>
|
||||
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YVU420</constant>
|
||||
with planes non contiguous in memory. </refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This is a multi-planar format, as opposed to a packed format.
|
||||
The three components are separated into three sub-images or planes.
|
||||
|
||||
The Y plane is first. The Y plane has one byte per pixel. The Cr data
|
||||
constitutes the second plane which is half the width and half
|
||||
the height of the Y plane (and of the image). Each Cr belongs to four
|
||||
pixels, a two-by-two square of the image. For example,
|
||||
Cr<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
|
||||
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
|
||||
Y'<subscript>11</subscript>. The Cb data, just like the Cr plane, constitutes
|
||||
the third plane. </para>
|
||||
|
||||
<para>If the Y plane has pad bytes after each row, then the Cr
|
||||
and Cb planes have half as many pad bytes after their rows. In other
|
||||
words, two Cx rows (including padding) is exactly as long as one Y row
|
||||
(including padding).</para>
|
||||
|
||||
<para><constant>V4L2_PIX_FMT_YVU420M</constant> is intended to be
|
||||
used only in drivers and applications that support the multi-planar API,
|
||||
described in <xref linkend="planar-apis"/>. </para>
|
||||
|
||||
<example>
|
||||
<title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 × 4
|
||||
pixel image</title>
|
||||
|
||||
<formalpara>
|
||||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte.
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="5" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>start0 + 0:</entry>
|
||||
<entry>Y'<subscript>00</subscript></entry>
|
||||
<entry>Y'<subscript>01</subscript></entry>
|
||||
<entry>Y'<subscript>02</subscript></entry>
|
||||
<entry>Y'<subscript>03</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start0 + 4:</entry>
|
||||
<entry>Y'<subscript>10</subscript></entry>
|
||||
<entry>Y'<subscript>11</subscript></entry>
|
||||
<entry>Y'<subscript>12</subscript></entry>
|
||||
<entry>Y'<subscript>13</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start0 + 8:</entry>
|
||||
<entry>Y'<subscript>20</subscript></entry>
|
||||
<entry>Y'<subscript>21</subscript></entry>
|
||||
<entry>Y'<subscript>22</subscript></entry>
|
||||
<entry>Y'<subscript>23</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start0 + 12:</entry>
|
||||
<entry>Y'<subscript>30</subscript></entry>
|
||||
<entry>Y'<subscript>31</subscript></entry>
|
||||
<entry>Y'<subscript>32</subscript></entry>
|
||||
<entry>Y'<subscript>33</subscript></entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry>start1 + 0:</entry>
|
||||
<entry>Cr<subscript>00</subscript></entry>
|
||||
<entry>Cr<subscript>01</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start1 + 2:</entry>
|
||||
<entry>Cr<subscript>10</subscript></entry>
|
||||
<entry>Cr<subscript>11</subscript></entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry>start2 + 0:</entry>
|
||||
<entry>Cb<subscript>00</subscript></entry>
|
||||
<entry>Cb<subscript>01</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start2 + 2:</entry>
|
||||
<entry>Cb<subscript>10</subscript></entry>
|
||||
<entry>Cb<subscript>11</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
|
||||
<formalpara>
|
||||
<title>Color Sample Location.</title>
|
||||
<para>
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="7" align="center">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
|
||||
<entry>2</entry><entry></entry><entry>3</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>0</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry><entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>1</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>2</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry><entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>3</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
</example>
|
||||
</refsect1>
|
||||
</refentry>
|
@ -708,6 +708,7 @@ information.</para>
|
||||
&sub-y41p;
|
||||
&sub-yuv420;
|
||||
&sub-yuv420m;
|
||||
&sub-yvu420m;
|
||||
&sub-yuv410;
|
||||
&sub-yuv422p;
|
||||
&sub-yuv411p;
|
||||
|
@ -40,6 +40,7 @@ cropping and composing rectangles have the same size.</para>
|
||||
<section>
|
||||
<title>Selection targets</title>
|
||||
|
||||
<para>
|
||||
<figure id="sel-targets-capture">
|
||||
<title>Cropping and composing targets</title>
|
||||
<mediaobject>
|
||||
@ -52,12 +53,12 @@ cropping and composing rectangles have the same size.</para>
|
||||
</textobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
</para>
|
||||
|
||||
<para>See <xref linkend="v4l2-selection-targets" /> for more
|
||||
information.</para>
|
||||
</section>
|
||||
|
||||
See <xref linkend="v4l2-selection-targets" /> for more
|
||||
information.
|
||||
|
||||
<section>
|
||||
|
||||
<title>Configuration</title>
|
||||
@ -216,18 +217,17 @@ composing and cropping operations by setting the appropriate targets. The V4L2
|
||||
API lacks any support for composing to and cropping from an image inside a
|
||||
memory buffer. The application could configure a capture device to fill only a
|
||||
part of an image by abusing V4L2 API. Cropping a smaller image from a larger
|
||||
one is achieved by setting the field <structfield>
|
||||
&v4l2-pix-format;::bytesperline </structfield>. Introducing an image offsets
|
||||
could be done by modifying field <structfield> &v4l2-buffer;::m:userptr
|
||||
</structfield> before calling <constant> VIDIOC_QBUF </constant>. Those
|
||||
one is achieved by setting the field
|
||||
&v4l2-pix-format;<structfield>::bytesperline</structfield>. Introducing an image offsets
|
||||
could be done by modifying field &v4l2-buffer;<structfield>::m_userptr</structfield>
|
||||
before calling <constant> VIDIOC_QBUF </constant>. Those
|
||||
operations should be avoided because they are not portable (endianness), and do
|
||||
not work for macroblock and Bayer formats and mmap buffers. The selection API
|
||||
deals with configuration of buffer cropping/composing in a clear, intuitive and
|
||||
portable way. Next, with the selection API the concepts of the padded target
|
||||
and constraints flags are introduced. Finally, <structname> &v4l2-crop;
|
||||
</structname> and <structname> &v4l2-cropcap; </structname> have no reserved
|
||||
fields. Therefore there is no way to extend their functionality. The new
|
||||
<structname> &v4l2-selection; </structname> provides a lot of place for future
|
||||
and constraints flags are introduced. Finally, &v4l2-crop; and &v4l2-cropcap;
|
||||
have no reserved fields. Therefore there is no way to extend their functionality.
|
||||
The new &v4l2-selection; provides a lot of place for future
|
||||
extensions. Driver developers are encouraged to implement only selection API.
|
||||
The former cropping API would be simulated using the new one. </para>
|
||||
|
||||
|
@ -145,9 +145,12 @@ applications. -->
|
||||
<authorinitials>hv</authorinitials>
|
||||
<revremark>Added VIDIOC_ENUM_FREQ_BANDS.
|
||||
</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>3.5</revnumber>
|
||||
<date>2012-05-07</date>
|
||||
<authorinitials>sa, sn</authorinitials>
|
||||
<authorinitials>sa, sn, hv</authorinitials>
|
||||
<revremark>Added V4L2_CTRL_TYPE_INTEGER_MENU and V4L2 subdev
|
||||
selections API. Improved the description of V4L2_CID_COLORFX
|
||||
control, added V4L2_CID_COLORFX_CBCR control.
|
||||
@ -158,11 +161,8 @@ applications. -->
|
||||
V4L2_CID_3A_LOCK, V4L2_CID_AUTO_FOCUS_START,
|
||||
V4L2_CID_AUTO_FOCUS_STOP, V4L2_CID_AUTO_FOCUS_STATUS
|
||||
and V4L2_CID_AUTO_FOCUS_RANGE.
|
||||
</revremark>
|
||||
<date>2012-05-01</date>
|
||||
<authorinitials>hv</authorinitials>
|
||||
<revremark>Added VIDIOC_ENUM_DV_TIMINGS, VIDIOC_QUERY_DV_TIMINGS and
|
||||
VIDIOC_DV_TIMINGS_CAP.
|
||||
Added VIDIOC_ENUM_DV_TIMINGS, VIDIOC_QUERY_DV_TIMINGS and
|
||||
VIDIOC_DV_TIMINGS_CAP.
|
||||
</revremark>
|
||||
</revision>
|
||||
|
||||
@ -472,7 +472,7 @@ and discussions on the V4L mailing list.</revremark>
|
||||
</partinfo>
|
||||
|
||||
<title>Video for Linux Two API Specification</title>
|
||||
<subtitle>Revision 3.5</subtitle>
|
||||
<subtitle>Revision 3.6</subtitle>
|
||||
|
||||
<chapter id="common">
|
||||
&sub-common;
|
||||
@ -581,6 +581,7 @@ and discussions on the V4L mailing list.</revremark>
|
||||
&sub-subdev-enum-frame-size;
|
||||
&sub-subdev-enum-mbus-code;
|
||||
&sub-subdev-g-crop;
|
||||
&sub-subdev-g-edid;
|
||||
&sub-subdev-g-fmt;
|
||||
&sub-subdev-g-frame-interval;
|
||||
&sub-subdev-g-selection;
|
||||
|
@ -59,6 +59,9 @@ constant except when switching the video standard. Remember this
|
||||
switch can occur implicit when switching the video input or
|
||||
output.</para>
|
||||
|
||||
<para>This ioctl must be implemented for video capture or output devices that
|
||||
support cropping and/or scaling and/or have non-square pixels, and for overlay devices.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-cropcap">
|
||||
<title>struct <structname>v4l2_cropcap</structname></title>
|
||||
<tgroup cols="3">
|
||||
@ -70,10 +73,10 @@ output.</para>
|
||||
<entry>Type of the data stream, set by the application.
|
||||
Only these types are valid here:
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver
|
||||
defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant>
|
||||
and higher. See <xref linkend="v4l2-buf-type" />.</entry>
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant> and
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>. See <xref linkend="v4l2-buf-type" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>struct <link linkend="v4l2-rect-crop">v4l2_rect</link></entry>
|
||||
@ -156,8 +159,7 @@ on 22 Oct 2002 subject "Re:[V4L][patches!] Re:v4l2/kernel-2.5" -->
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The &v4l2-cropcap; <structfield>type</structfield> is
|
||||
invalid. This is not permitted for video capture, output and overlay devices,
|
||||
which must support <constant>VIDIOC_CROPCAP</constant>.</para>
|
||||
invalid.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
@ -49,13 +49,6 @@
|
||||
<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
|
||||
|
@ -49,13 +49,6 @@
|
||||
<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-) encoder.
|
||||
<constant>VIDIOC_ENCODER_CMD</constant> sends a command to the
|
||||
encoder, <constant>VIDIOC_TRY_ENCODER_CMD</constant> can be used to
|
||||
|
@ -229,6 +229,12 @@ intended for the user.</entry>
|
||||
is out of bounds.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>Digital video presets are not supported for this input or output.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
@ -106,6 +106,12 @@ application.</entry>
|
||||
is out of bounds.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>Digital video presets are not supported for this input or output.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
@ -58,6 +58,9 @@ structure. Drivers fill the rest of the structure or return an
|
||||
incrementing by one until <errorcode>EINVAL</errorcode> is
|
||||
returned.</para>
|
||||
|
||||
<para>Note that after switching input or output the list of enumerated image
|
||||
formats may be different.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-fmtdesc">
|
||||
<title>struct <structname>v4l2_fmtdesc</structname></title>
|
||||
<tgroup cols="3">
|
||||
@ -78,10 +81,8 @@ Only these types are valid here:
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver
|
||||
defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant>
|
||||
and higher. See <xref linkend="v4l2-buf-type" />.</entry>
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant> and
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>. See <xref linkend="v4l2-buf-type" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
@ -50,13 +50,6 @@ and pixel format and receives a frame width and height.</para>
|
||||
<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>This ioctl allows applications to enumerate all frame sizes
|
||||
(&ie; width and height in pixels) that the device supports for the
|
||||
given pixel format.</para>
|
||||
|
@ -283,7 +283,7 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
|
||||
<entry>This input supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_IN_CAP_CUSTOM_TIMINGS</constant></entry>
|
||||
<entry><constant>V4L2_IN_CAP_DV_TIMINGS</constant></entry>
|
||||
<entry>0x00000002</entry>
|
||||
<entry>This input supports setting video timings by using VIDIOC_S_DV_TIMINGS.</entry>
|
||||
</row>
|
||||
|
@ -168,7 +168,7 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
|
||||
<entry>This output supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_OUT_CAP_CUSTOM_TIMINGS</constant></entry>
|
||||
<entry><constant>V4L2_OUT_CAP_DV_TIMINGS</constant></entry>
|
||||
<entry>0x00000002</entry>
|
||||
<entry>This output supports setting video timings by using VIDIOC_S_DV_TIMINGS.</entry>
|
||||
</row>
|
||||
|
@ -378,6 +378,12 @@ system)</para></footnote></para></entry>
|
||||
is out of bounds.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>Standard video timings are not supported for this input or output.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
@ -104,10 +104,8 @@ changed and <constant>VIDIOC_S_CROP</constant> returns the
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry>Type of the data stream, set by the application.
|
||||
Only these types are valid here: <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver
|
||||
defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant>
|
||||
and higher. See <xref linkend="v4l2-buf-type" />.</entry>
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> and
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>. See <xref linkend="v4l2-buf-type" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-rect;</entry>
|
||||
|
@ -77,6 +77,12 @@ If the preset is not supported, it returns an &EINVAL; </para>
|
||||
<constant>VIDIOC_S_DV_PRESET</constant>,<constant>VIDIOC_S_DV_PRESET</constant> parameter was unsuitable.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>Digital video presets are not supported for this input or output.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EBUSY</errorcode></term>
|
||||
<listitem>
|
||||
@ -104,7 +110,4 @@ If the preset is not supported, it returns an &EINVAL; </para>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
<refsect1>
|
||||
&return-value;
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
@ -56,7 +56,9 @@ a pointer to the &v4l2-dv-timings; structure as argument. If the ioctl is not su
|
||||
or the timing values are not correct, the driver returns &EINVAL;.</para>
|
||||
<para>The <filename>linux/v4l2-dv-timings.h</filename> header can be used to get the
|
||||
timings of the formats in the <xref linkend="cea861" /> and <xref linkend="vesadmt" />
|
||||
standards.</para>
|
||||
standards. If the current input or output does not support DV timings (e.g. if
|
||||
&VIDIOC-ENUMINPUT; does not set the <constant>V4L2_IN_CAP_DV_TIMINGS</constant> flag), then
|
||||
&ENODATA; is returned.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
@ -70,6 +72,12 @@ standards.</para>
|
||||
<constant>VIDIOC_S_DV_TIMINGS</constant> parameter was unsuitable.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>Digital video timings are not supported for this input or output.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EBUSY</errorcode></term>
|
||||
<listitem>
|
||||
@ -320,7 +328,4 @@ detected or used depends on the hardware.
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
<refsect1>
|
||||
&return-value;
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
@ -48,13 +48,6 @@
|
||||
<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>The <constant>VIDIOC_G_ENC_INDEX</constant> ioctl provides
|
||||
meta data about a compressed video stream the same or another
|
||||
application currently reads from the driver, which is useful for
|
||||
|
@ -81,7 +81,7 @@ the application calls the <constant>VIDIOC_S_FMT</constant> ioctl
|
||||
with a pointer to a <structname>v4l2_format</structname> structure
|
||||
the driver checks
|
||||
and adjusts the parameters against hardware abilities. Drivers
|
||||
should not return an error code unless the input is ambiguous, this is
|
||||
should not return an error code unless the <structfield>type</structfield> field is invalid, this is
|
||||
a mechanism to fathom device capabilities and to approach parameters
|
||||
acceptable for both the application and driver. On success the driver
|
||||
may program the hardware, allocate resources and generally prepare for
|
||||
@ -107,6 +107,10 @@ disabling I/O or possibly time consuming hardware preparations.
|
||||
Although strongly recommended drivers are not required to implement
|
||||
this ioctl.</para>
|
||||
|
||||
<para>The format as returned by <constant>VIDIOC_TRY_FMT</constant>
|
||||
must be identical to what <constant>VIDIOC_S_FMT</constant> returns for
|
||||
the same input or output.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-format">
|
||||
<title>struct <structname>v4l2_format</structname></title>
|
||||
<tgroup cols="4">
|
||||
@ -170,9 +174,7 @@ capture and output devices.</entry>
|
||||
<entry></entry>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>raw_data</structfield>[200]</entry>
|
||||
<entry>Place holder for future extensions and custom
|
||||
(driver defined) formats with <structfield>type</structfield>
|
||||
<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher.</entry>
|
||||
<entry>Place holder for future extensions.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
@ -187,8 +189,7 @@ capture and output devices.</entry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The &v4l2-format; <structfield>type</structfield>
|
||||
field is invalid, the requested buffer type not supported, or the
|
||||
format is not supported with this buffer type.</para>
|
||||
field is invalid or the requested buffer type not supported.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
@ -108,9 +108,7 @@ devices.</para>
|
||||
<entry></entry>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>raw_data</structfield>[200]</entry>
|
||||
<entry>A place holder for future extensions and custom
|
||||
(driver defined) buffer types <constant>V4L2_BUF_TYPE_PRIVATE</constant> and
|
||||
higher.</entry>
|
||||
<entry>A place holder for future extensions.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
@ -152,12 +152,10 @@ satisfactory parameters have been negotiated. If constraints flags have to be
|
||||
violated at then ERANGE is returned. The error indicates that <emphasis> there
|
||||
exist no rectangle </emphasis> that satisfies the constraints.</para>
|
||||
|
||||
</refsect1>
|
||||
|
||||
<para>Selection targets and flags are documented in <xref
|
||||
linkend="v4l2-selections-common"/>.</para>
|
||||
|
||||
<section>
|
||||
<para>
|
||||
<figure id="sel-const-adjust">
|
||||
<title>Size adjustments with constraint flags.</title>
|
||||
<mediaobject>
|
||||
@ -170,9 +168,9 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
|
||||
</textobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
</section>
|
||||
</para>
|
||||
|
||||
<refsect1>
|
||||
<para>
|
||||
<table pgwide="1" frame="none" id="v4l2-selection">
|
||||
<title>struct <structname>v4l2_selection</structname></title>
|
||||
<tgroup cols="3">
|
||||
@ -208,6 +206,7 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
@ -72,7 +72,9 @@ flags, being a write-only ioctl it does not return the actual new standard as
|
||||
the current input does not support the requested standard the driver
|
||||
returns an &EINVAL;. When the standard set is ambiguous drivers may
|
||||
return <errorcode>EINVAL</errorcode> or choose any of the requested
|
||||
standards.</para>
|
||||
standards. If the current input or output does not support standard video timings (e.g. if
|
||||
&VIDIOC-ENUMINPUT; does not set the <constant>V4L2_IN_CAP_STD</constant> flag), then
|
||||
&ENODATA; is returned.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
@ -85,6 +87,12 @@ standards.</para>
|
||||
<para>The <constant>VIDIOC_S_STD</constant> parameter was unsuitable.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>Standard video timings are not supported for this input or output.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
@ -354,6 +354,12 @@ radio tuners.</entry>
|
||||
<entry>The &VIDIOC-ENUM-FREQ-BANDS; ioctl can be used to enumerate
|
||||
the available frequency bands.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_TUNER_CAP_HWSEEK_PROG_LIM</constant></entry>
|
||||
<entry>0x0800</entry>
|
||||
<entry>The range to search when using the hardware seek functionality
|
||||
is programmable, see &VIDIOC-S-HW-FREQ-SEEK; for details.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
@ -155,6 +155,8 @@ or no buffers have been allocated yet, or the
|
||||
<structfield>userptr</structfield> or
|
||||
<structfield>length</structfield> are invalid.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EIO</errorcode></term>
|
||||
<listitem>
|
||||
<para><constant>VIDIOC_DQBUF</constant> failed due to an
|
||||
|
@ -65,5 +65,14 @@ returned.</para>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>Digital video presets are not supported for this input or output.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
@ -77,6 +77,12 @@ capabilities in order to give more precise feedback to the user.
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>Digital video timings are not supported for this input or output.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENOLINK</errorcode></term>
|
||||
<listitem>
|
||||
|
@ -90,11 +90,13 @@ ambiguities.</entry>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>bus_info</structfield>[32]</entry>
|
||||
<entry>Location of the device in the system, a
|
||||
NUL-terminated ASCII string. For example: "PCI Slot 4". This
|
||||
NUL-terminated ASCII string. For example: "PCI:0000:05:06.0". This
|
||||
information is intended for users, to distinguish multiple
|
||||
identical devices. If no such information is available the field may
|
||||
simply count the devices controlled by the driver, or contain the
|
||||
empty string (<structfield>bus_info</structfield>[0] = 0).<!-- XXX pci_dev->slot_name example --></entry>
|
||||
identical devices. If no such information is available the field must
|
||||
simply count the devices controlled by the driver ("platform:vivi-000").
|
||||
The bus_info must start with "PCI:" for PCI boards, "PCIe:" for PCI Express boards,
|
||||
"usb-" for USB devices, "I2C:" for i2c devices, "ISA:" for ISA devices,
|
||||
"parport" for parallel port devices and "platform:" for platform devices.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
@ -62,5 +62,13 @@ current video input or output.</para>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>Standard video timings are not supported for this input or output.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
@ -109,9 +109,8 @@ as the &v4l2-format; <structfield>type</structfield> field. See <xref
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[2]</entry>
|
||||
<entry>A place holder for future extensions and custom
|
||||
(driver defined) buffer types <constant>V4L2_BUF_TYPE_PRIVATE</constant> and
|
||||
higher. This array should be zeroed by applications.</entry>
|
||||
<entry>A place holder for future extensions. This array should
|
||||
be zeroed by applications.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
@ -75,6 +75,9 @@ seek is started.</para>
|
||||
|
||||
<para>This ioctl is supported if the <constant>V4L2_CAP_HW_FREQ_SEEK</constant> capability is set.</para>
|
||||
|
||||
<para>If this ioctl is called from a non-blocking filehandle, then &EAGAIN; is
|
||||
returned and no seek takes place.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-hw-freq-seek">
|
||||
<title>struct <structname>v4l2_hw_freq_seek</structname></title>
|
||||
<tgroup cols="3">
|
||||
@ -157,6 +160,13 @@ one of the values in the <structfield>type</structfield>,
|
||||
fields is wrong.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EAGAIN</errorcode></term>
|
||||
<listitem>
|
||||
<para>Attempted to call <constant>VIDIOC_S_HW_FREQ_SEEK</constant>
|
||||
with the filehandle in non-blocking mode.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
|
@ -74,7 +74,12 @@ not transmitted yet. I/O returns to the same state as after calling
|
||||
stream type. This is the same as &v4l2-requestbuffers;
|
||||
<structfield>type</structfield>.</para>
|
||||
|
||||
<para>Note applications can be preempted for unknown periods right
|
||||
<para>If <constant>VIDIOC_STREAMON</constant> is called when streaming
|
||||
is already in progress, or if <constant>VIDIOC_STREAMOFF</constant> is called
|
||||
when streaming is already stopped, then the ioctl does nothing and 0 is
|
||||
returned.</para>
|
||||
|
||||
<para>Note that applications can be preempted for unknown periods right
|
||||
before or after the <constant>VIDIOC_STREAMON</constant> or
|
||||
<constant>VIDIOC_STREAMOFF</constant> calls, there is no notion of
|
||||
starting or stopping "now". Buffer timestamps can be used to
|
||||
|
152
Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml
Normal file
152
Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml
Normal file
@ -0,0 +1,152 @@
|
||||
<refentry id="vidioc-subdev-g-edid">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_SUBDEV_G_EDID</refname>
|
||||
<refname>VIDIOC_SUBDEV_S_EDID</refname>
|
||||
<refpurpose>Get or set the EDID of a video receiver/transmitter</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_subdev_edid *<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>const struct v4l2_subdev_edid *<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_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
<para>These ioctls can be used to get or set an EDID associated with an input pad
|
||||
from a receiver or an output pad of a transmitter subdevice.</para>
|
||||
|
||||
<para>To get the EDID data the application has to fill in the <structfield>pad</structfield>,
|
||||
<structfield>start_block</structfield>, <structfield>blocks</structfield> and <structfield>edid</structfield>
|
||||
fields and call <constant>VIDIOC_SUBDEV_G_EDID</constant>. The current EDID from block
|
||||
<structfield>start_block</structfield> and of size <structfield>blocks</structfield>
|
||||
will be placed in the memory <structfield>edid</structfield> points to. The <structfield>edid</structfield>
|
||||
pointer must point to memory at least <structfield>blocks</structfield> * 128 bytes
|
||||
large (the size of one block is 128 bytes).</para>
|
||||
|
||||
<para>If there are fewer blocks than specified, then the driver will set <structfield>blocks</structfield>
|
||||
to the actual number of blocks. If there are no EDID blocks available at all, then the error code
|
||||
ENODATA is set.</para>
|
||||
|
||||
<para>If blocks have to be retrieved from the sink, then this call will block until they
|
||||
have been read.</para>
|
||||
|
||||
<para>To set the EDID blocks of a receiver the application has to fill in the <structfield>pad</structfield>,
|
||||
<structfield>blocks</structfield> and <structfield>edid</structfield> fields and set
|
||||
<structfield>start_block</structfield> to 0. It is not possible to set part of an EDID,
|
||||
it is always all or nothing. Setting the EDID data is only valid for receivers as it makes
|
||||
no sense for a transmitter.</para>
|
||||
|
||||
<para>The driver assumes that the full EDID is passed in. If there are more EDID blocks than
|
||||
the hardware can handle then the EDID is not written, but instead the error code E2BIG is set
|
||||
and <structfield>blocks</structfield> is set to the maximum that the hardware supports.
|
||||
If <structfield>start_block</structfield> is any
|
||||
value other than 0 then the error code EINVAL is set.</para>
|
||||
|
||||
<para>To disable an EDID you set <structfield>blocks</structfield> to 0. Depending on the
|
||||
hardware this will drive the hotplug pin low and/or block the source from reading the EDID
|
||||
data in some way. In any case, the end result is the same: the EDID is no longer available.
|
||||
</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-subdev-edid">
|
||||
<title>struct <structname>v4l2_subdev_edid</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>pad</structfield></entry>
|
||||
<entry>Pad for which to get/set the EDID blocks.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>start_block</structfield></entry>
|
||||
<entry>Read the EDID from starting with this block. Must be 0 when setting
|
||||
the EDID.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>blocks</structfield></entry>
|
||||
<entry>The number of blocks to get or set. Must be less or equal to 256 (the
|
||||
maximum number of blocks as defined by the standard). When you set the EDID and
|
||||
<structfield>blocks</structfield> is 0, then the EDID is disabled or erased.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u8 *</entry>
|
||||
<entry><structfield>edid</structfield></entry>
|
||||
<entry>Pointer to memory that contains the EDID. The minimum size is
|
||||
<structfield>blocks</structfield> * 128.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[5]</entry>
|
||||
<entry>Reserved for future extensions. Applications and drivers must
|
||||
set the array to zero.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>The EDID data is not available.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>E2BIG</errorcode></term>
|
||||
<listitem>
|
||||
<para>The EDID data you provided is more than the hardware can handle.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
@ -69,23 +69,22 @@
|
||||
more information on how each selection target affects the image
|
||||
processing pipeline inside the subdevice.</para>
|
||||
|
||||
<section>
|
||||
<refsect2>
|
||||
<title>Types of selection targets</title>
|
||||
|
||||
<para>There are two types of selection targets: actual and bounds. The
|
||||
actual targets are the targets which configure the hardware. The BOUNDS
|
||||
target will return a rectangle that contain all possible actual
|
||||
rectangles.</para>
|
||||
</section>
|
||||
</refsect2>
|
||||
|
||||
<section>
|
||||
<refsect2>
|
||||
<title>Discovering supported features</title>
|
||||
|
||||
<para>To discover which targets are supported, the user can
|
||||
perform <constant>VIDIOC_SUBDEV_G_SELECTION</constant> on them.
|
||||
Any unsupported target will return
|
||||
<constant>EINVAL</constant>.</para>
|
||||
</section>
|
||||
|
||||
<para>Selection targets and flags are documented in <xref
|
||||
linkend="v4l2-selections-common"/>.</para>
|
||||
@ -132,6 +131,7 @@
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect2>
|
||||
|
||||
</refsect1>
|
||||
|
||||
|
@ -29,7 +29,7 @@
|
||||
<title>LINUX MEDIA INFRASTRUCTURE API</title>
|
||||
|
||||
<copyright>
|
||||
<year>2009-2011</year>
|
||||
<year>2009-2012</year>
|
||||
<holder>LinuxTV Developers</holder>
|
||||
</copyright>
|
||||
|
||||
@ -53,7 +53,7 @@ Foundation. A copy of the license is included in the chapter entitled
|
||||
video and radio straming devices, including video cameras,
|
||||
analog and digital TV receiver cards, AM/FM receiver cards,
|
||||
streaming capture devices.</para>
|
||||
<para>It is divided into three parts.</para>
|
||||
<para>It is divided into four parts.</para>
|
||||
<para>The first part covers radio, capture,
|
||||
cameras and analog TV devices.</para>
|
||||
<para>The second part covers the
|
||||
@ -62,7 +62,8 @@ Foundation. A copy of the license is included in the chapter entitled
|
||||
in fact it covers several different video standards including
|
||||
DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated
|
||||
to documment support also for DVB-S2, ISDB-T and ISDB-S.</para>
|
||||
<para>The third part covers Remote Controller API</para>
|
||||
<para>The third part covers the Remote Controller API.</para>
|
||||
<para>The fourth part covers the Media Controller API.</para>
|
||||
<para>For additional information and for the latest development code,
|
||||
see: <ulink url="http://linuxtv.org">http://linuxtv.org</ulink>.</para>
|
||||
<para>For discussing improvements, reporting troubles, sending new drivers, etc, please mail to: <ulink url="http://vger.kernel.org/vger-lists.html#linux-media">Linux Media Mailing List (LMML).</ulink>.</para>
|
||||
@ -87,7 +88,7 @@ Foundation. A copy of the license is included in the chapter entitled
|
||||
</author>
|
||||
</authorgroup>
|
||||
<copyright>
|
||||
<year>2009-2011</year>
|
||||
<year>2009-2012</year>
|
||||
<holder>Mauro Carvalho Chehab</holder>
|
||||
</copyright>
|
||||
|
||||
|
@ -18,16 +18,16 @@ from the rest of the system. The article on LWN [12] mentions some probable
|
||||
uses of the memory controller. The memory controller can be used to
|
||||
|
||||
a. Isolate an application or a group of applications
|
||||
Memory hungry applications can be isolated and limited to a smaller
|
||||
Memory-hungry applications can be isolated and limited to a smaller
|
||||
amount of memory.
|
||||
b. Create a cgroup with limited amount of memory, this can be used
|
||||
b. Create a cgroup with a limited amount of memory; this can be used
|
||||
as a good alternative to booting with mem=XXXX.
|
||||
c. Virtualization solutions can control the amount of memory they want
|
||||
to assign to a virtual machine instance.
|
||||
d. A CD/DVD burner could control the amount of memory used by the
|
||||
rest of the system to ensure that burning does not fail due to lack
|
||||
of available memory.
|
||||
e. There are several other use cases, find one or use the controller just
|
||||
e. There are several other use cases; find one or use the controller just
|
||||
for fun (to learn and hack on the VM subsystem).
|
||||
|
||||
Current Status: linux-2.6.34-mmotm(development version of 2010/April)
|
||||
@ -38,12 +38,12 @@ Features:
|
||||
- optionally, memory+swap usage can be accounted and limited.
|
||||
- hierarchical accounting
|
||||
- soft limit
|
||||
- moving(recharging) account at moving a task is selectable.
|
||||
- moving (recharging) account at moving a task is selectable.
|
||||
- usage threshold notifier
|
||||
- oom-killer disable knob and oom-notifier
|
||||
- Root cgroup has no limit controls.
|
||||
|
||||
Kernel memory support is work in progress, and the current version provides
|
||||
Kernel memory support is a work in progress, and the current version provides
|
||||
basically functionality. (See Section 2.7)
|
||||
|
||||
Brief summary of control files.
|
||||
@ -144,9 +144,9 @@ Figure 1 shows the important aspects of the controller
|
||||
3. Each page has a pointer to the page_cgroup, which in turn knows the
|
||||
cgroup it belongs to
|
||||
|
||||
The accounting is done as follows: mem_cgroup_charge() is invoked to setup
|
||||
The accounting is done as follows: mem_cgroup_charge() is invoked to set up
|
||||
the necessary data structures and check if the cgroup that is being charged
|
||||
is over its limit. If it is then reclaim is invoked on the cgroup.
|
||||
is over its limit. If it is, then reclaim is invoked on the cgroup.
|
||||
More details can be found in the reclaim section of this document.
|
||||
If everything goes well, a page meta-data-structure called page_cgroup is
|
||||
updated. page_cgroup has its own LRU on cgroup.
|
||||
@ -163,13 +163,13 @@ for earlier. A file page will be accounted for as Page Cache when it's
|
||||
inserted into inode (radix-tree). While it's mapped into the page tables of
|
||||
processes, duplicate accounting is carefully avoided.
|
||||
|
||||
A RSS page is unaccounted when it's fully unmapped. A PageCache page is
|
||||
An RSS page is unaccounted when it's fully unmapped. A PageCache page is
|
||||
unaccounted when it's removed from radix-tree. Even if RSS pages are fully
|
||||
unmapped (by kswapd), they may exist as SwapCache in the system until they
|
||||
are really freed. Such SwapCaches also also accounted.
|
||||
are really freed. Such SwapCaches are also accounted.
|
||||
A swapped-in page is not accounted until it's mapped.
|
||||
|
||||
Note: The kernel does swapin-readahead and read multiple swaps at once.
|
||||
Note: The kernel does swapin-readahead and reads multiple swaps at once.
|
||||
This means swapped-in pages may contain pages for other tasks than a task
|
||||
causing page fault. So, we avoid accounting at swap-in I/O.
|
||||
|
||||
@ -209,7 +209,7 @@ memsw.limit_in_bytes.
|
||||
Example: Assume a system with 4G of swap. A task which allocates 6G of memory
|
||||
(by mistake) under 2G memory limitation will use all swap.
|
||||
In this case, setting memsw.limit_in_bytes=3G will prevent bad use of swap.
|
||||
By using memsw limit, you can avoid system OOM which can be caused by swap
|
||||
By using the memsw limit, you can avoid system OOM which can be caused by swap
|
||||
shortage.
|
||||
|
||||
* why 'memory+swap' rather than swap.
|
||||
@ -217,7 +217,7 @@ The global LRU(kswapd) can swap out arbitrary pages. Swap-out means
|
||||
to move account from memory to swap...there is no change in usage of
|
||||
memory+swap. In other words, when we want to limit the usage of swap without
|
||||
affecting global LRU, memory+swap limit is better than just limiting swap from
|
||||
OS point of view.
|
||||
an OS point of view.
|
||||
|
||||
* What happens when a cgroup hits memory.memsw.limit_in_bytes
|
||||
When a cgroup hits memory.memsw.limit_in_bytes, it's useless to do swap-out
|
||||
@ -236,7 +236,7 @@ an OOM routine is invoked to select and kill the bulkiest task in the
|
||||
cgroup. (See 10. OOM Control below.)
|
||||
|
||||
The reclaim algorithm has not been modified for cgroups, except that
|
||||
pages that are selected for reclaiming come from the per cgroup LRU
|
||||
pages that are selected for reclaiming come from the per-cgroup LRU
|
||||
list.
|
||||
|
||||
NOTE: Reclaim does not work for the root cgroup, since we cannot set any
|
||||
@ -316,7 +316,7 @@ We can check the usage:
|
||||
# cat /sys/fs/cgroup/memory/0/memory.usage_in_bytes
|
||||
1216512
|
||||
|
||||
A successful write to this file does not guarantee a successful set of
|
||||
A successful write to this file does not guarantee a successful setting of
|
||||
this limit to the value written into the file. This can be due to a
|
||||
number of factors, such as rounding up to page boundaries or the total
|
||||
availability of memory on the system. The user is required to re-read
|
||||
@ -350,7 +350,7 @@ Trying usual test under memory controller is always helpful.
|
||||
4.1 Troubleshooting
|
||||
|
||||
Sometimes a user might find that the application under a cgroup is
|
||||
terminated by OOM killer. There are several causes for this:
|
||||
terminated by the OOM killer. There are several causes for this:
|
||||
|
||||
1. The cgroup limit is too low (just too low to do anything useful)
|
||||
2. The user is using anonymous memory and swap is turned off or too low
|
||||
@ -358,7 +358,7 @@ terminated by OOM killer. There are several causes for this:
|
||||
A sync followed by echo 1 > /proc/sys/vm/drop_caches will help get rid of
|
||||
some of the pages cached in the cgroup (page cache pages).
|
||||
|
||||
To know what happens, disable OOM_Kill by 10. OOM Control(see below) and
|
||||
To know what happens, disabling OOM_Kill as per "10. OOM Control" (below) and
|
||||
seeing what happens will be helpful.
|
||||
|
||||
4.2 Task migration
|
||||
@ -399,10 +399,10 @@ About use_hierarchy, see Section 6.
|
||||
|
||||
Almost all pages tracked by this memory cgroup will be unmapped and freed.
|
||||
Some pages cannot be freed because they are locked or in-use. Such pages are
|
||||
moved to parent(if use_hierarchy==1) or root (if use_hierarchy==0) and this
|
||||
moved to parent (if use_hierarchy==1) or root (if use_hierarchy==0) and this
|
||||
cgroup will be empty.
|
||||
|
||||
Typical use case of this interface is that calling this before rmdir().
|
||||
The typical use case for this interface is before calling rmdir().
|
||||
Because rmdir() moves all pages to parent, some out-of-use page caches can be
|
||||
moved to the parent. If you want to avoid that, force_empty will be useful.
|
||||
|
||||
@ -486,7 +486,7 @@ You can reset failcnt by writing 0 to failcnt file.
|
||||
|
||||
For efficiency, as other kernel components, memory cgroup uses some optimization
|
||||
to avoid unnecessary cacheline false sharing. usage_in_bytes is affected by the
|
||||
method and doesn't show 'exact' value of memory(and swap) usage, it's an fuzz
|
||||
method and doesn't show 'exact' value of memory (and swap) usage, it's a fuzz
|
||||
value for efficient access. (Of course, when necessary, it's synchronized.)
|
||||
If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP)
|
||||
value in memory.stat(see 5.2).
|
||||
@ -496,8 +496,8 @@ value in memory.stat(see 5.2).
|
||||
This is similar to numa_maps but operates on a per-memcg basis. This is
|
||||
useful for providing visibility into the numa locality information within
|
||||
an memcg since the pages are allowed to be allocated from any physical
|
||||
node. One of the usecases is evaluating application performance by
|
||||
combining this information with the application's cpu allocation.
|
||||
node. One of the use cases is evaluating application performance by
|
||||
combining this information with the application's CPU allocation.
|
||||
|
||||
We export "total", "file", "anon" and "unevictable" pages per-node for
|
||||
each memcg. The ouput format of memory.numa_stat is:
|
||||
@ -561,10 +561,10 @@ are pushed back to their soft limits. If the soft limit of each control
|
||||
group is very high, they are pushed back as much as possible to make
|
||||
sure that one control group does not starve the others of memory.
|
||||
|
||||
Please note that soft limits is a best effort feature, it comes with
|
||||
Please note that soft limits is a best-effort feature; it comes with
|
||||
no guarantees, but it does its best to make sure that when memory is
|
||||
heavily contended for, memory is allocated based on the soft limit
|
||||
hints/setup. Currently soft limit based reclaim is setup such that
|
||||
hints/setup. Currently soft limit based reclaim is set up such that
|
||||
it gets invoked from balance_pgdat (kswapd).
|
||||
|
||||
7.1 Interface
|
||||
@ -592,7 +592,7 @@ page tables.
|
||||
|
||||
8.1 Interface
|
||||
|
||||
This feature is disabled by default. It can be enabled(and disabled again) by
|
||||
This feature is disabled by default. It can be enabledi (and disabled again) by
|
||||
writing to memory.move_charge_at_immigrate of the destination cgroup.
|
||||
|
||||
If you want to enable it:
|
||||
@ -601,8 +601,8 @@ If you want to enable it:
|
||||
|
||||
Note: Each bits of move_charge_at_immigrate has its own meaning about what type
|
||||
of charges should be moved. See 8.2 for details.
|
||||
Note: Charges are moved only when you move mm->owner, IOW, a leader of a thread
|
||||
group.
|
||||
Note: Charges are moved only when you move mm->owner, in other words,
|
||||
a leader of a thread group.
|
||||
Note: If we cannot find enough space for the task in the destination cgroup, we
|
||||
try to make space by reclaiming memory. Task migration may fail if we
|
||||
cannot make enough space.
|
||||
@ -612,25 +612,25 @@ And if you want disable it again:
|
||||
|
||||
# echo 0 > memory.move_charge_at_immigrate
|
||||
|
||||
8.2 Type of charges which can be move
|
||||
8.2 Type of charges which can be moved
|
||||
|
||||
Each bits of move_charge_at_immigrate has its own meaning about what type of
|
||||
charges should be moved. But in any cases, it must be noted that an account of
|
||||
a page or a swap can be moved only when it is charged to the task's current(old)
|
||||
memory cgroup.
|
||||
Each bit in move_charge_at_immigrate has its own meaning about what type of
|
||||
charges should be moved. But in any case, it must be noted that an account of
|
||||
a page or a swap can be moved only when it is charged to the task's current
|
||||
(old) memory cgroup.
|
||||
|
||||
bit | what type of charges would be moved ?
|
||||
-----+------------------------------------------------------------------------
|
||||
0 | A charge of an anonymous page(or swap of it) used by the target task.
|
||||
| You must enable Swap Extension(see 2.4) to enable move of swap charges.
|
||||
0 | A charge of an anonymous page (or swap of it) used by the target task.
|
||||
| You must enable Swap Extension (see 2.4) to enable move of swap charges.
|
||||
-----+------------------------------------------------------------------------
|
||||
1 | A charge of file pages(normal file, tmpfs file(e.g. ipc shared memory)
|
||||
1 | A charge of file pages (normal file, tmpfs file (e.g. ipc shared memory)
|
||||
| and swaps of tmpfs file) mmapped by the target task. Unlike the case of
|
||||
| anonymous pages, file pages(and swaps) in the range mmapped by the task
|
||||
| anonymous pages, file pages (and swaps) in the range mmapped by the task
|
||||
| will be moved even if the task hasn't done page fault, i.e. they might
|
||||
| not be the task's "RSS", but other task's "RSS" that maps the same file.
|
||||
| And mapcount of the page is ignored(the page can be moved even if
|
||||
| page_mapcount(page) > 1). You must enable Swap Extension(see 2.4) to
|
||||
| And mapcount of the page is ignored (the page can be moved even if
|
||||
| page_mapcount(page) > 1). You must enable Swap Extension (see 2.4) to
|
||||
| enable move of swap charges.
|
||||
|
||||
8.3 TODO
|
||||
@ -640,11 +640,11 @@ memory cgroup.
|
||||
|
||||
9. Memory thresholds
|
||||
|
||||
Memory cgroup implements memory thresholds using cgroups notification
|
||||
Memory cgroup implements memory thresholds using the cgroups notification
|
||||
API (see cgroups.txt). It allows to register multiple memory and memsw
|
||||
thresholds and gets notifications when it crosses.
|
||||
|
||||
To register a threshold application need:
|
||||
To register a threshold, an application must:
|
||||
- create an eventfd using eventfd(2);
|
||||
- open memory.usage_in_bytes or memory.memsw.usage_in_bytes;
|
||||
- write string like "<event_fd> <fd of memory.usage_in_bytes> <threshold>" to
|
||||
@ -659,24 +659,24 @@ It's applicable for root and non-root cgroup.
|
||||
|
||||
memory.oom_control file is for OOM notification and other controls.
|
||||
|
||||
Memory cgroup implements OOM notifier using cgroup notification
|
||||
Memory cgroup implements OOM notifier using the cgroup notification
|
||||
API (See cgroups.txt). It allows to register multiple OOM notification
|
||||
delivery and gets notification when OOM happens.
|
||||
|
||||
To register a notifier, application need:
|
||||
To register a notifier, an application must:
|
||||
- create an eventfd using eventfd(2)
|
||||
- open memory.oom_control file
|
||||
- write string like "<event_fd> <fd of memory.oom_control>" to
|
||||
cgroup.event_control
|
||||
|
||||
Application will be notified through eventfd when OOM happens.
|
||||
OOM notification doesn't work for root cgroup.
|
||||
The application will be notified through eventfd when OOM happens.
|
||||
OOM notification doesn't work for the root cgroup.
|
||||
|
||||
You can disable OOM-killer by writing "1" to memory.oom_control file, as:
|
||||
You can disable the OOM-killer by writing "1" to memory.oom_control file, as:
|
||||
|
||||
#echo 1 > memory.oom_control
|
||||
|
||||
This operation is only allowed to the top cgroup of sub-hierarchy.
|
||||
This operation is only allowed to the top cgroup of a sub-hierarchy.
|
||||
If OOM-killer is disabled, tasks under cgroup will hang/sleep
|
||||
in memory cgroup's OOM-waitqueue when they request accountable memory.
|
||||
|
||||
|
@ -1,3 +1,15 @@
|
||||
ARM Integrator/AP (Application Platform) and Integrator/CP (Compact Platform)
|
||||
-----------------------------------------------------------------------------
|
||||
ARM's oldest Linux-supported platform with connectors for different core
|
||||
tiles of ARMv4, ARMv5 and ARMv6 type.
|
||||
|
||||
Required properties (in root node):
|
||||
compatible = "arm,integrator-ap"; /* Application Platform */
|
||||
compatible = "arm,integrator-cp"; /* Compact Platform */
|
||||
|
||||
FPGA type interrupt controllers, see the versatile-fpga-irq binding doc.
|
||||
|
||||
|
||||
ARM Versatile Application and Platform Baseboards
|
||||
-------------------------------------------------
|
||||
ARM's development hardware platform with connectors for customizable
|
||||
|
31
Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt
Normal file
31
Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt
Normal file
@ -0,0 +1,31 @@
|
||||
* ARM Versatile FPGA interrupt controller
|
||||
|
||||
One or more FPGA IRQ controllers can be synthesized in an ARM reference board
|
||||
such as the Integrator or Versatile family. The output of these different
|
||||
controllers are OR:ed together and fed to the CPU tile's IRQ input. Each
|
||||
instance can handle up to 32 interrupts.
|
||||
|
||||
Required properties:
|
||||
- compatible: "arm,versatile-fpga-irq"
|
||||
- interrupt-controller: Identifies the node as an interrupt controller
|
||||
- #interrupt-cells: The number of cells to define the interrupts. Must be 1
|
||||
as the FPGA IRQ controller has no configuration options for interrupt
|
||||
sources. The cell is a u32 and defines the interrupt number.
|
||||
- reg: The register bank for the FPGA interrupt controller.
|
||||
- clear-mask: a u32 number representing the mask written to clear all IRQs
|
||||
on the controller at boot for example.
|
||||
- valid-mask: a u32 number representing a bit mask determining which of
|
||||
the interrupts are valid. Unconnected/unused lines are set to 0, and
|
||||
the system till not make it possible for devices to request these
|
||||
interrupts.
|
||||
|
||||
Example:
|
||||
|
||||
pic: pic@14000000 {
|
||||
compatible = "arm,versatile-fpga-irq";
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-controller;
|
||||
reg = <0x14000000 0x100>;
|
||||
clear-mask = <0xffffffff>;
|
||||
valid-mask = <0x003fffff>;
|
||||
};
|
20
Documentation/devicetree/bindings/crypto/mv_cesa.txt
Normal file
20
Documentation/devicetree/bindings/crypto/mv_cesa.txt
Normal file
@ -0,0 +1,20 @@
|
||||
Marvell Cryptographic Engines And Security Accelerator
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "marvell,orion-crypto"
|
||||
- reg : base physical address of the engine and length of memory mapped
|
||||
region, followed by base physical address of sram and its memory
|
||||
length
|
||||
- reg-names : "regs" , "sram";
|
||||
- interrupts : interrupt number
|
||||
|
||||
Examples:
|
||||
|
||||
crypto@30000 {
|
||||
compatible = "marvell,orion-crypto";
|
||||
reg = <0x30000 0x10000>,
|
||||
<0x4000000 0x800>;
|
||||
reg-names = "regs" , "sram";
|
||||
interrupts = <22>;
|
||||
status = "okay";
|
||||
};
|
25
Documentation/devicetree/bindings/gpio/gpio-fan.txt
Normal file
25
Documentation/devicetree/bindings/gpio/gpio-fan.txt
Normal file
@ -0,0 +1,25 @@
|
||||
Bindings for fan connected to GPIO lines
|
||||
|
||||
Required properties:
|
||||
- compatible : "gpio-fan"
|
||||
- gpios: Specifies the pins that map to bits in the control value,
|
||||
ordered MSB-->LSB.
|
||||
- gpio-fan,speed-map: A mapping of possible fan RPM speeds and the
|
||||
control value that should be set to achieve them. This array
|
||||
must have the RPM values in ascending order.
|
||||
|
||||
Optional properties:
|
||||
- alarm-gpios: This pin going active indicates something is wrong with
|
||||
the fan, and a udev event will be fired.
|
||||
|
||||
Examples:
|
||||
|
||||
gpio_fan {
|
||||
compatible = "gpio-fan";
|
||||
gpios = <&gpio1 14 1
|
||||
&gpio1 13 1>;
|
||||
gpio-fan,speed-map = <0 0
|
||||
3000 1
|
||||
6000 2>;
|
||||
alarm-gpios = <&gpio1 15 1>;
|
||||
};
|
53
Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
Normal file
53
Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
Normal file
@ -0,0 +1,53 @@
|
||||
* Marvell EBU GPIO controller
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio"
|
||||
or "marvell,armadaxp-gpio". "marvell,orion-gpio" should be used for
|
||||
Orion, Kirkwood, Dove, Discovery (except MV78200) and Armada
|
||||
370. "marvell,mv78200-gpio" should be used for the Discovery
|
||||
MV78200. "marvel,armadaxp-gpio" should be used for all Armada XP
|
||||
SoCs (MV78230, MV78260, MV78460).
|
||||
|
||||
- reg: Address and length of the register set for the device. Only one
|
||||
entry is expected, except for the "marvell,armadaxp-gpio" variant
|
||||
for which two entries are expected: one for the general registers,
|
||||
one for the per-cpu registers.
|
||||
|
||||
- interrupts: The list of interrupts that are used for all the pins
|
||||
managed by this GPIO bank. There can be more than one interrupt
|
||||
(example: 1 interrupt per 8 pins on Armada XP, which means 4
|
||||
interrupts per bank of 32 GPIOs).
|
||||
|
||||
- interrupt-controller: identifies the node as an interrupt controller
|
||||
|
||||
- #interrupt-cells: specifies the number of cells needed to encode an
|
||||
interrupt source. Should be two.
|
||||
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.
|
||||
|
||||
- gpio-controller: marks the device node as a gpio controller
|
||||
|
||||
- ngpios: number of GPIOs this controller has
|
||||
|
||||
- #gpio-cells: Should be two. The first cell is the pin number. The
|
||||
second cell is reserved for flags, unused at the moment.
|
||||
|
||||
Example:
|
||||
|
||||
gpio0: gpio@d0018100 {
|
||||
compatible = "marvell,armadaxp-gpio";
|
||||
reg = <0xd0018100 0x40>,
|
||||
<0xd0018800 0x30>;
|
||||
ngpios = <32>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupts = <16>, <17>, <18>, <19>;
|
||||
};
|
@ -0,0 +1,83 @@
|
||||
Lantiq FALCON pinmux controller
|
||||
|
||||
Required properties:
|
||||
- compatible: "lantiq,pinctrl-falcon"
|
||||
- reg: Should contain the physical address and length of the gpio/pinmux
|
||||
register range
|
||||
|
||||
Please refer to pinctrl-bindings.txt in this directory for details of the
|
||||
common pinctrl bindings used by client devices, including the meaning of the
|
||||
phrase "pin configuration node".
|
||||
|
||||
Lantiq's pin configuration nodes act as a container for an abitrary number of
|
||||
subnodes. Each of these subnodes represents some desired configuration for a
|
||||
pin, a group, or a list of pins or groups. This configuration can include the
|
||||
mux function to select on those group(s), and two pin configuration parameters:
|
||||
pull-up and open-drain
|
||||
|
||||
The name of each subnode is not important as long as it is unique; all subnodes
|
||||
should be enumerated and processed purely based on their content.
|
||||
|
||||
Each subnode only affects those parameters that are explicitly listed. In
|
||||
other words, a subnode that lists a mux function but no pin configuration
|
||||
parameters implies no information about any pin configuration parameters.
|
||||
Similarly, a pin subnode that describes a pullup parameter implies no
|
||||
information about e.g. the mux function.
|
||||
|
||||
We support 2 types of nodes.
|
||||
|
||||
Definition of mux function groups:
|
||||
|
||||
Required subnode-properties:
|
||||
- lantiq,groups : An array of strings. Each string contains the name of a group.
|
||||
Valid values for these names are listed below.
|
||||
- lantiq,function: A string containing the name of the function to mux to the
|
||||
group. Valid values for function names are listed below.
|
||||
|
||||
Valid values for group and function names:
|
||||
|
||||
mux groups:
|
||||
por, ntr, ntr8k, hrst, mdio, bootled, asc0, spi, spi cs0, spi cs1, i2c,
|
||||
jtag, slic, pcm, asc1
|
||||
|
||||
functions:
|
||||
rst, ntr, mdio, led, asc, spi, i2c, jtag, slic, pcm
|
||||
|
||||
|
||||
Definition of pin configurations:
|
||||
|
||||
Required subnode-properties:
|
||||
- lantiq,pins : An array of strings. Each string contains the name of a pin.
|
||||
Valid values for these names are listed below.
|
||||
|
||||
Optional subnode-properties:
|
||||
- lantiq,pull: Integer, representing the pull-down/up to apply to the pin.
|
||||
0: none, 1: down
|
||||
- lantiq,drive-current: Boolean, enables drive-current
|
||||
- lantiq,slew-rate: Boolean, enables slew-rate
|
||||
|
||||
Example:
|
||||
pinmux0 {
|
||||
compatible = "lantiq,pinctrl-falcon";
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&state_default>;
|
||||
|
||||
state_default: pinmux {
|
||||
asc0 {
|
||||
lantiq,groups = "asc0";
|
||||
lantiq,function = "asc";
|
||||
};
|
||||
ntr {
|
||||
lantiq,groups = "ntr8k";
|
||||
lantiq,function = "ntr";
|
||||
};
|
||||
i2c {
|
||||
lantiq,groups = "i2c";
|
||||
lantiq,function = "i2c";
|
||||
};
|
||||
hrst {
|
||||
lantiq,groups = "hrst";
|
||||
lantiq,function = "rst";
|
||||
};
|
||||
};
|
||||
};
|
@ -0,0 +1,97 @@
|
||||
Lantiq XWAY pinmux controller
|
||||
|
||||
Required properties:
|
||||
- compatible: "lantiq,pinctrl-xway" or "lantiq,pinctrl-xr9"
|
||||
- reg: Should contain the physical address and length of the gpio/pinmux
|
||||
register range
|
||||
|
||||
Please refer to pinctrl-bindings.txt in this directory for details of the
|
||||
common pinctrl bindings used by client devices, including the meaning of the
|
||||
phrase "pin configuration node".
|
||||
|
||||
Lantiq's pin configuration nodes act as a container for an abitrary number of
|
||||
subnodes. Each of these subnodes represents some desired configuration for a
|
||||
pin, a group, or a list of pins or groups. This configuration can include the
|
||||
mux function to select on those group(s), and two pin configuration parameters:
|
||||
pull-up and open-drain
|
||||
|
||||
The name of each subnode is not important as long as it is unique; all subnodes
|
||||
should be enumerated and processed purely based on their content.
|
||||
|
||||
Each subnode only affects those parameters that are explicitly listed. In
|
||||
other words, a subnode that lists a mux function but no pin configuration
|
||||
parameters implies no information about any pin configuration parameters.
|
||||
Similarly, a pin subnode that describes a pullup parameter implies no
|
||||
information about e.g. the mux function.
|
||||
|
||||
We support 2 types of nodes.
|
||||
|
||||
Definition of mux function groups:
|
||||
|
||||
Required subnode-properties:
|
||||
- lantiq,groups : An array of strings. Each string contains the name of a group.
|
||||
Valid values for these names are listed below.
|
||||
- lantiq,function: A string containing the name of the function to mux to the
|
||||
group. Valid values for function names are listed below.
|
||||
|
||||
Valid values for group and function names:
|
||||
|
||||
mux groups:
|
||||
exin0, exin1, exin2, jtag, ebu a23, ebu a24, ebu a25, ebu clk, ebu cs1,
|
||||
ebu wait, nand ale, nand cs1, nand cle, spi, spi_cs1, spi_cs2, spi_cs3,
|
||||
spi_cs4, spi_cs5, spi_cs6, asc0, asc0 cts rts, stp, nmi , gpt1, gpt2,
|
||||
gpt3, clkout0, clkout1, clkout2, clkout3, gnt1, gnt2, gnt3, req1, req2,
|
||||
req3
|
||||
|
||||
additional mux groups (XR9 only):
|
||||
mdio, nand rdy, nand rd, exin3, exin4, gnt4, req4
|
||||
|
||||
functions:
|
||||
spi, asc, cgu, jtag, exin, stp, gpt, nmi, pci, ebu, mdio
|
||||
|
||||
|
||||
|
||||
Definition of pin configurations:
|
||||
|
||||
Required subnode-properties:
|
||||
- lantiq,pins : An array of strings. Each string contains the name of a pin.
|
||||
Valid values for these names are listed below.
|
||||
|
||||
Optional subnode-properties:
|
||||
- lantiq,pull: Integer, representing the pull-down/up to apply to the pin.
|
||||
0: none, 1: down, 2: up.
|
||||
- lantiq,open-drain: Boolean, enables open-drain on the defined pin.
|
||||
|
||||
Valid values for XWAY pin names:
|
||||
Pinconf pins can be referenced via the names io0-io31.
|
||||
|
||||
Valid values for XR9 pin names:
|
||||
Pinconf pins can be referenced via the names io0-io55.
|
||||
|
||||
Example:
|
||||
gpio: pinmux@E100B10 {
|
||||
compatible = "lantiq,pinctrl-xway";
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&state_default>;
|
||||
|
||||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
reg = <0xE100B10 0xA0>;
|
||||
|
||||
state_default: pinmux {
|
||||
stp {
|
||||
lantiq,groups = "stp";
|
||||
lantiq,function = "stp";
|
||||
};
|
||||
pci {
|
||||
lantiq,groups = "gnt1";
|
||||
lantiq,function = "pci";
|
||||
};
|
||||
conf_out {
|
||||
lantiq,pins = "io4", "io5", "io6"; /* stp */
|
||||
lantiq,open-drain;
|
||||
lantiq,pull = <0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
@ -0,0 +1,95 @@
|
||||
* Marvell Armada 370 SoC pinctrl driver for mpp
|
||||
|
||||
Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
|
||||
part and usage.
|
||||
|
||||
Required properties:
|
||||
- compatible: "marvell,88f6710-pinctrl"
|
||||
|
||||
Available mpp pins/groups and functions:
|
||||
Note: brackets (x) are not part of the mpp name for marvell,function and given
|
||||
only for more detailed description in this document.
|
||||
|
||||
name pins functions
|
||||
================================================================================
|
||||
mpp0 0 gpio, uart0(rxd)
|
||||
mpp1 1 gpo, uart0(txd)
|
||||
mpp2 2 gpio, i2c0(sck), uart0(txd)
|
||||
mpp3 3 gpio, i2c0(sda), uart0(rxd)
|
||||
mpp4 4 gpio, cpu_pd(vdd)
|
||||
mpp5 5 gpo, ge0(txclko), uart1(txd), spi1(clk), audio(mclk)
|
||||
mpp6 6 gpio, ge0(txd0), sata0(prsnt), tdm(rst), audio(sdo)
|
||||
mpp7 7 gpo, ge0(txd1), tdm(tdx), audio(lrclk)
|
||||
mpp8 8 gpio, ge0(txd2), uart0(rts), tdm(drx), audio(bclk)
|
||||
mpp9 9 gpo, ge0(txd3), uart1(txd), sd0(clk), audio(spdifo)
|
||||
mpp10 10 gpio, ge0(txctl), uart0(cts), tdm(fsync), audio(sdi)
|
||||
mpp11 11 gpio, ge0(rxd0), uart1(rxd), sd0(cmd), spi0(cs1),
|
||||
sata1(prsnt), spi1(cs1)
|
||||
mpp12 12 gpio, ge0(rxd1), i2c1(sda), sd0(d0), spi1(cs0),
|
||||
audio(spdifi)
|
||||
mpp13 13 gpio, ge0(rxd2), i2c1(sck), sd0(d1), tdm(pclk),
|
||||
audio(rmclk)
|
||||
mpp14 14 gpio, ge0(rxd3), pcie(clkreq0), sd0(d2), spi1(mosi),
|
||||
spi0(cs2)
|
||||
mpp15 15 gpio, ge0(rxctl), pcie(clkreq1), sd0(d3), spi1(miso),
|
||||
spi0(cs3)
|
||||
mpp16 16 gpio, ge0(rxclk), uart1(rxd), tdm(int), audio(extclk)
|
||||
mpp17 17 gpo, ge(mdc)
|
||||
mpp18 18 gpio, ge(mdio)
|
||||
mpp19 19 gpio, ge0(txclk), ge1(txclkout), tdm(pclk)
|
||||
mpp20 20 gpo, ge0(txd4), ge1(txd0)
|
||||
mpp21 21 gpo, ge0(txd5), ge1(txd1), uart1(txd)
|
||||
mpp22 22 gpo, ge0(txd6), ge1(txd2), uart0(rts)
|
||||
mpp23 23 gpo, ge0(txd7), ge1(txd3), spi1(mosi)
|
||||
mpp24 24 gpio, ge0(col), ge1(txctl), spi1(cs0)
|
||||
mpp25 25 gpio, ge0(rxerr), ge1(rxd0), uart1(rxd)
|
||||
mpp26 26 gpio, ge0(crs), ge1(rxd1), spi1(miso)
|
||||
mpp27 27 gpio, ge0(rxd4), ge1(rxd2), uart0(cts)
|
||||
mpp28 28 gpio, ge0(rxd5), ge1(rxd3)
|
||||
mpp29 29 gpio, ge0(rxd6), ge1(rxctl), i2c1(sda)
|
||||
mpp30 30 gpio, ge0(rxd7), ge1(rxclk), i2c1(sck)
|
||||
mpp31 31 gpio, tclk, ge0(txerr)
|
||||
mpp32 32 gpio, spi0(cs0)
|
||||
mpp33 33 gpio, dev(bootcs), spi0(cs0)
|
||||
mpp34 34 gpo, dev(wen0), spi0(mosi)
|
||||
mpp35 35 gpo, dev(oen), spi0(sck)
|
||||
mpp36 36 gpo, dev(a1), spi0(miso)
|
||||
mpp37 37 gpo, dev(a0), sata0(prsnt)
|
||||
mpp38 38 gpio, dev(ready), uart1(cts), uart0(cts)
|
||||
mpp39 39 gpo, dev(ad0), audio(spdifo)
|
||||
mpp40 40 gpio, dev(ad1), uart1(rts), uart0(rts)
|
||||
mpp41 41 gpio, dev(ad2), uart1(rxd)
|
||||
mpp42 42 gpo, dev(ad3), uart1(txd)
|
||||
mpp43 43 gpo, dev(ad4), audio(bclk)
|
||||
mpp44 44 gpo, dev(ad5), audio(mclk)
|
||||
mpp45 45 gpo, dev(ad6), audio(lrclk)
|
||||
mpp46 46 gpo, dev(ad7), audio(sdo)
|
||||
mpp47 47 gpo, dev(ad8), sd0(clk), audio(spdifo)
|
||||
mpp48 48 gpio, dev(ad9), uart0(rts), sd0(cmd), sata1(prsnt),
|
||||
spi0(cs1)
|
||||
mpp49 49 gpio, dev(ad10), pcie(clkreq1), sd0(d0), spi1(cs0),
|
||||
audio(spdifi)
|
||||
mpp50 50 gpio, dev(ad11), uart0(cts), sd0(d1), spi1(miso),
|
||||
audio(rmclk)
|
||||
mpp51 51 gpio, dev(ad12), i2c1(sda), sd0(d2), spi1(mosi)
|
||||
mpp52 52 gpio, dev(ad13), i2c1(sck), sd0(d3), spi1(sck)
|
||||
mpp53 53 gpio, dev(ad14), sd0(clk), tdm(pclk), spi0(cs2),
|
||||
pcie(clkreq1)
|
||||
mpp54 54 gpo, dev(ad15), tdm(dtx)
|
||||
mpp55 55 gpio, dev(cs1), uart1(txd), tdm(rst), sata1(prsnt),
|
||||
sata0(prsnt)
|
||||
mpp56 56 gpio, dev(cs2), uart1(cts), uart0(cts), spi0(cs3),
|
||||
pcie(clkreq0), spi1(cs1)
|
||||
mpp57 57 gpio, dev(cs3), uart1(rxd), tdm(fsync), sata0(prsnt),
|
||||
audio(sdo)
|
||||
mpp58 58 gpio, dev(cs0), uart1(rts), tdm(int), audio(extclk),
|
||||
uart0(rts)
|
||||
mpp59 59 gpo, dev(ale0), uart1(rts), uart0(rts), audio(bclk)
|
||||
mpp60 60 gpio, dev(ale1), uart1(rxd), sata0(prsnt), pcie(rst-out),
|
||||
audio(sdi)
|
||||
mpp61 61 gpo, dev(wen1), uart1(txd), audio(rclk)
|
||||
mpp62 62 gpio, dev(a2), uart1(cts), tdm(drx), pcie(clkreq0),
|
||||
audio(mclk), uart0(cts)
|
||||
mpp63 63 gpo, spi0(sck), tclk
|
||||
mpp64 64 gpio, spi0(miso), spi0-1(cs1)
|
||||
mpp65 65 gpio, spi0(mosi), spi0-1(cs2)
|
@ -0,0 +1,100 @@
|
||||
* Marvell Armada XP SoC pinctrl driver for mpp
|
||||
|
||||
Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
|
||||
part and usage.
|
||||
|
||||
Required properties:
|
||||
- compatible: "marvell,mv78230-pinctrl", "marvell,mv78260-pinctrl",
|
||||
"marvell,mv78460-pinctrl"
|
||||
|
||||
This driver supports all Armada XP variants, i.e. mv78230, mv78260, and mv78460.
|
||||
|
||||
Available mpp pins/groups and functions:
|
||||
Note: brackets (x) are not part of the mpp name for marvell,function and given
|
||||
only for more detailed description in this document.
|
||||
|
||||
* Marvell Armada XP (all variants)
|
||||
|
||||
name pins functions
|
||||
================================================================================
|
||||
mpp0 0 gpio, ge0(txclko), lcd(d0)
|
||||
mpp1 1 gpio, ge0(txd0), lcd(d1)
|
||||
mpp2 2 gpio, ge0(txd1), lcd(d2)
|
||||
mpp3 3 gpio, ge0(txd2), lcd(d3)
|
||||
mpp4 4 gpio, ge0(txd3), lcd(d4)
|
||||
mpp5 5 gpio, ge0(txctl), lcd(d5)
|
||||
mpp6 6 gpio, ge0(rxd0), lcd(d6)
|
||||
mpp7 7 gpio, ge0(rxd1), lcd(d7)
|
||||
mpp8 8 gpio, ge0(rxd2), lcd(d8)
|
||||
mpp9 9 gpio, ge0(rxd3), lcd(d9)
|
||||
mpp10 10 gpio, ge0(rxctl), lcd(d10)
|
||||
mpp11 11 gpio, ge0(rxclk), lcd(d11)
|
||||
mpp12 12 gpio, ge0(txd4), ge1(txd0), lcd(d12)
|
||||
mpp13 13 gpio, ge0(txd5), ge1(txd1), lcd(d13)
|
||||
mpp14 14 gpio, ge0(txd6), ge1(txd2), lcd(d15)
|
||||
mpp15 15 gpio, ge0(txd7), ge1(txd3), lcd(d16)
|
||||
mpp16 16 gpio, ge0(txd7), ge1(txd3), lcd(d16)
|
||||
mpp17 17 gpio, ge0(col), ge1(txctl), lcd(d17)
|
||||
mpp18 18 gpio, ge0(rxerr), ge1(rxd0), lcd(d18), ptp(trig)
|
||||
mpp19 19 gpio, ge0(crs), ge1(rxd1), lcd(d19), ptp(evreq)
|
||||
mpp20 20 gpio, ge0(rxd4), ge1(rxd2), lcd(d20), ptp(clk)
|
||||
mpp21 21 gpio, ge0(rxd5), ge1(rxd3), lcd(d21), mem(bat)
|
||||
mpp22 22 gpio, ge0(rxd6), ge1(rxctl), lcd(d22), sata0(prsnt)
|
||||
mpp23 23 gpio, ge0(rxd7), ge1(rxclk), lcd(d23), sata1(prsnt)
|
||||
mpp24 24 gpio, lcd(hsync), sata1(prsnt), nf(bootcs-re), tdm(rst)
|
||||
mpp25 25 gpio, lcd(vsync), sata0(prsnt), nf(bootcs-we), tdm(pclk)
|
||||
mpp26 26 gpio, lcd(clk), tdm(fsync), vdd(cpu1-pd)
|
||||
mpp27 27 gpio, lcd(e), tdm(dtx), ptp(trig)
|
||||
mpp28 28 gpio, lcd(pwm), tdm(drx), ptp(evreq)
|
||||
mpp29 29 gpio, lcd(ref-clk), tdm(int0), ptp(clk), vdd(cpu0-pd)
|
||||
mpp30 30 gpio, tdm(int1), sd0(clk)
|
||||
mpp31 31 gpio, tdm(int2), sd0(cmd), vdd(cpu0-pd)
|
||||
mpp32 32 gpio, tdm(int3), sd0(d0), vdd(cpu1-pd)
|
||||
mpp33 33 gpio, tdm(int4), sd0(d1), mem(bat)
|
||||
mpp34 34 gpio, tdm(int5), sd0(d2), sata0(prsnt)
|
||||
mpp35 35 gpio, tdm(int6), sd0(d3), sata1(prsnt)
|
||||
mpp36 36 gpio, spi(mosi)
|
||||
mpp37 37 gpio, spi(miso)
|
||||
mpp38 38 gpio, spi(sck)
|
||||
mpp39 39 gpio, spi(cs0)
|
||||
mpp40 40 gpio, spi(cs1), uart2(cts), lcd(vga-hsync), vdd(cpu1-pd),
|
||||
pcie(clkreq0)
|
||||
mpp41 41 gpio, spi(cs2), uart2(rts), lcd(vga-vsync), sata1(prsnt),
|
||||
pcie(clkreq1)
|
||||
mpp42 42 gpio, uart2(rxd), uart0(cts), tdm(int7), tdm-1(timer),
|
||||
vdd(cpu0-pd)
|
||||
mpp43 43 gpio, uart2(txd), uart0(rts), spi(cs3), pcie(rstout),
|
||||
vdd(cpu2-3-pd){1}
|
||||
mpp44 44 gpio, uart2(cts), uart3(rxd), spi(cs4), pcie(clkreq2),
|
||||
mem(bat)
|
||||
mpp45 45 gpio, uart2(rts), uart3(txd), spi(cs5), sata1(prsnt)
|
||||
mpp46 46 gpio, uart3(rts), uart1(rts), spi(cs6), sata0(prsnt)
|
||||
mpp47 47 gpio, uart3(cts), uart1(cts), spi(cs7), pcie(clkreq3),
|
||||
ref(clkout)
|
||||
mpp48 48 gpio, tclk, dev(burst/last)
|
||||
|
||||
* Marvell Armada XP (mv78260 and mv78460 only)
|
||||
|
||||
name pins functions
|
||||
================================================================================
|
||||
mpp49 49 gpio, dev(we3)
|
||||
mpp50 50 gpio, dev(we2)
|
||||
mpp51 51 gpio, dev(ad16)
|
||||
mpp52 52 gpio, dev(ad17)
|
||||
mpp53 53 gpio, dev(ad18)
|
||||
mpp54 54 gpio, dev(ad19)
|
||||
mpp55 55 gpio, dev(ad20), vdd(cpu0-pd)
|
||||
mpp56 56 gpio, dev(ad21), vdd(cpu1-pd)
|
||||
mpp57 57 gpio, dev(ad22), vdd(cpu2-3-pd){1}
|
||||
mpp58 58 gpio, dev(ad23)
|
||||
mpp59 59 gpio, dev(ad24)
|
||||
mpp60 60 gpio, dev(ad25)
|
||||
mpp61 61 gpio, dev(ad26)
|
||||
mpp62 62 gpio, dev(ad27)
|
||||
mpp63 63 gpio, dev(ad28)
|
||||
mpp64 64 gpio, dev(ad29)
|
||||
mpp65 65 gpio, dev(ad30)
|
||||
mpp66 66 gpio, dev(ad31)
|
||||
|
||||
Notes:
|
||||
* {1} vdd(cpu2-3-pd) only available on mv78460.
|
@ -0,0 +1,72 @@
|
||||
* Marvell Dove SoC pinctrl driver for mpp
|
||||
|
||||
Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
|
||||
part and usage.
|
||||
|
||||
Required properties:
|
||||
- compatible: "marvell,dove-pinctrl"
|
||||
- clocks: (optional) phandle of pdma clock
|
||||
|
||||
Available mpp pins/groups and functions:
|
||||
Note: brackets (x) are not part of the mpp name for marvell,function and given
|
||||
only for more detailed description in this document.
|
||||
|
||||
name pins functions
|
||||
================================================================================
|
||||
mpp0 0 gpio, pmu, uart2(rts), sdio0(cd), lcd0(pwm)
|
||||
mpp1 1 gpio, pmu, uart2(cts), sdio0(wp), lcd1(pwm)
|
||||
mpp2 2 gpio, pmu, uart2(txd), sdio0(buspwr), sata(prsnt),
|
||||
uart1(rts)
|
||||
mpp3 3 gpio, pmu, uart2(rxd), sdio0(ledctrl), sata(act),
|
||||
uart1(cts), lcd-spi(cs1)
|
||||
mpp4 4 gpio, pmu, uart3(rts), sdio1(cd), spi1(miso)
|
||||
mpp5 5 gpio, pmu, uart3(cts), sdio1(wp), spi1(cs)
|
||||
mpp6 6 gpio, pmu, uart3(txd), sdio1(buspwr), spi1(mosi)
|
||||
mpp7 7 gpio, pmu, uart3(rxd), sdio1(ledctrl), spi1(sck)
|
||||
mpp8 8 gpio, pmu, watchdog(rstout)
|
||||
mpp9 9 gpio, pmu, pex1(clkreq)
|
||||
mpp10 10 gpio, pmu, ssp(sclk)
|
||||
mpp11 11 gpio, pmu, sata(prsnt), sata-1(act), sdio0(ledctrl),
|
||||
sdio1(ledctrl), pex0(clkreq)
|
||||
mpp12 12 gpio, pmu, uart2(rts), audio0(extclk), sdio1(cd), sata(act)
|
||||
mpp13 13 gpio, pmu, uart2(cts), audio1(extclk), sdio1(wp),
|
||||
ssp(extclk)
|
||||
mpp14 14 gpio, pmu, uart2(txd), sdio1(buspwr), ssp(rxd)
|
||||
mpp15 15 gpio, pmu, uart2(rxd), sdio1(ledctrl), ssp(sfrm)
|
||||
mpp16 16 gpio, uart3(rts), sdio0(cd), ac97(sdi1), lcd-spi(cs1)
|
||||
mpp17 17 gpio, uart3(cts), sdio0(wp), ac97(sdi2), twsi(sda),
|
||||
ac97-1(sysclko)
|
||||
mpp18 18 gpio, uart3(txd), sdio0(buspwr), ac97(sdi3), lcd0(pwm)
|
||||
mpp19 19 gpio, uart3(rxd), sdio0(ledctrl), twsi(sck)
|
||||
mpp20 20 gpio, sdio0(cd), sdio1(cd), spi1(miso), lcd-spi(miso),
|
||||
ac97(sysclko)
|
||||
mpp21 21 gpio, sdio0(wp), sdio1(wp), spi1(cs), lcd-spi(cs0),
|
||||
uart1(cts), ssp(sfrm)
|
||||
mpp22 22 gpio, sdio0(buspwr), sdio1(buspwr), spi1(mosi),
|
||||
lcd-spi(mosi), uart1(cts), ssp(txd)
|
||||
mpp23 23 gpio, sdio0(ledctrl), sdio1(ledctrl), spi1(sck),
|
||||
lcd-spi(sck), ssp(sclk)
|
||||
mpp_camera 24-39 gpio, camera
|
||||
mpp_sdio0 40-45 gpio, sdio0
|
||||
mpp_sdio1 46-51 gpio, sdio1
|
||||
mpp_audio1 52-57 gpio, i2s1/spdifo, i2s1, spdifo, twsi, ssp/spdifo, ssp,
|
||||
ssp/twsi
|
||||
mpp_spi0 58-61 gpio, spi0
|
||||
mpp_uart1 62-63 gpio, uart1
|
||||
mpp_nand 64-71 gpo, nand
|
||||
audio0 - i2s, ac97
|
||||
twsi - none, opt1, opt2, opt3
|
||||
|
||||
Notes:
|
||||
* group "mpp_audio1" allows the following functions and gpio pins:
|
||||
- gpio : gpio on pins 52-57
|
||||
- i2s1/spdifo : audio1 i2s on pins 52-55 and spdifo on 57, no gpios
|
||||
- i2s1 : audio1 i2s on pins 52-55, gpio on pins 56,57
|
||||
- spdifo : spdifo on pin 57, gpio on pins 52-55
|
||||
- twsi : twsi on pins 56,57, gpio on pins 52-55
|
||||
- ssp/spdifo : ssp on pins 52-55, spdifo on pin 57, no gpios
|
||||
- ssp : ssp on pins 52-55, gpio on pins 56,57
|
||||
- ssp/twsi : ssp on pins 52-55, twsi on pins 56,57, no gpios
|
||||
* group "audio0" internally muxes i2s0 or ac97 controller to the dedicated
|
||||
audio0 pins.
|
||||
* group "twsi" internally muxes twsi controller to the dedicated or option pins.
|
@ -0,0 +1,279 @@
|
||||
* Marvell Kirkwood SoC pinctrl driver for mpp
|
||||
|
||||
Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
|
||||
part and usage.
|
||||
|
||||
Required properties:
|
||||
- compatible: "marvell,88f6180-pinctrl",
|
||||
"marvell,88f6190-pinctrl", "marvell,88f6192-pinctrl",
|
||||
"marvell,88f6281-pinctrl", "marvell,88f6282-pinctrl"
|
||||
|
||||
This driver supports all kirkwood variants, i.e. 88f6180, 88f619x, and 88f628x.
|
||||
|
||||
Available mpp pins/groups and functions:
|
||||
Note: brackets (x) are not part of the mpp name for marvell,function and given
|
||||
only for more detailed description in this document.
|
||||
|
||||
* Marvell Kirkwood 88f6180
|
||||
|
||||
name pins functions
|
||||
================================================================================
|
||||
mpp0 0 gpio, nand(io2), spi(cs)
|
||||
mpp1 1 gpo, nand(io3), spi(mosi)
|
||||
mpp2 2 gpo, nand(io4), spi(sck)
|
||||
mpp3 3 gpo, nand(io5), spi(miso)
|
||||
mpp4 4 gpio, nand(io6), uart0(rxd), ptp(clk)
|
||||
mpp5 5 gpo, nand(io7), uart0(txd), ptp(trig)
|
||||
mpp6 6 sysrst(out), spi(mosi), ptp(trig)
|
||||
mpp7 7 gpo, pex(rsto), spi(cs), ptp(trig)
|
||||
mpp8 8 gpio, twsi0(sda), uart0(rts), uart1(rts), ptp(clk),
|
||||
mii(col)
|
||||
mpp9 9 gpio, twsi(sck), uart0(cts), uart1(cts), ptp(evreq),
|
||||
mii(crs)
|
||||
mpp10 10 gpo, spi(sck), uart0(txd), ptp(trig)
|
||||
mpp11 11 gpio, spi(miso), uart0(rxd), ptp(clk), ptp-1(evreq),
|
||||
ptp-2(trig)
|
||||
mpp12 12 gpo, sdio(clk)
|
||||
mpp13 13 gpio, sdio(cmd), uart1(txd)
|
||||
mpp14 14 gpio, sdio(d0), uart1(rxd), mii(col)
|
||||
mpp15 15 gpio, sdio(d1), uart0(rts), uart1(txd)
|
||||
mpp16 16 gpio, sdio(d2), uart0(cts), uart1(rxd), mii(crs)
|
||||
mpp17 17 gpio, sdio(d3)
|
||||
mpp18 18 gpo, nand(io0)
|
||||
mpp19 19 gpo, nand(io1)
|
||||
mpp20 20 gpio, mii(rxerr)
|
||||
mpp21 21 gpio, audio(spdifi)
|
||||
mpp22 22 gpio, audio(spdifo)
|
||||
mpp23 23 gpio, audio(rmclk)
|
||||
mpp24 24 gpio, audio(bclk)
|
||||
mpp25 25 gpio, audio(sdo)
|
||||
mpp26 26 gpio, audio(lrclk)
|
||||
mpp27 27 gpio, audio(mclk)
|
||||
mpp28 28 gpio, audio(sdi)
|
||||
mpp29 29 gpio, audio(extclk)
|
||||
|
||||
* Marvell Kirkwood 88f6190
|
||||
|
||||
name pins functions
|
||||
================================================================================
|
||||
mpp0 0 gpio, nand(io2), spi(cs)
|
||||
mpp1 1 gpo, nand(io3), spi(mosi)
|
||||
mpp2 2 gpo, nand(io4), spi(sck)
|
||||
mpp3 3 gpo, nand(io5), spi(miso)
|
||||
mpp4 4 gpio, nand(io6), uart0(rxd), ptp(clk)
|
||||
mpp5 5 gpo, nand(io7), uart0(txd), ptp(trig), sata0(act)
|
||||
mpp6 6 sysrst(out), spi(mosi), ptp(trig)
|
||||
mpp7 7 gpo, pex(rsto), spi(cs), ptp(trig)
|
||||
mpp8 8 gpio, twsi0(sda), uart0(rts), uart1(rts), ptp(clk),
|
||||
mii(col), mii-1(rxerr)
|
||||
mpp9 9 gpio, twsi(sck), uart0(cts), uart1(cts), ptp(evreq),
|
||||
mii(crs), sata0(prsnt)
|
||||
mpp10 10 gpo, spi(sck), uart0(txd), ptp(trig)
|
||||
mpp11 11 gpio, spi(miso), uart0(rxd), ptp(clk), ptp-1(evreq),
|
||||
ptp-2(trig), sata0(act)
|
||||
mpp12 12 gpo, sdio(clk)
|
||||
mpp13 13 gpio, sdio(cmd), uart1(txd)
|
||||
mpp14 14 gpio, sdio(d0), uart1(rxd), mii(col)
|
||||
mpp15 15 gpio, sdio(d1), uart0(rts), uart1(txd), sata0(act)
|
||||
mpp16 16 gpio, sdio(d2), uart0(cts), uart1(rxd), mii(crs)
|
||||
mpp17 17 gpio, sdio(d3), sata0(prsnt)
|
||||
mpp18 18 gpo, nand(io0)
|
||||
mpp19 19 gpo, nand(io1)
|
||||
mpp20 20 gpio, ge1(txd0)
|
||||
mpp21 21 gpio, ge1(txd1), sata0(act)
|
||||
mpp22 22 gpio, ge1(txd2)
|
||||
mpp23 23 gpio, ge1(txd3), sata0(prsnt)
|
||||
mpp24 24 gpio, ge1(rxd0)
|
||||
mpp25 25 gpio, ge1(rxd1)
|
||||
mpp26 26 gpio, ge1(rxd2)
|
||||
mpp27 27 gpio, ge1(rxd3)
|
||||
mpp28 28 gpio, ge1(col)
|
||||
mpp29 29 gpio, ge1(txclk)
|
||||
mpp30 30 gpio, ge1(rxclk)
|
||||
mpp31 31 gpio, ge1(rxclk)
|
||||
mpp32 32 gpio, ge1(txclko)
|
||||
mpp33 33 gpo, ge1(txclk)
|
||||
mpp34 34 gpio, ge1(txen)
|
||||
mpp35 35 gpio, ge1(rxerr), sata0(act), mii(rxerr)
|
||||
|
||||
* Marvell Kirkwood 88f6192
|
||||
|
||||
name pins functions
|
||||
================================================================================
|
||||
mpp0 0 gpio, nand(io2), spi(cs)
|
||||
mpp1 1 gpo, nand(io3), spi(mosi)
|
||||
mpp2 2 gpo, nand(io4), spi(sck)
|
||||
mpp3 3 gpo, nand(io5), spi(miso)
|
||||
mpp4 4 gpio, nand(io6), uart0(rxd), ptp(clk), sata1(act)
|
||||
mpp5 5 gpo, nand(io7), uart0(txd), ptp(trig), sata0(act)
|
||||
mpp6 6 sysrst(out), spi(mosi), ptp(trig)
|
||||
mpp7 7 gpo, pex(rsto), spi(cs), ptp(trig)
|
||||
mpp8 8 gpio, twsi0(sda), uart0(rts), uart1(rts), ptp(clk),
|
||||
mii(col), mii-1(rxerr), sata1(prsnt)
|
||||
mpp9 9 gpio, twsi(sck), uart0(cts), uart1(cts), ptp(evreq),
|
||||
mii(crs), sata0(prsnt)
|
||||
mpp10 10 gpo, spi(sck), uart0(txd), ptp(trig), sata1(act)
|
||||
mpp11 11 gpio, spi(miso), uart0(rxd), ptp(clk), ptp-1(evreq),
|
||||
ptp-2(trig), sata0(act)
|
||||
mpp12 12 gpo, sdio(clk)
|
||||
mpp13 13 gpio, sdio(cmd), uart1(txd)
|
||||
mpp14 14 gpio, sdio(d0), uart1(rxd), mii(col), sata1(prsnt)
|
||||
mpp15 15 gpio, sdio(d1), uart0(rts), uart1(txd), sata0(act)
|
||||
mpp16 16 gpio, sdio(d2), uart0(cts), uart1(rxd), mii(crs),
|
||||
sata1(act)
|
||||
mpp17 17 gpio, sdio(d3), sata0(prsnt)
|
||||
mpp18 18 gpo, nand(io0)
|
||||
mpp19 19 gpo, nand(io1)
|
||||
mpp20 20 gpio, ge1(txd0), ts(mp0), tdm(tx0ql), audio(spdifi),
|
||||
sata1(act)
|
||||
mpp21 21 gpio, ge1(txd1), sata0(act), ts(mp1), tdm(rx0ql),
|
||||
audio(spdifo)
|
||||
mpp22 22 gpio, ge1(txd2), ts(mp2), tdm(tx2ql), audio(rmclk),
|
||||
sata1(prsnt)
|
||||
mpp23 23 gpio, ge1(txd3), sata0(prsnt), ts(mp3), tdm(rx2ql),
|
||||
audio(bclk)
|
||||
mpp24 24 gpio, ge1(rxd0), ts(mp4), tdm(spi-cs0), audio(sdo)
|
||||
mpp25 25 gpio, ge1(rxd1), ts(mp5), tdm(spi-sck), audio(lrclk)
|
||||
mpp26 26 gpio, ge1(rxd2), ts(mp6), tdm(spi-miso), audio(mclk)
|
||||
mpp27 27 gpio, ge1(rxd3), ts(mp7), tdm(spi-mosi), audio(sdi)
|
||||
mpp28 28 gpio, ge1(col), ts(mp8), tdm(int), audio(extclk)
|
||||
mpp29 29 gpio, ge1(txclk), ts(mp9), tdm(rst)
|
||||
mpp30 30 gpio, ge1(rxclk), ts(mp10), tdm(pclk)
|
||||
mpp31 31 gpio, ge1(rxclk), ts(mp11), tdm(fs)
|
||||
mpp32 32 gpio, ge1(txclko), ts(mp12), tdm(drx)
|
||||
mpp33 33 gpo, ge1(txclk), tdm(drx)
|
||||
mpp34 34 gpio, ge1(txen), tdm(spi-cs1)
|
||||
mpp35 35 gpio, ge1(rxerr), sata0(act), mii(rxerr), tdm(tx0ql)
|
||||
|
||||
* Marvell Kirkwood 88f6281
|
||||
|
||||
name pins functions
|
||||
================================================================================
|
||||
mpp0 0 gpio, nand(io2), spi(cs)
|
||||
mpp1 1 gpo, nand(io3), spi(mosi)
|
||||
mpp2 2 gpo, nand(io4), spi(sck)
|
||||
mpp3 3 gpo, nand(io5), spi(miso)
|
||||
mpp4 4 gpio, nand(io6), uart0(rxd), ptp(clk), sata1(act)
|
||||
mpp5 5 gpo, nand(io7), uart0(txd), ptp(trig), sata0(act)
|
||||
mpp6 6 sysrst(out), spi(mosi), ptp(trig)
|
||||
mpp7 7 gpo, pex(rsto), spi(cs), ptp(trig)
|
||||
mpp8 8 gpio, twsi0(sda), uart0(rts), uart1(rts), ptp(clk),
|
||||
mii(col), mii-1(rxerr), sata1(prsnt)
|
||||
mpp9 9 gpio, twsi(sck), uart0(cts), uart1(cts), ptp(evreq),
|
||||
mii(crs), sata0(prsnt)
|
||||
mpp10 10 gpo, spi(sck), uart0(txd), ptp(trig), sata1(act)
|
||||
mpp11 11 gpio, spi(miso), uart0(rxd), ptp(clk), ptp-1(evreq),
|
||||
ptp-2(trig), sata0(act)
|
||||
mpp12 12 gpio, sdio(clk)
|
||||
mpp13 13 gpio, sdio(cmd), uart1(txd)
|
||||
mpp14 14 gpio, sdio(d0), uart1(rxd), mii(col), sata1(prsnt)
|
||||
mpp15 15 gpio, sdio(d1), uart0(rts), uart1(txd), sata0(act)
|
||||
mpp16 16 gpio, sdio(d2), uart0(cts), uart1(rxd), mii(crs),
|
||||
sata1(act)
|
||||
mpp17 17 gpio, sdio(d3), sata0(prsnt)
|
||||
mpp18 18 gpo, nand(io0)
|
||||
mpp19 19 gpo, nand(io1)
|
||||
mpp20 20 gpio, ge1(txd0), ts(mp0), tdm(tx0ql), audio(spdifi),
|
||||
sata1(act)
|
||||
mpp21 21 gpio, ge1(txd1), sata0(act), ts(mp1), tdm(rx0ql),
|
||||
audio(spdifo)
|
||||
mpp22 22 gpio, ge1(txd2), ts(mp2), tdm(tx2ql), audio(rmclk),
|
||||
sata1(prsnt)
|
||||
mpp23 23 gpio, ge1(txd3), sata0(prsnt), ts(mp3), tdm(rx2ql),
|
||||
audio(bclk)
|
||||
mpp24 24 gpio, ge1(rxd0), ts(mp4), tdm(spi-cs0), audio(sdo)
|
||||
mpp25 25 gpio, ge1(rxd1), ts(mp5), tdm(spi-sck), audio(lrclk)
|
||||
mpp26 26 gpio, ge1(rxd2), ts(mp6), tdm(spi-miso), audio(mclk)
|
||||
mpp27 27 gpio, ge1(rxd3), ts(mp7), tdm(spi-mosi), audio(sdi)
|
||||
mpp28 28 gpio, ge1(col), ts(mp8), tdm(int), audio(extclk)
|
||||
mpp29 29 gpio, ge1(txclk), ts(mp9), tdm(rst)
|
||||
mpp30 30 gpio, ge1(rxclk), ts(mp10), tdm(pclk)
|
||||
mpp31 31 gpio, ge1(rxclk), ts(mp11), tdm(fs)
|
||||
mpp32 32 gpio, ge1(txclko), ts(mp12), tdm(drx)
|
||||
mpp33 33 gpo, ge1(txclk), tdm(drx)
|
||||
mpp34 34 gpio, ge1(txen), tdm(spi-cs1), sata1(act)
|
||||
mpp35 35 gpio, ge1(rxerr), sata0(act), mii(rxerr), tdm(tx0ql)
|
||||
mpp36 36 gpio, ts(mp0), tdm(spi-cs1), audio(spdifi)
|
||||
mpp37 37 gpio, ts(mp1), tdm(tx2ql), audio(spdifo)
|
||||
mpp38 38 gpio, ts(mp2), tdm(rx2ql), audio(rmclk)
|
||||
mpp39 39 gpio, ts(mp3), tdm(spi-cs0), audio(bclk)
|
||||
mpp40 40 gpio, ts(mp4), tdm(spi-sck), audio(sdo)
|
||||
mpp41 41 gpio, ts(mp5), tdm(spi-miso), audio(lrclk)
|
||||
mpp42 42 gpio, ts(mp6), tdm(spi-mosi), audio(mclk)
|
||||
mpp43 43 gpio, ts(mp7), tdm(int), audio(sdi)
|
||||
mpp44 44 gpio, ts(mp8), tdm(rst), audio(extclk)
|
||||
mpp45 45 gpio, ts(mp9), tdm(pclk)
|
||||
mpp46 46 gpio, ts(mp10), tdm(fs)
|
||||
mpp47 47 gpio, ts(mp11), tdm(drx)
|
||||
mpp48 48 gpio, ts(mp12), tdm(dtx)
|
||||
mpp49 49 gpio, ts(mp9), tdm(rx0ql), ptp(clk)
|
||||
|
||||
* Marvell Kirkwood 88f6282
|
||||
|
||||
name pins functions
|
||||
================================================================================
|
||||
mpp0 0 gpio, nand(io2), spi(cs)
|
||||
mpp1 1 gpo, nand(io3), spi(mosi)
|
||||
mpp2 2 gpo, nand(io4), spi(sck)
|
||||
mpp3 3 gpo, nand(io5), spi(miso)
|
||||
mpp4 4 gpio, nand(io6), uart0(rxd), sata1(act), lcd(hsync)
|
||||
mpp5 5 gpo, nand(io7), uart0(txd), sata0(act), lcd(vsync)
|
||||
mpp6 6 sysrst(out), spi(mosi)
|
||||
mpp7 7 gpo, spi(cs), lcd(pwm)
|
||||
mpp8 8 gpio, twsi0(sda), uart0(rts), uart1(rts), mii(col),
|
||||
mii-1(rxerr), sata1(prsnt)
|
||||
mpp9 9 gpio, twsi(sck), uart0(cts), uart1(cts), mii(crs),
|
||||
sata0(prsnt)
|
||||
mpp10 10 gpo, spi(sck), uart0(txd), sata1(act)
|
||||
mpp11 11 gpio, spi(miso), uart0(rxd), sata0(act)
|
||||
mpp12 12 gpo, sdio(clk), audio(spdifo), spi(mosi), twsi(sda)
|
||||
mpp13 13 gpio, sdio(cmd), uart1(txd), audio(rmclk), lcd(pwm)
|
||||
mpp14 14 gpio, sdio(d0), uart1(rxd), mii(col), sata1(prsnt),
|
||||
audio(spdifi), audio-1(sdi)
|
||||
mpp15 15 gpio, sdio(d1), uart0(rts), uart1(txd), sata0(act),
|
||||
spi(cs)
|
||||
mpp16 16 gpio, sdio(d2), uart0(cts), uart1(rxd), mii(crs),
|
||||
sata1(act), lcd(extclk)
|
||||
mpp17 17 gpio, sdio(d3), sata0(prsnt), sata1(act), twsi1(sck)
|
||||
mpp18 18 gpo, nand(io0), pex(clkreq)
|
||||
mpp19 19 gpo, nand(io1)
|
||||
mpp20 20 gpio, ge1(txd0), ts(mp0), tdm(tx0ql), audio(spdifi),
|
||||
sata1(act), lcd(d0)
|
||||
mpp21 21 gpio, ge1(txd1), sata0(act), ts(mp1), tdm(rx0ql),
|
||||
audio(spdifo), lcd(d1)
|
||||
mpp22 22 gpio, ge1(txd2), ts(mp2), tdm(tx2ql), audio(rmclk),
|
||||
sata1(prsnt), lcd(d2)
|
||||
mpp23 23 gpio, ge1(txd3), sata0(prsnt), ts(mp3), tdm(rx2ql),
|
||||
audio(bclk), lcd(d3)
|
||||
mpp24 24 gpio, ge1(rxd0), ts(mp4), tdm(spi-cs0), audio(sdo),
|
||||
lcd(d4)
|
||||
mpp25 25 gpio, ge1(rxd1), ts(mp5), tdm(spi-sck), audio(lrclk),
|
||||
lcd(d5)
|
||||
mpp26 26 gpio, ge1(rxd2), ts(mp6), tdm(spi-miso), audio(mclk),
|
||||
lcd(d6)
|
||||
mpp27 27 gpio, ge1(rxd3), ts(mp7), tdm(spi-mosi), audio(sdi),
|
||||
lcd(d7)
|
||||
mpp28 28 gpio, ge1(col), ts(mp8), tdm(int), audio(extclk),
|
||||
lcd(d8)
|
||||
mpp29 29 gpio, ge1(txclk), ts(mp9), tdm(rst), lcd(d9)
|
||||
mpp30 30 gpio, ge1(rxclk), ts(mp10), tdm(pclk), lcd(d10)
|
||||
mpp31 31 gpio, ge1(rxclk), ts(mp11), tdm(fs), lcd(d11)
|
||||
mpp32 32 gpio, ge1(txclko), ts(mp12), tdm(drx), lcd(d12)
|
||||
mpp33 33 gpo, ge1(txclk), tdm(drx), lcd(d13)
|
||||
mpp34 34 gpio, ge1(txen), tdm(spi-cs1), sata1(act), lcd(d14)
|
||||
mpp35 35 gpio, ge1(rxerr), sata0(act), mii(rxerr), tdm(tx0ql),
|
||||
lcd(d15)
|
||||
mpp36 36 gpio, ts(mp0), tdm(spi-cs1), audio(spdifi), twsi1(sda)
|
||||
mpp37 37 gpio, ts(mp1), tdm(tx2ql), audio(spdifo), twsi1(sck)
|
||||
mpp38 38 gpio, ts(mp2), tdm(rx2ql), audio(rmclk), lcd(d18)
|
||||
mpp39 39 gpio, ts(mp3), tdm(spi-cs0), audio(bclk), lcd(d19)
|
||||
mpp40 40 gpio, ts(mp4), tdm(spi-sck), audio(sdo), lcd(d20)
|
||||
mpp41 41 gpio, ts(mp5), tdm(spi-miso), audio(lrclk), lcd(d21)
|
||||
mpp42 42 gpio, ts(mp6), tdm(spi-mosi), audio(mclk), lcd(d22)
|
||||
mpp43 43 gpio, ts(mp7), tdm(int), audio(sdi), lcd(d23)
|
||||
mpp44 44 gpio, ts(mp8), tdm(rst), audio(extclk), lcd(clk)
|
||||
mpp45 45 gpio, ts(mp9), tdm(pclk), lcd(e)
|
||||
mpp46 46 gpio, ts(mp10), tdm(fs), lcd(hsync)
|
||||
mpp47 47 gpio, ts(mp11), tdm(drx), lcd(vsync)
|
||||
mpp48 48 gpio, ts(mp12), tdm(dtx), lcd(d16)
|
||||
mpp49 49 gpo, tdm(rx0ql), pex(clkreq), lcd(d17)
|
@ -0,0 +1,46 @@
|
||||
* Marvell SoC pinctrl core driver for mpp
|
||||
|
||||
The pinctrl driver enables Marvell SoCs to configure the multi-purpose pins
|
||||
(mpp) to a specific function. For each SoC family there is a SoC specific
|
||||
driver using this core driver.
|
||||
|
||||
Please refer to pinctrl-bindings.txt in this directory for details of the
|
||||
common pinctrl bindings used by client devices, including the meaning of the
|
||||
phrase "pin configuration node".
|
||||
|
||||
A Marvell SoC pin configuration node is a node of a group of pins which can
|
||||
be used for a specific device or function. Each node requires one or more
|
||||
mpp pins or group of pins and a mpp function common to all pins.
|
||||
|
||||
Required properties for pinctrl driver:
|
||||
- compatible: "marvell,<soc>-pinctrl"
|
||||
Please refer to each marvell,<soc>-pinctrl.txt binding doc for supported SoCs.
|
||||
|
||||
Required properties for pin configuration node:
|
||||
- marvell,pins: string array of mpp pins or group of pins to be muxed.
|
||||
- marvell,function: string representing a function to mux to for all
|
||||
marvell,pins given in this pin configuration node. The function has to be
|
||||
common for all marvell,pins. Please refer to marvell,<soc>-pinctrl.txt for
|
||||
valid pin/pin group names and available function names for each SoC.
|
||||
|
||||
Examples:
|
||||
|
||||
uart1: serial@12100 {
|
||||
compatible = "ns16550a";
|
||||
reg = <0x12100 0x100>;
|
||||
reg-shift = <2>;
|
||||
interrupts = <7>;
|
||||
|
||||
pinctrl-0 = <&pmx_uart1_sw>;
|
||||
pinctrl-names = "default";
|
||||
};
|
||||
|
||||
pinctrl: pinctrl@d0200 {
|
||||
compatible = "marvell,dove-pinctrl";
|
||||
reg = <0xd0200 0x20>;
|
||||
|
||||
pmx_uart1_sw: pmx-uart1-sw {
|
||||
marvell,pins = "mpp_uart1";
|
||||
marvell,function = "uart1";
|
||||
};
|
||||
};
|
21
Documentation/devicetree/bindings/sound/cs4270.txt
Normal file
21
Documentation/devicetree/bindings/sound/cs4270.txt
Normal file
@ -0,0 +1,21 @@
|
||||
CS4270 audio CODEC
|
||||
|
||||
The driver for this device currently only supports I2C.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "cirrus,cs4270"
|
||||
|
||||
- reg : the I2C address of the device for I2C
|
||||
|
||||
Optional properties:
|
||||
|
||||
- reset-gpio : a GPIO spec for the reset pin. If specified, it will be
|
||||
deasserted before communication to the codec starts.
|
||||
|
||||
Example:
|
||||
|
||||
codec: cs4270@48 {
|
||||
compatible = "cirrus,cs4270";
|
||||
reg = <0x48>;
|
||||
};
|
36
Documentation/devicetree/bindings/sound/cs4271.txt
Normal file
36
Documentation/devicetree/bindings/sound/cs4271.txt
Normal file
@ -0,0 +1,36 @@
|
||||
Cirrus Logic CS4271 DT bindings
|
||||
|
||||
This driver supports both the I2C and the SPI bus.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: "cirrus,cs4271"
|
||||
|
||||
For required properties on SPI, please consult
|
||||
Documentation/devicetree/bindings/spi/spi-bus.txt
|
||||
|
||||
Required properties on I2C:
|
||||
|
||||
- reg: the i2c address
|
||||
|
||||
|
||||
Optional properties:
|
||||
|
||||
- reset-gpio: a GPIO spec to define which pin is connected to the chip's
|
||||
!RESET pin
|
||||
|
||||
Examples:
|
||||
|
||||
codec_i2c: cs4271@10 {
|
||||
compatible = "cirrus,cs4271";
|
||||
reg = <0x10>;
|
||||
reset-gpio = <&gpio 23 0>;
|
||||
};
|
||||
|
||||
codec_spi: cs4271@0 {
|
||||
compatible = "cirrus,cs4271";
|
||||
reg = <0x0>;
|
||||
reset-gpio = <&gpio 23 0>;
|
||||
spi-max-frequency = <6000000>;
|
||||
};
|
||||
|
@ -0,0 +1,45 @@
|
||||
Texas Instruments McASP controller
|
||||
|
||||
Required properties:
|
||||
- compatible :
|
||||
"ti,dm646x-mcasp-audio" : for DM646x platforms
|
||||
"ti,da830-mcasp-audio" : for both DA830 & DA850 platforms
|
||||
"ti,omap2-mcasp-audio" : for OMAP2 platforms (TI81xx, AM33xx)
|
||||
|
||||
- reg : Should contain McASP registers offset and length
|
||||
- interrupts : Interrupt number for McASP
|
||||
- op-mode : I2S/DIT ops mode.
|
||||
- tdm-slots : Slots for TDM operation.
|
||||
- num-serializer : Serializers used by McASP.
|
||||
- serial-dir : A list of serializer pin mode. The list number should be equal
|
||||
to "num-serializer" parameter. Each entry is a number indication
|
||||
serializer pin direction. (0 - INACTIVE, 1 - TX, 2 - RX)
|
||||
|
||||
|
||||
Optional properties:
|
||||
|
||||
- ti,hwmods : Must be "mcasp<n>", n is controller instance starting 0
|
||||
- tx-num-evt : FIFO levels.
|
||||
- rx-num-evt : FIFO levels.
|
||||
- sram-size-playback : size of sram to be allocated during playback
|
||||
- sram-size-capture : size of sram to be allocated during capture
|
||||
|
||||
Example:
|
||||
|
||||
mcasp0: mcasp0@1d00000 {
|
||||
compatible = "ti,da830-mcasp-audio";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0x100000 0x3000>;
|
||||
interrupts = <82 83>;
|
||||
op-mode = <0>; /* MCASP_IIS_MODE */
|
||||
tdm-slots = <2>;
|
||||
num-serializer = <16>;
|
||||
serial-dir = <
|
||||
0 0 0 0 /* 0: INACTIVE, 1: TX, 2: RX */
|
||||
0 0 0 0
|
||||
0 0 0 1
|
||||
2 0 0 0 >;
|
||||
tx-num-evt = <1>;
|
||||
rx-num-evt = <1>;
|
||||
};
|
91
Documentation/devicetree/bindings/sound/omap-abe-twl6040.txt
Normal file
91
Documentation/devicetree/bindings/sound/omap-abe-twl6040.txt
Normal file
@ -0,0 +1,91 @@
|
||||
* Texas Instruments OMAP4+ and twl6040 based audio setups
|
||||
|
||||
Required properties:
|
||||
- compatible: "ti,abe-twl6040"
|
||||
- ti,model: Name of the sound card ( for example "SDP4430")
|
||||
- ti,mclk-freq: MCLK frequency for HPPLL operation
|
||||
- ti,mcpdm: phandle for the McPDM node
|
||||
- ti,twl6040: phandle for the twl6040 core node
|
||||
- ti,audio-routing: List of connections between audio components.
|
||||
Each entry is a pair of strings, the first being the connection's sink,
|
||||
the second being the connection's source.
|
||||
|
||||
Optional properties:
|
||||
- ti,dmic: phandle for the OMAP dmic node if the machine have it connected
|
||||
- ti,jack_detection: Need to be set to <1> if the board capable to detect jack
|
||||
insertion, removal.
|
||||
|
||||
Available audio endpoints for the audio-routing table:
|
||||
|
||||
Board connectors:
|
||||
* Headset Stereophone
|
||||
* Earphone Spk
|
||||
* Ext Spk
|
||||
* Line Out
|
||||
* Vibrator
|
||||
* Headset Mic
|
||||
* Main Handset Mic
|
||||
* Sub Handset Mic
|
||||
* Line In
|
||||
* Digital Mic
|
||||
|
||||
twl6040 pins:
|
||||
* HSOL
|
||||
* HSOR
|
||||
* EP
|
||||
* HFL
|
||||
* HFR
|
||||
* AUXL
|
||||
* AUXR
|
||||
* VIBRAL
|
||||
* VIBRAR
|
||||
* HSMIC
|
||||
* MAINMIC
|
||||
* SUBMIC
|
||||
* AFML
|
||||
* AFMR
|
||||
|
||||
* Headset Mic Bias
|
||||
* Main Mic Bias
|
||||
* Digital Mic1 Bias
|
||||
* Digital Mic2 Bias
|
||||
|
||||
Digital mic pins:
|
||||
* DMic
|
||||
|
||||
Example:
|
||||
|
||||
sound {
|
||||
compatible = "ti,abe-twl6040";
|
||||
ti,model = "SDP4430";
|
||||
|
||||
ti,jack-detection = <1>;
|
||||
ti,mclk-freq = <38400000>;
|
||||
|
||||
ti,mcpdm = <&mcpdm>;
|
||||
ti,dmic = <&dmic>;
|
||||
|
||||
ti,twl6040 = <&twl6040>;
|
||||
|
||||
/* Audio routing */
|
||||
ti,audio-routing =
|
||||
"Headset Stereophone", "HSOL",
|
||||
"Headset Stereophone", "HSOR",
|
||||
"Earphone Spk", "EP",
|
||||
"Ext Spk", "HFL",
|
||||
"Ext Spk", "HFR",
|
||||
"Line Out", "AUXL",
|
||||
"Line Out", "AUXR",
|
||||
"Vibrator", "VIBRAL",
|
||||
"Vibrator", "VIBRAR",
|
||||
"HSMIC", "Headset Mic",
|
||||
"Headset Mic", "Headset Mic Bias",
|
||||
"MAINMIC", "Main Handset Mic",
|
||||
"Main Handset Mic", "Main Mic Bias",
|
||||
"SUBMIC", "Sub Handset Mic",
|
||||
"Sub Handset Mic", "Main Mic Bias",
|
||||
"AFML", "Line In",
|
||||
"AFMR", "Line In",
|
||||
"DMic", "Digital Mic",
|
||||
"Digital Mic", "Digital Mic1 Bias";
|
||||
};
|
37
Documentation/devicetree/bindings/sound/omap-mcbsp.txt
Normal file
37
Documentation/devicetree/bindings/sound/omap-mcbsp.txt
Normal file
@ -0,0 +1,37 @@
|
||||
* Texas Instruments OMAP2+ McBSP module
|
||||
|
||||
Required properties:
|
||||
- compatible: "ti,omap2420-mcbsp" for McBSP on OMAP2420
|
||||
"ti,omap2430-mcbsp" for McBSP on OMAP2430
|
||||
"ti,omap3-mcbsp" for McBSP on OMAP3
|
||||
"ti,omap4-mcbsp" for McBSP on OMAP4 and newer SoC
|
||||
- reg: Register location and size, for OMAP4+ as an array:
|
||||
<MPU access base address, size>,
|
||||
<L3 interconnect address, size>;
|
||||
- reg-names: Array of strings associated with the address space
|
||||
- interrupts: Interrupt numbers for the McBSP port, as an array in case the
|
||||
McBSP IP have more interrupt lines:
|
||||
<OCP compliant irq>,
|
||||
<TX irq>,
|
||||
<RX irq>;
|
||||
- interrupt-names: Array of strings associated with the interrupt numbers
|
||||
- interrupt-parent: The parent interrupt controller
|
||||
- ti,buffer-size: Size of the FIFO on the port (OMAP2430 and newer SoC)
|
||||
- ti,hwmods: Name of the hwmod associated to the McBSP port
|
||||
|
||||
Example:
|
||||
|
||||
mcbsp2: mcbsp@49022000 {
|
||||
compatible = "ti,omap3-mcbsp";
|
||||
reg = <0x49022000 0xff>,
|
||||
<0x49028000 0xff>;
|
||||
reg-names = "mpu", "sidetone";
|
||||
interrupts = <0 17 0x4>, /* OCP compliant interrupt */
|
||||
<0 62 0x4>, /* TX interrupt */
|
||||
<0 63 0x4>, /* RX interrupt */
|
||||
<0 4 0x4>; /* Sidetone */
|
||||
interrupt-names = "common", "tx", "rx", "sidetone";
|
||||
interrupt-parent = <&intc>;
|
||||
ti,buffer-size = <1280>;
|
||||
ti,hwmods = "mcbsp2";
|
||||
};
|
17
Documentation/devicetree/bindings/sound/omap-twl4030.txt
Normal file
17
Documentation/devicetree/bindings/sound/omap-twl4030.txt
Normal file
@ -0,0 +1,17 @@
|
||||
* Texas Instruments SoC with twl4030 based audio setups
|
||||
|
||||
Required properties:
|
||||
- compatible: "ti,omap-twl4030"
|
||||
- ti,model: Name of the sound card (for example "omap3beagle")
|
||||
- ti,mcbsp: phandle for the McBSP node
|
||||
- ti,codec: phandle for the twl4030 audio node
|
||||
|
||||
Example:
|
||||
|
||||
sound {
|
||||
compatible = "ti,omap-twl4030";
|
||||
ti,model = "omap3beagle";
|
||||
|
||||
ti,mcbsp = <&mcbsp2>;
|
||||
ti,codec = <&twl_audio>;
|
||||
};
|
20
Documentation/devicetree/bindings/sound/tlv320aic3x.txt
Normal file
20
Documentation/devicetree/bindings/sound/tlv320aic3x.txt
Normal file
@ -0,0 +1,20 @@
|
||||
Texas Instruments - tlv320aic3x Codec module
|
||||
|
||||
The tlv320aic3x serial control bus communicates through I2C protocols
|
||||
|
||||
Required properties:
|
||||
- compatible - "string" - "ti,tlv320aic3x"
|
||||
- reg - <int> - I2C slave address
|
||||
|
||||
|
||||
Optional properties:
|
||||
|
||||
- gpio-reset - gpio pin number used for codec reset
|
||||
- ai3x-gpio-func - <array of 2 int> - AIC3X_GPIO1 & AIC3X_GPIO2 Functionality
|
||||
|
||||
Example:
|
||||
|
||||
tlv320aic3x: tlv320aic3x@1b {
|
||||
compatible = "ti,tlv320aic3x";
|
||||
reg = <0x1b>;
|
||||
};
|
33
Documentation/devicetree/bindings/spi/spi-octeon.txt
Normal file
33
Documentation/devicetree/bindings/spi/spi-octeon.txt
Normal file
@ -0,0 +1,33 @@
|
||||
Cavium, Inc. OCTEON SOC SPI master controller.
|
||||
|
||||
Required properties:
|
||||
- compatible : "cavium,octeon-3010-spi"
|
||||
- reg : The register base for the controller.
|
||||
- interrupts : One interrupt, used by the controller.
|
||||
- #address-cells : <1>, as required by generic SPI binding.
|
||||
- #size-cells : <0>, also as required by generic SPI binding.
|
||||
|
||||
Child nodes as per the generic SPI binding.
|
||||
|
||||
Example:
|
||||
|
||||
spi@1070000001000 {
|
||||
compatible = "cavium,octeon-3010-spi";
|
||||
reg = <0x10700 0x00001000 0x0 0x100>;
|
||||
interrupts = <0 58>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
eeprom@0 {
|
||||
compatible = "st,m95256", "atmel,at25";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <5000000>;
|
||||
spi-cpha;
|
||||
spi-cpol;
|
||||
|
||||
pagesize = <64>;
|
||||
size = <32768>;
|
||||
address-width = <16>;
|
||||
};
|
||||
};
|
||||
|
@ -30,7 +30,7 @@ with the device via the bus. The connection between the DVB-API-functionality
|
||||
is done via callbacks, assigned in a static device-description (struct
|
||||
dvb_usb_device) each device-driver has to have.
|
||||
|
||||
For an example have a look in drivers/media/dvb/dvb-usb/vp7045*.
|
||||
For an example have a look in drivers/media/usb/dvb-usb/vp7045*.
|
||||
|
||||
Objective is to migrate all the usb-devices (dibusb, cinergyT2, maybe the
|
||||
ttusb; flexcop-usb already benefits from the generic flexcop-device) to use
|
||||
|
@ -116,7 +116,7 @@ sub tda10045 {
|
||||
|
||||
sub tda10046 {
|
||||
my $sourcefile = "TT_PCI_2.19h_28_11_2006.zip";
|
||||
my $url = "http://www.tt-download.com/download/updates/219/$sourcefile";
|
||||
my $url = "http://technotrend.com.ua/download/software/219/$sourcefile";
|
||||
my $hash = "6a7e1e2f2644b162ff0502367553c72d";
|
||||
my $outfile = "dvb-fe-tda10046.fw";
|
||||
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
|
||||
|
@ -375,6 +375,16 @@ dioread_nolock locking. If the dioread_nolock option is specified
|
||||
Because of the restrictions this options comprises
|
||||
it is off by default (e.g. dioread_lock).
|
||||
|
||||
max_dir_size_kb=n This limits the size of directories so that any
|
||||
attempt to expand them beyond the specified
|
||||
limit in kilobytes will cause an ENOSPC error.
|
||||
This is useful in memory constrained
|
||||
environments, where a very large directory can
|
||||
cause severe performance problems or even
|
||||
provoke the Out Of Memory killer. (For example,
|
||||
if there is only 512mb memory available, a 176mb
|
||||
directory may seriously cramp the system's style.)
|
||||
|
||||
i_version Enable 64-bit inode version support. This option is
|
||||
off by default.
|
||||
|
||||
|
@ -33,7 +33,7 @@ Table of Contents
|
||||
2 Modifying System Parameters
|
||||
|
||||
3 Per-Process Parameters
|
||||
3.1 /proc/<pid>/oom_adj & /proc/<pid>/oom_score_adj - Adjust the oom-killer
|
||||
3.1 /proc/<pid>/oom_score_adj - Adjust the oom-killer
|
||||
score
|
||||
3.2 /proc/<pid>/oom_score - Display current oom-killer score
|
||||
3.3 /proc/<pid>/io - Display the IO accounting fields
|
||||
@ -1320,10 +1320,10 @@ of the kernel.
|
||||
CHAPTER 3: PER-PROCESS PARAMETERS
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
3.1 /proc/<pid>/oom_adj & /proc/<pid>/oom_score_adj- Adjust the oom-killer score
|
||||
3.1 /proc/<pid>/oom_score_adj- Adjust the oom-killer score
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
These file can be used to adjust the badness heuristic used to select which
|
||||
This file can be used to adjust the badness heuristic used to select which
|
||||
process gets killed in out of memory conditions.
|
||||
|
||||
The badness heuristic assigns a value to each candidate task ranging from 0
|
||||
@ -1361,22 +1361,10 @@ same system, cpuset, mempolicy, or memory controller resources to use at least
|
||||
equivalent to discounting 50% of the task's allowed memory from being considered
|
||||
as scoring against the task.
|
||||
|
||||
For backwards compatibility with previous kernels, /proc/<pid>/oom_adj may also
|
||||
be used to tune the badness score. Its acceptable values range from -16
|
||||
(OOM_ADJUST_MIN) to +15 (OOM_ADJUST_MAX) and a special value of -17
|
||||
(OOM_DISABLE) to disable oom killing entirely for that task. Its value is
|
||||
scaled linearly with /proc/<pid>/oom_score_adj.
|
||||
|
||||
Writing to /proc/<pid>/oom_score_adj or /proc/<pid>/oom_adj will change the
|
||||
other with its scaled value.
|
||||
|
||||
The value of /proc/<pid>/oom_score_adj may be reduced no lower than the last
|
||||
value set by a CAP_SYS_RESOURCE process. To reduce the value any lower
|
||||
requires CAP_SYS_RESOURCE.
|
||||
|
||||
NOTICE: /proc/<pid>/oom_adj is deprecated and will be removed, please see
|
||||
Documentation/feature-removal-schedule.txt.
|
||||
|
||||
Caveat: when a parent task is selected, the oom killer will sacrifice any first
|
||||
generation children with separate address spaces instead, if possible. This
|
||||
avoids servers and important system daemons from being killed and loses the
|
||||
@ -1387,9 +1375,7 @@ minimal amount of work.
|
||||
-------------------------------------------------------------
|
||||
|
||||
This file can be used to check the current score used by the oom-killer is for
|
||||
any given <pid>. Use it together with /proc/<pid>/oom_adj to tune which
|
||||
process should be killed in an out-of-memory situation.
|
||||
|
||||
any given <pid>.
|
||||
|
||||
3.3 /proc/<pid>/io - Display the IO accounting fields
|
||||
-------------------------------------------------------
|
||||
|
@ -20,7 +20,10 @@ Supported adapters:
|
||||
Datasheet: available on http://linux.via.com.tw
|
||||
|
||||
* VIA Technologies, Inc. VX855/VX875
|
||||
Datasheet: Availability unknown
|
||||
Datasheet: available on http://linux.via.com.tw
|
||||
|
||||
* VIA Technologies, Inc. VX900
|
||||
Datasheet: available on http://linux.via.com.tw
|
||||
|
||||
Authors:
|
||||
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
||||
@ -57,6 +60,7 @@ Your lspci -n listing must show one of these :
|
||||
device 1106:8324 (CX700)
|
||||
device 1106:8353 (VX800/VX820)
|
||||
device 1106:8409 (VX855/VX875)
|
||||
device 1106:8410 (VX900)
|
||||
|
||||
If none of these show up, you should look in the BIOS for settings like
|
||||
enable ACPI / SMBus or even USB.
|
||||
|
@ -63,3 +63,21 @@ static struct platform_device myboard_i2cmux = {
|
||||
.platform_data = &myboard_i2cmux_data,
|
||||
},
|
||||
};
|
||||
|
||||
If you don't know the absolute GPIO pin numbers at registration time,
|
||||
you can instead provide a chip name (.chip_name) and relative GPIO pin
|
||||
numbers, and the i2c-gpio-mux driver will do the work for you,
|
||||
including deferred probing if the GPIO chip isn't immediately
|
||||
available.
|
||||
|
||||
Device Registration
|
||||
-------------------
|
||||
|
||||
When registering your i2c-gpio-mux device, you should pass the number
|
||||
of any GPIO pin it uses as the device ID. This guarantees that every
|
||||
instance has a different ID.
|
||||
|
||||
Alternatively, if you don't need a stable device name, you can simply
|
||||
pass PLATFORM_DEVID_AUTO as the device ID, and the platform core will
|
||||
assign a dynamic ID to your device. If you do not know the absolute
|
||||
GPIO pin numbers at registration time, this is even the only option.
|
||||
|
@ -178,7 +178,6 @@ Code Seq#(hex) Include File Comments
|
||||
'V' C0 linux/ivtv.h conflict!
|
||||
'V' C0 media/davinci/vpfe_capture.h conflict!
|
||||
'V' C0 media/si4713.h conflict!
|
||||
'V' C0-CF drivers/media/video/mxb.h conflict!
|
||||
'W' 00-1F linux/watchdog.h conflict!
|
||||
'W' 00-1F linux/wanrouter.h conflict!
|
||||
'W' 00-3F sound/asound.h conflict!
|
||||
@ -204,8 +203,6 @@ Code Seq#(hex) Include File Comments
|
||||
'c' A0-AF arch/x86/include/asm/msr.h conflict!
|
||||
'd' 00-FF linux/char/drm/drm/h conflict!
|
||||
'd' 02-40 pcmcia/ds.h conflict!
|
||||
'd' 10-3F drivers/media/video/dabusb.h conflict!
|
||||
'd' C0-CF drivers/media/video/saa7191.h conflict!
|
||||
'd' F0-FF linux/digi1.h
|
||||
'e' all linux/digi1.h conflict!
|
||||
'e' 00-1F drivers/net/irda/irtty-sir.h conflict!
|
||||
@ -267,9 +264,7 @@ Code Seq#(hex) Include File Comments
|
||||
'v' 00-1F linux/ext2_fs.h conflict!
|
||||
'v' 00-1F linux/fs.h conflict!
|
||||
'v' 00-0F linux/sonypi.h conflict!
|
||||
'v' C0-DF media/pwc-ioctl.h conflict!
|
||||
'v' C0-FF linux/meye.h conflict!
|
||||
'v' D0-DF drivers/media/video/cpia2/cpia2dev.h conflict!
|
||||
'w' all CERN SCI driver
|
||||
'y' 00-1F packet based user level communications
|
||||
<mailto:zapman@interlan.net>
|
||||
|
@ -1,33 +0,0 @@
|
||||
There are several classic problems related to memory on Linux
|
||||
systems.
|
||||
|
||||
1) There are some motherboards that will not cache above
|
||||
a certain quantity of memory. If you have one of these
|
||||
motherboards, your system will be SLOWER, not faster
|
||||
as you add more memory. Consider exchanging your
|
||||
motherboard.
|
||||
|
||||
All of these problems can be addressed with the "mem=XXXM" boot option
|
||||
(where XXX is the size of RAM to use in megabytes).
|
||||
It can also tell Linux to use less memory than is actually installed.
|
||||
If you use "mem=" on a machine with PCI, consider using "memmap=" to avoid
|
||||
physical address space collisions.
|
||||
|
||||
See the documentation of your boot loader (LILO, grub, loadlin, etc.) about
|
||||
how to pass options to the kernel.
|
||||
|
||||
There are other memory problems which Linux cannot deal with. Random
|
||||
corruption of memory is usually a sign of serious hardware trouble.
|
||||
Try:
|
||||
|
||||
* Reducing memory settings in the BIOS to the most conservative
|
||||
timings.
|
||||
|
||||
* Adding a cooling fan.
|
||||
|
||||
* Not overclocking your CPU.
|
||||
|
||||
* Having the memory tested in a memory tester or exchanged
|
||||
with the vendor. Consider testing it with memtest86 yourself.
|
||||
|
||||
* Exchanging your CPU, cache, or motherboard for one that works.
|
@ -81,6 +81,9 @@ This defines trickle and fast charges. For batteries that
|
||||
are already charged or discharging, 'n/a' can be displayed (or
|
||||
'unknown', if the status is not known).
|
||||
|
||||
AUTHENTIC - indicates the power supply (battery or charger) connected
|
||||
to the platform is authentic(1) or non authentic(0).
|
||||
|
||||
HEALTH - represents health of the battery, values corresponds to
|
||||
POWER_SUPPLY_HEALTH_*, defined in battery.h.
|
||||
|
||||
@ -113,8 +116,12 @@ be negative; there is no empty or full value. It is only useful for
|
||||
relative, time-based measurements.
|
||||
|
||||
CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger.
|
||||
CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by the
|
||||
power supply object.
|
||||
|
||||
CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
|
||||
CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the
|
||||
power supply object.
|
||||
|
||||
ENERGY_FULL, ENERGY_EMPTY - same as above but for energy.
|
||||
|
||||
|
@ -1,107 +0,0 @@
|
||||
The prio_tree.c code indexes vmas using 3 different indexes:
|
||||
* heap_index = vm_pgoff + vm_size_in_pages : end_vm_pgoff
|
||||
* radix_index = vm_pgoff : start_vm_pgoff
|
||||
* size_index = vm_size_in_pages
|
||||
|
||||
A regular radix-priority-search-tree indexes vmas using only heap_index and
|
||||
radix_index. The conditions for indexing are:
|
||||
* ->heap_index >= ->left->heap_index &&
|
||||
->heap_index >= ->right->heap_index
|
||||
* if (->heap_index == ->left->heap_index)
|
||||
then ->radix_index < ->left->radix_index;
|
||||
* if (->heap_index == ->right->heap_index)
|
||||
then ->radix_index < ->right->radix_index;
|
||||
* nodes are hashed to left or right subtree using radix_index
|
||||
similar to a pure binary radix tree.
|
||||
|
||||
A regular radix-priority-search-tree helps to store and query
|
||||
intervals (vmas). However, a regular radix-priority-search-tree is only
|
||||
suitable for storing vmas with different radix indices (vm_pgoff).
|
||||
|
||||
Therefore, the prio_tree.c extends the regular radix-priority-search-tree
|
||||
to handle many vmas with the same vm_pgoff. Such vmas are handled in
|
||||
2 different ways: 1) All vmas with the same radix _and_ heap indices are
|
||||
linked using vm_set.list, 2) if there are many vmas with the same radix
|
||||
index, but different heap indices and if the regular radix-priority-search
|
||||
tree cannot index them all, we build an overflow-sub-tree that indexes such
|
||||
vmas using heap and size indices instead of heap and radix indices. For
|
||||
example, in the figure below some vmas with vm_pgoff = 0 (zero) are
|
||||
indexed by regular radix-priority-search-tree whereas others are pushed
|
||||
into an overflow-subtree. Note that all vmas in an overflow-sub-tree have
|
||||
the same vm_pgoff (radix_index) and if necessary we build different
|
||||
overflow-sub-trees to handle each possible radix_index. For example,
|
||||
in figure we have 3 overflow-sub-trees corresponding to radix indices
|
||||
0, 2, and 4.
|
||||
|
||||
In the final tree the first few (prio_tree_root->index_bits) levels
|
||||
are indexed using heap and radix indices whereas the overflow-sub-trees below
|
||||
those levels (i.e. levels prio_tree_root->index_bits + 1 and higher) are
|
||||
indexed using heap and size indices. In overflow-sub-trees the size_index
|
||||
is used for hashing the nodes to appropriate places.
|
||||
|
||||
Now, an example prio_tree:
|
||||
|
||||
vmas are represented [radix_index, size_index, heap_index]
|
||||
i.e., [start_vm_pgoff, vm_size_in_pages, end_vm_pgoff]
|
||||
|
||||
level prio_tree_root->index_bits = 3
|
||||
-----
|
||||
_
|
||||
0 [0,7,7] |
|
||||
/ \ |
|
||||
------------------ ------------ | Regular
|
||||
/ \ | radix priority
|
||||
1 [1,6,7] [4,3,7] | search tree
|
||||
/ \ / \ |
|
||||
------- ----- ------ ----- | heap-and-radix
|
||||
/ \ / \ | indexed
|
||||
2 [0,6,6] [2,5,7] [5,2,7] [6,1,7] |
|
||||
/ \ / \ / \ / \ |
|
||||
3 [0,5,5] [1,5,6] [2,4,6] [3,4,7] [4,2,6] [5,1,6] [6,0,6] [7,0,7] |
|
||||
/ / / _
|
||||
/ / / _
|
||||
4 [0,4,4] [2,3,5] [4,1,5] |
|
||||
/ / / |
|
||||
5 [0,3,3] [2,2,4] [4,0,4] | Overflow-sub-trees
|
||||
/ / |
|
||||
6 [0,2,2] [2,1,3] | heap-and-size
|
||||
/ / | indexed
|
||||
7 [0,1,1] [2,0,2] |
|
||||
/ |
|
||||
8 [0,0,0] |
|
||||
_
|
||||
|
||||
Note that we use prio_tree_root->index_bits to optimize the height
|
||||
of the heap-and-radix indexed tree. Since prio_tree_root->index_bits is
|
||||
set according to the maximum end_vm_pgoff mapped, we are sure that all
|
||||
bits (in vm_pgoff) above prio_tree_root->index_bits are 0 (zero). Therefore,
|
||||
we only use the first prio_tree_root->index_bits as radix_index.
|
||||
Whenever index_bits is increased in prio_tree_expand, we shuffle the tree
|
||||
to make sure that the first prio_tree_root->index_bits levels of the tree
|
||||
is indexed properly using heap and radix indices.
|
||||
|
||||
We do not optimize the height of overflow-sub-trees using index_bits.
|
||||
The reason is: there can be many such overflow-sub-trees and all of
|
||||
them have to be suffled whenever the index_bits increases. This may involve
|
||||
walking the whole prio_tree in prio_tree_insert->prio_tree_expand code
|
||||
path which is not desirable. Hence, we do not optimize the height of the
|
||||
heap-and-size indexed overflow-sub-trees using prio_tree->index_bits.
|
||||
Instead the overflow sub-trees are indexed using full BITS_PER_LONG bits
|
||||
of size_index. This may lead to skewed sub-trees because most of the
|
||||
higher significant bits of the size_index are likely to be 0 (zero). In
|
||||
the example above, all 3 overflow-sub-trees are skewed. This may marginally
|
||||
affect the performance. However, processes rarely map many vmas with the
|
||||
same start_vm_pgoff but different end_vm_pgoffs. Therefore, we normally
|
||||
do not require overflow-sub-trees to index all vmas.
|
||||
|
||||
From the above discussion it is clear that the maximum height of
|
||||
a prio_tree can be prio_tree_root->index_bits + BITS_PER_LONG.
|
||||
However, in most of the common cases we do not need overflow-sub-trees,
|
||||
so the tree height in the common cases will be prio_tree_root->index_bits.
|
||||
|
||||
It is fair to mention here that the prio_tree_root->index_bits
|
||||
is increased on demand, however, the index_bits is not decreased when
|
||||
vmas are removed from the prio_tree. That's tricky to do. Hence, it's
|
||||
left as a home work problem.
|
||||
|
||||
|
@ -102,9 +102,7 @@ related hangs. The functions call chain log is stored in a "ftrace-ramoops"
|
||||
file. Here is an example of usage:
|
||||
|
||||
# mount -t debugfs debugfs /sys/kernel/debug/
|
||||
# cd /sys/kernel/debug/tracing
|
||||
# echo function > current_tracer
|
||||
# echo 1 > options/func_pstore
|
||||
# echo 1 > /sys/kernel/debug/pstore/record_ftrace
|
||||
# reboot -f
|
||||
[...]
|
||||
# mount -t pstore pstore /mnt/
|
||||
|
@ -193,24 +193,55 @@ Example:
|
||||
Support for Augmented rbtrees
|
||||
-----------------------------
|
||||
|
||||
Augmented rbtree is an rbtree with "some" additional data stored in each node.
|
||||
This data can be used to augment some new functionality to rbtree.
|
||||
Augmented rbtree is an optional feature built on top of basic rbtree
|
||||
infrastructure. An rbtree user who wants this feature will have to call the
|
||||
augmentation functions with the user provided augmentation callback
|
||||
when inserting and erasing nodes.
|
||||
Augmented rbtree is an rbtree with "some" additional data stored in
|
||||
each node, where the additional data for node N must be a function of
|
||||
the contents of all nodes in the subtree rooted at N. This data can
|
||||
be used to augment some new functionality to rbtree. Augmented rbtree
|
||||
is an optional feature built on top of basic rbtree infrastructure.
|
||||
An rbtree user who wants this feature will have to call the augmentation
|
||||
functions with the user provided augmentation callback when inserting
|
||||
and erasing nodes.
|
||||
|
||||
On insertion, the user must call rb_augment_insert() once the new node is in
|
||||
place. This will cause the augmentation function callback to be called for
|
||||
each node between the new node and the root which has been affected by the
|
||||
insertion.
|
||||
C files implementing augmented rbtree manipulation must include
|
||||
<linux/rbtree_augmented.h> instead of <linus/rbtree.h>. Note that
|
||||
linux/rbtree_augmented.h exposes some rbtree implementations details
|
||||
you are not expected to rely on; please stick to the documented APIs
|
||||
there and do not include <linux/rbtree_augmented.h> from header files
|
||||
either so as to minimize chances of your users accidentally relying on
|
||||
such implementation details.
|
||||
|
||||
When erasing a node, the user must call rb_augment_erase_begin() first to
|
||||
retrieve the deepest node on the rebalance path. Then, after erasing the
|
||||
original node, the user must call rb_augment_erase_end() with the deepest
|
||||
node found earlier. This will cause the augmentation function to be called
|
||||
for each affected node between the deepest node and the root.
|
||||
On insertion, the user must update the augmented information on the path
|
||||
leading to the inserted node, then call rb_link_node() as usual and
|
||||
rb_augment_inserted() instead of the usual rb_insert_color() call.
|
||||
If rb_augment_inserted() rebalances the rbtree, it will callback into
|
||||
a user provided function to update the augmented information on the
|
||||
affected subtrees.
|
||||
|
||||
When erasing a node, the user must call rb_erase_augmented() instead of
|
||||
rb_erase(). rb_erase_augmented() calls back into user provided functions
|
||||
to updated the augmented information on affected subtrees.
|
||||
|
||||
In both cases, the callbacks are provided through struct rb_augment_callbacks.
|
||||
3 callbacks must be defined:
|
||||
|
||||
- A propagation callback, which updates the augmented value for a given
|
||||
node and its ancestors, up to a given stop point (or NULL to update
|
||||
all the way to the root).
|
||||
|
||||
- A copy callback, which copies the augmented value for a given subtree
|
||||
to a newly assigned subtree root.
|
||||
|
||||
- A tree rotation callback, which copies the augmented value for a given
|
||||
subtree to a newly assigned subtree root AND recomputes the augmented
|
||||
information for the former subtree root.
|
||||
|
||||
The compiled code for rb_erase_augmented() may inline the propagation and
|
||||
copy callbacks, which results in a large function, so each augmented rbtree
|
||||
user should have a single rb_erase_augmented() call site in order to limit
|
||||
compiled code size.
|
||||
|
||||
|
||||
Sample usage:
|
||||
|
||||
Interval tree is an example of augmented rb tree. Reference -
|
||||
"Introduction to Algorithms" by Cormen, Leiserson, Rivest and Stein.
|
||||
@ -230,26 +261,132 @@ and its immediate children. And this will be used in O(log n) lookup
|
||||
for lowest match (lowest start address among all possible matches)
|
||||
with something like:
|
||||
|
||||
find_lowest_match(lo, hi, node)
|
||||
struct interval_tree_node *
|
||||
interval_tree_first_match(struct rb_root *root,
|
||||
unsigned long start, unsigned long last)
|
||||
{
|
||||
lowest_match = NULL;
|
||||
while (node) {
|
||||
if (max_hi(node->left) > lo) {
|
||||
// Lowest overlap if any must be on left side
|
||||
node = node->left;
|
||||
} else if (overlap(lo, hi, node)) {
|
||||
lowest_match = node;
|
||||
break;
|
||||
} else if (lo > node->lo) {
|
||||
// Lowest overlap if any must be on right side
|
||||
node = node->right;
|
||||
} else {
|
||||
break;
|
||||
struct interval_tree_node *node;
|
||||
|
||||
if (!root->rb_node)
|
||||
return NULL;
|
||||
node = rb_entry(root->rb_node, struct interval_tree_node, rb);
|
||||
|
||||
while (true) {
|
||||
if (node->rb.rb_left) {
|
||||
struct interval_tree_node *left =
|
||||
rb_entry(node->rb.rb_left,
|
||||
struct interval_tree_node, rb);
|
||||
if (left->__subtree_last >= start) {
|
||||
/*
|
||||
* Some nodes in left subtree satisfy Cond2.
|
||||
* Iterate to find the leftmost such node N.
|
||||
* If it also satisfies Cond1, that's the match
|
||||
* we are looking for. Otherwise, there is no
|
||||
* matching interval as nodes to the right of N
|
||||
* can't satisfy Cond1 either.
|
||||
*/
|
||||
node = left;
|
||||
continue;
|
||||
}
|
||||
}
|
||||
if (node->start <= last) { /* Cond1 */
|
||||
if (node->last >= start) /* Cond2 */
|
||||
return node; /* node is leftmost match */
|
||||
if (node->rb.rb_right) {
|
||||
node = rb_entry(node->rb.rb_right,
|
||||
struct interval_tree_node, rb);
|
||||
if (node->__subtree_last >= start)
|
||||
continue;
|
||||
}
|
||||
}
|
||||
return NULL; /* No match */
|
||||
}
|
||||
return lowest_match;
|
||||
}
|
||||
|
||||
Finding exact match will be to first find lowest match and then to follow
|
||||
successor nodes looking for exact match, until the start of a node is beyond
|
||||
the hi value we are looking for.
|
||||
Insertion/removal are defined using the following augmented callbacks:
|
||||
|
||||
static inline unsigned long
|
||||
compute_subtree_last(struct interval_tree_node *node)
|
||||
{
|
||||
unsigned long max = node->last, subtree_last;
|
||||
if (node->rb.rb_left) {
|
||||
subtree_last = rb_entry(node->rb.rb_left,
|
||||
struct interval_tree_node, rb)->__subtree_last;
|
||||
if (max < subtree_last)
|
||||
max = subtree_last;
|
||||
}
|
||||
if (node->rb.rb_right) {
|
||||
subtree_last = rb_entry(node->rb.rb_right,
|
||||
struct interval_tree_node, rb)->__subtree_last;
|
||||
if (max < subtree_last)
|
||||
max = subtree_last;
|
||||
}
|
||||
return max;
|
||||
}
|
||||
|
||||
static void augment_propagate(struct rb_node *rb, struct rb_node *stop)
|
||||
{
|
||||
while (rb != stop) {
|
||||
struct interval_tree_node *node =
|
||||
rb_entry(rb, struct interval_tree_node, rb);
|
||||
unsigned long subtree_last = compute_subtree_last(node);
|
||||
if (node->__subtree_last == subtree_last)
|
||||
break;
|
||||
node->__subtree_last = subtree_last;
|
||||
rb = rb_parent(&node->rb);
|
||||
}
|
||||
}
|
||||
|
||||
static void augment_copy(struct rb_node *rb_old, struct rb_node *rb_new)
|
||||
{
|
||||
struct interval_tree_node *old =
|
||||
rb_entry(rb_old, struct interval_tree_node, rb);
|
||||
struct interval_tree_node *new =
|
||||
rb_entry(rb_new, struct interval_tree_node, rb);
|
||||
|
||||
new->__subtree_last = old->__subtree_last;
|
||||
}
|
||||
|
||||
static void augment_rotate(struct rb_node *rb_old, struct rb_node *rb_new)
|
||||
{
|
||||
struct interval_tree_node *old =
|
||||
rb_entry(rb_old, struct interval_tree_node, rb);
|
||||
struct interval_tree_node *new =
|
||||
rb_entry(rb_new, struct interval_tree_node, rb);
|
||||
|
||||
new->__subtree_last = old->__subtree_last;
|
||||
old->__subtree_last = compute_subtree_last(old);
|
||||
}
|
||||
|
||||
static const struct rb_augment_callbacks augment_callbacks = {
|
||||
augment_propagate, augment_copy, augment_rotate
|
||||
};
|
||||
|
||||
void interval_tree_insert(struct interval_tree_node *node,
|
||||
struct rb_root *root)
|
||||
{
|
||||
struct rb_node **link = &root->rb_node, *rb_parent = NULL;
|
||||
unsigned long start = node->start, last = node->last;
|
||||
struct interval_tree_node *parent;
|
||||
|
||||
while (*link) {
|
||||
rb_parent = *link;
|
||||
parent = rb_entry(rb_parent, struct interval_tree_node, rb);
|
||||
if (parent->__subtree_last < last)
|
||||
parent->__subtree_last = last;
|
||||
if (start < parent->start)
|
||||
link = &parent->rb.rb_left;
|
||||
else
|
||||
link = &parent->rb.rb_right;
|
||||
}
|
||||
|
||||
node->__subtree_last = last;
|
||||
rb_link_node(&node->rb, rb_parent, link);
|
||||
rb_insert_augmented(&node->rb, root, &augment_callbacks);
|
||||
}
|
||||
|
||||
void interval_tree_remove(struct interval_tree_node *node,
|
||||
struct rb_root *root)
|
||||
{
|
||||
rb_erase_augmented(&node->rb, root, &augment_callbacks);
|
||||
}
|
||||
|
@ -860,8 +860,14 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
||||
|
||||
[Multiple options for each card instance]
|
||||
model - force the model name
|
||||
position_fix - Fix DMA pointer (0 = auto, 1 = use LPIB, 2 = POSBUF,
|
||||
3 = VIACOMBO, 4 = COMBO)
|
||||
position_fix - Fix DMA pointer
|
||||
-1 = system default: choose appropriate one per controller
|
||||
hardware
|
||||
0 = auto: falls back to LPIB when POSBUF doesn't work
|
||||
1 = use LPIB
|
||||
2 = POSBUF: use position buffer
|
||||
3 = VIACOMBO: VIA-specific workaround for capture
|
||||
4 = COMBO: use LPIB for playback, auto for capture stream
|
||||
probe_mask - Bitmask to probe codecs (default = -1, meaning all slots)
|
||||
When the bit 8 (0x100) is set, the lower 8 bits are used
|
||||
as the "fixed" codec slots; i.e. the driver probes the
|
||||
|
153
Documentation/sound/alsa/Channel-Mapping-API.txt
Normal file
153
Documentation/sound/alsa/Channel-Mapping-API.txt
Normal file
@ -0,0 +1,153 @@
|
||||
ALSA PCM channel-mapping API
|
||||
============================
|
||||
Takashi Iwai <tiwai@suse.de>
|
||||
|
||||
GENERAL
|
||||
-------
|
||||
|
||||
The channel mapping API allows user to query the possible channel maps
|
||||
and the current channel map, also optionally to modify the channel map
|
||||
of the current stream.
|
||||
|
||||
A channel map is an array of position for each PCM channel.
|
||||
Typically, a stereo PCM stream has a channel map of
|
||||
{ front_left, front_right }
|
||||
while a 4.0 surround PCM stream has a channel map of
|
||||
{ front left, front right, rear left, rear right }.
|
||||
|
||||
The problem, so far, was that we had no standard channel map
|
||||
explicitly, and applications had no way to know which channel
|
||||
corresponds to which (speaker) position. Thus, applications applied
|
||||
wrong channels for 5.1 outputs, and you hear suddenly strange sound
|
||||
from rear. Or, some devices secretly assume that center/LFE is the
|
||||
third/fourth channels while others that C/LFE as 5th/6th channels.
|
||||
|
||||
Also, some devices such as HDMI are configurable for different speaker
|
||||
positions even with the same number of total channels. However, there
|
||||
was no way to specify this because of lack of channel map
|
||||
specification. These are the main motivations for the new channel
|
||||
mapping API.
|
||||
|
||||
|
||||
DESIGN
|
||||
------
|
||||
|
||||
Actually, "the channel mapping API" doesn't introduce anything new in
|
||||
the kernel/user-space ABI perspective. It uses only the existing
|
||||
control element features.
|
||||
|
||||
As a ground design, each PCM substream may contain a control element
|
||||
providing the channel mapping information and configuration. This
|
||||
element is specified by:
|
||||
iface = SNDRV_CTL_ELEM_IFACE_PCM
|
||||
name = "Playback Channel Map" or "Capture Channel Map"
|
||||
device = the same device number for the assigned PCM substream
|
||||
index = the same index number for the assigned PCM substream
|
||||
|
||||
Note the name is different depending on the PCM substream direction.
|
||||
|
||||
Each control element provides at least the TLV read operation and the
|
||||
read operation. Optionally, the write operation can be provided to
|
||||
allow user to change the channel map dynamically.
|
||||
|
||||
* TLV
|
||||
|
||||
The TLV operation gives the list of available channel
|
||||
maps. A list item of a channel map is usually a TLV of
|
||||
type data-bytes ch0 ch1 ch2...
|
||||
where type is the TLV type value, the second argument is the total
|
||||
bytes (not the numbers) of channel values, and the rest are the
|
||||
position value for each channel.
|
||||
|
||||
As a TLV type, either SNDRV_CTL_TLVT_CHMAP_FIXED,
|
||||
SNDRV_CTL_TLV_CHMAP_VAR or SNDRV_CTL_TLVT_CHMAP_PAIRED can be used.
|
||||
The _FIXED type is for a channel map with the fixed channel position
|
||||
while the latter two are for flexible channel positions. _VAR type is
|
||||
for a channel map where all channels are freely swappable and _PAIRED
|
||||
type is where pair-wise channels are swappable. For example, when you
|
||||
have {FL/FR/RL/RR} channel map, _PAIRED type would allow you to swap
|
||||
only {RL/RR/FL/FR} while _VAR type would allow even swapping FL and
|
||||
RR.
|
||||
|
||||
These new TLV types are defined in sound/tlv.h.
|
||||
|
||||
The available channel position values are defined in sound/asound.h,
|
||||
here is a cut:
|
||||
|
||||
/* channel positions */
|
||||
enum {
|
||||
SNDRV_CHMAP_UNKNOWN = 0,
|
||||
SNDRV_CHMAP_NA, /* N/A, silent */
|
||||
SNDRV_CHMAP_MONO, /* mono stream */
|
||||
/* this follows the alsa-lib mixer channel value + 3 */
|
||||
SNDRV_CHMAP_FL, /* front left */
|
||||
SNDRV_CHMAP_FR, /* front right */
|
||||
SNDRV_CHMAP_RL, /* rear left */
|
||||
SNDRV_CHMAP_RR, /* rear right */
|
||||
SNDRV_CHMAP_FC, /* front center */
|
||||
SNDRV_CHMAP_LFE, /* LFE */
|
||||
SNDRV_CHMAP_SL, /* side left */
|
||||
SNDRV_CHMAP_SR, /* side right */
|
||||
SNDRV_CHMAP_RC, /* rear center */
|
||||
/* new definitions */
|
||||
SNDRV_CHMAP_FLC, /* front left center */
|
||||
SNDRV_CHMAP_FRC, /* front right center */
|
||||
SNDRV_CHMAP_RLC, /* rear left center */
|
||||
SNDRV_CHMAP_RRC, /* rear right center */
|
||||
SNDRV_CHMAP_FLW, /* front left wide */
|
||||
SNDRV_CHMAP_FRW, /* front right wide */
|
||||
SNDRV_CHMAP_FLH, /* front left high */
|
||||
SNDRV_CHMAP_FCH, /* front center high */
|
||||
SNDRV_CHMAP_FRH, /* front right high */
|
||||
SNDRV_CHMAP_TC, /* top center */
|
||||
SNDRV_CHMAP_TFL, /* top front left */
|
||||
SNDRV_CHMAP_TFR, /* top front right */
|
||||
SNDRV_CHMAP_TFC, /* top front center */
|
||||
SNDRV_CHMAP_TRL, /* top rear left */
|
||||
SNDRV_CHMAP_TRR, /* top rear right */
|
||||
SNDRV_CHMAP_TRC, /* top rear center */
|
||||
SNDRV_CHMAP_LAST = SNDRV_CHMAP_TRC,
|
||||
};
|
||||
|
||||
When a PCM stream can provide more than one channel map, you can
|
||||
provide multiple channel maps in a TLV container type. The TLV data
|
||||
to be returned will contain such as:
|
||||
SNDRV_CTL_TLVT_CONTAINER 96
|
||||
SNDRV_CTL_TLVT_CHMAP_FIXED 4 SNDRV_CHMAP_FC
|
||||
SNDRV_CTL_TLVT_CHMAP_FIXED 8 SNDRV_CHMAP_FL SNDRV_CHMAP_FR
|
||||
SNDRV_CTL_TLVT_CHMAP_FIXED 16 NDRV_CHMAP_FL SNDRV_CHMAP_FR \
|
||||
SNDRV_CHMAP_RL SNDRV_CHMAP_RR
|
||||
|
||||
The channel position is provided in LSB 16bits. The upper bits are
|
||||
used for bit flags.
|
||||
|
||||
#define SNDRV_CHMAP_POSITION_MASK 0xffff
|
||||
#define SNDRV_CHMAP_PHASE_INVERSE (0x01 << 16)
|
||||
#define SNDRV_CHMAP_DRIVER_SPEC (0x02 << 16)
|
||||
|
||||
SNDRV_CHMAP_PHASE_INVERSE indicates the channel is phase inverted,
|
||||
(thus summing left and right channels would result in almost silence).
|
||||
Some digital mic devices have this.
|
||||
|
||||
When SNDRV_CHMAP_DRIVER_SPEC is set, all the channel position values
|
||||
don't follow the standard definition above but driver-specific.
|
||||
|
||||
* READ OPERATION
|
||||
|
||||
The control read operation is for providing the current channel map of
|
||||
the given stream. The control element returns an integer array
|
||||
containing the position of each channel.
|
||||
|
||||
When this is performed before the number of the channel is specified
|
||||
(i.e. hw_params is set), it should return all channels set to
|
||||
UNKNOWN.
|
||||
|
||||
* WRITE OPERATION
|
||||
|
||||
The control write operation is optional, and only for devices that can
|
||||
change the channel configuration on the fly, such as HDMI. User needs
|
||||
to pass an integer value containing the valid channel positions for
|
||||
all channels of the assigned PCM substream.
|
||||
|
||||
This operation is allowed only at PCM PREPARED state. When called in
|
||||
other states, it shall return an error.
|
@ -74,7 +74,8 @@ CMI9880
|
||||
|
||||
AD1882 / AD1882A
|
||||
================
|
||||
3stack 3-stack mode (default)
|
||||
3stack 3-stack mode
|
||||
3stack-automute 3-stack with automute front HP (default)
|
||||
6stack 6-stack mode
|
||||
|
||||
AD1884A / AD1883 / AD1984A / AD1984B
|
||||
|
@ -35,3 +35,4 @@
|
||||
34 -> TerraTec Cinergy T PCIe Dual [153b:117e]
|
||||
35 -> TeVii S471 [d471:9022]
|
||||
36 -> Hauppauge WinTV-HVR1255 [0070:2259]
|
||||
37 -> Prof Revolution DVB-S2 8000 [8000:3034]
|
||||
|
@ -18,7 +18,7 @@ Table of Contents
|
||||
|
||||
1.0 Introduction
|
||||
|
||||
The file ../../drivers/media/video/c-qcam.c is a device driver for
|
||||
The file ../../drivers/media/parport/c-qcam.c is a device driver for
|
||||
the Logitech (nee Connectix) parallel port interface color CCD camera.
|
||||
This is a fairly inexpensive device for capturing images. Logitech
|
||||
does not currently provide information for developers, but many people
|
||||
|
@ -5,22 +5,22 @@
|
||||
File partitioning
|
||||
-----------------
|
||||
V4L2 display device driver
|
||||
drivers/media/video/davinci/vpbe_display.c
|
||||
drivers/media/video/davinci/vpbe_display.h
|
||||
drivers/media/platform/davinci/vpbe_display.c
|
||||
drivers/media/platform/davinci/vpbe_display.h
|
||||
|
||||
VPBE display controller
|
||||
drivers/media/video/davinci/vpbe.c
|
||||
drivers/media/video/davinci/vpbe.h
|
||||
drivers/media/platform/davinci/vpbe.c
|
||||
drivers/media/platform/davinci/vpbe.h
|
||||
|
||||
VPBE venc sub device driver
|
||||
drivers/media/video/davinci/vpbe_venc.c
|
||||
drivers/media/video/davinci/vpbe_venc.h
|
||||
drivers/media/video/davinci/vpbe_venc_regs.h
|
||||
drivers/media/platform/davinci/vpbe_venc.c
|
||||
drivers/media/platform/davinci/vpbe_venc.h
|
||||
drivers/media/platform/davinci/vpbe_venc_regs.h
|
||||
|
||||
VPBE osd driver
|
||||
drivers/media/video/davinci/vpbe_osd.c
|
||||
drivers/media/video/davinci/vpbe_osd.h
|
||||
drivers/media/video/davinci/vpbe_osd_regs.h
|
||||
drivers/media/platform/davinci/vpbe_osd.c
|
||||
drivers/media/platform/davinci/vpbe_osd.h
|
||||
drivers/media/platform/davinci/vpbe_osd_regs.h
|
||||
|
||||
Functional partitioning
|
||||
-----------------------
|
||||
|
@ -10,7 +10,7 @@ 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.
|
||||
drivers/media/platform/s5p-fimc directory.
|
||||
|
||||
1. Supported SoCs
|
||||
=================
|
||||
@ -36,21 +36,21 @@ Not currently supported:
|
||||
=====================
|
||||
|
||||
- media device driver
|
||||
drivers/media/video/s5p-fimc/fimc-mdevice.[ch]
|
||||
drivers/media/platform/s5p-fimc/fimc-mdevice.[ch]
|
||||
|
||||
- camera capture video device driver
|
||||
drivers/media/video/s5p-fimc/fimc-capture.c
|
||||
drivers/media/platform/s5p-fimc/fimc-capture.c
|
||||
|
||||
- MIPI-CSI2 receiver subdev
|
||||
drivers/media/video/s5p-fimc/mipi-csis.[ch]
|
||||
drivers/media/platform/s5p-fimc/mipi-csis.[ch]
|
||||
|
||||
- video post-processor (mem-to-mem)
|
||||
drivers/media/video/s5p-fimc/fimc-core.c
|
||||
drivers/media/platform/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
|
||||
drivers/media/platform/s5p-fimc/fimc-core.h
|
||||
drivers/media/platform/s5p-fimc/fimc-reg.h
|
||||
drivers/media/platform/s5p-fimc/regs-fimc.h
|
||||
|
||||
4. User space interfaces
|
||||
========================
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user