dri-devel June 2021

dri-devel@lists.freedesktop.org

341 participants
878 discussions

[PATCH 0/2] drm/etnaviv: add GC7000 r6202 support
by Michael Walle 06 Jul '21

06 Jul '21

This is the first step to bring GPU support to the NXP LS1028A SoC. It features a Mali DP500, a Vivante GC7000 and has one DisplayPort output which is driven by a Cadence MHDP controller and PHY. This was briefly tested with glmark2, a patched mesa kmsro driver [1] to support the mali DP500/GC7000 duo, fixes from mesa merge request 9255 [2] and using ETNA_MESA_DEBUG=no_supertile,no_ts. [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11419 [2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9255 Michael Walle (2): drm/etnaviv: add HWDB entry for GC7000 r6202 drm/etnaviv: add clock gating workaround for GC7000 r6202 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 6 +++++ drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 31 ++++++++++++++++++++++++++ 2 files changed, 37 insertions(+) -- 2.20.1

2 3

XDC 2021: Registration & Call for Proposals now open!
by Szwichtenberg, Radoslaw 06 Jul '21

06 Jul '21

Hello! Registration & Call for Proposals are now open for XDC 2021, which will take place on September 15-17, 2021. This year we will repeat as virtual event. https://indico.freedesktop.org/event/1/ As usual, the conference is free of charge and open to the general public. If you plan on attending, please make sure to register as early as possible! In order to register as attendee, you will therefore need to register via the XDC website. As XDC moved to a new Indico infrastructure, if you previously registered on the XDC website, you need to create a new account again. https://indico.freedesktop.org/event/1/registrations/1/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2021. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://indico.freedesktop.org/event/1/abstracts/ The deadline for submissions is Sunday, 4 July 2021. Last year we modified our Reimbursement Policy to accept speaker expenses for X.Org virtual events like XDC 2021. Check it out here: https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ If you have any questions, please send me an email to radoslaw.szwichtenberg(a)intel.com<mailto:radoslaw.szwichtenberg@intel.com>, adding on CC the X.org board (board at foundation.x.org). And don't forget, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/XOrgDevConf Best, Radek P.S: a DNS redirection (xdc2021.x.org) is work in progress. Please use the mentioned links for the moment. Radosław Szwichtenberg ------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Slowackiego 173, 80-298 Gdansk KRS 101882 - NIP 957-07-52-316

2 4

[PATCH] drm: vc4: Fix pixel-wrap issue with DVP teardown
by Maxime Ripard 06 Jul '21

06 Jul '21

From: Tim Gover <tim.gover(a)raspberrypi.com> Adjust the DVP enable/disable sequence to avoid a pixel getting stuck in an internal, non resettable FIFO within PixelValve when changing HDMI resolution. The blank pixels features of the DVP can prevent signals back to pixelvalve causing it to not clear the FIFO. Adjust the ordering and timing of operations to ensure the clear signal makes it through to pixelvalve. Signed-off-by: Tim Gover <tim.gover(a)raspberrypi.com> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> --- drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index 4ebe216b10a9..472a9d6b5866 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -605,12 +605,12 @@ static void vc4_hdmi_encoder_post_crtc_disable(struct drm_encoder *encoder, HDMI_WRITE(HDMI_RAM_PACKET_CONFIG, 0); - HDMI_WRITE(HDMI_VID_CTL, HDMI_READ(HDMI_VID_CTL) | - VC4_HD_VID_CTL_CLRRGB | VC4_HD_VID_CTL_CLRSYNC); + HDMI_WRITE(HDMI_VID_CTL, HDMI_READ(HDMI_VID_CTL) | VC4_HD_VID_CTL_CLRRGB); + + mdelay(1); HDMI_WRITE(HDMI_VID_CTL, - HDMI_READ(HDMI_VID_CTL) | VC4_HD_VID_CTL_BLANKPIX); - + HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE); vc4_hdmi_disable_scrambling(encoder); } @@ -620,12 +620,12 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct drm_encoder *encoder, struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder); int ret; + HDMI_WRITE(HDMI_VID_CTL, + HDMI_READ(HDMI_VID_CTL) | VC4_HD_VID_CTL_BLANKPIX); + if (vc4_hdmi->variant->phy_disable) vc4_hdmi->variant->phy_disable(vc4_hdmi); - HDMI_WRITE(HDMI_VID_CTL, - HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE); - clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock); clk_disable_unprepare(vc4_hdmi->hsm_clock); clk_disable_unprepare(vc4_hdmi->pixel_clock); @@ -1017,6 +1017,7 @@ static void vc4_hdmi_encoder_post_crtc_enable(struct drm_encoder *encoder, HDMI_WRITE(HDMI_VID_CTL, VC4_HD_VID_CTL_ENABLE | + VC4_HD_VID_CTL_CLRRGB | VC4_HD_VID_CTL_UNDERFLOW_ENABLE | VC4_HD_VID_CTL_FRAME_COUNTER_RESET | (vsync_pos ? 0 : VC4_HD_VID_CTL_VSYNC_LOW) | -- 2.31.1

1 1

[PATCH] drm/vc4: hdmi: Limit noise when deferring snd card registration
by Nicolas Saenz Julienne 06 Jul '21

06 Jul '21

We don't want to print an error message each time devm_snd_soc_register_card() returns -EPROBE_DEFER, the function will most likely succeed some time in the future, once the missing resources are available. So use dev_err_probe(), which will redirect the messages to the debug log level in such case. Signed-off-by: Nicolas Saenz Julienne <nsaenzju(a)redhat.com> --- drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index 04936cd6db8c..32da45821d3a 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -1575,7 +1575,7 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi *vc4_hdmi) snd_soc_card_set_drvdata(card, vc4_hdmi); ret = devm_snd_soc_register_card(dev, card); if (ret) - dev_err(dev, "Could not register sound card: %d\n", ret); + dev_err_probe(dev, ret, "Could not register sound card\n"); return ret; -- 2.31.1

2 1

[Bug 207383] New: [Regression] 5.7-rc: amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
by bugzilla-daemon＠bugzilla.kernel.org 06 Jul '21

06 Jul '21

https://bugzilla.kernel.org/show_bug.cgi?id=207383 Bug ID: 207383 Summary: [Regression] 5.7-rc: amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail Product: Drivers Version: 2.5 Kernel Version: 5.7-rc1, 5.7-rc2 Hardware: All 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: 1i5t5.duncan(a)cox.net Regression: No Created attachment 288649 --> https://bugzilla.kernel.org/attachment.cgi?id=288649&action=edit kernel config 5.7-rc1 and rc2 regression from kernel 5.6.0 After starting X/plasma on 5.7-rc1 and rc2, system runs for a few seconds to a few hours, then display freezes. The pointer continues to be movable and audio will continue to play for some seconds but they eventually stop as well. The kernel remains alive at least enough to reboot with SRQ-b, not sure if previous SRQs have any effect or not. Sometimes but not always there's a gpf left in the log, appearing to confirm it's amdgpu (the -dirty is simply a patch making mounts noatime by default): Apr 20 03:25:55 h2 kernel: general protection fault, probably for non-canonical address 0xc1316515e40a92f6: 0000 [#1] SMP Apr 20 03:25:55 h2 kernel: CPU: 3 PID: 3921 Comm: kworker/u16:5 Tainted: G T 5.7.0-rc2-dirty #194 Apr 20 03:25:55 h2 kernel: Hardware name: Gigabyte Technology Co., Ltd. GA-990FXA-UD3/GA-990FXA-UD3, BIOS F6 03/30/2012 Apr 20 03:25:55 h2 kernel: Workqueue: events_unbound commit_work Apr 20 03:25:55 h2 kernel: RIP: 0010:amdgpu_dm_atomic_commit_tail+0x102d/0x1fd8 Apr 20 03:25:55 h2 kernel: Code: 48 89 9d a0 fc ff ff 8b 90 e0 02 00 00 85 d2 0f 85 26 f1 ff ff 48 8b 85 e0 fc ff ff 48 89 85 a0 fc ff ff 48 8b b5 e0 fc ff ff <80> be b0 01 00 00 01 0f 86 b4 00 00 00 31 c0 48 b9 00 00 00 00 01 Apr 20 03:25:55 h2 kernel: RSP: 0018:ffffc9000216bad0 EFLAGS: 00010286 Apr 20 03:25:55 h2 kernel: RAX: ffff88842a6e1000 RBX: ffff8883d1d5b800 RCX: ffff8884283db200 Apr 20 03:25:55 h2 kernel: RDX: ffff8884283db2e0 RSI: c1316515e40a92f6 RDI: 0000000000000002 Apr 20 03:25:55 h2 kernel: RBP: ffffc9000216be50 R08: 0000000000000001 R09: 0000000000000001 Apr 20 03:25:55 h2 kernel: R10: 0000000000030000 R11: 0000000000000000 R12: 0000000000000000 Apr 20 03:25:55 h2 kernel: R13: 0000000000000005 R14: ffff88842bb76000 R15: ffff88841c08cc00 Apr 20 03:25:55 h2 kernel: FS: 0000000000000000(0000) GS:ffff88842ecc0000(0000) knlGS:0000000000000000 Apr 20 03:25:55 h2 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Apr 20 03:25:55 h2 kernel: CR2: 000078617de4fffc CR3: 000000040ca0e000 CR4: 00000000000406e0 Apr 20 03:25:55 h2 kernel: Call Trace: Apr 20 03:25:55 h2 kernel: ? 0xffffffff81000000 Apr 20 03:25:55 h2 kernel: ? __switch_to_asm+0x34/0x70 Apr 20 03:25:55 h2 kernel: ? __switch_to_asm+0x40/0x70 Apr 20 03:25:55 h2 kernel: ? __switch_to_asm+0x34/0x70 Apr 20 03:25:55 h2 kernel: ? __switch_to_asm+0x40/0x70 Apr 20 03:25:55 h2 kernel: ? commit_tail+0x8e/0x120 Apr 20 03:25:55 h2 kernel: ? process_one_work+0x1a9/0x300 Apr 20 03:25:55 h2 kernel: ? worker_thread+0x45/0x3b8 Apr 20 03:25:55 h2 kernel: ? kthread+0xf3/0x130 Apr 20 03:25:55 h2 kernel: ? process_one_work+0x300/0x300 Apr 20 03:25:55 h2 kernel: ? __kthread_create_on_node+0x180/0x180 Apr 20 03:25:55 h2 kernel: ? ret_from_fork+0x22/0x40 Apr 20 03:25:55 h2 kernel: ---[ end trace 33869116def8e8ad ]--- Apr 20 03:25:55 h2 kernel: RIP: 0010:amdgpu_dm_atomic_commit_tail+0x102d/0x1fd8 Apr 20 03:25:55 h2 kernel: Code: 48 89 9d a0 fc ff ff 8b 90 e0 02 00 00 85 d2 0f 85 26 f1 ff ff 48 8b 85 e0 fc ff ff 48 89 85 a0 fc ff ff 48 89 85 a0 fc ff ff 48 8b b5 e0 fc ff ff <80> be b0 01 00 00 01 0f 86 b4 00 00 00 31 c0 48 b9 00 00 00 00 01 Apr 20 03:25:55 h2 kernel: RSP: 0018:ffffc9000216bad0 EFLAGS: 00010286 Apr 20 03:25:55 h2 kernel: RAX: ffff88842a6e1000 RBX: ffff8883d1d5b800 RCX: ffff8884283db200 Apr 20 03:25:55 h2 kernel: RDX: ffff8884283db2e0 RSI: c1316515e40a92f6 RDI: 0000000000000002 Apr 20 03:25:55 h2 kernel: RBP: ffffc9000216be50 R08: 0000000000000001 R09: 0000000000000001 Apr 20 03:25:55 h2 kernel: R10: 0000000000030000 R11: 0000000000000000 R12: 0000000000000000 Apr 20 03:25:55 h2 kernel: R13: 0000000000000005 R14: ffff88842bb76000 R15: ffff88841c08cc00 Apr 20 03:25:55 h2 kernel: FS: 0000000000000000(0000) GS:ffff88842ecc0000(0000) knlGS:0000000000000000 Apr 20 03:25:55 h2 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Apr 20 03:25:55 h2 kernel: CR2: 000078617de4fffc CR3: 000000040ca0e000 CR4: 00000000000406e0 That's it. Nothing in the log since boot before, and the next entry is after reboot. gcc version 9.3.0 on Gentoo. AMD fx6100 on the Gigabyte board in the log above. xorg-server 1.20.8, mesa 20.0.4, xf86-video-amdgpu 19.1.0, linux-firmware 20200413 kernel config attached -- You are receiving this mail because: You are watching the assignee of the bug.

1 121

[PATCH] drm/vc4: dsi: Only register our component once a DSI device is attached
by Maxime Ripard 05 Jul '21

05 Jul '21

If the DSI driver is the last to probe, component_add will try to run all the bind callbacks straight away and return the error code. However, since we depend on a power domain, we're pretty much guaranteed to be in that case on the BCM2711, and are just lucky on the previous SoCs since the v3d also depends on that power domain and is further in the probe order. In that case, the DSI host will not stick around in the system: the DSI bind callback will be executed, will not find any DSI device attached and will return EPROBE_DEFER, and we will then remove the DSI host and ask to be probed later on. But since that host doesn't stick around, DSI devices like the RaspberryPi touchscreen whose probe is not linked to the DSI host (unlike the usual DSI devices that will be probed through the call to mipi_dsi_host_register) cannot attach to the DSI host, and we thus end up in a situation where the DSI host cannot probe because the panel hasn't probed yet, and the panel cannot probe because the DSI host hasn't yet. In order to break this cycle, let's wait until there's a DSI device that attaches to the DSI host to register the component and allow to progress further. Suggested-by: Andrzej Hajda <a.hajda(a)samsung.com> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> --- drivers/gpu/drm/vc4/vc4_dsi.c | 25 ++++++++----------------- 1 file changed, 8 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c index eaf276978ee7..19aab4e7e209 100644 --- a/drivers/gpu/drm/vc4/vc4_dsi.c +++ b/drivers/gpu/drm/vc4/vc4_dsi.c @@ -1246,10 +1246,12 @@ static ssize_t vc4_dsi_host_transfer(struct mipi_dsi_host *host, return ret; } +static const struct component_ops vc4_dsi_ops; static int vc4_dsi_host_attach(struct mipi_dsi_host *host, struct mipi_dsi_device *device) { struct vc4_dsi *dsi = host_to_dsi(host); + int ret; dsi->lanes = device->lanes; dsi->channel = device->channel; @@ -1284,6 +1286,12 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host *host, return 0; } + ret = component_add(&dsi->pdev->dev, &vc4_dsi_ops); + if (ret) { + mipi_dsi_host_unregister(&dsi->dsi_host); + return ret; + } + return 0; } @@ -1662,7 +1670,6 @@ static int vc4_dsi_dev_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; struct vc4_dsi *dsi; - int ret; dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL); if (!dsi) @@ -1670,26 +1677,10 @@ static int vc4_dsi_dev_probe(struct platform_device *pdev) dev_set_drvdata(dev, dsi); dsi->pdev = pdev; - - /* Note, the initialization sequence for DSI and panels is - * tricky. The component bind above won't get past its - * -EPROBE_DEFER until the panel/bridge probes. The - * panel/bridge will return -EPROBE_DEFER until it has a - * mipi_dsi_host to register its device to. So, we register - * the host during pdev probe time, so vc4 as a whole can then - * -EPROBE_DEFER its component bind process until the panel - * successfully attaches. - */ dsi->dsi_host.ops = &vc4_dsi_host_ops; dsi->dsi_host.dev = dev; mipi_dsi_host_register(&dsi->dsi_host); - ret = component_add(&pdev->dev, &vc4_dsi_ops); - if (ret) { - mipi_dsi_host_unregister(&dsi->dsi_host); - return ret; - } - return 0; } -- 2.26.2

5 21

[PATCH v2] drm/panfrost:report the full raw fault information instead
by ChunyouTang 05 Jul '21

05 Jul '21

From: ChunyouTang <tangchunyou(a)icubecorp.cn> of the low 8 bits. Signed-off-by: ChunyouTang <tangchunyou(a)icubecorp.cn> --- drivers/gpu/drm/panfrost/panfrost_gpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c b/drivers/gpu/drm/panfrost/panfrost_gpu.c index 1fffb6a0b24f..d2d287bbf4e7 100644 --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c @@ -33,7 +33,7 @@ static irqreturn_t panfrost_gpu_irq_handler(int irq, void *data) address |= gpu_read(pfdev, GPU_FAULT_ADDRESS_LO); dev_warn(pfdev->dev, "GPU Fault 0x%08x (%s) at 0x%016llx\n", - fault_status & 0xFF, panfrost_exception_name(pfdev, fault_status & 0xFF), + fault_status, panfrost_exception_name(pfdev, fault_status & 0xFF), address); if (state & GPU_IRQ_MULTIPLE_FAULT) -- 2.25.1

4 13

[PATCH v2] drm/dp_mst: Fix return code on sideband message failure
by Kuogee Hsieh 05 Jul '21

05 Jul '21

From: Rajkumar Subbiah <rsubbia(a)codeaurora.org> Commit 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests") added some debug code for sideband message tracing. But it seems to have unintentionally changed the behavior on sideband message failure. It catches and returns failure only if DRM_UT_DP is enabled. Otherwise it ignores the error code and returns success. So on an MST unplug, the caller is unaware that the clear payload message failed and ends up waiting for 4 seconds for the response. Fixes the issue by returning the proper error code. Changes in V2: -- Revise commit text as review comment -- add Fixes text Fixes: 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests") Signed-off-by: Rajkumar Subbiah <rsubbia(a)codeaurora.org> Signed-off-by: Kuogee Hsieh <khsieh(a)codeaurora.org> Reviewed-by: Stephen Boyd <swboyd(a)chromium.org> --- drivers/gpu/drm/drm_dp_mst_topology.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 1590144..8d97430 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -2887,11 +2887,13 @@ static int process_single_tx_qlock(struct drm_dp_mst_topology_mgr *mgr, idx += tosend + 1; ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx); - if (unlikely(ret) && drm_debug_enabled(DRM_UT_DP)) { - struct drm_printer p = drm_debug_printer(DBG_PREFIX); + if (unlikely(ret)) { + if (drm_debug_enabled(DRM_UT_DP)) { + struct drm_printer p = drm_debug_printer(DBG_PREFIX); - drm_printf(&p, "sideband msg failed to send\n"); - drm_dp_mst_dump_sideband_msg_tx(&p, txmsg); + drm_printf(&p, "sideband msg failed to send\n"); + drm_dp_mst_dump_sideband_msg_tx(&p, txmsg); + } return ret; } -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

3 2

[RFC 0/6] drm/msm/dpu: add support for idependent DSI config
by Dmitry Baryshkov 04 Jul '21

04 Jul '21

This patchseries adds support for independent DSI config to DPU1 display subdriver. This results in ability to drop one of msm_kms_funcs callbacks. This code was tested on RB5 (dpu, dsi). Neither DP nor MDP5 changes were tested (thus the RFC tag).

3 12

[PATCH v2 1/2] dt-bindings: Add E Ink to vendor bindings
by Alistair Francis 04 Jul '21

04 Jul '21

Add the E Ink Corporation to the vendor bindings. Signed-off-by: Alistair Francis <alistair(a)alistair23.me> Acked-by: Rob Herring <robh(a)kernel.org> --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index abd878ff23d5..a35cec512530 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -335,6 +335,8 @@ patternProperties: description: eGalax_eMPIA Technology Inc "^einfochips,.*": description: Einfochips + "^eink,.*": + description: E Ink Corporation "^elan,.*": description: Elan Microelectronic Corp. "^element14,.*": -- 2.31.1

3 3

← Newer
1
...
14
15
16
17
18
19
20
...
88
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2021