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 > > > > 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 Yes making common API and uniform behaviour does help, but we are not there today. 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 Thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
