dri-devel June 2022

dri-devel@lists.freedesktop.org

332 participants
697 discussions

[PATCH] drm/stm: ltdc: remove error message about scaling
by Yannick Fertre 09 Jun '22

09 Jun '22

Remove error message about scaling & replace it by a debug message to avoid too much error. Signed-off-by: Yannick Fertre <yannick.fertre(a)foss.st.com> --- drivers/gpu/drm/stm/ltdc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c index eeefc3260c07..a4098aaff243 100644 --- a/drivers/gpu/drm/stm/ltdc.c +++ b/drivers/gpu/drm/stm/ltdc.c @@ -1215,7 +1215,8 @@ static int ltdc_plane_atomic_check(struct drm_plane *plane, /* Reject scaling */ if (src_w != new_plane_state->crtc_w || src_h != new_plane_state->crtc_h) { - DRM_ERROR("Scaling is not supported"); + DRM_DEBUG_DRIVER("Scaling is not supported"); + return -EINVAL; } -- 2.25.1

2 1

[RFC] Common DRM execution context v2
by Christian König 09 Jun '22

09 Jun '22

Hello everyone, compared to the earlier version this has seen quite a bit of additional testing and can now handle both amdgpu as well as radeon without any performance drop. QXL is converted over as well and then the remaining ttm_execbuf_util implementation moved into VMWGFX which is the only remaining user of this. Please review and comment, Christian.

4 17

[PATCH] drm/atomic: fix warning of unused variable
by GONG, Ruiqi 09 Jun '22

09 Jun '22

Fix the `unused-but-set-variable` warning as how other iteration wrappers do. Link: https://lore.kernel.org/all/202206071049.pofHsRih-lkp@intel.com/ Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: GONG, Ruiqi <gongruiqi1(a)huawei.com> --- include/drm/drm_atomic.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index 0777725085df..10b1990bc1f6 100644 --- a/include/drm/drm_atomic.h +++ b/include/drm/drm_atomic.h @@ -1022,6 +1022,7 @@ void drm_state_dump(struct drm_device *dev, struct drm_printer *p); for ((__i) = 0; \ (__i) < (__state)->num_private_objs && \ ((obj) = (__state)->private_objs[__i].ptr, \ + (void)(obj) /* Only to avoid unused-but-set-variable warning */, \ (new_obj_state) = (__state)->private_objs[__i].new_state, 1); \ (__i)++) -- 2.25.1

2 1

[PATCH v3 0/4] drm/dp: Make DP AUX bus usage easier; use it on ps8640
by Douglas Anderson 09 Jun '22

09 Jun '22

This patch is v3 of the first 2 patches from my RFC series ("drm/dp: Improvements for DP AUX channel") [1]. I've broken the series in two so we can make progress on the two halves separately. v2 of this series tries to incorporate all the feedback from v1. Hopefully things are less confusing and simpler this time around. The one thing that got slightly more confusing is that the done_probing() callback can't return -EPROBE_DEFER in most cases so we have to adjust drivers a little more. v3 takes Dmitry's advice on v2. This now introduces devm_drm_bridge_add() (in an extra patch), splits some fixups into their own patch, uses a new name for functions, and requires an explicit call to done_probing if you have no children. The idea for this series came up during the review process of Sankeerth's series trying to add eDP for Qualcomm SoCs [2]. This _doesn't_ attempt to fix the Analogix driver. If this works out, ideally someone can post a patch up to do that. NOTE: I don't have any ps8640 devices that _don't_ use the aux panel underneath them, so I'm relying on code inspection to make sure I didn't break those. If someone sees that I did something wrong for that case then please yell! [1] https://lore.kernel.org/r/20220409023628.2104952-1-dianders@chromium.org/ [2] https://lore.kernel.org/r/1648656179-10347-2-git-send-email-quic_sbillaka@q… Changes in v3: - Adapt to v3 changes in aux bus. - Don't call done_probing() if there are no children; return -ENODEV. - Patch ("drm/bridge: Add devm_drm_bridge_add()") new for v3. - Patch ("drm/dp: Export symbol / kerneldoc fixes...") split for v3. - Split out EXPORT_SYMBOL and kerneldoc fixes to its own patch. - Use devm_drm_bridge_add() to simplify. - Used Dmitry's proposed name: of_dp_aux_populate_bus() Changes in v2: - Change to assume exactly one device. - Have a probe callback instead of an extra sub device. - Rewrote atop new method introduced by patch #1. Douglas Anderson (4): drm/dp: Export symbol / kerneldoc fixes for DP AUX bus drm/dp: Add callbacks to make using DP AUX bus properly easier drm/bridge: Add devm_drm_bridge_add() drm/bridge: parade-ps8640: Handle DP AUX more properly drivers/gpu/drm/bridge/parade-ps8640.c | 74 +++++--- drivers/gpu/drm/display/drm_dp_aux_bus.c | 211 +++++++++++++++-------- drivers/gpu/drm/drm_bridge.c | 23 +++ include/drm/display/drm_dp_aux_bus.h | 34 +++- include/drm/drm_bridge.h | 1 + 5 files changed, 238 insertions(+), 105 deletions(-) -- 2.36.0.550.gb090851708-goog

5 24

drm/vc4: module dysfunctional on Raspberry Pi 3B as of 5.18.0
by Peter Mattern 09 Jun '22

09 Jun '22

> Which kernel config do you use (is it a defconfig)? These are custom configs provided by the distribution, the origin of which I do not know. You can find them at [1] (5.17.0, used in 5.17.1 as well) and [2] (5.18.0, modified in 5.18.1). The difference between these files and their upstream (kernel.org) counterpart as created by running 'make ARCH=arm64 defconfig' is about 11k lines, the difference between the two files of the distribution around 800 lines. Didn't investigate the differences in detail yet. > Do you use the mainline device tree blob or the Raspberry Pi DTB? It's the one from the kernel.org sources. Note: At times you'll find claims that the DTBs of the Raspberry Pi Foundation were used on Arch Linux ARM. These probably are due to the fact that those blobs happen to be around. But U-Boot's boot.scr does pick the "mainline" ones in /boot/dtbs/. > Please provide the version/date of the GPU firmware? It is provided by the Broadcom bootloader package (which is used to chainload U-Boot). It happened to be updated in parallel with kernel 5.18.0 to commit f145afcf [3] and has since been updated to upstream commit 8f91a969. Those latest changes don't seem to have an impact on the problem we're discussing here (not all combinations bootloader / kernel tested). > Do you have any KMS related setting in the config.txt? No. My epic config.txt is: enable_uart=1 > Can you provide a full dmesg for the bad case? I sure could. But grepping through it yields the exact same results included in my first post. And assuming this list scrubs attachments I'm not sure whether posting those 500 lines in a mail would make sense? [1] https://github.com/archlinuxarm/PKGBUILDs/blob/ae861a830e6e1d6d3e37c94462c8… [2] https://github.com/archlinuxarm/PKGBUILDs/blob/9c5b51b25ecc038cd505b26e15bb… [3] https://github.com/archlinuxarm/PKGBUILDs/blob/722080b0aaa7e158d91b323d27c4…

1 0

[PATCH v2 00/12] drm/msm/hdmi: YAML-ify schema and cleanup some platform properties
by Dmitry Baryshkov 09 Jun '22

09 Jun '22

As agreed with David, this is a continuation of his work started at [1]. I didn't pick up his R-b tag for the first patch, since patch has been heavily modified. Changes since v1: - Dropped quotes in $id/$schema - Sorted out compat strings alphabetically - Removed obvious descriptions - Removed undocumented qcom,hdmi-tx-ddc-* properties - Switched to additionalProperties - Fixed IRQ and GPIO flags in the schema example - Added 8084 and 8660 variants to qcom,hdmi-phy-other.yaml conditional - Marked hdmi-mux-supply as deprecated (and dropped it from apq8064-ifc6410.dtsi) - Reused 8960 regulator/clock configs for 8x60 (verified against msm-3.4 kernel) Changes since his patches: HDMI schema: - Dropped generic pinctrl properties - Dropped data-lanes property, which is not supported by the HDMI driver - Switched to unevaluatedProperties - Moved clocks/regulators/supplies to condition clauses - Specified phy-names as used by existing DT files - Dropped #phy-cells - Dropped power-domains property (which is not used by the device trees) - Marked old GPIO properties as deprecated (in a separate patch) HDMI PHY schema: - Split into QMP (msm8996) and non-QMP (other) PHY schemas - Added proper clocks/clock-names/reg/reg-names descriptions The rest of the patches consist of the new work. They further cleanup the platform configs, remove unused supplies, etc. [1]: https://patchwork.freedesktop.org/series/98353/ Dmitry Baryshkov (12): dt-bindings: display/msm: hdmi: split and convert to yaml dt-bindings: display/msm: hdmi: mark old GPIO properties as deprecated dt-bindings: display/msm: hdmi: mark hdmi-mux-supply as deprecated arm: dts: qcom: apq8064-ifc6410: drop hdmi-mux-supply drm/msm/hdmi: drop the hdmi-mux support drm/msm/hdmi: drop unused GPIO support drm/msm/hdmi: enable core-vcc/core-vdda-supply for 8996 platform drm/msm/hdmi: drop empty 'none' regulator lists drm/msm/hdmi: drop hpd_regs usage on 8x74/8084 drm/msm/hdmi: merge platform config for 8974/8084/8994/8996 drm/msm/hdmi: reuse MSM8960's config for MSM8660 drm/msm/hdmi-phy: populate 8x60 HDMI PHY requirements .../devicetree/bindings/display/msm/hdmi.txt | 99 -------- .../devicetree/bindings/display/msm/hdmi.yaml | 234 ++++++++++++++++++ .../bindings/phy/qcom,hdmi-phy-other.yaml | 103 ++++++++ .../bindings/phy/qcom,hdmi-phy-qmp.yaml | 83 +++++++ arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 1 - drivers/gpu/drm/msm/hdmi/hdmi.c | 104 ++------ drivers/gpu/drm/msm/hdmi/hdmi.h | 13 +- drivers/gpu/drm/msm/hdmi/hdmi_hpd.c | 62 +---- drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c | 12 + 9 files changed, 454 insertions(+), 257 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/msm/hdmi.txt create mode 100644 Documentation/devicetree/bindings/display/msm/hdmi.yaml create mode 100644 Documentation/devicetree/bindings/phy/qcom,hdmi-phy-other.yaml create mode 100644 Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml -- 2.35.1

5 32

[PATCH v3 0/2] Add the property to make backlight OCP level selectable
by cy_huang 09 Jun '22

09 Jun '22

From: ChiYuan Huang <cy_huang(a)richtek.com> This patch series is to add the backlight ocp level property parsing. Since v3 - Refine the description for backlight ocp property. - Use the enum to list the supported value. Since v2 - change the property name from the register style 'richtek,bled-ocp-cel' to 'richtek,bled-ocp-microamp'. - Use the clamp and roundup to get the ovp level selector. ChiYuan Huang (2): dt-bindings: backlight: rt4831: Add the new ocp level property backlight: rt4831: Apply ocp level from devicetree .../leds/backlight/richtek,rt4831-backlight.yaml | 5 ++++ drivers/video/backlight/rt4831-backlight.c | 33 +++++++++++++++++++++- 2 files changed, 37 insertions(+), 1 deletion(-) -- 2.7.4

3 4

[PULL] drm-misc-fixes
by Maxime Ripard 09 Jun '22

09 Jun '22

Hi Daniel, Dave, Here's this week drm-misc-fixes PR Maxime drm-misc-fixes-2022-06-09: One fix to handle DT errors in ti-sn65dsi83, a fix for a use-after-free in panfrost, two fixes for panel self-refresh handling, and one to fix multiple output support on AST. The following changes since commit f2906aa863381afb0015a9eb7fefad885d4e5a56: Linux 5.19-rc1 (2022-06-05 17:18:54 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2022-06-09 for you to fetch changes up to 477277c7fd43d48ae68cbdcaa7c0f82024a87421: drm/ast: Support multiple outputs (2022-06-09 10:27:49 +0200) ---------------------------------------------------------------- One fix to handle DT errors in ti-sn65dsi83, a fix for a use-after-free in panfrost, two fixes for panel self-refresh handling, and one to fix multiple output support on AST. ---------------------------------------------------------------- Brian Norris (2): drm/bridge: analogix_dp: Support PSR-exit to disable transition drm/atomic: Force bridge self-refresh-exit on CRTC switch Marek Vasut (1): drm/bridge: ti-sn65dsi83: Handle dsi_lanes == 0 as invalid Maxime Ripard (1): Merge v5.19-rc1 into drm-misc-fixes Steven Price (1): drm/panfrost: Job should reference MMU not file_priv Thomas Zimmermann (1): drm/ast: Support multiple outputs drivers/gpu/drm/ast/ast_dp.c | 5 ++- drivers/gpu/drm/ast/ast_dp501.c | 2 +- drivers/gpu/drm/ast/ast_drv.h | 9 +++-- drivers/gpu/drm/ast/ast_main.c | 21 +++++------ drivers/gpu/drm/ast/ast_mode.c | 38 +++++++++++--------- drivers/gpu/drm/ast/ast_post.c | 2 +- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 42 +++++++++++++++++++--- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 2 +- drivers/gpu/drm/drm_atomic_helper.c | 16 +++++++-- drivers/gpu/drm/panfrost/panfrost_drv.c | 5 +-- drivers/gpu/drm/panfrost/panfrost_job.c | 6 ++-- drivers/gpu/drm/panfrost/panfrost_job.h | 2 +- 12 files changed, 100 insertions(+), 50 deletions(-)

1 0

[RESEND PATCH v3] drm/cma-helper: Describe what a "contiguous chunk" actually means
by Daniel Thompson 09 Jun '22

09 Jun '22

Since it's inception in 2012 it has been understood that the DRM GEM CMA helpers do not depend on CMA as the backend allocator. In fact the first bug fix to ensure the cma-helpers work correctly with an IOMMU backend appeared in 2014. However currently the documentation for drm_gem_cma_create() talks about "a contiguous chunk of memory" without making clear which address space it will be a contiguous part of. Additionally the CMA introduction is actively misleading because it only contemplates the CMA backend. This matters because when the device accesses the bus through an IOMMU (and don't use the CMA backend) then the allocated memory is contiguous only in the IOVA space. This is a significant difference compared to the CMA backend and the behaviour can be a surprise even to someone who does a reasonable level of code browsing (but doesn't find all the relevant function pointers ;-) ). Improve the kernel doc comments accordingly. Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> Reviewed-by: Lucas Stach <l.stach(a)pengutronix.de> --- Notes: Am I Cc:ing the correct reviewers/maintainers with this patch? There has been no negative feedback but I've been rebasing and re-posting it for three kernel cycles now. Do I need to queue it somewhere special or get it in front of someone specific? Either way... This RESEND is unaltered (except for collecting tags) and is rebased on v5.19-rc1. RESEND for v5.18-rc3 - Unaltered but rebased on v5.18-rc3 Changes in v3: - Rebased on v5.17-rc2 - Minor improvements to wording. Changes in v2: - Oops. I did a final proof read and accidentally committed these changes as a seperate patch. This means that v1 contains only one tenth of the actual patch. This is fixed in v2. Many apologies for the noise! drivers/gpu/drm/drm_gem_cma_helper.c | 39 +++++++++++++++++++++------- 1 file changed, 29 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c index f36734c2c9e1..42abee9a0f4f 100644 --- a/drivers/gpu/drm/drm_gem_cma_helper.c +++ b/drivers/gpu/drm/drm_gem_cma_helper.c @@ -26,12 +26,22 @@ /** * DOC: cma helpers * - * The Contiguous Memory Allocator reserves a pool of memory at early boot - * that is used to service requests for large blocks of contiguous memory. + * The DRM GEM/CMA helpers are a means to provide buffer objects that are + * presented to the device as a contiguous chunk of memory. This is useful + * for devices that do not support scatter-gather DMA (either directly or + * by using an intimately attached IOMMU). * - * The DRM GEM/CMA helpers use this allocator as a means to provide buffer - * objects that are physically contiguous in memory. This is useful for - * display drivers that are unable to map scattered buffers via an IOMMU. + * Despite the name, the DRM GEM/CMA helpers are not hardwired to use the + * Contiguous Memory Allocator (CMA). + * + * For devices that access the memory bus through an (external) IOMMU then + * the buffer objects are allocated using a traditional page-based + * allocator and may be scattered through physical memory. However they + * are contiguous in the IOVA space so appear contiguous to devices using + * them. + * + * For other devices then the helpers rely on CMA to provide buffer + * objects that are physically contiguous in memory. * * For GEM callback helpers in struct &drm_gem_object functions, see likewise * named functions with an _object_ infix (e.g., drm_gem_cma_object_vmap() wraps @@ -111,8 +121,14 @@ __drm_gem_cma_create(struct drm_device *drm, size_t size, bool private) * @drm: DRM device * @size: size of the object to allocate * - * This function creates a CMA GEM object and allocates a contiguous chunk of - * memory as backing store. + * This function creates a CMA GEM object and allocates memory as backing store. + * The allocated memory will occupy a contiguous chunk of bus address space. + * + * For devices that are directly connected to the memory bus then the allocated + * memory will be physically contiguous. For devices that access through an + * IOMMU, then the allocated memory is not expected to be physically contiguous + * because having contiguous IOVAs is sufficient to meet a devices DMA + * requirements. * * Returns: * A struct drm_gem_cma_object * on success or an ERR_PTR()-encoded negative @@ -162,9 +178,12 @@ EXPORT_SYMBOL_GPL(drm_gem_cma_create); * @size: size of the object to allocate * @handle: return location for the GEM handle * - * This function creates a CMA GEM object, allocating a physically contiguous - * chunk of memory as backing store. The GEM object is then added to the list - * of object associated with the given file and a handle to it is returned. + * This function creates a CMA GEM object, allocating a chunk of memory as + * backing store. The GEM object is then added to the list of object associated + * with the given file and a handle to it is returned. + * + * The allocated memory will occupy a contiguous chunk of bus address space. + * See drm_gem_cma_create() for more details. * * Returns: * A struct drm_gem_cma_object * on success or an ERR_PTR()-encoded negative base-commit: f2906aa863381afb0015a9eb7fefad885d4e5a56 -- 2.35.1

2 2

i915 w/5.19: wild flickering glitching technicolor pyrotechnics on resumption from suspend
by Jason A. Donenfeld 09 Jun '22

09 Jun '22

Hi, Using the i7-11850H's iGPU, when I wake my Thinkpad X1 Extreme Gen 4 from suspend on 5.19-rc1, the display shows wild flickering with strobing colors and more artifacts than real pixels in an utter disaster explosion of pantone, as though bombs were dropped on the leprechauns at the base of the rainbow. That sounds ridiculous, but the strobing pattern really is a sight to be seen. I can only stop it by rebooting. I took a video, but I worry about having private info in my video buffer, so if you'd like to see it, email me privately. The system is otherwise operational and fine. Nothing in dmesg, even with i915 debugging enabled, and if it weren't for the display artifacts, I believe the actual rendering in video memory would be fine. So this sort of looks like a display driver or some sort of psr problem. Let me know if there's anything else I can do to provide more debug info. It's pretty trivial to reproduce: I just put my laptop to sleep and wake it back up. Jason

2 3

← Newer
1
...
46
47
48
49
50
51
52
...
70
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2022