[v2,00/10] spi: Extend the framework to generically support memory devices

Message ID 20180410224439.9260-1-boris.brezillon@bootlin.com
Headers show
Series
  • spi: Extend the framework to generically support memory devices
Related show

Message

Boris Brezillon April 10, 2018, 10:44 p.m.
Hello,

Shrinking a bit the explanation on why the spi-mem abstraction is
needed (a detailed explanation is available here [2]). In addition to
what as been said in my initial explanation I'll add that making it part
of the SPI framework instead of as an extra independent layer is
justified by the fact that some controllers support both SPI memory
operations and regular SPI transfers, and it's cleaner to have both
features exposed through a single driver.

In this v2, I think I addressed all the comments I had except the
advanced direct memory mapping stuff mentioned by Cyrille, but I don't
think any of the work done in this series prevents us from adding this
feature later on.

For those who want to have the full picture, here is a branch [1]
containing the SPI NAND framework based on top of this spi-mem layer.

Thanks,

Boris

[1]https://github.com/bbrezillon/linux/tree/spi-mem
[2]https://www.spinics.net/lists/linux-spi/msg12058.html

Boris Brezillon (10):
  spi: Check presence the of ->transfer[_xxx]() before registering a
    controller
  spi: Expose spi_{map,unmap}_buf() for internal use
  spi: Add an helper to flush the message queue
  spi: Extend the core to ease integration of SPI memory controllers
  spi: Make support for regular transfers optional when ->mem_ops !=
    NULL
  spi: bcm-qspi: Implement the spi_mem interface
  spi: bcm53xx: Implement the spi_mem interface
  spi: ti-qspi: Implement the spi_mem interface
  mtd: spi-nor: Use the spi_mem_xx() API
  spi: Get rid of the spi_flash_read() API

 drivers/mtd/devices/Kconfig  |   1 +
 drivers/mtd/devices/m25p80.c | 236 +++++++++----------------
 drivers/spi/Kconfig          |   7 +
 drivers/spi/Makefile         |   1 +
 drivers/spi/spi-bcm-qspi.c   | 162 ++++++++---------
 drivers/spi/spi-bcm2835.c    |   1 +
 drivers/spi/spi-bcm53xx.c    |  36 ++--
 drivers/spi/spi-mem.c        | 408 +++++++++++++++++++++++++++++++++++++++++++
 drivers/spi/spi-ti-qspi.c    |  85 +++++----
 drivers/spi/spi.c            | 142 +++++++--------
 include/linux/spi/spi-mem.h  | 249 ++++++++++++++++++++++++++
 include/linux/spi/spi.h      |  88 ++++------
 12 files changed, 1005 insertions(+), 411 deletions(-)
 create mode 100644 drivers/spi/spi-mem.c
 create mode 100644 include/linux/spi/spi-mem.h

Comments

Mark Brown April 17, 2018, 10:57 a.m. | #1
On Wed, Apr 11, 2018 at 12:44:29AM +0200, Boris Brezillon wrote:

> In this v2, I think I addressed all the comments I had except the
> advanced direct memory mapping stuff mentioned by Cyrille, but I don't
> think any of the work done in this series prevents us from adding this
> feature later on.

I'm pretty much OK with this, there's a few small bits to be addressed
it seems but it looks good overall.
Boris Brezillon April 18, 2018, 2:25 p.m. | #2
Hi Mark,

On Tue, 17 Apr 2018 11:57:13 +0100
Mark Brown <broonie@kernel.org> wrote:

> On Wed, Apr 11, 2018 at 12:44:29AM +0200, Boris Brezillon wrote:
> 
> > In this v2, I think I addressed all the comments I had except the
> > advanced direct memory mapping stuff mentioned by Cyrille, but I don't
> > think any of the work done in this series prevents us from adding this
> > feature later on.  
> 
> I'm pretty much OK with this, there's a few small bits to be addressed
> it seems but it looks good overall.

Okay, cool. I'll send a v3 addressing the few issues pointed by
reviewers.

Thanks,

Boris