Re: 4K@60 YCbCr420 missing mode in usermode
On 2018-06-27 11:39 AM, Emil Velikov wrote: > On 27 June 2018 at 09:40, Michel Dänzer wrote: >> On 2018-06-26 07:11 PM, Emil Velikov wrote: >>> On 26 June 2018 at 17:23, Michel Dänzer wrote: On 2018-06-26 05:43 PM, Emil Velikov wrote: > On 25 June 2018 at 22:45, Zuo, Jerry wrote: >> >> >> >> We are working on an issue affecting 4K@60 HDMI display not to light up, >> but >> only showing up 4K@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@60 supported. Such HDMI 4K@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@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@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@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@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. >>> Might have been too brief there. Here goes a more elaborate >>> suggestion, please point out any misunderstandings. >>> >>> If we look into the drivers we'll see a call to xf86InterpretEDID(), >>> followed by xf86OutputSetEDID(). >>> The former doing a partial parsing of the edid, creating a xf86MonPtr >>> (timings information et al.) with the latter attaching it to the >>> output. >>> >>> Thus as we get into xf86ProbeOutputModes/xf86ValidateModesClocks the >>> Xserver probes the mode against given timing/bandwidth constrains, >>> discarding it where applicable. >>> >>> Considering that the DRM driver already does similar checks, X could >>> side-step the parsing and filtering/validation all together. >>> Trusting the kernel should be reasonable, considering weston (and I >>> would imagine other wayland compositors) already do so. >> >> It's still not clear to me what exactly you're proposing. Maybe you can >> whip up at least a mock-up patch? >> >> > I don't have much time to tinker with it, hopefully the following > proposal will be clear enough. If not perhaps I'll get to in at some > point. I'm afraid it's still rather vague to me at least. Anyway, since this is a (at least behavioural) regression in the 4.18 kernel cycle, it cannot be solved with userspace changes, especially not any involving xserver. A solution is needed for the final 4.18 release which works with current userspace. Taking a step back, it's not clear to me why the kernel change bisected in the bug report makes a difference as to whether Xorg prunes the 60 Hz 4K modes or not. EDID is identical in both cases, right? So does the kernel report a different clock for the modes now, or what exactly has changed that is
RE: 4K@60 YCbCr420 missing mode in usermode
Hi Mike: I’ve checked amd-staging-drm-next branch with the commit point “35d594ef218696edc92cf6a1175c1a4a9c7c2aa6” (4.18.0-rc1). Please checkout that commit, and apply the attached patch. ASUS PA328 display could only give 4K@30, and attached Xorg log shows YCbCr420 only 4K@60 modes are getting filtered out. The usermode I am using now is 607399. Thanks for your help. Regards, Jerry From: Mike Lothian [mailto:m...@fireburn.co.uk] Sent: June 27, 2018 11:36 AM To: Zuo, Jerry Cc: Michel Dänzer ; Emil Velikov ; xorg-devel@lists.x.org; Lipski, Mikita ; Wentland, Harry Subject: Re: 4K@60 YCbCr420 missing mode in usermode Hi I'm using https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.19-wip Cheers Mike On Wed, 27 Jun 2018 at 15:27 Zuo, Jerry mailto:jerry@amd.com>> wrote: Hi Mike: The build I am using for debug is based on amd-staging-dal-drm-next branch with commit 624fa8daa6e10af0b7f74dc31a66c26c4fbb2926. Please let me know which build you are using. Thanks. Regards, Jerry From: Mike Lothian [mailto:m...@fireburn.co.uk<mailto:m...@fireburn.co.uk>] Sent: June 26, 2018 7:09 PM To: Zuo, Jerry mailto:jerry@amd.com>> Cc: Michel Dänzer mailto:mic...@daenzer.net>>; Emil Velikov mailto:emil.l.veli...@gmail.com>>; xorg-devel@lists.x.org<mailto:xorg-devel@lists.x.org>; Lipski, Mikita mailto:mikita.lip...@amd.com>>; Wentland, Harry mailto:harry.wentl...@amd.com>> Subject: Re: 4K@60 YCbCr420 missing mode in usermode With the modesetting driver I would see this in my dmesg if it helps: Jun 27 00:00:38 quark kernel: [ cut here ] Jun 27 00:00:38 quark kernel: kernel BUG at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4797! Jun 27 00:00:38 quark kernel: invalid opcode: [#1] PREEMPT SMP NOPTI Jun 27 00:00:38 quark kernel: CPU: 2 PID: 335 Comm: Xorg Tainted: GW 4.18.0-rc1-agd5f+ #189 Jun 27 00:00:38 quark kernel: Hardware name: System manufacturer System Product Name/ROG STRIX X470-I GAMING, BIOS 0601 04/19/2018 Jun 27 00:00:38 quark kernel: RIP: 0010:dm_update_crtcs_state+0x45b/0x4e0 Jun 27 00:00:38 quark kernel: 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 Jun 27 00:00:38 quark kernel: RSP: 0018:c94fbb08 EFLAGS: 00010246 Jun 27 00:00:38 quark kernel: RAX: 880818642401 RBX: 88081b354000 RCX: Jun 27 00:00:38 quark kernel: RDX: 22d2 RSI: 22d2 RDI: 880818641800 Jun 27 00:00:38 quark kernel: RBP: 880806659f80 R08: 00022ac0 R09: 815bf644 Jun 27 00:00:38 quark kernel: R10: ea0020619000 R11: 88083e806e80 R12: Jun 27 00:00:38 quark kernel: R13: 880818642000 R14: 880818646800 R15: 88081b360800 Jun 27 00:00:38 quark kernel: FS: 7f5529f3df80() GS:88083ec8() knlGS: Jun 27 00:00:38 quark kernel: CS: 0010 DS: ES: CR0: 80050033 Jun 27 00:00:38 quark kernel: CR2: 7fb043f26610 CR3: 000811394000 CR4: 003406a0 Jun 27 00:00:38 quark kernel: Call Trace: Jun 27 00:00:38 quark kernel: ? amdgpu_dm_atomic_check+0x1b7/0x3d0 Jun 27 00:00:38 quark kernel: ? drm_atomic_check_only+0x44d/0x640 Jun 27 00:00:38 quark kernel: ? drm_atomic_set_property+0x6a/0x680 Jun 27 00:00:38 quark kernel: ? drm_mode_atomic_ioctl+0x64c/0x9f0 Jun 27 00:00:38 quark kernel: ? drm_atomic_set_property+0x680/0x680 Jun 27 00:00:38 quark kernel: ? drm_ioctl_kernel+0x9c/0xe0 Jun 27 00:00:38 quark kernel: ? drm_ioctl+0x1e1/0x380 Jun 27 00:00:38 quark kernel: ? drm_atomic_set_property+0x680/0x680 Jun 27 00:00:38 quark kernel: ? __set_current_blocked+0x38/0x50 Jun 27 00:00:38 quark kernel: ? _raw_spin_unlock_irq+0xe/0x20 Jun 27 00:00:38 quark kernel: ? amdgpu_drm_ioctl+0x44/0x80 Jun 27 00:00:38 quark kernel: ? do_vfs_ioctl+0x9f/0x610 Jun 27 00:00:38 quark kernel: ? recalc_sigpending+0x11/0x40 Jun 27 00:00:38 quark kernel: ? _copy_from_user+0x37/0x60 Jun 27 00:00:38 quark kernel: ? ksys_ioctl+0x35/0x70 Jun 27 00:00:38 quark kernel: ? __x64_sys_ioctl+0x11/0x20 Jun 27 00:00:38 quark kernel: ? do_syscall_64+0x43/0xf0 Jun 27 00:00:38 quark kernel: ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 Jun 27 00:00:38 quark kernel: Modules linked in: Jun 27 00:00:38 quark kernel: ---[ end trace c37f846a2d1ee561 ]--- Jun 27 00:00:38 quark kernel: RIP: 0010:dm_update_crtcs_state+0x45b/0x4e0 Jun 27 00:00:38 quark kernel: 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 Jun 27 00:00:38 quark kernel: RSP: 0018:c94fbb08 EFLAGS: 00010246 Jun 27 00:00:38 quark kernel: RAX: 880818642401 RBX: 88081b354
Re: 4K@60 YCbCr420 missing mode in usermode
Hi Jerry I can't see that commit in the tree: git show 35d594ef218696edc92cf6a1175c1a4a9c7c2aa6 fatal: bad object 35d594ef218696edc92cf6a1175c1a4a9c7c2aa6 As I explained before putting: if (bpc > 8) bpc = 8; Allows me to get 4K@60Hz, it's only when doing higher bpc that the 60Hz option disappears I'm using a https://www.asus.com/Motherboards/ROG-STRIX-X470-I-GAMING/overview/ motherboard which is HDMI 2.0 when paired with Raven 2400G Do you still want me to try the patch? Regards Mike On Wed, 27 Jun 2018 at 21:52 Zuo, Jerry wrote: > Hi Mike: > > > > I’ve checked amd-staging-drm-next branch with the commit point > “35d594ef218696edc92cf6a1175c1a4a9c7c2aa6” (4.18.0-rc1). Please checkout > that commit, and apply the attached patch. ASUS PA328 display could only > give 4K@30, and attached Xorg log shows YCbCr420 only 4K@60 modes are > getting filtered out. The usermode I am using now is 607399. Thanks for > your help. > > > > Regards, > > Jerry > > > > *From:* Mike Lothian [mailto:m...@fireburn.co.uk] > > *Sent:* June 27, 2018 11:36 AM > > > *To:* Zuo, Jerry > *Cc:* Michel Dänzer ; Emil Velikov < > emil.l.veli...@gmail.com>; xorg-devel@lists.x.org; Lipski, Mikita < > mikita.lip...@amd.com>; Wentland, Harry > *Subject:* Re: 4K@60 YCbCr420 missing mode in usermode > > > > Hi > > > > I'm using > https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.19-wip > > > > Cheers > > > > Mike > > > > On Wed, 27 Jun 2018 at 15:27 Zuo, Jerry wrote: > > Hi Mike: > > > > The build I am using for debug is based on amd-staging-dal-drm-next > branch with commit 624fa8daa6e10af0b7f74dc31a66c26c4fbb2926. Please let me > know which build you are using. Thanks. > > > > Regards, > > Jerry > > > > *From:* Mike Lothian [mailto:m...@fireburn.co.uk] > > *Sent:* June 26, 2018 7:09 PM > *To:* Zuo, Jerry > *Cc:* Michel Dänzer ; Emil Velikov < > emil.l.veli...@gmail.com>; xorg-devel@lists.x.org; Lipski, Mikita < > mikita.lip...@amd.com>; Wentland, Harry > > > *Subject:* Re: 4K@60 YCbCr420 missing mode in usermode > > > > With the modesetting driver I would see this in my dmesg if it helps: > > > > Jun 27 00:00:38 quark kernel: *[ cut here ]* > Jun 27 00:00:38 quark kernel: *kernel BUG at > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4797!* > Jun 27 00:00:38 quark kernel: *invalid opcode: [#1] PREEMPT SMP > NOPTI* > Jun 27 00:00:38 quark kernel: *CPU: 2 PID: 335 Comm: Xorg Tainted: G >W 4.18.0-rc1-agd5f+ #189* > Jun 27 00:00:38 quark kernel: *Hardware name: System manufacturer System > Product Name/ROG STRIX X470-I GAMING, BIOS 0601 04/19/2018* > Jun 27 00:00:38 quark kernel: *RIP: > 0010:dm_update_crtcs_state+0x45b/0x4e0* > Jun 27 00:00:38 quark kernel: *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 * > Jun 27 00:00:38 quark kernel: *RSP: 0018:c94fbb08 EFLAGS: > 00010246* > Jun 27 00:00:38 quark kernel: *RAX: 880818642401 RBX: > 88081b354000 RCX: * > Jun 27 00:00:38 quark kernel: *RDX: 22d2 RSI: > 22d2 RDI: 880818641800* > Jun 27 00:00:38 quark kernel: *RBP: 880806659f80 R08: > 00022ac0 R09: 815bf644* > Jun 27 00:00:38 quark kernel: *R10: ea0020619000 R11: > 88083e806e80 R12: * > Jun 27 00:00:38 quark kernel: *R13: 880818642000 R14: > 880818646800 R15: 88081b360800* > Jun 27 00:00:38 quark kernel: *FS: 7f5529f3df80() > GS:88083ec8() knlGS:* > Jun 27 00:00:38 quark kernel: *CS: 0010 DS: ES: CR0: > 80050033* > Jun 27 00:00:38 quark kernel: *CR2: 7fb043f26610 CR3: > 000811394000 CR4: 003406a0* > Jun 27 00:00:38 quark kernel: *Call Trace:* > Jun 27 00:00:38 quark kernel: * ? amdgpu_dm_atomic_check+0x1b7/0x3d0* > Jun 27 00:00:38 quark kernel: * ? drm_atomic_check_only+0x44d/0x640* > Jun 27 00:00:38 quark kernel: * ? drm_atomic_set_property+0x6a/0x680* > Jun 27 00:00:38 quark kernel: * ? drm_mode_atomic_ioctl+0x64c/0x9f0* > Jun 27 00:00:38 quark kernel: * ? drm_atomic_set_property+0x680/0x680* > Jun 27 00:00:38 quark kernel: * ? drm_ioctl_kernel+0x9c/0xe0* > Jun 27 00:00:38 quark kernel: * ? drm_ioctl+0x1e1/0x380* > Jun 27 00:00:38 quark kernel: * ? drm_atomic_set_property+0x680/0x680* > Jun 27 00:00:38 quark kernel: * ? __set_current_blocked+0x38/0x50* > Jun 27 00:00:38 quark kernel: * ? _raw_spin_u
Re: 4K@60 YCbCr420 missing mode in usermode
Hi I'm using https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.19-wip Cheers Mike On Wed, 27 Jun 2018 at 15:27 Zuo, Jerry wrote: > Hi Mike: > > > > The build I am using for debug is based on amd-staging-dal-drm-next > branch with commit 624fa8daa6e10af0b7f74dc31a66c26c4fbb2926. Please let me > know which build you are using. Thanks. > > > > Regards, > > Jerry > > > > *From:* Mike Lothian [mailto:m...@fireburn.co.uk] > > *Sent:* June 26, 2018 7:09 PM > *To:* Zuo, Jerry > *Cc:* Michel Dänzer ; Emil Velikov < > emil.l.veli...@gmail.com>; xorg-devel@lists.x.org; Lipski, Mikita < > mikita.lip...@amd.com>; Wentland, Harry > > > *Subject:* Re: 4K@60 YCbCr420 missing mode in usermode > > > > With the modesetting driver I would see this in my dmesg if it helps: > > > > Jun 27 00:00:38 quark kernel: *[ cut here ]* > Jun 27 00:00:38 quark kernel: *kernel BUG at > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4797!* > Jun 27 00:00:38 quark kernel: *invalid opcode: [#1] PREEMPT SMP > NOPTI* > Jun 27 00:00:38 quark kernel: *CPU: 2 PID: 335 Comm: Xorg Tainted: G >W 4.18.0-rc1-agd5f+ #189* > Jun 27 00:00:38 quark kernel: *Hardware name: System manufacturer System > Product Name/ROG STRIX X470-I GAMING, BIOS 0601 04/19/2018* > Jun 27 00:00:38 quark kernel: *RIP: > 0010:dm_update_crtcs_state+0x45b/0x4e0* > Jun 27 00:00:38 quark kernel: *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 * > Jun 27 00:00:38 quark kernel: *RSP: 0018:c94fbb08 EFLAGS: > 00010246* > Jun 27 00:00:38 quark kernel: *RAX: 880818642401 RBX: > 88081b354000 RCX: * > Jun 27 00:00:38 quark kernel: *RDX: 22d2 RSI: > 22d2 RDI: 880818641800* > Jun 27 00:00:38 quark kernel: *RBP: 880806659f80 R08: > 00022ac0 R09: 815bf644* > Jun 27 00:00:38 quark kernel: *R10: ea0020619000 R11: > 88083e806e80 R12: * > Jun 27 00:00:38 quark kernel: *R13: 880818642000 R14: > 880818646800 R15: 88081b360800* > Jun 27 00:00:38 quark kernel: *FS: 7f5529f3df80() > GS:88083ec8() knlGS:* > Jun 27 00:00:38 quark kernel: *CS: 0010 DS: ES: CR0: > 80050033* > Jun 27 00:00:38 quark kernel: *CR2: 7fb043f26610 CR3: > 000811394000 CR4: 003406a0* > Jun 27 00:00:38 quark kernel: *Call Trace:* > Jun 27 00:00:38 quark kernel: * ? amdgpu_dm_atomic_check+0x1b7/0x3d0* > Jun 27 00:00:38 quark kernel: * ? drm_atomic_check_only+0x44d/0x640* > Jun 27 00:00:38 quark kernel: * ? drm_atomic_set_property+0x6a/0x680* > Jun 27 00:00:38 quark kernel: * ? drm_mode_atomic_ioctl+0x64c/0x9f0* > Jun 27 00:00:38 quark kernel: * ? drm_atomic_set_property+0x680/0x680* > Jun 27 00:00:38 quark kernel: * ? drm_ioctl_kernel+0x9c/0xe0* > Jun 27 00:00:38 quark kernel: * ? drm_ioctl+0x1e1/0x380* > Jun 27 00:00:38 quark kernel: * ? drm_atomic_set_property+0x680/0x680* > Jun 27 00:00:38 quark kernel: * ? __set_current_blocked+0x38/0x50* > Jun 27 00:00:38 quark kernel: * ? _raw_spin_unlock_irq+0xe/0x20* > Jun 27 00:00:38 quark kernel: * ? amdgpu_drm_ioctl+0x44/0x80* > Jun 27 00:00:38 quark kernel: * ? do_vfs_ioctl+0x9f/0x610* > Jun 27 00:00:38 quark kernel: * ? recalc_sigpending+0x11/0x40* > Jun 27 00:00:38 quark kernel: * ? _copy_from_user+0x37/0x60* > Jun 27 00:00:38 quark kernel: * ? ksys_ioctl+0x35/0x70* > Jun 27 00:00:38 quark kernel: * ? __x64_sys_ioctl+0x11/0x20* > Jun 27 00:00:38 quark kernel: * ? do_syscall_64+0x43/0xf0* > Jun 27 00:00:38 quark kernel: * ? > entry_SYSCALL_64_after_hwframe+0x44/0xa9* > Jun 27 00:00:38 quark kernel: *Modules linked in:* > Jun 27 00:00:38 quark kernel: *---[ end trace c37f846a2d1ee561 ]---* > Jun 27 00:00:38 quark kernel: *RIP: > 0010:dm_update_crtcs_state+0x45b/0x4e0* > Jun 27 00:00:38 quark kernel: *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 * > Jun 27 00:00:38 quark kernel: *RSP: 0018:c94fbb08 EFLAGS: > 00010246* > Jun 27 00:00:38 quark kernel: *RAX: 880818642401 RBX: > 88081b354000 RCX: * > Jun 27 00:00:38 quark kernel: *RDX: 22d2 RSI: > 22d2 RDI: 880818641800* > Jun 27 00:00:38 quark kernel: *RBP: 880806659f80 R08: > 00022ac0 R09: 815bf644* > Jun 27 00:00:38 quark kernel: *R10: ea0020
RE: 4K@60 YCbCr420 missing mode in usermode
Hi Mike: The build I am using for debug is based on amd-staging-dal-drm-next branch with commit 624fa8daa6e10af0b7f74dc31a66c26c4fbb2926. Please let me know which build you are using. Thanks. Regards, Jerry From: Mike Lothian [mailto:m...@fireburn.co.uk] Sent: June 26, 2018 7:09 PM To: Zuo, Jerry Cc: Michel Dänzer ; Emil Velikov ; xorg-devel@lists.x.org; Lipski, Mikita ; Wentland, Harry Subject: Re: 4K@60 YCbCr420 missing mode in usermode With the modesetting driver I would see this in my dmesg if it helps: Jun 27 00:00:38 quark kernel: [ cut here ] Jun 27 00:00:38 quark kernel: kernel BUG at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4797! Jun 27 00:00:38 quark kernel: invalid opcode: [#1] PREEMPT SMP NOPTI Jun 27 00:00:38 quark kernel: CPU: 2 PID: 335 Comm: Xorg Tainted: GW 4.18.0-rc1-agd5f+ #189 Jun 27 00:00:38 quark kernel: Hardware name: System manufacturer System Product Name/ROG STRIX X470-I GAMING, BIOS 0601 04/19/2018 Jun 27 00:00:38 quark kernel: RIP: 0010:dm_update_crtcs_state+0x45b/0x4e0 Jun 27 00:00:38 quark kernel: 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 Jun 27 00:00:38 quark kernel: RSP: 0018:c94fbb08 EFLAGS: 00010246 Jun 27 00:00:38 quark kernel: RAX: 880818642401 RBX: 88081b354000 RCX: Jun 27 00:00:38 quark kernel: RDX: 22d2 RSI: 22d2 RDI: 880818641800 Jun 27 00:00:38 quark kernel: RBP: 880806659f80 R08: 00022ac0 R09: 815bf644 Jun 27 00:00:38 quark kernel: R10: ea0020619000 R11: 88083e806e80 R12: Jun 27 00:00:38 quark kernel: R13: 880818642000 R14: 880818646800 R15: 88081b360800 Jun 27 00:00:38 quark kernel: FS: 7f5529f3df80() GS:88083ec8() knlGS: Jun 27 00:00:38 quark kernel: CS: 0010 DS: ES: CR0: 80050033 Jun 27 00:00:38 quark kernel: CR2: 7fb043f26610 CR3: 000811394000 CR4: 003406a0 Jun 27 00:00:38 quark kernel: Call Trace: Jun 27 00:00:38 quark kernel: ? amdgpu_dm_atomic_check+0x1b7/0x3d0 Jun 27 00:00:38 quark kernel: ? drm_atomic_check_only+0x44d/0x640 Jun 27 00:00:38 quark kernel: ? drm_atomic_set_property+0x6a/0x680 Jun 27 00:00:38 quark kernel: ? drm_mode_atomic_ioctl+0x64c/0x9f0 Jun 27 00:00:38 quark kernel: ? drm_atomic_set_property+0x680/0x680 Jun 27 00:00:38 quark kernel: ? drm_ioctl_kernel+0x9c/0xe0 Jun 27 00:00:38 quark kernel: ? drm_ioctl+0x1e1/0x380 Jun 27 00:00:38 quark kernel: ? drm_atomic_set_property+0x680/0x680 Jun 27 00:00:38 quark kernel: ? __set_current_blocked+0x38/0x50 Jun 27 00:00:38 quark kernel: ? _raw_spin_unlock_irq+0xe/0x20 Jun 27 00:00:38 quark kernel: ? amdgpu_drm_ioctl+0x44/0x80 Jun 27 00:00:38 quark kernel: ? do_vfs_ioctl+0x9f/0x610 Jun 27 00:00:38 quark kernel: ? recalc_sigpending+0x11/0x40 Jun 27 00:00:38 quark kernel: ? _copy_from_user+0x37/0x60 Jun 27 00:00:38 quark kernel: ? ksys_ioctl+0x35/0x70 Jun 27 00:00:38 quark kernel: ? __x64_sys_ioctl+0x11/0x20 Jun 27 00:00:38 quark kernel: ? do_syscall_64+0x43/0xf0 Jun 27 00:00:38 quark kernel: ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 Jun 27 00:00:38 quark kernel: Modules linked in: Jun 27 00:00:38 quark kernel: ---[ end trace c37f846a2d1ee561 ]--- Jun 27 00:00:38 quark kernel: RIP: 0010:dm_update_crtcs_state+0x45b/0x4e0 Jun 27 00:00:38 quark kernel: 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 Jun 27 00:00:38 quark kernel: RSP: 0018:c94fbb08 EFLAGS: 00010246 Jun 27 00:00:38 quark kernel: RAX: 880818642401 RBX: 88081b354000 RCX: Jun 27 00:00:38 quark kernel: RDX: 22d2 RSI: 22d2 RDI: 880818641800 Jun 27 00:00:38 quark kernel: RBP: 880806659f80 R08: 00022ac0 R09: 815bf644 Jun 27 00:00:38 quark kernel: R10: ea0020619000 R11: 88083e806e80 R12: Jun 27 00:00:38 quark kernel: R13: 880818642000 R14: 880818646800 R15: 88081b360800 Jun 27 00:00:38 quark kernel: FS: 7f5529f3df80() GS:88083ec8() knlGS: Jun 27 00:00:38 quark kernel: CS: 0010 DS: ES: CR0: 80050033 Jun 27 00:00:38 quark kernel: CR2: 7fb043f26610 CR3: 000811394000 CR4: 003406a0 On Wed, 27 Jun 2018 at 00:06 Mike Lothian mailto:m...@fireburn.co.uk>> wrote: 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 mailto:jerry@amd.com>> wrote: Hi Mike: I’ve got the patch updated by checking ASIC ycbcr_420 capability. It will eliminate the support to any ASI
Re: 4K@60 YCbCr420 missing mode in usermode
On 27 June 2018 at 09:40, Michel Dänzer wrote: > On 2018-06-26 07:11 PM, Emil Velikov wrote: >> On 26 June 2018 at 17:23, Michel Dänzer wrote: >>> On 2018-06-26 05:43 PM, Emil Velikov wrote: On 25 June 2018 at 22:45, Zuo, Jerry wrote: > Hello all: > > > > We are working on an issue affecting 4K@60 HDMI display not to light up, > but > only showing up 4K@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@60 supported. Such HDMI 4K@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@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@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@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@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. >>> >> Might have been too brief there. Here goes a more elaborate >> suggestion, please point out any misunderstandings. >> >> If we look into the drivers we'll see a call to xf86InterpretEDID(), >> followed by xf86OutputSetEDID(). >> The former doing a partial parsing of the edid, creating a xf86MonPtr >> (timings information et al.) with the latter attaching it to the >> output. >> >> Thus as we get into xf86ProbeOutputModes/xf86ValidateModesClocks the >> Xserver probes the mode against given timing/bandwidth constrains, >> discarding it where applicable. >> >> Considering that the DRM driver already does similar checks, X could >> side-step the parsing and filtering/validation all together. >> Trusting the kernel should be reasonable, considering weston (and I >> would imagine other wayland compositors) already do so. > > It's still not clear to me what exactly you're proposing. Maybe you can > whip up at least a mock-up patch? > > I don't have much time to tinker with it, hopefully the following proposal will be clear enough. If not perhaps I'll get to in at some point. Step 1) Since xf86InterpretEDID/xf86OutputSetEDID are used by both KMS and UMS drivers one will need another set of functions. The former parsing only the required info of the edid - ideally zero modeset details, into a say into a new struct. With the latter attaching the new data to the output. Update Xserver to use the data produced by the new functions, falling back the old one. Step 2) Any Xserver functions that do mode validation (for example xf86ProbeOutputModes) become mostly a no-op if the mode comes from the kernel. Basically no max_clock/timings adjustments, no *Validate* calls. Modes added manually via xorg.conf would still need to go through all the tweaks (tmds_freq > max_clock, nHsync == 0, etc) and validation
Re: 4K@60 YCbCr420 missing mode in usermode
On 2018-06-26 07:11 PM, Emil Velikov wrote: > On 26 June 2018 at 17:23, Michel Dänzer wrote: >> On 2018-06-26 05:43 PM, Emil Velikov wrote: >>> On 25 June 2018 at 22:45, Zuo, Jerry wrote: Hello all: We are working on an issue affecting 4K@60 HDMI display not to light up, but only showing up 4K@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@60 supported. Such HDMI 4K@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@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@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@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@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. >> > Might have been too brief there. Here goes a more elaborate > suggestion, please point out any misunderstandings. > > If we look into the drivers we'll see a call to xf86InterpretEDID(), > followed by xf86OutputSetEDID(). > The former doing a partial parsing of the edid, creating a xf86MonPtr > (timings information et al.) with the latter attaching it to the > output. > > Thus as we get into xf86ProbeOutputModes/xf86ValidateModesClocks the > Xserver probes the mode against given timing/bandwidth constrains, > discarding it where applicable. > > Considering that the DRM driver already does similar checks, X could > side-step the parsing and filtering/validation all together. > Trusting the kernel should be reasonable, considering weston (and I > would imagine other wayland compositors) already do so. It's still not clear to me what exactly you're proposing. Maybe you can whip up at least a mock-up patch? > Obviously, manually added modelines (via a config file) would still > need to be validated. How would that be done? Does the kernel provide functionality for this? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
RE: 4K@60 YCbCr420 missing mode in usermode
Hi Mike: Are you trying out the patch “0001-SWDEV-155733-Add-YCbCr420-only-support-for-HDMI-4K-6.patch” and X doesn’t start? Jerry From: Mike Lothian [mailto:m...@fireburn.co.uk] Sent: June 26, 2018 12:41 PM To: Michel Dänzer Cc: Emil Velikov ; Zuo, Jerry ; xorg-devel@lists.x.org; Lipski, Mikita ; Wentland, Harry Subject: Re: 4K@60 YCbCr420 missing mode in usermode With AMDGPU DDX I'm not seeing 4k@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: [#1] PREEMPT SMP NOPTI [ 105.397884] CPU: 0 PID: 334 Comm: Xorg Tainted: GW 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:c963b8f8 EFLAGS: 00010246 [ 105.397910] RAX: 880819942001 RBX: 88081b317000 RCX: [ 105.397911] RDX: 7690 RSI: 7690 RDI: 880819943800 [ 105.397911] RBP: 880805bd0a80 R08: 00022ac0 R09: 815bf6f4 [ 105.397912] R10: ea0020665000 R11: 88083e806e80 R12: [ 105.397913] R13: 880819942400 R14: 880819940400 R15: 88081b32e800 [ 105.397914] FS: 7f0374519f80() GS:88083ec0() knlGS: [ 105.397914] CS: 0010 DS: ES: CR0: 80050033 [ 105.397915] CR2: 561ac61e0e10 CR3: 00081acc6000 CR4: 003406b0 [ 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 mailto:m...@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 mailto:mic...@daenzer.net>> wrote: On 2018-06-26 05:43 PM, Emil Velikov wrote: > Hi Jerry, > > On 25 June 2018 at 22:45, Zuo, Jerry > mailto:jerry@amd.com>> wrote: >> Hello all: >> >> >> >> We are working on an issue affecting 4K@60 HDMI display not to light up, but >> only showing up 4K@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@60 supported. Such HDMI 4K@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@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@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@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 &g
RE: 4K@60 YCbCr420 missing mode in usermode
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' ; Michel Dänzer Cc: Emil Velikov ; xorg-devel@lists.x.org; Lipski, Mikita ; Wentland, Harry Subject: RE: 4K@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:m...@fireburn.co.uk] Sent: June 26, 2018 12:41 PM To: Michel Dänzer mailto:mic...@daenzer.net>> Cc: Emil Velikov mailto:emil.l.veli...@gmail.com>>; Zuo, Jerry mailto:jerry@amd.com>>; xorg-devel@lists.x.org<mailto:xorg-devel@lists.x.org>; Lipski, Mikita mailto:mikita.lip...@amd.com>>; Wentland, Harry mailto:harry.wentl...@amd.com>> Subject: Re: 4K@60 YCbCr420 missing mode in usermode With AMDGPU DDX I'm not seeing 4k@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: [#1] PREEMPT SMP NOPTI [ 105.397884] CPU: 0 PID: 334 Comm: Xorg Tainted: GW 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:c963b8f8 EFLAGS: 00010246 [ 105.397910] RAX: 880819942001 RBX: 88081b317000 RCX: [ 105.397911] RDX: 7690 RSI: 7690 RDI: 880819943800 [ 105.397911] RBP: 880805bd0a80 R08: 00022ac0 R09: 815bf6f4 [ 105.397912] R10: ea0020665000 R11: 88083e806e80 R12: [ 105.397913] R13: 880819942400 R14: 880819940400 R15: 88081b32e800 [ 105.397914] FS: 7f0374519f80() GS:88083ec0() knlGS: [ 105.397914] CS: 0010 DS: ES: CR0: 80050033 [ 105.397915] CR2: 561ac61e0e10 CR3: 00081acc6000 CR4: 003406b0 [ 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 mailto:m...@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 mailto:mic...@daenzer.net>> wrote: On 2018-06-26 05:43 PM, Emil Velikov wrote: > Hi Jerry, > > On 25 June 2018 at 22:45, Zuo, Jerry > mailto:jerry@amd.com>> wrote: >> Hello all: >> >> >> >> We are working on an issue affecting 4K@60 HDMI display not to light up, but >> only showing up 4K@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@60 supported. Such HDMI 4K@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@60 suppo
RE: 4K@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:m...@fireburn.co.uk] Sent: June 26, 2018 12:41 PM To: Michel Dänzer Cc: Emil Velikov ; Zuo, Jerry ; xorg-devel@lists.x.org; Lipski, Mikita ; Wentland, Harry Subject: Re: 4K@60 YCbCr420 missing mode in usermode With AMDGPU DDX I'm not seeing 4k@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: [#1] PREEMPT SMP NOPTI [ 105.397884] CPU: 0 PID: 334 Comm: Xorg Tainted: GW 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:c963b8f8 EFLAGS: 00010246 [ 105.397910] RAX: 880819942001 RBX: 88081b317000 RCX: [ 105.397911] RDX: 7690 RSI: 7690 RDI: 880819943800 [ 105.397911] RBP: 880805bd0a80 R08: 00022ac0 R09: 815bf6f4 [ 105.397912] R10: ea0020665000 R11: 88083e806e80 R12: [ 105.397913] R13: 880819942400 R14: 880819940400 R15: 88081b32e800 [ 105.397914] FS: 7f0374519f80() GS:88083ec0() knlGS: [ 105.397914] CS: 0010 DS: ES: CR0: 80050033 [ 105.397915] CR2: 561ac61e0e10 CR3: 00081acc6000 CR4: 003406b0 [ 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 mailto:m...@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 mailto:mic...@daenzer.net>> wrote: On 2018-06-26 05:43 PM, Emil Velikov wrote: > Hi Jerry, > > On 25 June 2018 at 22:45, Zuo, Jerry > mailto:jerry@amd.com>> wrote: >> Hello all: >> >> >> >> We are working on an issue affecting 4K@60 HDMI display not to light up, but >> only showing up 4K@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@60 supported. Such HDMI 4K@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@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@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@60 YCbCr4:2:0 specific mode. In order to pass validation of being >> added to usermode modelist, its pixel c
Re: 4K@60 YCbCr420 missing mode in usermode
With the modesetting driver I would see this in my dmesg if it helps: Jun 27 00:00:38 quark kernel: [ cut here ] Jun 27 00:00:38 quark kernel: kernel BUG at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4797! Jun 27 00:00:38 quark kernel: invalid opcode: [#1] PREEMPT SMP NOPTI Jun 27 00:00:38 quark kernel: CPU: 2 PID: 335 Comm: Xorg Tainted: G W 4.18.0-rc1-agd5f+ #189 Jun 27 00:00:38 quark kernel: Hardware name: System manufacturer System Product Name/ROG STRIX X470-I GAMING, BIOS 0601 04/19/2018 Jun 27 00:00:38 quark kernel: RIP: 0010:dm_update_crtcs_state+0x45b/0x4e0 Jun 27 00:00:38 quark kernel: 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 Jun 27 00:00:38 quark kernel: RSP: 0018:c94fbb08 EFLAGS: 00010246 Jun 27 00:00:38 quark kernel: RAX: 880818642401 RBX: 88081b354000 RCX: Jun 27 00:00:38 quark kernel: RDX: 22d2 RSI: 22d2 RDI: 880818641800 Jun 27 00:00:38 quark kernel: RBP: 880806659f80 R08: 00022ac0 R09: 815bf644 Jun 27 00:00:38 quark kernel: R10: ea0020619000 R11: 88083e806e80 R12: Jun 27 00:00:38 quark kernel: R13: 880818642000 R14: 880818646800 R15: 88081b360800 Jun 27 00:00:38 quark kernel: FS: 7f5529f3df80() GS:88083ec8() knlGS: Jun 27 00:00:38 quark kernel: CS: 0010 DS: ES: CR0: 80050033 Jun 27 00:00:38 quark kernel: CR2: 7fb043f26610 CR3: 000811394000 CR4: 003406a0 Jun 27 00:00:38 quark kernel: Call Trace: Jun 27 00:00:38 quark kernel: ? amdgpu_dm_atomic_check+0x1b7/0x3d0 Jun 27 00:00:38 quark kernel: ? drm_atomic_check_only+0x44d/0x640 Jun 27 00:00:38 quark kernel: ? drm_atomic_set_property+0x6a/0x680 Jun 27 00:00:38 quark kernel: ? drm_mode_atomic_ioctl+0x64c/0x9f0 Jun 27 00:00:38 quark kernel: ? drm_atomic_set_property+0x680/0x680 Jun 27 00:00:38 quark kernel: ? drm_ioctl_kernel+0x9c/0xe0 Jun 27 00:00:38 quark kernel: ? drm_ioctl+0x1e1/0x380 Jun 27 00:00:38 quark kernel: ? drm_atomic_set_property+0x680/0x680 Jun 27 00:00:38 quark kernel: ? __set_current_blocked+0x38/0x50 Jun 27 00:00:38 quark kernel: ? _raw_spin_unlock_irq+0xe/0x20 Jun 27 00:00:38 quark kernel: ? amdgpu_drm_ioctl+0x44/0x80 Jun 27 00:00:38 quark kernel: ? do_vfs_ioctl+0x9f/0x610 Jun 27 00:00:38 quark kernel: ? recalc_sigpending+0x11/0x40 Jun 27 00:00:38 quark kernel: ? _copy_from_user+0x37/0x60 Jun 27 00:00:38 quark kernel: ? ksys_ioctl+0x35/0x70 Jun 27 00:00:38 quark kernel: ? __x64_sys_ioctl+0x11/0x20 Jun 27 00:00:38 quark kernel: ? do_syscall_64+0x43/0xf0 Jun 27 00:00:38 quark kernel: ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 Jun 27 00:00:38 quark kernel: Modules linked in: Jun 27 00:00:38 quark kernel: ---[ end trace c37f846a2d1ee561 ]--- Jun 27 00:00:38 quark kernel: RIP: 0010:dm_update_crtcs_state+0x45b/0x4e0 Jun 27 00:00:38 quark kernel: 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 Jun 27 00:00:38 quark kernel: RSP: 0018:c94fbb08 EFLAGS: 00010246 Jun 27 00:00:38 quark kernel: RAX: 880818642401 RBX: 88081b354000 RCX: Jun 27 00:00:38 quark kernel: RDX: 22d2 RSI: 22d2 RDI: 880818641800 Jun 27 00:00:38 quark kernel: RBP: 880806659f80 R08: 00022ac0 R09: 815bf644 Jun 27 00:00:38 quark kernel: R10: ea0020619000 R11: 88083e806e80 R12: Jun 27 00:00:38 quark kernel: R13: 880818642000 R14: 880818646800 R15: 88081b360800 Jun 27 00:00:38 quark kernel: FS: 7f5529f3df80() GS:88083ec8() knlGS: Jun 27 00:00:38 quark kernel: CS: 0010 DS: ES: CR0: 80050033 Jun 27 00:00:38 quark kernel: CR2: 7fb043f26610 CR3: 000811394000 CR4: 003406a0 On Wed, 27 Jun 2018 at 00:06 Mike Lothian wrote: > 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 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' ; Michel Dänzer < >> mic...@daenzer.net> >> *Cc:* Emil Velikov ; xorg-devel@lists.x.org; >> Lipski, Mikita ; Wentland, Harry < >> harry.wentl...@amd
Re: 4K@60 YCbCr420 missing mode in usermode
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 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' ; Michel Dänzer < > mic...@daenzer.net> > *Cc:* Emil Velikov ; xorg-devel@lists.x.org; > Lipski, Mikita ; Wentland, Harry < > harry.wentl...@amd.com> > *Subject:* RE: 4K@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:m...@fireburn.co.uk ] > *Sent:* June 26, 2018 12:41 PM > *To:* Michel Dänzer > *Cc:* Emil Velikov ; Zuo, Jerry < > jerry@amd.com>; xorg-devel@lists.x.org; Lipski, Mikita < > mikita.lip...@amd.com>; Wentland, Harry > *Subject:* Re: 4K@60 YCbCr420 missing mode in usermode > > > > With AMDGPU DDX I'm not seeing 4k@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: [#1] PREEMPT SMP NOPTI > > [ 105.397884] CPU: 0 PID: 334 Comm: Xorg Tainted: GW > 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:c963b8f8 EFLAGS: 00010246 > > [ 105.397910] RAX: 880819942001 RBX: 88081b317000 RCX: > > > [ 105.397911] RDX: 7690 RSI: 7690 RDI: > 880819943800 > > [ 105.397911] RBP: 880805bd0a80 R08: 00022ac0 R09: > 815bf6f4 > > [ 105.397912] R10: ea0020665000 R11: 88083e806e80 R12: > > > [ 105.397913] R13: 880819942400 R14: 880819940400 R15: > 88081b32e800 > > [ 105.397914] FS: 7f0374519f80() GS:88083ec0() > knlGS: > > [ 105.397914] CS: 0010 DS: ES: CR0: 80050033 > > [ 105.397915] CR2: 561ac61e0e10 CR3: 00081acc6000 CR4: > 003406b0 > > [ 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 wrote: > > Hi > > > > I'm happy to test this when I get home > > > > I'm currently reverting that patch t
Re: 4K@60 YCbCr420 missing mode in usermode
On 26 June 2018 at 17:23, Michel Dänzer wrote: > On 2018-06-26 05:43 PM, Emil Velikov wrote: >> Hi Jerry, >> >> On 25 June 2018 at 22:45, Zuo, Jerry wrote: >>> Hello all: >>> >>> >>> >>> We are working on an issue affecting 4K@60 HDMI display not to light up, but >>> only showing up 4K@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@60 supported. Such HDMI 4K@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@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@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@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@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. > Might have been too brief there. Here goes a more elaborate suggestion, please point out any misunderstandings. If we look into the drivers we'll see a call to xf86InterpretEDID(), followed by xf86OutputSetEDID(). The former doing a partial parsing of the edid, creating a xf86MonPtr (timings information et al.) with the latter attaching it to the output. Thus as we get into xf86ProbeOutputModes/xf86ValidateModesClocks the Xserver probes the mode against given timing/bandwidth constrains, discarding it where applicable. Considering that the DRM driver already does similar checks, X could side-step the parsing and filtering/validation all together. Trusting the kernel should be reasonable, considering weston (and I would imagine other wayland compositors) already do so. Obviously, manually added modelines (via a config file) would still need to be validated. Thanks Emil ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: 4K@60 YCbCr420 missing mode in usermode
With AMDGPU DDX I'm not seeing 4k@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: [#1] PREEMPT SMP NOPTI [ 105.397884] CPU: 0 PID: 334 Comm: Xorg Tainted: GW 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:c963b8f8 EFLAGS: 00010246 [ 105.397910] RAX: 880819942001 RBX: 88081b317000 RCX: [ 105.397911] RDX: 7690 RSI: 7690 RDI: 880819943800 [ 105.397911] RBP: 880805bd0a80 R08: 00022ac0 R09: 815bf6f4 [ 105.397912] R10: ea0020665000 R11: 88083e806e80 R12: [ 105.397913] R13: 880819942400 R14: 880819940400 R15: 88081b32e800 [ 105.397914] FS: 7f0374519f80() GS:88083ec0() knlGS: [ 105.397914] CS: 0010 DS: ES: CR0: 80050033 [ 105.397915] CR2: 561ac61e0e10 CR3: 00081acc6000 CR4: 003406b0 [ 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 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 wrote: > >> On 2018-06-26 05:43 PM, Emil Velikov wrote: >> > Hi Jerry, >> > >> > On 25 June 2018 at 22:45, Zuo, Jerry wrote: >> >> Hello all: >> >> >> >> >> >> >> >> We are working on an issue affecting 4K@60 HDMI display not to light >> up, but >> >> only showing up 4K@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@60 supported. Such HDMI 4K@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@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@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@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@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
Re: 4K@60 YCbCr420 missing mode in usermode
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 wrote: > On 2018-06-26 05:43 PM, Emil Velikov wrote: > > Hi Jerry, > > > > On 25 June 2018 at 22:45, Zuo, Jerry wrote: > >> Hello all: > >> > >> > >> > >> We are working on an issue affecting 4K@60 HDMI display not to light > up, but > >> only showing up 4K@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@60 supported. Such HDMI 4K@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@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@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@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@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@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: 4K@60 YCbCr420 missing mode in usermode
On 2018-06-26 05:43 PM, Emil Velikov wrote: > Hi Jerry, > > On 25 June 2018 at 22:45, Zuo, Jerry wrote: >> Hello all: >> >> >> >> We are working on an issue affecting 4K@60 HDMI display not to light up, but >> only showing up 4K@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@60 supported. Such HDMI 4K@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@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@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@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@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@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: 4K@60 YCbCr420 missing mode in usermode
Hi Jerry, On 25 June 2018 at 22:45, Zuo, Jerry wrote: > Hello all: > > > > We are working on an issue affecting 4K@60 HDMI display not to light up, but > only showing up 4K@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@60 supported. Such HDMI 4K@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@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@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@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@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. Doubt I'll have time to tackle this, so this is a brain dump for anyone interested in fixing this. HTH Emil ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
