Searched full:image (Results 1 – 25 of 527) sorted by relevance
12345678910>>...22
| /Documentation/arch/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/admin-guide/media/ |
| D | raspberrypi-pisp-be.rst | 10 The PiSP Back End is a memory-to-memory Image Signal Processor (ISP) which reads
11 image data from DRAM memory and performs image processing as specified by the
16 Image Signal Processor (PiSP) Specification document`_
18 The PiSP Back End ISP processes images in tiles. The handling of image
23 The full image processing pipeline, which involves capturing RAW Bayer data from
24 an image sensor through a MIPI CSI-2 compatible capture interface, storing them
52 - pispbe-stitch_input: output device for image stitching (HDR).
56 - pispbe-stitch_output: capture device for image stitching (HDR).
63 node. For a list of image formats supported as input to the ISP refer to the
64 `Raspberry Pi Image Signal Processor (PiSP) Specification document`_.
[all …]
|
| /Documentation/admin-guide/ |
| 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
113 suspend image is first created, as though the system had been suspended
116 its state on the basis of the saved suspend image otherwise)
118 The device's read() operation can be used to transfer the snapshot image from
[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 * 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
92 .write function will get image buffer starting at header_size offset from the
94 the image buffer, otherwise .write will get data up to the end of image buffer.
95 This will not affect .write_sg, .write_sg will still get whole image in
96 sg_table form. If FPGA image is already mapped as a single contiguous buffer,
97 whole buffer will be passed into .parse_header. If image is in scatter-gather
[all …]
|
| /Documentation/userspace-api/media/v4l/ |
| D | selection-api-intro.rst | 8 shrink or enlarge it to an image of arbitrary size. Next, the devices
9 can insert the image into larger one. Some video output devices can crop
10 part of an input image, scale it up or down and insert it at an
16 image stored in a memory buffer. The composing area specifies which part
19 On a video *output* device the source is an image in a memory buffer,
20 and the cropping target is a part of an image to be shown on a display.
22 select the part of display where the image should be displayed. The size
|
| D | ext-ctrls-image-source.rst | 6 Image Source Control Reference
9 The Image Source control class is intended for low-level control of
10 image source devices such as image sensors. The devices feature an
12 image data out of the device.
17 Image Source Control IDs
25 image data is produced. The unit of vertical blanking is a line.
26 Every line has length of the image width plus horizontal blanking at
31 Horizontal blanking. The idle period after every line of image data
32 during which no image data is produced. The unit of horizontal
|
| D | pixfmt.rst | 6 Image Formats
8 The V4L2 API was primarily designed for devices exchanging image data
11 format and layout of an image in memory. The former is used with the
13 version (see :ref:`planar-apis`). Image formats are negotiated with
|
| D | format.rst | 16 abundance of image formats. Although drivers must provide a default and
32 image formats see :ref:`pixfmt`.
45 can invalidate the selected image format. Therefore only the file
51 image size.
70 Image Format Enumeration
74 enumerate all image formats supported by video capture, overlay or
78 by all drivers exchanging image data with applications.
82 Drivers are not supposed to convert image formats in kernel space.
|
| D | metafmt-pisp-be.rst | 12 The Raspberry Pi PiSP Back End memory-to-memory image signal processor is
22 <https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf>`_
29 The global configuration data describe how the pixels in a particular image are
30 to be processed and is therefore shared across all the tiles of the image. So
41 a single tile in an image is going to be processed. A single set of tile
54 <https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf>`_.
|
| D | dev-subdev.rst | 30 - 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
344 interest in an image, typically on an image sensor or a video decoder.
[all …]
|
| D | metafmt-vivid.rst | 30 - Image brightness, the value is in the range 0 to 255, with the default value as 128.
32 - Image contrast, the value is in the range 0 to 255, with the default value as 128.
34 - Image color saturation, the value is in the range 0 to 255, with the default value as 128.
36 - Image color balance, the value is in the range -128 to 128, with the default value as 0.
|
| D | pixfmt-v4l2.rst | 20 - Image width in pixels.
23 - Image height in pixels. If ``field`` is one of ``V4L2_FIELD_TOP``,
28 * - :cspan:`2` Applications set these fields to request an image
33 example when the image format is YUV 4:2:0, ``width`` and
76 after the last line of an image cross a system page boundary.
80 When the image format is planar the ``bytesperline`` value applies
83 planes of a YUV 4:2:0 image have half as many padding bytes
92 - Size in bytes of the buffer to hold a complete image, set by the
94 the image consists of variable length compressed data this is the
109 - Image colorspace, from enum :c:type:`v4l2_colorspace`.
[all …]
|
| D | ext-ctrls-image-process.rst | 6 Image Process Control Reference
9 The Image Process control class is intended for low-level control of
10 image processing functions. Unlike ``V4L2_CID_IMAGE_SOURCE_CLASS``, the
11 controls in this class affect processing the image, and do not control
17 Image Process Control IDs
|
| /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/arch/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.
10 The following 64-byte header is present in decompressed Linux kernel image::
14 u64 text_offset; /* Image load offset, little endian */
15 u64 image_size; /* Effective Image size, little endian */
32 needs PE/COFF image header in the beginning of the kernel image in order to
58 - Image size is mandatory for boot loader to load kernel image. Booting will
|
| /Documentation/devicetree/bindings/media/ |
| D | st,stm32-dma2d.yaml | 15 - Filling a part or the whole of a destination image with a specific color.
16 - Copying a part or the whole of a source image into a part or the whole of
17 a destination image.
18 - Copying a part or the whole of a source image into a part or the whole of
19 a destination image with a pixel format conversion.
21 format and copy the result into a part or the whole of a destination image
|
| /Documentation/ABI/testing/ |
| D | sysfs-platform-intel-ifs | 38 Description: Version (hexadecimal) of loaded IFS test image. If no test image
39 is loaded reports "none". Only present for device instances where a test image
47 Description: Write a number less than or equal to 0xff to load an IFS test image.
50 Reading the file will provide the suffix of the currently loaded IFS test image.
51 This file is present only for device instances where a test image is applicable.
|
| D | sysfs-bus-rbd | 8 Usage: <mon ip addr> <options> <pool name> <rbd image name> [<snap name>]
14 The snapshot name can be "-" or omitted to map the image
33 running requests and then unmap the image. Requests sent to the
98 image resides. An rbd image name is unique
101 name (RO) The name of the rbd image.
103 refresh (WO) Writing to this file will reread the image
117 (RO) The unique identifier for the rbd image's pool. This is a
128 image_id (RO) The unique id for the rbd image. (For rbd
129 image format 1 this is empty.)
132 for this image.
[all …]
|
| /Documentation/admin-guide/pm/ |
| D | sleep-states.rst | 122 creates a snapshot image of memory to be written into persistent storage. Next,
123 the system goes into a state in which the snapshot image can be saved, the image
128 Once the snapshot image has been written out, the system may either enter a
139 (referred to as the ``restore kernel``) looks for a hibernation image in
142 the image contents and jumps into a special trampoline area in the original
143 kernel stored in the image (referred to as the ``image kernel``), which is where
145 image kernel restores the system to the pre-hibernation state and allows user
199 hibernation image.
211 hibernation image (platforms with ACPI do that as a rule, for
224 the hibernation image and continue. Otherwise, use the image
[all …]
|
| /Documentation/driver-api/mtd/ |
| D | spi-intel.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/networking/devlink/ |
| D | iosm.rst | 37 It supports updating the device flash using a combined flash image which contains
41 firmware image that need to be flashed as requested by user space application.
42 Supported firmware image types.
44 .. list-table:: Firmware Image types
50 - Primary Signed Image
54 - Modem Software Image
58 image is flashed to the device. The modem software image contains multiple files
71 image using devlink flash command.
|
| /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
129 # image handling
130 app.add_directive("kernel-image", KernelImage)
240 """Convert a image node for the builder.
242 Different builder prefer different image formats, e.g. *latex* builder
245 This function handles output image formats in dependence of source the
[all …]
|
| /Documentation/arch/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 …]
|
12345678910>>...22