From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common Date: Mon, 4 Feb 2013 20:33:58 +0000 Message-ID: <20130204203358.GX4720@opensource.wolfsonmicro.com> References: <510C2A47.1090607@mvista.com> <20130201205600.GA31762@arwen.pp.htv.fi> <20130201213003.GW2637@n2100.arm.linux.org.uk> <20130204154153.GA18237@arwen.pp.htv.fi> <510FF1A6.403@mvista.com> <20130204164712.GB4269@arwen.pp.htv.fi> <510FF5C9.3030600@mvista.com> <20130204170216.GC4269@arwen.pp.htv.fi> <51100A72.6030909@ti.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QQ0dNM4HnH4+xgqD" Cc: Cyril Chemparathy , balbi@ti.com, Sergei Shtylyov , Linux Documentation List , Lindgren , Russell King - ARM Linux , Vinod Koul , "Nair, Sandeep" , Chris Ball , Matt Porter , Arnd Bergmann , Devicetree Discuss , Rob Herring , Linux OMAP List , ARM Kernel List , Linux DaVinci Kernel List , "Cousson, Benoit" , Linux MMC List , Linux Kernel Mailing List , Landley , Dan Williams , Linux SPI Devel List < To: Linus Walleij Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-doc-owner@vger.kernel.org List-Id: linux-spi.vger.kernel.org --QQ0dNM4HnH4+xgqD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote: > On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy wrote: > > Based on our experience with fitting multiple subsystems on top of this > > DMA-Engine driver, I must say that the DMA-Engine interface has proven > > to be a less than ideal fit for the network driver use case. > > The first problem is that the DMA-Engine interface expects to "push" > > completed traffic up into the upper layer as a part of its callback. > > This doesn't fit cleanly with NAPI, which expects to "pull" completed > > traffic from below in the NAPI poll. We've somehow kludged together a > > solution around this, but it isn't very elegant. > I cannot understand the actual technical problem from the above > paragraphs though. dmaengine doesn't have a concept of pushing > nor polling, it basically copies streams of words from A to B, where > A/B can be a device or a buffer, nothing else. > The thing you're looking for sounds more like an adapter on top > of dmaengine, which can surely be constructed, some > drivers/dma/dmaengine-napi.c or whatever. Broadly speaking what NAPI wants is to never get any callbacks from the hardware (or DMAs). It wants to wake up periodically, take a look at what packets have been read by the hardware and process them. The goal is to have the DMAs sitting and running without disturbing the processor at all after the first packet has been handled. --QQ0dNM4HnH4+xgqD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJREBsvAAoJELSic+t+oim9gPkP/1B4xZUtjrKkxCZzZQbQoBdT 0kOI5MJhqvvNUNhGc3HWSZV7u1QfR3HeLYa+xEpJfUMmqawpMyTkDaju08Y3d1eU MXM8fx7Uj3l8TfJ0UiqcerGMyRjUUY7xQJNH/J3FdP0iqOGsoeGA7QKnonwS3LEe 4tRP2hVFWceooq5PdZs5Ya1aKIdhBvMst77xSHxeoK/ljhePKSg915a03mmXiho6 +ikeNw/dgHSrMkqReQz3DwTbL/yzeJeAYNAI8DuWh4ogXGdpzQzi8gOyxiPC02B2 i/lcLPb5khLs/aB9NyOhoTC0yYKGvZE7rlX4t8d5afDcmFb4LB4mCiwsGw7jG+AN v59ggyzzgtTOSpZQ6Ha+putZJGRsnaL/3f+uIE5jeHsPwkEjxq9VKrxJlTmChdYN vraf2JyeibxSlORdQqzJ1UGRGNyGL1tHY+CQ/5QkjPKL+PxZxuE3p9KQmB8e4S5R YTdGlSVBPRH5MnvR9W+WLSqe7PpX0eL+GGktO6oo//w710Y7Ne/Hvxd0gEI2+Ezg VdnqnAmOIF+W/DM/4um9w/hn4id5uSMie+hW9yiDoB9SdAMMQ+zsVAU0gzGKt5tz P8regcr4V7Vpw2BLCjvqNPbq7ilTksp0lhAZI352i3Mr8Ai+R60i7Jz7Fqnbk0Ut pd155HoumXzeG6zHQuV8 =M6TV -----END PGP SIGNATURE----- --QQ0dNM4HnH4+xgqD--