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

[Jie, Yang]

> -----Original Message-----
> From: Liam Girdwood [mailto:liam.r.girdwood@xxxxxxxxxxxxxxx]
> Sent: Wednesday, August 26, 2015 4:07 PM
> To: Jie, Yang
> Cc: Takashi Iwai; Dmitry Torokhov; Luis R. Rodriguez;
> joonas.lahtinen@xxxxxxxxxxxxxxx; Tom Gundersen; Ming Lei; Al Viro; Greg
> Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; Luis
> Rodriguez; lkml; yalin wang
> Subject: Re: Problems loading firmware using built-in drivers with kernels
> that use initramfs.
> 
> 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.
> > >
> > > 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.

Yep, this case is quite similar with what Linus described.
 
Is it possible that we can probe pcm device after firmware is loaded for this
case?

What I am thinking about is postponing all firmware related(e.g. pcm probing,
dma/dsp/ipc initialization, ...) code to that rootfs is ready and FW is loaded.

~Keyon

> 
> Liam
>