Merge branch 'fixes' into for-linus
Conflicts: arch/arm/kernel/smp.c
This commit is contained in:
commit
a0f0dd57f4
10081 changed files with 493408 additions and 259317 deletions
Documentation
ABI/testing
ima_policysysfs-bus-rbdsysfs-bus-usbsysfs-class-extconsysfs-class-regulatorsysfs-devices-firmware_nodesysfs-devices-system-cpusysfs-driver-ppisysfs-driver-wacomsysfs-fs-ext4sysfs-ptpsysfs-tty
CodingStyleDocBook
drm.tmpl
media
Makefile
media_api.tmpldvb
v4l
biblio.xmlcommon.xmlcompat.xmlcontrols.xmldev-osd.xmldev-rds.xmldev-subdev.xmlgen-errors.xmlio.xmlpixfmt-srggb10dpcm8.xmlpixfmt-yvu420m.xmlpixfmt.xmlselection-api.xmlv4l2.xmlvidioc-cropcap.xmlvidioc-decoder-cmd.xmlvidioc-encoder-cmd.xmlvidioc-enum-dv-presets.xmlvidioc-enum-dv-timings.xmlvidioc-enum-fmt.xmlvidioc-enum-framesizes.xmlvidioc-enuminput.xmlvidioc-enumoutput.xmlvidioc-enumstd.xmlvidioc-g-crop.xmlvidioc-g-dv-preset.xmlvidioc-g-dv-timings.xmlvidioc-g-enc-index.xmlvidioc-g-fmt.xmlvidioc-g-parm.xmlvidioc-g-selection.xmlvidioc-g-std.xmlvidioc-g-tuner.xmlvidioc-qbuf.xmlvidioc-query-dv-preset.xmlvidioc-query-dv-timings.xmlvidioc-querycap.xmlvidioc-querystd.xmlvidioc-reqbufs.xmlvidioc-s-hw-freq-seek.xmlvidioc-streamon.xmlvidioc-subdev-g-edid.xmlvidioc-subdev-g-selection.xml
RCU
accounting
aoe
arm
arm64
cgroups
cpu-freq
cpuidle
devicetree/bindings/arm
|
@ -12,11 +12,14 @@ Description:
|
|||
then closing the file. The new policy takes effect after
|
||||
the file ima/policy is closed.
|
||||
|
||||
IMA appraisal, if configured, uses these file measurements
|
||||
for local measurement appraisal.
|
||||
|
||||
rule format: action [condition ...]
|
||||
|
||||
action: measure | dont_measure
|
||||
action: measure | dont_measure | appraise | dont_appraise | audit
|
||||
condition:= base | lsm
|
||||
base: [[func=] [mask=] [fsmagic=] [uid=]]
|
||||
base: [[func=] [mask=] [fsmagic=] [uid=] [fowner]]
|
||||
lsm: [[subj_user=] [subj_role=] [subj_type=]
|
||||
[obj_user=] [obj_role=] [obj_type=]]
|
||||
|
||||
|
@ -24,36 +27,50 @@ Description:
|
|||
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
|
||||
fsmagic:= hex value
|
||||
uid:= decimal value
|
||||
fowner:=decimal value
|
||||
lsm: are LSM specific
|
||||
|
||||
default policy:
|
||||
# PROC_SUPER_MAGIC
|
||||
dont_measure fsmagic=0x9fa0
|
||||
dont_appraise fsmagic=0x9fa0
|
||||
# SYSFS_MAGIC
|
||||
dont_measure fsmagic=0x62656572
|
||||
dont_appraise fsmagic=0x62656572
|
||||
# DEBUGFS_MAGIC
|
||||
dont_measure fsmagic=0x64626720
|
||||
dont_appraise fsmagic=0x64626720
|
||||
# TMPFS_MAGIC
|
||||
dont_measure fsmagic=0x01021994
|
||||
dont_appraise fsmagic=0x01021994
|
||||
# RAMFS_MAGIC
|
||||
dont_measure fsmagic=0x858458f6
|
||||
dont_appraise fsmagic=0x858458f6
|
||||
# SECURITYFS_MAGIC
|
||||
dont_measure fsmagic=0x73636673
|
||||
dont_appraise fsmagic=0x73636673
|
||||
|
||||
measure func=BPRM_CHECK
|
||||
measure func=FILE_MMAP mask=MAY_EXEC
|
||||
measure func=FILE_CHECK mask=MAY_READ uid=0
|
||||
appraise fowner=0
|
||||
|
||||
The default policy measures all executables in bprm_check,
|
||||
all files mmapped executable in file_mmap, and all files
|
||||
open for read by root in do_filp_open.
|
||||
open for read by root in do_filp_open. The default appraisal
|
||||
policy appraises all files owned by root.
|
||||
|
||||
Examples of LSM specific definitions:
|
||||
|
||||
SELinux:
|
||||
# SELINUX_MAGIC
|
||||
dont_measure fsmagic=0xF97CFF8C
|
||||
dont_measure fsmagic=0xf97cff8c
|
||||
dont_appraise fsmagic=0xf97cff8c
|
||||
|
||||
dont_measure obj_type=var_log_t
|
||||
dont_appraise obj_type=var_log_t
|
||||
dont_measure obj_type=auditd_log_t
|
||||
dont_appraise obj_type=auditd_log_t
|
||||
measure subj_user=system_u func=FILE_CHECK mask=MAY_READ
|
||||
measure subj_role=system_r func=FILE_CHECK mask=MAY_READ
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -220,3 +220,10 @@ Description:
|
|||
If the device doesn't support LTM, the file will read "no".
|
||||
The file will be present for all speeds of USB devices, and will
|
||||
always read "no" for USB 1.1 and USB 2.0 devices.
|
||||
|
||||
What: /sys/bus/usb/devices/.../(hub interface)/portX
|
||||
Date: August 2012
|
||||
Contact: Lan Tianyu <tianyu.lan@intel.com>
|
||||
Description:
|
||||
The /sys/bus/usb/devices/.../(hub interface)/portX
|
||||
is usb port device's sysfs directory.
|
||||
|
|
|
@ -13,7 +13,7 @@ Description:
|
|||
accessory cables have such capability. For example,
|
||||
the 30-pin port of Nuri board (/arch/arm/mach-exynos)
|
||||
may have both HDMI and Charger attached, or analog audio,
|
||||
video, and USB cables attached simulteneously.
|
||||
video, and USB cables attached simultaneously.
|
||||
|
||||
If there are cables mutually exclusive with each other,
|
||||
such binary relations may be expressed with extcon_dev's
|
||||
|
@ -35,7 +35,7 @@ Description:
|
|||
The /sys/class/extcon/.../state shows and stores the cable
|
||||
attach/detach information of the corresponding extcon object.
|
||||
If the extcon object has an optional callback "show_state"
|
||||
defined, the showing function is overriden with the optional
|
||||
defined, the showing function is overridden with the optional
|
||||
callback.
|
||||
|
||||
If the default callback for showing function is used, the
|
||||
|
@ -46,19 +46,19 @@ Description:
|
|||
TA=1
|
||||
EAR_JACK=0
|
||||
#
|
||||
In this example, the extcon device have USB_OTG and TA
|
||||
In this example, the extcon device has USB_OTG and TA
|
||||
cables attached and HDMI and EAR_JACK cables detached.
|
||||
|
||||
In order to update the state of an extcon device, enter a hex
|
||||
state number starting with 0x.
|
||||
echo 0xHEX > state
|
||||
state number starting with 0x:
|
||||
# echo 0xHEX > state
|
||||
|
||||
This updates the whole state of the extcon dev.
|
||||
This updates the whole state of the extcon device.
|
||||
Inputs of all the methods are required to meet the
|
||||
mutually_exclusive contidions if they exist.
|
||||
mutually_exclusive conditions if they exist.
|
||||
|
||||
It is recommended to use this "global" state interface if
|
||||
you need to enter the value atomically. The later state
|
||||
you need to set the value atomically. The later state
|
||||
interface associated with each cable cannot update
|
||||
multiple cable states of an extcon device simultaneously.
|
||||
|
||||
|
@ -73,7 +73,7 @@ What: /sys/class/extcon/.../cable.x/state
|
|||
Date: February 2012
|
||||
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
|
||||
Description:
|
||||
The /sys/class/extcon/.../cable.x/name shows and stores the
|
||||
The /sys/class/extcon/.../cable.x/state shows and stores the
|
||||
state of cable "x" (integer between 0 and 31) of an extcon
|
||||
device. The state value is either 0 (detached) or 1
|
||||
(attached).
|
||||
|
@ -83,8 +83,8 @@ Date: December 2011
|
|||
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
|
||||
Description:
|
||||
Shows the relations of mutually exclusiveness. For example,
|
||||
if the mutually_exclusive array of extcon_dev is
|
||||
{0x3, 0x5, 0xC, 0x0}, the, the output is:
|
||||
if the mutually_exclusive array of extcon device is
|
||||
{0x3, 0x5, 0xC, 0x0}, then the output is:
|
||||
# ls mutually_exclusive/
|
||||
0x3
|
||||
0x5
|
||||
|
|
|
@ -349,3 +349,24 @@ Description:
|
|||
|
||||
This will be one of the same strings reported by
|
||||
the "state" attribute.
|
||||
|
||||
What: /sys/class/regulator/.../bypass
|
||||
Date: September 2012
|
||||
KernelVersion: 3.7
|
||||
Contact: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Some regulator directories will contain a field called
|
||||
bypass. This indicates if the device is in bypass mode.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
'enabled'
|
||||
'disabled'
|
||||
'unknown'
|
||||
|
||||
'enabled' means the regulator is in bypass mode.
|
||||
|
||||
'disabled' means that the regulator is regulating.
|
||||
|
||||
'unknown' means software cannot determine the state, or
|
||||
the reported state is invalid.
|
||||
|
|
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.
|
|
@ -176,3 +176,14 @@ Description: Disable L3 cache indices
|
|||
All AMD processors with L3 caches provide this functionality.
|
||||
For details, see BKDGs at
|
||||
http://developer.amd.com/documentation/guides/Pages/default.aspx
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpufreq/boost
|
||||
Date: August 2012
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description: Processor frequency boosting control
|
||||
|
||||
This switch controls the boost setting for the whole system.
|
||||
Boosting allows the CPU and the firmware to run at a frequency
|
||||
beyound it's nominal limit.
|
||||
More details can be found in Documentation/cpu-freq/boost.txt
|
||||
|
|
70
Documentation/ABI/testing/sysfs-driver-ppi
Normal file
70
Documentation/ABI/testing/sysfs-driver-ppi
Normal file
|
@ -0,0 +1,70 @@
|
|||
What: /sys/devices/pnp0/<bus-num>/ppi/
|
||||
Date: August 2012
|
||||
Kernel Version: 3.6
|
||||
Contact: xiaoyan.zhang@intel.com
|
||||
Description:
|
||||
This folder includes the attributes related with PPI (Physical
|
||||
Presence Interface). Only if TPM is supported by BIOS, this
|
||||
folder makes sence. The folder path can be got by command
|
||||
'find /sys/ -name 'pcrs''. For the detail information of PPI,
|
||||
please refer to the PPI specification from
|
||||
http://www.trustedcomputinggroup.org/
|
||||
|
||||
What: /sys/devices/pnp0/<bus-num>/ppi/version
|
||||
Date: August 2012
|
||||
Contact: xiaoyan.zhang@intel.com
|
||||
Description:
|
||||
This attribute shows the version of the PPI supported by the
|
||||
platform.
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/devices/pnp0/<bus-num>/ppi/request
|
||||
Date: August 2012
|
||||
Contact: xiaoyan.zhang@intel.com
|
||||
Description:
|
||||
This attribute shows the request for an operation to be
|
||||
executed in the pre-OS environment. It is the only input from
|
||||
the OS to the pre-OS environment. The request should be an
|
||||
integer value range from 1 to 160, and 0 means no request.
|
||||
This file can be read and written.
|
||||
|
||||
What: /sys/devices/pnp0/00:<bus-num>/ppi/response
|
||||
Date: August 2012
|
||||
Contact: xiaoyan.zhang@intel.com
|
||||
Description:
|
||||
This attribute shows the response to the most recent operation
|
||||
request it acted upon. The format is "<request> <response num>
|
||||
: <response description>".
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/devices/pnp0/<bus-num>/ppi/transition_action
|
||||
Date: August 2012
|
||||
Contact: xiaoyan.zhang@intel.com
|
||||
Description:
|
||||
This attribute shows the platform-specific action that should
|
||||
take place in order to transition to the BIOS for execution of
|
||||
a requested operation. The format is "<action num>: <action
|
||||
description>".
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/devices/pnp0/<bus-num>/ppi/tcg_operations
|
||||
Date: August 2012
|
||||
Contact: xiaoyan.zhang@intel.com
|
||||
Description:
|
||||
This attribute shows whether it is allowed to request an
|
||||
operation to be executed in the pre-OS environment by the BIOS
|
||||
for the requests defined by TCG, i.e. requests from 1 to 22.
|
||||
The format is "<request> <status num>: <status description>".
|
||||
This attribute is only supported by PPI version 1.2+.
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/devices/pnp0/<bus-num>/ppi/vs_operations
|
||||
Date: August 2012
|
||||
Contact: xiaoyan.zhang@intel.com
|
||||
Description:
|
||||
This attribute shows whether it is allowed to request an
|
||||
operation to be executed in the pre-OS environment by the BIOS
|
||||
for the verdor specific requests, i.e. requests from 128 to
|
||||
255. The format is same with tcg_operations. This attribute
|
||||
is also only supported by PPI version 1.2+.
|
||||
This file is readonly.
|
|
@ -1,3 +1,16 @@
|
|||
WWhat: /sys/class/hidraw/hidraw*/device/oled*_img
|
||||
Date: June 2012
|
||||
Contact: linux-bluetooth@vger.kernel.org
|
||||
Description:
|
||||
The /sys/class/hidraw/hidraw*/device/oled*_img files control
|
||||
OLED mocro displays on Intuos4 Wireless tablet. Accepted image
|
||||
has to contain 256 bytes (64x32 px 1 bit colour). The format
|
||||
is the same as PBM image 62x32px without header (64 bits per
|
||||
horizontal line, 32 lines). An example of setting OLED No. 0:
|
||||
dd bs=256 count=1 if=img_file of=[path to oled0_img]/oled0_img
|
||||
The attribute is read only and no local copy of the image is
|
||||
stored.
|
||||
|
||||
What: /sys/class/hidraw/hidraw*/device/speed
|
||||
Date: April 2010
|
||||
Kernel Version: 2.6.35
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -19,7 +19,11 @@ Date: September 2010
|
|||
Contact: Richard Cochran <richardcochran@gmail.com>
|
||||
Description:
|
||||
This file contains the name of the PTP hardware clock
|
||||
as a human readable string.
|
||||
as a human readable string. The purpose of this
|
||||
attribute is to provide the user with a "friendly
|
||||
name" and to help distinguish PHY based devices from
|
||||
MAC based ones. The string does not necessarily have
|
||||
to be any kind of unique id.
|
||||
|
||||
What: /sys/class/ptp/ptpN/max_adjustment
|
||||
Date: September 2010
|
||||
|
|
|
@ -17,3 +17,12 @@ Description:
|
|||
device, like 'tty1'.
|
||||
The file supports poll() to detect virtual
|
||||
console switches.
|
||||
|
||||
What: /sys/class/tty/ttyS0/uartclk
|
||||
Date: Sep 2012
|
||||
Contact: Tomas Hlavacek <tmshlvck@gmail.com>
|
||||
Description:
|
||||
Shows the current uartclk value associated with the
|
||||
UART port in serial_core, that is bound to TTY like ttyS0.
|
||||
uartclk = 16 * baud_base
|
||||
|
||||
|
|
|
@ -454,6 +454,16 @@ The preferred style for long (multi-line) comments is:
|
|||
* with beginning and ending almost-blank lines.
|
||||
*/
|
||||
|
||||
For files in net/ and drivers/net/ the preferred style for long (multi-line)
|
||||
comments is a little different.
|
||||
|
||||
/* The preferred comment style for files in net/ and drivers/net
|
||||
* looks like this.
|
||||
*
|
||||
* It is nearly the same as the generally preferred comment style,
|
||||
* but there is no initial almost-blank line.
|
||||
*/
|
||||
|
||||
It's also important to comment data, whether they are basic types or derived
|
||||
types. To this end, use just one data declaration per line (no commas for
|
||||
multiple data declarations). This leaves you room for a small comment on each
|
||||
|
|
File diff suppressed because it is too large
Load diff
|
@ -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>
|
||||
|
||||
|
|
|
@ -310,6 +310,12 @@ over a rather long period of time, but improvements are always welcome!
|
|||
code under the influence of preempt_disable(), you instead
|
||||
need to use synchronize_irq() or synchronize_sched().
|
||||
|
||||
This same limitation also applies to synchronize_rcu_bh()
|
||||
and synchronize_srcu(), as well as to the asynchronous and
|
||||
expedited forms of the three primitives, namely call_rcu(),
|
||||
call_rcu_bh(), call_srcu(), synchronize_rcu_expedited(),
|
||||
synchronize_rcu_bh_expedited(), and synchronize_srcu_expedited().
|
||||
|
||||
12. Any lock acquired by an RCU callback must be acquired elsewhere
|
||||
with softirq disabled, e.g., via spin_lock_irqsave(),
|
||||
spin_lock_bh(), etc. Failing to disable irq on a given
|
||||
|
|
|
@ -99,7 +99,7 @@ In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
|
|||
printed:
|
||||
|
||||
INFO: rcu_preempt detected stall on CPU
|
||||
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer=-1
|
||||
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer not pending
|
||||
(t=65000 jiffies)
|
||||
|
||||
The "(64628 ticks this GP)" indicates that this CPU has taken more
|
||||
|
@ -116,13 +116,13 @@ number between the two "/"s is the value of the nesting, which will
|
|||
be a small positive number if in the idle loop and a very large positive
|
||||
number (as shown above) otherwise.
|
||||
|
||||
For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the
|
||||
CPU is not in the process of trying to force itself into dyntick-idle
|
||||
state, the "." indicates that the CPU has not given up forcing RCU
|
||||
into dyntick-idle mode (it would be "H" otherwise), and the "timer=-1"
|
||||
indicates that the CPU has not recented forced RCU into dyntick-idle
|
||||
mode (it would otherwise indicate the number of microseconds remaining
|
||||
in this forced state).
|
||||
For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the CPU is
|
||||
not in the process of trying to force itself into dyntick-idle state, the
|
||||
"." indicates that the CPU has not given up forcing RCU into dyntick-idle
|
||||
mode (it would be "H" otherwise), and the "timer not pending" indicates
|
||||
that the CPU has not recently forced RCU into dyntick-idle mode (it
|
||||
would otherwise indicate the number of microseconds remaining in this
|
||||
forced state).
|
||||
|
||||
|
||||
Multiple Warnings From One Stall
|
||||
|
|
|
@ -333,23 +333,23 @@ o Each element of the form "1/1 0:127 ^0" represents one struct
|
|||
The output of "cat rcu/rcu_pending" looks as follows:
|
||||
|
||||
rcu_sched:
|
||||
0 np=255892 qsp=53936 rpq=85 cbr=0 cng=14417 gpc=10033 gps=24320 nf=6445 nn=146741
|
||||
1 np=261224 qsp=54638 rpq=33 cbr=0 cng=25723 gpc=16310 gps=2849 nf=5912 nn=155792
|
||||
2 np=237496 qsp=49664 rpq=23 cbr=0 cng=2762 gpc=45478 gps=1762 nf=1201 nn=136629
|
||||
3 np=236249 qsp=48766 rpq=98 cbr=0 cng=286 gpc=48049 gps=1218 nf=207 nn=137723
|
||||
4 np=221310 qsp=46850 rpq=7 cbr=0 cng=26 gpc=43161 gps=4634 nf=3529 nn=123110
|
||||
5 np=237332 qsp=48449 rpq=9 cbr=0 cng=54 gpc=47920 gps=3252 nf=201 nn=137456
|
||||
6 np=219995 qsp=46718 rpq=12 cbr=0 cng=50 gpc=42098 gps=6093 nf=4202 nn=120834
|
||||
7 np=249893 qsp=49390 rpq=42 cbr=0 cng=72 gpc=38400 gps=17102 nf=41 nn=144888
|
||||
0 np=255892 qsp=53936 rpq=85 cbr=0 cng=14417 gpc=10033 gps=24320 nn=146741
|
||||
1 np=261224 qsp=54638 rpq=33 cbr=0 cng=25723 gpc=16310 gps=2849 nn=155792
|
||||
2 np=237496 qsp=49664 rpq=23 cbr=0 cng=2762 gpc=45478 gps=1762 nn=136629
|
||||
3 np=236249 qsp=48766 rpq=98 cbr=0 cng=286 gpc=48049 gps=1218 nn=137723
|
||||
4 np=221310 qsp=46850 rpq=7 cbr=0 cng=26 gpc=43161 gps=4634 nn=123110
|
||||
5 np=237332 qsp=48449 rpq=9 cbr=0 cng=54 gpc=47920 gps=3252 nn=137456
|
||||
6 np=219995 qsp=46718 rpq=12 cbr=0 cng=50 gpc=42098 gps=6093 nn=120834
|
||||
7 np=249893 qsp=49390 rpq=42 cbr=0 cng=72 gpc=38400 gps=17102 nn=144888
|
||||
rcu_bh:
|
||||
0 np=146741 qsp=1419 rpq=6 cbr=0 cng=6 gpc=0 gps=0 nf=2 nn=145314
|
||||
1 np=155792 qsp=12597 rpq=3 cbr=0 cng=0 gpc=4 gps=8 nf=3 nn=143180
|
||||
2 np=136629 qsp=18680 rpq=1 cbr=0 cng=0 gpc=7 gps=6 nf=0 nn=117936
|
||||
3 np=137723 qsp=2843 rpq=0 cbr=0 cng=0 gpc=10 gps=7 nf=0 nn=134863
|
||||
4 np=123110 qsp=12433 rpq=0 cbr=0 cng=0 gpc=4 gps=2 nf=0 nn=110671
|
||||
5 np=137456 qsp=4210 rpq=1 cbr=0 cng=0 gpc=6 gps=5 nf=0 nn=133235
|
||||
6 np=120834 qsp=9902 rpq=2 cbr=0 cng=0 gpc=6 gps=3 nf=2 nn=110921
|
||||
7 np=144888 qsp=26336 rpq=0 cbr=0 cng=0 gpc=8 gps=2 nf=0 nn=118542
|
||||
0 np=146741 qsp=1419 rpq=6 cbr=0 cng=6 gpc=0 gps=0 nn=145314
|
||||
1 np=155792 qsp=12597 rpq=3 cbr=0 cng=0 gpc=4 gps=8 nn=143180
|
||||
2 np=136629 qsp=18680 rpq=1 cbr=0 cng=0 gpc=7 gps=6 nn=117936
|
||||
3 np=137723 qsp=2843 rpq=0 cbr=0 cng=0 gpc=10 gps=7 nn=134863
|
||||
4 np=123110 qsp=12433 rpq=0 cbr=0 cng=0 gpc=4 gps=2 nn=110671
|
||||
5 np=137456 qsp=4210 rpq=1 cbr=0 cng=0 gpc=6 gps=5 nn=133235
|
||||
6 np=120834 qsp=9902 rpq=2 cbr=0 cng=0 gpc=6 gps=3 nn=110921
|
||||
7 np=144888 qsp=26336 rpq=0 cbr=0 cng=0 gpc=8 gps=2 nn=118542
|
||||
|
||||
As always, this is once again split into "rcu_sched" and "rcu_bh"
|
||||
portions, with CONFIG_TREE_PREEMPT_RCU kernels having an additional
|
||||
|
@ -377,17 +377,6 @@ o "gpc" is the number of times that an old grace period had
|
|||
o "gps" is the number of times that a new grace period had started,
|
||||
but this CPU was not yet aware of it.
|
||||
|
||||
o "nf" is the number of times that this CPU suspected that the
|
||||
current grace period had run for too long, and thus needed to
|
||||
be forced.
|
||||
|
||||
Please note that "forcing" consists of sending resched IPIs
|
||||
to holdout CPUs. If that CPU really still is in an old RCU
|
||||
read-side critical section, then we really do have to wait for it.
|
||||
The assumption behing "forcing" is that the CPU is not still in
|
||||
an old RCU read-side critical section, but has not yet responded
|
||||
for some other reason.
|
||||
|
||||
o "nn" is the number of times that this CPU needed nothing. Alert
|
||||
readers will note that the rcu "nn" number for a given CPU very
|
||||
closely matches the rcu_bh "np" number for that same CPU. This
|
||||
|
|
|
@ -873,7 +873,7 @@ d. Do you need to treat NMI handlers, hardirq handlers,
|
|||
and code segments with preemption disabled (whether
|
||||
via preempt_disable(), local_irq_save(), local_bh_disable(),
|
||||
or some other mechanism) as if they were explicit RCU readers?
|
||||
If so, you need RCU-sched.
|
||||
If so, RCU-sched is the only choice that will work for you.
|
||||
|
||||
e. Do you need RCU grace periods to complete even in the face
|
||||
of softirq monopolization of one or more of the CPUs? For
|
||||
|
@ -884,7 +884,12 @@ f. Is your workload too update-intensive for normal use of
|
|||
RCU, but inappropriate for other synchronization mechanisms?
|
||||
If so, consider SLAB_DESTROY_BY_RCU. But please be careful!
|
||||
|
||||
g. Otherwise, use RCU.
|
||||
g. Do you need read-side critical sections that are respected
|
||||
even though they are in the middle of the idle loop, during
|
||||
user-mode execution, or on an offlined CPU? If so, SRCU is the
|
||||
only choice that will work for you.
|
||||
|
||||
h. Otherwise, use RCU.
|
||||
|
||||
Of course, this all assumes that you have determined that RCU is in fact
|
||||
the right tool for your job.
|
||||
|
|
|
@ -98,10 +98,9 @@ static int create_nl_socket(int protocol)
|
|||
if (rcvbufsz)
|
||||
if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF,
|
||||
&rcvbufsz, sizeof(rcvbufsz)) < 0) {
|
||||
fprintf(stderr, "Unable to set socket rcv buf size "
|
||||
"to %d\n",
|
||||
fprintf(stderr, "Unable to set socket rcv buf size to %d\n",
|
||||
rcvbufsz);
|
||||
return -1;
|
||||
goto error;
|
||||
}
|
||||
|
||||
memset(&local, 0, sizeof(local));
|
||||
|
|
|
@ -1,8 +1,16 @@
|
|||
The EtherDrive (R) HOWTO for users of 2.6 kernels is found at ...
|
||||
ATA over Ethernet is a network protocol that provides simple access to
|
||||
block storage on the LAN.
|
||||
|
||||
http://www.coraid.com/SUPPORT/EtherDrive-HBA
|
||||
http://support.coraid.com/documents/AoEr11.txt
|
||||
|
||||
It has many tips and hints!
|
||||
The EtherDrive (R) HOWTO for 2.6 and 3.x kernels is found at ...
|
||||
|
||||
http://support.coraid.com/support/linux/EtherDrive-2.6-HOWTO.html
|
||||
|
||||
It has many tips and hints! Please see, especially, recommended
|
||||
tunings for virtual memory:
|
||||
|
||||
http://support.coraid.com/support/linux/EtherDrive-2.6-HOWTO-5.html#ss5.19
|
||||
|
||||
The aoetools are userland programs that are designed to work with this
|
||||
driver. The aoetools are on sourceforge.
|
||||
|
@ -23,20 +31,12 @@ CREATING DEVICE NODES
|
|||
There is a udev-install.sh script that shows how to install these
|
||||
rules on your system.
|
||||
|
||||
If you are not using udev, two scripts are provided in
|
||||
Documentation/aoe as examples of static device node creation for
|
||||
using the aoe driver.
|
||||
|
||||
rm -rf /dev/etherd
|
||||
sh Documentation/aoe/mkdevs.sh /dev/etherd
|
||||
|
||||
... or to make just one shelf's worth of block device nodes ...
|
||||
|
||||
sh Documentation/aoe/mkshelf.sh /dev/etherd 0
|
||||
|
||||
There is also an autoload script that shows how to edit
|
||||
/etc/modprobe.d/aoe.conf to ensure that the aoe module is loaded when
|
||||
necessary.
|
||||
necessary. Preloading the aoe module is preferable to autoloading,
|
||||
however, because AoE discovery takes a few seconds. It can be
|
||||
confusing when an AoE device is not present the first time the a
|
||||
command is run but appears a second later.
|
||||
|
||||
USING DEVICE NODES
|
||||
|
||||
|
@ -51,9 +51,9 @@ USING DEVICE NODES
|
|||
"echo > /dev/etherd/discover" tells the driver to find out what AoE
|
||||
devices are available.
|
||||
|
||||
These character devices may disappear and be replaced by sysfs
|
||||
counterparts. Using the commands in aoetools insulates users from
|
||||
these implementation details.
|
||||
In the future these character devices may disappear and be replaced
|
||||
by sysfs counterparts. Using the commands in aoetools insulates
|
||||
users from these implementation details.
|
||||
|
||||
The block devices are named like this:
|
||||
|
||||
|
@ -76,8 +76,8 @@ USING SYSFS
|
|||
The netif attribute is the network interface on the localhost
|
||||
through which we are communicating with the remote AoE device.
|
||||
|
||||
There is a script in this directory that formats this information
|
||||
in a convenient way. Users with aoetools can use the aoe-stat
|
||||
There is a script in this directory that formats this information in
|
||||
a convenient way. Users with aoetools should use the aoe-stat
|
||||
command.
|
||||
|
||||
root@makki root# sh Documentation/aoe/status.sh
|
||||
|
@ -121,3 +121,21 @@ DRIVER OPTIONS
|
|||
usage example for the module parameter.
|
||||
|
||||
modprobe aoe_iflist="eth1 eth3"
|
||||
|
||||
The aoe_deadsecs module parameter determines the maximum number of
|
||||
seconds that the driver will wait for an AoE device to provide a
|
||||
response to an AoE command. After aoe_deadsecs seconds have
|
||||
elapsed, the AoE device will be marked as "down".
|
||||
|
||||
The aoe_maxout module parameter has a default of 128. This is the
|
||||
maximum number of unresponded packets that will be sent to an AoE
|
||||
target at one time.
|
||||
|
||||
The aoe_dyndevs module parameter defaults to 1, meaning that the
|
||||
driver will assign a block device minor number to a discovered AoE
|
||||
target based on the order of its discovery. With dynamic minor
|
||||
device numbers in use, a greater range of AoE shelf and slot
|
||||
addresses can be supported. Users with udev will never have to
|
||||
think about minor numbers. Using aoe_dyndevs=0 allows device nodes
|
||||
to be pre-created using a static minor-number scheme with the
|
||||
aoe-mkshelf script in the aoetools.
|
||||
|
|
|
@ -1,41 +0,0 @@
|
|||
#!/bin/sh
|
||||
|
||||
n_shelves=${n_shelves:-10}
|
||||
n_partitions=${n_partitions:-16}
|
||||
|
||||
if test "$#" != "1"; then
|
||||
echo "Usage: sh `basename $0` {dir}" 1>&2
|
||||
echo " n_partitions=16 sh `basename $0` {dir}" 1>&2
|
||||
exit 1
|
||||
fi
|
||||
dir=$1
|
||||
|
||||
MAJOR=152
|
||||
|
||||
echo "Creating AoE devnode files in $dir ..."
|
||||
|
||||
set -e
|
||||
|
||||
mkdir -p $dir
|
||||
|
||||
# (Status info is in sysfs. See status.sh.)
|
||||
# rm -f $dir/stat
|
||||
# mknod -m 0400 $dir/stat c $MAJOR 1
|
||||
rm -f $dir/err
|
||||
mknod -m 0400 $dir/err c $MAJOR 2
|
||||
rm -f $dir/discover
|
||||
mknod -m 0200 $dir/discover c $MAJOR 3
|
||||
rm -f $dir/interfaces
|
||||
mknod -m 0200 $dir/interfaces c $MAJOR 4
|
||||
rm -f $dir/revalidate
|
||||
mknod -m 0200 $dir/revalidate c $MAJOR 5
|
||||
rm -f $dir/flush
|
||||
mknod -m 0200 $dir/flush c $MAJOR 6
|
||||
|
||||
export n_partitions
|
||||
mkshelf=`echo $0 | sed 's!mkdevs!mkshelf!'`
|
||||
i=0
|
||||
while test $i -lt $n_shelves; do
|
||||
sh -xc "sh $mkshelf $dir $i"
|
||||
i=`expr $i + 1`
|
||||
done
|
|
@ -1,28 +0,0 @@
|
|||
#! /bin/sh
|
||||
|
||||
if test "$#" != "2"; then
|
||||
echo "Usage: sh `basename $0` {dir} {shelfaddress}" 1>&2
|
||||
echo " n_partitions=16 sh `basename $0` {dir} {shelfaddress}" 1>&2
|
||||
exit 1
|
||||
fi
|
||||
n_partitions=${n_partitions:-16}
|
||||
dir=$1
|
||||
shelf=$2
|
||||
nslots=16
|
||||
maxslot=`echo $nslots 1 - p | dc`
|
||||
MAJOR=152
|
||||
|
||||
set -e
|
||||
|
||||
minor=`echo $nslots \* $shelf \* $n_partitions | bc`
|
||||
endp=`echo $n_partitions - 1 | bc`
|
||||
for slot in `seq 0 $maxslot`; do
|
||||
for part in `seq 0 $endp`; do
|
||||
name=e$shelf.$slot
|
||||
test "$part" != "0" && name=${name}p$part
|
||||
rm -f $dir/$name
|
||||
mknod -m 0660 $dir/$name b $MAJOR $minor
|
||||
|
||||
minor=`expr $minor + 1`
|
||||
done
|
||||
done
|
|
@ -1,5 +1,8 @@
|
|||
#! /bin/sh
|
||||
# collate and present sysfs information about AoE storage
|
||||
#
|
||||
# A more complete version of this script is aoe-stat, in the
|
||||
# aoetools.
|
||||
|
||||
set -e
|
||||
format="%8s\t%8s\t%8s\n"
|
||||
|
|
232
Documentation/arm/Marvell/README
Normal file
232
Documentation/arm/Marvell/README
Normal file
|
@ -0,0 +1,232 @@
|
|||
ARM Marvell SoCs
|
||||
================
|
||||
|
||||
This document lists all the ARM Marvell SoCs that are currently
|
||||
supported in mainline by the Linux kernel. As the Marvell families of
|
||||
SoCs are large and complex, it is hard to understand where the support
|
||||
for a particular SoC is available in the Linux kernel. This document
|
||||
tries to help in understanding where those SoCs are supported, and to
|
||||
match them with their corresponding public datasheet, when available.
|
||||
|
||||
Orion family
|
||||
------------
|
||||
|
||||
Flavors:
|
||||
88F5082
|
||||
88F5181
|
||||
88F5181L
|
||||
88F5182
|
||||
Datasheet : http://www.embeddedarm.com/documentation/third-party/MV88F5182-datasheet.pdf
|
||||
Programmer's User Guide : http://www.embeddedarm.com/documentation/third-party/MV88F5182-opensource-manual.pdf
|
||||
User Manual : http://www.embeddedarm.com/documentation/third-party/MV88F5182-usermanual.pdf
|
||||
88F5281
|
||||
Datasheet : http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf
|
||||
88F6183
|
||||
Core: Feroceon ARMv5 compatible
|
||||
Linux kernel mach directory: arch/arm/mach-orion5x
|
||||
Linux kernel plat directory: arch/arm/plat-orion
|
||||
|
||||
Kirkwood family
|
||||
---------------
|
||||
|
||||
Flavors:
|
||||
88F6282 a.k.a Armada 300
|
||||
Product Brief : http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf
|
||||
88F6283 a.k.a Armada 310
|
||||
Product Brief : http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf
|
||||
88F6190
|
||||
Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6190-003_WEB.pdf
|
||||
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
|
||||
88F6192
|
||||
Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6192-003_ver1.pdf
|
||||
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
|
||||
88F6182
|
||||
88F6180
|
||||
Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6180-003_ver1.pdf
|
||||
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
|
||||
88F6281
|
||||
Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6281-004_ver1.pdf
|
||||
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
|
||||
Homepage: http://www.marvell.com/embedded-processors/kirkwood/
|
||||
Core: Feroceon ARMv5 compatible
|
||||
Linux kernel mach directory: arch/arm/mach-kirkwood
|
||||
Linux kernel plat directory: arch/arm/plat-orion
|
||||
|
||||
Discovery family
|
||||
----------------
|
||||
|
||||
Flavors:
|
||||
MV78100
|
||||
Product Brief : http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78100-003_WEB.pdf
|
||||
Hardware Spec : http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV78100_OpenSource.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf
|
||||
MV78200
|
||||
Product Brief : http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78200-002_WEB.pdf
|
||||
Hardware Spec : http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV78200_OpenSource.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf
|
||||
MV76100
|
||||
Not supported by the Linux kernel.
|
||||
|
||||
Core: Feroceon ARMv5 compatible
|
||||
|
||||
Linux kernel mach directory: arch/arm/mach-mv78xx0
|
||||
Linux kernel plat directory: arch/arm/plat-orion
|
||||
|
||||
EBU Armada family
|
||||
-----------------
|
||||
|
||||
Armada 370 Flavors:
|
||||
88F6710
|
||||
88F6707
|
||||
88F6W11
|
||||
|
||||
Armada XP Flavors:
|
||||
MV78230
|
||||
MV78260
|
||||
MV78460
|
||||
|
||||
Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
|
||||
No public datasheet available.
|
||||
|
||||
Core: Sheeva ARMv7 compatible
|
||||
|
||||
Linux kernel mach directory: arch/arm/mach-mvebu
|
||||
Linux kernel plat directory: none
|
||||
|
||||
Avanta family
|
||||
-------------
|
||||
|
||||
Flavors:
|
||||
88F6510
|
||||
88F6530P
|
||||
88F6550
|
||||
88F6560
|
||||
Homepage : http://www.marvell.com/broadband/
|
||||
Product Brief: http://www.marvell.com/broadband/assets/Marvell_Avanta_88F6510_305_060-001_product_brief.pdf
|
||||
No public datasheet available.
|
||||
|
||||
Core: ARMv5 compatible
|
||||
|
||||
Linux kernel mach directory: no code in mainline yet, planned for the future
|
||||
Linux kernel plat directory: no code in mainline yet, planned for the future
|
||||
|
||||
Dove family (application processor)
|
||||
-----------------------------------
|
||||
|
||||
Flavors:
|
||||
88AP510 a.k.a Armada 510
|
||||
Product Brief : http://www.marvell.com/application-processors/armada-500/assets/Marvell_Armada510_SoC.pdf
|
||||
Hardware Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Hardware-Spec.pdf
|
||||
Functional Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf
|
||||
Homepage: http://www.marvell.com/application-processors/armada-500/
|
||||
Core: ARMv7 compatible
|
||||
Directory: arch/arm/mach-dove
|
||||
|
||||
PXA 2xx/3xx/93x/95x family
|
||||
--------------------------
|
||||
|
||||
Flavors:
|
||||
PXA21x, PXA25x, PXA26x
|
||||
Application processor only
|
||||
Core: ARMv5 XScale core
|
||||
PXA270, PXA271, PXA272
|
||||
Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_pb.pdf
|
||||
Design guide : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_design_guide.pdf
|
||||
Developers manual : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_dev_man.pdf
|
||||
Specification : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_emts.pdf
|
||||
Specification update : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_spec_update.pdf
|
||||
Application processor only
|
||||
Core: ARMv5 XScale core
|
||||
PXA300, PXA310, PXA320
|
||||
PXA 300 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA300_PB_R4.pdf
|
||||
PXA 310 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA310_PB_R4.pdf
|
||||
PXA 320 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA320_PB_R4.pdf
|
||||
Design guide : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Design_Guide.pdf
|
||||
Developers manual : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Developers_Manual.zip
|
||||
Specifications : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_EMTS.pdf
|
||||
Specification Update : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Spec_Update.zip
|
||||
Reference Manual : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_TavorP_BootROM_Ref_Manual.pdf
|
||||
Application processor only
|
||||
Core: ARMv5 XScale core
|
||||
PXA930, PXA935
|
||||
Application processor with Communication processor
|
||||
Core: ARMv5 XScale core
|
||||
PXA955
|
||||
Application processor with Communication processor
|
||||
Core: ARMv7 compatible Sheeva PJ4 core
|
||||
|
||||
Comments:
|
||||
|
||||
* This line of SoCs originates from the XScale family developed by
|
||||
Intel and acquired by Marvell in ~2006. The PXA21x, PXA25x,
|
||||
PXA26x, PXA27x, PXA3xx and PXA93x were developed by Intel, while
|
||||
the later PXA95x were developed by Marvell.
|
||||
|
||||
* Due to their XScale origin, these SoCs have virtually nothing in
|
||||
common with the other (Kirkwood, Dove, etc.) families of Marvell
|
||||
SoCs, except with the MMP/MMP2 family of SoCs.
|
||||
|
||||
Linux kernel mach directory: arch/arm/mach-pxa
|
||||
Linux kernel plat directory: arch/arm/plat-pxa
|
||||
|
||||
MMP/MMP2 family (communication processor)
|
||||
-----------------------------------------
|
||||
|
||||
Flavors:
|
||||
PXA168, a.k.a Armada 168
|
||||
Homepage : http://www.marvell.com/application-processors/armada-100/armada-168.jsp
|
||||
Product brief : http://www.marvell.com/application-processors/armada-100/assets/pxa_168_pb.pdf
|
||||
Hardware manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_datasheet.pdf
|
||||
Software manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_software_manual.pdf
|
||||
Specification update : http://www.marvell.com/application-processors/armada-100/assets/ARMADA16x_Spec_update.pdf
|
||||
Boot ROM manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_ref_manual.pdf
|
||||
App node package : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_app_note_package.pdf
|
||||
Application processor only
|
||||
Core: ARMv5 compatible Marvell PJ1 (Mohawk)
|
||||
PXA910
|
||||
Homepage : http://www.marvell.com/communication-processors/pxa910/
|
||||
Product Brief : http://www.marvell.com/communication-processors/pxa910/assets/Marvell_PXA910_Platform-001_PB_final.pdf
|
||||
Application processor with Communication processor
|
||||
Core: ARMv5 compatible Marvell PJ1 (Mohawk)
|
||||
MMP2, a.k.a Armada 610
|
||||
Product Brief : http://www.marvell.com/application-processors/armada-600/assets/armada610_pb.pdf
|
||||
Application processor only
|
||||
Core: ARMv7 compatible Sheeva PJ4 core
|
||||
|
||||
Comments:
|
||||
|
||||
* This line of SoCs originates from the XScale family developed by
|
||||
Intel and acquired by Marvell in ~2006. All the processors of
|
||||
this MMP/MMP2 family were developed by Marvell.
|
||||
|
||||
* Due to their XScale origin, these SoCs have virtually nothing in
|
||||
common with the other (Kirkwood, Dove, etc.) families of Marvell
|
||||
SoCs, except with the PXA family of SoCs listed above.
|
||||
|
||||
Linux kernel mach directory: arch/arm/mach-mmp
|
||||
Linux kernel plat directory: arch/arm/plat-pxa
|
||||
|
||||
Long-term plans
|
||||
---------------
|
||||
|
||||
* Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ and
|
||||
mach-kirkwood/ into the mach-mvebu/ to support all SoCs from the
|
||||
Marvell EBU (Engineering Business Unit) in a single mach-<foo>
|
||||
directory. The plat-orion/ would therefore disappear.
|
||||
|
||||
* Unify the mach-mmp/ and mach-pxa/ into the same mach-pxa
|
||||
directory. The plat-pxa/ would therefore disappear.
|
||||
|
||||
Credits
|
||||
-------
|
||||
|
||||
Maen Suleiman <maen@marvell.com>
|
||||
Lior Amsalem <alior@marvell.com>
|
||||
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
||||
Andrew Lunn <andrew@lunn.ch>
|
||||
Nicolas Pitre <nico@fluxnic.net>
|
||||
Eric Miao <eric.y.miao@gmail.com>
|
|
@ -1,4 +1,4 @@
|
|||
S3C2410 GPIO Control
|
||||
S3C24XX GPIO Control
|
||||
====================
|
||||
|
||||
Introduction
|
||||
|
@ -12,7 +12,7 @@ Introduction
|
|||
of the s3c2410 GPIO system, please read the Samsung provided
|
||||
data-sheet/users manual to find out the complete list.
|
||||
|
||||
See Documentation/arm/Samsung/GPIO.txt for the core implemetation.
|
||||
See Documentation/arm/Samsung/GPIO.txt for the core implementation.
|
||||
|
||||
|
||||
GPIOLIB
|
||||
|
@ -41,8 +41,8 @@ GPIOLIB
|
|||
GPIOLIB conversion
|
||||
------------------
|
||||
|
||||
If you need to convert your board or driver to use gpiolib from the exiting
|
||||
s3c2410 api, then here are some notes on the process.
|
||||
If you need to convert your board or driver to use gpiolib from the phased
|
||||
out s3c2410 API, then here are some notes on the process.
|
||||
|
||||
1) If your board is exclusively using an GPIO, say to control peripheral
|
||||
power, then it will require to claim the gpio with gpio_request() before
|
||||
|
@ -55,7 +55,7 @@ s3c2410 api, then here are some notes on the process.
|
|||
as they have the same arguments, and can either take the pin specific
|
||||
values, or the more generic special-function-number arguments.
|
||||
|
||||
3) s3c2410_gpio_pullup() changs have the problem that whilst the
|
||||
3) s3c2410_gpio_pullup() changes have the problem that whilst the
|
||||
s3c2410_gpio_pullup(x, 1) can be easily translated to the
|
||||
s3c_gpio_setpull(x, S3C_GPIO_PULL_NONE), the s3c2410_gpio_pullup(x, 0)
|
||||
are not so easy.
|
||||
|
@ -74,7 +74,7 @@ s3c2410 api, then here are some notes on the process.
|
|||
when using gpio_get_value() on an output pin (s3c2410_gpio_getpin
|
||||
would return the value the pin is supposed to be outputting).
|
||||
|
||||
6) s3c2410_gpio_getirq() should be directly replacable with the
|
||||
6) s3c2410_gpio_getirq() should be directly replaceable with the
|
||||
gpio_to_irq() call.
|
||||
|
||||
The s3c2410_gpio and gpio_ calls have always operated on the same gpio
|
||||
|
@ -105,7 +105,7 @@ PIN Numbers
|
|||
-----------
|
||||
|
||||
Each pin has an unique number associated with it in regs-gpio.h,
|
||||
eg S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell
|
||||
e.g. S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell
|
||||
the GPIO functions which pin is to be used.
|
||||
|
||||
With the conversion to gpiolib, there is no longer a direct conversion
|
||||
|
@ -120,31 +120,27 @@ Configuring a pin
|
|||
The following function allows the configuration of a given pin to
|
||||
be changed.
|
||||
|
||||
void s3c2410_gpio_cfgpin(unsigned int pin, unsigned int function);
|
||||
void s3c_gpio_cfgpin(unsigned int pin, unsigned int function);
|
||||
|
||||
Eg:
|
||||
e.g.:
|
||||
|
||||
s3c2410_gpio_cfgpin(S3C2410_GPA(0), S3C2410_GPA0_ADDR0);
|
||||
s3c2410_gpio_cfgpin(S3C2410_GPE(8), S3C2410_GPE8_SDDAT1);
|
||||
s3c_gpio_cfgpin(S3C2410_GPA(0), S3C_GPIO_SFN(1));
|
||||
s3c_gpio_cfgpin(S3C2410_GPE(8), S3C_GPIO_SFN(2));
|
||||
|
||||
which would turn GPA(0) into the lowest Address line A0, and set
|
||||
GPE(8) to be connected to the SDIO/MMC controller's SDDAT1 line.
|
||||
|
||||
The s3c_gpio_cfgpin() call is a functional replacement for this call.
|
||||
|
||||
|
||||
Reading the current configuration
|
||||
---------------------------------
|
||||
|
||||
The current configuration of a pin can be read by using:
|
||||
The current configuration of a pin can be read by using standard
|
||||
gpiolib function:
|
||||
|
||||
s3c2410_gpio_getcfg(unsigned int pin);
|
||||
s3c_gpio_getcfg(unsigned int pin);
|
||||
|
||||
The return value will be from the same set of values which can be
|
||||
passed to s3c2410_gpio_cfgpin().
|
||||
|
||||
The s3c_gpio_getcfg() call should be a functional replacement for
|
||||
this call.
|
||||
passed to s3c_gpio_cfgpin().
|
||||
|
||||
|
||||
Configuring a pull-up resistor
|
||||
|
@ -154,61 +150,33 @@ Configuring a pull-up resistor
|
|||
pull-up resistors enabled. This can be configured by the following
|
||||
function:
|
||||
|
||||
void s3c2410_gpio_pullup(unsigned int pin, unsigned int to);
|
||||
void s3c_gpio_setpull(unsigned int pin, unsigned int to);
|
||||
|
||||
Where the to value is zero to set the pull-up off, and 1 to enable
|
||||
the specified pull-up. Any other values are currently undefined.
|
||||
|
||||
The s3c_gpio_setpull() offers similar functionality, but with the
|
||||
ability to encode whether the pull is up or down. Currently there
|
||||
is no 'just on' state, so up or down must be selected.
|
||||
Where the to value is S3C_GPIO_PULL_NONE to set the pull-up off,
|
||||
and S3C_GPIO_PULL_UP to enable the specified pull-up. Any other
|
||||
values are currently undefined.
|
||||
|
||||
|
||||
Getting the state of a PIN
|
||||
--------------------------
|
||||
Getting and setting the state of a PIN
|
||||
--------------------------------------
|
||||
|
||||
The state of a pin can be read by using the function:
|
||||
|
||||
unsigned int s3c2410_gpio_getpin(unsigned int pin);
|
||||
|
||||
This will return either zero or non-zero. Do not count on this
|
||||
function returning 1 if the pin is set.
|
||||
|
||||
This call is now implemented by the relevant gpiolib calls, convert
|
||||
your board or driver to use gpiolib.
|
||||
|
||||
|
||||
Setting the state of a PIN
|
||||
--------------------------
|
||||
|
||||
The value an pin is outputing can be modified by using the following:
|
||||
|
||||
void s3c2410_gpio_setpin(unsigned int pin, unsigned int to);
|
||||
|
||||
Which sets the given pin to the value. Use 0 to write 0, and 1 to
|
||||
set the output to 1.
|
||||
|
||||
This call is now implemented by the relevant gpiolib calls, convert
|
||||
These calls are now implemented by the relevant gpiolib calls, convert
|
||||
your board or driver to use gpiolib.
|
||||
|
||||
|
||||
Getting the IRQ number associated with a PIN
|
||||
--------------------------------------------
|
||||
|
||||
The following function can map the given pin number to an IRQ
|
||||
A standard gpiolib function can map the given pin number to an IRQ
|
||||
number to pass to the IRQ system.
|
||||
|
||||
int s3c2410_gpio_getirq(unsigned int pin);
|
||||
int gpio_to_irq(unsigned int pin);
|
||||
|
||||
Note, not all pins have an IRQ.
|
||||
|
||||
This call is now implemented by the relevant gpiolib calls, convert
|
||||
your board or driver to use gpiolib.
|
||||
|
||||
|
||||
Authour
|
||||
Author
|
||||
-------
|
||||
|
||||
|
||||
Ben Dooks, 03 October 2004
|
||||
Copyright 2004 Ben Dooks, Simtec Electronics
|
||||
|
|
|
@ -5,14 +5,14 @@ Introduction
|
|||
------------
|
||||
|
||||
This outlines the Samsung GPIO implementation and the architecture
|
||||
specific calls provided alongisde the drivers/gpio core.
|
||||
specific calls provided alongside the drivers/gpio core.
|
||||
|
||||
|
||||
S3C24XX (Legacy)
|
||||
----------------
|
||||
|
||||
See Documentation/arm/Samsung-S3C24XX/GPIO.txt for more information
|
||||
about these devices. Their implementation is being brought into line
|
||||
about these devices. Their implementation has been brought into line
|
||||
with the core samsung implementation described in this document.
|
||||
|
||||
|
||||
|
@ -29,7 +29,7 @@ GPIO numbering is synchronised between the Samsung and gpiolib system.
|
|||
PIN configuration
|
||||
-----------------
|
||||
|
||||
Pin configuration is specific to the Samsung architecutre, with each SoC
|
||||
Pin configuration is specific to the Samsung architecture, with each SoC
|
||||
registering the necessary information for the core gpio configuration
|
||||
implementation to configure pins as necessary.
|
||||
|
||||
|
@ -38,5 +38,3 @@ driver or machine to change gpio configuration.
|
|||
|
||||
See arch/arm/plat-samsung/include/plat/gpio-cfg.h for more information
|
||||
on these functions.
|
||||
|
||||
|
||||
|
|
|
@ -51,6 +51,9 @@ ffc00000 ffefffff DMA memory mapping region. Memory returned
|
|||
ff000000 ffbfffff Reserved for future expansion of DMA
|
||||
mapping region.
|
||||
|
||||
fee00000 feffffff Mapping of PCI I/O space. This is a static
|
||||
mapping within the vmalloc space.
|
||||
|
||||
VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space.
|
||||
Memory returned by vmalloc/ioremap will
|
||||
be dynamically placed in this region.
|
||||
|
|
152
Documentation/arm64/booting.txt
Normal file
152
Documentation/arm64/booting.txt
Normal file
|
@ -0,0 +1,152 @@
|
|||
Booting AArch64 Linux
|
||||
=====================
|
||||
|
||||
Author: Will Deacon <will.deacon@arm.com>
|
||||
Date : 07 September 2012
|
||||
|
||||
This document is based on the ARM booting document by Russell King and
|
||||
is relevant to all public releases of the AArch64 Linux kernel.
|
||||
|
||||
The AArch64 exception model is made up of a number of exception levels
|
||||
(EL0 - EL3), with EL0 and EL1 having a secure and a non-secure
|
||||
counterpart. EL2 is the hypervisor level and exists only in non-secure
|
||||
mode. EL3 is the highest priority level and exists only in secure mode.
|
||||
|
||||
For the purposes of this document, we will use the term `boot loader'
|
||||
simply to define all software that executes on the CPU(s) before control
|
||||
is passed to the Linux kernel. This may include secure monitor and
|
||||
hypervisor code, or it may just be a handful of instructions for
|
||||
preparing a minimal boot environment.
|
||||
|
||||
Essentially, the boot loader should provide (as a minimum) the
|
||||
following:
|
||||
|
||||
1. Setup and initialise the RAM
|
||||
2. Setup the device tree
|
||||
3. Decompress the kernel image
|
||||
4. Call the kernel image
|
||||
|
||||
|
||||
1. Setup and initialise RAM
|
||||
---------------------------
|
||||
|
||||
Requirement: MANDATORY
|
||||
|
||||
The boot loader is expected to find and initialise all RAM that the
|
||||
kernel will use for volatile data storage in the system. It performs
|
||||
this in a machine dependent manner. (It may use internal algorithms
|
||||
to automatically locate and size all RAM, or it may use knowledge of
|
||||
the RAM in the machine, or any other method the boot loader designer
|
||||
sees fit.)
|
||||
|
||||
|
||||
2. Setup the device tree
|
||||
-------------------------
|
||||
|
||||
Requirement: MANDATORY
|
||||
|
||||
The device tree blob (dtb) must be no bigger than 2 megabytes in size
|
||||
and placed at a 2-megabyte boundary within the first 512 megabytes from
|
||||
the start of the kernel image. This is to allow the kernel to map the
|
||||
blob using a single section mapping in the initial page tables.
|
||||
|
||||
|
||||
3. Decompress the kernel image
|
||||
------------------------------
|
||||
|
||||
Requirement: OPTIONAL
|
||||
|
||||
The AArch64 kernel does not currently provide a decompressor and
|
||||
therefore requires decompression (gzip etc.) to be performed by the boot
|
||||
loader if a compressed Image target (e.g. Image.gz) is used. For
|
||||
bootloaders that do not implement this requirement, the uncompressed
|
||||
Image target is available instead.
|
||||
|
||||
|
||||
4. Call the kernel image
|
||||
------------------------
|
||||
|
||||
Requirement: MANDATORY
|
||||
|
||||
The decompressed kernel image contains a 32-byte header as follows:
|
||||
|
||||
u32 magic = 0x14000008; /* branch to stext, little-endian */
|
||||
u32 res0 = 0; /* reserved */
|
||||
u64 text_offset; /* Image load offset */
|
||||
u64 res1 = 0; /* reserved */
|
||||
u64 res2 = 0; /* reserved */
|
||||
|
||||
The image must be placed at the specified offset (currently 0x80000)
|
||||
from the start of the system RAM and called there. The start of the
|
||||
system RAM must be aligned to 2MB.
|
||||
|
||||
Before jumping into the kernel, the following conditions must be met:
|
||||
|
||||
- Quiesce all DMA capable devices so that memory does not get
|
||||
corrupted by bogus network packets or disk data. This will save
|
||||
you many hours of debug.
|
||||
|
||||
- Primary CPU general-purpose register settings
|
||||
x0 = physical address of device tree blob (dtb) in system RAM.
|
||||
x1 = 0 (reserved for future use)
|
||||
x2 = 0 (reserved for future use)
|
||||
x3 = 0 (reserved for future use)
|
||||
|
||||
- CPU mode
|
||||
All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError,
|
||||
IRQ and FIQ).
|
||||
The CPU must be in either EL2 (RECOMMENDED in order to have access to
|
||||
the virtualisation extensions) or non-secure EL1.
|
||||
|
||||
- Caches, MMUs
|
||||
The MMU must be off.
|
||||
Instruction cache may be on or off.
|
||||
Data cache must be off and invalidated.
|
||||
External caches (if present) must be configured and disabled.
|
||||
|
||||
- Architected timers
|
||||
CNTFRQ must be programmed with the timer frequency.
|
||||
If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0)
|
||||
set where available.
|
||||
|
||||
- Coherency
|
||||
All CPUs to be booted by the kernel must be part of the same coherency
|
||||
domain on entry to the kernel. This may require IMPLEMENTATION DEFINED
|
||||
initialisation to enable the receiving of maintenance operations on
|
||||
each CPU.
|
||||
|
||||
- System registers
|
||||
All writable architected system registers at the exception level where
|
||||
the kernel image will be entered must be initialised by software at a
|
||||
higher exception level to prevent execution in an UNKNOWN state.
|
||||
|
||||
The boot loader is expected to enter the kernel on each CPU in the
|
||||
following manner:
|
||||
|
||||
- The primary CPU must jump directly to the first instruction of the
|
||||
kernel image. The device tree blob passed by this CPU must contain
|
||||
for each CPU node:
|
||||
|
||||
1. An 'enable-method' property. Currently, the only supported value
|
||||
for this field is the string "spin-table".
|
||||
|
||||
2. A 'cpu-release-addr' property identifying a 64-bit,
|
||||
zero-initialised memory location.
|
||||
|
||||
It is expected that the bootloader will generate these device tree
|
||||
properties and insert them into the blob prior to kernel entry.
|
||||
|
||||
- Any secondary CPUs must spin outside of the kernel in a reserved area
|
||||
of memory (communicated to the kernel by a /memreserve/ region in the
|
||||
device tree) polling their cpu-release-addr location, which must be
|
||||
contained in the reserved region. A wfe instruction may be inserted
|
||||
to reduce the overhead of the busy-loop and a sev will be issued by
|
||||
the primary CPU. When a read of the location pointed to by the
|
||||
cpu-release-addr returns a non-zero value, the CPU must jump directly
|
||||
to this value.
|
||||
|
||||
- Secondary CPU general-purpose register settings
|
||||
x0 = 0 (reserved for future use)
|
||||
x1 = 0 (reserved for future use)
|
||||
x2 = 0 (reserved for future use)
|
||||
x3 = 0 (reserved for future use)
|
73
Documentation/arm64/memory.txt
Normal file
73
Documentation/arm64/memory.txt
Normal file
|
@ -0,0 +1,73 @@
|
|||
Memory Layout on AArch64 Linux
|
||||
==============================
|
||||
|
||||
Author: Catalin Marinas <catalin.marinas@arm.com>
|
||||
Date : 20 February 2012
|
||||
|
||||
This document describes the virtual memory layout used by the AArch64
|
||||
Linux kernel. The architecture allows up to 4 levels of translation
|
||||
tables with a 4KB page size and up to 3 levels with a 64KB page size.
|
||||
|
||||
AArch64 Linux uses 3 levels of translation tables with the 4KB page
|
||||
configuration, allowing 39-bit (512GB) virtual addresses for both user
|
||||
and kernel. With 64KB pages, only 2 levels of translation tables are
|
||||
used but the memory layout is the same.
|
||||
|
||||
User addresses have bits 63:39 set to 0 while the kernel addresses have
|
||||
the same bits set to 1. TTBRx selection is given by bit 63 of the
|
||||
virtual address. The swapper_pg_dir contains only kernel (global)
|
||||
mappings while the user pgd contains only user (non-global) mappings.
|
||||
The swapper_pgd_dir address is written to TTBR1 and never written to
|
||||
TTBR0.
|
||||
|
||||
|
||||
AArch64 Linux memory layout:
|
||||
|
||||
Start End Size Use
|
||||
-----------------------------------------------------------------------
|
||||
0000000000000000 0000007fffffffff 512GB user
|
||||
|
||||
ffffff8000000000 ffffffbbfffcffff ~240GB vmalloc
|
||||
|
||||
ffffffbbfffd0000 ffffffbcfffdffff 64KB [guard page]
|
||||
|
||||
ffffffbbfffe0000 ffffffbcfffeffff 64KB PCI I/O space
|
||||
|
||||
ffffffbbffff0000 ffffffbcffffffff 64KB [guard page]
|
||||
|
||||
ffffffbc00000000 ffffffbdffffffff 8GB vmemmap
|
||||
|
||||
ffffffbe00000000 ffffffbffbffffff ~8GB [guard, future vmmemap]
|
||||
|
||||
ffffffbffc000000 ffffffbfffffffff 64MB modules
|
||||
|
||||
ffffffc000000000 ffffffffffffffff 256GB memory
|
||||
|
||||
|
||||
Translation table lookup with 4KB pages:
|
||||
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
| | | | | |
|
||||
| | | | | v
|
||||
| | | | | [11:0] in-page offset
|
||||
| | | | +-> [20:12] L3 index
|
||||
| | | +-----------> [29:21] L2 index
|
||||
| | +---------------------> [38:30] L1 index
|
||||
| +-------------------------------> [47:39] L0 index (not used)
|
||||
+-------------------------------------------------> [63] TTBR0/1
|
||||
|
||||
|
||||
Translation table lookup with 64KB pages:
|
||||
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
| | | | |
|
||||
| | | | v
|
||||
| | | | [15:0] in-page offset
|
||||
| | | +----------> [28:16] L3 index
|
||||
| | +--------------------------> [41:29] L2 index (only 38:29 used)
|
||||
| +-------------------------------> [47:42] L1 index (not used)
|
||||
+-------------------------------------------------> [63] TTBR0/1
|
|
@ -29,7 +29,8 @@ CONTENTS:
|
|||
3.1 Overview
|
||||
3.2 Synchronization
|
||||
3.3 Subsystem API
|
||||
4. Questions
|
||||
4. Extended attributes usage
|
||||
5. Questions
|
||||
|
||||
1. Control Groups
|
||||
=================
|
||||
|
@ -62,9 +63,9 @@ an instance of the cgroup virtual filesystem associated with it.
|
|||
At any one time there may be multiple active hierarchies of task
|
||||
cgroups. Each hierarchy is a partition of all tasks in the system.
|
||||
|
||||
User level code may create and destroy cgroups by name in an
|
||||
User-level code may create and destroy cgroups by name in an
|
||||
instance of the cgroup virtual file system, specify and query to
|
||||
which cgroup a task is assigned, and list the task pids assigned to
|
||||
which cgroup a task is assigned, and list the task PIDs assigned to
|
||||
a cgroup. Those creations and assignments only affect the hierarchy
|
||||
associated with that instance of the cgroup file system.
|
||||
|
||||
|
@ -72,7 +73,7 @@ On their own, the only use for cgroups is for simple job
|
|||
tracking. The intention is that other subsystems hook into the generic
|
||||
cgroup support to provide new attributes for cgroups, such as
|
||||
accounting/limiting the resources which processes in a cgroup can
|
||||
access. For example, cpusets (see Documentation/cgroups/cpusets.txt) allows
|
||||
access. For example, cpusets (see Documentation/cgroups/cpusets.txt) allow
|
||||
you to associate a set of CPUs and a set of memory nodes with the
|
||||
tasks in each cgroup.
|
||||
|
||||
|
@ -80,11 +81,11 @@ tasks in each cgroup.
|
|||
----------------------------
|
||||
|
||||
There are multiple efforts to provide process aggregations in the
|
||||
Linux kernel, mainly for resource tracking purposes. Such efforts
|
||||
Linux kernel, mainly for resource-tracking purposes. Such efforts
|
||||
include cpusets, CKRM/ResGroups, UserBeanCounters, and virtual server
|
||||
namespaces. These all require the basic notion of a
|
||||
grouping/partitioning of processes, with newly forked processes ending
|
||||
in the same group (cgroup) as their parent process.
|
||||
up in the same group (cgroup) as their parent process.
|
||||
|
||||
The kernel cgroup patch provides the minimum essential kernel
|
||||
mechanisms required to efficiently implement such groups. It has
|
||||
|
@ -127,14 +128,14 @@ following lines:
|
|||
/ \
|
||||
Professors (15%) students (5%)
|
||||
|
||||
Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go
|
||||
into NFS network class.
|
||||
Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd goes
|
||||
into the NFS network class.
|
||||
|
||||
At the same time Firefox/Lynx will share an appropriate CPU/Memory class
|
||||
depending on who launched it (prof/student).
|
||||
|
||||
With the ability to classify tasks differently for different resources
|
||||
(by putting those resource subsystems in different hierarchies) then
|
||||
(by putting those resource subsystems in different hierarchies),
|
||||
the admin can easily set up a script which receives exec notifications
|
||||
and depending on who is launching the browser he can
|
||||
|
||||
|
@ -145,19 +146,19 @@ a separate cgroup for every browser launched and associate it with
|
|||
appropriate network and other resource class. This may lead to
|
||||
proliferation of such cgroups.
|
||||
|
||||
Also lets say that the administrator would like to give enhanced network
|
||||
Also let's say that the administrator would like to give enhanced network
|
||||
access temporarily to a student's browser (since it is night and the user
|
||||
wants to do online gaming :)) OR give one of the students simulation
|
||||
apps enhanced CPU power,
|
||||
wants to do online gaming :)) OR give one of the student's simulation
|
||||
apps enhanced CPU power.
|
||||
|
||||
With ability to write pids directly to resource classes, it's just a
|
||||
matter of :
|
||||
With ability to write PIDs directly to resource classes, it's just a
|
||||
matter of:
|
||||
|
||||
# echo pid > /sys/fs/cgroup/network/<new_class>/tasks
|
||||
(after some time)
|
||||
# echo pid > /sys/fs/cgroup/network/<orig_class>/tasks
|
||||
|
||||
Without this ability, he would have to split the cgroup into
|
||||
Without this ability, the administrator would have to split the cgroup into
|
||||
multiple separate ones and then associate the new cgroups with the
|
||||
new resource classes.
|
||||
|
||||
|
@ -184,20 +185,20 @@ Control Groups extends the kernel as follows:
|
|||
field of each task_struct using the css_set, anchored at
|
||||
css_set->tasks.
|
||||
|
||||
- A cgroup hierarchy filesystem can be mounted for browsing and
|
||||
- A cgroup hierarchy filesystem can be mounted for browsing and
|
||||
manipulation from user space.
|
||||
|
||||
- You can list all the tasks (by pid) attached to any cgroup.
|
||||
- You can list all the tasks (by PID) attached to any cgroup.
|
||||
|
||||
The implementation of cgroups requires a few, simple hooks
|
||||
into the rest of the kernel, none in performance critical paths:
|
||||
into the rest of the kernel, none in performance-critical paths:
|
||||
|
||||
- in init/main.c, to initialize the root cgroups and initial
|
||||
css_set at system boot.
|
||||
|
||||
- in fork and exit, to attach and detach a task from its css_set.
|
||||
|
||||
In addition a new file system, of type "cgroup" may be mounted, to
|
||||
In addition, a new file system of type "cgroup" may be mounted, to
|
||||
enable browsing and modifying the cgroups presently known to the
|
||||
kernel. When mounting a cgroup hierarchy, you may specify a
|
||||
comma-separated list of subsystems to mount as the filesystem mount
|
||||
|
@ -230,13 +231,13 @@ as the path relative to the root of the cgroup file system.
|
|||
Each cgroup is represented by a directory in the cgroup file system
|
||||
containing the following files describing that cgroup:
|
||||
|
||||
- tasks: list of tasks (by pid) attached to that cgroup. This list
|
||||
is not guaranteed to be sorted. Writing a thread id into this file
|
||||
- tasks: list of tasks (by PID) attached to that cgroup. This list
|
||||
is not guaranteed to be sorted. Writing a thread ID into this file
|
||||
moves the thread into this cgroup.
|
||||
- cgroup.procs: list of tgids in the cgroup. This list is not
|
||||
guaranteed to be sorted or free of duplicate tgids, and userspace
|
||||
- cgroup.procs: list of thread group IDs in the cgroup. This list is
|
||||
not guaranteed to be sorted or free of duplicate TGIDs, and userspace
|
||||
should sort/uniquify the list if this property is required.
|
||||
Writing a thread group id into this file moves all threads in that
|
||||
Writing a thread group ID into this file moves all threads in that
|
||||
group into this cgroup.
|
||||
- notify_on_release flag: run the release agent on exit?
|
||||
- release_agent: the path to use for release notifications (this file
|
||||
|
@ -261,7 +262,7 @@ cgroup file system directories.
|
|||
|
||||
When a task is moved from one cgroup to another, it gets a new
|
||||
css_set pointer - if there's an already existing css_set with the
|
||||
desired collection of cgroups then that group is reused, else a new
|
||||
desired collection of cgroups then that group is reused, otherwise a new
|
||||
css_set is allocated. The appropriate existing css_set is located by
|
||||
looking into a hash table.
|
||||
|
||||
|
@ -292,7 +293,7 @@ file system) of the abandoned cgroup. This enables automatic
|
|||
removal of abandoned cgroups. The default value of
|
||||
notify_on_release in the root cgroup at system boot is disabled
|
||||
(0). The default value of other cgroups at creation is the current
|
||||
value of their parents notify_on_release setting. The default value of
|
||||
value of their parents' notify_on_release settings. The default value of
|
||||
a cgroup hierarchy's release_agent path is empty.
|
||||
|
||||
1.5 What does clone_children do ?
|
||||
|
@ -316,7 +317,7 @@ the "cpuset" cgroup subsystem, the steps are something like:
|
|||
4) Create the new cgroup by doing mkdir's and write's (or echo's) in
|
||||
the /sys/fs/cgroup virtual file system.
|
||||
5) Start a task that will be the "founding father" of the new job.
|
||||
6) Attach that task to the new cgroup by writing its pid to the
|
||||
6) Attach that task to the new cgroup by writing its PID to the
|
||||
/sys/fs/cgroup/cpuset/tasks file for that cgroup.
|
||||
7) fork, exec or clone the job tasks from this founding father task.
|
||||
|
||||
|
@ -344,7 +345,7 @@ and then start a subshell 'sh' in that cgroup:
|
|||
2.1 Basic Usage
|
||||
---------------
|
||||
|
||||
Creating, modifying, using the cgroups can be done through the cgroup
|
||||
Creating, modifying, using cgroups can be done through the cgroup
|
||||
virtual filesystem.
|
||||
|
||||
To mount a cgroup hierarchy with all available subsystems, type:
|
||||
|
@ -441,7 +442,7 @@ You can attach the current shell task by echoing 0:
|
|||
# echo 0 > tasks
|
||||
|
||||
You can use the cgroup.procs file instead of the tasks file to move all
|
||||
threads in a threadgroup at once. Echoing the pid of any task in a
|
||||
threads in a threadgroup at once. Echoing the PID of any task in a
|
||||
threadgroup to cgroup.procs causes all tasks in that threadgroup to be
|
||||
be attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
|
||||
in the writing task's threadgroup.
|
||||
|
@ -479,7 +480,7 @@ in /proc/mounts and /proc/<pid>/cgroups.
|
|||
There is mechanism which allows to get notifications about changing
|
||||
status of a cgroup.
|
||||
|
||||
To register new notification handler you need:
|
||||
To register a new notification handler you need to:
|
||||
- create a file descriptor for event notification using eventfd(2);
|
||||
- open a control file to be monitored (e.g. memory.usage_in_bytes);
|
||||
- write "<event_fd> <control_fd> <args>" to cgroup.event_control.
|
||||
|
@ -488,7 +489,7 @@ To register new notification handler you need:
|
|||
eventfd will be woken up by control file implementation or when the
|
||||
cgroup is removed.
|
||||
|
||||
To unregister notification handler just close eventfd.
|
||||
To unregister a notification handler just close eventfd.
|
||||
|
||||
NOTE: Support of notifications should be implemented for the control
|
||||
file. See documentation for the subsystem.
|
||||
|
@ -502,7 +503,7 @@ file. See documentation for the subsystem.
|
|||
Each kernel subsystem that wants to hook into the generic cgroup
|
||||
system needs to create a cgroup_subsys object. This contains
|
||||
various methods, which are callbacks from the cgroup system, along
|
||||
with a subsystem id which will be assigned by the cgroup system.
|
||||
with a subsystem ID which will be assigned by the cgroup system.
|
||||
|
||||
Other fields in the cgroup_subsys object include:
|
||||
|
||||
|
@ -516,7 +517,7 @@ Other fields in the cgroup_subsys object include:
|
|||
at system boot.
|
||||
|
||||
Each cgroup object created by the system has an array of pointers,
|
||||
indexed by subsystem id; this pointer is entirely managed by the
|
||||
indexed by subsystem ID; this pointer is entirely managed by the
|
||||
subsystem; the generic cgroup code will never touch this pointer.
|
||||
|
||||
3.2 Synchronization
|
||||
|
@ -639,7 +640,7 @@ void post_clone(struct cgroup *cgrp)
|
|||
|
||||
Called during cgroup_create() to do any parameter
|
||||
initialization which might be required before a task could attach. For
|
||||
example in cpusets, no task may attach before 'cpus' and 'mems' are set
|
||||
example, in cpusets, no task may attach before 'cpus' and 'mems' are set
|
||||
up.
|
||||
|
||||
void bind(struct cgroup *root)
|
||||
|
@ -650,7 +651,26 @@ and root cgroup. Currently this will only involve movement between
|
|||
the default hierarchy (which never has sub-cgroups) and a hierarchy
|
||||
that is being created/destroyed (and hence has no sub-cgroups).
|
||||
|
||||
4. Questions
|
||||
4. Extended attribute usage
|
||||
===========================
|
||||
|
||||
cgroup filesystem supports certain types of extended attributes in its
|
||||
directories and files. The current supported types are:
|
||||
- Trusted (XATTR_TRUSTED)
|
||||
- Security (XATTR_SECURITY)
|
||||
|
||||
Both require CAP_SYS_ADMIN capability to set.
|
||||
|
||||
Like in tmpfs, the extended attributes in cgroup filesystem are stored
|
||||
using kernel memory and it's advised to keep the usage at minimum. This
|
||||
is the reason why user defined extended attributes are not supported, since
|
||||
any user can do it and there's no limit in the value size.
|
||||
|
||||
The current known users for this feature are SELinux to limit cgroup usage
|
||||
in containers and systemd for assorted meta data like main PID in a cgroup
|
||||
(systemd creates a cgroup per service).
|
||||
|
||||
5. Questions
|
||||
============
|
||||
|
||||
Q: what's up with this '/bin/echo' ?
|
||||
|
@ -660,5 +680,5 @@ A: bash's builtin 'echo' command does not check calls to write() against
|
|||
|
||||
Q: When I attach processes, only the first of the line gets really attached !
|
||||
A: We can only return one error code per call to write(). So you should also
|
||||
put only ONE pid.
|
||||
put only ONE PID.
|
||||
|
||||
|
|
93
Documentation/cpu-freq/boost.txt
Normal file
93
Documentation/cpu-freq/boost.txt
Normal file
|
@ -0,0 +1,93 @@
|
|||
Processor boosting control
|
||||
|
||||
- information for users -
|
||||
|
||||
Quick guide for the impatient:
|
||||
--------------------
|
||||
/sys/devices/system/cpu/cpufreq/boost
|
||||
controls the boost setting for the whole system. You can read and write
|
||||
that file with either "0" (boosting disabled) or "1" (boosting allowed).
|
||||
Reading or writing 1 does not mean that the system is boosting at this
|
||||
very moment, but only that the CPU _may_ raise the frequency at it's
|
||||
discretion.
|
||||
--------------------
|
||||
|
||||
Introduction
|
||||
-------------
|
||||
Some CPUs support a functionality to raise the operating frequency of
|
||||
some cores in a multi-core package if certain conditions apply, mostly
|
||||
if the whole chip is not fully utilized and below it's intended thermal
|
||||
budget. This is done without operating system control by a combination
|
||||
of hardware and firmware.
|
||||
On Intel CPUs this is called "Turbo Boost", AMD calls it "Turbo-Core",
|
||||
in technical documentation "Core performance boost". In Linux we use
|
||||
the term "boost" for convenience.
|
||||
|
||||
Rationale for disable switch
|
||||
----------------------------
|
||||
|
||||
Though the idea is to just give better performance without any user
|
||||
intervention, sometimes the need arises to disable this functionality.
|
||||
Most systems offer a switch in the (BIOS) firmware to disable the
|
||||
functionality at all, but a more fine-grained and dynamic control would
|
||||
be desirable:
|
||||
1. While running benchmarks, reproducible results are important. Since
|
||||
the boosting functionality depends on the load of the whole package,
|
||||
single thread performance can vary. By explicitly disabling the boost
|
||||
functionality at least for the benchmark's run-time the system will run
|
||||
at a fixed frequency and results are reproducible again.
|
||||
2. To examine the impact of the boosting functionality it is helpful
|
||||
to do tests with and without boosting.
|
||||
3. Boosting means overclocking the processor, though under controlled
|
||||
conditions. By raising the frequency and the voltage the processor
|
||||
will consume more power than without the boosting, which may be
|
||||
undesirable for instance for mobile users. Disabling boosting may
|
||||
save power here, though this depends on the workload.
|
||||
|
||||
|
||||
User controlled switch
|
||||
----------------------
|
||||
|
||||
To allow the user to toggle the boosting functionality, the acpi-cpufreq
|
||||
driver exports a sysfs knob to disable it. There is a file:
|
||||
/sys/devices/system/cpu/cpufreq/boost
|
||||
which can either read "0" (boosting disabled) or "1" (boosting enabled).
|
||||
Reading the file is always supported, even if the processor does not
|
||||
support boosting. In this case the file will be read-only and always
|
||||
reads as "0". Explicitly changing the permissions and writing to that
|
||||
file anyway will return EINVAL.
|
||||
|
||||
On supported CPUs one can write either a "0" or a "1" into this file.
|
||||
This will either disable the boost functionality on all cores in the
|
||||
whole system (0) or will allow the hardware to boost at will (1).
|
||||
|
||||
Writing a "1" does not explicitly boost the system, but just allows the
|
||||
CPU (and the firmware) to boost at their discretion. Some implementations
|
||||
take external factors like the chip's temperature into account, so
|
||||
boosting once does not necessarily mean that it will occur every time
|
||||
even using the exact same software setup.
|
||||
|
||||
|
||||
AMD legacy cpb switch
|
||||
---------------------
|
||||
The AMD powernow-k8 driver used to support a very similar switch to
|
||||
disable or enable the "Core Performance Boost" feature of some AMD CPUs.
|
||||
This switch was instantiated in each CPU's cpufreq directory
|
||||
(/sys/devices/system/cpu[0-9]*/cpufreq) and was called "cpb".
|
||||
Though the per CPU existence hints at a more fine grained control, the
|
||||
actual implementation only supported a system-global switch semantics,
|
||||
which was simply reflected into each CPU's file. Writing a 0 or 1 into it
|
||||
would pull the other CPUs to the same state.
|
||||
For compatibility reasons this file and its behavior is still supported
|
||||
on AMD CPUs, though it is now protected by a config switch
|
||||
(X86_ACPI_CPUFREQ_CPB). On Intel CPUs this file will never be created,
|
||||
even with the config option set.
|
||||
This functionality is considered legacy and will be removed in some future
|
||||
kernel version.
|
||||
|
||||
More fine grained boosting control
|
||||
----------------------------------
|
||||
|
||||
Technically it is possible to switch the boosting functionality at least
|
||||
on a per package basis, for some CPUs even per core. Currently the driver
|
||||
does not support it, but this may be implemented in the future.
|
|
@ -76,9 +76,17 @@ total 0
|
|||
|
||||
|
||||
* desc : Small description about the idle state (string)
|
||||
* disable : Option to disable this idle state (bool)
|
||||
* disable : Option to disable this idle state (bool) -> see note below
|
||||
* latency : Latency to exit out of this idle state (in microseconds)
|
||||
* name : Name of the idle state (string)
|
||||
* power : Power consumed while in this idle state (in milliwatts)
|
||||
* time : Total time spent in this idle state (in microseconds)
|
||||
* usage : Number of times this state was entered (count)
|
||||
|
||||
Note:
|
||||
The behavior and the effect of the disable variable depends on the
|
||||
implementation of a particular governor. In the ladder governor, for
|
||||
example, it is not coherent, i.e. if one is disabling a light state,
|
||||
then all deeper states are disabled as well, but the disable variable
|
||||
does not reflect it. Likewise, if one enables a deep state but a lighter
|
||||
state still is disabled, then this has no effect.
|
||||
|
|
|
@ -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
|
||||
|
|
8
Documentation/devicetree/bindings/arm/bcm2835.txt
Normal file
8
Documentation/devicetree/bindings/arm/bcm2835.txt
Normal file
|
@ -0,0 +1,8 @@
|
|||
Broadcom BCM2835 device tree bindings
|
||||
-------------------------------------------
|
||||
|
||||
Boards with the BCM2835 SoC shall have the following properties:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible = "brcm,bcm2835";
|
17
Documentation/devicetree/bindings/arm/calxeda/combophy.txt
Normal file
17
Documentation/devicetree/bindings/arm/calxeda/combophy.txt
Normal file
|
@ -0,0 +1,17 @@
|
|||
Calxeda Highbank Combination Phys for SATA
|
||||
|
||||
Properties:
|
||||
- compatible : Should be "calxeda,hb-combophy"
|
||||
- #phy-cells: Should be 1.
|
||||
- reg : Address and size for Combination Phy registers.
|
||||
- phydev: device ID for programming the combophy.
|
||||
|
||||
Example:
|
||||
|
||||
combophy5: combo-phy@fff5d000 {
|
||||
compatible = "calxeda,hb-combophy";
|
||||
#phy-cells = <1>;
|
||||
reg = <0xfff5d000 0x1000>;
|
||||
phydev = <31>;
|
||||
};
|
||||
|
17
Documentation/devicetree/bindings/arm/mrvl/tauros2.txt
Normal file
17
Documentation/devicetree/bindings/arm/mrvl/tauros2.txt
Normal file
|
@ -0,0 +1,17 @@
|
|||
* Marvell Tauros2 Cache
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "marvell,tauros2-cache".
|
||||
- marvell,tauros2-cache-features : Specify the features supported for the
|
||||
tauros2 cache.
|
||||
The features including
|
||||
CACHE_TAUROS2_PREFETCH_ON (1 << 0)
|
||||
CACHE_TAUROS2_LINEFILL_BURST8 (1 << 1)
|
||||
The definition can be found at
|
||||
arch/arm/include/asm/hardware/cache-tauros2.h
|
||||
|
||||
Example:
|
||||
L2: l2-cache {
|
||||
compatible = "marvell,tauros2-cache";
|
||||
marvell,tauros2-cache-features = <0x3>;
|
||||
};
|
38
Documentation/devicetree/bindings/arm/msm/timer.txt
Normal file
38
Documentation/devicetree/bindings/arm/msm/timer.txt
Normal file
|
@ -0,0 +1,38 @@
|
|||
* MSM Timer
|
||||
|
||||
Properties:
|
||||
|
||||
- compatible : Should at least contain "qcom,msm-timer". More specific
|
||||
properties such as "qcom,msm-gpt" and "qcom,msm-dgt" specify a general
|
||||
purpose timer and a debug timer respectively.
|
||||
|
||||
- interrupts : Interrupt indicating a match event.
|
||||
|
||||
- reg : Specifies the base address of the timer registers. The second region
|
||||
specifies an optional register used to configure the clock divider.
|
||||
|
||||
- clock-frequency : The frequency of the timer in Hz.
|
||||
|
||||
Optional:
|
||||
|
||||
- cpu-offset : per-cpu offset used when the timer is accessed without the
|
||||
CPU remapping facilities. The offset is cpu-offset * cpu-nr.
|
||||
|
||||
Example:
|
||||
|
||||
timer@200a004 {
|
||||
compatible = "qcom,msm-gpt", "qcom,msm-timer";
|
||||
interrupts = <1 2 0x301>;
|
||||
reg = <0x0200a004 0x10>;
|
||||
clock-frequency = <32768>;
|
||||
cpu-offset = <0x40000>;
|
||||
};
|
||||
|
||||
timer@200a024 {
|
||||
compatible = "qcom,msm-dgt", "qcom,msm-timer";
|
||||
interrupts = <1 3 0x301>;
|
||||
reg = <0x0200a024 0x10>,
|
||||
<0x0200a034 0x4>;
|
||||
clock-frequency = <6750000>;
|
||||
cpu-offset = <0x40000>;
|
||||
};
|
|
@ -36,6 +36,9 @@ Boards:
|
|||
- OMAP3 BeagleBoard : Low cost community board
|
||||
compatible = "ti,omap3-beagle", "ti,omap3"
|
||||
|
||||
- OMAP3 Tobi with Overo : Commercial expansion board with daughter board
|
||||
compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3"
|
||||
|
||||
- OMAP4 SDP : Software Developement Board
|
||||
compatible = "ti,omap4-sdp", "ti,omap4430"
|
||||
|
||||
|
|
|
@ -7,8 +7,12 @@ representation in the device tree should be done as under:-
|
|||
Required properties:
|
||||
|
||||
- compatible : should be one of
|
||||
"arm,cortex-a15-pmu"
|
||||
"arm,cortex-a9-pmu"
|
||||
"arm,cortex-a8-pmu"
|
||||
"arm,cortex-a7-pmu"
|
||||
"arm,cortex-a5-pmu"
|
||||
"arm,arm11mpcore-pmu"
|
||||
"arm,arm1176-pmu"
|
||||
"arm,arm1136-pmu"
|
||||
- interrupts : 1 combined interrupt or 1 per core.
|
||||
|
|
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>;
|
||||
};
|
14
Documentation/devicetree/bindings/arm/vt8500.txt
Normal file
14
Documentation/devicetree/bindings/arm/vt8500.txt
Normal file
|
@ -0,0 +1,14 @@
|
|||
VIA/Wondermedia VT8500 Platforms Device Tree Bindings
|
||||
---------------------------------------
|
||||
|
||||
Boards with the VIA VT8500 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "via,vt8500";
|
||||
|
||||
Boards with the Wondermedia WM8505 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "wm,wm8505";
|
||||
|
||||
Boards with the Wondermedia WM8650 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "wm,wm8650";
|
|
@ -0,0 +1,16 @@
|
|||
VIA/Wondermedia VT8500 Interrupt Controller
|
||||
-----------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible : "via,vt8500-intc"
|
||||
- reg : Should contain 1 register ranges(address and length)
|
||||
- #interrupt-cells : should be <1>
|
||||
|
||||
Example:
|
||||
|
||||
intc: interrupt-controller@d8140000 {
|
||||
compatible = "via,vt8500-intc";
|
||||
interrupt-controller;
|
||||
reg = <0xd8140000 0x10000>;
|
||||
#interrupt-cells = <1>;
|
||||
};
|
|
@ -0,0 +1,13 @@
|
|||
VIA/Wondermedia VT8500 Power Management Controller
|
||||
-----------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible : "via,vt8500-pmc"
|
||||
- reg : Should contain 1 register ranges(address and length)
|
||||
|
||||
Example:
|
||||
|
||||
pmc@d8130000 {
|
||||
compatible = "via,vt8500-pmc";
|
||||
reg = <0xd8130000 0x1000>;
|
||||
};
|
|
@ -0,0 +1,15 @@
|
|||
VIA/Wondermedia VT8500 Timer
|
||||
-----------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible : "via,vt8500-timer"
|
||||
- reg : Should contain 1 register ranges(address and length)
|
||||
- interrupts : interrupt for the timer
|
||||
|
||||
Example:
|
||||
|
||||
timer@d8130100 {
|
||||
compatible = "via,vt8500-timer";
|
||||
reg = <0xd8130100 0x28>;
|
||||
interrupts = <36>;
|
||||
};
|
25
Documentation/devicetree/bindings/arm/xen.txt
Normal file
25
Documentation/devicetree/bindings/arm/xen.txt
Normal file
|
@ -0,0 +1,25 @@
|
|||
* Xen hypervisor device tree bindings
|
||||
|
||||
Xen ARM virtual platforms shall have a top-level "hypervisor" node with
|
||||
the following properties:
|
||||
|
||||
- compatible:
|
||||
compatible = "xen,xen-<version>", "xen,xen";
|
||||
where <version> is the version of the Xen ABI of the platform.
|
||||
|
||||
- reg: specifies the base physical address and size of a region in
|
||||
memory where the grant table should be mapped to, using an
|
||||
HYPERVISOR_memory_op hypercall. The memory region is large enough to map
|
||||
the whole grant table (it is larger or equal to gnttab_max_grant_frames()).
|
||||
|
||||
- interrupts: the interrupt used by Xen to inject event notifications.
|
||||
A GIC node is also required.
|
||||
|
||||
|
||||
Example (assuming #address-cells = <2> and #size-cells = <2>):
|
||||
|
||||
hypervisor {
|
||||
compatible = "xen,xen-4.3", "xen,xen";
|
||||
reg = <0 0xb0000000 0 0x20000>;
|
||||
interrupts = <1 15 0xf08>;
|
||||
};
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Reference in a new issue