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.
