+Vignesh
Hi Cédric,
On Fri, 25 Jan 2019 18:28:02 +0100 Cédric Le Goater clg@kaod.org wrote:
Hello
On 10/10/18 2:02 PM, Cédric Le Goater wrote:
Hello Boris,
On 10/10/18 9:32 AM, Boris Brezillon wrote:
Hi Cédric,
On Wed, 10 Oct 2018 11:46:56 +0530 Jagan Teki jagan@amarulasolutions.com wrote:
On Mon, Oct 8, 2018 at 11:32 AM Cédric Le Goater clg@kaod.org wrote:
On 10/4/18 5:57 PM, Jagan Teki wrote:
On Fri, Sep 28, 2018 at 5:20 PM Cédric Le Goater clg@kaod.org wrote: > > Hello Simon, > > > The Aspeed AST2500 FMC controller can handle SPI flash and NOR flash memory, > and the Aspeed AST2500 SPI Flash Controllers only SPI. If there is some > misunderstanding on this driver, it might come from the fact it is closer > to a SPI-NOR driver like we have in Linux, than a generic SPI driver. > The stm32 SPI driver is somewhat similar. > > Should we move it under drivers/mtd/spi/ maybe ?
Seems with new spi-mem in Linux flash memory driver rely on spi-mem instead of mtd/spi-nor. So I think you can handle this via new spi-mem. have you send any patches to Linux?
No, not yet. The patchset is sent :
https://patchwork.ozlabs.org/cover/933293/is not using spimem. I was not aware of that change in the spi-nor layer at the time. I will take a look.
Indeed, if you have some time to convert the Linux aspeed driver to the spi-mem interface that would be appreciated.
Yes. That's the plan. I have a series on the way but I will see if I can rework a v2 to use spi-mem.
I took a look at spi-mem and worked on an initial spi-aspeed-smc driver using the new framework in Linux 5.0.x. It looks good but I have a couple of questions.
Great!
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.
I think the U-Boot and Linux driver will be very similar wrt the issues above ?
I hope so.
Thanks for working on this conversion.
Boris