ARM : OMAP: Pass logical DMA channel number always to callback handlers
Hi Jarkko\Tony , Recently during some debugging, I observed this patch. http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=538528de0cb256f65716ab2e9613d9e920f97fe2;hp=29e8c3c304b62f31b799565c9ee85d42bd163f80 As per your description,it improves the debugging. Can you elaborate more on this ? For users this change is little confusing, if they go as per the signatures of the 'omap_request_dma_chain' and 'omap_request_dma' APIs. Also separating the callbacks for chained and non-chained transfers seems to be the practical usage in most of the cases. Also users would be only interested in 'chain_id' and not 'channel number' in case of chaining. So if it improves only debugging and some what complicates the usage, I suggest we should revert this patch. Regards, Santosh Shilimkar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM : OMAP: Pass logical DMA channel number always to callback handlers
On Wed, 26 Nov 2008 14:43:02 +0530 ext Shilimkar, Santosh [EMAIL PROTECTED] wrote: Hi Jarkko\Tony , Recently during some debugging, I observed this patch. http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=538528de0cb256f65716ab2e9613d9e920f97fe2;hp=29e8c3c304b62f31b799565c9ee85d42bd163f80 As per your description,it improves the debugging. Can you elaborate more on this ? Honestly don't remember what I meant for easier debugging, probably just watching how the logical channels are rotating during the transfer or something like that. For users this change is little confusing, if they go as per the signatures of the 'omap_request_dma_chain' and 'omap_request_dma' APIs. Also separating the callbacks for chained and non-chained transfers seems to be the practical usage in most of the cases. Also users would be only interested in 'chain_id' and not 'channel number' in case of chaining. As commit log says, user can pass the chain_id via callback data if needed. I think chained dma callback may also find more use for logical channel number than chain_id e.g. when modifying the transfer parameters etc. And uniform, smaller API set is always better than bloated one. Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM : OMAP: Pass logical DMA channel number always to callback handlers
On Wed, 26 Nov 2008 16:26:42 +0530 ext Shilimkar, Santosh [EMAIL PROTECTED] wrote: As commit log says, user can pass the chain_id via callback data if needed. Yes there are few ways you can achieve this if you don't want to pass the chain_id as part of the callback. But in that case the 'omap_request_dma_chain' callback signature should have been also cleaned ( 'ch' instead of 'chain_id'). Ah, yeah, then it was missing from my patch and have to send a patch changing it. I think chained dma callback may also find more use for logical channel number than chain_id e.g. when modifying the transfer parameters etc. When user wants to use chaining,they expects that the chain internals ( free channel allocation etc) should be managed by DMA library. So even user wants to modify the parameters, it can directly use 'omap_modify_dma_chain_params' api and just provide 'chain_id'. For which channel the parameters should be changed will be decided by the DMA library internally depending on free channels from chain. This approach doesn't work e.g. with audio. Let's assume you would like to use DMA chaining with ALSA (been there, done that, until found a better solution. See sound/soc/omap-pcm.c). ALSA application may ask to use e.g. 100 periods, which is more than n.o. logical DMA channels in OMAP so chain length is have to be shorter than n.o. periods. Which then means that channel parameters are have to modify while the chain is running. omap_modify_dma_chain_params is setting parameters for all channels in a chain, and more over, function header of it says Dont do this while dma is running!!. And uniform, smaller API set is always better than bloated one. This change any way don't reduce a single API so not sure what you mean by 'smaller API set is always better than bloated one'. It may reduce a callback for a user in IMO, API is a one step bigger if DMA callback has different arguments depending is it in non-chained vs. chained configuration. So I still don't see a real benefit of this patch. Because of above mentioned reasons I think we should revert this patch. Probably you would like to show/share opposite example? Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
