dri-devel October 2019

dri-devel@lists.freedesktop.org

359 participants
1833 discussions

[Bug 8896] X error when using off-screen rendering with DRI enabled
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=8896 Martin Peres <martin.peres(a)free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Martin Peres <martin.peres(a)free.fr> --- Hi, Freedesktop's Bugzilla instance is EOLed and open bugs are about to be migrated to http://gitlab.freedesktop.org. To avoid migrating out of date bugs, I am now closing all the bugs that did not see any activity in the past year. If the issue is still happening, please create a new bug in the relevant project at https://gitlab.freedesktop.org/drm (use misc by default). Sorry about the noise! -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 110139] Driver throws exceptions when external display is connected over HDMI
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=110139 Bug ID: 110139 Summary: Driver throws exceptions when external display is connected over HDMI Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: General Assignee: dri-devel(a)lists.freedesktop.org Reporter: bastiborchers(a)gmx.net Created attachment 143690 --> https://bugs.freedesktop.org/attachment.cgi?id=143690&action=edit The complete output of dmesg Hello! Let me state right now that this is my first bug report and I am a little bit lost about what criteria I have to fulfill and whether I am reporting for the correct component. My system: I am using Arch Linux with the 5.0.1 Linux kernel. I have a Thinkpad P1 laptop with an Intel 8750H and an NVidia Quadro P1000. What happens: Before I turn on my laptop, I connected my external display via HDMI. Then I turn on my laptop and reach the bare tty (I am not using any Login Manager). While the tty is displayed, a lot of kernel messages are printed to the standard output about nouveau having some problems. As soon as I try to login (which starts my Window Manager, Sway), the system freezes and I have to hard reset my Laptop. Workaround: When I disconnect the HDMI cable before booting and connect it AFTER I logged into my system, then my external display works correctly. I dumped my whole dmesg output into the attached 'system.log' file, and I also retrieved the VBIOS information for my external display, I think. Let me know, if I can provide any further information and again, excuse any noob mistakes. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[PATCH v2 0/7] drm/meson: add AFBC support
by Neil Armstrong 14 Oct '19

14 Oct '19

This adds support for the ARM Framebuffer Compression decoders found in the Amlogic GXM and G12A SoCs. The Amlogic GXM and G12A AFBC decoder are totally different, the GXM only handling only the AFBC v1.0 modes and the G12A decoder handling the AFBC v1.2 modes. The G12A AFBC decoder is an external IP integrated in the video pipeline, and the GXM AFBC decoder seems to the an Amlogic custom decoder more tighly integrated in the video pipeline. The GXM AFBC decoder can handle only one AFBC plane for 2 available OSD planes available in HW, and the G12A AFBC decoder can handle up to 4 AFBC planes for up to 3 OSD planes available in HW. The Amlogic GXM supports 16x16 SPARSE and 16x16 SPLIT AFBC buffers up to 4k. On the other side, for G12A SPLIT is mandatory in 16x16 block mode, but for 4k modes 32x8+SPLIT AFBC buffers is manadatory for performances reasons. The Amlogic GXM and G12A AFBC decoders are integrated very differently. The Amlogic GXM has a direct output path to the OSD1 VIU pixel input, because the GXM AFBC decoder seem to be a custom IP developed by Amlogic. On the other side, the Amlogic G12A AFBC decoder seems to be an external IP that emit pixels on an AXI master hooked to a "Mali Unpack" block feeding the OSD1 VIU pixel input. This uses a weird "0x1000000" internal HW physical address on both sides to transfer the pixels. For Amlogic GXM, the supported pixel formats are the same as the normal linear OSD1 mode. On the other side, Amlogic added support for all AFBC v1.2 formats for the G12A AFBC integration. For testing, the only available AFBC buffer generation is the Android Yukawa Dvalin Android Mali blobs found at [1]. Both SoCs has been tested using buffers generated under AOSP, but only G12A was tested using a runtime stream of AFBC buffers, GXM was only tested using static buffers loaded from files. Changes since v1 at [2]: - Discards XRGB modes with YTR, only allow XBGR with YTR - Add non-YTR modifiers for G12A - Disable completely XRGB modes for GXM, until we find how to disable YTR - Add proper argb remap for XRGB modes - Enable OSD_STAT sync signal [1] https://android.googlesource.com/device/amlogic/yukawa/+/refs/heads/master/… [2] https://patchwork.freedesktop.org/series/67832/#rev1 Neil Armstrong (7): drm/meson: add AFBC decoder registers for GXM and G12A drm/meson: store the framebuffer width for plane commit drm/meson: Add AFBCD module driver drm/meson: plane: add support for AFBC mode for OSD1 plane drm/meson: viu: add AFBC modules routing functions drm/meson: hold 32 lines after vsync to give time for AFBC start drm/meson: crtc: add OSD1 plane AFBC commit drivers/gpu/drm/meson/Makefile | 1 + drivers/gpu/drm/meson/meson_crtc.c | 81 ++++- drivers/gpu/drm/meson/meson_drv.c | 38 ++- drivers/gpu/drm/meson/meson_drv.h | 17 ++ drivers/gpu/drm/meson/meson_osd_afbcd.c | 375 ++++++++++++++++++++++++ drivers/gpu/drm/meson/meson_osd_afbcd.h | 28 ++ drivers/gpu/drm/meson/meson_plane.c | 224 ++++++++++++-- drivers/gpu/drm/meson/meson_registers.h | 62 ++++ drivers/gpu/drm/meson/meson_viu.c | 78 ++++- drivers/gpu/drm/meson/meson_viu.h | 19 ++ 10 files changed, 880 insertions(+), 43 deletions(-) create mode 100644 drivers/gpu/drm/meson/meson_osd_afbcd.c create mode 100644 drivers/gpu/drm/meson/meson_osd_afbcd.h -- 2.22.0

1 7

[PATCH v7 0/9] drm: cec: convert DRM drivers to the new notifier API
by Dariusz Marcinkiewicz 14 Oct '19

14 Oct '19

This series updates DRM drivers to use new CEC notifier API. Changes since v6: Made CEC notifiers' registration and de-registration symmetric in tda998x and dw-hdmi drivers. Also, accidentally dropped one patch in v6 (change to drm_dp_cec), brought it back now. Changes since v5: Fixed a warning about a missing comment for a new member of drm_dp_aux_cec struct. Sending to a wider audience, including maintainers of respective drivers. Changes since v4: Addressing review comments. Changes since v3: Updated adapter flags in dw-hdmi-cec. Changes since v2: Include all DRM patches from "cec: improve notifier support, add connector info connector info" series. Changes since v1: Those patches delay creation of notifiers until respective connectors are constructed. It seems that those patches, for a couple of drivers, by adding the delay, introduce a race between notifiers' creation and the IRQs handling threads - at least I don't see anything obvious in there that would explicitly forbid such races to occur. v2 adds a write barrier to make sure IRQ threads see the notifier once it is created (replacing the WRITE_ONCE I put in v1). The best thing to do here, I believe, would be not to have any synchronization and make sure that an IRQ only gets enabled after the notifier is created. Dariusz Marcinkiewicz (9): drm_dp_cec: add connector info support. drm/i915/intel_hdmi: use cec_notifier_conn_(un)register dw-hdmi-cec: use cec_notifier_cec_adap_(un)register tda9950: use cec_notifier_cec_adap_(un)register drm: tda998x: use cec_notifier_conn_(un)register drm: sti: use cec_notifier_conn_(un)register drm: tegra: use cec_notifier_conn_(un)register drm: dw-hdmi: use cec_notifier_conn_(un)register drm: exynos: exynos_hdmi: use cec_notifier_conn_(un)register .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 13 +++--- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +++++++++++++------ drivers/gpu/drm/drm_dp_cec.c | 25 ++++++---- drivers/gpu/drm/exynos/exynos_hdmi.c | 31 +++++++------ drivers/gpu/drm/i2c/tda9950.c | 12 ++--- drivers/gpu/drm/i2c/tda998x_drv.c | 36 ++++++++++----- drivers/gpu/drm/i915/display/intel_dp.c | 4 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 13 ++++-- drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +- drivers/gpu/drm/sti/sti_hdmi.c | 19 +++++--- drivers/gpu/drm/tegra/output.c | 28 ++++++++--- include/drm/drm_dp_helper.h | 17 ++++--- 13 files changed, 155 insertions(+), 94 deletions(-) -- 2.23.0.rc1.153.gdeed80330f-goog

10 52

[PATCH 00/11] of: Fix DMA configuration for non-DT masters
by Nicolas Saenz Julienne 14 Oct '19

14 Oct '19

Hi All, this series tries to address one of the issues blocking us from upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that devices not represented in DT which sit behind a PCI bus fail to get the bus' DMA addressing constraints. This is due to the fact that of_dma_configure() assumes it's receiving a DT node representing the device being configured, as opposed to the PCIe bridge node we currently pass. This causes the code to directly jump into PCI's parent node when checking for 'dma-ranges' and misses whatever was set there. To address this I create a new API in OF - inspired from Robin Murphys original proposal[2] - which accepts a bus DT node as it's input in order to configure a device's DMA constraints. The changes go deep into of/address.c's implementation, as a device being having a DT node assumption was pretty strong. On top of this work, I also cleaned up of_dma_configure() removing its redundant arguments and creating an alternative function for the special cases not applicable to either the above case or the default usage. IMO the resulting functions are more explicit. They will probably surface some hacky usages that can be properly fixed as I show with the DT fixes on the Layerscape platform. This was also tested on a Raspberry Pi 4 with a custom PCIe driver and on a Seattle AMD board. Regards, Nicolas [1] https://patchwork.kernel.org/patch/9650345/#20294961 [2] https://patchwork.kernel.org/patch/9650345/ --- Nicolas Saenz Julienne (11): of: address: clean-up unused variable in of_dma_get_range() of: base: introduce __of_n_*_cells_parent() of: address: use parent DT node in bus->count_cells() of: address: introduce of_translate_dma_address_parent() of: expose __of_get_dma_parent() to OF subsystem of: address: use parent OF node in of_dma_get_range() dts: arm64: layerscape: add dma-ranges property to qoric-mc node dts: arm64: layerscape: add dma-ranges property to pcie nodes of: device: remove comment in of_dma_configure() of: device: introduce of_dma_configure_parent() of: simplify of_dma_config()'s arguments .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 1 + .../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 5 + .../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 1 + drivers/base/platform.c | 2 +- drivers/bcma/main.c | 2 +- drivers/bus/fsl-mc/fsl-mc-bus.c | 2 +- drivers/dma/qcom/hidma_mgmt.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +- drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +- drivers/gpu/drm/xen/xen_drm_front.c | 2 +- drivers/gpu/host1x/bus.c | 4 +- drivers/media/platform/qcom/venus/firmware.c | 2 +- drivers/media/platform/s5p-mfc/s5p_mfc.c | 2 +- drivers/of/address.c | 136 +++++++++--------- drivers/of/base.c | 69 +++++++-- drivers/of/device.c | 59 +++++++- drivers/of/of_private.h | 5 + drivers/pci/pci-driver.c | 3 +- drivers/xen/gntdev.c | 2 +- include/linux/of_address.h | 8 +- include/linux/of_device.h | 23 ++- 22 files changed, 223 insertions(+), 113 deletions(-) -- 2.23.0

5 26

[PATCH v2 0/4] drm/komeda: Enable CRTC color-mgmt
by james qian wang (Arm Technology China) 14 Oct '19

14 Oct '19

This series enable CRTC color-mgmt for komeda driver, for current komeda HW which only supports color conversion and forward gamma for CRTC. This series actually are regrouped from: - drm/komeda: Enable layer/plane color-mgmt: https://patchwork.freedesktop.org/series/60893/ - drm/komeda: Enable CRTC color-mgmt https://patchwork.freedesktop.org/series/61370/ For removing the dependence on: - https://patchwork.freedesktop.org/series/30876/ Lowry Li (Arm Technology China) (1): drm/komeda: Adds gamma and color-transform support for DOU-IPS james qian wang (Arm Technology China) (3): drm/komeda: Add a new helper drm_color_ctm_s31_32_to_qm_n() drm/komeda: Add drm_lut_to_fgamma_coeffs() drm/komeda: Add drm_ctm_to_coeffs() v2: Move the fixpoint conversion function s31_32_to_q2_12() to drm core as a shared helper. .../arm/display/komeda/d71/d71_component.c | 24 +++++++ .../arm/display/komeda/komeda_color_mgmt.c | 66 +++++++++++++++++++ .../arm/display/komeda/komeda_color_mgmt.h | 10 ++- .../gpu/drm/arm/display/komeda/komeda_crtc.c | 2 + .../drm/arm/display/komeda/komeda_pipeline.h | 3 + .../display/komeda/komeda_pipeline_state.c | 6 ++ drivers/gpu/drm/drm_color_mgmt.c | 23 +++++++ include/drm/drm_color_mgmt.h | 2 + 8 files changed, 135 insertions(+), 1 deletion(-) -- 2.20.1

3 12

WARNING in vkms_gem_free_object
by syzbot 14 Oct '19

14 Oct '19

Hello, syzbot found the following crash on: HEAD commit: 8ada228a Add linux-next specific files for 20191011 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=14c30b1b600000 kernel config: https://syzkaller.appspot.com/x/.config?x=7cf4eed5fe42c31a dashboard link: https://syzkaller.appspot.com/bug?extid=e7ad70d406e74d8fc9d0 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1087d31b600000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15e27c53600000 The bug was bisected to: commit 94e2ec3f7fef86506293a448273b2b4ee21e6195 Author: Oleg Vasilev <omrigann(a)gmail.com> Date: Mon Sep 30 15:59:24 2019 +0000 drm/vkms: prime import support bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15ef2d57600000 final crash: https://syzkaller.appspot.com/x/report.txt?x=17ef2d57600000 console output: https://syzkaller.appspot.com/x/log.txt?x=13ef2d57600000 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+e7ad70d406e74d8fc9d0(a)syzkaller.appspotmail.com Fixes: 94e2ec3f7fef ("drm/vkms: prime import support") ------------[ cut here ]------------ WARNING: CPU: 1 PID: 9040 at drivers/gpu/drm/vkms/vkms_gem.c:37 vkms_gem_free_object+0x92/0xb0 drivers/gpu/drm/vkms/vkms_gem.c:37 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 9040 Comm: syz-executor028 Not tainted 5.4.0-rc2-next-20191011 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 panic+0x2e3/0x75c kernel/panic.c:221 __warn.cold+0x2f/0x35 kernel/panic.c:582 report_bug+0x289/0x300 lib/bug.c:195 fixup_bug arch/x86/kernel/traps.c:174 [inline] fixup_bug arch/x86/kernel/traps.c:169 [inline] do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:267 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:286 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1028 RIP: 0010:vkms_gem_free_object+0x92/0xb0 drivers/gpu/drm/vkms/vkms_gem.c:37 Code: 44 68 7f fd 49 8d bc 24 f8 01 00 00 e8 c7 8d 64 fd 4c 89 e7 e8 3f 39 ae ff 4c 89 e7 e8 f7 9a ba fd 41 5c 5d c3 e8 1e 68 7f fd <0f> 0b eb a2 e8 15 68 7f fd 0f 0b eb c8 e8 2c e7 ba fd eb b6 e8 25 RSP: 0018:ffff8880971df9e8 EFLAGS: 00010293 RAX: ffff8880989c2200 RBX: ffffffff894e5000 RCX: ffffffff83a1eda6 RDX: 0000000000000000 RSI: ffffffff83f3ab02 RDI: ffff8880a8c4fa78 RBP: ffff8880971df9f0 R08: ffff8880989c2200 R09: ffffed1012e3bf36 R10: ffffed1012e3bf35 R11: 0000000000000003 R12: ffff8880a8c4f800 R13: ffff8880a3ab8000 R14: ffffffff83f3aa70 R15: ffff8880a3ab8020 drm_gem_object_free+0x100/0x220 drivers/gpu/drm/drm_gem.c:983 kref_put include/linux/kref.h:65 [inline] drm_gem_object_put_unlocked drivers/gpu/drm/drm_gem.c:1017 [inline] drm_gem_object_put_unlocked+0x127/0x170 drivers/gpu/drm/drm_gem.c:1002 drm_gem_object_handle_put_unlocked+0x1ad/0x2d0 drivers/gpu/drm/drm_gem.c:239 drm_gem_object_release_handle+0x102/0x1c0 drivers/gpu/drm/drm_gem.c:261 idr_for_each+0x138/0x250 lib/idr.c:208 drm_gem_release+0x27/0x40 drivers/gpu/drm/drm_gem.c:939 drm_file_free.part.0+0x7f4/0xc00 drivers/gpu/drm/drm_file.c:244 drm_file_free drivers/gpu/drm/drm_file.c:213 [inline] drm_close_helper drivers/gpu/drm/drm_file.c:271 [inline] drm_release+0x286/0x3f0 drivers/gpu/drm/drm_file.c:443 __fput+0x2ff/0x890 fs/file_table.c:280 ____fput+0x16/0x20 fs/file_table.c:313 task_work_run+0x145/0x1c0 kernel/task_work.c:113 exit_task_work include/linux/task_work.h:22 [inline] do_exit+0x904/0x2e60 kernel/exit.c:817 do_group_exit+0x135/0x360 kernel/exit.c:921 __do_sys_exit_group kernel/exit.c:932 [inline] __se_sys_exit_group kernel/exit.c:930 [inline] __x64_sys_exit_group+0x44/0x50 kernel/exit.c:930 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x442bb8 Code: Bad RIP value. RSP: 002b:00007ffd8fdc0b98 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000442bb8 RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 RBP: 00000000004c24c8 R08: 00000000000000e7 R09: ffffffffffffffd0 R10: 00000000004002e0 R11: 0000000000000246 R12: 0000000000000001 R13: 00000000006d41a0 R14: 0000000000000000 R15: 0000000000000000 Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. For information about bisection process see: https://goo.gl/tpsmEJ#bisection syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches

3 2

[PATCH] drm/drm_edid: correct VIC and HDMI_VIC under HDMI 2.0
by Wayne Lin 14 Oct '19

14 Oct '19

In HDMI 1.4 defines 4k modes without specific aspect ratio. However, in HDMI 2.0, adds aspect ratio attribute to distinguish different 4k modes. According to Appendix E of HDMI 2.0 spec, source should use VSIF to indicate VIC mode only when the mode is one defined in HDMI 1.4b 4K modes. Otherwise, use AVI infoframes to convey VIC. eg: VIC_103 should use AVI infoframes and VIC_93 use VSIF When the sink is HDMI 2.0, current code in drm_hdmi_avi_infoframe_from_display_mode will also force mode VIC_103 to have VIC value 0. This violates the spec and needs to be corrected. The same situation occurs in drm_hdmi_vendor_infoframe_from_display_mode and should set HDMI_VIC when the mode is one defined in HDMI 1.4b 4K modes. --- drivers/gpu/drm/drm_edid.c | 95 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 92 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 649cfd8b4200..0fea9bf4ec67 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1306,6 +1306,37 @@ static const struct drm_display_mode edid_4k_modes[] = { .vrefresh = 24, }, }; +/* + * 4k modes of HDMI 1.4 defined in HDMI 2.0. Index using the VIC. + */ +static const struct drm_display_mode hdmi_1_4_edid_4k_modes[] = { + /* 0 - dummy, VICs start at 1 */ + { }, + /* 1 - 3840x2160@30Hz */ + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, + 3840, 4016, 4104, 4400, 0, + 2160, 2168, 2178, 2250, 0, + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC), + .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, }, + /* 2 - 3840x2160@25Hz */ + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, + 3840, 4896, 4984, 5280, 0, + 2160, 2168, 2178, 2250, 0, + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC), + .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, }, + /* 3 - 3840x2160@24Hz */ + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, + 3840, 5116, 5204, 5500, 0, + 2160, 2168, 2178, 2250, 0, + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC), + .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, }, + /* 4 - 4096x2160@24Hz (SMPTE) */ + { DRM_MODE("4096x2160", DRM_MODE_TYPE_DRIVER, 297000, + 4096, 5116, 5204, 5500, 0, + 2160, 2168, 2178, 2250, 0, + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC), + .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_256_135, }, +}; /*** DDC fetch and block validation ***/ static const u8 edid_header[] = { @@ -3061,6 +3092,19 @@ hdmi_mode_alternate_clock(const struct drm_display_mode *hdmi_mode) return cea_mode_alternate_clock(hdmi_mode); } +/* + * Calculate the alternate clock for HDMI modes (those from the HDMI vendor + * specific block). + * + * It's almost like hdmi_mode_alternate_clock(), but no exception for VIC 4 mode. + * There is an alternate clock (23.98Hz) of VIC 4 mode (4096x2160@24Hz) in HDMI 2.0 + */ +static unsigned int +hdmi_1_4_mode_alternate_clock(const struct drm_display_mode *hdmi_mode) +{ + return cea_mode_alternate_clock(hdmi_mode); +} + static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_match, unsigned int clock_tolerance) { @@ -3121,11 +3165,53 @@ static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match) return 0; } +/* + * drm_match_hdmi_1_4_mode - look for a HDMI 1.4 mode matching given mode + * @to_match: display mode + * + * An HDMI mode is one defined in the HDMI vendor specific block. + * In HDMI 2.0, only few 4k resolutions with specific aspect ratio should + * utilize H14b VSIF. + * + * Returns the HDMI Video ID (VIC) of the mode or 0 if it isn't one. + */ +static u8 drm_match_hdmi_1_4_mode(const struct drm_display_mode *to_match) +{ + unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | DRM_MODE_MATCH_FLAGS; + u8 vic; + + if (!to_match->clock) + return 0; + + if (to_match->picture_aspect_ratio) + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO; + + for (vic = 1; vic < ARRAY_SIZE(hdmi_1_4_edid_4k_modes); vic++) { + const struct drm_display_mode *hdmi_1_4_mode = &hdmi_1_4_edid_4k_modes[vic]; + unsigned int clock1, clock2; + + /* Make sure to also match alternate clocks */ + clock1 = hdmi_1_4_mode->clock; + clock2 = hdmi_1_4_mode_alternate_clock(hdmi_1_4_mode); + + if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) || + KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) && + drm_mode_match(to_match, hdmi_1_4_mode, match_flags)) + return vic; + } + return 0; +} + static bool drm_valid_hdmi_vic(u8 vic) { return vic > 0 && vic < ARRAY_SIZE(edid_4k_modes); } +static bool drm_valid_hdmi_1_4_vic(u8 vic) +{ + return vic > 0 && vic < ARRAY_SIZE(hdmi_1_4_edid_4k_modes); +} + static int add_alternate_cea_modes(struct drm_connector *connector, struct edid *edid) { @@ -4894,10 +4980,12 @@ drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame, * HDMI 1.4b 4K modes */ if (frame->video_code) { - u8 vendor_if_vic = drm_match_hdmi_mode(mode); + u8 vendor_if_vic = is_hdmi2_sink(connector) ? + drm_match_hdmi_1_4_mode(mode) : drm_match_hdmi_mode(mode); bool is_s3d = mode->flags & DRM_MODE_FLAG_3D_MASK; - if (drm_valid_hdmi_vic(vendor_if_vic) && !is_s3d) + if (!is_s3d && is_hdmi2_sink(connector) ? + drm_valid_hdmi_1_4_vic(vendor_if_vic) : drm_valid_hdmi_vic(vendor_if_vic)) frame->video_code = 0; } @@ -5125,7 +5213,8 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe *frame, if (!has_hdmi_infoframe) return -EINVAL; - vic = drm_match_hdmi_mode(mode); + vic = is_hdmi2_sink(connector) ? + drm_match_hdmi_1_4_mode(mode) : drm_match_hdmi_mode(mode); s3d_flags = mode->flags & DRM_MODE_FLAG_3D_MASK; /* -- 2.17.1

3 6

[PATCH 1/3] dma-buf: add dma_resv_ctx for deadlock handling
by Christian König 14 Oct '19

14 Oct '19

The ww_mutex framework allows for detecting deadlocks when multiple threads try to acquire the same set of locks in different order. The problem is that handling those deadlocks was the burden of the user of the ww_mutex implementation and at least some users didn't got that right on the first try. So introduce a new dma_resv_ctx object which can be used to simplify the deadlock handling. This is done by tracking all locked dma_resv objects in the context as well as the last contended object. When a deadlock occurse we now unlock all previously locked objects and acquire the contended lock in the slow path. After this is done -EDEADLK is still returned to signal that all other locks now need to be re-acquired again. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/Makefile | 2 +- drivers/dma-buf/dma-resv-ctx.c | 108 +++++++++++++++++++++++++++++++++ include/linux/dma-resv-ctx.h | 68 +++++++++++++++++++++ include/linux/dma-resv.h | 1 + 4 files changed, 178 insertions(+), 1 deletion(-) create mode 100644 drivers/dma-buf/dma-resv-ctx.c create mode 100644 include/linux/dma-resv-ctx.h diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile index 03479da06422..da7701c85de2 100644 --- a/drivers/dma-buf/Makefile +++ b/drivers/dma-buf/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0-only obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \ - dma-resv.o seqno-fence.o + dma-resv.o dma-resv-ctx.o seqno-fence.o obj-$(CONFIG_SYNC_FILE) += sync_file.o obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o obj-$(CONFIG_UDMABUF) += udmabuf.o diff --git a/drivers/dma-buf/dma-resv-ctx.c b/drivers/dma-buf/dma-resv-ctx.c new file mode 100644 index 000000000000..cad10fa6f80b --- /dev/null +++ b/drivers/dma-buf/dma-resv-ctx.c @@ -0,0 +1,108 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright 2019 Advanced Micro Devices, Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + * + * Authors: + * Christian König <christian.koenig(a)amd.com> + */ + +#include <linux/dma-resv-ctx.h> + +/** + * dma_resv_ctx_init - initialize a reservation context + * @ctx: the context to initialize + * + * Start using this reservation context to lock reservation objects for update. + */ +void dma_resv_ctx_init(struct dma_resv_ctx *ctx) +{ + ww_acquire_init(&ctx->base, &reservation_ww_class); + init_llist_head(&ctx->locked); + ctx->contended = NULL; +} +EXPORT_SYMBOL(dma_resv_ctx_init); + +/** + * dma_resv_ctx_unlock_all - unlock all reservation objects + * @ctx: the context which holds the reservation objects + * + * Unlocks all reservation objects locked with this context. + */ +void dma_resv_ctx_unlock_all(struct dma_resv_ctx *ctx) +{ + struct dma_resv *obj, *next; + + if (ctx->contended) + dma_resv_unlock(ctx->contended); + ctx->contended = NULL; + + llist_for_each_entry_safe(obj, next, ctx->locked.first, locked) + ww_mutex_unlock(&obj->lock); + init_llist_head(&ctx->locked); +} +EXPORT_SYMBOL(dma_resv_ctx_unlock_all); + +/** + * dma_resv_ctx_lock - lock a reservation object with deadlock handling + * @ctx: the context which should be used to lock the object + * @obj: the object which needs to be locked + * @interruptible: if we should wait interruptible + * + * Use @ctx to lock the reservation object. If a deadlock is detected we backoff + * by releasing all locked objects and use the slow path to lock the reservation + * object. After successfully locking in the slow path -EDEADLK is returned to + * signal that all other locks must be re-taken as well. + */ +int dma_resv_ctx_lock(struct dma_resv_ctx *ctx, struct dma_resv *obj, + bool interruptible) +{ + int ret = 0; + + if (unlikely(ctx->contended == obj)) + ctx->contended = NULL; + else if (interruptible) + ret = dma_resv_lock_interruptible(obj, &ctx->base); + else + ret = dma_resv_lock(obj, &ctx->base); + + if (likely(!ret)) { + /* don't use llist_add here, we have separate locking */ + obj->locked.next = ctx->locked.first; + ctx->locked.first = &obj->locked; + return 0; + } + if (unlikely(ret != -EDEADLK)) + return ret; + + dma_resv_ctx_unlock_all(ctx); + + if (interruptible) { + ret = dma_resv_lock_slow_interruptible(obj, &ctx->base); + if (unlikely(ret)) + return ret; + } else { + dma_resv_lock_slow(obj, &ctx->base); + } + + ctx->contended = obj; + return -EDEADLK; +} +EXPORT_SYMBOL(dma_resv_ctx_lock); diff --git a/include/linux/dma-resv-ctx.h b/include/linux/dma-resv-ctx.h new file mode 100644 index 000000000000..86473de65167 --- /dev/null +++ b/include/linux/dma-resv-ctx.h @@ -0,0 +1,68 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright 2019 Advanced Micro Devices, Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + * + * Authors: + * Christian König <christian.koenig(a)amd.com> + */ + +#ifndef _LINUX_DMA_RESV_CTX_H +#define _LINUX_DMA_RESV_CTX_H + +#include <linux/llist.h> +#include <linux/dma-resv.h> + +/** + * struct dma_resv_ctx - context to lock reservation objects + * @base: ww_acquire_ctx used for deadlock detection + * @locked: list of dma_resv objects locked in this context + * @contended: contended dma_resv object + */ +struct dma_resv_ctx { + struct ww_acquire_ctx base; + struct llist_head locked; + struct dma_resv *contended; +}; + +/** + * dma_resv_ctx_done - wrapper for ww_acquire_done + * @ctx: the reservation context which is done with locking + */ +static inline void dma_resv_ctx_done(struct dma_resv_ctx *ctx) +{ + ww_acquire_done(&ctx->base); +} + +/** + * dma_resv_ctx_fini - wrapper for ww_acquire_fini + * @ctx: the reservation context which is finished + */ +static inline void dma_resv_ctx_fini(struct dma_resv_ctx *ctx) +{ + ww_acquire_fini(&ctx->base); +} + +void dma_resv_ctx_init(struct dma_resv_ctx *ctx); +void dma_resv_ctx_unlock_all(struct dma_resv_ctx *ctx); +int dma_resv_ctx_lock(struct dma_resv_ctx *ctx, struct dma_resv *obj, + bool interruptible); + +#endif /* _LINUX_DMA_RESV_CTX_H */ diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h index ee50d10f052b..1267822c2669 100644 --- a/include/linux/dma-resv.h +++ b/include/linux/dma-resv.h @@ -71,6 +71,7 @@ struct dma_resv_list { */ struct dma_resv { struct ww_mutex lock; + struct llist_node locked; seqcount_t seq; struct dma_fence __rcu *fence_excl; -- 2.17.1

3 6

[PATCH 0/6] drm/amdgpu: Fix incorrect encoder API usages
by Lyude Paul 14 Oct '19

14 Oct '19

Noticed this while trying to respin my MST suspend/resume patch series. It's not technically possible (at least until someone moves amdgpu away from the deprecated drm_device->driver->{load,unload} hooks) for amdgpu to properly register all of it's encoders before registering with userspace. However, amdgpu also apparently adds and removes encoders along with MST connectors - which is a much bigger issue as userspace applications definitely do not expect this type of behavior. So, let's fix it and add some WARNs() so new drivers don't accidentally make this mistake in the future. Lyude Paul (6): drm/amdgpu/dm/mst: Don't create MST topology managers for eDP ports drm/amdgpu/dm/mst: Remove unnecessary NULL check drm/amdgpu/dm/mst: Use ->atomic_best_encoder drm/amdgpu/dm/mst: Make MST encoders per-CRTC and fix encoder usage drm/amdgpu/dm/mst: Report possible_crtcs incorrectly, for now drm/encoder: WARN() when adding/removing encoders after device registration drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 3 ++ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 ++++++ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 - .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 46 ++++++++++--------- .../display/amdgpu_dm/amdgpu_dm_mst_types.h | 3 ++ drivers/gpu/drm/drm_encoder.c | 31 ++++++++++--- 6 files changed, 70 insertions(+), 29 deletions(-) -- 2.21.0

5 16

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2019