From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [PATCH v3 5/6] iommu/mediatek: Add mt8173 IOMMU driver Date: Wed, 29 Jul 2015 11:31:50 +0100 Message-ID: <20150729103150.GB4797@arm.com> References: <1437037475-9065-1-git-send-email-yong.wu@mediatek.com> <1437037475-9065-6-git-send-email-yong.wu@mediatek.com> <55B630CE.4050803@arm.com> <20150727153148.GJ7557@n2100.arm.linux.org.uk> <55B6530A.9050903@arm.com> <1438148491.25925.89.camel@mhfsdcap03> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1438148491.25925.89.camel@mhfsdcap03> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Yong Wu Cc: Mark Rutland , Catalin Marinas , "cloud.chou-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org" , "youhua.li-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org" , Russell King - ARM Linux , "frederic.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org" , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "arnd-r2nGTMty4D4@public.gmane.org" , Tomasz Figa , Rob Herring , "linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Matthias Brugger , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "pebolle-IWqWACnzNjzz+pZb47iToQ@public.gmane.org" , Thierry Reding , "srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , iommu-cunTk1MwBs9QetFLy7KEm77oxUfYCNXn@public.gmane.org List-Id: devicetree@vger.kernel.org On Wed, Jul 29, 2015 at 06:41:31AM +0100, Yong Wu wrote: > On Mon, 2015-07-27 at 16:49 +0100, Robin Murphy wrote: > > On 27/07/15 16:31, Russell King - ARM Linux wrote: > > > On Mon, Jul 27, 2015 at 02:23:26PM +0100, Robin Murphy wrote: > > >> On 16/07/15 10:04, Yong Wu wrote: > > >>> This patch adds support for mediatek m4u (MultiMedia Memory Management > > >>> Unit). > > >>> > > >>> Signed-off-by: Yong Wu > > >> [...] > > >>> +static void mtk_iommu_flush_pgtable(void *ptr, size_t size, void *cookie) > > >>> +{ > > >>> + struct mtk_iommu_domain *domain = cookie; > > >>> + unsigned long offset = (unsigned long)ptr & ~PAGE_MASK; > > >>> + > > >>> + dma_map_page(domain->data->dev, virt_to_page(ptr), offset, > > >>> + size, DMA_TO_DEVICE); > > >> > > >> Nit: this looks like it may as well be dma_map_single. > > >> > > >> It would probably be worth following it with a matching unmap too, just to > > >> avoid any possible leakage bugs (especially if this M4U ever appears in a > > >> SoC supporting RAM above the 32-bit boundary). > > > > > > Why not do the job properly? Take a look at how I implemented the > > > streaming DMA API on Tegra SMMU (patch set recently sent out earlier > > > today). > > > > > > There's no need for hacks like dma_map_page() (and discarding it's > > > return value) or dma_map_page() followed by dma_unmap_page(). > > > > Indeed, as it happens I do have a branch where I prototyped that for the > > long-descriptor io-pgtable-arm code a while ago; this discussion has > > prompted me to dig it up again. Stay tuned, folks... > > Hi Russell, Robin, > > From I see in arm-smmu-v3.c in v4.2-rc1, > > The flush_pgtable seems like this: > //========== > dma_addr_t dma_addr; > > dma_addr = dma_map_page(dev, ptr, size, DMA_TO_DEVICE); > > if (dma_mapping_error(dev, dma_addr)) > dev_err(dev, "failed to flush pgtable at %p\n", ptr); > else > dma_unmap_page(dev, dma_addr, size, DMA_TO_DEVICE); > //========== > I will change map like this and use dma_map_single instead. > > Is this also seems to be not proper? > > Then how to do it? add this before unmap? : > dma_sync_single_for_device(dev, dma_addr, size, DMA_TO_DEVICE); Robin's proposed a series fixing this in the io-pgtable code: http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013821.html which is currently under review. Please take a look and give comments! Once merged, the code you cite above will be removed. Will