linux-kernel - Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

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]

Message-ID: <CACRpkdbeoMO1rjPiWDAuVL0uYwMGF+9-vCxqoMiMd1uAgZm=RQ@mail.gmail.com>
Date:	Tue, 5 Feb 2013 19:29:53 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Cyril Chemparathy <cyril@...com>, balbi@...com,
	Sergei Shtylyov <sshtylyov@...sta.com>,
	Linux Documentation List <linux-doc@...r.kernel.org>,
	Lindgren <tony@...mide.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Vinod Koul <vinod.koul@...el.com>,
	"Nair, Sandeep" <sandeep_n@...com>, Chris Ball <cjb@...top.org>,
	Matt Porter <mporter@...com>, Arnd Bergmann <arnd@...db.de>,
	Devicetree Discuss <devicetree-discuss@...ts.ozlabs.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Linux OMAP List <linux-omap@...r.kernel.org>,
	ARM Kernel List <linux-arm-kernel@...ts.infradead.org>,
	Linux DaVinci Kernel List 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	"Cousson, Benoit" <b-cousson@...com>,
	Linux MMC List <linux-mmc@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Landley <rob@...dley.net>, Dan Williams <djbw@...com>,
	Linux SPI Devel List 
	<spi-devel-general@...ts.sourceforge.net>
Subject: Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

On Tue, Feb 5, 2013 at 5:47 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote:
>
>> For IRQ mode, use the completion callback to push each cookie
>> to NAPI, and thus let the IRQ drive the traffic.
>
> The whole purpose of NAPI is to avoid taking interrupts for completion
> of transfers.  Anything that generates interrupts when NAPI is in
> polling mode is defeating the point.

So what I was trying to get across is that when you're in polling
mode you do not set DMA_PREP_INTERRUPT on your transfers,
just throw the obtained struct dma_async_tx_descriptor on some
list and then when polling use dma_async_is_tx_complete()
on the channel and the cookie inside the descriptor.

I was trying to describe that you can move from
IRQ mode to polling mode and back again by selectively
choosing to set/not set the DMA_PREP_INTERRUPT flag.

If polling is all you want you never set it.

Then there is the fact that the transfer needs to have
been flagged complete and it is indeed something that needs
to be set in some bytes somewhere. By something. But it
doesn't have to be an interrupt from the DMA controller.

In such cases we use dma_async_is_tx_complete() with
channel and cookies as parameter. This will call down into the
driver chan->device->device_tx_status() and there we can
actually poll the hardware to see if the transfer happens to
be complete, and if it is flag it complete.

Which is likely what we want.

No interrupts, only function calls as far as I can see.

(I bet Russell will poke a hole in my reasoning, but it's worth
a try.)

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/