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

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Pratyush,

p.yadav@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)
- 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).

> 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.

> 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).

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/