Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752135AbbH2Iuo (ORCPT ); Sat, 29 Aug 2015 04:50:44 -0400 Received: from mail-gw1-out.broadcom.com ([216.31.210.62]:31542 "EHLO mail-gw1-out.broadcom.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751568AbbH2Iul (ORCPT ); Sat, 29 Aug 2015 04:50:41 -0400 X-IronPort-AV: E=Sophos;i="5.17,429,1437462000"; d="scan'208";a="73794303" Message-ID: <55E1724E.6040303@broadcom.com> Date: Sat, 29 Aug 2015 10:50:22 +0200 From: Arend van Spriel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Takashi Iwai , Ming Lei CC: "Luis R. Rodriguez" , Linus Torvalds , Liam Girdwood , "Jie, Yang" , "Dmitry Torokhov" , "joonas.lahtinen@linux.intel.com" , Tom Gundersen , Al Viro , Greg Kroah-Hartman , Kay Sievers , David Woodhouse , "Luis Rodriguez" , lkml , yalin wang Subject: Re: Problems loading firmware using built-in drivers with kernels that use initramfs. References: <20150825193408.GR8051@wotan.suse.de> <1440576394.2443.17.camel@loki> <20150829011130.GK8051@wotan.suse.de> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3805 Lines: 87 On 08/29/2015 09:11 AM, Takashi Iwai wrote: > On Sat, 29 Aug 2015 06:09:01 +0200, > Ming Lei wrote: >> >> On Sat, Aug 29, 2015 at 9:11 AM, Luis R. Rodriguez wrote: >>> On Thu, Aug 27, 2015 at 08:55:13AM +0800, Ming Lei wrote: >>>> On Thu, Aug 27, 2015 at 2:07 AM, Linus Torvalds >>>> wrote: >>>>> On Wed, Aug 26, 2015 at 1:06 AM, Liam Girdwood >>>>> wrote: >>>>>> >>>>>> 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. >>>>> >>>>> Yes, forcing it to be a module and not letting people compile it in by >>>>> mistake (and then not have it work) is an option. >>>>> >>>>> That said, there are situations where people don't want to use >>>>> modules. I used to eschew them for security reasons, for example - now >>>>> I instead just do a one-time temporary key. But others may have other >>>>> reasons to try to avoid modules. >>>>> >>>>>> 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. >>>>> >>>>> That would seem to be the better option if it is reasonably implementable. >>>>> >>>>> Of course, some kind of timer-based retry (limited *somehow*) of the >>>>> fw loading could work too, but smells really really hacky. >>>> >>>> Yeah, years ago, we discussed to use -EPROBE_DEFER for the situation, >>>> which should be one kind of fix, but looks there were objections at that time. >>> >>> That would still be a hack. I'll note there is also asynchronous probe support >>> now but to use that would also be a hack for this issue. We don't want to >> >> If we think firmware as one kind of resources like regulators, gpio and others, >> PROBE_DEFER is one good match for firmware loading case, and >> it has been used by lots of drivers, so why can't it be used for >> firmware loading? >> >> One problem is that we need to convert drivers into returning -EPROBE_DEFER >> in case of request failure, and that may involve some work, but which >> should be mechanical. > > I find such a delaying mechanism not so bad, too. It's very > straightforward, at least, no big pain in the transition in the driver > side. Not sure how this is going to work with request_firmware_nowait(). We use that in our drivers to get rid of ~60 sec. delay in probe and consequently boot time when built-in. So basically we return 0 on probe lacking better knowledge. Guess we can always move back to request_firmware calls when defer_probe support is available. Regards, Arend >>> encourage folks to go down that road. They'd be hacks for this issue as you >>> are simply delaying the driver probe for a later time and there is no guarantee >>> that any pivot_root() might have already been completed later to ensure your >>> driver's fw file is present. So it may work or it may not. >> >> We can trigger defer probe explicitly once root fs is setup or other condition >> is met. > > Right, how to trigger the reprobe (and relevant optimization) needs to > be considered on top of the current mechanism. > > > Takashi > -- > 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/ > -- 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/