Bug 207223 - linux-5.6.x breaks NVidia HDMI audio
Summary: linux-5.6.x breaks NVidia HDMI audio
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-13 14:24 UTC by schopdiedwaas
Modified: 2020-07-01 06:52 UTC (History)
5 users (show)

See Also:
Kernel Version: 5.6
Tree: Mainline
Regression: No


Attachments
alsa-info.sh output (74.92 KB, text/plain)
2020-04-13 14:24 UTC, schopdiedwaas
Details
alsa-info.sh v5.7-rc1 with c31427d reverted (75.76 KB, text/plain)
2020-04-13 19:43 UTC, schopdiedwaas
Details
Patch for fixing kconfig CONFIG_SND_HDA_PREALLOC_SIZE (2.17 KB, patch)
2020-04-13 20:18 UTC, Takashi Iwai
Details | Diff
git bisect log (4.77 KB, text/plain)
2020-04-14 21:02 UTC, schopdiedwaas
Details
alsa-info.sh output in working state (74.89 KB, text/plain)
2020-04-15 08:24 UTC, schopdiedwaas
Details
alsa-info.sh output in broken state (74.89 KB, text/plain)
2020-04-15 08:27 UTC, schopdiedwaas
Details
edid on affected HDMI port (2.92 KB, text/plain)
2020-04-15 10:10 UTC, schopdiedwaas
Details
test debug patch (1.67 KB, patch)
2020-04-15 10:30 UTC, Takashi Iwai
Details | Diff
dmesg output with debug patch (1.33 KB, text/plain)
2020-04-15 11:29 UTC, schopdiedwaas
Details
Output of asla-info.sh (53.05 KB, text/plain)
2020-04-15 12:39 UTC, contact
Details
Test fix for nouveau audio (2.24 KB, patch)
2020-04-15 13:01 UTC, Takashi Iwai
Details | Diff
alsa-info.sh output after patch (76.16 KB, text/plain)
2020-04-15 13:22 UTC, schopdiedwaas
Details
Proper fix patch for nouveau audio (3.36 KB, patch)
2020-04-15 14:07 UTC, Takashi Iwai
Details | Diff
Patch to add a module option to disable audio component binding (1.64 KB, patch)
2020-04-15 15:33 UTC, Takashi Iwai
Details | Diff

Description schopdiedwaas 2020-04-13 14:24:19 UTC
Created attachment 288415 [details]
alsa-info.sh output

When upgrading from 5.5.13 to 5.6, NVidia HDMI audio stops working.
The card is still there with all controls in alsamixer, but there is no sound output. Downgrading to 5.5.13 solves the issue.

The problem was initially observed on linux-5.6.2-arch1-1 from the Arch Linux repositories. I compiled 5.7.0-rc1 for testing purposes, which shows the same behavior as 5.6. Speaker-test reports the following:


$ speaker-test -c 6 -D hdmi:CARD=NVidia,DEV=1

speaker-test 1.2.2

Playback device is hdmi:CARD=NVidia,DEV=1
Stream parameters are 48000Hz, S16_LE, 6 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 64 to 8544000
Period size range from 32 to 4272000
Using max buffer size 8544000
Periods = 4
Unable to set hw params for playback: Cannot allocate memory
Setting of hwparams failed: Cannot allocate memory
Comment 1 Takashi Iwai 2020-04-13 16:21:21 UTC
It's the first report, and currently I have no clue what went south.
Could you try bisecting?
Comment 2 Takashi Iwai 2020-04-13 16:23:58 UTC
BTW, the max buffer size shown in speaker-test looks very large.  Is it same for both working and non-working cases?
Comment 3 schopdiedwaas 2020-04-13 16:33:23 UTC
I will have a go at bisecting tonight.
There seems to be at least one other user affected at https://bbs.archlinux.org/viewtopic.php?id=254507

Speaker-test on the working kernel (5.5.13-arch2-1) shows smaller buffer sizes indeed:

$ speaker-test -c 6 -D hdmi:CARD=NVidia,DEV=1

speaker-test 1.2.2

Playback device is hdmi:CARD=NVidia,DEV=1
Stream parameters are 48000Hz, S16_LE, 6 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 64 to 349504
Period size range from 32 to 174752
Using max buffer size 349504
Periods = 4
was set period_size = 174752
was set buffer_size = 349504
 0 - Front Left
 4 - Front Center
 1 - Front Right
 3 - Rear Right
 2 - Rear Left
 5 - LFE
Time per period = 23.013076
Comment 4 Takashi Iwai 2020-04-13 18:49:11 UTC
OK, if the memory size differs: do you happen to set 0 to CONFIG_SND_HDA_PREALLOC_SIZE?  That would explain.  It'll allow the memory allocation up to 32MB, and the application tries to allocate the max size and fails.

Please try to set 1024 or 2048 (corresponds to 1MB / 2MB) and see whether it makes working.
Comment 5 Takashi Iwai 2020-04-13 18:52:04 UTC
Ah, wait...  This can't be set explicitly any longer, and that's the cause of the regression.

Please try reverting c31427d0d21e198c74d5d92082c4b8194b257f82, and set the old CONFIG_SND_HDA_PREALLOC_SIZE used for 5.5 kernel.

I guess we need to revert the commit, but increase the default size instead.
Comment 6 schopdiedwaas 2020-04-13 19:43:07 UTC
Created attachment 288427 [details]
alsa-info.sh v5.7-rc1 with c31427d reverted
Comment 7 schopdiedwaas 2020-04-13 19:47:55 UTC
Ok, reverting that commit on v5.7-rc1 and setting CONFIG_SND_HDA_PREALLOC_SIZE=4096 (value from working 5.5.13 config) fixed the memory allocation issue, but unfortunately still no sound... Speaker-test now reports the following:


$ speaker-test -c 6 -D hdmi:CARD=NVidia,DEV=1

speaker-test 1.2.2

Playback device is hdmi:CARD=NVidia,DEV=1
Stream parameters are 48000Hz, S16_LE, 6 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 64 to 349504
Period size range from 32 to 174752
Using max buffer size 349504
Periods = 4
was set period_size = 174752
was set buffer_size = 349504
 0 - Unknown
 1 - Unknown
 2 - Unknown
 3 - Unknown
 4 - Unknown
 5 - Unknown
Time per period = 21.996715


I will do some more testing/reverting on earlier versions soon.
Comment 8 Takashi Iwai 2020-04-13 20:17:15 UTC
Hm, then there must be another reason.  But at least we should revert and change the default again.  The patch I'm going to submit is below.
Comment 9 Takashi Iwai 2020-04-13 20:18:13 UTC
Created attachment 288429 [details]
Patch for fixing kconfig CONFIG_SND_HDA_PREALLOC_SIZE
Comment 10 schopdiedwaas 2020-04-14 21:02:47 UTC
Created attachment 288455 [details]
git bisect log

Git bisect points to 742db30c4ee6cd28142e83e154b5271f95a2c67a as the culprit. The log is slightly longer than strictly necessary, I mixed up one good/bad somewhere in the process and had to replay.

All bisect builds were tested with c31427d0d21e198c74d5d92082c4b8194b257f82 reverted where necessary and CONFIG_SND_HDA_PREALLOC_SIZE=4096. On "good" builds, speaker-test reported no errors and gave correct channel names. On "bad" builds, the channel names were all "Unknown" and did not produce any sound, though no error was reported in this case either.
Comment 11 schopdiedwaas 2020-04-14 22:06:27 UTC
One more test result: building v5.7-rc1 with c31427d0d21e198c74d5d92082c4b8194b257f82 and 742db30c4ee6cd28142e83e154b5271f95a2c67a reverted works without any of the mentioned issues. It gives me sound again and the channel names in speaker-test are correct.
Comment 12 Takashi Iwai 2020-04-15 06:41:46 UTC
Thanks for bisection.  Just to be sure, which driver are you testing, nouveau or Nvidia binary-only?

Please give alsa-info.sh outputs on both working and non-working cases.
Comment 13 schopdiedwaas 2020-04-15 08:24:43 UTC
Created attachment 288467 [details]
alsa-info.sh output in working state

Attached here is the output from alsa-info.sh on v5.7-rc1 with both c31427d0d21e198c74d5d92082c4b8194b257f82 and 742db30c4ee6cd28142e83e154b5271f95a2c67a reverted. This produces a kernel with working sound as expected.

I am using nouveau (never installed the nvidia driver) and according to https://bbs.archlinux.org/viewtopic.php?id=254507 the nvidia driver is not affected.

Below is the output from alsa-info.sh on v5.7-rc1 with only c31427d0d21e198c74d5d92082c4b8194b257f82 reverted to address the memory allocation issue. In this scenario, there is no sound output and all channel names in speaker-test are "Unknown" as seen earlier in this thread.
Comment 14 schopdiedwaas 2020-04-15 08:27:00 UTC
Created attachment 288469 [details]
alsa-info.sh output in broken state
Comment 15 Takashi Iwai 2020-04-15 09:55:07 UTC
Comparing those two outputs shows that "HDMI/DP,pcm=X Jack" on Nvidia exactly inverted value: pcm=7 showed true and and others false in the working case, while pcm=7 showed false and others true in the broken case.

If my understanding is correct, this value is directly delivered from nv50_audio_component_get_eld(), and it invokes drm_detect_monitor_audio() for each inquired port and stores the returned value.

That is, the possible culprit is: either
- Something wrong in nv_connector->edid values,
- drm_detect_monitor_audio() is broken for your device, or
- we're looking at a wrong information

It's still puzzling why all values are inverted.  Hmm.
Could you check the EDID values from sysfs?
Comment 16 schopdiedwaas 2020-04-15 10:10:23 UTC
Created attachment 288477 [details]
edid on affected HDMI port

See attachment, dump was taken in broken state (v5.7-rc1 with only the memory allocation fix).
Comment 17 Takashi Iwai 2020-04-15 10:29:44 UTC
Let's check whether the code executed in nouveau returning the expected value.
Please try the debug patch below and see what values are shown.
Comment 18 Takashi Iwai 2020-04-15 10:30:17 UTC
Created attachment 288479 [details]
test debug patch
Comment 19 Jaroslav Kysela 2020-04-15 10:45:15 UTC
Takashi, I can see this too with a test equipment for a nouveau driver:

- MST is activated in the audio driver, but it seems that it does not match the video driver state (4 MST audio devices have "joined" state because audio component does not send the proper MST device id - value -1 is used!)
- dynamic PCM assignments are enabled with the nvidia patch code (not a real problem, makes debugging a bit harder)
- physical video port mapping to HDA NID mapping fails for my test platform (it seems that wrong value is used on the video driver side (shift by 6 not 4 port2pin mapping)
Comment 20 Takashi Iwai 2020-04-15 10:57:58 UTC
Good that you have equipment for testing / debugging!  I'm locked without those (my Nvidia machine is in the office), so couldn't test anything for now.

MST might be indeed a problem that was added recently.  My original patch has been tested without MST in the past, admittedly.
Comment 21 schopdiedwaas 2020-04-15 11:29:50 UTC
Created attachment 288481 [details]
dmesg output with debug patch

Dmesg output from the debug patch is attached. I had to edit the third hunk slightly, as nv_connector is not declared in nv50_audio_disable. I used the line below instead, but it looks like it's not being called anyway:

+   pr_info("XXX audio disable: index=%d, encoder=%p, crtc=%p\n",
+       nv_crtc->index, encoder, nv_crtc);
Comment 22 Takashi Iwai 2020-04-15 12:17:32 UTC
Thanks.  Could you give alsa-info.sh output again after this plugged state?

I'm afraid that the mapping between the crtc index and the HDA pin on yours isn't straightforward like my tested device.  That can be tough.
Comment 23 contact 2020-04-15 12:34:08 UTC
Same problem here for both sound devices, on-board analog and HDMI (AMDGPU driver) on kernel 5.6.3 artix/arch.


`$ speaker-test -D <device> -c 2`


with `<device>` being:
- `hw:0,3` (HDMI)
- `hw:1,0` (on-board sound-card)
- `default` (mapped to `hw:0,3` by config)


all fail saying:

```
Stream parameters are 48000Hz, S16_LE, 2 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 64 to 8544000
Period size range from 32 to 4272000
Using max buffer size 8544000
Periods = 4
Unable to set hw params for playback: Cannot allocate memory
Setting of hwparams failed: Cannot allocate memory
```

All do work though when buffer size is limited with "--buffer 2000"
Comment 24 schopdiedwaas 2020-04-15 12:35:29 UTC
Takashi, what do you mean exactly by "plugged state"?
Comment 25 contact 2020-04-15 12:39:23 UTC
Created attachment 288487 [details]
Output of asla-info.sh
Comment 26 Takashi Iwai 2020-04-15 13:00:24 UTC
(In reply to schopdiedwaas from comment #24)
> Takashi, what do you mean exactly by "plugged state"?
I meant the moment you got alsa-info.sh output, i.e. the status with the monitor connection.

But never mind, I think I see now the culprit.
Could you try the patch below?
Comment 27 Takashi Iwai 2020-04-15 13:01:00 UTC
Created attachment 288489 [details]
Test fix for nouveau audio
Comment 28 Takashi Iwai 2020-04-15 13:03:59 UTC
... and if the patch doesn't work, please check what values nv_encoder->or and nv_crtc->index have.
Comment 29 Takashi Iwai 2020-04-15 13:13:54 UTC
(In reply to contact from comment #23)
> Same problem here for both sound devices, on-board analog and HDMI (AMDGPU
> driver) on kernel 5.6.3 artix/arch.
> 
> `$ speaker-test -D <device> -c 2`
(snip)
> Setting of hwparams failed: Cannot allocate memory

This should be fixed by the patch in comment 9 and setting CONFIG_SND_HDA_PREALLOC_SIZE to 2048 or whatever reasonable value.
Comment 30 schopdiedwaas 2020-04-15 13:22:11 UTC
Created attachment 288495 [details]
alsa-info.sh output after patch

The patch from comment 27 seems to fix the issue. Sound is working and speaker-test reports normal channel names. Output from alsa-info.sh after the fix is attached.


$ speaker-test -c 6 -D hdmi:CARD=NVidia,DEV=1

speaker-test 1.2.2

Playback device is hdmi:CARD=NVidia,DEV=1
Stream parameters are 48000Hz, S16_LE, 6 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 64 to 349504
Period size range from 32 to 174752
Using max buffer size 349504
Periods = 4
was set period_size = 174752
was set buffer_size = 349504
 0 - Front Left
 4 - Front Center
 1 - Front Right
 3 - Rear Right
 2 - Rear Left
 5 - LFE
Time per period = 22.008309
Comment 31 Jaroslav Kysela 2020-04-15 13:34:01 UTC
Thank you for the MST port / device id fix. But the patch does not resolve issue for my platform. Notifications with debug prints:

[   24.426589] XXX: Notify port = 0 dev_id = 0
[   24.426599] snd_hda_codec_hdmi hdaudioC1D0: HDMI: pin nid 4 not registered
[   25.884095] XXX: Notify port = 0 dev_id = 0
[   25.884099] snd_hda_codec_hdmi hdaudioC1D0: HDMI: pin nid 4 not registered
[   27.500536] rfkill: input handler disabled

The correct NIDs are 6 and 7 (confirmed with the proprietary driver). We need to find a way to dermine this physical output connection in the nouveau driver.
Comment 32 Takashi Iwai 2020-04-15 13:45:33 UTC
Is NID 0x04 a valid pin widget?  Or does your HDMI codec have different widget layout?  Please give alsa-info.sh output.
Comment 33 Takashi Iwai 2020-04-15 14:07:14 UTC
Created attachment 288497 [details]
Proper fix patch for nouveau audio

The same patch as the previous one but with a proper changelog.
Comment 34 Jaroslav Kysela 2020-04-15 14:14:10 UTC
Hmm, this laptop has HDMI and miniDP ports, both are reported as port 0 / dev_id 0 to the audio driver (see above; added encoder->link print):

XXX: get or/port = 0 index/dev_id = 0 (link = 1)

Something is missing in the video driver...

The output are identified as [CONNECTOR:127:DP-3] - HDMI connector and [CONNECTOR:91:DP-4] - miniDP connector.

If you have a hint, where to read the correct values, I can give a try.

Codec NIDs:

Node 0x04 [Pin Complex] wcaps 0x407381: 8-Channels Digital CP
  Pincap 0x09000094: OUT Detect HBR HDMI DP
  Pin Default 0x585600f0: [N/A] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0xf, Sequence = 0x0
  Pin-ctls: 0x00:
  Unsolicited: tag=00, enabled=0
  Devices: 4
    *Dev 00: PD = 1, ELDV = 1, IA = 0
     Dev 01: PD = 0, ELDV = 0, IA = 0
     Dev 02: PD = 0, ELDV = 0, IA = 0
     Dev 03: PD = 0, ELDV = 0, IA = 0
  Connection: 4
     0x08* 0x09 0x0a 0x0b
Node 0x05 [Pin Complex] wcaps 0x407381: 8-Channels Digital CP
  Pincap 0x09000094: OUT Detect HBR HDMI DP
  Pin Default 0x585600f0: [N/A] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0xf, Sequence = 0x0
  Pin-ctls: 0x00:
  Unsolicited: tag=00, enabled=0
  Devices: 4
    *Dev 00: PD = 0, ELDV = 0, IA = 0
     Dev 01: PD = 0, ELDV = 0, IA = 0
     Dev 02: PD = 0, ELDV = 0, IA = 0
     Dev 03: PD = 0, ELDV = 0, IA = 0
  Connection: 4
     0x08* 0x09 0x0a 0x0b
Node 0x06 [Pin Complex] wcaps 0x407381: 8-Channels Digital CP
  Pincap 0x09000094: OUT Detect HBR HDMI DP
  Pin Default 0x185600f0: [Jack] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0xf, Sequence = 0x0
  Pin-ctls: 0x00:
  Unsolicited: tag=00, enabled=0
  Devices: 4
     Dev 00: PD = 0, ELDV = 0, IA = 0
     Dev 01: PD = 0, ELDV = 0, IA = 0
     Dev 02: PD = 0, ELDV = 0, IA = 0
    *Dev 03: PD = 0, ELDV = 0, IA = 0
  Connection: 4
     0x08* 0x09 0x0a 0x0b
Node 0x07 [Pin Complex] wcaps 0x407381: 8-Channels Digital CP
  Pincap 0x09000094: OUT Detect HBR HDMI DP
  Pin Default 0x185600f0: [Jack] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0xf, Sequence = 0x0
  Pin-ctls: 0x00:
  Unsolicited: tag=00, enabled=0
  Devices: 4
     Dev 00: PD = 0, ELDV = 0, IA = 0
     Dev 01: PD = 0, ELDV = 0, IA = 0
     Dev 02: PD = 0, ELDV = 0, IA = 0
    *Dev 03: PD = 0, ELDV = 0, IA = 0
  Connection: 4
     0x08* 0x09 0x0a 0x0b
Comment 35 Takashi Iwai 2020-04-15 14:28:34 UTC
Judging from the output, I guess the audio has never worked on yours with nouveau.  The PD=1 indicates that nouveau enabled already the wrong one.

Disabling the audio component in HD-audio side is easy, just comment out the call of generic_acomp_init() in patch_nvhdmi().  Could you confirm that it's broken no matter whether the audio component is used or not?
Comment 36 Takashi Iwai 2020-04-15 14:53:37 UTC
Also, it might be interesting not to skip the port NONE.

--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1695,9 +1695,11 @@ static int hdmi_add_pin(struct hda_codec *codec, hda_nid_t pin_nid)
 	 * For DP MST audio, Configuration Default is the same for
 	 * all device entries on the same pin
 	 */
+#if 0
 	config = snd_hda_codec_get_pincfg(codec, pin_nid);
 	if (get_defcfg_connect(config) == AC_JACK_PORT_NONE)
 		return 0;
+#endif
 
 	/*
 	 * To simplify the implementation, malloc all
Comment 37 Takashi Iwai 2020-04-15 15:33:05 UTC
(In reply to Takashi Iwai from comment #35)
> Disabling the audio component in HD-audio side is easy, just comment out the
> call of generic_acomp_init() in patch_nvhdmi().
The patch below adds the module option to control it, too, for convenience.
Comment 38 Takashi Iwai 2020-04-15 15:33:55 UTC
Created attachment 288501 [details]
Patch to add a module option to disable audio component binding
Comment 39 Jaroslav Kysela 2020-04-15 15:45:00 UTC
Ok, after some more debugging, I feel that the audio component part is incomplete. My hw has those connectors:

[    5.383622] XXX: crtcs = 0xf
[    5.383819] XXX: dcbe->location = 0, type = 6, heads = 15, hashm = 0xf82, hasht = 0x6
[    5.383994] XXX: dcbe->location = 0, type = 6, heads = 15, hashm = 0xf44, hasht = 0x6
[    5.404307] XXX: dcbe->location = 0, type = 2, heads = 15, hashm = 0xf44, hasht = 0x2
[    5.404335] XXX: dcbe->location = 0, type = 2, heads = 15, hashm = 0xf42, hasht = 0x2
[    5.404566] XXX: dcbe->location = 0, type = 6, heads = 15, hashm = 0xf41, hasht = 0x6
[    5.425802] XXX: dcbe->location = 0, type = 2, heads = 15, hashm = 0xf41, hasht = 0x2
[    5.426078] XXX: dcbe->location = 0, type = 6, heads = 15, hashm = 0xf81, hasht = 0x6
[    5.448789] XXX: dcbe->location = 0, type = 2, heads = 15, hashm = 0xf41, hasht = 0x2

Type 6 means the DP output.

As you see, the only difference between the output physical connectors are hashes (thus index / or fields are zero):

[   25.440828] XXX: hdmi_enable: hasht = 0x2, hashm = 0xf42, index = 0
[   25.440860] XXX: audio_enable: hasht = 0x2, hashm = 0xf42, index = 0
[   25.440861] XXX: Notify port = 0 dev_id = 0

[   26.391381] XXX: hdmi_enable: hasht = 0x2, hashm = 0xf44, index = 0
[   26.391414] XXX: audio_enable: hasht = 0x2, hashm = 0xf44, index = 0
[   26.391415] XXX: Notify port = 0 dev_id = 0

I will print more struct dcb_output fields, perhaps, the hints are there.
Comment 40 Jaroslav Kysela 2020-04-15 15:52:32 UTC
[    5.456880] XXX: crtcs = 0xf
[    5.457169] XXX: dcbe->location = 0, type = 6, heads = 15
[    5.457170] XXX:   hashm = 0xf82, hasht = 0x6
[    5.457171] XXX:   connector = 0x3, bus = 0x0, location = 0x0
[    5.457172] XXX:   or = 2, link = 0
[    5.457410] XXX: dcbe->location = 0, type = 6, heads = 15
[    5.457412] XXX:   hashm = 0xf44, hasht = 0x6
[    5.457413] XXX:   connector = 0x4, bus = 0x2, location = 0x0
[    5.457414] XXX:   or = 4, link = 0
[    5.478858] XXX: dcbe->location = 0, type = 2, heads = 15
[    5.478859] XXX:   hashm = 0xf44, hasht = 0x2
[    5.478861] XXX:   connector = 0x4, bus = 0x2, location = 0x0
[    5.478862] XXX:   or = 4, link = 0
[    5.478874] XXX: dcbe->location = 0, type = 2, heads = 15
[    5.478875] XXX:   hashm = 0xf42, hasht = 0x2
[    5.478876] XXX:   connector = 0x2, bus = 0x1, location = 0x0
[    5.478877] XXX:   or = 2, link = 0
[    5.479023] XXX: dcbe->location = 0, type = 6, heads = 15
[    5.479025] XXX:   hashm = 0xf41, hasht = 0x6
[    5.479026] XXX:   connector = 0x0, bus = 0x3, location = 0x0
[    5.479028] XXX:   or = 1, link = 0
[    5.498373] XXX: dcbe->location = 0, type = 2, heads = 15
[    5.498375] XXX:   hashm = 0xf41, hasht = 0x2
[    5.498376] XXX:   connector = 0x0, bus = 0x3, location = 0x0
[    5.498377] XXX:   or = 1, link = 0
[    5.498501] XXX: dcbe->location = 0, type = 6, heads = 15
[    5.498502] XXX:   hashm = 0xf81, hasht = 0x6
[    5.498503] XXX:   connector = 0x1, bus = 0x4, location = 0x0
[    5.498505] XXX:   or = 1, link = 0
[    5.517871] XXX: dcbe->location = 0, type = 2, heads = 15
[    5.517872] XXX:   hashm = 0xf41, hasht = 0x2
[    5.517873] XXX:   connector = 0x1, bus = 0x4, location = 0x0
[    5.517875] XXX:   or = 1, link = 0
Comment 41 Takashi Iwai 2020-04-15 16:23:57 UTC
Does the audio work with nouveau driver on your device at all?  If yes, we can have a chance to fix for the audio component, too.
As far as I see the nouveau driver sets the audio register bits in either gf119_hda_hpd() and gt215_hda_hpd().  And it receives the encoded hidx in the passed hashm, which is equal with nv_crtc->index.  So I see no difference in the HPD/ELD handling without the audio component...
Comment 42 Jaroslav Kysela 2020-04-15 19:30:50 UTC
> Does the audio work with nouveau driver on your device at all?

I was not able to get audio with the nouveau. So no regression. It works with the propriatery driver which uses HDA PIN NIDs 0x06 and 0x07.

The workaround from comment#36 (skip pincfg from BIOS) makes the ELD detection / HDMI device working but no sound. It seems that a route / initialization is missing in nouveau for the TU117 chip.
Comment 43 Takashi Iwai 2020-04-16 07:42:13 UTC
OK, then I'm going to submit my last fix to DRM guys.  The fix for CONFIG_SND_HDA_PREALLOC_SIZE was already merged to sound git tree, the PR to Linus is planned for tomorrow to be merged in 5.7-rc2.

Jaroslav, could you open the report on freedesktop gitlab issues for the remaining problem of your device?  It's a nouveau problem and should be handled there.
Comment 44 Jaroslav Kysela 2020-04-16 10:23:59 UTC
It seems that it's almost impossible to fill a nouveau bug. Freedesktop bugzilla is closed and gitlab does not have the nouveau driver project. I'll try to contact Ben directly.

Just for the record purposes: The patch bellow will skip SOR 0 and 1 (which makes ELD pass / monitor detection working without the workaround in the audio driver, but it does not fix audio):

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgv100.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgv100.c
index b0597ff9a714..a022f9ed15f4 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgv100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgv100.c
@@ -117,5 +117,6 @@ gv100_sor_cnt(struct nvkm_disp *disp, unsigned long *pmask)
 {
        struct nvkm_device *device = disp->engine.subdev.device;
        *pmask = (nvkm_rd32(device, 0x610060) & 0x0000ff00) >> 8;
+       *pmask = 0x0c;
        return (nvkm_rd32(device, 0x610074) & 0x00000f00) >> 8;
 }
Comment 45 alex 2020-05-09 20:12:56 UTC
Hello, I am just a user, but I send you messages from my system in case I gave you a clue of what is happening. Excuse my poor English

All kernels before kernel 5.6 the Mate Desktop sound preferences show that my only profile is "Digital Stereo (HDMI 2) Output"

But with kernel 5.6 the Mate Desktop sound preferences show just the opposite, all profiles but not HDMI 2: "Digital Stereo (HDMI) Output", "Digital Stereo (HDMI 3) Output", "Digital Stereo (HDMI 4) Output", "Digital Stereo (HDMI 5) Output"

Is it problem with a boolean?

$ lspci

01:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1)

Thanks
Comment 46 Takashi Iwai 2020-05-29 15:38:50 UTC
The regression itself has been addressed, so let's close the bug here.
Comment 47 alex 2020-05-30 06:49:58 UTC
I moved in Debian testing from kernel 5.6.7 to kernel 5.6.14 and the problem persists
Comment 48 schopdiedwaas 2020-06-03 09:49:07 UTC
(In reply to alex from comment #47)
> I moved in Debian testing from kernel 5.6.7 to kernel 5.6.14 and the problem
> persists

Please be patient. The fix is applied in the nouveau repo and now has to make its way into the main kernel repo. As of linux 5.7 this did not happen yet, so don't expect a fix before  5.7.x or even 5.8.
Comment 49 devsk 2020-06-04 16:59:06 UTC
Why has this not landed in 5.6.x series yet? I think this is a serious bug.
Comment 50 schopdiedwaas 2020-06-27 12:31:51 UTC
The last fix is present in 5.7.6. Normal sound is working again, but I still have to provide a buffer size to speaker-test.
Looks like the CONFIG_SND_HDA_PREALLOC_SIZE patch from #9 has not made it into the 5.7.x branch yet.
Comment 51 alex 2020-07-01 06:52:09 UTC
Working fine in Debian Testing with kernel 5.7.6 . Fixed

Note You need to log in before you can comment on or make changes to this bug.