[PATCH v5 1/3] dt-bindings: mtd: spi-nor: Allow two CS per device

[Miquel Raynal]

Hi Pratyush,

p.yadav at ti.com 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 at bootlin.com>
> > Acked-by: Rob Herring <robh at kernel.org>
> > ---
> >  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