Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1218760 > unrolled thread
| Started by | Vignesh R <vigneshr@ti.com> |
|---|---|
| First post | 2015-09-04 10:40 +0200 |
| Last post | 2015-09-04 13:30 +0200 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[PATCH 1/5] spi: introduce mmap read support for spi flash devices Vignesh R <vigneshr@ti.com> - 2015-09-04 10:40 +0200
Re: [PATCH 1/5] spi: introduce mmap read support for spi flash devices Jagan Teki <jteki@openedev.com> - 2015-09-04 13:30 +0200
| From | Vignesh R <vigneshr@ti.com> |
|---|---|
| Date | 2015-09-04 10:40 +0200 |
| Subject | [PATCH 1/5] spi: introduce mmap read support for spi flash devices |
| Message-ID | <q4UHn-5cD-1@gated-at.bofh.it> |
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 or
DMA engine.
Introduce spi_mtd_mmap_read() method to support memory mapped read
over SPI flash devices. SPI master drivers can implement this method 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>
---
include/linux/spi/spi.h | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index d673072346f2..b74a3f169fc2 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -293,6 +293,23 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv)
* @handle_err: the subsystem calls the driver to handle an error that occurs
* in the generic implementation of transfer_one_message().
* @unprepare_message: undo any work done by prepare_message().
+ * @spi_mtd_mmap_read: some spi-controller hardwares provide memory
+ * mapped interface to communicate with mtd flashes.
+ * For this, spi controller needs to know flash
+ * memory settings 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(as defined
+ * by SoC) 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 or DMA. SPI master drivers can use this
+ * callback to implement memory mapped read
+ * interface. Flash driver (like m25p80) requests
+ * memory mapped read via this method. The interface
+ * should only be used mtd flashes and cannot be
+ * used with other spi devices.
* @cs_gpios: Array of GPIOs to use as chip select lines; one per CS
* number. Any individual value may be -ENOENT for CS lines that
* are not GPIOs (driven by the SPI controller itself).
@@ -438,6 +455,10 @@ struct spi_master {
struct spi_message *message);
int (*unprepare_message)(struct spi_master *master,
struct spi_message *message);
+ 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);
/*
* These hooks are for drivers that use a generic implementation
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Jagan Teki <jteki@openedev.com> |
|---|---|
| Date | 2015-09-04 13:30 +0200 |
| Message-ID | <q4XlU-D8-7@gated-at.bofh.it> |
| In reply to | #1218760 |
On 4 September 2015 at 13:59, 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 or
> DMA engine.
>
> Introduce spi_mtd_mmap_read() method to support memory mapped read
> over SPI flash devices. SPI master drivers can implement this method 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>
> ---
> include/linux/spi/spi.h | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> index d673072346f2..b74a3f169fc2 100644
> --- a/include/linux/spi/spi.h
> +++ b/include/linux/spi/spi.h
> @@ -293,6 +293,23 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv)
> * @handle_err: the subsystem calls the driver to handle an error that occurs
> * in the generic implementation of transfer_one_message().
> * @unprepare_message: undo any work done by prepare_message().
> + * @spi_mtd_mmap_read: some spi-controller hardwares provide memory
> + * mapped interface to communicate with mtd flashes.
> + * For this, spi controller needs to know flash
> + * memory settings 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(as defined
> + * by SoC) 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 or DMA. SPI master drivers can use this
> + * callback to implement memory mapped read
> + * interface. Flash driver (like m25p80) requests
> + * memory mapped read via this method. The interface
> + * should only be used mtd flashes and cannot be
> + * used with other spi devices.
> * @cs_gpios: Array of GPIOs to use as chip select lines; one per CS
> * number. Any individual value may be -ENOENT for CS lines that
> * are not GPIOs (driven by the SPI controller itself).
> @@ -438,6 +455,10 @@ struct spi_master {
> struct spi_message *message);
> int (*unprepare_message)(struct spi_master *master,
> struct spi_message *message);
> + 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);
This looks un-manageable to know spi core or master knows what are the
command or opcode used by spi-nor flash and also I think mmap support
seems to be flash related or any justification this is spi bus
master/controller feature?
thanks!
--
Jagan | openedev.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web