Bug 108542 - hdmi issues with kernel 4.18
Summary: hdmi issues with kernel 4.18
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/AMDgpu (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-24 18:22 UTC by davide26079
Modified: 2019-11-19 09:00 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg (78.59 KB, text/plain)
2018-10-25 19:26 UTC, davide26079
no flags Details
0001-Fix-unsigned-short-unsigned-long-mixup-for-usSymCloc.patch (1.47 KB, patch)
2018-10-30 16:31 UTC, Nicholas Kazlauskas
no flags Details | Splinter Review

Description davide26079 2018-10-24 18:22:46 UTC
- since 4.18, the hdmi output says "12 bit"
- since 4.18.8 there's no video output !!

You can find more details in this thread

https://bbs.archlinux.org/viewtopic.php?id=241212

I did a bisection to find the bad commit for the first regression already, and that's the result:

e03fd3f300f6184c1264186a4c815e93bf658abb is the first bad commit
commit e03fd3f300f6184c1264186a4c815e93bf658abb
Author: Mikita Lipski <mikita.lipski@amd.com>
Date:   Wed May 16 16:46:18 2018 -0400

    drm/amd/display: Do not limit color depth to 8bpc
    
    Delete if statement that would force any display's color depth higher
    than 8 bpc to 8
    
    Signed-off-by: Mikita Lipski <mikita.lipski@amd.com>
    Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

:040000 040000 57c7a743a10059addbfdd1a122f90c4053d377fa 13139317e62ef56db1748bf48f31f81eb986c7f8 M      drivers
Comment 1 Nicholas Kazlauskas 2018-10-25 12:52:21 UTC
Thanks for the bisection.

Would you mind posting a full dmesg log for your 4.18.8 kernel?
Comment 2 davide26079 2018-10-25 19:26:17 UTC
Created attachment 142207 [details]
dmesg
Comment 3 davide26079 2018-10-25 19:28:51 UTC
(In reply to Nicholas Kazlauskas from comment #1)
> Thanks for the bisection.
> 
> Would you mind posting a full dmesg log for your 4.18.8 kernel?

done. Dunno if that's what you asked for, I am just a newbie...

I did start bisecting the second issue as well, but my free time is limited. I think I'll finish this weekend though.

May I hope to get things fixed in a few weeks?
Comment 4 Nicholas Kazlauskas 2018-10-25 19:35:29 UTC
(In reply to davide26079 from comment #3)
> (In reply to Nicholas Kazlauskas from comment #1)
> > Thanks for the bisection.
> > 
> > Would you mind posting a full dmesg log for your 4.18.8 kernel?
> 
> done. Dunno if that's what you asked for, I am just a newbie...
> 
> I did start bisecting the second issue as well, but my free time is limited.
> I think I'll finish this weekend though.
> 
> May I hope to get things fixed in a few weeks?

The log you posted should be sufficient. I'm not sure about a timeline for a fix, however.
Comment 5 davide26079 2018-10-27 10:47:43 UTC
> The log you posted should be sufficient. I'm not sure about a timeline for a
> fix, however.

Couldn't you just reverse the commits ?

I did complete the bisection btw:

691f2d763d0731224439686ecf2d440df8fe910e is the first bad commit
commit 691f2d763d0731224439686ecf2d440df8fe910e
Author: Mikita Lipski <mikita.lipski@amd.com>
Date:   Fri Jul 13 09:07:35 2018 -0400

    drm/amd/display: update clk for various HDMI color depths
    
    commit 81aca8e75c1b046865fb2badef95a0dcff6f73de upstream.
    
    [why]
    When programming tonga's connector's backend we didn't take
    in account that HDMI's colour depth might be more than 8bpc
    therefore we need to add a switch statement that would adjust
    the pixel clock accordingly.
    
    [how]
    Add a switch statement updating clock by its appropriate
    coefficient.
    
    Signed-off-by: Mikita Lipski <mikita.lipski@amd.com>
    Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
    Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

:040000 040000 ef9f989910439dc8749f1440863e3e26646d5fa1 c9ae9b8a137f9ef9d62147fcc28ea25fc4ffbc1e M      drivers
Comment 6 davide26079 2018-10-28 10:23:39 UTC
Built 4.19 reverting both commits, everything works fine.
Comment 7 Nicholas Kazlauskas 2018-10-30 16:31:00 UTC
Created attachment 142278 [details] [review]
0001-Fix-unsigned-short-unsigned-long-mixup-for-usSymCloc.patch

Does applying this patch help?

Try this on top of the tree without reverting the other patches.
Comment 8 davide26079 2018-10-31 10:03:45 UTC
(In reply to Nicholas Kazlauskas from comment #7)
> Created attachment 142278 [details] [review] [review]
> 0001-Fix-unsigned-short-unsigned-long-mixup-for-usSymCloc.patch
> 
> Does applying this patch help?
> 
> Try this on top of the tree without reverting the other patches.

Just tried, unfortunately it does not.
Comment 9 Nicholas Kazlauskas 2018-11-20 14:07:15 UTC
The patchset from:

https://patchwork.freedesktop.org/patch/260799/

...will likely resolve this issue.

It has been merged into amd-staging-drm-next branch at:

https://cgit.freedesktop.org/~agd5f/linux
Comment 10 davide26079 2018-11-21 15:41:35 UTC
(In reply to Nicholas Kazlauskas from comment #9)
> The patchset from:
> 
> https://patchwork.freedesktop.org/patch/260799/
> 
> ...will likely resolve this issue.
> 
> It has been merged into amd-staging-drm-next branch at:
> 
> https://cgit.freedesktop.org/~agd5f/linux

Tried amd-staging-drm-next, it works!
Comment 11 Martin Peres 2019-11-19 09:00:16 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/568.


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.