linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Suchanek <hramrach@gmail.com>
To: Vignesh R <vigneshr@ti.com>
Cc: Mark Brown <broonie@kernel.org>, Tony Lindgren <tony@atomide.com>,
	Russell King <linux@arm.linux.org.uk>,
	devicetree <devicetree@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-omap@vger.kernel.org,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	MTD Maling List <linux-mtd@lists.infradead.org>,
	linux-spi <linux-spi@vger.kernel.org>
Subject: Re: [PATCH v2 1/5] spi: introduce mmap read support for spi flash devices
Date: Tue, 3 Nov 2015 12:19:18 +0100	[thread overview]
Message-ID: <CAOMqctQ7uPXo5GzVK918DfvuaAPBvbooxW00jFP4ryyfcdLURA@mail.gmail.com> (raw)
In-Reply-To: <1446545174-14193-2-git-send-email-vigneshr@ti.com>

On 3 November 2015 at 11:06, Vignesh R <vigneshr@ti.com> wrote:
> In addition to providing direct access to SPI bus, some spi controller
> hardwares (like ti-qspi) provide special memory mapped port
> to accesses SPI flash devices in order to increase read performance.
> This means the controller can automatically send the SPI signals
> required to read data from the SPI flash device.
> For this, spi controller needs to know flash specific information like
> read command to use, dummy bytes and address width. Once these settings
> are populated in hardware registers, any read accesses to flash's memory
> map region(SoC specific) through memcpy (or mem-to mem DMA copy) will be
> handled by controller hardware. The hardware will automatically generate
> SPI signals required to read data from flash and present it to CPU/DMA.
>
> Introduce spi_mtd_mmap_read() interface to support memory mapped read
> over SPI flash devices. SPI master drivers can implement this callback to
> support memory mapped read interfaces. m25p80 flash driver and other
> flash drivers can call this to request memory mapped read. The interface
> should only be used MTD flashes and cannot be used with other SPI devices.
>
> Signed-off-by: Vignesh R <vigneshr@ti.com>
> ---
>  drivers/spi/spi.c       | 35 +++++++++++++++++++++++++++++++++++
>  include/linux/spi/spi.h | 23 +++++++++++++++++++++++
>  2 files changed, 58 insertions(+)
>
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index a5f53de813d3..5a5c7a7d47f2 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1059,6 +1059,7 @@ static void __spi_pump_messages(struct spi_master *master, bool in_kthread)
>                 }
>         }
>
> +       mutex_lock(&master->mmap_lock_mutex);
>         trace_spi_message_start(master->cur_msg);
>
>         if (master->prepare_message) {
> @@ -1068,6 +1069,7 @@ static void __spi_pump_messages(struct spi_master *master, bool in_kthread)
>                                 "failed to prepare message: %d\n", ret);
>                         master->cur_msg->status = ret;
>                         spi_finalize_current_message(master);
> +                       mutex_unlock(&master->mmap_lock_mutex);
>                         return;
>                 }
>                 master->cur_msg_prepared = true;
> @@ -1077,6 +1079,7 @@ static void __spi_pump_messages(struct spi_master *master, bool in_kthread)
>         if (ret) {
>                 master->cur_msg->status = ret;
>                 spi_finalize_current_message(master);
> +               mutex_unlock(&master->mmap_lock_mutex);
>                 return;
>         }
>
> @@ -1084,8 +1087,10 @@ static void __spi_pump_messages(struct spi_master *master, bool in_kthread)
>         if (ret) {
>                 dev_err(&master->dev,
>                         "failed to transfer one message from queue\n");
> +               mutex_unlock(&master->mmap_lock_mutex);
>                 return;
>         }
> +       mutex_unlock(&master->mmap_lock_mutex);
>  }
>
>  /**
> @@ -1732,6 +1737,7 @@ int spi_register_master(struct spi_master *master)
>         spin_lock_init(&master->queue_lock);
>         spin_lock_init(&master->bus_lock_spinlock);
>         mutex_init(&master->bus_lock_mutex);
> +       mutex_init(&master->mmap_lock_mutex);
>         master->bus_lock_flag = 0;
>         init_completion(&master->xfer_completion);
>         if (!master->max_dma_len)
> @@ -2237,6 +2243,35 @@ int spi_async_locked(struct spi_device *spi, struct spi_message *message)
>  EXPORT_SYMBOL_GPL(spi_async_locked);
>
>
> +int spi_mtd_mmap_read(struct spi_device *spi, loff_t from, size_t len,
> +                     size_t *retlen, u_char *buf, u8 read_opcode,
> +                     u8 addr_width, u8 dummy_bytes)
> +
> +{
> +       struct spi_master *master = spi->master;
> +       int ret;
> +
> +       if (master->auto_runtime_pm) {
> +               ret = pm_runtime_get_sync(master->dev.parent);
> +               if (ret < 0) {
> +                       dev_err(&master->dev, "Failed to power device: %d\n",
> +                               ret);
> +                       goto err;
> +               }
> +       }
> +       mutex_lock(&master->mmap_lock_mutex);
> +       ret = master->spi_mtd_mmap_read(spi, from, len, retlen, buf,
> +                                       read_opcode, addr_width,
> +                                       dummy_bytes);
> +       mutex_unlock(&master->mmap_lock_mutex);
> +       if (master->auto_runtime_pm)
> +               pm_runtime_put(master->dev.parent);
> +
> +err:
> +       return ret;
> +}
> +EXPORT_SYMBOL_GPL(spi_mtd_mmap_read);
> +
>  /*-------------------------------------------------------------------------*/
>
>  /* Utility methods for SPI master protocol drivers, layered on
> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> index 6b00f18f5e6b..0a6d8ad57357 100644
> --- a/include/linux/spi/spi.h
> +++ b/include/linux/spi/spi.h
> @@ -297,6 +297,7 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv)
>   * @flags: other constraints relevant to this driver
>   * @bus_lock_spinlock: spinlock for SPI bus locking
>   * @bus_lock_mutex: mutex for SPI bus locking
> + * @mmap_lock_mutex: mutex for locking SPI bus when mmap transfer is on.

Any reason to not use the bus_lock_mutex here? The bus is busy as much
during mmap transfer as it is during any other transfer.

Thanks

Michal

  reply	other threads:[~2015-11-03 11:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-03 10:06 [PATCH v2 0/5] Add memory mapped read support for ti-qspi Vignesh R
2015-11-03 10:06 ` [PATCH v2 1/5] spi: introduce mmap read support for spi flash devices Vignesh R
2015-11-03 11:19   ` Michal Suchanek [this message]
2015-11-04  4:48     ` Vignesh R
2015-11-04 14:39   ` Mark Brown
2015-11-05 12:29     ` Vignesh R
2015-11-05 15:29       ` Mark Brown
2015-11-03 10:06 ` [PATCH v2 2/5] spi: spi-ti-qspi: add mmap mode read support Vignesh R
2015-11-04 14:41   ` Mark Brown
2015-11-05  6:16     ` Vignesh R
2015-11-03 10:06 ` [PATCH v2 3/5] mtd: devices: m25p80: add support for mmap read request Vignesh R
2015-11-03 10:06 ` [PATCH v2 4/5] ARM: dts: DRA7: add entry for qspi mmap region Vignesh R
2015-11-05 16:36   ` Rob Herring
2015-11-03 10:06 ` [PATCH v2 5/5] ARM: dts: AM4372: " Vignesh R
2015-11-05 23:51   ` Rob Herring
2015-11-06  5:14     ` Felipe Balbi
2015-11-06 12:21       ` Vignesh R

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOMqctQ7uPXo5GzVK918DfvuaAPBvbooxW00jFP4ryyfcdLURA@mail.gmail.com \
    --to=hramrach@gmail.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=tony@atomide.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).