[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20090731.125852.229722391.anemo@mba.ocn.ne.jp>
Date: Fri, 31 Jul 2009 12:58:52 +0900 (JST)
From: Atsushi Nemoto <anemo@....ocn.ne.jp>
To: dan.j.williams@...el.com
Cc: maciej.sosnowski@...el.com, haavard.skinnemoen@...el.com,
nicolas.ferre@...el.com, linux-arm-kernel@...ts.arm.linux.org.uk,
patrice.vilchez@...el.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dmaengine: at_hdmac: add DMA slave transfers
On Wed, 29 Jul 2009 07:27:59 -0700, Dan Williams <dan.j.williams@...el.com> wrote:
> > Then, what should dma driver do when client driver did not set these
> > flags? If it should call dma_unmap_sg(), the dma driver should keep
> > sg and direction somewhere...
> >
> > Also, calling dma_map_sg() in its prep_slave_sg function will not fit
> > for sound drivers, which use DMA buffers prepared in its framework.
> >
> > For slave DMA, doing all mapping/unmapping in DMA client is better,
> > isn't it?
>
> Yes it is. The whole point of the dma driver doing its own unmapping is
> specifically for clients that use the async_tx api, i.e. where they do
> not know if the transaction is carried out in hardware and have no way
> of tracking the details necessary to perform the unmap. DMA-slave
> clients request specific channels and know the hardware details at a low
> level, so it should not be too high an expectation to push dma mapping
> responsibility to the client.
OK, I will send a patch to move all map_sg/unmap_sg for slave channel
to its client. Affected drivers are at_hdmac, dw_dmac and atmel-mci.
I do not have any of them, I hope someone who have them can test it.
Thank you.
---
Atsushi Nemoto
--
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