From: Catalin Marinas <catalin.marinas@arm.com> To: Arnd Bergmann <arnd@arndb.de> Cc: linaro-mm-sig@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC] ARM DMA mapping TODO, v1 Date: Wed, 27 Apr 2011 12:08:28 +0100 [thread overview] Message-ID: <1303902508.15101.21.camel@e102109-lin.cambridge.arm.com> (raw) In-Reply-To: <201104271243.16868.arnd@arndb.de> On Wed, 2011-04-27 at 11:43 +0100, Arnd Bergmann wrote: > On Wednesday 27 April 2011, Catalin Marinas wrote: > > On 21 April 2011 20:29, Arnd Bergmann <arnd@arndb.de> wrote: > > > I think the recent discussions on linaro-mm-sig and the BoF last week > > > at ELC have been quite productive, and at least my understanding > > > of the missing pieces has improved quite a bit. This is a list of > > > things that I think need to be done in the kernel. Please complain > > > if any of these still seem controversial: > > > > > > 1. Fix the arm version of dma_alloc_coherent. It's in use today and > > > is broken on modern CPUs because it results in both cached and > > > uncached mappings. Rebecca suggested different approaches how to > > > get there. > > > > It's not broken since we moved to using Normal non-cacheable memory > > for the coherent DMA buffers (as long as you flush the cacheable alias > > before using the buffer, as we already do). The ARM ARM currently says > > unpredictable for such situations but this is being clarified in > > future updates and the Normal non-cacheable vs cacheable aliases can > > be used (given correct cache maintenance before using the buffer). > > Thanks for that information, I believe a number of people in the > previous discussions were relying on the information from the > documentation. Are you sure that this is not only correct for the > cores made by ARM ltd but also for the other implementations that > may have relied on documentation? It is a clarification in the ARM ARM so it covers all the cores made by architecture licensees, not just ARM Ltd. It basically makes the "unpredictable" part more predictable to allow certain types of aliases (e.g. Strongly Ordered vs Normal memory would still be disallowed). All the current implementations are safe with Normal memory aliases (cacheable vs non-cacheable) but of course, there may be some performance benefits in not having any alias. > As I mentioned before, there are other architectures, where having > conflicting cache settings in TLB entries for the same pysical page > immediately checkstops the CPU, and I guess that this was also allowed > by the current version of the ARM ARM. The current version of the ARM ARM says "unpredictable". But this general definition of "unpredictable" does not allow it to deadlock (hardware) or have security implications. It is however allowed to corrupt data. > > > 2. Implement dma_alloc_noncoherent on ARM. Marek pointed out > > > that this is needed, and it currently is not implemented, with > > > an outdated comment explaining why it used to not be possible > > > to do it. > > > > As Russell pointed out, there are 4 main combinations with iommu and > > some coherency support (i.e. being able to snoop the CPU caches). But > > in an SoC you can have different devices with different iommu and > > coherency configurations. Some of them may even be able to see the L2 > > cache but not the L1 (in which case it would help if we can get an > > inner non-cacheable outer cacheable mapping). > > > > Anyway, we end up with different DMA ops per device via dev_archdata. > > Having different DMA ops per device was the solution that I was suggesting > with dma_mapping_common.h, but Russell pointed out that it may not be > the best option. IMHO, that's the most flexible option. I can't say for sure whether we'll need such flexibility in the future. > The alternative would be to have just one set of dma_mapping functions > as we do today, but to extend the functions to also cover the iommu > case, for instance (example, don't take literally): > > static inline dma_addr_t dma_map_single(struct device *dev, void *cpu_addr, > size_t size, enum dma_data_direction dir) > { > dma_addr_t ret; > > #ifdef CONFIG_DMABOUNCE > if (dev->archdata.dmabounce) > return dmabounce_map_single(dev, cpu_addr, size, dir); > #endif > > #ifdef CONFIG_IOMMU > if (dev->archdata.iommu) > ret = iommu_map_single(dev, cpu_addr, size, dir); > else > #endif > dma_addr = virt_to_dma(dev, ptr); > > dma_sync_single_for_device(dev, dma_addr, size, dir); > } > > This would not even conflict with having a common implementation > for iommu based dma_map_ops -- we would just call the iommu functions > directly when needed rather than having an indirect function call. I don't particularly like having lots of #ifdef's (but we could probably have some macros checking archdata.* to make this cleaner). We also need a way to specify a coherency level as we are getting platforms with devices connected to something like ACP (ARM Coherency Port). -- Catalin
WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas) To: linux-arm-kernel@lists.infradead.org Subject: [RFC] ARM DMA mapping TODO, v1 Date: Wed, 27 Apr 2011 12:08:28 +0100 [thread overview] Message-ID: <1303902508.15101.21.camel@e102109-lin.cambridge.arm.com> (raw) In-Reply-To: <201104271243.16868.arnd@arndb.de> On Wed, 2011-04-27 at 11:43 +0100, Arnd Bergmann wrote: > On Wednesday 27 April 2011, Catalin Marinas wrote: > > On 21 April 2011 20:29, Arnd Bergmann <arnd@arndb.de> wrote: > > > I think the recent discussions on linaro-mm-sig and the BoF last week > > > at ELC have been quite productive, and at least my understanding > > > of the missing pieces has improved quite a bit. This is a list of > > > things that I think need to be done in the kernel. Please complain > > > if any of these still seem controversial: > > > > > > 1. Fix the arm version of dma_alloc_coherent. It's in use today and > > > is broken on modern CPUs because it results in both cached and > > > uncached mappings. Rebecca suggested different approaches how to > > > get there. > > > > It's not broken since we moved to using Normal non-cacheable memory > > for the coherent DMA buffers (as long as you flush the cacheable alias > > before using the buffer, as we already do). The ARM ARM currently says > > unpredictable for such situations but this is being clarified in > > future updates and the Normal non-cacheable vs cacheable aliases can > > be used (given correct cache maintenance before using the buffer). > > Thanks for that information, I believe a number of people in the > previous discussions were relying on the information from the > documentation. Are you sure that this is not only correct for the > cores made by ARM ltd but also for the other implementations that > may have relied on documentation? It is a clarification in the ARM ARM so it covers all the cores made by architecture licensees, not just ARM Ltd. It basically makes the "unpredictable" part more predictable to allow certain types of aliases (e.g. Strongly Ordered vs Normal memory would still be disallowed). All the current implementations are safe with Normal memory aliases (cacheable vs non-cacheable) but of course, there may be some performance benefits in not having any alias. > As I mentioned before, there are other architectures, where having > conflicting cache settings in TLB entries for the same pysical page > immediately checkstops the CPU, and I guess that this was also allowed > by the current version of the ARM ARM. The current version of the ARM ARM says "unpredictable". But this general definition of "unpredictable" does not allow it to deadlock (hardware) or have security implications. It is however allowed to corrupt data. > > > 2. Implement dma_alloc_noncoherent on ARM. Marek pointed out > > > that this is needed, and it currently is not implemented, with > > > an outdated comment explaining why it used to not be possible > > > to do it. > > > > As Russell pointed out, there are 4 main combinations with iommu and > > some coherency support (i.e. being able to snoop the CPU caches). But > > in an SoC you can have different devices with different iommu and > > coherency configurations. Some of them may even be able to see the L2 > > cache but not the L1 (in which case it would help if we can get an > > inner non-cacheable outer cacheable mapping). > > > > Anyway, we end up with different DMA ops per device via dev_archdata. > > Having different DMA ops per device was the solution that I was suggesting > with dma_mapping_common.h, but Russell pointed out that it may not be > the best option. IMHO, that's the most flexible option. I can't say for sure whether we'll need such flexibility in the future. > The alternative would be to have just one set of dma_mapping functions > as we do today, but to extend the functions to also cover the iommu > case, for instance (example, don't take literally): > > static inline dma_addr_t dma_map_single(struct device *dev, void *cpu_addr, > size_t size, enum dma_data_direction dir) > { > dma_addr_t ret; > > #ifdef CONFIG_DMABOUNCE > if (dev->archdata.dmabounce) > return dmabounce_map_single(dev, cpu_addr, size, dir); > #endif > > #ifdef CONFIG_IOMMU > if (dev->archdata.iommu) > ret = iommu_map_single(dev, cpu_addr, size, dir); > else > #endif > dma_addr = virt_to_dma(dev, ptr); > > dma_sync_single_for_device(dev, dma_addr, size, dir); > } > > This would not even conflict with having a common implementation > for iommu based dma_map_ops -- we would just call the iommu functions > directly when needed rather than having an indirect function call. I don't particularly like having lots of #ifdef's (but we could probably have some macros checking archdata.* to make this cleaner). We also need a way to specify a coherency level as we are getting platforms with devices connected to something like ACP (ARM Coherency Port). -- Catalin
next prev parent reply other threads:[~2011-04-27 11:08 UTC|newest] Thread overview: 196+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-04-21 19:29 [RFC] ARM DMA mapping TODO, v1 Arnd Bergmann 2011-04-21 19:29 ` Arnd Bergmann 2011-04-21 20:09 ` [Linaro-mm-sig] " Jesse Barnes 2011-04-21 20:09 ` Jesse Barnes 2011-04-21 21:52 ` Zach Pfeffer 2011-04-21 21:52 ` Zach Pfeffer 2011-04-22 0:34 ` KyongHo Cho 2011-04-22 0:34 ` KyongHo Cho 2011-04-26 14:29 ` Arnd Bergmann 2011-04-26 14:29 ` Arnd Bergmann 2011-04-26 14:28 ` Arnd Bergmann 2011-04-26 14:28 ` Arnd Bergmann 2011-04-26 14:26 ` Arnd Bergmann 2011-04-26 14:26 ` Arnd Bergmann 2011-04-26 15:39 ` Jesse Barnes 2011-04-26 15:39 ` Jesse Barnes 2011-04-27 7:35 ` Russell King - ARM Linux 2011-04-27 7:35 ` Russell King - ARM Linux 2011-04-27 8:56 ` Arnd Bergmann 2011-04-27 8:56 ` Arnd Bergmann 2011-04-27 9:09 ` Russell King - ARM Linux 2011-04-27 9:09 ` Russell King - ARM Linux 2011-04-27 11:02 ` Arnd Bergmann 2011-04-27 11:02 ` Arnd Bergmann 2011-04-27 16:16 ` [Linaro-mm-sig] " Alex Deucher 2011-04-27 16:16 ` Alex Deucher 2011-04-27 17:44 ` Anca Emanuel 2011-04-27 17:44 ` Anca Emanuel 2011-04-27 20:27 ` Russell King - ARM Linux 2011-04-27 20:27 ` Russell King - ARM Linux 2011-04-27 20:16 ` Russell King - ARM Linux 2011-04-27 20:16 ` Russell King - ARM Linux 2011-04-27 20:21 ` Arnd Bergmann 2011-04-27 20:21 ` Arnd Bergmann 2011-04-27 20:26 ` Russell King - ARM Linux 2011-04-27 20:26 ` Russell King - ARM Linux 2011-04-27 20:48 ` Arnd Bergmann 2011-04-27 20:48 ` Arnd Bergmann 2011-04-27 21:41 ` Benjamin Herrenschmidt 2011-04-27 21:41 ` Benjamin Herrenschmidt 2011-04-28 9:30 ` Russell King - ARM Linux 2011-04-28 9:30 ` Russell King - ARM Linux 2011-04-28 21:07 ` Benjamin Herrenschmidt 2011-04-28 21:07 ` Benjamin Herrenschmidt 2011-04-29 11:26 ` Arnd Bergmann 2011-04-29 11:26 ` Arnd Bergmann 2011-04-29 11:47 ` Benjamin Herrenschmidt 2011-04-29 11:47 ` Benjamin Herrenschmidt 2011-04-29 11:56 ` Alan Cox 2011-04-29 11:56 ` Alan Cox 2011-04-29 22:51 ` Benjamin Herrenschmidt 2011-04-29 22:51 ` Benjamin Herrenschmidt 2011-04-29 12:06 ` [Linaro-mm-sig] " Thomas Hellstrom 2011-04-29 12:06 ` Thomas Hellstrom 2011-04-29 13:34 ` Jerome Glisse 2011-04-29 13:34 ` Jerome Glisse 2011-04-29 22:55 ` Benjamin Herrenschmidt 2011-04-29 22:55 ` Benjamin Herrenschmidt 2011-04-29 22:53 ` Benjamin Herrenschmidt 2011-04-29 22:53 ` Benjamin Herrenschmidt 2011-04-27 10:51 ` Marek Szyprowski 2011-04-27 10:51 ` Marek Szyprowski 2011-04-27 21:37 ` Benjamin Herrenschmidt 2011-04-27 21:37 ` Benjamin Herrenschmidt 2011-04-28 6:40 ` [Linaro-mm-sig] " Arnd Bergmann 2011-04-28 6:40 ` Arnd Bergmann 2011-04-28 6:46 ` FUJITA Tomonori 2011-04-28 6:46 ` FUJITA Tomonori 2011-04-28 9:37 ` Russell King - ARM Linux 2011-04-28 9:37 ` Russell King - ARM Linux 2011-04-28 10:32 ` [Linaro-mm-sig] " Marek Szyprowski 2011-04-28 10:32 ` Marek Szyprowski 2011-04-28 10:51 ` Russell King - ARM Linux 2011-04-28 10:51 ` Russell King - ARM Linux 2011-04-28 12:28 ` Arnd Bergmann 2011-04-28 12:28 ` Arnd Bergmann 2011-04-28 13:15 ` Russell King - ARM Linux 2011-04-28 13:15 ` Russell King - ARM Linux 2011-04-28 14:29 ` Arnd Bergmann 2011-04-28 14:29 ` Arnd Bergmann 2011-04-28 14:34 ` Russell King - ARM Linux 2011-04-28 14:34 ` Russell King - ARM Linux 2011-04-28 14:39 ` Arnd Bergmann 2011-04-28 14:39 ` Arnd Bergmann 2011-04-28 14:58 ` Russell King - ARM Linux 2011-04-28 14:58 ` Russell King - ARM Linux 2011-04-28 19:37 ` Jerome Glisse 2011-04-28 19:37 ` Jerome Glisse 2011-04-29 0:29 ` Benjamin Herrenschmidt 2011-04-29 0:29 ` Benjamin Herrenschmidt 2011-04-29 5:50 ` Thomas Hellstrom 2011-04-29 5:50 ` Thomas Hellstrom 2011-04-29 7:35 ` Benjamin Herrenschmidt 2011-04-29 7:35 ` Benjamin Herrenschmidt 2011-04-29 10:55 ` Thomas Hellstrom 2011-04-29 10:55 ` Thomas Hellstrom 2011-04-29 22:50 ` Benjamin Herrenschmidt 2011-04-29 22:50 ` Benjamin Herrenschmidt 2011-04-29 16:27 ` Jesse Barnes 2011-04-29 16:27 ` Jesse Barnes 2011-04-29 22:46 ` Benjamin Herrenschmidt 2011-04-29 22:46 ` Benjamin Herrenschmidt 2011-04-30 2:45 ` Jesse Barnes 2011-04-30 2:45 ` Jesse Barnes 2011-04-29 7:59 ` Russell King - ARM Linux 2011-04-29 7:59 ` Russell King - ARM Linux 2011-04-29 16:32 ` Jesse Barnes 2011-04-29 16:32 ` Jesse Barnes 2011-04-29 18:29 ` Arnd Bergmann 2011-04-29 18:29 ` Arnd Bergmann 2011-04-29 22:15 ` Russell King - ARM Linux 2011-04-29 22:15 ` Russell King - ARM Linux 2011-05-02 4:42 ` David Brown 2011-05-02 4:42 ` David Brown 2011-05-02 11:26 ` Arnd Bergmann 2011-05-02 11:26 ` Arnd Bergmann 2011-04-29 22:37 ` Benjamin Herrenschmidt 2011-04-29 22:37 ` Benjamin Herrenschmidt 2011-04-29 13:42 ` Joerg Roedel 2011-04-29 13:42 ` Joerg Roedel 2011-04-29 14:19 ` Jerome Glisse 2011-04-29 14:19 ` Jerome Glisse 2011-04-29 15:37 ` Jordan Crouse 2011-04-29 15:37 ` Jordan Crouse 2011-04-28 14:38 ` FUJITA Tomonori 2011-04-28 14:38 ` FUJITA Tomonori 2011-04-29 0:25 ` Benjamin Herrenschmidt 2011-04-29 0:25 ` Benjamin Herrenschmidt 2011-04-29 11:21 ` Arnd Bergmann 2011-04-29 11:21 ` Arnd Bergmann 2011-04-28 10:41 ` Joerg Roedel 2011-04-28 10:41 ` Joerg Roedel 2011-04-28 11:01 ` Russell King - ARM Linux 2011-04-28 11:01 ` Russell King - ARM Linux 2011-04-28 12:25 ` Joerg Roedel 2011-04-28 12:25 ` Joerg Roedel 2011-04-28 12:42 ` Russell King - ARM Linux 2011-04-28 12:42 ` Russell King - ARM Linux 2011-04-28 12:59 ` Joerg Roedel 2011-04-28 12:59 ` Joerg Roedel 2011-04-28 13:02 ` Arnd Bergmann 2011-04-28 13:02 ` Arnd Bergmann 2011-04-28 13:19 ` Russell King - ARM Linux 2011-04-28 13:19 ` Russell King - ARM Linux 2011-04-28 13:56 ` Joerg Roedel 2011-04-28 13:56 ` Joerg Roedel 2011-04-28 14:30 ` Russell King - ARM Linux 2011-04-28 14:30 ` Russell King - ARM Linux 2011-04-27 9:52 ` Catalin Marinas 2011-04-27 9:52 ` Catalin Marinas 2011-04-27 10:43 ` Arnd Bergmann 2011-04-27 10:43 ` Arnd Bergmann 2011-04-27 11:08 ` Catalin Marinas [this message] 2011-04-27 11:08 ` Catalin Marinas 2011-04-28 0:15 ` Valdis.Kletnieks 2011-04-28 0:15 ` Valdis.Kletnieks at vt.edu 2011-04-28 8:27 ` Catalin Marinas 2011-04-28 8:27 ` Catalin Marinas 2011-04-28 12:12 ` Arnd Bergmann 2011-04-28 12:12 ` Arnd Bergmann 2011-04-28 12:36 ` Russell King - ARM Linux 2011-04-28 12:36 ` Russell King - ARM Linux 2011-04-28 12:48 ` Arnd Bergmann 2011-04-28 12:48 ` Arnd Bergmann 2011-05-03 14:45 ` Dave Martin 2011-05-03 14:45 ` Dave Martin 2011-04-29 15:41 ` [Linaro-mm-sig] " Arnd Bergmann 2011-04-29 15:41 ` Arnd Bergmann 2011-04-29 16:42 ` Catalin Marinas 2011-04-29 16:42 ` Catalin Marinas 2011-05-03 15:05 ` [Linaro-mm-sig] " Laurent Pinchart 2011-05-03 15:05 ` Laurent Pinchart 2011-05-03 15:31 ` Arnd Bergmann 2011-05-03 15:31 ` Arnd Bergmann 2011-04-27 14:06 ` FUJITA Tomonori 2011-04-27 14:06 ` FUJITA Tomonori 2011-04-27 14:29 ` Catalin Marinas 2011-04-27 14:29 ` Catalin Marinas 2011-04-27 14:34 ` FUJITA Tomonori 2011-04-27 14:34 ` FUJITA Tomonori 2011-04-27 20:29 ` Russell King - ARM Linux 2011-04-27 20:29 ` Russell King - ARM Linux 2011-04-27 21:45 ` Benjamin Herrenschmidt 2011-04-27 21:45 ` Benjamin Herrenschmidt 2011-04-28 7:24 ` [Linaro-mm-sig] " KyongHo Cho 2011-04-28 7:24 ` KyongHo Cho 2011-04-28 8:31 ` Catalin Marinas 2011-04-28 8:31 ` Catalin Marinas 2011-04-27 21:31 ` Benjamin Herrenschmidt 2011-04-27 21:31 ` Benjamin Herrenschmidt 2011-04-28 9:42 ` Russell King - ARM Linux 2011-04-28 9:42 ` Russell King - ARM Linux 2011-04-28 10:27 ` Joerg Roedel 2011-04-28 10:27 ` Joerg Roedel 2011-04-28 12:15 ` Arnd Bergmann 2011-04-28 12:15 ` Arnd Bergmann
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=1303902508.15101.21.camel@e102109-lin.cambridge.arm.com \ --to=catalin.marinas@arm.com \ --cc=arnd@arndb.de \ --cc=linaro-mm-sig@lists.linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.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.