dri-devel February 2022

dri-devel@lists.freedesktop.org

394 participants
865 discussions

[Bug 211807] New: [drm:drm_dp_mst_dpcd_read] *ERROR* mstb 000000004e6288dd port 3: DPCD read on addr 0x60 for 1 bytes NAKed
by bugzilla-daemon＠bugzilla.kernel.org 07 Apr '22

07 Apr '22

https://bugzilla.kernel.org/show_bug.cgi?id=211807 Bug ID: 211807 Summary: [drm:drm_dp_mst_dpcd_read] *ERROR* mstb 000000004e6288dd port 3: DPCD read on addr 0x60 for 1 bytes NAKed Product: Drivers Version: 2.5 Kernel Version: 5.10.16 Hardware: All 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: kernelbugs(a)equaeghe.nospammail.net Regression: No In my logs, I see the following error: [drm:drm_dp_mst_dpcd_read] *ERROR* mstb 000000004e6288dd port 3: DPCD read on addr 0x60 for 1 bytes NAKed It has not caused any detected issues, but I guess that if the kernel complains this loudy, it is good to report it. This is on a laptop with a Ryzen Pro 4750U APU. I custom-build the kernel, so do not hesitate to request changing some config options to investigate. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

2 21

[PATCH] drm: sti: fix spelling mistake: rejec -> rejection
by Colin King 07 Apr '22

07 Apr '22

From: Colin Ian King <colin.king(a)canonical.com> In other places of the driver the string hdmi_rejection_pll is used instead of the truncated hdmi_rejec_pll, so use this string instead to be consistent. Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/gpu/drm/sti/sti_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c index 814560ead4e1..e2018e4a3ec5 100644 --- a/drivers/gpu/drm/sti/sti_hdmi.c +++ b/drivers/gpu/drm/sti/sti_hdmi.c @@ -886,7 +886,7 @@ static void sti_hdmi_pre_enable(struct drm_bridge *bridge) if (clk_prepare_enable(hdmi->clk_tmds)) DRM_ERROR("Failed to prepare/enable hdmi_tmds clk\n"); if (clk_prepare_enable(hdmi->clk_phy)) - DRM_ERROR("Failed to prepare/enable hdmi_rejec_pll clk\n"); + DRM_ERROR("Failed to prepare/enable hdmi_rejection_pll clk\n"); hdmi->enabled = true; -- 2.20.1

2 1

[PATCH] drm/mediatek: Fix DPI component detection for MT8192
by Chen-Yu Tsai 07 Apr '22

07 Apr '22

When support for MT8192 was added, the DPI device was not added to the list of components to look for. This causes the secondary display pipeline to not be able to fully bind, and the DRM driver subsequently defers probing. Add the DPI device compatible to list of DPI components to fix this. Fixes: 01365f549c88 ("drm/mediatek: Add support for Mediatek SoC MT8192") Signed-off-by: Chen-Yu Tsai <wenst(a)chromium.org> --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index b147797177c6..47ba18cbc5c8 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -511,6 +511,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = { .data = (void *)MTK_DPI }, { .compatible = "mediatek,mt8183-dpi", .data = (void *)MTK_DPI }, + { .compatible = "mediatek,mt8192-dpi", + .data = (void *)MTK_DPI }, { .compatible = "mediatek,mt2701-dsi", .data = (void *)MTK_DSI }, { .compatible = "mediatek,mt8173-dsi", -- 2.35.1.574.g5d30c73bfb-goog

2 2

[PATCH][RESEND] drm/bridge: ti-sn65dsi83: Check link status register after enabling the bridge
by Marek Vasut 06 Apr '22

06 Apr '22

In rare cases, the bridge may not start up correctly, which usually leads to no display output. In case this happens, warn about it in the kernel log. Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Jagan Teki <jagan(a)amarulasolutions.com> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Linus Walleij <linus.walleij(a)linaro.org> Cc: Robert Foss <robert.foss(a)linaro.org> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: dri-devel(a)lists.freedesktop.org --- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c index 19daaddd29a41..1d7c154ea1d79 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -488,6 +488,11 @@ static void sn65dsi83_atomic_enable(struct drm_bridge *bridge, /* Clear all errors that got asserted during initialization. */ regmap_read(ctx->regmap, REG_IRQ_STAT, &pval); regmap_write(ctx->regmap, REG_IRQ_STAT, pval); + + usleep_range(10000, 12000); + regmap_read(ctx->regmap, REG_IRQ_STAT, &pval); + if (pval) + dev_err(ctx->dev, "Unexpected link status 0x%02x\n", pval); } static void sn65dsi83_atomic_disable(struct drm_bridge *bridge, -- 2.34.1

5 13

[PATCH] gpu: host1x: Show all allocated syncpts via debugfs
by Jon Hunter 06 Apr '22

06 Apr '22

When the host1x syncpts status is dumped via the debugfs, syncpts that have been allocated but not yet used are not shown and so currently it is not possible to see all the allocated syncpts. Update the path for dumping the syncpt status via the debugfs to show all allocated syncpts even if they have not been used yet. Note that when the syncpt status is dumped by the kernel itself for debugging only the active syncpt are shown. Signed-off-by: Jon Hunter <jonathanh(a)nvidia.com> --- drivers/gpu/host1x/debug.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c index 18d9c8d206e3..34c2e36d09e9 100644 --- a/drivers/gpu/host1x/debug.c +++ b/drivers/gpu/host1x/debug.c @@ -75,7 +75,7 @@ static int show_channel(struct host1x_channel *ch, void *data, bool show_fifo) return 0; } -static void show_syncpts(struct host1x *m, struct output *o) +static void show_syncpts(struct host1x *m, struct output *o, bool show_all) { struct list_head *pos; unsigned int i; @@ -97,7 +97,10 @@ static void show_syncpts(struct host1x *m, struct output *o) waiters++; spin_unlock(&m->syncpt[i].intr.lock); - if (!min && !max && !waiters) + if (!kref_read(&m->syncpt[i].ref)) + continue; + + if (!show_all && !min && !max && !waiters) continue; host1x_debug_output(o, @@ -124,7 +127,7 @@ static void show_all(struct host1x *m, struct output *o, bool show_fifo) unsigned int i; host1x_hw_show_mlocks(m, o); - show_syncpts(m, o); + show_syncpts(m, o, true); host1x_debug_output(o, "---- channels ----\n"); for (i = 0; i < m->info->nb_channels; ++i) { @@ -241,5 +244,5 @@ void host1x_debug_dump_syncpts(struct host1x *host1x) .fn = write_to_printk }; - show_syncpts(host1x, &o); + show_syncpts(host1x, &o, false); } -- 2.25.1

2 1

[PATCH v7 00/12] clk: Improve clock range handling
by Maxime Ripard 06 Apr '22

06 Apr '22

Hi, This is a follow-up of the discussion here: https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/ and here: https://lore.kernel.org/all/20210914093515.260031-1-maxime@cerno.tech/ While the initial proposal implemented a new API to temporarily raise and lower clock rates based on consumer workloads, Stephen suggested an alternative approach implemented here. The main issue that needed to be addressed in our case was that in a situation where we would have multiple calls to clk_set_rate_range, we would end up with a clock at the maximum of the minimums being set. This would be expected, but the issue was that if one of the users was to relax or drop its requirements, the rate would be left unchanged, even though the ideal rate would have changed. So something like clk_set_rate(user1_clk, 1000); clk_set_min_rate(user1_clk, 2000); clk_set_min_rate(user2_clk, 3000); clk_set_min_rate(user2_clk, 1000); Would leave the clock running at 3000Hz, while the minimum would now be 2000Hz. This was mostly due to the fact that the core only triggers a rate change in clk_set_rate_range() if the current rate is outside of the boundaries, but not if it's within the new boundaries. That series changes that and will trigger a rate change on every call, with the former rate being tried again. This way, providers have a chance to follow whatever policy they see fit for a given clock each time the boundaries change. This series also implements some kunit tests, first to test a few rate related functions in the CCF, and then extends it to make sure that behaviour has some test coverage. Let me know what you think Maxime Changes from v6: - Removed unused header - Used more fitting KUNIT macros - Enhanced some comments - Reworded a commit message Changes from v5: - Changed clk_hw_create_clk for clk_hw_get_clk since the former isn't exported to modules. - Added fix for clk_hw_get_clk Changes from v4: - Rename the test file - Move all the tests to the first patch, and fix them up as fixes are done - Improved the test conditions - Added more tests - Improved commit messages - Fixed a regression where two disjoints clock ranges would now be accepted Changes from v3: - Renamed the test file and Kconfig option - Add option to .kunitconfig - Switch to kunit_kzalloc - Use KUNIT_EXPECT_* instead of KUNIT_ASSERT_* where relevant - Test directly relevant calls instead of going through a temporary variable - Switch to more precise KUNIT_ASSERT_* macros where relevant Changes from v2: - Rebased on current next - Rewrote the whole thing according to Stephen reviews - Implemented some kunit tests Changes from v1: - Return NULL in clk_request_start if clk pointer is NULL - Test for clk_req pointer in clk_request_done - Add another user in vc4 - Rebased on top of v5.15-rc1 Maxime Ripard (12): clk: Fix clk_hw_get_clk() when dev is NULL clk: Introduce Kunit Tests for the framework clk: Enforce that disjoints limits are invalid clk: Always clamp the rounded rate clk: Use clamp instead of open-coding our own clk: Always set the rate on clk_set_range_rate clk: Add clk_drop_range clk: bcm: rpi: Add variant structure clk: bcm: rpi: Set a default minimum rate clk: bcm: rpi: Run some clocks at the minimum rate allowed drm/vc4: Add logging and comments drm/vc4: hdmi: Remove clock rate initialization drivers/clk/.kunitconfig | 1 + drivers/clk/Kconfig | 7 + drivers/clk/Makefile | 1 + drivers/clk/bcm/clk-raspberrypi.c | 125 ++++- drivers/clk/clk.c | 76 ++- drivers/clk/clk_test.c | 795 ++++++++++++++++++++++++++++++ drivers/gpu/drm/vc4/vc4_hdmi.c | 13 - drivers/gpu/drm/vc4/vc4_kms.c | 11 + include/linux/clk.h | 11 + 9 files changed, 985 insertions(+), 55 deletions(-) create mode 100644 drivers/clk/clk_test.c -- 2.35.1

4 21

[PATCH v1 1/8] ARM: dts: imx6qdl-vicut1/vicutgo: Set default backlight brightness to maximum
by Oleksij Rempel 06 Apr '22

06 Apr '22

From: David Jander <david(a)protonic.nl> Recover default behavior of the device and set maximal brightness Signed-off-by: David Jander <david(a)protonic.nl> Signed-off-by: Oleksij Rempel <o.rempel(a)pengutronix.de> --- arch/arm/boot/dts/imx6dl-victgo.dts | 2 +- arch/arm/boot/dts/imx6qdl-vicut1.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/imx6dl-victgo.dts b/arch/arm/boot/dts/imx6dl-victgo.dts index 227c952543d4..e6134efbfabd 100644 --- a/arch/arm/boot/dts/imx6dl-victgo.dts +++ b/arch/arm/boot/dts/imx6dl-victgo.dts @@ -28,7 +28,7 @@ backlight: backlight { pwms = <&pwm1 0 5000000 0>; brightness-levels = <0 16 64 255>; num-interpolated-steps = <16>; - default-brightness-level = <1>; + default-brightness-level = <48>; power-supply = <&reg_3v3>; enable-gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>; }; diff --git a/arch/arm/boot/dts/imx6qdl-vicut1.dtsi b/arch/arm/boot/dts/imx6qdl-vicut1.dtsi index 1ac7e13249d2..c1d06bc28c67 100644 --- a/arch/arm/boot/dts/imx6qdl-vicut1.dtsi +++ b/arch/arm/boot/dts/imx6qdl-vicut1.dtsi @@ -23,7 +23,7 @@ backlight: backlight { pwms = <&pwm1 0 5000000 0>; brightness-levels = <0 16 64 255>; num-interpolated-steps = <16>; - default-brightness-level = <1>; + default-brightness-level = <48>; power-supply = <&reg_3v3>; enable-gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>; }; -- 2.30.2

2 17

[PATCH v4 0/3] drm/msm/dp: replace DRM_DEBUG_DP with drm_dbg_dp
by Kuogee Hsieh 01 Apr '22

01 Apr '22

Since DRM_DEBUG_DP is deprecated in favor of drm_dbg_dp(NULL, ...), replace all DRM_DEBUG_DP with drm_dbg_dp(). Kuogee Hsieh (3): drm/msm/dp: add connector type to enhance debug messages drm/msm/dp: enhance debug info related to dp phy drm/msm/dp: replace DRM_DEBUG_DP marco with drm_dbg_dp drivers/gpu/drm/msm/dp/dp_audio.c | 50 ++++++++++----- drivers/gpu/drm/msm/dp/dp_catalog.c | 35 +++++----- drivers/gpu/drm/msm/dp/dp_ctrl.c | 124 +++++++++++++++++++----------------- drivers/gpu/drm/msm/dp/dp_display.c | 103 +++++++++++++++++++++--------- drivers/gpu/drm/msm/dp/dp_drm.c | 4 +- drivers/gpu/drm/msm/dp/dp_link.c | 103 ++++++++++++++++++------------ drivers/gpu/drm/msm/dp/dp_panel.c | 47 ++++++++------ drivers/gpu/drm/msm/dp/dp_parser.c | 2 - drivers/gpu/drm/msm/dp/dp_power.c | 25 ++++++-- 9 files changed, 302 insertions(+), 191 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

3 11

[PATCH v12 0/4] drm/msm/dpu: enable widebus feature base on chip hardware revision
by Kuogee Hsieh 01 Apr '22

01 Apr '22

revise widebus timing engine programming and enable widebus feature base on chip Kuogee Hsieh (4): drm/msm/dpu: adjust display_v_end for eDP and DP drm/msm/dpu: replace BIT(x) with correspond marco define string drm/msm/dpu: revise timing engine programming to support widebus feature drm/msm/dp: enable widebus feature for display port drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 14 ++++- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 2 + .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 14 +++++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 62 ++++++++++++++++------ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 2 + drivers/gpu/drm/msm/dp/dp_catalog.c | 34 +++++++++++- drivers/gpu/drm/msm/dp/dp_catalog.h | 2 + drivers/gpu/drm/msm/dp/dp_ctrl.c | 7 ++- drivers/gpu/drm/msm/dp/dp_ctrl.h | 1 + drivers/gpu/drm/msm/dp/dp_display.c | 21 +++++++- drivers/gpu/drm/msm/dp/dp_display.h | 2 + drivers/gpu/drm/msm/msm_drv.h | 6 +++ 12 files changed, 146 insertions(+), 21 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

3 8

[PATCH] linux/fb.h: Spelling s/palette/palette/
by Geert Uytterhoeven 01 Apr '22

01 Apr '22

Fix a misspelling of "palette" in a comment. Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> --- include/uapi/linux/fb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/linux/fb.h b/include/uapi/linux/fb.h index 4c14e8be7267761b..3a49913d006c9bf6 100644 --- a/include/uapi/linux/fb.h +++ b/include/uapi/linux/fb.h @@ -182,7 +182,7 @@ struct fb_fix_screeninfo { * * For pseudocolor: offset and length should be the same for all color * components. Offset specifies the position of the least significant bit - * of the pallette index in a pixel value. Length indicates the number + * of the palette index in a pixel value. Length indicates the number * of available palette entries (i.e. # of entries = 1 << length). */ struct fb_bitfield { -- 2.25.1

3 2

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2022