Re: [RFC v2 0/5] dmaengine: Slave DMA interface and example users

[Haavard Skinnemoen]

On Tue, 29 Jan 2008 19:10:08 +0100
Haavard Skinnemoen <hskinnemoen@xxxxxxxxx> wrote:

> This patch series adds the necessary interfaces to the DMA Engine
> framework to use functionality found on most embedded DMA controllers:
> DMA from and to I/O registers with hardware handshaking.

Btw, there's one issue I forgot to mention: I believe the DMA Engine
framework is currently misusing the DMA mapping API, and this patchset
makes things worse.

Currently, the async_tx bits of the API do the required calls to
dma_map_single() and/or dma_map_page(), but they rely on the driver to
do the unmapping. This is problematic since the driver doesn't have a
clue about whether it should use dma_unmap_single(), dma_unmap_page()
or something else.

The MMC driver I posted as a part of this series gets a scatterlist
from the MMC core, so it needs to use dma_map_sg() / dma_unmap_sg(). To
make this work, I decided not to do any unmapping in the DMA driver and
do the necessary dma_unmap_sg() from the DMA completion callback in the
MMC driver. Thus, for the normal async_tx operations, the buffers
aren't unmapped at all when using the dw_dmac driver. Since the
dma_unmap calls are no-ops on avr32, this doesn't have any consequences
for me in practice, but I want to use the DMA mapping API correctly
somehow.

Also, clients may want to just sync the buffer and reuse it. They can't
do that if the DMA engine driver unmaps the buffer on completion.

How do we solve this?

Haavard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/