forked from Minki/linux
Merge commit 'origin/queue' into for-queue
Conflicts: arch/powerpc/include/asm/Kbuild arch/powerpc/include/uapi/asm/Kbuild
This commit is contained in:
commit
0588000eac
8
.gitignore
vendored
8
.gitignore
vendored
@ -84,3 +84,11 @@ GTAGS
|
||||
*.orig
|
||||
*~
|
||||
\#*#
|
||||
|
||||
#
|
||||
# Leavings from module signing
|
||||
#
|
||||
extra_certificates
|
||||
signing_key.priv
|
||||
signing_key.x509
|
||||
x509.genkey
|
||||
|
@ -210,6 +210,8 @@ local_ops.txt
|
||||
- semantics and behavior of local atomic operations.
|
||||
lockdep-design.txt
|
||||
- documentation on the runtime locking correctness validator.
|
||||
lockup-watchdogs.txt
|
||||
- info on soft and hard lockup detectors (aka nmi_watchdog).
|
||||
logo.gif
|
||||
- full colour GIF image of Linux logo (penguin - Tux).
|
||||
logo.txt
|
||||
@ -240,8 +242,6 @@ netlabel/
|
||||
- directory with information on the NetLabel subsystem.
|
||||
networking/
|
||||
- directory with info on various aspects of networking with Linux.
|
||||
nmi_watchdog.txt
|
||||
- info on NMI watchdog for SMP systems.
|
||||
nommu-mmap.txt
|
||||
- documentation about no-mmu memory mapping support.
|
||||
numastat.txt
|
||||
@ -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.
|
@ -206,3 +206,17 @@ Description:
|
||||
when a discarded area is read the discard_zeroes_data
|
||||
parameter will be set to one. Otherwise it will be 0 and
|
||||
the result of reading a discarded area is undefined.
|
||||
|
||||
What: /sys/block/<disk>/queue/write_same_max_bytes
|
||||
Date: January 2012
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Some devices support a write same operation in which a
|
||||
single data block can be written to a range of several
|
||||
contiguous blocks on storage. This can be used to wipe
|
||||
areas on disk or to initialize drives in a RAID
|
||||
configuration. write_same_max_bytes indicates how many
|
||||
bytes can be written in a single write same command. If
|
||||
write_same_max_bytes is 0, write same is not supported
|
||||
by the device.
|
||||
|
||||
|
@ -9,19 +9,19 @@ Attributes:
|
||||
this value will change the dev_loss_tmo for all
|
||||
FCFs discovered by this controller.
|
||||
|
||||
lesb_link_fail: Link Error Status Block (LESB) link failure count.
|
||||
lesb/link_fail: Link Error Status Block (LESB) link failure count.
|
||||
|
||||
lesb_vlink_fail: Link Error Status Block (LESB) virtual link
|
||||
lesb/vlink_fail: Link Error Status Block (LESB) virtual link
|
||||
failure count.
|
||||
|
||||
lesb_miss_fka: Link Error Status Block (LESB) missed FCoE
|
||||
lesb/miss_fka: Link Error Status Block (LESB) missed FCoE
|
||||
Initialization Protocol (FIP) Keep-Alives (FKA).
|
||||
|
||||
lesb_symb_err: Link Error Status Block (LESB) symbolic error count.
|
||||
lesb/symb_err: Link Error Status Block (LESB) symbolic error count.
|
||||
|
||||
lesb_err_block: Link Error Status Block (LESB) block error count.
|
||||
lesb/err_block: Link Error Status Block (LESB) block error count.
|
||||
|
||||
lesb_fcs_error: Link Error Status Block (LESB) Fibre Channel
|
||||
lesb/fcs_error: Link Error Status Block (LESB) Fibre Channel
|
||||
Serivces error count.
|
||||
|
||||
Notes: ctlr_X (global increment starting at 0)
|
||||
|
@ -25,6 +25,10 @@ client_id
|
||||
|
||||
The ceph unique client id that was assigned for this specific session.
|
||||
|
||||
features
|
||||
|
||||
A hexadecimal encoding of the feature bits for this image.
|
||||
|
||||
major
|
||||
|
||||
The block device major number.
|
||||
@ -33,6 +37,11 @@ name
|
||||
|
||||
The name of the rbd image.
|
||||
|
||||
image_id
|
||||
|
||||
The unique id for the rbd image. (For rbd image format 1
|
||||
this is empty.)
|
||||
|
||||
pool
|
||||
|
||||
The name of the storage pool where this rbd image resides.
|
||||
@ -57,12 +66,6 @@ current_snap
|
||||
|
||||
The current snapshot for which the device is mapped.
|
||||
|
||||
create_snap
|
||||
|
||||
Create a snapshot:
|
||||
|
||||
$ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_create
|
||||
|
||||
snap_*
|
||||
|
||||
A directory per each snapshot
|
||||
@ -79,4 +82,7 @@ snap_size
|
||||
|
||||
The size of the image when this snapshot was taken.
|
||||
|
||||
snap_features
|
||||
|
||||
A hexadecimal encoding of the feature bits for this snapshot.
|
||||
|
||||
|
17
Documentation/ABI/testing/sysfs-devices-firmware_node
Normal file
17
Documentation/ABI/testing/sysfs-devices-firmware_node
Normal file
@ -0,0 +1,17 @@
|
||||
What: /sys/devices/.../firmware_node/
|
||||
Date: September 2012
|
||||
Contact: <>
|
||||
Description:
|
||||
The /sys/devices/.../firmware_node directory contains attributes
|
||||
allowing the user space to check and modify some firmware
|
||||
related properties of given device.
|
||||
|
||||
What: /sys/devices/.../firmware_node/description
|
||||
Date: September 2012
|
||||
Contact: Lance Ortiz <lance.ortiz@hp.com>
|
||||
Description:
|
||||
The /sys/devices/.../firmware/description attribute contains a string
|
||||
that describes the device as provided by the _STR method in the ACPI
|
||||
namespace. This attribute is read-only. If the device does not have
|
||||
an _STR method associated with it in the ACPI namespace, this
|
||||
attribute is not present.
|
@ -96,3 +96,16 @@ Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
The maximum number of megabytes the writeback code will
|
||||
try to write out before move on to another inode.
|
||||
|
||||
What: /sys/fs/ext4/<disk>/extent_max_zeroout_kb
|
||||
Date: August 2012
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
The maximum number of kilobytes which will be zeroed
|
||||
out in preference to creating a new uninitialized
|
||||
extent when manipulating an inode's extent tree. Note
|
||||
that using a larger value will increase the
|
||||
variability of time necessary to complete a random
|
||||
write operation (since a 4k random write might turn
|
||||
into a much larger write due to the zeroout
|
||||
operation).
|
||||
|
@ -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
|
||||
|
@ -56,15 +56,15 @@ FUNCS = \
|
||||
write \
|
||||
|
||||
IOCTLS = \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/videodev2.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/audio.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/ca.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/dmx.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/frontend.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([A-Z][^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/net.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/video.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/media.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/v4l2-subdev.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/videodev2.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/audio.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/ca.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/dmx.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/frontend.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([A-Z][^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/net.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/video.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/media.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \
|
||||
VIDIOC_SUBDEV_G_FRAME_INTERVAL \
|
||||
VIDIOC_SUBDEV_S_FRAME_INTERVAL \
|
||||
VIDIOC_SUBDEV_ENUM_MBUS_CODE \
|
||||
@ -74,32 +74,32 @@ IOCTLS = \
|
||||
VIDIOC_SUBDEV_S_SELECTION \
|
||||
|
||||
TYPES = \
|
||||
$(shell perl -ne 'print "$$1 " if /^typedef\s+[^\s]+\s+([^\s]+)\;/' $(srctree)/include/linux/videodev2.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^}\s+([a-z0-9_]+_t)/' $(srctree)/include/linux/dvb/frontend.h)
|
||||
$(shell perl -ne 'print "$$1 " if /^typedef\s+[^\s]+\s+([^\s]+)\;/' $(srctree)/include/uapi/linux/videodev2.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^}\s+([a-z0-9_]+_t)/' $(srctree)/include/uapi/linux/dvb/frontend.h)
|
||||
|
||||
ENUMS = \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/videodev2.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/audio.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/ca.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/dmx.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/frontend.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/net.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/video.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/media.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/v4l2-mediabus.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/v4l2-subdev.h)
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/videodev2.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/audio.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/ca.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/dmx.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/frontend.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/net.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/video.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/media.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-mediabus.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-subdev.h)
|
||||
|
||||
STRUCTS = \
|
||||
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/linux/videodev2.h) \
|
||||
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s\{]+)\s*/)' $(srctree)/include/linux/dvb/audio.h) \
|
||||
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/linux/dvb/ca.h) \
|
||||
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/linux/dvb/dmx.h) \
|
||||
$(shell perl -ne 'print "$$1 " if (!/dtv\_cmds\_h/ && /^struct\s+([^\s]+)\s+/)' $(srctree)/include/linux/dvb/frontend.h) \
|
||||
$(shell perl -ne 'print "$$1 " if (/^struct\s+([A-Z][^\s]+)\s+/)' $(srctree)/include/linux/dvb/net.h) \
|
||||
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/linux/dvb/video.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/linux/media.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/linux/v4l2-subdev.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/linux/v4l2-mediabus.h)
|
||||
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/videodev2.h) \
|
||||
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s\{]+)\s*/)' $(srctree)/include/uapi/linux/dvb/audio.h) \
|
||||
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/ca.h) \
|
||||
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/dmx.h) \
|
||||
$(shell perl -ne 'print "$$1 " if (!/dtv\_cmds\_h/ && /^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/frontend.h) \
|
||||
$(shell perl -ne 'print "$$1 " if (/^struct\s+([A-Z][^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/net.h) \
|
||||
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/video.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/media.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \
|
||||
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-mediabus.h)
|
||||
|
||||
ERRORS = \
|
||||
E2BIG \
|
||||
@ -205,7 +205,7 @@ $(MEDIA_OBJ_DIR)/v4l2.xml: $(OBJIMGFILES)
|
||||
@(ln -sf $(MEDIA_SRC_DIR)/v4l/*xml $(MEDIA_OBJ_DIR)/)
|
||||
@(ln -sf $(MEDIA_SRC_DIR)/dvb/*xml $(MEDIA_OBJ_DIR)/)
|
||||
|
||||
$(MEDIA_OBJ_DIR)/videodev2.h.xml: $(srctree)/include/linux/videodev2.h $(MEDIA_OBJ_DIR)/v4l2.xml
|
||||
$(MEDIA_OBJ_DIR)/videodev2.h.xml: $(srctree)/include/uapi/linux/videodev2.h $(MEDIA_OBJ_DIR)/v4l2.xml
|
||||
@$($(quiet)gen_xml)
|
||||
@( \
|
||||
echo "<programlisting>") > $@
|
||||
@ -216,7 +216,7 @@ $(MEDIA_OBJ_DIR)/videodev2.h.xml: $(srctree)/include/linux/videodev2.h $(MEDIA_O
|
||||
@( \
|
||||
echo "</programlisting>") >> $@
|
||||
|
||||
$(MEDIA_OBJ_DIR)/audio.h.xml: $(srctree)/include/linux/dvb/audio.h $(MEDIA_OBJ_DIR)/v4l2.xml
|
||||
$(MEDIA_OBJ_DIR)/audio.h.xml: $(srctree)/include/uapi/linux/dvb/audio.h $(MEDIA_OBJ_DIR)/v4l2.xml
|
||||
@$($(quiet)gen_xml)
|
||||
@( \
|
||||
echo "<programlisting>") > $@
|
||||
@ -227,7 +227,7 @@ $(MEDIA_OBJ_DIR)/audio.h.xml: $(srctree)/include/linux/dvb/audio.h $(MEDIA_OBJ_D
|
||||
@( \
|
||||
echo "</programlisting>") >> $@
|
||||
|
||||
$(MEDIA_OBJ_DIR)/ca.h.xml: $(srctree)/include/linux/dvb/ca.h $(MEDIA_OBJ_DIR)/v4l2.xml
|
||||
$(MEDIA_OBJ_DIR)/ca.h.xml: $(srctree)/include/uapi/linux/dvb/ca.h $(MEDIA_OBJ_DIR)/v4l2.xml
|
||||
@$($(quiet)gen_xml)
|
||||
@( \
|
||||
echo "<programlisting>") > $@
|
||||
@ -238,7 +238,7 @@ $(MEDIA_OBJ_DIR)/ca.h.xml: $(srctree)/include/linux/dvb/ca.h $(MEDIA_OBJ_DIR)/v4
|
||||
@( \
|
||||
echo "</programlisting>") >> $@
|
||||
|
||||
$(MEDIA_OBJ_DIR)/dmx.h.xml: $(srctree)/include/linux/dvb/dmx.h $(MEDIA_OBJ_DIR)/v4l2.xml
|
||||
$(MEDIA_OBJ_DIR)/dmx.h.xml: $(srctree)/include/uapi/linux/dvb/dmx.h $(MEDIA_OBJ_DIR)/v4l2.xml
|
||||
@$($(quiet)gen_xml)
|
||||
@( \
|
||||
echo "<programlisting>") > $@
|
||||
@ -249,7 +249,7 @@ $(MEDIA_OBJ_DIR)/dmx.h.xml: $(srctree)/include/linux/dvb/dmx.h $(MEDIA_OBJ_DIR)/
|
||||
@( \
|
||||
echo "</programlisting>") >> $@
|
||||
|
||||
$(MEDIA_OBJ_DIR)/frontend.h.xml: $(srctree)/include/linux/dvb/frontend.h $(MEDIA_OBJ_DIR)/v4l2.xml
|
||||
$(MEDIA_OBJ_DIR)/frontend.h.xml: $(srctree)/include/uapi/linux/dvb/frontend.h $(MEDIA_OBJ_DIR)/v4l2.xml
|
||||
@$($(quiet)gen_xml)
|
||||
@( \
|
||||
echo "<programlisting>") > $@
|
||||
@ -260,7 +260,7 @@ $(MEDIA_OBJ_DIR)/frontend.h.xml: $(srctree)/include/linux/dvb/frontend.h $(MEDIA
|
||||
@( \
|
||||
echo "</programlisting>") >> $@
|
||||
|
||||
$(MEDIA_OBJ_DIR)/net.h.xml: $(srctree)/include/linux/dvb/net.h $(MEDIA_OBJ_DIR)/v4l2.xml
|
||||
$(MEDIA_OBJ_DIR)/net.h.xml: $(srctree)/include/uapi/linux/dvb/net.h $(MEDIA_OBJ_DIR)/v4l2.xml
|
||||
@$($(quiet)gen_xml)
|
||||
@( \
|
||||
echo "<programlisting>") > $@
|
||||
@ -271,7 +271,7 @@ $(MEDIA_OBJ_DIR)/net.h.xml: $(srctree)/include/linux/dvb/net.h $(MEDIA_OBJ_DIR)/
|
||||
@( \
|
||||
echo "</programlisting>") >> $@
|
||||
|
||||
$(MEDIA_OBJ_DIR)/video.h.xml: $(srctree)/include/linux/dvb/video.h $(MEDIA_OBJ_DIR)/v4l2.xml
|
||||
$(MEDIA_OBJ_DIR)/video.h.xml: $(srctree)/include/uapi/linux/dvb/video.h $(MEDIA_OBJ_DIR)/v4l2.xml
|
||||
@$($(quiet)gen_xml)
|
||||
@( \
|
||||
echo "<programlisting>") > $@
|
||||
@ -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>
|
||||
@ -2615,11 +2580,11 @@ ioctls.</para>
|
||||
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>
|
||||
<para>Support for frequency band enumeration: &VIDIOC-ENUM-FREQ-BANDS; ioctl.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Support for frequency band enumeration: &VIDIOC-ENUM-FREQ-BANDS; ioctl.</para>
|
||||
<para>Vendor and device specific media bus pixel formats.
|
||||
<xref linkend="v4l2-mbus-vendor-spec-fmts" />.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
@ -1586,7 +1586,6 @@ frame counter of the frame that is currently displayed (decoded). This value is
|
||||
the decoder is started.</entry>
|
||||
</row>
|
||||
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE</constant> </entry>
|
||||
@ -2269,6 +2268,14 @@ encoder or editing process may produce.".
|
||||
Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row id="v4l2-mpeg-video-vbv-delay">
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VBV_DELAY</constant> </entry>
|
||||
<entry>integer</entry>
|
||||
</row><row><entry spanname="descr">Sets the initial delay in milliseconds for
|
||||
VBV buffer control.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant> </entry>
|
||||
@ -2334,6 +2341,265 @@ Applicable to the MPEG4 decoder.</entry>
|
||||
</row><row><entry spanname="descr">vop_time_increment value for MPEG4. Applicable to the MPEG4 encoder.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_SEI_FRAME_PACKING</constant> </entry>
|
||||
<entry>boolean</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Enable generation of frame packing supplemental enhancement information in the encoded bitstream.
|
||||
The frame packing SEI message contains the arrangement of L and R planes for 3D viewing. Applicable to the H264 encoder.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_SEI_FP_CURRENT_FRAME_0</constant> </entry>
|
||||
<entry>boolean</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Sets current frame as frame0 in frame packing SEI.
|
||||
Applicable to the H264 encoder.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row id="v4l2-mpeg-video-h264-sei-fp-arrangement-type">
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE</constant> </entry>
|
||||
<entry>enum v4l2_mpeg_video_h264_sei_fp_arrangement_type</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Frame packing arrangement type for H264 SEI.
|
||||
Applicable to the H264 encoder.
|
||||
Possible values are:</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_CHEKERBOARD</constant> </entry>
|
||||
<entry>Pixels are alternatively from L and R.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_COLUMN</constant> </entry>
|
||||
<entry>L and R are interlaced by column.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_ROW</constant> </entry>
|
||||
<entry>L and R are interlaced by row.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_SIDE_BY_SIDE</constant> </entry>
|
||||
<entry>L is on the left, R on the right.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TOP_BOTTOM</constant> </entry>
|
||||
<entry>L is on top, R on bottom.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TEMPORAL</constant> </entry>
|
||||
<entry>One view per frame.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO</constant> </entry>
|
||||
<entry>boolean</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Enables flexible macroblock ordering in the encoded bitstream. It is a technique
|
||||
used for restructuring the ordering of macroblocks in pictures. Applicable to the H264 encoder.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row id="v4l2-mpeg-video-h264-fmo-map-type">
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_MAP_TYPE</constant> </entry>
|
||||
<entry>enum v4l2_mpeg_video_h264_fmo_map_type</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">When using FMO, the map type divides the image in different scan patterns of macroblocks.
|
||||
Applicable to the H264 encoder.
|
||||
Possible values are:</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_INTERLEAVED_SLICES</constant> </entry>
|
||||
<entry>Slices are interleaved one after other with macroblocks in run length order.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_SCATTERED_SLICES</constant> </entry>
|
||||
<entry>Scatters the macroblocks based on a mathematical function known to both encoder and decoder.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_FOREGROUND_WITH_LEFT_OVER</constant> </entry>
|
||||
<entry>Macroblocks arranged in rectangular areas or regions of interest.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_BOX_OUT</constant> </entry>
|
||||
<entry>Slice groups grow in a cyclic way from centre to outwards.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_RASTER_SCAN</constant> </entry>
|
||||
<entry>Slice groups grow in raster scan pattern from left to right.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_WIPE_SCAN</constant> </entry>
|
||||
<entry>Slice groups grow in wipe scan pattern from top to bottom.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_EXPLICIT</constant> </entry>
|
||||
<entry>User defined map type.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_SLICE_GROUP</constant> </entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Number of slice groups in FMO.
|
||||
Applicable to the H264 encoder.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row id="v4l2-mpeg-video-h264-fmo-change-direction">
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_CHANGE_DIRECTION</constant> </entry>
|
||||
<entry>enum v4l2_mpeg_video_h264_fmo_change_dir</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Specifies a direction of the slice group change for raster and wipe maps.
|
||||
Applicable to the H264 encoder.
|
||||
Possible values are:</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_CHANGE_DIR_RIGHT</constant> </entry>
|
||||
<entry>Raster scan or wipe right.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_CHANGE_DIR_LEFT</constant> </entry>
|
||||
<entry>Reverse raster scan or wipe left.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_CHANGE_RATE</constant> </entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Specifies the size of the first slice group for raster and wipe map.
|
||||
Applicable to the H264 encoder.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_RUN_LENGTH</constant> </entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Specifies the number of consecutive macroblocks for the interleaved map.
|
||||
Applicable to the H264 encoder.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_ASO</constant> </entry>
|
||||
<entry>boolean</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Enables arbitrary slice ordering in encoded bitstream.
|
||||
Applicable to the H264 encoder.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_ASO_SLICE_ORDER</constant> </entry>
|
||||
<entry>integer</entry>
|
||||
</row><row><entry spanname="descr">Specifies the slice order in ASO. Applicable to the H264 encoder.
|
||||
The supplied 32-bit integer is interpreted as follows (bit
|
||||
0 = least significant bit):</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>Bit 0:15</entry>
|
||||
<entry>Slice ID</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>Bit 16:32</entry>
|
||||
<entry>Slice position or order</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING</constant> </entry>
|
||||
<entry>boolean</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Enables H264 hierarchical coding.
|
||||
Applicable to the H264 encoder.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row id="v4l2-mpeg-video-h264-hierarchical-coding-type">
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_TYPE</constant> </entry>
|
||||
<entry>enum v4l2_mpeg_video_h264_hierarchical_coding_type</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Specifies the hierarchical coding type.
|
||||
Applicable to the H264 encoder.
|
||||
Possible values are:</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_HIERARCHICAL_CODING_B</constant> </entry>
|
||||
<entry>Hierarchical B coding.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_HIERARCHICAL_CODING_P</constant> </entry>
|
||||
<entry>Hierarchical P coding.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER</constant> </entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Specifies the number of hierarchical coding layers.
|
||||
Applicable to the H264 encoder.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER_QP</constant> </entry>
|
||||
<entry>integer</entry>
|
||||
</row><row><entry spanname="descr">Specifies a user defined QP for each layer. Applicable to the H264 encoder.
|
||||
The supplied 32-bit integer is interpreted as follows (bit
|
||||
0 = least significant bit):</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>Bit 0:15</entry>
|
||||
<entry>QP value</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>Bit 16:32</entry>
|
||||
<entry>Layer number</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
@ -3505,7 +3771,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 +3785,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 +3916,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 +3983,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">
|
||||
@ -4268,6 +4533,177 @@ interface and may change in the future.</para>
|
||||
pixels / second.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_TEST_PATTERN</constant></entry>
|
||||
<entry>menu</entry>
|
||||
</row>
|
||||
<row id="v4l2-test-pattern">
|
||||
<entry spanname="descr"> Some capture/display/sensor devices have
|
||||
the capability to generate test pattern images. These hardware
|
||||
specific test patterns can be used to test if a device is working
|
||||
properly.</entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</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>
|
||||
|
@ -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
|
||||
@ -677,26 +677,24 @@ memory, set by the application. See <xref linkend="userp" /> for details.
|
||||
<entry><structfield>length</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Size of the buffer (not the payload) in bytes for the
|
||||
single-planar API. For the multi-planar API should contain the
|
||||
number of elements in the <structfield>planes</structfield> array.
|
||||
single-planar API. For the multi-planar API the application sets
|
||||
this to the number of elements in the <structfield>planes</structfield>
|
||||
array. The driver will fill in the actual number of valid elements in
|
||||
that array.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<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 +825,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>
|
||||
|
@ -1,11 +1,13 @@
|
||||
<refentry id="V4L2-PIX-FMT-NV12M">
|
||||
<refentry>
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_NV12M ('NM12')</refentrytitle>
|
||||
<refentrytitle>V4L2_PIX_FMT_NV12M ('NM12'), V4L2_PIX_FMT_NV21M ('NM21'), V4L2_PIX_FMT_NV12MT_16X16</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname> <constant>V4L2_PIX_FMT_NV12M</constant></refname>
|
||||
<refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> with planes
|
||||
<refname id="V4L2-PIX-FMT-NV12M"><constant>V4L2_PIX_FMT_NV12M</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-NV21M"><constant>V4L2_PIX_FMT_NV21M</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-NV12MT_16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
|
||||
<refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> and <constant>V4L2_PIX_FMT_NV21</constant> with planes
|
||||
non contiguous in memory. </refpurpose>
|
||||
</refnamediv>
|
||||
<refsect1>
|
||||
@ -22,7 +24,12 @@ The CbCr plane is the same width, in bytes, as the Y plane (and of the image),
|
||||
but is half as tall in pixels. Each CbCr pair belongs to four pixels. For example,
|
||||
Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to
|
||||
Y'<subscript>00</subscript>, Y'<subscript>01</subscript>,
|
||||
Y'<subscript>10</subscript>, Y'<subscript>11</subscript>. </para>
|
||||
Y'<subscript>10</subscript>, Y'<subscript>11</subscript>.
|
||||
<constant>V4L2_PIX_FMT_NV12MT_16X16</constant> is the tiled version of
|
||||
<constant>V4L2_PIX_FMT_NV12M</constant> with 16x16 macroblock tiles. Here pixels
|
||||
are arranged in 16x16 2D tiles and tiles are arranged in linear order in memory.
|
||||
<constant>V4L2_PIX_FMT_NV21M</constant> is the same as <constant>V4L2_PIX_FMT_NV12M</constant>
|
||||
except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.</para>
|
||||
|
||||
<para><constant>V4L2_PIX_FMT_NV12M</constant> is intended to be
|
||||
used only in drivers and applications that support the multi-planar API,
|
||||
|
@ -22,8 +22,7 @@
|
||||
with 10 bits per colour compressed to 8 bits each, using DPCM
|
||||
compression. DPCM, differential pulse-code modulation, is lossy.
|
||||
Each colour component consumes 8 bits of memory. In other respects
|
||||
this format is similar to <xref
|
||||
linkend="pixfmt-srggb10">.</xref></para>
|
||||
this format is similar to <xref linkend="pixfmt-srggb10" />.</para>
|
||||
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
154
Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml
Normal file
154
Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml
Normal file
@ -0,0 +1,154 @@
|
||||
<refentry id="V4L2-PIX-FMT-YVU420M">
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname> <constant>V4L2_PIX_FMT_YVU420M</constant></refname>
|
||||
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YVU420</constant>
|
||||
with planes non contiguous in memory. </refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This is a multi-planar format, as opposed to a packed format.
|
||||
The three components are separated into three sub-images or planes.
|
||||
|
||||
The Y plane is first. The Y plane has one byte per pixel. The Cr data
|
||||
constitutes the second plane which is half the width and half
|
||||
the height of the Y plane (and of the image). Each Cr belongs to four
|
||||
pixels, a two-by-two square of the image. For example,
|
||||
Cr<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
|
||||
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
|
||||
Y'<subscript>11</subscript>. The Cb data, just like the Cr plane, constitutes
|
||||
the third plane. </para>
|
||||
|
||||
<para>If the Y plane has pad bytes after each row, then the Cr
|
||||
and Cb planes have half as many pad bytes after their rows. In other
|
||||
words, two Cx rows (including padding) is exactly as long as one Y row
|
||||
(including padding).</para>
|
||||
|
||||
<para><constant>V4L2_PIX_FMT_YVU420M</constant> is intended to be
|
||||
used only in drivers and applications that support the multi-planar API,
|
||||
described in <xref linkend="planar-apis"/>. </para>
|
||||
|
||||
<example>
|
||||
<title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 × 4
|
||||
pixel image</title>
|
||||
|
||||
<formalpara>
|
||||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte.
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="5" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>start0 + 0:</entry>
|
||||
<entry>Y'<subscript>00</subscript></entry>
|
||||
<entry>Y'<subscript>01</subscript></entry>
|
||||
<entry>Y'<subscript>02</subscript></entry>
|
||||
<entry>Y'<subscript>03</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start0 + 4:</entry>
|
||||
<entry>Y'<subscript>10</subscript></entry>
|
||||
<entry>Y'<subscript>11</subscript></entry>
|
||||
<entry>Y'<subscript>12</subscript></entry>
|
||||
<entry>Y'<subscript>13</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start0 + 8:</entry>
|
||||
<entry>Y'<subscript>20</subscript></entry>
|
||||
<entry>Y'<subscript>21</subscript></entry>
|
||||
<entry>Y'<subscript>22</subscript></entry>
|
||||
<entry>Y'<subscript>23</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start0 + 12:</entry>
|
||||
<entry>Y'<subscript>30</subscript></entry>
|
||||
<entry>Y'<subscript>31</subscript></entry>
|
||||
<entry>Y'<subscript>32</subscript></entry>
|
||||
<entry>Y'<subscript>33</subscript></entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry>start1 + 0:</entry>
|
||||
<entry>Cr<subscript>00</subscript></entry>
|
||||
<entry>Cr<subscript>01</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start1 + 2:</entry>
|
||||
<entry>Cr<subscript>10</subscript></entry>
|
||||
<entry>Cr<subscript>11</subscript></entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry>start2 + 0:</entry>
|
||||
<entry>Cb<subscript>00</subscript></entry>
|
||||
<entry>Cb<subscript>01</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start2 + 2:</entry>
|
||||
<entry>Cb<subscript>10</subscript></entry>
|
||||
<entry>Cb<subscript>11</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
|
||||
<formalpara>
|
||||
<title>Color Sample Location.</title>
|
||||
<para>
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="7" align="center">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
|
||||
<entry>2</entry><entry></entry><entry>3</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>0</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry><entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>1</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>2</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry><entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>3</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
</example>
|
||||
</refsect1>
|
||||
</refentry>
|
@ -708,6 +708,7 @@ information.</para>
|
||||
&sub-y41p;
|
||||
&sub-yuv420;
|
||||
&sub-yuv420m;
|
||||
&sub-yvu420m;
|
||||
&sub-yuv410;
|
||||
&sub-yuv422p;
|
||||
&sub-yuv411p;
|
||||
@ -757,6 +758,11 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see
|
||||
<entry>'AVC1'</entry>
|
||||
<entry>H264 video elementary stream without start codes.</entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-H264-MVC">
|
||||
<entry><constant>V4L2_PIX_FMT_H264_MVC</constant></entry>
|
||||
<entry>'MVC'</entry>
|
||||
<entry>H264 MVC video elementary stream.</entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-H263">
|
||||
<entry><constant>V4L2_PIX_FMT_H263</constant></entry>
|
||||
<entry>'H263'</entry>
|
||||
@ -792,6 +798,11 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see
|
||||
<entry>'VC1L'</entry>
|
||||
<entry>VC1, SMPTE 421M Annex L compliant stream.</entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-VP8">
|
||||
<entry><constant>V4L2_PIX_FMT_VP8</constant></entry>
|
||||
<entry>'VP8'</entry>
|
||||
<entry>VP8 video elementary stream.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
@ -995,6 +1006,34 @@ the other bits are set to 0.</entry>
|
||||
<entry>Old 6-bit greyscale format. Only the most significant 6 bits of each byte are used,
|
||||
the other bits are set to 0.</entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-S5C-UYVY-JPG">
|
||||
<entry><constant>V4L2_PIX_FMT_S5C_UYVY_JPG</constant></entry>
|
||||
<entry>'S5CI'</entry>
|
||||
<entry>Two-planar format used by Samsung S5C73MX cameras. The
|
||||
first plane contains interleaved JPEG and UYVY image data, followed by meta data
|
||||
in form of an array of offsets to the UYVY data blocks. The actual pointer array
|
||||
follows immediately the interleaved JPEG/UYVY data, the number of entries in
|
||||
this array equals the height of the UYVY image. Each entry is a 4-byte unsigned
|
||||
integer in big endian order and it's an offset to a single pixel line of the
|
||||
UYVY image. The first plane can start either with JPEG or UYVY data chunk. The
|
||||
size of a single UYVY block equals the UYVY image's width multiplied by 2. The
|
||||
size of a JPEG chunk depends on the image and can vary with each line.
|
||||
<para>The second plane, at an offset of 4084 bytes, contains a 4-byte offset to
|
||||
the pointer array in the first plane. This offset is followed by a 4-byte value
|
||||
indicating size of the pointer array. All numbers in the second plane are also
|
||||
in big endian order. Remaining data in the second plane is undefined. The
|
||||
information in the second plane allows to easily find location of the pointer
|
||||
array, which can be different for each frame. The size of the pointer array is
|
||||
constant for given UYVY image height.</para>
|
||||
<para>In order to extract UYVY and JPEG frames an application can initially set
|
||||
a data pointer to the start of first plane and then add an offset from the first
|
||||
entry of the pointers table. Such a pointer indicates start of an UYVY image
|
||||
pixel line. Whole UYVY line can be copied to a separate buffer. These steps
|
||||
should be repeated for each line, i.e. the number of entries in the pointer
|
||||
array. Anything what's in between the UYVY lines is JPEG data and should be
|
||||
concatenated to form the JPEG stream. </para>
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
@ -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>
|
||||
|
||||
|
@ -2565,5 +2565,49 @@
|
||||
</tgroup>
|
||||
</table>
|
||||
</section>
|
||||
|
||||
<section id="v4l2-mbus-vendor-spec-fmts">
|
||||
<title>Vendor and Device Specific Formats</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 section lists complex data formats that are either vendor or
|
||||
device specific.
|
||||
</para>
|
||||
|
||||
<para>The following table lists the existing vendor and device specific
|
||||
formats.</para>
|
||||
|
||||
<table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-vendor-specific">
|
||||
<title>Vendor and device specific formats</title>
|
||||
<tgroup cols="3">
|
||||
<colspec colname="id" align="left" />
|
||||
<colspec colname="code" align="left"/>
|
||||
<colspec colname="remarks" align="left"/>
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Identifier</entry>
|
||||
<entry>Code</entry>
|
||||
<entry>Comments</entry>
|
||||
</row>
|
||||
</thead>
|
||||
<tbody valign="top">
|
||||
<row id="V4L2-MBUS-FMT-S5C-UYVY-JPEG-1X8">
|
||||
<entry>V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8</entry>
|
||||
<entry>0x5001</entry>
|
||||
<entry>
|
||||
Interleaved raw UYVY and JPEG image format with embedded
|
||||
meta-data used by Samsung S3C73MX camera sensors.
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</section>
|
||||
|
||||
</section>
|
||||
</section>
|
||||
|
@ -145,9 +145,12 @@ applications. -->
|
||||
<authorinitials>hv</authorinitials>
|
||||
<revremark>Added VIDIOC_ENUM_FREQ_BANDS.
|
||||
</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>3.5</revnumber>
|
||||
<date>2012-05-07</date>
|
||||
<authorinitials>sa, sn</authorinitials>
|
||||
<authorinitials>sa, sn, hv</authorinitials>
|
||||
<revremark>Added V4L2_CTRL_TYPE_INTEGER_MENU and V4L2 subdev
|
||||
selections API. Improved the description of V4L2_CID_COLORFX
|
||||
control, added V4L2_CID_COLORFX_CBCR control.
|
||||
@ -158,11 +161,8 @@ applications. -->
|
||||
V4L2_CID_3A_LOCK, V4L2_CID_AUTO_FOCUS_START,
|
||||
V4L2_CID_AUTO_FOCUS_STOP, V4L2_CID_AUTO_FOCUS_STATUS
|
||||
and V4L2_CID_AUTO_FOCUS_RANGE.
|
||||
</revremark>
|
||||
<date>2012-05-01</date>
|
||||
<authorinitials>hv</authorinitials>
|
||||
<revremark>Added VIDIOC_ENUM_DV_TIMINGS, VIDIOC_QUERY_DV_TIMINGS and
|
||||
VIDIOC_DV_TIMINGS_CAP.
|
||||
Added VIDIOC_ENUM_DV_TIMINGS, VIDIOC_QUERY_DV_TIMINGS and
|
||||
VIDIOC_DV_TIMINGS_CAP.
|
||||
</revremark>
|
||||
</revision>
|
||||
|
||||
@ -472,7 +472,7 @@ and discussions on the V4L mailing list.</revremark>
|
||||
</partinfo>
|
||||
|
||||
<title>Video for Linux Two API Specification</title>
|
||||
<subtitle>Revision 3.5</subtitle>
|
||||
<subtitle>Revision 3.6</subtitle>
|
||||
|
||||
<chapter id="common">
|
||||
&sub-common;
|
||||
@ -581,6 +581,7 @@ and discussions on the V4L mailing list.</revremark>
|
||||
&sub-subdev-enum-frame-size;
|
||||
&sub-subdev-enum-mbus-code;
|
||||
&sub-subdev-g-crop;
|
||||
&sub-subdev-g-edid;
|
||||
&sub-subdev-g-fmt;
|
||||
&sub-subdev-g-frame-interval;
|
||||
&sub-subdev-g-selection;
|
||||
|
@ -59,6 +59,9 @@ constant except when switching the video standard. Remember this
|
||||
switch can occur implicit when switching the video input or
|
||||
output.</para>
|
||||
|
||||
<para>This ioctl must be implemented for video capture or output devices that
|
||||
support cropping and/or scaling and/or have non-square pixels, and for overlay devices.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-cropcap">
|
||||
<title>struct <structname>v4l2_cropcap</structname></title>
|
||||
<tgroup cols="3">
|
||||
@ -70,10 +73,10 @@ output.</para>
|
||||
<entry>Type of the data stream, set by the application.
|
||||
Only these types are valid here:
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver
|
||||
defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant>
|
||||
and higher. See <xref linkend="v4l2-buf-type" />.</entry>
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant> and
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>. See <xref linkend="v4l2-buf-type" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>struct <link linkend="v4l2-rect-crop">v4l2_rect</link></entry>
|
||||
@ -156,8 +159,7 @@ on 22 Oct 2002 subject "Re:[V4L][patches!] Re:v4l2/kernel-2.5" -->
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The &v4l2-cropcap; <structfield>type</structfield> is
|
||||
invalid. This is not permitted for video capture, output and overlay devices,
|
||||
which must support <constant>VIDIOC_CROPCAP</constant>.</para>
|
||||
invalid.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
@ -49,13 +49,6 @@
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
|
||||
<para>This is an <link linkend="experimental">experimental</link>
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
<para>These ioctls control an audio/video (usually MPEG-) decoder.
|
||||
<constant>VIDIOC_DECODER_CMD</constant> sends a command to the
|
||||
decoder, <constant>VIDIOC_TRY_DECODER_CMD</constant> can be used to
|
||||
|
@ -49,13 +49,6 @@
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
|
||||
<para>This is an <link linkend="experimental">experimental</link>
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
<para>These ioctls control an audio/video (usually MPEG-) encoder.
|
||||
<constant>VIDIOC_ENCODER_CMD</constant> sends a command to the
|
||||
encoder, <constant>VIDIOC_TRY_ENCODER_CMD</constant> can be used to
|
||||
|
@ -229,6 +229,12 @@ intended for the user.</entry>
|
||||
is out of bounds.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>Digital video presets are not supported for this input or output.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
@ -106,6 +106,12 @@ application.</entry>
|
||||
is out of bounds.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>Digital video presets are not supported for this input or output.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
@ -58,6 +58,9 @@ structure. Drivers fill the rest of the structure or return an
|
||||
incrementing by one until <errorcode>EINVAL</errorcode> is
|
||||
returned.</para>
|
||||
|
||||
<para>Note that after switching input or output the list of enumerated image
|
||||
formats may be different.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-fmtdesc">
|
||||
<title>struct <structname>v4l2_fmtdesc</structname></title>
|
||||
<tgroup cols="3">
|
||||
@ -78,10 +81,8 @@ Only these types are valid here:
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver
|
||||
defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant>
|
||||
and higher. See <xref linkend="v4l2-buf-type" />.</entry>
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant> and
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>. See <xref linkend="v4l2-buf-type" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
@ -50,13 +50,6 @@ and pixel format and receives a frame width and height.</para>
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
|
||||
<para>This is an <link linkend="experimental">experimental</link>
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
<para>This ioctl allows applications to enumerate all frame sizes
|
||||
(&ie; width and height in pixels) that the device supports for the
|
||||
given pixel format.</para>
|
||||
|
@ -283,7 +283,7 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
|
||||
<entry>This input supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_IN_CAP_CUSTOM_TIMINGS</constant></entry>
|
||||
<entry><constant>V4L2_IN_CAP_DV_TIMINGS</constant></entry>
|
||||
<entry>0x00000002</entry>
|
||||
<entry>This input supports setting video timings by using VIDIOC_S_DV_TIMINGS.</entry>
|
||||
</row>
|
||||
|
@ -168,7 +168,7 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
|
||||
<entry>This output supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_OUT_CAP_CUSTOM_TIMINGS</constant></entry>
|
||||
<entry><constant>V4L2_OUT_CAP_DV_TIMINGS</constant></entry>
|
||||
<entry>0x00000002</entry>
|
||||
<entry>This output supports setting video timings by using VIDIOC_S_DV_TIMINGS.</entry>
|
||||
</row>
|
||||
|
@ -378,6 +378,12 @@ system)</para></footnote></para></entry>
|
||||
is out of bounds.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>Standard video timings are not supported for this input or output.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
@ -104,10 +104,8 @@ changed and <constant>VIDIOC_S_CROP</constant> returns the
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry>Type of the data stream, set by the application.
|
||||
Only these types are valid here: <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver
|
||||
defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant>
|
||||
and higher. See <xref linkend="v4l2-buf-type" />.</entry>
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> and
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>. See <xref linkend="v4l2-buf-type" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-rect;</entry>
|
||||
|
@ -77,6 +77,12 @@ If the preset is not supported, it returns an &EINVAL; </para>
|
||||
<constant>VIDIOC_S_DV_PRESET</constant>,<constant>VIDIOC_S_DV_PRESET</constant> parameter was unsuitable.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>Digital video presets are not supported for this input or output.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EBUSY</errorcode></term>
|
||||
<listitem>
|
||||
@ -104,7 +110,4 @@ If the preset is not supported, it returns an &EINVAL; </para>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
<refsect1>
|
||||
&return-value;
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
@ -56,7 +56,9 @@ a pointer to the &v4l2-dv-timings; structure as argument. If the ioctl is not su
|
||||
or the timing values are not correct, the driver returns &EINVAL;.</para>
|
||||
<para>The <filename>linux/v4l2-dv-timings.h</filename> header can be used to get the
|
||||
timings of the formats in the <xref linkend="cea861" /> and <xref linkend="vesadmt" />
|
||||
standards.</para>
|
||||
standards. If the current input or output does not support DV timings (e.g. if
|
||||
&VIDIOC-ENUMINPUT; does not set the <constant>V4L2_IN_CAP_DV_TIMINGS</constant> flag), then
|
||||
&ENODATA; is returned.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
@ -70,6 +72,12 @@ standards.</para>
|
||||
<constant>VIDIOC_S_DV_TIMINGS</constant> parameter was unsuitable.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>Digital video timings are not supported for this input or output.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EBUSY</errorcode></term>
|
||||
<listitem>
|
||||
@ -320,7 +328,4 @@ detected or used depends on the hardware.
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
<refsect1>
|
||||
&return-value;
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
@ -48,13 +48,6 @@
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
|
||||
<para>This is an <link linkend="experimental">experimental</link>
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
<para>The <constant>VIDIOC_G_ENC_INDEX</constant> ioctl provides
|
||||
meta data about a compressed video stream the same or another
|
||||
application currently reads from the driver, which is useful for
|
||||
|
@ -81,7 +81,7 @@ the application calls the <constant>VIDIOC_S_FMT</constant> ioctl
|
||||
with a pointer to a <structname>v4l2_format</structname> structure
|
||||
the driver checks
|
||||
and adjusts the parameters against hardware abilities. Drivers
|
||||
should not return an error code unless the input is ambiguous, this is
|
||||
should not return an error code unless the <structfield>type</structfield> field is invalid, this is
|
||||
a mechanism to fathom device capabilities and to approach parameters
|
||||
acceptable for both the application and driver. On success the driver
|
||||
may program the hardware, allocate resources and generally prepare for
|
||||
@ -107,6 +107,10 @@ disabling I/O or possibly time consuming hardware preparations.
|
||||
Although strongly recommended drivers are not required to implement
|
||||
this ioctl.</para>
|
||||
|
||||
<para>The format as returned by <constant>VIDIOC_TRY_FMT</constant>
|
||||
must be identical to what <constant>VIDIOC_S_FMT</constant> returns for
|
||||
the same input or output.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-format">
|
||||
<title>struct <structname>v4l2_format</structname></title>
|
||||
<tgroup cols="4">
|
||||
@ -170,9 +174,7 @@ capture and output devices.</entry>
|
||||
<entry></entry>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>raw_data</structfield>[200]</entry>
|
||||
<entry>Place holder for future extensions and custom
|
||||
(driver defined) formats with <structfield>type</structfield>
|
||||
<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher.</entry>
|
||||
<entry>Place holder for future extensions.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
@ -187,8 +189,7 @@ capture and output devices.</entry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The &v4l2-format; <structfield>type</structfield>
|
||||
field is invalid, the requested buffer type not supported, or the
|
||||
format is not supported with this buffer type.</para>
|
||||
field is invalid or the requested buffer type not supported.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
@ -108,9 +108,7 @@ devices.</para>
|
||||
<entry></entry>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>raw_data</structfield>[200]</entry>
|
||||
<entry>A place holder for future extensions and custom
|
||||
(driver defined) buffer types <constant>V4L2_BUF_TYPE_PRIVATE</constant> and
|
||||
higher.</entry>
|
||||
<entry>A place holder for future extensions.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
@ -152,12 +152,10 @@ satisfactory parameters have been negotiated. If constraints flags have to be
|
||||
violated at then ERANGE is returned. The error indicates that <emphasis> there
|
||||
exist no rectangle </emphasis> that satisfies the constraints.</para>
|
||||
|
||||
</refsect1>
|
||||
|
||||
<para>Selection targets and flags are documented in <xref
|
||||
linkend="v4l2-selections-common"/>.</para>
|
||||
|
||||
<section>
|
||||
<para>
|
||||
<figure id="sel-const-adjust">
|
||||
<title>Size adjustments with constraint flags.</title>
|
||||
<mediaobject>
|
||||
@ -170,9 +168,9 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
|
||||
</textobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
</section>
|
||||
</para>
|
||||
|
||||
<refsect1>
|
||||
<para>
|
||||
<table pgwide="1" frame="none" id="v4l2-selection">
|
||||
<title>struct <structname>v4l2_selection</structname></title>
|
||||
<tgroup cols="3">
|
||||
@ -208,6 +206,7 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
@ -72,7 +72,9 @@ flags, being a write-only ioctl it does not return the actual new standard as
|
||||
the current input does not support the requested standard the driver
|
||||
returns an &EINVAL;. When the standard set is ambiguous drivers may
|
||||
return <errorcode>EINVAL</errorcode> or choose any of the requested
|
||||
standards.</para>
|
||||
standards. If the current input or output does not support standard video timings (e.g. if
|
||||
&VIDIOC-ENUMINPUT; does not set the <constant>V4L2_IN_CAP_STD</constant> flag), then
|
||||
&ENODATA; is returned.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
@ -85,6 +87,12 @@ standards.</para>
|
||||
<para>The <constant>VIDIOC_S_STD</constant> parameter was unsuitable.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>Standard video timings are not supported for this input or output.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
@ -354,6 +354,12 @@ radio tuners.</entry>
|
||||
<entry>The &VIDIOC-ENUM-FREQ-BANDS; ioctl can be used to enumerate
|
||||
the available frequency bands.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_TUNER_CAP_HWSEEK_PROG_LIM</constant></entry>
|
||||
<entry>0x0800</entry>
|
||||
<entry>The range to search when using the hardware seek functionality
|
||||
is programmable, see &VIDIOC-S-HW-FREQ-SEEK; for details.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
@ -121,8 +121,7 @@ remaining fields or returns an error code. The driver may also set
|
||||
field. It indicates a non-critical (recoverable) streaming error. In such case
|
||||
the application may continue as normal, but should be aware that data in the
|
||||
dequeued buffer might be corrupted. When using the multi-planar API, the
|
||||
planes array does not have to be passed; the <structfield>m.planes</structfield>
|
||||
member must be set to NULL in that case.</para>
|
||||
planes array must be passed in as well.</para>
|
||||
|
||||
<para>By default <constant>VIDIOC_DQBUF</constant> blocks when no
|
||||
buffer is in the outgoing queue. When the
|
||||
@ -155,6 +154,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>
|
||||
|
@ -48,8 +48,8 @@
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This ioctl is part of the <link linkend="mmap">memory
|
||||
mapping</link> I/O method. It can be used to query the status of a
|
||||
<para>This ioctl is part of the <link linkend="mmap">streaming
|
||||
</link> I/O method. It can be used to query the status of a
|
||||
buffer at any time after buffers have been allocated with the
|
||||
&VIDIOC-REQBUFS; ioctl.</para>
|
||||
|
||||
@ -71,6 +71,7 @@ the structure.</para>
|
||||
|
||||
<para>In the <structfield>flags</structfield> field the
|
||||
<constant>V4L2_BUF_FLAG_MAPPED</constant>,
|
||||
<constant>V4L2_BUF_FLAG_PREPARED</constant>,
|
||||
<constant>V4L2_BUF_FLAG_QUEUED</constant> and
|
||||
<constant>V4L2_BUF_FLAG_DONE</constant> flags will be valid. The
|
||||
<structfield>memory</structfield> field will be set to the current
|
||||
@ -79,8 +80,10 @@ contains the offset of the buffer from the start of the device memory,
|
||||
the <structfield>length</structfield> field its size. For the multi-planar API,
|
||||
fields <structfield>m.mem_offset</structfield> and
|
||||
<structfield>length</structfield> in the <structfield>m.planes</structfield>
|
||||
array elements will be used instead. The driver may or may not set the remaining
|
||||
fields and flags, they are meaningless in this context.</para>
|
||||
array elements will be used instead and the <structfield>length</structfield>
|
||||
field of &v4l2-buffer; is set to the number of filled-in array elements.
|
||||
The driver may or may not set the remaining fields and flags, they are
|
||||
meaningless in this context.</para>
|
||||
|
||||
<para>The <structname>v4l2_buffer</structname> structure is
|
||||
specified in <xref linkend="buffer" />.</para>
|
||||
|
@ -90,11 +90,13 @@ ambiguities.</entry>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>bus_info</structfield>[32]</entry>
|
||||
<entry>Location of the device in the system, a
|
||||
NUL-terminated ASCII string. For example: "PCI Slot 4". This
|
||||
NUL-terminated ASCII string. For example: "PCI:0000:05:06.0". This
|
||||
information is intended for users, to distinguish multiple
|
||||
identical devices. If no such information is available the field may
|
||||
simply count the devices controlled by the driver, or contain the
|
||||
empty string (<structfield>bus_info</structfield>[0] = 0).<!-- XXX pci_dev->slot_name example --></entry>
|
||||
identical devices. If no such information is available the field must
|
||||
simply count the devices controlled by the driver ("platform:vivi-000").
|
||||
The bus_info must start with "PCI:" for PCI boards, "PCIe:" for PCI Express boards,
|
||||
"usb-" for USB devices, "I2C:" for i2c devices, "ISA:" for ISA devices,
|
||||
"parport" for parallel port devices and "platform:" for platform devices.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
@ -62,5 +62,13 @@ current video input or output.</para>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>Standard video timings are not supported for this input or output.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
@ -109,9 +109,8 @@ as the &v4l2-format; <structfield>type</structfield> field. See <xref
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[2]</entry>
|
||||
<entry>A place holder for future extensions and custom
|
||||
(driver defined) buffer types <constant>V4L2_BUF_TYPE_PRIVATE</constant> and
|
||||
higher. This array should be zeroed by applications.</entry>
|
||||
<entry>A place holder for future extensions. This array should
|
||||
be zeroed by applications.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
@ -75,6 +75,9 @@ seek is started.</para>
|
||||
|
||||
<para>This ioctl is supported if the <constant>V4L2_CAP_HW_FREQ_SEEK</constant> capability is set.</para>
|
||||
|
||||
<para>If this ioctl is called from a non-blocking filehandle, then &EAGAIN; is
|
||||
returned and no seek takes place.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-hw-freq-seek">
|
||||
<title>struct <structname>v4l2_hw_freq_seek</structname></title>
|
||||
<tgroup cols="3">
|
||||
@ -157,6 +160,13 @@ one of the values in the <structfield>type</structfield>,
|
||||
fields is wrong.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EAGAIN</errorcode></term>
|
||||
<listitem>
|
||||
<para>Attempted to call <constant>VIDIOC_S_HW_FREQ_SEEK</constant>
|
||||
with the filehandle in non-blocking mode.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
|
@ -74,7 +74,12 @@ not transmitted yet. I/O returns to the same state as after calling
|
||||
stream type. This is the same as &v4l2-requestbuffers;
|
||||
<structfield>type</structfield>.</para>
|
||||
|
||||
<para>Note applications can be preempted for unknown periods right
|
||||
<para>If <constant>VIDIOC_STREAMON</constant> is called when streaming
|
||||
is already in progress, or if <constant>VIDIOC_STREAMOFF</constant> is called
|
||||
when streaming is already stopped, then the ioctl does nothing and 0 is
|
||||
returned.</para>
|
||||
|
||||
<para>Note that applications can be preempted for unknown periods right
|
||||
before or after the <constant>VIDIOC_STREAMON</constant> or
|
||||
<constant>VIDIOC_STREAMOFF</constant> calls, there is no notion of
|
||||
starting or stopping "now". Buffer timestamps can be used to
|
||||
|
152
Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml
Normal file
152
Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml
Normal file
@ -0,0 +1,152 @@
|
||||
<refentry id="vidioc-subdev-g-edid">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_SUBDEV_G_EDID</refname>
|
||||
<refname>VIDIOC_SUBDEV_S_EDID</refname>
|
||||
<refpurpose>Get or set the EDID of a video receiver/transmitter</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>struct v4l2_subdev_edid *<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>const struct v4l2_subdev_edid *<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>&fd;</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
<para>These ioctls can be used to get or set an EDID associated with an input pad
|
||||
from a receiver or an output pad of a transmitter subdevice.</para>
|
||||
|
||||
<para>To get the EDID data the application has to fill in the <structfield>pad</structfield>,
|
||||
<structfield>start_block</structfield>, <structfield>blocks</structfield> and <structfield>edid</structfield>
|
||||
fields and call <constant>VIDIOC_SUBDEV_G_EDID</constant>. The current EDID from block
|
||||
<structfield>start_block</structfield> and of size <structfield>blocks</structfield>
|
||||
will be placed in the memory <structfield>edid</structfield> points to. The <structfield>edid</structfield>
|
||||
pointer must point to memory at least <structfield>blocks</structfield> * 128 bytes
|
||||
large (the size of one block is 128 bytes).</para>
|
||||
|
||||
<para>If there are fewer blocks than specified, then the driver will set <structfield>blocks</structfield>
|
||||
to the actual number of blocks. If there are no EDID blocks available at all, then the error code
|
||||
ENODATA is set.</para>
|
||||
|
||||
<para>If blocks have to be retrieved from the sink, then this call will block until they
|
||||
have been read.</para>
|
||||
|
||||
<para>To set the EDID blocks of a receiver the application has to fill in the <structfield>pad</structfield>,
|
||||
<structfield>blocks</structfield> and <structfield>edid</structfield> fields and set
|
||||
<structfield>start_block</structfield> to 0. It is not possible to set part of an EDID,
|
||||
it is always all or nothing. Setting the EDID data is only valid for receivers as it makes
|
||||
no sense for a transmitter.</para>
|
||||
|
||||
<para>The driver assumes that the full EDID is passed in. If there are more EDID blocks than
|
||||
the hardware can handle then the EDID is not written, but instead the error code E2BIG is set
|
||||
and <structfield>blocks</structfield> is set to the maximum that the hardware supports.
|
||||
If <structfield>start_block</structfield> is any
|
||||
value other than 0 then the error code EINVAL is set.</para>
|
||||
|
||||
<para>To disable an EDID you set <structfield>blocks</structfield> to 0. Depending on the
|
||||
hardware this will drive the hotplug pin low and/or block the source from reading the EDID
|
||||
data in some way. In any case, the end result is the same: the EDID is no longer available.
|
||||
</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-subdev-edid">
|
||||
<title>struct <structname>v4l2_subdev_edid</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>pad</structfield></entry>
|
||||
<entry>Pad for which to get/set the EDID blocks.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>start_block</structfield></entry>
|
||||
<entry>Read the EDID from starting with this block. Must be 0 when setting
|
||||
the EDID.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>blocks</structfield></entry>
|
||||
<entry>The number of blocks to get or set. Must be less or equal to 256 (the
|
||||
maximum number of blocks as defined by the standard). When you set the EDID and
|
||||
<structfield>blocks</structfield> is 0, then the EDID is disabled or erased.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u8 *</entry>
|
||||
<entry><structfield>edid</structfield></entry>
|
||||
<entry>Pointer to memory that contains the EDID. The minimum size is
|
||||
<structfield>blocks</structfield> * 128.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[5]</entry>
|
||||
<entry>Reserved for future extensions. Applications and drivers must
|
||||
set the array to zero.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>The EDID data is not available.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>E2BIG</errorcode></term>
|
||||
<listitem>
|
||||
<para>The EDID data you provided is more than the hardware can handle.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
@ -69,23 +69,22 @@
|
||||
more information on how each selection target affects the image
|
||||
processing pipeline inside the subdevice.</para>
|
||||
|
||||
<section>
|
||||
<refsect2>
|
||||
<title>Types of selection targets</title>
|
||||
|
||||
<para>There are two types of selection targets: actual and bounds. The
|
||||
actual targets are the targets which configure the hardware. The BOUNDS
|
||||
target will return a rectangle that contain all possible actual
|
||||
rectangles.</para>
|
||||
</section>
|
||||
</refsect2>
|
||||
|
||||
<section>
|
||||
<refsect2>
|
||||
<title>Discovering supported features</title>
|
||||
|
||||
<para>To discover which targets are supported, the user can
|
||||
perform <constant>VIDIOC_SUBDEV_G_SELECTION</constant> on them.
|
||||
Any unsupported target will return
|
||||
<constant>EINVAL</constant>.</para>
|
||||
</section>
|
||||
|
||||
<para>Selection targets and flags are documented in <xref
|
||||
linkend="v4l2-selections-common"/>.</para>
|
||||
@ -132,6 +131,7 @@
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect2>
|
||||
|
||||
</refsect1>
|
||||
|
||||
|
@ -29,7 +29,7 @@
|
||||
<title>LINUX MEDIA INFRASTRUCTURE API</title>
|
||||
|
||||
<copyright>
|
||||
<year>2009-2011</year>
|
||||
<year>2009-2012</year>
|
||||
<holder>LinuxTV Developers</holder>
|
||||
</copyright>
|
||||
|
||||
@ -53,7 +53,7 @@ Foundation. A copy of the license is included in the chapter entitled
|
||||
video and radio straming devices, including video cameras,
|
||||
analog and digital TV receiver cards, AM/FM receiver cards,
|
||||
streaming capture devices.</para>
|
||||
<para>It is divided into three parts.</para>
|
||||
<para>It is divided into four parts.</para>
|
||||
<para>The first part covers radio, capture,
|
||||
cameras and analog TV devices.</para>
|
||||
<para>The second part covers the
|
||||
@ -62,7 +62,8 @@ Foundation. A copy of the license is included in the chapter entitled
|
||||
in fact it covers several different video standards including
|
||||
DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated
|
||||
to documment support also for DVB-S2, ISDB-T and ISDB-S.</para>
|
||||
<para>The third part covers Remote Controller API</para>
|
||||
<para>The third part covers the Remote Controller API.</para>
|
||||
<para>The fourth part covers the Media Controller API.</para>
|
||||
<para>For additional information and for the latest development code,
|
||||
see: <ulink url="http://linuxtv.org">http://linuxtv.org</ulink>.</para>
|
||||
<para>For discussing improvements, reporting troubles, sending new drivers, etc, please mail to: <ulink url="http://vger.kernel.org/vger-lists.html#linux-media">Linux Media Mailing List (LMML).</ulink>.</para>
|
||||
@ -87,7 +88,7 @@ Foundation. A copy of the license is included in the chapter entitled
|
||||
</author>
|
||||
</authorgroup>
|
||||
<copyright>
|
||||
<year>2009-2011</year>
|
||||
<year>2009-2012</year>
|
||||
<holder>Mauro Carvalho Chehab</holder>
|
||||
</copyright>
|
||||
|
||||
|
@ -1216,8 +1216,6 @@ in this page</entry>
|
||||
#define NAND_BBT_LASTBLOCK 0x00000010
|
||||
/* The bbt is at the given page, else we must scan for the bbt */
|
||||
#define NAND_BBT_ABSPAGE 0x00000020
|
||||
/* The bbt is at the given page, else we must scan for the bbt */
|
||||
#define NAND_BBT_SEARCH 0x00000040
|
||||
/* bbt is stored per chip on multichip devices */
|
||||
#define NAND_BBT_PERCHIP 0x00000080
|
||||
/* bbt has a version counter at offset veroffs */
|
||||
|
@ -56,7 +56,7 @@
|
||||
!Enet/core/filter.c
|
||||
</sect1>
|
||||
<sect1><title>Generic Network Statistics</title>
|
||||
!Iinclude/linux/gen_stats.h
|
||||
!Iinclude/uapi/linux/gen_stats.h
|
||||
!Enet/core/gen_stats.c
|
||||
!Enet/core/gen_estimator.c
|
||||
</sect1>
|
||||
@ -80,7 +80,7 @@
|
||||
!Enet/wimax/op-rfkill.c
|
||||
!Enet/wimax/stack.c
|
||||
!Iinclude/net/wimax.h
|
||||
!Iinclude/linux/wimax.h
|
||||
!Iinclude/uapi/linux/wimax.h
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
|
@ -42,13 +42,7 @@ The driver interface depends on your hardware. If your system
|
||||
properly provides the SMBIOS info for IPMI, the driver will detect it
|
||||
and just work. If you have a board with a standard interface (These
|
||||
will generally be either "KCS", "SMIC", or "BT", consult your hardware
|
||||
manual), choose the 'IPMI SI handler' option. A driver also exists
|
||||
for direct I2C access to the IPMI management controller. Some boards
|
||||
support this, but it is unknown if it will work on every board. For
|
||||
this, choose 'IPMI SMBus handler', but be ready to try to do some
|
||||
figuring to see if it will work on your system if the SMBIOS/APCI
|
||||
information is wrong or not present. It is fairly safe to have both
|
||||
these enabled and let the drivers auto-detect what is present.
|
||||
manual), choose the 'IPMI SI handler' option.
|
||||
|
||||
You should generally enable ACPI on your system, as systems with IPMI
|
||||
can have ACPI tables describing them.
|
||||
@ -58,8 +52,7 @@ their job correctly, the IPMI controller should be automatically
|
||||
detected (via ACPI or SMBIOS tables) and should just work. Sadly,
|
||||
many boards do not have this information. The driver attempts
|
||||
standard defaults, but they may not work. If you fall into this
|
||||
situation, you need to read the section below named 'The SI Driver' or
|
||||
"The SMBus Driver" on how to hand-configure your system.
|
||||
situation, you need to read the section below named 'The SI Driver'.
|
||||
|
||||
IPMI defines a standard watchdog timer. You can enable this with the
|
||||
'IPMI Watchdog Timer' config option. If you compile the driver into
|
||||
@ -104,12 +97,7 @@ driver, each open file for this device ties in to the message handler
|
||||
as an IPMI user.
|
||||
|
||||
ipmi_si - A driver for various system interfaces. This supports KCS,
|
||||
SMIC, and BT interfaces. Unless you have an SMBus interface or your
|
||||
own custom interface, you probably need to use this.
|
||||
|
||||
ipmi_smb - A driver for accessing BMCs on the SMBus. It uses the
|
||||
I2C kernel driver's SMBus interfaces to send and receive IPMI messages
|
||||
over the SMBus.
|
||||
SMIC, and BT interfaces.
|
||||
|
||||
ipmi_watchdog - IPMI requires systems to have a very capable watchdog
|
||||
timer. This driver implements the standard Linux watchdog timer
|
||||
@ -482,53 +470,6 @@ for specifying an interface. Note that when removing an interface,
|
||||
only the first three parameters (si type, address type, and address)
|
||||
are used for the comparison. Any options are ignored for removing.
|
||||
|
||||
The SMBus Driver
|
||||
----------------
|
||||
|
||||
The SMBus driver allows up to 4 SMBus devices to be configured in the
|
||||
system. By default, the driver will register any SMBus interfaces it finds
|
||||
in the I2C address range of 0x20 to 0x4f on any adapter. You can change this
|
||||
at module load time (for a module) with:
|
||||
|
||||
modprobe ipmi_smb.o
|
||||
addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]]
|
||||
dbg=<flags1>,<flags2>...
|
||||
[defaultprobe=1] [dbg_probe=1]
|
||||
|
||||
The addresses are specified in pairs, the first is the adapter ID and the
|
||||
second is the I2C address on that adapter.
|
||||
|
||||
The debug flags are bit flags for each BMC found, they are:
|
||||
IPMI messages: 1, driver state: 2, timing: 4, I2C probe: 8
|
||||
|
||||
Setting smb_defaultprobe to zero disabled the default probing of SMBus
|
||||
interfaces at address range 0x20 to 0x4f. This means that only the
|
||||
BMCs specified on the smb_addr line will be detected.
|
||||
|
||||
Setting smb_dbg_probe to 1 will enable debugging of the probing and
|
||||
detection process for BMCs on the SMBusses.
|
||||
|
||||
Discovering the IPMI compliant BMC on the SMBus can cause devices
|
||||
on the I2C bus to fail. The SMBus driver writes a "Get Device ID" IPMI
|
||||
message as a block write to the I2C bus and waits for a response.
|
||||
This action can be detrimental to some I2C devices. It is highly recommended
|
||||
that the known I2c address be given to the SMBus driver in the smb_addr
|
||||
parameter. The default address range will not be used when a smb_addr
|
||||
parameter is provided.
|
||||
|
||||
When compiled into the kernel, the addresses can be specified on the
|
||||
kernel command line as:
|
||||
|
||||
ipmb_smb.addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]]
|
||||
ipmi_smb.dbg=<flags1>,<flags2>...
|
||||
ipmi_smb.defaultprobe=0 ipmi_smb.dbg_probe=1
|
||||
|
||||
These are the same options as on the module command line.
|
||||
|
||||
Note that you might need some I2C changes if CONFIG_IPMI_PANIC_EVENT
|
||||
is enabled along with this, so the I2C driver knows to run to
|
||||
completion during sending a panic event.
|
||||
|
||||
|
||||
Other Pieces
|
||||
------------
|
||||
|
@ -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"
|
||||
|
@ -154,13 +154,33 @@ In either case, the following conditions must be met:
|
||||
|
||||
- CPU mode
|
||||
All forms of interrupts must be disabled (IRQs and FIQs)
|
||||
The CPU must be in SVC mode. (A special exception exists for Angel)
|
||||
|
||||
For CPUs which do not include the ARM virtualization extensions, the
|
||||
CPU must be in SVC mode. (A special exception exists for Angel)
|
||||
|
||||
CPUs which include support for the virtualization extensions can be
|
||||
entered in HYP mode in order to enable the kernel to make full use of
|
||||
these extensions. This is the recommended boot method for such CPUs,
|
||||
unless the virtualisations are already in use by a pre-installed
|
||||
hypervisor.
|
||||
|
||||
If the kernel is not entered in HYP mode for any reason, it must be
|
||||
entered in SVC mode.
|
||||
|
||||
- Caches, MMUs
|
||||
The MMU must be off.
|
||||
Instruction cache may be on or off.
|
||||
Data cache must be off.
|
||||
|
||||
If the kernel is entered in HYP mode, the above requirements apply to
|
||||
the HYP mode configuration in addition to the ordinary PL1 (privileged
|
||||
kernel modes) configuration. In addition, all traps into the
|
||||
hypervisor must be disabled, and PL1 access must be granted for all
|
||||
peripherals and CPU resources for which this is architecturally
|
||||
possible. Except for entering in HYP mode, the system configuration
|
||||
should be such that a kernel which does not include support for the
|
||||
virtualization extensions can boot correctly without extra help.
|
||||
|
||||
- The boot loader is expected to call the kernel image by jumping
|
||||
directly to the first instruction of the kernel image.
|
||||
|
||||
|
@ -465,7 +465,6 @@ struct bio {
|
||||
bio_end_io_t *bi_end_io; /* bi_end_io (bio) */
|
||||
atomic_t bi_cnt; /* pin count: free when it hits zero */
|
||||
void *bi_private;
|
||||
bio_destructor_t *bi_destructor; /* bi_destructor (bio) */
|
||||
};
|
||||
|
||||
With this multipage bio design:
|
||||
@ -647,10 +646,6 @@ for a non-clone bio. There are the 6 pools setup for different size biovecs,
|
||||
so bio_alloc(gfp_mask, nr_iovecs) will allocate a vec_list of the
|
||||
given size from these slabs.
|
||||
|
||||
The bi_destructor() routine takes into account the possibility of the bio
|
||||
having originated from a different source (see later discussions on
|
||||
n/w to block transfers and kvec_cb)
|
||||
|
||||
The bio_get() routine may be used to hold an extra reference on a bio prior
|
||||
to i/o submission, if the bio fields are likely to be accessed after the
|
||||
i/o is issued (since the bio may otherwise get freed in case i/o completion
|
||||
|
@ -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.
|
||||
|
||||
|
312
Documentation/crypto/asymmetric-keys.txt
Normal file
312
Documentation/crypto/asymmetric-keys.txt
Normal file
@ -0,0 +1,312 @@
|
||||
=============================================
|
||||
ASYMMETRIC / PUBLIC-KEY CRYPTOGRAPHY KEY TYPE
|
||||
=============================================
|
||||
|
||||
Contents:
|
||||
|
||||
- Overview.
|
||||
- Key identification.
|
||||
- Accessing asymmetric keys.
|
||||
- Signature verification.
|
||||
- Asymmetric key subtypes.
|
||||
- Instantiation data parsers.
|
||||
|
||||
|
||||
========
|
||||
OVERVIEW
|
||||
========
|
||||
|
||||
The "asymmetric" key type is designed to be a container for the keys used in
|
||||
public-key cryptography, without imposing any particular restrictions on the
|
||||
form or mechanism of the cryptography or form of the key.
|
||||
|
||||
The asymmetric key is given a subtype that defines what sort of data is
|
||||
associated with the key and provides operations to describe and destroy it.
|
||||
However, no requirement is made that the key data actually be stored in the
|
||||
key.
|
||||
|
||||
A completely in-kernel key retention and operation subtype can be defined, but
|
||||
it would also be possible to provide access to cryptographic hardware (such as
|
||||
a TPM) that might be used to both retain the relevant key and perform
|
||||
operations using that key. In such a case, the asymmetric key would then
|
||||
merely be an interface to the TPM driver.
|
||||
|
||||
Also provided is the concept of a data parser. Data parsers are responsible
|
||||
for extracting information from the blobs of data passed to the instantiation
|
||||
function. The first data parser that recognises the blob gets to set the
|
||||
subtype of the key and define the operations that can be done on that key.
|
||||
|
||||
A data parser may interpret the data blob as containing the bits representing a
|
||||
key, or it may interpret it as a reference to a key held somewhere else in the
|
||||
system (for example, a TPM).
|
||||
|
||||
|
||||
==================
|
||||
KEY IDENTIFICATION
|
||||
==================
|
||||
|
||||
If a key is added with an empty name, the instantiation data parsers are given
|
||||
the opportunity to pre-parse a key and to determine the description the key
|
||||
should be given from the content of the key.
|
||||
|
||||
This can then be used to refer to the key, either by complete match or by
|
||||
partial match. The key type may also use other criteria to refer to a key.
|
||||
|
||||
The asymmetric key type's match function can then perform a wider range of
|
||||
comparisons than just the straightforward comparison of the description with
|
||||
the criterion string:
|
||||
|
||||
(1) If the criterion string is of the form "id:<hexdigits>" then the match
|
||||
function will examine a key's fingerprint to see if the hex digits given
|
||||
after the "id:" match the tail. For instance:
|
||||
|
||||
keyctl search @s asymmetric id:5acc2142
|
||||
|
||||
will match a key with fingerprint:
|
||||
|
||||
1A00 2040 7601 7889 DE11 882C 3823 04AD 5ACC 2142
|
||||
|
||||
(2) If the criterion string is of the form "<subtype>:<hexdigits>" then the
|
||||
match will match the ID as in (1), but with the added restriction that
|
||||
only keys of the specified subtype (e.g. tpm) will be matched. For
|
||||
instance:
|
||||
|
||||
keyctl search @s asymmetric tpm:5acc2142
|
||||
|
||||
Looking in /proc/keys, the last 8 hex digits of the key fingerprint are
|
||||
displayed, along with the subtype:
|
||||
|
||||
1a39e171 I----- 1 perm 3f010000 0 0 asymmetri modsign.0: DSA 5acc2142 []
|
||||
|
||||
|
||||
=========================
|
||||
ACCESSING ASYMMETRIC KEYS
|
||||
=========================
|
||||
|
||||
For general access to asymmetric keys from within the kernel, the following
|
||||
inclusion is required:
|
||||
|
||||
#include <crypto/public_key.h>
|
||||
|
||||
This gives access to functions for dealing with asymmetric / public keys.
|
||||
Three enums are defined there for representing public-key cryptography
|
||||
algorithms:
|
||||
|
||||
enum pkey_algo
|
||||
|
||||
digest algorithms used by those:
|
||||
|
||||
enum pkey_hash_algo
|
||||
|
||||
and key identifier representations:
|
||||
|
||||
enum pkey_id_type
|
||||
|
||||
Note that the key type representation types are required because key
|
||||
identifiers from different standards aren't necessarily compatible. For
|
||||
instance, PGP generates key identifiers by hashing the key data plus some
|
||||
PGP-specific metadata, whereas X.509 has arbitrary certificate identifiers.
|
||||
|
||||
The operations defined upon a key are:
|
||||
|
||||
(1) Signature verification.
|
||||
|
||||
Other operations are possible (such as encryption) with the same key data
|
||||
required for verification, but not currently supported, and others
|
||||
(eg. decryption and signature generation) require extra key data.
|
||||
|
||||
|
||||
SIGNATURE VERIFICATION
|
||||
----------------------
|
||||
|
||||
An operation is provided to perform cryptographic signature verification, using
|
||||
an asymmetric key to provide or to provide access to the public key.
|
||||
|
||||
int verify_signature(const struct key *key,
|
||||
const struct public_key_signature *sig);
|
||||
|
||||
The caller must have already obtained the key from some source and can then use
|
||||
it to check the signature. The caller must have parsed the signature and
|
||||
transferred the relevant bits to the structure pointed to by sig.
|
||||
|
||||
struct public_key_signature {
|
||||
u8 *digest;
|
||||
u8 digest_size;
|
||||
enum pkey_hash_algo pkey_hash_algo : 8;
|
||||
u8 nr_mpi;
|
||||
union {
|
||||
MPI mpi[2];
|
||||
...
|
||||
};
|
||||
};
|
||||
|
||||
The algorithm used must be noted in sig->pkey_hash_algo, and all the MPIs that
|
||||
make up the actual signature must be stored in sig->mpi[] and the count of MPIs
|
||||
placed in sig->nr_mpi.
|
||||
|
||||
In addition, the data must have been digested by the caller and the resulting
|
||||
hash must be pointed to by sig->digest and the size of the hash be placed in
|
||||
sig->digest_size.
|
||||
|
||||
The function will return 0 upon success or -EKEYREJECTED if the signature
|
||||
doesn't match.
|
||||
|
||||
The function may also return -ENOTSUPP if an unsupported public-key algorithm
|
||||
or public-key/hash algorithm combination is specified or the key doesn't
|
||||
support the operation; -EBADMSG or -ERANGE if some of the parameters have weird
|
||||
data; or -ENOMEM if an allocation can't be performed. -EINVAL can be returned
|
||||
if the key argument is the wrong type or is incompletely set up.
|
||||
|
||||
|
||||
=======================
|
||||
ASYMMETRIC KEY SUBTYPES
|
||||
=======================
|
||||
|
||||
Asymmetric keys have a subtype that defines the set of operations that can be
|
||||
performed on that key and that determines what data is attached as the key
|
||||
payload. The payload format is entirely at the whim of the subtype.
|
||||
|
||||
The subtype is selected by the key data parser and the parser must initialise
|
||||
the data required for it. The asymmetric key retains a reference on the
|
||||
subtype module.
|
||||
|
||||
The subtype definition structure can be found in:
|
||||
|
||||
#include <keys/asymmetric-subtype.h>
|
||||
|
||||
and looks like the following:
|
||||
|
||||
struct asymmetric_key_subtype {
|
||||
struct module *owner;
|
||||
const char *name;
|
||||
|
||||
void (*describe)(const struct key *key, struct seq_file *m);
|
||||
void (*destroy)(void *payload);
|
||||
int (*verify_signature)(const struct key *key,
|
||||
const struct public_key_signature *sig);
|
||||
};
|
||||
|
||||
Asymmetric keys point to this with their type_data[0] member.
|
||||
|
||||
The owner and name fields should be set to the owning module and the name of
|
||||
the subtype. Currently, the name is only used for print statements.
|
||||
|
||||
There are a number of operations defined by the subtype:
|
||||
|
||||
(1) describe().
|
||||
|
||||
Mandatory. This allows the subtype to display something in /proc/keys
|
||||
against the key. For instance the name of the public key algorithm type
|
||||
could be displayed. The key type will display the tail of the key
|
||||
identity string after this.
|
||||
|
||||
(2) destroy().
|
||||
|
||||
Mandatory. This should free the memory associated with the key. The
|
||||
asymmetric key will look after freeing the fingerprint and releasing the
|
||||
reference on the subtype module.
|
||||
|
||||
(3) verify_signature().
|
||||
|
||||
Optional. These are the entry points for the key usage operations.
|
||||
Currently there is only the one defined. If not set, the caller will be
|
||||
given -ENOTSUPP. The subtype may do anything it likes to implement an
|
||||
operation, including offloading to hardware.
|
||||
|
||||
|
||||
==========================
|
||||
INSTANTIATION DATA PARSERS
|
||||
==========================
|
||||
|
||||
The asymmetric key type doesn't generally want to store or to deal with a raw
|
||||
blob of data that holds the key data. It would have to parse it and error
|
||||
check it each time it wanted to use it. Further, the contents of the blob may
|
||||
have various checks that can be performed on it (eg. self-signatures, validity
|
||||
dates) and may contain useful data about the key (identifiers, capabilities).
|
||||
|
||||
Also, the blob may represent a pointer to some hardware containing the key
|
||||
rather than the key itself.
|
||||
|
||||
Examples of blob formats for which parsers could be implemented include:
|
||||
|
||||
- OpenPGP packet stream [RFC 4880].
|
||||
- X.509 ASN.1 stream.
|
||||
- Pointer to TPM key.
|
||||
- Pointer to UEFI key.
|
||||
|
||||
During key instantiation each parser in the list is tried until one doesn't
|
||||
return -EBADMSG.
|
||||
|
||||
The parser definition structure can be found in:
|
||||
|
||||
#include <keys/asymmetric-parser.h>
|
||||
|
||||
and looks like the following:
|
||||
|
||||
struct asymmetric_key_parser {
|
||||
struct module *owner;
|
||||
const char *name;
|
||||
|
||||
int (*parse)(struct key_preparsed_payload *prep);
|
||||
};
|
||||
|
||||
The owner and name fields should be set to the owning module and the name of
|
||||
the parser.
|
||||
|
||||
There is currently only a single operation defined by the parser, and it is
|
||||
mandatory:
|
||||
|
||||
(1) parse().
|
||||
|
||||
This is called to preparse the key from the key creation and update paths.
|
||||
In particular, it is called during the key creation _before_ a key is
|
||||
allocated, and as such, is permitted to provide the key's description in
|
||||
the case that the caller declines to do so.
|
||||
|
||||
The caller passes a pointer to the following struct with all of the fields
|
||||
cleared, except for data, datalen and quotalen [see
|
||||
Documentation/security/keys.txt].
|
||||
|
||||
struct key_preparsed_payload {
|
||||
char *description;
|
||||
void *type_data[2];
|
||||
void *payload;
|
||||
const void *data;
|
||||
size_t datalen;
|
||||
size_t quotalen;
|
||||
};
|
||||
|
||||
The instantiation data is in a blob pointed to by data and is datalen in
|
||||
size. The parse() function is not permitted to change these two values at
|
||||
all, and shouldn't change any of the other values _unless_ they are
|
||||
recognise the blob format and will not return -EBADMSG to indicate it is
|
||||
not theirs.
|
||||
|
||||
If the parser is happy with the blob, it should propose a description for
|
||||
the key and attach it to ->description, ->type_data[0] should be set to
|
||||
point to the subtype to be used, ->payload should be set to point to the
|
||||
initialised data for that subtype, ->type_data[1] should point to a hex
|
||||
fingerprint and quotalen should be updated to indicate how much quota this
|
||||
key should account for.
|
||||
|
||||
When clearing up, the data attached to ->type_data[1] and ->description
|
||||
will be kfree()'d and the data attached to ->payload will be passed to the
|
||||
subtype's ->destroy() method to be disposed of. A module reference for
|
||||
the subtype pointed to by ->type_data[0] will be put.
|
||||
|
||||
|
||||
If the data format is not recognised, -EBADMSG should be returned. If it
|
||||
is recognised, but the key cannot for some reason be set up, some other
|
||||
negative error code should be returned. On success, 0 should be returned.
|
||||
|
||||
The key's fingerprint string may be partially matched upon. For a
|
||||
public-key algorithm such as RSA and DSA this will likely be a printable
|
||||
hex version of the key's fingerprint.
|
||||
|
||||
Functions are provided to register and unregister parsers:
|
||||
|
||||
int register_asymmetric_key_parser(struct asymmetric_key_parser *parser);
|
||||
void unregister_asymmetric_key_parser(struct asymmetric_key_parser *subtype);
|
||||
|
||||
Parsers may not have the same name. The names are otherwise only used for
|
||||
displaying in debugging messages.
|
@ -132,3 +132,12 @@ Here we can see the RAID type is raid4, there are 5 devices - all of
|
||||
which are 'A'live, and the array is 2/490221568 complete with recovery.
|
||||
Faulty or missing devices are marked 'D'. Devices that are out-of-sync
|
||||
are marked 'a'.
|
||||
|
||||
|
||||
Version History
|
||||
---------------
|
||||
1.0.0 Initial version. Support for RAID 4/5/6
|
||||
1.1.0 Added support for RAID 1
|
||||
1.2.0 Handle creation of arrays that contain failed devices.
|
||||
1.3.0 Added support for RAID 10
|
||||
1.3.1 Allow device replacement/rebuild for RAID 10
|
||||
|
@ -1,3 +1,15 @@
|
||||
ARM Integrator/AP (Application Platform) and Integrator/CP (Compact Platform)
|
||||
-----------------------------------------------------------------------------
|
||||
ARM's oldest Linux-supported platform with connectors for different core
|
||||
tiles of ARMv4, ARMv5 and ARMv6 type.
|
||||
|
||||
Required properties (in root node):
|
||||
compatible = "arm,integrator-ap"; /* Application Platform */
|
||||
compatible = "arm,integrator-cp"; /* Compact Platform */
|
||||
|
||||
FPGA type interrupt controllers, see the versatile-fpga-irq binding doc.
|
||||
|
||||
|
||||
ARM Versatile Application and Platform Baseboards
|
||||
-------------------------------------------------
|
||||
ARM's development hardware platform with connectors for customizable
|
||||
|
@ -8,7 +8,7 @@ PIT Timer required properties:
|
||||
shared across all System Controller members.
|
||||
|
||||
TC/TCLIB Timer required properties:
|
||||
- compatible: Should be "atmel,<chip>-pit".
|
||||
- compatible: Should be "atmel,<chip>-tcb".
|
||||
<chip> can be "at91rm9200" or "at91sam9x5"
|
||||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain all interrupts for the TC block
|
||||
|
51
Documentation/devicetree/bindings/arm/davinci/nand.txt
Normal file
51
Documentation/devicetree/bindings/arm/davinci/nand.txt
Normal file
@ -0,0 +1,51 @@
|
||||
* Texas Instruments Davinci NAND
|
||||
|
||||
This file provides information, what the device node for the
|
||||
davinci nand interface contain.
|
||||
|
||||
Required properties:
|
||||
- compatible: "ti,davinci-nand";
|
||||
- reg : contain 2 offset/length values:
|
||||
- offset and length for the access window
|
||||
- offset and length for accessing the aemif control registers
|
||||
- ti,davinci-chipselect: Indicates on the davinci_nand driver which
|
||||
chipselect is used for accessing the nand.
|
||||
|
||||
Recommended properties :
|
||||
- ti,davinci-mask-ale: mask for ale
|
||||
- ti,davinci-mask-cle: mask for cle
|
||||
- ti,davinci-mask-chipsel: mask for chipselect
|
||||
- ti,davinci-ecc-mode: ECC mode valid values for davinci driver:
|
||||
- "none"
|
||||
- "soft"
|
||||
- "hw"
|
||||
- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
|
||||
- ti,davinci-nand-buswidth: buswidth 8 or 16
|
||||
- ti,davinci-nand-use-bbt: use flash based bad block table support.
|
||||
|
||||
Example (enbw_cmc board):
|
||||
aemif@60000000 {
|
||||
compatible = "ti,davinci-aemif";
|
||||
#address-cells = <2>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x68000000 0x80000>;
|
||||
ranges = <2 0 0x60000000 0x02000000
|
||||
3 0 0x62000000 0x02000000
|
||||
4 0 0x64000000 0x02000000
|
||||
5 0 0x66000000 0x02000000
|
||||
6 0 0x68000000 0x02000000>;
|
||||
nand@3,0 {
|
||||
compatible = "ti,davinci-nand";
|
||||
reg = <3 0x0 0x807ff
|
||||
6 0x0 0x8000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ti,davinci-chipselect = <1>;
|
||||
ti,davinci-mask-ale = <0>;
|
||||
ti,davinci-mask-cle = <0>;
|
||||
ti,davinci-mask-chipsel = <0>;
|
||||
ti,davinci-ecc-mode = "hw";
|
||||
ti,davinci-ecc-bits = <4>;
|
||||
ti,davinci-nand-use-bbt;
|
||||
};
|
||||
};
|
31
Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt
Normal file
31
Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt
Normal file
@ -0,0 +1,31 @@
|
||||
* ARM Versatile FPGA interrupt controller
|
||||
|
||||
One or more FPGA IRQ controllers can be synthesized in an ARM reference board
|
||||
such as the Integrator or Versatile family. The output of these different
|
||||
controllers are OR:ed together and fed to the CPU tile's IRQ input. Each
|
||||
instance can handle up to 32 interrupts.
|
||||
|
||||
Required properties:
|
||||
- compatible: "arm,versatile-fpga-irq"
|
||||
- interrupt-controller: Identifies the node as an interrupt controller
|
||||
- #interrupt-cells: The number of cells to define the interrupts. Must be 1
|
||||
as the FPGA IRQ controller has no configuration options for interrupt
|
||||
sources. The cell is a u32 and defines the interrupt number.
|
||||
- reg: The register bank for the FPGA interrupt controller.
|
||||
- clear-mask: a u32 number representing the mask written to clear all IRQs
|
||||
on the controller at boot for example.
|
||||
- valid-mask: a u32 number representing a bit mask determining which of
|
||||
the interrupts are valid. Unconnected/unused lines are set to 0, and
|
||||
the system till not make it possible for devices to request these
|
||||
interrupts.
|
||||
|
||||
Example:
|
||||
|
||||
pic: pic@14000000 {
|
||||
compatible = "arm,versatile-fpga-irq";
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-controller;
|
||||
reg = <0x14000000 0x100>;
|
||||
clear-mask = <0xffffffff>;
|
||||
valid-mask = <0x003fffff>;
|
||||
};
|
25
Documentation/devicetree/bindings/arm/xen.txt
Normal file
25
Documentation/devicetree/bindings/arm/xen.txt
Normal file
@ -0,0 +1,25 @@
|
||||
* Xen hypervisor device tree bindings
|
||||
|
||||
Xen ARM virtual platforms shall have a top-level "hypervisor" node with
|
||||
the following properties:
|
||||
|
||||
- compatible:
|
||||
compatible = "xen,xen-<version>", "xen,xen";
|
||||
where <version> is the version of the Xen ABI of the platform.
|
||||
|
||||
- reg: specifies the base physical address and size of a region in
|
||||
memory where the grant table should be mapped to, using an
|
||||
HYPERVISOR_memory_op hypercall. The memory region is large enough to map
|
||||
the whole grant table (it is larger or equal to gnttab_max_grant_frames()).
|
||||
|
||||
- interrupts: the interrupt used by Xen to inject event notifications.
|
||||
A GIC node is also required.
|
||||
|
||||
|
||||
Example (assuming #address-cells = <2> and #size-cells = <2>):
|
||||
|
||||
hypervisor {
|
||||
compatible = "xen,xen-4.3", "xen,xen";
|
||||
reg = <0 0xb0000000 0 0x20000>;
|
||||
interrupts = <1 15 0xf08>;
|
||||
};
|
@ -9,6 +9,7 @@ Copyright (C) 2008-2011 Freescale Semiconductor Inc.
|
||||
-Run Time Integrity Check (RTIC) Node
|
||||
-Run Time Integrity Check (RTIC) Memory Node
|
||||
-Secure Non-Volatile Storage (SNVS) Node
|
||||
-Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
|
||||
-Full Example
|
||||
|
||||
NOTE: the SEC 4 is also known as Freescale's Cryptographic Accelerator
|
||||
@ -294,6 +295,27 @@ Secure Non-Volatile Storage (SNVS) Node
|
||||
address and length of the SEC4 configuration
|
||||
registers.
|
||||
|
||||
- #address-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: A standard property. Defines the number of cells
|
||||
for representing physical addresses in child nodes. Must
|
||||
have a value of 1.
|
||||
|
||||
- #size-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: A standard property. Defines the number of cells
|
||||
for representing the size of physical addresses in
|
||||
child nodes. Must have a value of 1.
|
||||
|
||||
- ranges
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
range of the SNVS register space. A triplet that includes
|
||||
the child address, parent address, & length.
|
||||
|
||||
- interrupts
|
||||
Usage: required
|
||||
Value type: <prop_encoded-array>
|
||||
@ -314,10 +336,33 @@ EXAMPLE
|
||||
sec_mon@314000 {
|
||||
compatible = "fsl,sec-v4.0-mon";
|
||||
reg = <0x314000 0x1000>;
|
||||
ranges = <0 0x314000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <93 2>;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
|
||||
|
||||
A SNVS child node that defines SNVS LP RTC.
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0-mon-rtc-lp".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical
|
||||
address and length of the SNVS LP configuration registers.
|
||||
|
||||
EXAMPLE
|
||||
sec_mon_rtc_lp@314000 {
|
||||
compatible = "fsl,sec-v4.0-mon-rtc-lp";
|
||||
reg = <0x34 0x58>;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
FULL EXAMPLE
|
||||
|
||||
@ -390,8 +435,14 @@ FULL EXAMPLE
|
||||
sec_mon: sec_mon@314000 {
|
||||
compatible = "fsl,sec-v4.0-mon";
|
||||
reg = <0x314000 0x1000>;
|
||||
ranges = <0 0x314000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <93 2>;
|
||||
|
||||
sec_mon_rtc_lp@34 {
|
||||
compatible = "fsl,sec-v4.0-mon-rtc-lp";
|
||||
reg = <0x34 0x58>;
|
||||
};
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
|
20
Documentation/devicetree/bindings/crypto/mv_cesa.txt
Normal file
20
Documentation/devicetree/bindings/crypto/mv_cesa.txt
Normal file
@ -0,0 +1,20 @@
|
||||
Marvell Cryptographic Engines And Security Accelerator
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "marvell,orion-crypto"
|
||||
- reg : base physical address of the engine and length of memory mapped
|
||||
region, followed by base physical address of sram and its memory
|
||||
length
|
||||
- reg-names : "regs" , "sram";
|
||||
- interrupts : interrupt number
|
||||
|
||||
Examples:
|
||||
|
||||
crypto@30000 {
|
||||
compatible = "marvell,orion-crypto";
|
||||
reg = <0x30000 0x10000>,
|
||||
<0x4000000 0x800>;
|
||||
reg-names = "regs" , "sram";
|
||||
interrupts = <22>;
|
||||
status = "okay";
|
||||
};
|
25
Documentation/devicetree/bindings/gpio/gpio-fan.txt
Normal file
25
Documentation/devicetree/bindings/gpio/gpio-fan.txt
Normal file
@ -0,0 +1,25 @@
|
||||
Bindings for fan connected to GPIO lines
|
||||
|
||||
Required properties:
|
||||
- compatible : "gpio-fan"
|
||||
- gpios: Specifies the pins that map to bits in the control value,
|
||||
ordered MSB-->LSB.
|
||||
- gpio-fan,speed-map: A mapping of possible fan RPM speeds and the
|
||||
control value that should be set to achieve them. This array
|
||||
must have the RPM values in ascending order.
|
||||
|
||||
Optional properties:
|
||||
- alarm-gpios: This pin going active indicates something is wrong with
|
||||
the fan, and a udev event will be fired.
|
||||
|
||||
Examples:
|
||||
|
||||
gpio_fan {
|
||||
compatible = "gpio-fan";
|
||||
gpios = <&gpio1 14 1
|
||||
&gpio1 13 1>;
|
||||
gpio-fan,speed-map = <0 0
|
||||
3000 1
|
||||
6000 2>;
|
||||
alarm-gpios = <&gpio1 15 1>;
|
||||
};
|
53
Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
Normal file
53
Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
Normal file
@ -0,0 +1,53 @@
|
||||
* Marvell EBU GPIO controller
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio"
|
||||
or "marvell,armadaxp-gpio". "marvell,orion-gpio" should be used for
|
||||
Orion, Kirkwood, Dove, Discovery (except MV78200) and Armada
|
||||
370. "marvell,mv78200-gpio" should be used for the Discovery
|
||||
MV78200. "marvel,armadaxp-gpio" should be used for all Armada XP
|
||||
SoCs (MV78230, MV78260, MV78460).
|
||||
|
||||
- reg: Address and length of the register set for the device. Only one
|
||||
entry is expected, except for the "marvell,armadaxp-gpio" variant
|
||||
for which two entries are expected: one for the general registers,
|
||||
one for the per-cpu registers.
|
||||
|
||||
- interrupts: The list of interrupts that are used for all the pins
|
||||
managed by this GPIO bank. There can be more than one interrupt
|
||||
(example: 1 interrupt per 8 pins on Armada XP, which means 4
|
||||
interrupts per bank of 32 GPIOs).
|
||||
|
||||
- interrupt-controller: identifies the node as an interrupt controller
|
||||
|
||||
- #interrupt-cells: specifies the number of cells needed to encode an
|
||||
interrupt source. Should be two.
|
||||
The first cell is the GPIO number.
|
||||
The second cell is used to specify flags:
|
||||
bits[3:0] trigger type and level flags:
|
||||
1 = low-to-high edge triggered.
|
||||
2 = high-to-low edge triggered.
|
||||
4 = active high level-sensitive.
|
||||
8 = active low level-sensitive.
|
||||
|
||||
- gpio-controller: marks the device node as a gpio controller
|
||||
|
||||
- ngpios: number of GPIOs this controller has
|
||||
|
||||
- #gpio-cells: Should be two. The first cell is the pin number. The
|
||||
second cell is reserved for flags, unused at the moment.
|
||||
|
||||
Example:
|
||||
|
||||
gpio0: gpio@d0018100 {
|
||||
compatible = "marvell,armadaxp-gpio";
|
||||
reg = <0xd0018100 0x40>,
|
||||
<0xd0018800 0x30>;
|
||||
ngpios = <32>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupts = <16>, <17>, <18>, <19>;
|
||||
};
|
30
Documentation/devicetree/bindings/i2c/atmel-i2c.txt
Normal file
30
Documentation/devicetree/bindings/i2c/atmel-i2c.txt
Normal file
@ -0,0 +1,30 @@
|
||||
I2C for Atmel platforms
|
||||
|
||||
Required properties :
|
||||
- compatible : Must be "atmel,at91rm9200-i2c", "atmel,at91sam9261-i2c",
|
||||
"atmel,at91sam9260-i2c", "atmel,at91sam9g20-i2c", "atmel,at91sam9g10-i2c"
|
||||
or "atmel,at91sam9x5-i2c"
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- interrupts: interrupt number to the cpu.
|
||||
- #address-cells = <1>;
|
||||
- #size-cells = <0>;
|
||||
|
||||
Optional properties:
|
||||
- Child nodes conforming to i2c bus binding
|
||||
|
||||
Examples :
|
||||
|
||||
i2c0: i2c@fff84000 {
|
||||
compatible = "atmel,at91sam9g20-i2c";
|
||||
reg = <0xfff84000 0x100>;
|
||||
interrupts = <12 4 6>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
24c512@50 {
|
||||
compatible = "24c512";
|
||||
reg = <0x50>;
|
||||
pagesize = <128>;
|
||||
}
|
||||
}
|
28
Documentation/devicetree/bindings/i2c/davinci.txt
Normal file
28
Documentation/devicetree/bindings/i2c/davinci.txt
Normal file
@ -0,0 +1,28 @@
|
||||
* Texas Instruments Davinci I2C
|
||||
|
||||
This file provides information, what the device node for the
|
||||
davinci i2c interface contain.
|
||||
|
||||
Required properties:
|
||||
- compatible: "ti,davinci-i2c";
|
||||
- reg : Offset and length of the register set for the device
|
||||
|
||||
Recommended properties :
|
||||
- interrupts : standard interrupt property.
|
||||
- clock-frequency : desired I2C bus clock frequency in Hz.
|
||||
|
||||
Example (enbw_cmc board):
|
||||
i2c@1c22000 {
|
||||
compatible = "ti,davinci-i2c";
|
||||
reg = <0x22000 0x1000>;
|
||||
clock-frequency = <100000>;
|
||||
interrupts = <15>;
|
||||
interrupt-parent = <&intc>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
dtt@48 {
|
||||
compatible = "national,lm75";
|
||||
reg = <0x48>;
|
||||
};
|
||||
};
|
@ -6,6 +6,7 @@ Required properties:
|
||||
- interrupts: Should contain ERROR and DMA interrupts
|
||||
- clock-frequency: Desired I2C bus clock frequency in Hz.
|
||||
Only 100000Hz and 400000Hz modes are supported.
|
||||
- fsl,i2c-dma-channel: APBX DMA channel for the I2C
|
||||
|
||||
Examples:
|
||||
|
||||
@ -16,4 +17,5 @@ i2c0: i2c@80058000 {
|
||||
reg = <0x80058000 2000>;
|
||||
interrupts = <111 68>;
|
||||
clock-frequency = <100000>;
|
||||
fsl,i2c-dma-channel = <6>;
|
||||
};
|
||||
|
23
Documentation/devicetree/bindings/i2c/nomadik.txt
Normal file
23
Documentation/devicetree/bindings/i2c/nomadik.txt
Normal file
@ -0,0 +1,23 @@
|
||||
I2C for Nomadik based systems
|
||||
|
||||
Required (non-standard) properties:
|
||||
- Nil
|
||||
|
||||
Recommended (non-standard) properties:
|
||||
- clock-frequency : Maximum bus clock frequency for the device
|
||||
|
||||
Optional (non-standard) properties:
|
||||
- Nil
|
||||
|
||||
Example :
|
||||
|
||||
i2c@80004000 {
|
||||
compatible = "stericsson,db8500-i2c", "st,nomadik-i2c";
|
||||
reg = <0x80004000 0x1000>;
|
||||
interrupts = <0 21 0x4>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
v-i2c-supply = <&db8500_vape_reg>;
|
||||
|
||||
clock-frequency = <400000>;
|
||||
};
|
@ -7,7 +7,7 @@ as "armctrl" in the SoC documentation, hence naming of this binding.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "brcm,bcm2835-armctrl-ic.txt"
|
||||
- compatible : should be "brcm,bcm2835-armctrl-ic"
|
||||
- reg : Specifies base physical address and size of the registers.
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
|
85
Documentation/devicetree/bindings/mfd/88pm860x.txt
Normal file
85
Documentation/devicetree/bindings/mfd/88pm860x.txt
Normal file
@ -0,0 +1,85 @@
|
||||
* Marvell 88PM860x Power Management IC
|
||||
|
||||
Required parent device properties:
|
||||
- compatible : "marvell,88pm860x"
|
||||
- reg : the I2C slave address for the 88pm860x chip
|
||||
- interrupts : IRQ line for the 88pm860x chip
|
||||
- interrupt-controller: describes the 88pm860x as an interrupt controller (has its own domain)
|
||||
- #interrupt-cells : should be 1.
|
||||
- The cell is the 88pm860x local IRQ number
|
||||
|
||||
Optional parent device properties:
|
||||
- marvell,88pm860x-irq-read-clr: inicates whether interrupt status is cleared by read
|
||||
- marvell,88pm860x-slave-addr: 88pm860x are two chips solution. <reg> stores the I2C address
|
||||
of one chip, and this property stores the I2C address of
|
||||
another chip.
|
||||
|
||||
88pm860x consists of a large and varied group of sub-devices:
|
||||
|
||||
Device Supply Names Description
|
||||
------ ------------ -----------
|
||||
88pm860x-onkey : : On key
|
||||
88pm860x-rtc : : RTC
|
||||
88pm8607 : : Regulators
|
||||
88pm860x-backlight : : Backlight
|
||||
88pm860x-led : : Led
|
||||
88pm860x-touch : : Touchscreen
|
||||
|
||||
Example:
|
||||
|
||||
pmic: 88pm860x@34 {
|
||||
compatible = "marvell,88pm860x";
|
||||
reg = <0x34>;
|
||||
interrupts = <4>;
|
||||
interrupt-parent = <&intc>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
marvell,88pm860x-irq-read-clr;
|
||||
marvell,88pm860x-slave-addr = <0x11>;
|
||||
|
||||
regulators {
|
||||
BUCK1 {
|
||||
regulator-min-microvolt = <1000000>;
|
||||
regulator-max-microvolt = <1500000>;
|
||||
regulator-boot-on;
|
||||
regulator-always-on;
|
||||
};
|
||||
LDO1 {
|
||||
regulator-min-microvolt = <1200000>;
|
||||
regulator-max-microvolt = <2800000>;
|
||||
regulator-boot-on;
|
||||
regulator-always-on;
|
||||
};
|
||||
};
|
||||
rtc {
|
||||
marvell,88pm860x-vrtc = <1>;
|
||||
};
|
||||
touch {
|
||||
marvell,88pm860x-gpadc-prebias = <1>;
|
||||
marvell,88pm860x-gpadc-slot-cycle = <1>;
|
||||
marvell,88pm860x-tsi-prebias = <6>;
|
||||
marvell,88pm860x-pen-prebias = <16>;
|
||||
marvell,88pm860x-pen-prechg = <2>;
|
||||
marvell,88pm860x-resistor-X = <300>;
|
||||
};
|
||||
backlights {
|
||||
backlight-0 {
|
||||
marvell,88pm860x-iset = <4>;
|
||||
marvell,88pm860x-pwm = <3>;
|
||||
};
|
||||
backlight-2 {
|
||||
};
|
||||
};
|
||||
leds {
|
||||
led0-red {
|
||||
marvell,88pm860x-iset = <12>;
|
||||
};
|
||||
led0-green {
|
||||
marvell,88pm860x-iset = <12>;
|
||||
};
|
||||
led0-blue {
|
||||
marvell,88pm860x-iset = <12>;
|
||||
};
|
||||
};
|
||||
};
|
20
Documentation/devicetree/bindings/mfd/syscon.txt
Normal file
20
Documentation/devicetree/bindings/mfd/syscon.txt
Normal file
@ -0,0 +1,20 @@
|
||||
* System Controller Registers R/W driver
|
||||
|
||||
System controller node represents a register region containing a set
|
||||
of miscellaneous registers. The registers are not cohesive enough to
|
||||
represent as any specific type of device. The typical use-case is for
|
||||
some other node's driver, or platform-specific code, to acquire a
|
||||
reference to the syscon node (e.g. by phandle, node path, or search
|
||||
using a specific compatible value), interrogate the node (or associated
|
||||
OS driver) to determine the location of the registers, and access the
|
||||
registers directly.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should contain "syscon".
|
||||
- reg: the register region can be accessed from syscon
|
||||
|
||||
Examples:
|
||||
gpr: iomuxc-gpr@020e0000 {
|
||||
compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
|
||||
reg = <0x020e0000 0x38>;
|
||||
};
|
@ -59,6 +59,8 @@ Optional properties:
|
||||
in TPS6591X datasheet)
|
||||
- ti,en-gpio-sleep: enable sleep control for gpios
|
||||
There should be 9 entries here, one for each gpio.
|
||||
- ti,system-power-controller: Telling whether or not this pmic is controlling
|
||||
the system power.
|
||||
|
||||
Regulator Optional properties:
|
||||
- ti,regulator-ext-sleep-control: enable external sleep
|
||||
@ -79,6 +81,8 @@ Example:
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
|
||||
ti,system-power-controller;
|
||||
|
||||
ti,vmbch-threshold = 0;
|
||||
ti,vmbch2-threshold = 0;
|
||||
ti,en-ck32k-xtal;
|
||||
|
46
Documentation/devicetree/bindings/mfd/twl4030-audio.txt
Normal file
46
Documentation/devicetree/bindings/mfd/twl4030-audio.txt
Normal file
@ -0,0 +1,46 @@
|
||||
Texas Instruments TWL family (twl4030) audio module
|
||||
|
||||
The audio module inside the TWL family consist of an audio codec and a vibra
|
||||
driver.
|
||||
|
||||
Required properties:
|
||||
- compatible : must be "ti,twl4030-audio"
|
||||
|
||||
Optional properties, nodes:
|
||||
|
||||
Audio functionality:
|
||||
- codec { }: Need to be present if the audio functionality is used. Within this
|
||||
section the following options can be used:
|
||||
- ti,digimic_delay: Delay need after enabling the digimic to reduce artifacts
|
||||
from the start of the recorded sample (in ms)
|
||||
-ti,ramp_delay_value: HS ramp delay configuration to reduce pop noise
|
||||
-ti,hs_extmute: Use external mute for HS pop reduction
|
||||
-ti,hs_extmute_gpio: Use external GPIO to control the external mute
|
||||
-ti,offset_cncl_path: Offset cancellation path selection, refer to TRM for the
|
||||
valid values.
|
||||
|
||||
Vibra functionality
|
||||
- ti,enable-vibra: Need to be set to <1> if the vibra functionality is used. if
|
||||
missing or it is 0, the vibra functionality is disabled.
|
||||
|
||||
Example:
|
||||
&i2c1 {
|
||||
clock-frequency = <2600000>;
|
||||
|
||||
twl: twl@48 {
|
||||
reg = <0x48>;
|
||||
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
|
||||
interrupt-parent = <&intc>;
|
||||
|
||||
twl_audio: audio {
|
||||
compatible = "ti,twl4030-audio";
|
||||
|
||||
ti,enable-vibra = <1>;
|
||||
|
||||
codec {
|
||||
ti,ramp_delay_value = <3>;
|
||||
};
|
||||
|
||||
};
|
||||
};
|
||||
};
|
@ -1,7 +1,7 @@
|
||||
Texas Instruments TWL6040 family
|
||||
|
||||
The TWL6040s are 8-channel high quality low-power audio codecs providing audio
|
||||
and vibra functionality on OMAP4+ platforms.
|
||||
The TWL6040s are 8-channel high quality low-power audio codecs providing audio,
|
||||
vibra and GPO functionality on OMAP4+ platforms.
|
||||
They are connected ot the host processor via i2c for commands, McPDM for audio
|
||||
data and commands.
|
||||
|
||||
@ -10,6 +10,8 @@ Required properties:
|
||||
- reg: must be 0x4b for i2c address
|
||||
- interrupts: twl6040 has one interrupt line connecteded to the main SoC
|
||||
- interrupt-parent: The parent interrupt controller
|
||||
- gpio-controller:
|
||||
- #gpio-cells = <1>: twl6040 provides GPO lines.
|
||||
- twl6040,audpwron-gpio: Power on GPIO line for the twl6040
|
||||
|
||||
- vio-supply: Regulator for the twl6040 VIO supply
|
||||
@ -37,7 +39,6 @@ Example:
|
||||
&i2c1 {
|
||||
twl6040: twl@4b {
|
||||
compatible = "ti,twl6040";
|
||||
reg = <0x4b>;
|
||||
|
||||
interrupts = <0 119 4>;
|
||||
interrupt-parent = <&gic>;
|
||||
@ -60,3 +61,5 @@ Example:
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
/include/ "twl6040.dtsi"
|
||||
|
41
Documentation/devicetree/bindings/misc/ifm-csi.txt
Normal file
41
Documentation/devicetree/bindings/misc/ifm-csi.txt
Normal file
@ -0,0 +1,41 @@
|
||||
IFM camera sensor interface on mpc5200 LocalPlus bus
|
||||
|
||||
Required properties:
|
||||
- compatible: "ifm,o2d-csi"
|
||||
- reg: specifies sensor chip select number and associated address range
|
||||
- interrupts: external interrupt line number and interrupt sense mode
|
||||
of the interrupt line signaling frame valid events
|
||||
- gpios: three gpio-specifiers for "capture", "reset" and "master enable"
|
||||
GPIOs (strictly in this order).
|
||||
- ifm,csi-clk-handle: the phandle to a node in the DT describing the sensor
|
||||
clock generator. This node is usually a general purpose timer controller.
|
||||
- ifm,csi-addr-bus-width: address bus width (valid values are 16, 24, 25)
|
||||
- ifm,csi-data-bus-width: data bus width (valid values are 8 and 16)
|
||||
- ifm,csi-wait-cycles: sensor bus wait cycles
|
||||
|
||||
Optional properties:
|
||||
- ifm,csi-byte-swap: if this property is present, the byte swapping on
|
||||
the bus will be enabled.
|
||||
|
||||
Example:
|
||||
|
||||
csi@3,0 {
|
||||
compatible = "ifm,o2d-csi";
|
||||
reg = <3 0 0x00100000>; /* CS 3, 1 MiB range */
|
||||
interrupts = <1 1 2>; /* IRQ1, edge falling */
|
||||
|
||||
ifm,csi-clk-handle = <&timer7>;
|
||||
gpios = <&gpio_simple 23 0 /* image_capture */
|
||||
&gpio_simple 26 0 /* image_reset */
|
||||
&gpio_simple 29 0>; /* image_master_en */
|
||||
|
||||
ifm,csi-addr-bus-width = <24>;
|
||||
ifm,csi-data-bus-width = <8>;
|
||||
ifm,csi-wait-cycles = <0>;
|
||||
};
|
||||
|
||||
The base address of the used chip select is specified in the
|
||||
ranges property of the parent localbus node, for example:
|
||||
|
||||
ranges = <0 0 0xff000000 0x01000000
|
||||
3 0 0xe3000000 0x00100000>;
|
68
Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
Normal file
68
Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
Normal file
@ -0,0 +1,68 @@
|
||||
* Atmel High Speed MultiMedia Card Interface
|
||||
|
||||
This controller on atmel products provides an interface for MMC, SD and SDIO
|
||||
types of memory cards.
|
||||
|
||||
This file documents differences between the core properties described
|
||||
by mmc.txt and the properties used by the atmel-mci driver.
|
||||
|
||||
1) MCI node
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "atmel,hsmci"
|
||||
- #address-cells: should be one. The cell is the slot id.
|
||||
- #size-cells: should be zero.
|
||||
- at least one slot node
|
||||
|
||||
The node contains child nodes for each slot that the platform uses
|
||||
|
||||
Example MCI node:
|
||||
|
||||
mmc0: mmc@f0008000 {
|
||||
compatible = "atmel,hsmci";
|
||||
reg = <0xf0008000 0x600>;
|
||||
interrupts = <12 4>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
[ child node definitions...]
|
||||
};
|
||||
|
||||
2) slot nodes
|
||||
|
||||
Required properties:
|
||||
- reg: should contain the slot id.
|
||||
- bus-width: number of data lines connected to the controller
|
||||
|
||||
Optional properties:
|
||||
- cd-gpios: specify GPIOs for card detection
|
||||
- cd-inverted: invert the value of external card detect gpio line
|
||||
- wp-gpios: specify GPIOs for write protection
|
||||
|
||||
Example slot node:
|
||||
|
||||
slot@0 {
|
||||
reg = <0>;
|
||||
bus-width = <4>;
|
||||
cd-gpios = <&pioD 15 0>
|
||||
cd-inverted;
|
||||
};
|
||||
|
||||
Example full MCI node:
|
||||
mmc0: mmc@f0008000 {
|
||||
compatible = "atmel,hsmci";
|
||||
reg = <0xf0008000 0x600>;
|
||||
interrupts = <12 4>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
slot@0 {
|
||||
reg = <0>;
|
||||
bus-width = <4>;
|
||||
cd-gpios = <&pioD 15 0>
|
||||
cd-inverted;
|
||||
};
|
||||
slot@1 {
|
||||
reg = <1>;
|
||||
bus-width = <4>;
|
||||
};
|
||||
};
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user