dri-devel January 2022

dri-devel@lists.freedesktop.org

373 participants
842 discussions

[Bug 212499] New: nouveau locking issue - WARNING: possible circular locking dependency detected
by bugzilla-daemon＠bugzilla.kernel.org 18 Apr '22

18 Apr '22

https://bugzilla.kernel.org/show_bug.cgi?id=212499 Bug ID: 212499 Summary: nouveau locking issue - WARNING: possible circular locking dependency detected Product: Drivers Version: 2.5 Kernel Version: 5.12-rc5 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: erhard_f(a)mailbox.org CC: dri-devel(a)lists.freedesktop.org Regression: No Created attachment 296155 --> https://bugzilla.kernel.org/attachment.cgi?id=296155&action=edit dmesg (kernel 5.12-rc5, A10-9700E) [...] ====================================================== WARNING: possible circular locking dependency detected 5.12.0-rc5-Excavator #4 Not tainted ------------------------------------------------------ X/593 is trying to acquire lock: ffff95f9110ec518 (&cli->mutex){+.+.}-{3:3}, at: nouveau_bo_move+0x167/0x990 [nouveau] but task is already holding lock: ffff95f8e70281a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: nouveau_bo_pin+0x3b/0x3c0 [nouveau] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (reservation_ww_class_mutex){+.+.}-{3:3}: __ww_mutex_lock.constprop.0+0x99/0xf20 nouveau_bo_pin+0x3b/0x3c0 [nouveau] nouveau_channel_prep+0x126/0x2f0 [nouveau] nouveau_channel_new+0x5d/0x6b0 [nouveau] nouveau_abi16_ioctl_channel_alloc+0x10d/0x3a0 [nouveau] drm_ioctl_kernel+0xa8/0xf0 [drm] drm_ioctl+0x20a/0x3a0 [drm] nouveau_drm_ioctl+0x50/0xa0 [nouveau] __x64_sys_ioctl+0x81/0xa0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #0 (&cli->mutex){+.+.}-{3:3}: __lock_acquire+0x1480/0x2610 lock_acquire+0xc4/0x390 __mutex_lock+0x78/0x870 nouveau_bo_move+0x167/0x990 [nouveau] ttm_bo_handle_move_mem+0x8b/0x170 [ttm] ttm_bo_validate+0x193/0x1f0 [ttm] nouveau_bo_pin+0x177/0x3c0 [nouveau] nv50_wndw_prepare_fb+0x5a/0x4c0 [nouveau] drm_atomic_helper_prepare_planes+0x85/0x110 [drm_kms_helper] nv50_disp_atomic_commit+0xa6/0x1d0 [nouveau] drm_atomic_helper_update_plane+0xe4/0x140 [drm_kms_helper] drm_mode_cursor_universal+0x126/0x230 [drm] drm_mode_cursor_common+0xfc/0x230 [drm] drm_mode_cursor_ioctl+0x46/0x60 [drm] drm_ioctl_kernel+0xa8/0xf0 [drm] drm_ioctl+0x20a/0x3a0 [drm] nouveau_drm_ioctl+0x50/0xa0 [nouveau] __x64_sys_ioctl+0x81/0xa0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(reservation_ww_class_mutex); lock(&cli->mutex); lock(reservation_ww_class_mutex); lock(&cli->mutex); *** DEADLOCK *** 3 locks held by X/593: #0: ffffaae9888e7ce0 (crtc_ww_class_acquire){+.+.}-{0:0}, at: drm_mode_cursor_common+0xbb/0x230 [drm] #1: ffff95f9113b0098 (crtc_ww_class_mutex){+.+.}-{3:3}, at: modeset_lock+0x5f/0x1c0 [drm] #2: ffff95f8e70281a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: nouveau_bo_pin+0x3b/0x3c0 [nouveau] stack backtrace: CPU: 3 PID: 593 Comm: X Not tainted 5.12.0-rc5-Excavator #4 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./A320M-HDV R3.0, BIOS P3.10 06/26/2019 Call Trace: dump_stack+0x7f/0xad check_noncircular+0x104/0x120 ? nvkm_uvmm_mthd+0x778/0x7b0 [nouveau] __lock_acquire+0x1480/0x2610 lock_acquire+0xc4/0x390 ? nouveau_bo_move+0x167/0x990 [nouveau] ? nvif_object_mthd+0x112/0x130 [nouveau] __mutex_lock+0x78/0x870 ? nouveau_bo_move+0x167/0x990 [nouveau] ? nouveau_bo_move+0x167/0x990 [nouveau] nouveau_bo_move+0x167/0x990 [nouveau] ? unmap_mapping_pages+0x59/0x120 ttm_bo_handle_move_mem+0x8b/0x170 [ttm] ttm_bo_validate+0x193/0x1f0 [ttm] ? nouveau_bo_sync_for_device+0x9b/0xe0 [nouveau] nouveau_bo_pin+0x177/0x3c0 [nouveau] nv50_wndw_prepare_fb+0x5a/0x4c0 [nouveau] ? _raw_spin_unlock_irqrestore+0x42/0x50 drm_atomic_helper_prepare_planes+0x85/0x110 [drm_kms_helper] ? lockdep_init_map_type+0x47/0x220 nv50_disp_atomic_commit+0xa6/0x1d0 [nouveau] drm_atomic_helper_update_plane+0xe4/0x140 [drm_kms_helper] drm_mode_cursor_universal+0x126/0x230 [drm] drm_mode_cursor_common+0xfc/0x230 [drm] ? drm_mode_setplane+0x1a0/0x1a0 [drm] drm_mode_cursor_ioctl+0x46/0x60 [drm] drm_ioctl_kernel+0xa8/0xf0 [drm] drm_ioctl+0x20a/0x3a0 [drm] ? drm_mode_setplane+0x1a0/0x1a0 [drm] ? lockdep_hardirqs_on_prepare+0xd4/0x180 ? _raw_spin_unlock_irqrestore+0x42/0x50 nouveau_drm_ioctl+0x50/0xa0 [nouveau] __x64_sys_ioctl+0x81/0xa0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f0621dbecc7 Code: 3c 1c 48 f7 d8 49 39 c4 72 b9 e8 24 ff ff ff 85 c0 78 be 5b 4c 89 e0 5d 41 5c c3 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 71 41 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffd8eb88dc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f0621dbecc7 RDX: 00007ffd8eb88e1c RSI: 00000000c01c64a3 RDI: 000000000000000c RBP: 00000000c01c64a3 R08: 0000000000000040 R09: 0000000000000001 R10: 00007f0622505bc0 R11: 0000000000000246 R12: 000055fbec3f5ec0 R13: 00007ffd8eb88e1c R14: 00000000000003bc R15: 0000000000000218 # lspci -s 04:00.0 -v 04:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GT710-4H-SL-2GD5 Flags: bus master, fast devsel, latency 0, IRQ 51, IOMMU group 0 Memory at fd000000 (32-bit, non-prefetchable) [size=16M] Memory at e8000000 (64-bit, prefetchable) [size=128M] Memory at f0000000 (64-bit, prefetchable) [size=32M] I/O ports at e000 [size=128] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [60] Power Management version 3 Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [78] Express Legacy Endpoint, MSI 00 Capabilities: [100] Virtual Channel Capabilities: [128] Power Budgeting <?> Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?> Capabilities: [900] Secondary PCI Express Kernel driver in use: nouveau Kernel modules: nouveau -- You may reply to this email to add a comment. You are receiving this mail because: You are on the CC list for the bug. You are watching the assignee of the bug.

2 2

[Bug 212635] New: nouveau 0000:04:00.0: fifo: fault 00 [READ] at 0000000000380000 engine 00 [GR] client 14 [HUB/SCC] reason 02 [PTE] on channel 5 [007fabf000 X[570]]
by bugzilla-daemon＠bugzilla.kernel.org 18 Apr '22

18 Apr '22

https://bugzilla.kernel.org/show_bug.cgi?id=212635 Bug ID: 212635 Summary: nouveau 0000:04:00.0: fifo: fault 00 [READ] at 0000000000380000 engine 00 [GR] client 14 [HUB/SCC] reason 02 [PTE] on channel 5 [007fabf000 X[570]] Product: Drivers Version: 2.5 Kernel Version: 5.11.12 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: erhard_f(a)mailbox.org Regression: No Created attachment 296315 --> https://bugzilla.kernel.org/attachment.cgi?id=296315&action=edit dmesg (kernel 5.11.12) Happened during browsing on Firefox, WebGL conformance tests were running in the background (https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.ht…). The screen went blank, but I got to desktop back again and the machine stayed usable. [...] nouveau 0000:04:00.0: fifo: fault 00 [READ] at 0000000000380000 engine 00 [GR] client 14 [HUB/SCC] reason 02 [PTE] on channel 5 [007fabf000 X[570]] nouveau 0000:04:00.0: fifo: channel 5: killed nouveau 0000:04:00.0: fifo: runlist 0: scheduled for recovery nouveau 0000:04:00.0: fifo: engine 0: scheduled for recovery nouveau 0000:04:00.0: X[570]: channel 5 killed! nouveau 0000:04:00.0: fifo: fault 00 [READ] at 0000000000380000 engine 00 [GR] client 14 [HUB/SCC] reason 02 [PTE] on channel 5 [007fabf000 X[570]] nouveau 0000:04:00.0: fifo: channel 5: killed nouveau 0000:04:00.0: fifo: runlist 0: scheduled for recovery nouveau 0000:04:00.0: fifo: engine 0: scheduled for recovery nouveau 0000:04:00.0: X[570]: channel 5 killed! nouveau 0000:04:00.0: fifo: fault 00 [READ] at 0000000000380000 engine 00 [GR] client 14 [HUB/SCC] reason 02 [PTE] on channel 5 [007fabf000 X[570]] nouveau 0000:04:00.0: fifo: channel 5: killed nouveau 0000:04:00.0: fifo: runlist 0: scheduled for recovery nouveau 0000:04:00.0: fifo: engine 0: scheduled for recovery nouveau 0000:04:00.0: X[570]: channel 5 killed! nouveau 0000:04:00.0: fifo: fault 00 [READ] at 0000000000380000 engine 00 [GR] client 14 [HUB/SCC] reason 02 [PTE] on channel 5 [007fabf000 X[570]] nouveau 0000:04:00.0: fifo: channel 5: killed nouveau 0000:04:00.0: fifo: runlist 0: scheduled for recovery nouveau 0000:04:00.0: fifo: engine 0: scheduled for recovery nouveau 0000:04:00.0: X[570]: channel 5 killed! # inxi -b System: Kernel: 5.11.12-gentoo-Excavator x86_64 bits: 64 Desktop: MATE 1.24.0 Distro: Gentoo Base System release 2.7 Machine: Type: Desktop Mobo: ASRock model: A320M-HDV R3.0 serial: M80-BA024200938 UEFI: American Megatrends v: P3.10 date: 06/26/2019 CPU: Info: Quad Core AMD A10-9700E RADEON R7 10 COMPUTE CORES 4C+6G [MCP] speed: 3300 MHz min/max: 800/3000 MHz Graphics: Device-1: NVIDIA GK208B [GeForce GT 710] driver: nouveau v: kernel Display: x11 server: X.Org 1.20.10 driver: modesetting resolution: 1920x1080~60Hz OpenGL: renderer: NV106 v: 4.3 Mesa 20.3.5 Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 # lspci 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Root Complex 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) I/O Memory Management Unit 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Host Bridge 00:02.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Root Port 00:02.5 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Root Port 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Host Bridge 00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Root Port 00:08.0 Encryption controller: Advanced Micro Devices, Inc. [AMD] Carrizo Platform Security Processor 00:09.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Carrizo Audio Dummy Host Bridge 00:09.2 Audio device: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Audio Controller 00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 20) 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 49) 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 49) 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 4a) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 11) 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 0 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 1 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 2 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 3 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 4 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 5 01:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Device 43bc (rev 02) 01:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] Device 43b8 (rev 02) 01:00.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43b3 (rev 02) 02:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) 02:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) 02:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) 04:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) 04:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1) 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) 06:00.0 Non-Volatile memory controller: Sandisk Corp WD Black 2019/PC SN750 NVMe SSD 07:00.0 USB controller: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller -- 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 2

[PATCH v5 1/2] dt-bindings: Add DT schema for Arm Mali Valhall GPU
by Nick Fan 14 Apr '22

14 Apr '22

Add devicetree schema for Arm Mali Valhall GPU Define a compatible string for the Mali Valhall GPU for Mediatek's SoC platform. Signed-off-by: Nick Fan <Nick.Fan(a)mediatek.com> --- .../bindings/gpu/arm,mali-valhall.yaml | 217 ++++++++++++++++++ 1 file changed, 217 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml new file mode 100644 index 000000000000..275c14ad173a --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml @@ -0,0 +1,217 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020 MediaTek Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpu/arm,mali-valhall.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Mali Valhall GPU + +maintainers: + - Rob Herring <robh(a)kernel.org> + +properties: + $nodename: + pattern: '^gpu@[a-f0-9]+$' + + compatible: + items: + - enum: + - mediatek,mt8192-mali + - const: arm,mali-valhall + + reg: + maxItems: 1 + + interrupts: + items: + - description: GPU interrupt + - description: MMU interrupt + - description: Job interrupt + + interrupt-names: + items: + - const: gpu + - const: mmu + - const: job + + clocks: + minItems: 1 + + power-domains: + minItems: 1 + maxItems: 5 + + mali-supply: true + sram-supply: true + + operating-points-v2: true + opp_table: true + + "#cooling-cells": + const: 2 + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + const: mediatek,mt8192-mali + then: + properties: + power-domains: + minItems: 5 + maxItems: 5 + + power-domain-names: + items: + - const: core0 + - const: core1 + - const: core2 + - const: core3 + - const: core4 + + required: + - sram-supply + - power-domains + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + gpu@13000000 { + compatible = "mediatek,mt8192-mali", "arm,mali-valhall"; + reg = <0x13000000 0x4000>; + interrupts = + <GIC_SPI 363 IRQ_TYPE_LEVEL_HIGH 0>, + <GIC_SPI 364 IRQ_TYPE_LEVEL_HIGH 0>, + <GIC_SPI 365 IRQ_TYPE_LEVEL_HIGH 0>; + interrupt-names = + "gpu", + "mmu", + "job"; + + clocks = <&mfgcfg 0>; + + power-domains = + <&spm 4>, + <&spm 5>, + <&spm 6>, + <&spm 7>, + <&spm 8>; + + operating-points-v2 = <&gpu_opp_table>; + mali-supply = <&mt6315_7_vbuck1>; + sram-supply = <&mt6359_vsram_others_ldo_reg>; + gpu_opp_table: opp_table { + compatible = "operating-points-v2"; + opp-shared; + + opp-358000000 { + opp-hz = /bits/ 64 <358000000>; + opp-microvolt = <606250>, + <750000>; + }; + + opp-399000000 { + opp-hz = /bits/ 64 <399000000>; + opp-microvolt = <618750>, + <750000>; + }; + + opp-440000000 { + opp-hz = /bits/ 64 <440000000>; + opp-microvolt = <631250>, + <750000>; + }; + + opp-482000000 { + opp-hz = /bits/ 64 <482000000>; + opp-microvolt = <643750>, + <750000>; + }; + + opp-523000000 { + opp-hz = /bits/ 64 <523000000>; + opp-microvolt = <656250>, + <750000>; + }; + + opp-564000000 { + opp-hz = /bits/ 64 <564000000>; + opp-microvolt = <668750>, + <750000>; + }; + + opp-605000000 { + opp-hz = /bits/ 64 <605000000>; + opp-microvolt = <681250>, + <750000>; + }; + + opp-647000000 { + opp-hz = /bits/ 64 <647000000>; + opp-microvolt = <693750>, + <750000>; + }; + + opp-688000000 { + opp-hz = /bits/ 64 <688000000>; + opp-microvolt = <706250>, + <750000>; + }; + + opp-724000000 { + opp-hz = /bits/ 64 <724000000>; + opp-microvolt = <725000>, + <750000>; + }; + + opp-760000000 { + opp-hz = /bits/ 64 <760000000>; + opp-microvolt = <743750>, + <750000>; + }; + + opp-795000000 { + opp-hz = /bits/ 64 <795000000>; + opp-microvolt = <762500>, + <762500>; + }; + + opp-831000000 { + opp-hz = /bits/ 64 <831000000>; + opp-microvolt = <781250>, + <781250>; + }; + + opp-855000000 { + opp-hz = /bits/ 64 <855000000>; + opp-microvolt = <793750>, + <793750>; + }; + + opp-902000000 { + opp-hz = /bits/ 64 <902000000>; + opp-microvolt = <818750>, + <818750>; + }; + + opp-950000000 { + opp-hz = /bits/ 64 <950000000>; + opp-microvolt = <843750>, + <843750>; + }; + }; + }; +... -- 2.18.0

3 3

[Bug 211425] New: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting
by bugzilla-daemon＠bugzilla.kernel.org 11 Apr '22

11 Apr '22

https://bugzilla.kernel.org/show_bug.cgi?id=211425 Bug ID: 211425 Summary: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting Product: Drivers Version: 2.5 Kernel Version: 5.10.10 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: icedragon.aw(a)web.de Regression: No Reproducible: Every times when I switched my monitor off and on again, then my screen keeps black for round about a minute - the DP port seem to be in a kind of suspend state. After a minute I can try to switch my monitor off and on again or switching between the linux consoles, then my screen comes back. If I try this earlier than after a minute I get no success. My dmesg output shows the following errors (triggered by this event): [Di Jan 26 12:59:17 2021] [drm] amdgpu_dm_irq_schedule_work FAILED src 2 [Di Jan 26 12:59:19 2021] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting [Di Jan 26 12:59:19 2021] [drm:amdgpu_atom_execute_table_locked] *ERROR* atombios stuck executing B200 (len 3615, WS 8, PS 0) @ 0xB34E [Di Jan 26 12:59:19 2021] [drm:amdgpu_atom_execute_table_locked] *ERROR* atombios stuck executing B0F4 (len 268, WS 4, PS 0) @ 0xB147 [Di Jan 26 12:59:19 2021] [drm:dcn10_link_encoder_enable_dp_output] *ERROR* dcn10_link_encoder_enable_dp_output: Failed to execute VBIOS command table! [Di Jan 26 12:59:41 2021] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting [Di Jan 26 12:59:41 2021] [drm:amdgpu_atom_execute_table_locked] *ERROR* atombios stuck executing B200 (len 3615, WS 8, PS 0) @ 0xB6EA [Di Jan 26 12:59:41 2021] [drm:amdgpu_atom_execute_table_locked] *ERROR* atombios stuck executing B0F4 (len 268, WS 4, PS 0) @ 0xB147 [Di Jan 26 12:59:41 2021] [drm:dcn10_link_encoder_enable_dp_output] *ERROR* dcn10_link_encoder_enable_dp_output: Failed to execute VBIOS command table! [Di Jan 26 12:59:42 2021] [drm] amdgpu_dm_irq_schedule_work FAILED src 2 I observe such issues with switching monitor off and on again at least since 5.10.4 - I have not tested this with an older kernel version, because at this time of 5.10.4 I changed my system from an intel processor to this AMD system: System: Kubuntu 20.10, Ryzon 7 PRO 4750G - using only integrated GPU (Vega10): Jan 24 17:41:38 localhost kernel: [ 0.000000] Linux version 5.10.10-aw (root@icehome) (gcc (Ubuntu 10.2.0-13ubuntu1) 10.2.0, GNU ld (GNU Binutils for Ubuntu) 2.35.1) #1 SMP PREEMPT Sun Jan 24 17:36:28 CET 2021 Jan 24 17:41:38 localhost kernel: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.10-aw root=UUID=6ff371aa-4315-475d-b8ec-b0a642c9eb5b ro nosplash video=1920x1080 Jan 24 17:41:38 localhost kernel: [ 0.000000] KERNEL supported cpus: Jan 24 17:41:38 localhost kernel: [ 0.000000] AMD AuthenticAMD ... -- 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 39

[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

[PATCH] gpu: host1x: Show all allocated syncpts via debugfs
by Jon Hunter 06 Apr '22

06 Apr '22

When the host1x syncpts status is dumped via the debugfs, syncpts that have been allocated but not yet used are not shown and so currently it is not possible to see all the allocated syncpts. Update the path for dumping the syncpt status via the debugfs to show all allocated syncpts even if they have not been used yet. Note that when the syncpt status is dumped by the kernel itself for debugging only the active syncpt are shown. Signed-off-by: Jon Hunter <jonathanh(a)nvidia.com> --- drivers/gpu/host1x/debug.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c index 18d9c8d206e3..34c2e36d09e9 100644 --- a/drivers/gpu/host1x/debug.c +++ b/drivers/gpu/host1x/debug.c @@ -75,7 +75,7 @@ static int show_channel(struct host1x_channel *ch, void *data, bool show_fifo) return 0; } -static void show_syncpts(struct host1x *m, struct output *o) +static void show_syncpts(struct host1x *m, struct output *o, bool show_all) { struct list_head *pos; unsigned int i; @@ -97,7 +97,10 @@ static void show_syncpts(struct host1x *m, struct output *o) waiters++; spin_unlock(&m->syncpt[i].intr.lock); - if (!min && !max && !waiters) + if (!kref_read(&m->syncpt[i].ref)) + continue; + + if (!show_all && !min && !max && !waiters) continue; host1x_debug_output(o, @@ -124,7 +127,7 @@ static void show_all(struct host1x *m, struct output *o, bool show_fifo) unsigned int i; host1x_hw_show_mlocks(m, o); - show_syncpts(m, o); + show_syncpts(m, o, true); host1x_debug_output(o, "---- channels ----\n"); for (i = 0; i < m->info->nb_channels; ++i) { @@ -241,5 +244,5 @@ void host1x_debug_dump_syncpts(struct host1x *host1x) .fn = write_to_printk }; - show_syncpts(host1x, &o); + show_syncpts(host1x, &o, false); } -- 2.25.1

2 1

Re: [PATCH v2 1/5] dt-bindings: reserved-memory: Document memory region specifier
by Thierry Reding 01 Apr '22

01 Apr '22

On Fri, Jul 02, 2021 at 05:16:25PM +0300, Dmitry Osipenko wrote: > 01.07.2021 21:14, Thierry Reding пишет: > > On Tue, Jun 08, 2021 at 06:51:40PM +0200, Thierry Reding wrote: > >> On Fri, May 28, 2021 at 06:54:55PM +0200, Thierry Reding wrote: > >>> On Thu, May 20, 2021 at 05:03:06PM -0500, Rob Herring wrote: > >>>> On Fri, Apr 23, 2021 at 06:32:30PM +0200, Thierry Reding wrote: > >>>>> From: Thierry Reding <treding(a)nvidia.com> > >>>>> > >>>>> Reserved memory region phandle references can be accompanied by a > >>>>> specifier that provides additional information about how that specific > >>>>> reference should be treated. > >>>>> > >>>>> One use-case is to mark a memory region as needing an identity mapping > >>>>> in the system's IOMMU for the device that references the region. This is > >>>>> needed for example when the bootloader has set up hardware (such as a > >>>>> display controller) to actively access a memory region (e.g. a boot > >>>>> splash screen framebuffer) during boot. The operating system can use the > >>>>> identity mapping flag from the specifier to make sure an IOMMU identity > >>>>> mapping is set up for the framebuffer before IOMMU translations are > >>>>> enabled for the display controller. > >>>>> > >>>>> Signed-off-by: Thierry Reding <treding(a)nvidia.com> > >>>>> --- > >>>>> .../reserved-memory/reserved-memory.txt | 21 +++++++++++++++++++ > >>>>> include/dt-bindings/reserved-memory.h | 8 +++++++ > >>>>> 2 files changed, 29 insertions(+) > >>>>> create mode 100644 include/dt-bindings/reserved-memory.h > >>>> > >>>> Sorry for being slow on this. I have 2 concerns. > >>>> > >>>> First, this creates an ABI issue. A DT with cells in 'memory-region' > >>>> will not be understood by an existing OS. I'm less concerned about this > >>>> if we address that with a stable fix. (Though I'm pretty sure we've > >>>> naively added #?-cells in the past ignoring this issue.) > >>> > >>> A while ago I had proposed adding memory-region*s* as an alternative > >>> name for memory-region to make the naming more consistent with other > >>> types of properties (think clocks, resets, gpios, ...). If we added > >>> that, we could easily differentiate between the "legacy" cases where > >>> no #memory-region-cells was allowed and the new cases where it was. > >>> > >>>> Second, it could be the bootloader setting up the reserved region. If a > >>>> node already has 'memory-region', then adding more regions is more > >>>> complicated compared to adding new properties. And defining what each > >>>> memory-region entry is or how many in schemas is impossible. > >>> > >>> It's true that updating the property gets a bit complicated, but it's > >>> not exactly rocket science. We really just need to splice the array. I > >>> have a working implemention for this in U-Boot. > >>> > >>> For what it's worth, we could run into the same issue with any new > >>> property that we add. Even if we renamed this to iommu-memory-region, > >>> it's still possible that a bootloader may have to update this property > >>> if it already exists (it could be hard-coded in DT, or it could have > >>> been added by some earlier bootloader or firmware). > >>> > >>>> Both could be addressed with a new property. Perhaps something like > >>>> 'iommu-memory-region = <&phandle>;'. I think the 'iommu' prefix is > >>>> appropriate given this is entirely because of the IOMMU being in the > >>>> mix. I might feel differently if we had other uses for cells, but I > >>>> don't really see it in this case. > >>> > >>> I'm afraid that down the road we'll end up with other cases and then we > >>> might proliferate a number of *-memory-region properties with varying > >>> prefixes. > >>> > >>> I am aware of one other case where we might need something like this: on > >>> some Tegra SoCs we have audio processors that will access memory buffers > >>> using a DMA engine. These processors are booted from early firmware > >>> using firmware from system memory. In order to avoid trashing the > >>> firmware, we need to reserve memory. We can do this using reserved > >>> memory nodes. However, the audio DMA engine also uses the SMMU, so we > >>> need to make sure that the firmware memory is marked as reserved within > >>> the SMMU. This is similar to the identity mapping case, but not exactly > >>> the same. Instead of creating a 1:1 mapping, we just want that IOVA > >>> region to be reserved (i.e. IOMMU_RESV_RESERVED instead of > >>> IOMMU_RESV_DIRECT{,_RELAXABLE}). > >>> > >>> That would also fall into the IOMMU domain, but we can't reuse the > >>> iommu-memory-region property for that because then we don't have enough > >>> information to decide which type of reservation we need. > >>> > >>> We could obviously make iommu-memory-region take a specifier, but we > >>> could just as well use memory-regions in that case since we have > >>> something more generic anyway. > >>> > >>> With the #memory-region-cells proposal, we can easily extend the cell in > >>> the specifier with an additional MEMORY_REGION_IOMMU_RESERVE flag to > >>> take that other use case into account. If we than also change to the new > >>> memory-regions property name, we avoid the ABI issue (and we gain a bit > >>> of consistency while at it). > >> > >> Ping? Rob, do you want me to add this second use-case to the patch > >> series to make it more obvious that this isn't just a one-off thing? Or > >> how do we proceed? > > > > Rob, given that additional use-case, do you want me to run with this > > proposal and send out an updated series? > > > What about variant with a "descriptor" properties that will describe > each region: > > fb_desc: display-framebuffer-memory-descriptor { > needs-identity-mapping; > } > > display@52400000 { > memory-region = <&fb ...>; > memory-region-descriptor = <&fb_desc ...>; > }; > > It could be a more flexible/extendible variant. This problem recently came up on #dri-devel again. Adding Alyssa and Sven who are facing a similar challenge on their work on Apple M1 (if I understood correctly). Also adding dri-devel for visibility since this is a very common problem for display in particular. On M1 the situation is slightly more complicated: the firmware will allocate a couple of buffers (including the framebuffer) in high memory (> 4 GiB) and use the IOMMU to map that into an IOVA region below 4 GiB so that the display hardware can access it. This makes it impossible to bypass the IOMMU like we do on other chips (in particular to work around the fault-by-default policy of the ARM SMMU driver). It also means that in addition to the simple reserved regions I mentioned we need for audio use-cases and identity mapping use-cases we need for display on Tegra, we now also need to be able to convey physical to IOVA mappings. Fitting the latter into the original proposal sounds difficult. A quick fix would've been to generate a mapping table in memory and pass that to the kernel using a reserved-memory node (similar to what's done for example on Tegra for the EMC frequency table on Tegra210) and mark it as such using a special flag. But that then involves two layers of parsing, which seems a bit suboptimal. Another way to shoehorn that into the original proposal would've been to add flags for physical and virtual address regions and use pairs to pass them using special flags. Again, this is a bit wonky because it needs these to be carefully parsed and matched up. Another downside is that we now have a situation where some of these regions are no longer "reserved-memory regions" in the traditional sense. This would require an additional flag in the reserved-memory region nodes to prevent the IOVA regions from being reserved. By the way, this is something that would also be needed for the audio use-case I mentioned before, because the physical memory at that address can still be used by an operating system. A more general solution would be to draw a bit from Dmitry's proposal and introduce a new top-level "iov-reserved-memory" node. This could be modelled on the existing reserved-memory node, except that the physical memory pages for regions represented by child nodes would not be marked as reserved. Only the IOVA range described by the region would be reserved subsequently by the IOMMU framework and/or IOMMU driver. The simplest case where we just want to reserve some IOVA region could then be done like this: iov-reserved-memory { /* * Probably safest to default to <2>, <2> here given * that most IOMMUs support either > 32 bits of IAS * or OAS. */ #address-cells = <2>; #size-cells = <2>; firmware: firmware@80000000 { reg = <0 0x80000000 0 0x01000000>; }; }; audio@30000000 { ... iov-memory-regions = <&firmware>; ... }; Mappings could be represented by an IOV reserved region taking a reference to the reserved-region that they map: reserved-memory { #address-cells = <2>; #size-cells = <2>; /* 16 MiB of framebuffer at top-of-memory */ framebuffer: framebuffer@1,ff000000 { reg = <0x1 0xff000000 0 0x01000000>; no-map; }; }; iov-reserved-memory { /* IOMMU supports only 32-bit output address space */ #address-cells = <1>; #size-cells = <1>; /* 16 MiB of framebuffer mapped to top of IOVA */ fb: fb@ff000000 { reg = <0 0xff000000 0 0x01000000>; memory-region = <&framebuffer>; }; }; display@40000000 { ... /* optional? */ memory-region = <&framebuffer>; iov-memory-regions = <&fb>; ... }; It's interesting how identity mapped regions now become a trivial special case of mappings. All that is needed is to make the reg property of the IOV reserved region correspond to the reg property of the normal reserved region. Alternatively, as a small optimization for lazy people like me, we could just allow these cases to omit the reg property and instead inherit it from the referenced reserved region. As the second example shows it might be convenient if memory-region could be derived from iov-memory-regions. This could be useful for cases where the driver wants to do something with the physical pages of the reserved region (such as mapping them and copying out the framebuffer data to another buffer so that the reserved memory can be recycled). If we have the IOV reserved region, we could provide an API to extract the physical reserved region (if it exists). That way we could avoid referencing it twice in DT. Then again, there's something elegant about the explicit second reference to. It indicates the intent that we may want to use the region for something other than just the IOV mapping. Anyway, this has been long enough. Let me know what you think. Alyssa, Sven, it'd be interesting to hear if you think this could work as a solution to the problem on M1. Rob, I think you might like this alternative because it basically gets rid of all the points in the original proposal that you were concerned about. Let me know what you think. Thierry

3 12

[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

← Newer
1
2
3
4
5
6
7
...
85
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2022