dri-devel December 2020

dri-devel@lists.freedesktop.org

278 participants
659 discussions

[Bug 209713] New: amdgpu drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_link_encoder.c:483 dcn10_get_dig_frontend+0x9e/0xc0 [amdgpu] when resuming from S3 state
by bugzilla-daemon＠bugzilla.kernel.org 01 Mar '21

01 Mar '21

https://bugzilla.kernel.org/show_bug.cgi?id=209713 Bug ID: 209713 Summary: amdgpu drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_l ink_encoder.c:483 dcn10_get_dig_frontend+0x9e/0xc0 [amdgpu] when resuming from S3 state Product: Drivers Version: 2.5 Kernel Version: 5.8.13-arch1-1 Hardware: x86-64 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: samy(a)lahfa.xyz Regression: No Created attachment 293025 --> https://bugzilla.kernel.org/attachment.cgi?id=293025&action=edit parts of dmesg where the call trace happens during the resume from S3 sleep state. I'm thinking that this bug is a regression since I haven't seen this call trace before on kernel older than 5.8.12-arch1-1 but I have yet to confirm this. The call trace may also happen only in a very specific way, my current computer has a USB-C Dock that is plugged in and the call trace happened when the USB-C was plugged in and the computer was suspended, then resumed. It is a Lenovo Thinkpad T495 model 20NKS28F00 with an AMD Ryzen 7 3700U and a Vega Radeon RX 10. Further comments will confirm if the call trace happens only when the USB-C Dock is plugged. As well as if this call trace happens on kernels older than 5.8.12-arch1-1. The computer does resume successfully and there is a like a minor screen glitch for a millisecond so it's not a very severe bug. -- You are receiving this mail because: You are watching the assignee of the bug.

1 21

[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

[PATCH] drm/rockchip: Require the YTR modifier for AFBC
by Alyssa Rosenzweig 26 Feb '21

26 Feb '21

The AFBC decoder used in the Rockchip VOP assumes the use of the YUV-like colourspace transform (YTR). YTR is lossless for RGB(A) buffers, which covers the RGBA8 and RGB565 formats supported in vop_convert_afbc_format. Use of YTR is signaled with the AFBC_FORMAT_MOD_YTR modifier, which prior to this commit was missing. As such, a producer would have to generate buffers that do not use YTR, which the VOP would erroneously decode as YTR, leading to severe visual corruption. The upstream AFBC support was developed against a captured frame, which failed to exercise modifier support. Prior to bring-up of AFBC in Mesa (in the Panfrost driver), no open userspace respected modifier reporting. As such, this change is not expected to affect broken userspaces. Tested on RK3399 with Panfrost and Weston. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig(a)collabora.com> --- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h index 4a2099cb5..857d97cdc 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h @@ -17,9 +17,20 @@ #define NUM_YUV2YUV_COEFFICIENTS 12 +/* AFBC supports a number of configurable modes. Relevant to us is block size + * (16x16 or 32x8), storage modifiers (SPARSE, SPLIT), and the YUV-like + * colourspace transform (YTR). 16x16 SPARSE mode is always used. SPLIT mode + * could be enabled via the hreg_block_split register, but is not currently + * handled. The colourspace transform is implicitly always assumed by the + * decoder, so consumers must use this transform as well. + * + * Failure to match modifiers will cause errors displaying AFBC buffers + * produced by conformant AFBC producers, including Mesa. + */ #define ROCKCHIP_AFBC_MOD \ DRM_FORMAT_MOD_ARM_AFBC( \ AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | AFBC_FORMAT_MOD_SPARSE \ + | AFBC_FORMAT_MOD_YTR \ ) enum vop_data_format { -- 2.28.0

8 18

[v2] drm/msm/disp/dpu1: turn off vblank irqs aggressively in dpu driver
by Kalyan Thota 16 Feb '21

16 Feb '21

Set the flag vblank_disable_immediate = true to turn off vblank irqs immediately as soon as drm_vblank_put is requested so that there are no irqs triggered during idle state. This will reduce cpu wakeups and help in power saving. To enable vblank_disable_immediate flag the underlying KMS driver needs to support high precision vblank timestamping and also a reliable way of providing vblank counter which is incrementing at the leading edge of vblank. This patch also brings in changes to support vblank_disable_immediate requirement in dpu driver. Changes in v1: - Specify reason to add vblank timestamp support. (Rob) - Add changes to provide vblank counter from dpu driver. Signed-off-by: Kalyan Thota <kalyan_t(a)codeaurora.org> --- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 80 ++++++++++++++++++++++ drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 30 ++++++++ drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 11 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 1 + .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 17 +++++ drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 ++ 6 files changed, 144 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c index d4662e8..9a80981 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c @@ -65,6 +65,83 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc) kfree(dpu_crtc); } +static struct drm_encoder *get_encoder_from_crtc(struct drm_crtc *crtc) +{ + struct drm_device *dev = crtc->dev; + struct drm_encoder *encoder; + + drm_for_each_encoder(encoder, dev) + if (encoder->crtc == crtc) + return encoder; + + return NULL; +} + +static u32 dpu_crtc_get_vblank_counter(struct drm_crtc *crtc) +{ + struct drm_encoder *encoder; + + encoder = get_encoder_from_crtc(crtc); + if (!encoder) { + DRM_ERROR("no encoder found for crtc %d\n", crtc->index); + return false; + } + + return dpu_encoder_get_frame_count(encoder); +} + +static bool dpu_crtc_get_scanout_position(struct drm_crtc *crtc, + bool in_vblank_irq, + int *vpos, int *hpos, + ktime_t *stime, ktime_t *etime, + const struct drm_display_mode *mode) +{ + unsigned int pipe = crtc->index; + struct drm_encoder *encoder; + int line, vsw, vbp, vactive_start, vactive_end, vfp_end; + + encoder = get_encoder_from_crtc(crtc); + if (!encoder) { + DRM_ERROR("no encoder found for crtc %d\n", pipe); + return false; + } + + vsw = mode->crtc_vsync_end - mode->crtc_vsync_start; + vbp = mode->crtc_vtotal - mode->crtc_vsync_end; + + /* + * the line counter is 1 at the start of the VSYNC pulse and VTOTAL at + * the end of VFP. Translate the porch values relative to the line + * counter positions. + */ + + vactive_start = vsw + vbp + 1; + vactive_end = vactive_start + mode->crtc_vdisplay; + + /* last scan line before VSYNC */ + vfp_end = mode->crtc_vtotal; + + if (stime) + *stime = ktime_get(); + + line = dpu_encoder_get_linecount(encoder); + + if (line < vactive_start) + line -= vactive_start; + else if (line > vactive_end) + line = line - vfp_end - vactive_start; + else + line -= vactive_start; + + *vpos = line; + *hpos = 0; + + if (etime) + *etime = ktime_get(); + + return true; +} + static void _dpu_crtc_setup_blend_cfg(struct dpu_crtc_mixer *mixer, struct dpu_plane_state *pstate, struct dpu_format *format) { @@ -1243,6 +1320,8 @@ static const struct drm_crtc_funcs dpu_crtc_funcs = { .early_unregister = dpu_crtc_early_unregister, .enable_vblank = msm_crtc_enable_vblank, .disable_vblank = msm_crtc_disable_vblank, + .get_vblank_timestamp = drm_crtc_vblank_helper_get_vblank_timestamp, + .get_vblank_counter = dpu_crtc_get_vblank_counter, }; static const struct drm_crtc_helper_funcs dpu_crtc_helper_funcs = { @@ -1251,6 +1330,7 @@ static const struct drm_crtc_helper_funcs dpu_crtc_helper_funcs = { .atomic_check = dpu_crtc_atomic_check, .atomic_begin = dpu_crtc_atomic_begin, .atomic_flush = dpu_crtc_atomic_flush, + .get_scanout_position = dpu_crtc_get_scanout_position, }; /* initialize crtc */ diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c index f7f5c25..5cd3f31 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c @@ -425,6 +425,36 @@ int dpu_encoder_helper_unregister_irq(struct dpu_encoder_phys *phys_enc, return 0; } +int dpu_encoder_get_frame_count(struct drm_encoder *drm_enc) +{ + struct dpu_encoder_virt *dpu_enc; + struct dpu_encoder_phys *phys; + int framecount = 0; + + dpu_enc = to_dpu_encoder_virt(drm_enc); + phys = dpu_enc ? dpu_enc->cur_master : NULL; + + if (phys && phys->ops.get_frame_count) + framecount = phys->ops.get_frame_count(phys); + + return framecount; +} + +int dpu_encoder_get_linecount(struct drm_encoder *drm_enc) +{ + struct dpu_encoder_virt *dpu_enc; + struct dpu_encoder_phys *phys; + int linecount = 0; + + dpu_enc = to_dpu_encoder_virt(drm_enc); + phys = dpu_enc ? dpu_enc->cur_master : NULL; + + if (phys && phys->ops.get_line_count) + linecount = phys->ops.get_line_count(phys); + + return linecount; +} + void dpu_encoder_get_hw_resources(struct drm_encoder *drm_enc, struct dpu_encoder_hw_resources *hw_res) { diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h index b491346..99a5d73 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h @@ -156,5 +156,16 @@ void dpu_encoder_prepare_commit(struct drm_encoder *drm_enc); */ void dpu_encoder_set_idle_timeout(struct drm_encoder *drm_enc, u32 idle_timeout); +/** + * dpu_encoder_get_linecount - get interface line count for the encoder. + * @drm_enc: Pointer to previously created drm encoder structure + */ +int dpu_encoder_get_linecount(struct drm_encoder *drm_enc); + +/** + * dpu_encoder_get_frame_count - get interface frame count for the encoder. + * @drm_enc: Pointer to previously created drm encoder structure + */ +int dpu_encoder_get_frame_count(struct drm_encoder *drm_enc); #endif /* __DPU_ENCODER_H__ */ diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h index f8f2515..ecbc4be 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h @@ -143,6 +143,7 @@ struct dpu_encoder_phys_ops { void (*prepare_idle_pc)(struct dpu_encoder_phys *phys_enc); void (*restore)(struct dpu_encoder_phys *phys); int (*get_line_count)(struct dpu_encoder_phys *phys); + int (*get_frame_count)(struct dpu_encoder_phys *phys); }; /** diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c index 9a69fad..f983595 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c @@ -658,6 +658,22 @@ static int dpu_encoder_phys_vid_get_line_count( return phys_enc->hw_intf->ops.get_line_count(phys_enc->hw_intf); } +static int dpu_encoder_phys_vid_get_frame_count( + struct dpu_encoder_phys *phys_enc) +{ + struct intf_status s = {0}; + + if (!dpu_encoder_phys_vid_is_master(phys_enc)) + return -EINVAL; + + if (!phys_enc->hw_intf || !phys_enc->hw_intf->ops.get_status) + return -EINVAL; + + phys_enc->hw_intf->ops.get_status(phys_enc->hw_intf, &s); + + return s.frame_count; +} + static void dpu_encoder_phys_vid_init_ops(struct dpu_encoder_phys_ops *ops) { ops->is_master = dpu_encoder_phys_vid_is_master; @@ -676,6 +692,7 @@ static void dpu_encoder_phys_vid_init_ops(struct dpu_encoder_phys_ops *ops) ops->handle_post_kickoff = dpu_encoder_phys_vid_handle_post_kickoff; ops->needs_single_flush = dpu_encoder_phys_vid_needs_single_flush; ops->get_line_count = dpu_encoder_phys_vid_get_line_count; + ops->get_frame_count = dpu_encoder_phys_vid_get_frame_count; } struct dpu_encoder_phys *dpu_encoder_phys_vid_init( diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c index 374b0e8..764a773 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c @@ -14,6 +14,7 @@ #include <drm/drm_crtc.h> #include <drm/drm_file.h> +#include <drm/drm_vblank.h> #include "msm_drv.h" #include "msm_mmu.h" @@ -1020,6 +1021,10 @@ static int dpu_kms_hw_init(struct msm_kms *kms) */ dev->mode_config.allow_fb_modifiers = true; + dev->max_vblank_count = 0; + /* Disable vblank irqs aggressively for power-saving */ + dev->vblank_disable_immediate = true; + /* * _dpu_kms_drm_obj_init should create the DRM related objects * i.e. CRTCs, planes, encoders, connectors and so forth -- 2.7.4

3 7

[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

soc: mediatek: cmdq: add address shift in jump
by Yongqiang Niu 15 Feb '21

15 Feb '21

Change since v1: -move out from mt8192 seri series Yongqiang Niu (1): soc: mediatek: cmdq: add address shift in jump drivers/mailbox/mtk-cmdq-mailbox.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.8.1.1.dirty

3 4

[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

[PATCH 0/3] drm/v3d: CL/CSD job timeout fixes
by Yukimasa Sugizaki 11 Feb '21

11 Feb '21

From: Yukimasa Sugizaki <ysugi(a)idein.jp> Hi, The current V3D scheduler has two issues where CSD jobs are resubmitted regardless of the previous timed-out flag, and where the timer is not restarted for timed-out CL/CSD jobs (which we wish to continue running). The second one is due to the DRM scheduler API change and fixed in a similar way to [1]. A kernel command-line option to set the default timeout value is also added. I tested this patchset with Piglit and our CSD programs in [2]. Because it is hard to get the current upstream kernel to work on BCM2711, I used the kernel from rpi-5.8.y tree [3]. There still are problems where some Piglit tests get longer time to finish running (3610 minutes to 3650 minutes in total), and some ones result in the invalid memory read errors with unknown reasons: [17086.230959] v3d fec00000.v3d: MMU error from client CLE (4) at 0xac1000, pte invalid [17086.238722] v3d fec00000.v3d: MMU error from client CLE (4) at 0x1b61000, pte invalid [18643.303188] v3d fec00000.v3d: MMU error from client L2T (0) at 0x15bff00, pte invalid [18655.933748] v3d fec00000.v3d: MMU error from client L2T (0) at 0x15bff00, pte invalid However, most of the CL/CSD programs are now working happily without kernel warnings and errors. Regards, Sugizaki [1] https://patchwork.kernel.org/patch/11732895/ [2] https://github.com/Idein/py-videocore6 [3] https://github.com/raspberrypi/linux/tree/rpi-5.8.y Yukimasa Sugizaki (3): drm/v3d: Don't resubmit guilty CSD jobs drm/v3d: Correctly restart the timer when progress is made drm/v3d: Add job timeout module param drivers/gpu/drm/v3d/v3d_sched.c | 62 +++++++++++++++++++++++++++++++++-------- 1 file changed, 51 insertions(+), 11 deletions(-) -- 2.7.4

3 9

[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

← Newer
1
...
7
8
9
10
11
12
13
...
66
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel December 2020