From mboxrd@z Thu Jan 1 00:00:00 1970 From: KyongHo Cho Subject: Re: [Linaro-mm-sig] [PATCH 7/8] common: dma-mapping: change alloc/free_coherent method to more generic alloc/free_attrs Date: Wed, 22 Jun 2011 09:00:54 +0900 Message-ID: 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=ISO-8859-1 Return-path: Received: from mail-gx0-f174.google.com ([209.85.161.174]:39912 "EHLO mail-gx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757407Ab1FVAAy (ORCPT ); Tue, 21 Jun 2011 20:00:54 -0400 Received: by gxk21 with SMTP id 21so123413gxk.19 for ; Tue, 21 Jun 2011 17:00:54 -0700 (PDT) In-Reply-To: <002401cc3005$a941c010$fbc54030$%szyprowski@samsung.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Marek Szyprowski 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 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 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. > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by kanga.kvack.org (Postfix) with ESMTP id 74C156B0155 for ; Tue, 21 Jun 2011 20:00:56 -0400 (EDT) Received: by gxk23 with SMTP id 23so157700gxk.14 for ; Tue, 21 Jun 2011 17:00:54 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <002401cc3005$a941c010$fbc54030$%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> Date: Wed, 22 Jun 2011 09:00:54 +0900 Message-ID: Subject: Re: [Linaro-mm-sig] [PATCH 7/8] common: dma-mapping: change alloc/free_coherent method to more generic alloc/free_attrs From: KyongHo Cho Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Marek Szyprowski 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 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 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. > 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. -- 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: pullip.cho@samsung.com (KyongHo Cho) Date: Wed, 22 Jun 2011 09:00:54 +0900 Subject: [Linaro-mm-sig] [PATCH 7/8] common: dma-mapping: change alloc/free_coherent method to more generic alloc/free_attrs In-Reply-To: <002401cc3005$a941c010$fbc54030$%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> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 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. > 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.