From: Sekhar Nori <nsekhar@ti.com>
To: Peter Hurley <peter@hurleysoftware.com>,
John Ogness <john.ogness@linutronix.de>,
Tony Lindgren <tony@atomide.com>
Cc: gregkh@linuxfoundation.org, vinod.koul@intel.com,
dan.j.williams@intel.com, bigeasy@linutronix.de,
peter.ujfalusi@ti.com, dmaengine@vger.kernel.org,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] serial: omap: robustify for high speed transfers
Date: Wed, 24 Feb 2016 21:07:14 +0530 [thread overview]
Message-ID: <56CDCE2A.30809@ti.com> (raw)
In-Reply-To: <56CD2184.40304@hurleysoftware.com>
On Wednesday 24 February 2016 08:50 AM, Peter Hurley wrote:
> Just to follow-up on what Sebastian wrote.
>
> As he pointed out, these spurious interrupts are not timeout interrupts.
> Since IIR_UART[0] == 1, no uart interrupt is pending.
>
> As he wrote, these count as spurious interrupts and trigger
> interrupt shutdown at 100000 (unless acked as uart interrupts).
Okay, by adding a printk to where the check for UART_IIR_NO_INT is in
omap_8250_dma_handle_irq(), I do see that UART irq handler is called
when there is apparently no interrupt.
I don't see the error interrupt count in /proc/interrupts go up although
the code is returning IRQ_NONE when this happens. I initially thought
that must be because of the interrupt being IRQF_SHARED. But getting rid
of IRQF_SHARED still does not lead to error count going up. I need to
spend some more time to see what is going on.
> These spurious interrupts very nearly correspond 1:1 (but not quite)
> with each dma submission. So, for example, one test run had:
>
> @3Mbaud line rate
> 195826 submits
> 195823 completions
>
> 195704 spurious interrupts (ie., interrupts with IIR_UART[0] == 1)
> 0 RLSI interrupts (no line errors) (IIR_UART == 0xc6)
> 2 RX timeout interrupts (IIR_UART == 0xcc),
> one during i/o test and one at the end of i/o test
> 6 RDI interrupts (IIR_UART == 0xc4)
>
> The spurious interrupts occur with nearly 1:1 correspondence at _all_
> line rates.
>
> Presumbably, the 6 RDI interrupts are from too-slow submission of
> the next DMA and the uart rx fifo has reached rx trigger level already.
> [NOTE: we should at least be using ping-pong dma buffers for rx so that
> there is always a next DMA buffer when the current buffer is completed].
>
> There is no documentation in any of the OMAP TRMs regarding RDI
> interrupts while in DMA mode. Some guidance from TI would be appreciated.
UART interrupts triggering while UART_IIR_NO_INT is set is weird enough.
I will check around internally with hardware folks here. Getting an
answer might take time. But this is easily reproducible so I am
optimistic we will get an answer soon.
Regards,
Sekhar
WARNING: multiple messages have this Message-ID (diff)
From: Sekhar Nori <nsekhar@ti.com>
To: Peter Hurley <peter@hurleysoftware.com>,
John Ogness <john.ogness@linutronix.de>,
Tony Lindgren <tony@atomide.com>
Cc: <gregkh@linuxfoundation.org>, <vinod.koul@intel.com>,
<dan.j.williams@intel.com>, <bigeasy@linutronix.de>,
<peter.ujfalusi@ti.com>, <dmaengine@vger.kernel.org>,
<linux-serial@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] serial: omap: robustify for high speed transfers
Date: Wed, 24 Feb 2016 21:07:14 +0530 [thread overview]
Message-ID: <56CDCE2A.30809@ti.com> (raw)
In-Reply-To: <56CD2184.40304@hurleysoftware.com>
On Wednesday 24 February 2016 08:50 AM, Peter Hurley wrote:
> Just to follow-up on what Sebastian wrote.
>
> As he pointed out, these spurious interrupts are not timeout interrupts.
> Since IIR_UART[0] == 1, no uart interrupt is pending.
>
> As he wrote, these count as spurious interrupts and trigger
> interrupt shutdown at 100000 (unless acked as uart interrupts).
Okay, by adding a printk to where the check for UART_IIR_NO_INT is in
omap_8250_dma_handle_irq(), I do see that UART irq handler is called
when there is apparently no interrupt.
I don't see the error interrupt count in /proc/interrupts go up although
the code is returning IRQ_NONE when this happens. I initially thought
that must be because of the interrupt being IRQF_SHARED. But getting rid
of IRQF_SHARED still does not lead to error count going up. I need to
spend some more time to see what is going on.
> These spurious interrupts very nearly correspond 1:1 (but not quite)
> with each dma submission. So, for example, one test run had:
>
> @3Mbaud line rate
> 195826 submits
> 195823 completions
>
> 195704 spurious interrupts (ie., interrupts with IIR_UART[0] == 1)
> 0 RLSI interrupts (no line errors) (IIR_UART == 0xc6)
> 2 RX timeout interrupts (IIR_UART == 0xcc),
> one during i/o test and one at the end of i/o test
> 6 RDI interrupts (IIR_UART == 0xc4)
>
> The spurious interrupts occur with nearly 1:1 correspondence at _all_
> line rates.
>
> Presumbably, the 6 RDI interrupts are from too-slow submission of
> the next DMA and the uart rx fifo has reached rx trigger level already.
> [NOTE: we should at least be using ping-pong dma buffers for rx so that
> there is always a next DMA buffer when the current buffer is completed].
>
> There is no documentation in any of the OMAP TRMs regarding RDI
> interrupts while in DMA mode. Some guidance from TI would be appreciated.
UART interrupts triggering while UART_IIR_NO_INT is set is weird enough.
I will check around internally with hardware folks here. Getting an
answer might take time. But this is easily reproducible so I am
optimistic we will get an answer soon.
Regards,
Sekhar
next prev parent reply other threads:[~2016-02-24 15:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-22 10:27 [PATCH 0/4] serial: omap: robustify for high speed transfers John Ogness
2016-01-22 10:27 ` John Ogness
2016-01-25 18:56 ` Peter Hurley
2016-01-29 16:35 ` John Ogness
2016-02-03 1:21 ` Peter Hurley
2016-02-11 12:02 ` John Ogness
2016-02-11 21:00 ` Tony Lindgren
2016-02-22 15:30 ` John Ogness
2016-02-22 19:38 ` Tony Lindgren
2016-02-23 9:59 ` Sekhar Nori
2016-02-23 9:59 ` Sekhar Nori
2016-02-23 12:43 ` Sebastian Andrzej Siewior
2016-02-23 16:56 ` Andy Shevchenko
2016-02-24 3:20 ` Peter Hurley
2016-02-24 15:37 ` Sekhar Nori [this message]
2016-02-24 15:37 ` Sekhar Nori
2016-02-24 15:46 ` Sebastian Andrzej Siewior
2016-03-07 20:23 ` Peter Hurley
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=56CDCE2A.30809@ti.com \
--to=nsekhar@ti.com \
--cc=bigeasy@linutronix.de \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=peter.ujfalusi@ti.com \
--cc=peter@hurleysoftware.com \
--cc=tony@atomide.com \
--cc=vinod.koul@intel.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.