<div dir="ltr">With AMDGPU DDX I'm not seeing 4k@60Hz with this patch and allowing >8bpc<div><br></div><div>With modesetting X doesn't start and I get the following in dmesg:</div><div><br></div><div><div>[ 105.397875] ------------[ cut here ]------------</div><div>[ 105.397877] kernel BUG at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4796!</div><div>[ 105.397882] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI</div><div>[ 105.397884] CPU: 0 PID: 334 Comm: Xorg Tainted: G W 4.18.0-rc1-agd5f+ #187</div><div>[ 105.397885] Hardware name: System manufacturer System Product Name/ROG STRIX X470-I GAMING, BIOS 0601 04/19/2018</div><div>[ 105.397890] RIP: 0010:dm_update_crtcs_state+0x45b/0x4e0</div><div>[ 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</div><div>[ 105.397908] RSP: 0018:ffffc9000063b8f8 EFLAGS: 00010246</div><div>[ 105.397910] RAX: ffff880819942001 RBX: ffff88081b317000 RCX: 0000000000000000</div><div>[ 105.397911] RDX: 0000000000007690 RSI: 0000000000007690 RDI: ffff880819943800</div><div>[ 105.397911] RBP: ffff880805bd0a80 R08: 0000000000022ac0 R09: ffffffff815bf6f4</div><div>[ 105.397912] R10: ffffea0020665000 R11: ffff88083e806e80 R12: 0000000000000000</div><div>[ 105.397913] R13: ffff880819942400 R14: ffff880819940400 R15: ffff88081b32e800</div><div>[ 105.397914] FS: 00007f0374519f80(0000) GS:ffff88083ec00000(0000) knlGS:0000000000000000</div><div>[ 105.397914] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033</div><div>[ 105.397915] CR2: 0000561ac61e0e10 CR3: 000000081acc6000 CR4: 00000000003406b0</div><div>[ 105.397916] Call Trace:</div><div>[ 105.397920] ? amdgpu_dm_atomic_check+0x1b7/0x3d0</div><div>[ 105.397922] ? _raw_spin_lock_irqsave+0x12/0x40</div><div>[ 105.397923] ? _raw_spin_unlock_irqrestore+0xf/0x30</div><div>[ 105.397926] ? drm_atomic_check_only+0x44d/0x640</div><div>[ 105.397928] ? drm_atomic_commit+0xe/0x50</div><div>[ 105.397930] ? restore_fbdev_mode_atomic+0x1b9/0x1d0</div><div>[ 105.397932] ? drm_fb_helper_restore_fbdev_mode_unlocked+0x40/0x90</div><div>[ 105.397933] ? drm_fb_helper_set_par+0x24/0x50</div><div>[ 105.397936] ? fb_set_var+0x20f/0x3e0</div><div>[ 105.397938] ? sugov_should_update_freq+0x42/0x60</div><div>[ 105.397940] ? sugov_update_single+0x6e/0x1f0</div><div>[ 105.397942] ? fbcon_blank+0x246/0x320</div><div>[ 105.397944] ? try_to_wake_up+0x1f1/0x370</div><div>[ 105.397948] ? do_unblank_screen+0x96/0x150</div><div>[ 105.397949] ? vt_ioctl+0x35e/0x10f0</div><div>[ 105.397952] ? path_parentat.isra.63+0x40/0x80</div><div>[ 105.397954] ? tty_ioctl+0x217/0x890</div><div>[ 105.397956] ? do_vfs_ioctl+0x9f/0x610</div><div>[ 105.397957] ? dput.part.36+0x9a/0x120</div><div>[ 105.397959] ? __fput+0x11a/0x1e0</div><div>[ 105.397960] ? ksys_ioctl+0x35/0x70</div><div>[ 105.397962] ? __x64_sys_ioctl+0x11/0x20</div><div>[ 105.397963] ? do_syscall_64+0x43/0xf0</div><div>[ 105.397965] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9</div><div>[ 105.397966] Modules linked in:</div><div>[ 105.397967] ---[ end trace 82b2adbb705155c8 ]---</div></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 26 Jun 2018 at 17:27 Mike Lothian <<a href="mailto:mike@fireburn.co.uk">mike@fireburn.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi<div><br></div><div>I'm happy to test this when I get home</div><div><br></div><div>I'm currently reverting that patch that enables >8bit colour to get 60Hz back</div><div><br></div><div>Cheers</div></div><div dir="ltr"><div><br></div><div>Mike</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 26 Jun 2018 at 17:23 Michel Dänzer <<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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" rel="noreferrer" 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" rel="noreferrer" 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" rel="noreferrer" target="_blank">http://lists.x.org/archives/xorg-devel</a><br>
Info: <a href="https://lists.x.org/mailman/listinfo/xorg-devel" rel="noreferrer" target="_blank">https://lists.x.org/mailman/listinfo/xorg-devel</a></blockquote></div>
</blockquote></div>