Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756784AbbHZIbV (ORCPT ); Wed, 26 Aug 2015 04:31:21 -0400 Received: from mga03.intel.com ([134.134.136.65]:55866 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755582AbbHZIbR (ORCPT ); Wed, 26 Aug 2015 04:31:17 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,415,1437462000"; d="scan'208";a="755610041" From: "Jie, Yang" To: Liam Girdwood CC: Takashi Iwai , Dmitry Torokhov , "Luis R. Rodriguez" , "joonas.lahtinen@linux.intel.com" , Tom Gundersen , Ming Lei , Al Viro , "Greg Kroah-Hartman" , Kay Sievers , Linus Torvalds , David Woodhouse , Luis Rodriguez , lkml , yalin wang , "Lin, Mengdong" Subject: RE: Problems loading firmware using built-in drivers with kernels that use initramfs. Thread-Topic: Problems loading firmware using built-in drivers with kernels that use initramfs. Thread-Index: AQHQ3q55Gv2R73fENk2leYdv1OZYrJ4b1gEAgACajKCAACX+AIAAA4oAgAADMYCAAR8o0P//gVwAgACPkzD//5toAIAAiajQ Date: Wed, 26 Aug 2015 08:29:41 +0000 Message-ID: References: <1440449403.2469.35.camel@loki> <1440489900.2419.4.camel@loki> <20150825193408.GR8051@wotan.suse.de> <1440576394.2443.17.camel@loki> In-Reply-To: <1440576394.2443.17.camel@loki> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id t7Q8VS4K023750 Content-Length: 3222 Lines: 73 > -----Original Message----- > From: Liam Girdwood [mailto:liam.r.girdwood@linux.intel.com] > Sent: Wednesday, August 26, 2015 4:07 PM > To: Jie, Yang > Cc: Takashi Iwai; Dmitry Torokhov; Luis R. Rodriguez; > joonas.lahtinen@linux.intel.com; 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@suse.de] > > > Sent: Wednesday, August 26, 2015 1:33 PM > > > To: Jie, Yang > > > Cc: Dmitry Torokhov; Luis R. Rodriguez; Girdwood, Liam R; > > > joonas.lahtinen@linux.intel.com; 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 > ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?