HD-audio runtime PM

HD-audio runtime PM

[Takashi Iwai]

Hi,

after my previous fix, the runtime PM seems working stably finally.
However, there seem still some glitches:

1. The wakeup via jack or HDMI/DP detection doesn't seem to work on my
  test machines.  WAKEEN is set properly.  And its value can be read
  correctly at the point of runtime resume, too.

2. We don't change the device to D3 in runtime suspend.  So I guess we
  save little power as of now.

  Actually, setting to D3 and resuming to D0 works fine, as far as I
  tested -- except for HDMI/DP ELD read out on Haswell.  Although ELD
  read doesn't give any errors, the received bytes are corrupted.  In
  my case, the read starts from offset 0x1c.

  The HDMI can be still played even at that state, but then it falls
  back to the stereo 2ch mode, of course.

The tests were performed on both Haswell (DP and LynxPoint-LP) and
IvyBridge (PantherPoint) machines.

The first problem has been present, and it's also the behavior of some
old chips where the codec can't go to sleep with unsol wakeup.  So, in
this regard, it's no regression, per se.  But certainly it's no good
thing.

I thought Mengdong once made WAKEEN working.  Mengdong, do you
remember what was the condition?  Could you check whether the latest
kernel (at best sound git tree for-linus branch) still works?

About the second point: we should do D3 if we do care power, and
that's the very right reason for runtime PM.  But the ELD issue is a
bad bug, and it makes me wonder whether it's a graphics driver side
issue or a codec side.  As a quick workaround, we can implement D3 on
controllers but for Haswell HDMI/DP.

In anyway, this is no urgent issue, clearly targeted for 3.14.
The whole patch series are found in my sound-unstable git tree
test/hda branch.
  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git


thanks,

Takashi

Re: HD-audio runtime PM

[David Henningsson]

On 11/22/2013 12:57 PM, Takashi Iwai wrote:
> Hi,
> 
> after my previous fix, the runtime PM seems working stably finally.
> However, there seem still some glitches:
> 
> 1. The wakeup via jack or HDMI/DP detection doesn't seem to work on my
>   test machines.  WAKEEN is set properly.  And its value can be read
>   correctly at the point of runtime resume, too.

Hi and thanks for working on this.

I've been trying to reproduce the above, but I can't seem to activate
runtime PM at all. I can't seem to get a callback to runtime_suspend,
and further investigation shows that
/sys/class/sound/card0/power/runtime_status shows "unsupported".

And this is on 3.13-rc1, and there *shouldn't* be any Ubuntu specific
stuff or configuration in that kernel.

Any ideas? (Sorry if this is a newbie question..)


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

Re: HD-audio runtime PM

[Takashi Iwai]

At Mon, 25 Nov 2013 07:32:57 +0100,
David Henningsson wrote:
> 
> On 11/22/2013 12:57 PM, Takashi Iwai wrote:
> > Hi,
> > 
> > after my previous fix, the runtime PM seems working stably finally.
> > However, there seem still some glitches:
> > 
> > 1. The wakeup via jack or HDMI/DP detection doesn't seem to work on my
> >   test machines.  WAKEEN is set properly.  And its value can be read
> >   correctly at the point of runtime resume, too.
> 
> Hi and thanks for working on this.
> 
> I've been trying to reproduce the above, but I can't seem to activate
> runtime PM at all. I can't seem to get a callback to runtime_suspend,
> and further investigation shows that
> /sys/class/sound/card0/power/runtime_status shows "unsupported".

You need to adjust power/control of the parent PCM device,
i.e. /sys/devices/pci/*/power/control.  The following udev rule should
work for HD-audio.  Give it a try.

  ACTION=="add", SUBSYSTEM=="pci", ATTR{class}=="0x040300", TEST=="power/control", ATTR{power/control}="auto"


Takashi

Re: HD-audio runtime PM

[David Henningsson]

On 11/25/2013 08:17 AM, Takashi Iwai wrote:
> At Mon, 25 Nov 2013 07:32:57 +0100,
> David Henningsson wrote:
>>
>> On 11/22/2013 12:57 PM, Takashi Iwai wrote:
>>> Hi,
>>>
>>> after my previous fix, the runtime PM seems working stably finally.
>>> However, there seem still some glitches:
>>>
>>> 1. The wakeup via jack or HDMI/DP detection doesn't seem to work on my
>>>   test machines.  WAKEEN is set properly.  And its value can be read
>>>   correctly at the point of runtime resume, too.
>>
>> Hi and thanks for working on this.
>>
>> I've been trying to reproduce the above, but I can't seem to activate
>> runtime PM at all. I can't seem to get a callback to runtime_suspend,
>> and further investigation shows that
>> /sys/class/sound/card0/power/runtime_status shows "unsupported".
> 
> You need to adjust power/control of the parent PCM device,
> i.e. /sys/devices/pci/*/power/control.  The following udev rule should
> work for HD-audio.  Give it a try.
> 
>   ACTION=="add", SUBSYSTEM=="pci", ATTR{class}=="0x040300", TEST=="power/control", ATTR{power/control}="auto"

I tried this rule, but it did not make any difference -
/sys/class/sound/card0/device/power/control was still on. (And I did
proofread the rule...)

I tried "echo auto > /sys/class/sound/card0/device/power/control" -
after that, I had the following:

/sys/class/sound/card0/device/power/control - auto
/sys/class/sound/card0/device/power/runtime_status - active
/sys/class/sound/card0/power/control - auto
/sys/class/sound/card0/power/runtime_status - unsupported

...so it did not seem to help.

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

Re: HD-audio runtime PM

[Takashi Iwai]

At Mon, 25 Nov 2013 10:20:55 +0100,
David Henningsson wrote:
> 
> On 11/25/2013 08:17 AM, Takashi Iwai wrote:
> > At Mon, 25 Nov 2013 07:32:57 +0100,
> > David Henningsson wrote:
> >>
> >> On 11/22/2013 12:57 PM, Takashi Iwai wrote:
> >>> Hi,
> >>>
> >>> after my previous fix, the runtime PM seems working stably finally.
> >>> However, there seem still some glitches:
> >>>
> >>> 1. The wakeup via jack or HDMI/DP detection doesn't seem to work on my
> >>>   test machines.  WAKEEN is set properly.  And its value can be read
> >>>   correctly at the point of runtime resume, too.
> >>
> >> Hi and thanks for working on this.
> >>
> >> I've been trying to reproduce the above, but I can't seem to activate
> >> runtime PM at all. I can't seem to get a callback to runtime_suspend,
> >> and further investigation shows that
> >> /sys/class/sound/card0/power/runtime_status shows "unsupported".
> > 
> > You need to adjust power/control of the parent PCM device,
> > i.e. /sys/devices/pci/*/power/control.  The following udev rule should
> > work for HD-audio.  Give it a try.
> > 
> >   ACTION=="add", SUBSYSTEM=="pci", ATTR{class}=="0x040300", TEST=="power/control", ATTR{power/control}="auto"
> 
> I tried this rule, but it did not make any difference -
> /sys/class/sound/card0/device/power/control was still on. (And I did
> proofread the rule...)

This (and other sound/*) doesn't matter.  Only the entry in the PCI
device counts.  It's the runtime PM of the PCI device after all.
(Remember that the runtime PM callbacks are set only on this device.)

You can put a printk in azx_runtime_suspend().  For Haswell, it should
work as is with 3.13-rc1.

For IvyBridge, check sound-unstable test/hda branch.  I'll try to
merge to sound git tree once after brushing up and submitting for
review.


Takashi

Re: HD-audio runtime PM

[David Henningsson]

On 11/25/2013 10:26 AM, Takashi Iwai wrote:
> At Mon, 25 Nov 2013 10:20:55 +0100,
> David Henningsson wrote:
>>
>> On 11/25/2013 08:17 AM, Takashi Iwai wrote:
>>> At Mon, 25 Nov 2013 07:32:57 +0100,
>>> David Henningsson wrote:
>>>>
>>>> On 11/22/2013 12:57 PM, Takashi Iwai wrote:
>>>>> Hi,
>>>>>
>>>>> after my previous fix, the runtime PM seems working stably finally.
>>>>> However, there seem still some glitches:
>>>>>
>>>>> 1. The wakeup via jack or HDMI/DP detection doesn't seem to work on my
>>>>>   test machines.  WAKEEN is set properly.  And its value can be read
>>>>>   correctly at the point of runtime resume, too.
>>>>
>>>> Hi and thanks for working on this.
>>>>
>>>> I've been trying to reproduce the above, but I can't seem to activate
>>>> runtime PM at all. I can't seem to get a callback to runtime_suspend,
>>>> and further investigation shows that
>>>> /sys/class/sound/card0/power/runtime_status shows "unsupported".
>>>
>>> You need to adjust power/control of the parent PCM device,
>>> i.e. /sys/devices/pci/*/power/control.  The following udev rule should
>>> work for HD-audio.  Give it a try.
>>>
>>>   ACTION=="add", SUBSYSTEM=="pci", ATTR{class}=="0x040300", TEST=="power/control", ATTR{power/control}="auto"
>>
>> I tried this rule, but it did not make any difference -
>> /sys/class/sound/card0/device/power/control was still on. (And I did
>> proofread the rule...)
> 
> This (and other sound/*) doesn't matter.  Only the entry in the PCI
> device counts.  It's the runtime PM of the PCI device after all.
> (Remember that the runtime PM callbacks are set only on this device.)

But /sys/class/sound/card0/device is just a symlink for
/sys/devices/pci0000:00/0000:00:03.0 - is this not the PCI device you're
talking about?

Anyway, power/runtime_status is always active, and power/usage_count is
always 1. (And pulseaudio is not running, and nothing else is using any
/dev/snd/* files.)

> You can put a printk in azx_runtime_suspend().  For Haswell, it should
> work as is with 3.13-rc1.

I guess I could test that, but I doubt it would help...

> For IvyBridge, check sound-unstable test/hda branch.  I'll try to
> merge to sound git tree once after brushing up and submitting for
> review.

Ok. I currently have nothing Ivybridge to check with.


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

Re: HD-audio runtime PM

[Takashi Iwai]

At Mon, 25 Nov 2013 11:25:46 +0100,
David Henningsson wrote:
> 
> On 11/25/2013 10:26 AM, Takashi Iwai wrote:
> > At Mon, 25 Nov 2013 10:20:55 +0100,
> > David Henningsson wrote:
> >>
> >> On 11/25/2013 08:17 AM, Takashi Iwai wrote:
> >>> At Mon, 25 Nov 2013 07:32:57 +0100,
> >>> David Henningsson wrote:
> >>>>
> >>>> On 11/22/2013 12:57 PM, Takashi Iwai wrote:
> >>>>> Hi,
> >>>>>
> >>>>> after my previous fix, the runtime PM seems working stably finally.
> >>>>> However, there seem still some glitches:
> >>>>>
> >>>>> 1. The wakeup via jack or HDMI/DP detection doesn't seem to work on my
> >>>>>   test machines.  WAKEEN is set properly.  And its value can be read
> >>>>>   correctly at the point of runtime resume, too.
> >>>>
> >>>> Hi and thanks for working on this.
> >>>>
> >>>> I've been trying to reproduce the above, but I can't seem to activate
> >>>> runtime PM at all. I can't seem to get a callback to runtime_suspend,
> >>>> and further investigation shows that
> >>>> /sys/class/sound/card0/power/runtime_status shows "unsupported".
> >>>
> >>> You need to adjust power/control of the parent PCM device,
> >>> i.e. /sys/devices/pci/*/power/control.  The following udev rule should
> >>> work for HD-audio.  Give it a try.
> >>>
> >>>   ACTION=="add", SUBSYSTEM=="pci", ATTR{class}=="0x040300", TEST=="power/control", ATTR{power/control}="auto"
> >>
> >> I tried this rule, but it did not make any difference -
> >> /sys/class/sound/card0/device/power/control was still on. (And I did
> >> proofread the rule...)
> > 
> > This (and other sound/*) doesn't matter.  Only the entry in the PCI
> > device counts.  It's the runtime PM of the PCI device after all.
> > (Remember that the runtime PM callbacks are set only on this device.)
> 
> But /sys/class/sound/card0/device is just a symlink for
> /sys/devices/pci0000:00/0000:00:03.0 - is this not the PCI device you're
> talking about?

Ah, ok, I missed ..../device/... part.  Then it's correct.
If it doesn't change, it means that the udev rule isn't correctly
installed or activated by some reason.  You can check the udev log, or
just check via udevadm monitor and udevadm trigger.  For a temporary
testing, you can of course change the sysfs entry manually...

> Anyway, power/runtime_status is always active, and power/usage_count is
> always 1. (And pulseaudio is not running, and nothing else is using any
> /dev/snd/* files.)
>
> > You can put a printk in azx_runtime_suspend().  For Haswell, it should
> > work as is with 3.13-rc1.
> 
> I guess I could test that, but I doubt it would help...

You're testing with Haswell and 3.13-rc1, right?


Takashi

Re: HD-audio runtime PM

[David Henningsson]

On 11/25/2013 11:34 AM, Takashi Iwai wrote:
> At Mon, 25 Nov 2013 11:25:46 +0100,
> David Henningsson wrote:
>>
>> On 11/25/2013 10:26 AM, Takashi Iwai wrote:
>>> At Mon, 25 Nov 2013 10:20:55 +0100,
>>> David Henningsson wrote:
>>>>
>>>> On 11/25/2013 08:17 AM, Takashi Iwai wrote:
>>>>> At Mon, 25 Nov 2013 07:32:57 +0100,
>>>>> David Henningsson wrote:
>>>>>>
>>>>>> On 11/22/2013 12:57 PM, Takashi Iwai wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> after my previous fix, the runtime PM seems working stably finally.
>>>>>>> However, there seem still some glitches:
>>>>>>>
>>>>>>> 1. The wakeup via jack or HDMI/DP detection doesn't seem to work on my
>>>>>>>   test machines.  WAKEEN is set properly.  And its value can be read
>>>>>>>   correctly at the point of runtime resume, too.
>>>>>>
>>>>>> Hi and thanks for working on this.
>>>>>>
>>>>>> I've been trying to reproduce the above, but I can't seem to activate
>>>>>> runtime PM at all. I can't seem to get a callback to runtime_suspend,
>>>>>> and further investigation shows that
>>>>>> /sys/class/sound/card0/power/runtime_status shows "unsupported".
>>>>>
>>>>> You need to adjust power/control of the parent PCM device,
>>>>> i.e. /sys/devices/pci/*/power/control.  The following udev rule should
>>>>> work for HD-audio.  Give it a try.
>>>>>
>>>>>   ACTION=="add", SUBSYSTEM=="pci", ATTR{class}=="0x040300", TEST=="power/control", ATTR{power/control}="auto"
>>>>
>>>> I tried this rule, but it did not make any difference -
>>>> /sys/class/sound/card0/device/power/control was still on. (And I did
>>>> proofread the rule...)
>>>
>>> This (and other sound/*) doesn't matter.  Only the entry in the PCI
>>> device counts.  It's the runtime PM of the PCI device after all.
>>> (Remember that the runtime PM callbacks are set only on this device.)
>>
>> But /sys/class/sound/card0/device is just a symlink for
>> /sys/devices/pci0000:00/0000:00:03.0 - is this not the PCI device you're
>> talking about?
> 
> Ah, ok, I missed ..../device/... part.  Then it's correct.
> If it doesn't change, it means that the udev rule isn't correctly
> installed or activated by some reason.  You can check the udev log, or
> just check via udevadm monitor and udevadm trigger.  For a temporary
> testing, you can of course change the sysfs entry manually...
> 
>> Anyway, power/runtime_status is always active, and power/usage_count is
>> always 1. (And pulseaudio is not running, and nothing else is using any
>> /dev/snd/* files.)

Found it. It was the power_save module parameter that kept a usage_count
on the device. Sorry for the noise.

Anyway; I could then reproduce the bug (noticed by missing ELD update on
plug/unplug of HDMI monitor). I also went back to the WAKEEN commit
(originally by Xingchao), but it didn't work there either. The
interrupts do not get through. (Feel free to double check.)

>>> You can put a printk in azx_runtime_suspend().  For Haswell, it should
>>> work as is with 3.13-rc1.
>>
>> I guess I could test that, but I doubt it would help...
> 
> You're testing with Haswell and 3.13-rc1, right?

Right.


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

Re: HD-audio runtime PM

[Wang Xingchao]

Hi Takashi,

2013/11/22 Takashi Iwai <tiwai@suse.de>:
> Hi,
>
> after my previous fix, the runtime PM seems working stably finally.
> However, there seem still some glitches:
>
> 1. The wakeup via jack or HDMI/DP detection doesn't seem to work on my
>   test machines.  WAKEEN is set properly.  And its value can be read
>   correctly at the point of runtime resume, too.
>
> 2. We don't change the device to D3 in runtime suspend.  So I guess we
>   save little power as of now.
>
>   Actually, setting to D3 and resuming to D0 works fine, as far as I
>   tested -- except for HDMI/DP ELD read out on Haswell.  Although ELD
>   read doesn't give any errors, the received bytes are corrupted.  In
>   my case, the read starts from offset 0x1c.
>
>   The HDMI can be still played even at that state, but then it falls
>   back to the stereo 2ch mode, of course.
>
> The tests were performed on both Haswell (DP and LynxPoint-LP) and
> IvyBridge (PantherPoint) machines.
>
> The first problem has been present, and it's also the behavior of some
> old chips where the codec can't go to sleep with unsol wakeup.  So, in
> this regard, it's no regression, per se.  But certainly it's no good
> thing.
>
> I thought Mengdong once made WAKEEN working.  Mengdong, do you
> remember what was the condition?  Could you check whether the latest
> kernel (at best sound git tree for-linus branch) still works?
>
> About the second point: we should do D3 if we do care power, and
> that's the very right reason for runtime PM.  But the ELD issue is a
> bad bug, and it makes me wonder whether it's a graphics driver side
> issue or a codec side.  As a quick workaround, we can implement D3 on
> controllers but for Haswell HDMI/DP.

I didnot follow alsa-devel threads often now, is that ELD issue an
regression from my previous commit?
I test WAKEEN feature on Haswell machines before, it could really
wakeup system from D3.
The controller must be in RESET mode after enter runtime-suspend,
otherwise it will not be waken up
even if codec send out wake-up event. And STATESTS will be cleared
after controller brought out of RESET mode.

thanks
--xingchao
>
> In anyway, this is no urgent issue, clearly targeted for 3.14.
> The whole patch series are found in my sound-unstable git tree
> test/hda branch.
>   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
>
>
> thanks,
>
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: HD-audio runtime PM

[Takashi Iwai]

At Tue, 26 Nov 2013 09:05:20 +0800,
Wang Xingchao wrote:
> 
> Hi Takashi,
> 
> 2013/11/22 Takashi Iwai <tiwai@suse.de>:
> > Hi,
> >
> > after my previous fix, the runtime PM seems working stably finally.
> > However, there seem still some glitches:
> >
> > 1. The wakeup via jack or HDMI/DP detection doesn't seem to work on my
> >   test machines.  WAKEEN is set properly.  And its value can be read
> >   correctly at the point of runtime resume, too.
> >
> > 2. We don't change the device to D3 in runtime suspend.  So I guess we
> >   save little power as of now.
> >
> >   Actually, setting to D3 and resuming to D0 works fine, as far as I
> >   tested -- except for HDMI/DP ELD read out on Haswell.  Although ELD
> >   read doesn't give any errors, the received bytes are corrupted.  In
> >   my case, the read starts from offset 0x1c.
> >
> >   The HDMI can be still played even at that state, but then it falls
> >   back to the stereo 2ch mode, of course.
> >
> > The tests were performed on both Haswell (DP and LynxPoint-LP) and
> > IvyBridge (PantherPoint) machines.
> >
> > The first problem has been present, and it's also the behavior of some
> > old chips where the codec can't go to sleep with unsol wakeup.  So, in
> > this regard, it's no regression, per se.  But certainly it's no good
> > thing.
> >
> > I thought Mengdong once made WAKEEN working.  Mengdong, do you
> > remember what was the condition?  Could you check whether the latest
> > kernel (at best sound git tree for-linus branch) still works?
> >
> > About the second point: we should do D3 if we do care power, and
> > that's the very right reason for runtime PM.  But the ELD issue is a
> > bad bug, and it makes me wonder whether it's a graphics driver side
> > issue or a codec side.  As a quick workaround, we can implement D3 on
> > controllers but for Haswell HDMI/DP.
> 
> I didnot follow alsa-devel threads often now, is that ELD issue an
> regression from my previous commit?

I'm not sure whether it's a regression.  We need to track down.

> I test WAKEEN feature on Haswell machines before, it could really
> wakeup system from D3.

But the runtime suspend doesn't power down to D3 by itself.
Did you test really with D3?

> The controller must be in RESET mode after enter runtime-suspend,
> otherwise it will not be waken up
> even if codec send out wake-up event. And STATESTS will be cleared
> after controller brought out of RESET mode.

And I noticed that RESET mode makes some machines inconsistent,
e.g. the mute LED is reset on HP machines without keeping the previous
state.  I need to double-check whether this still happens with the
recent fixes.


thanks,

Takashi

> 
> thanks
> --xingchao
> >
> > In anyway, this is no urgent issue, clearly targeted for 3.14.
> > The whole patch series are found in my sound-unstable git tree
> > test/hda branch.
> >   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
> >
> >
> > thanks,
> >
> > Takashi
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

Re: HD-audio runtime PM

[Lin, Mengdong]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Tuesday, November 26, 2013 2:14 PM
> To: Wang Xingchao
 
> > I test WAKEEN feature on Haswell machines before, it could really
> > wakeup system from D3.
> 
> But the runtime suspend doesn't power down to D3 by itself.
> Did you test really with D3?

I will double check this on Haswell with sound git tree for-linus branch.
We've tried Android on Haswell-ULT last week, the display HD-A controller can enter D3 and HDMI cable plug-in can wake up the controller and codec. The code base is v3.9 with various driver patches.

For non-Haswell platforms, hardware team suggest that unless all of the codecs on the HD-A link support EPSS and ClkStopOK, runtime PM of the controller should not be enabled on the controller. Otherwise, functionality will be lost and there are likely going to be audio artifacts.

Thanks
Mengdong

> > The controller must be in RESET mode after enter runtime-suspend,
> > otherwise it will not be waken up even if codec send out wake-up
> > event. And STATESTS will be cleared after controller brought out of
> > RESET mode.
> 
> And I noticed that RESET mode makes some machines inconsistent, e.g.
> the mute LED is reset on HP machines without keeping the previous state.
> I need to double-check whether this still happens with the recent fixes.

Re: HD-audio runtime PM

[Takashi Iwai]

At Tue, 26 Nov 2013 06:56:12 +0000,
Lin, Mengdong wrote:
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de]
> > Sent: Tuesday, November 26, 2013 2:14 PM
> > To: Wang Xingchao
>  
> > > I test WAKEEN feature on Haswell machines before, it could really
> > > wakeup system from D3.
> > 
> > But the runtime suspend doesn't power down to D3 by itself.
> > Did you test really with D3?
> 
> I will double check this on Haswell with sound git tree for-linus branch.
> We've tried Android on Haswell-ULT last week, the display HD-A controller can enter D3 and HDMI cable plug-in can wake up the controller and codec. The code base is v3.9 with various driver patches.

Hrm, but as I mentioned, we have no D3 call in runtime suspend
callback.  How does it reach to D3 then?  Maybe that part is patched
in your side?

> For non-Haswell platforms, hardware team suggest that unless all of the codecs on the HD-A link support EPSS and ClkStopOK, runtime PM of the controller should not be enabled on the controller. Otherwise, functionality will be lost and there are likely going to be audio artifacts.

Is EPSS mandatory?  We have already a check of ClkStopOK bit, but EPSS
influences only on the wait time, so far.


Takashi

> Thanks
> Mengdong
> 
> > > The controller must be in RESET mode after enter runtime-suspend,
> > > otherwise it will not be waken up even if codec send out wake-up
> > > event. And STATESTS will be cleared after controller brought out of
> > > RESET mode.
> > 
> > And I noticed that RESET mode makes some machines inconsistent, e.g.
> > the mute LED is reset on HP machines without keeping the previous state.
> > I need to double-check whether this still happens with the recent fixes.
> 

Re: HD-audio runtime PM

[Takashi Iwai]

At Tue, 26 Nov 2013 08:28:15 +0100,
Takashi Iwai wrote:
> 
> At Tue, 26 Nov 2013 06:56:12 +0000,
> Lin, Mengdong wrote:
> > 
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > Sent: Tuesday, November 26, 2013 2:14 PM
> > > To: Wang Xingchao
> >  
> > > > I test WAKEEN feature on Haswell machines before, it could really
> > > > wakeup system from D3.
> > > 
> > > But the runtime suspend doesn't power down to D3 by itself.
> > > Did you test really with D3?
> > 
> > I will double check this on Haswell with sound git tree for-linus branch.
> > We've tried Android on Haswell-ULT last week, the display HD-A controller can enter D3 and HDMI cable plug-in can wake up the controller and codec. The code base is v3.9 with various driver patches.
> 
> Hrm, but as I mentioned, we have no D3 call in runtime suspend
> callback.  How does it reach to D3 then?  Maybe that part is patched
> in your side?
> 
> > For non-Haswell platforms, hardware team suggest that unless all of the codecs on the HD-A link support EPSS and ClkStopOK, runtime PM of the controller should not be enabled on the controller. Otherwise, functionality will be lost and there are likely going to be audio artifacts.
> 
> Is EPSS mandatory?  We have already a check of ClkStopOK bit, but EPSS
> influences only on the wait time, so far.

I forgot that EPSS check does exist for HDMI codecs.  But it's not
applied to other codecs.


Takashi

Re: HD-audio runtime PM

[Lin, Mengdong]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Tuesday, November 26, 2013 4:26 PM

> > > > -----Original Message-----
> > > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > > Sent: Tuesday, November 26, 2013 2:14 PM
> > > > To: Wang Xingchao
> > >
> > > > > I test WAKEEN feature on Haswell machines before, it could
> > > > > really wakeup system from D3.
> > > >
> > > > But the runtime suspend doesn't power down to D3 by itself.
> > > > Did you test really with D3?
> > >
> > > I will double check this on Haswell with sound git tree for-linus branch.
> > > We've tried Android on Haswell-ULT last week, the display HD-A
> controller can enter D3 and HDMI cable plug-in can wake up the controller
> and codec. The code base is v3.9 with various driver patches.
> >
> > Hrm, but as I mentioned, we have no D3 call in runtime suspend
> > callback.  How does it reach to D3 then?  Maybe that part is patched
> > in your side?

Hi,

I've checked two Haswell-ULT platforms with sound git tree for-linus branch, under Ubuntu:
- ELD cannot refresh properly.
- HDMI hot-plug cannot wake up the audio controller.

The controller is suspended when idle timeout and put in D3 by PCI driver. Here is the status shown by lspci -vvvv as root:
00:03.0 Audio device: Intel Corporation Device 0a0c (rev 09)
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
... Status: D3 mean the device is in D3.

I guess maybe the latest display driver does not handle hot-plug properly which affect both ELD and device wakeup.

For Android on Haswell, the kernel code base and BIOS are different.

I'll further check this issue. Is it very urgent?
I cannot work full time on this now due to some timing optimization task for Baytrail at the same time.

Regards
Mengdong

Re: HD-audio runtime PM

[Takashi Iwai]

At Wed, 27 Nov 2013 09:37:17 +0000,
Lin, Mengdong wrote:
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de]
> > Sent: Tuesday, November 26, 2013 4:26 PM
> 
> > > > > -----Original Message-----
> > > > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > > > Sent: Tuesday, November 26, 2013 2:14 PM
> > > > > To: Wang Xingchao
> > > >
> > > > > > I test WAKEEN feature on Haswell machines before, it could
> > > > > > really wakeup system from D3.
> > > > >
> > > > > But the runtime suspend doesn't power down to D3 by itself.
> > > > > Did you test really with D3?
> > > >
> > > > I will double check this on Haswell with sound git tree for-linus branch.
> > > > We've tried Android on Haswell-ULT last week, the display HD-A
> > controller can enter D3 and HDMI cable plug-in can wake up the controller
> > and codec. The code base is v3.9 with various driver patches.
> > >
> > > Hrm, but as I mentioned, we have no D3 call in runtime suspend
> > > callback.  How does it reach to D3 then?  Maybe that part is patched
> > > in your side?
> 
> Hi,
> 
> I've checked two Haswell-ULT platforms with sound git tree for-linus branch, under Ubuntu:
> - ELD cannot refresh properly.
> - HDMI hot-plug cannot wake up the audio controller.
> 
> The controller is suspended when idle timeout and put in D3 by PCI driver. Here is the status shown by lspci -vvvv as root:
> 00:03.0 Audio device: Intel Corporation Device 0a0c (rev 09)
> 	Capabilities: [50] Power Management version 2
> 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> 		Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> ... Status: D3 mean the device is in D3.
> 
> I guess maybe the latest display driver does not handle hot-plug properly which affect both ELD and device wakeup.
> 
> For Android on Haswell, the kernel code base and BIOS are different.
> 
> I'll further check this issue. Is it very urgent?

Not that urgent, but if it's a regression, we must fix it.
If it's no regression, the urgency decreases, of course.

> I cannot work full time on this now due to some timing optimization task for Baytrail at the same time.

At least, it'd be helpful if you can confirm whether it still works
with vanilla 3.9.x kernel (or whatever version) you tested in the
past -- i.e. to know whether it's a regression or not.


thanks,

Takashi

Re: HD-audio runtime PM

[Lin, Mengdong]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Wednesday, November 27, 2013 6:55 PM
> To: Lin, Mengdong
> Cc: Wang Xingchao; Alsa-devel@alsa-project.org; David Henningsson
> Subject: Re: [alsa-devel] HD-audio runtime PM
> 
> At Wed, 27 Nov 2013 09:37:17 +0000,
> Lin, Mengdong wrote:
> >
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > Sent: Tuesday, November 26, 2013 4:26 PM
> >
> > > > > > -----Original Message-----
> > > > > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > > > > Sent: Tuesday, November 26, 2013 2:14 PM
> > > > > > To: Wang Xingchao
> > > > >
> > > > > > > I test WAKEEN feature on Haswell machines before, it could
> > > > > > > really wakeup system from D3.
> > > > > >
> > > > > > But the runtime suspend doesn't power down to D3 by itself.
> > > > > > Did you test really with D3?
> > > > >
> > > > > I will double check this on Haswell with sound git tree for-linus
> branch.
> > > > > We've tried Android on Haswell-ULT last week, the display HD-A
> > > controller can enter D3 and HDMI cable plug-in can wake up the
> > > controller and codec. The code base is v3.9 with various driver patches.
> > > >
> > > > Hrm, but as I mentioned, we have no D3 call in runtime suspend
> > > > callback.  How does it reach to D3 then?  Maybe that part is
> > > > patched in your side?
> >
> > Hi,
> >
> > I've checked two Haswell-ULT platforms with sound git tree for-linus
> branch, under Ubuntu:
> > - ELD cannot refresh properly.
> > - HDMI hot-plug cannot wake up the audio controller.
> >
> > The controller is suspended when idle timeout and put in D3 by PCI
> driver. Here is the status shown by lspci -vvvv as root:
> > 00:03.0 Audio device: Intel Corporation Device 0a0c (rev 09)
> > 	Capabilities: [50] Power Management version 2
> > 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> > 		Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- ...
> Status:
> > D3 mean the device is in D3.
> >
> > I guess maybe the latest display driver does not handle hot-plug
> properly which affect both ELD and device wakeup.
> >
> > For Android on Haswell, the kernel code base and BIOS are different.
> >
> > I'll further check this issue. Is it very urgent?
> 
> Not that urgent, but if it's a regression, we must fix it.
> If it's no regression, the urgency decreases, of course.
> 
> > I cannot work full time on this now due to some timing optimization
> task for Baytrail at the same time.
> 
> At least, it'd be helpful if you can confirm whether it still works with
> vanilla 3.9.x kernel (or whatever version) you tested in the past -- i.e. to
> know whether it's a regression or not.

Okay, I'll try kernels close to when Xingchao enable this wake-up feature.

Thanks
Mengdong

Re: HD-audio runtime PM

[Lin, Mengdong]

> > > I've checked two Haswell-ULT platforms with sound git tree for-linus
> > branch, under Ubuntu:
> > > - ELD cannot refresh properly.
> > > - HDMI hot-plug cannot wake up the audio controller.

I've tested the latest 3.13-rc2 based sound git tree, master branch:
- ELD can refresh properly on hot-plug event.
 I need to bisect to see where the ELD regression happened and how it was fixed. 

- Headset insertion can wake up the legacy audio controller (PCI device 00:1b)

- HDMI insertion still cannot wake up the display audio controller (PCI device 00:03)
 We'll double check with HW owner whether the display audio controller really supports wake up on HDMI/DP insertion.
 I remember when Xingchao enabled runtime PM on Haswell display audio controller for display power well release, 
 there was an issue that this controller does not support "wake up", but we finally enable runtime PM on it and remove the request for "wake up".

Thanks
Mengdong

> > > I guess maybe the latest display driver does not handle hot-plug
> > properly which affect both ELD and device wakeup.
> > >
> > > For Android on Haswell, the kernel code base and BIOS are different.
> > >
> > > I'll further check this issue. Is it very urgent?
> >
> > Not that urgent, but if it's a regression, we must fix it.
> > If it's no regression, the urgency decreases, of course.
> >
> > > I cannot work full time on this now due to some timing optimization
> > task for Baytrail at the same time.
> >
> > At least, it'd be helpful if you can confirm whether it still works
> > with vanilla 3.9.x kernel (or whatever version) you tested in the past
> > -- i.e. to know whether it's a regression or not.
> 
> Okay, I'll try kernels close to when Xingchao enable this wake-up feature.

Re: HD-audio runtime PM

[Lin, Mengdong]

Hi Takashi,

> -----Original Message-----
> From: Lin, Mengdong
> Sent: Monday, December 09, 2013 3:03 PM

> > > > I've checked two Haswell-ULT platforms with sound git tree
> > > > for-linus
> > > branch, under Ubuntu:
> > > > - ELD cannot refresh properly.
> > > > - HDMI hot-plug cannot wake up the audio controller.
> 
> I've tested the latest 3.13-rc2 based sound git tree, master branch:
> - ELD can refresh properly on hot-plug event.
>  I need to bisect to see where the ELD regression happened and how it
> was fixed.

ELD info cannot refresh on hot-plug event after the controller enters D3 on Haswell.
Sorry, I forgot to enable runtime PM yesterday when checking ELD refreshing.  

> - Headset insertion can wake up the legacy audio controller (PCI device
> 00:1b)
> 
> - HDMI insertion still cannot wake up the display audio controller (PCI
> device 00:03)  We'll double check with HW owner whether the display
> audio controller really supports wake up on HDMI/DP insertion.
>  I remember when Xingchao enabled runtime PM on Haswell display
> audio controller for display power well release,  there was an issue that
> this controller does not support "wake up", but we finally enable runtime
> PM on it and remove the request for "wake up".

HW team clarified that HDMI/DP jack insertion cannot wake up the controller from D3. So this is a HW restriction for Haswell, not a driver regression.

Now the problem on Haswell/Broadwell is:
After the controller enters D3, Gfx driver can still detect HDMI/DP hot plug event even if the display power well is disabled.
Although Gfx driver set Presence Detect and ELD Valid , the audio controller does not wake up and so audio driver has no idea about the HDMI/DP hot-plug.

Is it audio driver itself or the user space that need this ELD info?
Maybe Gfx driver can directly report ELD info to user space.

Thanks
Mengdong

Re: HD-audio runtime PM

[Takashi Iwai]

At Tue, 10 Dec 2013 12:17:16 +0000,
Lin, Mengdong wrote:
> 
> Hi Takashi,
> 
> > -----Original Message-----
> > From: Lin, Mengdong
> > Sent: Monday, December 09, 2013 3:03 PM
> 
> > > > > I've checked two Haswell-ULT platforms with sound git tree
> > > > > for-linus
> > > > branch, under Ubuntu:
> > > > > - ELD cannot refresh properly.
> > > > > - HDMI hot-plug cannot wake up the audio controller.
> > 
> > I've tested the latest 3.13-rc2 based sound git tree, master branch:
> > - ELD can refresh properly on hot-plug event.
> >  I need to bisect to see where the ELD regression happened and how it
> > was fixed.
> 
> ELD info cannot refresh on hot-plug event after the controller enters D3 on Haswell.
> Sorry, I forgot to enable runtime PM yesterday when checking ELD refreshing.  
> 
> > - Headset insertion can wake up the legacy audio controller (PCI device
> > 00:1b)
> > 
> > - HDMI insertion still cannot wake up the display audio controller (PCI
> > device 00:03)  We'll double check with HW owner whether the display
> > audio controller really supports wake up on HDMI/DP insertion.
> >  I remember when Xingchao enabled runtime PM on Haswell display
> > audio controller for display power well release,  there was an issue that
> > this controller does not support "wake up", but we finally enable runtime
> > PM on it and remove the request for "wake up".
> 
> HW team clarified that HDMI/DP jack insertion cannot wake up the controller from D3. So this is a HW restriction for Haswell, not a driver regression.
> 
> Now the problem on Haswell/Broadwell is:
> After the controller enters D3, Gfx driver can still detect HDMI/DP hot plug event even if the display power well is disabled.
> Although Gfx driver set Presence Detect and ELD Valid , the audio controller does not wake up and so audio driver has no idea about the HDMI/DP hot-plug.
> 
> Is it audio driver itself or the user space that need this ELD info?
> Maybe Gfx driver can directly report ELD info to user space.

If so, the graphics driver can wake up the audio driver as well --
this is yet one more reason to create a direct communication channel
between the graphics and audio drivers :)


Takashi

Re: HD-audio runtime PM

[Lin, Mengdong]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Tuesday, December 10, 2013 8:25 PM
> To: Lin, Mengdong
> Cc: Alsa-devel@alsa-project.org; Wang Xingchao; David Henningsson
> Subject: Re: [alsa-devel] HD-audio runtime PM
> 
> At Tue, 10 Dec 2013 12:17:16 +0000,
> Lin, Mengdong wrote:
> >
> > Hi Takashi,
> >
> > > -----Original Message-----
> > > From: Lin, Mengdong
> > > Sent: Monday, December 09, 2013 3:03 PM
> >
> > > > > > I've checked two Haswell-ULT platforms with sound git tree
> > > > > > for-linus
> > > > > branch, under Ubuntu:
> > > > > > - ELD cannot refresh properly.
> > > > > > - HDMI hot-plug cannot wake up the audio controller.
> > >
> > > I've tested the latest 3.13-rc2 based sound git tree, master branch:
> > > - ELD can refresh properly on hot-plug event.
> > >  I need to bisect to see where the ELD regression happened and how
> > > it was fixed.
> >
> > ELD info cannot refresh on hot-plug event after the controller enters D3
> on Haswell.
> > Sorry, I forgot to enable runtime PM yesterday when checking ELD
> refreshing.
> >
> > > - Headset insertion can wake up the legacy audio controller (PCI
> > > device
> > > 00:1b)
> > >
> > > - HDMI insertion still cannot wake up the display audio controller
> > > (PCI device 00:03)  We'll double check with HW owner whether the
> > > display audio controller really supports wake up on HDMI/DP
> insertion.
> > >  I remember when Xingchao enabled runtime PM on Haswell display
> > > audio controller for display power well release,  there was an issue
> > > that this controller does not support "wake up", but we finally
> > > enable runtime PM on it and remove the request for "wake up".
> >
> > HW team clarified that HDMI/DP jack insertion cannot wake up the
> controller from D3. So this is a HW restriction for Haswell, not a driver
> regression.
> >
> > Now the problem on Haswell/Broadwell is:
> > After the controller enters D3, Gfx driver can still detect HDMI/DP hot
> plug event even if the display power well is disabled.
> > Although Gfx driver set Presence Detect and ELD Valid , the audio
> controller does not wake up and so audio driver has no idea about the
> HDMI/DP hot-plug.
> >
> > Is it audio driver itself or the user space that need this ELD info?
> > Maybe Gfx driver can directly report ELD info to user space.
> 
> If so, the graphics driver can wake up the audio driver as well -- this is yet
> one more reason to create a direct communication channel between the
> graphics and audio drivers :)

Need the audio driver provide an API for gfx driver?
Maybe this API can call snd_hda_power_up(codec) and then snd_hda_power_down(codec),
thus the controller and codec will wake up and audio driver can check ELD info.

Regards
Mengdong

Re: HD-audio runtime PM

[Takashi Iwai]

At Tue, 10 Dec 2013 12:34:51 +0000,
Lin, Mengdong wrote:
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de]
> > Sent: Tuesday, December 10, 2013 8:25 PM
> > To: Lin, Mengdong
> > Cc: Alsa-devel@alsa-project.org; Wang Xingchao; David Henningsson
> > Subject: Re: [alsa-devel] HD-audio runtime PM
> > 
> > At Tue, 10 Dec 2013 12:17:16 +0000,
> > Lin, Mengdong wrote:
> > >
> > > Hi Takashi,
> > >
> > > > -----Original Message-----
> > > > From: Lin, Mengdong
> > > > Sent: Monday, December 09, 2013 3:03 PM
> > >
> > > > > > > I've checked two Haswell-ULT platforms with sound git tree
> > > > > > > for-linus
> > > > > > branch, under Ubuntu:
> > > > > > > - ELD cannot refresh properly.
> > > > > > > - HDMI hot-plug cannot wake up the audio controller.
> > > >
> > > > I've tested the latest 3.13-rc2 based sound git tree, master branch:
> > > > - ELD can refresh properly on hot-plug event.
> > > >  I need to bisect to see where the ELD regression happened and how
> > > > it was fixed.
> > >
> > > ELD info cannot refresh on hot-plug event after the controller enters D3
> > on Haswell.
> > > Sorry, I forgot to enable runtime PM yesterday when checking ELD
> > refreshing.
> > >
> > > > - Headset insertion can wake up the legacy audio controller (PCI
> > > > device
> > > > 00:1b)
> > > >
> > > > - HDMI insertion still cannot wake up the display audio controller
> > > > (PCI device 00:03)  We'll double check with HW owner whether the
> > > > display audio controller really supports wake up on HDMI/DP
> > insertion.
> > > >  I remember when Xingchao enabled runtime PM on Haswell display
> > > > audio controller for display power well release,  there was an issue
> > > > that this controller does not support "wake up", but we finally
> > > > enable runtime PM on it and remove the request for "wake up".
> > >
> > > HW team clarified that HDMI/DP jack insertion cannot wake up the
> > controller from D3. So this is a HW restriction for Haswell, not a driver
> > regression.
> > >
> > > Now the problem on Haswell/Broadwell is:
> > > After the controller enters D3, Gfx driver can still detect HDMI/DP hot
> > plug event even if the display power well is disabled.
> > > Although Gfx driver set Presence Detect and ELD Valid , the audio
> > controller does not wake up and so audio driver has no idea about the
> > HDMI/DP hot-plug.
> > >
> > > Is it audio driver itself or the user space that need this ELD info?
> > > Maybe Gfx driver can directly report ELD info to user space.
> > 
> > If so, the graphics driver can wake up the audio driver as well -- this is yet
> > one more reason to create a direct communication channel between the
> > graphics and audio drivers :)
> 
> Need the audio driver provide an API for gfx driver?
> Maybe this API can call snd_hda_power_up(codec) and then snd_hda_power_down(codec),
> thus the controller and codec will wake up and audio driver can check ELD info.

Well, we can create a common object containing the ops registered by
both graphics and audio drivers, then communicate through it,
something like vga_switcheroo.


Takashi

Re: HD-audio runtime PM

[Lin, Mengdong]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Tuesday, December 10, 2013 10:26 PM

> > > > HW team clarified that HDMI/DP jack insertion cannot wake up the
> > > controller from D3. So this is a HW restriction for Haswell, not a
> > > driver regression.
> > > >
> > > > Now the problem on Haswell/Broadwell is:
> > > > After the controller enters D3, Gfx driver can still detect
> > > > HDMI/DP hot
> > > plug event even if the display power well is disabled.
> > > > Although Gfx driver set Presence Detect and ELD Valid , the audio
> > > controller does not wake up and so audio driver has no idea about
> > > the HDMI/DP hot-plug.
> > > >
> > > > Is it audio driver itself or the user space that need this ELD info?
> > > > Maybe Gfx driver can directly report ELD info to user space.
> > >
> > > If so, the graphics driver can wake up the audio driver as well --
> > > this is yet one more reason to create a direct communication channel
> > > between the graphics and audio drivers :)
> >
> > Need the audio driver provide an API for gfx driver?
> > Maybe this API can call snd_hda_power_up(codec) and then
> > snd_hda_power_down(codec), thus the controller and codec will wake
> up and audio driver can check ELD info.
> 
> Well, we can create a common object containing the ops registered by
> both graphics and audio drivers, then communicate through it, something
> like vga_switcheroo.

Hi Takashi,

I'm sure how to use a common object like vga_switcheroo. Would you please share more info?

I feel a wake up process may be like this:
- Gfx driver detects the hot-plug at first and notify audio driver by the communication channel.
- In the notification callback, the audio driver wakes up the audio controller to D0, but codec can still stay in D3. 
 (Hope we can add a time out for controller here to avoid controller back to D3 at once and lose the capability to check unsol event)
- Then when Gfx driver enables or disables audio, and the audio controller can receive the unsol event in D0.
- Audio driver check ELD in unsol event handler, this will make codec resume to D0.

Regards
Mengdong

Re: HD-audio runtime PM

[Takashi Iwai]

At Wed, 11 Dec 2013 05:37:44 +0000,
Lin, Mengdong wrote:
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de]
> > Sent: Tuesday, December 10, 2013 10:26 PM
> 
> > > > > HW team clarified that HDMI/DP jack insertion cannot wake up the
> > > > controller from D3. So this is a HW restriction for Haswell, not a
> > > > driver regression.
> > > > >
> > > > > Now the problem on Haswell/Broadwell is:
> > > > > After the controller enters D3, Gfx driver can still detect
> > > > > HDMI/DP hot
> > > > plug event even if the display power well is disabled.
> > > > > Although Gfx driver set Presence Detect and ELD Valid , the audio
> > > > controller does not wake up and so audio driver has no idea about
> > > > the HDMI/DP hot-plug.
> > > > >
> > > > > Is it audio driver itself or the user space that need this ELD info?
> > > > > Maybe Gfx driver can directly report ELD info to user space.
> > > >
> > > > If so, the graphics driver can wake up the audio driver as well --
> > > > this is yet one more reason to create a direct communication channel
> > > > between the graphics and audio drivers :)
> > >
> > > Need the audio driver provide an API for gfx driver?
> > > Maybe this API can call snd_hda_power_up(codec) and then
> > > snd_hda_power_down(codec), thus the controller and codec will wake
> > up and audio driver can check ELD info.
> > 
> > Well, we can create a common object containing the ops registered by
> > both graphics and audio drivers, then communicate through it, something
> > like vga_switcheroo.
> 
> Hi Takashi,
> 
> I'm sure how to use a common object like vga_switcheroo. Would you please share more info?
> 
> I feel a wake up process may be like this:
> - Gfx driver detects the hot-plug at first and notify audio driver by the communication channel.
> - In the notification callback, the audio driver wakes up the audio controller to D0, but codec can still stay in D3. 
>  (Hope we can add a time out for controller here to avoid controller back to D3 at once and lose the capability to check unsol event)
> - Then when Gfx driver enables or disables audio, and the audio controller can receive the unsol event in D0.
> - Audio driver check ELD in unsol event handler, this will make codec resume to D0.

If we have a direct communication with the graphics driver, the audio
driver doesn't wait for the unsol event at all.  It can retrieve ELD
and even better port info more directly; i.e. we can skip even the
wake up of the HDMI controller and codec chips.  The notification and
ELD updates can be done without the audio hardware, after all (actual
ELD updates will be done at resume).


Takashi

Re: HD-audio runtime PM

[Lin, Mengdong]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Wednesday, December 11, 2013 9:37 PM
> To: Lin, Mengdong
> Cc: Alsa-devel@alsa-project.org; Wang Xingchao; David Henningsson
> Subject: Re: [alsa-devel] HD-audio runtime PM
> 
> At Wed, 11 Dec 2013 05:37:44 +0000,
> Lin, Mengdong wrote:
> >
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > Sent: Tuesday, December 10, 2013 10:26 PM
> >
> > > > > > HW team clarified that HDMI/DP jack insertion cannot wake up
> > > > > > the
> > > > > controller from D3. So this is a HW restriction for Haswell, not
> > > > > a driver regression.
> > > > > >
> > > > > > Now the problem on Haswell/Broadwell is:
> > > > > > After the controller enters D3, Gfx driver can still detect
> > > > > > HDMI/DP hot
> > > > > plug event even if the display power well is disabled.
> > > > > > Although Gfx driver set Presence Detect and ELD Valid , the
> > > > > > audio
> > > > > controller does not wake up and so audio driver has no idea
> > > > > about the HDMI/DP hot-plug.
> > > > > >
> > > > > > Is it audio driver itself or the user space that need this ELD info?
> > > > > > Maybe Gfx driver can directly report ELD info to user space.
> > > > >
> > > > > If so, the graphics driver can wake up the audio driver as well
> > > > > -- this is yet one more reason to create a direct communication
> > > > > channel between the graphics and audio drivers :)
> > > >
> > > > Need the audio driver provide an API for gfx driver?
> > > > Maybe this API can call snd_hda_power_up(codec) and then
> > > > snd_hda_power_down(codec), thus the controller and codec will
> wake
> > > up and audio driver can check ELD info.
> > >
> > > Well, we can create a common object containing the ops registered by
> > > both graphics and audio drivers, then communicate through it,
> > > something like vga_switcheroo.
> >
> > Hi Takashi,
> >
> > I'm sure how to use a common object like vga_switcheroo. Would you
> please share more info?
> >
> > I feel a wake up process may be like this:
> > - Gfx driver detects the hot-plug at first and notify audio driver by the
> communication channel.
> > - In the notification callback, the audio driver wakes up the audio
> controller to D0, but codec can still stay in D3.
> >  (Hope we can add a time out for controller here to avoid controller
> > back to D3 at once and lose the capability to check unsol event)
> > - Then when Gfx driver enables or disables audio, and the audio
> controller can receive the unsol event in D0.
> > - Audio driver check ELD in unsol event handler, this will make codec
> resume to D0.
> 
> If we have a direct communication with the graphics driver, the audio
> driver doesn't wait for the unsol event at all.  It can retrieve ELD and
> even better port info more directly; i.e. we can skip even the wake up of
> the HDMI controller and codec chips.  The notification and ELD updates
> can be done without the audio hardware, after all (actual ELD updates will
> be done at resume).
> 
Good idea. We can try this.
The HDMI controller and codec can sleep until user space really wants to use HDMI audio.

Regards
Mengdong

Re: HD-audio runtime PM

[Lin, Mengdong]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Wednesday, December 11, 2013 9:37 PM
> To: Lin, Mengdong
> Cc: Alsa-devel@alsa-project.org; Wang Xingchao; David Henningsson
> Subject: Re: [alsa-devel] HD-audio runtime PM
> 
> At Wed, 11 Dec 2013 05:37:44 +0000,
> Lin, Mengdong wrote:
> >
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > Sent: Tuesday, December 10, 2013 10:26 PM
> >
> > > > > > HW team clarified that HDMI/DP jack insertion cannot wake up
> > > > > > the
> > > > > controller from D3. So this is a HW restriction for Haswell, not
> > > > > a driver regression.
> > > > > >
> > > > > > Now the problem on Haswell/Broadwell is:
> > > > > > After the controller enters D3, Gfx driver can still detect
> > > > > > HDMI/DP hot
> > > > > plug event even if the display power well is disabled.
> > > > > > Although Gfx driver set Presence Detect and ELD Valid , the
> > > > > > audio
> > > > > controller does not wake up and so audio driver has no idea
> > > > > about the HDMI/DP hot-plug.
> > > > > >
> > > > > > Is it audio driver itself or the user space that need this ELD info?
> > > > > > Maybe Gfx driver can directly report ELD info to user space.
> > > > >
> > > > > If so, the graphics driver can wake up the audio driver as well
> > > > > -- this is yet one more reason to create a direct communication
> > > > > channel between the graphics and audio drivers :)
> > > >
> > > > Need the audio driver provide an API for gfx driver?
> > > > Maybe this API can call snd_hda_power_up(codec) and then
> > > > snd_hda_power_down(codec), thus the controller and codec will
> wake
> > > up and audio driver can check ELD info.
> > >
> > > Well, we can create a common object containing the ops registered by
> > > both graphics and audio drivers, then communicate through it,
> > > something like vga_switcheroo.
> >
> > Hi Takashi,
> >
> > I'm sure how to use a common object like vga_switcheroo. Would you
> please share more info?
> >
> > I feel a wake up process may be like this:
> > - Gfx driver detects the hot-plug at first and notify audio driver by the
> communication channel.
> > - In the notification callback, the audio driver wakes up the audio
> controller to D0, but codec can still stay in D3.
> >  (Hope we can add a time out for controller here to avoid controller
> > back to D3 at once and lose the capability to check unsol event)
> > - Then when Gfx driver enables or disables audio, and the audio
> controller can receive the unsol event in D0.
> > - Audio driver check ELD in unsol event handler, this will make codec
> resume to D0.
> 
> If we have a direct communication with the graphics driver, the audio
> driver doesn't wait for the unsol event at all.  It can retrieve ELD and
> even better port info more directly; i.e. we can skip even the wake up of
> the HDMI controller and codec chips.  The notification and ELD updates
> can be done without the audio hardware, after all (actual ELD updates will
> be done at resume).
> 

For audio, using the SW communication interface to retrieve ELD information directly from gfx driver will be more reliable than using the verb.

Today we observed ELD corruption on Haswell after the audio controller resumes from D3 to D0. I removed and reconnect HDMI monitor when the controller is in D3.
The gfx i195 driver will shut off the power well when HDMI monitor is removed and turn on power again when it detects HDMI is reconnected. 
But when I play something and thus resume the audio, ELD info shows monitor is present but ELD becomes invalid:
The ELD info got by audio driver is corrupted and audio driver complains 'invalid ELD version 0'. It seems to be the ELD corruption issue you mention before.

We found the gfx driver still gets the proper ELD and uses it to update HW buffer for audio side. However, reading back shows the HW buffer is corrupted and update fails.
So when theaudio driver uses verb to get ELD data, it also get the corrupted data.

If we force i915 to keeps its power well on (set i1915_disable_power_well = 0), there will be no ELD corruption. But we need to shut off power well if applicable for power saving.

So this adds one more reason to use a SW communication interface to retrieve the ELD info and other necessary info like port number.

Thanks
Mengdong

Re: HD-audio runtime PM

[Lin, Mengdong]

> -----Original Message-----
> From: Lin, Mengdong
> Sent: Wednesday, December 11, 2013 1:38 PM
> To: 'Takashi Iwai'
> Cc: Alsa-devel@alsa-project.org; Wang Xingchao; David Henningsson
> Subject: RE: [alsa-devel] HD-audio runtime PM
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de]
> > Sent: Tuesday, December 10, 2013 10:26 PM
> 
> > > > > HW team clarified that HDMI/DP jack insertion cannot wake up the
> > > > controller from D3. So this is a HW restriction for Haswell, not a
> > > > driver regression.
> > > > >
> > > > > Now the problem on Haswell/Broadwell is:
> > > > > After the controller enters D3, Gfx driver can still detect
> > > > > HDMI/DP hot
> > > > plug event even if the display power well is disabled.
> > > > > Although Gfx driver set Presence Detect and ELD Valid , the
> > > > > audio
> > > > controller does not wake up and so audio driver has no idea about
> > > > the HDMI/DP hot-plug.
> > > > >
> > > > > Is it audio driver itself or the user space that need this ELD info?
> > > > > Maybe Gfx driver can directly report ELD info to user space.
> > > >
> > > > If so, the graphics driver can wake up the audio driver as well --
> > > > this is yet one more reason to create a direct communication
> > > > channel between the graphics and audio drivers :)
> > >
> > > Need the audio driver provide an API for gfx driver?
> > > Maybe this API can call snd_hda_power_up(codec) and then
> > > snd_hda_power_down(codec), thus the controller and codec will wake
> > up and audio driver can check ELD info.
> >
> > Well, we can create a common object containing the ops registered by
> > both graphics and audio drivers, then communicate through it,
> > something like vga_switcheroo.
> 
> Hi Takashi,
> 
> I'm sure how to use a common object like vga_switcheroo. Would you
> please share more info?

A typo here. I'm NOT sure how to use it.

> I feel a wake up process may be like this:
> - Gfx driver detects the hot-plug at first and notify audio driver by the
> communication channel.
> - In the notification callback, the audio driver wakes up the audio
> controller to D0, but codec can still stay in D3.
>  (Hope we can add a time out for controller here to avoid controller back
> to D3 at once and lose the capability to check unsol event)
> - Then when Gfx driver enables or disables audio, and the audio controller
> can receive the unsol event in D0.
> - Audio driver check ELD in unsol event handler, this will make codec
> resume to D0.
> 
> Regards
> Mengdong

Re: HD-audio runtime PM

[Lin, Mengdong]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Tuesday, November 26, 2013 3:28 PM
> To: Lin, Mengdong
> Cc: Wang Xingchao; Alsa-devel@alsa-project.org; David Henningsson
> Subject: Re: [alsa-devel] HD-audio runtime PM
> 
> At Tue, 26 Nov 2013 06:56:12 +0000,
> Lin, Mengdong wrote:
> >
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > Sent: Tuesday, November 26, 2013 2:14 PM
> > > To: Wang Xingchao
> >
> > > > I test WAKEEN feature on Haswell machines before, it could really
> > > > wakeup system from D3.
> > >
> > > But the runtime suspend doesn't power down to D3 by itself.
> > > Did you test really with D3?
> >
> > I will double check this on Haswell with sound git tree for-linus branch.
> > We've tried Android on Haswell-ULT last week, the display HD-A
> controller can enter D3 and HDMI cable plug-in can wake up the controller
> and codec. The code base is v3.9 with various driver patches.
> 
> Hrm, but as I mentioned, we have no D3 call in runtime suspend callback.
> How does it reach to D3 then?  Maybe that part is patched in your side?
> 
> > For non-Haswell platforms, hardware team suggest that unless all of the
> codecs on the HD-A link support EPSS and ClkStopOK, runtime PM of the
> controller should not be enabled on the controller. Otherwise,
> functionality will be lost and there are likely going to be audio artifacts.
> 
> Is EPSS mandatory?  We have already a check of ClkStopOK bit, but EPSS
> influences only on the wait time, so far.

It's a suggestion based on Windows experience. 
So maybe we can add this check at the moment. How do you think?

Regards
Mengdong
 

Re: HD-audio runtime PM

[Takashi Iwai]

At Tue, 26 Nov 2013 08:53:00 +0000,
Lin, Mengdong wrote:
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de]
> > Sent: Tuesday, November 26, 2013 3:28 PM
> > To: Lin, Mengdong
> > Cc: Wang Xingchao; Alsa-devel@alsa-project.org; David Henningsson
> > Subject: Re: [alsa-devel] HD-audio runtime PM
> > 
> > At Tue, 26 Nov 2013 06:56:12 +0000,
> > Lin, Mengdong wrote:
> > >
> > > > -----Original Message-----
> > > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > > Sent: Tuesday, November 26, 2013 2:14 PM
> > > > To: Wang Xingchao
> > >
> > > > > I test WAKEEN feature on Haswell machines before, it could really
> > > > > wakeup system from D3.
> > > >
> > > > But the runtime suspend doesn't power down to D3 by itself.
> > > > Did you test really with D3?
> > >
> > > I will double check this on Haswell with sound git tree for-linus branch.
> > > We've tried Android on Haswell-ULT last week, the display HD-A
> > controller can enter D3 and HDMI cable plug-in can wake up the controller
> > and codec. The code base is v3.9 with various driver patches.
> > 
> > Hrm, but as I mentioned, we have no D3 call in runtime suspend callback.
> > How does it reach to D3 then?  Maybe that part is patched in your side?
> > 
> > > For non-Haswell platforms, hardware team suggest that unless all of the
> > codecs on the HD-A link support EPSS and ClkStopOK, runtime PM of the
> > controller should not be enabled on the controller. Otherwise,
> > functionality will be lost and there are likely going to be audio artifacts.
> > 
> > Is EPSS mandatory?  We have already a check of ClkStopOK bit, but EPSS
> > influences only on the wait time, so far.
> 
> It's a suggestion based on Windows experience. 
> So maybe we can add this check at the moment. How do you think?

Yes, it should be mostly harmless, as the recent codecs support
already EPSS, and we enabled the runtime PM only on new controllers.

We can simply move the code in patch_hdmi.c to hda_codec.c.


Takashi

Re: HD-audio runtime PM

[Takashi Iwai]

At Tue, 26 Nov 2013 09:56:00 +0100,
Takashi Iwai wrote:
> 
> At Tue, 26 Nov 2013 08:53:00 +0000,
> Lin, Mengdong wrote:
> > 
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > Sent: Tuesday, November 26, 2013 3:28 PM
> > > To: Lin, Mengdong
> > > Cc: Wang Xingchao; Alsa-devel@alsa-project.org; David Henningsson
> > > Subject: Re: [alsa-devel] HD-audio runtime PM
> > > 
> > > At Tue, 26 Nov 2013 06:56:12 +0000,
> > > Lin, Mengdong wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > > > Sent: Tuesday, November 26, 2013 2:14 PM
> > > > > To: Wang Xingchao
> > > >
> > > > > > I test WAKEEN feature on Haswell machines before, it could really
> > > > > > wakeup system from D3.
> > > > >
> > > > > But the runtime suspend doesn't power down to D3 by itself.
> > > > > Did you test really with D3?
> > > >
> > > > I will double check this on Haswell with sound git tree for-linus branch.
> > > > We've tried Android on Haswell-ULT last week, the display HD-A
> > > controller can enter D3 and HDMI cable plug-in can wake up the controller
> > > and codec. The code base is v3.9 with various driver patches.
> > > 
> > > Hrm, but as I mentioned, we have no D3 call in runtime suspend callback.
> > > How does it reach to D3 then?  Maybe that part is patched in your side?
> > > 
> > > > For non-Haswell platforms, hardware team suggest that unless all of the
> > > codecs on the HD-A link support EPSS and ClkStopOK, runtime PM of the
> > > controller should not be enabled on the controller. Otherwise,
> > > functionality will be lost and there are likely going to be audio artifacts.
> > > 
> > > Is EPSS mandatory?  We have already a check of ClkStopOK bit, but EPSS
> > > influences only on the wait time, so far.
> > 
> > It's a suggestion based on Windows experience. 
> > So maybe we can add this check at the moment. How do you think?
> 
> Yes, it should be mostly harmless, as the recent codecs support
> already EPSS, and we enabled the runtime PM only on new controllers.
> 
> We can simply move the code in patch_hdmi.c to hda_codec.c.

That is, a patch like below.  This was queued to test/hda branch of
sound-unstable git tree.


Takashi

-- >8 --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] ALSA: hda - Disable runtime PM when EPSS is unavailable

According to Mengdong, we shouldn't enable runtime PM when a codec
doesn't support EPSS, based on the experiences on Windows.
We have already this check in HDMI codec drivers, but now apply it in
general in hda_codec.c.

Credit goes to Mengdong Lin <mengdong.lin@intel.com>

Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/pci/hda/hda_codec.c  |  7 +++++--
 sound/pci/hda/patch_hdmi.c | 11 -----------
 2 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 8f7295bdccbd..6deb8d1852cc 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -1510,11 +1510,14 @@ int snd_hda_codec_new(struct hda_bus *bus,
 #ifdef CONFIG_PM
 	codec->d3_stop_clk = snd_hda_codec_get_supported_ps(codec, fg,
 					AC_PWRST_CLKSTOP);
-	if (!codec->d3_stop_clk)
-		bus->power_keep_link_on = 1;
 #endif
 	codec->epss = snd_hda_codec_get_supported_ps(codec, fg,
 					AC_PWRST_EPSS);
+#ifdef CONFIG_PM
+	if (!codec->d3_stop_clk || !codec->epss)
+		bus->power_keep_link_on = 1;
+#endif
+
 
 	/* power-up all before initialization */
 	hda_set_power_state(codec, AC_PWRST_D0);
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 1773a640e72e..4098196b2300 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1692,17 +1692,6 @@ static int hdmi_parse_codec(struct hda_codec *codec)
 		}
 	}
 
-#ifdef CONFIG_PM
-	/*
-	 * G45/IbexPeak don't support EPSS: the unsolicited pin hot plug event
-	 * can be lost and presence sense verb will become inaccurate if the
-	 * HDA link is powered off at hot plug or hw initialization time.
-	 */
-	if (!(snd_hda_param_read(codec, codec->afg, AC_PAR_POWER_STATE) &
-	      AC_PWRST_EPSS))
-		codec->bus->power_keep_link_on = 1;
-#endif
-
 	return 0;
 }
 
-- 
1.8.4.3