Hi Pratyush, p.yadav@xxxxxx wrote on Wed, 22 Dec 2021 00:17:27 +0530: > On 21/12/21 06:00PM, Miquel Raynal wrote: > > The Xilinx QSPI controller has two advanced modes which allow the > > controller to behave differently and consider two flashes as one single > > storage. > > > > One of these two modes is quite complex to support from a binding point > > of view and is the dual parallel memories. In this mode, each byte of > > data is stored in both devices: the even bits in one, the odd bits in > > the other. The split is automatically handled by the QSPI controller and > > is transparent for the user. > > > > The other mode is simpler to support, it is called dual stacked > > memories. The controller shares the same SPI bus but each of the devices > > contain half of the data. Once in this mode, the controller does not > > follow CS requests but instead internally wires the two CS levels with > > the value of the most significant address bit. > > > > Supporting these two modes will involve core changes which include the > > possibility of providing two CS for a single SPI device > > > > Signed-off-by: Miquel Raynal <miquel.raynal@xxxxxxxxxxx> > > Acked-by: Rob Herring <robh@xxxxxxxxxx> > > --- > > Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > > index 39421f7233e4..4abfb4cfc157 100644 > > --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > > +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > > @@ -47,7 +47,8 @@ properties: > > identified by the JEDEC READ ID opcode (0x9F). > > > > reg: > > - maxItems: 1 > > + minItems: 1 > > + maxItems: 2 > > You allow up to 4 items in stacked-memories but only allow up to 2 CS, > which would make the other 2 memories unusable. Should also change this > to 4. Yes, I allowed "more" theoretical devices in the stacked/parallel-memories properties because there is no real limitation on this side so I didn't want to constrain it too much, while still keeping a maximum value, hence 4 seemed a nice guess for a "maximum but can be bigger value we don't really care it's just for bounding". However on the SPI side this is a big change with deep consequences and I don't want to rush things so it is on purpose that I kept the limitation to 2. But we can change the maxItems to 2 everywhere if this appears to be the thing to do. Thanks, Miquèl
