[RFC PATCH 0/3] Dual stacked/parallel memories bindings

[Pratyush Yadav]

On 16/11/21 09:19AM, Miquel Raynal wrote:
> Hi Pratyush,
> 
> p.yadav at ti.com wrote on Mon, 15 Nov 2021 15:53:10 +0530:
> 
> > On 12/11/21 04:24PM, Miquel Raynal wrote:
> > > Hello Rob, Mark, Tudor & Pratyush,
> > > 
> > > Here is an RFC to open the discussion about the sensitive task of
> > > supporting specific SPI controller modes like Xilinx's where the
> > > controller can highly abstract the hardware and provide access to a
> > > single bigger device instead. I'll let you go through the series and
> > > tell me what you think.
> > > 
> > > I think there are two possible approaches:
> > > 1- Describe the two devices as being a single one which is what we will
> > >    get from the controller anyway (implies supporting two CS per SPI
> > >    device)
> > > or
> > > 2- Describe the two devices in the device tree and then by software hack
> > >    into the MTD core to simulate a single device to talk to.  
> > 
> > Approach 1 makes more sense to me since once we implement it you can 
> > also use such multi-CS flashes with "dumber" controllers as well like 
> > spi-cadence-quadspi. There, the driver would have to manually set the 
> > chip select instead of it being done automatically by looking at the top 
> > bit. This would at least work for the dual-stacked memories.
> 
> I believe it would. But in that case we should think about a more
> generic binding for the stacked mode. So far I've proposed:
> - xlnx,dual-stacked-memories
> - xlnx,dual-parallel-memories
> 
> It actually looks like the former might be a generic binding. What do
> you think is best between:
> - 'dual-stacked-memories'
> - 'stacked-memories' ('dual' is encoded in the reg property)

I think this works best. This would also allow "triple" and "quad" 
stacked flashes.

> - no specific property, it's just a memory with two CS, again 'reg'
>   gives us the information.
> 
> Then we could keep only the latter property, which looks more specific
> to Xilinx and use it as a flash node property instead (as advised
> by Mark).

Even if the parallel mode is only implemented by the Xilinx controller, 
we would need to support it in the core, right? So we need to figure out 
how that case would work as well.

> 
> > How I envision this being implemented is that SPI NOR would be aware of 
> > the number of Chip Selects and when to use which one, and it would 
> > specify the CS value in the SPI MEM op.
> 
> Yes, this is the approach I had in mind to. This fits both the purpose
> of SPI-NOR and SPI-NAND which will both need to be updated as well tu
> support multi-CS.
> 
> > The controller driver can then 
> > execute this op as needed. One point to note here is that the entire 
> > memory won't be read in a single transaction. There would be 2 
> > transactions: one with CS=0 and one with CS=1. Is this fine for you? Do 
> > you have something else in mind?
> 
> I believe this should be let to the controller's discretion and appear
> like a single op in the upper layers.

But then how do you tell the controller when to change the CS if all it 
sees is a single large transaction that spans across multiple flashes? 
You mention in patch 1 that your controller automatically switches CS 
based on most significant address bit, but that would only work if you 
have two 2 GiB flashes wired in. In case someone uses two 1 GiB flashes, 
the MSB always remains 0. And what about controllers that can't switch 
the CS automatically?

> 
> > I am not sure how this model would work for a dual-parallel memory 
> > though.
> 
> If the controller is aware of the two CS and knows about the full
> request we can hope that integration won't be difficult (last famous
> words).

For your specific controller this might work but if we want this feature 
implemented generically I think it would need some more thought.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.