[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <129600E5E5FB004392DDC3FB599660D7B2980817@irsmsx504.ger.corp.intel.com>
Date: Wed, 29 Jul 2009 14:05:17 +0100
From: "Sosnowski, Maciej" <maciej.sosnowski@...el.com>
To: Atsushi Nemoto <anemo@....ocn.ne.jp>
CC: "haavard.skinnemoen@...el.com" <haavard.skinnemoen@...el.com>,
"nicolas.ferre@...el.com" <nicolas.ferre@...el.com>,
"Williams, Dan J" <dan.j.williams@...el.com>,
"linux-arm-kernel@...ts.arm.linux.org.uk"
<linux-arm-kernel@...ts.arm.linux.org.uk>,
"patrice.vilchez@...el.com" <patrice.vilchez@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] dmaengine: at_hdmac: add DMA slave transfers
Atsushi Nemoto wrote:
> On Mon, 27 Jul 2009 14:24:26 +0100, "Sosnowski, Maciej" <maciej.sosnowski@...el.com> wrote:
>>>> Your atc_chain_complete() calls dma_unmap_xxx unless
>>>> DMA_COMPL_SKIP_XXX_UNMAP specified. But atmel-mci driver does not set
>>>> the flag on dma_async_tx_descriptor. I suppose one of them should be
>>>> fixed.
>>>
>>> atmel-mci should definitely set that flag.
>>>
>>> Haavard
>>
>> I agree with Haavard.
>
> 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...
Well, what about BUG_ON?
>
> 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.
It looks like a need for one more flag: DMA_SKIP_MAP_SG.
What do you think?
Regards,
Maciej
--
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