linux-kernel - Re: [PATCH 11/13] arm: dts: dra7: add DMA properties for UART

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 5 Nov 2014 14:43:23 -0500
From:	"Lennart Sorensen" <lsorense@...lub.uwaterloo.ca>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
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 Wed, Nov 05, 2014 at 05:30:51PM +0100, Sebastian Andrzej Siewior wrote:
> 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 :)

I managed to get something dma related on uart3.  But it isn't happy:

[   95.577401] DMA misaligned error with device 53
repeated many times.

I wonder if the dma support isn't quite working for the omap572x yet in
this tree (ti's 3.12.y tree), or maybe it is picky and the driver still
needs a bit of work.

I have had no issues on uart7 and 8 without 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…

-- 
Len Sorensen
--
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/