dri-devel July 2017

dri-devel@lists.freedesktop.org

212 participants
1542 discussions

[Bug 172421] New: radeon: allow to set the TMDS frequency by a special kernel parameter
by bugzilla-daemon＠bugzilla.kernel.org 19 Jun '22

19 Jun '22

https://bugzilla.kernel.org/show_bug.cgi?id=172421 Bug ID: 172421 Summary: radeon: allow to set the TMDS frequency by a special kernel parameter Product: Drivers Version: 2.5 Kernel Version: 4.8.0-rc7+ Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: enhancement Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: estellnb(a)elstel.org Regression: No Despite different claims by ATI in 2016 Radeon R5 230 graphics cards featuring HDMI, DVI and VGA had originally been sold as 4K-ready up to the year 2015. The only prove I have for this is a comercial invoice from Nexus Mobile and a packaging card. As far as I know Radeon R5 230 cards currently sold can still be run stable and reliable under UltraHD provided that you apply the right kernel patch (see for the attachement). Unfortunately neither my former merchant nor ATI have responded about my questions concerning this change in trade and marketing policy. My request would now be to integrate the provided patch into the mainline kernel. It does not change the behaviour of the radeon driver unless you specify a nonzero value for the radeon.hdmimhz parameter. If you do I have tested the R5 230 cards I have to run stable and reliably for days. At least the 2GB variant of this card has largely sufficient resources for proficient desktop computing under UltraHD including image manipulation in 3840x2160. While never officially discussed for the radeon driver nouveau is already implementing a similar parameter called nouveau.hdmimhz since kernel 4.5.x. Though it thereby becomes possible to specify a hdmimhz that is far above the cards technical possibilties the nouveau developers I have talked with say that it would rarely be possible to damage any card by overcloking the TMDS. In deed I have successfully been overclocking my GeForce 9600M GT to feature 4K/2160p. Even specifying values considerable higher than 225MHz did not damage my GeForce 9600M GT though the screen stayed black upon the nouveau driver initialization. While the Radeon R5 230 works well at 297MHz (as long as you specify that via radeon.hdmimhz) I have similarly to the GeForce 9600M GT tried to overclock a Radeon R7 240. It did produce stable images at a higher hdmimhz like 330 though the HDMI input of my monitor features no more than 30Hz at 3840x2160 (tested with or without a DP-adapter). While it remains questionable if the provided patch can improve things for newer Radeon cards I would believe it to be beneficial for some elder cards. At least it is known to be beneficial for the R5 230 initially marketed as 4K-ready. The according radeon patch provided with this report has so far already been accepted by the Mageia 6 distribution. Though the attached patch is for application at the current 4.8.0-rcX+ kernels most of my machines that rely on it still run with 4.6.0. -- You are receiving this mail because: You are watching the assignee of the bug.

2 23

[RFC 00/21] Renesas r8a7795/Salvator-X HDMI output prototype
by Ulrich Hecht 26 Apr '22

26 Apr '22

Hi! This is a prototype of HDMI output support for the Renesas r8a7795 SoC and Salvator-X board. It is based on the renesas-devel-20160516-v4.6 tree and includes the bridge API conversion patches to the adv7511 and rcar-du drivers written by Archit Taneja. The obvious issue with this series is the awkward binding of the dw-hdmi bridge IP, which can be seen in the "drm: rcar-du: Add dw_hdmi driver startup" patch. Any comments on how to implement this interface properly are much appreciated. Functionally, this series works as expected on both connectors, but EDID reading is currently broken. CU Uli Archit Taneja (2): drm: rcar-du: Remove i2c slave encoder interface for hdmi encoder drm: i2c: adv7511: Convert to drm_bridge Koji Matsuoka (12): media: vsp1: Set format to RPF input source drm: bridge/dw_hdmi: Fix R-Car Gen3 device support drm: rcar-du: Add R8A7795 device support drm: rcar-du: Add dw_hdmi driver startup drm: rcar-du: Add DPLL support drm: rcar-du: Fix display registers for R-Car Gen3 drm: rcar-du: Fix VSP plane number per devices drm: rcar-du: Fix VSP feed plane number drm: rcar-du: Add pixel format support drm: rcar-du: Fix display max size to 4096x2160 size arm64: dts: salvator-x: Add DU pins, HDMI connectors and encoder arm64: configs: Enable R-Car DU related config Kuninori Morimoto (1): arm64: defconfig: add VIDEO_RENESAS_FCP Ulrich Hecht (5): v4l: vsp1: Change VSP1 LIF linebuffer FIFO pinctrl: sh-pfc: r8a7795: Add DU support pinctrl: sh-pfc: r8a7795: Add HDMI CEC support arm64: dts: r8a7795: Add HDMI encoder support arm64: dts: r8a7795: add HDMI support to DU Vladimir Zapolskiy (1): drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 107 +++++ arch/arm64/boot/dts/renesas/r8a7795.dtsi | 33 +- arch/arm64/configs/defconfig | 15 + drivers/gpu/drm/bridge/dw-hdmi.c | 489 +++++++++++++++++++-- drivers/gpu/drm/i2c/adv7511.c | 224 ++++++---- drivers/gpu/drm/rcar-du/Kconfig | 2 + drivers/gpu/drm/rcar-du/Makefile | 3 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 97 +++- drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 12 +- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 20 +- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 6 +- drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 12 +- drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 13 +- drivers/gpu/drm/rcar-du/rcar_du_group.c | 5 + drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c | 117 ----- drivers/gpu/drm/rcar-du/rcar_du_hdmicon.h | 31 -- drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 260 ++++++++--- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 68 ++- drivers/gpu/drm/rcar-du/rcar_du_kms.h | 1 + drivers/gpu/drm/rcar-du/rcar_du_plane.c | 8 +- drivers/gpu/drm/rcar-du/rcar_du_plane.h | 7 +- drivers/gpu/drm/rcar-du/rcar_du_regs.h | 19 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 51 ++- drivers/media/platform/vsp1/vsp1_drm.c | 6 + drivers/media/platform/vsp1/vsp1_lif.c | 6 +- drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 113 +++++ include/drm/bridge/dw_hdmi.h | 9 + 27 files changed, 1388 insertions(+), 346 deletions(-) delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.h -- 2.7.4

6 28

[Bug 121831] New: Several kmemcheck: Caught 64-bit read from uninitialized memory in radeo
by bugzilla-daemon＠bugzilla.kernel.org 17 Feb '22

17 Feb '22

https://bugzilla.kernel.org/show_bug.cgi?id=121831 Bug ID: 121831 Summary: Several kmemcheck: Caught 64-bit read from uninitialized memory in radeo Product: Drivers Version: 2.5 Kernel Version: 4.7-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: casteyde.christian(a)free.fr Regression: No Created attachment 222631 --> https://bugzilla.kernel.org/attachment.cgi?id=222631&action=edit dmesg output Slackware 64 14.1 With kmemcheck activated, I get the following warnings: [ 1185.586288] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff8801c2cd5d08) [ 1185.586292] 000000000000000060f11c81ffffffff68509ab40188ffff0100010001000000 [ 1185.586314] i i i i i i i i u u u u u u u u u u u u u u u u u u u u u u u u [ 1185.586335] ^ [ 1185.586337] RIP: 0010:[<ffffffff8158521d>] [<ffffffff8158521d>] fence_signal+0x1d/0xe0 [ 1185.586343] RSP: 0018:ffff8801b560fa20 EFLAGS: 00010282 [ 1185.586345] RAX: 0000000000000003 RBX: ffff8801c2cd5cc0 RCX: 0000000000000002 [ 1185.586346] RDX: 0000000080000002 RSI: ffff8801b5591fa0 RDI: ffff8801c2cd5cc0 [ 1185.586348] RBP: ffff8801b560fa50 R08: 0000000000000000 R09: 0000000000000001 [ 1185.586349] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000003 [ 1185.586350] R13: ffff8801c2cd5cc0 R14: 00000000021ae410 R15: ffff8800a9490000 [ 1185.586352] FS: 00007fe3e0e408c0(0000) GS:ffff8801c7400000(0000) knlGS:0000000000000000 [ 1185.586353] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1185.586355] CR2: ffff8801c7060c90 CR3: 00000001b558d000 CR4: 00000000000406f0 [ 1185.586356] [<ffffffff8148cb7a>] radeon_fence_signaled+0x4a/0x80 [ 1185.586360] [<ffffffff814f5cf7>] radeon_sa_bo_free+0x37/0xb0 [ 1185.586364] [<ffffffff81547f39>] radeon_ib_free+0x29/0x40 [ 1185.586369] [<ffffffff814a5105>] radeon_cs_parser_fini+0xc5/0x120 [ 1185.586372] [<ffffffff814a597b>] radeon_cs_ioctl+0x2fb/0x7d0 [ 1185.586374] [<ffffffff81449dce>] drm_ioctl+0x13e/0x530 [ 1185.586378] [<ffffffff81471b17>] radeon_drm_ioctl+0x47/0x80 [ 1185.586381] [<ffffffff811aebce>] do_vfs_ioctl+0x8e/0x670 [ 1185.586384] [<ffffffff811af1ec>] SyS_ioctl+0x3c/0x70 [ 1185.586386] [<ffffffff819434a5>] entry_SYSCALL_64_fastpath+0x18/0xa8 [ 1185.586391] [<ffffffffffffffff>] 0xffffffffffffffff [ 1197.075973] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff8800a2cf4ac8) [ 1197.075977] 0200000000000000ffffffff3f000000ffffffff3f0000000000000000000000 [ 1197.075999] i i i i i i i i u u u u u u u u u u u u u u u u u u u u u u u u [ 1197.076019] ^ [ 1197.076021] RIP: 0010:[<ffffffff81584fc6>] [<ffffffff81584fc6>] fence_signal_locked+0x16/0xc0 [ 1197.076028] RSP: 0018:ffff8801c7403d18 EFLAGS: 00010082 [ 1197.076029] RAX: 000000000000001a RBX: ffff8800a2cf4b10 RCX: 0000000000000000 [ 1197.076031] RDX: ffff8800a9490000 RSI: 0000000000000003 RDI: ffff8800a2cf4a80 [ 1197.076032] RBP: ffff8801c7403d48 R08: 0000000000000000 R09: 0000000000000001 [ 1197.076033] R10: 0000000000000000 R11: ffffffff8200b540 R12: ffff8800a2cf4a80 [ 1197.076034] R13: ffff8800a9491ea8 R14: 0000000000000000 R15: 0000000000000003 [ 1197.076036] FS: 0000000000000000(0000) GS:ffff8801c7400000(0000) knlGS:0000000000000000 [ 1197.076038] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1197.076039] CR2: ffff8801c29c016c CR3: 0000000002006000 CR4: 00000000000406f0 [ 1197.076040] [<ffffffff8148c571>] radeon_fence_check_signaled+0x41/0x80 [ 1197.076044] [<ffffffff810da49d>] __wake_up_common+0x4d/0x80 [ 1197.076334] [<ffffffff810da504>] __wake_up+0x34/0x50 [ 1197.076336] [<ffffffff8148c6c6>] radeon_fence_process+0x26/0x30 [ 1197.076338] [<ffffffff814e0caa>] evergreen_irq_process+0x92a/0x17e0 [ 1197.076342] [<ffffffff814a4309>] radeon_driver_irq_handler_kms+0x19/0x40 [ 1197.076345] [<ffffffff810f15e4>] handle_irq_event_percpu+0x64/0x100 [ 1197.076349] [<ffffffff810f16b4>] handle_irq_event+0x34/0x60 [ 1197.076352] [<ffffffff810f466e>] handle_edge_irq+0xbe/0x150 [ 1197.076356] [<ffffffff810617f8>] handle_irq+0x68/0x180 [ 1197.076360] [<ffffffff81060ff8>] do_IRQ+0x68/0x130 [ 1197.076362] [<ffffffff81943e09>] ret_from_intr+0x0/0x19 [ 1197.076367] [<ffffffff816fec82>] cpuidle_enter+0x12/0x20 [ 1197.076371] [<ffffffff810db0f5>] call_cpuidle+0x25/0x40 [ 1197.076373] [<ffffffff810db3c3>] cpu_startup_entry+0x1b3/0x290 [ 1197.076375] [<ffffffff8193ad5c>] rest_init+0x12c/0x140 [ 1197.076379] [<ffffffff82299de5>] start_kernel+0x354/0x361 [ 1197.076384] [<ffffffff822992ae>] x86_64_start_reservations+0x2f/0x31 [ 1197.076387] [<ffffffff8229939b>] x86_64_start_kernel+0xeb/0xf0 [ 1197.076390] [<ffffffffffffffff>] 0xffffffffffffffff [ 1207.836251] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff8800a2cf4348) etc. In gdb: (gdb) l *0xffffffff8158521d 0xffffffff8158521d is in fence_signal (drivers/dma-buf/fence.c:114). 109 unsigned long flags; 110 111 if (!fence) 112 return -EINVAL; 113 114 if (!ktime_to_ns(fence->timestamp)) { 115 fence->timestamp = ktime_get(); 116 smp_mb__before_atomic(); 117 } -- You are receiving this mail because: You are watching the assignee of the bug.

2 3

[PATCH 1/3] drm/dp/mst: Handle errors from drm_atomic_get_private_obj_state() correctly
by ville.syrjala＠linux.intel.com 12 Jan '22

12 Jan '22

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> On failure drm_atomic_get_private_obj_state() returns and error pointer instead of NULL. Adjust the checks in the callers to match. Cc: stable(a)vger.kernel.org Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Cc: Harry Wentland <harry.wentland(a)amd.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Fixes: edb1ed1ab7d3 ("drm/dp: Add DP MST helpers to atomically find and release vcpi slots") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/drm_dp_mst_topology.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index bfd237c15e76..18cecd94acb6 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -2515,8 +2515,8 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state, int req_slots; topology_state = drm_atomic_get_mst_topology_state(state, mgr); - if (topology_state == NULL) - return -ENOMEM; + if (IS_ERR(topology_state)) + return PTR_ERR(topology_state); port = drm_dp_get_validated_port_ref(mgr, port); if (port == NULL) @@ -2555,8 +2555,8 @@ int drm_dp_atomic_release_vcpi_slots(struct drm_atomic_state *state, struct drm_dp_mst_topology_state *topology_state; topology_state = drm_atomic_get_mst_topology_state(state, mgr); - if (topology_state == NULL) - return -ENOMEM; + if (IS_ERR(topology_state)) + return PTR_ERR(topology_state); /* We cannot rely on port->vcpi.num_slots to update * topology_state->avail_slots as the port may not exist if the parent -- 2.13.0

4 7

[Bug 53391] New: nouveau: wrong display output order
by bugzilla-daemon＠bugzilla.kernel.org 08 Dec '21

08 Dec '21

https://bugzilla.kernel.org/show_bug.cgi?id=53391 Summary: nouveau: wrong display output order Product: Drivers Version: 2.5 Kernel Version: 3.8-rc6 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: stijn+bugs(a)linux-ipv6.be Regression: No My graphics card is a Gainward GTX480 (http://www.gainward.com/main/vgapro.php?id=238). It has 2 DVI outputs, and 1 mini HDMI output. The DVI outputs are numbered on the card, with DVI 1 being the closest to the PCIe slot, then DVI 2, and finally the mini HDMI. My primary (left) monitor, is connected to DVI 1, my secondary (right) monitor to DVI 2. When I boot the computer, the BIOS initializes and uses the monitor on DVI 1. Grub is displayed on the primary monitor, and the kernel initially outputs to the primary monitor as well. However, as soon as the nouveau module is loaded, the primary monitor goes to standby and the kernel now uses the secondary monitor (on DVI 2) as primary. When X starts (no Xorg.conf file), it is also displayed on the secondary monitor. When using either efifb, vesafb or uvesafb, the monitor on DVI 1 is always the primary monitor. X with nvidia.ko also uses DVI 1 as the primary display. Finally, when booting Windows, the startup screen is also displayed on the monitor connected to DVI 1. Here comes the weird part: when I am in X, and run xrandr, it does show 3 connected devices: DVI-I-1, DVI-I-2, and HDMI-1, with DVI-I-2 being the only active one. So it seems that in X, the output order is correct, but with nouveaufb the DVI connectors are swapped. I will attach the output of dmesg here. If anything else is needed, please let me know and I'll be happy to add it. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 13

[Bug 85421] New: radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox.
by bugzilla-daemon＠bugzilla.kernel.org 24 Sep '21

24 Sep '21

https://bugzilla.kernel.org/show_bug.cgi?id=85421 Bug ID: 85421 Summary: radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox. Product: Drivers Version: 2.5 Kernel Version: 3.16.3 Hardware: x86-64 OS: Linux Tree: Fedora Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: htl10(a)users.sourceforge.net Regression: No Created attachment 152191 --> https://bugzilla.kernel.org/attachment.cgi?id=152191&action=edit /var/log/messages from radeon 0000:00:01.0: ring 0 stalled to reboot. I was away from the computer when the radeon dri driver crashed; I left a fair number of firefox windows on/tab, some of them may have videos (from BBC news web site) and animated gifs from another web site on; but it crashed about 5-10 minutes after I was away and I was aware of it because the laptop blipped. # lspci | grep VGA 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R3 Graphics] some excerpt from the attached logs are: ... [ 8770.250116] radeon 0000:00:01.0: ring 0 stalled for more than 10012msec [ 8770.250128] radeon 0000:00:01.0: GPU lockup (waiting for 0x0000000000056034 last fence id 0x0000000000056031 on ring 0) [ 8770.298635] radeon 0000:00:01.0: Saved 14196 dwords of commands on ring 0. [ 8770.298663] radeon 0000:00:01.0: GPU softreset: 0x0000000C ... [ 8770.313299] radeon 0000:00:01.0: GPU reset succeeded, trying to resume ... [ 8770.339724] [drm] ring test on 0 succeeded in 3 usecs [ 8770.518568] [drm:cik_ring_test] *ERROR* radeon: ring 1 test failed (scratch(0x3010C)=0xCAFEDEAD) [ 8770.752885] [drm:cik_sdma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD) [ 8770.752892] [drm:cik_resume] *ERROR* cik startup failed on resume [ 8780.753181] radeon 0000:00:01.0: ring 0 stalled for more than 10001msec [ 8780.753193] radeon 0000:00:01.0: GPU lockup (waiting for 0x00000000000560f7 last fence id 0x0000000000056031 on ring 0) [ 8780.753199] [drm:cik_ib_test] *ERROR* radeon: fence wait failed (-35). [ 8780.753209] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35). [ 8780.753215] radeon 0000:00:01.0: ib ring test failed (-35). [ 8780.762131] radeon 0000:00:01.0: GPU softreset: 0x0000000C ... The kernel is a largely fedora 3.16.3-200 one grabbed from the koji srpm but with the additional patch from https://bugzilla.kernel.org/show_bug.cgi?id=71051#c8 drv ati 7.4.0 , mesa 10.2.8, glamor from git 347ef4 . -- You are receiving this mail because: You are watching the assignee of the bug.

1 41

[Bug 107381] New: radeon VCE init error (-110) -- AMD/Intel Mars Hybrid Graphics
by bugzilla-daemon＠bugzilla.kernel.org 06 Sep '21

06 Sep '21

https://bugzilla.kernel.org/show_bug.cgi?id=107381 Bug ID: 107381 Summary: radeon VCE init error (-110) -- AMD/Intel Mars Hybrid Graphics Product: Drivers Version: 2.5 Kernel Version: 4.3 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: schmod(a)gmail.com Regression: No Created attachment 192261 --> https://bugzilla.kernel.org/attachment.cgi?id=192261&action=edit dmesg output Since upgrading to Ubuntu 15.10, I have encountered graphics performance issues, and have occasionally experienced lockups during boot. I have encountered this issue on kernel 4.2.0 and 4.3.0, and it seems to have affected users on other distributions as well: https://bugs.launchpad.net/fedora/+source/linux/+bug/1512848 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803087 https://bugzilla.redhat.com/show_bug.cgi?id=1262649 Notably, this issue seems to primarily impact users with The ATI "Mars" chipset, on machines that have an Intel/AMD hybrid graphics hardware configuration. This shows up in dmesg (full log attached, because there's a fair amount of seemingly-useful context): [ 4.917369] radeon 0000:01:00.0: VCE init error (-110). Some other context from my PC: $ xrandr --listproviders Providers: number : 3 Provider 0: id: 0x6a cap: 0x9, Source Output, Sink Offload crtcs: 4 outputs: 5 associated providers: 2 name:Intel Provider 1: id: 0x41 cap: 0x6, Sink Output, Source Offload crtcs: 2 outputs: 0 associated providers: 2 name:radeon Provider 2: id: 0x41 cap: 0x6, Sink Output, Source Offload crtcs: 2 outputs: 0 associated providers: 2 name:radeon $ lspci -k (trimmed to omit likely-irrelevant devices) 00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09) Subsystem: Samsung Electronics Co Ltd Device c0e6 Kernel driver in use: ivb_uncore 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09) Kernel driver in use: pcieport 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) DeviceName: Onboard IGD Subsystem: Samsung Electronics Co Ltd Device c0e6 Kernel driver in use: i915 01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Mars [Radeon HD 8670A/8670M/8750M] (rev ff) Kernel driver in use: radeon -- You are receiving this mail because: You are watching the assignee of the bug.

1 23

[Bug 51381] New: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
by bugzilla-daemon＠bugzilla.kernel.org 11 May '21

11 May '21

https://bugzilla.kernel.org/show_bug.cgi?id=51381 Summary: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo Product: Drivers Version: 2.5 Kernel Version: Linux version 3.6.9-1-ARCH (tobias@T-POWA-LX) (gcc version 4.7.2 (GCC) ) #1 SMP PREEMPT Tue Dec 4 08:04:10 CET 2012 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: a(a)anrd.net Regression: Yes Created an attachment (id=88591) --> (https://bugzilla.kernel.org/attachment.cgi?id=88591) journald log After updating from 3.6.6 to 3.6.9 my laptop with Intel graphics and ATI HD 5650 will not resume from suspend. I use vgaswitcheroo to disable the ATI card at boot. On resume the computer almost hangs (I can press power button and wait 5 minutes for a proper shutdown, but no other interaction is possible). It logs a lot of messages saying: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [drm:atom_execute_table_locked] *ERROR* atombios stuck executing D098 (len 72, WS 0, PS 0) @ 0xD0C7 Steps to reproduce: echo "OFF" > /sys/kernel/debug/vgaswitcheroo/switch [suspend and resume] Actual results: Almost freeze. Expected results: Resume and work as normal. Log is attached, but if you need anything else just ask. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 62

[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

[Bug 94061] New: [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
by bugzilla-daemon＠bugzilla.kernel.org 03 Dec '20

03 Dec '20

https://bugzilla.kernel.org/show_bug.cgi?id=94061 Bug ID: 94061 Summary: [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst Product: Drivers Version: 2.5 Kernel Version: 3.14.x ... 3.19. 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: abcdmail(a)freenet.de Regression: No With all kernel versions >= 3.14 (I didn't test versions below), radeon / dpm consumes about 6 W more compared to catalyst in idle mode (X-server 1.15 / 1.16) with Kaveri graphics (AMD A10-7800 Radeon R7). Idle mode: Xorg runs (KDE 4.11.x), screen saver off, static screen, load: 0.0 If the screen is turned off by X, the power consumption finally reaches the same level as with catalyst. It's raising immediately again at the moment the screen is switched on again by X. Seams the lowest rate is never reached as long as even a static screen has to be drawn - but it should! -- You are receiving this mail because: You are watching the assignee of the bug.

1 12

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2017