[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160801171951.GC13516@tuxbot>
Date: Mon, 1 Aug 2016 10:19:51 -0700
From: Bjorn Andersson <bjorn.andersson@...aro.org>
To: "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc: Arend van Spriel <arend.vanspriel@...adcom.com>,
Daniel Wagner <daniel.wagner@...-carit.de>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Daniel Wagner <wagi@...om.org>,
Bastien Nocera <hadess@...ess.net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Johannes Berg <johannes.berg@...el.com>,
Kalle Valo <kvalo@...eaurora.org>,
Ohad Ben-Cohen <ohad@...ery.com>, linux-input@...r.kernel.org,
linux-kselftest@...r.kernel.org, linux-wireless@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of
completion
On Sat 30 Jul 09:58 PDT 2016, Luis R. Rodriguez wrote:
> On Sat, Jul 30, 2016 at 02:42:41PM +0200, Arend van Spriel wrote:
> > + Luis (again) ;-)
> >
> > On 29-07-16 08:13, Daniel Wagner wrote:
> > > On 07/28/2016 09:01 PM, Bjorn Andersson wrote:
> > >> On Thu 28 Jul 11:33 PDT 2016, Dmitry Torokhov wrote:
> > >>
> > >>> On Thu, Jul 28, 2016 at 09:55:11AM +0200, Daniel Wagner wrote:
> > >>>> From: Daniel Wagner <daniel.wagner@...-carit.de>
> > >>>>
> > >> [..]
> > >>>
> > >>> Do not quite like it... I'd rather asynchronous request give out a
> > >>> firmware status pointer that could be used later on.
> >
> > Excellent. Why not get rid of the callback function as well and have
> > fw_loading_wait() return result (0 = firmware available, < 0 = fail).
> > Just to confirm, you are proposing a new API function next to
> > request_firmware_nowait(), right?
>
> If proposing new firmware_class patches please bounce / Cc me, I've
> recently asked for me to be added to MAINTAINERS so I get these
> e-mails as I'm working on a new flexible API which would allow us
> to extend the firmware API without having to care about the old
> stupid usermode helper at all.
>
In the remoteproc world there are several systems where we see 100+MB of
firmware being loaded. It's unfeasible to have these files in an
initramfs, so we need a way to indicate to the kernel that the
second/primary (or a dedicated firmware partition) is mounted.
We're currently loading these files with request_firmware_nowait(), so
either one can either use kernel modules or the user-helper fallback to
delay the loading until the files are available. (I don't like to
enforce the usage of kernel modules)
I'm open to alternative ways of having firmware loading wait on
secondary filesystems to be mounted, but have not yet tried to tackle
this problem. I do believe something that waits and retries the firmware
load as additional file systems gets mounted would be prettier than
forcing user space to tell us it's time to move on.
Due to the size of these firmware files we release the firmware as soon
as we have copied the content into the appropriate memory segments, so
we're not utilizing the caching mechanisms of the current fw loader.
Regards,
Bjorn
Powered by blists - more mailing lists