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 for Android: free password hash cracker in your pocket

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

Message-ID: <20130114002608.GV23505@n2100.arm.linux.org.uk>
Date:	Mon, 14 Jan 2013 00:26:08 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Chanho Min <chanho.min@....com>, Alan Cox <alan@...ux.intel.com>,
	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 Mon, Jan 14, 2013 at 01:04:58AM +0100, Linus Walleij wrote:
> 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.

What you describe above is exactly the problem I see on the Versatile
platform with it's PL080 and PL011.  I made the comment that this setup
can't work properly as it stands.  And I don't think that setting a
timer which fires every jiffy count is really a solution to the problem.
That's an expensive way of having a per-jiffy callback for something
that's probably going to remain idle most of the time.

Not only that, but a 1 jiffy timeout even for slower baud rates is
just utterly silly.

The point of using DMA is to move the workload off the CPU onto hardware,
so that the CPU can go off and do other stuff.  If it's having to poll
it once every jiffy, then...

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

Unless there's something inbetween the PL080 and PL011 to do that.
The peripherals themselves don't have any means of controlling this.

The solution I came up with on Versatile was to just not enable
receive DMA - at all.
--
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/