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