linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Lamparter <chunkeey@web.de>
To: Max Filippov <jcmvbkbc@gmail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] p54spi: get rid of busy-wait loops
Date: Mon, 6 Apr 2009 00:30:25 +0200	[thread overview]
Message-ID: <200904060030.25425.chunkeey@web.de> (raw)
In-Reply-To: <1238965389-5706-1-git-send-email-jcmvbkbc@gmail.com>

On Sunday 05 April 2009 23:03:09 Max Filippov wrote:
> p54spi_wakeup and p54spi_tx_frame used busy-waiting loop
> to poll for 'ready' bits in SPI_ADRS_HOST_INTERRUPTS register.
> With this change in place 'WR_READY timeout' messages do not
> show anymore.
> 
> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
> ---
looks good to me.
Acked-by: Christian Lamparter <chunkeey@web.de>

> I wish I knew for sure why. My guess is that busy-waiting
> somehow interferes with SPI transfer scheduling.
> 
>  drivers/net/wireless/p54/p54spi.c |   41 ++++++++++++------------------------
>  1 files changed, 14 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
> index 2903672..e4e708e 100644
> --- a/drivers/net/wireless/p54/p54spi.c
> +++ b/drivers/net/wireless/p54/p54spi.c
> @@ -153,14 +153,13 @@ static const struct p54spi_spi_reg p54spi_registers_array[] =
>  static int p54spi_wait_bit(struct p54s_priv *priv, u16 reg, __le32 bits)
>  {
>  	int i;
> -	__le32 buffer;
>  
>  	for (i = 0; i < 2000; i++) {
> -		p54spi_spi_read(priv, reg, &buffer, sizeof(buffer));
> +		__le32 buffer = p54spi_read32(priv, reg);
>  		if ((buffer & bits) == bits)
>  			return 1;
>  
> -		msleep(1);
> +		msleep(0);
I never liked msleep in workqueues. So instead of msleep(0),
what about replacing it with udelay or remove it entirely?

OR: maybe you can get the chip to generate IRQs when its ready,
so we don't have to poll it at all?

>  	}
>  	return 0;
>  }
> @@ -171,10 +170,10 @@ static int p54spi_spi_write_dma(struct p54s_priv *priv, __le32 base,
>  	p54spi_write16(priv, SPI_ADRS_DMA_WRITE_CTRL,
>  		       cpu_to_le16(SPI_DMA_WRITE_CTRL_ENABLE));
>  
> -	if (p54spi_wait_bit(priv, SPI_ADRS_DMA_WRITE_CTRL,
> -			    cpu_to_le32(HOST_ALLOWED)) == 0) {
> +	if (!p54spi_wait_bit(priv, SPI_ADRS_DMA_WRITE_CTRL,
> +			     cpu_to_le32(HOST_ALLOWED))) {
>  		dev_err(&priv->spi->dev, "spi_write_dma not allowed "
> -			"to DMA write.");
> +			"to DMA write.\n");
>  		return -EAGAIN;
>  	}
>  
> @@ -316,21 +315,15 @@ static inline void p54spi_int_ack(struct p54s_priv *priv, u32 val)
>  
>  static void p54spi_wakeup(struct p54s_priv *priv)
>  {
> -	unsigned long timeout;
> -	u32 ints;
> -
>  	/* wake the chip */
>  	p54spi_write32(priv, SPI_ADRS_ARM_INTERRUPTS,
>  		       cpu_to_le32(SPI_TARGET_INT_WAKEUP));
>  
>  	/* And wait for the READY interrupt */
> -	timeout = jiffies + HZ;
> -
> -	ints =  p54spi_read32(priv, SPI_ADRS_HOST_INTERRUPTS);
> -	while (!(ints & SPI_HOST_INT_READY)) {
> -		if (time_after(jiffies, timeout))
> -				goto out;
> -		ints = p54spi_read32(priv, SPI_ADRS_HOST_INTERRUPTS);
> +	if (!p54spi_wait_bit(priv, SPI_ADRS_HOST_INTERRUPTS,
> +			     cpu_to_le32(SPI_HOST_INT_READY))) {
> +		dev_err(&priv->spi->dev, "INT_READY timeout\n");
> +		goto out;
>  	}
>  
>  	p54spi_int_ack(priv, SPI_HOST_INT_READY);
> @@ -418,9 +411,7 @@ static irqreturn_t p54spi_interrupt(int irq, void *config)
>  static int p54spi_tx_frame(struct p54s_priv *priv, struct sk_buff *skb)
>  {
>  	struct p54_hdr *hdr = (struct p54_hdr *) skb->data;
> -	unsigned long timeout;
>  	int ret = 0;
> -	u32 ints;
>  
>  	p54spi_wakeup(priv);
>  
> @@ -428,15 +419,11 @@ static int p54spi_tx_frame(struct p54s_priv *priv, struct sk_buff *skb)
>  	if (ret < 0)
>  		goto out;
>  
> -	timeout = jiffies + 2 * HZ;
> -	ints = p54spi_read32(priv, SPI_ADRS_HOST_INTERRUPTS);
> -	while (!(ints & SPI_HOST_INT_WR_READY)) {
> -		if (time_after(jiffies, timeout)) {
> -			dev_err(&priv->spi->dev, "WR_READY timeout\n");
> -			ret = -1;
what about replacing the generic code "-1" with EBUSY/EIO or ETIMEDOUT?

> -			goto out;
> -		}
> -		ints = p54spi_read32(priv, SPI_ADRS_HOST_INTERRUPTS);
> +	if (!p54spi_wait_bit(priv, SPI_ADRS_HOST_INTERRUPTS,
> +			     cpu_to_le32(SPI_HOST_INT_WR_READY))) {
> +		dev_err(&priv->spi->dev, "WR_READY timeout\n");
> +		ret = -1;
here too?!

> +		goto out;
>  	}
>  
>  	p54spi_int_ack(priv, SPI_HOST_INT_WR_READY);

---

By the way a few days ago the libertas driver authors posted a patch
which "improve the average throughput 13%."

http://marc.info/?l=linux-wireless&m=123871643203161

I wonder if this would also work with p54spi.
But to test this theory, one has to rewrite the driver to use kthread
instead of hogging workqueues.... just in case you're looking for more
TODOs ;-)

Regards,
	Chr

  reply	other threads:[~2009-04-05 22:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-05 21:03 [PATCH] p54spi: get rid of busy-wait loops Max Filippov
2009-04-05 22:30 ` Christian Lamparter [this message]
2009-04-06  5:16   ` Max Filippov
2009-04-06 11:47     ` Christian Lamparter

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=200904060030.25425.chunkeey@web.de \
    --to=chunkeey@web.de \
    --cc=jcmvbkbc@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    /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).