[alsa-devel] [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[David Henningsson]

On 2015-11-26 10:24, Takashi Iwai wrote:
> On Thu, 26 Nov 2015 10:16:17 +0100,
> Zhang, Xiong Y wrote:
>>
>>
>>> On Thu, 26 Nov 2015 08:57:30 +0100,
>>> Zhang, Xiong Y wrote:
>>>>
>>>>>>> BTW, I have a patchset to avoid the audio h/w wakeup by a new
>>>>>>> component ops to get ELD and connection states.  It was posted to
>>>>>>> alsa-devel shortly ago just as a reference, but this should work well
>>>>>>> in such a case, too.  The test patches are found in test/hdmi-jack
>>>>>>> branch of my sound git tree.
>>>>>
>>>>> Did you try this branch (merge onto intel-test-nightly)?
>>>>>
>>>> [Zhang, Xiong Y] Yes, this branch could fix my issue.
>>>
>>> OK, good to hear.  But this isn't for 4.4 or backport, as it's more
>>> radical changes.
>>>
>>> Could you check the patch below instead?  This suppresses the notifier
>>> handling during suspend.  It's bad, but the hotplug should be still
>>> handled via normal unsol event, so it should keep working, good enough
>>> as a stop gap.
>>>
>>>
>>> Takashi
>>>
>>> ---
>>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
>>> index bdb6f226d006..f7c70e2ae65c 100644
>>> --- a/sound/pci/hda/patch_hdmi.c
>>> +++ b/sound/pci/hda/patch_hdmi.c
>>> @@ -33,6 +33,7 @@
>>>   #include <linux/delay.h>
>>>   #include <linux/slab.h>
>>>   #include <linux/module.h>
>>> +#include <linux/pm_runtime.h>
>>>   #include <sound/core.h>
>>>   #include <sound/jack.h>
>>>   #include <sound/asoundef.h>
>>> @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int
>>> port)
>>>   	struct hda_codec *codec = audio_ptr;
>>>   	int pin_nid = port + 0x04;
>>>
>>> -	check_presence_and_report(codec, pin_nid);
>>> +	if (!atomic_read(&codec->core.in_pm) &&
>>> +	    !pm_runtime_suspended(hda_codec_dev(codec)))
>>> +		check_presence_and_report(codec, pin_nid);
>>>   }
>>>
>>>   static int patch_generic_hdmi(struct hda_codec *codec)
>> [Zhang, Xiong Y]  this patch couldn't remove the error message. So audio controller isn't in Runtime D3 after azx_suspend().
>
> OK, then the problem isn't about the HD-audio driver but rather i915
> driver.  As already mentioned, i915 driver shouldn't issue eld_notify
> callback in the suspend code path.

We don't have a complete drm log so I'm only speculating here; but the 
HDA log seems to indicate the power well is off when we try to talk to 
the HDA controller. That means either the i915 shut it down while we 
were holding a lock on it, or HDA tried to lock it and that didn't make 
it through; in which case the HDA side should handle an error from 
get_power more gracefully...?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic