* [PATCH] Add support for CONFIG_ARM64_DMA_USE_IOMMU. [not found] <1422379495-10268-1-git-send-email-stripathi@apm.com> @ 2015-01-28 11:27 ` Catalin Marinas [not found] ` <CAOHikRCSoijzZ8oKEtMadEHOvLiWLO6fWkqiGEiPyb+Egb_1rw@mail.gmail.com> 0 siblings, 1 reply; 5+ messages in thread From: Catalin Marinas @ 2015-01-28 11:27 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jan 27, 2015 at 05:24:54PM +0000, Suman Tripathi wrote: > This patch implements the support for ARM64_DMA_USE_IOMMU > ported from ARM 32-bit. > > Signed-off-by: Suman Tripathi <stripathi@apm.com> > --- > > Suman Tripathi (1): > arm64: dma-mapping: Support for ARM64_DMA_USE_IOMMU. > > arch/arm64/Kconfig | 24 ++ > arch/arm64/include/asm/device.h | 9 + > arch/arm64/include/asm/dma-iommu.h | 48 +++ > arch/arm64/mm/dma-mapping.c | 611 +++++++++++++++++++++++++++++++++++++ > 4 files changed, 692 insertions(+) > create mode 100644 arch/arm64/include/asm/dma-iommu.h I guess there is an overlap with this thread: http://thread.gmane.org/gmane.linux.kernel.iommu/8213 I would rather go for a more generic solution that Robin (cc'ed) is trying to implement. -- Catalin ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <CAOHikRCSoijzZ8oKEtMadEHOvLiWLO6fWkqiGEiPyb+Egb_1rw@mail.gmail.com>]
* [PATCH] Add support for CONFIG_ARM64_DMA_USE_IOMMU. [not found] ` <CAOHikRCSoijzZ8oKEtMadEHOvLiWLO6fWkqiGEiPyb+Egb_1rw@mail.gmail.com> @ 2015-03-17 23:33 ` Suman Tripathi 2015-03-22 1:31 ` Arnd Bergmann 0 siblings, 1 reply; 5+ messages in thread From: Suman Tripathi @ 2015-03-17 23:33 UTC (permalink / raw) To: linux-arm-kernel I guess there is an overlap with this thread: http://thread.gmane.org/gmane.linux.kernel.iommu/8213 I would rather go for a more generic solution that Robin (cc'ed) is trying to implement. I followed the above thread but our requirement deviates from normal IOMMU conventions. For our case we need a 1:1 mapping of PA to IOVA. Actually our's is not a real IOMMU (ie not having a cap of page table walk). It's a simple 32-bit from (device side ) ot 64-bit (cpu side) address translation with the help of a set of window registers. So we want to bypass the entire iova . Any suggestions on this ? On Wed, Mar 18, 2015 at 5:02 AM, Suman Tripathi <stripathi@apm.com> wrote: > I guess there is an overlap with this thread: > > http://thread.gmane.org/gmane.linux.kernel.iommu/8213 > > I would rather go for a more generic solution that Robin (cc'ed) is > trying to implement. > > I followed the above thread but our requirement deviates from normal IOMMU > conventions. > For our case we need a 1:1 mapping of PA to IOVA. Actually our's is not a > real IOMMU (ie not having a cap of page table walk). It's a simple 32-bit > from (device side ) ot 64-bit (cpu side) address translation with the help > of a set of window registers. So we want to bypass the entire iova . > > Any suggestions on this ? > > On Wed, Jan 28, 2015 at 4:57 PM, Catalin Marinas <catalin.marinas@arm.com> > wrote: >> >> On Tue, Jan 27, 2015 at 05:24:54PM +0000, Suman Tripathi wrote: >> > This patch implements the support for ARM64_DMA_USE_IOMMU >> > ported from ARM 32-bit. >> > >> > Signed-off-by: Suman Tripathi <stripathi@apm.com> >> > --- >> > >> > Suman Tripathi (1): >> > arm64: dma-mapping: Support for ARM64_DMA_USE_IOMMU. >> > >> > arch/arm64/Kconfig | 24 ++ >> > arch/arm64/include/asm/device.h | 9 + >> > arch/arm64/include/asm/dma-iommu.h | 48 +++ >> > arch/arm64/mm/dma-mapping.c | 611 >> > +++++++++++++++++++++++++++++++++++++ >> > 4 files changed, 692 insertions(+) >> > create mode 100644 arch/arm64/include/asm/dma-iommu.h >> >> I guess there is an overlap with this thread: >> >> http://thread.gmane.org/gmane.linux.kernel.iommu/8213 >> >> I would rather go for a more generic solution that Robin (cc'ed) is >> trying to implement. >> >> -- >> Catalin > > > > > -- > Thanks, > with regards, > Suman Tripathi -- Thanks, with regards, Suman Tripathi ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] Add support for CONFIG_ARM64_DMA_USE_IOMMU. 2015-03-17 23:33 ` Suman Tripathi @ 2015-03-22 1:31 ` Arnd Bergmann 2015-03-23 15:58 ` Suman Tripathi 0 siblings, 1 reply; 5+ messages in thread From: Arnd Bergmann @ 2015-03-22 1:31 UTC (permalink / raw) To: linux-arm-kernel On Wednesday 18 March 2015, Suman Tripathi wrote: > I guess there is an overlap with this thread: > > http://thread.gmane.org/gmane.linux.kernel.iommu/8213 > > I would rather go for a more generic solution that Robin (cc'ed) is > trying to implement. > > I followed the above thread but our requirement deviates from normal > IOMMU conventions. > For our case we need a 1:1 mapping of PA to IOVA. Actually our's is > not a real IOMMU (ie not having a cap of page table walk). It's a > simple 32-bit from (device side ) ot 64-bit (cpu side) address > translation with the help of a set of window registers. So we want to > bypass the entire iova . > > Any suggestions on this ? My first suggestion would be to separate this from IOMMU support completely as you don't really have an IOMMU. The easiest way to deal with hardware like this is to use swiotlb with a fixed mapping. This is also the only way to deal with any devices that may have multiple outstanding DMAs (PCI, SATA, USB, ...). If you have any high-speed devices that only do a single request at a time connected to this remapper, I would suggest you implement your own set of dma_map_ops and come back with performance data showing whether it's worth merging this compared to the trivial iommu support. Arnd ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] Add support for CONFIG_ARM64_DMA_USE_IOMMU. 2015-03-22 1:31 ` Arnd Bergmann @ 2015-03-23 15:58 ` Suman Tripathi 2015-04-10 21:53 ` Arnd Bergmann 0 siblings, 1 reply; 5+ messages in thread From: Suman Tripathi @ 2015-03-23 15:58 UTC (permalink / raw) To: linux-arm-kernel My first suggestion would be to separate this from IOMMU support completely as you don't really have an IOMMU. The easiest way to deal with hardware like this is to use swiotlb with a fixed mapping. This is also the only way to deal with any devices that may have multiple outstanding DMAs (PCI, SATA, USB, ...). I guess you are talking about the swiotlb force idea ? That's really good but I think we should make configuring swiotlb force per device otherwise it applies to all devices ?? If you have any high-speed devices that only do a single request at a time connected to this remapper, I would suggest you implement your own set of dma_map_ops and come back with performance data showing whether it's worth merging this compared to the trivial iommu support. Ok. I will make a NON-TRIVIAL IOMMU support . On Sun, Mar 22, 2015 at 7:01 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Wednesday 18 March 2015, Suman Tripathi wrote: >> I guess there is an overlap with this thread: >> >> http://thread.gmane.org/gmane.linux.kernel.iommu/8213 >> >> I would rather go for a more generic solution that Robin (cc'ed) is >> trying to implement. >> >> I followed the above thread but our requirement deviates from normal >> IOMMU conventions. >> For our case we need a 1:1 mapping of PA to IOVA. Actually our's is >> not a real IOMMU (ie not having a cap of page table walk). It's a >> simple 32-bit from (device side ) ot 64-bit (cpu side) address >> translation with the help of a set of window registers. So we want to >> bypass the entire iova . >> >> Any suggestions on this ? > > My first suggestion would be to separate this from IOMMU support completely > as you don't really have an IOMMU. The easiest way to deal with hardware > like this is to use swiotlb with a fixed mapping. This is also the only > way to deal with any devices that may have multiple outstanding DMAs > (PCI, SATA, USB, ...). > > If you have any high-speed devices that only do a single request at a > time connected to this remapper, I would suggest you implement your own > set of dma_map_ops and come back with performance data showing whether it's > worth merging this compared to the trivial iommu support. > > Arnd -- Thanks, with regards, Suman Tripathi ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] Add support for CONFIG_ARM64_DMA_USE_IOMMU. 2015-03-23 15:58 ` Suman Tripathi @ 2015-04-10 21:53 ` Arnd Bergmann 0 siblings, 0 replies; 5+ messages in thread From: Arnd Bergmann @ 2015-04-10 21:53 UTC (permalink / raw) To: linux-arm-kernel On Monday 23 March 2015 21:28:45 Suman Tripathi wrote: > > My first suggestion would be to separate this from IOMMU support > > completely > > as you don't really have an IOMMU. The easiest way to deal with hardware > > like this is to use swiotlb with a fixed mapping. This is also the only > > way to deal with any devices that may have multiple outstanding DMAs > > (PCI, SATA, USB, ...). > I guess you are talking about the swiotlb force idea ? That's really > good but I think we should make configuring swiotlb force per device > otherwise it applies to all devices ?? Sorry for the late reply, I was still catching up on email after my vacation. The swiotlb is automatically enabled for all devices that have a DMA mask smaller than the available memory. There is no need to force that at all. All you have to do is to put devices that have the same limitation regarding their DMA space on a common device node, and set the dma-ranges property of the bus node to correctly describe the mapping. For devices that have a real iommu, or that are on a 64-bit DMA capable bus, you model that bus correctly in DT and set the dma-ranges to cover that address space. The default dma_mask is 32-bit wide, so for devices that have exactly 32-bit (4GB) visibility into physical memory, you don't actually need to do anything. Only devices that you want to access a larger address space have to be on a bus node with the larger dma-ranges, and they need to call dma_set_mask_and_coherent() with the mask that the device supports itself (which may be more than the bus can handle). Arnd ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-04-10 21:53 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1422379495-10268-1-git-send-email-stripathi@apm.com>
2015-01-28 11:27 ` [PATCH] Add support for CONFIG_ARM64_DMA_USE_IOMMU Catalin Marinas
[not found] ` <CAOHikRCSoijzZ8oKEtMadEHOvLiWLO6fWkqiGEiPyb+Egb_1rw@mail.gmail.com>
2015-03-17 23:33 ` Suman Tripathi
2015-03-22 1:31 ` Arnd Bergmann
2015-03-23 15:58 ` Suman Tripathi
2015-04-10 21:53 ` Arnd Bergmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).