[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120116105448.GT1068@n2100.arm.linux.org.uk>
Date: Mon, 16 Jan 2012 10:54:48 +0000
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Viresh Kumar <viresh.kumar@...com>
Cc: vinod.koul@...el.com, dan.j.williams@...el.com,
pratyush.anand@...com, rajeev-dlh.kumar@...com,
bhupesh.sharma@...com, armando.visconti@...com,
linus.walleij@...aro.org, mirko.gardi@...com,
linux-kernel@...r.kernel.org, vipin.kumar@...com,
shiraz.hashim@...com, amit.virdi@...com, vipulkumar.samar@...com,
viresh.linux@...il.com, deepak.sikri@...com, bhavna.yadav@...com,
linux-arm-kernel@...ts.infradead.org, vincenzo.frascino@...com
Subject: Re: [PATCH 7/8] dmaengine/dw_dmac: Unmap all memory buffers after
completion of slave transfers
On Mon, Jan 16, 2012 at 03:20:35PM +0530, Viresh Kumar wrote:
> Currently, after completion of transfer, source address or destination address
> of only the first LLI descriptor is unmapped. And length passed for unmap is
> total length of all descriptors in the list. Which means unmapping code assumed
> that the memory buffers pointed to by the descriptors will be physically
> contiguous, which might not be the case. It is possible for other drivers to
> pass sglist to slave_sg(), in which all buffers are scattered throughout the
> memory.
>
> This patch intends to fix this wrong expectation of dw_dmac. Now, first desc
> will not contain total length of transfer. But individual descriptors will
> contain their individual lengths. Finally, we will call unmap for all
> descriptors.
Note that DMA engine drivers are not responsible for unmapping the buffers
when the transfer completes - that is the responsibility of the caller.
The automatic buffer unmapping is required for the async_tx APIs and
offload APIs.
--
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