Message-ID: <401E54CE964CD94BAE1EB4A729C7087E37982E5C8F@HQMAIL04.nvidia.com>
Date:	Tue, 3 Apr 2012 12:26:25 -0700
From:	Krishna Reddy <vdumpa@...dia.com>
To:	Arnd Bergmann <arnd@...db.de>, Kyungmin Park <kmpark@...radead.org>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Hiroshi Doyu <hdoyu@...dia.com>,
	"konrad.wilk@...cle.com" <konrad.wilk@...cle.com>
Subject: RE: Linux 3.4-rc1

> We are seeing lots of IOMMUs come up on ARM now, but unfortunately the
> existing dma_map_ops do not cover the need on ARM to have two different
> kind of coherent memory (write-combine and not
> write-combine) that we have traditionally abstracted using the
> dma_alloc_coherent and dma_alloc_writecombine functions on both arm
> and avr32.

I agree with Arnd. 
Nvidia Tegra3 SOC and the other  future SOC's, which are based on ARM, have
IOMMU support. Most of the H/W modules see the memory through IOMMU.
We definitely need IOMMU support under dma_api's for ARM based SOC's
This really helps in avoiding vendor specific code for IOMMU space management.


>In order to support IOMMUs on ARM using the same API as
> everyone else, I've asked Marek to use dma_map_ops on ARM, which
> requires slightly extending the include/linux/dma-mapping.h interfaces so
> they cover this variation.

We have been using Marek patches from quite some time. 
The patches are stable enough and we are using them already internally.
 It  would be nice to get them into main stream as possible to avoid back porting
 during kernel transitions.

My two cents.


-KR
-nvpublic

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@...db.de]
> Sent: Tuesday, April 03, 2012 2:07 AM
> To: Kyungmin Park
> Cc: Linus Torvalds; Linux Kernel Mailing List; Krishna Reddy; Hiroshi Doyu;
> konrad.wilk@...cle.com
> Subject: Re: Linux 3.4-rc1
> 
> On Tuesday 03 April 2012, Kyungmin Park wrote:
> > >
> > >  - DMA-mapping framework. The tree now has a few more acks from
> > > people, and it's largely in the same situation as HSI is: I'll
> > > probably pull, but I really wanted the users who are impacted to
> > > actually talk to me about it.
> > >
> > Hi,
> >
> > Now Marek and Nvidia persons are used it for DMA mapping based
> IOMMU.
> >
> > Are there other person who help to merge it?
> > (+CC related persons).
> 
> I can give a little more background information.
> 
> We used to have separate implementations of dma_map_ops for each
> architecture that had the need to abstract dma_alloc_coherent and
> dma_map_* across both IOMMU and linear (virt_to_bus style) mappings
> and/or swiotlb. Those dma_map_ops imlpementations were already merged
> before the start of the git history and subsequently got used on powerpc,
> ia64, x86_64, sparc, alpha, mips, unicore32 and hexagon, roughly in that
> order.
> 
> We are seeing lots of IOMMUs come up on ARM now, but unfortunately the
> existing dma_map_ops do not cover the need on ARM to have two different
> kind of coherent memory (write-combine and not
> write-combine) that we have traditionally abstracted using the
> dma_alloc_coherent and dma_alloc_writecombine functions on both arm
> and avr32. In order to support IOMMUs on ARM using the same API as
> everyone else, I've asked Marek to use dma_map_ops on ARM, which
> requires slightly extending the include/linux/dma-mapping.h interfaces so
> they cover this variation.
> 
> The actually interesting work to implement a better abstraction for IOMMUs,
> building the dma-mapping.h API on top of the iommu.h API in an architecture
> independent way has also been implemented but requires these changes as
> a prerequisite.
> 
> 	Arnd
--
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