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 'mvebu/drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Merge the mvebu/drivers branch of the arm-soc tree which contains
just a single patch bfa1ce5f38 ("bus:
mvebu-mbus: add mv_mbus_dram_info_nooverlap()") that happens to be
a prerequisite of the new marvell/cesa crypto driver.
This commit is contained in:
Herbert Xu
@@ -24,6 +24,7 @@
|
||||
*.order
|
||||
*.elf
|
||||
*.bin
|
||||
*.tar
|
||||
*.gz
|
||||
*.bz2
|
||||
*.lzma
|
||||
|
||||
@@ -2049,6 +2049,10 @@ D: pirq addr, CS5535 alsa audio driver
|
||||
S: Gurgaon, India
|
||||
S: Kuala Lumpur, Malaysia
|
||||
|
||||
N: Mohit Kumar
|
||||
D: ST Microelectronics SPEAr13xx PCI host bridge driver
|
||||
D: Synopsys Designware PCI host bridge driver
|
||||
|
||||
N: Gabor Kuti
|
||||
M: seasons@falcon.sch.bme.hu
|
||||
M: seasons@makosteszta.sote.hu
|
||||
|
||||
@@ -23,3 +23,25 @@ Description: Device-mapper device suspend state.
|
||||
Contains the value 1 while the device is suspended.
|
||||
Otherwise it contains 0. Read-only attribute.
|
||||
Users: util-linux, device-mapper udev rules
|
||||
|
||||
What: /sys/block/dm-<num>/dm/rq_based_seq_io_merge_deadline
|
||||
Date: March 2015
|
||||
KernelVersion: 4.1
|
||||
Contact: dm-devel@redhat.com
|
||||
Description: Allow control over how long a request that is a
|
||||
reasonable merge candidate can be queued on the request
|
||||
queue. The resolution of this deadline is in
|
||||
microseconds (ranging from 1 to 100000 usecs).
|
||||
Setting this attribute to 0 (the default) will disable
|
||||
request-based DM's merge heuristic and associated extra
|
||||
accounting. This attribute is not applicable to
|
||||
bio-based DM devices so it will only ever report 0 for
|
||||
them.
|
||||
|
||||
What: /sys/block/dm-<num>/dm/use_blk_mq
|
||||
Date: March 2015
|
||||
KernelVersion: 4.1
|
||||
Contact: dm-devel@redhat.com
|
||||
Description: Request-based Device-mapper blk-mq I/O path mode.
|
||||
Contains the value 1 if the device is using blk-mq.
|
||||
Otherwise it contains 0. Read-only attribute.
|
||||
|
||||
@@ -100,7 +100,7 @@ Description: read only
|
||||
Hexadecimal value of the device ID found in this AFU
|
||||
configuration record.
|
||||
|
||||
What: /sys/class/cxl/<afu>/cr<config num>/vendor
|
||||
What: /sys/class/cxl/<afu>/cr<config num>/class
|
||||
Date: February 2015
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read only
|
||||
|
||||
@@ -222,3 +222,13 @@ Description:
|
||||
The number of blocks that are marked as reserved, if any, in
|
||||
this partition. These are typically used to store the in-flash
|
||||
bad block table (BBT).
|
||||
|
||||
What: /sys/class/mtd/mtdX/offset
|
||||
Date: March 2015
|
||||
KernelVersion: 4.1
|
||||
Contact: linux-mtd@lists.infradead.org
|
||||
Description:
|
||||
For a partition, the offset of that partition from the start
|
||||
of the master device in bytes. This attribute is absent on
|
||||
main devices, so it can be used to distinguish between
|
||||
partitions and devices that aren't partitions.
|
||||
|
||||
@@ -8,9 +8,11 @@ Description: This file controls the keyboard backlight operation mode, valid
|
||||
* 0x2 -> AUTO (also called TIMER)
|
||||
* 0x8 -> ON
|
||||
* 0x10 -> OFF
|
||||
Note that the kernel 3.16 onwards this file accepts all listed
|
||||
Note that from kernel 3.16 onwards this file accepts all listed
|
||||
parameters, kernel 3.15 only accepts the first two (FN-Z and
|
||||
AUTO).
|
||||
Also note that toggling this value on type 1 devices, requires
|
||||
a reboot for changes to take effect.
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_backlight_timeout
|
||||
@@ -67,15 +69,72 @@ Description: This file shows the current keyboard backlight type,
|
||||
* 2 -> Type 2, supporting modes TIMER, ON and OFF
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_sleep_charge
|
||||
Date: January 23, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls the USB Sleep & Charge charging mode, which
|
||||
can be:
|
||||
* 0 -> Disabled (0x00)
|
||||
* 1 -> Alternate (0x09)
|
||||
* 2 -> Auto (0x21)
|
||||
* 3 -> Typical (0x11)
|
||||
Note that from kernel 4.1 onwards this file accepts all listed
|
||||
values, kernel 4.0 only supports the first three.
|
||||
Note that this feature only works when connected to power, if
|
||||
you want to use it under battery, see the entry named
|
||||
"sleep_functions_on_battery"
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/sleep_functions_on_battery
|
||||
Date: January 23, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls the USB Sleep Functions under battery, and
|
||||
set the level at which point they will be disabled, accepted
|
||||
values can be:
|
||||
* 0 -> Disabled
|
||||
* 1-100 -> Battery level to disable sleep functions
|
||||
Currently it prints two values, the first one indicates if the
|
||||
feature is enabled or disabled, while the second one shows the
|
||||
current battery level set.
|
||||
Note that when the value is set to disabled, the sleep function
|
||||
will only work when connected to power.
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_rapid_charge
|
||||
Date: January 23, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls the USB Rapid Charge state, which can be:
|
||||
* 0 -> Disabled
|
||||
* 1 -> Enabled
|
||||
Note that toggling this value requires a reboot for changes to
|
||||
take effect.
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_sleep_music
|
||||
Date: January 23, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls the Sleep & Music state, which values can be:
|
||||
* 0 -> Disabled
|
||||
* 1 -> Enabled
|
||||
Note that this feature only works when connected to power, if
|
||||
you want to use it under battery, see the entry named
|
||||
"sleep_functions_on_battery"
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/version
|
||||
Date: February, 2015
|
||||
KernelVersion: 3.20
|
||||
Date: February 12, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file shows the current version of the driver
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/fan
|
||||
Date: February, 2015
|
||||
KernelVersion: 3.20
|
||||
Date: February 12, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls the state of the internal fan, valid
|
||||
values are:
|
||||
@@ -83,8 +142,8 @@ Description: This file controls the state of the internal fan, valid
|
||||
* 1 -> ON
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_function_keys
|
||||
Date: February, 2015
|
||||
KernelVersion: 3.20
|
||||
Date: February 12, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls the Special Functions (hotkeys) operation
|
||||
mode, valid values are:
|
||||
@@ -94,21 +153,29 @@ Description: This file controls the Special Functions (hotkeys) operation
|
||||
and the hotkeys are accessed via FN-F{1-12}.
|
||||
In the "Special Functions" mode, the F{1-12} keys trigger the
|
||||
hotkey and the F{1-12} keys are accessed via FN-F{1-12}.
|
||||
Note that toggling this value requires a reboot for changes to
|
||||
take effect.
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/panel_power_on
|
||||
Date: February, 2015
|
||||
KernelVersion: 3.20
|
||||
Date: February 12, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls whether the laptop should turn ON whenever
|
||||
the LID is opened, valid values are:
|
||||
* 0 -> Disabled
|
||||
* 1 -> Enabled
|
||||
Note that toggling this value requires a reboot for changes to
|
||||
take effect.
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_three
|
||||
Date: February, 2015
|
||||
KernelVersion: 3.20
|
||||
Date: February 12, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls whether the USB 3 functionality, valid
|
||||
values are:
|
||||
Description: This file controls the USB 3 functionality, valid values are:
|
||||
* 0 -> Disabled (Acts as a regular USB 2)
|
||||
* 1 -> Enabled (Full USB 3 functionality)
|
||||
Note that toggling this value requires a reboot for changes to
|
||||
take effect.
|
||||
Users: KToshiba
|
||||
|
||||
@@ -0,0 +1,69 @@
|
||||
What: /sys/class/leds/dell::kbd_backlight/als_enabled
|
||||
Date: December 2014
|
||||
KernelVersion: 3.19
|
||||
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
|
||||
Pali Rohár <pali.rohar@gmail.com>
|
||||
Description:
|
||||
This file allows to control the automatic keyboard
|
||||
illumination mode on some systems that have an ambient
|
||||
light sensor. Write 1 to this file to enable the auto
|
||||
mode, 0 to disable it.
|
||||
|
||||
What: /sys/class/leds/dell::kbd_backlight/als_setting
|
||||
Date: December 2014
|
||||
KernelVersion: 3.19
|
||||
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
|
||||
Pali Rohár <pali.rohar@gmail.com>
|
||||
Description:
|
||||
This file allows to specifiy the on/off threshold value,
|
||||
as reported by the ambient light sensor.
|
||||
|
||||
What: /sys/class/leds/dell::kbd_backlight/start_triggers
|
||||
Date: December 2014
|
||||
KernelVersion: 3.19
|
||||
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
|
||||
Pali Rohár <pali.rohar@gmail.com>
|
||||
Description:
|
||||
This file allows to control the input triggers that
|
||||
turn on the keyboard backlight illumination that is
|
||||
disabled because of inactivity.
|
||||
Read the file to see the triggers available. The ones
|
||||
enabled are preceded by '+', those disabled by '-'.
|
||||
|
||||
To enable a trigger, write its name preceded by '+' to
|
||||
this file. To disable a trigger, write its name preceded
|
||||
by '-' instead.
|
||||
|
||||
For example, to enable the keyboard as trigger run:
|
||||
echo +keyboard > /sys/class/leds/dell::kbd_backlight/start_triggers
|
||||
To disable it:
|
||||
echo -keyboard > /sys/class/leds/dell::kbd_backlight/start_triggers
|
||||
|
||||
Note that not all the available triggers can be configured.
|
||||
|
||||
What: /sys/class/leds/dell::kbd_backlight/stop_timeout
|
||||
Date: December 2014
|
||||
KernelVersion: 3.19
|
||||
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
|
||||
Pali Rohár <pali.rohar@gmail.com>
|
||||
Description:
|
||||
This file allows to specify the interval after which the
|
||||
keyboard illumination is disabled because of inactivity.
|
||||
The timeouts are expressed in seconds, minutes, hours and
|
||||
days, for which the symbols are 's', 'm', 'h' and 'd'
|
||||
respectively.
|
||||
|
||||
To configure the timeout, write to this file a value along
|
||||
with any the above units. If no unit is specified, the value
|
||||
is assumed to be expressed in seconds.
|
||||
|
||||
For example, to set the timeout to 10 minutes run:
|
||||
echo 10m > /sys/class/leds/dell::kbd_backlight/stop_timeout
|
||||
|
||||
Note that when this file is read, the returned value might be
|
||||
expressed in a different unit than the one used when the timeout
|
||||
was set.
|
||||
|
||||
Also note that only some timeouts are supported and that
|
||||
some systems might fall back to a specific timeout in case
|
||||
an invalid timeout is written to this file.
|
||||
+87
-71
@@ -13,7 +13,7 @@ and NOT read it. Burn them, it's a great symbolic gesture.
|
||||
Anyway, here goes:
|
||||
|
||||
|
||||
Chapter 1: Indentation
|
||||
Chapter 1: Indentation
|
||||
|
||||
Tabs are 8 characters, and thus indentations are also 8 characters.
|
||||
There are heretic movements that try to make indentations 4 (or even 2!)
|
||||
@@ -56,7 +56,6 @@ instead of "double-indenting" the "case" labels. E.g.:
|
||||
break;
|
||||
}
|
||||
|
||||
|
||||
Don't put multiple statements on a single line unless you have
|
||||
something to hide:
|
||||
|
||||
@@ -156,25 +155,25 @@ comments on.
|
||||
|
||||
Do not unnecessarily use braces where a single statement will do.
|
||||
|
||||
if (condition)
|
||||
action();
|
||||
if (condition)
|
||||
action();
|
||||
|
||||
and
|
||||
|
||||
if (condition)
|
||||
do_this();
|
||||
else
|
||||
do_that();
|
||||
if (condition)
|
||||
do_this();
|
||||
else
|
||||
do_that();
|
||||
|
||||
This does not apply if only one branch of a conditional statement is a single
|
||||
statement; in the latter case use braces in both branches:
|
||||
|
||||
if (condition) {
|
||||
do_this();
|
||||
do_that();
|
||||
} else {
|
||||
otherwise();
|
||||
}
|
||||
if (condition) {
|
||||
do_this();
|
||||
do_that();
|
||||
} else {
|
||||
otherwise();
|
||||
}
|
||||
|
||||
3.1: Spaces
|
||||
|
||||
@@ -186,8 +185,11 @@ although they are not required in the language, as in: "sizeof info" after
|
||||
"struct fileinfo info;" is declared).
|
||||
|
||||
So use a space after these keywords:
|
||||
|
||||
if, switch, case, for, do, while
|
||||
|
||||
but not with sizeof, typeof, alignof, or __attribute__. E.g.,
|
||||
|
||||
s = sizeof(struct file);
|
||||
|
||||
Do not add spaces around (inside) parenthesized expressions. This example is
|
||||
@@ -209,12 +211,15 @@ such as any of these:
|
||||
= + - < > * / % | & ^ <= >= == != ? :
|
||||
|
||||
but no space after unary operators:
|
||||
|
||||
& * + - ~ ! sizeof typeof alignof __attribute__ defined
|
||||
|
||||
no space before the postfix increment & decrement unary operators:
|
||||
|
||||
++ --
|
||||
|
||||
no space after the prefix increment & decrement unary operators:
|
||||
|
||||
++ --
|
||||
|
||||
and no space around the '.' and "->" structure member operators.
|
||||
@@ -268,13 +273,11 @@ See chapter 6 (Functions).
|
||||
Chapter 5: Typedefs
|
||||
|
||||
Please don't use things like "vps_t".
|
||||
|
||||
It's a _mistake_ to use typedef for structures and pointers. When you see a
|
||||
|
||||
vps_t a;
|
||||
|
||||
in the source, what does it mean?
|
||||
|
||||
In contrast, if it says
|
||||
|
||||
struct virtual_container *a;
|
||||
@@ -372,11 +375,11 @@ In source files, separate functions with one blank line. If the function is
|
||||
exported, the EXPORT* macro for it should follow immediately after the closing
|
||||
function brace line. E.g.:
|
||||
|
||||
int system_is_up(void)
|
||||
{
|
||||
return system_state == SYSTEM_RUNNING;
|
||||
}
|
||||
EXPORT_SYMBOL(system_is_up);
|
||||
int system_is_up(void)
|
||||
{
|
||||
return system_state == SYSTEM_RUNNING;
|
||||
}
|
||||
EXPORT_SYMBOL(system_is_up);
|
||||
|
||||
In function prototypes, include parameter names with their data types.
|
||||
Although this is not required by the C language, it is preferred in Linux
|
||||
@@ -405,34 +408,34 @@ The rationale for using gotos is:
|
||||
modifications are prevented
|
||||
- saves the compiler work to optimize redundant code away ;)
|
||||
|
||||
int fun(int a)
|
||||
{
|
||||
int result = 0;
|
||||
char *buffer;
|
||||
int fun(int a)
|
||||
{
|
||||
int result = 0;
|
||||
char *buffer;
|
||||
|
||||
buffer = kmalloc(SIZE, GFP_KERNEL);
|
||||
if (!buffer)
|
||||
return -ENOMEM;
|
||||
buffer = kmalloc(SIZE, GFP_KERNEL);
|
||||
if (!buffer)
|
||||
return -ENOMEM;
|
||||
|
||||
if (condition1) {
|
||||
while (loop1) {
|
||||
...
|
||||
if (condition1) {
|
||||
while (loop1) {
|
||||
...
|
||||
}
|
||||
result = 1;
|
||||
goto out_buffer;
|
||||
}
|
||||
result = 1;
|
||||
goto out_buffer;
|
||||
...
|
||||
out_buffer:
|
||||
kfree(buffer);
|
||||
return result;
|
||||
}
|
||||
...
|
||||
out_buffer:
|
||||
kfree(buffer);
|
||||
return result;
|
||||
}
|
||||
|
||||
A common type of bug to be aware of it "one err bugs" which look like this:
|
||||
|
||||
err:
|
||||
kfree(foo->bar);
|
||||
kfree(foo);
|
||||
return ret;
|
||||
err:
|
||||
kfree(foo->bar);
|
||||
kfree(foo);
|
||||
return ret;
|
||||
|
||||
The bug in this code is that on some exit paths "foo" is NULL. Normally the
|
||||
fix for this is to split it up into two error labels "err_bar:" and "err_foo:".
|
||||
@@ -503,9 +506,9 @@ values. To do the latter, you can stick the following in your .emacs file:
|
||||
(defun c-lineup-arglist-tabs-only (ignored)
|
||||
"Line up argument lists by tabs, not spaces"
|
||||
(let* ((anchor (c-langelem-pos c-syntactic-element))
|
||||
(column (c-langelem-2nd-pos c-syntactic-element))
|
||||
(offset (- (1+ column) anchor))
|
||||
(steps (floor offset c-basic-offset)))
|
||||
(column (c-langelem-2nd-pos c-syntactic-element))
|
||||
(offset (- (1+ column) anchor))
|
||||
(steps (floor offset c-basic-offset)))
|
||||
(* (max steps 1)
|
||||
c-basic-offset)))
|
||||
|
||||
@@ -612,7 +615,7 @@ have a reference count on it, you almost certainly have a bug.
|
||||
|
||||
Names of macros defining constants and labels in enums are capitalized.
|
||||
|
||||
#define CONSTANT 0x12345
|
||||
#define CONSTANT 0x12345
|
||||
|
||||
Enums are preferred when defining several related constants.
|
||||
|
||||
@@ -623,28 +626,28 @@ Generally, inline functions are preferable to macros resembling functions.
|
||||
|
||||
Macros with multiple statements should be enclosed in a do - while block:
|
||||
|
||||
#define macrofun(a, b, c) \
|
||||
do { \
|
||||
if (a == 5) \
|
||||
do_this(b, c); \
|
||||
} while (0)
|
||||
#define macrofun(a, b, c) \
|
||||
do { \
|
||||
if (a == 5) \
|
||||
do_this(b, c); \
|
||||
} while (0)
|
||||
|
||||
Things to avoid when using macros:
|
||||
|
||||
1) macros that affect control flow:
|
||||
|
||||
#define FOO(x) \
|
||||
do { \
|
||||
if (blah(x) < 0) \
|
||||
return -EBUGGERED; \
|
||||
} while(0)
|
||||
#define FOO(x) \
|
||||
do { \
|
||||
if (blah(x) < 0) \
|
||||
return -EBUGGERED; \
|
||||
} while(0)
|
||||
|
||||
is a _very_ bad idea. It looks like a function call but exits the "calling"
|
||||
function; don't break the internal parsers of those who will read the code.
|
||||
|
||||
2) macros that depend on having a local variable with a magic name:
|
||||
|
||||
#define FOO(val) bar(index, val)
|
||||
#define FOO(val) bar(index, val)
|
||||
|
||||
might look like a good thing, but it's confusing as hell when one reads the
|
||||
code and it's prone to breakage from seemingly innocent changes.
|
||||
@@ -656,8 +659,21 @@ bite you if somebody e.g. turns FOO into an inline function.
|
||||
must enclose the expression in parentheses. Beware of similar issues with
|
||||
macros using parameters.
|
||||
|
||||
#define CONSTANT 0x4000
|
||||
#define CONSTEXP (CONSTANT | 3)
|
||||
#define CONSTANT 0x4000
|
||||
#define CONSTEXP (CONSTANT | 3)
|
||||
|
||||
5) namespace collisions when defining local variables in macros resembling
|
||||
functions:
|
||||
|
||||
#define FOO(x) \
|
||||
({ \
|
||||
typeof(x) ret; \
|
||||
ret = calc_ret(x); \
|
||||
(ret); \
|
||||
)}
|
||||
|
||||
ret is a common name for a local variable - __foo_ret is less likely
|
||||
to collide with an existing variable.
|
||||
|
||||
The cpp manual deals with macros exhaustively. The gcc internals manual also
|
||||
covers RTL which is used frequently with assembly language in the kernel.
|
||||
@@ -796,11 +812,11 @@ you should use, rather than explicitly coding some variant of them yourself.
|
||||
For example, if you need to calculate the length of an array, take advantage
|
||||
of the macro
|
||||
|
||||
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
|
||||
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
|
||||
|
||||
Similarly, if you need to calculate the size of some structure member, use
|
||||
|
||||
#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
|
||||
#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
|
||||
|
||||
There are also min() and max() macros that do strict type checking if you
|
||||
need them. Feel free to peruse that header file to see what else is already
|
||||
@@ -813,19 +829,19 @@ Some editors can interpret configuration information embedded in source files,
|
||||
indicated with special markers. For example, emacs interprets lines marked
|
||||
like this:
|
||||
|
||||
-*- mode: c -*-
|
||||
-*- mode: c -*-
|
||||
|
||||
Or like this:
|
||||
|
||||
/*
|
||||
Local Variables:
|
||||
compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c"
|
||||
End:
|
||||
*/
|
||||
/*
|
||||
Local Variables:
|
||||
compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c"
|
||||
End:
|
||||
*/
|
||||
|
||||
Vim interprets markers that look like this:
|
||||
|
||||
/* vim:set sw=8 noet */
|
||||
/* vim:set sw=8 noet */
|
||||
|
||||
Do not include any of these in source files. People have their own personal
|
||||
editor configurations, and your source files should not override them. This
|
||||
@@ -902,9 +918,9 @@ At the end of any non-trivial #if or #ifdef block (more than a few lines),
|
||||
place a comment after the #endif on the same line, noting the conditional
|
||||
expression used. For instance:
|
||||
|
||||
#ifdef CONFIG_SOMETHING
|
||||
...
|
||||
#endif /* CONFIG_SOMETHING */
|
||||
#ifdef CONFIG_SOMETHING
|
||||
...
|
||||
#endif /* CONFIG_SOMETHING */
|
||||
|
||||
|
||||
Appendix I: References
|
||||
|
||||
@@ -1293,7 +1293,7 @@ int max_width, max_height;</synopsis>
|
||||
</para>
|
||||
<para>
|
||||
If a page flip can be successfully scheduled the driver must set the
|
||||
<code>drm_crtc-<fb</code> field to the new framebuffer pointed to
|
||||
<code>drm_crtc->fb</code> field to the new framebuffer pointed to
|
||||
by <code>fb</code>. This is important so that the reference counting
|
||||
on framebuffers stays balanced.
|
||||
</para>
|
||||
@@ -3979,6 +3979,11 @@ int num_ioctls;</synopsis>
|
||||
!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts
|
||||
!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Intel GVT-g Guest Support(vGPU)</title>
|
||||
!Pdrivers/gpu/drm/i915/i915_vgpu.c Intel GVT-g guest support
|
||||
!Idrivers/gpu/drm/i915/i915_vgpu.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1>
|
||||
<title>Display Hardware Handling</title>
|
||||
@@ -4046,6 +4051,17 @@ int num_ioctls;</synopsis>
|
||||
<title>Frame Buffer Compression (FBC)</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_fbc.c Frame Buffer Compression (FBC)
|
||||
!Idrivers/gpu/drm/i915/intel_fbc.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Display Refresh Rate Switching (DRRS)</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_dp.c Display Refresh Rate Switching (DRRS)
|
||||
!Fdrivers/gpu/drm/i915/intel_dp.c intel_dp_set_drrs_state
|
||||
!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_enable
|
||||
!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_disable
|
||||
!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_invalidate
|
||||
!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_flush
|
||||
!Fdrivers/gpu/drm/i915/intel_dp.c intel_dp_drrs_init
|
||||
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>DPIO</title>
|
||||
@@ -4168,7 +4184,7 @@ int num_ioctls;</synopsis>
|
||||
<sect2>
|
||||
<title>Buffer Object Eviction</title>
|
||||
<para>
|
||||
This section documents the interface function for evicting buffer
|
||||
This section documents the interface functions for evicting buffer
|
||||
objects to make space available in the virtual gpu address spaces.
|
||||
Note that this is mostly orthogonal to shrinking buffer objects
|
||||
caches, which has the goal to make main memory (shared with the gpu
|
||||
@@ -4176,6 +4192,17 @@ int num_ioctls;</synopsis>
|
||||
</para>
|
||||
!Idrivers/gpu/drm/i915/i915_gem_evict.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Buffer Object Memory Shrinking</title>
|
||||
<para>
|
||||
This section documents the interface function for shrinking memory
|
||||
usage of buffer object caches. Shrinking is used to make main memory
|
||||
available. Note that this is mostly orthogonal to evicting buffer
|
||||
objects, which has the goal to make space in gpu virtual address
|
||||
spaces.
|
||||
</para>
|
||||
!Idrivers/gpu/drm/i915/i915_gem_shrinker.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
|
||||
@@ -1,14 +1,13 @@
|
||||
<bibliography>
|
||||
<title>References</title>
|
||||
|
||||
<biblioentry id="eia608">
|
||||
<abbrev>EIA 608-B</abbrev>
|
||||
<biblioentry id="cea608">
|
||||
<abbrev>CEA 608-E</abbrev>
|
||||
<authorgroup>
|
||||
<corpauthor>Electronic Industries Alliance (<ulink
|
||||
url="http://www.eia.org">http://www.eia.org</ulink>)</corpauthor>
|
||||
<corpauthor>Consumer Electronics Association (<ulink
|
||||
url="http://www.ce.org">http://www.ce.org</ulink>)</corpauthor>
|
||||
</authorgroup>
|
||||
<title>EIA 608-B "Recommended Practice for Line 21 Data
|
||||
Service"</title>
|
||||
<title>CEA-608-E R-2014 "Line 21 Data Services"</title>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="en300294">
|
||||
|
||||
@@ -2491,7 +2491,7 @@ that used it. It was originally scheduled for removal in 2.6.35.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control event
|
||||
changes flag. See <xref linkend="changes-flags"/>.</para>
|
||||
changes flag. See <xref linkend="ctrl-changes-flags"/>.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
@@ -254,7 +254,7 @@ ETS 300 231, lsb first transmitted.</entry>
|
||||
<row>
|
||||
<entry><constant>V4L2_SLICED_CAPTION_525</constant></entry>
|
||||
<entry>0x1000</entry>
|
||||
<entry><xref linkend="eia608" /></entry>
|
||||
<entry><xref linkend="cea608" /></entry>
|
||||
<entry>NTSC line 21, 284 (second field 21)</entry>
|
||||
<entry>Two bytes in transmission order, including parity
|
||||
bit, lsb first transmitted.</entry>
|
||||
|
||||
@@ -143,86 +143,28 @@
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>struct</entry>
|
||||
<entry><structfield>v4l</structfield></entry>
|
||||
<entry><structfield>dev</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Valid for V4L sub-devices and nodes only.</entry>
|
||||
<entry>Valid for (sub-)devices that create a single device node.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>major</structfield></entry>
|
||||
<entry>V4L device node major number. For V4L sub-devices with no
|
||||
device node, set by the driver to 0.</entry>
|
||||
<entry>Device node major number.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>minor</structfield></entry>
|
||||
<entry>V4L device node minor number. For V4L sub-devices with no
|
||||
device node, set by the driver to 0.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>struct</entry>
|
||||
<entry><structfield>fb</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Valid for frame buffer nodes only.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>major</structfield></entry>
|
||||
<entry>Frame buffer device node major number.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>minor</structfield></entry>
|
||||
<entry>Frame buffer device node minor number.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>struct</entry>
|
||||
<entry><structfield>alsa</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Valid for ALSA devices only.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>card</structfield></entry>
|
||||
<entry>ALSA card number</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>device</structfield></entry>
|
||||
<entry>ALSA device number</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>subdevice</structfield></entry>
|
||||
<entry>ALSA sub-device number</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>int</entry>
|
||||
<entry><structfield>dvb</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>DVB card number</entry>
|
||||
<entry>Device node minor number.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>raw</structfield>[180]</entry>
|
||||
<entry><structfield>raw</structfield>[184]</entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
@@ -253,8 +195,24 @@
|
||||
<entry>ALSA card</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB</constant></entry>
|
||||
<entry>DVB card</entry>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_FE</constant></entry>
|
||||
<entry>DVB frontend devnode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DEMUX</constant></entry>
|
||||
<entry>DVB demux devnode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DVR</constant></entry>
|
||||
<entry>DVB DVR devnode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_CA</constant></entry>
|
||||
<entry>DVB CAM devnode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_NET</constant></entry>
|
||||
<entry>DVB network devnode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV</constant></entry>
|
||||
@@ -282,6 +240,10 @@
|
||||
it in some digital video standard, with appropriate embedded timing
|
||||
signals.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_TUNER</constant></entry>
|
||||
<entry>TV and/or radio tuner</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
@@ -303,45 +303,6 @@ for a pixel lie next to each other in memory.</para>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-BGR666">
|
||||
<entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
|
||||
<entry>'BGRH'</entry>
|
||||
<entry></entry>
|
||||
<entry>b<subscript>5</subscript></entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
<entry>r<subscript>5</subscript></entry>
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-BGR24">
|
||||
<entry><constant>V4L2_PIX_FMT_BGR24</constant></entry>
|
||||
<entry>'BGR3'</entry>
|
||||
@@ -404,6 +365,46 @@ for a pixel lie next to each other in memory.</para>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-BGR666">
|
||||
<entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
|
||||
<entry>'BGRH'</entry>
|
||||
<entry></entry>
|
||||
<entry>b<subscript>5</subscript></entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
<entry>r<subscript>5</subscript></entry>
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry></entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-ABGR32">
|
||||
<entry><constant>V4L2_PIX_FMT_ABGR32</constant></entry>
|
||||
<entry>'AR24'</entry>
|
||||
|
||||
@@ -38,10 +38,10 @@ columns and rows.</para>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 4:</entry>
|
||||
<entry>R<subscript>10</subscript></entry>
|
||||
<entry>B<subscript>11</subscript></entry>
|
||||
<entry>R<subscript>12</subscript></entry>
|
||||
<entry>B<subscript>13</subscript></entry>
|
||||
<entry>B<subscript>10</subscript></entry>
|
||||
<entry>G<subscript>11</subscript></entry>
|
||||
<entry>B<subscript>12</subscript></entry>
|
||||
<entry>G<subscript>13</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 8:</entry>
|
||||
@@ -52,10 +52,10 @@ columns and rows.</para>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 12:</entry>
|
||||
<entry>R<subscript>30</subscript></entry>
|
||||
<entry>B<subscript>31</subscript></entry>
|
||||
<entry>R<subscript>32</subscript></entry>
|
||||
<entry>B<subscript>33</subscript></entry>
|
||||
<entry>B<subscript>30</subscript></entry>
|
||||
<entry>G<subscript>31</subscript></entry>
|
||||
<entry>B<subscript>32</subscript></entry>
|
||||
<entry>G<subscript>33</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
||||
@@ -38,7 +38,7 @@
|
||||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte.
|
||||
<informaltable frame="topbot" colsep="1" rowsep="1">
|
||||
<tgroup cols="5" align="center" border="1">
|
||||
<tgroup cols="5" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
|
||||
@@ -29,12 +29,12 @@ and Cr planes have half as many pad bytes after their rows. In other
|
||||
words, two Cx rows (including padding) is exactly as long as one Y row
|
||||
(including padding).</para>
|
||||
|
||||
<para><constant>V4L2_PIX_FMT_NV12M</constant> is intended to be
|
||||
<para><constant>V4L2_PIX_FMT_YUV420M</constant> is intended to be
|
||||
used only in drivers and applications that support the multi-planar API,
|
||||
described in <xref linkend="planar-apis"/>. </para>
|
||||
|
||||
<example>
|
||||
<title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 × 4
|
||||
<title><constant>V4L2_PIX_FMT_YUV420M</constant> 4 × 4
|
||||
pixel image</title>
|
||||
|
||||
<formalpara>
|
||||
|
||||
@@ -80,9 +80,9 @@ padding bytes after the last line of an image cross a system page
|
||||
boundary. Input devices may write padding bytes, the value is
|
||||
undefined. Output devices ignore the contents of padding
|
||||
bytes.</para><para>When the image format is planar the
|
||||
<structfield>bytesperline</structfield> value applies to the largest
|
||||
<structfield>bytesperline</structfield> value applies to the first
|
||||
plane and is divided by the same factor as the
|
||||
<structfield>width</structfield> field for any smaller planes. For
|
||||
<structfield>width</structfield> field for the other planes. For
|
||||
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
|
||||
@@ -182,14 +182,14 @@ see <xref linkend="colorspaces" />.</entry>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u16</entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>bytesperline</structfield></entry>
|
||||
<entry>Distance in bytes between the leftmost pixels in two adjacent
|
||||
lines. See &v4l2-pix-format;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u16</entry>
|
||||
<entry><structfield>reserved[7]</structfield></entry>
|
||||
<entry><structfield>reserved[6]</structfield></entry>
|
||||
<entry>Reserved for future extensions. Should be zeroed by the
|
||||
application.</entry>
|
||||
</row>
|
||||
@@ -483,8 +483,8 @@ is the Y'CbCr encoding identifier (&v4l2-ycbcr-encoding;) to specify non-standar
|
||||
Y'CbCr encodings and the third is the quantization identifier (&v4l2-quantization;)
|
||||
to specify non-standard quantization methods. Most of the time only the colorspace
|
||||
field of &v4l2-pix-format; or &v4l2-pix-format-mplane; needs to be filled in. Note
|
||||
that the default R'G'B' quantization is always full range for all colorspaces,
|
||||
so this won't be mentioned explicitly for each colorspace description.</para>
|
||||
that the default R'G'B' quantization is full range for all colorspaces except for
|
||||
BT.2020 which uses limited range R'G'B' quantization.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-colorspace">
|
||||
<title>V4L2 Colorspaces</title>
|
||||
@@ -598,7 +598,8 @@ so this won't be mentioned explicitly for each colorspace description.</para>
|
||||
<row>
|
||||
<entry><constant>V4L2_QUANTIZATION_DEFAULT</constant></entry>
|
||||
<entry>Use the default quantization encoding as defined by the colorspace.
|
||||
This is always full range for R'G'B' and usually limited range for Y'CbCr.</entry>
|
||||
This is always full range for R'G'B' (except for the BT.2020 colorspace) and usually
|
||||
limited range for Y'CbCr.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_QUANTIZATION_FULL_RANGE</constant></entry>
|
||||
@@ -620,8 +621,8 @@ is mapped to [16…235]. Cb and Cr are mapped from [-0.5…0.5] to [16
|
||||
|
||||
<section>
|
||||
<title>Detailed Colorspace Descriptions</title>
|
||||
<section>
|
||||
<title id="col-smpte-170m">Colorspace SMPTE 170M (<constant>V4L2_COLORSPACE_SMPTE170M</constant>)</title>
|
||||
<section id="col-smpte-170m">
|
||||
<title>Colorspace SMPTE 170M (<constant>V4L2_COLORSPACE_SMPTE170M</constant>)</title>
|
||||
<para>The <xref linkend="smpte170m" /> standard defines the colorspace used by NTSC and PAL and by SDTV
|
||||
in general. The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_601</constant>.
|
||||
The default Y'CbCr quantization is limited range. The chromaticities of the primary colors and
|
||||
@@ -666,8 +667,7 @@ as the SMPTE C set, so this colorspace is sometimes called SMPTE C as well.</par
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>The transfer function defined for SMPTE 170M is the same as the
|
||||
one defined in Rec. 709. Normally L is in the range [0…1], but for the extended
|
||||
gamut xvYCC encoding values outside that range are allowed.</term>
|
||||
one defined in Rec. 709.</term>
|
||||
<listitem>
|
||||
<para>L' = -1.099(-L)<superscript>0.45</superscript> + 0.099 for L ≤ -0.018</para>
|
||||
<para>L' = 4.5L for -0.018 < L < 0.018</para>
|
||||
@@ -702,29 +702,10 @@ defined in the <xref linkend="itu601" /> standard and this colorspace is sometim
|
||||
though BT.601 does not mention any color primaries.</para>
|
||||
<para>The default quantization is limited range, but full range is possible although
|
||||
rarely seen.</para>
|
||||
<para>The <constant>V4L2_YCBCR_ENC_601</constant> encoding as described above is the
|
||||
default for this colorspace, but it can be overridden with <constant>V4L2_YCBCR_ENC_709</constant>,
|
||||
in which case the Rec. 709 Y'CbCr encoding is used.</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>The xvYCC 601 encoding (<constant>V4L2_YCBCR_ENC_XV601</constant>, <xref linkend="xvycc" />) is similar
|
||||
to the BT.601 encoding, but it allows for R', G' and B' values that are outside the range
|
||||
[0…1]. The resulting Y', Cb and Cr values are scaled and offset:</term>
|
||||
<listitem>
|
||||
<para>Y' = (219 / 255) * (0.299R' + 0.587G' + 0.114B') + (16 / 255)</para>
|
||||
<para>Cb = (224 / 255) * (-0.169R' - 0.331G' + 0.5B')</para>
|
||||
<para>Cr = (224 / 255) * (0.5R' - 0.419G' - 0.081B')</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<para>Y' is clamped to the range [0…1] and Cb and Cr are clamped
|
||||
to the range [-0.5…0.5]. The non-standard xvYCC 709 encoding can also be used by selecting
|
||||
<constant>V4L2_YCBCR_ENC_XV709</constant>. The xvYCC encodings always use full range
|
||||
quantization.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-rec709">Colorspace Rec. 709 (<constant>V4L2_COLORSPACE_REC709</constant>)</title>
|
||||
<section id="col-rec709">
|
||||
<title>Colorspace Rec. 709 (<constant>V4L2_COLORSPACE_REC709</constant>)</title>
|
||||
<para>The <xref linkend="itu709" /> standard defines the colorspace used by HDTV in general. The default
|
||||
Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_709</constant>. The default Y'CbCr quantization is
|
||||
limited range. The chromaticities of the primary colors and the white reference are:</para>
|
||||
@@ -803,26 +784,39 @@ rarely seen.</para>
|
||||
<para>The <constant>V4L2_YCBCR_ENC_709</constant> encoding described above is the default
|
||||
for this colorspace, but it can be overridden with <constant>V4L2_YCBCR_ENC_601</constant>, in which
|
||||
case the BT.601 Y'CbCr encoding is used.</para>
|
||||
<para>Two additional extended gamut Y'CbCr encodings are also possible with this colorspace:</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>The xvYCC 709 encoding (<constant>V4L2_YCBCR_ENC_XV709</constant>, <xref linkend="xvycc" />)
|
||||
is similar to the Rec. 709 encoding, but it allows for R', G' and B' values that are outside the range
|
||||
[0…1]. The resulting Y', Cb and Cr values are scaled and offset:</term>
|
||||
<listitem>
|
||||
<para>Y' = (219 / 255) * (0.2126R' + 0.7152G' + 0.0722B') + (16 / 255)</para>
|
||||
<para>Cb = (224 / 255) * (-0.1146R' - 0.3854G' + 0.5B')</para>
|
||||
<para>Cr = (224 / 255) * (0.5R' - 0.4542G' - 0.0458B')</para>
|
||||
<para>Y' = (219 / 256) * (0.2126R' + 0.7152G' + 0.0722B') + (16 / 256)</para>
|
||||
<para>Cb = (224 / 256) * (-0.1146R' - 0.3854G' + 0.5B')</para>
|
||||
<para>Cr = (224 / 256) * (0.5R' - 0.4542G' - 0.0458B')</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>The xvYCC 601 encoding (<constant>V4L2_YCBCR_ENC_XV601</constant>, <xref linkend="xvycc" />) is similar
|
||||
to the BT.601 encoding, but it allows for R', G' and B' values that are outside the range
|
||||
[0…1]. The resulting Y', Cb and Cr values are scaled and offset:</term>
|
||||
<listitem>
|
||||
<para>Y' = (219 / 256) * (0.299R' + 0.587G' + 0.114B') + (16 / 256)</para>
|
||||
<para>Cb = (224 / 256) * (-0.169R' - 0.331G' + 0.5B')</para>
|
||||
<para>Cr = (224 / 256) * (0.5R' - 0.419G' - 0.081B')</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<para>Y' is clamped to the range [0…1] and Cb and Cr are clamped
|
||||
to the range [-0.5…0.5]. The non-standard xvYCC 601 encoding can also be used by
|
||||
selecting <constant>V4L2_YCBCR_ENC_XV601</constant>. The xvYCC encodings always use full
|
||||
range quantization.</para>
|
||||
to the range [-0.5…0.5]. The non-standard xvYCC 709 or xvYCC 601 encodings can be used by
|
||||
selecting <constant>V4L2_YCBCR_ENC_XV709</constant> or <constant>V4L2_YCBCR_ENC_XV601</constant>.
|
||||
The xvYCC encodings always use full range quantization.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-srgb">Colorspace sRGB (<constant>V4L2_COLORSPACE_SRGB</constant>)</title>
|
||||
<section id="col-srgb">
|
||||
<title>Colorspace sRGB (<constant>V4L2_COLORSPACE_SRGB</constant>)</title>
|
||||
<para>The <xref linkend="srgb" /> standard defines the colorspace used by most webcams and computer graphics. The
|
||||
default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_SYCC</constant>. The default Y'CbCr quantization
|
||||
is full range. The chromaticities of the primary colors and the white reference are:</para>
|
||||
@@ -898,8 +892,8 @@ encoding, it is not. The <constant>V4L2_YCBCR_ENC_XV601</constant> scales and of
|
||||
values before quantization, but this encoding does not do that.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-adobergb">Colorspace Adobe RGB (<constant>V4L2_COLORSPACE_ADOBERGB</constant>)</title>
|
||||
<section id="col-adobergb">
|
||||
<title>Colorspace Adobe RGB (<constant>V4L2_COLORSPACE_ADOBERGB</constant>)</title>
|
||||
<para>The <xref linkend="adobergb" /> standard defines the colorspace used by computer graphics
|
||||
that use the AdobeRGB colorspace. This is also known as the <xref linkend="oprgb" /> standard.
|
||||
The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_601</constant>. The default Y'CbCr
|
||||
@@ -970,12 +964,12 @@ clamped to the range [-0.5…0.5]. This transform is identical to one defin
|
||||
SMPTE 170M/BT.601. The Y'CbCr quantization is limited range.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-bt2020">Colorspace BT.2020 (<constant>V4L2_COLORSPACE_BT2020</constant>)</title>
|
||||
<section id="col-bt2020">
|
||||
<title>Colorspace BT.2020 (<constant>V4L2_COLORSPACE_BT2020</constant>)</title>
|
||||
<para>The <xref linkend="itu2020" /> standard defines the colorspace used by Ultra-high definition
|
||||
television (UHDTV). The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_BT2020</constant>.
|
||||
The default Y'CbCr quantization is limited range. The chromaticities of the primary colors and
|
||||
the white reference are:</para>
|
||||
The default R'G'B' quantization is limited range (!), and so is the default Y'CbCr quantization.
|
||||
The chromaticities of the primary colors and the white reference are:</para>
|
||||
<table frame="none">
|
||||
<title>BT.2020 Chromaticities</title>
|
||||
<tgroup cols="3" align="left">
|
||||
@@ -1032,7 +1026,7 @@ the white reference are:</para>
|
||||
<term>The luminance (Y') and color difference (Cb and Cr) are obtained with the
|
||||
following <constant>V4L2_YCBCR_ENC_BT2020</constant> encoding:</term>
|
||||
<listitem>
|
||||
<para>Y' = 0.2627R' + 0.6789G' + 0.0593B'</para>
|
||||
<para>Y' = 0.2627R' + 0.6780G' + 0.0593B'</para>
|
||||
<para>Cb = -0.1396R' - 0.3604G' + 0.5B'</para>
|
||||
<para>Cr = 0.5R' - 0.4598G' - 0.0402B'</para>
|
||||
</listitem>
|
||||
@@ -1046,7 +1040,7 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
||||
<varlistentry>
|
||||
<term>Luma:</term>
|
||||
<listitem>
|
||||
<para>Yc' = (0.2627R + 0.6789G + 0.0593B)'</para>
|
||||
<para>Yc' = (0.2627R + 0.6780G + 0.0593B)'</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
@@ -1054,7 +1048,7 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
||||
<varlistentry>
|
||||
<term>B' - Yc' ≤ 0:</term>
|
||||
<listitem>
|
||||
<para>Cbc = (B' - Y') / 1.9404</para>
|
||||
<para>Cbc = (B' - Yc') / 1.9404</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
@@ -1062,7 +1056,7 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
||||
<varlistentry>
|
||||
<term>B' - Yc' > 0:</term>
|
||||
<listitem>
|
||||
<para>Cbc = (B' - Y') / 1.5816</para>
|
||||
<para>Cbc = (B' - Yc') / 1.5816</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
@@ -1086,8 +1080,8 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
||||
clamped to the range [-0.5…0.5]. The Yc'CbcCrc quantization is limited range.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-smpte-240m">Colorspace SMPTE 240M (<constant>V4L2_COLORSPACE_SMPTE240M</constant>)</title>
|
||||
<section id="col-smpte-240m">
|
||||
<title>Colorspace SMPTE 240M (<constant>V4L2_COLORSPACE_SMPTE240M</constant>)</title>
|
||||
<para>The <xref linkend="smpte240m" /> standard was an interim standard used during the early days of HDTV (1988-1998).
|
||||
It has been superseded by Rec. 709. The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_SMPTE240M</constant>.
|
||||
The default Y'CbCr quantization is limited range. The chromaticities of the primary colors and the
|
||||
@@ -1159,8 +1153,8 @@ following <constant>V4L2_YCBCR_ENC_SMPTE240M</constant> encoding:</term>
|
||||
clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-sysm">Colorspace NTSC 1953 (<constant>V4L2_COLORSPACE_470_SYSTEM_M</constant>)</title>
|
||||
<section id="col-sysm">
|
||||
<title>Colorspace NTSC 1953 (<constant>V4L2_COLORSPACE_470_SYSTEM_M</constant>)</title>
|
||||
<para>This standard defines the colorspace used by NTSC in 1953. In practice this
|
||||
colorspace is obsolete and SMPTE 170M should be used instead. The default Y'CbCr encoding
|
||||
is <constant>V4L2_YCBCR_ENC_601</constant>. The default Y'CbCr quantization is limited range.
|
||||
@@ -1237,8 +1231,8 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
||||
This transform is identical to one defined in SMPTE 170M/BT.601.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-sysbg">Colorspace EBU Tech. 3213 (<constant>V4L2_COLORSPACE_470_SYSTEM_BG</constant>)</title>
|
||||
<section id="col-sysbg">
|
||||
<title>Colorspace EBU Tech. 3213 (<constant>V4L2_COLORSPACE_470_SYSTEM_BG</constant>)</title>
|
||||
<para>The <xref linkend="tech3213" /> standard defines the colorspace used by PAL/SECAM in 1975. In practice this
|
||||
colorspace is obsolete and SMPTE 170M should be used instead. The default Y'CbCr encoding
|
||||
is <constant>V4L2_YCBCR_ENC_601</constant>. The default Y'CbCr quantization is limited range.
|
||||
@@ -1311,8 +1305,8 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
||||
This transform is identical to one defined in SMPTE 170M/BT.601.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-jpeg">Colorspace JPEG (<constant>V4L2_COLORSPACE_JPEG</constant>)</title>
|
||||
<section id="col-jpeg">
|
||||
<title>Colorspace JPEG (<constant>V4L2_COLORSPACE_JPEG</constant>)</title>
|
||||
<para>This colorspace defines the colorspace used by most (Motion-)JPEG formats. The chromaticities
|
||||
of the primary colors and the white reference are identical to sRGB. The Y'CbCr encoding is
|
||||
<constant>V4L2_YCBCR_ENC_601</constant> with full range quantization where
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -136,6 +136,7 @@ Remote Controller chapter.</contrib>
|
||||
<year>2012</year>
|
||||
<year>2013</year>
|
||||
<year>2014</year>
|
||||
<year>2015</year>
|
||||
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
|
||||
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab,
|
||||
Pawel Osciak</holder>
|
||||
@@ -151,6 +152,14 @@ 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.21</revnumber>
|
||||
<date>2015-02-13</date>
|
||||
<authorinitials>mcc</authorinitials>
|
||||
<revremark>Fix documentation for media controller device nodes and add support for DVB device nodes.
|
||||
Add support for Tuner sub-device.
|
||||
</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>3.19</revnumber>
|
||||
<date>2014-12-05</date>
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user