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]

Message-ID: <1332157021.7180.5.camel@vkoul-udesk3>
Date:	Mon, 19 Mar 2012 17:07:01 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Guennadi Liakhovetski <g.liakhovetski@....de>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org,
	'Jassi Brar' <jassisinghbrar@...il.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Magnus Damm <magnus.damm@...il.com>,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH/RFC] dmaengine: add a slave parameter to
 __dma_request_channel()

On Fri, 2012-03-16 at 10:36 +0100, Guennadi Liakhovetski wrote:
> On Mon, 12 Mar 2012, Vinod Koul wrote:
> 
> > On Fri, 2012-03-09 at 13:20 +0100, Guennadi Liakhovetski wrote:
> > > It can be made to work as long as there's only one DMAC group with 
> > > configurable channels and all other DMACs are dedicated to specific 
> > > peripherals, yes. I don't know whether there are already now or are 
> > > approaching any platforms with multiple reconfigurable groups. 
> > And that is what I am talking about.
> > 
> > Having specific channel mapping given by platform for all channels which
> > are to be used dedicated. And a pool of channels which can be used by
> > anyone (if they can be) on a platform.
> > 
> > Does this proposal sound good for others as well. I think we can target
> > this for next merge cycle, we are too late for the current one.
> 
> Ok, let me try to summarise, what this would mean for sh-mobile:
> 
> 1. this proposal introduces a new special case: with or without a mapping, 
> that will have to be handled in affected client and DMA controller 
> drivers. E.g., on sh-mobile some devices might on some systems use 
> channels from "general purpose" DMA controllers (no mapping), on other 
> systems it will be a dedicated controller (fixed mapping).
that should work. The mapping is platform specific, so I expect the
board handling code for that one to tell dmaengine the mapping.
On device A: controller P can be generic but on some other device it can
be dedicated.
> 
> 2. this will break, if we get more than 1 "general purpose" type with 
> different supported client sets. So, we develop a new API with a 
> pre-programmed limitation.
No, see above
> 
> 3. this will mean a substantial driver and platform code modification. 
> Nothing super-complex, but still some.
Again No to driver, Yes to platform mapping part, which is again device
specfic
> 
> 4. we'll need a 3-stage channel allocation / configuration: request, 
> filter, config. Whereas with my configuration-parameter proposal it's just 
> one stage: allocate-and-configure.
Its not about stages, it about doing the right thing. Which happens to
make dmaengine aware of the mapping which exists for a certain device
and give you the channels based on how hardware is mapped.

If we get this right then we dont need to worry about filtering as well,
that can go away. With Russell's approach it just request_config one
single step to get channel and get it configured for slave.
> 
> So, yes, this would be doable, but it doesn't look like a very good 
> solution to me.


-- 
~Vinod

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