[alsa-devel] [PATCH] ALSA: hda - delay resume haswell hdmi codec in system resume

[David Henningsson]

On 04/08/2013 01:59 PM, Takashi Iwai wrote:
> At Mon, 08 Apr 2013 13:35:25 +0200,
> David Henningsson wrote:
>>
>> On 04/08/2013 01:06 PM, Lin, Mengdong wrote:
>>>> -----Original Message-----
>>>> From: Takashi Iwai [mailto:tiwai at suse.de]
>>>> Sent: Monday, April 08, 2013 6:24 PM
>>>> To: David Henningsson
>>>> Cc: Lin, Mengdong; alsa-devel at alsa-project.org
>>>> Subject: Re: [alsa-devel] [PATCH] ALSA: hda - delay resume haswell hdmi codec
>>>> in system resume
>>>>
>>>> At Mon, 08 Apr 2013 11:49:09 +0200,
>>>> David Henningsson wrote:
>>>>>
>>>>> I'm still not understanding this patch.
>>>>>
>>>>> We of course cannot have a situation where HDMI jack detection is not
>>>>> correctly working after S3, which looks like would be the case here?
>>>>
>>>> No.  The patch itself has nothing to do with the HDMI jack detection at all.
>>>> This intrinsic unsol event is (according to Intel) guaranteed to be issued once at
>>>> the audio codec initialization, at least for Haswell.
>>
>> Well, if no process is using the HDMI codec actively, nothing will
>> initialize the resume, and the HDMI codec will not initialized at all, i
>> e, no unsol events enabled in the first place?
>
> No, the intrinsic unsol event that is issued for this seems irrelevant
> from the jack state (i.e. active usage).
>
>> (The counter argument would be; if nobody uses HDMI codec, does it
>> matter that it is not initialized, but I'm unsure if e g "amixer
>> contents" or listeners on legacy /dev/input actually powers up the chip.)
>
> The problem is that the codec resume is always performed no matter
> whether the device is used or not.  This was different in the past but
> it's been changed in that way because there are cases where you need
> to initialize the hardware properly once (e.g. mute-LED toggling).
>
>
>>>>> Second, I just saw on a machine we're working on, the symptoms: one of
>>>>> the pins in D3 and the right channel muted. And this was on a clean
>>>>> boot, not after S3 suspend/resume cycle.
>>>>
>>>> Maybe another problem.  Maybe not.  Does the problem persist if you reload
>>>> the driver (without invocation of alsactl via udev)?
>>>
>>> Hi Takashi and David,
>>>
>>> This is the same dependency issue as after system suspend/resume cycles, with same phenomenon.
>>> I duplicated this error if I boot without an HDMI/DP cable connected and connect the cable later.
>>> Maybe we need to delay codec operations on initialization like in resume case.
>>
>> So it's a problem both on hotplug and S3...
>
> In the case of hotplug, you don't hit the inconsistent power sate
> we're trying to solve.  The graphics has been already powered up.
>
>
>>>>> To look at the problem again: If the problem is that something must be
>>>>> done on the graphics driver side first and then on the audio side,
>>>>> wouldn't the solution be for the video driver and audio driver to
>>>>> communicate somehow?
>>>>
>>>> Yes, the pm domain support is necessary sooner or later, as I already discussed
>>>> shortly with Dave Airlie.  However...
>>>
>>> Liam will propose Gfx driver team to implement a pm domain.
>>>
>>>>> And resume (and possibly init?) would not complete until first the
>>>>> graphics driver has done its resume, and after that, the audio driver.
>>>>> I e, userspace will remain frozen until both drivers have completed a
>>>>> correct resume.
>>>>
>>>> ... the resume problem can't be fixed only by the usual pm domain serialization.
>>>> The graphics initialization for the audio bit is done asynchronously, thus we
>>>> can't guarantee the audio codec is really ready after the graphics driver returns
>>>> from the resume callback.
>>>> It shows as if it's ready (you can turn it to D0) but actually it doesn't change on
>>>> the hardware.  Thus, the serialization with an unsol event wait seems
>>>> mandatory for the time being.
>>>>
>>> It seems so. We have not found better solution now :-(
>>> I've revised the patch for system suspend/resume case. Please review.
>>
>> If this problem can be detected by looking at the pin and finding that
>> it is in D3,
>
> No, you can't see that it's D3.  The controller chip _shows_ it's in
> D0 while it's actually in D3.  That's the problem.
>
> So, this is actually a hardware design bug.  But we need to live with
> that.

Then I'm not sure it's the same problem; because for me I can see the D3 
in the codec proc output.




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