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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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

(changed Russell's address to the one from MAINTAINERS)

On Wed, 7 Mar 2012, Vinod Koul wrote:

> On Tue, 2012-03-06 at 14:03 +0100, Guennadi Liakhovetski wrote:
> <adding few folks to thread, who i may be intrested in this discussion>
> > But the DMAC is certainly a better match for making channel-selection 
> > decisions.
> I am not sure about that as well...
> > 
> > > Bigger question is who knows about this mapping and how do we
> > > incorporate this mapping into channel allocation
> > 
> > The platform does. And this knowledge has to be passed to the relevant 
> > driver. But I think it's the DMAC driver, that is relevant, not the client 
> > driver. The platform would supply information like
> > 
> > DMAC #1
> > 	channel #1
> > 		(can be used for) device #1
> > 		device #2
> > 		...
> > 	channel #2
> > 	...
> > ...
> right :-)
> and we need to ensure that somehow this information is presented to
> dmaengine and dmaengine uses this information to filter the channel
> requests. In past we had good discussion [1], [2], [3] on this topic but
> unfortunately nothing came out of it.
> 
> 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.

Following his clock / regulator analogy. There the correspondence is 
clearly fixed: fixed clocks and power supplies are used with every 
specific device. Whereas in our DMAC case it's not.

I'm trying to think of an analogy, where you have several pools of 
resources, and each consumer can use any of the resources on some of those 
pools, but nothing pops up. Interrupts, GPIOs, clocks, regulators - they 
all are fixed to their consumers.

Also notice, this can become even worse, if we ever get controllers with 
channels with different capabilities on them. So, I really would let the 
DMAC driver do the mapping and not try to put it in the core.

Thanks
Guennadi

> I think we need to solve this _now_. There are two aspects
> a) to ensure dmaengine understand channel-client mapping. For this we
> can start with idea in [1] and see if this suits everyones needs
> b) how to ensure the platform gives this information in variety of arch
> we have (arm, x86, sh-....)
> 
> Thoughts...?
> > And I don't think, it would be reasonable to let every slave driver use 
> > this information. These lists can also be optimised for specific 
> > platforms. E.g., on some sh-mobile SoCs you have two DMAC types. One of 
> > them can serve devices from list A on any channel, the other one - from 
> > list B. So, all you have to do, is to reference either A or B from your 
> > DMAC platform data. Whereas doing a reverse mapping: for each (potential) 
> > DMA user reference a list of channels, that it can use - would be really 
> > clumsy.
> > 
> [1]:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-August/060717.html
> [2]:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-July/059212.html
> [3]:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-July/059217.html
> 
> 
> -- 
> ~Vinod
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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/