linux-kernel - Re: [PATCH] ARM: PL011: Add support for Rx DMA buffer polling

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-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdaJd48WOzP_iURATb=c+V6==2-AB2Y9oFyh=E3oe1eT0Q@mail.gmail.com>
Date:	Mon, 14 Jan 2013 01:04:58 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Chanho Min <chanho.min@....com>
Cc:	Alan Cox <alan@...ux.intel.com>,
	Russell King <linux@....linux.org.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
	Pawel Moll <pawel.moll@....com>, chanho0207@...il.com
Subject: Re: [PATCH] ARM: PL011: Add support for Rx DMA buffer polling

On Sat, Jan 12, 2013 at 7:50 AM, Chanho Min <chanho.min@....com> wrote:

> We tested as follows:
> We set baud rate to 3Mbps and transfer 5000 bytes via /dev/tty at
> a time. Then 4096 bytes is received by DMA irq. But, There is no way
> to get remaining 904 bytes, unless another 3192 bytes are coming,

OK clearly cut phenomena: IRQs seem to appear from the
PL080 TC (transfer complete) IRQ only, not from any of the
PL011 IRQs.

So there will be zero IRQs from the uart in /proc/interrupts
but a few of them from the PL080, correct?

>>- What DMA controller are you using with the
>>  PL011?
>
> PL080.
> We don't add any customized configuration from the mainline.

OK sorry I was thinking of the old times when we has
.cctl configured from the platform.

>> - If they cannot be software-configured, how are
>>   they then configured in hardware? Burst-only?
>> Burst single
>
> As far as I know, single request is not disabled at PL080.
> Could you explain what single request has to do with this?

At some point we reasoned that we may actually be saved
by the reverse phenomena - if single request is *NOT*
connected, there will very often be some characters in the
FIFO, and that's enough to trigger the RTIM IRQ, and we get
a nice flow. So maybe the platforms that actually work, work
because they have bursts only.

But that would pose a problem when an even burst of
characters arrive. Say 16 characters, this will be transferred
in two bursts and leave the FIFO empty, but no DMA TC
IRQ since the buffer is not full, and we'd get your
phenomena.

But I could never reproduce the latter theoretical problem,
so I think the hardware actually has a fix for this, around
the burst signal logic.

But it may very well be that the single request can not be
enabled for the PL011 for it to work properly.

You may not be able to turn this off, and in that case this
kind of code is the only way forward indeed.

Yours,
Linus Walleij
--
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/