Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753099AbcD0SQk (ORCPT ); Wed, 27 Apr 2016 14:16:40 -0400 Received: from mail-qk0-f176.google.com ([209.85.220.176]:34405 "EHLO mail-qk0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752203AbcD0SQi (ORCPT ); Wed, 27 Apr 2016 14:16:38 -0400 Subject: Re: [RFC/PATCHv2 v2 2/4] dma-mapping: Add dma_remap() APIs To: Catalin Marinas , Stephen Boyd References: <1461114269-13718-1-git-send-email-stephen.boyd@linaro.org> <1461114269-13718-3-git-send-email-stephen.boyd@linaro.org> <20160421103512.GC23774@e104818-lin.cambridge.arm.com> <20160423003516.12876.30413@sboyd-linaro> <20160427152524.GD20646@e104818-lin.cambridge.arm.com> Cc: linux-kernel@vger.kernel.org, Laura Abbott , linux-arm@lists.infradead.org, Robin Murphy , Arnd Bergmann , Marek Szyprowski , Mimi Zohar , Andrew Morton , Mark Brown , Will Deacon , Ming Lei From: Laura Abbott Message-ID: <57210200.2060405@redhat.com> Date: Wed, 27 Apr 2016 11:16:32 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160427152524.GD20646@e104818-lin.cambridge.arm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3456 Lines: 71 On 04/27/2016 08:25 AM, Catalin Marinas wrote: > On Fri, Apr 22, 2016 at 05:35:16PM -0700, Stephen Boyd wrote: >> Quoting Catalin Marinas (2016-04-21 03:35:12) >>> On Tue, Apr 19, 2016 at 06:04:27PM -0700, Stephen Boyd wrote: >>>> From: Laura Abbott >>>> >>>> Some systems are memory constrained but they need to load very >>>> large firmwares. The firmware subsystem allows drivers to request >>>> this firmware be loaded from the filesystem, but this requires >>>> that the entire firmware be loaded into kernel memory first >>>> before it's provided to the driver. This can lead to a situation >>>> where we map the firmware twice, once to load the firmware into >>>> kernel memory and once to copy the firmware into the final >>>> resting place. >>>> >>>> This design creates needless memory pressure and delays loading >>>> because we have to copy from kernel memory to somewhere else. >>>> Let's add a couple DMA APIs that allow us to map DMA buffers into >>>> the CPU's address space in arbitrary sizes. With this API, we can >>>> allocate a DMA buffer with DMA_ATTR_NO_KERNEL_MAPPING and move a >>>> small mapping window across our large DMA buffer to load the >>>> firmware directly into buffer. >>> >>> The first two patches in this series don't make sense to me. I don't >>> understand what the memory pressure is: physical or virtual? Because >>> they don't seem to address the former (the DMA buffer is allocated in >>> full) while the latter doesn't need any addressing at all on arm64, we >>> have plenty of VA space. >>> >>> Why do you even need the coherent DMA API? Can you use the streaming API >>> (map_sg etc.) with a separately allocated buffer? >> >> Hmm I guess I need to add in the patches that show how this is used on >> top of "no-map" DT reserved memory regions. There are some more patches >> that allow us to assigned reserved memory regions with the "no-map" >> attribute to devices and then allocate from those regions using the >> coherent DMA APIs. In the downstream kernel it's called a removed dma >> pool[1]. >> >> So the plan is to wire that all up so that the device can have a >> reserved chunk of memory for the firmware that doesn't exist in the >> kernel's linear memory mappings. Once we have allocated the region, we >> can map it into the kernel's view of memory for a short time so that we >> can load the firmware into it (dma_remap part). Once that's over, we >> want to destroy the mapping so that we 1) don't use any of the kernel's >> virtual memory space (dma_unremap part) to back the buffer and 2) so >> that the secure world can protect the memory from the non-secure world. > > Does the firmware already know about such memory? If yes, I presume the > kernel would have to be told about it and won't try to map it in the > linear mapping. > > At this point, wouldn't a combination of: > > dma_declare_coherent_memory() > dma_alloc_from_coherent() > dma_release_from_coherent() > dma_release_declared_memory() > > work? The removed_alloc() implementation in the link you posted doesn't > seem far from dma_alloc_from_coherent(). The releasing of the declared > memory above would unmap the memory, so there are no VA mappings left. > The removed alloc was specifically written as a fork of the coherent pool. This was a choice for ease of out of tree maintenance. The better choice here would be to fold those features back into dma-coherent.c if needed. Thanks, Laura