asgardius/android_kernel_motorola_sm6225
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git

Browse source 
Conflicts:
	include/net/bluetooth/l2cap.h
	net/bluetooth/hci_conn.c
	net/bluetooth/l2cap_core.c
This commit is contained in:
Johan Hedberg 2012-02-16 14:23:04 +02:00
commit 46479e6985
2623 changed files with 108618 additions and 44881 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
CREDITS
View file

@ -514,6 +514,11 @@ S: Bessemerstraat 21
S: Amsterdam
S: The Netherlands
N: NeilBrown
E: neil@brown.name
P: 4096R/566281B9 1BC6 29EB D390 D870 7B5F 497A 39EC 9EDD 5662 81B9
D: NFSD Maintainer 2000-2007
N: Zach Brown
E: zab@zabbo.net
D: maestro pci sound

16
Documentation/ABI/testing/sysfs-module
View file

@ -33,3 +33,19 @@ Description: Maximum time allowed for periodic transfers per microframe (μs)
Beware, non-standard modes are usually not thoroughly tested by
hardware designers, and the hardware can malfunction when this
setting differ from default 100.
What: /sys/module/*/{coresize,initsize}
Date: Jan 2012
KernelVersion:»·3.3
Contact: Kay Sievers <kay.sievers@vrfy.org>
Description: Module size in bytes.
What: /sys/module/*/taint
Date: Jan 2012
KernelVersion:»·3.3
Contact: Kay Sievers <kay.sievers@vrfy.org>
Description: Module taint flags:
P - proprietary module
O - out-of-tree module
F - force-loaded module
C - staging driver module

5
Documentation/DocBook/device-drivers.tmpl
View file

@ -50,7 +50,9 @@
<sect1><title>Delaying, scheduling, and timer routines</title>
!Iinclude/linux/sched.h
!Ekernel/sched.c
!Ekernel/sched/core.c
!Ikernel/sched/cpupri.c
!Ikernel/sched/fair.c
!Iinclude/linux/completion.h
!Ekernel/timer.c
</sect1>
@ -216,7 +218,6 @@ X!Isound/sound_firmware.c
<chapter id="uart16x50">
<title>16x50 UART Driver</title>
!Iinclude/linux/serial_core.h
!Edrivers/tty/serial/serial_core.c
!Edrivers/tty/serial/8250.c
</chapter>

2
Documentation/DocBook/deviceiobook.tmpl
View file

@ -317,7 +317,7 @@ CPU B: spin_unlock_irqrestore(&amp;dev_lock, flags)
<chapter id="pubfunctions">
<title>Public Functions Provided</title>
!Iarch/x86/include/asm/io.h
!Elib/iomap.c
!Elib/pci_iomap.c
</chapter>
</book>

59
Documentation/DocBook/media/constraints.png.b64 Normal file
View file

@ -0,0 +1,59 @@
iVBORw0KGgoAAAANSUhEUgAAAlQAAAFYCAYAAACVsmLPAAAAAXNSR0IArs4c6QAAAAZiS0dEAP8A
/wD/oL2nkwAAAAlwSFlzAAAOxAAADsQBlSsOGwAAAAd0SU1FB9sLCBIAKVtZsMAAAAxxSURBVHja
7d3ZbqvIAkDRLsv//8v0QytXvpYZap7Wko56OAnE2AXbBSbhOI7jHwAAkr1sAgAAQQUAIKgAAAQV
AICgAgBAUAEACCoAAEEFACCoAAAQVAAAzb2jvyMEWw0AmFvh37xnhgoAQFABAPT1zvruwtNlAADV
VLxsyQwVAICgAgAQVAAAggoAQFABACCoYEohuFkugKACsmLq178DIKiAyJgSVQCCCigQU6IKQFAB
BWJKVAEIKqBgKIkqAEEFFAgkUQUgqIACYSSqAAQViKkwxjIAEFSwbUyJKgBBBWJq8GUCIKhgm5gS
VQCCCsSUqAIQVMBYoSOqAAQVLOk41lwXAIIKhoqqJyFUYhkACCpYMqpiQqjEMgAQVLBUVKWEUIll
ACCoYImoygmhEssAQFDBElHVexkACCoAAEEFACCoAAAQVAAAggoAQFABAAgqAAAEFQCAoAIAEFQA
AIIKAABBBQAgqAAABBUAgKACAOA/b5sAGjsO2wBgMWaoAAAEFQCAoAIAEFQAADtzUXohIQQbAYDi
Dh9kmYIZKgAAQQUAIKgAAAQVAICgAgAgmU/5VeSTGQDE8InxeZmhAgAQVAAAggoAQFABAAgqAAAE
FQCAoAIAEFQAAHtyY0/o4O7efe4JCzAXM1QAAIIKAEBQAQAIKgAAQQUAgKACABBUAACCCgBAUAEA
IKgAAAQVAICgAgAQVAAACCoAAEEFACCoAAAEFVBICGMsAwBBBVPHVE4QlVgGAIIKpo6ps/9utQwA
BBUsEVMpQVRiGQAIKlgqpmKCqMQyABBUsGRMzbouAAQVNHMca64LAEEFy0WVmAIQVCCqxBSAoAL6
hI+YAhBUIKrEFICgAvqEkJgCEFQgqo4+3wuAoILto0pMAQgqICOQxBSAoAIyQklMAQgqICOYxBSA
oAIyokpMAQgqICOqxBTAvN42AYwTVQDMyQwVAICgAgAQVAAAggoAQFABAJDMp/y4FIJtwJx8ehJo
yQwVAICgAgDoyyk/HnMKhdE5RQ30YoYKAEBQAQAIKgAAQQUAIKgAABBUAACCCgBAUAEACCoAAAQV
AICgAgAQVAAAggoAAEEFACCoAAAEFQCAoAIAQFABAAgqAABBBQAgqAAAEFQAAIIKAEBQAQAIKgAA
BBUAgKACABBUAACCCgAAQQUAIKgAAAQVAICgAgBAUAEACCoAAEEFACCoAAAQVAAAggoAQFABAAgq
AACGCKoQPAs2JQAIquwCUAI2JQAIqowCOPtvbEoAEFQRBaAEbEoAEFQFCkAJ2JQAIKgKFIASsClh
szEKrDGoXkNuiOPwwim4iezYoc9+39iDfQbVq+mGEFOiCjZ7E23swR6D6tV8Q4gpUQWb7PeNPdhn
UL26bAgxJapgk/2+sQd7DKr3EDE1y96mUPT1fqgh6Ffosbsz9mDdQfXquiEY/rUKlBtLYgoqDJZB
Dmjlg8qRWlSBMSSmYLOoKhtUjtCiCowdMQUbRtXLswUgpkBU5XkXf9CmPJZ9nQJrft6Gife9XmC/
t0mHg9tr3FcJYgrmjilgn8Fa55SfI7WYAvtnYKNBW+8+VLGn/zY6wtd4qDY1iCngx+BtdNCre1G6
W3gPt7MXUwAwW1CJKjEFCzB2wODtH1SiSkyB/TKw+KB9DfnARJWYAvtnYKLB+m7+AJ+UgL2WTQmT
jz1jEJVf0ASD7jXck2/vY1PCQscwE+6wfkz1CaqrB6wAbEoQVcBkMdUvqH49cAVgU4KoAiaMqb5B
9bkBFIBNCaIKmDSm+geVArApYaOxZ4zCuoPq5VkDqL//F1Ow9qASVACV9/9iCtYfVIIKoOL+X0zB
HoNKUAFU2v+LKdhnUAkqgAZvqoG1B5WgAgAQVAAAggoAQFABAAgqAAAEFQCAoAIAEFQAAIIKAABB
BQAgqAAABBUAgKACAEBQAQAIKgAAQQUAIKgAABBUAACCCgBAUAEACCoAAAQVAICgAgAY3NsmIEYI
//3zONK/7u/v/nx+zdPl/1rO0++LWd6vZZ59Xe7jSfnZSq3z6jnJ2ValX09PHj9AD2aoiPJ34Lo6
wJWKiJQD7N2BN/WAzbNtZTsCuzJDRZeD8XHkH3zPZo5CSJudeTKbdrX+lkE7QkzFbq8VHj/AGTNU
dDkY1ziw1jjY7nAA/wzKqxnIu5gSPICggoTIuDroXh1YRz3ohuCUlcgESOOUH81iZdR1fJ9+zL1Q
use1Y6nrvLsearR46rHNAQQVw6l14HtyOurJz5USVqs9LynXt8V+ShBAUMHHQfdzFuMsQGqHSW5M
PQmrVtdsjRCkOwY5gKBiGne3Okg5WJaMqbuw2uX5+P6aX4H8/f922F4AgorlgyD3hp47z3ycPfZf
p/FSb00BIKjg4kD8/cm4mFNjKfd/OpsJyb2GJ+V+UzEXSK9wAfuvqGr9s7ooHRiV2yYgDCe8xUOp
gHny2GNjVdwAOzJDRbUYSfnep8srfdCOWV6tr225ztzt3PpxiTRgdGaoAAAEFQBAX075sbS7C6dH
OJU0w8/ocQEIKjY2w0F71bAQTMBOnPIDABBUAAB9OeXHY36tCAD8ZoYKAEBQAQD05ZQfl3xSCwDu
maECABBUAACCCgBAUAEACCqgiRDczwtAUAFZMfXr3wEQVEBkTIkqAEEFFIgpUQUgqIACMSWqAAQV
UDCURBWAoAIKBJKoAhBUQIEwElUAggrEVBhjGQAIKtg2pkQVgKACMTX4MgEQVLBNTIkqAEEFYkpU
AQgqYKzQEVUAggqWdBxrrgsAQQVDRdWTECqxDAAEFSwZVTEhVGIZAAgqWCqqUkKoxDIAEFSwRFTl
hFCJZQAgqGCJqOq9DAAEFQCAoAIAEFQAAAgqAABBBQAwibdNAECqcPKLJo8fH1cNN7+U8up7jpOP
v6as//PvPr+/xPpTlsEazFABUDSmnsRTie/pvX74ZIYKgKz4+J55+fu7EMLPWZmU2auY9YsjejBD
BUDRmDk7pdZq/Vf/P2bZT7/2OI7/rU/ICSoAiHIVLS2uFyq5Dtc3kcspPwCairmQvHUghhBOT1U+
eQx/fyfQBBUALBNrtcPmc/l/QYagAoDqYi9ib/2zPZ2l+hVw7Ms1VAAkKXXbgpIXkH9eIF7r8T15
bEJLUAHA4wD6FQ5PPoVXc/0ll3/3db/+sCen/ABIio7PU3U5YfIdY0++78n6RzPqxfiUYYYKqh94
rv/AzFGV8nelouLue3JC5e5XzTx57E777SUcsa+4zxeIo8HlOw/vOgBwLBlqA1drGDNUAACCCgBA
UAEATM2n/CpyQSIA7MEMFQCAoAIAEFQAAIIKAGBnLkovxI3XAGBfZqgAAAQVAEBfTvlBbXf3I3O6
GGB6ZqgAAAQVAICgAgAQVAAAggoAAEEFACCoAAAEFQCAoAIAQFABAAgqAABBBQAgqAAAEFQAAIIK
AEBQAQAIKiBFCGMsAwBBBVPHVE4QlVgGAM29bQIoGFOf/30c7ZcBrV/zd6/Rq6/7fs1/fs3T5Z+9
AckZO2dvaL6XeffGJ/XxpPxspdZ59ZzkbKve278BM1RQOqaeDvbSy4CW/g5WV6/RUhHRcuwYc2W2
VY3tP/hzY4YKar5bfLIDeLIMM1WsOnaOI/9AeTZzETt2YmbTrtbfMmhH2PfFbq/Syxxk/2iGCmrF
1Kzrgplez78OpjUOsDu8qfkMyqsZyLvwSdleNZYpqGASLQe3GSpGHgNXB92r1+6or+sQvInptV+a
eF/nlB/kDv7aO14xxUpahErqOr7Hc+yF9y3Hbul13l27NPJ+aJBTgYIKRo4qMcXK46b2wTVlHb9m
3VpcXD/i85Kyb4v9lGCvZQoq2CiqxBQzvfY/ZzHOAqR2mOTG1JOwanXN1ghBunucR3INFYw4qMUU
K/sLsO9rlXKuXSoZU99jcfXxmPpp5LP7f5W+B9Ukz4GggtGiSkxBn5ja/UL0v3D5/nO1jyq1zWos
szGn/KDGTinnoliY9TV/FzZnr++U+z+dfcIw93qblPtNxVwUvcIF7N/7uZJRlbLMQS5KN0MFtQ4w
YgrWGberjs+Y21vExmqN/eDAz0M4jsifrtZ5alh5ZyWmAMbaJxfe75qhgl7veMUUwDIEFfSMKjEF
sAQXpUOrqJrk5nSwpLvT7yOMxxl+Ro9LUMFQUSWmoP348zN6XIIK7FgAWDWo/DZuAAAXpQMACCoA
gM7iT/m5BgQA4P+YoQIAEFQAAIIKAEBQAQAIKgAABBUAgKACABBUAAB7+hfHbDX87cMFJQAAAABJ
RU5ErkJggg==

31
Documentation/DocBook/media/dvb/dvbproperty.xml
View file

@ -163,14 +163,16 @@ get/set up to 64 properties. The actual meaning of each property is described on
<section id="DTV-FREQUENCY">
<title><constant>DTV_FREQUENCY</constant></title>
<para>Central frequency of the channel, in HZ.</para>
<para>Central frequency of the channel.</para>
<para>Notes:</para>
<para>1)For ISDB-T, the channels are usually transmitted with an offset of 143kHz.
<para>1)For satellital delivery systems, it is measured in kHz.
For the other ones, it is measured in Hz.</para>
<para>2)For ISDB-T, the channels are usually transmitted with an offset of 143kHz.
E.g. a valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
the channel which is 6MHz.</para>
<para>2)As in ISDB-Tsb the channel consists of only one or three segments the
<para>3)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>
@ -334,9 +336,10 @@ typedef enum fe_rolloff {
<title>fe_delivery_system type</title>
<para>Possible values: </para>
<programlisting>
typedef enum fe_delivery_system {
SYS_UNDEFINED,
SYS_DVBC_ANNEX_AC,
SYS_DVBC_ANNEX_A,
SYS_DVBC_ANNEX_B,
SYS_DVBT,
SYS_DSS,
@ -353,6 +356,7 @@ typedef enum fe_delivery_system {
SYS_DAB,
SYS_DVBT2,
SYS_TURBO,
SYS_DVBC_ANNEX_C,
} fe_delivery_system_t;
</programlisting>
</section>
@ -647,6 +651,18 @@ typedef enum fe_hierarchy {
many data types via a single multiplex. The API will soon support this
at which point this section will be expanded.</para>
</section>
<section id="DTV_ENUM_DELSYS">
<title><constant>DTV_ENUM_DELSYS</constant></title>
<para>A Multi standard frontend needs to advertise the delivery systems provided.
Applications need to enumerate the provided delivery systems, before using
any other operation with the frontend. Prior to it's introduction,
FE_GET_INFO was used to determine a frontend type. A frontend which
provides more than a single delivery system, FE_GET_INFO doesn't help much.
Applications which intends to use a multistandard frontend must enumerate
the delivery systems associated with it, rather than trying to use
FE_GET_INFO. In the case of a legacy frontend, the result is just the same
as with FE_GET_INFO, but in a more structured format </para>
</section>
</section>
<section id="frontend-property-terrestrial-systems">
<title>Properties used on terrestrial delivery systems</title>
@ -721,14 +737,10 @@ typedef enum fe_hierarchy {
<listitem><para><link linkend="DTV-TUNE"><constant>DTV_TUNE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-CLEAR"><constant>DTV_CLEAR</constant></link></para></listitem>
<listitem><para><link linkend="DTV-FREQUENCY"><constant>DTV_FREQUENCY</constant></link></para></listitem>
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-CODE-RATE-HP"><constant>DTV_CODE_RATE_HP</constant></link></para></listitem>
<listitem><para><link linkend="DTV-CODE-RATE-LP"><constant>DTV_CODE_RATE_LP</constant></link></para></listitem>
<listitem><para><link linkend="DTV-GUARD-INTERVAL"><constant>DTV_GUARD_INTERVAL</constant></link></para></listitem>
<listitem><para><link linkend="DTV-TRANSMISSION-MODE"><constant>DTV_TRANSMISSION_MODE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ISDBT-LAYER-ENABLED"><constant>DTV_ISDBT_LAYER_ENABLED</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ISDBT-PARTIAL-RECEPTION"><constant>DTV_ISDBT_PARTIAL_RECEPTION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ISDBT-SOUND-BROADCASTING"><constant>DTV_ISDBT_SOUND_BROADCASTING</constant></link></para></listitem>
@ -767,7 +779,8 @@ typedef enum fe_hierarchy {
<title>Properties used on cable delivery systems</title>
<section id="dvbc-params">
<title>DVB-C delivery system</title>
<para>The DVB-C Annex-A/C is the widely used cable standard. Transmission uses QAM modulation.</para>
<para>The DVB-C Annex-A is the widely used cable standard. Transmission uses QAM modulation.</para>
<para>The DVB-C Annex-C is optimized for 6MHz, and is used in Japan. It supports a subset of the Annex A modulation types, and a roll-off of 0.13, instead of 0.15</para>
<para>The following parameters are valid for DVB-C Annex A/C:</para>
<itemizedlist mark='opencircle'>
<listitem><para><link linkend="DTV-API-VERSION"><constant>DTV_API_VERSION</constant></link></para></listitem>

8
Documentation/DocBook/media/dvb/frontend.xml
View file

@ -45,8 +45,8 @@ transmission. The fontend types are given by fe_type_t type, defined as:</para>
</row>
<row>
<entry id="FE_QAM"><constant>FE_QAM</constant></entry>
<entry>For DVB-C annex A/C standard</entry>
<entry><constant>SYS_DVBC_ANNEX_AC</constant></entry>
<entry>For DVB-C annex A standard</entry>
<entry><constant>SYS_DVBC_ANNEX_A</constant></entry>
</row>
<row>
<entry id="FE_OFDM"><constant>FE_OFDM</constant></entry>
@ -63,6 +63,10 @@ transmission. The fontend types are given by fe_type_t type, defined as:</para>
<para>Newer formats like DVB-S2, ISDB-T, ISDB-S and DVB-T2 are not described at the above, as they're
supported via the new <link linkend="FE_GET_SET_PROPERTY">FE_GET_PROPERTY/FE_GET_SET_PROPERTY</link> ioctl's, using the <link linkend="DTV-DELIVERY-SYSTEM">DTV_DELIVERY_SYSTEM</link> parameter.
</para>
<para>The usage of this field is deprecated, as it doesn't report all supported standards, and
will provide an incomplete information for frontends that support multiple delivery systems.
Please use <link linkend="DTV_ENUM_DELSYS">DTV_ENUM_DELSYS</link> instead.</para>
</section>
<section id="fe-caps-t">

206
Documentation/DocBook/media/selection.png.b64 Normal file
View file

@ -0,0 +1,206 @@
iVBORw0KGgoAAAANSUhEUgAABIsAAAHpCAYAAAACi7yYAAAAAXNSR0IArs4c6QAAAAZiS0dEAP8A
/wD/oL2nkwAAAAlwSFlzAAAOxAAADsQBlSsOGwAAAAd0SU1FB9sLCBAiCLMGMtAAACAASURBVHja
7d3rkds4FgZQaMohTBY7ObRCV+fgyWJy4P6wJavVIgmSAIjHOVWu3bElPkBSAj5dgpdpmqYAAAAA
ACGEvzQBAAAAAHfCIgAAAAAehEUAAAAAPAiLAAAAAHgQFgEAAADwICwCAAAA4EFYBAAAAMDDD00A
21wul9XXTNN0aHnP749Z39o2rK0jRzssLX/pvVve9+61S69Jdey2bn/sMTx6TAAA/cIW+oVb+2tb
3p+izwioLIJsHYe9X+a979vae89ut6Pb1+txBwD0C3vZN0ERrFNZBAct/ZJxuVx2Vdg8v+/oLyEx
69j7xbq2/1u2e0u75Th2Mevf8ytVzDkDAOgXjtYv3LquVP0nQRHEUVkEBTsJve/r0hfu2hdz7e0W
27HQ4QAA9Avr7BcJiiCesAhO+GKK/YIt8SV+RscoNmippUPl1jIAQL/w3PUc7Y8JimAbYRGc9KVY
Yu6b3OsYNUTRuQAA9AvL9AtT9LsERbCdOYsAX74ZOiVbO1M6LQCAfmH7/TzohcoiqOhLK+eXV4p1
xP4y1krF0X1bn7dXBwIA0C+ss19oagAoR1gEJ4j9osv5iPq965imKUk59eidwNc/AIB+oX7h/HpK
tzeMzm1oQJIv7Ra/eO/7sOWxtgAAtN0v1N+DdcIiyPQFlPP1JbZpTyehl19q1joQOhgAgH7hOf3C
Pct9tz36c7DMbWhQwPMXUYkOQ6517P3Sj/216axJEdfWoyMBAOgXpukX5uqv7Xm/W9JgnsoiSGxr
4FHiiyvlOu7v21pu/PqLzuuvOTHtlmIZW/bz+f1r6177ewBAv1C/8FwqjCCesAgSdwK2dAh63e+5
fX8XuBxtt1SdkZhy6djt37vNOioAoF84Sr8wV39tzzIERvCd29Agg7knQ8T+unTk15mc64j5El17
KsbRW75inrqR6glj79rELWsAgH5hmn7hmcckpt8HI7tMRjYAAAAA/KayCAAAAIAHYREAAAAAD8Ii
AAAAAB6ERQAAAAA8CIsAAAAAeBAWAQAAAPAgLAIAAADgQVgEAAAAwIOwCAAAAIAHYREAAAAADz80
AQAAqVwuF40AABWbpmn1NbvDIh0BAKDGzg3n0T8EgD7sCot0BAAAmDNNUwj6iwBQlS3fzIduQ7vd
blobAMjuer1qhKZ6o4IiAGiZOYsAAMji0w+LAHC6jx0/unkaGgAAAAAPwiIAAAAAHoRFAAAAADwI
iwAAAAB4EBYBAAAA8OBpaAAAFDf3ZJa5J6htef3za5eeyDb3urWnxsQuM/V7jmxX7Dr3HIMUbfj6
+qXjurZ977Zja1vuaVOAnqgsAgCgqKWB+rt/2/r6s7Z/z3aesf0x+1fjdgFQjsoiALpyfRng3J5+
Fb7/2+3NL8Xv/m1pWa/veX7t/XXXN4OtuWXs+fe59c/t45H2erd/Mdu/9XX0b63q5zWkWHr9/d8+
rtfFapOY9byz9L7X5e7ZzqVKmT2VP3ts2cc966+1MmfuGKkkAvhFZREA3XgON94FNnMhzlJQNLes
1/ffX/f62ue/fw1d3r3m9d/nlhu7/rX22rv8LW20d/voT8ztYbEBzNJrS4YMubbzzNCidLs+BzX3
datsAjiXsAiALrwLfPYGE1uXtaVK5l2YNLes2OXurdI5svwtbaSKiFdbg5Cl18f821y1UupAZu92
1njblwobgLG5DQ0AZqSofjkSnOSuvsmxf2fsB5SUMtT5vN2+LC82xNoziXaJNthyO11MBdHS7YUA
5CUsAmAo91u97rdGLc1jdKQi5t08QiH8uSVrTcwcSkekWv7avuTeD1hzD2TuwcOWqqIS8wa9C01G
nD/neV9fQzQAyhMWAUAma5NVA23KEeLMhUZHJ5g+e/9jXyscAqiLOYsA6MK7+XLW5gWK/fdnsYHP
2uvWJtveu969ti5/bxsJzNgTDOx5JP2z1yAmNsC4T7j8+ifXdj6vs7VjlGsdQiSAc6gsAqAbz7eY
Pf9dqmVtWd7cbWivE0LPbe/rv80tL1Vb7Vl+TBvl3g/a8nx70dIj7e9/v/b6mKer1bBfc9tZ65w8
pdt1bh1zQdFaGwNw3GWapmnzmy6XQx1wAIAt7gHTjm4LJTuWv/uI084QYC482Pv6LfMSvXtc/Nag
pNR+xb7+yLYeXX9MG669ZunYpN7mEeeJAsZx/4y7/P7vmP6U29AAAChq6yPm9z6S3n7t34/c648J
Z97N49TKuQDQOpVFAED1VBY10rGMrCwCAMpRWQQAAADAIcIiAAAAAB48DQ0AADqSciJsAMYkLAIA
gI4IgwA4SlgEAADAZh9/X9/+/ed/t8Ovf37t3PKWXje3rq3LTP2eI9sVs961969t59r2LbX16zJi
t+Xzv1vyduE4YVHpD9SZsuDnX4COlA7HLD/Ferase2lZW7Zh6/a+vn6pDda27912rK0vVbsCAEB1
45qFwf3H39dNIcm715fY/rWQKsV7Wj5me93Dn6VlxgZKnEdYVPLiXAgTPq7X6BBh7rWpln/kPWv7
LigBAIDGxzUrVT+vocTS6+//thYs7A1plt73utw927kUeixt3xnhWEybzO13qe0VHtVDWFTq4nwK
cmKDni2B0NLy7/82F/4srWdPYLRneVvWUWvgNNfuAjIAALoZ10TcHhYbwNz/LiYwStpvf3PbU47t
zL0v727/WqvqijlmEEIIf2mCAh+oK0HR0UBhbflbbuVKsT1ry4vdhhRt/nm7PdZdYr0AADCCreHC
0utj/m0u3EkdcuzdzntQ09MxS7Gud23iFrQ2qCwqeXFmrjBZWv7n7XZ6WFLDNgAAAGNLGeq8Vilt
ndz53fKO7sMZc0DlPjaCpfKERTVfKBsmqy617hr2de21qeduAgAAzvM6YfKWypQS8wa9q6IpVT3z
vPyYp4pBLGERu55i1sSXytO2q2oCAAAe44MMIc5caDQ3B1KSsVzF4dC7p6KthWgqiOohLKr5A2zj
RNW511/LurY8NQ4AAEhv661OMY9RXxwDPAUP9/+OGjtsDB+ObufzOnMFOTHLnZvoWhhDLBNcl/xA
PRherIUka7dfLS333Z/a9j/VOoRIAACwc0wy86SzL/3tmadvLU12/Pra2vZryz6V3OZ3f44eMwhB
ZVGZi/jpFqi5qqAj1UJry495Gltupbdhbh1zQdFauwEAAL/72i+PkU/x+hoeRb93O/fMi1R6Iuet
xyz1emNDQRNc10NYVOoieQl0jnoNN2KWXyoo2jMH0lnbfKTdzm5nAAA4bXyzMJnyXHVLC0FA7fsV
cxveu7mCWjoG1EFYVPKDZ2GS5diAYW0ZtQYYJZ/gtrSuexs9h201txsAAFQ7vtkYMGx5/dHXHgk/
atmvI+9PNYF0ioqvGqrG2O4yTdO0+U2XSwghhJuBNABQwPV3qL+j20LJjuXvPuL9KPnRBWCbtVvE
hCrsOq9+96Muv/87pj+lsggAAKDFAeBLsCBIaJ9jSC2ERQAAAB0QHgGpCIuI++JZmZRbmTkAAFTW
h98QHn1cPzQYFPR5+6x6+4RFRJ7IN40AAAA19dGfwp+Yx6HHPr4cQFgEAADQuNfwZy08inkEOzAu
YREAAECjYiqKdvl50bg04Ujg+Xr7Ze5bw1q63VNYlPzgXzUCAP13zNyeDJB/bJErCAKKB0WtERYB
AACcNWA9IRBy6xnDX3eColXCoowUbgLQk0kTAMQPRguFQItPOHuzDXuCoss/jieV9Ul+Hrg2TwqK
WnvioLAIAABgy6CvgiBoz/apKGL4a1dQFE1YBAAA8DywK3hrWOoAJ1U1EXR3XQuKNhEWAQAAYwwW
Gw6B9u6foAgERXsIiwAAgLYHgoUnia4tgBESwcL1UUlQ9Hn7bCo8EhYBAAB1DvJOenR860GLoAh+
f4ZUFBS1RlgEAACUH8R5ZLx9hJyfMYKiQ4RFAABAuoGSEMj+w9mfQ4Kiw4RFAADA+iBICAS08Fkl
KEpCWAQAACMPrMwLBPTyeSYoSkZYBAAAPQ6ahEDASJ95gqKkhEUAANDaoMgtYQB/PhMFRckJiwAA
oJYBjxAIYNvnpqAoC2ERAADkHlQIgQDyf+4JipIRFgEAwN4Bg3mBAKogKEpLWAQAAK+DASEQQDME
RekJiwAAGIpbwgD6ISjKQ1gEAEAXhEAAZPl+GSwoCkFYBABA7Z10IRAAZ30HDRgUhSAsAgDgrA64
eYEAqPl7atCgKARhEQAAR/17CSGEMP186WSHa9HNEAIB70zTNMy+Xi4XBzyRkYOiEIRFAAAs+ff8
gYcQCICSRg+KQhAWAQCMSQgE0J25KioVR/EERb8IiwAAenJGCPS/6ctgZHp0sG+OB0AFXkMk4dF7
gqI/hEUAAC04qxLof5O2B6B7gqKvhEUAAGcSAgFQ2HOlkSojQdE7wiIAgFxOvCUMAFgnKHpPWAQA
sJUQCIBOjFxlJCiaJywCALgTAgHAEARFy4RFAED/zAsEAKvuVUa9VxgJitYJi6DmD+uf7//+8s/6
a969ds/yU6xn636uLWttu9e2dakdX5cRuy2Xf/K2ETBDCAQAbHBWUPS63toJi6BSS8HD9DM+eJh7
barlH3nPme2y5h7+LC0zNlACdnaq/r5+v/Zzh0NCIADotsJIUBRPWAQ1fjg/BSKxQc+WQGhp+fd/
mwtJltaTOzCKbZe5fSoV6giPYKXD9BQCFSMEAoCx+x+Cok2ERVCZtUBk6e9TLP/5dqrY8CfmFqy1
7Xm+/evdenO3C5CgMyQEAoC+xibT1EV1kaBoO2ERVCp38LG0/CPhT+vt8q4dlsIrARVDdBTffB58
hGv29X7+d3v8/+v1+ui0AgDEqiUo+rx9NhUeCYug48FcCOfPI7T3faXmQOrtWECJa/eo5xAIAKi8
v9Dw/EU1BUWtERYByQaXe8OQ5/fVXNUEvVyruQiBAIBaCIqOERZBJ7ZOVJ17/bUParfs1+utaGu3
oKkgIqczrpfHuf+l43NzMABgpD5IQ/MXCYqOExZBxQPCI6HDWoVOzCPhlwaNJQa8c3MFCWPo9Zov
zbUEAPRGUJSGsAgqE/M0siOBydryY546VmKw+jpwzt0ukMtZlXOuBQAgeb+m8uoiQVE6wiKo0Gsw
kmKwOjcvUEuTMadul63rjQ3STHA9SGdJCAQAUA1BUVrCIqjU0m1ksYPFtWWcFWrEPHZ+7rH1Z243
43BLGADATD+pwuoiQVF6wiKoWMzgce01a4HMGQPZLWFXim3J3Y4G+w11boRAAABdERTlISwCoHlC
IACAgn2v6dczUmurMBIUpSMsAqDejoh5gQAAiCAoSktYBBQf4BuIIwQCACAVQVF6wiLAgJyk3BIG
AEApgqI8hEUARBECAQDwpX9Y4ZPRchgtKApBWATgS14IBAAAb40YFIUgLALolnmBAADI3ufsuLpo
1KAoBGERQHtfyEIgAADIauSgKARhEUBV3BIGAEBzfdjOqotGD4pCEBYBlPkCFQIBAED1BEW/CIsA
DhACAQCMpbYKmmmaqtmO1quLBEV/CIsA3n3ZmRcIAACGISj6SlgEDEUIBABAT16reWqpNGqJoOg7
YRHQDbeEAQAAWwiK3hMWAdUTAgEAQGQ/9qnSqHSVUWvzFgmK5gmLgNMIgQAAgDMIipYJi4DkzAsE
AADnu1f5mMfoK0HROmEREE0IBAAAtOysoOh1vbUTFgEhBLeEAQBAr0pWGNU8b5GgKJ6wCDonBAIA
AEYnKNpGWASNEgIBAACb+vODzmEkKNpOWASVMS8QAABAGrUERZ+3z6bCI2ERFCIEAgAAanC5XLJW
F9Uyb1FNQVFrhEWQ+oOxUCgkBAIAAHaPJzIHRmcTFB0jLILaPrSFQAAAALsJio4TFkEhQiAAAKCq
MUqH1UWCojSERZD6A1coBAAAUJygKJ2/nE4AAABASqUrlgRFaaksghQfhD+1Af1QHQcAQEsERemp
LAIAAIBB1fCI+yMERXkIiwAAAIDmCYrScRsaJOYWHlrkVkoAgIHHMB08FU1QlJbKIgAAAKBZgqL0
hEUAAABAkwRFeQiLAAAAAGaMFhSFICwCAAAAeGvEoCgEYREAAADAN6MGRSEIiwAAAGB4l8sl+TJb
fsLayEFRCCH8cEkAQJkOTo5OGAAAaY0eFIUgLAJgcCV/8VpalyAJAOB8gqJfhEUADKPmUuh32yZA
AgAoR1D0h7CIrgduBlp9DqqdM4xyHj9vv3MTACAfQdFXwiKAmcH5K4P19o9hT/vlfAQASENQ9J2w
iO4HjQZUGKyPeXxG2V/nIQCQyuVyGa5PJSh6T1iEgR0kOIcN2H2OOA8BANoiKJonLAIwYG+6vfne
Ls5BAIBlgqJlf2kCeh/oGVRyxvntvNO22gkAoE6ConUqiwAyDthDUOWRsi1xDgIAHHFWUPS63tqp
LAIoMGAXdhxrP5yDAABHCYriCYsYYuBnkIQBu/ZCmwIA4xIUbSMsAjhhwI42Ort9tTEAMApB0XbC
IoYZABoY4Vpoo120jfMQACCVWoKi1ibRFhYBGKhrD+0OANAdQdF+wiKAkwfqBusCCwAA0hIUHSMs
YqjBoAEp1Pe54LoEACAlQdFxP5xGAOebpilcLpfh9rkVKY6NUAwAID9BURrCIoBKjBQY1Rqc5Gz/
uWULkQAA0hAUpSMsYriB4YgVHLR1rfR+ftb0eVBDW79ug/AIAGA7QVFawiJgqIH5O7UNznsOjGpo
69rb9nn7BEcAAOsERekJixhuIN77YJxjg3OD9D4/C1q93gVHAADLBEV5CIsAKhyk9xZonhV09NSG
giMAgGWConSERQCRg3QD9PaOmXMSAGAMgqJkHc0Qpin85ZQip5oHMgZZ7BmglwwhejlHS+/HSLeY
lj4nAQBqJChK2nkPIQRhEW0NisAAvbXvmslxse8AgDFcNoKiPIRFGMhCxV9+LZ+jpYMitAMAQA6j
BUUhCItoZKB4HwAZCGFwPt71v9b+joE2AQDa6sO1ZMSgKARhEUCSwTnaXfsAAPRl1KAoBGERmbSU
SEvPcY62t72CkPh20lYAANuNHBSFICyikcGOQSKtnaejEhQ5PwEAWjd6UBSCsAjAgFwbD9N22g8A
YJmg6BdhEcnlmNi6pW0G134egg7tCACQk6DoD2ERBjuAa157AgAMTVD0lbCIpFqu0FFdRM2D8NrP
z5zbJ9jQrgBAe/25lvoagqLvhEU0O5Ax0IE+OxbU8zkLANA7QdF7wiIAqiXM0MYAALkIiuYJi0im
xYmtc+4DBt+ue+0IAECdBEXLhEUYlAMAAAxstB/NBUXrhEUAVNepEAQDAJDDWUHR63prJyyiukHj
1kFi6kGlW9HgXIIiAAD9uRwERfGERQAAAEDXBEXbCIs4rMdKHNVFcM41oqoIAMDYJzVB0XbCIqqy
d6BogAkAAMCrWoKi1ibRFhYBsImqIgAA/boW+nSCov2ERVTz4VLbQNGtaAAAAG0SFB0jLKIbqhLA
9QsAQJyefxwXFB0nLIJBP0BpSy1himsCAICaCYrSEBZRxaAx1UBYdQK9XRsAANBKf/Xs8ZigKB1h
EQCnEvICAHCUoCgtYRG79Dyxdc59Bdc9AABn9ud67NMJitITFtEdVQoAAABjEBTl8cOpBZBOjl9q
eg5AhbsAAG32UWvs1wmK0lFZxKkfNLk+UFIv1+03AAAA9RIUpaWyCCCRnkNFgSkAgD7cnLOrigRF
6akswoDRvlMxt2kBAMA8QVEeKovodhB8uVwEPBTjXKvvMwAAQL9Uny6F0YKiEFQWAVT7hSxMAQCA
c40YFIWgsoiTBsSlBsGpq4umaTKAJ9t1AQAALfVHex8bjRoUhaCyCKDKL+aavngFYgAAjGbkoCgE
lUUAmwlPjlOhBwDoC+rP1Wr0oCgElUWc8IFY+kMl9fp8OYx9HZQ4/oIUAAA4h6DoF5VFACtKBoSC
IgAAatdrn1VQ9IewiKID5V4+VEx07bz3pQsAAP0QFH0lLGIIqZ+KRl9qODcERQAAtDK26o2g6Dth
EVCMwG6cL1wAAGiBoOg9E1xTbHB/9oDYRNfUSFAEAEAr/dbe+q6ConnCIoATv3BrJxQFAKBHgqJl
bkMDKGz0aiLVVAAA+m5nEhStU1nErB6fguZWNM4+/wQlAABwnrOCotf11k5lEUBmAiIAAPRjzyco
iqeyiLd6rCrKtT2qi5g7z1QSAQBAHQRF26gsAjhIIAQAgL5tvQRF26ksAjhomqYvfwAAgDrUEhS1
Nom2yiLeDnxTqTWVvlwuBvUUuYZUHQEAUKve+6qCov2ERQAZCY4AAGihr9pbf1VQdIzb0Fj8sDjC
wBi+X18q2gAAIC9B0XHCIoYlzOIsQiMAAGrup7bcVxUUpSEsAjjxyxgAAEhDUJSOsIgsA9dWqnZU
F1HDdSc0AgBAP/UYQVFawiKASr6MAQCA7QRF6QmLACohMAIAoMY+as39VEFRHj+c+qQepLZ2a9fl
ckm6/9M0ub2t4XPj7C9C5w8AAOwjKEpHWATw5F1QUzpAEhgBAFCbe5+41n6qoCgtt6ExdFVRru12
O1FfLpfL40+L1yUAAPRMUJSesAhgg5LBkcAIAIDa1NZHFRTlISwC2KlEaCQwAgCAc40WFIUgLBqe
W9Dybb9B/jgERgAAjDaOHKWPOmJQFIKwCCCJ0nMaAQAAeY0aFIUgLCLhQBnIdy2oLgIAoDY991FH
DopCEBa5sMk60NfGzqPWz6cc++K6AACgZqMHRSEIiwCyUG0HAMAIevshUFD0i7DIBW1QnHl/VFHg
fAIAgPoJiv744XQAyONyuQh3AIDmTdOkavqlj1fzsXKO7CMo+kplEUBjnQkBFAAApCMo+k5YNCC3
oJXfL4N7AACgxDjm+U+r48ySBEXvCYsACnxp+zIGAIC6CIrmCYsGo6rovP0zuAfXAwD47qb0mKZk
lVFL54mgaJkJrvGFAax2MlzvAAD0QlC0TmURQAGeIAIAwNn90RJVRrX/yHhWUPS63toJiwaiMsAx
wPkEAACjEhTFExYBcAphFwDAOXJXGNXYzxMUbSMsAgAAALolKNpOWDQIv+A7Fpyv5XmLzLkEAOjH
6p+2eL7UEhS1Nom2sAgAAADojqBoP2HRAPwC4JjgXLL9AAC8U+IJaWcQFB0jLAIAAAC6ISg6TlgE
QBTzFgEA6OttcUYVuaAoDWFR59zi4diAawEAgBEIitIRFgEAABDFjzx9a7m6SFCUlrAIgFM7EAAA
cISgKD1hUcek/o4RuBYAANiitR8HBUV5CIsAAACA5gmK0hEWdcqv9I4V5JLr1ybXAgDov+Kc2UtQ
lJawCAAAAGiWoCi9H04rYpjU9iu/puAz4ZLlOpimyecNAECnfb0cBEV5qCzqkCDDMcNxBgAA0hgt
KApBWEQEv/IDJQnVAACMA2sxYlAUgrDIIItqPjgdO1wHrgcAMO6AeowaFIUgLAJoml98AAAgvZGD
ohCERRiIahuK6PXXN9VFAAD01rcbPSgKQVjk4sMxBNeENgYAIIQgKLoTFjFL5Qzgs6JvgiIAfI/A
H4KiP4RFYJCMjpT2064AAEMTFH0lLNLpx7GkUTWFlbm3xXWhPQEAchEUfScsovpBKBiU+9wYrS21
IwBAGYKi94RFOv5UOEB2TF2baNMcbaf9AICzxzo1ERTNExYB+OJuarsEHtoMAOAoQdEyYRHNDELB
4NxniPbVVgD4nsH5cpSgaJ2wyMWGY4tjp507bR9tBADw1VlB0et6aycsAkg8QM+theq/UtsoENEm
AACxBEXxhEU0NwgFA3SfJ+/aH+0AADBHULSNsMigAMeYho5Ta4Fu6cBo1GtGWAkAME9QtJ2wiGYH
oWCA7rNl7rg4BwEACKGeoKi1SbSFRQ0PEHCsOW9wfsZxEehuP072DwD0Vxm3Dyoo2u+HUx+g/g5Q
60HR5XI5pR3v6+whaNMRBwCIJyg6RlhENwMpMCCv/3PmrPZ9Xm9rn3fOSQCAbQRFxwmLDGZpYEA8
TZPKiMHPKddHnvOwxrZ1nQAA7CcoSkNYBFCxHqv+agiM7l6344z2Fg4B0INeftyk7XNFUJSOsAgf
6uDaPGXfagxJ5rYpxbEQCgEA5CMoSktY1BiDjXEHwn6tGe8ccp347AUAYJ2gKL2/nFYGpIDr8sx9
9TkEAMBegqI8hEUN8cu2Ab9zwHljv9H2AADvCYrSERYBGLTbf20OANA0QVFa5iwySABci1W1hQo6
5xwAwBaCovRUFjXC4MmAzLngHBmpTbSLcw4AIIagKA+VRQAG7FW3kYDUOQcAcKbRgqIQVBY1IcdA
yaDBOcF5A3bXn88r5xwAQBtGDIpCUFkERQZqwh0M1tO0n2vJOQcAUMqoQVEIwiIAA/YG21No5JwD
AMhp5KAoBLehVc8taAZvJc8N0h1vt/6UaWO0CQB9j13gDKMHRSGoLAJINlDn3HYfsYPqvAMASEtQ
9IuwyMACcB11dVxGCI2cgwAA6QmK/hAWVUwZZ3+Du9THdJomg0aDcRaOXS+fo85HAIC8BEVfCYsM
DnBMnX8Mc821FB65BgFokR8zaZGg6DthEaT+gvypDaBW7zqvNQRIOtUAAOcQFL0nLAJgaEtBTcog
SSAEAFAXQdE8YREAzBDwAAD0SVC0TFgEKQaU//z637lb0O7/DgAAwLkEReuERVBAzDxGAiUAAIC8
zgqKXtdbO2ERVGItUBImAQDQRL/WE9G6O569EBTFExZBQnOBToonpKlOAgAA2EdQtI2wCAqICXEE
SgAAAOkJirYTFkEl1kKcFGFS7HIESgAAHOpzuhWNStQSFH3ePpsKj4RF0IhS1UkxyxEmAQAAtasp
KGqNsAg64nY3AACg6jFLoYozQdExwiIY7cPZ7W4AAEDHBEXHCYuAL2q63S12ewAAgPSmaWpumwVF
aQiLgM3MnwQAANRGUJSOsAjIwvxJAABj80Q0ShIUpSUsAk5j/iQA8i3Z/QAADThJREFUAOAoQVF6
wiKgWm53AwAAlgiK8hAWAU1zuxsAABCCoCglYRHQPYESAAD0TVCUlrAIIJg/CQAAWiUoSk9YBBDB
/EkAADv6NZ6IxnM/NsO5ICjKQ1gEkOrLz+1uAADQndGCohCERQBFCZQAAGjBNE0aIYwZFIUgLAKo
jvmTAADgfKMGRSEIiwCaY/4kAKAl5i1q85iNbuSgKARhEUCX3O4GAAD7jB4UhSAsAhiW290AACjW
92ykukxQ9IuwCID3X+gV3e4Wuz0AALCXoOgPYREAu5k/CQCgL6POVyQo+kpYBEBW5k8CAKBmgqLv
hEUAnM78SQDQN09Ea+c4jUZQ9J6wCIDqmT8JAIDUBEXzhEUAdMH8SQAAB/o3g1UVCYqWCYsAGIb5
kwAAEBStExYBwBPzJwEAI1FR9HnKemsnLAKADdzuBgDQJkFRPGERACTmdjcAePO95YloVR6TIn2j
Co67oGgbYREAnECgBABQhqBoO2ERAFTK/EkAQA4jzVNUS1D0eftsKjwSFgFAo86cP+kjXL92gP67
OSAAQFVqCopaIywCgI6VCpQ+/r6uvkagBIB5i85t+1P6Iicdb0HRMcIiABhcqdvdBEoAQAmCouOE
RQDAonuYNH3p/Ny+do4igqCoTtbMch6B1b+XEP43OSgAEOHsuYnOqCoSFKUhLAIADoupCEoVKIV/
VzqewiQAGJKgKB1hEQBQRLFA6d+IXzEFSgB0aKSnnH3rQwiKkhIWAQDVmAuUrtfrr05wovmTBEoA
0A9BUXrCIgCgHTEBzr+J5kcQKAGEEH7NO5OyYqX1J6KNXL2z9bwpQVCUh7AIAOhLTYGSMAkAihEU
pSMsAgDGUypQUp0EwIDOqBwTFKUlLAIAeGctxHG7GwBUQVCUnrAIAGAPt7sBwDelq4oERXkIiwAA
cnG7G9BRAGCSa2LOkx6NFhSFICwCADiXQAkAqjViUBSCsAgAoH7mTwKgcj1WFY0aFIUgLAIAaF8l
8ydNP0O4/ONwANC+kYOiEIRFAABjKBQoTT+fOtrhGvWez/9ujg80wLxFLJ0bPRk9KApBWAQAwF2p
291eO+V/X1dfI1ACoARB0S/CIgAA4qyESZfL5UtlUdLOu0AJoEo9VRUJiv4QFgEAkG7Q8E8I06OT
fYvrnEcEQSmWI0wCYPY7RFD0hbAIAIBTxYQ4KQIl1UkA6ago6puwCACA6q2FOKWqk2K2BYB2CIre
ExYBANC8UtVJscsRKNErT0Tjfh70QFA0T1gEAMAQagqUhEkA5xIULRMWAQDAfbBg/iSAWSqKxiEs
AgCADcyfBNCus4Ki1/XWTlgEAAAJud0NtjFvUf1UFKVdbwuERQAAUJjb3QDKEhRtIywCAIAKCZSo
VeonolH3se6BoGg7YREAADTK/EkAK59flQRFn7fPpsIjYREAAHTK/EnAXj1UFdUUFLVGWAQAAANz
uxvQI0HRMcIiAABgkUCJV6nnLfJEtHqOaw8ERccJiwAAgMPMnwTUQFCUhrAIAADIzvxJUKeeKroE
RekIiwAAgCq43S3xAPZpPwVk9E5QlJawCAAAaEYNt7u1GLx8/H0VGNHtvFCCovSERQAAQDdKVCe1
WpkkMKJHgqI8hEUAAMBQSlQn1TBv0ud/t2/bkTIw8kS0Oo3choKidIRFAAAAzwO/CsKkmO2I3Zec
gRFUc90KipISFgEAAGwZlJ44b9KekCdnYNRCFYtqpQGuSUFRcsIiAACAlAPXjPMm7b29TYUR3V5v
gqIshEUAAAClB7iZAqWt74kJjKafjhdjGy0oCkFYBAAAUKV3IU6qW9y+L3PS4PDu+hgwKApBWAQA
ANCMUvMlAeMGRSEIiwAAALqR6va2PXMZnTWwtl7r7Wm9tRAWAQAADCBn1ZEgwXqtty/Coozc9QsA
AJwt5glqHwb01mu9p663NsIiAACAzsQERAb01mu9day3RsIiAACATpQKiUYc0Fuv9Y5EWJTY5+2m
EQAAgHrGKAkDolEH9NZrvaMRFgEAAHQoR0g04oDeeq13RMIiAACATuQKiEYd0Fuv9Y7qL00AAACA
Ab31Wi93wiIAAAAM6K3XenkQFgEAAGBAb73WW3C9tRMWAQAAYEBvvdZbaL0tEBYBAABgQG+91ltg
va0QFgEAAGBAb73Wm3m9LREWAQAAMEuQYL3W2856UxEWAQAA8JYBvfVabzvrTekyTdO0+U2XSwgh
hNvt5tMTAMjuer2GEELY0W2hZMfydx9xenSO9RWhFS3fLgMtKhkgffzuR11+/3dMf0plEQAAAAAP
wiIAAAAAHn5oAgAAgLG1OKcKkI/KIgAAAAAehEUAAAAAPAiLAAAAAHgQFgEAAADwYIJrAAAAivq4
frz9+7mJtre8/vm1SxN3z71ubl1bl5n6PUe2K3adW4/DWvsfPb5737PlmJrc/T2VRQAAABSzNHB/
929bX3/W9u/ZzjO2/+gxOrrcrcve856alt8qlUUAAAAUsVb18zpoX3r9/d8+rh+L1Sdbq19itu91
uXu28/73qapz9tiyjyWWneo9Z+xvb1QWAQAAkF3M7WGxAczSa3Pac9vbnu08M7RYu+3r8/b5eM3W
dj/aFjmO8xnnUQuERQAAABSzNQhZen3Mv81VK6UOZPZu52i3Qe1p99zhmYqi79yGBgAAABFShjqf
t88vy4sNsfZMon10H9fmYzozbMndHqMSFgEAANCleyBzDzS2VBWVmDfoXfVTrsqnFPv4/HevYRd9
ERYBAABApBwhzlxodHRC59T7WGM4pIIoD2ERAAAAxWy9bWntaWdrnquL7v8dY2sIcXQ7n9d55oTd
e7Z9yzHds2+520OF1HcmuAYAACC7mKdOzT1ZbG0enVqeHrZlO1sLKO5PQXv9s8WeY5b7ONdyHtVG
ZREAAABFPM9zs6UqaOn1MQP8Ek/T2rOde+ZFamVC55T7lqo9SsxD1QuVRQAAABSz9RHzex9Jb7+O
i7l1b8utc3uqkfa8p6blt+oyTdO0+U2XSwghhNvtpgUBgOyu12sIIYQd3RZKdix/9xGnRwdcXxEA
zvbxux91+f3fMf0plUUAAAAAPJizCACA09yrxl7NVbBvef3za5cq4udeN7eurctM/Z4j2xW7ztT7
eH/t2nGda//YZS7tz1q77DlmAL1SWQQAwCmWBvbv/m3r68/a/j3becb2x+5jDccixTLn9qXm9oc9
Pq4fi38gRrHKopikvvQvG3vWs+fLxS8yfpEBAOb7DDH9taXX3//ter0u9pP29AvXtu91uXu2c6mP
d6RftsWWdR89FiXsOWZ7zw+ojcmaSaFIZVGqXx5S/nqzd3v37r9fZAAA1sOGd3+/9votPz6msue2
tz3bWWvgcsaxOLq81tof4EzZK4u2/mq05XVry1/7ZWPLLw4pvlBTbXcNHQS/yAAAOfoae19/u90W
K5zvP3jN9V9S9lf2budaFXlpe6uacrRnquW11P4AZ8paWbT1V6PUy6/h1wO/yPjCBQD6kzNcWqrk
fve61z9792duOTX05e7bkONHyL3tD9CzIreh5f6CWftlo9aORMntzn1Puy9XAKBmr2HDliqSEkHK
7XYTWpx8fmh/gD9+1LhRZ06SfOQLodQEhEe+BN+VYKdc9mtbqCoCAHqVo5/zroJmy5QKqfclV9+x
tr7snvYH6NmPkXe+9nCn1Q6T0AgAiO2LbekjrD3tLKav8lwtErvuPU/KPbKdc/2qVo5diW0+crtd
D+0PkNtfNW7UvQz0tRz0zKdb7Nnu5+2v5YumxPbMlfECALz2tbY+DGTtCbO1PBxky3a21E86eiy2
PiE4VT+9l/YHKKVIZdHR0s21JyDs/WWjhvmM/CIDAIzouX+3pSpo6fUxfbsSc2nu2c49fdaUUzds
DWy27mOq45dif1K1P0DPslYWbf3VKPXya3uKQ6rt9osMANCDrQ/7qPmhJr3u17uK8b3bnGo/j94F
0Op5BVDSZZqmafObLpdNH55rQcJrBcrWx83HLv/19ak+/Pc+Qn7rdqfc19flbA1+UuwLAGz9rt3R
baFkx/J3H/F+lD59/wPA6T5+96Muv/87pj9VZM6iFGn93mXU8uQGv8gAAAAALShSWQQAcITKokY6
liqLAKA6eyqLfmg2AADoj2kCANhLWAQAAB0SBgGwl7BohV9kAAAAgJEIi1YIgwAAAICRCIsAAMji
Y6VCGwCo01+aAAAAAIA7lUUAACR10QQA0PZ3+TRN0+Y3XXQBAIDydnRbKNmx1EcEgC76UyqLAAAo
1vkEAOq3KyzSEQAAAADokwmuAQAAAHgQFgEAAADwICwCAAAA4EFYBAAAAMCDsAgAAACAB2ERAAAA
AA/CIgAAAAAehEUAAAAAPAiLAAAAAHgQFgEAAADwICwCAAAA4EFYBAAAAMCDsAgAAACAB2ERAAAA
AA/CIgAAAAAehEUAAAAAPAiLAAAAAHgQFgEAAADwICwCAAAA4EFYBAAAAMCDsAgAAACAB2ERAAAA
AA/CIgAAAAAe/g/10lQlA3JSSwAAAABJRU5ErkJggg==

8
Documentation/DocBook/media/v4l/biblio.xml
View file

@ -178,11 +178,3 @@ in the frequency range from 87,5 to 108,0 MHz</title>
</biblioentry>
</bibliography>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

10
Documentation/DocBook/media/v4l/common.xml
View file

@ -1168,6 +1168,8 @@ dheight = format.fmt.pix.height;
</section>
</section>
&sub-selection-api;
<section id="streaming-par">
<title>Streaming Parameters</title>
@ -1195,11 +1197,3 @@ separate parameters for input and output devices.</para>
<para>These ioctls are optional, drivers need not implement
them. If so, they return the &EINVAL;.</para>
</section>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

30
Documentation/DocBook/media/v4l/compat.xml
View file

@ -1082,7 +1082,7 @@ until the time in the timestamp field has arrived. I would like to
follow SGI's lead, and adopt a multimedia timestamping system like
their UST (Unadjusted System Time). See
http://web.archive.org/web/*/http://reality.sgi.com
/cpirazzi_engr/lg/time/intro.html.
/cpirazzi_engr/lg/time/intro.html.
UST uses timestamps that are 64-bit signed integers
(not struct timeval's) and given in nanosecond units. The UST clock
starts at zero when the system is booted and runs continuously and
@ -2376,6 +2376,23 @@ that used it. It was originally scheduled for removal in 2.6.35.
<listitem>
<para>V4L2_CTRL_FLAG_VOLATILE was added to signal volatile controls to userspace.</para>
</listitem>
<listitem>
<para>Add selection API for extended control over cropping and
composing. Does not affect the compatibility of current drivers and
applications. See <link linkend="selection-api"> selection API </link> for
details.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.3</title>
<orderedlist>
<listitem>
<para>Added <constant>V4L2_CID_ALPHA_COMPONENT</constant> control
to the <link linkend="control">User controls class</link>.
</para>
</listitem>
</orderedlist>
</section>
@ -2489,6 +2506,9 @@ ioctls.</para>
<listitem>
<para>&VIDIOC-CREATE-BUFS; and &VIDIOC-PREPARE-BUF; ioctls.</para>
</listitem>
<listitem>
<para>Selection API. <xref linkend="selection-api" /></para>
</listitem>
</itemizedlist>
</section>
@ -2507,11 +2527,3 @@ interfaces and should not be implemented in new drivers.</para>
</itemizedlist>
</section>
</section>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

43
Documentation/DocBook/media/v4l/controls.xml
View file

@ -323,12 +323,6 @@ minimum value disables backlight compensation.</entry>
<entry>Switch on or off the illuminator 1 or 2 of the device
(usually a microscope).</entry>
</row>
<row>
<entry><constant>V4L2_CID_LASTP1</constant></entry>
<entry></entry>
<entry>End of the predefined control IDs (currently
<constant>V4L2_CID_ILLUMINATORS_2</constant> + 1).</entry>
</row>
<row>
<entry><constant>V4L2_CID_MIN_BUFFERS_FOR_CAPTURE</constant></entry>
<entry>integer</entry>
@ -345,6 +339,25 @@ and used as a hint to determine the number of OUTPUT buffers to pass to REQBUFS.
The value is the minimum number of OUTPUT buffers that is necessary for hardware
to work.</entry>
</row>
<row id="v4l2-alpha-component">
<entry><constant>V4L2_CID_ALPHA_COMPONENT</constant></entry>
<entry>integer</entry>
<entry> Sets the alpha color component on the capture device or on
the capture buffer queue of a mem-to-mem device. When a mem-to-mem
device produces frame format that includes an alpha component
(e.g. <link linkend="rgb-formats">packed RGB image formats</link>)
and the alpha value is not defined by the mem-to-mem input data
this control lets you select the alpha component value of all
pixels. It is applicable to any pixel format that contains an alpha
component.
</entry>
</row>
<row>
<entry><constant>V4L2_CID_LASTP1</constant></entry>
<entry></entry>
<entry>End of the predefined control IDs (currently
<constant>V4L2_CID_ALPHA_COMPONENT</constant> + 1).</entry>
</row>
<row>
<entry><constant>V4L2_CID_PRIVATE_BASE</constant></entry>
<entry></entry>
@ -3329,6 +3342,16 @@ interface and may change in the future.</para>
<entry>The short circuit protection of the flash
controller has been triggered.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_OVER_CURRENT</constant></entry>
<entry>Current in the LED power supply has exceeded the limit
specific to the flash controller.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_INDICATOR</constant></entry>
<entry>The flash controller has detected a short or open
circuit condition on the indicator LED.</entry>
</row>
</tbody>
</entrytbl>
</row>
@ -3357,11 +3380,3 @@ interface and may change in the future.</para>
</section>
</section>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "common.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/dev-capture.xml
View file

@ -108,11 +108,3 @@ linkend="mmap">memory mapping</link> or <link
linkend="userp">user pointer</link>) I/O. See <xref
linkend="io" /> for details.</para>
</section>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/dev-codec.xml
View file

@ -16,11 +16,3 @@ Applications send data to be converted to the driver through a
I/O.</para>
<para>[to do]</para>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/dev-effect.xml
View file

@ -15,11 +15,3 @@ receive the result data either with &func-read; and &func-write;
functions, or through the streaming I/O mechanism.</para>
<para>[to do]</para>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/dev-event.xml
View file

@ -41,11 +41,3 @@ intermediate step leading up to that information. See the documentation for the
event you want to subscribe to whether this is applicable for that event or not.</para>
</listitem>
</orderedlist></para>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/dev-osd.xml
View file

@ -154,11 +154,3 @@ data flow. For more information see <xref linkend="crop" />.</para>
however the framebuffer interface of the driver may support the
<constant>FBIOBLANK</constant> ioctl.</para>
</section>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/dev-output.xml
View file

@ -104,11 +104,3 @@ linkend="mmap">memory mapping</link> or <link
linkend="userp">user pointer</link>) I/O. See <xref
linkend="io" /> for details.</para>
</section>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/dev-overlay.xml
View file

@ -369,11 +369,3 @@ reasons. <!-- video4linux-list@redhat.com on 22 Oct 2002 subject
<para>To start or stop the frame buffer overlay applications call
the &VIDIOC-OVERLAY; ioctl.</para>
</section>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/dev-radio.xml
View file

@ -47,11 +47,3 @@ depending on the selected frequency. The &VIDIOC-G-TUNER; or
&VIDIOC-G-MODULATOR; ioctl
reports the supported frequency range.</para>
</section>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/dev-raw-vbi.xml
View file

@ -337,11 +337,3 @@ an &EBUSY; if the required hardware resources are temporarily
unavailable, for example the device is already in use by another
process.</para>
</section>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

16
Documentation/DocBook/media/v4l/dev-rds.xml
View file

@ -29,10 +29,10 @@ returned by the &VIDIOC-QUERYCAP; ioctl. Any tuner that supports RDS
will set the <constant>V4L2_TUNER_CAP_RDS</constant> flag in
the <structfield>capability</structfield> field of &v4l2-tuner;. If
the driver only passes RDS blocks without interpreting the data
the <constant>V4L2_TUNER_SUB_RDS_BLOCK_IO</constant> flag has to be
the <constant>V4L2_TUNER_CAP_RDS_BLOCK_IO</constant> flag has to be
set, see <link linkend="reading-rds-data">Reading RDS data</link>.
For future use the
flag <constant>V4L2_TUNER_SUB_RDS_CONTROLS</constant> has also been
flag <constant>V4L2_TUNER_CAP_RDS_CONTROLS</constant> has also been
defined. However, a driver for a radio tuner with this capability does
not yet exist, so if you are planning to write such a driver you
should discuss this on the linux-media mailing list: &v4l-ml;.</para>
@ -52,9 +52,9 @@ field of &v4l2-modulator;.
In order to enable the RDS transmission one must set the <constant>V4L2_TUNER_SUB_RDS</constant>
bit in the <structfield>txsubchans</structfield> field of &v4l2-modulator;.
If the driver only passes RDS blocks without interpreting the data
the <constant>V4L2_TUNER_SUB_RDS_BLOCK_IO</constant> flag has to be set. If the
the <constant>V4L2_TUNER_CAP_RDS_BLOCK_IO</constant> flag has to be set. If the
tuner is capable of handling RDS entities like program identification codes and radio
text, the flag <constant>V4L2_TUNER_SUB_RDS_CONTROLS</constant> should be set,
text, the flag <constant>V4L2_TUNER_CAP_RDS_CONTROLS</constant> should be set,
see <link linkend="writing-rds-data">Writing RDS data</link> and
<link linkend="fm-tx-controls">FM Transmitter Control Reference</link>.</para>
</section>
@ -194,11 +194,3 @@ as follows:</para>
</tgroup>
</table>
</section>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

9
Documentation/DocBook/media/v4l/dev-sliced-vbi.xml
View file

@ -697,12 +697,3 @@ Sliced VBI services</link> for a description of the line payload.</entry>
</section>
</section>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/dev-teletext.xml
View file

@ -27,11 +27,3 @@ kernel 2.6.37.</para>
<para>Modern devices all use the <link linkend="raw-vbi">raw</link> or
<link linkend="sliced">sliced</link> VBI API.</para>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/driver.xml
View file

@ -198,11 +198,3 @@ devices with the videodev module.</para>
<para>to do</para>
</section>
-->
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/func-close.xml
View file

@ -60,11 +60,3 @@ descriptor.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/func-ioctl.xml
View file

@ -69,11 +69,3 @@ their respective function and parameters are specified in <xref
the parameter remains unmodified.</para>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/func-mmap.xml
View file

@ -181,11 +181,3 @@ complete the request.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/func-munmap.xml
View file

@ -74,11 +74,3 @@ mapped yet.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/func-open.xml
View file

@ -111,11 +111,3 @@ system has been reached.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/func-poll.xml
View file

@ -117,11 +117,3 @@ than <constant>OPEN_MAX</constant>.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/func-read.xml
View file

@ -179,11 +179,3 @@ type of device.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/func-select.xml
View file

@ -128,11 +128,3 @@ zero or greater than <constant>FD_SETSIZE</constant>.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/func-write.xml
View file

@ -126,11 +126,3 @@ type of device.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/io.xml
View file

@ -1282,11 +1282,3 @@ line, top field first. The bottom field is transmitted first.</entry>
</mediaobject>
</figure>
</section>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

7
Documentation/DocBook/media/v4l/libv4l.xml
View file

@ -158,10 +158,3 @@ still don't use libv4l.</para>
</section>
</section>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-grey.xml
View file

@ -60,11 +60,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-m420.xml
View file

@ -137,11 +137,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-nv12.xml
View file

@ -141,11 +141,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
View file

@ -144,11 +144,3 @@ CbCr plane has as many pad bytes after its rows.</para>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-nv12mt.xml
View file

@ -64,11 +64,3 @@ layout of macroblocks</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-nv16.xml
View file

@ -164,11 +164,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

121
Documentation/DocBook/media/v4l/pixfmt-nv24.xml Normal file
View file

@ -0,0 +1,121 @@
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_NV24 ('NV24'), V4L2_PIX_FMT_NV42 ('NV42')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-NV24"><constant>V4L2_PIX_FMT_NV24</constant></refname>
<refname id="V4L2-PIX-FMT-NV42"><constant>V4L2_PIX_FMT_NV42</constant></refname>
<refpurpose>Formats with full horizontal and vertical
chroma resolutions, also known as YUV 4:4:4. One luminance and one
chrominance plane with alternating chroma samples as opposed to
<constant>V4L2_PIX_FMT_YVU420</constant></refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>These are two-plane versions of the YUV 4:4:4 format. The three
components are separated into two sub-images or planes. The Y plane is
first, with each Y sample stored in one byte per pixel. For
<constant>V4L2_PIX_FMT_NV24</constant>, a combined CbCr plane
immediately follows the Y plane in memory. The CbCr plane has the same
width and height, in pixels, as the Y plane (and the image). Each line
contains one CbCr pair per pixel, with each Cb and Cr sample stored in
one byte. <constant>V4L2_PIX_FMT_NV42</constant> is the same except that
the Cb and Cr samples are swapped, the CrCb plane starts with a Cr
sample.</para>
<para>If the Y plane has pad bytes after each row, then the CbCr plane
has twice as many pad bytes after its rows.</para>
<example>
<title><constant>V4L2_PIX_FMT_NV24</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="9" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
<entry>Cb<subscript>02</subscript></entry>
<entry>Cr<subscript>02</subscript></entry>
<entry>Cb<subscript>03</subscript></entry>
<entry>Cr<subscript>03</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
<entry>Cb<subscript>12</subscript></entry>
<entry>Cr<subscript>12</subscript></entry>
<entry>Cb<subscript>13</subscript></entry>
<entry>Cr<subscript>13</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;32:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cr<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
<entry>Cr<subscript>21</subscript></entry>
<entry>Cb<subscript>22</subscript></entry>
<entry>Cr<subscript>22</subscript></entry>
<entry>Cb<subscript>23</subscript></entry>
<entry>Cr<subscript>23</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;40:</entry>
<entry>Cb<subscript>30</subscript></entry>
<entry>Cr<subscript>30</subscript></entry>
<entry>Cb<subscript>31</subscript></entry>
<entry>Cr<subscript>31</subscript></entry>
<entry>Cb<subscript>32</subscript></entry>
<entry>Cr<subscript>32</subscript></entry>
<entry>Cb<subscript>33</subscript></entry>
<entry>Cr<subscript>33</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

15
Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
View file

@ -428,8 +428,11 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
<para>Bit 7 is the most significant bit. The value of a = alpha
bits is undefined when reading from the driver, ignored when writing
to the driver, except when alpha blending has been negotiated for a
<link linkend="overlay">Video Overlay</link> or <link
linkend="osd">Video Output Overlay</link>.</para>
<link linkend="overlay">Video Overlay</link> or <link linkend="osd">
Video Output Overlay</link> or when alpha component has been configured
for a <link linkend="capture">Video Capture</link> by means of <link
linkend="v4l2-alpha-component"> <constant>V4L2_CID_ALPHA_COMPONENT
</constant> </link> control.</para>
<example>
<title><constant>V4L2_PIX_FMT_BGR24</constant> 4 &times; 4 pixel
@ -930,11 +933,3 @@ See &v4l-dvb; for access instructions.</para>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-packed-yuv.xml
View file

@ -234,11 +234,3 @@ linkend="osd">Video Output Overlay</link>.</para>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-sbggr16.xml
View file

@ -81,11 +81,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-sbggr8.xml
View file

@ -65,11 +65,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-sgbrg8.xml
View file

@ -65,11 +65,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-sgrbg8.xml
View file

@ -65,11 +65,3 @@ columns and rows.</para>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-uyvy.xml
View file

@ -118,11 +118,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-vyuy.xml
View file

@ -118,11 +118,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-y16.xml
View file

@ -79,11 +79,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-y41p.xml
View file

@ -147,11 +147,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-yuv410.xml
View file

@ -131,11 +131,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-yuv411p.xml
View file

@ -145,11 +145,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-yuv420.xml
View file

@ -147,11 +147,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml
View file

@ -152,11 +152,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-yuv422p.xml
View file

@ -151,11 +151,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-yuyv.xml
View file

@ -118,11 +118,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/pixfmt-yvyu.xml
View file

@ -118,11 +118,3 @@ pixel image</title>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

14
Documentation/DocBook/media/v4l/pixfmt.xml
View file

@ -714,6 +714,7 @@ information.</para>
&sub-nv12m;
&sub-nv12mt;
&sub-nv16;
&sub-nv24;
&sub-m420;
</section>
@ -890,6 +891,11 @@ kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm
<entry>'M310'</entry>
<entry>Compressed BGGR Bayer format used by the gspca driver.</entry>
</row>
<row id="V4L2-PIX-FMT-JL2005BCD">
<entry><constant>V4L2_PIX_FMT_JL2005BCD</constant></entry>
<entry>'JL20'</entry>
<entry>JPEG compressed RGGB Bayer format used by the gspca driver.</entry>
</row>
<row id="V4L2-PIX-FMT-OV511">
<entry><constant>V4L2_PIX_FMT_OV511</constant></entry>
<entry>'O511'</entry>
@ -997,11 +1003,3 @@ the other bits are set to 0.</entry>
</tgroup>
</table>
</section>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

321
Documentation/DocBook/media/v4l/selection-api.xml Normal file
View file

@ -0,0 +1,321 @@
<section id="selection-api">
<title>Experimental API for cropping, composing and scaling</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<section>
<title>Introduction</title>
<para>Some video capture devices can sample a subsection of a picture and
shrink or enlarge it to an image of arbitrary size. Next, the devices can
insert the image into larger one. Some video output devices can crop part of an
input image, scale it up or down and insert it at an arbitrary scan line and
horizontal offset into a video signal. We call these abilities cropping,
scaling and composing.</para>
<para>On a video <emphasis>capture</emphasis> device the source is a video
signal, and the cropping target determine the area actually sampled. The sink
is an image stored in a memory buffer. The composing area specifies which part
of the buffer is actually written to by the hardware. </para>
<para>On a video <emphasis>output</emphasis> device the source is an image in a
memory buffer, and the cropping target is a part of an image to be shown on a
display. The sink is the display or the graphics screen. The application may
select the part of display where the image should be displayed. The size and
position of such a window is controlled by the compose target.</para>
<para>Rectangles for all cropping and composing targets are defined even if the
device does supports neither cropping nor composing. Their size and position
will be fixed in such a case. If the device does not support scaling then the
cropping and composing rectangles have the same size.</para>
</section>
<section>
<title>Selection targets</title>
<figure id="sel-targets-capture">
<title>Cropping and composing targets</title>
<mediaobject>
<imageobject>
<imagedata fileref="selection.png" format="PNG" />
</imageobject>
<textobject>
<phrase>Targets used by a cropping, composing and scaling
process</phrase>
</textobject>
</mediaobject>
</figure>
</section>
<section>
<title>Configuration</title>
<para>Applications can use the <link linkend="vidioc-g-selection">selection
API</link> to select an area in a video signal or a buffer, and to query for
default settings and hardware limits.</para>
<para>Video hardware can have various cropping, composing and scaling
limitations. It may only scale up or down, support only discrete scaling
factors, or have different scaling abilities in the horizontal and vertical
directions. Also it may not support scaling at all. At the same time the
cropping/composing rectangles may have to be aligned, and both the source and
the sink may have arbitrary upper and lower size limits. Therefore, as usual,
drivers are expected to adjust the requested parameters and return the actual
values selected. An application can control the rounding behaviour using <link
linkend="v4l2-sel-flags"> constraint flags </link>.</para>
<section>
<title>Configuration of video capture</title>
<para>See figure <xref linkend="sel-targets-capture" /> for examples of the
selection targets available for a video capture device. It is recommended to
configure the cropping targets before to the composing targets.</para>
<para>The range of coordinates of the top left corner, width and height of
areas that can be sampled is given by the <constant> V4L2_SEL_TGT_CROP_BOUNDS
</constant> target. It is recommended for the driver developers to put the
top/left corner at position <constant> (0,0) </constant>. The rectangle's
coordinates are expressed in pixels.</para>
<para>The top left corner, width and height of the source rectangle, that is
the area actually sampled, is given by the <constant> V4L2_SEL_TGT_CROP_ACTIVE
</constant> target. It uses the same coordinate system as <constant>
V4L2_SEL_TGT_CROP_BOUNDS </constant>. The active cropping area must lie
completely inside the capture boundaries. The driver may further adjust the
requested size and/or position according to hardware limitations.</para>
<para>Each capture device has a default source rectangle, given by the
<constant> V4L2_SEL_TGT_CROP_DEFAULT </constant> target. This rectangle shall
over what the driver writer considers the complete picture. Drivers shall set
the active crop rectangle to the default when the driver is first loaded, but
not later.</para>
<para>The composing targets refer to a memory buffer. The limits of composing
coordinates are obtained using <constant> V4L2_SEL_TGT_COMPOSE_BOUNDS
</constant>. All coordinates are expressed in pixels. The rectangle's top/left
corner must be located at position <constant> (0,0) </constant>. The width and
height are equal to the image size set by <constant> VIDIOC_S_FMT </constant>.
</para>
<para>The part of a buffer into which the image is inserted by the hardware is
controlled by the <constant> V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target.
The rectangle's coordinates are also expressed in the same coordinate system as
the bounds rectangle. The composing rectangle must lie completely inside bounds
rectangle. The driver must adjust the composing rectangle to fit to the
bounding limits. Moreover, the driver can perform other adjustments according
to hardware limitations. The application can control rounding behaviour using
<link linkend="v4l2-sel-flags"> constraint flags </link>.</para>
<para>For capture devices the default composing rectangle is queried using
<constant> V4L2_SEL_TGT_COMPOSE_DEFAULT </constant>. It is usually equal to the
bounding rectangle.</para>
<para>The part of a buffer that is modified by the hardware is given by
<constant> V4L2_SEL_TGT_COMPOSE_PADDED </constant>. It contains all pixels
defined using <constant> V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> plus all
padding data modified by hardware during insertion process. All pixels outside
this rectangle <emphasis>must not</emphasis> be changed by the hardware. The
content of pixels that lie inside the padded area but outside active area is
undefined. The application can use the padded and active rectangles to detect
where the rubbish pixels are located and remove them if needed.</para>
</section>
<section>
<title>Configuration of video output</title>
<para>For output devices targets and ioctls are used similarly to the video
capture case. The <emphasis> composing </emphasis> rectangle refers to the
insertion of an image into a video signal. The cropping rectangles refer to a
memory buffer. It is recommended to configure the composing targets before to
the cropping targets.</para>
<para>The cropping targets refer to the memory buffer that contains an image to
be inserted into a video signal or graphical screen. The limits of cropping
coordinates are obtained using <constant> V4L2_SEL_TGT_CROP_BOUNDS </constant>.
All coordinates are expressed in pixels. The top/left corner is always point
<constant> (0,0) </constant>. The width and height is equal to the image size
specified using <constant> VIDIOC_S_FMT </constant> ioctl.</para>
<para>The top left corner, width and height of the source rectangle, that is
the area from which image date are processed by the hardware, is given by the
<constant> V4L2_SEL_TGT_CROP_ACTIVE </constant>. Its coordinates are expressed
in in the same coordinate system as the bounds rectangle. The active cropping
area must lie completely inside the crop boundaries and the driver may further
adjust the requested size and/or position according to hardware
limitations.</para>
<para>For output devices the default cropping rectangle is queried using
<constant> V4L2_SEL_TGT_CROP_DEFAULT </constant>. It is usually equal to the
bounding rectangle.</para>
<para>The part of a video signal or graphics display where the image is
inserted by the hardware is controlled by <constant>
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target. The rectangle's coordinates
are expressed in pixels. The composing rectangle must lie completely inside the
bounds rectangle. The driver must adjust the area to fit to the bounding
limits. Moreover, the driver can perform other adjustments according to
hardware limitations. </para>
<para>The device has a default composing rectangle, given by the <constant>
V4L2_SEL_TGT_COMPOSE_DEFAULT </constant> target. This rectangle shall cover what
the driver writer considers the complete picture. It is recommended for the
driver developers to put the top/left corner at position <constant> (0,0)
</constant>. Drivers shall set the active composing rectangle to the default
one when the driver is first loaded.</para>
<para>The devices may introduce additional content to video signal other than
an image from memory buffers. It includes borders around an image. However,
such a padded area is driver-dependent feature not covered by this document.
Driver developers are encouraged to keep padded rectangle equal to active one.
The padded target is accessed by the <constant> V4L2_SEL_TGT_COMPOSE_PADDED
</constant> identifier. It must contain all pixels from the <constant>
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target.</para>
</section>
<section>
<title>Scaling control.</title>
<para>An application can detect if scaling is performed by comparing the width
and the height of rectangles obtained using <constant> V4L2_SEL_TGT_CROP_ACTIVE
</constant> and <constant> V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> targets. If
these are not equal then the scaling is applied. The application can compute
the scaling ratios using these values.</para>
</section>
</section>
<section>
<title>Comparison with old cropping API.</title>
<para>The selection API was introduced to cope with deficiencies of previous
<link linkend="crop"> API </link>, that was designed to control simple capture
devices. Later the cropping API was adopted by video output drivers. The ioctls
are used to select a part of the display were the video signal is inserted. It
should be considered as an API abuse because the described operation is
actually the composing. The selection API makes a clear distinction between
composing and cropping operations by setting the appropriate targets. The V4L2
API lacks any support for composing to and cropping from an image inside a
memory buffer. The application could configure a capture device to fill only a
part of an image by abusing V4L2 API. Cropping a smaller image from a larger
one is achieved by setting the field <structfield>
&v4l2-pix-format;::bytesperline </structfield>. Introducing an image offsets
could be done by modifying field <structfield> &v4l2-buffer;::m:userptr
</structfield> before calling <constant> VIDIOC_QBUF </constant>. Those
operations should be avoided because they are not portable (endianness), and do
not work for macroblock and Bayer formats and mmap buffers. The selection API
deals with configuration of buffer cropping/composing in a clear, intuitive and
portable way. Next, with the selection API the concepts of the padded target
and constraints flags are introduced. Finally, <structname> &v4l2-crop;
</structname> and <structname> &v4l2-cropcap; </structname> have no reserved
fields. Therefore there is no way to extend their functionality. The new
<structname> &v4l2-selection; </structname> provides a lot of place for future
extensions. Driver developers are encouraged to implement only selection API.
The former cropping API would be simulated using the new one. </para>
</section>
<section>
<title>Examples</title>
<example>
<title>Resetting the cropping parameters</title>
<para>(A video capture device is assumed; change <constant>
V4L2_BUF_TYPE_VIDEO_CAPTURE </constant> for other devices; change target to
<constant> V4L2_SEL_TGT_COMPOSE_* </constant> family to configure composing
area)</para>
<programlisting>
&v4l2-selection; sel = {
.type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
.target = V4L2_SEL_TGT_CROP_DEFAULT,
};
ret = ioctl(fd, &VIDIOC-G-SELECTION;, &amp;sel);
if (ret)
exit(-1);
sel.target = V4L2_SEL_TGT_CROP_ACTIVE;
ret = ioctl(fd, &VIDIOC-S-SELECTION;, &amp;sel);
if (ret)
exit(-1);
</programlisting>
</example>
<example>
<title>Simple downscaling</title>
<para>Setting a composing area on output of size of <emphasis> at most
</emphasis> half of limit placed at a center of a display.</para>
<programlisting>
&v4l2-selection; sel = {
.type = V4L2_BUF_TYPE_VIDEO_OUTPUT,
.target = V4L2_SEL_TGT_COMPOSE_BOUNDS,
};
struct v4l2_rect r;
ret = ioctl(fd, &VIDIOC-G-SELECTION;, &amp;sel);
if (ret)
exit(-1);
/* setting smaller compose rectangle */
r.width = sel.r.width / 2;
r.height = sel.r.height / 2;
r.left = sel.r.width / 4;
r.top = sel.r.height / 4;
sel.r = r;
sel.target = V4L2_SEL_TGT_COMPOSE_ACTIVE;
sel.flags = V4L2_SEL_FLAG_LE;
ret = ioctl(fd, &VIDIOC-S-SELECTION;, &amp;sel);
if (ret)
exit(-1);
</programlisting>
</example>
<example>
<title>Querying for scaling factors</title>
<para>A video output device is assumed; change <constant>
V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> for other devices</para>
<programlisting>
&v4l2-selection; compose = {
.type = V4L2_BUF_TYPE_VIDEO_OUTPUT,
.target = V4L2_SEL_TGT_COMPOSE_ACTIVE,
};
&v4l2-selection; crop = {
.type = V4L2_BUF_TYPE_VIDEO_OUTPUT,
.target = V4L2_SEL_TGT_CROP_ACTIVE,
};
double hscale, vscale;
ret = ioctl(fd, &VIDIOC-G-SELECTION;, &amp;compose);
if (ret)
exit(-1);
ret = ioctl(fd, &VIDIOC-G-SELECTION;, &amp;crop);
if (ret)
exit(-1);
/* computing scaling factors */
hscale = (double)compose.r.width / crop.r.width;
vscale = (double)compose.r.height / crop.r.height;
</programlisting>
</example>
</section>
</section>

1
Documentation/DocBook/media/v4l/v4l2.xml
View file

@ -501,6 +501,7 @@ and discussions on the V4L mailing list.</revremark>
&sub-g-output;
&sub-g-parm;
&sub-g-priority;
&sub-g-selection;
&sub-g-sliced-vbi-cap;
&sub-g-std;
&sub-g-tuner;

8
Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml
View file

@ -228,11 +228,3 @@ is out of bounds.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml
View file

@ -156,11 +156,3 @@ bounds.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/vidioc-enuminput.xml
View file

@ -311,11 +311,3 @@ out of bounds.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/vidioc-enumoutput.xml
View file

@ -196,11 +196,3 @@ is out of bounds.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/vidioc-enumstd.xml
View file

@ -381,11 +381,3 @@ is out of bounds.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml
View file

@ -127,11 +127,3 @@ this control belongs to.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

25
Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
View file

@ -183,7 +183,12 @@ applications must set the array to zero.</entry>
<entry>__u32</entry>
<entry><structfield>ctrl_class</structfield></entry>
<entry>The control class to which all controls belong, see
<xref linkend="ctrl-class" />.</entry>
<xref linkend="ctrl-class" />. Drivers that use a kernel framework for handling
controls will also accept a value of 0 here, meaning that the controls can
belong to any control class. Whether drivers support this can be tested by setting
<structfield>ctrl_class</structfield> to 0 and calling <constant>VIDIOC_TRY_EXT_CTRLS</constant>
with a <structfield>count</structfield> of 0. If that succeeds, then the driver
supports this feature.</entry>
</row>
<row>
<entry>__u32</entry>
@ -194,10 +199,13 @@ also be zero.</entry>
<row>
<entry>__u32</entry>
<entry><structfield>error_idx</structfield></entry>
<entry>Set by the driver in case of an error. It is the
index of the control causing the error or equal to 'count' when the
error is not associated with a particular control. Undefined when the
ioctl returns 0 (success).</entry>
<entry>Set by the driver in case of an error. If it is equal
to <structfield>count</structfield>, then no actual changes were made to
controls. In other words, the error was not associated with setting a particular
control. If it is another value, then only the controls up to <structfield>error_idx-1</structfield>
were modified and control <structfield>error_idx</structfield> is the one that
caused the error. The <structfield>error_idx</structfield> value is undefined
if the ioctl returned 0 (success).</entry>
</row>
<row>
<entry>__u32</entry>
@ -312,10 +320,3 @@ to store the payload and this error code is returned.</para>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

35
Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml
View file

@ -295,7 +295,8 @@ set this field to zero.</entry>
<entry>The device is capable of non-destructive overlays.
When the driver clears this flag, only destructive overlays are
supported. There are no drivers yet which support both destructive and
non-destructive overlays.</entry>
non-destructive overlays. Video Output Overlays are in practice always
non-destructive.</entry>
</row>
<row>
<entry><constant>V4L2_FBUF_CAP_CHROMAKEY</constant></entry>
@ -339,8 +340,8 @@ blending makes no sense for destructive overlays.</entry>
<row>
<entry><constant>V4L2_FBUF_CAP_SRC_CHROMAKEY</constant></entry>
<entry>0x0080</entry>
<entry>The device supports Source Chroma-keying. Framebuffer pixels
with the chroma-key colors are replaced by video pixels, which is exactly opposite of
<entry>The device supports Source Chroma-keying. Video pixels
with the chroma-key colors are replaced by framebuffer pixels, which is exactly opposite of
<constant>V4L2_FBUF_CAP_CHROMAKEY</constant></entry>
</row>
</tbody>
@ -356,21 +357,27 @@ with the chroma-key colors are replaced by video pixels, which is exactly opposi
<entry><constant>V4L2_FBUF_FLAG_PRIMARY</constant></entry>
<entry>0x0001</entry>
<entry>The framebuffer is the primary graphics surface.
In other words, the overlay is destructive. [?]</entry>
In other words, the overlay is destructive. This flag is typically set by any
driver that doesn't have the <constant>V4L2_FBUF_CAP_EXTERNOVERLAY</constant>
capability and it is cleared otherwise.</entry>
</row>
<row>
<entry><constant>V4L2_FBUF_FLAG_OVERLAY</constant></entry>
<entry>0x0002</entry>
<entry>The frame buffer is an overlay surface the same
size as the capture. [?]</entry>
</row>
<row>
<entry spanname="hspan">The purpose of
<constant>V4L2_FBUF_FLAG_PRIMARY</constant> and
<constant>V4L2_FBUF_FLAG_OVERLAY</constant> was never quite clear.
Most drivers seem to ignore these flags. For compatibility with the
<wordasword>bttv</wordasword> driver applications should set the
<constant>V4L2_FBUF_FLAG_OVERLAY</constant> flag.</entry>
<entry>If this flag is set for a video capture device, then the
driver will set the initial overlay size to cover the full framebuffer size,
otherwise the existing overlay size (as set by &VIDIOC-S-FMT;) will be used.
Only one video capture driver (bttv) supports this flag. The use of this flag
for capture devices is deprecated. There is no way to detect which drivers
support this flag, so the only reliable method of setting the overlay size is
through &VIDIOC-S-FMT;.
If this flag is set for a video output device, then the video output overlay
window is relative to the top-left corner of the framebuffer and restricted
to the size of the framebuffer. If it is cleared, then the video output
overlay window is relative to the video output display.
</entry>
</row>
<row>
<entry><constant>V4L2_FBUF_FLAG_CHROMAKEY</constant></entry>

15
Documentation/DocBook/media/v4l/vidioc-g-frequency.xml
View file

@ -98,8 +98,11 @@ the &v4l2-output; <structfield>modulator</structfield> field and the
<entry>&v4l2-tuner-type;</entry>
<entry><structfield>type</structfield></entry>
<entry>The tuner type. This is the same value as in the
&v4l2-tuner; <structfield>type</structfield> field. The field is not
applicable to modulators, &ie; ignored by drivers.</entry>
&v4l2-tuner; <structfield>type</structfield> field. The type must be set
to <constant>V4L2_TUNER_RADIO</constant> for <filename>/dev/radioX</filename>
device nodes, and to <constant>V4L2_TUNER_ANALOG_TV</constant>
for all others. The field is not applicable to modulators, &ie; ignored
by drivers.</entry>
</row>
<row>
<entry>__u32</entry>
@ -135,11 +138,3 @@ wrong.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

4
Documentation/DocBook/media/v4l/vidioc-g-input.xml
View file

@ -61,8 +61,8 @@ desired input in an integer and call the
<constant>VIDIOC_S_INPUT</constant> ioctl with a pointer to this
integer. Side effects are possible. For example inputs may support
different video standards, so the driver may implicitly switch the
current standard. It is good practice to select an input before
querying or negotiating any other parameters.</para>
current standard. Because of these possible side effects applications
must select an input before querying or negotiating any other parameters.</para>
<para>Information about video inputs is available using the
&VIDIOC-ENUMINPUT; ioctl.</para>

8
Documentation/DocBook/media/v4l/vidioc-g-modulator.xml
View file

@ -236,11 +236,3 @@ mode.</entry>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

5
Documentation/DocBook/media/v4l/vidioc-g-output.xml
View file

@ -61,8 +61,9 @@ desired output in an integer and call the
<constant>VIDIOC_S_OUTPUT</constant> ioctl with a pointer to this integer.
Side effects are possible. For example outputs may support different
video standards, so the driver may implicitly switch the current
standard. It is good practice to select an output before querying or
negotiating any other parameters.</para>
standard.
standard. Because of these possible side effects applications
must select an output before querying or negotiating any other parameters.</para>
<para>Information about video outputs is available using the
&VIDIOC-ENUMOUTPUT; ioctl.</para>

8
Documentation/DocBook/media/v4l/vidioc-g-priority.xml
View file

@ -133,11 +133,3 @@ priority.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

304
Documentation/DocBook/media/v4l/vidioc-g-selection.xml Normal file
View file

@ -0,0 +1,304 @@
<refentry id="vidioc-g-selection">
<refmeta>
<refentrytitle>ioctl VIDIOC_G_SELECTION, VIDIOC_S_SELECTION</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_G_SELECTION</refname>
<refname>VIDIOC_S_SELECTION</refname>
<refpurpose>Get or set one of the selection rectangles</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>struct v4l2_selection *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_G_SELECTION, VIDIOC_S_SELECTION</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
interface and may change in the future.</para>
</note>
<para>The ioctls are used to query and configure selection rectangles.</para>
<para> To query the cropping (composing) rectangle set <structfield>
&v4l2-selection;::type </structfield> to the respective buffer type. Do not
use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE
</constant> instead of <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of
<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is
setting <structfield> &v4l2-selection;::target </structfield> to value
<constant> V4L2_SEL_TGT_CROP_ACTIVE </constant> (<constant>
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant>). Please refer to table <xref
linkend="v4l2-sel-target" /> or <xref linkend="selection-api" /> for additional
targets. Fields <structfield> &v4l2-selection;::flags </structfield> and
<structfield> &v4l2-selection;::reserved </structfield> are ignored and they
must be filled with zeros. The driver fills the rest of the structure or
returns &EINVAL; if incorrect buffer type or target was used. If cropping
(composing) is not supported then the active rectangle is not mutable and it is
always equal to the bounds rectangle. Finally, structure <structfield>
&v4l2-selection;::r </structfield> is filled with the current cropping
(composing) coordinates. The coordinates are expressed in driver-dependent
units. The only exception are rectangles for images in raw formats, whose
coordinates are always expressed in pixels. </para>
<para> To change the cropping (composing) rectangle set <structfield>
&v4l2-selection;::type </structfield> to the respective buffer type. Do not
use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE
</constant> instead of <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of
<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is
setting <structfield> &v4l2-selection;::target </structfield> to value
<constant> V4L2_SEL_TGT_CROP_ACTIVE </constant> (<constant>
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant>). Please refer to table <xref
linkend="v4l2-sel-target" /> or <xref linkend="selection-api" /> for additional
targets. Set desired active area into the field <structfield>
&v4l2-selection;::r </structfield>. Field <structfield>
&v4l2-selection;::reserved </structfield> is ignored and must be filled with
zeros. The driver may adjust the rectangle coordinates. An application may
introduce constraints to control rounding behaviour. Set the field
<structfield> &v4l2-selection;::flags </structfield> to one of values:
<itemizedlist>
<listitem>
<para><constant>0</constant> - The driver can adjust the rectangle size freely
and shall choose a crop/compose rectangle as close as possible to the requested
one.</para>
</listitem>
<listitem>
<para><constant>V4L2_SEL_FLAG_GE</constant> - The driver is not allowed to
shrink the rectangle. The original rectangle must lay inside the adjusted
one.</para>
</listitem>
<listitem>
<para><constant>V4L2_SEL_FLAG_LE</constant> - The driver is not allowed to
enlarge the rectangle. The adjusted rectangle must lay inside the original
one.</para>
</listitem>
<listitem>
<para><constant>V4L2_SEL_FLAG_GE | V4L2_SEL_FLAG_LE</constant> - The driver
must choose the size exactly the same as in the requested rectangle.</para>
</listitem>
</itemizedlist>
Please refer to <xref linkend="sel-const-adjust" />.
</para>
<para> The driver may have to adjusts the requested dimensions against hardware
limits and other parts as the pipeline, i.e. the bounds given by the
capture/output window or TV display. The closest possible values of horizontal
and vertical offset and sizes are chosen according to following priority:
<orderedlist>
<listitem>
<para>Satisfy constraints from <structfield>&v4l2-selection;::flags</structfield>.</para>
</listitem>
<listitem>
<para>Adjust width, height, left, and top to hardware limits and alignments.</para>
</listitem>
<listitem>
<para>Keep center of adjusted rectangle as close as possible to the original one.</para>
</listitem>
<listitem>
<para>Keep width and height as close as possible to original ones.</para>
</listitem>
<listitem>
<para>Keep horizontal and vertical offset as close as possible to original ones.</para>
</listitem>
</orderedlist>
On success the field <structfield> &v4l2-selection;::r </structfield> contains
the adjusted rectangle. When the parameters are unsuitable the application may
modify the cropping (composing) or image parameters and repeat the cycle until
satisfactory parameters have been negotiated. If constraints flags have to be
violated at then ERANGE is returned. The error indicates that <emphasis> there
exist no rectangle </emphasis> that satisfies the constraints.</para>
</refsect1>
<refsect1>
<table frame="none" pgwide="1" id="v4l2-sel-target">
<title>Selection targets.</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_SEL_TGT_CROP_ACTIVE</constant></entry>
<entry>0</entry>
<entry>area that is currently cropped by hardware</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_CROP_DEFAULT</constant></entry>
<entry>1</entry>
<entry>suggested cropping rectangle that covers the "whole picture"</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_CROP_BOUNDS</constant></entry>
<entry>2</entry>
<entry>limits for the cropping rectangle</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_ACTIVE</constant></entry>
<entry>256</entry>
<entry>area to which data are composed by hardware</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_DEFAULT</constant></entry>
<entry>257</entry>
<entry>suggested composing rectangle that covers the "whole picture"</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_BOUNDS</constant></entry>
<entry>258</entry>
<entry>limits for the composing rectangle</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_PADDED</constant></entry>
<entry>259</entry>
<entry>the active area and all padding pixels that are inserted or modified by the hardware</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
<table frame="none" pgwide="1" id="v4l2-sel-flags">
<title>Selection constraint flags</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_SEL_FLAG_GE</constant></entry>
<entry>0x00000001</entry>
<entry>indicate that adjusted rectangle must contain a rectangle from <structfield>&v4l2-selection;::r</structfield></entry>
</row>
<row>
<entry><constant>V4L2_SEL_FLAG_LE</constant></entry>
<entry>0x00000002</entry>
<entry>indicate that adjusted rectangle must be inside a rectangle from <structfield>&v4l2-selection;::r</structfield></entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<section>
<figure id="sel-const-adjust">
<title>Size adjustments with constraint flags.</title>
<mediaobject>
<imageobject>
<imagedata fileref="constraints.png" format="PNG" />
</imageobject>
<textobject>
<phrase>Behaviour of rectangle adjustment for different constraint
flags.</phrase>
</textobject>
</mediaobject>
</figure>
</section>
<refsect1>
<table pgwide="1" frame="none" id="v4l2-selection">
<title>struct <structname>v4l2_selection</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry>Type of the buffer (from &v4l2-buf-type;)</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>target</structfield></entry>
<entry>used to select between <link linkend="v4l2-sel-target"> cropping and composing rectangles </link></entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>control over coordinates adjustments, refer to <link linkend="v4l2-sel-flags">selection flags</link></entry>
</row>
<row>
<entry>&v4l2-rect;</entry>
<entry><structfield>r</structfield></entry>
<entry>selection rectangle</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved[9]</structfield></entry>
<entry>Reserved fields for future use</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The buffer <structfield> &v4l2-selection;::type </structfield>
or <structfield> &v4l2-selection;::target </structfield> is not supported, or
the <structfield> &v4l2-selection;::flags </structfield> are invalid.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ERANGE</errorcode></term>
<listitem>
<para>it is not possible to adjust a rectangle <structfield>
&v4l2-selection;::r </structfield> that satisfies all contraints from
<structfield> &v4l2-selection;::flags </structfield>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>it is not possible to apply change of selection rectangle at the moment.
Usually because streaming is in progress.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

8
Documentation/DocBook/media/v4l/vidioc-g-std.xml
View file

@ -88,11 +88,3 @@ standards.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

18
Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
View file

@ -318,6 +318,16 @@ standard.</para><!-- FIXME what if PAL+NTSC and Bi but not SAP? --></entry>
<entry>RDS capture is supported. This capability is only valid for
radio tuners.</entry>
</row>
<row>
<entry><constant>V4L2_TUNER_CAP_RDS_BLOCK_IO</constant></entry>
<entry>0x0100</entry>
<entry>The RDS data is passed as unparsed RDS blocks.</entry>
</row>
<row>
<entry><constant>V4L2_TUNER_CAP_RDS_CONTROLS</constant></entry>
<entry>0x0200</entry>
<entry>The RDS data is parsed by the hardware and set via controls.</entry>
</row>
</tbody>
</tgroup>
</table>
@ -525,11 +535,3 @@ out of bounds.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/vidioc-querybuf.xml
View file

@ -100,11 +100,3 @@ supported, or the <structfield>index</structfield> is out of bounds.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/vidioc-queryctrl.xml
View file

@ -443,11 +443,3 @@ or this particular menu item is not supported by the driver.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
View file

@ -125,11 +125,3 @@ wrong.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

55
Documentation/acpi/apei/einj.txt
View file

@ -47,20 +47,53 @@ directory apei/einj. The following files are provided.
- param1
This file is used to set the first error parameter value. Effect of
parameter depends on error_type specified. For memory error, this is
physical memory address. Only available if param_extension module
parameter is specified.
parameter depends on error_type specified.
- param2
This file is used to set the second error parameter value. Effect of
parameter depends on error_type specified. For memory error, this is
physical memory address mask. Only available if param_extension
module parameter is specified.
parameter depends on error_type specified.
BIOS versions based in the ACPI 4.0 specification have limited options
to control where the errors are injected. Your BIOS may support an
extension (enabled with the param_extension=1 module parameter, or
boot command line einj.param_extension=1). This allows the address
and mask for memory injections to be specified by the param1 and
param2 files in apei/einj.
BIOS versions using the ACPI 5.0 specification have more control over
the target of the injection. For processor related errors (type 0x1,
0x2 and 0x4) the APICID of the target should be provided using the
param1 file in apei/einj. For memory errors (type 0x8, 0x10 and 0x20)
the address is set using param1 with a mask in param2 (0x0 is equivalent
to all ones). For PCI express errors (type 0x40, 0x80 and 0x100) the
segment, bus, device and function are specified using param1:
31 24 23 16 15 11 10 8 7 0
+-------------------------------------------------+
| segment | bus | device | function | reserved |
+-------------------------------------------------+
An ACPI 5.0 BIOS may also allow vendor specific errors to be injected.
In this case a file named vendor will contain identifying information
from the BIOS that hopefully will allow an application wishing to use
the vendor specific extension to tell that they are running on a BIOS
that supports it. All vendor extensions have the 0x80000000 bit set in
error_type. A file vendor_flags controls the interpretation of param1
and param2 (1 = PROCESSOR, 2 = MEMORY, 4 = PCI). See your BIOS vendor
documentation for details (and expect changes to this API if vendors
creativity in using this feature expands beyond our expectations).
Example:
# cd /sys/kernel/debug/apei/einj
# cat available_error_type # See which errors can be injected
0x00000002 Processor Uncorrectable non-fatal
0x00000008 Memory Correctable
0x00000010 Memory Uncorrectable non-fatal
# echo 0x12345000 > param1 # Set memory address for injection
# echo 0xfffffffffffff000 > param2 # Mask - anywhere in this page
# echo 0x8 > error_type # Choose correctable memory error
# echo 1 > error_inject # Inject now
Injecting parameter support is a BIOS version specific extension, that
is, it only works on some BIOS version. If you want to use it, please
make sure your BIOS version has the proper support and specify
"param_extension=y" in module parameter.
For more information about EINJ, please refer to ACPI specification
version 4.0, section 17.5.
version 4.0, section 17.5 and ACPI 5.0, section 18.6.

10
Documentation/coccinelle.txt
View file

@ -102,9 +102,15 @@ or
make coccicheck COCCI=<my_SP.cocci> MODE=report
Using Coccinelle on (modified) files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Controlling Which Files are Processed by Coccinelle
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By default the entire kernel source tree is checked.
To apply Coccinelle to a specific directory, M= can be used.
For example, to check drivers/net/wireless/ one may write:
make coccicheck M=drivers/net/wireless/
To apply Coccinelle on a file basis, instead of a directory basis, the
following command may be used:

14
Documentation/devicetree/bindings/dma/atmel-dma.txt Normal file
View file

@ -0,0 +1,14 @@
* Atmel Direct Memory Access Controller (DMA)
Required properties:
- compatible: Should be "atmel,<chip>-dma"
- reg: Should contain DMA registers location and length
- interrupts: Should contain DMA interrupt
Examples:
dma@ffffec00 {
compatible = "atmel,at91sam9g45-dma";
reg = <0xffffec00 0x200>;
interrupts = <21>;
};

30
Documentation/devicetree/bindings/i2c/omap-i2c.txt Normal file
View file

@ -0,0 +1,30 @@
I2C for OMAP platforms
Required properties :
- compatible : Must be "ti,omap3-i2c" or "ti,omap4-i2c"
- ti,hwmods : Must be "i2c<n>", n being the instance number (1-based)
- #address-cells = <1>;
- #size-cells = <0>;
Recommended properties :
- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise
the default 100 kHz frequency will be used.
Optional properties:
- Child nodes conforming to i2c bus binding
Note: Current implementation will fetch base address, irq and dma
from omap hwmod data base during device registration.
Future plan is to migrate hwmod data base contents into device tree
blob so that, all the required data will be used from device tree dts
file.
Examples :
i2c1: i2c@0 {
compatible = "ti,omap3-i2c";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c1";
clock-frequency = <400000>;
};

78
Documentation/devicetree/bindings/mfd/mc13xxx.txt Normal file
View file

@ -0,0 +1,78 @@
* Freescale MC13783/MC13892 Power Management Integrated Circuit (PMIC)
Required properties:
- compatible : Should be "fsl,mc13783" or "fsl,mc13892"
Optional properties:
- fsl,mc13xxx-uses-adc : Indicate the ADC is being used
- fsl,mc13xxx-uses-codec : Indicate the Audio Codec is being used
- fsl,mc13xxx-uses-rtc : Indicate the RTC is being used
- fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used
Sub-nodes:
- regulators : Contain the regulator nodes. The MC13892 regulators are
bound using their names as listed below with their registers and bits
for enabling.
vcoincell : regulator VCOINCELL (register 13, bit 23)
sw1 : regulator SW1 (register 24, bit 0)
sw2 : regulator SW2 (register 25, bit 0)
sw3 : regulator SW3 (register 26, bit 0)
sw4 : regulator SW4 (register 27, bit 0)
swbst : regulator SWBST (register 29, bit 20)
vgen1 : regulator VGEN1 (register 32, bit 0)
viohi : regulator VIOHI (register 32, bit 3)
vdig : regulator VDIG (register 32, bit 9)
vgen2 : regulator VGEN2 (register 32, bit 12)
vpll : regulator VPLL (register 32, bit 15)
vusb2 : regulator VUSB2 (register 32, bit 18)
vgen3 : regulator VGEN3 (register 33, bit 0)
vcam : regulator VCAM (register 33, bit 6)
vvideo : regulator VVIDEO (register 33, bit 12)
vaudio : regulator VAUDIO (register 33, bit 15)
vsd : regulator VSD (register 33, bit 18)
gpo1 : regulator GPO1 (register 34, bit 6)
gpo2 : regulator GPO2 (register 34, bit 8)
gpo3 : regulator GPO3 (register 34, bit 10)
gpo4 : regulator GPO4 (register 34, bit 12)
pwgt1spi : regulator PWGT1SPI (register 34, bit 15)
pwgt2spi : regulator PWGT2SPI (register 34, bit 16)
vusb : regulator VUSB (register 50, bit 3)
The bindings details of individual regulator device can be found in:
Documentation/devicetree/bindings/regulator/regulator.txt
Examples:
ecspi@70010000 { /* ECSPI1 */
fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
<&gpio3 25 0>; /* GPIO4_25 */
status = "okay";
pmic: mc13892@0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mc13892";
spi-max-frequency = <6000000>;
reg = <0>;
interrupt-parent = <&gpio0>;
interrupts = <8>;
regulators {
sw1_reg: mc13892__sw1 {
regulator-min-microvolt = <600000>;
regulator-max-microvolt = <1375000>;
regulator-boot-on;
regulator-always-on;
};
sw2_reg: mc13892__sw2 {
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <1850000>;
regulator-boot-on;
regulator-always-on;
};
};
};
};

47
Documentation/devicetree/bindings/mfd/twl-familly.txt Normal file
View file

@ -0,0 +1,47 @@
Texas Instruments TWL family
The TWLs are Integrated Power Management Chips.
Some version might contain much more analog function like
USB transceiver or Audio amplifier.
These chips are connected to an i2c bus.
Required properties:
- compatible : Must be "ti,twl4030";
For Integrated power-management/audio CODEC device used in OMAP3
based boards
- compatible : Must be "ti,twl6030";
For Integrated power-management used in OMAP4 based boards
- interrupts : This i2c device has an IRQ line connected to the main SoC
- interrupt-controller : Since the twl support several interrupts internally,
it is considered as an interrupt controller cascaded to the SoC one.
- #interrupt-cells = <1>;
- interrupt-parent : The parent interrupt controller.
Optional node:
- Child nodes contain in the twl. The twl family is made of several variants
that support a different number of features.
The children nodes will thus depend of the capability of the variant.
Example:
/*
* Integrated Power Management Chip
* http://www.ti.com/lit/ds/symlink/twl6030.pdf
*/
twl@48 {
compatible = "ti,twl6030";
reg = <0x48>;
interrupts = <39>; /* IRQ_SYS_1N cascaded to gic */
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&gic>;
#address-cells = <1>;
#size-cells = <0>;
twl_rtc {
compatible = "ti,twl_rtc";
interrupts = <11>;
reg = <0>;
};
};

54
Documentation/devicetree/bindings/resource-names.txt Normal file
View file

@ -0,0 +1,54 @@
Some properties contain an ordered list of 1 or more datum which are
normally accessed by index. However, some devices will have multiple
values which are more naturally accessed by name. Device nodes can
include a supplemental property for assigning names to each of the list
items. The names property consists of a list of strings in the same
order as the data in the resource property.
The following supplemental names properties are defined.
Resource Property Supplemental Names Property
----------------- ---------------------------
reg reg-names
clocks clock-names
interrupts interrupt-names
Usage:
The -names property must be used in conjunction with the normal resource
property. If not it will be ignored.
Examples:
l4-abe {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x48000000 0x00001000>, /* MPU path */
<1 0 0x49000000 0x00001000>; /* L3 path */
mcasp {
compatible = "ti,mcasp";
reg = <0 0x10 0x10>, <0 0x20 0x10>,
<1 0x10 0x10>, <1 0x20 0x10>;
reg-names = "mpu", "dat",
"dma", "dma_dat";
interrupts = <11>, <12>;
interrupt-names = "rx", "tx";
};
timer {
compatible = "ti,timer";
reg = <0 0x40 0x10>, <1 0x40 0x10>;
reg-names = "mpu", "dma";
};
};
usb {
compatible = "ti,usb-host";
reg = <0x4a064000 0x800>, <0x4a064800 0x200>,
<0x4a064c00 0x200>;
reg-names = "config", "ohci", "ehci";
interrupts = <14>, <15>;
interrupt-names = "ohci", "ehci";
};

4
Documentation/dma-buf-sharing.txt
View file

@ -219,6 +219,10 @@ NOTES:
If the exporter chooses not to allow an attach() operation once a
map_dma_buf() API has been called, it simply returns an error.
Miscellaneous notes:
- Any exporters or users of the dma-buf buffer sharing framework must have
a 'select DMA_SHARED_BUFFER' in their respective Kconfigs.
References:
[1] struct dma_buf_ops in include/linux/dma-buf.h
[2] All interfaces mentioned above defined in include/linux/dma-buf.h

8
Documentation/dmaengine.txt
View file

@ -75,6 +75,10 @@ The slave DMA usage consists of following steps:
slave_sg - DMA a list of scatter gather buffers from/to a peripheral
dma_cyclic - Perform a cyclic DMA operation from/to a peripheral till the
operation is explicitly stopped.
interleaved_dma - This is common to Slave as well as M2M clients. For slave
address of devices' fifo could be already known to the driver.
Various types of operations could be expressed by setting
appropriate values to the 'dma_interleaved_template' members.
A non-NULL return of this transfer API represents a "descriptor" for
the given transaction.
@ -89,6 +93,10 @@ The slave DMA usage consists of following steps:
struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
size_t period_len, enum dma_data_direction direction);
struct dma_async_tx_descriptor *(*device_prep_interleaved_dma)(
struct dma_chan *chan, struct dma_interleaved_template *xt,
unsigned long flags);
The peripheral driver is expected to have mapped the scatterlist for
the DMA operation prior to calling device_prep_slave_sg, and must
keep the scatterlist mapped until the DMA operation has completed.

42
Documentation/dvb/get_dvb_firmware
View file

@ -27,8 +27,8 @@ use IO::Handle;
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
"af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
"lme2510c_s7395_old", "drxk", "drxk_terratec_h5", "tda10071",
"it9135" );
"lme2510c_s7395_old", "drxk", "drxk_terratec_h5",
"drxk_hauppauge_hvr930c", "tda10071", "it9135", "it9137");
# Check args
syntax() if (scalar(@ARGV) != 1);
@ -644,6 +644,24 @@ sub drxk {
"$fwfile"
}
sub drxk_hauppauge_hvr930c {
my $url = "http://www.wintvcd.co.uk/drivers/";
my $zipfile = "HVR-9x0_5_10_325_28153_SIGNED.zip";
my $hash = "83ab82e7e9480ec8bf1ae0155ca63c88";
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
my $drvfile = "HVR-900/emOEM.sys";
my $fwfile = "dvb-usb-hauppauge-hvr930c-drxk.fw";
checkstandard();
wgetfile($zipfile, $url . $zipfile);
verify($zipfile, $hash);
unzip($zipfile, $tmpdir);
extract("$tmpdir/$drvfile", 0x117b0, 42692, "$fwfile");
"$fwfile"
}
sub drxk_terratec_h5 {
my $url = "http://www.linuxtv.org/downloads/firmware/";
my $hash = "19000dada8e2741162ccc50cc91fa7f1";
@ -658,6 +676,26 @@ sub drxk_terratec_h5 {
}
sub it9135 {
my $sourcefile = "dvb-usb-it9135.zip";
my $url = "http://www.ite.com.tw/uploads/firmware/v3.6.0.0/$sourcefile";
my $hash = "1e55f6c8833f1d0ae067c2bb2953e6a9";
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0);
my $outfile = "dvb-usb-it9135.fw";
my $fwfile1 = "dvb-usb-it9135-01.fw";
my $fwfile2 = "dvb-usb-it9135-02.fw";
checkstandard();
wgetfile($sourcefile, $url);
unzip($sourcefile, $tmpdir);
verify("$tmpdir/$outfile", $hash);
extract("$tmpdir/$outfile", 64, 8128, "$fwfile1");
extract("$tmpdir/$outfile", 12866, 5817, "$fwfile2");
"$fwfile1 $fwfile2"
}
sub it9137 {
my $url = "http://kworld.server261.com/kworld/CD/ITE_TiVme/V1.00/";
my $zipfile = "Driver_V10.323.1.0412.100412.zip";
my $hash = "79b597dc648698ed6820845c0c9d0d37";

306
Documentation/fb/api.txt Normal file
View file

@ -0,0 +1,306 @@
The Frame Buffer Device API
---------------------------
Last revised: June 21, 2011
0. Introduction
---------------
This document describes the frame buffer API used by applications to interact
with frame buffer devices. In-kernel APIs between device drivers and the frame
buffer core are not described.
Due to a lack of documentation in the original frame buffer API, drivers
behaviours differ in subtle (and not so subtle) ways. This document describes
the recommended API implementation, but applications should be prepared to
deal with different behaviours.
1. Capabilities
---------------
Device and driver capabilities are reported in the fixed screen information
capabilities field.
struct fb_fix_screeninfo {
...
__u16 capabilities; /* see FB_CAP_* */
...
};
Application should use those capabilities to find out what features they can
expect from the device and driver.
- FB_CAP_FOURCC
The driver supports the four character code (FOURCC) based format setting API.
When supported, formats are configured using a FOURCC instead of manually
specifying color components layout.
2. Types and visuals
--------------------
Pixels are stored in memory in hardware-dependent formats. Applications need
to be aware of the pixel storage format in order to write image data to the
frame buffer memory in the format expected by the hardware.
Formats are described by frame buffer types and visuals. Some visuals require
additional information, which are stored in the variable screen information
bits_per_pixel, grayscale, red, green, blue and transp fields.
Visuals describe how color information is encoded and assembled to create
macropixels. Types describe how macropixels are stored in memory. The following
types and visuals are supported.
- FB_TYPE_PACKED_PIXELS
Macropixels are stored contiguously in a single plane. If the number of bits
per macropixel is not a multiple of 8, whether macropixels are padded to the
next multiple of 8 bits or packed together into bytes depends on the visual.
Padding at end of lines may be present and is then reported through the fixed
screen information line_length field.
- FB_TYPE_PLANES
Macropixels are split across multiple planes. The number of planes is equal to
the number of bits per macropixel, with plane i'th storing i'th bit from all
macropixels.
Planes are located contiguously in memory.
- FB_TYPE_INTERLEAVED_PLANES
Macropixels are split across multiple planes. The number of planes is equal to
the number of bits per macropixel, with plane i'th storing i'th bit from all
macropixels.
Planes are interleaved in memory. The interleave factor, defined as the
distance in bytes between the beginning of two consecutive interleaved blocks
belonging to different planes, is stored in the fixed screen information
type_aux field.
- FB_TYPE_FOURCC
Macropixels are stored in memory as described by the format FOURCC identifier
stored in the variable screen information grayscale field.
- FB_VISUAL_MONO01
Pixels are black or white and stored on a number of bits (typically one)
specified by the variable screen information bpp field.
Black pixels are represented by all bits set to 1 and white pixels by all bits
set to 0. When the number of bits per pixel is smaller than 8, several pixels
are packed together in a byte.
FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only.
- FB_VISUAL_MONO10
Pixels are black or white and stored on a number of bits (typically one)
specified by the variable screen information bpp field.
Black pixels are represented by all bits set to 0 and white pixels by all bits
set to 1. When the number of bits per pixel is smaller than 8, several pixels
are packed together in a byte.
FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only.
- FB_VISUAL_TRUECOLOR
Pixels are broken into red, green and blue components, and each component
indexes a read-only lookup table for the corresponding value. Lookup tables
are device-dependent, and provide linear or non-linear ramps.
Each component is stored in a macropixel according to the variable screen
information red, green, blue and transp fields.
- FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR
Pixel values are encoded as indices into a colormap that stores red, green and
blue components. The colormap is read-only for FB_VISUAL_STATIC_PSEUDOCOLOR
and read-write for FB_VISUAL_PSEUDOCOLOR.
Each pixel value is stored in the number of bits reported by the variable
screen information bits_per_pixel field.
- FB_VISUAL_DIRECTCOLOR
Pixels are broken into red, green and blue components, and each component
indexes a programmable lookup table for the corresponding value.
Each component is stored in a macropixel according to the variable screen
information red, green, blue and transp fields.
- FB_VISUAL_FOURCC
Pixels are encoded and interpreted as described by the format FOURCC
identifier stored in the variable screen information grayscale field.
3. Screen information
---------------------
Screen information are queried by applications using the FBIOGET_FSCREENINFO
and FBIOGET_VSCREENINFO ioctls. Those ioctls take a pointer to a
fb_fix_screeninfo and fb_var_screeninfo structure respectively.
struct fb_fix_screeninfo stores device independent unchangeable information
about the frame buffer device and the current format. Those information can't
be directly modified by applications, but can be changed by the driver when an
application modifies the format.
struct fb_fix_screeninfo {
char id[16]; /* identification string eg "TT Builtin" */
unsigned long smem_start; /* Start of frame buffer mem */
/* (physical address) */
__u32 smem_len; /* Length of frame buffer mem */
__u32 type; /* see FB_TYPE_* */
__u32 type_aux; /* Interleave for interleaved Planes */
__u32 visual; /* see FB_VISUAL_* */
__u16 xpanstep; /* zero if no hardware panning */
__u16 ypanstep; /* zero if no hardware panning */
__u16 ywrapstep; /* zero if no hardware ywrap */
__u32 line_length; /* length of a line in bytes */
unsigned long mmio_start; /* Start of Memory Mapped I/O */
/* (physical address) */
__u32 mmio_len; /* Length of Memory Mapped I/O */
__u32 accel; /* Indicate to driver which */
/* specific chip/card we have */
__u16 capabilities; /* see FB_CAP_* */
__u16 reserved[2]; /* Reserved for future compatibility */
};
struct fb_var_screeninfo stores device independent changeable information
about a frame buffer device, its current format and video mode, as well as
other miscellaneous parameters.
struct fb_var_screeninfo {
__u32 xres; /* visible resolution */
__u32 yres;
__u32 xres_virtual; /* virtual resolution */
__u32 yres_virtual;
__u32 xoffset; /* offset from virtual to visible */
__u32 yoffset; /* resolution */
__u32 bits_per_pixel; /* guess what */
__u32 grayscale; /* 0 = color, 1 = grayscale, */
/* >1 = FOURCC */
struct fb_bitfield red; /* bitfield in fb mem if true color, */
struct fb_bitfield green; /* else only length is significant */
struct fb_bitfield blue;
struct fb_bitfield transp; /* transparency */
__u32 nonstd; /* != 0 Non standard pixel format */
__u32 activate; /* see FB_ACTIVATE_* */
__u32 height; /* height of picture in mm */
__u32 width; /* width of picture in mm */
__u32 accel_flags; /* (OBSOLETE) see fb_info.flags */
/* Timing: All values in pixclocks, except pixclock (of course) */
__u32 pixclock; /* pixel clock in ps (pico seconds) */
__u32 left_margin; /* time from sync to picture */
__u32 right_margin; /* time from picture to sync */
__u32 upper_margin; /* time from sync to picture */
__u32 lower_margin;
__u32 hsync_len; /* length of horizontal sync */
__u32 vsync_len; /* length of vertical sync */
__u32 sync; /* see FB_SYNC_* */
__u32 vmode; /* see FB_VMODE_* */
__u32 rotate; /* angle we rotate counter clockwise */
__u32 colorspace; /* colorspace for FOURCC-based modes */
__u32 reserved[4]; /* Reserved for future compatibility */
};
To modify variable information, applications call the FBIOPUT_VSCREENINFO
ioctl with a pointer to a fb_var_screeninfo structure. If the call is
successful, the driver will update the fixed screen information accordingly.
Instead of filling the complete fb_var_screeninfo structure manually,
applications should call the FBIOGET_VSCREENINFO ioctl and modify only the
fields they care about.
4. Format configuration
-----------------------
Frame buffer devices offer two ways to configure the frame buffer format: the
legacy API and the FOURCC-based API.
The legacy API has been the only frame buffer format configuration API for a
long time and is thus widely used by application. It is the recommended API
for applications when using RGB and grayscale formats, as well as legacy
non-standard formats.
To select a format, applications set the fb_var_screeninfo bits_per_pixel field
to the desired frame buffer depth. Values up to 8 will usually map to
monochrome, grayscale or pseudocolor visuals, although this is not required.
- For grayscale formats, applications set the grayscale field to one. The red,
blue, green and transp fields must be set to 0 by applications and ignored by
drivers. Drivers must fill the red, blue and green offsets to 0 and lengths
to the bits_per_pixel value.
- For pseudocolor formats, applications set the grayscale field to zero. The
red, blue, green and transp fields must be set to 0 by applications and
ignored by drivers. Drivers must fill the red, blue and green offsets to 0
and lengths to the bits_per_pixel value.
- For truecolor and directcolor formats, applications set the grayscale field
to zero, and the red, blue, green and transp fields to describe the layout of
color components in memory.
struct fb_bitfield {
__u32 offset; /* beginning of bitfield */
__u32 length; /* length of bitfield */
__u32 msb_right; /* != 0 : Most significant bit is */
/* right */
};
Pixel values are bits_per_pixel wide and are split in non-overlapping red,
green, blue and alpha (transparency) components. Location and size of each
component in the pixel value are described by the fb_bitfield offset and
length fields. Offset are computed from the right.
Pixels are always stored in an integer number of bytes. If the number of
bits per pixel is not a multiple of 8, pixel values are padded to the next
multiple of 8 bits.
Upon successful format configuration, drivers update the fb_fix_screeninfo
type, visual and line_length fields depending on the selected format.
The FOURCC-based API replaces format descriptions by four character codes
(FOURCC). FOURCCs are abstract identifiers that uniquely define a format
without explicitly describing it. This is the only API that supports YUV
formats. Drivers are also encouraged to implement the FOURCC-based API for RGB
and grayscale formats.
Drivers that support the FOURCC-based API report this capability by setting
the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field.
FOURCC definitions are located in the linux/videodev2.h header. However, and
despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to V4L2
and don't require usage of the V4L2 subsystem. FOURCC documentation is
available in Documentation/DocBook/v4l/pixfmt.xml.
To select a format, applications set the grayscale field to the desired FOURCC.
For YUV formats, they should also select the appropriate colorspace by setting
the colorspace field to one of the colorspaces listed in linux/videodev2.h and
documented in Documentation/DocBook/v4l/colorspaces.xml.
The red, green, blue and transp fields are not used with the FOURCC-based API.
For forward compatibility reasons applications must zero those fields, and
drivers must ignore them. Values other than 0 may get a meaning in future
extensions.
Upon successful format configuration, drivers update the fb_fix_screeninfo
type, visual and line_length fields depending on the selected format. The type
and visual fields are set to FB_TYPE_FOURCC and FB_VISUAL_FOURCC respectively.

46
Documentation/feature-removal-schedule.txt
View file

@ -439,52 +439,6 @@ Who: Jean Delvare <khali@linux-fr.org>
----------------------------
What: Support for driver specific ioctls in the pwc driver (everything
defined in media/pwc-ioctl.h)
When: 3.3
Why: This stems from the v4l1 era, with v4l2 everything can be done with
standardized v4l2 API calls
Who: Hans de Goede <hdegoede@redhat.com>
----------------------------
What: Driver specific sysfs API in the pwc driver
When: 3.3
Why: Setting pan/tilt should be done with v4l2 controls, like with other
cams. The button is available as a standard input device
Who: Hans de Goede <hdegoede@redhat.com>
----------------------------
What: Driver specific use of pixfmt.priv in the pwc driver
When: 3.3
Why: The .priv field never was intended for this, setting a framerate is
support using the standardized S_PARM ioctl
Who: Hans de Goede <hdegoede@redhat.com>
----------------------------
What: Software emulation of arbritary resolutions in the pwc driver
When: 3.3
Why: The pwc driver claims to support any resolution between 160x120
and 640x480, but emulates this by simply drawing a black border
around the image. Userspace can draw its own black border if it
really wants one.
Who: Hans de Goede <hdegoede@redhat.com>
----------------------------
What: For VIDIOC_S_FREQUENCY the type field must match the device node's type.
If not, return -EINVAL.
When: 3.2
Why: It makes no sense to switch the tuner to radio mode by calling
VIDIOC_S_FREQUENCY on a video node, or to switch the tuner to tv mode by
calling VIDIOC_S_FREQUENCY on a radio node. This is the first step of a
move to more consistent handling of tv and radio tuners.
Who: Hans Verkuil <hans.verkuil@cisco.com>
----------------------------
What: Opening a radio device node will no longer automatically switch the
tuner mode from tv to radio.
When: 3.3

18
Documentation/filesystems/ceph.txt
View file

@ -119,12 +119,20 @@ Mount Options
must rely on TCP's error correction to detect data corruption
in the data payload.
noasyncreaddir
Disable client's use its local cache to satisfy readdir
requests. (This does not change correctness; the client uses
cached metadata only when a lease or capability ensures it is
valid.)
dcache
Use the dcache contents to perform negative lookups and
readdir when the client has the entire directory contents in
its cache. (This does not change correctness; the client uses
cached metadata only when a lease or capability ensures it is
valid.)
nodcache
Do not use the dcache as above. This avoids a significant amount of
complex code, sacrificing performance without affecting correctness,
and is useful for tracking down bugs.
noasyncreaddir
Do not use the dcache as above for readdir.
More Information
================

2
Documentation/filesystems/nfs/00-INDEX
View file

@ -2,6 +2,8 @@
- this file (nfs-related documentation).
Exporting
- explanation of how to make filesystems exportable.
fault_injection.txt
- information for using fault injection on the server
knfsd-stats.txt
- statistics which the NFS server makes available to user space.
nfs.txt

69
Documentation/filesystems/nfs/fault_injection.txt Normal file
View file

@ -0,0 +1,69 @@
Fault Injection
===============
Fault injection is a method for forcing errors that may not normally occur, or
may be difficult to reproduce. Forcing these errors in a controlled environment
can help the developer find and fix bugs before their code is shipped in a
production system. Injecting an error on the Linux NFS server will allow us to
observe how the client reacts and if it manages to recover its state correctly.
NFSD_FAULT_INJECTION must be selected when configuring the kernel to use this
feature.
Using Fault Injection
=====================
On the client, mount the fault injection server through NFS v4.0+ and do some
work over NFS (open files, take locks, ...).
On the server, mount the debugfs filesystem to <debug_dir> and ls
<debug_dir>/nfsd. This will show a list of files that will be used for
injecting faults on the NFS server. As root, write a number n to the file
corresponding to the action you want the server to take. The server will then
process the first n items it finds. So if you want to forget 5 locks, echo '5'
to <debug_dir>/nfsd/forget_locks. A value of 0 will tell the server to forget
all corresponding items. A log message will be created containing the number
of items forgotten (check dmesg).
Go back to work on the client and check if the client recovered from the error
correctly.
Available Faults
================
forget_clients:
The NFS server keeps a list of clients that have placed a mount call. If
this list is cleared, the server will have no knowledge of who the client
is, forcing the client to reauthenticate with the server.
forget_openowners:
The NFS server keeps a list of what files are currently opened and who
they were opened by. Clearing this list will force the client to reopen
its files.
forget_locks:
The NFS server keeps a list of what files are currently locked in the VFS.
Clearing this list will force the client to reclaim its locks (files are
unlocked through the VFS as they are cleared from this list).
forget_delegations:
A delegation is used to assure the client that a file, or part of a file,
has not changed since the delegation was awarded. Clearing this list will
force the client to reaquire its delegation before accessing the file
again.
recall_delegations:
Delegations can be recalled by the server when another client attempts to
access a file. This test will notify the client that its delegation has
been revoked, forcing the client to reaquire the delegation before using
the file again.
tools/nfs/inject_faults.sh script
=================================
This script has been created to ease the fault injection process. This script
will detect the mounted debugfs directory and write to the files located there
based on the arguments passed by the user. For example, running
`inject_faults.sh forget_locks 1` as root will instruct the server to forget
one lock. Running `inject_faults forget_locks` will instruct the server to
forgetall locks.

6
Documentation/filesystems/squashfs.txt
View file

@ -93,8 +93,8 @@ byte alignment:
Compressed data blocks are written to the filesystem as files are read from
the source directory, and checked for duplicates. Once all file data has been
written the completed inode, directory, fragment, export and uid/gid lookup
tables are written.
written the completed inode, directory, fragment, export, uid/gid lookup and
xattr tables are written.
3.1 Compression options
-----------------------
@ -151,7 +151,7 @@ in each metadata block. Directories are sorted in alphabetical order,
and at lookup the index is scanned linearly looking for the first filename
alphabetically larger than the filename being looked up. At this point the
location of the metadata block the filename is in has been found.
The general idea of the index is ensure only one metadata block needs to be
The general idea of the index is to ensure only one metadata block needs to be
decompressed to do a lookup irrespective of the length of the directory.
This scheme has the advantage that it doesn't require extra memory overhead
and doesn't require much extra storage on disk.

13
Documentation/hwmon/it87
View file

@ -26,6 +26,10 @@ Supported chips:
Prefix: 'it8721'
Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: Not publicly available
* IT8728F
Prefix: 'it8728'
Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: Not publicly available
* SiS950 [clone of IT8705F]
Prefix: 'it87'
Addresses scanned: from Super I/O config space (8 I/O ports)
@ -71,7 +75,7 @@ Description
-----------
This driver implements support for the IT8705F, IT8712F, IT8716F,
IT8718F, IT8720F, IT8721F, IT8726F, IT8758E and SiS950 chips.
IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E and SiS950 chips.
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
joysticks and other miscellaneous stuff. For hardware monitoring, they
@ -105,6 +109,9 @@ The IT8726F is just bit enhanced IT8716F with additional hardware
for AMD power sequencing. Therefore the chip will appear as IT8716F
to userspace applications.
The IT8728F is considered compatible with the IT8721F, until a datasheet
becomes available (hopefully.)
Temperatures are measured in degrees Celsius. An alarm is triggered once
when the Overtemperature Shutdown limit is crossed.
@ -121,8 +128,8 @@ alarm is triggered if the voltage has crossed a programmable minimum or
maximum limit. Note that minimum in this case always means 'closest to
zero'; this is important for negative voltage measurements. All voltage
inputs can measure voltages between 0 and 4.08 volts, with a resolution of
0.016 volt (except IT8721F/IT8758E: 0.012 volt.) The battery voltage in8 does
not have limit registers.
0.016 volt (except IT8721F/IT8758E and IT8728F: 0.012 volt.) The battery
voltage in8 does not have limit registers.
On the IT8721F/IT8758E, some voltage inputs are internal and scaled inside
the chip (in7, in8 and optionally in3). The driver handles this transparently

21
Documentation/hwmon/lm63
View file

@ -12,6 +12,11 @@ Supported chips:
Addresses scanned: I2C 0x18 and 0x4e
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LM/LM64.html
* National Semiconductor LM96163
Prefix: 'lm96163'
Addresses scanned: I2C 0x4c
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LM/LM96163.html
Author: Jean Delvare <khali@linux-fr.org>
@ -49,16 +54,24 @@ value for measuring the speed of the fan. It can measure fan speeds down to
Note that the pin used for fan monitoring is shared with an alert out
function. Depending on how the board designer wanted to use the chip, fan
speed monitoring will or will not be possible. The proper chip configuration
is left to the BIOS, and the driver will blindly trust it.
is left to the BIOS, and the driver will blindly trust it. Only the original
LM63 suffers from this limitation, the LM64 and LM96163 have separate pins
for fan monitoring and alert out. On the LM64, monitoring is always enabled;
on the LM96163 it can be disabled.
A PWM output can be used to control the speed of the fan. The LM63 has two
PWM modes: manual and automatic. Automatic mode is not fully implemented yet
(you cannot define your custom PWM/temperature curve), and mode change isn't
supported either.
The lm63 driver will not update its values more frequently than every
second; reading them more often will do no harm, but will return 'old'
values.
The lm63 driver will not update its values more frequently than configured with
the update_interval sysfs attribute; reading them more often will do no harm,
but will return 'old' values. Values in the automatic fan control lookup table
(attributes pwm1_auto_*) have their own independent lifetime of 5 seconds.
The LM64 is effectively an LM63 with GPIO lines. The driver does not
support these GPIO lines at present.
The LM96163 is an enhanced version of LM63 with improved temperature accuracy
and better PWM resolution. For LM96163, the external temperature sensor type is
configurable as CPU embedded diode(1) or 3904 transistor(2).

Some files were not shown because too many files have changed in this diff Show more