mirror of
https://github.com/torvalds/linux.git
synced 2026-04-18 06:44:00 -04:00
The AMD QSPI controller supports an advanced connection modes called Stacked mode which allow the controller to treat two different flashes as one storage. In Stacked connection mode flashes share the same SPI bus, but different CS line, controller driver asserts the CS of the flash to which it needs to communicate. Stacked mode is a software abstraction rather than a controller feature or capability. At any given time, the controller communicates with one of the two connected flash devices, as determined by the requested address and data length. If an operation starts on one flash and ends on the other, the mtd layer needs to split it into two separate operations and adjust the data length accordingly. For more information on the modes please feel free to go through the controller flash interface below [1]. To support stacked mode, the existing MTD concat driver has been extended to be more generic, enabling multiple sets of MTD partitions to be virtually concatenated, with each set forming a distinct logical MTD device. A new Device Tree property is introduced to facilitate this, containing phandles of the partitions to be concatenated with the one where the property is defined. This approach supports multiple sets of concatenated partitions. [1] https://docs.amd.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Device-Interface Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com> Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
204 lines
6.5 KiB
YAML
204 lines
6.5 KiB
YAML
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||
%YAML 1.2
|
||
---
|
||
$id: http://devicetree.org/schemas/mtd/partitions/partition.yaml#
|
||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||
|
||
title: Partition
|
||
|
||
description: |
|
||
This binding describes a single flash partition. Each partition must have its
|
||
relative offset and size specified. Depending on partition function extra
|
||
properties can be used.
|
||
|
||
A partition may be dynamically allocated by a specific parser at runtime.
|
||
In this specific case, a specific suffix is required to the node name.
|
||
Everything after 'partition-' will be used as the partition name to compare
|
||
with the one dynamically allocated by the specific parser.
|
||
If the partition contains invalid char a label can be provided that will
|
||
be used instead of the node name to make the comparison.
|
||
This is used to assign an OF node to the dynamiccally allocated partition
|
||
so that subsystem like NVMEM can provide an OF node and declare NVMEM cells.
|
||
The OF node will be assigned only if the partition label declared match the
|
||
one assigned by the parser at runtime.
|
||
|
||
maintainers:
|
||
- Rafał Miłecki <rafal@milecki.pl>
|
||
|
||
properties:
|
||
reg:
|
||
description: partition's offset and size within the flash
|
||
maxItems: 1
|
||
|
||
label:
|
||
description: The label / name for this partition. If omitted, the label
|
||
is taken from the node name (excluding the unit address).
|
||
|
||
read-only:
|
||
description: This parameter, if present, is a hint that this partition
|
||
should only be mounted read-only. This is usually used for flash
|
||
partitions containing early-boot firmware images or data which should
|
||
not be clobbered.
|
||
type: boolean
|
||
|
||
lock:
|
||
description: Do not unlock the partition at initialization time (not
|
||
supported on all devices)
|
||
type: boolean
|
||
|
||
slc-mode:
|
||
description: This parameter, if present, allows one to emulate SLC mode
|
||
on a partition attached to an MLC NAND thus making this partition
|
||
immune to paired-pages corruptions
|
||
type: boolean
|
||
|
||
linux,rootfs:
|
||
description: Marks partition that contains root filesystem to mount and boot
|
||
user space from
|
||
type: boolean
|
||
|
||
part-concat-next:
|
||
description: List of phandles to MTD partitions that need be concatenated
|
||
with the current partition.
|
||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||
minItems: 1
|
||
maxItems: 16
|
||
items:
|
||
maxItems: 1
|
||
|
||
align:
|
||
$ref: /schemas/types.yaml#/definitions/uint32
|
||
minimum: 2
|
||
maximum: 0x80000000
|
||
multipleOf: 2
|
||
description:
|
||
This sets the alignment of the entry in bytes.
|
||
|
||
The entry offset is adjusted so that the entry starts on an aligned
|
||
boundary within the containing section or image. For example ‘align =
|
||
<16>’ means that the entry will start on a 16-byte boundary. This may
|
||
mean that padding is added before the entry. The padding is part of
|
||
the containing section but is not included in the entry, meaning that
|
||
an empty space may be created before the entry starts. Alignment
|
||
must be a power of 2. If ‘align’ is not provided, no alignment is
|
||
performed.
|
||
|
||
align-size:
|
||
$ref: /schemas/types.yaml#/definitions/uint32
|
||
minimum: 2
|
||
maximum: 0x80000000
|
||
multipleOf: 2
|
||
description:
|
||
This sets the alignment of the entry size in bytes. It must be a power
|
||
of 2.
|
||
|
||
For example, to ensure that the size of an entry is a multiple of 64
|
||
bytes, set this to 64. While this does not affect the content of the
|
||
entry itself (the padding is performed only when its parent section is
|
||
assembled), the end result is that the entry ends with the padding
|
||
bytes, so may grow. If ‘align-size’ is not provided, no alignment is
|
||
performed.
|
||
|
||
align-end:
|
||
$ref: /schemas/types.yaml#/definitions/uint32
|
||
minimum: 2
|
||
maximum: 0x80000000
|
||
multipleOf: 2
|
||
description:
|
||
This sets the alignment (in bytes) of the end of an entry with respect
|
||
to the containing section. It must be a power of 2.
|
||
|
||
Some entries require that they end on an alignment boundary,
|
||
regardless of where they start. This does not move the start of the
|
||
entry, so the content of the entry will still start at the beginning.
|
||
But there may be padding at the end. While this does not affect the
|
||
content of the entry itself (the padding is performed only when its
|
||
parent section is assembled), the end result is that the entry ends
|
||
with the padding bytes, so may grow. If ‘align-end’ is not provided,
|
||
no alignment is performed.
|
||
|
||
compression:
|
||
$ref: /schemas/types.yaml#/definitions/string
|
||
description: |
|
||
Compression algorithm used to store the data in this partition, chosen
|
||
from a list of well-known algorithms.
|
||
|
||
The contents are compressed using this algorithm.
|
||
|
||
enum:
|
||
- none
|
||
- bzip2
|
||
- gzip
|
||
- lzop
|
||
- lz4
|
||
- lzma
|
||
- xz
|
||
- zstd
|
||
|
||
sercomm,scpart-id:
|
||
description: Partition id in Sercomm partition map. Mtd parser
|
||
uses this id to find a record in the partition map containing
|
||
offset and size of the current partition. The values from
|
||
partition map overrides partition offset and size defined in
|
||
reg property of the dts. Frequently these values are the same,
|
||
but may differ if device has bad eraseblocks on a flash.
|
||
$ref: /schemas/types.yaml#/definitions/uint32
|
||
|
||
nvmem-layout:
|
||
$ref: /schemas/nvmem/layouts/nvmem-layout.yaml
|
||
|
||
if:
|
||
not:
|
||
required: [ reg ]
|
||
then:
|
||
properties:
|
||
$nodename:
|
||
pattern: '^partitions?(-.+)?$'
|
||
|
||
# This is a generic file other binding inherit from and extend
|
||
additionalProperties: true
|
||
|
||
$defs:
|
||
partition-node:
|
||
type: object
|
||
if:
|
||
not:
|
||
required: [ compatible ]
|
||
then:
|
||
$ref: '#'
|
||
unevaluatedProperties: false
|
||
else:
|
||
$ref: '#'
|
||
|
||
examples:
|
||
- |
|
||
partitions {
|
||
compatible = "fixed-partitions";
|
||
#address-cells = <1>;
|
||
#size-cells = <1>;
|
||
|
||
partition@100000 {
|
||
compatible = "u-boot";
|
||
reg = <0x100000 0xf00000>;
|
||
align-size = <0x1000>;
|
||
align-end = <0x10000>;
|
||
};
|
||
|
||
partition@200000 {
|
||
compatible = "tfa-bl31";
|
||
reg = <0x200000 0x100000>;
|
||
align = <0x4000>;
|
||
};
|
||
|
||
part0: partition@400000 {
|
||
part-concat-next = <&part1>;
|
||
label = "part0_0";
|
||
reg = <0x400000 0x100000>;
|
||
};
|
||
|
||
part1: partition@800000 {
|
||
label = "part0_1";
|
||
reg = <0x800000 0x800000>;
|
||
};
|
||
};
|