From: Stephen Boyd <stephen.boyd@linaro.org>
To: Alexander Stein <alexander.stein@systec-electronic.com>,
linux-kernel@vger.kernel.org
Cc: linux-arm@lists.infradead.org,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.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>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will.deacon@arm.com>
Subject: Re: [RFC/PATCH 0/4] request_firmware() on memory constrained devices
Date: Tue, 08 Mar 2016 17:07:38 +0700 [thread overview]
Message-ID: <20160308100738.5222.1570@sboyd-linaro> (raw)
In-Reply-To: <5879185.BRRaoAY1zb@ws-stein>
Quoting Alexander Stein (2016-03-08 16:32:21)
> On Tuesday 08 March 2016 16:22:15, Stephen Boyd wrote:
> > Some systems are memory constrained but they need to load very
> > large firmwares.
>
> Out of curiousity, about which sizes of memory and firmware are you talking about?
>
Hm.. I've seen an extreme case where there's around 100MB of a 128MB DDR
part dedicated to non-Linux firmware. So attempting to load that
firmware into DDR just doesn't work at all unless you have this patch
series. This is the most extreme case I've seen though.
Please also note that this is also about skipping the memcpy() step,
which I should probably quantify how much that actually matters if at
all. I'll make sure to do some loading time measurements in the next
round.
prev parent reply other threads:[~2016-03-08 10:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-08 9:22 [RFC/PATCH 0/4] request_firmware() on memory constrained devices Stephen Boyd
2016-03-08 9:22 ` [PATCH 1/4] ARM64: dma: Add support for NO_KERNEL_MAPPING attribute Stephen Boyd
2016-03-08 13:58 ` Robin Murphy
2016-03-08 9:22 ` [RFC/PATCH 2/4] dma-mapping: Add dma_remap() APIs Stephen Boyd
2016-03-08 9:22 ` [RFC/PATCH 3/4] firmware_class: Provide infrastructure to make fw caching optional Stephen Boyd
2016-03-08 9:22 ` [RFC/PATCH 4/4] firmware: Support requesting firmware directly into DMA memory Stephen Boyd
2016-03-08 11:58 ` Mimi Zohar
[not found] ` <20160412172708.28213.21206@sboyd-linaro>
2016-04-12 23:04 ` Mimi Zohar
2016-03-08 13:42 ` Ming Lei
2016-03-09 2:29 ` Mark Brown
2016-03-08 9:32 ` [RFC/PATCH 0/4] request_firmware() on memory constrained devices Alexander Stein
2016-03-08 10:07 ` Stephen Boyd [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160308100738.5222.1570@sboyd-linaro \
--to=stephen.boyd@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.stein@systec-electronic.com \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=labbott@redhat.com \
--cc=linux-arm@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=robin.murphy@arm.com \
--cc=will.deacon@arm.com \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).