From: Vignesh R <vigneshr@ti.com>
To: Boris Brezillon <boris.brezillon@bootlin.com>,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
Marek Vasut <marek.vasut@gmail.com>,
Richard Weinberger <richard@nod.at>,
Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
<linux-mtd@lists.infradead.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Mark Brown <broonie@kernel.org>, <linux-spi@vger.kernel.org>
Cc: "Peter Pan" <peterpansjtu@gmail.com>,
"Frieder Schrempf" <frieder.schrempf@exceet.de>,
"Yogesh Gaur" <yogeshnarayan.gaur@nxp.com>,
"Rafał Miłecki" <rafal@milecki.pl>,
"Kamal Dasu" <kdasu.kdev@gmail.com>,
"Maxime Chevallier" <maxime.chevallier@bootlin.com>
Subject: Re: [PATCH v2 04/10] spi: Extend the core to ease integration of SPI memory controllers
Date: Thu, 12 Apr 2018 20:08:28 +0530 [thread overview]
Message-ID: <60f3d53a-9668-9e1c-9f29-45aaf4004630@ti.com> (raw)
In-Reply-To: <20180410224439.9260-5-boris.brezillon@bootlin.com>
Hi,
- Sourav Poddar <sourav.poddar@ti.com> mail ID no longer valid.
On Wednesday 11 April 2018 04:14 AM, Boris Brezillon wrote:
> 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>
> ---
[...]
> +/**
> + * struct spi_mem_op - describes a SPI memory operation
> + * @cmd.buswidth: number of IO lines used to transmit the command
> + * @cmd.opcode: operation opcode
> + * @addr.nbytes: number of address bytes to send. Can be zero if the operation
> + * does not need to send an address
> + * @addr.buswidth: number of IO lines used to transmit the address cycles
> + * @addr.val: address value. This value is always sent MSB first on the bus.
> + * Note that only @addr.nbytes are taken into account in this
> + * address value, so users should make sure the value fits in the
> + * assigned number of bytes.
> + * @dummy.nbytes: number of dummy bytes to send after an opcode or address. Can
> + * be zero if the operation does not require dummy bytes
> + * @dummy.buswidth: number of IO lanes used to transmit the dummy bytes
> + * @data.buswidth: number of IO lanes used to send/receive the data
> + * @data.dir: direction of the transfer
> + * @data.buf.in: input buffer
> + * @data.buf.out: output buffer
> + */
> +struct spi_mem_op {
> + struct {
> + u8 buswidth;
> + u8 opcode;
> + } cmd;
> +
> + struct {
> + u8 nbytes;
> + u8 buswidth;
> + u64 val;
You could consider using loff_t here and be consistent with
spi_nor_read/write() API as well as mtd->_read().
> + } addr;
> +
> + struct {
> + u8 nbytes;
> + u8 buswidth;
> + } dummy;
> +
> + struct {
> + u8 buswidth;
> + enum spi_mem_data_dir dir;
> + unsigned int nbytes;
> + /* buf.{in,out} must be DMA-able. */
> + union {
> + void *in;
> + const void *out;
> + } buf;
> + } data;
> +};
> +
Some flash devices support Dual/Quad DDR (Double Data Rate) mode and the
SPI controller driver would need to know this information. We will need
to add a field for that.
Currently, there are drivers under mtd/spi-nor/ that need to know
page/sector/total size of flash memory(info available in
-`struct spi_nor). We would need a way to provide this info to spi_mem
drivers, if we ever plan to move drivers under mtd/spi-nor to spi/
[...]
--
Regards
Vignesh
WARNING: multiple messages have this Message-ID (diff)
From: Vignesh R <vigneshr@ti.com>
To: Boris Brezillon <boris.brezillon@bootlin.com>,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
Marek Vasut <marek.vasut@gmail.com>,
Richard Weinberger <richard@nod.at>,
Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
<linux-mtd@lists.infradead.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Mark Brown <broonie@kernel.org>, <linux-spi@vger.kernel.org>
Cc: "Yogesh Gaur" <yogeshnarayan.gaur@nxp.com>,
"Kamal Dasu" <kdasu.kdev@gmail.com>,
"Maxime Chevallier" <maxime.chevallier@bootlin.com>,
"Peter Pan" <peterpansjtu@gmail.com>,
"Frieder Schrempf" <frieder.schrempf@exceet.de>,
"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH v2 04/10] spi: Extend the core to ease integration of SPI memory controllers
Date: Thu, 12 Apr 2018 20:08:28 +0530 [thread overview]
Message-ID: <60f3d53a-9668-9e1c-9f29-45aaf4004630@ti.com> (raw)
In-Reply-To: <20180410224439.9260-5-boris.brezillon@bootlin.com>
Hi,
- Sourav Poddar <sourav.poddar@ti.com> mail ID no longer valid.
On Wednesday 11 April 2018 04:14 AM, Boris Brezillon wrote:
> 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>
> ---
[...]
> +/**
> + * struct spi_mem_op - describes a SPI memory operation
> + * @cmd.buswidth: number of IO lines used to transmit the command
> + * @cmd.opcode: operation opcode
> + * @addr.nbytes: number of address bytes to send. Can be zero if the operation
> + * does not need to send an address
> + * @addr.buswidth: number of IO lines used to transmit the address cycles
> + * @addr.val: address value. This value is always sent MSB first on the bus.
> + * Note that only @addr.nbytes are taken into account in this
> + * address value, so users should make sure the value fits in the
> + * assigned number of bytes.
> + * @dummy.nbytes: number of dummy bytes to send after an opcode or address. Can
> + * be zero if the operation does not require dummy bytes
> + * @dummy.buswidth: number of IO lanes used to transmit the dummy bytes
> + * @data.buswidth: number of IO lanes used to send/receive the data
> + * @data.dir: direction of the transfer
> + * @data.buf.in: input buffer
> + * @data.buf.out: output buffer
> + */
> +struct spi_mem_op {
> + struct {
> + u8 buswidth;
> + u8 opcode;
> + } cmd;
> +
> + struct {
> + u8 nbytes;
> + u8 buswidth;
> + u64 val;
You could consider using loff_t here and be consistent with
spi_nor_read/write() API as well as mtd->_read().
> + } addr;
> +
> + struct {
> + u8 nbytes;
> + u8 buswidth;
> + } dummy;
> +
> + struct {
> + u8 buswidth;
> + enum spi_mem_data_dir dir;
> + unsigned int nbytes;
> + /* buf.{in,out} must be DMA-able. */
> + union {
> + void *in;
> + const void *out;
> + } buf;
> + } data;
> +};
> +
Some flash devices support Dual/Quad DDR (Double Data Rate) mode and the
SPI controller driver would need to know this information. We will need
to add a field for that.
Currently, there are drivers under mtd/spi-nor/ that need to know
page/sector/total size of flash memory(info available in
-`struct spi_nor). We would need a way to provide this info to spi_mem
drivers, if we ever plan to move drivers under mtd/spi-nor to spi/
[...]
--
Regards
Vignesh
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2018-04-12 14:38 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-10 22:44 [PATCH v2 00/10] spi: Extend the framework to generically support memory devices Boris Brezillon
2018-04-10 22:44 ` Boris Brezillon
2018-04-10 22:44 ` [PATCH v2 01/10] spi: Check presence the of ->transfer[_xxx]() before registering a controller Boris Brezillon
2018-04-10 22:44 ` Boris Brezillon
2018-04-16 12:13 ` Applied "spi: Check presence the of ->transfer[_xxx]() before registering a controller" to the spi tree Mark Brown
2018-04-16 12:13 ` Mark Brown
2018-04-26 12:14 ` Boris Brezillon
2018-04-26 12:14 ` Boris Brezillon
2018-04-26 12:37 ` Mark Brown
2018-04-26 12:37 ` Mark Brown
2018-04-26 12:54 ` Mark Brown
2018-04-26 12:54 ` Mark Brown
2018-04-10 22:44 ` [PATCH v2 02/10] spi: Expose spi_{map,unmap}_buf() for internal use Boris Brezillon
2018-04-10 22:44 ` Boris Brezillon
2018-04-16 12:11 ` Mark Brown
2018-04-16 12:11 ` Mark Brown
2018-04-18 14:20 ` Boris Brezillon
2018-04-18 14:20 ` Boris Brezillon
2018-04-10 22:44 ` [PATCH v2 03/10] spi: Add an helper to flush the message queue Boris Brezillon
2018-04-10 22:44 ` Boris Brezillon
2018-04-10 22:44 ` [PATCH v2 04/10] spi: Extend the core to ease integration of SPI memory controllers Boris Brezillon
2018-04-10 22:44 ` Boris Brezillon
2018-04-12 14:38 ` Vignesh R [this message]
2018-04-12 14:38 ` Vignesh R
2018-04-12 15:10 ` Boris Brezillon
2018-04-12 15:10 ` Boris Brezillon
2018-04-12 19:59 ` Boris Brezillon
2018-04-12 19:59 ` Boris Brezillon
2018-04-17 4:12 ` Vignesh R
2018-04-17 4:12 ` Vignesh R
2018-04-18 14:17 ` Boris Brezillon
2018-04-18 14:17 ` Boris Brezillon
2018-04-16 10:33 ` Frieder Schrempf
2018-04-16 10:33 ` Frieder Schrempf
2018-04-18 14:23 ` Boris Brezillon
2018-04-18 14:23 ` Boris Brezillon
2018-04-10 22:44 ` [PATCH v2 05/10] spi: Make support for regular transfers optional when ->mem_ops != NULL Boris Brezillon
2018-04-10 22:44 ` Boris Brezillon
2018-04-10 22:44 ` [PATCH v2 06/10] spi: bcm-qspi: Implement the spi_mem interface Boris Brezillon
2018-04-10 22:44 ` Boris Brezillon
2018-05-11 2:56 ` Applied "spi: bcm-qspi: Implement the spi_mem interface" to the spi tree Mark Brown
2018-05-11 2:56 ` Mark Brown
2018-04-10 22:44 ` [PATCH v2 07/10] spi: bcm53xx: Implement the spi_mem interface Boris Brezillon
2018-04-10 22:44 ` Boris Brezillon
2018-04-12 13:09 ` Boris Brezillon
2018-04-12 13:09 ` Boris Brezillon
2018-05-07 9:35 ` Rafał Miłecki
2018-05-07 9:35 ` Rafał Miłecki
2018-04-10 22:44 ` [PATCH v2 08/10] spi: ti-qspi: " Boris Brezillon
2018-04-10 22:44 ` Boris Brezillon
2018-04-10 22:44 ` [PATCH v2 09/10] mtd: spi-nor: Use the spi_mem_xx() API Boris Brezillon
2018-04-10 22:44 ` Boris Brezillon
2018-05-11 2:55 ` Applied "mtd: spi-nor: Use the spi_mem_xx() API" to the spi tree Mark Brown
2018-05-11 2:55 ` Mark Brown
2018-04-10 22:44 ` [PATCH v2 10/10] spi: Get rid of the spi_flash_read() API Boris Brezillon
2018-04-10 22:44 ` Boris Brezillon
2018-04-17 10:57 ` [PATCH v2 00/10] spi: Extend the framework to generically support memory devices Mark Brown
2018-04-17 10:57 ` Mark Brown
2018-04-18 14:25 ` Boris Brezillon
2018-04-18 14:25 ` Boris Brezillon
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=60f3d53a-9668-9e1c-9f29-45aaf4004630@ti.com \
--to=vigneshr@ti.com \
--cc=boris.brezillon@bootlin.com \
--cc=broonie@kernel.org \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@wedev4u.fr \
--cc=dwmw2@infradead.org \
--cc=frieder.schrempf@exceet.de \
--cc=kdasu.kdev@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=marek.vasut@gmail.com \
--cc=maxime.chevallier@bootlin.com \
--cc=miquel.raynal@bootlin.com \
--cc=peterpansjtu@gmail.com \
--cc=rafal@milecki.pl \
--cc=richard@nod.at \
--cc=yogeshnarayan.gaur@nxp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.