4K at 60 YCbCr420 missing mode in usermode

Tue Jun 26 23:06:56 UTC 2018

That patch doesn't work for me on Raven - I'm not sure what the DCE version
is

On Tue, 26 Jun 2018 at 19:34 Zuo, Jerry <Jerry.Zuo at amd.com> wrote:

> Hi Mike:
>
>
>
>      I’ve got the patch updated by checking ASIC ycbcr_420 capability. It
> will eliminate the support to any ASIC with DCE version < 112.
>
>      Please use DCE112 or higher ASIC as well.
>
>
>
> Regards,
>
> Jerry
>
>
>
> *From:* Zuo, Jerry
> *Sent:* June 26, 2018 2:15 PM
> *To:* 'Mike Lothian' <mike at fireburn.co.uk>; Michel Dänzer <
> michel at daenzer.net>
> *Cc:* Emil Velikov <emil.l.velikov at gmail.com>; xorg-devel at lists.x.org;
> Lipski, Mikita <Mikita.Lipski at amd.com>; Wentland, Harry <
> Harry.Wentland at amd.com>
> *Subject:* RE: 4K at 60 YCbCr420 missing mode in usermode
>
>
>
> Hi Mike:
>
>
>
> It is my bad that I need to check DCE version > 112 to add this flag on.
> Since I am testing on Vega10, I didn’t realize that. Anything like Carrizo,
> Fiji doesn’t apply to the ycbcr420_only patch.
>
>
>
> I’ll get the patch updated soon.
>
>
>
> Regard,
>
> Jerry
>
>
>
> *From:* Mike Lothian [mailto:mike at fireburn.co.uk <mike at fireburn.co.uk>]
> *Sent:* June 26, 2018 12:41 PM
> *To:* Michel Dänzer <michel at daenzer.net>
> *Cc:* Emil Velikov <emil.l.velikov at gmail.com>; Zuo, Jerry <
> Jerry.Zuo at amd.com>; xorg-devel at lists.x.org; Lipski, Mikita <
> Mikita.Lipski at amd.com>; Wentland, Harry <Harry.Wentland at amd.com>
> *Subject:* Re: 4K at 60 YCbCr420 missing mode in usermode
>
>
>
> With AMDGPU DDX I'm not seeing 4k at 60Hz with this patch and allowing >8bpc
>
>
>
> With modesetting X doesn't start and I get the following in dmesg:
>
>
>
> [  105.397875] ------------[ cut here ]------------
>
> [  105.397877] kernel BUG at
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4796!
>
> [  105.397882] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
>
> [  105.397884] CPU: 0 PID: 334 Comm: Xorg Tainted: G        W
>  4.18.0-rc1-agd5f+ #187
>
> [  105.397885] Hardware name: System manufacturer System Product Name/ROG
> STRIX X470-I GAMING, BIOS 0601 04/19/2018
>
> [  105.397890] RIP: 0010:dm_update_crtcs_state+0x45b/0x4e0
>
> [  105.397890] Code: ff ff 48 85 db 0f 84 ea fe ff ff 48 c7 44 24 18 00 00
> 00 00 48 c7 44 24 08 00 00 00 00 48 c7 04 24 00 00 00 00 e9 34 fe ff ff
> <0f> 0b 48 83 c4 30 b8 ea ff ff ff 5b 5d 41 5c 41 5d 41 5e 41 5f c3
>
> [  105.397908] RSP: 0018:ffffc9000063b8f8 EFLAGS: 00010246
>
> [  105.397910] RAX: ffff880819942001 RBX: ffff88081b317000 RCX:
> 0000000000000000
>
> [  105.397911] RDX: 0000000000007690 RSI: 0000000000007690 RDI:
> ffff880819943800
>
> [  105.397911] RBP: ffff880805bd0a80 R08: 0000000000022ac0 R09:
> ffffffff815bf6f4
>
> [  105.397912] R10: ffffea0020665000 R11: ffff88083e806e80 R12:
> 0000000000000000
>
> [  105.397913] R13: ffff880819942400 R14: ffff880819940400 R15:
> ffff88081b32e800
>
> [  105.397914] FS:  00007f0374519f80(0000) GS:ffff88083ec00000(0000)
> knlGS:0000000000000000
>
> [  105.397914] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>
> [  105.397915] CR2: 0000561ac61e0e10 CR3: 000000081acc6000 CR4:
> 00000000003406b0
>
> [  105.397916] Call Trace:
>
> [  105.397920]  ? amdgpu_dm_atomic_check+0x1b7/0x3d0
>
> [  105.397922]  ? _raw_spin_lock_irqsave+0x12/0x40
>
> [  105.397923]  ? _raw_spin_unlock_irqrestore+0xf/0x30
>
> [  105.397926]  ? drm_atomic_check_only+0x44d/0x640
>
> [  105.397928]  ? drm_atomic_commit+0xe/0x50
>
> [  105.397930]  ? restore_fbdev_mode_atomic+0x1b9/0x1d0
>
> [  105.397932]  ? drm_fb_helper_restore_fbdev_mode_unlocked+0x40/0x90
>
> [  105.397933]  ? drm_fb_helper_set_par+0x24/0x50
>
> [  105.397936]  ? fb_set_var+0x20f/0x3e0
>
> [  105.397938]  ? sugov_should_update_freq+0x42/0x60
>
> [  105.397940]  ? sugov_update_single+0x6e/0x1f0
>
> [  105.397942]  ? fbcon_blank+0x246/0x320
>
> [  105.397944]  ? try_to_wake_up+0x1f1/0x370
>
> [  105.397948]  ? do_unblank_screen+0x96/0x150
>
> [  105.397949]  ? vt_ioctl+0x35e/0x10f0
>
> [  105.397952]  ? path_parentat.isra.63+0x40/0x80
>
> [  105.397954]  ? tty_ioctl+0x217/0x890
>
> [  105.397956]  ? do_vfs_ioctl+0x9f/0x610
>
> [  105.397957]  ? dput.part.36+0x9a/0x120
>
> [  105.397959]  ? __fput+0x11a/0x1e0
>
> [  105.397960]  ? ksys_ioctl+0x35/0x70
>
> [  105.397962]  ? __x64_sys_ioctl+0x11/0x20
>
> [  105.397963]  ? do_syscall_64+0x43/0xf0
>
> [  105.397965]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> [  105.397966] Modules linked in:
>
> [  105.397967] ---[ end trace 82b2adbb705155c8 ]---
>
>
>
>
>
> On Tue, 26 Jun 2018 at 17:27 Mike Lothian <mike at fireburn.co.uk> wrote:
>
> Hi
>
>
>
> I'm happy to test this when I get home
>
>
>
> I'm currently reverting that patch that enables >8bit colour to get 60Hz
> back
>
>
>
> Cheers
>
>
>
> Mike
>
>
>
> On Tue, 26 Jun 2018 at 17:23 Michel Dänzer <michel at daenzer.net> wrote:
>
> On 2018-06-26 05:43 PM, Emil Velikov wrote:
> > Hi Jerry,
> >
> > On 25 June 2018 at 22:45, Zuo, Jerry <Jerry.Zuo at amd.com> wrote:
> >> Hello all:
> >>
> >>
> >>
> >> We are working on an issue affecting 4K at 60 HDMI display not to light
> up, but
> >> only showing up 4K at 30 from:
> >> https://bugs.freedesktop.org/show_bug.cgi?id=106959 and others.
> >>
> >>
> >>
> >> Some displays (e.g., ASUS PA328) HDMI port shows YCbCr420 CEA extension
> >> block with 4K at 60 supported. Such HDMI 4K at 60 is not real HDMI 2.0, but
> still
> >> following HDMI 1.4 spec. with maximum TMDS clock of 300MHz instead of
> >> 600MHz.
> >>
> >> To get such 4K at 60 supported, it needs to limit the bandwidth by
> reducing the
> >> color space to YCbCr420 only. We’ve already raised YCbCr420 only flag
> >> (attached patch) from kernel side to pass the mode validation, and
> expose it
> >> to user space.
> >>
> >>
> >>
> >>     We think that one of the issues that causes this problem is due to
> >> usermode pruning the 4K at 60 mode from the modelist (attached
> Xorg.0.log). It
> >> seems like when usermode receives all the modes, it doesn't take in
> account
> >> the 4K at 60 YCbCr4:2:0 specific mode. In order to pass validation of
> being
> >> added to usermode modelist, its pixel clk needs to be divided by 2 so
> that
> >> it won't exceed TMDS max physical pixel clk (300MHz). That might
> explain the
> >> difference in modes between our usermode and modeset.
> >>
> >>
> >>
> >>     Such YCbCr4:2:0 4K at 60 special mode is marked in DRM by raising a
> flag
> >> (y420_vdb_modes) inside connector's display_info which can be seen in
> >> do_y420vdb_modes(). Usermode could rely on that flag to pick up such
> mode
> >> and halve the required pclk to prevent such mode getting pruned out.
> >>
> >>
> >>
> >> We were hoping for someone helps to look at it from usermode
> perspective.
> >> Thanks a lot.
> >>
> > Just some observations, while going through some coffee. Take them
> > with a pinch of salt.
> >
> > Currently the kernel edid parser (in drm core) handles the
> > EXT_VIDEO_DATA_BLOCK_420 extended block.
> > Additionally, the kernel allows such modes only as the (per connector)
> > ycbcr_420_allowed bool is set by the driver.
> >
> > Quick look shows that it's only enabled by i915 on gen10 && geminilake
> hardware.
> >
> > At the same time, X does it's own fairly partial edid parsing and
> > doesn't handle any(?) extended blocks.
> >
> > One solution is to update the X parser, although it seems like a
> > endless game of cat and mouse.
> > IMHO a much better approach is to not use edid codepaths for KMS
> > drivers (where AMDGPU is one).
> > On those, the supported modes is advertised by the kernel module via
> > drmModeGetConnector.
>
> We are getting the modes from the kernel; the issue is they are then
> pruned (presumably by xf86ProbeOutputModes => xf86ValidateModesClocks)
> due to violating the clock limits, as described by Jerry above.
>
>
> --
> Earthling Michel Dänzer               |               http://www.amd.com
> Libre software enthusiast             |             Mesa and X developer
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180627/7e6a0017/attachment-0001.html>