From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
Cc: linux-mtd@lists.infradead.org, frieder.schrempf@exceet.de,
computersforpeace@gmail.com, david.wolfe@nxp.com, han.xu@nxp.com,
festevam@gmail.com, marek.vasut@gmail.com,
prabhakar.kushwaha@nxp.com, linux-spi@vger.kernel.org,
linux-kernel@vger.kernel.org,
Fabio Estevam <fabio.estevam@nxp.com>
Subject: Re: [PATCH] mtd: spi-nor: Support controllers with limited TX FIFO size
Date: Mon, 9 Jul 2018 23:34:27 +0200 [thread overview]
Message-ID: <20180709233427.1a714de7@bbrezillon> (raw)
In-Reply-To: <1528870092-14526-1-git-send-email-yogeshnarayan.gaur@nxp.com>
+Fabio
Hi Yogesh,
On Wed, 13 Jun 2018 11:38:12 +0530
Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote:
> Some SPI controllers can't write nor->page_size bytes in a single
> step because their TX FIFO is too small.
>
> Allow nor->write() to return a size that is smaller than the requested
> write size to gracefully handle this case.
There's been a discussion between Marek and I regarding this patch and
patch "mtd: devices: m25p80: Make sure WRITE_EN is issued before each
write". Marek would like to avoid letting drivers do non-aligned page
writes when the MTD user requested full page writes.
So, the question is, is the FSL QSPI engine capable of handling that
when the NOR page is being than the TX FIFO? According to the current
implementation it's not [1], but it looks like we have a way to
know when the TX FIFO is not full so we could potentially refill the
FIFO either from the CPU or using DMA if that's possible (not sure the
eDMA engine can fill the QSPI TX FIFO directly).
What I find worrisome with this solution is this particular statement
in the datasheet:
"
When the QuadSPI module tries to pull data out of an empty TX Buffer
the TX Buffer underrun is signaled by the QSPI_FR[TBUF] flag. The
current IP Command leading to the underrun condition is continued until
the specified number of bytes has been sent to the serial flash device,
in the underrun condition when QuadSPI module tries to pull out data of
empty TX buffer, the data transferred is undefined i.e. once the
underrun flag is set, it will return the garbage value until the
required number of bytes are not sent.
"
If we fail to fill the TX FIFO fast enough for any reasons (contention
on the APB/AHB/AXI bus in case of DMA, task being scheduled out in
case of PIO access), that means we transfer garbage to the NOR...
Clearly something we should avoid at any cost.
Yogesh, Fabio, Han, any comment on this?
Thanks,
Boris
[1]https://elixir.bootlin.com/linux/v4.18-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L1117
>
> Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
> ---
> drivers/mtd/spi-nor/spi-nor.c | 7 -------
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 5bfa36e..3e63543 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -1431,13 +1431,6 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len,
> goto write_err;
> *retlen += written;
> i += written;
> - if (written != page_remain) {
> - dev_err(nor->dev,
> - "While writing %zu bytes written %zd bytes\n",
> - page_remain, written);
> - ret = -EIO;
> - goto write_err;
> - }
> }
>
> write_err:
next prev parent reply other threads:[~2018-07-09 21:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-13 6:08 [PATCH] mtd: spi-nor: Support controllers with limited TX FIFO size Yogesh Gaur
2018-07-09 21:34 ` Boris Brezillon [this message]
2018-09-18 10:51 ` Frieder Schrempf
2018-09-18 14:41 ` Boris Brezillon
2018-10-03 7:10 ` 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=20180709233427.1a714de7@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=computersforpeace@gmail.com \
--cc=david.wolfe@nxp.com \
--cc=fabio.estevam@nxp.com \
--cc=festevam@gmail.com \
--cc=frieder.schrempf@exceet.de \
--cc=han.xu@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=marek.vasut@gmail.com \
--cc=prabhakar.kushwaha@nxp.com \
--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 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).