Hi Cédric,
On 25/01/19 11:30 PM, Boris Brezillon wrote:
+Vignesh
[...]
The first is about performing direct accesses on the AHB window on which the flash contents is mapped.
We have introduced the dirmap API/interface exactly for this purpose, and the SPI NOR layer will use it in 5.1 (see [1]).
How do you distinguish a flash read (fast, dual, etc) from a RDSFPD command for instance ?
Why do you need to know the access type?
Are the drivers expected to check the SPI OP command and depending on the target/command redirect to the appropriate address space ?
Definitely not, the SPI MEM layer is supposed to be memory-type agnostic, so you should not guess the operation type based on the opcode. For direct mapping accesses, just implement the ->dirmap_xxx hooks at the controller level and you'll be able to use the feature.>>
Also, Aspeed SPI controllers have a Read Timing Compensation Register which defines different data input delay cycles depending on SPI clock rates. This register is supposed to be tuned when the flash chip characteristics are known, after the first bus scan. Is there a way to know that our SPI slave is alive and well detected before starting hammering successive reads on it to see how it behaves.
Vignesh mentioned that a while back (couldn't find the thread where this discussion happened) and I suggested adding a new hook to do this "link training" process where you'd pass a spi_mem_op template + the expected result so that the controller can test different setups until it finds a working one.
Right, Cadence QSPI/OSPI needs PHY DLL values to be tuned for operating at higher frequencies. So idea is to use READID to read flash ID at lowest speed and use that as golden reference for tuning/link training at higher frequencies. I am guessing Aspeed SPI controller has similar need. Here is the discussion that Boris was talking about: https://lkml.org/lkml/2018/10/4/468
I haven't been able to get to implement his suggestions yet, but I think idea is generic enough.
I think the U-Boot and Linux driver will be very similar wrt the issues above ?
I have submitted patches[1] to sync SPI NOR framework from kernel to U-Boot. Once that's merged then Aspeed SPI can make use of spi-mem interface in U-Boot as well.
[1] https://patchwork.ozlabs.org/cover/1017335/