[U-Boot] [PATCH 2/3] spi: Add support for the Aspeed ast2500 SPI controllers

[Boris Brezillon <boris.brezillon@bootlin.com>]

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, 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.