Bug 74861

To clarify, I did test this on kernel master, and the bug still exists.

I can confirm the issue on Dell XPS, Ubuntu 14.04, kernel 3.13.0-24-generic.

I have some output of lspci. Passing i915.disable_power_well=0 solves the problem.

+Daniel Vetter

I can confirm the problem and that the fix works on a Chillblast Defiant 13" Laptop with Haswell/Optimus Architecture, Core i7 Processor and nVidia GTX 765M graphics.

How long does will it take for this to get into the kernels?

Optimus is another kind of beast.  Remember that the HDMI audio is always coupled with graphics.  And when it plays with Nvidia...

In anyway, if the problem gets fixed by disabling the powerwell, it implies either the powerwell refcounting isn't correct or the audio power domain alone isn't sufficient for the proper HDMI audio.

Is the problem always seen unless i915.disable_power_well=0 is passed?  For example, if you replug HDMI and play on your TV (I suppose it's no extra receiver), does the problem remain?

Then, check whether the audio side is really properly configured.   At least, /proc/asound/card*/eld#* file should show that the monitor is connected and ELD is valid.

If it's properly connected, the next thing to check is /sys/kernel/debug/dri/64/i915/i915_power_domain.  What entries are enabled there.

I can confirm the same problem on a Toshiba Satellite P50-A 13" with Haswell/Optimus Core i7 and nVidia GT 740M.

Analog output sound at correct pitch, HDMI output sound pitched up.

Passing i915.disable_power_well=0 solves the problem.

(In reply to Takashi Iwai from comment #5)

> Is the problem always seen unless i915.disable_power_well=0 is passed?  For
> example, if you replug HDMI and play on your TV (I suppose it's no extra
> receiver), does the problem remain?
Yes
> 
> Then, check whether the audio side is really properly configured.   At
> least, /proc/asound/card*/eld#* file should show that the monitor is
> connected and ELD is valid.
/proc/asound/HDMI/eld#0.2 contains
monitor_present		1
eld_valid		0
> 
> If it's properly connected, the next thing to check is
> /sys/kernel/debug/dri/64/i915/i915_power_domain.  What entries are enabled
> there.
Lots of files in folder but not one of that name

(In reply to Peter Curtis from comment #7)
> (In reply to Takashi Iwai from comment #5)
> 
> > Is the problem always seen unless i915.disable_power_well=0 is passed?  For
> > example, if you replug HDMI and play on your TV (I suppose it's no extra
> > receiver), does the problem remain?
> Yes

OK, and you're *not* using Nvidia binary-only driver, right?

> > Then, check whether the audio side is really properly configured.   At
> > least, /proc/asound/card*/eld#* file should show that the monitor is
> > connected and ELD is valid.
> /proc/asound/HDMI/eld#0.2 contains
> monitor_present               1
> eld_valid             0

This is the reason of the wrong speed.  The audio driver isn't informed how to set up the channels.

> > If it's properly connected, the next thing to check is
> > /sys/kernel/debug/dri/64/i915/i915_power_domain.  What entries are enabled
> > there.
> Lots of files in folder but not one of that name

Are you testing with the latest Linus tree (or 3.15-rc7)?

(In reply to Takashi Iwai from comment #8)
> (In reply to Peter Curtis from comment #7)
> > (In reply to Takashi Iwai from comment #5)
> 
> OK, and you're *not* using Nvidia binary-only driver, right?

I am using Bumblebee and nVidia Drivers - tested with nVidia -319 and -331

> Are you testing with the latest Linus tree (or 3.15-rc7)?

I checked that it works without i915.disable_power_well=0 passed with 3.10.33 and it fails with standard Mint 17/Ubuntu Trusty 3.13.0-24-generic and mainline 3.14.4 unless i915.disable_power_well=0 passed. This is my main work machine and I can not afford to put it at risk with rc kernels.

There are two mandatory conditions for continuing debug:

- Don't use Nvidia binary-only driver
- Test with the latest upstream kernel

Unless there are satisfied, no upstream devs will work on any issues.  Especially no excuse about the first item.

One when you get a clean system and tested the latest driver, you should be able to get the information requested in comment 5.

(In reply to Takashi Iwai from comment #10)
> There are two mandatory conditions for continuing debug:
> 
> - Don't use Nvidia binary-only driver
> - Test with the latest upstream kernel
>
It does not even boot without disabling the Nouveau driver in my case!
 
> Unless there are satisfied, no upstream devs will work on any issues. 
> Especially no excuse about the first item.

See below.

> 
> One when you get a clean system and tested the latest driver, you should be
> able to get the information requested in comment 5.

I only put in an input in order to help confirm that the answer to quote "Now that the audio driver is using our power well API, everything should be working correctly, so let's give it a try. " was that either it did not work or there were unintended consequences in some cases. I have provided the output so far from my main machine I work on and there is no way I am going to mess around with rc kernels and changing drivers on a machine which now works perfectly. 

The problem seems well defined and the solution is too reverse a "lets see what happens" commit and the bug is already assigned so an upstream dev is working on it. The kernel developers have done and continue to do a magnificent job and I am happy to volunteer information. I however see no reason why I should be put under pressure to increase my invovement, it is 40 years since I wrote a kernel (for F100 hardened microprocessor) and my opensource contributions are now in a different area.

> OK, and you're *not* using Nvidia binary-only driver, right?

I don't use nvidia binary, just nouveau

> Are you testing with the latest Linus tree (or 3.15-rc7)?

I can confirm the bug exists in 3.15-rc7

(In reply to Takashi Iwai from comment #5)
> Optimus is another kind of beast.  Remember that the HDMI audio is always
> coupled with graphics.  And when it plays with Nvidia...
> 
Nouveau.

> In anyway, if the problem gets fixed by disabling the powerwell, it implies
> either the powerwell refcounting isn't correct or the audio power domain
> alone isn't sufficient for the proper HDMI audio.
> 
> Is the problem always seen unless i915.disable_power_well=0 is passed?  For
> example, if you replug HDMI and play on your TV (I suppose it's no extra
> receiver), does the problem remain?

Yes, the problem remains although replug HDMI connector.

> Then, check whether the audio side is really properly configured.   At
> least, /proc/asound/card*/eld#* file should show that the monitor is
> connected and ELD is valid.

$ cat /proc/asound/card0/eld#0.1
monitor_present         1
eld_valid               1
monitor_name            Panasonic-TV
connection_type         HDMI
eld_version             [0x2] CEA-861D or below
edid_version            [0x3] CEA-861-B, C or D
manufacture_id          0xa934
product_id              0xa0a7
port_id                 0x0
support_hdcp            0
support_ai              1
audio_sync_delay        0
speakers                [0xffff] FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC FLW/FRW FLH/FRH TC FCH
sad_count               1
sad0_coding_type        [0x1] LPCM
sad0_channels           2
sad0_rates              [0xe0] 32000 44100 48000
sad0_bits               [0x20000] 16

 
> If it's properly connected, the next thing to check is
> /sys/kernel/debug/dri/64/i915/i915_power_domain.  What entries are enabled
> there.

There is no such file /sys/kernel/debug/dri/64/i915/i915_power_domain but there is another with smiliar name I dump here:

# cat /sys/kernel/debug/dri/64/i915_power_domain_info 
Power well/domain         Use count
always-on                 4
  PIPE_A                  1
  TRANSCODER_EDP          1
  PORT_DDI_A_2_LANES      0
  PORT_DDI_A_4_LANES      1
  PORT_DDI_B_2_LANES      0
  PORT_DDI_B_4_LANES      0
  PORT_DDI_C_2_LANES      0
  PORT_DDI_C_4_LANES      1
  PORT_DDI_D_2_LANES      0
  PORT_DDI_D_4_LANES      0
  PORT_CRT                0
  INIT                    0
display                   3
  PIPE_B                  1
  PIPE_C                  0
  PIPE_A_PANEL_FITTER     0
  PIPE_B_PANEL_FITTER     0
  PIPE_C_PANEL_FITTER     0
  TRANSCODER_A            1
  TRANSCODER_B            0
  TRANSCODER_C            0
  PORT_DSI                0
  PORT_OTHER              0
  VGA                     0
  AUDIO                   1
  INIT                    0

OK, now it's getting more interesting.  In Peter's case, eld#* don't show the ELD, thus it cannot work at all.  Unless he is willing to test without Nvidia driver, we cannot help at all.  One of principles of debugging is to isolate the problem.  Using Nvidia driver makes it impossible.

Meanwhile, in Daniel's case, the audio driver itself receives ELD properly, and the powerwell refcount isn't zero.  So, this looks as if it should work indeed, and worth to take a deeper look.

How is i915_power_domain_info in the working case (i.e. with i915.disable_power_well=0)?

Also, checking the following would be helpful to understand the problem:

- Can the machine boot without Nvidia graphics?  Some BIOS can disable it.  This reduces the possible bad interaction and concentrate on i915 driver.

- Boot with drm.debug=0x0e option and take the dmesg output for both working and non-working cases.

- Install intel-gpu-tools package and run intel_reg_dumper and intel_audio_dump programs, save the outputs for both working and non-working cases.

- Test with power_save_controller=0 option for snd-hda-intel instead of i915.disable_power_well=0 option.

(In reply to Takashi Iwai from comment #14)
> OK, now it's getting more interesting.  In Peter's case, eld#* don't show
> the ELD, thus it cannot work at all.  Unless he is willing to test without
> Nvidia driver, we cannot help at all.  One of principles of debugging is to
> isolate the problem.  Using Nvidia driver makes it impossible.
I had assumed Bumbleebee had disabled the driver and I have tested with and without the driver via bummblebee. I have no problem booting without the nVidia driver if there is a suitable boot option you can give me - I had to use nouveau.modeset=0 to disable the nouveau driver in some kernels to get a successful boot, is there a similar one to inhibit nVidia?
> 
> Meanwhile, in Daniel's case, the audio driver itself receives ELD properly,
> and the powerwell refcount isn't zero.  So, this looks as if it should work
> indeed, and worth to take a deeper look.
> 
> How is i915_power_domain_info in the working case (i.e. with
> i915.disable_power_well=0)?
> 
> Also, checking the following would be helpful to understand the problem:
> 
> - Can the machine boot without Nvidia graphics?  Some BIOS can disable it. 
> This reduces the possible bad interaction and concentrate on i915 driver.
Nothing in Bios settings in my case
> 
> - Boot with drm.debug=0x0e option and take the dmesg output for both working
> and non-working cases.
> 
> - Install intel-gpu-tools package and run intel_reg_dumper and
> intel_audio_dump programs, save the outputs for both working and non-working
> cases.
> 
> - Test with power_save_controller=0 option for snd-hda-intel instead of
> i915.disable_power_well=0 option.
Are any of the above useful even with nVidia drivers?

(In reply to Peter Curtis from comment #15)
> (In reply to Takashi Iwai from comment #14)
> > OK, now it's getting more interesting.  In Peter's case, eld#* don't show
> > the ELD, thus it cannot work at all.  Unless he is willing to test without
> > Nvidia driver, we cannot help at all.  One of principles of debugging is to
> > isolate the problem.  Using Nvidia driver makes it impossible.
> I had assumed Bumbleebee had disabled the driver and I have tested with and
> without the driver via bummblebee. I have no problem booting without the
> nVidia driver if there is a suitable boot option you can give me - I had to
> use nouveau.modeset=0 to disable the nouveau driver in some kernels to get a
> successful boot, is there a similar one to inhibit nVidia?

I guess module blacklist should work.  But, the easiest hack would be just to remove kernel module files.  And, don't forget to rebuild initrd if such modules are included in there.

> > Meanwhile, in Daniel's case, the audio driver itself receives ELD properly,
> > and the powerwell refcount isn't zero.  So, this looks as if it should work
> > indeed, and worth to take a deeper look.
> > 
> > How is i915_power_domain_info in the working case (i.e. with
> > i915.disable_power_well=0)?
> > 
> > Also, checking the following would be helpful to understand the problem:
> > 
> > - Can the machine boot without Nvidia graphics?  Some BIOS can disable it. 
> > This reduces the possible bad interaction and concentrate on i915 driver.
> Nothing in Bios settings in my case

OK.

> > - Boot with drm.debug=0x0e option and take the dmesg output for both
> working
> > and non-working cases.
> > 
> > - Install intel-gpu-tools package and run intel_reg_dumper and
> > intel_audio_dump programs, save the outputs for both working and
> non-working
> > cases.
> > 
> > - Test with power_save_controller=0 option for snd-hda-intel instead of
> > i915.disable_power_well=0 option.
> Are any of the above useful even with nVidia drivers?

Yes, but let's begin with the simplified use case, Intel-only.

It's worth mentioning that this problem is surely not specific to nvidia graphics, as I experience this problem on my System76 Gazelle Pro which has exclusively intel onboard graphics.

I'll do some of the diagnostics you suggest and see what comes up.

Created attachment 137761 [details]
Script: gathers some debug info

Created attachment 137771 [details]
nshepperd-working: Debugging info in working case

Created attachment 137781 [details]
nshepperd-nonworking: Debugging info in nonworking case

Firstly, passing snd_hda_intel.power_save_controller=0 doesn't seem to make any difference. Is that right, or does it have to be snd-hda-intel.power_save_controller?

I obtained the data you suggested in working (i915.disable_power_well=0 drm.debug=0x0e) and nonworking (drm.debug=0x0e) cases, anyway. I did the tests with the monitor (it is actually a TV) attached and configured with xrandr. Results are attached, as well as the script I used.

snd_hda_intel.power_save_controller=0 should work.  But better to check /sys/module/snd_hda_intel/parameters/power_save_controller value.  Also, note that some desktop environment may change this value dynamically depending on the battery/power status.

Neil, could you give the result with 3.15-rc8?  The power domain controls have been changed since 3.14, and I don't want to waste time for tracking old issues.

(In reply to Takashi Iwai from comment #23)
> Neil, could you give the result with 3.15-rc8?  The power domain controls

In 3.15-rc8 same problem.

Loaded snd_hda_intel with power_save_controller=0 and sounds pitched up.

$ cat /sys/module/snd_hda_intel/parameters/power_save_controller
N

Yeah, I guessed so.
My question was rarher about the logs as you provided with the old kernel.
Could you take again for both working and non-working cases, but with the latest kernel?  Thanks.

Created attachment 138031 [details]
HDMI Sound working ok

Created attachment 138041 [details]
Debugging info HDMI Sound working bad

Created attachment 138051 [details]
Debugging info HDMI Sound working ok

Thanks.  In Daniel's case, again, the ELD transfer failed between video and audio.  Doing grep ELD for non-working log,

[    2.382852] [drm:haswell_write_eld] ELD on pipe B
[    2.382857] [drm:haswell_write_eld] ELD size 9
[    3.509002] [drm:drm_edid_to_eld] ELD: no CEA Extension found
[    3.563563] [drm:drm_edid_to_eld] ELD monitor Panasonic-TV
[    3.563566] [drm:drm_edid_to_eld] ELD size 9, SAD count 1
[   16.820283] HDMI: Unknown ELD version 1
[   16.821756] HDMI: Unknown ELD version 1
...

This implies that the contents of passed ELD to the audio is broken by some reason.

Since HSW_PWR_WELL_CTL* are identical in both cases, might this be a timing issue?  What if you put some delay in hsw_set_power_well() in intel_pm.c?

(In reply to Takashi Iwai from comment #29)

> Since HSW_PWR_WELL_CTL* are identical in both cases, might this be a timing
> issue?  What if you put some delay in hsw_set_power_well() in intel_pm.c?

Where I put the delay? At the ending of hsw_set_power_well()? I'll try with a msleep(250), is this correct?

Yeah, that should suffice, I suppose.

(In reply to Takashi Iwai from comment #31)
> Yeah, that should suffice, I suppose.

The problem persists with the delay, sounds pitched up.

Dmesg is still having same error "HDMI: Unknown ELD version 1"


$ dmesg |grep ELD
[    2.479527] [drm:intel_write_eld] ELD on [CONNECTOR:24:HDMI-A-1], [ENCODER:23:TMDS-23]
[    2.541908] [drm:haswell_write_eld] ELD on pipe B
[    2.541912] [drm:haswell_write_eld] ELD size 9
[    2.912819] [drm:drm_edid_to_eld] ELD: no CEA Extension found
[    2.967631] [drm:drm_edid_to_eld] ELD monitor Panasonic-TV
[    2.967634] [drm:drm_edid_to_eld] ELD size 9, SAD count 1
[   19.269978] HDMI: Unknown ELD version 1
[   19.271447] HDMI: Unknown ELD version 1
[   19.272983] HDMI: Unknown ELD version 1
[...]

OK, thanks.  Could you add the following line and get the dump of ELD contents in both good and bad cases?

diff --git a/sound/pci/hda/hda_eld.c b/sound/pci/hda/hda_eld.c
index 46690a7f48f6..52a20b4cc021 100644
--- a/sound/pci/hda/hda_eld.c
+++ b/sound/pci/hda/hda_eld.c
@@ -253,6 +253,8 @@ int snd_hdmi_parse_eld(struct parsed_hdmi_eld *e,
 	int mnl;
 	int i;
 
+	print_hex_dump(KERN_INFO, "ELD", DUMP_PREFIX_OFFSET, 16, 1, buf, size, false);
+
 	e->eld_ver = GRAB_BITS(buf, 0, 3, 5);
 	if (e->eld_ver != ELD_VER_CEA_861D &&
 	    e->eld_ver != ELD_VER_PARTIAL) {

(In reply to Takashi Iwai from comment #33)
> OK, thanks.  Could you add the following line and get the dump of ELD
> contents in both good and bad cases?

ELD Dump working:
[   20.386070] ELD00000000: 10 00 09 00 6c 12 00 00 00 00 00 00 00 00 00 00
[   20.386072] ELD00000010: 34 a9 a7 a0 50 61 6e 61 73 6f 6e 69 63 2d 54 56
[   20.386073] ELD00000020: 09 07 01 00 00 00 00 00 00 00 00 00 00 00 00 00
[   20.386074] ELD00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   20.386075] ELD00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   20.386075] ELD00000050: 00 00 00

ELD Dump non-working:
[   20.530389] ELD00000000: 09 07 01 00 00 00 00 00 00 00 00 00 00 00 00 00
[   20.530392] ELD00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   20.530393] ELD00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   20.530394] ELD00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   20.530395] ELD00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   20.530395] ELD00000050: 00 00 00
[   20.530396] HDMI: Unknown ELD version 1

I have a similar problem with HDMI Video/Audio output on a Haswell Core i5 Processor with an Intel Mainboard, but the difference for me is that audio output doesn't work either even if I set i915.disable_power_well=0 and/or snd_hda_intel.power_save_controller=0 at boottime.

To narrow down what hardware causes the problem I can definitly say that only i5 processors and (probably) i7 are affected. On a Intel Core i3 audio/video was working with identical mainboard, kernel configuration and monitor. I haven't the i3 configuration anymore so I can't post the hardware difference, but the main difference I saw earlier between an i3 and an i5 is the second audio "node"/"device". It's not a problem with other VGA cards plugged in, problem exists with and without them plugged in.

The problem still exists in 3.15.1 even with applied tiwai and/or broonie subtree sound kernel patches applied. Analog+USB sound output is working normal.

What makes me thoughtful is the output /proc/asound/card0/codec#0 which reports no "Default PCM" settings (which is unnormal compared to other systems) and "No Modem Function Group found" (maybe normal, got this on other working systems).

# cat /proc/asound/card0/eld#0.0
monitor_present		0
eld_valid		0

# cat /proc/asound/card0/eld#0.1
monitor_present		1
eld_valid		1
monitor_name		W2442
connection_type		HDMI
eld_version		[0x2] CEA-861D or below
edid_version		[0x3] CEA-861-B, C or D
manufacture_id		0x6d1e
product_id		0x56cc
port_id			0x0
support_hdcp		0
support_ai		0
audio_sync_delay	0
speakers		[0x1] FL/FR
sad_count		1
sad0_coding_type	[0x1] LPCM
sad0_channels		2
sad0_rates		[0xe0] 32000 44100 48000
sad0_bits		[0xe0000] 16 20 24

# cat /sys/kernel/debug/dri/64/i915_power_domain_info 
Power well/domain         Use count
always-on                 3
  PIPE_A                  1
  TRANSCODER_EDP          0
  PORT_DDI_A_2_LANES      0
  PORT_DDI_A_4_LANES      0
  PORT_DDI_B_2_LANES      0
  PORT_DDI_B_4_LANES      1
  PORT_DDI_C_2_LANES      0
  PORT_DDI_C_4_LANES      0
  PORT_DDI_D_2_LANES      0
  PORT_DDI_D_4_LANES      1
  PORT_CRT                0
  INIT                    0
display                   4
  PIPE_B                  1
  PIPE_C                  0
  PIPE_A_PANEL_FITTER     0
  PIPE_B_PANEL_FITTER     0
  PIPE_C_PANEL_FITTER     0
  TRANSCODER_A            1
  TRANSCODER_B            1
  TRANSCODER_C            0
  PORT_DSI                0
  PORT_OTHER              0
  VGA                     0
  AUDIO                   1
  INIT                    0

# cat /proc/asound/card0/codec#0 
Codec: Intel Haswell HDMI
Address: 0
AFG Function Id: 0x1 (unsol 0)
Vendor Id: 0x80862807
Subsystem Id: 0x80860101
Revision Id: 0x100000
No Modem Function Group found
Default PCM:
    rates [0x0]:
    bits [0x0]:
    formats [0x0]:
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
State of AFG node 0x01:
  Power states:  D0 D3 CLKSTOP EPSS
  Power: setting=D0, actual=D0, Clock-stop-OK
GPIO: io=0, o=0, i=0, unsolicited=0, wake=0
Node 0x02 [Audio Output] wcaps 0x6611: 8-Channels Digital
  Device: name="HDMI 1", type="HDMI", device=7
  Converter: stream=1, channel=0
  Digital: Enabled GenLevel KAE
  Digital category: 0x2
  IEC Coding Type: 0x0
  PCM:
    rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000
    bits [0x1e]: 16 20 24 32
    formats [0x5]: PCM AC3
  Power states:  D0 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x03 [Audio Output] wcaps 0x6611: 8-Channels Digital
  Converter: stream=0, channel=0
  Digital: Enabled KAE
  Digital category: 0x0
  IEC Coding Type: 0x0
  PCM:
    rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000
    bits [0x1e]: 16 20 24 32
    formats [0x5]: PCM AC3
  Power states:  D0 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x04 [Audio Output] wcaps 0x6611: 8-Channels Digital
  Converter: stream=0, channel=0
  Digital: Enabled KAE
  Digital category: 0x0
  IEC Coding Type: 0x0
  PCM:
    rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000
    bits [0x1e]: 16 20 24 32
    formats [0x5]: PCM AC3
  Power states:  D0 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x05 [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x0b000094: OUT Detect HBR HDMI DP
  Pin Default 0x58560010: [N/A] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D3 EPSS
  Power: setting=D0, actual=D0
  Devices: 0
  Connection: 3
     0x02 0x03* 0x04
Node 0x06 [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP
  Control: name="HDMI/DP,pcm=3 Jack", index=0, device=0
  Control: name="IEC958 Playback Con Mask", index=0, device=0
  Control: name="IEC958 Playback Pro Mask", index=0, device=0
  Control: name="IEC958 Playback Default", index=0, device=0
  Control: name="IEC958 Playback Switch", index=0, device=0
  Control: name="ELD", index=0, device=3
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x0b000094: OUT Detect HBR HDMI DP
  Pin Default 0x18560020: [Jack] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0x2, Sequence = 0x0
  Pin-ctls: 0x00:
  Unsolicited: tag=01, enabled=1
  Power states:  D0 D3 EPSS
  Power: setting=D0, actual=D0
  Devices: 0
  Connection: 0
  In-driver Connection: 3
     0x02 0x03 0x04
Node 0x07 [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP
  Control: name="HDMI/DP,pcm=7 Jack", index=0, device=0
  Control: name="IEC958 Playback Con Mask", index=1, device=0
  Control: name="IEC958 Playback Pro Mask", index=1, device=0
  Control: name="IEC958 Playback Default", index=1, device=0
  Control: name="IEC958 Playback Switch", index=1, device=0
  Control: name="ELD", index=0, device=7
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x0b000094: OUT Detect HBR HDMI DP
  Pin Default 0x18560030: [Jack] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0x3, Sequence = 0x0
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=02, enabled=1
  Power states:  D0 D3 EPSS
  Power: setting=D0, actual=D0
  Devices: 0
  Connection: 3
     0x02* 0x03 0x04
Node 0x08 [Vendor Defined Widget] wcaps 0xf00000: Mono

I can confirm that after hours of serching the internet and trying fixes that passing i915.disable_power_well=0 on the kernel command line works around the problem, letting audio play at the correct speed again.

I'm running a Shuttle SZ87R6 with Intel Core i7-4770K Intel Z87 Chipset using on board video and audio.  The HDMI and Optical out is going to a Pioneer Suround Sound System before the HDMI continues on to my projector. 

The S/PDIF works perfectly all the time but only has 2 channel audio which is annoying so I wanted to use the HDMI of course.  All my read debugging matched the others having same problem with all Intel hardware.  Followed everything here and confirmed.  Want any more information from me I will supply anything to help fix it right.

Forgot to mention I'm running KUbuntu 14.04 Trusty.

(In reply to Daniel Fernández from comment #34)
> (In reply to Takashi Iwai from comment #33)
> > OK, thanks.  Could you add the following line and get the dump of ELD
> > contents in both good and bad cases?
> 
> ELD Dump working:
> [   20.386070] ELD00000000: 10 00 09 00 6c 12 00 00 00 00 00 00 00 00 00 00
> [   20.386072] ELD00000010: 34 a9 a7 a0 50 61 6e 61 73 6f 6e 69 63 2d 54 56
> [   20.386073] ELD00000020: 09 07 01 00 00 00 00 00 00 00 00 00 00 00 00 00
> [   20.386074] ELD00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [   20.386075] ELD00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [   20.386075] ELD00000050: 00 00 00
> 
> ELD Dump non-working:
> [   20.530389] ELD00000000: 09 07 01 00 00 00 00 00 00 00 00 00 00 00 00 00
> [   20.530392] ELD00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [   20.530393] ELD00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [   20.530394] ELD00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [   20.530395] ELD00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [   20.530395] ELD00000050: 00 00 00
> [   20.530396] HDMI: Unknown ELD version 1

This indicates that the ELD data isn't transferred from the graphics side properly.  That is, it's very likely an issue in i915 graphics, not in the audio side.  Reassigning the component...

Created attachment 140991 [details]
Patch to restore valid M/V value to covert BCLK from CDCLK

Could you try if the attached patch can solve this faster playback rate issue on Haswell?

We observed the same problem on Broadwell: if the display power well is turn off during display mode change or for power saving, then audio playback rate will become ~20% faster. The root cause is the HD-A link BCLK is converted from Core Display Clock CDCLK. The default M/N value is for 450Mhz CDCLk to generate 24Mhz BCLK. BIOS can choose 540Mhz CDCLK (~20% than 450Mhz) and progrm M/N value accordingly. But the M/N value registers will fall back to default value after the display power well is turn off. So later the BCLK will be ~20% faster than 24Mhz and result in a faster playback rate. So the patch is to save and restore valid M/N value on controller suspend/resume (i.e. when release/request display power well).

Thanks
Mengdong

Created attachment 141031 [details]
Fix of possible counter missmatch

After a long debugging session I've noticed the following problems with intilizing HDMI-Devices.

1. In the hda_codec.c->snd_hda_get_raw_connections function I get an "invalid CONNECT_LIST verb" error. Maybe this is normal on a HASWELL/BROADWELL because of the PHYSICAL/NON-PHYSICAL node architecture, but maybe someone with knowledge of it can prove it.

2. In the patch_hdmi.c->generic_hdmi_build_pcms function the PCM is only initialized partially. Among others it won't set the NID of the PCM-Stream which causes problems for the hda_codec.c->snd_hda_attach_pcm. Because later this routine is run with "NID=0" and of course that's the point that it can't set the default values in the hda_codec.c->set_pcm_default_values function. This function can simply not select the right PCM-values because of the missing NID.
But "simply" setup the NID in the patch_hdmi.c->generic_hdmi_build_pcms like in the non HDMI hda_generic.c->snd_hda_gen_build_pcms function isn't an opportunity at least for HASWELL/BROADWELL/VALLEYVIEW processors because of the patch_hdmi.c->hdmi_pcm_open workaround for these processors reassignment of these NID's.

I've added a fix of a possible counter missmatch in the patch and get rid of an unneeded pointer to be more hda_generic.c like.

(In reply to Mengdong Lin from comment #39)
> Created attachment 140991 [details]
> Patch to restore valid M/V value to covert BCLK from CDCLK
> 
> Could you try if the attached patch can solve this faster playback rate
> issue on Haswell?

I tried it and doesn't solve the problem, audio continues playing faster.

Hi Daniel,

Could you change the code to program fix M/N value to EM4/EM5 regsiter like this?

static void haswell_restore_bclk(struct azx *chip)
{
	struct hda_intel *hda = container_of(chip, struct hda_intel, chip);

	//azx_writew(chip, EM4, hda->bclk_m);
	//azx_writew(chip, EM5, hda->bclk_n);
	azx_writew(chip, EM4, 0x4);
	azx_writew(chip, EM5, 0x5a);
}

The 0X4/0X5a is for 540MhZ CDLCK.

We found the previos patch is not always reliable:
If only embedded DP is connected on boot, the gfx driver will turn off the display power well on boot case before the audio driver probes and request this power. So the M/V values programmed by BIOS in EM4/5 registers will be lost at the very beginning. And so the audio driver will save invalid M/N values on suspend and restore these invalid values on resume. 
One phenomenon is: if HDMI or DP monitor is connected after boot, audio playback rate is ~20% faster than normal.

Created attachment 141391 [details]
Debug M/N values in azx_runtime_suspend()

(In reply to Mengdong Lin from comment #42)
> Hi Daniel,
> 
> Could you change the code to program fix M/N value to EM4/EM5 regsiter like
> this?
> 
> static void haswell_restore_bclk(struct azx *chip)
> {
>       struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
> 
>       //azx_writew(chip, EM4, hda->bclk_m);
>       //azx_writew(chip, EM5, hda->bclk_n);
>       azx_writew(chip, EM4, 0x4);
>       azx_writew(chip, EM5, 0x5a);
> }
> 
> The 0X4/0X5a is for 540MhZ CDLCK.

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.

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
Sounds pitched up and wrong speed.


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.

I attach the patch use to display M/N values.

> 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.

Please try the draft series I posted at
http://mid.gmane.org/cover.1404222047.git.jani.nikula@intel.com

Please make sure to pick all the *four* patches, and ignore the comments about bdw-only:

http://patchwork.freedesktop.org/patch/28866/
http://patchwork.freedesktop.org/patch/28867/
http://patchwork.freedesktop.org/patch/28868/
http://patchwork.freedesktop.org/patch/28875/

(In reply to Jani Nikula from comment #46)
> Please try the draft series I posted at
> http://mid.gmane.org/cover.1404222047.git.jani.nikula@intel.com

Scratch that.

The fix has been pushed as [1] and [2] through the sound tree [3]. They'll eventually find their way to Linus' tree. Please reopen if the problem persists with these commits.

Thanks for the report.

[1] https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?h=for-next&id=c149dcb5c60bfea8871f16dfcc0690255eeb825f
[2] https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?h=for-next&id=e4d9e513dedb5ac4e166c1053314fa935ddecc8c
[3] https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/log/?h=for-next

*** Bug 70511 has been marked as a duplicate of this bug. ***