All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sekhar Nori <nsekhar@ti.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	peter@hurleysoftware.com
Cc: linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
	linux-serial@vger.kernel.org, john.ogness@linutronix.de
Subject: Re: [RFC 3/3] serial: 8250_omap: try to avoid IER_RDI with DMA
Date: Wed, 26 Aug 2015 14:42:10 +0530	[thread overview]
Message-ID: <55DD82EA.6090300@ti.com> (raw)
In-Reply-To: <1439568064-7907-3-git-send-email-bigeasy@linutronix.de>

On Friday 14 August 2015 09:31 PM, Sebastian Andrzej Siewior wrote:
> It has been observed on DRA7-evm that the UART triggers the interrupt and
> reading IIR says IIR_NO_INT. It seems that we receive data via RX-DMA
> but the interrupt is triggered anyway. I have hardly observed it on
> AM335x and not in *that* quantity. On DRA7-evm with continuous transfers
> at 3MBaud and CPU running at 1.5Ghz it is possible that the IRQ-core will
> close the UART interrupt after "some time" with "nobody cared".
> 
> I've seen that by not enabling IER_RDI those spurious interrupts are not
> triggered. Also it seems that DMA and RDI cause the "timeout interrupt"
> which does not allow RX-DMA to be scheduled even if the FIFO reached the
> programmed RX threshold. However without RDI we don't get a notification
> if we have less than RX threshold bytes in the FIFO.
> This is where we have the rx_dma_wd timer. After programming the RX-DMA
> transfer wait HZ / 4 or 250ms for it to complete. If it does not
> complete in that time span we cancel the DMA transfer and enable RDI.
> RDI will trigger an UART interrupt in case we have bytes in the FIFO.
> Once we read bytes manually from the FIFO we enable RX-DMA again
> (without RDI) with the same 250ms timeout.
> 
> One downside with this approach is that latency sensitive protocols that
> transfer less than 48 bytes will have to wait 250ms to complete.

I guess because of this reason, wlink8 bluetooth connected to TI's DRA7
EVM failed to probe with this patch included. At the least, looks like
this patch needs some tuning.

> 
> Is there maybe a user interface where one could set small or bulk transfers?
> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

Thanks,
Sekhar

WARNING: multiple messages have this Message-ID (diff)
From: Sekhar Nori <nsekhar@ti.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	<peter@hurleysoftware.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-omap@vger.kernel.org>,
	<linux-serial@vger.kernel.org>, <john.ogness@linutronix.de>
Subject: Re: [RFC 3/3] serial: 8250_omap: try to avoid IER_RDI with DMA
Date: Wed, 26 Aug 2015 14:42:10 +0530	[thread overview]
Message-ID: <55DD82EA.6090300@ti.com> (raw)
In-Reply-To: <1439568064-7907-3-git-send-email-bigeasy@linutronix.de>

On Friday 14 August 2015 09:31 PM, Sebastian Andrzej Siewior wrote:
> It has been observed on DRA7-evm that the UART triggers the interrupt and
> reading IIR says IIR_NO_INT. It seems that we receive data via RX-DMA
> but the interrupt is triggered anyway. I have hardly observed it on
> AM335x and not in *that* quantity. On DRA7-evm with continuous transfers
> at 3MBaud and CPU running at 1.5Ghz it is possible that the IRQ-core will
> close the UART interrupt after "some time" with "nobody cared".
> 
> I've seen that by not enabling IER_RDI those spurious interrupts are not
> triggered. Also it seems that DMA and RDI cause the "timeout interrupt"
> which does not allow RX-DMA to be scheduled even if the FIFO reached the
> programmed RX threshold. However without RDI we don't get a notification
> if we have less than RX threshold bytes in the FIFO.
> This is where we have the rx_dma_wd timer. After programming the RX-DMA
> transfer wait HZ / 4 or 250ms for it to complete. If it does not
> complete in that time span we cancel the DMA transfer and enable RDI.
> RDI will trigger an UART interrupt in case we have bytes in the FIFO.
> Once we read bytes manually from the FIFO we enable RX-DMA again
> (without RDI) with the same 250ms timeout.
> 
> One downside with this approach is that latency sensitive protocols that
> transfer less than 48 bytes will have to wait 250ms to complete.

I guess because of this reason, wlink8 bluetooth connected to TI's DRA7
EVM failed to probe with this patch included. At the least, looks like
this patch needs some tuning.

> 
> Is there maybe a user interface where one could set small or bulk transfers?
> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

Thanks,
Sekhar

  reply	other threads:[~2015-08-26  9:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-14 16:01 [PATCH 1/3] serial: 8250: move rx_running out of the bitfield Sebastian Andrzej Siewior
2015-08-14 16:01 ` [PATCH 2/3] serial: 8250_omap: check how many bytes were injected Sebastian Andrzej Siewior
2015-08-26  9:38   ` Sekhar Nori
2015-08-26  9:38     ` Sekhar Nori
2015-08-26 12:44   ` Peter Hurley
2015-08-26 13:01     ` Sekhar Nori
2015-08-26 13:01       ` Sekhar Nori
2015-08-14 16:01 ` [RFC 3/3] serial: 8250_omap: try to avoid IER_RDI with DMA Sebastian Andrzej Siewior
2015-08-26  9:12   ` Sekhar Nori [this message]
2015-08-26  9:12     ` Sekhar Nori
2015-08-26  9:37 ` [PATCH 1/3] serial: 8250: move rx_running out of the bitfield Sekhar Nori
2015-08-26  9:37   ` Sekhar Nori
2015-08-26 12:43   ` Peter Hurley
2015-08-26 12:58     ` Sekhar Nori
2015-08-26 12:58       ` Sekhar Nori

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=55DD82EA.6090300@ti.com \
    --to=nsekhar@ti.com \
    --cc=bigeasy@linutronix.de \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=peter@hurleysoftware.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.