dri-devel July 2020

dri-devel@lists.freedesktop.org

336 participants
772 discussions

[PATCH] RFC: i915: Drop relocation support on Gen12+
by Jason Ekstrand 12 Mar '21

12 Mar '21

The Vulkan driver in Mesa for Intel hardware never uses relocations if it's running on a version of i915 that supports at least softpin which all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12 is only supported by iris which never uses relocations. The older i965 driver in Mesa does use relocations but it only supports Intel hardware through Gen11 and has been deprecated for all hardware Gen9+. The entire relocation UAPI and related infrastructure, therefore, doesn't have any open-source userspace consumer starting with Gen12. Rejecting relocations starting with Gen12 has the benefit that we don't have to bother supporting it on platforms with local memory. Given how much CPU touching of memory is required for relocations, not having to do so on platforms where not all memory is directly CPU-accessible carries significant advantages. Signed-off-by: Jason Ekstrand <jason(a)jlekstrand.net> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 4f9c1f5a4dedb..e10c93aff945d 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -1533,7 +1533,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct i915_vma *vma) return err; } -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry) +static int check_relocations(const struct i915_execbuffer *eb, + const struct drm_i915_gem_exec_object2 *entry) { const char __user *addr, *end; unsigned long size; @@ -1543,6 +1544,9 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry) if (size == 0) return 0; + if (size && eb->reloc_cache.gen >= 12) + return -EINVAL; + if (size > N_RELOC(ULONG_MAX)) return -EINVAL; @@ -1576,7 +1580,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb) if (nreloc == 0) continue; - err = check_relocations(&eb->exec[i]); + err = check_relocations(eb, &eb->exec[i]); if (err) goto err; -- 2.26.2

9 23

[PATCH v5 0/7] drm: add simpledrm driver
by David Herrmann 12 Mar '21

12 Mar '21

Hey On request of Noralf, I picked up the patches and prepared v5. Works fine with Xorg, if configured according to: https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html If anyone knows how to make Xorg pick it up dynamically without such a static configuration, please let me know. Thanks David David Herrmann (7): x86/sysfb: add support for 64bit EFI lfb_base x86/sysfb: fix lfb_size calculation of/platform: expose of_platform_device_destroy() video: add generic framebuffer eviction drm: switch to sysfb_evict_conflicts() drm: add SimpleDRM driver drm/simpledrm: add fbdev fallback support MAINTAINERS | 6 + arch/x86/kernel/sysfb_simplefb.c | 39 ++- drivers/gpu/drm/Kconfig | 3 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 24 +- drivers/gpu/drm/bochs/bochs_drv.c | 19 +- drivers/gpu/drm/i915/i915_drv.c | 73 +--- drivers/gpu/drm/mgag200/mgag200_drv.c | 27 +- drivers/gpu/drm/mgag200/mgag200_main.c | 9 - drivers/gpu/drm/nouveau/nouveau_drm.c | 33 +- drivers/gpu/drm/radeon/radeon_drv.c | 24 +- drivers/gpu/drm/simpledrm/Kconfig | 19 ++ drivers/gpu/drm/simpledrm/Makefile | 9 + drivers/gpu/drm/simpledrm/simpledrm.h | 91 +++++ drivers/gpu/drm/simpledrm/simpledrm_damage.c | 194 +++++++++++ drivers/gpu/drm/simpledrm/simpledrm_drv.c | 477 +++++++++++++++++++++++++++ drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 143 ++++++++ drivers/gpu/drm/simpledrm/simpledrm_gem.c | 109 ++++++ drivers/gpu/drm/simpledrm/simpledrm_kms.c | 270 +++++++++++++++ drivers/gpu/drm/simpledrm/simpledrm_of.c | 265 +++++++++++++++ drivers/gpu/drm/sun4i/sun4i_drv.c | 24 +- drivers/gpu/drm/vc4/vc4_drv.c | 25 +- drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 24 +- drivers/of/platform.c | 35 +- drivers/video/Kconfig | 4 + drivers/video/Makefile | 1 + drivers/video/sysfb.c | 327 ++++++++++++++++++ include/linux/of_platform.h | 1 + include/linux/sysfb.h | 34 ++ 29 files changed, 2054 insertions(+), 256 deletions(-) create mode 100644 drivers/gpu/drm/simpledrm/Kconfig create mode 100644 drivers/gpu/drm/simpledrm/Makefile create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_damage.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_drv.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_gem.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_kms.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_of.c create mode 100644 drivers/video/sysfb.c create mode 100644 include/linux/sysfb.h -- 2.9.3

5 28

[PATCH v6 0/9] Enable ili9341 and l3gd20 on stm32f429-disco
by dillon.minfei＠gmail.com 10 Mar '21

10 Mar '21

From: dillon min <dillon.minfei(a)gmail.com> V6: 1 separate '[PATCH v5 5/8]' patchs to two, each one has a Fixes tags according to Stephen Boyd's suggestion 2 fix panel-ilitek-ili9341 compile warning 'warning: Function parameter or member xxx not described in xxx' with W=1 V5's update based on Mark Brown's suggestion, use 'SPI_MASTER_MUST_RX' for SPI_SIMPLEX_RX mode on stm32 spi controller. V5: 1 instead of add send dummy data out under SIMPLEX_RX mode, add flags 'SPI_CONTROLLER_MUST_TX' for stm32 spi driver 2 bypass 'SPI_CONTROLLER_MUST_TX' and 'SPI_CONTROLLER_MUST_RX' under 'SPI_3WIRE' mode V4: According to alexandre torgue's suggestion, combine ili9341 and l3gd20's modification on stm32f429-disco board to one patchset. Changes: ili9341: 1 update ili9341 panel driver according to Linus's suggestion 2 drop V1's No.5 patch, sumbit new changes for clk-stm32f4 3 merge l3gd20's change to this patchset V3: 1 merge original tiny/ili9341.c driver to panel/panel-ilitek-ili9341.c to support serial spi & parallel rgb interface in one driver. 2 update ilitek,ili9341.yaml dts binding documentation. 3 update stm32f429-disco dts binding V2: 1 verify ilitek,ili9341.yaml with make O=../linux-stm32 dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/panel/ ilitek,ili9341.yaml V1: 1 add ili9341 drm panel driver 2 add ltdc, spi5 controller for stm32f429-disco 3 add ltdc, spi5 pin map for stm32f429-disco 4 add docs about ili9341 5 fix ltdc driver loading hang in clk set rate bug L3gd20: V3: 1 merge stm32f429-disco dtbs binding with ili9341 part V2: 1 insert blank line at stm32f420-disco.dts line 143 2 add more description for l3gd20 in commit message V1: 1 enable spi5 controller on stm32f429-disco (dts) 2 add spi5 pinmap for stm32f429-disco (dts) 3 add SPI_SIMPLEX_RX, SPI_3WIRE_RX support for stm32f4 dillon min (9): ARM: dts: stm32: Add dma config for spi5 ARM: dts: stm32: Add pin map for ltdc & spi5 on stm32f429-disco board ARM: dts: stm32: enable ltdc binding with ili9341, gyro l3gd20 on stm32429-disco board dt-bindings: display: panel: Add ilitek ili9341 panel bindings clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate clk: stm32: Fix ltdc's clock turn off by clk_disable_unused() after kernel startup drm/panel: Add ilitek ili9341 panel driver spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4 spi: flags 'SPI_CONTROLLER_MUST_RX' and 'SPI_CONTROLLER_MUST_TX' can't be coexit with 'SPI_3WIRE' mode .../bindings/display/panel/ilitek,ili9341.yaml | 69 ++ arch/arm/boot/dts/stm32f4-pinctrl.dtsi | 67 + arch/arm/boot/dts/stm32f429-disco.dts | 48 + arch/arm/boot/dts/stm32f429.dtsi | 3 + drivers/clk/clk-stm32f4.c | 7 +- drivers/gpu/drm/panel/Kconfig | 12 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 1288 ++++++++++++++++++++ drivers/spi/spi-stm32.c | 19 +- drivers/spi/spi.c | 3 +- 10 files changed, 1508 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c -- 2.7.4

6 20

[PATCH v9 0/5] drm/i915 Support for integrated privacy screen
by Rajat Jain 09 Mar '21

09 Mar '21

This patchset adds support for integrated privacy screen on some laptops using the ACPI methods to detect and control the feature. Rajat Jain (5): intel_acpi: Rename drm_dev local variable to dev drm/connector: Add support for privacy-screen property drm/i915: Lookup and attach ACPI device node for connectors drm/i915: Add helper code for ACPI privacy screen drm/i915: Enable support for integrated privacy screen drivers/gpu/drm/drm_atomic_uapi.c | 4 + drivers/gpu/drm/drm_connector.c | 51 +++++ drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/display/intel_acpi.c | 30 ++- drivers/gpu/drm/i915/display/intel_atomic.c | 2 + drivers/gpu/drm/i915/display/intel_ddi.c | 1 + .../drm/i915/display/intel_display_types.h | 5 + drivers/gpu/drm/i915/display/intel_dp.c | 48 ++++- drivers/gpu/drm/i915/display/intel_dp.h | 5 + .../drm/i915/display/intel_privacy_screen.c | 184 ++++++++++++++++++ .../drm/i915/display/intel_privacy_screen.h | 27 +++ drivers/gpu/drm/i915/i915_drv.h | 2 + include/drm/drm_connector.h | 24 +++ 13 files changed, 382 insertions(+), 4 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.c create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.h -- 2.25.1.481.gfbce0eb801-goog

2 9

[Bug 208115] New: amdgpu (likely) - power management and display connection problems with an RX590 card
by bugzilla-daemon＠bugzilla.kernel.org 01 Mar '21

01 Mar '21

https://bugzilla.kernel.org/show_bug.cgi?id=208115 Bug ID: 208115 Summary: amdgpu (likely) - power management and display connection problems with an RX590 card Product: Drivers Version: 2.5 Kernel Version: 5.x.x 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: h_mailinglists(a)posteo.de Regression: No Created attachment 289583 --> https://bugzilla.kernel.org/attachment.cgi?id=289583&action=edit excerpt from dmesg grepping amdgpu Bug report - power management and display connection problems with an RX590 card Hello developer team Please bear with me, it is my first bug report on the actual kernel. It _might_ partially be related to https://bugzilla.kernel.org/show_bug.cgi?id=201139 background / generic info: I have an AMD RX 590, which is giving me some severe troubles. I have a multitude of ATI/AMD cards/APUs in use for years, mostly Gentoo Linux, a few Deb. derivatives and W32. RX 590 (PCIe) RX 560 (PCIe) HD 5770 (PCIe) HD 5670 (PCIe) HD 5450 and the likes (PCI, PCIe) HD 3870 (PCIe) Kabini (Athlon 5350) (AM1) Kabini E-2100 (soldered/BGA) E-350 (soldered/BGA) Geode LX ;-) (soldered/BGA / companion chip) and more the very chip/card in question: Sapphire Nitro+ Radeon RX 590 8G 50th Anniversary, 8192 MB GDDR5 (the golden one) the following setup it is currently dysfunctional: RX 590 Zen+ 2700 MSI PC-Mate B-350 (latest FW) 16 GiB RAM PSU BeQuiet DarkPowerPro 550 (should be strong enough, and problems are on the low power state side) Monitor: Eizo EV2436W hooked up via DP The setup works _nicely_ with a different GPU (e.g. HD 5450, okay, that's not amdgpu driver, but anyway). My other actual amdgpu card, the RX 560 (Polaris 11) works like a charm in an FX 6300 setup. The very (Eizo) screen also works flawless on my Kabini (though there I have to use a HDMI-2-DVI adapter connection); also an old Geode LX runs fairly well via VGA. software (Gentoo) Linux (5.x.x kernel; tried various versions over time, dind't really get much better), libdrm 2.4.9x / 2.4.10x, mesa 19.3.2 or later, xf86-video-amdgpu 19.1.0 I built a box based on a Ryzen Zen+ 2700, MSI PC-Mate B-350 mainboard. While I was setting it up I ran my elderly HD 5670 in it and everything was fine. All other cards in that ZEN+ system I tried so far worked like a charm. Severe video transcoding (CPU based), just "desktopping around", severe compiling (<-Gentoo): No problem! Power management? No problem! With the RX 590 it's a sheer pain. problems: * GPU not coming back once monitor goes into powersaving * link lost on every second power save (screen blanking / suspend / off / BACO) relation to #201139 ? * reading EDID problems message I found once in dmesg could be a hint (but it seems all others (cards or different boxes) can obtain the EDID) * Sometimes it seems I can still send commands via keyboard / work blindly and thus I might try to start a xrandr script to switch on/off ("reset") the digital outputs? * occasionally switching to VT (and back) helps, sometimes not, and the hardware is frozen; even REISUB (!) won't work. * once I also got it back - but - in max. 800 x 600 resolution * sometimes I can re-gain a signal by replugging the cable switching monitor on/off * freezes (which seem power management related) e.g. running a standard compile job host system had little to do, compilation was running inside a chroot env. (amd64 on amd64) next morning: LEDs on mainboard/GPU still glowing, fans spinning, system entirely frozen, not even REISUB would help nothing in the logs from /var/log/emerge.log it must have stopped somewhere in the middle of a harmless compile (iirc. it was sys-fs/fuse or something), and I don't use strange CFLAGs which might throw illegeal opcodes or something * power consumption is too high during idle * strange power readings in "sensors" at least 33 W (should be 10 W on idling and 3 W in BACO / zero core) * hint: also the W32 / W64 blob showed quite high consumption during desktop idle (AMD blob / GPU-Z) * wall measured might be slightly better but whole system (Zen+, GPU, 2 SSDs and one HDD, hardly any USB periphery no other cards in slots one BD/DVD/CDROM) never drops below 55 W, it's rather higher Is there something I might have missed? Should I try to obtain more verbose logs? Is there any "x-trace" tool that I could run? Radeontop information outputs? I'll attach one of the few logs I could obtain which might contains some hints towards what is happening. on my to-do list: * try a different monitor (though that very EIZO monitor worked like a charm with everything else I threw at it) * try HDMI instead of DP, but I think I don't have HDMI monitors at hand * try the RX590 in a different box (e.g. my FX 6300 unit, which currently runs flawless with an RX 560) - and see if it still misbehaves... Sorry for the wall of text. keywords: link lost, power management problems, powerplay, device reset reinitialization, system freeze, x86-64 amd64, amdgpu, AMD RX 590 RX590 Polaris -- You are receiving this mail because: You are watching the assignee of the bug.

1 3

[Bug 197327] New: radeon 0000:01:00.0: failed VCE resume (-110).
by bugzilla-daemon＠bugzilla.kernel.org 16 Feb '21

16 Feb '21

https://bugzilla.kernel.org/show_bug.cgi?id=197327 Bug ID: 197327 Summary: radeon 0000:01:00.0: failed VCE resume (-110). Product: Drivers Version: 2.5 Kernel Version: 4.13.8 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: mad_sam(a)bk.ru Regression: No Created attachment 260297 --> https://bugzilla.kernel.org/attachment.cgi?id=260297&action=edit dmesg log Have some trouble on my laptop with Radeon HD 8550G + Radeon HD 8750M I have error message radeon 0000:01:00.0: failed VCE resume (-110) in boot time, and i think my discrette card Radeon HD 8750M possibly not work (3D with DRI_PRIME=1 gives a worse or the same FPS than without it) -- You are receiving this mail because: You are watching the assignee of the bug.

1 11

[Bug 206987] New: [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
by bugzilla-daemon＠bugzilla.kernel.org 11 Feb '21

11 Feb '21

https://bugzilla.kernel.org/show_bug.cgi?id=206987 Bug ID: 206987 Summary: [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration Product: Drivers Version: 2.5 Kernel Version: 5.5.11 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: evvke(a)hotmail.com Regression: No Whole system crashes with this error message : simd exception: 0000 [#1] PREEMPT SMP NOPTI Only giving a REISUB treatment works. And cause is amdgpu driver. --- Mar 26 20:47:13 shodan kernel: simd exception: 0000 [#1] PREEMPT SMP NOPTI Mar 26 20:47:13 shodan kernel: CPU: 7 PID: 1344 Comm: Xorg Tainted: G W OE 5.5.11-arch1-1 #1 Mar 26 20:47:13 shodan kernel: Hardware name: Micro-Star International Co., Ltd. MS-7B78/X470 GAMING PRO CARBON (MS-7B78), BIOS 2.80 03/06/2019 Mar 26 20:47:13 shodan kernel: RIP: 0010:mode_support_and_system_configuration+0x30a3/0x4d90 [amdgpu] Mar 26 20:47:13 shodan kernel: Code: 00 0f 28 c3 e8 7e c9 ff ff f3 41 0f 11 87 40 19 00 00 e9 12 fd ff ff 41 83 be a8 00 00 00 06 75 93 f3 41 0f 10 86 40 1b 00 00 <f3> 41 0f 5e 86 f8 17 00 00 e8 4f c9 ff ff 41 8b 87 80 04 00 00 f3 Mar 26 20:47:13 shodan kernel: RSP: 0018:ffffb216c1f3b978 EFLAGS: 00010246 Mar 26 20:47:13 shodan kernel: RAX: 0000000000000006 RBX: ffff9c120bbfadc4 RCX: 0000000000000004 Mar 26 20:47:13 shodan kernel: RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9c120bbfb008 Mar 26 20:47:13 shodan kernel: RBP: ffff9c120bbfadc4 R08: ffff9c120bbfc164 R09: 0000000000000120 Mar 26 20:47:13 shodan kernel: R10: ffff9c120bbfaee4 R11: ffff9c120bbf0248 R12: ffff9c120bbfc63c Mar 26 20:47:13 shodan kernel: R13: 0000000000000000 R14: ffff9c120bbfaf5c R15: ffff9c120bbfadc4 Mar 26 20:47:13 shodan kernel: FS: 00007f1c9f336dc0(0000) GS:ffff9c19009c0000(0000) knlGS:0000000000000000 Mar 26 20:47:13 shodan kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 26 20:47:13 shodan kernel: CR2: 00001f82bfec7fe0 CR3: 00000007cbe4a000 CR4: 00000000003406e0 Mar 26 20:47:13 shodan kernel: Call Trace: Mar 26 20:47:13 shodan kernel: dcn_validate_bandwidth+0xfe5/0x1f20 [amdgpu] Mar 26 20:47:13 shodan kernel: dc_validate_global_state+0x28a/0x310 [amdgpu] Mar 26 20:47:13 shodan kernel: amdgpu_dm_atomic_check+0x5d8/0x870 [amdgpu] Mar 26 20:47:13 shodan kernel: drm_atomic_check_only+0x578/0x800 [drm] Mar 26 20:47:13 shodan kernel: ? dm_crtc_duplicate_state+0x6b/0x1f0 [amdgpu] Mar 26 20:47:13 shodan kernel: drm_atomic_commit+0x13/0x50 [drm] Mar 26 20:47:13 shodan kernel: drm_atomic_helper_legacy_gamma_set+0x123/0x180 [drm_kms_helper] Mar 26 20:47:13 shodan kernel: drm_mode_gamma_set_ioctl+0x171/0x220 [drm] Mar 26 20:47:13 shodan kernel: ? drm_mode_crtc_set_gamma_size+0xa0/0xa0 [drm] Mar 26 20:47:13 shodan kernel: drm_ioctl_kernel+0xb2/0x100 [drm] Mar 26 20:47:13 shodan kernel: drm_ioctl+0x209/0x360 [drm] Mar 26 20:47:13 shodan kernel: ? drm_mode_crtc_set_gamma_size+0xa0/0xa0 [drm] Mar 26 20:47:13 shodan kernel: amdgpu_drm_ioctl+0x49/0x80 [amdgpu] Mar 26 20:47:13 shodan kernel: do_vfs_ioctl+0x4b7/0x730 Mar 26 20:47:13 shodan kernel: ksys_ioctl+0x5e/0x90 Mar 26 20:47:13 shodan kernel: __x64_sys_ioctl+0x16/0x20 Mar 26 20:47:13 shodan kernel: do_syscall_64+0x4e/0x150 Mar 26 20:47:13 shodan kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Mar 26 20:47:13 shodan kernel: RIP: 0033:0x7f1ca01892eb Mar 26 20:47:13 shodan kernel: Code: 0f 1e fa 48 8b 05 a5 8b 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 75 8b 0c 00 f7 d8 64 89 01 48 Mar 26 20:47:13 shodan kernel: RSP: 002b:00007ffc60ff5648 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 Mar 26 20:47:13 shodan kernel: RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f1ca01892eb Mar 26 20:47:13 shodan kernel: RDX: 00007ffc60ff5700 RSI: 00000000c02064a5 RDI: 000000000000000a Mar 26 20:47:13 shodan kernel: RBP: 00007ffc60ff5680 R08: 0000562bb635c080 R09: 0000562bb635c280 Mar 26 20:47:13 shodan kernel: R10: 0000562bb635be80 R11: 0000000000000206 R12: 0000000000000100 Mar 26 20:47:13 shodan kernel: R13: 0000562bb6ab4f70 R14: 0000562bb635b9c0 R15: 0000000000000100 Mar 26 20:47:13 shodan kernel: Modules linked in: snd_seq_dummy snd_seq bluetooth ecdh_generic rfkill ecc veth fuse iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi tun ip6table_mangle xt_MASQUERADE iptable_nat nf_nat xt_connmark iptable_mangle xt_helper xt_NFLOG xt_limit xt_conntrack xt_tcpudp nf_conntrack_ftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_irc nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) pktcdvd nfnetlink_log nfnetlink ip6table_filter nct6775 ip6_tables hwmon_vid iptable_filter edac_mce_amd kvm_amd ccp ext4 rng_core kvm snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi crc16 mbcache irqbypass mxm_wmi jbd2 snd_hda_intel wmi_bmof snd_intel_dspcfg snd_hda_codec snd_usb_audio crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_core uvcvideo snd_usbmidi_lib snd_rawmidi videobuf2_vmalloc videobuf2_memops snd_seq_device videobuf2_v4l2 aesni_intel snd_hwdep videobuf2_common crypto_simd snd_pcm mousedev cryptd glue_helper Mar 26 20:47:13 shodan kernel: input_leds sp5100_tco snd_timer igb k10temp pcspkr i2c_piix4 snd soundcore dca wmi evdev mac_hid gpio_amdpt pinctrl_amd acpi_cpufreq xt_mark v4l2loopback(OE) videodev mc usbmon nbd msr vhba(OE) sr_mod cdrom sg br_netfilter bridge stp llc ip_tables x_tables dm_mod btrfs blake2b_generic libcrc32c crc32c_generic xor raid6_pq sd_mod hid_generic usbhid hid crc32c_intel ahci libahci libata xhci_pci xhci_hcd scsi_mod amdgpu gpu_sched i2c_algo_bit ttm drm_kms_helper serio_raw syscopyarea sysfillrect sysimgblt fb_sys_fops drm agpgart i8042 atkbd libps2 serio Mar 26 20:47:13 shodan kernel: ---[ end trace e34593e526e29a3d ]--- Mar 26 20:47:13 shodan kernel: RIP: 0010:mode_support_and_system_configuration+0x30a3/0x4d90 [amdgpu] Mar 26 20:47:13 shodan kernel: Code: 00 0f 28 c3 e8 7e c9 ff ff f3 41 0f 11 87 40 19 00 00 e9 12 fd ff ff 41 83 be a8 00 00 00 06 75 93 f3 41 0f 10 86 40 1b 00 00 <f3> 41 0f 5e 86 f8 17 00 00 e8 4f c9 ff ff 41 8b 87 80 04 00 00 f3 Mar 26 20:47:13 shodan kernel: RSP: 0018:ffffb216c1f3b978 EFLAGS: 00010246 Mar 26 20:47:13 shodan kernel: RAX: 0000000000000006 RBX: ffff9c120bbfadc4 RCX: 0000000000000004 Mar 26 20:47:13 shodan kernel: RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9c120bbfb008 Mar 26 20:47:13 shodan kernel: RBP: ffff9c120bbfadc4 R08: ffff9c120bbfc164 R09: 0000000000000120 Mar 26 20:47:13 shodan kernel: R10: ffff9c120bbfaee4 R11: ffff9c120bbf0248 R12: ffff9c120bbfc63c Mar 26 20:47:13 shodan kernel: R13: 0000000000000000 R14: ffff9c120bbfaf5c R15: ffff9c120bbfadc4 Mar 26 20:47:13 shodan kernel: FS: 00007f1c9f336dc0(0000) GS:ffff9c19009c0000(0000) knlGS:0000000000000000 Mar 26 20:47:13 shodan kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 26 20:47:13 shodan kernel: CR2: 00001f82bfec7fe0 CR3: 00000007cbe4a000 CR4: 00000000003406e0 -- You are receiving this mail because: You are watching the assignee of the bug.

1 48

[RFC][PATCH 0/9] drm: Support simple-framebuffer devices and firmware fbs
by Thomas Zimmermann 10 Feb '21

10 Feb '21

This patchset adds support for simple-framebuffer platform devices and a handover mechanism for native drivers to take-over control of the hardware. The new driver, called simplekms, binds to a simple-frambuffer platform device. The kernel's boot code creates such devices for firmware-provided framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot loader sets up the framebuffers. Description via device tree is also an option. Simplekms is small enough to be linked into the kernel. The driver's main purpose is to provide graphical output during the early phases of the boot process, before the native DRM drivers are available. Native drivers are typically loaded from an initrd ram disk. Occationally simplekms can also serve as interim solution on graphics hardware without native DRM driver. So far distributions rely on fbdev drivers, such as efifb, vesafb or simplefb, for early-boot graphical output. However fbdev is deprecated and the drivers do not provide DRM interfaces for modern userspace. Patches 1 and 2 prepare the DRM format helpers for simplekms. Patches 3 to 7 add the simplekms driver. It's build on simple DRM helpers and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During pageflips, SHMEM buffers are copied into the framebuffer memory, similar to cirrus or mgag200. The code in patches 6 and 7 handles clocks and regulators. It's based on the simplefb drivers, but has been modified for DRM. Patches 8 and 9 add a hand-over mechanism. Simplekms acquires it's framebuffer's I/O-memory range and provides a callback function to be removed by a native driver. The native driver will remove simplekms before taking over the hardware. The removal is integrated into existing helpers, so drivers use it automatically. I tested simplekms with x86 EFI and VESA framebuffers, which both work reliably. The fbdev console and Weston work automatically. Xorg requires manual configuration of the device. Xorgs current modesetting driver does not work with both, platform and PCI device, for the same physical hardware. Once configured, X11 works. One cosmetical issue is that simplekms's device file is card0 and the native driver's device file is card1. After simplekms has been kicked out, only card1 is left. This does not seem to be a practical problem however. TODO/IDEAS: * provide deferred takeover * provide bootsplash DRM client * make simplekms usable with ARM-EFI fbs Thomas Zimmermann (9): drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip() drm/format-helper: Add blitter functions drm: Add simplekms driver drm/simplekms: Add fbdev emulation drm/simplekms: Initialize framebuffer data from device-tree node drm/simplekms: Acquire clocks from DT device node drm/simplekms: Acquire regulators from DT device node drm: Add infrastructure for platform devices drm/simplekms: Acquire memory aperture for framebuffer MAINTAINERS | 6 + drivers/gpu/drm/Kconfig | 6 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_format_helper.c | 96 ++- drivers/gpu/drm/drm_platform.c | 118 ++++ drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- drivers/gpu/drm/tiny/Kconfig | 17 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/cirrus.c | 2 +- drivers/gpu/drm/tiny/simplekms.c | 906 +++++++++++++++++++++++++ include/drm/drm_fb_helper.h | 18 +- include/drm/drm_format_helper.h | 10 +- include/drm/drm_platform.h | 42 ++ 13 files changed, 1217 insertions(+), 8 deletions(-) create mode 100644 drivers/gpu/drm/drm_platform.c create mode 100644 drivers/gpu/drm/tiny/simplekms.c create mode 100644 include/drm/drm_platform.h -- 2.27.0

10 54

[Bug 204241] New: amdgpu fails to resume from suspend
by bugzilla-daemon＠bugzilla.kernel.org 08 Feb '21

08 Feb '21

https://bugzilla.kernel.org/show_bug.cgi?id=204241 Bug ID: 204241 Summary: amdgpu fails to resume from suspend Product: Drivers Version: 2.5 Kernel Version: 5.2.1-arch1-1-ARCH Hardware: Intel 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: kitaev(a)gmail.com Regression: No Created attachment 283863 --> https://bugzilla.kernel.org/attachment.cgi?id=283863&action=edit dmesg Computer fails to resume from suspend. >From the logs it looks like AMDGPU fails to resume. -- You are receiving this mail because: You are watching the assignee of the bug.

1 77

[Bug 202043] New: amdgpu: Vega 56 SCLK drops to 700 Mhz when undervolting
by bugzilla-daemon＠bugzilla.kernel.org 08 Feb '21

08 Feb '21

https://bugzilla.kernel.org/show_bug.cgi?id=202043 Bug ID: 202043 Summary: amdgpu: Vega 56 SCLK drops to 700 Mhz when undervolting Product: Drivers Version: 2.5 Kernel Version: 4.19.8, 4.20.0-rc6 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: antifermion(a)protonmail.com Regression: No When undervolting my Sapphire Pulse Vega 56 by just 1mV, SCLK immediately drops down to 700 Mhz and pstate 1-2 under load (`gputest /test=fur /width=1920 /height=1080`). Script to undervolt: ``` echo "s 7 1630 1199" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "c" > /sys/class/drm/card0/device/pp_od_clk_voltage ``` Stock voltage would be 1200 on the Vega 64 Bios. The same behavior can be observed with the stock Vega 56 Bios. Undervolting the memory by 1mV results in similar behavior. Overvolting by 1mV has no discernable effect. `echo r > pp_od_clk_voltage` does not work to go back to the normal behavior. Instead, I need to use `echo "s 7 1630 1200" > pp_od_clk_voltage` as above. Without undervolting, SCLK is around 1330 Mhz, which matches the behavior on Windows, where undervolting by around 150 mV is no problem and increases clock. With an increased power limit of 300W, the clocks increase to around 1100 Mhz while the card uses the full 300W. It even maxes that limit with a significant underclock/undervolt which would pull around 200W on Windows. I tested with current Manjaro (4.19.8-2-MANJARO), as well as Kubuntu 18.10 with stock (4.18) and 4.20 from https://github.com/M-Bab/linux-kernel-amdgpu-binaries. -- You are receiving this mail because: You are watching the assignee of the bug.

1 10

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2020