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:	Mon, 19 Mar 2012 17:32:20 +0100 (CET)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	Vinod Koul <vinod.koul@...ux.intel.com>
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 Mon, 19 Mar 2012, Vinod Koul wrote:

> On Mon, 2012-03-19 at 15:45 +0100, Guennadi Liakhovetski wrote:
> > > Btw why should .device_alloc_chan_resources() need this, I so no reason,
> > > unless we are working around some other issue.
> > 
> > The reason is the following: with the proposed modifications to the 
> > existing API we want to achieve:
> > 
> > 1. client requests a channel
> > 	dmaengine_request_slave_channel(dev)
> > 2. the core looks through platform-specific mapping tables and finds a 
> >    suitable channel
> > 3. the core calls device driver's .device_alloc_chan_resources() method 
> >    for that channel
> > 4. the client uses
> > 	dmaengine_slave_config(chan, config)
> >    to configure the channel
> > 
> > Now, that last channel configuration can have two aspects: (1) static: 
> > routing, multiplexing, peripheral address. This needs to be set only once 
> > per each such channel allocation to a specific client,
> correct
> 
> >  (2) (potentially) 
> > dynamic: any burst sizes etc.
> I dont think burst-size would be dynamic, are they on sh- ?

Not atm, I just thought some other platforms / clients wanted to configure 
it dynamically. I may be wrong, though.

> >  We can pass both these configuration types 
> > together to the DMA device driver at step 4. For that the slave would have 
> > to embed struct dma_slave_config into another hardware-specific type with 
> > additional routing parameters.
> I think most of generic parameters are already there. As long as you
> dont have abnormal controller current dma_slave_config should suffice.
> Again, if you have specific need pls let us know, this structure can &
> should be expanded if dmacs needs something for slave configuration.

Sure. In the datasheet we have: to configure a channel for client 1 write 
value X to register A and value Y to register B. That's it. One of them is 
really just a magic slave ID. Another one has several fields with values 
like bus width and transfer size. They could be passed "properly," but 
since those fields also vary between DMAC versions, it is easier to just 
fix the whole register value per client and pass it from the platform 
data. In any case, at least the slave ID is really just a constant, that 
cannot be calculated and has to be passed from platform data.

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