Date: Wed, 27 Apr 2016 16:25:24 +0100
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stephen Boyd <stephen.boyd@linaro.org>
Cc: linux-kernel@vger.kernel.org, Laura Abbott <lauraa@codeaurora.org>,
        linux-arm@lists.infradead.org, Robin Murphy <robin.murphy@arm.com>,
        Laura Abbott <labbott@redhat.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>
Subject: Re: [RFC/PATCHv2 v2 2/4] dma-mapping: Add dma_remap() APIs
Message-ID: <20160427152524.GD20646@e104818-lin.cambridge.arm.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160423003516.12876.30413@sboyd-linaro>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3162
Lines: 64

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.

-- 
Catalin