On Wed, Mar 18, 2015 at 10:03:13PM +0530, Vinod Koul wrote: > On Tue, Mar 17, 2015 at 11:30:11AM +0100, Maxime Ripard wrote: > > > > I think we should really stop treating async_tx as a special case. > > > > > > It would be good and simpler but there are quite a bit differenace which > > > cause this assumption to stand out. For me the prominent among them is > > > buffer mapping. For slave-dma we expect client to map the buffers, but > > > async api relies on dmaengine to do the mapping. > > > > So, for a single user, we keep such undocumented and obscure cases? > > > > Wouldn't it make sense to fix that user instead, to have a clear and > > consistent behaviour? And that wouldn't introduce more code, just move > > it around. > > Well async_tx is not undocumented, see Documentation/crypto/async-tx-api.txt We can argue for quite some time, but the fact that this thread even started in the first place shows that there's clearly some lack of documentation somewhere. > > > > It just creates a combination of confusion (like seen above), > > > > brokenness (DMA_PRIVATE), and duplicated code (dma_find_channel vs > > > > dma_request_channel). > > > > > > > > If we need some features for async_tx, let's had it to the framework, > > > > and make it available to all the cases. This will make things better > > > > for everyone. > > > Bringing additional features is ok, but brining needs to justify why it > > > can't be done with current API. > > > > My point wasn't really that we wanted new features, but rather that > > existing features should be applicable to anybody. > > > > We might very well encounter cases (just like the one that started > > this thread) that need the exact same feature for the slave devices. > > The origin of dmaengine was for memory and slave was an after thought, so > yes there are subtle differences between the two which are more due to the > fact that the needs for slave and memcpy are quite different I'm quite aware of that. But maybe we should start to change that, and really make async_tx what it's should be aiming for: providing an easy way to abstract memory to memory transfers, disregarding whether you have a dmaengine driver or not. > Yes making common API and uniform behaviour does help, but we are not > there today. I'm not saying this is something that we should get rid of today, but start to aim at removing the async_tx special case in dmaengine. > Dan was supposed to remove async_tx. Net dma is already removed, so > slowly we will chip away not needed stuff and then rest of the bits > will be made consistent. That is certainly the goal here And I'm not even saying we should get rid of async_tx. The fact that it has a software fallback makes it really convenient, but we should aim at removing the async_tx priviledges. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Attachment:
signature.asc
Description: Digital signature
