提交 740c699a 编写于 作者: I Ingo Molnar

Merge tag 'v3.15-rc1' into perf/urgent

Pick up the latest fixes.
Signed-off-by: NIngo Molnar <mingo@kernel.org>
无相关合并请求

要显示的变更太多。

To preserve performance only 1000 of 1000+ files are displayed.
......@@ -630,6 +630,13 @@ N: Michael Elizabeth Chastain
E: mec@shout.net
D: Configure, Menuconfig, xconfig
N: Mauro Carvalho Chehab
E: m.chehab@samsung.org
E: mchehab@infradead.org
D: Media subsystem (V4L/DVB) drivers and core
D: EDAC drivers and EDAC 3.0 core rework
S: Brazil
N: Raymond Chen
E: raymondc@microsoft.com
D: Author of Configure script
......@@ -1229,7 +1236,7 @@ E: philip@gladstonefamily.net
D: Kernel / timekeeping stuff
S: Carlisle, MA 01741
S: USA
N: Jan-Benedict Glaw
E: jbglaw@lug-owl.de
D: SRM environment driver (for Alpha systems)
......@@ -2560,10 +2567,14 @@ S: 22 Seaview St
S: Fullarton 5063
S: South Australia
N. Wolfgang Muees
N: Wolfgang Muees
E: wolfgang@iksw-muees.de
D: Auerswald USB driver
N: Paul Mundt
E: paul.mundt@gmail.com
D: SuperH maintainer
N: Ian A. Murdock
E: imurdock@gnu.ai.mit.edu
D: Creator of Debian distribution
......@@ -2707,6 +2718,9 @@ N: Greg Page
E: gpage@sovereign.org
D: IPX development and support
N: Venkatesh Pallipadi (Venki)
D: x86/HPET
N: David Parsons
E: orc@pell.chi.il.us
D: improved memory detection code.
......
......@@ -413,8 +413,6 @@ serial-console.txt
- how to set up Linux with a serial line console as the default.
sgi-ioc4.txt
- description of the SGI IOC4 PCI (multi function) device.
sgi-visws.txt
- short blurb on the SGI Visual Workstations.
sh/
- directory with info on porting Linux to a new architecture.
smsc_ece1099.txt
......
What: /sys/firmware/opal/dump
Date: Feb 2014
Contact: Stewart Smith <stewart@linux.vnet.ibm.com>
Description:
This directory exposes interfaces for interacting with
the FSP and platform dumps through OPAL firmware interface.
This is only for the powerpc/powernv platform.
initiate_dump: When '1' is written to it,
we will initiate a dump.
Read this file for supported commands.
0xXX-0xYYYY: A directory for dump of type 0xXX and
id 0xYYYY (in hex). The name of this
directory should not be relied upon to
be in this format, only that it's unique
among all dumps. For determining the type
and ID of the dump, use the id and type files.
Do not rely on any particular size of dump
type or dump id.
Each dump has the following files:
id: An ASCII representation of the dump ID
in hex (e.g. '0x01')
type: An ASCII representation of the type of
dump in the format "0x%x %s" with the ID
in hex and a description of the dump type
(or 'unknown').
Type '0xffffffff unknown' is used when
we could not get the type from firmware.
e.g. '0x02 System/Platform Dump'
dump: A binary file containing the dump.
The size of the dump is the size of this file.
acknowledge: When 'ack' is written to this, we will
acknowledge that we've retrieved the
dump to the service processor. It will
then remove it, making the dump
inaccessible.
Reading this file will get a list of
supported actions.
What: /sys/firmware/opal/elog
Date: Feb 2014
Contact: Stewart Smith <stewart@linux.vnet.ibm.com>
Description:
This directory exposes error log entries retrieved
through the OPAL firmware interface.
Each error log is identified by a unique ID and will
exist until explicitly acknowledged to firmware.
Each log entry has a directory in /sys/firmware/opal/elog.
Log entries may be purged by the service processor
before retrieved by firmware or retrieved/acknowledged by
Linux if there is no room for more log entries.
In the event that Linux has retrieved the log entries
but not explicitly acknowledged them to firmware and
the service processor needs more room for log entries,
the only remaining copy of a log message may be in
Linux.
Typically, a user space daemon will monitor for new
entries, read them out and acknowledge them.
The service processor may be able to store more log
entries than firmware can, so after you acknowledge
an event from Linux you may instantly get another one
from the queue that was generated some time in the past.
The raw log format is a binary format. We currently
do not parse this at all in kernel, leaving it up to
user space to solve the problem. In future, we may
do more parsing in kernel and add more files to make
it easier for simple user space processes to extract
more information.
For each log entry (directory), there are the following
files:
id: An ASCII representation of the ID of the
error log, in hex - e.g. "0x01".
type: An ASCII representation of the type id and
description of the type of error log.
Currently just "0x00 PEL" - platform error log.
In the future there may be additional types.
raw: A read-only binary file that can be read
to get the raw log entry. These are
<16kb, often just hundreds of bytes and
"average" 2kb.
acknowledge: Writing 'ack' to this file will acknowledge
the error log to firmware (and in turn
the service processor, if applicable).
Shortly after acknowledging it, the log
entry will be removed from sysfs.
Reading this file will list the supported
operations (curently just acknowledge).
\ No newline at end of file
......@@ -43,6 +43,36 @@ Description:
The invalid_io file is read-only and specifies the number of
non-page-size-aligned I/O requests issued to this device.
What: /sys/block/zram<id>/failed_reads
Date: February 2014
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The failed_reads file is read-only and specifies the number of
failed reads happened on this device.
What: /sys/block/zram<id>/failed_writes
Date: February 2014
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The failed_writes file is read-only and specifies the number of
failed writes happened on this device.
What: /sys/block/zram<id>/max_comp_streams
Date: February 2014
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The max_comp_streams file is read-write and specifies the
number of backend's zcomp_strm compression streams (number of
concurrent compress operations).
What: /sys/block/zram<id>/comp_algorithm
Date: February 2014
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The comp_algorithm file is read-write and lets to show
available and selected compression algorithms, change
compression algorithm selection.
What: /sys/block/zram<id>/notify_free
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
......@@ -53,15 +83,6 @@ Description:
is freed. This statistic is applicable only when this disk is
being used as a swap disk.
What: /sys/block/zram<id>/discard
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The discard file is read-only and specifies the number of
discard requests received by this device. These requests
provide information to block device regarding blocks which are
no longer used by filesystem.
What: /sys/block/zram<id>/zero_pages
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
......
What: /sys/bus/event_source/devices/hv_24x7/interface/catalog
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Description:
Provides access to the binary "24x7 catalog" provided by the
hypervisor on POWER7 and 8 systems. This catalog lists events
avaliable from the powerpc "hv_24x7" pmu. Its format is
documented here:
https://raw.githubusercontent.com/jmesmon/catalog-24x7/master/hv-24x7-catalog.h
What: /sys/bus/event_source/devices/hv_24x7/interface/catalog_length
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Description:
A number equal to the length in bytes of the catalog. This is
also extractable from the provided binary "catalog" sysfs entry.
What: /sys/bus/event_source/devices/hv_24x7/interface/catalog_version
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Description:
Exposes the "version" field of the 24x7 catalog. This is also
extractable from the provided binary "catalog" sysfs entry.
What: /sys/bus/event_source/devices/hv_gpci/interface/collect_privileged
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Description:
'0' if the hypervisor is configured to forbid access to event
counters being accumulated by other guests and to physical
domain event counters.
'1' if that access is allowed.
What: /sys/bus/event_source/devices/hv_gpci/interface/ga
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Description:
0 or 1. Indicates whether we have access to "GA" events (listed
in arch/powerpc/perf/hv-gpci.h).
What: /sys/bus/event_source/devices/hv_gpci/interface/expanded
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Description:
0 or 1. Indicates whether we have access to "EXPANDED" events (listed
in arch/powerpc/perf/hv-gpci.h).
What: /sys/bus/event_source/devices/hv_gpci/interface/lab
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Description:
0 or 1. Indicates whether we have access to "LAB" events (listed
in arch/powerpc/perf/hv-gpci.h).
What: /sys/bus/event_source/devices/hv_gpci/interface/version
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Description:
A number indicating the version of the gpci interface that the
hypervisor reports supporting.
What: /sys/bus/event_source/devices/hv_gpci/interface/kernel_version
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Description:
A number indicating the latest version of the gpci interface
that the kernel is aware of.
......@@ -7,3 +7,23 @@ Description:
by the device during bus enumeration, encoded in hexadecimal.
This ID is used to match the device with the appropriate
driver.
What: /sys/bus/mdio_bus/devices/.../phy_interface
Date: February 2014
KernelVersion: 3.15
Contact: netdev@vger.kernel.org
Description:
This attribute contains the PHY interface as configured by the
Ethernet driver during bus enumeration, encoded in string.
This interface mode is used to configure the Ethernet MAC with the
appropriate mode for its data lines to the PHY hardware.
What: /sys/bus/mdio_bus/devices/.../phy_has_fixups
Date: February 2014
KernelVersion: 3.15
Contact: netdev@vger.kernel.org
Description:
This attribute contains the boolean value whether a given PHY
device has had any "fixup" workaround running on it, encoded as
a boolean. This information is provided to help troubleshooting
PHY configurations.
What: /sys/class/net/<iface>/addr_assign_type
Date: July 2010
KernelVersion: 3.2
Contact: netdev@vger.kernel.org
Description:
Indicates the address assignment type. Possible values are:
0: permanent address
1: randomly generated
2: stolen from another device
3: set using dev_set_mac_address
What: /sys/class/net/<iface>/addr_len
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the hardware address size in bytes.
Values vary based on the lower-level protocol used by the
interface (Ethernet, FDDI, ATM, IEEE 802.15.4...). See
include/uapi/linux/if_*.h for actual values.
What: /sys/class/net/<iface>/address
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Hardware address currently assigned to this interface.
Format is a string, e.g: 00:11:22:33:44:55 for an Ethernet MAC
address.
What: /sys/class/net/<iface>/broadcast
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Hardware broadcast address for this interface. Format is a
string, e.g: ff:ff:ff:ff:ff:ff for an Ethernet broadcast MAC
address.
What: /sys/class/net/<iface>/carrier
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the current physical link state of the interface.
Posssible values are:
0: physical link is down
1: physical link is up
Note: some special devices, e.g: bonding and team drivers will
allow this attribute to be written to force a link state for
operating correctly and designating another fallback interface.
What: /sys/class/net/<iface>/dev_id
Date: April 2008
KernelVersion: 2.6.26
Contact: netdev@vger.kernel.org
Description:
Indicates the device unique identifier. Format is an hexadecimal
value. This is used to disambiguate interfaces which might be
stacked (e.g: VLAN interfaces) but still have the same MAC
address as their parent device.
What: /sys/class/net/<iface>/dormant
Date: March 2006
KernelVersion: 2.6.17
Contact: netdev@vger.kernel.org
Description:
Indicates whether the interface is in dormant state. Possible
values are:
0: interface is not dormant
1: interface is dormant
This attribute can be used by supplicant software to signal that
the device is not usable unless some supplicant-based
authentication is performed (e.g: 802.1x). 'link_mode' attribute
will also reflect the dormant state.
What: /sys/clas/net/<iface>/duplex
Date: October 2009
KernelVersion: 2.6.33
Contact: netdev@vger.kernel.org
Description:
Indicates the interface latest or current duplex value. Possible
values are:
half: half duplex
full: full duplex
Note: This attribute is only valid for interfaces that implement
the ethtool get_settings method (mostly Ethernet).
What: /sys/class/net/<iface>/flags
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the interface flags as a bitmask in hexadecimal. See
include/uapi/linux/if.h for a list of all possible values and
the flags semantics.
What: /sys/class/net/<iface>/ifalias
Date: September 2008
KernelVersion: 2.6.28
Contact: netdev@vger.kernel.org
Description:
Indicates/stores an interface alias name as a string. This can
be used for system management purposes.
What: /sys/class/net/<iface>/ifindex
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the system-wide interface unique index identifier as a
decimal number. This attribute is used for mapping an interface
identifier to an interface name. It is used throughout the
networking stack for specifying the interface specific
requests/events.
What: /sys/class/net/<iface>/iflink
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the system-wide interface unique index identifier a
the interface is linked to. Format is decimal. This attribute is
used to resolve interfaces chaining, linking and stacking.
Physical interfaces have the same 'ifindex' and 'iflink' values.
What: /sys/class/net/<iface>/link_mode
Date: March 2006
KernelVersion: 2.6.17
Contact: netdev@vger.kernel.org
Description:
Indicates the interface link mode, as a decimal number. This
attribute should be used in conjunction with 'dormant' attribute
to determine the interface usability. Possible values:
0: default link mode
1: dormant link mode
What: /sys/class/net/<iface>/mtu
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the interface currently configured MTU value, in
bytes, and in decimal format. Specific values depends on the
lower-level interface protocol used. Ethernet devices will show
a 'mtu' attribute value of 1500 unless changed.
What: /sys/calss/net/<iface>/netdev_group
Date: January 2011
KernelVersion: 2.6.39
Contact: netdev@vger.kernel.org
Description:
Indicates the interface network device group, as a decimal
integer. Default value is 0 which corresponds to the initial
network devices group. The group can be changed to affect
routing decisions (see: net/ipv4/fib_rules and
net/ipv6/fib6_rules.c).
What: /sys/class/net/<iface>/operstate
Date: March 2006
KernelVersion: 2.6.17
Contact: netdev@vger.kernel.org
Description:
Indicates the interface RFC2863 operational state as a string.
Possible values are:
"unknown", "notpresent", "down", "lowerlayerdown", "testing",
"dormant", "up".
What: /sys/class/net/<iface>/speed
Date: October 2009
KernelVersion: 2.6.33
Contact: netdev@vger.kernel.org
Description:
Indicates the interface latest or current speed value. Value is
an integer representing the link speed in Mbits/sec.
Note: this attribute is only valid for interfaces that implement
the ethtool get_settings method (mostly Ethernet ).
What: /sys/class/net/<iface>/tx_queue_len
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the interface transmit queue len in number of packets,
as an integer value. Value depend on the type of interface,
Ethernet network adapters have a default value of 1000 unless
configured otherwise
What: /sys/class/net/<iface>/type
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the interface protocol type as a decimal value. See
include/uapi/linux/if_arp.h for all possible values.
......@@ -76,6 +76,15 @@ Description:
is used to classify clients as "isolated" by the
Extended Isolation feature.
What: /sys/class/net/<mesh_iface>/mesh/multicast_mode
Date: Feb 2014
Contact: Linus Lüssing <linus.luessing@web.de>
Description:
Indicates whether multicast optimizations are enabled
or disabled. If set to zero then all nodes in the
mesh are going to use classic flooding for any
multicast packet with no optimizations.
What: /sys/class/net/<mesh_iface>/mesh/network_coding
Date: Nov 2012
Contact: Martin Hundeboll <martin@hundeboll.net>
......
What: /sys/class/rc/
Date: Apr 2010
KernelVersion: 2.6.35
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
The rc/ class sub-directory belongs to the Remote Controller
core and provides a sysfs interface for configuring infrared
remote controller receivers.
What: /sys/class/rc/rcN/
Date: Apr 2010
KernelVersion: 2.6.35
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
A /sys/class/rc/rcN directory is created for each remote
control receiver device where N is the number of the receiver.
What: /sys/class/rc/rcN/protocols
Date: Jun 2010
KernelVersion: 2.6.36
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Reading this file returns a list of available protocols,
something like:
"rc5 [rc6] nec jvc [sony]"
Enabled protocols are shown in [] brackets.
Writing "+proto" will add a protocol to the list of enabled
protocols.
Writing "-proto" will remove a protocol from the list of enabled
protocols.
Writing "proto" will enable only "proto".
Writing "none" will disable all protocols.
Write fails with EINVAL if an invalid protocol combination or
unknown protocol name is used.
What: /sys/class/rc/rcN/filter
Date: Jan 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Sets the scancode filter expected value.
Use in combination with /sys/class/rc/rcN/filter_mask to set the
expected value of the bits set in the filter mask.
If the hardware supports it then scancodes which do not match
the filter will be ignored. Otherwise the write will fail with
an error.
This value may be reset to 0 if the current protocol is altered.
What: /sys/class/rc/rcN/filter_mask
Date: Jan 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Sets the scancode filter mask of bits to compare.
Use in combination with /sys/class/rc/rcN/filter to set the bits
of the scancode which should be compared against the expected
value. A value of 0 disables the filter to allow all valid
scancodes to be processed.
If the hardware supports it then scancodes which do not match
the filter will be ignored. Otherwise the write will fail with
an error.
This value may be reset to 0 if the current protocol is altered.
What: /sys/class/rc/rcN/wakeup_protocols
Date: Feb 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Reading this file returns a list of available protocols to use
for the wakeup filter, something like:
"rc5 rc6 nec jvc [sony]"
The enabled wakeup protocol is shown in [] brackets.
Writing "+proto" will add a protocol to the list of enabled
wakeup protocols.
Writing "-proto" will remove a protocol from the list of enabled
wakeup protocols.
Writing "proto" will use "proto" for wakeup events.
Writing "none" will disable wakeup.
Write fails with EINVAL if an invalid protocol combination or
unknown protocol name is used, or if wakeup is not supported by
the hardware.
What: /sys/class/rc/rcN/wakeup_filter
Date: Jan 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Sets the scancode wakeup filter expected value.
Use in combination with /sys/class/rc/rcN/wakeup_filter_mask to
set the expected value of the bits set in the wakeup filter mask
to trigger a system wake event.
If the hardware supports it and wakeup_filter_mask is not 0 then
scancodes which match the filter will wake the system from e.g.
suspend to RAM or power off.
Otherwise the write will fail with an error.
This value may be reset to 0 if the wakeup protocol is altered.
What: /sys/class/rc/rcN/wakeup_filter_mask
Date: Jan 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Sets the scancode wakeup filter mask of bits to compare.
Use in combination with /sys/class/rc/rcN/wakeup_filter to set
the bits of the scancode which should be compared against the
expected value to trigger a system wake event.
If the hardware supports it and wakeup_filter_mask is not 0 then
scancodes which match the filter will wake the system from e.g.
suspend to RAM or power off.
Otherwise the write will fail with an error.
This value may be reset to 0 if the wakeup protocol is altered.
......@@ -11,3 +11,19 @@ Description:
guaranteed. The 'isci_id' attribute unambiguously identifies
the controller index: '0' for the first controller,
'1' for the second.
What: /sys/class/scsi_host/hostX/acciopath_status
Date: November 2013
Contact: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Description: This file contains the current status of the "SSD Smart Path"
feature of HP Smart Array RAID controllers using the hpsa
driver. SSD Smart Path, when enabled permits the driver to
send i/o requests directly to physical devices that are part
of a logical drive, bypassing the controllers firmware RAID
stack for a performance advantage when possible. A value of
'1' indicates the feature is enabled, and the controller may
use the direct i/o path to physical devices. A value of zero
means the feature is disabled and the controller may not use
the direct i/o path to physical devices. This setting is
controller wide, affecting all configured logical drives on the
controller. This file is readable and writable.
......@@ -83,8 +83,10 @@ Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../wakeup_count attribute contains the number
of signaled wakeup events associated with the device. This
attribute is read-only. If the device is not enabled to wake up
attribute is read-only. If the device is not capable to wake up
the system from sleep states, this attribute is not present.
If the device is not enabled to wake up the system from sleep
states, this attribute is empty.
What: /sys/devices/.../power/wakeup_active_count
Date: September 2010
......@@ -93,8 +95,10 @@ Description:
The /sys/devices/.../wakeup_active_count attribute contains the
number of times the processing of wakeup events associated with
the device was completed (at the kernel level). This attribute
is read-only. If the device is not enabled to wake up the
system from sleep states, this attribute is not present.
is read-only. If the device is not capable to wake up the
system from sleep states, this attribute is not present. If
the device is not enabled to wake up the system from sleep
states, this attribute is empty.
What: /sys/devices/.../power/wakeup_abort_count
Date: February 2012
......@@ -104,8 +108,9 @@ Description:
number of times the processing of a wakeup event associated with
the device might have aborted system transition into a sleep
state in progress. This attribute is read-only. If the device
is not enabled to wake up the system from sleep states, this
attribute is not present.
is not capable to wake up the system from sleep states, this
attribute is not present. If the device is not enabled to wake
up the system from sleep states, this attribute is empty.
What: /sys/devices/.../power/wakeup_expire_count
Date: February 2012
......@@ -114,8 +119,10 @@ Description:
The /sys/devices/.../wakeup_expire_count attribute contains the
number of times a wakeup event associated with the device has
been reported with a timeout that expired. This attribute is
read-only. If the device is not enabled to wake up the system
from sleep states, this attribute is not present.
read-only. If the device is not capable to wake up the system
from sleep states, this attribute is not present. If the
device is not enabled to wake up the system from sleep states,
this attribute is empty.
What: /sys/devices/.../power/wakeup_active
Date: September 2010
......@@ -124,8 +131,10 @@ Description:
The /sys/devices/.../wakeup_active attribute contains either 1,
or 0, depending on whether or not a wakeup event associated with
the device is being processed (1). This attribute is read-only.
If the device is not enabled to wake up the system from sleep
states, this attribute is not present.
If the device is not capable to wake up the system from sleep
states, this attribute is not present. If the device is not
enabled to wake up the system from sleep states, this attribute
is empty.
What: /sys/devices/.../power/wakeup_total_time_ms
Date: September 2010
......@@ -134,8 +143,9 @@ Description:
The /sys/devices/.../wakeup_total_time_ms attribute contains
the total time of processing wakeup events associated with the
device, in milliseconds. This attribute is read-only. If the
device is not enabled to wake up the system from sleep states,
this attribute is not present.
device is not capable to wake up the system from sleep states,
this attribute is not present. If the device is not enabled to
wake up the system from sleep states, this attribute is empty.
What: /sys/devices/.../power/wakeup_max_time_ms
Date: September 2010
......@@ -144,8 +154,10 @@ Description:
The /sys/devices/.../wakeup_max_time_ms attribute contains
the maximum time of processing a single wakeup event associated
with the device, in milliseconds. This attribute is read-only.
If the device is not enabled to wake up the system from sleep
states, this attribute is not present.
If the device is not capable to wake up the system from sleep
states, this attribute is not present. If the device is not
enabled to wake up the system from sleep states, this attribute
is empty.
What: /sys/devices/.../power/wakeup_last_time_ms
Date: September 2010
......@@ -156,7 +168,8 @@ Description:
signaling the last wakeup event associated with the device, in
milliseconds. This attribute is read-only. If the device is
not enabled to wake up the system from sleep states, this
attribute is not present.
attribute is not present. If the device is not enabled to wake
up the system from sleep states, this attribute is empty.
What: /sys/devices/.../power/wakeup_prevent_sleep_time_ms
Date: February 2012
......@@ -165,9 +178,10 @@ Description:
The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute
contains the total time the device has been preventing
opportunistic transitions to sleep states from occurring.
This attribute is read-only. If the device is not enabled to
This attribute is read-only. If the device is not capable to
wake up the system from sleep states, this attribute is not
present.
present. If the device is not enabled to wake up the system
from sleep states, this attribute is empty.
What: /sys/devices/.../power/autosuspend_delay_ms
Date: September 2010
......@@ -187,7 +201,7 @@ Description:
Not all drivers support this attribute. If it isn't supported,
attempts to read or write it will yield I/O errors.
What: /sys/devices/.../power/pm_qos_latency_us
What: /sys/devices/.../power/pm_qos_resume_latency_us
Date: March 2012
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
......@@ -205,6 +219,31 @@ Description:
This attribute has no effect on system-wide suspend/resume and
hibernation.
What: /sys/devices/.../power/pm_qos_latency_tolerance_us
Date: January 2014
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../power/pm_qos_latency_tolerance_us attribute
contains the PM QoS active state latency tolerance limit for the
given device in microseconds. That is the maximum memory access
latency the device can suffer without any visible adverse
effects on user space functionality. If that value is the
string "any", the latency does not matter to user space at all,
but hardware should not be allowed to set the latency tolerance
for the device automatically.
Reading "auto" from this file means that the maximum memory
access latency for the device may be determined automatically
by the hardware as needed. Writing "auto" to it allows the
hardware to be switched to this mode if there are no other
latency tolerance requirements from the kernel side.
This attribute is only present if the feature controlled by it
is supported by the hardware.
This attribute has no effect on runtime suspend and resume of
devices and on system-wide suspend/resume and hibernation.
What: /sys/devices/.../power/pm_qos_no_power_off
Date: September 2012
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
......
What: /sys/firmware/devicetree/*
Date: November 2013
Contact: Grant Likely <grant.likely@linaro.org>
Description:
When using OpenFirmware or a Flattened Device Tree to enumerate
hardware, the device tree structure will be exposed in this
directory.
It is possible for multiple device-tree directories to exist.
Some device drivers use a separate detached device tree which
have no attachment to the system tree and will appear in a
different subdirectory under /sys/firmware/devicetree.
Userspace must not use the /sys/firmware/devicetree/base
path directly, but instead should follow /proc/device-tree
symlink. It is possible that the absolute path will change
in the future, but the symlink is the stable ABI.
The /proc/device-tree symlink replaces the devicetree /proc
filesystem support, and has largely the same semantics and
should be compatible with existing userspace.
The contents of /sys/firmware/devicetree/ is a
hierarchy of directories, one per device tree node. The
directory name is the resolved path component name (node
name plus address). Properties are represented as files
in the directory. The contents of each file is the exact
binary data from the device tree.
......@@ -55,3 +55,15 @@ Date: January 2014
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:
Controls the number of trials to find a victim segment.
What: /sys/fs/f2fs/<disk>/dir_level
Date: March 2014
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:
Controls the directory level for large directory.
What: /sys/fs/f2fs/<disk>/ram_thresh
Date: March 2014
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:
Controls the memory footprint used by f2fs.
......@@ -49,3 +49,4 @@ Description: Module taint flags:
O - out-of-tree module
F - force-loaded module
C - staging driver module
E - unsigned module
......@@ -12,8 +12,9 @@ Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/power/state file controls the system power state.
Reading from this file returns what states are supported,
which is hard-coded to 'standby' (Power-On Suspend), 'mem'
(Suspend-to-RAM), and 'disk' (Suspend-to-Disk).
which is hard-coded to 'freeze' (Low-Power Idle), 'standby'
(Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'
(Suspend-to-Disk).
Writing to this file one of these strings causes the system to
transition into that state. Please see the file
......
......@@ -54,6 +54,26 @@ Description:
This file contains the number of programmable periodic
output channels offered by the PTP hardware clock.
What: /sys/class/ptp/ptpN/n_pins
Date: March 2014
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This file contains the number of programmable pins
offered by the PTP hardware clock.
What: /sys/class/ptp/ptpN/pins
Date: March 2014
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This directory contains one file for each programmable
pin offered by the PTP hardware clock. The file name
is the hardware dependent pin name. Reading from this
file produces two numbers, the assigned function (see
the PTP_PF_ enumeration values in linux/ptp_clock.h)
and the channel number. The function and channel
assignment may be changed by two writing numbers into
the file.
What: /sys/class/ptp/ptpN/pps_avaiable
Date: September 2010
Contact: Richard Cochran <richardcochran@gmail.com>
......
......@@ -98,6 +98,8 @@
!Finclude/net/cfg80211.h priv_to_wiphy
!Finclude/net/cfg80211.h set_wiphy_dev
!Finclude/net/cfg80211.h wdev_priv
!Finclude/net/cfg80211.h ieee80211_iface_limit
!Finclude/net/cfg80211.h ieee80211_iface_combination
</chapter>
<chapter>
<title>Actions and configuration</title>
......
......@@ -14,9 +14,9 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
80211.xml debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
tracepoint.xml drm.xml media_api.xml
tracepoint.xml drm.xml media_api.xml w1.xml
include $(srctree)/Documentation/DocBook/media/Makefile
include Documentation/DocBook/media/Makefile
###
# The build process is as follows (targets):
......@@ -36,6 +36,7 @@ PS_METHOD = $(prefer-db2x)
# The targets that may be used.
PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs
targets += $(DOCBOOKS)
BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
xmldocs: $(BOOKS)
sgmldocs: xmldocs
......@@ -58,14 +59,14 @@ mandocs: $(MAN)
installmandocs: mandocs
mkdir -p /usr/local/man/man9/
install Documentation/DocBook/man/*.9.gz /usr/local/man/man9/
install $(obj)/man/*.9.gz /usr/local/man/man9/
###
#External programs used
KERNELDOC = $(srctree)/scripts/kernel-doc
DOCPROC = $(objtree)/scripts/docproc
XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl
XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl
XMLTOFLAGS += --skip-validation
###
......@@ -87,21 +88,9 @@ define rule_docproc
) > $(dir $@).$(notdir $@).cmd
endef
%.xml: %.tmpl FORCE
%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE
$(call if_changed_rule,docproc)
###
#Read in all saved dependency files
cmd_files := $(wildcard $(foreach f,$(BOOKS),$(dir $(f)).$(notdir $(f)).cmd))
ifneq ($(cmd_files),)
include $(cmd_files)
endif
###
# Changes in kernel-doc force a rebuild of all documentation
$(BOOKS): $(KERNELDOC)
# Tell kbuild to always build the programs
always := $(hostprogs-y)
......@@ -139,7 +128,7 @@ quiet_cmd_db2pdf = PDF $@
index = index.html
main_idx = Documentation/DocBook/$(index)
main_idx = $(obj)/$(index)
build_main_index = rm -rf $(main_idx); \
echo '<h1>Linux Kernel HTML Documentation</h1>' >> $(main_idx) && \
echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \
......@@ -148,7 +137,7 @@ build_main_index = rm -rf $(main_idx); \
quiet_cmd_db2html = HTML $@
cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
%.html: %.xml
@(which xmlto > /dev/null 2>&1) || \
......
此差异已折叠。
......@@ -671,7 +671,7 @@ printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);
<sect1 id="routines-local-irqs">
<title><function>local_irq_save()</function>/<function>local_irq_restore()</function>
<filename class="headerfile">include/asm/system.h</filename>
<filename class="headerfile">include/linux/irqflags.h</filename>
</title>
<para>
......@@ -850,16 +850,6 @@ printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);
<returnvalue>-ERESTARTSYS</returnvalue> if a signal is received.
The <function>wait_event()</function> version ignores signals.
</para>
<para>
Do not use the <function>sleep_on()</function> function family -
it is very easy to accidentally introduce races; almost certainly
one of the <function>wait_event()</function> family will do, or a
loop around <function>schedule_timeout()</function>. If you choose
to loop around <function>schedule_timeout()</function> remember
you must set the task state (with
<function>set_current_state()</function>) on each iteration to avoid
busy-looping.
</para>
</sect1>
......
......@@ -1042,7 +1042,14 @@ role="subsection"><title>DMX_ADD_PID</title>
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
<para>This ioctl call allows to add multiple PIDs to a transport stream filter
previously set up with DMX_SET_PES_FILTER and output equal to DMX_OUT_TSDEMUX_TAP.
</para></entry></row><row><entry align="char"><para>
It is used by readers of /dev/dvb/adapterX/demuxY.
</para></entry></row><row><entry align="char"><para>
It may be called at any time, i.e. before or after the first filter on the
shared file descriptor was started. It makes it possible to record multiple
services without the need to de-multiplex or re-multiplex TS packets.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
......@@ -1075,7 +1082,7 @@ role="subsection"><title>DMX_ADD_PID</title>
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
<para>PID number to be filtered.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
......@@ -1087,7 +1094,15 @@ role="subsection"><title>DMX_REMOVE_PID</title>
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
<para>This ioctl call allows to remove a PID when multiple PIDs are set on a
transport stream filter, e. g. a filter previously set up with output equal to
DMX_OUT_TSDEMUX_TAP, created via either DMX_SET_PES_FILTER or DMX_ADD_PID.
</para></entry></row><row><entry align="char"><para>
It is used by readers of /dev/dvb/adapterX/demuxY.
</para></entry></row><row><entry align="char"><para>
It may be called at any time, i.e. before or after the first filter on the
shared file descriptor was started. It makes it possible to record multiple
services without the need to de-multiplex or re-multiplex TS packets.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
......@@ -1120,7 +1135,7 @@ role="subsection"><title>DMX_REMOVE_PID</title>
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
<para>PID of the PES filter to be removed.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
......
......@@ -18,7 +18,7 @@
<firstname>Mauro</firstname>
<othername role="mi">Carvalho</othername>
<surname>Chehab</surname>
<affiliation><address><email>mchehab@redhat.com</email></address></affiliation>
<affiliation><address><email>m.chehab@samsung.com</email></address></affiliation>
<contrib>Ported document to Docbook XML.</contrib>
</author>
</authorgroup>
......@@ -28,7 +28,7 @@
<holder>Convergence GmbH</holder>
</copyright>
<copyright>
<year>2009-2012</year>
<year>2009-2014</year>
<holder>Mauro Carvalho Chehab</holder>
</copyright>
......
......@@ -196,7 +196,7 @@ get/set up to 64 properties. The actual meaning of each property is described on
<para>1)For satellital delivery systems, it is measured in kHz.
For the other ones, it is measured in Hz.</para>
<para>2)For ISDB-T, the channels are usually transmitted with an offset of 143kHz.
E.g. a valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
E.g. a valid frequency could be 474143 kHz. The stepping is bound to the bandwidth of
the channel which is 6MHz.</para>
<para>3)As in ISDB-Tsb the channel consists of only one or three segments the
......
......@@ -744,7 +744,7 @@ typedef enum fe_hierarchy {
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request = <link linkend="FE_READ_SNR">FE_READ_SNR</link>, int16_t
<para>int ioctl(int fd, int request = <link linkend="FE_READ_SNR">FE_READ_SNR</link>, uint16_t
&#x22C6;snr);</para>
</entry>
</row></tbody></tgroup></informaltable>
......@@ -766,7 +766,7 @@ typedef enum fe_hierarchy {
</entry>
</row><row><entry
align="char">
<para>int16_t *snr</para>
<para>uint16_t *snr</para>
</entry><entry
align="char">
<para>The signal-to-noise ratio is stored into *snr.</para>
......@@ -791,7 +791,7 @@ typedef enum fe_hierarchy {
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl( int fd, int request =
<link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link>, int16_t &#x22C6;strength);</para>
<link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link>, uint16_t &#x22C6;strength);</para>
</entry>
</row></tbody></tgroup></informaltable>
......@@ -814,7 +814,7 @@ typedef enum fe_hierarchy {
</entry>
</row><row><entry
align="char">
<para>int16_t *strength</para>
<para>uint16_t *strength</para>
</entry><entry
align="char">
<para>The signal strength value is stored into *strength.</para>
......
......@@ -397,7 +397,7 @@ linkend="control" />.</para>
<para>The <structfield>depth</structfield> (average number of
bits per pixel) of a video image is implied by the selected image
format. V4L2 does not explicitely provide such information assuming
format. V4L2 does not explicitly provide such information assuming
applications recognizing the format are aware of the image depth and
others need not know. The <structfield>palette</structfield> field
moved into the &v4l2-pix-format;:<informaltable>
......@@ -2535,6 +2535,16 @@ fields changed from _s32 to _u32.
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.15</title>
<orderedlist>
<listitem>
<para>Added Software Defined Radio (SDR) Interface.
</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>
......@@ -2651,6 +2661,9 @@ ioctls.</para>
<listitem>
<para>Exporting DMABUF files using &VIDIOC-EXPBUF; ioctl.</para>
</listitem>
<listitem>
<para>Software Defined Radio (SDR) Interface, <xref linkend="sdr" />.</para>
</listitem>
</itemizedlist>
</section>
......
......@@ -2256,6 +2256,26 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.</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 id="v4l2-mpeg-video-hor-search-range">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row><entry spanname="descr">Horizontal search range defines maximum horizontal search area in pixels
to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set
horizontal search range for motion estimation module in video encoder.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-vert-search-range">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row><entry spanname="descr">Vertical search range defines maximum vertical search area in pixels
to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set
vertical search range for motion estimation module in video encoder.</entry>
</row>
<row><entry></entry></row>
......@@ -4370,6 +4390,24 @@ interface and may change in the future.</para>
<entry>The flash controller has detected a short or open
circuit condition on the indicator LED.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_UNDER_VOLTAGE</constant></entry>
<entry>Flash controller voltage to the flash LED
has been below the minimum limit specific to the flash
controller.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_INPUT_VOLTAGE</constant></entry>
<entry>The input voltage of the flash controller is below
the limit under which strobing the flash at full current
will not be possible.The condition persists until this flag
is no longer set.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_LED_OVER_TEMPERATURE</constant></entry>
<entry>The temperature of the LED has exceeded its
allowed upper limit.</entry>
</row>
</tbody>
</entrytbl>
</row>
......@@ -4971,4 +5009,142 @@ defines possible values for de-emphasis. Here they are:</entry>
</table>
</section>
<section id="rf-tuner-controls">
<title>RF Tuner Control Reference</title>
<para>
The RF Tuner (RF_TUNER) class includes controls for common features of devices
having RF tuner.
</para>
<para>
In this context, RF tuner is radio receiver circuit between antenna and
demodulator. It receives radio frequency (RF) from the antenna and converts that
received signal to lower intermediate frequency (IF) or baseband frequency (BB).
Tuners that could do baseband output are often called Zero-IF tuners. Older
tuners were typically simple PLL tuners inside a metal box, whilst newer ones
are highly integrated chips without a metal box "silicon tuners". These controls
are mostly applicable for new feature rich silicon tuners, just because older
tuners does not have much adjustable features.
</para>
<para>
For more information about RF tuners see
<ulink url="http://en.wikipedia.org/wiki/Tuner_%28radio%29">Tuner (radio)</ulink>
and
<ulink url="http://en.wikipedia.org/wiki/RF_front_end">RF front end</ulink>
from Wikipedia.
</para>
<table pgwide="1" frame="none" id="rf-tuner-control-id">
<title>RF_TUNER 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_RF_TUNER_CLASS</constant>&nbsp;</entry>
<entry>class</entry>
</row><row><entry spanname="descr">The RF_TUNER class
descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a
description of this control class.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_BANDWIDTH_AUTO</constant>&nbsp;</entry>
<entry>boolean</entry>
</row>
<row>
<entry spanname="descr">Enables/disables tuner radio channel
bandwidth configuration. In automatic mode bandwidth configuration is performed
by the driver.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_BANDWIDTH</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">Filter(s) on tuner signal path are used to
filter signal according to receiving party needs. Driver configures filters to
fulfill desired bandwidth requirement. Used when V4L2_CID_RF_TUNER_BANDWIDTH_AUTO is not
set. Unit is in Hz. The range and step are driver-specific.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_LNA_GAIN_AUTO</constant>&nbsp;</entry>
<entry>boolean</entry>
</row>
<row>
<entry spanname="descr">Enables/disables LNA automatic gain control (AGC)</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO</constant>&nbsp;</entry>
<entry>boolean</entry>
</row>
<row>
<entry spanname="descr">Enables/disables mixer automatic gain control (AGC)</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_IF_GAIN_AUTO</constant>&nbsp;</entry>
<entry>boolean</entry>
</row>
<row>
<entry spanname="descr">Enables/disables IF automatic gain control (AGC)</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_LNA_GAIN</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">LNA (low noise amplifier) gain is first
gain stage on the RF tuner signal path. It is located very close to tuner
antenna input. Used when <constant>V4L2_CID_RF_TUNER_LNA_GAIN_AUTO</constant> is not set.
The range and step are driver-specific.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_MIXER_GAIN</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">Mixer gain is second gain stage on the RF
tuner signal path. It is located inside mixer block, where RF signal is
down-converted by the mixer. Used when <constant>V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO</constant>
is not set. The range and step are driver-specific.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_IF_GAIN</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">IF gain is last gain stage on the RF tuner
signal path. It is located on output of RF tuner. It controls signal level of
intermediate frequency output or baseband output. Used when
<constant>V4L2_CID_RF_TUNER_IF_GAIN_AUTO</constant> is not set. The range and step are
driver-specific.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_PLL_LOCK</constant>&nbsp;</entry>
<entry>boolean</entry>
</row>
<row>
<entry spanname="descr">Is synthesizer PLL locked? RF tuner is
receiving given frequency when that control is set. This is a read-only control.
</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
</section>
......@@ -56,18 +56,18 @@ framebuffer device.</para>
unsigned int i;
int fb_fd;
if (-1 == ioctl (fd, VIDIOC_G_FBUF, &amp;fbuf)) {
perror ("VIDIOC_G_FBUF");
exit (EXIT_FAILURE);
if (-1 == ioctl(fd, VIDIOC_G_FBUF, &amp;fbuf)) {
perror("VIDIOC_G_FBUF");
exit(EXIT_FAILURE);
}
for (i = 0; i &gt; 30; ++i) {
for (i = 0; i &lt; 30; i++) {
char dev_name[16];
struct fb_fix_screeninfo si;
snprintf (dev_name, sizeof (dev_name), "/dev/fb%u", i);
snprintf(dev_name, sizeof(dev_name), "/dev/fb%u", i);
fb_fd = open (dev_name, O_RDWR);
fb_fd = open(dev_name, O_RDWR);
if (-1 == fb_fd) {
switch (errno) {
case ENOENT: /* no such file */
......@@ -75,19 +75,19 @@ for (i = 0; i &gt; 30; ++i) {
continue;
default:
perror ("open");
exit (EXIT_FAILURE);
perror("open");
exit(EXIT_FAILURE);
}
}
if (0 == ioctl (fb_fd, FBIOGET_FSCREENINFO, &amp;si)) {
if (si.smem_start == (unsigned long) fbuf.base)
if (0 == ioctl(fb_fd, FBIOGET_FSCREENINFO, &amp;si)) {
if (si.smem_start == (unsigned long)fbuf.base)
break;
} else {
/* Apparently not a framebuffer device. */
}
close (fb_fd);
close(fb_fd);
fb_fd = -1;
}
......
<title>Software Defined Radio Interface (SDR)</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
interface and may change in the future.</para>
</note>
<para>
SDR is an abbreviation of Software Defined Radio, the radio device
which uses application software for modulation or demodulation. This interface
is intended for controlling and data streaming of such devices.
</para>
<para>
SDR devices are accessed through character device special files named
<filename>/dev/swradio0</filename> to <filename>/dev/swradio255</filename>
with major number 81 and dynamically allocated minor numbers 0 to 255.
</para>
<section>
<title>Querying Capabilities</title>
<para>
Devices supporting the SDR receiver interface set the
<constant>V4L2_CAP_SDR_CAPTURE</constant> and
<constant>V4L2_CAP_TUNER</constant> flag in the
<structfield>capabilities</structfield> field of &v4l2-capability;
returned by the &VIDIOC-QUERYCAP; ioctl. That flag means the device has an
Analog to Digital Converter (ADC), which is a mandatory element for the SDR receiver.
At least one of the read/write, streaming or asynchronous I/O methods must
be supported.
</para>
</section>
<section>
<title>Supplemental Functions</title>
<para>
SDR devices can support <link linkend="control">controls</link>, and must
support the <link linkend="tuner">tuner</link> ioctls. Tuner ioctls are used
for setting the ADC sampling rate (sampling frequency) and the possible RF tuner
frequency.
</para>
<para>
The <constant>V4L2_TUNER_ADC</constant> tuner type is used for ADC tuners, and
the <constant>V4L2_TUNER_RF</constant> tuner type is used for RF tuners. The
tuner index of the RF tuner (if any) must always follow the ADC tuner index.
Normally the ADC tuner is #0 and the RF tuner is #1.
</para>
<para>
The &VIDIOC-S-HW-FREQ-SEEK; ioctl is not supported.
</para>
</section>
<section>
<title>Data Format Negotiation</title>
<para>
The SDR capture device uses the <link linkend="format">format</link> ioctls to
select the capture format. Both the sampling resolution and the data streaming
format are bound to that selectable format. In addition to the basic
<link linkend="format">format</link> ioctls, the &VIDIOC-ENUM-FMT; ioctl
must be supported as well.
</para>
<para>
To use the <link linkend="format">format</link> ioctls applications set the
<structfield>type</structfield> field of a &v4l2-format; to
<constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant> and use the &v4l2-sdr-format;
<structfield>sdr</structfield> member of the <structfield>fmt</structfield>
union as needed per the desired operation.
Currently only the <structfield>pixelformat</structfield> field of
&v4l2-sdr-format; is used. The content of that field is the V4L2 fourcc code
of the data format.
</para>
<table pgwide="1" frame="none" id="v4l2-sdr-format">
<title>struct <structname>v4l2_sdr_format</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>pixelformat</structfield></entry>
<entry>
The data format or type of compression, set by the application. This is a
little endian <link linkend="v4l2-fourcc">four character code</link>.
V4L2 defines SDR formats in <xref linkend="sdr-formats" />.
</entry>
</row>
<row>
<entry>__u8</entry>
<entry><structfield>reserved[28]</structfield></entry>
<entry>This array is reserved for future extensions.
Drivers and applications must set it to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
An SDR device may support <link linkend="rw">read/write</link>
and/or streaming (<link linkend="mmap">memory mapping</link>
or <link linkend="userp">user pointer</link>) I/O.
</para>
</section>
......@@ -339,8 +339,8 @@ returns immediately with an &EAGAIN; when no buffer is available. The
queues as a side effect. Since there is no notion of doing anything
"now" on a multitasking system, if an application needs to synchronize
with another event it should examine the &v4l2-buffer;
<structfield>timestamp</structfield> of captured buffers, or set the
field before enqueuing buffers for output.</para>
<structfield>timestamp</structfield> of captured or outputted buffers.
</para>
<para>Drivers implementing memory mapping I/O must
support the <constant>VIDIOC_REQBUFS</constant>,
......@@ -457,7 +457,7 @@ queues and unlocks all buffers as a side effect. Since there is no
notion of doing anything "now" on a multitasking system, if an
application needs to synchronize with another event it should examine
the &v4l2-buffer; <structfield>timestamp</structfield> of captured
buffers, or set the field before enqueuing buffers for output.</para>
or outputted buffers.</para>
<para>Drivers implementing user pointer I/O must
support the <constant>VIDIOC_REQBUFS</constant>,
......@@ -620,8 +620,7 @@ returns immediately with an &EAGAIN; when no buffer is available. The
unlocks all buffers as a side effect. Since there is no notion of doing
anything "now" on a multitasking system, if an application needs to synchronize
with another event it should examine the &v4l2-buffer;
<structfield>timestamp</structfield> of captured buffers, or set the field
before enqueuing buffers for output.</para>
<structfield>timestamp</structfield> of captured or outputted buffers.</para>
<para>Drivers implementing DMABUF importing I/O must support the
<constant>VIDIOC_REQBUFS</constant>, <constant>VIDIOC_QBUF</constant>,
......@@ -654,38 +653,19 @@ plane, are stored in struct <structname>v4l2_plane</structname> instead.
In that case, struct <structname>v4l2_buffer</structname> contains an array of
plane structures.</para>
<para>Nominally timestamps refer to the first data byte transmitted.
In practice however the wide range of hardware covered by the V4L2 API
limits timestamp accuracy. Often an interrupt routine will
sample the system clock shortly after the field or frame was stored
completely in memory. So applications must expect a constant
difference up to one field or frame period plus a small (few scan
lines) random error. The delay and error can be much
larger due to compression or transmission over an external bus when
the frames are not properly stamped by the sender. This is frequently
the case with USB cameras. Here timestamps refer to the instant the
field or frame was received by the driver, not the capture time. These
devices identify by not enumerating any video standards, see <xref
linkend="standard" />.</para>
<para>Similar limitations apply to output timestamps. Typically
the video hardware locks to a clock controlling the video timing, the
horizontal and vertical synchronization pulses. At some point in the
line sequence, possibly the vertical blanking, an interrupt routine
samples the system clock, compares against the timestamp and programs
the hardware to repeat the previous field or frame, or to display the
buffer contents.</para>
<para>Apart of limitations of the video device and natural
inaccuracies of all clocks, it should be noted system time itself is
not perfectly stable. It can be affected by power saving cycles,
warped to insert leap seconds, or even turned back or forth by the
system administrator affecting long term measurements. <footnote>
<para>Since no other Linux multimedia
API supports unadjusted time it would be foolish to introduce here. We
must use a universally supported clock to synchronize different media,
hence time of day.</para>
</footnote></para>
<para>Dequeued video buffers come with timestamps. The driver
decides at which part of the frame and with which clock the
timestamp is taken. Please see flags in the masks
<constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant> and
<constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> in <xref
linkend="buffer-flags" />. These flags are always valid and constant
across all buffers during the whole video stream. Changes in these
flags may take place as a side effect of &VIDIOC-S-INPUT; or
&VIDIOC-S-OUTPUT; however. The
<constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant> timestamp type
which is used by e.g. on mem-to-mem devices is an exception to the
rule: the timestamp source flags are copied from the OUTPUT video
buffer to the CAPTURE video buffer.</para>
<table frame="none" pgwide="1" id="v4l2-buffer">
<title>struct <structname>v4l2_buffer</structname></title>
......@@ -696,10 +676,11 @@ hence time of day.</para>
<entry>__u32</entry>
<entry><structfield>index</structfield></entry>
<entry></entry>
<entry>Number of the buffer, set by the application. This
field is only used for <link linkend="mmap">memory mapping</link> I/O
and can range from zero to the number of buffers allocated
with the &VIDIOC-REQBUFS; ioctl (&v4l2-requestbuffers; <structfield>count</structfield>) minus one.</entry>
<entry>Number of the buffer, set by the application except
when calling &VIDIOC-DQBUF;, then it is set by the driver.
This field can range from zero to the number of buffers allocated
with the &VIDIOC-REQBUFS; ioctl (&v4l2-requestbuffers; <structfield>count</structfield>),
plus any buffers allocated with &VIDIOC-CREATE-BUFS; minus one.</entry>
</row>
<row>
<entry>__u32</entry>
......@@ -718,7 +699,7 @@ linkend="v4l2-buf-type" /></entry>
buffer. It depends on the negotiated data format and may change with
each buffer for compressed variable size data like JPEG images.
Drivers must set this field when <structfield>type</structfield>
refers to an input stream, applications when an output stream.</entry>
refers to an input stream, applications when it refers to an output stream.</entry>
</row>
<row>
<entry>__u32</entry>
......@@ -735,7 +716,7 @@ linkend="buffer-flags" />.</entry>
buffer, see <xref linkend="v4l2-field" />. This field is not used when
the buffer contains VBI data. Drivers must set it when
<structfield>type</structfield> refers to an input stream,
applications when an output stream.</entry>
applications when it refers to an output stream.</entry>
</row>
<row>
<entry>struct timeval</entry>
......@@ -745,15 +726,13 @@ applications when an output stream.</entry>
byte was captured, as returned by the
<function>clock_gettime()</function> function for the relevant
clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
<xref linkend="buffer-flags" />. For output streams the data
will not be displayed before this time, secondary to the nominal
frame rate determined by the current video standard in enqueued
order. Applications can for example zero this field to display
frames as soon as possible. The driver stores the time at which
the first data byte was actually sent out in the
<structfield>timestamp</structfield> field. This permits
<xref linkend="buffer-flags" />. For output streams the driver
stores the time at which the last data byte was actually sent out
in the <structfield>timestamp</structfield> field. This permits
applications to monitor the drift between the video and system
clock.</para></entry>
clock. For output streams that use <constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant>
the application has to fill in the timestamp which will be copied
by the driver to the capture stream.</para></entry>
</row>
<row>
<entry>&v4l2-timecode;</entry>
......@@ -846,7 +825,8 @@ is the file descriptor associated with a DMABUF buffer.</entry>
<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 the application sets
single-planar API. This is set by the driver based on the calls to
&VIDIOC-REQBUFS; and/or &VIDIOC-CREATE-BUFS;. 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.
......@@ -880,13 +860,15 @@ should set this to 0.</entry>
<entry><structfield>bytesused</structfield></entry>
<entry></entry>
<entry>The number of bytes occupied by data in the plane
(its payload).</entry>
(its payload). Drivers must set this field when <structfield>type</structfield>
refers to an input stream, applications when it refers to an output stream.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>length</structfield></entry>
<entry></entry>
<entry>Size in bytes of the plane (not its payload).</entry>
<entry>Size in bytes of the plane (not its payload). This is set by the driver
based on the calls to &VIDIOC-REQBUFS; and/or &VIDIOC-CREATE-BUFS;.</entry>
</row>
<row>
<entry>union</entry>
......@@ -925,7 +907,9 @@ should set this to 0.</entry>
<entry>__u32</entry>
<entry><structfield>data_offset</structfield></entry>
<entry></entry>
<entry>Offset in bytes to video data in the plane, if applicable.
<entry>Offset in bytes to video data in the plane.
Drivers must set this field when <structfield>type</structfield>
refers to an input stream, applications when it refers to an output stream.
</entry>
</row>
<row>
......@@ -1005,6 +989,12 @@ should set this to 0.</entry>
<entry>Buffer for video output overlay (OSD), see <xref
linkend="osd" />.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant></entry>
<entry>11</entry>
<entry>Buffer for Software Defined Radio (SDR), see <xref
linkend="sdr" />.</entry>
</row>
</tbody>
</tgroup>
</table>
......@@ -1016,7 +1006,7 @@ should set this to 0.</entry>
<tbody valign="top">
<row>
<entry><constant>V4L2_BUF_FLAG_MAPPED</constant></entry>
<entry>0x0001</entry>
<entry>0x00000001</entry>
<entry>The buffer resides in device memory and has been mapped
into the application's address space, see <xref linkend="mmap" /> for details.
Drivers set or clear this flag when the
......@@ -1026,7 +1016,7 @@ Drivers set or clear this flag when the
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_QUEUED</constant></entry>
<entry>0x0002</entry>
<entry>0x00000002</entry>
<entry>Internally drivers maintain two buffer queues, an
incoming and outgoing queue. When this flag is set, the buffer is
currently on the incoming queue. It automatically moves to the
......@@ -1039,7 +1029,7 @@ cleared.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_DONE</constant></entry>
<entry>0x0004</entry>
<entry>0x00000004</entry>
<entry>When this flag is set, the buffer is currently on
the outgoing queue, ready to be dequeued from the driver. Drivers set
or clear this flag when the <constant>VIDIOC_QUERYBUF</constant> ioctl
......@@ -1049,11 +1039,11 @@ buffer cannot be on both queues at the same time, the
<constant>V4L2_BUF_FLAG_QUEUED</constant> and
<constant>V4L2_BUF_FLAG_DONE</constant> flag are mutually exclusive.
They can be both cleared however, then the buffer is in "dequeued"
state, in the application domain to say so.</entry>
state, in the application domain so to say.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_ERROR</constant></entry>
<entry>0x0040</entry>
<entry>0x00000040</entry>
<entry>When this flag is set, the buffer has been dequeued
successfully, although the data might have been corrupted.
This is recoverable, streaming may continue as normal and
......@@ -1063,35 +1053,43 @@ state, in the application domain to say so.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_KEYFRAME</constant></entry>
<entry>0x0008</entry>
<entry>0x00000008</entry>
<entry>Drivers set or clear this flag when calling the
<constant>VIDIOC_DQBUF</constant> ioctl. It may be set by video
capture devices when the buffer contains a compressed image which is a
key frame (or field), &ie; can be decompressed on its own.</entry>
key frame (or field), &ie; can be decompressed on its own. Also know as
an I-frame. Applications can set this bit when <structfield>type</structfield>
refers to an output stream.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_PFRAME</constant></entry>
<entry>0x0010</entry>
<entry>0x00000010</entry>
<entry>Similar to <constant>V4L2_BUF_FLAG_KEYFRAME</constant>
this flags predicted frames or fields which contain only differences to a
previous key frame.</entry>
previous key frame. Applications can set this bit when <structfield>type</structfield>
refers to an output stream.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_BFRAME</constant></entry>
<entry>0x0020</entry>
<entry>Similar to <constant>V4L2_BUF_FLAG_PFRAME</constant>
this is a bidirectional predicted frame or field. [ooc tbd]</entry>
<entry>0x00000020</entry>
<entry>Similar to <constant>V4L2_BUF_FLAG_KEYFRAME</constant>
this flags a bi-directional predicted frame or field which contains only
the differences between the current frame and both the preceding and following
key frames to specify its content. Applications can set this bit when
<structfield>type</structfield> refers to an output stream.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMECODE</constant></entry>
<entry>0x0100</entry>
<entry>0x00000100</entry>
<entry>The <structfield>timecode</structfield> field is valid.
Drivers set or clear this flag when the <constant>VIDIOC_DQBUF</constant>
ioctl is called.</entry>
ioctl is called. Applications can set this bit and the corresponding
<structfield>timecode</structfield> structure when <structfield>type</structfield>
refers to an output stream.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_PREPARED</constant></entry>
<entry>0x0400</entry>
<entry>0x00000400</entry>
<entry>The buffer has been prepared for I/O and can be queued by the
application. Drivers set or clear this flag when the
<link linkend="vidioc-querybuf">VIDIOC_QUERYBUF</link>, <link
......@@ -1101,7 +1099,7 @@ application. Drivers set or clear this flag when the
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant></entry>
<entry>0x0800</entry>
<entry>0x00000800</entry>
<entry>Caches do not have to be invalidated for this buffer.
Typically applications shall use this flag if the data captured in the buffer
is not going to be touched by the CPU, instead the buffer will, probably, be
......@@ -1110,7 +1108,7 @@ passed on to a DMA-capable hardware unit for further processing or output.
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant></entry>
<entry>0x1000</entry>
<entry>0x00001000</entry>
<entry>Caches do not have to be cleaned for this buffer.
Typically applications shall use this flag for output buffers if the data
in this buffer has not been created by the CPU but by some DMA-capable unit,
......@@ -1118,7 +1116,7 @@ in which case caches have not been used.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
<entry>0xe000</entry>
<entry>0x0000e000</entry>
<entry>Mask for timestamp types below. To test the
timestamp type, mask out bits not belonging to timestamp
type by performing a logical and operation with buffer
......@@ -1126,7 +1124,7 @@ in which case caches have not been used.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
<entry>0x0000</entry>
<entry>0x00000000</entry>
<entry>Unknown timestamp type. This type is used by
drivers before Linux 3.9 and may be either monotonic (see
below) or realtime (wall clock). Monotonic clock has been
......@@ -1139,7 +1137,7 @@ in which case caches have not been used.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry>
<entry>0x2000</entry>
<entry>0x00002000</entry>
<entry>The buffer timestamp has been taken from the
<constant>CLOCK_MONOTONIC</constant> clock. To access the
same clock outside V4L2, use
......@@ -1147,10 +1145,42 @@ in which case caches have not been used.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant></entry>
<entry>0x4000</entry>
<entry>0x00004000</entry>
<entry>The CAPTURE buffer timestamp has been taken from the
corresponding OUTPUT buffer. This flag applies only to mem2mem devices.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant></entry>
<entry>0x00070000</entry>
<entry>Mask for timestamp sources below. The timestamp source
defines the point of time the timestamp is taken in relation to
the frame. Logical 'and' operation between the
<structfield>flags</structfield> field and
<constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> produces the
value of the timestamp source. Applications must set the timestamp
source when <structfield>type</structfield> refers to an output stream
and <constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant> is set.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_EOF</constant></entry>
<entry>0x00000000</entry>
<entry>End Of Frame. The buffer timestamp has been taken
when the last pixel of the frame has been received or the
last pixel of the frame has been transmitted. In practice,
software generated timestamps will typically be read from
the clock a small amount of time after the last pixel has
been received or transmitten, depending on the system and
other activity in it.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_SOE</constant></entry>
<entry>0x00010000</entry>
<entry>Start Of Exposure. The buffer timestamp has been
taken when the exposure of the frame has begun. This is
only valid for the
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> buffer
type.</entry>
</row>
</tbody>
</tgroup>
</table>
......@@ -1440,10 +1470,9 @@ or application, depending on data direction, must set &v4l2-buffer;
<constant>V4L2_FIELD_BOTTOM</constant>. Any two successive fields pair
to build a frame. If fields are successive, without any dropped fields
between them (fields can drop individually), can be determined from
the &v4l2-buffer; <structfield>sequence</structfield> field. Image
sizes refer to the frame, not fields. This format cannot be selected
when using the read/write I/O method.<!-- Where it's indistinguishable
from V4L2_FIELD_SEQ_*. --></entry>
the &v4l2-buffer; <structfield>sequence</structfield> field. This format
cannot be selected when using the read/write I/O method since there
is no way to communicate if a field was a top or bottom field.</entry>
</row>
<row>
<entry><constant>V4L2_FIELD_INTERLACED_TB</constant></entry>
......
......@@ -12,18 +12,17 @@
<refsect1>
<title>Description</title>
<para>This is a multi-planar, two-plane version of the YUV 4:2:0 format.
<para>This is a multi-planar, two-plane version of the YUV 4:2:2 format.
The three components are separated into two sub-images or planes.
<constant>V4L2_PIX_FMT_NV16M</constant> differs from <constant>V4L2_PIX_FMT_NV16
</constant> in that the two planes are non-contiguous in memory, i.e. the chroma
plane does not necessarily immediately follows the luma plane.
plane does not necessarily immediately follow the luma plane.
The luminance data occupies the first plane. The Y plane has one byte per pixel.
In the second plane there is chrominance data with alternating chroma samples.
The CbCr plane is the same width and height, in bytes, as the Y plane.
Each CbCr pair belongs to four pixels. For example,
Each CbCr pair belongs to two 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>.
Y'<subscript>00</subscript>, Y'<subscript>01</subscript>.
<constant>V4L2_PIX_FMT_NV61M</constant> is the same as <constant>V4L2_PIX_FMT_NV16M</constant>
except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.</para>
......
<refentry id="V4L2-SDR-FMT-CU08">
<refmeta>
<refentrytitle>V4L2_SDR_FMT_CU8 ('CU08')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>
<constant>V4L2_SDR_FMT_CU8</constant>
</refname>
<refpurpose>Complex unsigned 8-bit IQ sample</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>
This format contains sequence of complex number samples. Each complex number
consist two parts, called In-phase and Quadrature (IQ). Both I and Q are
represented as a 8 bit unsigned number. I value comes first and Q value after
that.
</para>
<example>
<title><constant>V4L2_SDR_FMT_CU8</constant> 1 sample</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="2" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>I'<subscript>0</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;1:</entry>
<entry>Q'<subscript>0</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>
<refentry id="V4L2-SDR-FMT-CU16LE">
<refmeta>
<refentrytitle>V4L2_SDR_FMT_CU16LE ('CU16')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>
<constant>V4L2_SDR_FMT_CU16LE</constant>
</refname>
<refpurpose>Complex unsigned 16-bit little endian IQ sample</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>
This format contains sequence of complex number samples. Each complex number
consist two parts, called In-phase and Quadrature (IQ). Both I and Q are
represented as a 16 bit unsigned little endian number. I value comes first
and Q value after that.
</para>
<example>
<title><constant>V4L2_SDR_FMT_CU16LE</constant> 1 sample</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="3" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>I'<subscript>0[7:0]</subscript></entry>
<entry>I'<subscript>0[15:8]</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;2:</entry>
<entry>Q'<subscript>0[7:0]</subscript></entry>
<entry>Q'<subscript>0[15:8]</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>
......@@ -25,7 +25,12 @@ capturing and output, for overlay frame buffer formats see also
<row>
<entry>__u32</entry>
<entry><structfield>height</structfield></entry>
<entry>Image height in pixels.</entry>
<entry>Image height in pixels. If <structfield>field</structfield> is
one of <constant>V4L2_FIELD_TOP</constant>, <constant>V4L2_FIELD_BOTTOM</constant>
or <constant>V4L2_FIELD_ALTERNATE</constant> then height refers to the
number of lines in the field, otherwise it refers to the number of
lines in the frame (which is twice the field height for interlaced
formats).</entry>
</row>
<row>
<entry spanname="hspan">Applications set these fields to
......@@ -54,7 +59,7 @@ linkend="reserved-formats" /></entry>
can request to capture or output only the top or bottom field, or both
fields interlaced or sequentially stored in one buffer or alternating
in separate buffers. Drivers return the actual field order selected.
For details see <xref linkend="field-order" />.</entry>
For more details on fields see <xref linkend="field-order" />.</entry>
</row>
<row>
<entry>__u32</entry>
......@@ -81,7 +86,10 @@ plane and is divided by the same factor as the
example the Cb and Cr planes of a YUV 4:2:0 image have half as many
padding bytes following each line as the Y plane. To avoid ambiguities
drivers must return a <structfield>bytesperline</structfield> value
rounded up to a multiple of the scale factor.</para></entry>
rounded up to a multiple of the scale factor.</para>
<para>For compressed formats the <structfield>bytesperline</structfield>
value makes no sense. Applications and drivers must set this to 0 in
that case.</para></entry>
</row>
<row>
<entry>__u32</entry>
......@@ -97,7 +105,8 @@ hold an image.</entry>
<entry>&v4l2-colorspace;</entry>
<entry><structfield>colorspace</structfield></entry>
<entry>This information supplements the
<structfield>pixelformat</structfield> and must be set by the driver,
<structfield>pixelformat</structfield> and must be set by the driver for
capture streams and by the application for output streams,
see <xref linkend="colorspaces" />.</entry>
</row>
<row>
......@@ -135,7 +144,7 @@ set this field to zero.</entry>
<entry>__u16</entry>
<entry><structfield>bytesperline</structfield></entry>
<entry>Distance in bytes between the leftmost pixels in two adjacent
lines.</entry>
lines. See &v4l2-pix-format;.</entry>
</row>
<row>
<entry>__u16</entry>
......@@ -154,12 +163,12 @@ set this field to zero.</entry>
<row>
<entry>__u32</entry>
<entry><structfield>width</structfield></entry>
<entry>Image width in pixels.</entry>
<entry>Image width in pixels. See &v4l2-pix-format;.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>height</structfield></entry>
<entry>Image height in pixels.</entry>
<entry>Image height in pixels. See &v4l2-pix-format;.</entry>
</row>
<row>
<entry>__u32</entry>
......@@ -811,6 +820,17 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see
</table>
</section>
<section id="sdr-formats">
<title>SDR Formats</title>
<para>These formats are used for <link linkend="sdr">SDR Capture</link>
interface only.</para>
&sub-sdr-cu08;
&sub-sdr-cu16le;
</section>
<section id="pixfmt-reserved">
<title>Reserved Format Identifiers</title>
......
<partinfo>
<authorgroup>
<author>
<firstname>Mauro</firstname>
<surname>Chehab</surname>
<othername role="mi">Carvalho</othername>
<affiliation><address><email>m.chehab@samsung.com</email></address></affiliation>
<contrib>Initial version.</contrib>
</author>
</authorgroup>
<copyright>
<year>2009-2014</year>
<holder>Mauro Carvalho Chehab</holder>
</copyright>
<revhistory>
<!-- Put document revisions here, newest first. -->
<revision>
<revnumber>3.15</revnumber>
<date>2014-02-06</date>
<authorinitials>mcc</authorinitials>
<revremark>Added the interface description and the RC sysfs class description.</revremark>
</revision>
<revision>
<revnumber>1.0</revnumber>
<date>2009-09-06</date>
<authorinitials>mcc</authorinitials>
<revremark>Initial revision</revremark>
</revision>
</revhistory>
</partinfo>
<title>Remote Controller API</title>
<chapter id="remote_controllers">
<title>Remote Controllers</title>
<section id="Remote_controllers_Intro">
<title>Introduction</title>
<para>Currently, most analog and digital devices have a Infrared input for remote controllers. Each
manufacturer has their own type of control. It is not rare for the same manufacturer to ship different
types of controls, depending on the device.</para>
<para>A Remote Controller interface is mapped as a normal evdev/input interface, just like a keyboard or a mouse.
So, it uses all ioctls already defined for any other input devices.</para>
<para>However, remove controllers are more flexible than a normal input device, as the IR
receiver (and/or transmitter) can be used in conjunction with a wide variety of different IR remotes.</para>
<para>In order to allow flexibility, the Remote Controller subsystem allows controlling the
RC-specific attributes via <link linkend="remote_controllers_sysfs_nodes">the sysfs class nodes</link>.</para>
</section>
<section id="remote_controllers_sysfs_nodes">
<title>Remote Controller's sysfs nodes</title>
<para>As defined at <constant>Documentation/ABI/testing/sysfs-class-rc</constant>, those are the sysfs nodes that control the Remote Controllers:</para>
<section id="sys_class_rc">
<title>/sys/class/rc/</title>
<para>The <constant>/sys/class/rc/</constant> class sub-directory belongs to the Remote Controller
core and provides a sysfs interface for configuring infrared remote controller receivers.
</para>
</section>
<section id="sys_class_rc_rcN">
<title>/sys/class/rc/rcN/</title>
<para>A <constant>/sys/class/rc/rcN</constant> directory is created for each remote
control receiver device where N is the number of the receiver.</para>
</section>
<section id="sys_class_rc_rcN_protocols">
<title>/sys/class/rc/rcN/protocols</title>
<para>Reading this file returns a list of available protocols, something like:</para>
<para><constant>rc5 [rc6] nec jvc [sony]</constant></para>
<para>Enabled protocols are shown in [] brackets.</para>
<para>Writing "+proto" will add a protocol to the list of enabled protocols.</para>
<para>Writing "-proto" will remove a protocol from the list of enabled protocols.</para>
<para>Writing "proto" will enable only "proto".</para>
<para>Writing "none" will disable all protocols.</para>
<para>Write fails with EINVAL if an invalid protocol combination or unknown protocol name is used.</para>
</section>
<section id="sys_class_rc_rcN_filter">
<title>/sys/class/rc/rcN/filter</title>
<para>Sets the scancode filter expected value.</para>
<para>Use in combination with <constant>/sys/class/rc/rcN/filter_mask</constant> to set the
expected value of the bits set in the filter mask.
If the hardware supports it then scancodes which do not match
the filter will be ignored. Otherwise the write will fail with
an error.</para>
<para>This value may be reset to 0 if the current protocol is altered.</para>
</section>
<section id="sys_class_rc_rcN_filter_mask">
<title>/sys/class/rc/rcN/filter_mask</title>
<para>Sets the scancode filter mask of bits to compare.
Use in combination with <constant>/sys/class/rc/rcN/filter</constant> to set the bits
of the scancode which should be compared against the expected
value. A value of 0 disables the filter to allow all valid
scancodes to be processed.</para>
<para>If the hardware supports it then scancodes which do not match
the filter will be ignored. Otherwise the write will fail with
an error.</para>
<para>This value may be reset to 0 if the current protocol is altered.</para>
</section>
<section id="sys_class_rc_rcN_wakeup_protocols">
<title>/sys/class/rc/rcN/wakeup_protocols</title>
<para>Reading this file returns a list of available protocols to use for the
wakeup filter, something like:</para>
<para><constant>rc5 rc6 nec jvc [sony]</constant></para>
<para>The enabled wakeup protocol is shown in [] brackets.</para>
<para>Writing "+proto" will add a protocol to the list of enabled wakeup
protocols.</para>
<para>Writing "-proto" will remove a protocol from the list of enabled wakeup
protocols.</para>
<para>Writing "proto" will use "proto" for wakeup events.</para>
<para>Writing "none" will disable wakeup.</para>
<para>Write fails with EINVAL if an invalid protocol combination or unknown
protocol name is used, or if wakeup is not supported by the hardware.</para>
</section>
<section id="sys_class_rc_rcN_wakeup_filter">
<title>/sys/class/rc/rcN/wakeup_filter</title>
<para>Sets the scancode wakeup filter expected value.
Use in combination with <constant>/sys/class/rc/rcN/wakeup_filter_mask</constant> to
set the expected value of the bits set in the wakeup filter mask
to trigger a system wake event.</para>
<para>If the hardware supports it and wakeup_filter_mask is not 0 then
scancodes which match the filter will wake the system from e.g.
suspend to RAM or power off.
Otherwise the write will fail with an error.</para>
<para>This value may be reset to 0 if the wakeup protocol is altered.</para>
</section>
<section id="sys_class_rc_rcN_wakeup_filter_mask">
<title>/sys/class/rc/rcN/wakeup_filter_mask</title>
<para>Sets the scancode wakeup filter mask of bits to compare.
Use in combination with <constant>/sys/class/rc/rcN/wakeup_filter</constant> to set
the bits of the scancode which should be compared against the
expected value to trigger a system wake event.</para>
<para>If the hardware supports it and wakeup_filter_mask is not 0 then
scancodes which match the filter will wake the system from e.g.
suspend to RAM or power off.
Otherwise the write will fail with an error.</para>
<para>This value may be reset to 0 if the wakeup protocol is altered.</para>
</section>
</section>
<section id="Remote_controllers_tables">
<title>Remote controller tables</title>
<para>Unfortunately, for several years, there was no effort to create uniform IR keycodes for
different devices. This caused the same IR keyname to be mapped completely differently on
different IR devices. This resulted that the same IR keyname to be mapped completely different on
......@@ -175,3 +317,4 @@ keymapping.</para>
</section>
&sub-lirc_device_interface;
</chapter>
......@@ -70,7 +70,7 @@ MPEG stream embedded, sliced VBI data format in this specification.
Remote Controller chapter.</contrib>
<affiliation>
<address>
<email>mchehab@redhat.com</email>
<email>m.chehab@samsung.com</email>
</address>
</affiliation>
</author>
......@@ -107,6 +107,16 @@ Remote Controller chapter.</contrib>
</address>
</affiliation>
</author>
<author>
<firstname>Antti</firstname>
<surname>Palosaari</surname>
<contrib>SDR API.</contrib>
<affiliation>
<address>
<email>crope@iki.fi</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
......@@ -125,6 +135,7 @@ Remote Controller chapter.</contrib>
<year>2011</year>
<year>2012</year>
<year>2013</year>
<year>2014</year>
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab,
Pawel Osciak</holder>
......@@ -140,6 +151,16 @@ structs, ioctls) must be noted in more detail in the history chapter
(compat.xml), along with the possible impact on existing drivers and
applications. -->
<revision>
<revnumber>3.15</revnumber>
<date>2014-02-03</date>
<authorinitials>hv, ap</authorinitials>
<revremark>Update several sections of "Common API Elements": "Opening and Closing Devices"
"Querying Capabilities", "Application Priority", "Video Inputs and Outputs", "Audio Inputs and Outputs"
"Tuners and Modulators", "Video Standards" and "Digital Video (DV) Timings". Added SDR API.
</revremark>
</revision>
<revision>
<revnumber>3.14</revnumber>
<date>2013-11-25</date>
......@@ -537,6 +558,7 @@ and discussions on the V4L mailing list.</revremark>
<section id="ttx"> &sub-dev-teletext; </section>
<section id="radio"> &sub-dev-radio; </section>
<section id="rds"> &sub-dev-rds; </section>
<section id="sdr"> &sub-dev-sdr; </section>
<section id="event"> &sub-dev-event; </section>
<section id="subdev"> &sub-dev-subdev; </section>
</chapter>
......@@ -585,6 +607,7 @@ and discussions on the V4L mailing list.</revremark>
&sub-g-crop;
&sub-g-ctrl;
&sub-g-dv-timings;
&sub-g-edid;
&sub-g-enc-index;
&sub-g-ext-ctrls;
&sub-g-fbuf;
......@@ -616,7 +639,6 @@ 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;
......
......@@ -100,7 +100,7 @@ See <xref linkend="v4l2-tuner-type" /></entry>
<entry><structfield>capability</structfield></entry>
<entry spanname="hspan">The tuner/modulator capability flags for
this frequency band, see <xref linkend="tuner-capability" />. The <constant>V4L2_TUNER_CAP_LOW</constant>
capability must be the same for all frequency bands of the selected tuner/modulator.
or <constant>V4L2_TUNER_CAP_1HZ</constant> capability must be the same for all frequency bands of the selected tuner/modulator.
So either all bands have that capability set, or none of them have that capability.</entry>
</row>
<row>
......@@ -109,7 +109,8 @@ So either all bands have that capability set, or none of them have that capabili
<entry spanname="hspan">The lowest tunable frequency in
units of 62.5 kHz, or if the <structfield>capability</structfield>
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz, for this frequency band.</entry>
Hz, for this frequency band. A 1 Hz unit is used when the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry>
</row>
<row>
<entry>__u32</entry>
......@@ -117,7 +118,8 @@ Hz, for this frequency band.</entry>
<entry spanname="hspan">The highest tunable frequency in
units of 62.5 kHz, or if the <structfield>capability</structfield>
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz, for this frequency band.</entry>
Hz, for this frequency band. A 1 Hz unit is used when the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry>
</row>
<row>
<entry>__u32</entry>
......
<refentry id="vidioc-g-edid">
<refmeta>
<refentrytitle>ioctl VIDIOC_G_EDID, VIDIOC_S_EDID</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_G_EDID</refname>
<refname>VIDIOC_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_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_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_G_EDID, VIDIOC_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
from a receiver or an output of a transmitter device. They can be
used with subdevice nodes (/dev/v4l-subdevX) or with video nodes (/dev/videoX).</para>
<para>When used with video nodes the <structfield>pad</structfield> field represents the
input (for video capture devices) or output (for video output devices) index as
is returned by &VIDIOC-ENUMINPUT; and &VIDIOC-ENUMOUTPUT; respectively. When used
with subdevice nodes the <structfield>pad</structfield> field represents the
input or output pad of the subdevice. If there is no EDID support for the given
<structfield>pad</structfield> value, then the &EINVAL; will be returned.</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_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>&nbsp;*&nbsp;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-edid">
<title>struct <structname>v4l2_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. When used with a video device
node the pad represents the input or output index as returned by
&VIDIOC-ENUMINPUT; and &VIDIOC-ENUMOUTPUT; respectively.</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&nbsp;*</entry>
<entry><structfield>edid</structfield></entry>
<entry>Pointer to memory that contains the EDID. The minimum size is
<structfield>blocks</structfield>&nbsp;*&nbsp;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>
......@@ -327,7 +327,12 @@ These controls are described in <xref
These controls are described in <xref
linkend="fm-rx-controls" />.</entry>
</row>
<row>
<entry><constant>V4L2_CTRL_CLASS_RF_TUNER</constant></entry>
<entry>0xa20000</entry>
<entry>The class containing RF tuner controls.
These controls are described in <xref linkend="rf-tuner-controls" />.</entry>
</row>
</tbody>
</tgroup>
</table>
......
......@@ -169,6 +169,13 @@ capture and output devices.</entry>
<entry>Sliced VBI capture or output parameters. See
<xref linkend="sliced" /> for details. Used by sliced VBI
capture and output devices.</entry>
</row>
<row>
<entry></entry>
<entry>&v4l2-sdr-format;</entry>
<entry><structfield>sdr</structfield></entry>
<entry>Definition of a data format, see
<xref linkend="pixfmt" />, used by SDR capture devices.</entry>
</row>
<row>
<entry></entry>
......
......@@ -109,9 +109,10 @@ See <xref linkend="v4l2-tuner-type" /></entry>
<entry>__u32</entry>
<entry><structfield>frequency</structfield></entry>
<entry>Tuning frequency in units of 62.5 kHz, or if the
&v4l2-tuner; or &v4l2-modulator; <structfield>capabilities</structfield> flag
&v4l2-tuner; or &v4l2-modulator; <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz.</entry>
Hz. A 1 Hz unit is used when the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry>
</row>
<row>
<entry>__u32</entry>
......
......@@ -113,7 +113,8 @@ change for example with the current video standard.</entry>
<entry>The lowest tunable frequency in units of 62.5
KHz, or if the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz.</entry>
Hz, or if the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.</entry>
</row>
<row>
<entry>__u32</entry>
......@@ -121,7 +122,8 @@ Hz.</entry>
<entry>The highest tunable frequency in units of 62.5
KHz, or if the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz.</entry>
Hz, or if the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.</entry>
</row>
<row>
<entry>__u32</entry>
......
......@@ -134,7 +134,9 @@ the structure refers to a radio tuner the
<entry spanname="hspan">The lowest tunable frequency in
units of 62.5 kHz, or if the <structfield>capability</structfield>
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz. If multiple frequency bands are supported, then
Hz, or if the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.
If multiple frequency bands are supported, then
<structfield>rangelow</structfield> is the lowest frequency
of all the frequency bands.</entry>
</row>
......@@ -144,7 +146,9 @@ of all the frequency bands.</entry>
<entry spanname="hspan">The highest tunable frequency in
units of 62.5 kHz, or if the <structfield>capability</structfield>
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz. If multiple frequency bands are supported, then
Hz, or if the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.
If multiple frequency bands are supported, then
<structfield>rangehigh</structfield> is the highest frequency
of all the frequency bands.</entry>
</row>
......@@ -270,7 +274,7 @@ applications must set the array to zero.</entry>
<entry><constant>V4L2_TUNER_CAP_LOW</constant></entry>
<entry>0x0001</entry>
<entry>When set, tuning frequencies are expressed in units of
62.5&nbsp;Hz, otherwise in units of 62.5&nbsp;kHz.</entry>
62.5 Hz instead of 62.5 kHz.</entry>
</row>
<row>
<entry><constant>V4L2_TUNER_CAP_NORM</constant></entry>
......@@ -360,6 +364,11 @@ radio tuners.</entry>
<entry>The range to search when using the hardware seek functionality
is programmable, see &VIDIOC-S-HW-FREQ-SEEK; for details.</entry>
</row>
<row>
<entry><constant>V4L2_TUNER_CAP_1HZ</constant></entry>
<entry>0x1000</entry>
<entry>When set, tuning frequencies are expressed in units of 1 Hz instead of 62.5 kHz.</entry>
</row>
</tbody>
</tgroup>
</table>
......
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册