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 <ja...@amarulasolutions.com> wrote: > >> On Mon, Oct 8, 2018 at 11:32 AM Cédric Le Goater <c...@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 <c...@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. > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
