Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757770Ab0GNUMD (ORCPT ); Wed, 14 Jul 2010 16:12:03 -0400 Received: from wolverine01.qualcomm.com ([199.106.114.254]:11963 "EHLO wolverine01.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757758Ab0GNUL5 (ORCPT ); Wed, 14 Jul 2010 16:11:57 -0400 X-IronPort-AV: E=McAfee;i="5400,1158,6043"; a="47488456" Date: Wed, 14 Jul 2010 13:11:49 -0700 From: Zach Pfeffer To: FUJITA Tomonori Cc: linux@arm.linux.org.uk, ebiederm@xmission.com, linux-arch@vger.kernel.org, dwalker@codeaurora.org, mel@csn.ul.ie, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, andi@firstfloor.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management Message-ID: <20100714201149.GA14008@codeaurora.org> References: <4C3C0032.5020702@codeaurora.org> <20100713150311B.fujita.tomonori@lab.ntt.co.jp> <20100713121420.GB4263@codeaurora.org> <20100714104353B.fujita.tomonori@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100714104353B.fujita.tomonori@lab.ntt.co.jp> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2323 Lines: 56 On Wed, Jul 14, 2010 at 10:59:38AM +0900, FUJITA Tomonori wrote: > On Tue, 13 Jul 2010 05:14:21 -0700 > Zach Pfeffer wrote: > > > > You mean that you want to specify this alignment attribute every time > > > you create an IOMMU mapping? Then you can set segment_boundary_mask > > > every time you create an IOMMU mapping. It's odd but it should work. > > > > Kinda. I want to forget about IOMMUs, devices and CPUs. I just want to > > create a mapping that has the alignment I specify, regardless of the > > mapper. The mapping is created on a VCM and the VCM is associated with > > a mapper: a CPU, an IOMMU'd device or a direct mapped device. > > Sounds like you can do the above with the combination of the current > APIs, create a virtual address and then an I/O address. > Yes, and that's what the implementation does - and all the other implementations that need to do this same thing. Why not solve the problem once? > The above can't be a reason to add a new infrastructure includes more > than 3,000 lines. Right now its 3000 lines because I haven't converted to a function pointer based implementation. Once I do that the size of the implementation will shrink and the code will act as a lib. Users pass buffer mappers and the lib will ease the management of of those buffers. > > > > > Another possible solution is extending struct dma_attrs. We could add > > > the alignment attribute to it. > > > > That may be useful, but in the current DMA-API may be seen as > > redundant info. > > If there is real requirement, we can extend the DMA-API. If the DMA-API contained functions to allocate virtual space separate from physical space and reworked how chained buffers functioned it would probably work - but then things start to look like the VCM API which does graph based map management. > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/