linux-sh.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH] serial: sh-sci: submit rx dma the way the DMA driver can handle it
Date: Mon, 06 Oct 2014 01:55:40 +0000	[thread overview]
Message-ID: <20141006015540.GD22040@verge.net.au> (raw)
In-Reply-To: <1412266448-20266-1-git-send-email-wsa@the-dreams.de>

On Thu, Oct 02, 2014 at 06:14:08PM +0200, Wolfram Sang wrote:
> From: Wolfram Sang <wsa+renesas@sang-engineering.com>
> 
> The shdmac driver has a problem when one wants to submit two RX
> descriptors and then use issue_pending on both (like this driver does):
> 
> Submit first desc
> -> channel state after: SHDMA_PM_ESTABLISHED
> 
> Submit second desc
> -> channel state after: SHDMA_PM_PENDING
> 
> PENDING here means: "Oh, we will wait until the first desc is finished
> and then the second desc will be grabbed from the list anyhow"
> 
> However, because issue_pending does nothing for states !> SHDMA_PM_ESTABLISHED, nothing ever gets active :(
> 
> Since the DMA driver is probably replaced soon anyhow, I decided for the
> least intrusive workaround which is to use issue_pending on every RX
> desc. (Yes, setting s->active_rx twice is ugly).
> 
> Probably not for upstream! However, this patch restores DMA capability
> for SCIFA on my Lager board. Sadly, not for SCIF due to interrupt
> problems still to be investigated.
> 
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

Acked-by: Simon Horman <horms+renesas@verge.net.au>

sh-sci patches usually go via linux-serial@vger.kernel.org and
Greg Kroah-Hartman <gregkh@linuxfoundation.org>. Could you repost this patch
with those parties included?

> ---
> 
> Some more words about the not working SCIF:
> 
> Once I submit the RX descriptor, I don't get any irq anymore (which the driver
> needs to detect timeouts). Before that, I got them.
> 
> SCIFA has a bit (SCSCR_RDRQE) to select if the interrupt should go to the CPU
> or DMAC and the driver handles this correctly, so DMA works again.
> 
> Plain SCIF does not have such a bit. The documentation has a chapter "SCIF
> Interrupt Sources and the DMAC" (chapter 51.4 here in v0.9) which is a little
> vague to me. But from what I understand, I should get an irq along with the
> DMAC transferring data. The implementation of this driver shows that earlier SH
> hardware worked this way. However, I don't get interrupts, so the timeout
> mechanism fails. DMA works partly, you can receive in 32 bytes chunks only. If
> you are happy with that, you can also use SCIF. Good practice for your typing
> skills ;)
> 
> So, my SCIF->SCIFA patch becomes more useful, too.
> 
>  drivers/tty/serial/sh-sci.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index b11819bc95c4..f23b4d2ab51f 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -1365,16 +1365,18 @@ static void sci_submit_rx(struct sci_port *s)
>  			}
>  			dev_warn(s->port.dev,
>  				 "failed to re-start DMA, using PIO\n");
> +
> +			chan->device->device_control(chan, DMA_TERMINATE_ALL, 0);
>  			sci_rx_dma_release(s, true);
>  			return;
>  		}
> +
> +		s->active_rx = s->cookie_rx[0];
> +
> +		dma_async_issue_pending(chan);
>  		dev_dbg(s->port.dev, "%s(): cookie %d to #%d\n",
>  			__func__, s->cookie_rx[i], i);
>  	}
> -
> -	s->active_rx = s->cookie_rx[0];
> -
> -	dma_async_issue_pending(chan);
>  }
>  
>  static void work_fn_rx(struct work_struct *work)
> -- 
> 2.0.0
> 

  reply	other threads:[~2014-10-06  1:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-02 16:14 [PATCH] serial: sh-sci: submit rx dma the way the DMA driver can handle it Wolfram Sang
2014-10-06  1:55 ` Simon Horman [this message]
2014-10-06  5:59 ` Wolfram Sang
2014-10-06  7:39 ` Simon Horman

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=20141006015540.GD22040@verge.net.au \
    --to=horms@verge.net.au \
    --cc=linux-sh@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).