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
| ||
|
Date: Tue, 6 Mar 2012 09:53:15 +0100 (CET) From: Guennadi Liakhovetski <g.liakhovetski@....de> To: Vinod Koul <vinod.koul@...el.com> cc: linux-kernel@...r.kernel.org Subject: Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel() Hi Vinod Thanks for your review. On Tue, 6 Mar 2012, Vinod Koul wrote: > On Fri, 2012-03-02 at 14:21 +0100, Guennadi Liakhovetski wrote: > > Hi Vinod > > > > On Wed, 1 Feb 2012, Guennadi Liakhovetski wrote: > sorry I thought I had replied, but looks like it got missed! > > > > > When performing slame DMA some dmaengine drivers need additional data from > typo ^^^^^^^^^ > > > client drivers to find out, whether they can support that specific client > > > and to configure the DMA channel for it. This additional data has to be > > > supplied by client drivers during channel allocation, i.e., with the > > > __dma_request_channel() function. This patch adds a new > > > struct dma_slave_desc with some basic data in it, further this struct can > > > be embedded in hardware-specific types to supply any auxiliary > > > configuration. > counter arguing shouldn't the client drivers find out of the channel > requested is capable or not, that can be alternate approach as well. > That way people implement this in the filer functions and find if this > is the channel we need rather than dmac finding out if it can service > the client or not. How shall clients find this out? This is system- and DMAC-specific, this has nothing to do with the client functionality. The proposed approach is: * a client driver (MMC, USB, anything else) is capable to use DMA uses the standard dmaengine API to transfer the data * if the platform, where it's running, is supplying any auxiliary data, that it has to pass to the DMAC driver, it can do so, without getting involved in the details, just passing a pointer * the most natural location to do this is IMHO when requesting a DMA channel Now, on sh-mobile platforms you can realistically have around 5 DMAC instances with 2 or 6 channels each, of which, say, 3 controllers are suitable for MMC and 2 are not. How shall the filter function find this out? Call some ugly platform callback? Traverse some platform-specific lists? Or use a fixed channel, thus significantly reducing flexibility? Sorry, none of these options seems very attractive to me. > Frankly I prefer former model, as that way dmacs will present channel > capabilities, and clients can use as they deem fit. > > > > > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@....de> [snip] > > > @@ -948,7 +954,9 @@ int dma_async_device_register(struct dma_device *device); > > > void dma_async_device_unregister(struct dma_device *device); > > > void dma_run_dependencies(struct dma_async_tx_descriptor *tx); > > > struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type); > > > -#define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y) > > > +#define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y, NULL) > > > +#define dma_request_slave_channel(mask, x, y, id) __dma_request_channel(&(mask), \ > > > + x, y, id) > > > > > > /* --- Helper iov-locking functions --- */ > > > > So what are we supposed to do with the slave argument. Is the > expectation that dmacs will parse the parameters in dma_slave_desc and > based on these return the status of .device_alloc_chan_resources? Exactly. If the channel, handed in to the DMAC driver by the dmaengine core for allocation / configuration is suitable for this slave, actions will be performed, otherwise an error will be returned. 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/
Powered by blists - more mailing lists