Messages in this thread | | | Date | Wed, 8 Sep 2021 16:51:15 +0530 | From | Pratyush Yadav <> | Subject | Re: [PATCH v3 2/2] spi: cadence: add support for Cadence XSPI controller |
| |
On 08/09/21 07:27AM, Parshuram Raju Thombare wrote: > >Depends on SPI_MEM as well. > > Ok > > >I commented on this last time around as well. This does not look right > >at all. A SPI MEM based driver should *not* need to know anything about > >the subsystem driving it. That is the entire point of the API. > > > >The controller seems to be able to extract the read and write opcodes > >from the SFDP on its own since you don't pass in that information to > >cdns_xspi_nor_read(). It looks like it is tied very heavily to a NOR > >flash, and I am not sure if it can really be used with a NAND flash, or > >something else entirely. > > > >Which makes me wonder how we should handle controllers like these. I > >don't think they fit in very well with the SPI MEM model, since they > >can't execute arbitrary SPI MEM commands very well. At the same time we > >are trying to get rid of mtd/spi-nor/controllers. Dunno... > > > >Mark, Tudor, Vignesh, any ideas? > > Ok, then for now I will drop ACMD PIO mode and use only STIG mode. > In STIG mode driver configures bus width and clock edge mode for > command, address and data for each operation.
But it would reduce performance by a lot, no? I think we should try to figure out how we can accomodate controllers like this before resorting to using the slower modes.
-- Regards, Pratyush Yadav Texas Instruments Inc.
| |