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].
Introduce new DT property to specify which partitions are concatenated to
each other.
flash@0 {
reg = <0>;
partitions {
compatible = "fixed-partitions";
part-concat = <&flash0_part1>, <&flash1_part0>;
flash0_part0: part0@0 {
label = "part0_0";
reg = <0x0 0x800000>;
};
flash0_part1: part1@800000 {
label = "part0_1";
reg = <0x800000 0x800000>;
};
};
};
flash@1 {
reg = <1>;
partitions {
compatible = "fixed-partitions";
flash1_part0: part1@0 {
label = "part1_0";
reg = <0x0 0x800000>;
};
flash1_part1: part1@800000 {
label = "part1_1";
reg = <0x800000 0x800000>;
};
};
};
The partitions that gets created are
part0_0
part1_1
part0_1-part1_0-concat
[1] https://docs.amd.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Device-Interface
Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
---
.../bindings/mtd/partitions/partition.yaml | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
index 80d0452a2a33..f77fef368211 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
@@ -57,6 +57,12 @@ properties:
user space from
type: boolean
+ part-concat:
+ description: List of MTD partitions phandles that should be concatenated.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 2
+ maxItems: 16
+
align:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 2
@@ -125,6 +131,7 @@ examples:
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
+ part-concat = <&part0>, <&part1>;
partition@100000 {
compatible = "u-boot";
@@ -138,4 +145,14 @@ examples:
reg = <0x200000 0x100000>;
align = <0x4000>;
};
+
+ part0: partition@400000 {
+ label = "part0_0";
+ reg = <0x400000 0x100000>;
+ };
+
+ part1: partition@800000 {
+ label = "part0_1";
+ reg = <0x800000 0x800000>;
+ };
};
--
2.34.1On Wed, Feb 05, 2025 at 07:07:28PM +0530, Amit Kumar Mahapatra wrote:
> 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].
>
> Introduce new DT property to specify which partitions are concatenated to
> each other.
>
> flash@0 {
> reg = <0>;
> partitions {
> compatible = "fixed-partitions";
> part-concat = <&flash0_part1>, <&flash1_part0>;
>
> flash0_part0: part0@0 {
> label = "part0_0";
> reg = <0x0 0x800000>;
> };
>
> flash0_part1: part1@800000 {
> label = "part0_1";
> reg = <0x800000 0x800000>;
> };
> };
> };
>
> flash@1 {
> reg = <1>;
> partitions {
> compatible = "fixed-partitions";
>
> flash1_part0: part1@0 {
> label = "part1_0";
> reg = <0x0 0x800000>;
> };
>
> flash1_part1: part1@800000 {
> label = "part1_1";
> reg = <0x800000 0x800000>;
> };
> };
> };
>
> The partitions that gets created are
> part0_0
> part1_1
> part0_1-part1_0-concat
'part-concat' doesn't work if you have multiple sets of partitions you
want to concatenate.
I think you need something like 'prev-partition' or 'next-partition' in
the partition nodes to create a linked list of partitions. Hopefully,
you don't need both properties, but you do have to scan everything to
figure out which ones are concatenated or not. For example, no property
can mean not concatenated or last partition if you use 'next-partition'.
Rob
Hi, >> The partitions that gets created are >> part0_0 >> part1_1 >> part0_1-part1_0-concat > > 'part-concat' doesn't work if you have multiple sets of partitions you > want to concatenate. > > I think you need something like 'prev-partition' or 'next-partition' in > the partition nodes to create a linked list of partitions. Hopefully, > you don't need both properties, but you do have to scan everything to > figure out which ones are concatenated or not. For example, no property > can mean not concatenated or last partition if you use 'next-partition'. Out of curiosity, would the chosen node be eligible as a central place where to look at? Thanks, Miquèl
On Wed, Feb 12, 2025 at 09:25:53AM +0100, Miquel Raynal wrote: > Hi, > > >> The partitions that gets created are > >> part0_0 > >> part1_1 > >> part0_1-part1_0-concat > > > > 'part-concat' doesn't work if you have multiple sets of partitions you > > want to concatenate. > > > > I think you need something like 'prev-partition' or 'next-partition' in > > the partition nodes to create a linked list of partitions. Hopefully, > > you don't need both properties, but you do have to scan everything to > > figure out which ones are concatenated or not. For example, no property > > can mean not concatenated or last partition if you use 'next-partition'. > > Out of curiosity, would the chosen node be eligible as a central place > where to look at? Why would you need that? Rob
On 12/02/2025 at 10:06:59 -06, Rob Herring <robh@kernel.org> wrote: > On Wed, Feb 12, 2025 at 09:25:53AM +0100, Miquel Raynal wrote: >> Hi, >> >> >> The partitions that gets created are >> >> part0_0 >> >> part1_1 >> >> part0_1-part1_0-concat >> > >> > 'part-concat' doesn't work if you have multiple sets of partitions you >> > want to concatenate. >> > >> > I think you need something like 'prev-partition' or 'next-partition' in >> > the partition nodes to create a linked list of partitions. Hopefully, >> > you don't need both properties, but you do have to scan everything to >> > figure out which ones are concatenated or not. For example, no property >> > can mean not concatenated or last partition if you use 'next-partition'. >> >> Out of curiosity, would the chosen node be eligible as a central place >> where to look at? > > Why would you need that? I'm talking about storing in a central place all the concatenated partitions. Your proposal with "next-partition" works fine if we locate it inside the 'partitions' node, but I feel like the 'part-concat' instead was not fitting very well there. So I was wondering in this case if moving the concatenation of the partitions would be eligible to the chosen node, or if that's reserved to *very* few properties (and should remain like that). Thanks, Miquèl
On Wed, Feb 12, 2025 at 05:18:39PM +0100, Miquel Raynal wrote: > On 12/02/2025 at 10:06:59 -06, Rob Herring <robh@kernel.org> wrote: > > > On Wed, Feb 12, 2025 at 09:25:53AM +0100, Miquel Raynal wrote: > >> Hi, > >> > >> >> The partitions that gets created are > >> >> part0_0 > >> >> part1_1 > >> >> part0_1-part1_0-concat > >> > > >> > 'part-concat' doesn't work if you have multiple sets of partitions you > >> > want to concatenate. > >> > > >> > I think you need something like 'prev-partition' or 'next-partition' in > >> > the partition nodes to create a linked list of partitions. Hopefully, > >> > you don't need both properties, but you do have to scan everything to > >> > figure out which ones are concatenated or not. For example, no property > >> > can mean not concatenated or last partition if you use 'next-partition'. > >> > >> Out of curiosity, would the chosen node be eligible as a central place > >> where to look at? > > > > Why would you need that? > > I'm talking about storing in a central place all the concatenated > partitions. Your proposal with "next-partition" works fine if we locate > it inside the 'partitions' node, but I feel like the 'part-concat' > instead was not fitting very well there. So I was wondering in this case > if moving the concatenation of the partitions would be eligible to the > chosen node, or if that's reserved to *very* few properties (and should > remain like that). You would have to solve the same problem as this patchset which is how to support N sets of concatenated partitions. In general though, we add new things to /chosen very carefully. It's usually "things the bootloader configured/enabled" which I don't think this qualifies as. Rob
Hi Rob, >> I'm talking about storing in a central place all the concatenated >> partitions. Your proposal with "next-partition" works fine if we locate >> it inside the 'partitions' node, but I feel like the 'part-concat' >> instead was not fitting very well there. So I was wondering in this case >> if moving the concatenation of the partitions would be eligible to the >> chosen node, or if that's reserved to *very* few properties (and should >> remain like that). > > You would have to solve the same problem as this patchset which is how > to support N sets of concatenated partitions. > > In general though, we add new things to /chosen very carefully. It's > usually "things the bootloader configured/enabled" which I don't think > this qualifies as. Interesting, I didn't have this "things the bootloader did" explicit case in mind. Thanks! Miquèl
© 2016 - 2025 Red Hat, Inc.