You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG][tgl] Jack detection is off in amixer contents after reboot with HDMI connected #1792
Describe the bug
Jack detection is off in amixer contents after reboot with HDMI/DP connected,and no sound output,but monitor display is normally
Unplug/plug HDMI/DP again can recovery
To Reproduce
1.sudo reboot with HDMI/DP connected
2.amixer contents to check jack detection
Reproduction Rate
10/10
Expected behavior
HDMI/DP jack detection is on in amixer contents
Actual result
HDMI/DP jack detection is off in amixer contents
changed the title [-][BUG][tgl] Jack detection is off in amixer contents after reboot with HDMI/DP connected[/-][+][BUG][tgl] Jack detection is off in amixer contents after reboot with HDMI connected[/+]on Feb 27, 2020
@Liviali155 The DRM log is so verbose that it fills the dmesg buffer very quickly and e.g. this log is missing lot of events from the early boot. You can overcome by increasing the dmesg size. "log_buf_len=1M" should be sufficient. You can add this e.g. with following to to /etc/default/grub:
@Liviali155 The DRM log is so verbose that it fills the dmesg buffer very quickly and e.g. this log is missing lot of events from the early boot. You can overcome by increasing the dmesg size. "log_buf_len=1M" should be sufficient. You can add this e.g. with following to to /etc/default/grub:
After further usage, however, it seems this introduces a strange issue where even small amounts of GPU load cause the mouse cursor to move jerkily and "drop frames". It seems weird, but reverting the patch causes it to work normally again.
That patch is different from the one you linked earlier. When I tried the one from the list (it took a bit of massaging to get it to apply to 5.6-rc6), the audio works on boot and the cursor behaves normally.
That patch is different from the one you linked earlier. When I tried the one from the list
(it took a bit of massaging to get it to apply to 5.6-rc6), the audio works on boot and
Yes, true, they modified the implementation in the first version sent out on the list. Thanks a lot for the report. There are now additional validation rounds done on the patch sent to the list and if all goes well, the patch will get merged. Thanks a lot for testing!
@Liviali155 I'll check the log separately, this might something else.
Excellent news, thanks a lot for the quick testing. The patch is merged upstream and I'll now proceed to merge this in sof-dev as well, so we get the fixing immediately to the audio tree.
Activity
Liviali155 commentedon Feb 14, 2020
Bi-sect result:
caused by kernel commit #8c0050f
kv2019i commentedon Feb 14, 2020
@Liviali155 wrote:
Thanks, this a good lead. I will take a look at this next week.
sinahuang commentedon Feb 26, 2020
Issue also can be reproduced on TGL-U RVP with codec ALC711 in SDW mode and RT1308 in I2S mode if reboot with HDMI connected.
Liviali155 commentedon Feb 27, 2020
On latest sof/dev +master,issue can only be reproduced with HDMI,DP is normal,tested on TGL HDA
Platform: TGL-U RVP with onboard codec ALC711 in HDA mode
Firmware: 21f1344 https://github.com/thesofproject/sof/commits/master
Kernel: 8d47294 https://github.com/thesofproject/linux/commits/topic/sof-dev
Topology file: tools/topology/sof-hda-generic-4ch.tplg same as firmware
[-][BUG][tgl] Jack detection is off in amixer contents after reboot with HDMI/DP connected[/-][+][BUG][tgl] Jack detection is off in amixer contents after reboot with HDMI connected[/+]kv2019i commentedon Feb 27, 2020
Tested today with TGL RVP and HDMI, but could not reproduce. @Liviali155 can you take log of the case with i915 traces enabled:
modprobe conf.d:
options drm debug=0x1e
OR with kernel cmdline:
drm.debug=0x1e
Liviali155 commentedon Feb 28, 2020
log as attachment
drm.log
kv2019i commentedon Mar 3, 2020
@Liviali155 The DRM log is so verbose that it fills the dmesg buffer very quickly and e.g. this log is missing lot of events from the early boot. You can overcome by increasing the dmesg size. "log_buf_len=1M" should be sufficient. You can add this e.g. with following to to /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash log_buf_len=1M"
Liviali155 commentedon Mar 5, 2020
I have increased the dmesg size,drm log as attachment
drm0305.log
5 remaining items
Liviali155 commentedon Mar 18, 2020
Tried with PR #1904 ,tips“Failed to start load kernel Modules”
mamarley commentedon Mar 18, 2020
Not sure what's happening for Livia, but for me it works fine. HDMI/DP audio now works fine immediately on boot. Thanks!
mamarley commentedon Mar 18, 2020
After further usage, however, it seems this introduces a strange issue where even small amounts of GPU load cause the mouse cursor to move jerkily and "drop frames". It seems weird, but reverting the patch causes it to work normally again.
kv2019i commentedon Mar 18, 2020
Thanks @mamarley ! Follow-up is currently discussed on intel-gfx list and I passed your findings to the folks working on the patch now.
mamarley commentedon Mar 18, 2020
I'm probably just being dense, but I can't seem to locate the thread. Could you please link to it? Thanks!
kv2019i commentedon Mar 18, 2020
@mamarley
Sure, no prob. It is here: https://lists.freedesktop.org/archives/intel-gfx/2020-March/233802.html
mamarley commentedon Mar 18, 2020
That patch is different from the one you linked earlier. When I tried the one from the list (it took a bit of massaging to get it to apply to 5.6-rc6), the audio works on boot and the cursor behaves normally.
Liviali155 commentedon Mar 19, 2020
The kern.log as attachment,It should has 2 times power on log,first is power on failed log
kern.log
kv2019i commentedon Mar 19, 2020
@mamarley wrote:
Yes, true, they modified the implementation in the first version sent out on the list. Thanks a lot for the report. There are now additional validation rounds done on the patch sent to the list and if all goes well, the patch will get merged. Thanks a lot for testing!
@Liviali155 I'll check the log separately, this might something else.
mamarley commentedon Mar 23, 2020
I hadn't noticed this before since I didn't test my Broadwell laptop with an eDP display with the patched kernel, but the patch from the ML re-regresses https://gitlab.freedesktop.org/drm/intel/issues/1151.
kv2019i commentedon Mar 24, 2020
@mamarley Can you report this in the gitlab issue 1363? The gfx folks are not following this bug tracker.
UPDATE: aa, you already did, thanks!
mamarley commentedon Mar 24, 2020
Already done :)
Liviali155 commentedon Mar 27, 2020
Tried with #1939,error not seen
kv2019i commentedon Mar 27, 2020
@Liviali155 wrote:
Excellent news, thanks a lot for the quick testing. The patch is merged upstream and I'll now proceed to merge this in sof-dev as well, so we get the fixing immediately to the audio tree.