From: Peter Hurley <peter@hurleysoftware.com>
To: Sekhar Nori <nsekhar@ti.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
John Ogness <john.ogness@linutronix.de>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Tony Lindgren <tony@atomide.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
linux-omap@vger.kernel.org
Subject: Re: omap uart + dma issues (Re: [PATCH] tty: serial: 8250_omap: do not defer termios changes)
Date: Wed, 13 Apr 2016 18:14:24 -0700 [thread overview]
Message-ID: <570EEEF0.2070102@hurleysoftware.com> (raw)
In-Reply-To: <570E295B.2030708@ti.com>
On 04/13/2016 04:11 AM, Sekhar Nori wrote:
> On Wednesday 13 April 2016 05:30 AM, Peter Hurley wrote:
>
>>>> - generates spurious uart interrupt for every rx dma transaction
>>>> (ie., necessitates acking every UART interrupt, even UART_IIR_NO_INT)
>>>> _Even with this workaround_, it still generates spurious interrupt warning
>>>> which shuts off interrupts for several ms while logging the error
>>>> message to the console, virtually guaranteeing lost data.
>>>
>>> as I wrote in my other email I think RDI should be disabled with DMA
>>
>>
>> I'll test to see if disabling RDI eliminates the UART_IIR_NO_INT spurious
>> interrupts.
Ok; disabling UART_IER_RDI eliminates the UART_IIR_NO_INT spurious
interrupts.
However, disabling RDI disables RX timeout as well, so data just sits in
the RX fifo with no way to get it out. AFAICT that's a showstopper.
>>> according the Intel manual and I *think* someone here reported that
>>> they see the same problem.
>>
>> Let's confirm with the Intel folks that this is true, which would argue
>> for using the omap-style rx dma flow.
>
> Andy Shevchenko pointed this out here: https://lkml.org/lkml/2016/2/23/588
which Andy noted as well:
On 02/23/2016 08:56 AM, Andy Shevchenko wrote:
> The problem is that we have no separate bit to control timeout
> interrupts from UART.
next prev parent reply other threads:[~2016-04-14 1:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-31 8:41 [PATCH] tty: serial: 8250_omap: do not defer termios changes John Ogness
2016-03-31 8:41 ` John Ogness
2016-03-31 10:51 ` John Ogness
2016-03-31 14:33 ` One Thousand Gnomes
2016-04-05 4:07 ` Peter Hurley
2016-04-11 8:18 ` John Ogness
2016-04-11 17:53 ` Peter Hurley
2016-04-11 18:31 ` Sebastian Andrzej Siewior
2016-04-11 20:10 ` Peter Hurley
2016-04-12 17:03 ` Sebastian Andrzej Siewior
2016-04-12 18:42 ` Peter Hurley
2016-04-14 16:03 ` Peter Hurley
2016-04-12 23:20 ` 8250 dma issues ( was Re: [PATCH] tty: serial: 8250_omap: do not defer termios changes) Peter Hurley
2016-04-14 15:07 ` One Thousand Gnomes
2016-04-14 17:54 ` Peter Hurley
2016-04-13 0:00 ` omap uart + dma issues (Re: " Peter Hurley
2016-04-13 11:11 ` Sekhar Nori
2016-04-13 11:11 ` Sekhar Nori
2016-04-14 1:14 ` Peter Hurley [this message]
2016-05-03 12:00 ` [PATCH] tty: serial: 8250_omap: do not defer termios changes Vignesh R
2016-05-03 12:00 ` Vignesh R
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=570EEEF0.2070102@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bigeasy@linutronix.de \
--cc=gregkh@linuxfoundation.org \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=tony@atomide.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.