>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. Regards, Parshuram Thombare
