Bug 75729 - [hsw dp audio] Muting S/PDIF turns off DP
[hsw dp audio] Muting S/PDIF turns off DP
Status: RESOLVED INVALID
Product: DRI
Classification: Unclassified
Component: DRM/Intel
unspecified
x86-64 (AMD64) Linux (All)
: medium normal
Assigned To: Intel GFX Bugs mailing list
Intel GFX Bugs mailing list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-03 21:24 UTC by Daniel Martin
Modified: 2014-12-04 21:12 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg 3.13.4 (stock Arch kernel, booted with drm.debug=0xe) (88.82 KB, text/plain)
2014-03-03 21:24 UTC, Daniel Martin
no flags Details
alsa-info.log (v3.13.6) (24.32 KB, text/plain)
2014-03-23 16:14 UTC, Daniel Martin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Martin 2014-03-03 21:24:46 UTC
Created attachment 95061 [details]
dmesg 3.13.4 (stock Arch kernel, booted with drm.debug=0xe)

This time it's not a bug with a ThinkPad nor a docking station involved, even no laptop at all. But, again it's some DP vs. audio "issue".

I have just set up my new desktop at home. It's a Haswell i7-4770 sitting on a Intel DH87RL board. A monitor (iiyama 27") is connected via DP. This monitor has a massive sound system of 2x2W speakers build in, which I tested (this bug report doesn't cover the audio quality).

So, the audio output via DP to the monitor played and I just tested to mute the S/PDIF via alsamixer ... and the monitor turned off into standby, audio stoped. Blindly typing another 'm' to unmute the S/PDIF and the monitor turned back on and the audio playback proceeded.

If I don't play audio and mute the S/PDIF, the monitor stays active/on. Until I start playing audio.


I've attached a dmesg log (drm.debug=0xe) of a boot to the console, where I have played audio and muted the S/PDIF. Though, the log doesn't show anything after the login. There's a "[drm:ivb_err_int_handler], Pipe A FIFO underrun" at the end, but I don't think (...famous noob words) that this is related because I've "turned off" the monitor via muting during this boot a couple of times and this message doesn't show up.


How can provide any useful debug logs for this issue? (I guess: build a kernel with alsa-debug options?)
Comment 1 Jani Nikula 2014-03-04 07:42:12 UTC
CC Mengdong. Any ideas?
Comment 2 Daniel Martin 2014-03-06 12:34:10 UTC
I think most people want be affected by this as they don't touch the S/PDIF directly. They may use something like pulseaudio in between. Even I may have to use it for volume control.

This misbehaviour exists, but it's not a showstopper for me and I don't mind if you set and treat this bug as lowest-minor.
Comment 3 Mengdong Lin 2014-03-12 13:10:42 UTC
Hi Martin/Jani,

Sorry for the late reply. 

I don't think this is an audio driver issue, because audio driver operations does not directly cause screen on/off. Screen on/off is controlled by Gfx driver.

For Haswell, the display audio devices (controller + codec) share the same power well with display. So the audio verb excution, such as muting/unmuting S/PDIF can wake up the audio devices and the audio driver will request power from Graphic driver. When audio devcies are idle (in D3), the audio driver will notify gfx driver it does not need the power. That's all. And even if the gfx driver keeps the power well always on, it can still turn on/off the screen.

It seems to me that some user space module binds ALSA S/PDIF mute control with screen on/off. 

Thanks
Mengdong
Comment 4 Daniel Martin 2014-03-13 07:16:52 UTC
(In reply to comment #3)
> Hi Martin/Jani,
> 
> Sorry for the late reply. 

No problem, as stated it's not a showstopper for me. (And I'm even worse with replies.)

> I don't think this is an audio driver issue, because audio driver operations
> does not directly cause screen on/off. Screen on/off is controlled by Gfx
> driver.
> 
> For Haswell, the display audio devices (controller + codec) share the same
> power well with display. So the audio verb excution, such as muting/unmuting
> S/PDIF can wake up the audio devices and the audio driver will request power
> from Graphic driver. When audio devcies are idle (in D3), the audio driver
> will notify gfx driver it does not need the power. That's all. And even if
> the gfx driver keeps the power well always on, it can still turn on/off the
> screen.
> 
> It seems to me that some user space module binds ALSA S/PDIF mute control
> with screen on/off. 

What do you mean by "user space module", some ALSA module configured with alsa.conf and friends? The only ALSA configuration I set is to choose the card with S/PDIF as default. I'll remove it for testing and may temporarily remove system provided ALSA configurations as well.
Everything else is as bare as a fresh Archlinux installs it, using slim for login and spectrwm as WM. So, no fency hidden stuff should happen.
Comment 5 Mengdong Lin 2014-03-20 08:16:26 UTC
Hi Martin,

Could you raise the question to ALSA mailiing list alsa-devel@alsa-project.org?

I'm not sure about user space behavior. 
Maybe someone on the mailist list could share more information.

Thanks
Mengdong
Comment 6 Daniel Martin 2014-03-23 16:14:17 UTC
Created attachment 96246 [details]
alsa-info.log (v3.13.6)

Output of alsa-util-alsa-info.sh.
Comment 7 Daniel Martin 2014-03-24 10:41:17 UTC
(In reply to comment #5)
> Could you raise the question to ALSA mailiing list
> alsa-devel@alsa-project.org?
>
> I'm not sure about user space behavior. 
> Maybe someone on the mailist list could share more information.

Done and Takashi Iwai replied: It's an issue of Haswell graphics side.  From the audio POV, it merely turns on/off the IEC958 status bits in the HDMI audio codec.
    http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/074707.html
Comment 8 Jani Nikula 2014-09-05 12:40:07 UTC
Please re-test with current drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel
Comment 9 Jesse Barnes 2014-12-04 21:12:42 UTC
Hoping this is fixed now.  Daniel, if not, please re-open.  But we've made changes to the audio well handling and lots of other things since March, so hopefully this is resolved too.