RE: [PATCH v3 2/2] spi: cadence: add support for Cadence XSPI controller

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux