UAPI Disintegration 2012-10-09
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIVAwUAUHPmWxOxKuMESys7AQKN4w//XDwALfbf0MXIw+gwyRiUtJe9mGexvI6X 1R4FWU9a3ImzEZP4cWnmPGT2wmC/x007DcIvx8cyvbdlSuqtR2i/DC+HbWabiLRn nJS7Eer1BJvLv5dn6NmXMEz7yB4Z46+frcmBs3WQeR0sqBMDm+rjQzCqECznO8Jc VtCbox+VR2DuWcM++YECTblYEH3Z+doDXUN2eBaD8L9x3klPbPXD7OcRyOnry8w+ ynmUTKKyH4+hpxDakYrObPIg+vFCxb4QRck1mlgA4wbvb3eqjhM0oOCYJ8GvmILA vdFYztWCjkiuOl5djtXBlsClX8SAMOBYlRed+R1GvjNCSR+WCWrFJJ2F8qoQ1w87 9ts2/8qrozS8luTB475SkT2uLdJkIUKX89Oh+dWeE8YkbPnRPj5lNAdtNY5QSyDq VaRpIo+YfmZygyvHJQlAXBuZ0mvzcPzArfcPgSVTD3B7xTEGVu/45V7SnQX5os/V v39ySPXMdGOIdvK51gw7OtZl64uqrEKu39PyYDX/GUADflp/CHD0J7PJrQePbsH9 AQolVZDIxTfKqYQnUdL8+C8Zc24RowEzz3c2+aO89MSzwGqev3q8sXRVbW/Iqryg p+V3nHe+ipKcga5tOBlPr9KDtDd7j3xN2yaIwf5/QyO1OHBpjAZP1gjSVDcUcwpi svYy4kPn3PA= =etoL -----END PGP SIGNATURE----- nfs: disintegrate UAPI for nfs This is to complete part of the Userspace API (UAPI) disintegration for which the preparatory patches were pulled recently. After these patches, userspace headers will be segregated into: include/uapi/linux/.../foo.h for the userspace interface stuff, and: include/linux/.../foo.h for the strictly kernel internal stuff. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
This commit is contained in:
commit
f474af7051
|
@ -270,8 +270,6 @@ preempt-locking.txt
|
|||
- info on locking under a preemptive kernel.
|
||||
printk-formats.txt
|
||||
- how to get printk format specifiers right
|
||||
prio_tree.txt
|
||||
- info on radix-priority-search-tree use for indexing vmas.
|
||||
ramoops.txt
|
||||
- documentation of the ramoops oops/panic logging module.
|
||||
rbtree.txt
|
||||
|
|
|
@ -1,22 +0,0 @@
|
|||
What: /proc/<pid>/oom_adj
|
||||
When: August 2012
|
||||
Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's
|
||||
badness heuristic used to determine which task to kill when the kernel
|
||||
is out of memory.
|
||||
|
||||
The badness heuristic has since been rewritten since the introduction of
|
||||
this tunable such that its meaning is deprecated. The value was
|
||||
implemented as a bitshift on a score generated by the badness()
|
||||
function that did not have any precise units of measure. With the
|
||||
rewrite, the score is given as a proportion of available memory to the
|
||||
task allocating pages, so using a bitshift which grows the score
|
||||
exponentially is, thus, impossible to tune with fine granularity.
|
||||
|
||||
A much more powerful interface, /proc/<pid>/oom_score_adj, was
|
||||
introduced with the oom killer rewrite that allows users to increase or
|
||||
decrease the badness score linearly. This interface will replace
|
||||
/proc/<pid>/oom_adj.
|
||||
|
||||
A warning will be emitted to the kernel log if an application uses this
|
||||
deprecated interface. After it is printed once, future warnings will be
|
||||
suppressed until the kernel is rebooted.
|
|
@ -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
|
||||
|
||||
|
|
|
@ -210,3 +210,15 @@ Users:
|
|||
firmware assigned instance number of the PCI
|
||||
device that can help in understanding the firmware
|
||||
intended order of the PCI device.
|
||||
|
||||
What: /sys/bus/pci/devices/.../d3cold_allowed
|
||||
Date: July 2012
|
||||
Contact: Huang Ying <ying.huang@intel.com>
|
||||
Description:
|
||||
d3cold_allowed is bit to control whether the corresponding PCI
|
||||
device can be put into D3Cold state. If it is cleared, the
|
||||
device will never be put into D3Cold state. If it is set, the
|
||||
device may be put into D3Cold state if other requirements are
|
||||
satisfied too. Reading this attribute will show the current
|
||||
value of d3cold_allowed bit. Writing this attribute will set
|
||||
the value of d3cold_allowed bit.
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -5,4 +5,15 @@ Contact: "Ike Panhc <ike.pan@canonical.com>"
|
|||
Description:
|
||||
Control the power of camera module. 1 means on, 0 means off.
|
||||
|
||||
What: /sys/devices/platform/ideapad/fan_mode
|
||||
Date: June 2012
|
||||
KernelVersion: 3.6
|
||||
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
|
||||
Description:
|
||||
Change fan mode
|
||||
There are four available modes:
|
||||
* 0 -> Super Silent Mode
|
||||
* 1 -> Standard Mode
|
||||
* 2 -> Dust Cleaning
|
||||
* 4 -> Efficient Thermal Dissipation Mode
|
||||
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -125,7 +125,7 @@ the structure refers to a radio tuner the
|
|||
<constant>V4L2_TUNER_CAP_NORM</constant> flags can't be used.</para>
|
||||
<para>If multiple frequency bands are supported, then
|
||||
<structfield>capability</structfield> is the union of all
|
||||
<structfield>capability></structfield> fields of each &v4l2-frequency-band;.
|
||||
<structfield>capability</structfield> fields of each &v4l2-frequency-band;.
|
||||
</para></entry>
|
||||
</row>
|
||||
<row>
|
||||
|
@ -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
|
||||
|
|
|
@ -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"
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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)
|
|
@ -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
|
|
@ -3,15 +3,21 @@
|
|||
biodoc.txt
|
||||
- Notes on the Generic Block Layer Rewrite in Linux 2.5
|
||||
capability.txt
|
||||
- Generic Block Device Capability (/sys/block/<disk>/capability)
|
||||
- Generic Block Device Capability (/sys/block/<device>/capability)
|
||||
cfq-iosched.txt
|
||||
- CFQ IO scheduler tunables
|
||||
data-integrity.txt
|
||||
- Block data integrity
|
||||
deadline-iosched.txt
|
||||
- Deadline IO scheduler tunables
|
||||
ioprio.txt
|
||||
- Block io priorities (in CFQ scheduler)
|
||||
queue-sysfs.txt
|
||||
- Queue's sysfs entries
|
||||
request.txt
|
||||
- The members of struct request (in include/linux/blkdev.h)
|
||||
stat.txt
|
||||
- Block layer statistics in /sys/block/<dev>/stat
|
||||
- Block layer statistics in /sys/block/<device>/stat
|
||||
switching-sched.txt
|
||||
- Switching I/O schedulers at runtime
|
||||
writeback_cache_control.txt
|
||||
|
|
|
@ -1,3 +1,14 @@
|
|||
CFQ (Complete Fairness Queueing)
|
||||
===============================
|
||||
|
||||
The main aim of CFQ scheduler is to provide a fair allocation of the disk
|
||||
I/O bandwidth for all the processes which requests an I/O operation.
|
||||
|
||||
CFQ maintains the per process queue for the processes which request I/O
|
||||
operation(syncronous requests). In case of asynchronous requests, all the
|
||||
requests from all the processes are batched together according to their
|
||||
process's I/O priority.
|
||||
|
||||
CFQ ioscheduler tunables
|
||||
========================
|
||||
|
||||
|
@ -25,6 +36,72 @@ there are multiple spindles behind single LUN (Host based hardware RAID
|
|||
controller or for storage arrays), setting slice_idle=0 might end up in better
|
||||
throughput and acceptable latencies.
|
||||
|
||||
back_seek_max
|
||||
-------------
|
||||
This specifies, given in Kbytes, the maximum "distance" for backward seeking.
|
||||
The distance is the amount of space from the current head location to the
|
||||
sectors that are backward in terms of distance.
|
||||
|
||||
This parameter allows the scheduler to anticipate requests in the "backward"
|
||||
direction and consider them as being the "next" if they are within this
|
||||
distance from the current head location.
|
||||
|
||||
back_seek_penalty
|
||||
-----------------
|
||||
This parameter is used to compute the cost of backward seeking. If the
|
||||
backward distance of request is just 1/back_seek_penalty from a "front"
|
||||
request, then the seeking cost of two requests is considered equivalent.
|
||||
|
||||
So scheduler will not bias toward one or the other request (otherwise scheduler
|
||||
will bias toward front request). Default value of back_seek_penalty is 2.
|
||||
|
||||
fifo_expire_async
|
||||
-----------------
|
||||
This parameter is used to set the timeout of asynchronous requests. Default
|
||||
value of this is 248ms.
|
||||
|
||||
fifo_expire_sync
|
||||
----------------
|
||||
This parameter is used to set the timeout of synchronous requests. Default
|
||||
value of this is 124ms. In case to favor synchronous requests over asynchronous
|
||||
one, this value should be decreased relative to fifo_expire_async.
|
||||
|
||||
slice_async
|
||||
-----------
|
||||
This parameter is same as of slice_sync but for asynchronous queue. The
|
||||
default value is 40ms.
|
||||
|
||||
slice_async_rq
|
||||
--------------
|
||||
This parameter is used to limit the dispatching of asynchronous request to
|
||||
device request queue in queue's slice time. The maximum number of request that
|
||||
are allowed to be dispatched also depends upon the io priority. Default value
|
||||
for this is 2.
|
||||
|
||||
slice_sync
|
||||
----------
|
||||
When a queue is selected for execution, the queues IO requests are only
|
||||
executed for a certain amount of time(time_slice) before switching to another
|
||||
queue. This parameter is used to calculate the time slice of synchronous
|
||||
queue.
|
||||
|
||||
time_slice is computed using the below equation:-
|
||||
time_slice = slice_sync + (slice_sync/5 * (4 - prio)). To increase the
|
||||
time_slice of synchronous queue, increase the value of slice_sync. Default
|
||||
value is 100ms.
|
||||
|
||||
quantum
|
||||
-------
|
||||
This specifies the number of request dispatched to the device queue. In a
|
||||
queue's time slice, a request will not be dispatched if the number of request
|
||||
in the device exceeds this parameter. This parameter is used for synchronous
|
||||
request.
|
||||
|
||||
In case of storage with several disk, this setting can limit the parallel
|
||||
processing of request. Therefore, increasing the value can imporve the
|
||||
performace although this can cause the latency of some I/O to increase due
|
||||
to more number of requests.
|
||||
|
||||
CFQ IOPS Mode for group scheduling
|
||||
===================================
|
||||
Basic CFQ design is to provide priority based time slices. Higher priority
|
||||
|
|
|
@ -9,20 +9,71 @@ These files are the ones found in the /sys/block/xxx/queue/ directory.
|
|||
Files denoted with a RO postfix are readonly and the RW postfix means
|
||||
read-write.
|
||||
|
||||
add_random (RW)
|
||||
----------------
|
||||
This file allows to trun off the disk entropy contribution. Default
|
||||
value of this file is '1'(on).
|
||||
|
||||
discard_granularity (RO)
|
||||
-----------------------
|
||||
This shows the size of internal allocation of the device in bytes, if
|
||||
reported by the device. A value of '0' means device does not support
|
||||
the discard functionality.
|
||||
|
||||
discard_max_bytes (RO)
|
||||
----------------------
|
||||
Devices that support discard functionality may have internal limits on
|
||||
the number of bytes that can be trimmed or unmapped in a single operation.
|
||||
The discard_max_bytes parameter is set by the device driver to the maximum
|
||||
number of bytes that can be discarded in a single operation. Discard
|
||||
requests issued to the device must not exceed this limit. A discard_max_bytes
|
||||
value of 0 means that the device does not support discard functionality.
|
||||
|
||||
discard_zeroes_data (RO)
|
||||
------------------------
|
||||
When read, this file will show if the discarded block are zeroed by the
|
||||
device or not. If its value is '1' the blocks are zeroed otherwise not.
|
||||
|
||||
hw_sector_size (RO)
|
||||
-------------------
|
||||
This is the hardware sector size of the device, in bytes.
|
||||
|
||||
iostats (RW)
|
||||
-------------
|
||||
This file is used to control (on/off) the iostats accounting of the
|
||||
disk.
|
||||
|
||||
logical_block_size (RO)
|
||||
-----------------------
|
||||
This is the logcal block size of the device, in bytes.
|
||||
|
||||
max_hw_sectors_kb (RO)
|
||||
----------------------
|
||||
This is the maximum number of kilobytes supported in a single data transfer.
|
||||
|
||||
max_integrity_segments (RO)
|
||||
---------------------------
|
||||
When read, this file shows the max limit of integrity segments as
|
||||
set by block layer which a hardware controller can handle.
|
||||
|
||||
max_sectors_kb (RW)
|
||||
-------------------
|
||||
This is the maximum number of kilobytes that the block layer will allow
|
||||
for a filesystem request. Must be smaller than or equal to the maximum
|
||||
size allowed by the hardware.
|
||||
|
||||
max_segments (RO)
|
||||
-----------------
|
||||
Maximum number of segments of the device.
|
||||
|
||||
max_segment_size (RO)
|
||||
---------------------
|
||||
Maximum segment size of the device.
|
||||
|
||||
minimum_io_size (RO)
|
||||
--------------------
|
||||
This is the smallest preferred io size reported by the device.
|
||||
|
||||
nomerges (RW)
|
||||
-------------
|
||||
This enables the user to disable the lookup logic involved with IO
|
||||
|
@ -45,11 +96,24 @@ per-block-cgroup request pool. IOW, if there are N block cgroups,
|
|||
each request queue may have upto N request pools, each independently
|
||||
regulated by nr_requests.
|
||||
|
||||
optimal_io_size (RO)
|
||||
--------------------
|
||||
This is the optimal io size reported by the device.
|
||||
|
||||
physical_block_size (RO)
|
||||
------------------------
|
||||
This is the physical block size of device, in bytes.
|
||||
|
||||
read_ahead_kb (RW)
|
||||
------------------
|
||||
Maximum number of kilobytes to read-ahead for filesystems on this block
|
||||
device.
|
||||
|
||||
rotational (RW)
|
||||
---------------
|
||||
This file is used to stat if the device is of rotational type or
|
||||
non-rotational type.
|
||||
|
||||
rq_affinity (RW)
|
||||
----------------
|
||||
If this option is '1', the block layer will migrate request completions to the
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -18,16 +18,16 @@ from the rest of the system. The article on LWN [12] mentions some probable
|
|||
uses of the memory controller. The memory controller can be used to
|
||||
|
||||
a. Isolate an application or a group of applications
|
||||
Memory hungry applications can be isolated and limited to a smaller
|
||||
Memory-hungry applications can be isolated and limited to a smaller
|
||||
amount of memory.
|
||||
b. Create a cgroup with limited amount of memory, this can be used
|
||||
b. Create a cgroup with a limited amount of memory; this can be used
|
||||
as a good alternative to booting with mem=XXXX.
|
||||
c. Virtualization solutions can control the amount of memory they want
|
||||
to assign to a virtual machine instance.
|
||||
d. A CD/DVD burner could control the amount of memory used by the
|
||||
rest of the system to ensure that burning does not fail due to lack
|
||||
of available memory.
|
||||
e. There are several other use cases, find one or use the controller just
|
||||
e. There are several other use cases; find one or use the controller just
|
||||
for fun (to learn and hack on the VM subsystem).
|
||||
|
||||
Current Status: linux-2.6.34-mmotm(development version of 2010/April)
|
||||
|
@ -38,12 +38,12 @@ Features:
|
|||
- optionally, memory+swap usage can be accounted and limited.
|
||||
- hierarchical accounting
|
||||
- soft limit
|
||||
- moving(recharging) account at moving a task is selectable.
|
||||
- moving (recharging) account at moving a task is selectable.
|
||||
- usage threshold notifier
|
||||
- oom-killer disable knob and oom-notifier
|
||||
- Root cgroup has no limit controls.
|
||||
|
||||
Kernel memory support is work in progress, and the current version provides
|
||||
Kernel memory support is a work in progress, and the current version provides
|
||||
basically functionality. (See Section 2.7)
|
||||
|
||||
Brief summary of control files.
|
||||
|
@ -144,9 +144,9 @@ Figure 1 shows the important aspects of the controller
|
|||
3. Each page has a pointer to the page_cgroup, which in turn knows the
|
||||
cgroup it belongs to
|
||||
|
||||
The accounting is done as follows: mem_cgroup_charge() is invoked to setup
|
||||
The accounting is done as follows: mem_cgroup_charge() is invoked to set up
|
||||
the necessary data structures and check if the cgroup that is being charged
|
||||
is over its limit. If it is then reclaim is invoked on the cgroup.
|
||||
is over its limit. If it is, then reclaim is invoked on the cgroup.
|
||||
More details can be found in the reclaim section of this document.
|
||||
If everything goes well, a page meta-data-structure called page_cgroup is
|
||||
updated. page_cgroup has its own LRU on cgroup.
|
||||
|
@ -163,13 +163,13 @@ for earlier. A file page will be accounted for as Page Cache when it's
|
|||
inserted into inode (radix-tree). While it's mapped into the page tables of
|
||||
processes, duplicate accounting is carefully avoided.
|
||||
|
||||
A RSS page is unaccounted when it's fully unmapped. A PageCache page is
|
||||
An RSS page is unaccounted when it's fully unmapped. A PageCache page is
|
||||
unaccounted when it's removed from radix-tree. Even if RSS pages are fully
|
||||
unmapped (by kswapd), they may exist as SwapCache in the system until they
|
||||
are really freed. Such SwapCaches also also accounted.
|
||||
are really freed. Such SwapCaches are also accounted.
|
||||
A swapped-in page is not accounted until it's mapped.
|
||||
|
||||
Note: The kernel does swapin-readahead and read multiple swaps at once.
|
||||
Note: The kernel does swapin-readahead and reads multiple swaps at once.
|
||||
This means swapped-in pages may contain pages for other tasks than a task
|
||||
causing page fault. So, we avoid accounting at swap-in I/O.
|
||||
|
||||
|
@ -209,7 +209,7 @@ memsw.limit_in_bytes.
|
|||
Example: Assume a system with 4G of swap. A task which allocates 6G of memory
|
||||
(by mistake) under 2G memory limitation will use all swap.
|
||||
In this case, setting memsw.limit_in_bytes=3G will prevent bad use of swap.
|
||||
By using memsw limit, you can avoid system OOM which can be caused by swap
|
||||
By using the memsw limit, you can avoid system OOM which can be caused by swap
|
||||
shortage.
|
||||
|
||||
* why 'memory+swap' rather than swap.
|
||||
|
@ -217,7 +217,7 @@ The global LRU(kswapd) can swap out arbitrary pages. Swap-out means
|
|||
to move account from memory to swap...there is no change in usage of
|
||||
memory+swap. In other words, when we want to limit the usage of swap without
|
||||
affecting global LRU, memory+swap limit is better than just limiting swap from
|
||||
OS point of view.
|
||||
an OS point of view.
|
||||
|
||||
* What happens when a cgroup hits memory.memsw.limit_in_bytes
|
||||
When a cgroup hits memory.memsw.limit_in_bytes, it's useless to do swap-out
|
||||
|
@ -236,7 +236,7 @@ an OOM routine is invoked to select and kill the bulkiest task in the
|
|||
cgroup. (See 10. OOM Control below.)
|
||||
|
||||
The reclaim algorithm has not been modified for cgroups, except that
|
||||
pages that are selected for reclaiming come from the per cgroup LRU
|
||||
pages that are selected for reclaiming come from the per-cgroup LRU
|
||||
list.
|
||||
|
||||
NOTE: Reclaim does not work for the root cgroup, since we cannot set any
|
||||
|
@ -316,7 +316,7 @@ We can check the usage:
|
|||
# cat /sys/fs/cgroup/memory/0/memory.usage_in_bytes
|
||||
1216512
|
||||
|
||||
A successful write to this file does not guarantee a successful set of
|
||||
A successful write to this file does not guarantee a successful setting of
|
||||
this limit to the value written into the file. This can be due to a
|
||||
number of factors, such as rounding up to page boundaries or the total
|
||||
availability of memory on the system. The user is required to re-read
|
||||
|
@ -350,7 +350,7 @@ Trying usual test under memory controller is always helpful.
|
|||
4.1 Troubleshooting
|
||||
|
||||
Sometimes a user might find that the application under a cgroup is
|
||||
terminated by OOM killer. There are several causes for this:
|
||||
terminated by the OOM killer. There are several causes for this:
|
||||
|
||||
1. The cgroup limit is too low (just too low to do anything useful)
|
||||
2. The user is using anonymous memory and swap is turned off or too low
|
||||
|
@ -358,7 +358,7 @@ terminated by OOM killer. There are several causes for this:
|
|||
A sync followed by echo 1 > /proc/sys/vm/drop_caches will help get rid of
|
||||
some of the pages cached in the cgroup (page cache pages).
|
||||
|
||||
To know what happens, disable OOM_Kill by 10. OOM Control(see below) and
|
||||
To know what happens, disabling OOM_Kill as per "10. OOM Control" (below) and
|
||||
seeing what happens will be helpful.
|
||||
|
||||
4.2 Task migration
|
||||
|
@ -399,10 +399,10 @@ About use_hierarchy, see Section 6.
|
|||
|
||||
Almost all pages tracked by this memory cgroup will be unmapped and freed.
|
||||
Some pages cannot be freed because they are locked or in-use. Such pages are
|
||||
moved to parent(if use_hierarchy==1) or root (if use_hierarchy==0) and this
|
||||
moved to parent (if use_hierarchy==1) or root (if use_hierarchy==0) and this
|
||||
cgroup will be empty.
|
||||
|
||||
Typical use case of this interface is that calling this before rmdir().
|
||||
The typical use case for this interface is before calling rmdir().
|
||||
Because rmdir() moves all pages to parent, some out-of-use page caches can be
|
||||
moved to the parent. If you want to avoid that, force_empty will be useful.
|
||||
|
||||
|
@ -486,7 +486,7 @@ You can reset failcnt by writing 0 to failcnt file.
|
|||
|
||||
For efficiency, as other kernel components, memory cgroup uses some optimization
|
||||
to avoid unnecessary cacheline false sharing. usage_in_bytes is affected by the
|
||||
method and doesn't show 'exact' value of memory(and swap) usage, it's an fuzz
|
||||
method and doesn't show 'exact' value of memory (and swap) usage, it's a fuzz
|
||||
value for efficient access. (Of course, when necessary, it's synchronized.)
|
||||
If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP)
|
||||
value in memory.stat(see 5.2).
|
||||
|
@ -496,8 +496,8 @@ value in memory.stat(see 5.2).
|
|||
This is similar to numa_maps but operates on a per-memcg basis. This is
|
||||
useful for providing visibility into the numa locality information within
|
||||
an memcg since the pages are allowed to be allocated from any physical
|
||||
node. One of the usecases is evaluating application performance by
|
||||
combining this information with the application's cpu allocation.
|
||||
node. One of the use cases is evaluating application performance by
|
||||
combining this information with the application's CPU allocation.
|
||||
|
||||
We export "total", "file", "anon" and "unevictable" pages per-node for
|
||||
each memcg. The ouput format of memory.numa_stat is:
|
||||
|
@ -561,10 +561,10 @@ are pushed back to their soft limits. If the soft limit of each control
|
|||
group is very high, they are pushed back as much as possible to make
|
||||
sure that one control group does not starve the others of memory.
|
||||
|
||||
Please note that soft limits is a best effort feature, it comes with
|
||||
Please note that soft limits is a best-effort feature; it comes with
|
||||
no guarantees, but it does its best to make sure that when memory is
|
||||
heavily contended for, memory is allocated based on the soft limit
|
||||
hints/setup. Currently soft limit based reclaim is setup such that
|
||||
hints/setup. Currently soft limit based reclaim is set up such that
|
||||
it gets invoked from balance_pgdat (kswapd).
|
||||
|
||||
7.1 Interface
|
||||
|
@ -592,7 +592,7 @@ page tables.
|
|||
|
||||
8.1 Interface
|
||||
|
||||
This feature is disabled by default. It can be enabled(and disabled again) by
|
||||
This feature is disabled by default. It can be enabledi (and disabled again) by
|
||||
writing to memory.move_charge_at_immigrate of the destination cgroup.
|
||||
|
||||
If you want to enable it:
|
||||
|
@ -601,8 +601,8 @@ If you want to enable it:
|
|||
|
||||
Note: Each bits of move_charge_at_immigrate has its own meaning about what type
|
||||
of charges should be moved. See 8.2 for details.
|
||||
Note: Charges are moved only when you move mm->owner, IOW, a leader of a thread
|
||||
group.
|
||||
Note: Charges are moved only when you move mm->owner, in other words,
|
||||
a leader of a thread group.
|
||||
Note: If we cannot find enough space for the task in the destination cgroup, we
|
||||
try to make space by reclaiming memory. Task migration may fail if we
|
||||
cannot make enough space.
|
||||
|
@ -612,25 +612,25 @@ And if you want disable it again:
|
|||
|
||||
# echo 0 > memory.move_charge_at_immigrate
|
||||
|
||||
8.2 Type of charges which can be move
|
||||
8.2 Type of charges which can be moved
|
||||
|
||||
Each bits of move_charge_at_immigrate has its own meaning about what type of
|
||||
charges should be moved. But in any cases, it must be noted that an account of
|
||||
a page or a swap can be moved only when it is charged to the task's current(old)
|
||||
memory cgroup.
|
||||
Each bit in move_charge_at_immigrate has its own meaning about what type of
|
||||
charges should be moved. But in any case, it must be noted that an account of
|
||||
a page or a swap can be moved only when it is charged to the task's current
|
||||
(old) memory cgroup.
|
||||
|
||||
bit | what type of charges would be moved ?
|
||||
-----+------------------------------------------------------------------------
|
||||
0 | A charge of an anonymous page(or swap of it) used by the target task.
|
||||
| You must enable Swap Extension(see 2.4) to enable move of swap charges.
|
||||
0 | A charge of an anonymous page (or swap of it) used by the target task.
|
||||
| You must enable Swap Extension (see 2.4) to enable move of swap charges.
|
||||
-----+------------------------------------------------------------------------
|
||||
1 | A charge of file pages(normal file, tmpfs file(e.g. ipc shared memory)
|
||||
1 | A charge of file pages (normal file, tmpfs file (e.g. ipc shared memory)
|
||||
| and swaps of tmpfs file) mmapped by the target task. Unlike the case of
|
||||
| anonymous pages, file pages(and swaps) in the range mmapped by the task
|
||||
| anonymous pages, file pages (and swaps) in the range mmapped by the task
|
||||
| will be moved even if the task hasn't done page fault, i.e. they might
|
||||
| not be the task's "RSS", but other task's "RSS" that maps the same file.
|
||||
| And mapcount of the page is ignored(the page can be moved even if
|
||||
| page_mapcount(page) > 1). You must enable Swap Extension(see 2.4) to
|
||||
| And mapcount of the page is ignored (the page can be moved even if
|
||||
| page_mapcount(page) > 1). You must enable Swap Extension (see 2.4) to
|
||||
| enable move of swap charges.
|
||||
|
||||
8.3 TODO
|
||||
|
@ -640,11 +640,11 @@ memory cgroup.
|
|||
|
||||
9. Memory thresholds
|
||||
|
||||
Memory cgroup implements memory thresholds using cgroups notification
|
||||
Memory cgroup implements memory thresholds using the cgroups notification
|
||||
API (see cgroups.txt). It allows to register multiple memory and memsw
|
||||
thresholds and gets notifications when it crosses.
|
||||
|
||||
To register a threshold application need:
|
||||
To register a threshold, an application must:
|
||||
- create an eventfd using eventfd(2);
|
||||
- open memory.usage_in_bytes or memory.memsw.usage_in_bytes;
|
||||
- write string like "<event_fd> <fd of memory.usage_in_bytes> <threshold>" to
|
||||
|
@ -659,24 +659,24 @@ It's applicable for root and non-root cgroup.
|
|||
|
||||
memory.oom_control file is for OOM notification and other controls.
|
||||
|
||||
Memory cgroup implements OOM notifier using cgroup notification
|
||||
Memory cgroup implements OOM notifier using the cgroup notification
|
||||
API (See cgroups.txt). It allows to register multiple OOM notification
|
||||
delivery and gets notification when OOM happens.
|
||||
|
||||
To register a notifier, application need:
|
||||
To register a notifier, an application must:
|
||||
- create an eventfd using eventfd(2)
|
||||
- open memory.oom_control file
|
||||
- write string like "<event_fd> <fd of memory.oom_control>" to
|
||||
cgroup.event_control
|
||||
|
||||
Application will be notified through eventfd when OOM happens.
|
||||
OOM notification doesn't work for root cgroup.
|
||||
The application will be notified through eventfd when OOM happens.
|
||||
OOM notification doesn't work for the root cgroup.
|
||||
|
||||
You can disable OOM-killer by writing "1" to memory.oom_control file, as:
|
||||
You can disable the OOM-killer by writing "1" to memory.oom_control file, as:
|
||||
|
||||
#echo 1 > memory.oom_control
|
||||
|
||||
This operation is only allowed to the top cgroup of sub-hierarchy.
|
||||
This operation is only allowed to the top cgroup of a sub-hierarchy.
|
||||
If OOM-killer is disabled, tasks under cgroup will hang/sleep
|
||||
in memory cgroup's OOM-waitqueue when they request accountable memory.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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";
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
|
@ -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>;
|
||||
};
|
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue