linux-kernel - Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request

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]

Date:	Wed, 7 Mar 2012 10:46:38 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Guennadi Liakhovetski <g.liakhovetski@....de>
Cc:	Vinod Koul <vinod.koul@...el.com>, linux-kernel@...r.kernel.org,
	Jassi Brar <jassisinghbrar@...il.com>,
	Russell King <linux@....linux.org.uk>
Subject: Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel()

On Wed, Mar 7, 2012 at 10:18 AM, Guennadi Liakhovetski
<g.liakhovetski@....de> wrote:
> [Vinod]
>> I like the approach outlined by Linus W [1], where we can get the
>> information from platform (DT, FW,....) and its presented to dmaengine.
>
> I still don't see an answer to the very same question, that we've been
> discussing over multiple threads and mails now: how do we use that, if
> it's not a 1-to-1 mapping? I.e., many channels on many controllers can be
> run-time configured for use with different client devices. Also the above
> idea from Linus W doesn't directly address this.

True, it's a new problem space.

However I see nothing wrong in the basic idea that the platform data
and/or device tree should supply a number of mappings with constraints
to dmaengine, that eventually helps it to select and enable a proper
channel.

For example in the regulator framework we have voltage constraints on
the rails, and the subsystem infers the voltage from these constraints.
Constraints in platform data are nice.

So the way forward in my simple opinion is to get the core dmaengine
to be aware of the applicable constraints and hand out DMA channels
or NACK channel requests if these constraints cannot be satisfied.

So when you write:

> Whereas doing a reverse mapping: for each (potential)
> DMA user reference a list of channels, that it can use - would be really
> clumsy.

I basically disagree. I think the knowledge of available channels
and their characteristics should be known to the dmaengine
core, and the core shall select what channel to use.

Else I fear we end up with a lot of logic distributed all over the
place with no consolidation in sight, it will just grow everywhere
with each new DMA controller.

However it may need to have a different form given what Russell
says: many drivers tend to have a number of arbitrable channels
and the constraints is really about which event line (burst/single
request line) to mux in for that one channel. So the platform
data may need to take a form that better reflects this, which in
turn necessitates that the dmaengine core and channel request
interface be refactored to be aware of this kind of DMAC slaves.

It requires a bit of upfront code but I think this is the way forward.
Besides, Russell says he's already working on refactoring one
part of the problem (virtual channels / request lines) if I understand
him correctly.

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/