Searched +full:fixed +full:- +full:layout (Results 1 – 25 of 58) sorted by relevance
123
| /Documentation/devicetree/bindings/nvmem/layouts/ |
| D | fixed-layout.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/nvmem/layouts/fixed-layout.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
7 title: NVMEM layout for fixed NVMEM cells
10 Many NVMEM devices have hardcoded cells layout (offset and size of defined
13 This binding allows defining such NVMEM layout with its cells. It can be used
17 - Rafał Miłecki <rafal@milecki.pl>
21 const: fixed-layout
23 "#address-cells":
[all …]
|
| D | nvmem-layout.yaml | 1 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/nvmem/layouts/nvmem-layout.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
11 - Michael Walle <michael@walle.cc>
12 - Miquel Raynal <miquel.raynal@bootlin.com>
18 perform their parsing. The nvmem-layout container is here to describe these.
21 - $ref: fixed-layout.yaml
22 - $ref: kontron,sl28-vpd.yaml
[all …]
|
| D | u-boot,env.yaml | 1 # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
3 ---
4 $id: http://devicetree.org/schemas/nvmem/layouts/u-boot,env.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
7 title: U-Boot environment variables layout
10 U-Boot uses environment variables to store device parameters and
14 Data is stored using U-Boot specific formats (variant specific header and NUL
15 separated key-value pairs).
27 - Rafał Miłecki <rafal@milecki.pl>
32 - description: A standalone env data block
[all …]
|
| /Documentation/devicetree/bindings/nvmem/ |
| D | nvmem-deprecated-cells.yaml | 1 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/nvmem/nvmem-deprecated-cells.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
7 title: NVMEM old syntax for fixed cells
10 - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
13 Before introducing NVMEM layouts all NVMEM (fixed) cells were defined
14 as direct device subnodes. That syntax was replaced by "fixed-layout"
18 "@[0-9a-f]+(,[0-7])?$":
21 - $ref: layouts/fixed-cell.yaml
[all …]
|
| D | xlnx,zynqmp-nvmem.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/nvmem/xlnx,zynqmp-nvmem.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
14 - Kalyani Akula <kalyani.akula@amd.com>
15 - Praveen Teja Kundanala <praveen.teja.kundanala@amd.com>
18 - $ref: nvmem.yaml#
22 const: xlnx,zynqmp-nvmem-fw
25 - compatible
30 - |
[all …]
|
| D | nvmem.yaml | 1 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
3 ---
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
23 "#address-cells":
26 "#size-cells":
29 read-only:
34 wp-gpios:
36 GPIO to which the write-protect pin of the chip is connected.
37 The write-protect GPIO is asserted, when it's driven high
[all …]
|
| /Documentation/devicetree/bindings/mtd/partitions/ |
| D | linux,ubi.yaml | 1 # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
3 ---
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
12 physical flash device and spreads the I/O load (i.e wear-leveling)
16 - Daniel Golle <daniel@makrotopia.org>
19 - $ref: partition.yaml#
30 "^ubi-volume-.*$":
31 $ref: /schemas/mtd/partitions/ubi-volume.yaml#
36 - compatible
41 - |
[all …]
|
| D | brcm,bcm963xx-cfe-nor-partitions.txt | 4 Most Broadcom BCM63XX SoC based devices follow the Broadcom reference layout for
6 NVRAM partition, and the remainder in-between for one to two firmware partitions
7 at fixed offsets. A valid firmware partition is identified by the ImageTag
12 - compatible : must be "brcm,bcm963xx-cfe-nor-partitions"
17 compatible = "cfi-flash";
19 bank-width = <2>;
22 compatible = "brcm,bcm963xx-cfe-nor-partitions";
|
| D | brcm,bcm963xx-imagetag.txt | 5 partitions or non standard bootloader partition sizes. For these a mixed layout
12 - compatible : must be "brcm,bcm963xx-imagetag"
17 compatible = "cfi-flash";
19 bank-width = <2>;
22 compatible = "fixed-partitions";
23 #address-cells = <1>;
24 #size-cells = <1>;
28 read-only;
33 compatible = "brcm,bcm963xx-imagetag";
38 read-only;
|
| /Documentation/arch/arm64/ |
| D | memory.rst | 2 Memory Layout on AArch64 Linux
7 This document describes the virtual memory layout used by the AArch64
12 with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit
14 64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB)
15 virtual address, are used but the memory layout is the same.
23 contains only user (non-global) mappings. The swapper_pg_dir address is
27 AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit)::
30 -----------------------------------------------------------------------
36 fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
44 AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support)::
[all …]
|
| D | kdump.rst | 9 reserved memory is needed to pre-load the kdump kernel and boot such
24 - crashkernel=size@offset
25 - crashkernel=size
26 - crashkernel=size,high crashkernel=size,low
32 limit, usually decided by the accessible address bits of the DMA-capable
35 not fixed: it is 1G on the RPi4 platform but 4G on most other systems.
44 --------------------------
46 The crashkernel memory must be reserved at the user-specified region or
51 -------------------
66 reservations. The user would not need to know the system memory layout
[all …]
|
| /Documentation/arch/arm/ |
| D | memory.rst | 2 Kernel Memory Layout on ARM Linux
9 This document describes the virtual memory layout which the Linux
39 in proc-xscale.S to flush the whole data
53 ff800000 ffbfffff Permanent, fixed read-only mapping of the
59 VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space.
68 PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region.
72 PKMAP_BASE PAGE_OFFSET-1 Permanent kernel mappings
76 MODULES_VADDR MODULES_END-1 Kernel module space
80 TASK_SIZE MODULES_VADDR-1 KASAn shadow memory when KASan is in use.
85 00001000 TASK_SIZE-1 User space mappings
[all …]
|
| /Documentation/driver-api/ |
| D | ioctl.rst | 18 the ioctl system call. While this can be any 32-bit number that uniquely
22 ``include/uapi/asm-generic/ioctl.h`` provides four macros for defining
36 An 8-bit number, often a character literal, specific to a subsystem
37 or driver, and listed in Documentation/userspace-api/ioctl/ioctl-number.rst
40 An 8-bit number identifying the specific command, unique for a give
45 encodes the ``sizeof(data_type)`` value in a 13-bit or 14-bit integer,
74 handler returns either -ENOTTY or -ENOIOCTLCMD, which also results in
75 -ENOTTY being returned from the system call. Some subsystems return
76 -ENOSYS or -EINVAL here for historic reasons, but this is wrong.
79 -ENOIOCTLCMD in order to use the fallback conversion into native
[all …]
|
| /Documentation/networking/ |
| D | xsk-tx-metadata.rst | 1 .. SPDX-License-Identifier: GPL-2.0
8 via :doc:`af_xdp`. Refer to :doc:`xdp-rx-metadata` on how to access similar
17 The metadata layout is a fixed UAPI, refer to ``union xsk_tx_metadata`` in
26 ``xdp_desc->addr`` in the umem frame. Within a frame, the metadata
27 layout is as follows::
31 +-----------------+---------+----------------------------+
33 +-----------------+---------+----------------------------+
36 xdp_desc->addr
40 use ``xdp_desc->addr - tx_metadata_len`` to locate
47 - ``XDP_TXMD_FLAGS_TIMESTAMP``: requests the device to put transmission
[all …]
|
| D | xdp-rx-metadata.rst | 1 .. SPDX-License-Identifier: GPL-2.0
22 .. kernel-doc:: net/core/xdp.c
25 .. kernel-doc:: net/core/xdp.c
28 .. kernel-doc:: net/core/xdp.c
35 metadata available in which case the driver returns ``-ENODATA``.
38 implemented, the default ones that return ``-EOPNOTSUPP`` will be used
42 Within an XDP frame, the metadata layout (accessed via ``xdp_buff``) is
45 +----------+-----------------+------+
47 +----------+-----------------+------+
50 xdp_buff->data_meta xdp_buff->data
[all …]
|
| /Documentation/filesystems/ext4/ |
| D | blockgroup.rst | 1 .. SPDX-License-Identifier: GPL-2.0
3 Layout chapter
4 ------
6 The layout of a standard block group is approximately as follows (each
9 .. list-table::
11 :header-rows: 1
13 * - Group 0 Padding
14 - ext4 Super Block
15 - Group Descriptors
16 - Reserved GDT Blocks
[all …]
|
| /Documentation/arch/powerpc/ |
| D | kaslr-booke32.rst | 1 .. SPDX-License-Identifier: GPL-2.0
7 The word KASLR stands for Kernel Address Space Layout Randomization.
14 map or copy kernel to a proper place and relocate. Freescale Book-E
15 parts expect lowmem to be mapped by fixed TLB entries(TLB1). The TLB1
22 pass entropy via the /chosen/kaslr-seed node in device tree.
31 |--> 64M <--|
33 +---------------+ +----------------+---------------+
35 +---------------+ +----------------+---------------+
37 |-----> offset <-----|
|
| /Documentation/devicetree/bindings/firmware/xilinx/ |
| D | xlnx,zynqmp-firmware.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/firmware/xilinx/xlnx,zynqmp-firmware.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Nava kishore Manne <nava.kishore.manne@amd.com>
12 description: The zynqmp-firmware node describes the interface to platform
23 - description: For implementations complying for Zynq Ultrascale+ MPSoC.
24 const: xlnx,zynqmp-firmware
26 - description: For implementations complying for Versal.
27 const: xlnx,versal-firmware
[all …]
|
| /Documentation/devicetree/bindings/pci/ |
| D | host-generic-pci.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/pci/host-generic-pci.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Will Deacon <will@kernel.org>
13 Firmware-initialised PCI host controllers and PCI emulations, such as the
14 virtio-pci implementations found in kvmtool and other para-virtualised
18 presenting a set of fixed windows describing a subset of IO, Memory and
21 Configuration Space is assumed to be memory-mapped (as opposed to being
26 For CAM, this 24-bit offset is:
[all …]
|
| /Documentation/admin-guide/device-mapper/ |
| D | switch.rst | 2 dm-switch
5 The device-mapper switch target creates a device that supports an
6 arbitrary mapping of fixed-size regions of I/O across a fixed set of
11 number of fixed-sized address regions but there is no simple pattern
13 dm-stripe.
16 ----------
29 forwarding is invisible to the initiator. The storage layout is also
42 A device-mapper table already lets you map different regions of a
48 Using this device-mapper switch target we can now build a two-layer
51 Upper Tier - Determine which array member the I/O should be sent to.
[all …]
|
| /Documentation/fb/ |
| D | api.rst | 9 ---------------
12 with frame buffer devices. In-kernel APIs between device drivers and the frame
22 ---------------
24 Device and driver capabilities are reported in the fixed screen information
36 - FB_CAP_FOURCC
40 specifying color components layout.
44 --------------------
46 Pixels are stored in memory in hardware-dependent formats. Applications need
58 - FB_TYPE_PACKED_PIXELS
64 Padding at end of lines may be present and is then reported through the fixed
[all …]
|
| /Documentation/devicetree/bindings/mtd/ |
| D | qcom,nandc.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
15 - qcom,ipq806x-nand
16 - qcom,ipq4019-nand
17 - qcom,ipq6018-nand
18 - qcom,ipq8074-nand
19 - qcom,sdx55-nand
26 - description: Core Clock
[all …]
|
| /Documentation/filesystems/ |
| D | erofs.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 EROFS - Enhanced Read-Only File System
10 EROFS filesystem stands for Enhanced Read-Only File System. It aims to form a
11 generic read-only filesystem solution for various read-only use cases instead
17 random-access friendly high-performance filesystem to get rid of unneeded I/O
18 amplification and memory-resident overhead compared to similar approaches.
22 - read-only storage media or
24 - part of a fully trusted read-only solution, which means it needs to be
25 immutable and bit-for-bit identical to the official golden image for
28 - hope to minimize extra storage space with guaranteed end-to-end performance
[all …]
|
| /Documentation/admin-guide/ |
| D | sysfs-rules.rst | 4 The kernel-exported sysfs exports internal kernel implementation details
5 and depends on internal kernel structures and layout. It is agreed upon
11 low-level userspace applications, with a new kernel release, the users
12 of sysfs must follow some rules to use an as-abstract-as-possible way to
21 - Do not use libsysfs
23 offer any abstraction, it exposes all the kernel driver-core
31 - sysfs is always at ``/sys``
38 - devices are only "devices"
39 There is no such thing like class-, bus-, physical devices,
41 just simply a "device". Class-, bus-, physical, ... types are just
[all …]
|
| /Documentation/userspace-api/media/drivers/ |
| D | dw100.rst | 1 .. SPDX-License-Identifier: GPL-2.0
15 <--------------------------------------->
17 ^ .-------.-------.-------.-------.-------.
21 a | .-------.-------.-------.-------.-------.
25 h | .-------.-------.-------.-------.-------.
29 h | .-------.-------.-------.-------.-------.
33 v '-------'-------'-------'-------'-------'
39 an unsigned 12.4 fixed point format (UQ12.4).
42 .----------------------.--------..----------------------.--------.
45 '----------------------'--------''----------------------'--------'
[all …]
|
123