kernel 4.9 works. But from 4.10-rc1 failed upstream 4.13 failed. Including KBL-S/U/H/Y HDA audio works Legacy audio works DP audio failed. you can get the Ubuntu 17.10 release. It has the 4.13 kernel. http://cdimage.ubuntu.com/ubuntu/daily-live/current/ It is easy to reproduce. Reproduce Steps: 1)connector DP monitor with KBL 2) and run the command speaker-test -t wav -c 2 -Dplughw:0,8 for HDA with plughw:0.7 (works) for legacy with plughw:0.0 (works) === Machine Information including BIOS == Platform info: OS: Ubuntu 17.04 Kernel: 4.10.0-9-generic KBL-S Processor: Kabylake DT Intel(R) Core(TM) i5-7600 CPU @ 3.50GHz, B0/S0/M0 Stepping, GT2(0x5912) Bios: KBLSE2R1.R00.X063.P00.1610281021 KBL-H Processor: Kabylake Halo, i5-7300HQ 2.5GHz, B0/S0/M0 Stepping, GT2(0x591B) Bios: KBLSE2R1.R00.X063.P00.1610281021 KBL-U Processor: KabyLake ULT, i7-7600U, 2.80GHz, H0/J0 Stepping, GT2 Bios: KBLSE2R1.R00.X063.P00.1610281021 Details: 1. The host connect the DP port to display, and connect the headset to the DP displayer. 2. Use the command "alsamixer " to adjust the audio to the best. 3. Use the command "aplay -l" to get the List of PLAYBACK Hardware Devices. 4. Use the command "speaker-test -c2 -t wav -Dhw:0,*" to check the audio, bus the headset cannot hear any sound. 5. Use "cat /proc/asound/card0/eld#2.*" to get the displayer info, but cannot get any info. Currently seems APL-I not works too.
Here is the regression commit. commit 6014ac122ed081feca99217bc57b2e15c7fc1a51 Author: Libin Yang <libin.yang@linux.intel.com> Date: Tue Oct 25 17:54:18 2016 +0300 drm/i915/audio: set proper N/M in modeset When modeset occurs and the LS_CLK is set to some special values in DP mode, the N/M need to be set manually if audio is playing. Otherwise the first several seconds may be silent in audio playback. The relationship of Maud and Naud is expressed in the following equation: Maud/Naud = 512 * fs / f_LS_Clk Please refer VESA DisplayPort Standard spec for details. v2 by Jani: - organize Maud/Naud table according to DP 1.4 spec - add 64k and 128k audio rates - update HSW_AUD_M_CTS_ENABLE register when Maud not found - remove extra checks for port clock - simplify Maud/Naud lookup - reset patch author back to Libin Cc: "Zhang, Keqiao" <keqiao.zhang@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: "Lin, Mengdong" <mengdong.lin@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Libin Yang <libin.yang@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477407258-30599-3-git-send-email-jani.nikula@intel.com
Hello Qwang, could you please try with top of this branch https://cgit.freedesktop.org/drm-tip? Also, it is possible to get some logs with debug information, dmesg with drm.debug=0xe parameter on grub would be helpful. Thanks for your time.
Created attachment 136048 [details] autodetect
attachment 136048 [details] (In reply to Elizabeth from comment #2) > Hello Qwang, could you please try with top of this branch > https://cgit.freedesktop.org/drm-tip? Also, it is possible to get some logs > with debug information, dmesg with drm.debug=0xe parameter on grub would be > helpful. > Thanks for your time. Please check the attached log attachment 136048 [details]. Thanks.
Rising priority since is a regression.
Document mail discussion: "Below patch which was identified to have caused the regression also exist in the kernel tree mentioned above. commit 6014ac122ed081feca99217bc57b2e15c7fc1a51 Author: Libin Yang <libin.yang@linux.intel.com> Date: Tue Oct 25 17:54:18 2016 +0300
Updated patch http://patchwork.freedesktop.org/patch/msgid/20180206114918.29389-1-jani.nikula@intel.com Please test.
Libin, can you remind us why it was required to use manual Maud/Naud in commit 6014ac122ed0 ("drm/i915/audio: set proper N/M in modeset")? My recollection is that it was related to higher link clock that the automatic mode didn't support on some platforms, but I can't be sure anymore. Quanxian, does the patch in comment #7 work around the issue on KBL? Does it re-introduce the problem fixed by the regressing commit? The usual upstream policy is to revert regressing commits, even if doing so breaks something else, and go back to the drawing board with the original patch that introduced the regression. The aim is to ensure non-regressing forward progress.
hi, Jani We are doing full validation of KBL-X(R|U|H...), SKY(Y|U|H), APL, GLK for DP audio issue. Based on our experience and our original patch, there is no side effect on other platforms. It should solve KBL DP audio issue. But we need validation on your updated patch. However, if yuor patch works, the patch only solved the problem of KBL. For others platform, the problem still exists. Do you need to work with Intel Audio/Graphics team to root cause this to solve all the problems not only on KBL? Keep tune our full test results as we discussed yesterday. We are working on that.
We need more time and resources to do testing. The result will be delayed to send.
Our test result: Case-1: Settings->sound->select ‘Speaker build-in audio’ Test result: DP audio doesn’t work on all the platforms attached all the monitors with different resolutions. Case-2: Settings->sound->select “HDMI/DisplayPort Build-in Audio” Test result: DP audio do work on all the platforms attached all the monitors with different resolutions. Jani's patch Jani’s patch and Quanxian’s original patch all don’t work with the case-1 setting. 1-ASUS Model: PA238 Manufacture: ASUS 2-Philips Model: BDM4350 Manufacture: PHILIPS 3-HP: Model: ZR2440w Manufacture: HP Test Result information ============= System information: Platform : KBL System: 17.10 Kernel: 4.13 (official, no any update) test@test-Kabylake-Client-platform:~$ cat /proc/asound/card0/eld#2.0 monitor_present 1 eld_valid 1 monitor_name HP ZR2440w connection_type DisplayPort *** this is DP audio port *** eld_version [0x2] CEA-861D or below edid_version [0x3] CEA-861-B, C or D manufacture_id 0xf022 product_id 0x2954 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 Command: speaker-test -t wav -c 2 -Dplughw:0,3 Output: speaker-test 1.1.3 Playback device is plughw:0,3 Stream parameters are 48000Hz, S16_LE, 2 channels WAV file(s) Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 16384 Period size range from 32 to 8192 Using max buffer size 16384 Periods = 4 was set period_size = 4096 was set buffer_size = 16384 0 - Front Left 1 - Front Right Time per period = 2.732593 0 - Front Left 1 - Front Right Time per period = 2.986920 0 - Front Left 1 - Front Right Time per period = 2.986144 0 - Front Left 1 - Front Right Time per period = 3.071854 0 - Front Left 1 - Front Right ….
Additional information: HDMI audio works. It is not related to “Sound UI setting”. Whatever Case 1 or Case 2, command works for HDMI audio. But for DP audio, it is related to “Sound UI setting”. HDMI and DP interface are located on the same monitor.
Testing on resolution List for every monitor: "Monitor-1 Model: PA238 Manufacture: ASUS Resolution: 1: 1920x1080(16:9) 2: 1024x768 (4:3) 3: 1280x1024 (5:4) 4: 1440x900 (16:10) 5: 640x480(4:3) " "Monitor-2 Model: ZR2440w Manufacture: HP Resolution: 1: 1920x1200(16:10) 2: 1920x1080(16:9) 3: 1024x768 (4:3) 4: 1280x1024(5:4) 5: 640x480(4:3)" "Monitor-3 Model: BDM4350 Manufacture: PHILIPS Resolution: 1: 3840x2160 (16:9) 2: 1024x768 (4:3) 3: 1920x1080 (16:9) 4: 1440x900 (16:10) 5: 640x480 (4:3) "
Sorry for delay reply. I was having vacation last few days. We need the manual setting of M/N because the HW setting of M/N will cause DP doesn't work properly on some old platforms. We decided to manually set the M/N, so that we can make sure the M/N value is following the DP spec. We tested a lot on the old platforms, it works well. But it seems the new platform behavior is changed. I think we may need add some judgement that on the new platform we should use the HW settings.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Hi Keqiao, Do we have KBL now? If yes, could you please help have a test? I remember someone has already submit some patch which may fix this issue.
Libin, where you able to make any progress?
I checked with our QA, we don't have KBL platforms as our team is not the owner of KBL audio. I will try to find a platform.
Hi Libin, Were you able to find a new platform? Does anyone else have access to KBL?
Hi Simon, We don't have such platforms. We didn't order the KBL platforms as it is in not our scope. Sorry for that. Does this bug still exist in the latest kernel? It's strange that there is no Intel formal team to work on KBL HD Audio. Regards, Libin
Qwang, Are you able to reproduce this issue with latest kernel and drmtip?
it is a monitor issue. Currently we don't find it. Just close it. Thank you!
Closing this as not our bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.