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.
Same for the u-boot aspeed spi driver which needs a spi-mem refresh if I understand correctly.
Thanks,
C.
Yes, but for newly added drivers. added spi-mem guys, may be they can comment.
Jagan, what's the plan for the spi-nor layer in u-boot? I mean, spi-mem is just the controller side of things, but it requires spi-mem drivers to support specific SPI memories. We added the spi-nand driver, but AFAICT, the spi-nor driver does not exist yet. There's the spi-flash layer already, but IIUC you were trying to replace it by a spi-nor framework.
I see 2 options here:
1/ copy the spi-nor framework from linux and adjust it to make it work in uboot 2/ create a spi-nor driver which interfaces directly with the spi-mem layer
I know I usually recommend going for #1, but it might be a bit different this time around since I'm trying to get rid of the spi_nor interface in Linux (the one that allows people to implement spi-nor controller drivers) in favor of a native spi-mem driver. So I think it's worth considering option #2.