[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <545A50BB.2020307@linutronix.de>
Date: Wed, 05 Nov 2014 17:30:51 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
CC: linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
tony@...mide.com, balbi@...com, gregkh@...uxfoundation.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH 11/13] arm: dts: dra7: add DMA properties for UART
On 11/05/2014 05:20 PM, Lennart Sorensen wrote:
> On Wed, Nov 05, 2014 at 10:33:15AM -0500, Lennart Sorensen wrote:
>> Two systems ran 16 hours each so far with no issues. Pushed 170MB of
>> data through the pair of serial ports on one system at 230400.
>
> The console on uart3 doesn't appear to be using the dma assuming the
> values in /sys for the dma controller and bytes transferred mean anything.
> It does mention in dmesg that it allocated dma channels for uart3 though.
Then it should use it :)
> How do you tell if it is using dma?
There is omap_8250_tx_dma() and omap_8250_rx_dma(). Both setup
callbacks (the rx+tx _complete). Upon successful DMA transfer you
should see them invoked with bytes transfered (>0).
For RX transfer you need at least trigger bytes in the FIFO within a
given time frame (I think it was 46 bytes and the delay may be up to 2
bytes). If you miss this then DMA for RX won't wire and you purge the
FIFO manually via "timeout-interrupt" (the callback will be invoked
with an error condition and 0 bytes).
Assuming this works for you then one should figure out why the counters
in /sys are not updated…
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists