dri-devel August 2021

dri-devel@lists.freedesktop.org

324 participants
762 discussions

[PATCH 0/1] Use platform specific defaults for GuC/HuC enabling
by Matthew Brost 08 Apr '22

08 Apr '22

Reviewed a long time ago, resending for CI + to dri-devel. John Harrison (1): drm/i915/uc: Use platform specific defaults for GuC/HuC enabling drivers/gpu/drm/i915/i915_params.c | 2 +- drivers/gpu/drm/i915/i915_params.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.28.0

4 5

[Bug 211807] New: [drm:drm_dp_mst_dpcd_read] *ERROR* mstb 000000004e6288dd port 3: DPCD read on addr 0x60 for 1 bytes NAKed
by bugzilla-daemon＠bugzilla.kernel.org 07 Apr '22

07 Apr '22

https://bugzilla.kernel.org/show_bug.cgi?id=211807 Bug ID: 211807 Summary: [drm:drm_dp_mst_dpcd_read] *ERROR* mstb 000000004e6288dd port 3: DPCD read on addr 0x60 for 1 bytes NAKed Product: Drivers Version: 2.5 Kernel Version: 5.10.16 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: low Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: kernelbugs(a)equaeghe.nospammail.net Regression: No In my logs, I see the following error: [drm:drm_dp_mst_dpcd_read] *ERROR* mstb 000000004e6288dd port 3: DPCD read on addr 0x60 for 1 bytes NAKed It has not caused any detected issues, but I guess that if the kernel complains this loudy, it is good to report it. This is on a laptop with a Ryzen Pro 4750U APU. I custom-build the kernel, so do not hesitate to request changing some config options to investigate. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

2 21

[PATCH] drm: sti: fix spelling mistake: rejec -> rejection
by Colin King 07 Apr '22

07 Apr '22

From: Colin Ian King <colin.king(a)canonical.com> In other places of the driver the string hdmi_rejection_pll is used instead of the truncated hdmi_rejec_pll, so use this string instead to be consistent. Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/gpu/drm/sti/sti_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c index 814560ead4e1..e2018e4a3ec5 100644 --- a/drivers/gpu/drm/sti/sti_hdmi.c +++ b/drivers/gpu/drm/sti/sti_hdmi.c @@ -886,7 +886,7 @@ static void sti_hdmi_pre_enable(struct drm_bridge *bridge) if (clk_prepare_enable(hdmi->clk_tmds)) DRM_ERROR("Failed to prepare/enable hdmi_tmds clk\n"); if (clk_prepare_enable(hdmi->clk_phy)) - DRM_ERROR("Failed to prepare/enable hdmi_rejec_pll clk\n"); + DRM_ERROR("Failed to prepare/enable hdmi_rejection_pll clk\n"); hdmi->enabled = true; -- 2.20.1

2 1

[Bug 214071] New: amdgpu idle power draw to high at +75Hz
by bugzilla-daemon＠bugzilla.kernel.org 31 Mar '22

31 Mar '22

https://bugzilla.kernel.org/show_bug.cgi?id=214071 Bug ID: 214071 Summary: amdgpu idle power draw to high at +75Hz Product: Drivers Version: 2.5 Kernel Version: 5.13.10 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: pb.g(a)gmx.de Regression: No For best viewing pleasure I usually set my monitor to 144Hz and native 1080p. At that refresh rate my RX6900XT draws about 35 Watts in idle situations Memory clock stays at 1000Hz. I have to lower the monitors refresh rate to 75Hz, then the card draws only 8 Watts in idle and memory clock goes significantly down to 96MHz. Using 100 or 120 Hz does not help. Situation in windows is different. The same hardware setup works in Windows10 at 1080p@144 with idle power draw of just 8 Watts. So my guess is this is a driver issue and not a hardware issue. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

2 4

[Bug 213983] New: WARNING: CPU: 3 PID: 520 at drivers/gpu/drm/ttm/ttm_bo.c:409 ttm_bo_release+0x7a/0x803 [ttm]
by bugzilla-daemon＠bugzilla.kernel.org 29 Mar '22

29 Mar '22

https://bugzilla.kernel.org/show_bug.cgi?id=213983 Bug ID: 213983 Summary: WARNING: CPU: 3 PID: 520 at drivers/gpu/drm/ttm/ttm_bo.c:409 ttm_bo_release+0x7a/0x803 [ttm] Product: Drivers Version: 2.5 Kernel Version: 5.14-rc4 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: erhard_f(a)mailbox.org Regression: No Created attachment 298221 --> https://bugzilla.kernel.org/attachment.cgi?id=298221&action=edit kernel dmesg (5.14-rc4, AMD A10-7860K) System was running fine for hours but got this at reboot: [...] [35939.202358] ------------[ cut here ]------------ [35939.202603] WARNING: CPU: 3 PID: 520 at drivers/gpu/drm/ttm/ttm_bo.c:409 ttm_bo_release+0x7a/0x803 [ttm] [35939.202870] Modules linked in: rfkill dm_crypt nhpoly1305_sse2 nhpoly1305 chacha_generic chacha_x86_64 libchacha adiantum libpoly1305 algif_skcipher input_leds joydev led_class dm_mod hid_generic usbhid hid raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx amdgpu md_mod evdev f2fs crc32_generic lz4hc_compress lz4_compress lz4_decompress edac_mce_amd crc32_pclmul ext4 crc16 mbcache jbd2 ohci_pci snd_hda_codec_hdmi drm_ttm_helper ttm aesni_intel snd_hda_intel mfd_core libaes crypto_simd cryptd gpu_sched snd_intel_dspcfg i2c_algo_bit k10temp snd_hda_codec fam15h_power i2c_piix4 snd_hwdep drm_kms_helper snd_hda_core ohci_hcd cfbfillrect ehci_pci xhci_pci xhci_hcd ehci_hcd syscopyarea cfbimgblt snd_pcm sysfillrect sysimgblt usbcore fb_sys_fops snd_timer cfbcopyarea usb_common snd soundcore video acpi_cpufreq processor button zram nct6775 zsmalloc hwmon_vid hwmon drm nfsd fb fuse font fbdev auth_rpcgss drm_panel_orientation_quirks backlight lockd grace configfs sunrpc [35939.203200] efivarfs [35939.205121] CPU: 3 PID: 520 Comm: X Not tainted 5.14.0-rc4-bdver3 #2 [35939.212327] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./A88M-G/3.1, BIOS P1.40C 11/21/2016 [35939.219364] RIP: 0010:ttm_bo_release+0x7a/0x803 [ttm] [35939.219387] Code: e0 2a 48 c1 ea 03 8a 14 02 48 8b 04 24 83 e0 07 83 c0 03 38 d0 7c 0d 84 d2 74 09 48 8b 3c 24 e8 99 eb 7c dd 83 7b 4c 00 74 02 <0f> 0b 48 8d 43 18 48 89 c2 48 89 44 24 10 b8 ff ff 37 00 48 c1 ea [35939.230367] RSP: 0018:ffffc900050dfb08 EFLAGS: 00010202 [35939.230376] RAX: 0000000000000007 RBX: ffff8881716441f0 RCX: ffff8881716441f0 [35939.230381] RDX: 1ffff1102e2c8800 RSI: 0000000000000004 RDI: ffff8881716441f0 [35939.230387] RBP: ffff8881716441d8 R08: 0000000000000001 R09: ffffed102e2c883f [35939.230391] R10: ffff8881716441f3 R11: ffffffffc0b6a201 R12: ffff888115000010 [35939.264555] R13: ffff888115005608 R14: ffff888171644058 R15: ffffffff9f5cf160 [35939.264564] FS: 00007fe7325f9980(0000) GS:ffff8883e0580000(0000) knlGS:0000000000000000 [35939.264572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [35939.264579] CR2: 00007fe73190d0e8 CR3: 0000000141978000 CR4: 00000000000506e0 [35939.264586] Call Trace: [35939.264591] ? fsnotify_grab_connector+0x8c/0x93 [35939.264608] amdgpu_bo_unref+0x30/0x57 [amdgpu] [35939.318763] amdgpu_gem_object_free+0x69/0x95 [amdgpu] [35939.319132] ? list_add+0xd1/0xd1 [amdgpu] [35939.319478] ? test_bit+0x1d/0x27 [35939.319489] drm_gem_dmabuf_release+0x5b/0x67 [drm] [35939.319551] dma_buf_release+0x113/0x1b6 [35939.319563] __dentry_kill+0x29e/0x302 [35939.319573] dput+0x184/0x1c3 [35939.319582] __fput+0x4dc/0x598 [35939.319590] task_work_run+0xfa/0x118 [35939.319599] do_exit+0x984/0x17ba [35939.319609] ? mm_update_next_owner+0x3fd/0x3fd [35939.319619] do_group_exit+0x229/0x229 [35939.319627] __x64_sys_exit_group+0x39/0x39 [35939.319635] do_syscall_64+0x75/0x88 [35939.319649] ? do_syscall_64+0xe/0x88 [35939.319658] entry_SYSCALL_64_after_hwframe+0x44/0xae [35939.319668] RIP: 0033:0x7fe731edd459 [35939.319676] Code: Unable to access opcode bytes at RIP 0x7fe731edd42f. [35939.319680] RSP: 002b:00007ffc8d3e1298 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [35939.319691] RAX: ffffffffffffffda RBX: 00007fe731fc6920 RCX: 00007fe731edd459 [35939.319698] RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 [35939.319704] RBP: 00007fe731fc6920 R08: fffffffffffffd40 R09: 00005630715eb7c0 [35939.319711] R10: 00007fe710db0a14 R11: 0000000000000246 R12: 0000000000000000 [35939.319716] R13: 0000000000000000 R14: 0000000000000668 R15: 0000000000000000 [35939.319724] ---[ end trace 0f92591c8b7a0f11 ]--- # inxi -bZ System: Kernel: 5.14.0-rc4-bdver3 x86_64 bits: 64 Desktop: MATE 1.24.1 Distro: Gentoo Base System release 2.7 Machine: Type: Desktop Mobo: ASRock model: A88M-G/3.1 serial: <superuser/root required> UEFI: American Megatrends v: P1.40C date: 11/21/2016 CPU: Info: Quad Core AMD A10-7860K Radeon R7 12 Compute Cores 4C+8G [MCP] speed: 1560 MHz min/max: 1400/3600 MHz Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Kaveri [Radeon R7 Graphics] driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.11 driver: amdgpu,ati unloaded: fbdev,modesetting resolution: 1920x1080~60Hz OpenGL: renderer: AMD KAVERI (DRM 3.42.0 5.14.0-rc4-bdver3 LLVM 12.0.1) v: 4.6 Mesa 21.1.4 Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 Drives: Local Storage: total: 9.33 TiB used: 4.13 TiB (44.3%) Info: Processes: 225 Uptime: 16m Memory: 13.32 GiB used: 1.38 GiB (10.3%) Shell: Bash inxi: 3.1.06 # lspci -s 00:01.0 -vv 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 Graphics] (rev d6) (prog-if 00 [VGA controller]) Subsystem: ASRock Incorporation Kaveri [Radeon R7 Graphics] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 62 IOMMU group: 0 Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at d0000000 (64-bit, prefetchable) [size=8M] Region 4: I/O ports at f000 [size=256] Region 5: Memory at feb00000 (32-bit, non-prefetchable) [size=256K] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [48] Vendor Specific Information: Len=08 <?> Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0 ExtTag+ RBE+ FLReset- DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- DevCap2: Completion Timeout: Not Supported, TimeoutDis- NROPrPrP- LTR- 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt+ EETLPPrefix+, MaxEETLPPrefixes 1 EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, AtomicOpsCtl: ReqEn- Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee04004 Data: 002a Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [270 v1] Secondary PCI Express LnkCtl3: LnkEquIntrruptEn- PerformEqu- LaneErrStat: 0 Capabilities: [2b0 v1] Address Translation Service (ATS) ATSCap: Invalidate Queue Depth: 00 ATSCtl: Enable+, Smallest Translation Unit: 00 Capabilities: [2c0 v1] Page Request Interface (PRI) PRICtl: Enable- Reset- PRISta: RF- UPRGI- Stopped+ Page Request Capacity: 00000020, Page Request Allocation: 00000000 Capabilities: [2d0 v1] Process Address Space ID (PASID) PASIDCap: Exec- Priv-, Max PASID Width: 10 PASIDCtl: Enable- Exec- Priv- Kernel driver in use: amdgpu Kernel modules: amdgpu -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

2 6

[PATCH v5 0/5] phy: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support
by Liu Ying 27 Mar '22

27 Mar '22

Hi, This series adds i.MX8qxp LVDS PHY mode support for the Mixel PHY in the Freescale i.MX8qxp SoC. The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in either MIPI DPHY mode or LVDS PHY mode. The PHY mode is controlled by i.MX8qxp SCU firmware. The PHY driver would call a SCU function to configure the mode. The PHY driver is already supporting the Mixel MIPI DPHY in i.MX8mq SoC, where it appears to be a single MIPI DPHY. Patch 1/5 sets PHY mode in the Northwest Logic MIPI DSI host controller bridge driver, since i.MX8qxp SoC embeds this controller IP to support MIPI DSI displays together with the Mixel PHY. Patch 2/5 allows LVDS PHYs to be configured through the generic PHY functions and through a custom structure added to the generic PHY configuration union. Patch 3/5 converts mixel,mipi-dsi-phy plain text dt binding to json-schema. Patch 4/5 adds dt binding support for the Mixel combo PHY in i.MX8qxp SoC. Patch 5/5 adds the i.MX8qxp LVDS PHY mode support in the Mixel PHY driver. Welcome comments, thanks. v4->v5: * Align kernel-doc style of include/linux/phy/phy-lvds.h to include/linux/phy/phy.h for patch 2/5. (Vinod) * Trivial tweaks on patch 2/5. * Drop Robert's R-b tag on patch 2/5. v3->v4: * Add all R-b tags received from v3 on relevant patches and respin. (Robert) v2->v3: * Improve readability of mixel_dphy_set_mode() in the Mixel PHY driver. (Guido) * Improve the 'clock-names' property in the PHY dt binding. v1->v2: * Convert mixel,mipi-dsi-phy plain text dt binding to json-schema. (Guido) * Print invalid PHY mode in dmesg from the Mixel PHY driver. (Guido) * Add Guido's R-b tag on the patch for the nwl-dsi drm bridge driver. Liu Ying (5): drm/bridge: nwl-dsi: Set PHY mode in nwl_dsi_enable() phy: Add LVDS configuration options dt-bindings: phy: Convert mixel,mipi-dsi-phy to json-schema dt-bindings: phy: mixel: mipi-dsi-phy: Add Mixel combo PHY support for i.MX8qxp phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support .../devicetree/bindings/phy/mixel,mipi-dsi-phy.txt | 29 --- .../bindings/phy/mixel,mipi-dsi-phy.yaml | 107 ++++++++ drivers/gpu/drm/bridge/nwl-dsi.c | 6 + drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 269 ++++++++++++++++++++- include/linux/phy/phy-lvds.h | 32 +++ include/linux/phy/phy.h | 4 + 6 files changed, 407 insertions(+), 40 deletions(-) delete mode 100644 Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt create mode 100644 Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml create mode 100644 include/linux/phy/phy-lvds.h -- 2.7.4

2 9

[PATCH 0/6] dma-buf: Add an API for exporting sync files (v12)
by Jason Ekstrand 22 Mar '22

22 Mar '22

Modern userspace APIs like Vulkan are built on an explicit synchronization model. This doesn't always play nicely with the implicit synchronization used in the kernel and assumed by X11 and Wayland. The client -> compositor half of the synchronization isn't too bad, at least on intel, because we can control whether or not i915 synchronizes on the buffer and whether or not it's considered written. The harder part is the compositor -> client synchronization when we get the buffer back from the compositor. We're required to be able to provide the client with a VkSemaphore and VkFence representing the point in time where the window system (compositor and/or display) finished using the buffer. With current APIs, it's very hard to do this in such a way that we don't get confused by the Vulkan driver's access of the buffer. In particular, once we tell the kernel that we're rendering to the buffer again, any CPU waits on the buffer or GPU dependencies will wait on some of the client rendering and not just the compositor. This new IOCTL solves this problem by allowing us to get a snapshot of the implicit synchronization state of a given dma-buf in the form of a sync file. It's effectively the same as a poll() or I915_GEM_WAIT only, instead of CPU waiting directly, it encapsulates the wait operation, at the current moment in time, in a sync_file so we can check/wait on it later. As long as the Vulkan driver does the sync_file export from the dma-buf before we re-introduce it for rendering, it will only contain fences from the compositor or display. This allows to accurately turn it into a VkFence or VkSemaphore without any over- synchronization. This patch series actually contains two new ioctls. There is the export one mentioned above as well as an RFC for an import ioctl which provides the other half. The intention is to land the export ioctl since it seems like there's no real disagreement on that one. The import ioctl, however, has a lot of debate around it so it's intended to be RFC-only for now. Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4037 IGT tests: https://patchwork.freedesktop.org/series/90490/ v10 (Jason Ekstrand, Daniel Vetter): - Add reviews/acks - Add a patch to rename _rcu to _unlocked - Split things better so import is clearly RFC status v11 (Daniel Vetter): - Add more CCs to try and get maintainers - Add a patch to document DMA_BUF_IOCTL_SYNC - Generally better docs - Use separate structs for import/export (easier to document) - Fix an issue in the import patch v12 (Daniel Vetter): - Better docs for DMA_BUF_IOCTL_SYNC v12 (Christian König): - Drop the rename patch in favor of Christian's series - Add a comment to the commit message for the dma-buf sync_file export ioctl saying why we made it an ioctl on dma-buf Cc: Christian König <christian.koenig(a)amd.com> Cc: Michel Dänzer <michel(a)daenzer.net> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> Cc: Daniel Stone <daniels(a)collabora.com> Cc: mesa-dev(a)lists.freedesktop.org Cc: wayland-devel(a)lists.freedesktop.org Test-with: 20210524205225.872316-1-jason(a)jlekstrand.net Christian König (1): dma-buf: Add dma_fence_array_for_each (v2) Jason Ekstrand (5): dma-buf: Add dma_resv_get_singleton (v6) dma-buf: Document DMA_BUF_IOCTL_SYNC (v2) dma-buf: Add an API for exporting sync files (v12) RFC: dma-buf: Add an extra fence to dma_resv_get_singleton_unlocked RFC: dma-buf: Add an API for importing sync files (v7) Documentation/driver-api/dma-buf.rst | 8 ++ drivers/dma-buf/dma-buf.c | 103 +++++++++++++++++++++++++ drivers/dma-buf/dma-fence-array.c | 27 +++++++ drivers/dma-buf/dma-resv.c | 110 +++++++++++++++++++++++++++ include/linux/dma-fence-array.h | 17 +++++ include/linux/dma-resv.h | 2 + include/uapi/linux/dma-buf.h | 103 ++++++++++++++++++++++++- 7 files changed, 369 insertions(+), 1 deletion(-) -- 2.31.1

8 31

[PATCH v3 0/5] drm: use dyndbg in drm_print
by Jim Cromie 05 Mar '22

05 Mar '22

hi dri-devel, Im pretty new in this particular playground. Im using this to send, is it too spammy ? too --to ? git send-email --dry-run \ --to-cmd='scripts/get_maintainer.pl --no-rolestats v3-000*.patch' \ --to=jbaron(a)akamai.com v3-000*.patch drm_debug_enabled() is called a lot (by drm_dev_dbg) to do unlikely bit-tests to selectively enable debug printing; this is a good job for dynamic-debug, IFF it is built with JUMP_LABEL. This patchset enables the use of dynamic-debug to avoid those drm_debug_enabled() overheads, if CONFIG_DRM_USE_DYNAMIC_DEBUG=y. v3: fixes missed SOB, && on BOL, commit-log tweaks reordered patches, 1 is comment, 2 is whitespace. dropped RFC, to see what happens. v2: https://lore.kernel.org/lkml/20210711055003.528167-1-jim.cromie@gmail.com/ v1: https://lore.kernel.org/lkml/20201204035318.332419-1-jim.cromie@gmail.com/ Doing so creates many new pr_debug callsites, otherwise i915 has ~120 prdbgs, and drm has just 1; bash-5.1# modprobe i915 dyndbg: 8 debug prints in module video dyndbg: 305 debug prints in module drm dyndbg: 207 debug prints in module drm_kms_helper dyndbg: 2 debug prints in module ttm dyndbg: 1720 debug prints in module i915 On amdgpu, enabling it adds ~3200 prdbgs, currently at 56 bytes each. So CONFIG_DRM_USE_DYNAMIC_DEBUG=y affects resource requirements. Im running this patchset bare-metal on an i915 laptop & an amdgpu desktop (both as loadable modules). I booted the amdgpu box with: BOOT_IMAGE=(hd2,gpt2)/vmlinuz-5.13.0-dd7-13692-g8def25788f56 \ root=UUID=mumble ro \ rootflags=subvol=root00 rhgb \ dynamic_debug.verbose=3 main.dyndbg=+p \ amdgpu.debug=1 amdgpu.test=1 \ "amdgpu.dyndbg=format ^[ +p" That last line enables ~1700 prdbg callsites with a format like '[DML' etc at boot, and amdgpu.test=1 triggers 3 minutes of tests, causing ~76k prdbgs in 409 seconds, before I turned them off with: echo module amdgpu -p > /proc/dynamic_debug/control This is on top of master @ v5.14-rc1 Should I rebase onto something else ? Jim Cromie (5): drm/print: fixup spelling in a comment drm_print.h: rewrap __DRM_DEFINE_DBG_RATELIMITED macro drm/print: RFC add choice to use dynamic debug in drm-debug drm/print: move conditional deref into macro defn i915: map gvt pr_debug categories to bits in parameters/debug_gvt Note: 3/5, 5/5 have bits that are here for POC, but belong in dynamic_debug.c. drivers/gpu/drm/Kconfig | 13 ++++ drivers/gpu/drm/drm_print.c | 75 +++++++++++++++++- drivers/gpu/drm/i915/gvt/Makefile | 4 + drivers/gpu/drm/i915/i915_params.c | 76 +++++++++++++++++++ include/drm/drm_print.h | 117 ++++++++++++++++++++--------- 5 files changed, 247 insertions(+), 38 deletions(-) -- 2.31.1

4 12

[RFC PATCH 00/11] drm/bridge: ti-sn65dsi86: Support DisplayPort mode
by Laurent Pinchart 04 Mar '22

04 Mar '22

Hello, Despite the SN65DSI86 being a DSI to eDP bridge, it can also operate in DisplayPort mode. This patch series adds support for this feature to the ti-sn65dsi86 driver. The series starts with miscellaneous fixes and improvements in patch 01/11 to 04/11. Patch 05/11 then moves to the panel-bridge helper, and is followed by patches 06/11 and 07/11 that refactor the code to prepare for the next steps. As my goal is to use the sn65dsi86 with the R-Car DU driver, which requires DRM_BRIDGE_ATTACH_NO_CONNECTOR support, the series continues with support for this feature. In patch 08/11 the bridge connector operations are added, and in 09/11 the connector creation is made optional. Patch 10/11 then implements supports for DisplayPort mode, enabled automatically when the next component in the pipeline isn't a panel. Finally, patch 11/11 adds hotplug detection support, which isn't very useful for eDP, but is needed for DisplayPort. This series is an RFC as I haven't been able to test it fully yet. The platform I'm working on is missing support for three other components in the display pipeline (I'm on it), which are required in order to run tests. I would however like to receive feedback on the approach already, in case problems would need to be solved. Laurent Pinchart (11): dt-bindings: drm/bridge: ti-sn65dsi8: Make enable GPIO optional drm/bridge: ti-sn65dsi86: Make enable GPIO optional drm/bridge: ti-sn65dsi86: Unregister AUX adapter in remove() drm/bridge: ti-sn65dsi86: Use bitmask to store valid rates drm/bridge: ti-sn65dsi86: Wrap panel with panel-bridge drm/bridge: ti-sn65dsi86: Group code in sections drm/bridge: ti-sn65dsi86: Split connector creation to a function drm/bridge: ti-sn65dsi86: Implement bridge connector operations drm/bridge: ti-sn65dsi86: Make connector creation optional drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode drm/bridge: ti-sn65dsi86: Support hotplug detection .../bindings/display/bridge/ti,sn65dsi86.yaml | 1 - drivers/gpu/drm/bridge/ti-sn65dsi86.c | 266 ++++++++++++------ 2 files changed, 183 insertions(+), 84 deletions(-) -- Regards, Laurent Pinchart

8 55

[PATCH v3 RESEND 00/24] drm/exynos: add support for GSCALER planes on Exynos5433
by Andrzej Hajda 03 Mar '22

03 Mar '22

Hi Inki, GSCALERs in Exynos SoCs support conversion between wide range of image formats, plus scaling and rotation. Driver already supports mem2mem mode - via ExynosDRM IPP framework. This patchset adds support for mem to display mode - framebuffers can be converted, scaled and send directly to Display Controller. From DRM framework's point of view every GSCALER exposes drm_plane which can be connected to display controller (display panel or TV). The feature is not well documented so the development was quite difficult - a process of trial and error, vendor code analysis, guessing from datasheets. Hopefully most of the issues were solved. I have developed and tested it on TM2 device with panel and TV paths. The patchset contains three parts: 1. Preparatory patches - mostly cleanup and refactoring of drm_crtc and drm_plane related structures, to allow usage of planes which are not physically bound to crtcs (01-13). 2. Adding local path support to GSCALER and DECON (14-20). 3. Few fixes of bugs existing already in the code but discovered due to added local path support (21-23). The patchset is based on exynos_drm_next plus my patchset adding zpos to DECON and FIMD - 'drm/exynos: add support for dynamic zpos in DECON and FIMD' - it is required to allow set z-pos position of GSCALER planes. To simplify tests I have also created branch containing all required patches: Repo: https://git.tizen.org/cgit/platform/kernel/linux-exynos Branch: sandbox/ahajda/dev/exynos-drm-local-path This is v2 version of the patchset. In this version I have moved code setting cursor plane in crtc to separate patch together with code disabling fast cursor updates - hardware does not support it. To keep bisectability DTS patches should be applied before subsequent ones. It is rebased on today's exynos-drm-next. Please be aware that DTS patches has been already applied to samsung-soc tree, I left them here to simplify testing on exynos-drm-next, which is not in sync with samsung-soc, for this reason I have moved them on the beginning of the patchset. Regards Andrzej Andrzej Hajda (24): arm64: dts: exynos: configure GSCALER related clocks arm64: dts: exynos: add DSD/GSD clocks to DECONs and GSCALERs drm/exynos: remove exynos_drm_plane.h header drm/exynos: remove spare macro drm/exynos: drop exynos_drm_plane_config structure drm/exynos: add exynos_drm_crtc_init function drm/exynos/decon5433: embed exynos_drm_crtc directly into context drm/exynos/decon7: embed exynos_drm_crtc directly into context drm/exynos/fimd: embed exynos_drm_crtc directly into context drm/exynos/mixer: embed exynos_drm_crtc directly into context drm/exynos/vidi: embed exynos_drm_crtc directly into context drm/exynos: remove standalone exynos_drm_crtc leftovers drm/exynos/vidi: remove encoder_to_vidi helper drm/exynos: unify plane type assignment drm/exynos: set primary plane in exynos_drm_crtc_init drm/exynos: set cursor plane in exynos_drm_crtc_init drm/exynos: add plane update/disable callbacks for planes drm/exynos: add GSCALER plane capability drm/exynos/gscaler: fix id assignement drm/exynos/gscaler: add local path support drm/exynos/decon5433: add local path support drm/exynos/decon5433: wait for finish previous update drm/exynos/gscaler: change supported color format BGRX8888 to XBGR8888 drm/exynos/gscaler: fix handling YVU420 pixel format .../dts/exynos/exynos5433-tm2-common.dtsi | 6 + arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 6 +- arch/arm64/boot/dts/exynos/exynos5433.dtsi | 25 +- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 162 ++++++++----- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 66 +++-- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 46 ++-- drivers/gpu/drm/exynos/exynos_drm_crtc.h | 7 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 - drivers/gpu/drm/exynos/exynos_drm_drv.h | 50 ++-- drivers/gpu/drm/exynos/exynos_drm_fb.c | 10 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 85 +++---- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 229 ++++++++++++++---- drivers/gpu/drm/exynos/exynos_drm_plane.c | 84 ++++--- drivers/gpu/drm/exynos/exynos_drm_plane.h | 14 -- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 48 ++-- drivers/gpu/drm/exynos/exynos_mixer.c | 95 +++----- drivers/gpu/drm/exynos/regs-decon5433.h | 6 + drivers/gpu/drm/exynos/regs-gsc.h | 6 + 18 files changed, 538 insertions(+), 408 deletions(-) delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_plane.h -- 2.17.1

5 35

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2021