diff options
Diffstat (limited to 'Documentation/DocBook')
16 files changed, 817 insertions, 256 deletions
diff --git a/Documentation/DocBook/crypto-API.tmpl b/Documentation/DocBook/crypto-API.tmpl index 07df23ea06e4..348619fcafb8 100644 --- a/Documentation/DocBook/crypto-API.tmpl +++ b/Documentation/DocBook/crypto-API.tmpl @@ -348,10 +348,7 @@ <para>type: <itemizedlist> <listitem> - <para>blkcipher for synchronous block ciphers</para> - </listitem> - <listitem> - <para>ablkcipher for asynchronous block ciphers</para> + <para>skcipher for symmetric key ciphers</para> </listitem> <listitem> <para>cipher for single block ciphers that may be used with @@ -485,6 +482,9 @@ <para>CRYPTO_ALG_TYPE_RNG Random Number Generation</para> </listitem> <listitem> + <para>CRYPTO_ALG_TYPE_AKCIPHER Asymmetric cipher</para> + </listitem> + <listitem> <para>CRYPTO_ALG_TYPE_PCOMPRESS Enhanced version of CRYPTO_ALG_TYPE_COMPRESS allowing for segmented compression / decompression instead of performing the operation on one @@ -597,7 +597,7 @@ kernel crypto API | IPSEC Layer v v +-----------+ +-----------+ | | | | -| ablkcipher| | ahash | +| skcipher | | ahash | | (ctr) | ---+ | (ghash) | +-----------+ | +-----------+ | @@ -658,7 +658,7 @@ kernel crypto API | IPSEC Layer <listitem> <para> - The GCM AEAD cipher type implementation now invokes the ABLKCIPHER API + The GCM AEAD cipher type implementation now invokes the SKCIPHER API with the instantiated CTR(AES) cipher handle. </para> @@ -669,7 +669,7 @@ kernel crypto API | IPSEC Layer </para> <para> - That means that the ABLKCIPHER implementation of CTR(AES) only + That means that the SKCIPHER implementation of CTR(AES) only implements the CTR block chaining mode. After performing the block chaining operation, the CIPHER implementation of AES is invoked. </para> @@ -677,7 +677,7 @@ kernel crypto API | IPSEC Layer <listitem> <para> - The ABLKCIPHER of CTR(AES) now invokes the CIPHER API with the AES + The SKCIPHER of CTR(AES) now invokes the CIPHER API with the AES cipher handle to encrypt one block. </para> </listitem> @@ -706,7 +706,7 @@ kernel crypto API | IPSEC Layer <para> For example, CBC(AES) is implemented with cbc.c, and aes-generic.c. The ASCII art picture above applies as well with the difference that only - step (4) is used and the ABLKCIPHER block chaining mode is CBC. + step (4) is used and the SKCIPHER block chaining mode is CBC. </para> </sect2> @@ -904,15 +904,14 @@ kernel crypto API | Caller </sect2> </sect1> - <sect1><title>Multi-Block Ciphers [BLKCIPHER] [ABLKCIPHER]</title> + <sect1><title>Multi-Block Ciphers</title> <para> Example of transformations: cbc(aes), ecb(arc4), ... </para> <para> This section describes the multi-block cipher transformation - implementations for both synchronous [BLKCIPHER] and - asynchronous [ABLKCIPHER] case. The multi-block ciphers are + implementations. The multi-block ciphers are used for transformations which operate on scatterlists of data supplied to the transformation functions. They output the result into a scatterlist of data as well. @@ -921,16 +920,15 @@ kernel crypto API | Caller <sect2><title>Registration Specifics</title> <para> - The registration of [BLKCIPHER] or [ABLKCIPHER] algorithms + The registration of multi-block cipher algorithms is one of the most standard procedures throughout the crypto API. </para> <para> Note, if a cipher implementation requires a proper alignment of data, the caller should use the functions of - crypto_blkcipher_alignmask() or crypto_ablkcipher_alignmask() - respectively to identify a memory alignment mask. The kernel - crypto API is able to process requests that are unaligned. + crypto_skcipher_alignmask() to identify a memory alignment mask. + The kernel crypto API is able to process requests that are unaligned. This implies, however, additional overhead as the kernel crypto API needs to perform the realignment of the data which may imply moving of data. @@ -945,14 +943,13 @@ kernel crypto API | Caller <para> Please refer to the single block cipher description for schematics - of the block cipher usage. The usage patterns are exactly the same - for [ABLKCIPHER] and [BLKCIPHER] as they are for plain [CIPHER]. + of the block cipher usage. </para> </sect2> <sect2><title>Specifics Of Asynchronous Multi-Block Cipher</title> <para> - There are a couple of specifics to the [ABLKCIPHER] interface. + There are a couple of specifics to the asynchronous interface. </para> <para> @@ -1692,7 +1689,28 @@ read(opfd, out, outlen); !Finclude/linux/crypto.h cipher_alg !Finclude/crypto/rng.h rng_alg </sect1> - <sect1><title>Asynchronous Block Cipher API</title> + <sect1><title>Symmetric Key Cipher API</title> +!Pinclude/crypto/skcipher.h Symmetric Key Cipher API +!Finclude/crypto/skcipher.h crypto_alloc_skcipher +!Finclude/crypto/skcipher.h crypto_free_skcipher +!Finclude/crypto/skcipher.h crypto_has_skcipher +!Finclude/crypto/skcipher.h crypto_skcipher_ivsize +!Finclude/crypto/skcipher.h crypto_skcipher_blocksize +!Finclude/crypto/skcipher.h crypto_skcipher_setkey +!Finclude/crypto/skcipher.h crypto_skcipher_reqtfm +!Finclude/crypto/skcipher.h crypto_skcipher_encrypt +!Finclude/crypto/skcipher.h crypto_skcipher_decrypt + </sect1> + <sect1><title>Symmetric Key Cipher Request Handle</title> +!Pinclude/crypto/skcipher.h Symmetric Key Cipher Request Handle +!Finclude/crypto/skcipher.h crypto_skcipher_reqsize +!Finclude/crypto/skcipher.h skcipher_request_set_tfm +!Finclude/crypto/skcipher.h skcipher_request_alloc +!Finclude/crypto/skcipher.h skcipher_request_free +!Finclude/crypto/skcipher.h skcipher_request_set_callback +!Finclude/crypto/skcipher.h skcipher_request_set_crypt + </sect1> + <sect1><title>Asynchronous Block Cipher API - Deprecated</title> !Pinclude/linux/crypto.h Asynchronous Block Cipher API !Finclude/linux/crypto.h crypto_alloc_ablkcipher !Finclude/linux/crypto.h crypto_free_ablkcipher @@ -1704,7 +1722,7 @@ read(opfd, out, outlen); !Finclude/linux/crypto.h crypto_ablkcipher_encrypt !Finclude/linux/crypto.h crypto_ablkcipher_decrypt </sect1> - <sect1><title>Asynchronous Cipher Request Handle</title> + <sect1><title>Asynchronous Cipher Request Handle - Deprecated</title> !Pinclude/linux/crypto.h Asynchronous Cipher Request Handle !Finclude/linux/crypto.h crypto_ablkcipher_reqsize !Finclude/linux/crypto.h ablkcipher_request_set_tfm @@ -1733,10 +1751,9 @@ read(opfd, out, outlen); !Finclude/crypto/aead.h aead_request_free !Finclude/crypto/aead.h aead_request_set_callback !Finclude/crypto/aead.h aead_request_set_crypt -!Finclude/crypto/aead.h aead_request_set_assoc !Finclude/crypto/aead.h aead_request_set_ad </sect1> - <sect1><title>Synchronous Block Cipher API</title> + <sect1><title>Synchronous Block Cipher API - Deprecated</title> !Pinclude/linux/crypto.h Synchronous Block Cipher API !Finclude/linux/crypto.h crypto_alloc_blkcipher !Finclude/linux/crypto.h crypto_free_blkcipher @@ -1762,19 +1779,6 @@ read(opfd, out, outlen); !Finclude/linux/crypto.h crypto_cipher_encrypt_one !Finclude/linux/crypto.h crypto_cipher_decrypt_one </sect1> - <sect1><title>Synchronous Message Digest API</title> -!Pinclude/linux/crypto.h Synchronous Message Digest API -!Finclude/linux/crypto.h crypto_alloc_hash -!Finclude/linux/crypto.h crypto_free_hash -!Finclude/linux/crypto.h crypto_has_hash -!Finclude/linux/crypto.h crypto_hash_blocksize -!Finclude/linux/crypto.h crypto_hash_digestsize -!Finclude/linux/crypto.h crypto_hash_init -!Finclude/linux/crypto.h crypto_hash_update -!Finclude/linux/crypto.h crypto_hash_final -!Finclude/linux/crypto.h crypto_hash_digest -!Finclude/linux/crypto.h crypto_hash_setkey - </sect1> <sect1><title>Message Digest Algorithm Definitions</title> !Pinclude/crypto/hash.h Message Digest Algorithm Definitions !Finclude/crypto/hash.h hash_alg_common @@ -1825,15 +1829,36 @@ read(opfd, out, outlen); !Finclude/crypto/rng.h crypto_alloc_rng !Finclude/crypto/rng.h crypto_rng_alg !Finclude/crypto/rng.h crypto_free_rng +!Finclude/crypto/rng.h crypto_rng_generate !Finclude/crypto/rng.h crypto_rng_get_bytes !Finclude/crypto/rng.h crypto_rng_reset !Finclude/crypto/rng.h crypto_rng_seedsize !Cinclude/crypto/rng.h </sect1> + <sect1><title>Asymmetric Cipher API</title> +!Pinclude/crypto/akcipher.h Generic Public Key API +!Finclude/crypto/akcipher.h akcipher_alg +!Finclude/crypto/akcipher.h akcipher_request +!Finclude/crypto/akcipher.h crypto_alloc_akcipher +!Finclude/crypto/akcipher.h crypto_free_akcipher +!Finclude/crypto/akcipher.h crypto_akcipher_set_pub_key +!Finclude/crypto/akcipher.h crypto_akcipher_set_priv_key + </sect1> + <sect1><title>Asymmetric Cipher Request Handle</title> +!Finclude/crypto/akcipher.h akcipher_request_alloc +!Finclude/crypto/akcipher.h akcipher_request_free +!Finclude/crypto/akcipher.h akcipher_request_set_callback +!Finclude/crypto/akcipher.h akcipher_request_set_crypt +!Finclude/crypto/akcipher.h crypto_akcipher_maxsize +!Finclude/crypto/akcipher.h crypto_akcipher_encrypt +!Finclude/crypto/akcipher.h crypto_akcipher_decrypt +!Finclude/crypto/akcipher.h crypto_akcipher_sign +!Finclude/crypto/akcipher.h crypto_akcipher_verify + </sect1> </chapter> <chapter id="Code"><title>Code Examples</title> - <sect1><title>Code Example For Asynchronous Block Cipher Operation</title> + <sect1><title>Code Example For Symmetric Key Cipher Operation</title> <programlisting> struct tcrypt_result { @@ -1842,15 +1867,15 @@ struct tcrypt_result { }; /* tie all data structures together */ -struct ablkcipher_def { +struct skcipher_def { struct scatterlist sg; - struct crypto_ablkcipher *tfm; - struct ablkcipher_request *req; + struct crypto_skcipher *tfm; + struct skcipher_request *req; struct tcrypt_result result; }; /* Callback function */ -static void test_ablkcipher_cb(struct crypto_async_request *req, int error) +static void test_skcipher_cb(struct crypto_async_request *req, int error) { struct tcrypt_result *result = req->data; @@ -1862,15 +1887,15 @@ static void test_ablkcipher_cb(struct crypto_async_request *req, int error) } /* Perform cipher operation */ -static unsigned int test_ablkcipher_encdec(struct ablkcipher_def *ablk, - int enc) +static unsigned int test_skcipher_encdec(struct skcipher_def *sk, + int enc) { int rc = 0; if (enc) - rc = crypto_ablkcipher_encrypt(ablk->req); + rc = crypto_skcipher_encrypt(sk->req); else - rc = crypto_ablkcipher_decrypt(ablk->req); + rc = crypto_skcipher_decrypt(sk->req); switch (rc) { case 0: @@ -1878,52 +1903,52 @@ static unsigned int test_ablkcipher_encdec(struct ablkcipher_def *ablk, case -EINPROGRESS: case -EBUSY: rc = wait_for_completion_interruptible( - &ablk->result.completion); - if (!rc && !ablk->result.err) { - reinit_completion(&ablk->result.completion); + &sk->result.completion); + if (!rc && !sk->result.err) { + reinit_completion(&sk->result.completion); break; } default: - pr_info("ablkcipher encrypt returned with %d result %d\n", - rc, ablk->result.err); + pr_info("skcipher encrypt returned with %d result %d\n", + rc, sk->result.err); break; } - init_completion(&ablk->result.completion); + init_completion(&sk->result.completion); return rc; } /* Initialize and trigger cipher operation */ -static int test_ablkcipher(void) +static int test_skcipher(void) { - struct ablkcipher_def ablk; - struct crypto_ablkcipher *ablkcipher = NULL; - struct ablkcipher_request *req = NULL; + struct skcipher_def sk; + struct crypto_skcipher *skcipher = NULL; + struct skcipher_request *req = NULL; char *scratchpad = NULL; char *ivdata = NULL; unsigned char key[32]; int ret = -EFAULT; - ablkcipher = crypto_alloc_ablkcipher("cbc-aes-aesni", 0, 0); - if (IS_ERR(ablkcipher)) { - pr_info("could not allocate ablkcipher handle\n"); - return PTR_ERR(ablkcipher); + skcipher = crypto_alloc_skcipher("cbc-aes-aesni", 0, 0); + if (IS_ERR(skcipher)) { + pr_info("could not allocate skcipher handle\n"); + return PTR_ERR(skcipher); } - req = ablkcipher_request_alloc(ablkcipher, GFP_KERNEL); + req = skcipher_request_alloc(skcipher, GFP_KERNEL); if (IS_ERR(req)) { pr_info("could not allocate request queue\n"); ret = PTR_ERR(req); goto out; } - ablkcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG, - test_ablkcipher_cb, - &ablk.result); + skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG, + test_skcipher_cb, + &sk.result); /* AES 256 with random key */ get_random_bytes(&key, 32); - if (crypto_ablkcipher_setkey(ablkcipher, key, 32)) { + if (crypto_skcipher_setkey(skcipher, key, 32)) { pr_info("key could not be set\n"); ret = -EAGAIN; goto out; @@ -1945,26 +1970,26 @@ static int test_ablkcipher(void) } get_random_bytes(scratchpad, 16); - ablk.tfm = ablkcipher; - ablk.req = req; + sk.tfm = skcipher; + sk.req = req; /* We encrypt one block */ - sg_init_one(&ablk.sg, scratchpad, 16); - ablkcipher_request_set_crypt(req, &ablk.sg, &ablk.sg, 16, ivdata); - init_completion(&ablk.result.completion); + sg_init_one(&sk.sg, scratchpad, 16); + skcipher_request_set_crypt(req, &sk.sg, &sk.sg, 16, ivdata); + init_completion(&sk.result.completion); /* encrypt data */ - ret = test_ablkcipher_encdec(&ablk, 1); + ret = test_skcipher_encdec(&sk, 1); if (ret) goto out; pr_info("Encryption triggered successfully\n"); out: - if (ablkcipher) - crypto_free_ablkcipher(ablkcipher); + if (skcipher) + crypto_free_skcipher(skcipher); if (req) - ablkcipher_request_free(req); + skcipher_request_free(req); if (ivdata) kfree(ivdata); if (scratchpad) @@ -1974,77 +1999,6 @@ out: </programlisting> </sect1> - <sect1><title>Code Example For Synchronous Block Cipher Operation</title> - <programlisting> - -static int test_blkcipher(void) -{ - struct crypto_blkcipher *blkcipher = NULL; - char *cipher = "cbc(aes)"; - // AES 128 - charkey = -"\x12\x34\x56\x78\x90\xab\xcd\xef\x12\x34\x56\x78\x90\xab\xcd\xef"; - chariv = -"\x12\x34\x56\x78\x90\xab\xcd\xef\x12\x34\x56\x78\x90\xab\xcd\xef"; - unsigned int ivsize = 0; - char *scratchpad = NULL; // holds plaintext and ciphertext - struct scatterlist sg; - struct blkcipher_desc desc; - int ret = -EFAULT; - - blkcipher = crypto_alloc_blkcipher(cipher, 0, 0); - if (IS_ERR(blkcipher)) { - printk("could not allocate blkcipher handle for %s\n", cipher); - return -PTR_ERR(blkcipher); - } - - if (crypto_blkcipher_setkey(blkcipher, key, strlen(key))) { - printk("key could not be set\n"); - ret = -EAGAIN; - goto out; - } - - ivsize = crypto_blkcipher_ivsize(blkcipher); - if (ivsize) { - if (ivsize != strlen(iv)) - printk("IV length differs from expected length\n"); - crypto_blkcipher_set_iv(blkcipher, iv, ivsize); - } - - scratchpad = kmalloc(crypto_blkcipher_blocksize(blkcipher), GFP_KERNEL); - if (!scratchpad) { - printk("could not allocate scratchpad for %s\n", cipher); - goto out; - } - /* get some random data that we want to encrypt */ - get_random_bytes(scratchpad, crypto_blkcipher_blocksize(blkcipher)); - - desc.flags = 0; - desc.tfm = blkcipher; - sg_init_one(&sg, scratchpad, crypto_blkcipher_blocksize(blkcipher)); - - /* encrypt data in place */ - crypto_blkcipher_encrypt(&desc, &sg, &sg, - crypto_blkcipher_blocksize(blkcipher)); - - /* decrypt data in place - * crypto_blkcipher_decrypt(&desc, &sg, &sg, - */ crypto_blkcipher_blocksize(blkcipher)); - - - printk("Cipher operation completed\n"); - return 0; - -out: - if (blkcipher) - crypto_free_blkcipher(blkcipher); - if (scratchpad) - kzfree(scratchpad); - return ret; -} - </programlisting> - </sect1> - <sect1><title>Code Example For Use of Operational State Memory With SHASH</title> <programlisting> diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index cdd8b24db68d..184f3c7b5145 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -229,6 +229,7 @@ X!Isound/sound_firmware.c !Iinclude/media/v4l2-dv-timings.h !Iinclude/media/v4l2-event.h !Iinclude/media/v4l2-flash-led-class.h +!Iinclude/media/v4l2-mc.h !Iinclude/media/v4l2-mediabus.h !Iinclude/media/v4l2-mem2mem.h !Iinclude/media/v4l2-of.h @@ -368,7 +369,7 @@ X!Ilib/fonts/fonts.c !Iinclude/linux/input-polldev.h !Edrivers/input/input-polldev.c </sect1> - <sect1><title>Matrix keyboars/keypads</title> + <sect1><title>Matrix keyboards/keypads</title> !Iinclude/linux/input/matrix_keypad.h </sect1> <sect1><title>Sparse keymap support</title> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index a8669330b456..1692c4dd5487 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >Description/Restrictions</td> </tr> <tr> - <td rowspan="37" valign="top" >DRM</td> + <td rowspan="42" valign="top" >DRM</td> <td valign="top" >Generic</td> <td valign="top" >“rotation”</td> <td valign="top" >BITMASK</td> @@ -2068,7 +2068,7 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >property to suggest an Y offset for a connector</td> </tr> <tr> - <td rowspan="3" valign="top" >Optional</td> + <td rowspan="8" valign="top" >Optional</td> <td valign="top" >“scaling mode”</td> <td valign="top" >ENUM</td> <td valign="top" >{ "None", "Full", "Center", "Full aspect" }</td> @@ -2092,6 +2092,61 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >TBD</td> </tr> <tr> + <td valign="top" >“DEGAMMA_LUT”</td> + <td valign="top" >BLOB</td> + <td valign="top" >0</td> + <td valign="top" >CRTC</td> + <td valign="top" >DRM property to set the degamma lookup table + (LUT) mapping pixel data from the framebuffer before it is + given to the transformation matrix. The data is an interpreted + as an array of struct drm_color_lut elements. Hardware might + choose not to use the full precision of the LUT elements nor + use all the elements of the LUT (for example the hardware + might choose to interpolate between LUT[0] and LUT[4]). </td> + </tr> + <tr> + <td valign="top" >“DEGAMMA_LUT_SIZE”</td> + <td valign="top" >RANGE | IMMUTABLE</td> + <td valign="top" >Min=0, Max=UINT_MAX</td> + <td valign="top" >CRTC</td> + <td valign="top" >DRM property to gives the size of the lookup + table to be set on the DEGAMMA_LUT property (the size depends + on the underlying hardware).</td> + </tr> + <tr> + <td valign="top" >“CTM”</td> + <td valign="top" >BLOB</td> + <td valign="top" >0</td> + <td valign="top" >CRTC</td> + <td valign="top" >DRM property to set the current + transformation matrix (CTM) apply to pixel data after the + lookup through the degamma LUT and before the lookup through + the gamma LUT. The data is an interpreted as a struct + drm_color_ctm.</td> + </tr> + <tr> + <td valign="top" >“GAMMA_LUT”</td> + <td valign="top" >BLOB</td> + <td valign="top" >0</td> + <td valign="top" >CRTC</td> + <td valign="top" >DRM property to set the gamma lookup table + (LUT) mapping pixel data after to the transformation matrix to + data sent to the connector. The data is an interpreted as an + array of struct drm_color_lut elements. Hardware might choose + not to use the full precision of the LUT elements nor use all + the elements of the LUT (for example the hardware might choose + to interpolate between LUT[0] and LUT[4]).</td> + </tr> + <tr> + <td valign="top" >“GAMMA_LUT_SIZE”</td> + <td valign="top" >RANGE | IMMUTABLE</td> + <td valign="top" >Min=0, Max=UINT_MAX</td> + <td valign="top" >CRTC</td> + <td valign="top" >DRM property to gives the size of the lookup + table to be set on the GAMMA_LUT property (the size depends on + the underlying hardware).</td> + </tr> + <tr> <td rowspan="20" valign="top" >i915</td> <td rowspan="2" valign="top" >Generic</td> <td valign="top" >"Broadcast RGB"</td> @@ -2886,52 +2941,8 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis> </sect2> <sect2> <title>File Operations</title> - <synopsis>const struct file_operations *fops</synopsis> - <abstract>File operations for the DRM device node.</abstract> - <para> - Drivers must define the file operations structure that forms the DRM - userspace API entry point, even though most of those operations are - implemented in the DRM core. The <methodname>open</methodname>, - <methodname>release</methodname> and <methodname>ioctl</methodname> - operations are handled by - <programlisting> - .owner = THIS_MODULE, - .open = drm_open, - .release = drm_release, - .unlocked_ioctl = drm_ioctl, - #ifdef CONFIG_COMPAT - .compat_ioctl = drm_compat_ioctl, - #endif - </programlisting> - </para> - <para> - Drivers that implement private ioctls that requires 32/64bit - compatibility support must provide their own - <methodname>compat_ioctl</methodname> handler that processes private - ioctls and calls <function>drm_compat_ioctl</function> for core ioctls. - </para> - <para> - The <methodname>read</methodname> and <methodname>poll</methodname> - operations provide support for reading DRM events and polling them. They - are implemented by - <programlisting> - .poll = drm_poll, - .read = drm_read, - .llseek = no_llseek, - </programlisting> - </para> - <para> - The memory mapping implementation varies depending on how the driver - manages memory. Pre-GEM drivers will use <function>drm_mmap</function>, - while GEM-aware drivers will use <function>drm_gem_mmap</function>. See - <xref linkend="drm-gem"/>. - <programlisting> - .mmap = drm_gem_mmap, - </programlisting> - </para> - <para> - No other file operation is supported by the DRM API. - </para> +!Pdrivers/gpu/drm/drm_fops.c file operations +!Edrivers/gpu/drm/drm_fops.c </sect2> <sect2> <title>IOCTLs</title> @@ -3319,6 +3330,12 @@ int num_ioctls;</synopsis> !Pdrivers/gpu/drm/i915/intel_csr.c csr support for dmc !Idrivers/gpu/drm/i915/intel_csr.c </sect2> + <sect2> + <title>Video BIOS Table (VBT)</title> +!Pdrivers/gpu/drm/i915/intel_bios.c Video BIOS Table (VBT) +!Idrivers/gpu/drm/i915/intel_bios.c +!Idrivers/gpu/drm/i915/intel_bios.h + </sect2> </sect1> <sect1> @@ -3460,6 +3477,7 @@ int num_ioctls;</synopsis> </sect1> <sect1> <title>Public constants</title> +!Finclude/linux/vga_switcheroo.h vga_switcheroo_handler_flags_t !Finclude/linux/vga_switcheroo.h vga_switcheroo_client_id !Finclude/linux/vga_switcheroo.h vga_switcheroo_state </sect1> @@ -3488,6 +3506,10 @@ int num_ioctls;</synopsis> <title>Backlight control</title> !Pdrivers/platform/x86/apple-gmux.c Backlight control </sect2> + <sect2> + <title>Public functions</title> +!Iinclude/linux/apple-gmux.h + </sect2> </sect1> </chapter> diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index f13a429093f1..361040e6b0f4 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -2330,6 +2330,14 @@ vertical search range for motion estimation module in video encoder.</entry> </row> <row><entry></entry></row> + <row id="v4l2-mpeg-video-force-key-frame"> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME</constant> </entry> + <entry>button</entry> + </row><row><entry spanname="descr">Force a key frame for the next queued buffer. Applicable to encoders. +This is a general, codec-agnostic keyframe control.</entry> + </row> + + <row><entry></entry></row> <row> <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant> </entry> <entry>integer</entry> @@ -5070,6 +5078,46 @@ interface and may change in the future.</para> </entry> </row> <row> + <entry spanname="id"><constant>V4L2_CID_DV_TX_IT_CONTENT_TYPE</constant></entry> + <entry id="v4l2-dv-content-type">enum v4l2_dv_it_content_type</entry> + </row> + <row><entry spanname="descr">Configures the IT Content Type + of the transmitted video. This information is sent over HDMI and DisplayPort connectors + as part of the AVI InfoFrame. The term 'IT Content' is used for content that originates + from a computer as opposed to content from a TV broadcast or an analog source. The + enum v4l2_dv_it_content_type defines the possible content types:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_DV_IT_CONTENT_TYPE_GRAPHICS</constant> </entry> + <entry>Graphics content. Pixel data should be passed unfiltered and without + analog reconstruction.</entry> + </row> + <row> + <entry><constant>V4L2_DV_IT_CONTENT_TYPE_PHOTO</constant> </entry> + <entry>Photo content. The content is derived from digital still pictures. + The content should be passed through with minimal scaling and picture + enhancements.</entry> + </row> + <row> + <entry><constant>V4L2_DV_IT_CONTENT_TYPE_CINEMA</constant> </entry> + <entry>Cinema content.</entry> + </row> + <row> + <entry><constant>V4L2_DV_IT_CONTENT_TYPE_GAME</constant> </entry> + <entry>Game content. Audio and video latency should be minimized.</entry> + </row> + <row> + <entry><constant>V4L2_DV_IT_CONTENT_TYPE_NO_ITC</constant> </entry> + <entry>No IT Content information is available and the ITC bit in the AVI + InfoFrame is set to 0.</entry> + </row> + </tbody> + </entrytbl> + </row> + <row> <entry spanname="id"><constant>V4L2_CID_DV_RX_POWER_PRESENT</constant></entry> <entry>bitmask</entry> </row> @@ -5098,6 +5146,16 @@ interface and may change in the future.</para> This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors. </entry> </row> + <row> + <entry spanname="id"><constant>V4L2_CID_DV_RX_IT_CONTENT_TYPE</constant></entry> + <entry>enum v4l2_dv_it_content_type</entry> + </row> + <row><entry spanname="descr">Reads the IT Content Type + of the received video. This information is sent over HDMI and DisplayPort connectors + as part of the AVI InfoFrame. The term 'IT Content' is used for content that originates + from a computer as opposed to content from a TV broadcast or an analog source. See + <constant>V4L2_CID_DV_TX_IT_CONTENT_TYPE</constant> for the available content types.</entry> + </row> <row><entry></entry></row> </tbody> </tgroup> diff --git a/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml b/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml index 63152ab9efba..e0d49fa329f0 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml @@ -48,9 +48,6 @@ <refsect1> <title>Description</title> - - <para><emphasis role="bold">NOTE:</emphasis> This new ioctl is programmed to be added on Kernel 4.6. Its definition/arguments may change until its final version.</para> - <para>The typical usage of this ioctl is to call it twice. On the first call, the structure defined at &media-v2-topology; should be zeroed. At return, if no errors happen, this ioctl will return the diff --git a/Documentation/DocBook/media/v4l/media-types.xml b/Documentation/DocBook/media/v4l/media-types.xml index 0ee0f3386cdf..5e3f20fdcf17 100644 --- a/Documentation/DocBook/media/v4l/media-types.xml +++ b/Documentation/DocBook/media/v4l/media-types.xml @@ -80,7 +80,46 @@ </row> <row> <entry><constant>MEDIA_ENT_F_TUNER</constant></entry> - <entry>Digital TV, analog TV, radio and/or software radio tuner.</entry> + <entry>Digital TV, analog TV, radio and/or software radio tuner, + with consists on a PLL tuning stage that converts radio + frequency (RF) signal into an Intermediate Frequency (IF). + Modern tuners have internally IF-PLL decoders for audio + and video, but older models have those stages implemented + on separate entities. + </entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_IF_VID_DECODER</constant></entry> + <entry>IF-PLL video decoder. It receives the IF from a PLL + and decodes the analog TV video signal. This is commonly + found on some very old analog tuners, like Philips MK3 + designs. They all contain a tda9887 (or some software + compatible similar chip, like tda9885). Those devices + use a different I2C address than the tuner PLL. + </entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_IF_AUD_DECODER</constant></entry> + <entry>IF-PLL sound decoder. It receives the IF from a PLL + and decodes the analog TV audio signal. This is commonly + found on some very old analog hardware, like Micronas + msp3400, Philips tda9840, tda985x, etc. Those devices + use a different I2C address than the tuner PLL and + should be controlled together with the IF-PLL video + decoder. + </entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_AUDIO_CAPTURE</constant></entry> + <entry>Audio Capture Function Entity.</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_AUDIO_PLAYBACK</constant></entry> + <entry>Audio Playback Function Entity.</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_AUDIO_MIXER</constant></entry> + <entry>Audio Mixer Function Entity.</entry> </row> </tbody> </tgroup> @@ -162,6 +201,46 @@ <entry>Device node interface for Software Defined Radio (V4L)</entry> <entry>typically, /dev/swradio?</entry> </row> + <row> + <entry><constant>MEDIA_INTF_T_ALSA_PCM_CAPTURE</constant></entry> + <entry>Device node interface for ALSA PCM Capture</entry> + <entry>typically, /dev/snd/pcmC?D?c</entry> + </row> + <row> + <entry><constant>MEDIA_INTF_T_ALSA_PCM_PLAYBACK</constant></entry> + <entry>Device node interface for ALSA PCM Playback</entry> + <entry>typically, /dev/snd/pcmC?D?p</entry> + </row> + <row> + <entry><constant>MEDIA_INTF_T_ALSA_CONTROL</constant></entry> + <entry>Device node interface for ALSA Control</entry> + <entry>typically, /dev/snd/controlC?</entry> + </row> + <row> + <entry><constant>MEDIA_INTF_T_ALSA_COMPRESS</constant></entry> + <entry>Device node interface for ALSA Compress</entry> + <entry>typically, /dev/snd/compr?</entry> + </row> + <row> + <entry><constant>MEDIA_INTF_T_ALSA_RAWMIDI</constant></entry> + <entry>Device node interface for ALSA Raw MIDI</entry> + <entry>typically, /dev/snd/midi?</entry> + </row> + <row> + <entry><constant>MEDIA_INTF_T_ALSA_HWDEP</constant></entry> + <entry>Device node interface for ALSA Hardware Dependent</entry> + <entry>typically, /dev/snd/hwC?D?</entry> + </row> + <row> + <entry><constant>MEDIA_INTF_T_ALSA_SEQUENCER</constant></entry> + <entry>Device node interface for ALSA Sequencer</entry> + <entry>typically, /dev/snd/seq</entry> + </row> + <row> + <entry><constant>MEDIA_INTF_T_ALSA_TIMER</constant></entry> + <entry>Device node interface for ALSA Timer</entry> + <entry>typically, /dev/snd/timer</entry> + </row> </tbody> </tgroup> </table> diff --git a/Documentation/DocBook/media/v4l/pixfmt-y12i.xml b/Documentation/DocBook/media/v4l/pixfmt-y12i.xml new file mode 100644 index 000000000000..4a2d1e5f67e4 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-y12i.xml @@ -0,0 +1,49 @@ +<refentry id="V4L2-PIX-FMT-Y12I"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_Y12I ('Y12I')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_Y12I</constant></refname> + <refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>This is a grey-scale image with a depth of 12 bits per pixel, but with +pixels from 2 sources interleaved and bit-packed. Each pixel is stored in a +24-bit word in the little-endian order. On a little-endian machine these pixels +can be deinterlaced using</para> + +<para> +<programlisting> +__u8 *buf; +left0 = 0xfff & *(__u16 *)buf; +right0 = *(__u16 *)(buf + 1) >> 4; +</programlisting> +</para> + + <example> + <title><constant>V4L2_PIX_FMT_Y12I</constant> 2 pixel data stream taking 3 bytes</title> + + <formalpara> + <title>Bit-packed representation</title> + <para>pixels cross the byte boundary and have a ratio of 3 bytes for each + interleaved pixel. + <informaltable frame="all"> + <tgroup cols="3" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>Y'<subscript>0left[7:0]</subscript></entry> + <entry>Y'<subscript>0right[3:0]</subscript>Y'<subscript>0left[11:8]</subscript></entry> + <entry>Y'<subscript>0right[11:4]</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> +</refentry> diff --git a/Documentation/DocBook/media/v4l/pixfmt-y8i.xml b/Documentation/DocBook/media/v4l/pixfmt-y8i.xml new file mode 100644 index 000000000000..99f389d4c6c8 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-y8i.xml @@ -0,0 +1,80 @@ +<refentry id="V4L2-PIX-FMT-Y8I"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_Y8I ('Y8I ')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_Y8I</constant></refname> + <refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>This is a grey-scale image with a depth of 8 bits per pixel, but with +pixels from 2 sources interleaved. Each pixel is stored in a 16-bit word. E.g. +the R200 RealSense camera stores pixel from the left sensor in lower and from +the right sensor in the higher 8 bits.</para> + + <example> + <title><constant>V4L2_PIX_FMT_Y8I</constant> 4 × 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 + 0:</entry> + <entry>Y'<subscript>00left</subscript></entry> + <entry>Y'<subscript>00right</subscript></entry> + <entry>Y'<subscript>01left</subscript></entry> + <entry>Y'<subscript>01right</subscript></entry> + <entry>Y'<subscript>02left</subscript></entry> + <entry>Y'<subscript>02right</subscript></entry> + <entry>Y'<subscript>03left</subscript></entry> + <entry>Y'<subscript>03right</subscript></entry> + </row> + <row> + <entry>start + 8:</entry> + <entry>Y'<subscript>10left</subscript></entry> + <entry>Y'<subscript>10right</subscript></entry> + <entry>Y'<subscript>11left</subscript></entry> + <entry>Y'<subscript>11right</subscript></entry> + <entry>Y'<subscript>12left</subscript></entry> + <entry>Y'<subscript>12right</subscript></entry> + <entry>Y'<subscript>13left</subscript></entry> + <entry>Y'<subscript>13right</subscript></entry> + </row> + <row> + <entry>start + 16:</entry> + <entry>Y'<subscript>20left</subscript></entry> + <entry>Y'<subscript>20right</subscript></entry> + <entry>Y'<subscript>21left</subscript></entry> + <entry>Y'<subscript>21right</subscript></entry> + <entry>Y'<subscript>22left</subscript></entry> + <entry>Y'<subscript>22right</subscript></entry> + <entry>Y'<subscript>23left</subscript></entry> + <entry>Y'<subscript>23right</subscript></entry> + </row> + <row> + <entry>start + 24:</entry> + <entry>Y'<subscript>30left</subscript></entry> + <entry>Y'<subscript>30right</subscript></entry> + <entry>Y'<subscript>31left</subscript></entry> + <entry>Y'<subscript>31right</subscript></entry> + <entry>Y'<subscript>32left</subscript></entry> + <entry>Y'<subscript>32right</subscript></entry> + <entry>Y'<subscript>33left</subscript></entry> + <entry>Y'<subscript>33right</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> +</refentry> diff --git a/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml b/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml index e781cc61786c..7d13fe96657d 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml @@ -1,35 +1,43 @@ - <refentry id="V4L2-PIX-FMT-YUV420M"> + <refentry> <refmeta> - <refentrytitle>V4L2_PIX_FMT_YUV420M ('YM12')</refentrytitle> + <refentrytitle>V4L2_PIX_FMT_YUV420M ('YM12'), V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle> &manvol; </refmeta> <refnamediv> - <refname> <constant>V4L2_PIX_FMT_YUV420M</constant></refname> - <refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant> - with planes non contiguous in memory. </refpurpose> + <refname id="V4L2-PIX-FMT-YUV420M"><constant>V4L2_PIX_FMT_YUV420M</constant></refname> + <refname id="V4L2-PIX-FMT-YVU420M"><constant>V4L2_PIX_FMT_YVU420M</constant></refname> + <refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant> and + <constant>V4L2_PIX_FMT_YVU420</constant> with planes non contiguous + in memory.</refpurpose> </refnamediv> <refsect1> <title>Description</title> <para>This is a multi-planar format, as opposed to a packed format. -The three components are separated into three sub- images or planes. +The three components are separated into three sub-images or planes.</para> -The Y plane is first. The Y plane has one byte per pixel. The Cb data + <para>The Y plane is first. The Y plane has one byte per pixel. +For <constant>V4L2_PIX_FMT_YUV420M</constant> the Cb data constitutes the second plane which is half the width and half the height of the Y plane (and of the image). Each Cb belongs to four pixels, a two-by-two square of the image. For example, Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>, Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and Y'<subscript>11</subscript>. The Cr data, just like the Cb plane, is -in the third plane. </para> +in the third plane.</para> + + <para><constant>V4L2_PIX_FMT_YVU420M</constant> is the same except +the Cr data is stored in the second plane and the Cb data in the third plane. +</para> <para>If the Y plane has pad bytes after each row, then the Cb and Cr planes have half as many pad bytes after their rows. In other words, two Cx rows (including padding) is exactly as long as one Y row (including padding).</para> - <para><constant>V4L2_PIX_FMT_YUV420M</constant> is intended to be + <para><constant>V4L2_PIX_FMT_YUV420M</constant> and +<constant>V4L2_PIX_FMT_YVU420M</constant> are intended to be used only in drivers and applications that support the multi-planar API, described in <xref linkend="planar-apis"/>. </para> diff --git a/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml b/Documentation/DocBook/media/v4l/pixfmt-yuv422m.xml index 2330667907c7..dd502802cb75 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-yuv422m.xml @@ -1,40 +1,45 @@ - <refentry id="V4L2-PIX-FMT-YVU420M"> + <refentry> <refmeta> - <refentrytitle>V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle> + <refentrytitle>V4L2_PIX_FMT_YUV422M ('YM16'), V4L2_PIX_FMT_YVU422M ('YM61')</refentrytitle> &manvol; </refmeta> <refnamediv> - <refname> <constant>V4L2_PIX_FMT_YVU420M</constant></refname> - <refpurpose>Variation of <constant>V4L2_PIX_FMT_YVU420</constant> - with planes non contiguous in memory. </refpurpose> + <refname id="V4L2-PIX-FMT-YUV422M"><constant>V4L2_PIX_FMT_YUV422M</constant></refname> + <refname id="V4L2-PIX-FMT-YVU422M"><constant>V4L2_PIX_FMT_YVU422M</constant></refname> + <refpurpose>Planar formats with ½ horizontal resolution, also + known as YUV and YVU 4:2:2</refpurpose> </refnamediv> <refsect1> <title>Description</title> <para>This is a multi-planar format, as opposed to a packed format. -The three components are separated into three sub-images or planes. +The three components are separated into three sub-images or planes.</para> -The Y plane is first. The Y plane has one byte per pixel. The Cr data -constitutes the second plane which is half the width and half -the height of the Y plane (and of the image). Each Cr belongs to four -pixels, a two-by-two square of the image. For example, -Cr<subscript>0</subscript> belongs to Y'<subscript>00</subscript>, -Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and -Y'<subscript>11</subscript>. The Cb data, just like the Cr plane, constitutes -the third plane. </para> + <para>The Y plane is first. The Y plane has one byte per pixel. +For <constant>V4L2_PIX_FMT_YUV422M</constant> the Cb data +constitutes the second plane which is half the width of the Y plane (and of the +image). Each Cb belongs to two pixels. For example, +Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>, +Y'<subscript>01</subscript>. The Cr data, just like the Cb plane, is +in the third plane. </para> - <para>If the Y plane has pad bytes after each row, then the Cr -and Cb planes have half as many pad bytes after their rows. In other + <para><constant>V4L2_PIX_FMT_YVU422M</constant> is the same except +the Cr data is stored in the second plane and the Cb data in the third plane. +</para> + + <para>If the Y plane has pad bytes after each row, then the Cb +and Cr planes have half as many pad bytes after their rows. In other words, two Cx rows (including padding) is exactly as long as one Y row (including padding).</para> - <para><constant>V4L2_PIX_FMT_YVU420M</constant> is intended to be + <para><constant>V4L2_PIX_FMT_YUV422M</constant> and +<constant>V4L2_PIX_FMT_YVU422M</constant> are intended to be used only in drivers and applications that support the multi-planar API, described in <xref linkend="planar-apis"/>. </para> <example> - <title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 × 4 + <title><constant>V4L2_PIX_FMT_YUV422M</constant> 4 × 4 pixel image</title> <formalpara> @@ -75,24 +80,44 @@ pixel image</title> <row><entry></entry></row> <row> <entry>start1 + 0:</entry> - <entry>Cr<subscript>00</subscript></entry> - <entry>Cr<subscript>01</subscript></entry> + <entry>Cb<subscript>00</subscript></entry> + <entry>Cb<subscript>01</subscript></entry> </row> <row> <entry>start1 + 2:</entry> - <entry>Cr<subscript>10</subscript></entry> - <entry>Cr<subscript>11</subscript></entry> + <entry>Cb<subscript>10</subscript></entry> + <entry>Cb<subscript>11</subscript></entry> + </row> + <row> + <entry>start1 + 4:</entry> + <entry>Cb<subscript>20</subscript></entry> + <entry>Cb<subscript>21</subscript></entry> + </row> + <row> + <entry>start1 + 6:</entry> + <entry>Cb<subscript>30</subscript></entry> + <entry>Cb<subscript>31</subscript></entry> </row> <row><entry></entry></row> <row> <entry>start2 + 0:</entry> - <entry>Cb<subscript>00</subscript></entry> - <entry>Cb<subscript>01</subscript></entry> + <entry>Cr<subscript>00</subscript></entry> + <entry>Cr<subscript>01</subscript></entry> </row> <row> <entry>start2 + 2:</entry> - <entry>Cb<subscript>10</subscript></entry> - <entry>Cb<subscript>11</subscript></entry> + <entry>Cr<subscript>10</subscript></entry> + <entry>Cr<subscript>11</subscript></entry> + </row> + <row> + <entry>start2 + 4:</entry> + <entry>Cr<subscript>20</subscript></entry> + <entry>Cr<subscript>21</subscript></entry> + </row> + <row> + <entry>start2 + 6:</entry> + <entry>Cr<subscript>30</subscript></entry> + <entry>Cr<subscript>31</subscript></entry> </row> </tbody> </tgroup> @@ -113,36 +138,23 @@ pixel image</title> </row> <row> <entry>0</entry> - <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> - <entry>Y</entry><entry></entry><entry>Y</entry> - </row> - <row> - <entry></entry> - <entry></entry><entry>C</entry><entry></entry><entry></entry> - <entry></entry><entry>C</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> </row> <row> <entry>1</entry> - <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> - <entry>Y</entry><entry></entry><entry>Y</entry> - </row> - <row> - <entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> </row> <row> <entry>2</entry> - <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> - <entry>Y</entry><entry></entry><entry>Y</entry> - </row> - <row> - <entry></entry> - <entry></entry><entry>C</entry><entry></entry><entry></entry> - <entry></entry><entry>C</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> </row> <row> <entry>3</entry> - <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> - <entry>Y</entry><entry></entry><entry>Y</entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> </row> </tbody> </tgroup> diff --git a/Documentation/DocBook/media/v4l/pixfmt-yuv444m.xml b/Documentation/DocBook/media/v4l/pixfmt-yuv444m.xml new file mode 100644 index 000000000000..1b7335940bc7 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-yuv444m.xml @@ -0,0 +1,177 @@ + <refentry> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_YUV444M ('YM24'), V4L2_PIX_FMT_YVU444M ('YM42')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname id="V4L2-PIX-FMT-YUV444M"><constant>V4L2_PIX_FMT_YUV444M</constant></refname> + <refname id="V4L2-PIX-FMT-YVU444M"><constant>V4L2_PIX_FMT_YVU444M</constant></refname> + <refpurpose>Planar formats with full horizontal resolution, also + known as YUV and YVU 4:4:4</refpurpose> + </refnamediv> + + <refsect1> + <title>Description</title> + + <para>This is a multi-planar format, as opposed to a packed format. +The three components are separated into three sub-images or planes.</para> + + <para>The Y plane is first. The Y plane has one byte per pixel. +For <constant>V4L2_PIX_FMT_YUV444M</constant> the Cb data +constitutes the second plane which is the same width and height as the Y plane +(and as the image). The Cr data, just like the Cb plane, is in the third plane. +</para> + + <para><constant>V4L2_PIX_FMT_YVU444M</constant> is the same except +the Cr data is stored in the second plane and the Cb data in the third plane. +</para> + <para>If the Y plane has pad bytes after each row, then the Cb +and Cr planes have the same number of pad bytes after their rows.</para> + + <para><constant>V4L2_PIX_FMT_YUV444M</constant> and +<constant>V4L2_PIX_FMT_YUV444M</constant> are intended to be +used only in drivers and applications that support the multi-planar API, +described in <xref linkend="planar-apis"/>. </para> + + <example> + <title><constant>V4L2_PIX_FMT_YUV444M</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="5" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start0 + 0:</entry> + <entry>Y'<subscript>00</subscript></entry> + <entry>Y'<subscript>01</subscript></entry> + <entry>Y'<subscript>02</subscript></entry> + <entry>Y'<subscript>03</subscript></entry> + </row> + <row> + <entry>start0 + 4:</entry> + <entry>Y'<subscript>10</subscript></entry> + <entry>Y'<subscript>11</subscript></entry> + <entry>Y'<subscript>12</subscript></entry> + <entry>Y'<subscript>13</subscript></entry> + </row> + <row> + <entry>start0 + 8:</entry> + <entry>Y'<subscript>20</subscript></entry> + <entry>Y'<subscript>21</subscript></entry> + <entry>Y'<subscript>22</subscript></entry> + <entry>Y'<subscript>23</subscript></entry> + </row> + <row> + <entry>start0 + 12:</entry> + <entry>Y'<subscript>30</subscript></entry> + <entry>Y'<subscript>31</subscript></entry> + <entry>Y'<subscript>32</subscript></entry> + <entry>Y'<subscript>33</subscript></entry> + </row> + <row><entry></entry></row> + <row> + <entry>start1 + 0:</entry> + <entry>Cb<subscript>00</subscript></entry> + <entry>Cb<subscript>01</subscript></entry> + <entry>Cb<subscript>02</subscript></entry> + <entry>Cb<subscript>03</subscript></entry> + </row> + <row> + <entry>start1 + 4:</entry> + <entry>Cb<subscript>10</subscript></entry> + <entry>Cb<subscript>11</subscript></entry> + <entry>Cb<subscript>12</subscript></entry> + <entry>Cb<subscript>13</subscript></entry> + </row> + <row> + <entry>start1 + 8:</entry> + <entry>Cb<subscript>20</subscript></entry> + <entry>Cb<subscript>21</subscript></entry> + <entry>Cb<subscript>22</subscript></entry> + <entry>Cb<subscript>23</subscript></entry> + </row> + <row> + <entry>start1 + 12:</entry> + <entry>Cb<subscript>20</subscript></entry> + <entry>Cb<subscript>21</subscript></entry> + <entry>Cb<subscript>32</subscript></entry> + <entry>Cb<subscript>33</subscript></entry> + </row> + <row><entry></entry></row> + <row> + <entry>start2 + 0:</entry> + <entry>Cr<subscript>00</subscript></entry> + <entry>Cr<subscript>01</subscript></entry> + <entry>Cr<subscript>02</subscript></entry> + <entry>Cr<subscript>03</subscript></entry> + </row> + <row> + <entry>start2 + 4:</entry> + <entry>Cr<subscript>10</subscript></entry> + <entry>Cr<subscript>11</subscript></entry> + <entry>Cr<subscript>12</subscript></entry> + <entry>Cr<subscript>13</subscript></entry> + </row> + <row> + <entry>start2 + 8:</entry> + <entry>Cr<subscript>20</subscript></entry> + <entry>Cr<subscript>21</subscript></entry> + <entry>Cr<subscript>22</subscript></entry> + <entry>Cr<subscript>23</subscript></entry> + </row> + <row> + <entry>start2 + 12:</entry> + <entry>Cr<subscript>30</subscript></entry> + <entry>Cr<subscript>31</subscript></entry> + <entry>Cr<subscript>32</subscript></entry> + <entry>Cr<subscript>33</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + + <formalpara> + <title>Color Sample Location.</title> + <para> + <informaltable frame="none"> + <tgroup cols="7" align="center"> + <tbody valign="top"> + <row> + <entry></entry> + <entry>0</entry><entry></entry><entry>1</entry><entry></entry> + <entry>2</entry><entry></entry><entry>3</entry> + </row> + <row> + <entry>0</entry> + <entry>YC</entry><entry></entry><entry>YC</entry><entry></entry> + <entry>YC</entry><entry></entry><entry>YC</entry> + </row> + <row> + <entry>1</entry> + <entry>YC</entry><entry></entry><entry>YC</entry><entry></entry> + <entry>YC</entry><entry></entry><entry>YC</entry> + </row> + <row> + <entry>2</entry> + <entry>YC</entry><entry></entry><entry>YC</entry><entry></entry> + <entry>YC</entry><entry></entry><entry>YC</entry> + </row> + <row> + <entry>3</entry> + <entry>YC</entry><entry></entry><entry>YC</entry><entry></entry> + <entry>YC</entry><entry></entry><entry>YC</entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> + </refentry> diff --git a/Documentation/DocBook/media/v4l/pixfmt-z16.xml b/Documentation/DocBook/media/v4l/pixfmt-z16.xml new file mode 100644 index 000000000000..3d87e4bf87b8 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-z16.xml @@ -0,0 +1,81 @@ +<refentry id="V4L2-PIX-FMT-Z16"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_Z16 ('Z16 ')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_Z16</constant></refname> + <refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>This is a 16-bit format, representing depth data. Each pixel is a +distance to the respective point in the image coordinates. Distance unit can +vary and has to be negotiated with the device separately. Each pixel is stored +in a 16-bit word in the little endian byte order. +</para> + + <example> + <title><constant>V4L2_PIX_FMT_Z16</constant> 4 × 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 + 0:</entry> + <entry>Z<subscript>00low</subscript></entry> + <entry>Z<subscript>00high</subscript></entry> + <entry>Z<subscript>01low</subscript></entry> + <entry>Z<subscript>01high</subscript></entry> + <entry>Z<subscript>02low</subscript></entry> + <entry>Z<subscript>02high</subscript></entry> + <entry>Z<subscript>03low</subscript></entry> + <entry>Z<subscript>03high</subscript></entry> + </row> + <row> + <entry>start + 8:</entry> + <entry>Z<subscript>10low</subscript></entry> + <entry>Z<subscript>10high</subscript></entry> + <entry>Z<subscript>11low</subscript></entry> + <entry>Z<subscript>11high</subscript></entry> + <entry>Z<subscript>12low</subscript></entry> + <entry>Z<subscript>12high</subscript></entry> + <entry>Z<subscript>13low</subscript></entry> + <entry>Z<subscript>13high</subscript></entry> + </row> + <row> + <entry>start + 16:</entry> + <entry>Z<subscript>20low</subscript></entry> + <entry>Z<subscript>20high</subscript></entry> + <entry>Z<subscript>21low</subscript></entry> + <entry>Z<subscript>21high</subscript></entry> + <entry>Z<subscript>22low</subscript></entry> + <entry>Z<subscript>22high</subscript></entry> + <entry>Z<subscript>23low</subscript></entry> + <entry>Z<subscript>23high</subscript></entry> + </row> + <row> + <entry>start + 24:</entry> + <entry>Z<subscript>30low</subscript></entry> + <entry>Z<subscript>30high</subscript></entry> + <entry>Z<subscript>31low</subscript></entry> + <entry>Z<subscript>31high</subscript></entry> + <entry>Z<subscript>32low</subscript></entry> + <entry>Z<subscript>32high</subscript></entry> + <entry>Z<subscript>33low</subscript></entry> + <entry>Z<subscript>33high</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> +</refentry> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index d871245d2973..5a08aeea4360 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -1620,6 +1620,8 @@ information.</para> &sub-y10b; &sub-y16; &sub-y16-be; + &sub-y8i; + &sub-y12i; &sub-uv8; &sub-yuyv; &sub-uyvy; @@ -1628,7 +1630,8 @@ information.</para> &sub-y41p; &sub-yuv420; &sub-yuv420m; - &sub-yvu420m; + &sub-yuv422m; + &sub-yuv444m; &sub-yuv410; &sub-yuv422p; &sub-yuv411p; @@ -1641,6 +1644,14 @@ information.</para> &sub-m420; </section> + <section id="depth-formats"> + <title>Depth Formats</title> + <para>Depth data provides distance to points, mapped onto the image plane + </para> + + &sub-z16; + </section> + <section> <title>Compressed Formats</title> diff --git a/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml b/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml index e9c70a8f3476..0c93677d16b4 100644 --- a/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml +++ b/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml @@ -60,9 +60,19 @@ input</refpurpose> automatically, similar to sensing the video standard. To do so, applications call <constant>VIDIOC_QUERY_DV_TIMINGS</constant> with a pointer to a &v4l2-dv-timings;. Once the hardware detects the timings, it will fill in the -timings structure. +timings structure.</para> -If the timings could not be detected because there was no signal, then +<para>Please note that drivers shall <emphasis>not</emphasis> switch timings automatically +if new timings are detected. Instead, drivers should send the +<constant>V4L2_EVENT_SOURCE_CHANGE</constant> event (if they support this) and expect +that userspace will take action by calling <constant>VIDIOC_QUERY_DV_TIMINGS</constant>. +The reason is that new timings usually mean different buffer sizes as well, and you +cannot change buffer sizes on the fly. In general, applications that receive the +Source Change event will have to call <constant>VIDIOC_QUERY_DV_TIMINGS</constant>, +and if the detected timings are valid they will have to stop streaming, set the new +timings, allocate new buffers and start streaming again.</para> + +<para>If the timings could not be detected because there was no signal, then <errorcode>ENOLINK</errorcode> is returned. If a signal was detected, but it was unstable and the receiver could not lock to the signal, then <errorcode>ENOLCK</errorcode> is returned. If the receiver could lock to the signal, diff --git a/Documentation/DocBook/media/v4l/vidioc-querystd.xml b/Documentation/DocBook/media/v4l/vidioc-querystd.xml index 222348542182..3ceae35fab03 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querystd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querystd.xml @@ -59,6 +59,16 @@ then the driver will return V4L2_STD_UNKNOWN. When detection is not possible or fails, the set must contain all standards supported by the current video input or output.</para> +<para>Please note that drivers shall <emphasis>not</emphasis> switch the video standard +automatically if a new video standard is detected. Instead, drivers should send the +<constant>V4L2_EVENT_SOURCE_CHANGE</constant> event (if they support this) and expect +that userspace will take action by calling <constant>VIDIOC_QUERYSTD</constant>. +The reason is that a new video standard can mean different buffer sizes as well, and you +cannot change buffer sizes on the fly. In general, applications that receive the +Source Change event will have to call <constant>VIDIOC_QUERYSTD</constant>, +and if the detected video standard is valid they will have to stop streaming, set the new +standard, allocate new buffers and start streaming again.</para> + </refsect1> <refsect1> diff --git a/Documentation/DocBook/usb.tmpl b/Documentation/DocBook/usb.tmpl index 4cd5b2cd0f3d..bc776be0f19c 100644 --- a/Documentation/DocBook/usb.tmpl +++ b/Documentation/DocBook/usb.tmpl @@ -732,6 +732,18 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param) or SET_INTERFACE. </para></warning></listitem></varlistentry> + <varlistentry><term>USBDEVFS_DROP_PRIVILEGES</term> + <listitem><para>This is used to relinquish the ability + to do certain operations which are considered to be + privileged on a usbfs file descriptor. + This includes claiming arbitrary interfaces, resetting + a device on which there are currently claimed interfaces + from other users, and issuing USBDEVFS_IOCTL calls. + The ioctl parameter is a 32 bit mask of interfaces + the user is allowed to claim on this file descriptor. + You may issue this ioctl more than one time to narrow + said mask. + </para></listitem></varlistentry> </variablelist> </sect2> |