[Bug 74861] [hsw regression] Fast audio playback on Intel Haswell HDMI due to runtime pm

[bugzilla-daemon at bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=74861

--- Comment #45 from Mengdong Lin <mengdong.lin at intel.com> ---
> Good news! I applied the patch and works BUT
> only in some cases.

> If I disconnect the power cable at AND no sound is
> routed through HDMI in that moment sound starts to work at correct
> speed/pitch.

> Make some research I noticed that azx_runtime_suspend is
> called when I disconnect the power cable. I added a printk in
> azx_runtime_suspend() with a counter to detect how many times is called and
> which are EM4 and EM5 values.

It seems the power policy is to enable runtime PM on devices when power cable
is removed.

> Results of tests made with HDMI cable
> connected.

> When I unplug power cable WITH an application sound routed to
> HDMI the result is:
> [  221.162532]  *** M/N Values [1]: 0/37312
> pitched up and wrong speed.

It's strange. Since when sound is routed to HDMI, audio device is active and
should not be suspended, so azx_runtime_suspend() should not be called until
the playback ends.

> When I unplug power cable WITHOUT an
> application routed to HDMI and later use HDMI sound result is:
>[ 
> 256.856095]  *** M/N Values [2]: 4/75
> And sound works perfect in correct
> pitch at correct speed and later if I replug power cable continues sounding
> ok, at this moment HDMI sound works permanently ok until I shutdown the
> system.

M/N Values [2]: 4/75 is for 450MHz default CDClock. If the pitch is correct, it
means the CDClock is 450Mhz, not 540Mhz. We'll adding dump CDClock in
intel_audio_dump.

In addtion, Gfx driver will add notification to BIOS and let BIOS reprograms
EM4/EM5 as per CD clock when restoring the shared power well with audio.
Hopefully this feature can be done this week or next.

-- 
You are receiving this mail because:
You are on the CC list for the bug.