[<prev] [next>] [day] [month] [year] [list]
Message-ID: <s5h1s9qv7ui.wl-tiwai@suse.de>
Date: Tue, 18 Sep 2018 23:00:53 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Paul Menzel <pmenzel+alsa-devel@...gen.mpg.de>
Cc: alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: snd_hda_codec_hdmi: `hdaudio hdaudioC0D2: Unable to bind the codec`
On Tue, 18 Sep 2018 17:55:15 +0200,
Paul Menzel wrote:
>
> Dear Linux folks,
>
>
> With drm-tip (v4.19-rc3-946-g09b295662edd) Linux prints
> `snd_hda_codec_hdmi hdaudioC0D2: No i915 binding for Intel HDMI/DP codec`
> to the log.
>
> ```
> […]
> [ 12.481788] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC671: line_outs=1 (0x21/0x0/0x0/0x0/0x0) type:line
> [ 12.482536] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=1 (0x17/0x0/0x0/0x0/0x0)
> [ 12.483184] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x14/0x0/0x0/0x0/0x0)
> [ 12.483737] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0
> [ 12.484198] snd_hda_codec_realtek hdaudioC0D0: inputs:
> [ 12.484582] snd_hda_codec_realtek hdaudioC0D0: Front Mic=0x19
> [ 12.485100] snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18
> [ 12.485519] snd_hda_codec_realtek hdaudioC0D0: Line=0x1a
> [ 12.497685] snd_hda_codec_hdmi hdaudioC0D2: No i915 binding for Intel HDMI/DP codec
> [ 12.498311] hdaudio hdaudioC0D2: Unable to bind the codec
> [ 12.498789] input: HDA Intel PCH Front Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input6
> [ 12.499567] input: HDA Intel PCH Rear Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input7
> [ 12.500268] input: HDA Intel PCH Line as /devices/pci0000:00/0000:00:1f.3/sound/card0/input8
> [ 12.501039] input: HDA Intel PCH Line Out as /devices/pci0000:00/0000:00:1f.3/sound/card0/input9
> [ 12.501683] input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input10
> [ 17.743338] [drm:intel_pch_type [i915]] Found SunrisePoint PCH
> […]
> ```
>
> Is that an error or just a notice?
This must be a side-effect of the recent change in i915 to be async
probe. This made me checking the corresponding ALSA audio binding
code change, and actually found a bug.
Could you try the fix below?
thanks,
Takashi
-- 8< --
From: Takashi Iwai <tiwai@...e.de>
Subject: [PATCH] ALSA: hda: Fix the audio-component completion timeout
The timeout of audio component binding was incorrectly specified in
msec, not in jiffies, which results in way too shorter timeout than
expected.
Along with fixing it, add the information print about the binding
failure to show the unexpected situation more clearly.
Fixes: a57942bfdd61 ("ALSA: hda: Make audio component support more generic")
Signed-off-by: Takashi Iwai <tiwai@...e.de>
---
sound/hda/hdac_i915.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
index b5282cbbe489..617ff1aa818f 100644
--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -145,9 +145,11 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
if (!acomp->ops) {
request_module("i915");
/* 10s timeout */
- wait_for_completion_timeout(&bind_complete, 10 * 1000);
+ wait_for_completion_timeout(&bind_complete,
+ msecs_to_jiffies(10 * 1000));
}
if (!acomp->ops) {
+ dev_info(bus->dev, "couldn't bind with audio component\n");
snd_hdac_acomp_exit(bus);
return -ENODEV;
}
--
2.18.0
Powered by blists - more mailing lists