Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1389433

Re: [RFC/PATCHv2 v2 2/4] dma-mapping: Add dma_remap() APIs

Path csiph.com!goblin3!goblin2!goblin.stu.neva.ru!gothmog.csi.it!bofh.it!news.nic.it!robomod
From Laura Abbott <labbott@redhat.com>
Newsgroups linux.kernel
Subject Re: [RFC/PATCHv2 v2 2/4] dma-mapping: Add dma_remap() APIs
Date Wed, 27 Apr 2016 20:20:02 +0200
Message-ID <rsCe6-5LS-5@gated-at.bofh.it> (permalink)
References <rpOOu-7Xt-3@gated-at.bofh.it> <rpOOu-7Xt-1@gated-at.bofh.it> <rqkbE-7J8-7@gated-at.bofh.it> <rszzB-3p7-25@gated-at.bofh.it> <rszzB-3p7-23@gated-at.bofh.it>
X-Google-Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dqS18x7WcxbLHMiX17HTnTqiPtYoBlETvhoVEd0029k=; b=X7JIkPXqv6VbRMN6H+mOxcVIcYXUfU3xyO1e5bsKqfbSJjNAER2sxO21IOIc8J/Jhq JCf/qYcsETF4h3ovx1tacA5LK69MepMxAf9Ngm+c/6N4CJu/ZfTCCjHqmms5IOnirOsg rDKIyo67DdLN+ZDNOmnuZKILfkz04I7dabcTge9IRIKD5S3MBGKUpl/SixG865XXI1wJ J6J1LSjaVidoZqjHwyc2RCITfOB59RFFOk/jixA9UNq5JbARL6Kwchqq/6lTKbChCYK+ 81qgD96/yQ6ydal3XJxyFdSwHzSBfaYH6AakvG3WBjRUx0T77vzKwDreofq5Pk/3a/Rq UnBA==
X-Gm-Message-State AOPr4FWnrVTbA+qf7AqXRYPK3/kWC6j76QU2meC0jk3uJuElbSgtxqYQTUnUcG1KD0mBz+Kz
X-Received by 10.55.109.7 with SMTP id i7mr10598030qkc.127.1461780997486; Wed, 27 Apr 2016 11:16:37 -0700 (PDT)
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version 1.0
Content-Type text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding 7bit
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 71
Organization linux.* mail to news gateway
X-Original-Cc linux-kernel@vger.kernel.org, Laura Abbott <lauraa@codeaurora.org>, linux-arm@lists.infradead.org, Robin Murphy <robin.murphy@arm.com>, Arnd Bergmann <arnd@arndb.de>, Marek Szyprowski <m.szyprowski@samsung.com>, Mimi Zohar <zohar@linux.vnet.ibm.com>, Andrew Morton <akpm@linux-foundation.org>, Mark Brown <broonie@kernel.org>, Will Deacon <will.deacon@arm.com>, Ming Lei <ming.lei@canonical.com>
X-Original-Date Wed, 27 Apr 2016 11:16:32 -0700
X-Original-Message-ID <57210200.2060405@redhat.com>
X-Original-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>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1389433

Show key headers only | View raw


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 <lauraa@codeaurora.org>
>>>>
>>>> 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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

[RFC/PATCHv2 v2 2/4] dma-mapping: Add dma_remap() APIs Stephen Boyd <stephen.boyd@linaro.org> - 2016-04-20 03:10 +0200
  Re: [RFC/PATCHv2 v2 2/4] dma-mapping: Add dma_remap() APIs Catalin Marinas <catalin.marinas@arm.com> - 2016-04-21 12:40 +0200
    Re: [RFC/PATCHv2 v2 2/4] dma-mapping: Add dma_remap() APIs Catalin Marinas <catalin.marinas@arm.com> - 2016-04-27 17:30 +0200
      Re: [RFC/PATCHv2 v2 2/4] dma-mapping: Add dma_remap() APIs Laura Abbott <labbott@redhat.com> - 2016-04-27 20:20 +0200

csiph-web