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
| ||
|
Date: Tue, 7 Jun 2016 13:04:19 +0300 From: Andy Shevchenko <andy.shevchenko@...il.com> To: "Bryan O'Donoghue" <pure.logic@...us-software.ie> Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Peter Hurley <peter@...leysoftware.com>, "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>, Vinod Koul <vinod.koul@...el.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, dmaengine <dmaengine@...r.kernel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Puustinen, Ismo" <ismo.puustinen@...el.com>, Heikki Krogerus <heikki.krogerus@...ux.intel.com> Subject: Re: [PATCH v5 00/11] serial: 8250: split LPSS to 8250_lpss, enable DMA on Quark On Thu, May 26, 2016 at 7:36 PM, Bryan O'Donoghue <pure.logic@...us-software.ie> wrote: > On Tue, 2016-05-24 at 21:08 +0300, Andy Shevchenko wrote: >> On Tue, 2016-05-24 at 20:37 +0300, Andy Shevchenko wrote: >> > On Thu, 2016-05-19 at 02:18 +0100, Bryan O'Donoghue wrote: >> > > On Thu, 2016-05-12 at 18:06 +0300, Andy Shevchenko wrote: >> > > > On Fri, 2016-05-06 at 18:17 +0300, Andy Shevchenko wrote: >> > > > > This is combined series of two things: >> > > > > - split out the Intel LPSS specific driver from 8250_pci into >> > > > > 8250_lpss >> > > > > - enable DMA support on Intel Quark UART >> > > > > >> > > > > The patch has been tested on few Intel SoCs / platforms. In >> > > > > any >> > > > > case I >> > > > > would >> > > > > like to ask Bryan to do independent test. >> > > >> > > Andy. >> > > >> > > It looks as though there's a performance drop when enabling the >> > > DMA >> > > here (v) stock PIO mode with the 8250 driver. >> >> Wait, the time measurement you done is unrelated to DMA/non-DMA mode. >> It's significantly depend to the speed of the port. > > Does it ? The size of the FIFO is what - 16 bytes ? Doesn't matter if you have data longer than FIFO size you will wait for data to be sent / received (DMA request line is asserted accordingly). > Max burst size is 8 > bytes - so for 37 bytes you'd expect to see five DMA transactions {8, > 8, 8, 5}, for the second test 183 bytes you'd expect to see 23 eight > byte transactions followed by one 7 byte transaction. The flip side to > add data to the FIFO in PIO mode is a pretty different pattern. Yes and it relies on DMA request signal. DMA is not about transfer speed it is about offload CPU. Basically you run the transfer process in a separate thread in the user application which will sleep until transfer is done. Your test case is synchronous. > >> I also tried on my Galileo board, I used longer data stream, i.e. >> output >> of dmesg (since your data pattern makes 0:s in statistics) and got >> something quite near to each other: > > I'll find some time to look at both a short stream and a long stream, > based on the branch you've indicated and maybe against the latest > stable kernel. Please, do. I'm planning to resend new version soon (this week or lately beginning of the next one). -- With Best Regards, Andy Shevchenko
Powered by blists - more mailing lists