From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Szyprowski Subject: RE: [Linaro-mm-sig] [PATCH 7/8] common: dma-mapping: change alloc/free_coherent method to more generic alloc/free_attrs Date: Fri, 24 Jun 2011 09:20:27 +0200 Message-ID: <000001cc323f$3114d8c0$933e8a40$%szyprowski@samsung.com> References: <1308556213-24970-1-git-send-email-m.szyprowski@samsung.com> <1308556213-24970-8-git-send-email-m.szyprowski@samsung.com> <002401cc3005$a941c010$fbc54030$%szyprowski@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Return-path: Received: from mailout2.w1.samsung.com ([210.118.77.12]:17485 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752497Ab1FXHUx (ORCPT ); Fri, 24 Jun 2011 03:20:53 -0400 Received: from eu_spt1 (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 <0LNA008X49QRGD@mailout2.w1.samsung.com> for linux-arch@vger.kernel.org; Fri, 24 Jun 2011 08:20:51 +0100 (BST) 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 <0LNA00J0A9QPKX@spt1.w1.samsung.com> for linux-arch@vger.kernel.org; Fri, 24 Jun 2011 08:20:50 +0100 (BST) In-reply-to: Content-language: pl Sender: linux-arch-owner@vger.kernel.org List-ID: To: 'KyongHo Cho' Cc: linux-arch@vger.kernel.org, 'Russell King - ARM Linux' , 'Arnd Bergmann' , 'Joerg Roedel' , linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, 'Kyungmin Park' , linux-arm-kernel@lists.infradead.org, Marek Szyprowski Hello, On Wednesday, June 22, 2011 2:01 AM KyongHo Cho wrote: > 2011/6/21 Marek Szyprowski : > > > > You already got a reply that dropping dma_alloc_writecombine() is no > > go on ARM. > > > Yes. > > > That's not a problem. Once we agree on dma_alloc_attrs(), the drivers > > can be changed to use DMA_ATTR_WRITE_COMBINE attribute. If the platform > > doesn't support the attribute, it is just ignored. That's the whole > > point of the attributes extension. Once a driver is converted to > > dma_alloc_attrs(), it can be used without any changes either on platforms > > that supports some specific attributes or the one that doesn't implement > > support for any of them. > > > I just worried that removing an existing construct is not a simple job. > You introduced 3 attributes: DMA_ATTR_WRITE_COMBINE, ***COHERENT and > ***NO_KERNEL_VADDR COHERENT is the default behavior when no attribute is provided. I also don't want to remove existing calls to dma_alloc_coherent() and dma_alloc_writecombine() from the drivers. This can be done later, once dma_alloc_attrs() API will stabilize. > I replied earlier, I also indicated that write combining option for > dma_alloc_*() is required. > But it does not mean dma_map_ops must support that. > I think dma_alloc_writecombine() can be implemented regardless of > dma_map_ops. The discussion about the need of dma_alloc_attrs() has been performed on Memory Management Summit at Linaro Meeting in Budapest. It simplifies the API and provides full backward compatibility for existing drivers. > > Allocation is a separate operation from mapping to userspace. Mmap > > operation should just map the buffer (represented by a cookie of type > > dma_addr_t) to user address space. > > > > Note that some drivers (like framebuffer drivers for example) also > > needs to have both types of mapping - one for user space and one for > > kernel virtual space. > > I meant that I think DMA_ATTR_NOKERNELVADDR is not required because > you also introduced mmap callback. I've already said that mmap callback is not related to the fact that the buffer has been allocated with or without respective kernel virtual space mapping. I really don't get what do you mean here. Best regards -- Marek Szyprowski Samsung Poland R&D Center From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail6.bemta7.messagelabs.com (mail6.bemta7.messagelabs.com [216.82.255.55]) by kanga.kvack.org (Postfix) with ESMTP id 14871900194 for ; Fri, 24 Jun 2011 03:20:55 -0400 (EDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from eu_spt1 ([210.118.77.14]) by mailout4.w1.samsung.com (Sun Java(tm) System Messaging Server 6.3-8.04 (built Jul 29 2009; 32bit)) with ESMTP id <0LNA00J3G9QQ3K80@mailout4.w1.samsung.com> for linux-mm@kvack.org; Fri, 24 Jun 2011 08:20:51 +0100 (BST) 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 <0LNA00J0A9QPKX@spt1.w1.samsung.com> for linux-mm@kvack.org; Fri, 24 Jun 2011 08:20:50 +0100 (BST) Date: Fri, 24 Jun 2011 09:20:27 +0200 From: Marek Szyprowski Subject: RE: [Linaro-mm-sig] [PATCH 7/8] common: dma-mapping: change alloc/free_coherent method to more generic alloc/free_attrs In-reply-to: Message-id: <000001cc323f$3114d8c0$933e8a40$%szyprowski@samsung.com> Content-language: pl References: <1308556213-24970-1-git-send-email-m.szyprowski@samsung.com> <1308556213-24970-8-git-send-email-m.szyprowski@samsung.com> <002401cc3005$a941c010$fbc54030$%szyprowski@samsung.com> Sender: owner-linux-mm@kvack.org List-ID: To: 'KyongHo Cho' Cc: linux-arch@vger.kernel.org, 'Russell King - ARM Linux' , 'Arnd Bergmann' , 'Joerg Roedel' , linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, 'Kyungmin Park' , linux-arm-kernel@lists.infradead.org, Marek Szyprowski Hello, On Wednesday, June 22, 2011 2:01 AM KyongHo Cho wrote: > 2011/6/21 Marek Szyprowski : > > > > You already got a reply that dropping dma_alloc_writecombine() is no > > go on ARM. > > > Yes. > > > That's not a problem. Once we agree on dma_alloc_attrs(), the drivers > > can be changed to use DMA_ATTR_WRITE_COMBINE attribute. If the platform > > doesn't support the attribute, it is just ignored. That's the whole > > point of the attributes extension. Once a driver is converted to > > dma_alloc_attrs(), it can be used without any changes either on platforms > > that supports some specific attributes or the one that doesn't implement > > support for any of them. > > > I just worried that removing an existing construct is not a simple job. > You introduced 3 attributes: DMA_ATTR_WRITE_COMBINE, ***COHERENT and > ***NO_KERNEL_VADDR COHERENT is the default behavior when no attribute is provided. I also don't want to remove existing calls to dma_alloc_coherent() and dma_alloc_writecombine() from the drivers. This can be done later, once dma_alloc_attrs() API will stabilize. > I replied earlier, I also indicated that write combining option for > dma_alloc_*() is required. > But it does not mean dma_map_ops must support that. > I think dma_alloc_writecombine() can be implemented regardless of > dma_map_ops. The discussion about the need of dma_alloc_attrs() has been performed on Memory Management Summit at Linaro Meeting in Budapest. It simplifies the API and provides full backward compatibility for existing drivers. > > Allocation is a separate operation from mapping to userspace. Mmap > > operation should just map the buffer (represented by a cookie of type > > dma_addr_t) to user address space. > > > > Note that some drivers (like framebuffer drivers for example) also > > needs to have both types of mapping - one for user space and one for > > kernel virtual space. > > I meant that I think DMA_ATTR_NOKERNELVADDR is not required because > you also introduced mmap callback. I've already said that mmap callback is not related to the fact that the buffer has been allocated with or without respective kernel virtual space mapping. I really don't get what do you mean here. 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 From: m.szyprowski@samsung.com (Marek Szyprowski) Date: Fri, 24 Jun 2011 09:20:27 +0200 Subject: [Linaro-mm-sig] [PATCH 7/8] common: dma-mapping: change alloc/free_coherent method to more generic alloc/free_attrs In-Reply-To: References: <1308556213-24970-1-git-send-email-m.szyprowski@samsung.com> <1308556213-24970-8-git-send-email-m.szyprowski@samsung.com> <002401cc3005$a941c010$fbc54030$%szyprowski@samsung.com> Message-ID: <000001cc323f$3114d8c0$933e8a40$%szyprowski@samsung.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hello, On Wednesday, June 22, 2011 2:01 AM KyongHo Cho wrote: > 2011/6/21 Marek Szyprowski : > > > > You already got a reply that dropping dma_alloc_writecombine() is no > > go on ARM. > > > Yes. > > > That's not a problem. Once we agree on dma_alloc_attrs(), the drivers > > can be changed to use DMA_ATTR_WRITE_COMBINE attribute. If the platform > > doesn't support the attribute, it is just ignored. That's the whole > > point of the attributes extension. Once a driver is converted to > > dma_alloc_attrs(), it can be used without any changes either on platforms > > that supports some specific attributes or the one that doesn't implement > > support for any of them. > > > I just worried that removing an existing construct is not a simple job. > You introduced 3 attributes: DMA_ATTR_WRITE_COMBINE, ***COHERENT and > ***NO_KERNEL_VADDR COHERENT is the default behavior when no attribute is provided. I also don't want to remove existing calls to dma_alloc_coherent() and dma_alloc_writecombine() from the drivers. This can be done later, once dma_alloc_attrs() API will stabilize. > I replied earlier, I also indicated that write combining option for > dma_alloc_*() is required. > But it does not mean dma_map_ops must support that. > I think dma_alloc_writecombine() can be implemented regardless of > dma_map_ops. The discussion about the need of dma_alloc_attrs() has been performed on Memory Management Summit at Linaro Meeting in Budapest. It simplifies the API and provides full backward compatibility for existing drivers. > > Allocation is a separate operation from mapping to userspace. Mmap > > operation should just map the buffer (represented by a cookie of type > > dma_addr_t) to user address space. > > > > Note that some drivers (like framebuffer drivers for example) also > > needs to have both types of mapping - one for user space and one for > > kernel virtual space. > > I meant that I think DMA_ATTR_NOKERNELVADDR is not required because > you also introduced mmap callback. I've already said that mmap callback is not related to the fact that the buffer has been allocated with or without respective kernel virtual space mapping. I really don't get what do you mean here. Best regards -- Marek Szyprowski Samsung Poland R&D Center