linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
Cc: kdasu.kdev@gmail.com, linux-kernel@vger.kernel.org,
	linux-spi@vger.kernel.org
Subject: Re: [PATCH 4/5] spi: bcm-qspi: Make multiple data blocks interrupt-driven
Date: Mon, 15 Jun 2020 15:32:33 +0100	[thread overview]
Message-ID: <20200615143233.GW4447@sirena.org.uk> (raw)
In-Reply-To: <20200615040557.2011-5-mark.tomlinson@alliedtelesis.co.nz>

[-- Attachment #1: Type: text/plain, Size: 1916 bytes --]

On Mon, Jun 15, 2020 at 04:05:56PM +1200, Mark Tomlinson wrote:

> When needing to send/receive data in small chunks, make this interrupt
> driven rather than waiting for a completion event for each small section
> of data.

Again was this done for a reason and if so do we understand why doing
this from interrupt context is safe - how long can the interrupts be
when stuffing the FIFO from interrupt context?

> @@ -731,12 +733,14 @@ static inline u16 read_rxram_slot_u16(struct bcm_qspi *qspi, int slot)
>  		((bcm_qspi_read(qspi, MSPI, msb_offset) & 0xff) << 8);
>  }
>  
> -static void read_from_hw(struct bcm_qspi *qspi, int slots)
> +static void read_from_hw(struct bcm_qspi *qspi)
>  {

Things might be clearer if this refactoring were split out into a
separate patch.

> @@ -960,24 +966,21 @@ static int bcm_qspi_transfer_one(struct spi_master *master,
>  				 struct spi_transfer *trans)
>  {
>  	struct bcm_qspi *qspi = spi_master_get_devdata(master);
> -	int slots;
> -	unsigned long timeo = msecs_to_jiffies(100);
> +	unsigned long timeo = msecs_to_jiffies(1000);

That's a randomly chosen value - if we're now doing the entire transfer
then we should be trying to estimate the length of time the transfer
will take, for a very large transfer on a slow bus it's possible that
even a second won't be enough.

> -		complete(&qspi->mspi_done);
> +
> +		read_from_hw(qspi);
> +
> +		if (qspi->trans_pos.trans) {
> +			write_to_hw(qspi);
> +		} else {
> +			complete(&qspi->mspi_done);
> +			spi_finalize_current_transfer(qspi->master);
> +		}
> +

This is adding a spi_finalize_current_transfer() which we didn't have
before, and still leaving us doing cleanup work in the driver in another
thread.  This is confused, the driver should only need to finalize the
transfer explicitly if it returned a timeout from transfer_one() but
nothing's changed there.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-06-15 14:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-15  4:05 [PATCH 0/5] Improvements to spi-bcm-qspi Mark Tomlinson
2020-06-15  4:05 ` [PATCH 1/5] spi: bcm-qspi: Add support for setting BSPI clock Mark Tomlinson
2020-06-15  4:05 ` [PATCH 2/5] spi: bcm-qspi: Improve debug reading SPI data Mark Tomlinson
2020-06-15  4:05 ` [PATCH 3/5] spi: bcm-qspi: Do not split transfers into small chunks Mark Tomlinson
2020-06-15 13:31   ` Mark Brown
2020-06-15  4:05 ` [PATCH 4/5] spi: bcm-qspi: Make multiple data blocks interrupt-driven Mark Tomlinson
2020-06-15 14:32   ` Mark Brown [this message]
2020-06-16  3:07     ` Mark Tomlinson
2020-06-16  8:26       ` Mark Brown
2020-06-15  4:05 ` [PATCH 5/5] spi: bcm-qspi: Improve interrupt handling Mark Tomlinson
2020-06-15 19:05 ` [PATCH 0/5] Improvements to spi-bcm-qspi Kamal Dasu

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=20200615143233.GW4447@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=kdasu.kdev@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=mark.tomlinson@alliedtelesis.co.nz \
    /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).