[RFC PATCH 1/3] spi: dt-bindings: Allow describing flashes with two CS

[Miquel Raynal]

Hi Rob,

robh+dt at kernel.org wrote on Fri, 12 Nov 2021 10:52:44 -0600:

> On Fri, Nov 12, 2021 at 9:24 AM Miquel Raynal <miquel.raynal at bootlin.com> 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 CSlevels 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>
> > ---
> >  .../bindings/spi/spi-controller.yaml          |  6 ++---  
> 
> Needs to go to dt list...
> 
> >  scripts/dtc/checks.c                          | 24 ++++++++++++-------  
> 
> We don't take changes to dtc in the kernel. It must go to upstream
> first and then we sync it.
> 
> >  2 files changed, 18 insertions(+), 12 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml
> > index 8246891602e7..51877b637bfe 100644
> > --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml
> > +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml
> > @@ -20,7 +20,7 @@ properties:
> >      pattern: "^spi(@.*|-[0-9a-f])*$"
> >
> >    "#address-cells":
> > -    enum: [0, 1]
> > +    enum: [0, 1, 2]  
> 
> A single 'device' with 2 chip-selects would be 2 'reg' entries, not 2
> address cells. 2 address cells would be a chip-select plus some other
> data needed to access the device. Sounds like your case is the former.

Oh yeah I got confused while playing with the different tools, indeed
this change should not be needed, it's the number of 'reg' entries that
we should extend, not its internal size.

Thanks,
Miquèl