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: <CACRpkdZihnp3_Df==QRWxQupgi7W_YXZxc-MxkusVH6J+Vx56A@mail.gmail.com>
Date:	Mon, 4 Feb 2013 21:29:46 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Cyril Chemparathy <cyril@...com>
Cc:	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>,
	Mark Brown <broonie@...nsource.wolfsonmicro.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 Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy <cyril@...com> 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.

> The second problem is one of binding fixed DMA resources to fixed users.
>   AFAICT, the stock DMA-Engine mechanism works best when one DMA
> resource is as good as any other.

The filter function picks a channel for whatever reason. That reason
can be, well whatever. Some engines have a clever mechanism to
select resources on the other end.

Then for tying devices to channels we have the dmaengine
DT branch:
http://git.infradead.org/users/vkoul/slave-dma.git/shortlog/refs/heads/topic/dmaengine_dt

This stuff didn't go into v3.8 but you can *sure* expect it
to be in v3.9.

Or are you referring to a multi-engine scenario? Say if there is engine
A and B and depending on circumstances A or B may be preferred
in some order (and permutations of this problem). That is currently
identified as a shortcoming that we need help to address.

> To get over this problem, we've added
> support for named channels, and drivers specifically request for a DMA
> resource by name.  Again, this is less than ideal.

Jon Hunter has been working on a mechanism to look up DMA channels
from struct device *, dev_name() or a device tree node for example.
Just like we do with clocks or regulators.

Look at this patch from the dmaengine_dt branch:
http://git.infradead.org/users/vkoul/slave-dma.git/commitdiff/528499a7037ebec0636d928f88cd783c618df3c5

Looks up an optionally named channel for a certain
device.

It currently only supports device tree, but you are free to
patch in whatever mechanism you need there. Static tables
in platform data works too. Just nobody did it.

So go ahead and hack on dma_request_slave_channel().
(I would just branch of the DT branch.)

> We found that virtio devices offer a more elegant solution to this
> problem.  First, the virtqueue interface is a much better fit into NAPI
> (callback --> napi schedule, napi poll --> get_buf), and this eliminates
> the need for aforementioned kludges in the code.  Second, the virtio
> device infrastructure nicely uses the device model to solve the problem
> of binding DMA users to specific DMA resources.

Not that I understand the polling issue, but it sounds to me like
what Jon is doing is similar.

Surely the way to look up resources cannot be paramount in this
discussion, I think the real problem must be your specific networking
usecase, so we need to drill into that.

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/