From: Peter Hurley <peter@hurleysoftware.com>
To: Sekhar Nori <nsekhar@ti.com>
Cc: John Ogness <john.ogness@linutronix.de>,
Tony Lindgren <tony@atomide.com>,
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: Mon, 7 Mar 2016 12:23:36 -0800 [thread overview]
Message-ID: <56DDE348.4060801@hurleysoftware.com> (raw)
In-Reply-To: <56CDCE2A.30809@ti.com>
On 02/24/2016 07:37 AM, Sekhar Nori wrote:
> 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.
Thanks.
Also, after looking over the latest errata for am335x, I was surprised
not to see an errata for our TX DMA workaround.
Currently, to get memory-to-device DMA to start *on am335x only* requires
writing the 1st byte to the UART fifo to trigger DMA, which is pretty odd.
It's almost as if the TX DMA trigger is edge-triggered rather than
level-triggered.
Let me know if you need more info.
Regards,
Peter Hurley
prev parent reply other threads:[~2016-03-07 20:23 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
2016-02-24 15:37 ` Sekhar Nori
2016-02-24 15:46 ` Sebastian Andrzej Siewior
2016-03-07 20:23 ` Peter Hurley [this message]
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=56DDE348.4060801@hurleysoftware.com \
--to=peter@hurleysoftware.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=nsekhar@ti.com \
--cc=peter.ujfalusi@ti.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.