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: <201302042147.38407.arnd@arndb.de>
Date:	Mon, 4 Feb 2013 21:47:38 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Cyril Chemparathy <cyril@...com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.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>,
	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 Monday 04 February 2013, Linus Walleij wrote:
> So I think the above concerns are moot. The callback we can
> set on cookies is entirely optional, and it's even implemented by
> each DMA engine, and some may not even support it but require
> polling, and then it won't even be implemented by the driver.

Just to ensure that everybody is talking about the same thing here:
Is it just the callback that is optional, or also the interrupt
coming from the hardware? With NAPI, you want to avoid both, since
getting an interrupt for every packet adds noticeable overhead,
but you still want to be able to tell the hardware that you
are fed up with polling and would like to get an interrupt again
when the next data arrives (ideally, after either a little time
has passed after the next packet, or a specific number of packets
has arrived).

	Arnd
--
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/