From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> To: Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> Cc: "arnd-r2nGTMty4D4@public.gmane.org" <arnd-r2nGTMty4D4@public.gmane.org>, "stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org" <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>, Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>, "josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org" <josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>, Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>, "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>, "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>, "thunder.leizhen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org" <thunder.leizhen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>, Yingjoe Chen <yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>, Yong Wu <yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> Subject: Re: [RFC PATCH v2 2/3] arm64: add IOMMU dma_ops Date: Tue, 10 Mar 2015 10:16:31 +0000 [thread overview] Message-ID: <54FEC47F.2040804@arm.com> (raw) In-Reply-To: <54FDFE0D.8030807-5wv7dgnIgG8@public.gmane.org> On 09/03/15 20:09, Robin Murphy wrote: [...] >>> I think ideally you'd call dma_map_page when you first create the page >>> table, dma_sync_single_for_device on any update, and dma_unmap_page when you >>> tear it down, and you'd also use the appropriate DMA addresses everywhere >>> instead of physical addresses. >> >> No. >> >> dma_map_page() ownership changes CPU->DMA >> dma_sync_single_for_cpu() ownership changes DMA->CPU >> dma_sync_single_for_device() ownership changes CPU->DMA >> dma_unmap_page() ownership changes DMA->CPU >> >> It's invalid to miss out the pairing that give those ownership changes. > > Thanks for the clarification - the wording in DMA-API.txt rather implies > that in the DMA_TO_DEVICE case you only have to sync the updated data > /after/ writing it. For the sake of purely getting pages flushed, would > it be more reasonable then to call dma_map_single() followed immediately > by dma_unmap_single_attrs() with DMA_ATTR_SKIP_CPU_SYNC? Since we know > the IOMMU can never write back to memory (ones that can are a different > issue) it would be nice to be able to skip the extra invalidations > somehow, without too heinously abusing the API. Scratch that, I'm being a massive idiot (again). Of course the actual invalidations will only happen if they need to, based on the DMA direction. The overhead of dma_sync_*_for_cpu() and dma_unmap() is then only a handful of function calls, which is probably an acceptable price to pay for making sure things work as correctly as possible. > > Robin. > > _______________________________________________ > iommu mailing list > iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu >
WARNING: multiple messages have this Message-ID (diff)
From: robin.murphy@arm.com (Robin Murphy) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH v2 2/3] arm64: add IOMMU dma_ops Date: Tue, 10 Mar 2015 10:16:31 +0000 [thread overview] Message-ID: <54FEC47F.2040804@arm.com> (raw) In-Reply-To: <54FDFE0D.8030807@arm.com> On 09/03/15 20:09, Robin Murphy wrote: [...] >>> I think ideally you'd call dma_map_page when you first create the page >>> table, dma_sync_single_for_device on any update, and dma_unmap_page when you >>> tear it down, and you'd also use the appropriate DMA addresses everywhere >>> instead of physical addresses. >> >> No. >> >> dma_map_page() ownership changes CPU->DMA >> dma_sync_single_for_cpu() ownership changes DMA->CPU >> dma_sync_single_for_device() ownership changes CPU->DMA >> dma_unmap_page() ownership changes DMA->CPU >> >> It's invalid to miss out the pairing that give those ownership changes. > > Thanks for the clarification - the wording in DMA-API.txt rather implies > that in the DMA_TO_DEVICE case you only have to sync the updated data > /after/ writing it. For the sake of purely getting pages flushed, would > it be more reasonable then to call dma_map_single() followed immediately > by dma_unmap_single_attrs() with DMA_ATTR_SKIP_CPU_SYNC? Since we know > the IOMMU can never write back to memory (ones that can are a different > issue) it would be nice to be able to skip the extra invalidations > somehow, without too heinously abusing the API. Scratch that, I'm being a massive idiot (again). Of course the actual invalidations will only happen if they need to, based on the DMA direction. The overhead of dma_sync_*_for_cpu() and dma_unmap() is then only a handful of function calls, which is probably an acceptable price to pay for making sure things work as correctly as possible. > > Robin. > > _______________________________________________ > iommu mailing list > iommu at lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu >
next prev parent reply other threads:[~2015-03-10 10:16 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-02-06 14:55 [RFC PATCH v2 0/3] arm64: IOMMU-backed DMA mapping Robin Murphy 2015-02-06 14:55 ` Robin Murphy [not found] ` <cover.1423226542.git.robin.murphy-5wv7dgnIgG8@public.gmane.org> 2015-02-06 14:55 ` [RFC PATCH v2 1/3] iommu: implement common IOMMU ops for " Robin Murphy 2015-02-06 14:55 ` Robin Murphy [not found] ` <da0e905ae94f2fca241a47b2a20e078255e45a81.1423226542.git.robin.murphy-5wv7dgnIgG8@public.gmane.org> 2015-02-09 4:05 ` Will Deacon 2015-02-09 4:05 ` Will Deacon [not found] ` <20150209040539.GE13969-5wv7dgnIgG8@public.gmane.org> 2015-02-10 15:11 ` Robin Murphy 2015-02-10 15:11 ` Robin Murphy 2015-03-12 12:45 ` Marek Szyprowski 2015-03-12 12:45 ` Marek Szyprowski 2015-02-06 14:55 ` [RFC PATCH v2 2/3] arm64: add IOMMU dma_ops Robin Murphy 2015-02-06 14:55 ` Robin Murphy [not found] ` <058e038009ac708a40197c80e07410914c2a162e.1423226542.git.robin.murphy-5wv7dgnIgG8@public.gmane.org> 2015-02-09 6:02 ` Will Deacon 2015-02-09 6:02 ` Will Deacon [not found] ` <20150209060224.GG13969-5wv7dgnIgG8@public.gmane.org> 2015-02-10 15:40 ` Robin Murphy 2015-02-10 15:40 ` Robin Murphy 2015-02-10 4:39 ` Yingjoe Chen 2015-02-10 4:39 ` Yingjoe Chen 2015-02-10 12:07 ` Robin Murphy 2015-02-10 12:07 ` Robin Murphy [not found] ` <54D9F486.10501-5wv7dgnIgG8@public.gmane.org> 2015-02-14 8:03 ` Yong Wu 2015-02-14 8:03 ` Yong Wu 2015-02-16 20:04 ` Robin Murphy 2015-02-16 20:04 ` Robin Murphy 2015-03-03 3:38 ` Yong Wu 2015-03-03 3:38 ` Yong Wu 2015-03-03 12:15 ` Robin Murphy 2015-03-03 12:15 ` Robin Murphy [not found] ` <54F5A5FE.3040506-5wv7dgnIgG8@public.gmane.org> 2015-03-05 0:19 ` Laura Abbott 2015-03-05 0:19 ` Laura Abbott [not found] ` <54F7A121.3050103-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2015-03-05 11:16 ` Robin Murphy 2015-03-05 11:16 ` Robin Murphy 2015-03-09 17:59 ` Russell King - ARM Linux 2015-03-09 17:59 ` Russell King - ARM Linux [not found] ` <20150309175904.GC8656-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2015-03-09 20:09 ` Robin Murphy 2015-03-09 20:09 ` Robin Murphy [not found] ` <54FDFE0D.8030807-5wv7dgnIgG8@public.gmane.org> 2015-03-10 10:16 ` Robin Murphy [this message] 2015-03-10 10:16 ` Robin Murphy 2015-03-12 12:50 ` Marek Szyprowski 2015-03-12 12:50 ` Marek Szyprowski 2015-02-06 14:55 ` [RFC PATCH v2 3/3] arm64: hook up " Robin Murphy 2015-02-06 14:55 ` Robin Murphy [not found] ` <482b3b109a3d4818b1b1e693f488a919cf1bb707.1423226542.git.robin.murphy-5wv7dgnIgG8@public.gmane.org> 2015-03-03 11:05 ` leizhen 2015-03-03 11:05 ` leizhen [not found] ` <54F59565.7000807-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> 2015-03-03 13:10 ` Robin Murphy 2015-03-03 13:10 ` Robin Murphy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=54FEC47F.2040804@arm.com \ --to=robin.murphy-5wv7dgnigg8@public.gmane.org \ --cc=Catalin.Marinas-5wv7dgnIgG8@public.gmane.org \ --cc=Will.Deacon-5wv7dgnIgG8@public.gmane.org \ --cc=arnd-r2nGTMty4D4@public.gmane.org \ --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \ --cc=josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \ --cc=stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org \ --cc=thunder.leizhen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \ --cc=yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \ --cc=yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.