Searched full:image (Results 1 – 25 of 377) sorted by relevance
12345678910>>...16
| /Documentation/powerpc/ |
| D | bootwrapper.rst | 7 PowerPC image targets compresses and wraps the kernel image (vmlinux) with
10 be adaptable for each kind of image that needs to be built.
13 Makefile in that directory has targets for all the available image types.
14 The different image types are used to support all of the various firmware
19 firmware interface requires a different image format.
23 image. The details of the build system is discussed in the next section.
24 Currently, the following image format targets exist:
29 tree). This image embeds a device tree blob inside
30 the image. The boot wrapper, kernel and device tree
48 inside the image instead of provided by firmware. The
[all …]
|
| /Documentation/media/uapi/v4l/ |
| D | ext-ctrls-image-source.rst | 13 Image Source Control Reference
16 The Image Source control class is intended for low-level control of
17 image source devices such as image sensors. The devices feature an
19 image data out of the device.
24 Image Source Control IDs
32 image data is produced. The unit of vertical blanking is a line.
33 Every line has length of the image width plus horizontal blanking at
38 Horizontal blanking. The idle period after every line of image data
39 during which no image data is produced. The unit of horizontal
|
| D | selection-api-intro.rst | 15 shrink or enlarge it to an image of arbitrary size. Next, the devices
16 can insert the image into larger one. Some video output devices can crop
17 part of an input image, scale it up or down and insert it at an
23 image stored in a memory buffer. The composing area specifies which part
26 On a video *output* device the source is an image in a memory buffer,
27 and the cropping target is a part of an image to be shown on a display.
29 select the part of display where the image should be displayed. The size
|
| D | dev-subdev.rst | 37 - negotiate image formats on individual pads
52 sensors and image processing hardware implement identical functions,
94 Image formats are typically negotiated on video capture and output
101 image sizes at the output of a pipeline can be achieved using different
103 :ref:`pipeline-scaling`, where image scaling can be performed on both
104 the video sensor and the host image processing hardware.
113 Image Format Negotiation on Pipelines
126 can expose pad-level image format configuration to applications. When
138 Pad-level image format configuration support can be tested by calling
342 interest in an image, typically on an image sensor or a video decoder.
[all …]
|
| D | ext-ctrls-image-process.rst | 13 Image Process Control Reference
16 The Image Process control class is intended for low-level control of
17 image processing functions. Unlike ``V4L2_CID_IMAGE_SOURCE_CLASS``, the
18 controls in this class affect processing the image, and do not control
24 Image Process Control IDs
34 elsewhere, if the device is not an image sensor). The frame rate can
35 be calculated from the pixel clock, image width and height and
|
| D | format.rst | 23 abundance of image formats. Although drivers must provide a default and
39 image formats see :ref:`pixfmt`.
52 can invalidate the selected image format. Therefore only the file
58 image size.
78 Image Format Enumeration
82 enumerate all image formats supported by video capture, overlay or
86 by all drivers exchanging image data with applications.
90 Drivers are not supposed to convert image formats in kernel space.
|
| D | pixfmt.rst | 13 Image Formats
15 The V4L2 API was primarily designed for devices exchanging image data
18 format and layout of an image in memory. The former is used with the
20 version (see :ref:`planar-apis`). Image formats are negotiated with
|
| D | pixfmt-v4l2.rst | 27 - Image width in pixels.
30 - Image height in pixels. If ``field`` is one of ``V4L2_FIELD_TOP``,
35 * - :cspan:`2` Applications set these fields to request an image
40 example when the image format is YUV 4:2:0, ``width`` and
78 after the last line of an image cross a system page boundary.
82 When the image format is planar the ``bytesperline`` value applies
85 planes of a YUV 4:2:0 image have half as many padding bytes
94 - Size in bytes of the buffer to hold a complete image, set by the
96 the image consists of variable length compressed data this is the
111 - Image colorspace, from enum :c:type:`v4l2_colorspace`.
|
| D | ext-ctrls-jpeg.rst | 34 input image is sampled, in respect to maximum sample rate in each
38 image from RGB to Y'CbCr color space.
65 image independently. For the lossy compression processes the restart
75 between image quality and size. It provides simpler method for
76 applications to control image quality, without a need for direct
85 where larger values correspond to better image quality.
|
| D | selection-api-configuration.rst | 60 the image size set by :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`.
62 The part of a buffer into which the image is inserted by the hardware is
91 image into a video signal. The cropping rectangles refer to a memory
95 The cropping targets refer to the memory buffer that contains an image
99 point ``(0,0)``. The width and height is equal to the image size
103 the area from which image date are processed by the hardware, is given
114 The part of a video signal or graphics display where the image is
129 an image from memory buffers. It includes borders around an image.
|
| /Documentation/driver-api/ |
| D | dell_rbu.rst | 16 update itself with the image downloaded in to the memory.
31 Dell_RBU driver supports BIOS update using the monolithic image and packetized
32 image methods. In case of monolithic the driver allocates a contiguous chunk
33 of physical pages having the BIOS image. In case of packetized the app
34 using the driver breaks the image in to packets of fixed sizes and the driver
43 The user should not unload the rbu driver after downloading the BIOS image
56 Most of the Dell systems support a monolithic update where the BIOS image is
60 of contiguous memory and the BIOS image is scattered in these packets.
75 The user creates packets header, gets the chunk of the BIOS image and
76 places it next to the packetheader; now, the packetheader + BIOS image chunk
[all …]
|
| /Documentation/power/ |
| D | userland-swsusp.rst | 56 uploaded snapshot image; before calling it you should transfer
59 image is not available to the kernel
62 free memory allocated for the snapshot image
65 set the preferred maximum size of the image
66 (the kernel will do its best to ensure the image size will not exceed
68 create the smallest image possible)
71 return the actual size of the hibernation image
111 suspend image is first created, as though the system had been suspended
114 its state on the basis of the saved suspend image otherwise)
116 The device's read() operation can be used to transfer the snapshot image from
[all …]
|
| D | swsusp.rst | 51 - If you would like to write hibernation image to swap and then suspend
62 If you want to limit the suspend image size to N bytes, do::
69 if found, it then checks the contents for the hibernation image signature.
70 If both are found, it resumes the hibernation image.
106 parameter, it saves hibernation image without compression.
152 Instead, we load the image into unused memory and then atomically copy
154 image size of half the amount of memory.
183 allows for arbitrary transformations on the image (compression,
184 encryption) and arbitrary backends for writing the image (eg to swap
225 * Write image to disk
[all …]
|
| /Documentation/driver-api/fpga/ |
| D | fpga-programming.rst | 22 The struct fpga_image_info specifies what FPGA image to program. It is
41 * First, alloc the struct with information about the FPGA image to
52 * Indicate where the FPGA image is. This is pseudo-code; you're
55 if (image is in a scatter gather table) {
59 } else if (image is in a buffer) {
61 info->buf = [your image buffer]
62 info->count = [image buffer size]
64 } else if (image is in a firmware file) {
75 /* Deallocate the image info if you're done with it */
88 * :c:type:`fpga_image_info` — Specifies what FPGA image to program
[all …]
|
| D | fpga-mgr.rst | 8 an image. The API is manufacturer agnostic. All manufacturer specifics are
10 The FPGA image data itself is very manufacturer specific, but for our purposes
13 The FPGA image to be programmed can be in a scatter gather list, a single
18 The particulars for programming the image are presented in a structure (struct
20 FPGA image as well as image-specific particulars such as whether the image was
81 The .write_init function will prepare the FPGA to receive the image data. The
87 whole FPGA image or may be a smaller chunk of an FPGA image. In the latter
94 The .write_complete function is called after all the image has been written
|
| /Documentation/driver-api/early-userspace/ |
| D | early_userspace_support.rst | 16 containing a root filesystem image. This archive is compressed, and
17 the compressed image is linked into the kernel image.
18 - initramfs, a chunk of code that unpacks the compressed cpio image
25 two ways to add an early userspace image: specify an existing cpio
26 archive to be used as the image or have the kernel build process build
27 the image from specifications.
32 You can create a cpio archive that contains the early userspace image.
38 IMAGE BUILDING method
41 The kernel build process can also build an early userspace image from
43 a way to create images with root-owned files even though the image was
[all …]
|
| /Documentation/riscv/ |
| D | boot-image-header.rst | 2 Boot image header in RISC-V Linux
8 This document only describes the boot image header details for RISC-V Linux.
13 The following 64-byte header is present in decompressed Linux kernel image::
17 u64 text_offset; /* Image load offset, little endian */
18 u64 image_size; /* Effective Image size, little endian */
35 specification needs PE/COFF image header in the beginning of the kernel image
61 - Image size is mandatory for boot loader to load kernel image. Booting will
|
| /Documentation/arm64/ |
| D | booting.rst | 28 3. Decompress the kernel image
29 4. Call the kernel image
56 the 512 MB region starting at text_offset bytes below the kernel Image.
58 3. Decompress the kernel image
65 loader if a compressed Image target (e.g. Image.gz) is used. For
67 Image target is available instead.
70 4. Call the kernel image
75 The decompressed kernel image contains a 64-byte header as follows::
79 u64 text_offset; /* Image load offset, little endian */
80 u64 image_size; /* Effective Image size, little endian */
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-bus-rbd | 8 Usage: <mon ip addr> <options> <pool name> <rbd image name> [<snap name>]
12 The snapshot name can be "-" or omitted to map the image
29 running requests and then unmap the image. Requests sent to the
92 image resides. An rbd image name is unique
95 name: (RO) The name of the rbd image.
97 refresh: (WO) Writing to this file will reread the image
110 (RO) The unique identifier for the rbd image's pool. This is a
120 image_id: (RO) The unique id for the rbd image. (For rbd
121 image format 1 this is empty.)
124 for this image.
[all …]
|
| D | sysfs-devices-platform-stratix10-rsu | 8 (RO) the address in flash of currently running image.
15 (RO) the address in flash of failed image.
68 (RO) the error offset inside the image that failed.
82 (RO) the current image's retry counter, which is used by
92 (WO) the address in flash of image to be loaded on next
116 1 firmware to reset current image retry
|
| /Documentation/devicetree/bindings/media/i2c/ |
| D | ov5647.txt | 1 Omnivision OV5647 raw image sensor
4 OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
14 used to specify link to the image data receiver. The OV5647 device
|
| D | ov7740.txt | 1 * Omnivision OV7740 CMOS image sensor
3 The Omnivision OV7740 image sensor supports multiple output image
8 be used to specify link to the image data receiver. The OV7740 device
|
| /Documentation/sphinx/ |
| D | kfigure.py | 4 scalable figure and image handling
7 Sphinx extension which implements scalable image handling.
12 The build for image formats depend on image's source format and output's
13 destination format. This extension implement methods to simplify image
19 * ``.. kernel-image``: for image handling / a ``.. image::`` replacement
133 # image handling
134 app.add_directive("kernel-image", KernelImage)
205 """Convert a image node for the builder.
207 Different builder prefer different image formats, e.g. *latex* builder
210 This function handles output image formats in dependence of source the
[all …]
|
| /Documentation/driver-api/mtd/ |
| D | intel-spi.rst | 12 allows upgrading the BIOS image directly from an OS.
21 Please keep in mind that overwriting the BIOS image on SPI serial flash
28 1) Download and extract the latest Minnowboard MAX BIOS SPI image
29 [1]. At the time writing this the latest image is v92.
48 5) Make backup of the existing image first::
69 8) Once completed without errors you can write the new BIOS image:
74 BIOS image::
|
| /Documentation/devicetree/bindings/media/ |
| D | samsung-s5k6a3.txt | 1 Samsung S5K6A3(YX) raw image sensor
4 S5K6A3(YX) is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
27 used to specify link to the image data receiver. The S5K6A3(YX) device
|
12345678910>>...16