Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

From	yalin wang <yalin.wang2010@gmail.com>
Newsgroups	linux.kernel
Subject	Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
Date	2015-08-26 07:40 +0200
Message-ID	<q1BBf-4SM-3@gated-at.bofh.it> (permalink)
References	(2 earlier) <q1seC-7G4-9@gated-at.bofh.it> <q1seC-7G4-3@gated-at.bofh.it> <q1soh-7Tn-7@gated-at.bofh.it> <q1sxZ-870-23@gated-at.bofh.it> <q1t10-vU-29@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

> 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











--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Thread

csiph-web