mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Clark <james.clark@linaro.org>
To: Mark Brown <broonie@kernel.org>, Frank Li <Frank.li@nxp.com>
Cc: Vladimir Oltean <olteanv@gmail.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Larisa Grigore <larisa.grigore@nxp.com>,
	Christoph Hellwig <hch@lst.de>,
	linux-spi@vger.kernel.org, imx@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 6/6] spi: spi-fsl-dspi: Report FIFO overflows as errors
Date: Mon, 30 Jun 2025 11:46:40 +0100	[thread overview]
Message-ID: <f4616741-9763-4221-b385-74c6d332b092@linaro.org> (raw)
In-Reply-To: <22d69113-fec0-4405-872d-af76bd038c09@sirena.org.uk>



On 27/06/2025 10:41 pm, Mark Brown wrote:
> On Fri, Jun 27, 2025 at 03:56:43PM -0400, Frank Li wrote:
>> On Fri, Jun 27, 2025 at 11:21:42AM +0100, James Clark wrote:
> 
>>> In target mode, the host sending more data than can be consumed would be
>>> a common problem for any message exceeding the FIFO or DMA buffer size.
>>> Cancel the whole message as soon as this condition is hit as the message
>>> will be corrupted.
> 
>>> Only do this for target mode in a DMA transfer, it's not likely these
>>> flags will be set in host mode
> 
>> "not likely", I think SPI controller should stop CLK if FIFO empty and full.
>> It should be "never" happen.
> 
>> Only check FIFO error flags at target mode because it never happen at host mode.
> 
>> You can remove below whole paragram.
> 
> I agree it *should* never happen in host mode but it can be good
> practice to look in case something gets messed up.  That said extra
> device accesses in the hot path are probably going to be noticable so
> likely not worth it, but in the dspi_poll() case:
> 

Yeah the point was to be defensive. Even though it shouldn't happen I 
don't see an issue with checking error flags.

We could add a condition to only do it in target mode, but it doesn't 
make the code more readable, and it wouldn't be any faster than just 
checking the flags. So I'm not sure what problem we're trying to solve 
by removing it.

>> @@ -1067,6 +1080,9 @@ static void dspi_poll(struct fsl_dspi *dspi)
>>                          regmap_read(dspi->regmap, SPI_SR, &spi_sr);
>>                          regmap_write(dspi->regmap, SPI_SR, spi_sr);
>>
>> +                       dspi->cur_msg->status = dspi_fifo_error(dspi, spi_sr);
>> +                       if (dspi->cur_msg->status)
>> +                               return;
> 
> we're reading the register anyway so the overhead is much lower.

In both poll and interrupt mode we're already reading it. Only DMA mode 
didn't have a read and I didn't add a check for error flags there anyway.


  reply	other threads:[~2025-06-30 10:46 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-27 10:21 [PATCH v4 0/6] spi: spi-fsl-dspi: Target mode improvements James Clark
2025-06-27 10:21 ` [PATCH v4 1/6] spi: spi-fsl-dspi: Clear completion counter before initiating transfer James Clark
2025-06-27 19:41   ` Frank Li
2025-06-27 10:21 ` [PATCH v4 2/6] spi: spi-fsl-dspi: Store status directly in cur_msg->status James Clark
2025-06-27 21:30   ` Vladimir Oltean
2025-06-30 12:54     ` James Clark
2025-06-30 20:41       ` Vladimir Oltean
2025-07-01 10:02         ` James Clark
2025-07-21 13:25     ` James Clark
2025-07-21 13:39       ` Vladimir Oltean
2025-07-21 14:02         ` James Clark
2025-07-21 14:04           ` Mark Brown
2025-06-27 10:21 ` [PATCH v4 3/6] spi: spi-fsl-dspi: Stub out DMA functions James Clark
2025-06-27 10:21 ` [PATCH v4 4/6] spi: spi-fsl-dspi: Use non-coherent memory for DMA James Clark
2025-06-27 19:38   ` Frank Li
2025-06-27 10:21 ` [PATCH v4 5/6] spi: spi-fsl-dspi: Increase DMA buffer size James Clark
2025-06-27 19:44   ` Frank Li
2025-06-30  8:59     ` James Clark
2025-07-01 14:47   ` Vladimir Oltean
2025-07-01 15:08     ` James Clark
2025-07-01 15:09     ` Arnd Bergmann
2025-06-27 10:21 ` [PATCH v4 6/6] spi: spi-fsl-dspi: Report FIFO overflows as errors James Clark
2025-06-27 19:56   ` Frank Li
2025-06-27 21:41     ` Mark Brown
2025-06-30 10:46       ` James Clark [this message]
2025-06-30 11:40 ` (subset) [PATCH v4 0/6] spi: spi-fsl-dspi: Target mode improvements Mark Brown
2025-06-30 15:26 ` Vladimir Oltean
2025-07-01 12:42   ` James Clark
2025-07-01 13:18     ` Mark Brown
2025-07-01 13:57     ` Vladimir Oltean
2025-07-01 14:36       ` Mark Brown
2025-07-01 14:53         ` Vladimir Oltean
2025-07-01 15:16           ` Mark Brown
2025-07-01 15:24             ` Vladimir Oltean
2025-07-01 15:30               ` Mark Brown

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=f4616741-9763-4221-b385-74c6d332b092@linaro.org \
    --to=james.clark@linaro.org \
    --cc=Frank.li@nxp.com \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=hch@lst.de \
    --cc=imx@lists.linux.dev \
    --cc=larisa.grigore@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=vladimir.oltean@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

all inboxes | Powered by JetHome®