From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Szyprowski Date: Wed, 28 Dec 2011 12:52:45 +0000 Subject: RE: [PATCH 00/14] DMA-mapping framework redesign preparation Message-Id: <003a01ccc55f$98dc6f50$ca954df0$%szyprowski@samsung.com> List-Id: References: <1324643253-3024-1-git-send-email-m.szyprowski@samsung.com> <20111223163516.GO20129@parisc-linux.org> <000901ccc471$15db8bc0$4192a340$%szyprowski@samsung.com> <1325008393.14252.5.camel@dabdike> In-Reply-To: <1325008393.14252.5.camel@dabdike> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: 'James Bottomley' Cc: 'Matthew Wilcox' , linux-kernel@vger.kernel.org, 'Benjamin Herrenschmidt' , 'Thomas Gleixner' , 'Andrew Morton' , 'Arnd Bergmann' , 'Stephen Rothwell' , microblaze-uclinux@itee.uq.edu.au, linux-arch@vger.kernel.org, x86@kernel.org, linux-sh@vger.kernel.org, linux-alpha@vger.kernel.org, sparclinux@vger.kernel.org, linux-ia64@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mips@linux-mips.org, discuss@x86-64.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linaro-mm-sig@lists.linaro.org, 'Jonathan Corbet' , 'Kyungmin Park' , Andrzej Pietrasiewicz Hello, On Tuesday, December 27, 2011 6:53 PM James Bottomley wrote: > On Tue, 2011-12-27 at 09:25 +0100, Marek Szyprowski wrote: > [...] > > > > Usually these drivers don't touch the buffer data at all, so the mapping > > > > in kernel virtual address space is not needed. We can introduce > > > > DMA_ATTRIB_NO_KERNEL_MAPPING attribute which lets kernel to skip/ignore > > > > creation of kernel virtual mapping. This way we can save previous > > > > vmalloc area and simply some mapping operation on a few architectures. > > > > > > I really think this wants to be a separate function. dma_alloc_coherent > > > is for allocating memory to be shared between the kernel and a driver; > > > we already have dma_map_sg for mapping userspace I/O as an alternative > > > interface. This feels like it's something different again rather than > > > an option to dma_alloc_coherent. > > > > That is just a starting point for the discussion. > > > > I thought about this API a bit and came to conclusion that there is no much > > difference between a dma_alloc_coherent which creates a mapping in kernel > > virtual space and the one that does not. It is just a hint from the driver > > that it will not use that mapping at all. Of course this attribute makes sense > > only together with adding a dma_mmap_attrs() call, because otherwise drivers > > won't be able to get access to the buffer data. > > This depends. On Virtually indexed systems like PA-RISC, there are two > ways of making a DMA range coherent. One is to make the range uncached. > This is incredibly slow and not what we do by default, but it can be > used to make multiple mappings coherent. The other is to load the > virtual address up as a coherence index into the IOMMU. This makes it a > full peer in the coherence process, but means we can only designate a > single virtual range to be coherent (not multiple mappings unless they > happen to be congruent). Perhaps it doesn't matter that much, since I > don't see a use for this on PA, but if any other architecture works the > same, you'd have to designate a single mapping as the coherent one and > essentially promise not to use the other mapping if we followed our > normal coherence protocols. > > Obviously, the usual range we currently make coherent is the kernel > mapping (that's actually the only virtual address we have by the time > we're deep in the iommu code), so designating a different virtual > address would need some surgery to the guts of the iommu code. I see, in this case not much can be achieved by dropping the kernel mapping for the allocated buffer. I'm also not sure how to mmap the buffer into userspace meet the cpu requirements? Is it possible to use non-cached mapping in userspace together with coherent mapping in kernel virtual space? However on some other architectures this attribute allows using HIGH_MEM for the allocated coherent buffer. The other possibility is to allocate it in chunks and map them contiguously into dma address space. With NO_KERNEL_MAPPING attribute we avoid consuming vmalloc range for the newly allocated buffer for which we cannot use the linear mapping (because it is scattered). Of course this attribute will be implemented by the architectures where it gives some benefits. All other can simply ignore it and return plain coherent buffer with ordinary kernel virtual mapping. The driver will just ignore it. Best regards -- Marek Szyprowski Samsung Poland R&D Center From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753595Ab1L1Mw7 (ORCPT ); Wed, 28 Dec 2011 07:52:59 -0500 Received: from mailout4.w1.samsung.com ([210.118.77.14]:59583 "EHLO mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751394Ab1L1Mw4 (ORCPT ); Wed, 28 Dec 2011 07:52:56 -0500 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=UTF-8 Date: Wed, 28 Dec 2011 13:52:45 +0100 From: Marek Szyprowski Subject: RE: [PATCH 00/14] DMA-mapping framework redesign preparation In-reply-to: <1325008393.14252.5.camel@dabdike> To: "'James Bottomley'" Cc: "'Matthew Wilcox'" , linux-kernel@vger.kernel.org, "'Benjamin Herrenschmidt'" , "'Thomas Gleixner'" , "'Andrew Morton'" , "'Arnd Bergmann'" , "'Stephen Rothwell'" , microblaze-uclinux@itee.uq.edu.au, linux-arch@vger.kernel.org, x86@kernel.org, linux-sh@vger.kernel.org, linux-alpha@vger.kernel.org, sparclinux@vger.kernel.org, linux-ia64@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mips@linux-mips.org, discuss@x86-64.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linaro-mm-sig@lists.linaro.org, "'Jonathan Corbet'" , "'Kyungmin Park'" , Andrzej Pietrasiewicz Message-id: <003a01ccc55f$98dc6f50$ca954df0$%szyprowski@samsung.com> Organization: SPRC X-Mailer: Microsoft Office Outlook 12.0 Content-language: pl Thread-index: AczEwG5Jc0rEXHLyR72j2XGo7DHGOwAdkvRw References: <1324643253-3024-1-git-send-email-m.szyprowski@samsung.com> <20111223163516.GO20129@parisc-linux.org> <000901ccc471$15db8bc0$4192a340$%szyprowski@samsung.com> <1325008393.14252.5.camel@dabdike> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Tuesday, December 27, 2011 6:53 PM James Bottomley wrote: > On Tue, 2011-12-27 at 09:25 +0100, Marek Szyprowski wrote: > [...] > > > > Usually these drivers don't touch the buffer data at all, so the mapping > > > > in kernel virtual address space is not needed. We can introduce > > > > DMA_ATTRIB_NO_KERNEL_MAPPING attribute which lets kernel to skip/ignore > > > > creation of kernel virtual mapping. This way we can save previous > > > > vmalloc area and simply some mapping operation on a few architectures. > > > > > > I really think this wants to be a separate function. dma_alloc_coherent > > > is for allocating memory to be shared between the kernel and a driver; > > > we already have dma_map_sg for mapping userspace I/O as an alternative > > > interface. This feels like it's something different again rather than > > > an option to dma_alloc_coherent. > > > > That is just a starting point for the discussion. > > > > I thought about this API a bit and came to conclusion that there is no much > > difference between a dma_alloc_coherent which creates a mapping in kernel > > virtual space and the one that does not. It is just a hint from the driver > > that it will not use that mapping at all. Of course this attribute makes sense > > only together with adding a dma_mmap_attrs() call, because otherwise drivers > > won't be able to get access to the buffer data. > > This depends. On Virtually indexed systems like PA-RISC, there are two > ways of making a DMA range coherent. One is to make the range uncached. > This is incredibly slow and not what we do by default, but it can be > used to make multiple mappings coherent. The other is to load the > virtual address up as a coherence index into the IOMMU. This makes it a > full peer in the coherence process, but means we can only designate a > single virtual range to be coherent (not multiple mappings unless they > happen to be congruent). Perhaps it doesn't matter that much, since I > don't see a use for this on PA, but if any other architecture works the > same, you'd have to designate a single mapping as the coherent one and > essentially promise not to use the other mapping if we followed our > normal coherence protocols. > > Obviously, the usual range we currently make coherent is the kernel > mapping (that's actually the only virtual address we have by the time > we're deep in the iommu code), so designating a different virtual > address would need some surgery to the guts of the iommu code. I see, in this case not much can be achieved by dropping the kernel mapping for the allocated buffer. I'm also not sure how to mmap the buffer into userspace meet the cpu requirements? Is it possible to use non-cached mapping in userspace together with coherent mapping in kernel virtual space? However on some other architectures this attribute allows using HIGH_MEM for the allocated coherent buffer. The other possibility is to allocate it in chunks and map them contiguously into dma address space. With NO_KERNEL_MAPPING attribute we avoid consuming vmalloc range for the newly allocated buffer for which we cannot use the linear mapping (because it is scattered). Of course this attribute will be implemented by the architectures where it gives some benefits. All other can simply ignore it and return plain coherent buffer with ordinary kernel virtual mapping. The driver will just ignore it. Best regards -- Marek Szyprowski Samsung Poland R&D Center From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Szyprowski Subject: RE: [PATCH 00/14] DMA-mapping framework redesign preparation Date: Wed, 28 Dec 2011 13:52:45 +0100 Message-ID: <003a01ccc55f$98dc6f50$ca954df0$%szyprowski@samsung.com> References: <1324643253-3024-1-git-send-email-m.szyprowski@samsung.com> <20111223163516.GO20129@parisc-linux.org> <000901ccc471$15db8bc0$4192a340$%szyprowski@samsung.com> <1325008393.14252.5.camel@dabdike> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7BIT Return-path: In-reply-to: <1325008393.14252.5.camel@dabdike> Content-language: pl Sender: owner-linux-mm@kvack.org To: 'James Bottomley' Cc: 'Matthew Wilcox' , linux-kernel@vger.kernel.org, 'Benjamin Herrenschmidt' , 'Thomas Gleixner' , 'Andrew Morton' , 'Arnd Bergmann' , 'Stephen Rothwell' , microblaze-uclinux@itee.uq.edu.au, linux-arch@vger.kernel.org, x86@kernel.org, linux-sh@vger.kernel.org, linux-alpha@vger.kernel.org, sparclinux@vger.kernel.org, linux-ia64@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mips@linux-mips.org, discuss@x86-64.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linaro-mm-sig@lists.linaro.org, 'Jonathan Corbet' , 'Kyungmin Park' , Andrzej Pietrasiewicz List-Id: linux-arch.vger.kernel.org Hello, On Tuesday, December 27, 2011 6:53 PM James Bottomley wrote: > On Tue, 2011-12-27 at 09:25 +0100, Marek Szyprowski wrote: > [...] > > > > Usually these drivers don't touch the buffer data at all, so the mapping > > > > in kernel virtual address space is not needed. We can introduce > > > > DMA_ATTRIB_NO_KERNEL_MAPPING attribute which lets kernel to skip/ignore > > > > creation of kernel virtual mapping. This way we can save previous > > > > vmalloc area and simply some mapping operation on a few architectures. > > > > > > I really think this wants to be a separate function. dma_alloc_coherent > > > is for allocating memory to be shared between the kernel and a driver; > > > we already have dma_map_sg for mapping userspace I/O as an alternative > > > interface. This feels like it's something different again rather than > > > an option to dma_alloc_coherent. > > > > That is just a starting point for the discussion. > > > > I thought about this API a bit and came to conclusion that there is no much > > difference between a dma_alloc_coherent which creates a mapping in kernel > > virtual space and the one that does not. It is just a hint from the driver > > that it will not use that mapping at all. Of course this attribute makes sense > > only together with adding a dma_mmap_attrs() call, because otherwise drivers > > won't be able to get access to the buffer data. > > This depends. On Virtually indexed systems like PA-RISC, there are two > ways of making a DMA range coherent. One is to make the range uncached. > This is incredibly slow and not what we do by default, but it can be > used to make multiple mappings coherent. The other is to load the > virtual address up as a coherence index into the IOMMU. This makes it a > full peer in the coherence process, but means we can only designate a > single virtual range to be coherent (not multiple mappings unless they > happen to be congruent). Perhaps it doesn't matter that much, since I > don't see a use for this on PA, but if any other architecture works the > same, you'd have to designate a single mapping as the coherent one and > essentially promise not to use the other mapping if we followed our > normal coherence protocols. > > Obviously, the usual range we currently make coherent is the kernel > mapping (that's actually the only virtual address we have by the time > we're deep in the iommu code), so designating a different virtual > address would need some surgery to the guts of the iommu code. I see, in this case not much can be achieved by dropping the kernel mapping for the allocated buffer. I'm also not sure how to mmap the buffer into userspace meet the cpu requirements? Is it possible to use non-cached mapping in userspace together with coherent mapping in kernel virtual space? However on some other architectures this attribute allows using HIGH_MEM for the allocated coherent buffer. The other possibility is to allocate it in chunks and map them contiguously into dma address space. With NO_KERNEL_MAPPING attribute we avoid consuming vmalloc range for the newly allocated buffer for which we cannot use the linear mapping (because it is scattered). Of course this attribute will be implemented by the architectures where it gives some benefits. All other can simply ignore it and return plain coherent buffer with ordinary kernel virtual mapping. The driver will just ignore it. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by ozlabs.org (Postfix) with ESMTP id 0F524B6FE2 for ; Wed, 28 Dec 2011 23:52:58 +1100 (EST) Received: from euspt1 (mailout2.w1.samsung.com [210.118.77.12]) by mailout2.w1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0LWW00E6MZS55U@mailout2.w1.samsung.com> for linuxppc-dev@lists.ozlabs.org; Wed, 28 Dec 2011 12:52:53 +0000 (GMT) Received: from linux.samsung.com ([106.116.38.10]) by spt1.w1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0LWW002P1ZS4E9@spt1.w1.samsung.com> for linuxppc-dev@lists.ozlabs.org; Wed, 28 Dec 2011 12:52:53 +0000 (GMT) Date: Wed, 28 Dec 2011 13:52:45 +0100 From: Marek Szyprowski Subject: RE: [PATCH 00/14] DMA-mapping framework redesign preparation In-reply-to: <1325008393.14252.5.camel@dabdike> To: 'James Bottomley' Message-id: <003a01ccc55f$98dc6f50$ca954df0$%szyprowski@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 References: <1324643253-3024-1-git-send-email-m.szyprowski@samsung.com> <20111223163516.GO20129@parisc-linux.org> <000901ccc471$15db8bc0$4192a340$%szyprowski@samsung.com> <1325008393.14252.5.camel@dabdike> Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, linux-mm@kvack.org, sparclinux@vger.kernel.org, linux-arch@vger.kernel.org, 'Stephen Rothwell' , 'Jonathan Corbet' , x86@kernel.org, 'Arnd Bergmann' , 'Matthew Wilcox' , microblaze-uclinux@itee.uq.edu.au, linaro-mm-sig@lists.linaro.org, Andrzej Pietrasiewicz , 'Thomas Gleixner' , linux-arm-kernel@lists.infradead.org, discuss@x86-64.org, linux-kernel@vger.kernel.org, 'Kyungmin Park' , linux-alpha@vger.kernel.org, 'Andrew Morton' , linuxppc-dev@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hello, On Tuesday, December 27, 2011 6:53 PM James Bottomley wrote: > On Tue, 2011-12-27 at 09:25 +0100, Marek Szyprowski wrote: > [...] > > > > Usually these drivers don't touch the buffer data at all, so the mapping > > > > in kernel virtual address space is not needed. We can introduce > > > > DMA_ATTRIB_NO_KERNEL_MAPPING attribute which lets kernel to skip/ignore > > > > creation of kernel virtual mapping. This way we can save previous > > > > vmalloc area and simply some mapping operation on a few architectures. > > > > > > I really think this wants to be a separate function. dma_alloc_coherent > > > is for allocating memory to be shared between the kernel and a driver; > > > we already have dma_map_sg for mapping userspace I/O as an alternative > > > interface. This feels like it's something different again rather than > > > an option to dma_alloc_coherent. > > > > That is just a starting point for the discussion. > > > > I thought about this API a bit and came to conclusion that there is no much > > difference between a dma_alloc_coherent which creates a mapping in kernel > > virtual space and the one that does not. It is just a hint from the driver > > that it will not use that mapping at all. Of course this attribute makes sense > > only together with adding a dma_mmap_attrs() call, because otherwise drivers > > won't be able to get access to the buffer data. > > This depends. On Virtually indexed systems like PA-RISC, there are two > ways of making a DMA range coherent. One is to make the range uncached. > This is incredibly slow and not what we do by default, but it can be > used to make multiple mappings coherent. The other is to load the > virtual address up as a coherence index into the IOMMU. This makes it a > full peer in the coherence process, but means we can only designate a > single virtual range to be coherent (not multiple mappings unless they > happen to be congruent). Perhaps it doesn't matter that much, since I > don't see a use for this on PA, but if any other architecture works the > same, you'd have to designate a single mapping as the coherent one and > essentially promise not to use the other mapping if we followed our > normal coherence protocols. > > Obviously, the usual range we currently make coherent is the kernel > mapping (that's actually the only virtual address we have by the time > we're deep in the iommu code), so designating a different virtual > address would need some surgery to the guts of the iommu code. I see, in this case not much can be achieved by dropping the kernel mapping for the allocated buffer. I'm also not sure how to mmap the buffer into userspace meet the cpu requirements? Is it possible to use non-cached mapping in userspace together with coherent mapping in kernel virtual space? However on some other architectures this attribute allows using HIGH_MEM for the allocated coherent buffer. The other possibility is to allocate it in chunks and map them contiguously into dma address space. With NO_KERNEL_MAPPING attribute we avoid consuming vmalloc range for the newly allocated buffer for which we cannot use the linear mapping (because it is scattered). Of course this attribute will be implemented by the architectures where it gives some benefits. All other can simply ignore it and return plain coherent buffer with ordinary kernel virtual mapping. The driver will just ignore it. Best regards -- Marek Szyprowski Samsung Poland R&D Center From mboxrd@z Thu Jan 1 00:00:00 1970 From: m.szyprowski@samsung.com (Marek Szyprowski) Date: Wed, 28 Dec 2011 13:52:45 +0100 Subject: [PATCH 00/14] DMA-mapping framework redesign preparation In-Reply-To: <1325008393.14252.5.camel@dabdike> References: <1324643253-3024-1-git-send-email-m.szyprowski@samsung.com> <20111223163516.GO20129@parisc-linux.org> <000901ccc471$15db8bc0$4192a340$%szyprowski@samsung.com> <1325008393.14252.5.camel@dabdike> Message-ID: <003a01ccc55f$98dc6f50$ca954df0$%szyprowski@samsung.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hello, On Tuesday, December 27, 2011 6:53 PM James Bottomley wrote: > On Tue, 2011-12-27 at 09:25 +0100, Marek Szyprowski wrote: > [...] > > > > Usually these drivers don't touch the buffer data at all, so the mapping > > > > in kernel virtual address space is not needed. We can introduce > > > > DMA_ATTRIB_NO_KERNEL_MAPPING attribute which lets kernel to skip/ignore > > > > creation of kernel virtual mapping. This way we can save previous > > > > vmalloc area and simply some mapping operation on a few architectures. > > > > > > I really think this wants to be a separate function. dma_alloc_coherent > > > is for allocating memory to be shared between the kernel and a driver; > > > we already have dma_map_sg for mapping userspace I/O as an alternative > > > interface. This feels like it's something different again rather than > > > an option to dma_alloc_coherent. > > > > That is just a starting point for the discussion. > > > > I thought about this API a bit and came to conclusion that there is no much > > difference between a dma_alloc_coherent which creates a mapping in kernel > > virtual space and the one that does not. It is just a hint from the driver > > that it will not use that mapping at all. Of course this attribute makes sense > > only together with adding a dma_mmap_attrs() call, because otherwise drivers > > won't be able to get access to the buffer data. > > This depends. On Virtually indexed systems like PA-RISC, there are two > ways of making a DMA range coherent. One is to make the range uncached. > This is incredibly slow and not what we do by default, but it can be > used to make multiple mappings coherent. The other is to load the > virtual address up as a coherence index into the IOMMU. This makes it a > full peer in the coherence process, but means we can only designate a > single virtual range to be coherent (not multiple mappings unless they > happen to be congruent). Perhaps it doesn't matter that much, since I > don't see a use for this on PA, but if any other architecture works the > same, you'd have to designate a single mapping as the coherent one and > essentially promise not to use the other mapping if we followed our > normal coherence protocols. > > Obviously, the usual range we currently make coherent is the kernel > mapping (that's actually the only virtual address we have by the time > we're deep in the iommu code), so designating a different virtual > address would need some surgery to the guts of the iommu code. I see, in this case not much can be achieved by dropping the kernel mapping for the allocated buffer. I'm also not sure how to mmap the buffer into userspace meet the cpu requirements? Is it possible to use non-cached mapping in userspace together with coherent mapping in kernel virtual space? However on some other architectures this attribute allows using HIGH_MEM for the allocated coherent buffer. The other possibility is to allocate it in chunks and map them contiguously into dma address space. With NO_KERNEL_MAPPING attribute we avoid consuming vmalloc range for the newly allocated buffer for which we cannot use the linear mapping (because it is scattered). Of course this attribute will be implemented by the architectures where it gives some benefits. All other can simply ignore it and return plain coherent buffer with ordinary kernel virtual mapping. The driver will just ignore it. Best regards -- Marek Szyprowski Samsung Poland R&D Center