Message-ID: <s5hzk64earo.wl%tiwai@suse.de>
Date:	Thu, 09 Aug 2012 10:21:15 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Thierry Reding <thierry.reding@...onic-design.de>
Cc:	Jaroslav Kysela <perex@...ex.cz>,
	David Henningsson <david.henningsson@...onical.com>,
	alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ALSA: hda - Defer probe when loading patch firmware

At Thu, 9 Aug 2012 10:07:13 +0200,
Thierry Reding wrote:
> 
> On Thu, Aug 09, 2012 at 09:42:48AM +0200, Takashi Iwai wrote:
> > At Thu, 9 Aug 2012 09:36:42 +0200,
> > Thierry Reding wrote:
> > > 
> > > On Thu, Aug 09, 2012 at 09:31:30AM +0200, Takashi Iwai wrote:
> > > > At Thu, 9 Aug 2012 09:08:13 +0200,
> > > > Thierry Reding wrote:
> > > > > 
> > > > > On Thu, Aug 09, 2012 at 08:57:13AM +0200, Takashi Iwai wrote:
> > > > > > At Thu,  9 Aug 2012 08:45:23 +0200,
> > > > > > Thierry Reding wrote:
> > > > > > > 
> > > > > > > Recent changes to the firmware loading helpers cause drivers to stall
> > > > > > > when firmware is loaded during the module_init() call. The snd-hda-intel
> > > > > > > module requests firmware if the patch= parameter is used to load a patch
> > > > > > > file. This patch works around the problem by deferring the probe in such
> > > > > > > cases, which will cause the module to load successfully and the driver
> > > > > > > binding to the device outside the module_init() call.
> > > > > > 
> > > > > > Is the "recent" change meant 3.6 kernel, or in linux-next?
> > > > > > 
> > > > > > In anyway, I don't understand why such a change was allowed.  Most
> > > > > > drivers do call request_firmware() at the device probing time.
> > > > > > If this really has to be resolved in the driver side, it must be a bug
> > > > > > in the firmware loader core code.
> > > > > 
> > > > > A good explanation of the problem and subsequent discussion can be found
> > > > > here:
> > > > > 
> > > > > 	http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/49975
> > > > 
> > > > Yeah, but it doesn't justify this ugly module option.
> > > > It's a simple bug.  Papering over it with this option doesn't fix
> > > > anything.
> > > 
> > > It's not an option, all it does is defer probing if and only if the
> > > patch parameter was specified to make sure the firmware load won't
> > > stall. I realize that this may not be an optimal solution, but at least
> > > it fixes the problem with no fallout.
> > 
> > Ah sorry, I misread the patch.
> > 
> > Then it shouldn't be checked at that point.  Since 3.5 kernel, the
> > probing code was already split for vga_switcheroo support.
> 
> Yes, I saw that. But unless you actually use vga_switcheroo, the second
> stage, azx_probe_continue(), will still be called from azx_probe() and
> therefore ultimately from module_init().

Yeah, but this could be easily delayed.  The split was already done,
so the next step would be to return after the first half at probe,
then call the second half later.

> Before coming up with this patch I actually did play around a bit with
> using the asynchronous firmware load functions but it turned out to be
> rather difficult to do so I opted for the easy way. The biggest problem
> I faced was that since patch loading needs to be done very early on, a
> lot of the initialization would need to be done after .probe() and many
> things could still fail, so cleaning up after errors would become
> increasingly difficult.

async probe is also on my TODO list, but it's deferred ;)

> > The point you added is the second stage.
> 
> I don't understand this sentence.

I meant that your patch added the check at the second-half probing
function (azx_probe_contine()).  That is, it could be already the
point triggered by vga_switcheroo handler, not via module_init any
longer.

So, after rethinking what you suggested, I wrote a quick patch below.
Could you check whether this works?


Takashi

---
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index c8aced1..4e5839a 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -559,13 +559,17 @@ enum {
  * VGA-switcher support
  */
 #ifdef SUPPORT_VGA_SWITCHEROO
+#define use_vga_switcheroo(chip)	((chip)->use_vga_switcheroo)
+#else
+#define use_vga_switcheroo(chip)	0
+#endif
+
+#if defined(SUPPORT_VGA_SWITCHEROO) || defined(CONFIG_SND_HDA_PATCH_LOADER)
 #define DELAYED_INIT_MARK
 #define DELAYED_INITDATA_MARK
-#define use_vga_switcheroo(chip)	((chip)->use_vga_switcheroo)
 #else
 #define DELAYED_INIT_MARK	__devinit
 #define DELAYED_INITDATA_MARK	__devinitdata
-#define use_vga_switcheroo(chip)	0
 #endif
 
 static char *driver_short_names[] DELAYED_INITDATA_MARK = {
@@ -3154,6 +3158,20 @@ static int __devinit azx_probe(struct pci_dev *pci,
 	struct azx *chip;
 	int err;
 
+#ifdef CONFIG_SND_HDA_PATCH_LOADER
+	/* delayed probe */
+	card = pci_get_drvdata(pci);
+	if (card) {
+		struct azx *chip = card->private_data;
+		if (chip->disabled)
+			return 0; /* will be loaded via vga_switcheroo */
+		err = azx_probe_continue(chip);
+		if (err < 0)
+			goto out_free;
+		return 0;
+	}
+#endif
+
 	if (dev >= SNDRV_CARDS)
 		return -ENODEV;
 	if (!enable[dev]) {
@@ -3175,19 +3193,28 @@ static int __devinit azx_probe(struct pci_dev *pci,
 		goto out_free;
 	card->private_data = chip;
 
+#ifndef CONFIG_SND_HDA_PATCH_LOADER
+	/* continue probing if no patch loader is required */
 	if (!chip->disabled) {
 		err = azx_probe_continue(chip);
 		if (err < 0)
 			goto out_free;
 	}
+#endif
 
 	pci_set_drvdata(pci, card);
 
 	dev++;
+
+#ifdef CONFIG_SND_HDA_PATCH_LOADER
+	return -EPROBE_DEFER; /* continue probing later for request_firmware() */
+#else
 	return 0;
+#endif
 
 out_free:
 	snd_card_free(card);
+	pci_set_drvdata(pci, NULL);
 	return err;
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists