Date: Thu, 21 Apr 2016 11:35:12 +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: <20160421103512.GC23774@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1461114269-13718-3-git-send-email-stephen.boyd@linaro.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1468
Lines: 33

Hi Stephen,

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?

-- 
Catalin