[U-Boot] [RFC PATCH 10/20] spi: Extend the core to ease integration of SPI memory controllers

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Jagan,

Jagan Teki <jagannadh.teki@gmail.com> wrote on Wed, 11 Jul 2018
20:07:19 +0530:

> On Wed, Jul 11, 2018 at 7:25 PM, Miquel Raynal
> <miquel.raynal@bootlin.com> wrote:
> > Hi Jagan,
> >
> > Jagan Teki <jagannadh.teki@gmail.com> wrote on Fri, 6 Jul 2018 17:02:22
> > +0530:
> >  
> >> On Wed, Jun 6, 2018 at 9:00 PM, Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> >> > From: Boris Brezillon <boris.brezillon@bootlin.com>
> >> >
> >> > Some controllers are exposing high-level interfaces to access various
> >> > kind of SPI memories. Unfortunately they do not fit in the current
> >> > spi_controller model and usually have drivers placed in
> >> > drivers/mtd/spi-nor which are only supporting SPI NORs and not SPI
> >> > memories in general.
> >> >
> >> > This is an attempt at defining a SPI memory interface which works for
> >> > all kinds of SPI memories (NORs, NANDs, SRAMs).
> >> >
> >> > Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
> >> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> >> > ---
> >> >  drivers/spi/Kconfig   |   7 +
> >> >  drivers/spi/Makefile  |   1 +
> >> >  drivers/spi/spi-mem.c | 500 ++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >  include/spi-mem.h     | 258 ++++++++++++++++++++++++++
> >> >  include/spi.h         |  11 ++
> >> >  5 files changed, 777 insertions(+)
> >> >  create mode 100644 drivers/spi/spi-mem.c
> >> >  create mode 100644 include/spi-mem.h
> >> >
> >> > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> >> > index 235a8c7d73..0ee371b2d9 100644
> >> > --- a/drivers/spi/Kconfig
> >> > +++ b/drivers/spi/Kconfig
> >> > @@ -15,6 +15,13 @@ config DM_SPI
> >> >
> >> >  if DM_SPI
> >> >
> >> > +config SPI_MEM
> >> > +       bool "SPI memory extension"
> >> > +       help
> >> > +         Enable this option if you want to enable the SPI memory extension.
> >> > +         This extension is meant to simplify interaction with SPI memories
> >> > +         by providing an high-level interface to send memory-like commands.
> >> > +
> >> >  config ALTERA_SPI
> >> >         bool "Altera SPI driver"
> >> >         help
> >> > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> >> > index 4b6000fd9a..982529a0e6 100644
> >> > --- a/drivers/spi/Makefile
> >> > +++ b/drivers/spi/Makefile
> >> > @@ -10,6 +10,7 @@ ifdef CONFIG_DM_SPI
> >> >  obj-y += spi-uclass.o
> >> >  obj-$(CONFIG_SANDBOX) += spi-emul-uclass.o
> >> >  obj-$(CONFIG_SOFT_SPI) += soft_spi.o
> >> > +obj-$(CONFIG_SPI_MEM) += spi-mem.o
> >> >  else
> >> >  obj-y += spi.o
> >> >  obj-$(CONFIG_SOFT_SPI) += soft_spi_legacy.o
> >> > diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> >> > new file mode 100644
> >> > index 0000000000..1aabe56819
> >> > --- /dev/null
> >> > +++ b/drivers/spi/spi-mem.c
> >> > @@ -0,0 +1,500 @@
> >> > +// SPDX-License-Identifier: GPL-2.0+
> >> > +/*
> >> > + * Copyright (C) 2018 Exceet Electronics GmbH
> >> > + * Copyright (C) 2018 Bootlin
> >> > + *
> >> > + * Author: Boris Brezillon <boris.brezillon@bootlin.com>
> >> > + */
> >> > +
> >> > +#ifndef __UBOOT__
> >> > +#include <linux/dmaengine.h>
> >> > +#include <linux/pm_runtime.h>
> >> > +#include "internals.h"
> >> > +#else
> >> > +#include <spi.h>
> >> > +#include <spi-mem.h>
> >> > +#endif
> >> > +
> >> > +#ifndef __UBOOT__  
> >>
> >> I would like remove Linux stuff atleast on this file becuase it's
> >> difficult for me to read or review the code and also driver/spi have
> >> fully u-boot dm stuff. I know it's easy for Linux sync but for this we
> >> can do manual sync what ever need. I'm on something what from Linux.  
> >
> > I'm not sure this is a wise idea.
> >
> > And I don't understand how "driver/spi have fully u-boot dm stuff" is
> > related in any manner to this request.  
> 
> The code in driver/spi is more or less u-boot code it doesn't have
> Linux sync. ie reason I want to maintain the similar integrity here,
> but on the other-side spi-mem depend more on Linux like MTD. OK let's
> move as-it-is like what you added, may be we can simulate if require
> in future need.

I understand better your POV, OK then, let met re-add these portions.

Thanks,
Miquèl