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

[Liam Girdwood]

On Wed, 2015-08-26 at 07:17 +0100, Jie, Yang wrote:
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@xxxxxxx]
> > Sent: Wednesday, August 26, 2015 1:33 PM
> > To: Jie, Yang
> > Cc: Dmitry Torokhov; Luis R. Rodriguez; Girdwood, Liam R;
> > joonas.lahtinen@xxxxxxxxxxxxxxx; Tom Gundersen; Ming Lei; Al Viro; Greg
> > Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; Luis
> > Rodriguez; lkml
> > Subject: Re: Problems loading firmware using built-in drivers with kernels
> > that use initramfs.
> > 
> > On Wed, 26 Aug 2015 07:12:46 +0200,
> > Jie, Yang wrote:
> > >
> > > > -----Original Message-----
> > > > From: Dmitry Torokhov [mailto:dmitry.torokhov@xxxxxxxxx]
> > > > Sent: Wednesday, August 26, 2015 3:58 AM
> > > > To: Takashi Iwai
> > > > Cc: Luis R. Rodriguez; Girdwood, Liam R; Jie, Yang;
> > > > joonas.lahtinen@xxxxxxxxxxxxxxx; Tom Gundersen; Ming Lei; Al Viro;
> > > > Greg Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse;
> > > > Luis Rodriguez; lkml
> > > > Subject: Re: Problems loading firmware using built-in drivers with
> > > > kernels that use initramfs.
> > > >
> > > > On Tue, Aug 25, 2015 at 12:46 PM, Takashi Iwai <tiwai@xxxxxxx> wrote:
> > > > > On Tue, 25 Aug 2015 21:34:08 +0200, Luis R. Rodriguez wrote:
> > > > >>
> > > > >> On Tue, Aug 25, 2015 at 10:17:00AM +0100, David Woodhouse wrote:
> > > > >> > Luis, did you tell me the other day that you made the kernel
> > > > >> > get firmware directly from the file system? This regression
> > > > >> > would be yours
> > > > then?
> > > > >>
> > > > >> I didn't implement that, Linus did in 2012 (see commit
> > > > >> abb139e75c2c titled
> > > > >> "firmware: teach the kernel to load firmware files directly from
> > > > >> the filesystem"). But we used to fallback to a userspace helper
> > > > >> when the fw was not present and then Takashi made this optional
> > > > >> via commit 7b1269f778782d titled "firmware: Make user-mode helper
> > optional".
> > > > >> Takashi noted in the Kconfig "The user-mode helper is no longer
> > > > >> required unless you have a special firmware file that resides in
> > > > >> a non-standard path". It was not clarified why that's true
> > > > >> though, or what you'd need to do to ensure that the fw would be
> > > > >> available. It would be good for us to elaborate on that.
> > > > >
> > > > > The recent udev already dropped the firmware loading feature.
> > > >
> > > > Note that even when we had udev helper to load the firmware it was
> > > > not always reliable depending on the exact point where we requested
> > firmware.
> > > > If request happened in probe() path before we mounted root fs then
> > > > we'd never get it loaded because we'd be waiting for devices settle
> > > > before mounting rootfs.
> > >
> > > For request in probe(), is it possible to use
> > > request_firmware_nowait() to wait rootfs mounted or timeout in another
> > thread?
> > >
> > > It looks usermodehelper_disabled is 0(at probe()) at this case then no
> > > waiting occurs here in our testing.
> > 
> > It's possible -- and even with the normal request_firmware(), in theory.  The
> > missing piece is that you need to inform the helper to retry the f/w loading.
> > Currently the direct f/w loader assumes that the file is there and returns
> > error if not present.
> > 
> > If we implement a retry, another question is how to trigger it, i.e. how the
> > helper can know when a fs is mounted a new file is present.
>  
> Got it, thanks Takashi and all.
> 
> So looks we should(and already done for most audio firmware) implement it 
> as Dmitry and Linus proposed, that is to make sure request_firmware() calls
> are not in driver's probe() paths.
> 
> Yalin help posted sample code for this implementation(to request firmware
> in device node open) and actually I also did similar for Broadwell ADSP driver
> and will send out later, thank you all.

Keyon, we have a similar situation to that of the FPGA example that
Linus described when the DSP driver uses topology data. i.e. the audio
driver will have no PCM devices that can be opened (to initiate the FW
loading) until after the FW is loaded. The topology data is part of the
FW and contains the PCMs, kcontrols, graphs etc. i.e. a PCM device is
created for every PCM description found in the FW topology data. 

I think the options are to either :-

1) Don not support audio DSP drivers using topology data as built-in
drivers. Audio is not really a critical system required for booting
anyway.

2) Create a default PCM for every driver that has topology data on the
assumption that every sound card will at least 1 PCM. This PCM can then
be re-configured when the FW is loaded. 

Liam


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