From: yalin wang <yalin.wang2010@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Takashi Iwai <tiwai@suse.de>,
"Luis R. Rodriguez" <mcgrof@suse.com>,
Liam Girdwood <liam.r.girdwood@intel.com>,
"Jie, Yang" <yang.jie@intel.com>,
joonas.lahtinen@linux.intel.com, Tom Gundersen <teg@jklm.no>,
Ming Lei <ming.lei@canonical.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Kay Sievers <kay@vrfy.org>, David Woodhouse <dwmw2@infradead.org>,
Luis Rodriguez <mcgrof@do-not-panic.com>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
Date: Wed, 26 Aug 2015 13:30:21 +0800 [thread overview]
Message-ID: <2B38A5C9-8940-464D-B473-CF62E8BD84C4@gmail.com> (raw)
In-Reply-To: <CA+55aFxcC=RFzpk0AF68krv6UtazT1cmaQoKgz5+dY9Zzcu4Kg@mail.gmail.com>
> On Aug 26, 2015, at 04:26, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Tue, Aug 25, 2015 at 12:58 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>>
>> Either build firmware in the kernel or ramdisk (so it is always
>> available), or make sure request_firmware() calls are not in driver's
>> probe() paths.
>
> The correct answer is almost always that second one.
>
> Drivers that load firmware in their probe parts are generally doign
> things wrong.
>
> It's very occasionally the right thing to do - there are a few pieces
> of hardware where just about _everything_ about the device is in the
> firmware, and you simply can't even problem them before that, because
> you don't know what they *are* before the firmware has been loaded.
> The extreme case of that might be something like the base hardware
> being an FPGA that has a USB interface, but before the FPGA has been
> loaded, it basically has no identity. So there are probably valid
> cases in theory for loading firmware at probe time, but pretty much
> every single case I've ever actually seen, the probe knows what the
> actual hardware is from some identifiable piece, and the actual
> firmware loading should be delayed until the piece of hardware is
> actually opened.
>
> So the "load firmware in probe routine" happens, and we shouldn't
> disallow it, but it should be considered a "last resort" kind of
> thing.
>
> In general, things like sound drivers should *not* need to have their
> firmware in the initrd, even if you build them into the kernel. A disk
> driver? Yes. Maybe the root filesystem is on that disk, and you need
> the firmware for the disk driver to load it. But a sound device?
> Please just make sure that you load the firmware as late as possible.
>
i remember lots of drivers load their firmware when some user space process
open the device node, that is to say, they load the firmware in
->open() function, at this time , you can make sure the real filesystem is ready in
most time.
i think your dsp firmware can also do like this.
you can refer to msm gnu driver:
static void load_gpu(struct drm_device *dev)
{
static DEFINE_MUTEX(init_lock);
struct msm_drm_private *priv = dev->dev_private;
mutex_lock(&init_lock);
if (!priv->gpu)
priv->gpu = adreno_load_gpu(dev);
mutex_unlock(&init_lock);
}
static int msm_open(struct drm_device *dev, struct drm_file *file)
{
struct msm_file_private *ctx;
/* For now, load gpu on open.. to avoid the requirement of having
* firmware in the initrd.
*/
load_gpu(dev);
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
file->driver_priv = ctx;
return 0;
}
it load the firmware in open() function.
Thanks
next prev parent reply other threads:[~2015-08-26 5:30 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1440449403.2469.35.camel@loki>
[not found] ` <1440489900.2419.4.camel@loki>
[not found] ` <rbhuamrc6ajy3l1qereb60l8.1440494220682@email.android.com>
2015-08-25 19:34 ` Problems loading firmware using built-in drivers with kernels that use initramfs Luis R. Rodriguez
2015-08-25 19:46 ` Takashi Iwai
2015-08-25 19:58 ` Dmitry Torokhov
2015-08-25 20:26 ` Linus Torvalds
2015-08-26 5:30 ` yalin wang [this message]
2015-08-26 5:12 ` Jie, Yang
2015-08-26 5:32 ` Takashi Iwai
2015-08-26 6:17 ` Jie, Yang
2015-08-26 8:06 ` Liam Girdwood
2015-08-26 8:29 ` Jie, Yang
2015-08-26 9:00 ` Liam Girdwood
2015-08-27 1:50 ` Lin, Mengdong
2015-08-27 7:09 ` Liam Girdwood
2015-08-26 18:07 ` Linus Torvalds
2015-08-27 0:55 ` Ming Lei
2015-08-29 1:11 ` Luis R. Rodriguez
2015-08-29 4:09 ` Ming Lei
2015-08-29 7:11 ` Takashi Iwai
2015-08-29 8:50 ` Arend van Spriel
2015-08-29 10:38 ` Ming Lei
2015-08-30 8:25 ` Arend van Spriel
2015-08-30 18:11 ` Linus Torvalds
2015-12-17 19:24 ` Luis R. Rodriguez
2015-08-31 14:21 ` Ming Lei
2015-09-02 1:19 ` Luis R. Rodriguez
2015-09-02 12:09 ` Arend van Spriel
2015-09-02 12:13 ` Arend van Spriel
2015-09-02 18:58 ` Luis R. Rodriguez
2015-09-02 21:03 ` Arend van Spriel
2015-09-02 23:13 ` Dmitry Torokhov
2015-09-02 23:22 ` Luis R. Rodriguez
2015-09-02 23:29 ` Dmitry Torokhov
2015-09-02 23:46 ` Luis R. Rodriguez
2015-09-03 17:23 ` Arend van Spriel
2015-09-03 17:33 ` Dmitry Torokhov
2015-10-16 19:35 ` Luis R. Rodriguez
2015-10-16 21:05 ` Luis R. Rodriguez
2015-10-17 8:31 ` Arend van Spriel
2015-09-02 20:43 ` Dmitry Torokhov
2015-09-02 0:39 ` Luis R. Rodriguez
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=2B38A5C9-8940-464D-B473-CF62E8BD84C4@gmail.com \
--to=yalin.wang2010@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=dwmw2@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kay@vrfy.org \
--cc=liam.r.girdwood@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@do-not-panic.com \
--cc=mcgrof@suse.com \
--cc=ming.lei@canonical.com \
--cc=teg@jklm.no \
--cc=tiwai@suse.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=yang.jie@intel.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).