You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
This commit is contained in:
Paul Mundt
@@ -328,7 +328,7 @@ S: Haifa, Israel
|
||||
N: Johannes Berg
|
||||
E: johannes@sipsolutions.net
|
||||
W: http://johannes.sipsolutions.net/
|
||||
P: 1024D/9AB78CA5 AD02 0176 4E29 C137 1DF6 08D2 FC44 CF86 9AB7 8CA5
|
||||
P: 4096R/7BF9099A C0EB C440 F6DA 091C 884D 8532 E0F3 73F3 7BF9 099A
|
||||
D: powerpc & 802.11 hacker
|
||||
|
||||
N: Stephen R. van den Berg (AKA BuGless)
|
||||
|
||||
@@ -328,8 +328,6 @@ sysrq.txt
|
||||
- info on the magic SysRq key.
|
||||
telephony/
|
||||
- directory with info on telephony (e.g. voice over IP) support.
|
||||
uml/
|
||||
- directory with information about User Mode Linux.
|
||||
unicode.txt
|
||||
- info on the Unicode character/font mapping used in Linux.
|
||||
unshare.txt
|
||||
|
||||
@@ -0,0 +1,10 @@
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/startup_profile
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 0-4.
|
||||
When read, this attribute returns the number of the actual
|
||||
profile. This value is persistent, so its equivalent to the
|
||||
profile that's active when the mouse is powered on next time.
|
||||
When written, this file sets the number of the startup profile
|
||||
and the mouse activates this profile immediately.
|
||||
Please use actual_profile, it does the same thing.
|
||||
@@ -0,0 +1,31 @@
|
||||
What: /sys/bus/bcma/devices/.../manuf
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.40
|
||||
Contact: Rafał Miłecki <zajec5@gmail.com>
|
||||
Description:
|
||||
Each BCMA core has it's manufacturer id. See
|
||||
include/linux/bcma/bcma.h for possible values.
|
||||
|
||||
What: /sys/bus/bcma/devices/.../id
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.40
|
||||
Contact: Rafał Miłecki <zajec5@gmail.com>
|
||||
Description:
|
||||
There are a few types of BCMA cores, they can be identified by
|
||||
id field.
|
||||
|
||||
What: /sys/bus/bcma/devices/.../rev
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.40
|
||||
Contact: Rafał Miłecki <zajec5@gmail.com>
|
||||
Description:
|
||||
BCMA cores of the same type can still slightly differ depending
|
||||
on their revision. Use it for detailed programming.
|
||||
|
||||
What: /sys/bus/bcma/devices/.../class
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.40
|
||||
Contact: Rafał Miłecki <zajec5@gmail.com>
|
||||
Description:
|
||||
Each BCMA core is identified by few fields, including class it
|
||||
belongs to. See include/linux/bcma/bcma.h for possible values.
|
||||
@@ -74,6 +74,15 @@ Description:
|
||||
hot-remove the PCI device and any of its children.
|
||||
Depends on CONFIG_HOTPLUG.
|
||||
|
||||
What: /sys/bus/pci/devices/.../pci_bus/.../rescan
|
||||
Date: May 2011
|
||||
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
|
||||
Description:
|
||||
Writing a non-zero value to this attribute will
|
||||
force a rescan of the bus and all child buses,
|
||||
and re-discover devices removed earlier from this
|
||||
part of the device tree. Depends on CONFIG_HOTPLUG.
|
||||
|
||||
What: /sys/bus/pci/devices/.../rescan
|
||||
Date: January 2009
|
||||
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
|
||||
|
||||
@@ -183,21 +183,21 @@ Description: Discover and change clock speed of CPUs
|
||||
to learn how to control the knobs.
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X
|
||||
Date: August 2008
|
||||
What: /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}
|
||||
Date: August 2008
|
||||
KernelVersion: 2.6.27
|
||||
Contact: mark.langsdorf@amd.com
|
||||
Description: These files exist in every cpu's cache index directories.
|
||||
There are currently 2 cache_disable_# files in each
|
||||
directory. Reading from these files on a supported
|
||||
processor will return that cache disable index value
|
||||
for that processor and node. Writing to one of these
|
||||
files will cause the specificed cache index to be disabled.
|
||||
Contact: discuss@x86-64.org
|
||||
Description: Disable L3 cache indices
|
||||
|
||||
Currently, only AMD Family 10h Processors support cache index
|
||||
disable, and only for their L3 caches. See the BIOS and
|
||||
Kernel Developer's Guide at
|
||||
http://support.amd.com/us/Embedded_TechDocs/31116-Public-GH-BKDG_3-28_5-28-09.pdf
|
||||
for formatting information and other details on the
|
||||
cache index disable.
|
||||
Users: joachim.deguara@amd.com
|
||||
These files exist in every CPU's cache/index3 directory. Each
|
||||
cache_disable_{0,1} file corresponds to one disable slot which
|
||||
can be used to disable a cache index. Reading from these files
|
||||
on a processor with this functionality will return the currently
|
||||
disabled index for that node. There is one L3 structure per
|
||||
node, or per internal node on MCM machines. Writing a valid
|
||||
index to one of these files will cause the specificed cache
|
||||
index to be disabled.
|
||||
|
||||
All AMD processors with L3 caches provide this functionality.
|
||||
For details, see BKDGs at
|
||||
http://developer.amd.com/documentation/guides/Pages/default.aspx
|
||||
|
||||
@@ -1,9 +1,12 @@
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/actual_profile
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the number of the actual profile in
|
||||
range 0-4.
|
||||
This file is readonly.
|
||||
Description: The integer value of this attribute ranges from 0-4.
|
||||
When read, this attribute returns the number of the actual
|
||||
profile. This value is persistent, so its equivalent to the
|
||||
profile that's active when the mouse is powered on next time.
|
||||
When written, this file sets the number of the startup profile
|
||||
and the mouse activates this profile immediately.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version
|
||||
@@ -89,16 +92,6 @@ Description: The mouse has a tracking- and a distance-control-unit. These
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/startup_profile
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 0-4.
|
||||
When read, this attribute returns the number of the profile
|
||||
that's active when the mouse is powered on.
|
||||
When written, this file sets the number of the startup profile
|
||||
and the mouse activates this profile immediately.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
|
||||
@@ -14,14 +14,15 @@ Description:
|
||||
|
||||
DMI is structured as a large table of entries, where
|
||||
each entry has a common header indicating the type and
|
||||
length of the entry, as well as 'handle' that is
|
||||
supposed to be unique amongst all entries.
|
||||
length of the entry, as well as a firmware-provided
|
||||
'handle' that is supposed to be unique amongst all
|
||||
entries.
|
||||
|
||||
Some entries are required by the specification, but many
|
||||
others are optional. In general though, users should
|
||||
never expect to find a specific entry type on their
|
||||
system unless they know for certain what their firmware
|
||||
is doing. Machine to machine will vary.
|
||||
is doing. Machine to machine experiences will vary.
|
||||
|
||||
Multiple entries of the same type are allowed. In order
|
||||
to handle these duplicate entry types, each entry is
|
||||
@@ -67,25 +68,24 @@ Description:
|
||||
and the two terminating nul characters.
|
||||
type : The type of the entry. This value is the same
|
||||
as found in the directory name. It indicates
|
||||
how the rest of the entry should be
|
||||
interpreted.
|
||||
how the rest of the entry should be interpreted.
|
||||
instance: The instance ordinal of the entry for the
|
||||
given type. This value is the same as found
|
||||
in the parent directory name.
|
||||
position: The position of the entry within the entirety
|
||||
of the entirety.
|
||||
position: The ordinal position (zero-based) of the entry
|
||||
within the entirety of the DMI entry table.
|
||||
|
||||
=== Entry Specialization ===
|
||||
|
||||
Some entry types may have other information available in
|
||||
sysfs.
|
||||
sysfs. Not all types are specialized.
|
||||
|
||||
--- Type 15 - System Event Log ---
|
||||
|
||||
This entry allows the firmware to export a log of
|
||||
events the system has taken. This information is
|
||||
typically backed by nvram, but the implementation
|
||||
details are abstracted by this table. This entries data
|
||||
details are abstracted by this table. This entry's data
|
||||
is exported in the directory:
|
||||
|
||||
/sys/firmware/dmi/entries/15-0/system_event_log
|
||||
|
||||
@@ -0,0 +1,58 @@
|
||||
What: /sys/firmware/gsmi
|
||||
Date: March 2011
|
||||
Contact: Mike Waychison <mikew@google.com>
|
||||
Description:
|
||||
Some servers used internally at Google have firmware
|
||||
that provides callback functionality via explicit SMI
|
||||
triggers. Some of the callbacks are similar to those
|
||||
provided by the EFI runtime services page, but due to
|
||||
historical reasons this different entry-point has been
|
||||
used.
|
||||
|
||||
The gsmi driver implements the kernel's abstraction for
|
||||
these firmware callbacks. Currently, this functionality
|
||||
is limited to handling the system event log and getting
|
||||
access to EFI-style variables stored in nvram.
|
||||
|
||||
Layout:
|
||||
|
||||
/sys/firmware/gsmi/vars:
|
||||
|
||||
This directory has the same layout (and
|
||||
underlying implementation as /sys/firmware/efi/vars.
|
||||
See Documentation/ABI/*/sysfs-firmware-efi-vars
|
||||
for more information on how to interact with
|
||||
this structure.
|
||||
|
||||
/sys/firmware/gsmi/append_to_eventlog - write-only:
|
||||
|
||||
This file takes a binary blob and passes it onto
|
||||
the firmware to be timestamped and appended to
|
||||
the system eventlog. The binary format is
|
||||
interpreted by the firmware and may change from
|
||||
platform to platform. The only kernel-enforced
|
||||
requirement is that the blob be prefixed with a
|
||||
32bit host-endian type used as part of the
|
||||
firmware call.
|
||||
|
||||
/sys/firmware/gsmi/clear_config - write-only:
|
||||
|
||||
Writing any value to this file will cause the
|
||||
entire firmware configuration to be reset to
|
||||
"factory defaults". Callers should assume that
|
||||
a reboot is required for the configuration to be
|
||||
cleared.
|
||||
|
||||
/sys/firmware/gsmi/clear_eventlog - write-only:
|
||||
|
||||
This file is used to clear out a portion/the
|
||||
whole of the system event log. Values written
|
||||
should be values between 1 and 100 inclusive (in
|
||||
ASCII) representing the fraction of the log to
|
||||
clear. Not all platforms support fractional
|
||||
clearing though, and this writes to this file
|
||||
will error out if the firmware doesn't like your
|
||||
submitted fraction.
|
||||
|
||||
Callers should assume that a reboot is needed
|
||||
for this operation to complete.
|
||||
@@ -0,0 +1,7 @@
|
||||
What: /sys/firmware/log
|
||||
Date: February 2011
|
||||
Contact: Mike Waychison <mikew@google.com>
|
||||
Description:
|
||||
The /sys/firmware/log is a binary file that represents a
|
||||
read-only copy of the firmware's log if one is
|
||||
available.
|
||||
@@ -0,0 +1,8 @@
|
||||
What: /sys/kernel/fscaps
|
||||
Date: February 2011
|
||||
KernelVersion: 2.6.38
|
||||
Contact: Ludwig Nussel <ludwig.nussel@suse.de>
|
||||
Description
|
||||
Shows whether file system capabilities are honored
|
||||
when executing a binary
|
||||
|
||||
@@ -158,3 +158,17 @@ Description:
|
||||
successful, will make the kernel abort a subsequent transition
|
||||
to a sleep state if any wakeup events are reported after the
|
||||
write has returned.
|
||||
|
||||
What: /sys/power/reserved_size
|
||||
Date: May 2011
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Description:
|
||||
The /sys/power/reserved_size file allows user space to control
|
||||
the amount of memory reserved for allocations made by device
|
||||
drivers during the "device freeze" stage of hibernation. It can
|
||||
be written a string representing a non-negative integer that
|
||||
will be used as the amount of memory to reserve for allocations
|
||||
made by device drivers' "freeze" callbacks, in bytes.
|
||||
|
||||
Reading from this file will display the current value, which is
|
||||
set to 1 MB by default.
|
||||
|
||||
@@ -8,3 +8,4 @@
|
||||
*.dvi
|
||||
*.log
|
||||
*.out
|
||||
media/
|
||||
|
||||
@@ -96,10 +96,10 @@ X!Iinclude/linux/kobject.h
|
||||
|
||||
<chapter id="devdrivers">
|
||||
<title>Device drivers infrastructure</title>
|
||||
<sect1><title>The Basic Device Driver-Model Structures </title>
|
||||
!Iinclude/linux/device.h
|
||||
</sect1>
|
||||
<sect1><title>Device Drivers Base</title>
|
||||
<!--
|
||||
X!Iinclude/linux/device.h
|
||||
-->
|
||||
!Edrivers/base/driver.c
|
||||
!Edrivers/base/core.c
|
||||
!Edrivers/base/class.c
|
||||
|
||||
@@ -34,6 +34,14 @@
|
||||
|
||||
<revhistory>
|
||||
<!-- Put document revisions here, newest first. -->
|
||||
<revision>
|
||||
<revnumber>2.0.4</revnumber>
|
||||
<date>2011-05-06</date>
|
||||
<authorinitials>mcc</authorinitials>
|
||||
<revremark>
|
||||
Add more information about DVB APIv5, better describing the frontend GET/SET props ioctl's.
|
||||
</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>2.0.3</revnumber>
|
||||
<date>2010-07-03</date>
|
||||
|
||||
@@ -1,6 +1,327 @@
|
||||
<section id="FE_GET_PROPERTY">
|
||||
<section id="FE_GET_SET_PROPERTY">
|
||||
<title>FE_GET_PROPERTY/FE_SET_PROPERTY</title>
|
||||
|
||||
<programlisting>
|
||||
/* Reserved fields should be set to 0 */
|
||||
struct dtv_property {
|
||||
__u32 cmd;
|
||||
union {
|
||||
__u32 data;
|
||||
struct {
|
||||
__u8 data[32];
|
||||
__u32 len;
|
||||
__u32 reserved1[3];
|
||||
void *reserved2;
|
||||
} buffer;
|
||||
} u;
|
||||
int result;
|
||||
} __attribute__ ((packed));
|
||||
|
||||
/* num of properties cannot exceed DTV_IOCTL_MAX_MSGS per ioctl */
|
||||
#define DTV_IOCTL_MAX_MSGS 64
|
||||
|
||||
struct dtv_properties {
|
||||
__u32 num;
|
||||
struct dtv_property *props;
|
||||
};
|
||||
</programlisting>
|
||||
|
||||
<section id="FE_GET_PROPERTY">
|
||||
<title>FE_GET_PROPERTY</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl call returns one or more frontend properties. This call only
|
||||
requires read-only access to the device.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request = <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link>,
|
||||
dtv_properties ⋆props);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int num</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link> for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>struct dtv_property *props</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Points to the location where the front-end property commands are stored.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>ERRORS</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row>
|
||||
<entry align="char"><para>EINVAL</para></entry>
|
||||
<entry align="char"><para>Invalid parameter(s) received or number of parameters out of the range.</para></entry>
|
||||
</row><row>
|
||||
<entry align="char"><para>ENOMEM</para></entry>
|
||||
<entry align="char"><para>Out of memory.</para></entry>
|
||||
</row><row>
|
||||
<entry align="char"><para>EFAULT</para></entry>
|
||||
<entry align="char"><para>Failure while copying data from/to userspace.</para></entry>
|
||||
</row><row>
|
||||
<entry align="char"><para>EOPNOTSUPP</para></entry>
|
||||
<entry align="char"><para>Property type not supported.</para></entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="FE_SET_PROPERTY">
|
||||
<title>FE_SET_PROPERTY</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>This ioctl call sets one or more frontend properties. This call only
|
||||
requires read-only access to the device.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>SYNOPSIS
|
||||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request = <link linkend="FE_SET_PROPERTY">FE_SET_PROPERTY</link>,
|
||||
dtv_properties ⋆props);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row><entry align="char">
|
||||
<para>int fd</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>File descriptor returned by a previous call to open().</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>int num</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals <link linkend="FE_SET_PROPERTY">FE_SET_PROPERTY</link> for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
<para>struct dtv_property *props</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Points to the location where the front-end property commands are stored.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>ERRORS
|
||||
</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row>
|
||||
<entry align="char"><para>EINVAL</para></entry>
|
||||
<entry align="char"><para>Invalid parameter(s) received or number of parameters out of the range.</para></entry>
|
||||
</row><row>
|
||||
<entry align="char"><para>ENOMEM</para></entry>
|
||||
<entry align="char"><para>Out of memory.</para></entry>
|
||||
</row><row>
|
||||
<entry align="char"><para>EFAULT</para></entry>
|
||||
<entry align="char"><para>Failure while copying data from/to userspace.</para></entry>
|
||||
</row><row>
|
||||
<entry align="char"><para>EOPNOTSUPP</para></entry>
|
||||
<entry align="char"><para>Property type not supported.</para></entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<para>
|
||||
On <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link>/<link linkend="FE_SET_PROPERTY">FE_SET_PROPERTY</link>,
|
||||
the actual action is determined by the dtv_property cmd/data pairs. With one single ioctl, is possible to
|
||||
get/set up to 64 properties. The actual meaning of each property is described on the next sections.
|
||||
</para>
|
||||
|
||||
<para>The Available frontend property types are:</para>
|
||||
<programlisting>
|
||||
#define DTV_UNDEFINED 0
|
||||
#define DTV_TUNE 1
|
||||
#define DTV_CLEAR 2
|
||||
#define DTV_FREQUENCY 3
|
||||
#define DTV_MODULATION 4
|
||||
#define DTV_BANDWIDTH_HZ 5
|
||||
#define DTV_INVERSION 6
|
||||
#define DTV_DISEQC_MASTER 7
|
||||
#define DTV_SYMBOL_RATE 8
|
||||
#define DTV_INNER_FEC 9
|
||||
#define DTV_VOLTAGE 10
|
||||
#define DTV_TONE 11
|
||||
#define DTV_PILOT 12
|
||||
#define DTV_ROLLOFF 13
|
||||
#define DTV_DISEQC_SLAVE_REPLY 14
|
||||
#define DTV_FE_CAPABILITY_COUNT 15
|
||||
#define DTV_FE_CAPABILITY 16
|
||||
#define DTV_DELIVERY_SYSTEM 17
|
||||
#define DTV_ISDBT_PARTIAL_RECEPTION 18
|
||||
#define DTV_ISDBT_SOUND_BROADCASTING 19
|
||||
#define DTV_ISDBT_SB_SUBCHANNEL_ID 20
|
||||
#define DTV_ISDBT_SB_SEGMENT_IDX 21
|
||||
#define DTV_ISDBT_SB_SEGMENT_COUNT 22
|
||||
#define DTV_ISDBT_LAYERA_FEC 23
|
||||
#define DTV_ISDBT_LAYERA_MODULATION 24
|
||||
#define DTV_ISDBT_LAYERA_SEGMENT_COUNT 25
|
||||
#define DTV_ISDBT_LAYERA_TIME_INTERLEAVING 26
|
||||
#define DTV_ISDBT_LAYERB_FEC 27
|
||||
#define DTV_ISDBT_LAYERB_MODULATION 28
|
||||
#define DTV_ISDBT_LAYERB_SEGMENT_COUNT 29
|
||||
#define DTV_ISDBT_LAYERB_TIME_INTERLEAVING 30
|
||||
#define DTV_ISDBT_LAYERC_FEC 31
|
||||
#define DTV_ISDBT_LAYERC_MODULATION 32
|
||||
#define DTV_ISDBT_LAYERC_SEGMENT_COUNT 33
|
||||
#define DTV_ISDBT_LAYERC_TIME_INTERLEAVING 34
|
||||
#define DTV_API_VERSION 35
|
||||
#define DTV_CODE_RATE_HP 36
|
||||
#define DTV_CODE_RATE_LP 37
|
||||
#define DTV_GUARD_INTERVAL 38
|
||||
#define DTV_TRANSMISSION_MODE 39
|
||||
#define DTV_HIERARCHY 40
|
||||
#define DTV_ISDBT_LAYER_ENABLED 41
|
||||
#define DTV_ISDBS_TS_ID 42
|
||||
</programlisting>
|
||||
|
||||
<section id="fe_property_common">
|
||||
<title>Parameters that are common to all Digital TV standards</title>
|
||||
<section id="DTV_FREQUENCY">
|
||||
<title><constant>DTV_FREQUENCY</constant></title>
|
||||
|
||||
<para>Central frequency of the channel, in HZ.</para>
|
||||
|
||||
<para>Notes:</para>
|
||||
<para>1)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
|
||||
the channel which is 6MHz.</para>
|
||||
|
||||
<para>2)As in ISDB-Tsb the channel consists of only one or three segments the
|
||||
frequency step is 429kHz, 3*429 respectively. As for ISDB-T the
|
||||
central frequency of the channel is expected.</para>
|
||||
</section>
|
||||
|
||||
<section id="DTV_BANDWIDTH_HZ">
|
||||
<title><constant>DTV_BANDWIDTH_HZ</constant></title>
|
||||
|
||||
<para>Bandwidth for the channel, in HZ.</para>
|
||||
|
||||
<para>Possible values:
|
||||
<constant>1712000</constant>,
|
||||
<constant>5000000</constant>,
|
||||
<constant>6000000</constant>,
|
||||
<constant>7000000</constant>,
|
||||
<constant>8000000</constant>,
|
||||
<constant>10000000</constant>.
|
||||
</para>
|
||||
|
||||
<para>Notes:</para>
|
||||
|
||||
<para>1) For ISDB-T it should be always 6000000Hz (6MHz)</para>
|
||||
<para>2) For ISDB-Tsb it can vary depending on the number of connected segments</para>
|
||||
<para>3) Bandwidth doesn't apply for DVB-C transmissions, as the bandwidth
|
||||
for DVB-C depends on the symbol rate</para>
|
||||
<para>4) Bandwidth in ISDB-T is fixed (6MHz) or can be easily derived from
|
||||
other parameters (DTV_ISDBT_SB_SEGMENT_IDX,
|
||||
DTV_ISDBT_SB_SEGMENT_COUNT).</para>
|
||||
<para>5) DVB-T supports 6, 7 and 8MHz.</para>
|
||||
<para>6) In addition, DVB-T2 supports 1.172, 5 and 10MHz.</para>
|
||||
</section>
|
||||
|
||||
<section id="DTV_DELIVERY_SYSTEM">
|
||||
<title><constant>DTV_DELIVERY_SYSTEM</constant></title>
|
||||
|
||||
<para>Specifies the type of Delivery system</para>
|
||||
|
||||
<para>Possible values: </para>
|
||||
<programlisting>
|
||||
typedef enum fe_delivery_system {
|
||||
SYS_UNDEFINED,
|
||||
SYS_DVBC_ANNEX_AC,
|
||||
SYS_DVBC_ANNEX_B,
|
||||
SYS_DVBT,
|
||||
SYS_DSS,
|
||||
SYS_DVBS,
|
||||
SYS_DVBS2,
|
||||
SYS_DVBH,
|
||||
SYS_ISDBT,
|
||||
SYS_ISDBS,
|
||||
SYS_ISDBC,
|
||||
SYS_ATSC,
|
||||
SYS_ATSCMH,
|
||||
SYS_DMBTH,
|
||||
SYS_CMMB,
|
||||
SYS_DAB,
|
||||
SYS_DVBT2,
|
||||
} fe_delivery_system_t;
|
||||
</programlisting>
|
||||
|
||||
</section>
|
||||
|
||||
<section id="DTV_TRANSMISSION_MODE">
|
||||
<title><constant>DTV_TRANSMISSION_MODE</constant></title>
|
||||
|
||||
<para>Specifies the number of carriers used by the standard</para>
|
||||
|
||||
<para>Possible values are:</para>
|
||||
<programlisting>
|
||||
typedef enum fe_transmit_mode {
|
||||
TRANSMISSION_MODE_2K,
|
||||
TRANSMISSION_MODE_8K,
|
||||
TRANSMISSION_MODE_AUTO,
|
||||
TRANSMISSION_MODE_4K,
|
||||
TRANSMISSION_MODE_1K,
|
||||
TRANSMISSION_MODE_16K,
|
||||
TRANSMISSION_MODE_32K,
|
||||
} fe_transmit_mode_t;
|
||||
</programlisting>
|
||||
|
||||
<para>Notes:</para>
|
||||
<para>1) ISDB-T supports three carrier/symbol-size: 8K, 4K, 2K. It is called
|
||||
'mode' in the standard: Mode 1 is 2K, mode 2 is 4K, mode 3 is 8K</para>
|
||||
|
||||
<para>2) If <constant>DTV_TRANSMISSION_MODE</constant> is set the <constant>TRANSMISSION_MODE_AUTO</constant> the
|
||||
hardware will try to find the correct FFT-size (if capable) and will
|
||||
use TMCC to fill in the missing parameters.</para>
|
||||
<para>3) DVB-T specifies 2K and 8K as valid sizes.</para>
|
||||
<para>4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K.</para>
|
||||
</section>
|
||||
|
||||
<section id="DTV_GUARD_INTERVAL">
|
||||
<title><constant>DTV_GUARD_INTERVAL</constant></title>
|
||||
|
||||
<para>Possible values are:</para>
|
||||
<programlisting>
|
||||
typedef enum fe_guard_interval {
|
||||
GUARD_INTERVAL_1_32,
|
||||
GUARD_INTERVAL_1_16,
|
||||
GUARD_INTERVAL_1_8,
|
||||
GUARD_INTERVAL_1_4,
|
||||
GUARD_INTERVAL_AUTO,
|
||||
GUARD_INTERVAL_1_128,
|
||||
GUARD_INTERVAL_19_128,
|
||||
GUARD_INTERVAL_19_256,
|
||||
} fe_guard_interval_t;
|
||||
</programlisting>
|
||||
|
||||
<para>Notes:</para>
|
||||
<para>1) If <constant>DTV_GUARD_INTERVAL</constant> is set the <constant>GUARD_INTERVAL_AUTO</constant> the hardware will
|
||||
try to find the correct guard interval (if capable) and will use TMCC to fill
|
||||
in the missing parameters.</para>
|
||||
<para>2) Intervals 1/128, 19/128 and 19/256 are used only for DVB-T2 at present</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id="isdbt">
|
||||
<title>ISDB-T frontend</title>
|
||||
<para>This section describes shortly what are the possible parameters in the Linux
|
||||
@@ -32,73 +353,6 @@
|
||||
|
||||
<para>Parameters used by ISDB-T and ISDB-Tsb.</para>
|
||||
|
||||
<section id="isdbt-parms">
|
||||
<title>Parameters that are common with DVB-T and ATSC</title>
|
||||
|
||||
<section id="isdbt-freq">
|
||||
<title><constant>DTV_FREQUENCY</constant></title>
|
||||
|
||||
<para>Central frequency of the channel.</para>
|
||||
|
||||
<para>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
|
||||
the channel which is 6MHz.</para>
|
||||
|
||||
<para>As in ISDB-Tsb the channel consists of only one or three segments the
|
||||
frequency step is 429kHz, 3*429 respectively. As for ISDB-T the
|
||||
central frequency of the channel is expected.</para>
|
||||
</section>
|
||||
|
||||
<section id="isdbt-bw">
|
||||
<title><constant>DTV_BANDWIDTH_HZ</constant> (optional)</title>
|
||||
|
||||
<para>Possible values:</para>
|
||||
|
||||
<para>For ISDB-T it should be always 6000000Hz (6MHz)</para>
|
||||
<para>For ISDB-Tsb it can vary depending on the number of connected segments</para>
|
||||
|
||||
<para>Note: Hardware specific values might be given here, but standard
|
||||
applications should not bother to set a value to this field as
|
||||
standard demods are ignoring it anyway.</para>
|
||||
|
||||
<para>Bandwidth in ISDB-T is fixed (6MHz) or can be easily derived from
|
||||
other parameters (DTV_ISDBT_SB_SEGMENT_IDX,
|
||||
DTV_ISDBT_SB_SEGMENT_COUNT).</para>
|
||||
</section>
|
||||
|
||||
<section id="isdbt-delivery-sys">
|
||||
<title><constant>DTV_DELIVERY_SYSTEM</constant></title>
|
||||
|
||||
<para>Possible values: <constant>SYS_ISDBT</constant></para>
|
||||
</section>
|
||||
|
||||
<section id="isdbt-tx-mode">
|
||||
<title><constant>DTV_TRANSMISSION_MODE</constant></title>
|
||||
|
||||
<para>ISDB-T supports three carrier/symbol-size: 8K, 4K, 2K. It is called
|
||||
'mode' in the standard: Mode 1 is 2K, mode 2 is 4K, mode 3 is 8K</para>
|
||||
|
||||
<para>Possible values: <constant>TRANSMISSION_MODE_2K</constant>, <constant>TRANSMISSION_MODE_8K</constant>,
|
||||
<constant>TRANSMISSION_MODE_AUTO</constant>, <constant>TRANSMISSION_MODE_4K</constant></para>
|
||||
|
||||
<para>If <constant>DTV_TRANSMISSION_MODE</constant> is set the <constant>TRANSMISSION_MODE_AUTO</constant> the
|
||||
hardware will try to find the correct FFT-size (if capable) and will
|
||||
use TMCC to fill in the missing parameters.</para>
|
||||
|
||||
<para><constant>TRANSMISSION_MODE_4K</constant> is added at the same time as the other new parameters.</para>
|
||||
</section>
|
||||
|
||||
<section id="isdbt-guard-interval">
|
||||
<title><constant>DTV_GUARD_INTERVAL</constant></title>
|
||||
|
||||
<para>Possible values: <constant>GUARD_INTERVAL_1_32</constant>, <constant>GUARD_INTERVAL_1_16</constant>, <constant>GUARD_INTERVAL_1_8</constant>,
|
||||
<constant>GUARD_INTERVAL_1_4</constant>, <constant>GUARD_INTERVAL_AUTO</constant></para>
|
||||
|
||||
<para>If <constant>DTV_GUARD_INTERVAL</constant> is set the <constant>GUARD_INTERVAL_AUTO</constant> the hardware will
|
||||
try to find the correct guard interval (if capable) and will use TMCC to fill
|
||||
in the missing parameters.</para>
|
||||
</section>
|
||||
</section>
|
||||
<section id="isdbt-new-parms">
|
||||
<title>ISDB-T only parameters</title>
|
||||
|
||||
@@ -314,5 +568,20 @@
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
<section id="dvbt2-params">
|
||||
<title>DVB-T2 parameters</title>
|
||||
|
||||
<para>This section covers parameters that apply only to the DVB-T2 delivery method. DVB-T2
|
||||
support is currently in the early stages development so expect this section to grow
|
||||
and become more detailed with time.</para>
|
||||
|
||||
<section id="dvbt2-plp-id">
|
||||
<title><constant>DTV_DVBT2_PLP_ID</constant></title>
|
||||
|
||||
<para>DVB-T2 supports Physical Layer Pipes (PLP) to allow transmission of
|
||||
many data types via a single multiplex. The API will soon support this
|
||||
at which point this section will be expanded.</para>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
@@ -176,14 +176,20 @@ typedef enum fe_transmit_mode {
|
||||
TRANSMISSION_MODE_2K,
|
||||
TRANSMISSION_MODE_8K,
|
||||
TRANSMISSION_MODE_AUTO,
|
||||
TRANSMISSION_MODE_4K
|
||||
TRANSMISSION_MODE_4K,
|
||||
TRANSMISSION_MODE_1K,
|
||||
TRANSMISSION_MODE_16K,
|
||||
TRANSMISSION_MODE_32K,
|
||||
} fe_transmit_mode_t;
|
||||
|
||||
typedef enum fe_bandwidth {
|
||||
BANDWIDTH_8_MHZ,
|
||||
BANDWIDTH_7_MHZ,
|
||||
BANDWIDTH_6_MHZ,
|
||||
BANDWIDTH_AUTO
|
||||
BANDWIDTH_AUTO,
|
||||
BANDWIDTH_5_MHZ,
|
||||
BANDWIDTH_10_MHZ,
|
||||
BANDWIDTH_1_712_MHZ,
|
||||
} fe_bandwidth_t;
|
||||
|
||||
|
||||
@@ -192,7 +198,10 @@ typedef enum fe_guard_interval {
|
||||
GUARD_INTERVAL_1_16,
|
||||
GUARD_INTERVAL_1_8,
|
||||
GUARD_INTERVAL_1_4,
|
||||
GUARD_INTERVAL_AUTO
|
||||
GUARD_INTERVAL_AUTO,
|
||||
GUARD_INTERVAL_1_128,
|
||||
GUARD_INTERVAL_19_128,
|
||||
GUARD_INTERVAL_19_256,
|
||||
} fe_guard_interval_t;
|
||||
|
||||
|
||||
@@ -306,7 +315,9 @@ struct dvb_frontend_event {
|
||||
|
||||
#define DTV_ISDBS_TS_ID 42
|
||||
|
||||
#define DTV_MAX_COMMAND DTV_ISDBS_TS_ID
|
||||
#define DTV_DVBT2_PLP_ID 43
|
||||
|
||||
#define DTV_MAX_COMMAND DTV_DVBT2_PLP_ID
|
||||
|
||||
typedef enum fe_pilot {
|
||||
PILOT_ON,
|
||||
@@ -338,6 +349,7 @@ typedef enum fe_delivery_system {
|
||||
SYS_DMBTH,
|
||||
SYS_CMMB,
|
||||
SYS_DAB,
|
||||
SYS_DVBT2,
|
||||
} fe_delivery_system_t;
|
||||
|
||||
struct dtv_cmds_h {
|
||||
|
||||
@@ -191,8 +191,8 @@
|
||||
<para>
|
||||
Whenever an interrupt triggers, the lowlevel arch code calls into
|
||||
the generic interrupt code by calling desc->handle_irq().
|
||||
This highlevel IRQ handling function only uses desc->chip primitives
|
||||
referenced by the assigned chip descriptor structure.
|
||||
This highlevel IRQ handling function only uses desc->irq_data.chip
|
||||
primitives referenced by the assigned chip descriptor structure.
|
||||
</para>
|
||||
</sect1>
|
||||
<sect1 id="Highlevel_Driver_API">
|
||||
@@ -206,11 +206,11 @@
|
||||
<listitem><para>enable_irq()</para></listitem>
|
||||
<listitem><para>disable_irq_nosync() (SMP only)</para></listitem>
|
||||
<listitem><para>synchronize_irq() (SMP only)</para></listitem>
|
||||
<listitem><para>set_irq_type()</para></listitem>
|
||||
<listitem><para>set_irq_wake()</para></listitem>
|
||||
<listitem><para>set_irq_data()</para></listitem>
|
||||
<listitem><para>set_irq_chip()</para></listitem>
|
||||
<listitem><para>set_irq_chip_data()</para></listitem>
|
||||
<listitem><para>irq_set_irq_type()</para></listitem>
|
||||
<listitem><para>irq_set_irq_wake()</para></listitem>
|
||||
<listitem><para>irq_set_handler_data()</para></listitem>
|
||||
<listitem><para>irq_set_chip()</para></listitem>
|
||||
<listitem><para>irq_set_chip_data()</para></listitem>
|
||||
</itemizedlist>
|
||||
See the autogenerated function documentation for details.
|
||||
</para>
|
||||
@@ -225,6 +225,8 @@
|
||||
<listitem><para>handle_fasteoi_irq</para></listitem>
|
||||
<listitem><para>handle_simple_irq</para></listitem>
|
||||
<listitem><para>handle_percpu_irq</para></listitem>
|
||||
<listitem><para>handle_edge_eoi_irq</para></listitem>
|
||||
<listitem><para>handle_bad_irq</para></listitem>
|
||||
</itemizedlist>
|
||||
The interrupt flow handlers (either predefined or architecture
|
||||
specific) are assigned to specific interrupts by the architecture
|
||||
@@ -241,13 +243,13 @@
|
||||
<programlisting>
|
||||
default_enable(struct irq_data *data)
|
||||
{
|
||||
desc->chip->irq_unmask(data);
|
||||
desc->irq_data.chip->irq_unmask(data);
|
||||
}
|
||||
|
||||
default_disable(struct irq_data *data)
|
||||
{
|
||||
if (!delay_disable(data))
|
||||
desc->chip->irq_mask(data);
|
||||
desc->irq_data.chip->irq_mask(data);
|
||||
}
|
||||
|
||||
default_ack(struct irq_data *data)
|
||||
@@ -284,9 +286,9 @@ noop(struct irq_data *data))
|
||||
<para>
|
||||
The following control flow is implemented (simplified excerpt):
|
||||
<programlisting>
|
||||
desc->chip->irq_mask();
|
||||
handle_IRQ_event(desc->action);
|
||||
desc->chip->irq_unmask();
|
||||
desc->irq_data.chip->irq_mask_ack();
|
||||
handle_irq_event(desc->action);
|
||||
desc->irq_data.chip->irq_unmask();
|
||||
</programlisting>
|
||||
</para>
|
||||
</sect3>
|
||||
@@ -300,8 +302,8 @@ desc->chip->irq_unmask();
|
||||
<para>
|
||||
The following control flow is implemented (simplified excerpt):
|
||||
<programlisting>
|
||||
handle_IRQ_event(desc->action);
|
||||
desc->chip->irq_eoi();
|
||||
handle_irq_event(desc->action);
|
||||
desc->irq_data.chip->irq_eoi();
|
||||
</programlisting>
|
||||
</para>
|
||||
</sect3>
|
||||
@@ -315,17 +317,17 @@ desc->chip->irq_eoi();
|
||||
The following control flow is implemented (simplified excerpt):
|
||||
<programlisting>
|
||||
if (desc->status & running) {
|
||||
desc->chip->irq_mask();
|
||||
desc->irq_data.chip->irq_mask_ack();
|
||||
desc->status |= pending | masked;
|
||||
return;
|
||||
}
|
||||
desc->chip->irq_ack();
|
||||
desc->irq_data.chip->irq_ack();
|
||||
desc->status |= running;
|
||||
do {
|
||||
if (desc->status & masked)
|
||||
desc->chip->irq_unmask();
|
||||
desc->irq_data.chip->irq_unmask();
|
||||
desc->status &= ~pending;
|
||||
handle_IRQ_event(desc->action);
|
||||
handle_irq_event(desc->action);
|
||||
} while (status & pending);
|
||||
desc->status &= ~running;
|
||||
</programlisting>
|
||||
@@ -344,7 +346,7 @@ desc->status &= ~running;
|
||||
<para>
|
||||
The following control flow is implemented (simplified excerpt):
|
||||
<programlisting>
|
||||
handle_IRQ_event(desc->action);
|
||||
handle_irq_event(desc->action);
|
||||
</programlisting>
|
||||
</para>
|
||||
</sect3>
|
||||
@@ -362,12 +364,29 @@ handle_IRQ_event(desc->action);
|
||||
<para>
|
||||
The following control flow is implemented (simplified excerpt):
|
||||
<programlisting>
|
||||
handle_IRQ_event(desc->action);
|
||||
if (desc->chip->irq_eoi)
|
||||
desc->chip->irq_eoi();
|
||||
if (desc->irq_data.chip->irq_ack)
|
||||
desc->irq_data.chip->irq_ack();
|
||||
handle_irq_event(desc->action);
|
||||
if (desc->irq_data.chip->irq_eoi)
|
||||
desc->irq_data.chip->irq_eoi();
|
||||
</programlisting>
|
||||
</para>
|
||||
</sect3>
|
||||
<sect3 id="EOI_Edge_IRQ_flow_handler">
|
||||
<title>EOI Edge IRQ flow handler</title>
|
||||
<para>
|
||||
handle_edge_eoi_irq provides an abnomination of the edge
|
||||
handler which is solely used to tame a badly wreckaged
|
||||
irq controller on powerpc/cell.
|
||||
</para>
|
||||
</sect3>
|
||||
<sect3 id="BAD_IRQ_flow_handler">
|
||||
<title>Bad IRQ flow handler</title>
|
||||
<para>
|
||||
handle_bad_irq is used for spurious interrupts which
|
||||
have no real handler assigned..
|
||||
</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
<sect2 id="Quirks_and_optimizations">
|
||||
<title>Quirks and optimizations</title>
|
||||
@@ -410,6 +429,7 @@ if (desc->chip->irq_eoi)
|
||||
<listitem><para>irq_mask_ack() - Optional, recommended for performance</para></listitem>
|
||||
<listitem><para>irq_mask()</para></listitem>
|
||||
<listitem><para>irq_unmask()</para></listitem>
|
||||
<listitem><para>irq_eoi() - Optional, required for eoi flow handlers</para></listitem>
|
||||
<listitem><para>irq_retrigger() - Optional</para></listitem>
|
||||
<listitem><para>irq_set_type() - Optional</para></listitem>
|
||||
<listitem><para>irq_set_wake() - Optional</para></listitem>
|
||||
@@ -424,32 +444,24 @@ if (desc->chip->irq_eoi)
|
||||
<chapter id="doirq">
|
||||
<title>__do_IRQ entry point</title>
|
||||
<para>
|
||||
The original implementation __do_IRQ() is an alternative entry
|
||||
point for all types of interrupts.
|
||||
The original implementation __do_IRQ() was an alternative entry
|
||||
point for all types of interrupts. It not longer exists.
|
||||
</para>
|
||||
<para>
|
||||
This handler turned out to be not suitable for all
|
||||
interrupt hardware and was therefore reimplemented with split
|
||||
functionality for egde/level/simple/percpu interrupts. This is not
|
||||
functionality for edge/level/simple/percpu interrupts. This is not
|
||||
only a functional optimization. It also shortens code paths for
|
||||
interrupts.
|
||||
</para>
|
||||
<para>
|
||||
To make use of the split implementation, replace the call to
|
||||
__do_IRQ by a call to desc->handle_irq() and associate
|
||||
the appropriate handler function to desc->handle_irq().
|
||||
In most cases the generic handler implementations should
|
||||
be sufficient.
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="locking">
|
||||
<title>Locking on SMP</title>
|
||||
<para>
|
||||
The locking of chip registers is up to the architecture that
|
||||
defines the chip primitives. There is a chip->lock field that can be used
|
||||
for serialization, but the generic layer does not touch it. The per-irq
|
||||
structure is protected via desc->lock, by the generic layer.
|
||||
defines the chip primitives. The per-irq structure is
|
||||
protected via desc->lock, by the generic layer.
|
||||
</para>
|
||||
</chapter>
|
||||
<chapter id="structs">
|
||||
|
||||
@@ -270,6 +270,7 @@
|
||||
<!ENTITY sub-write SYSTEM "v4l/func-write.xml">
|
||||
<!ENTITY sub-io SYSTEM "v4l/io.xml">
|
||||
<!ENTITY sub-grey SYSTEM "v4l/pixfmt-grey.xml">
|
||||
<!ENTITY sub-m420 SYSTEM "v4l/pixfmt-m420.xml">
|
||||
<!ENTITY sub-nv12 SYSTEM "v4l/pixfmt-nv12.xml">
|
||||
<!ENTITY sub-nv12m SYSTEM "v4l/pixfmt-nv12m.xml">
|
||||
<!ENTITY sub-nv12mt SYSTEM "v4l/pixfmt-nv12mt.xml">
|
||||
@@ -294,6 +295,8 @@
|
||||
<!ENTITY sub-srggb10 SYSTEM "v4l/pixfmt-srggb10.xml">
|
||||
<!ENTITY sub-srggb8 SYSTEM "v4l/pixfmt-srggb8.xml">
|
||||
<!ENTITY sub-y10 SYSTEM "v4l/pixfmt-y10.xml">
|
||||
<!ENTITY sub-y12 SYSTEM "v4l/pixfmt-y12.xml">
|
||||
<!ENTITY sub-y10b SYSTEM "v4l/pixfmt-y10b.xml">
|
||||
<!ENTITY sub-pixfmt SYSTEM "v4l/pixfmt.xml">
|
||||
<!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml">
|
||||
<!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">
|
||||
|
||||
@@ -34,7 +34,7 @@
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>MEDIA_IOC_ENUM_LINKS</para>
|
||||
<para>MEDIA_IOC_SETUP_LINK</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user