Re: [PATCH v9 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP
On Thu, 2023-04-27 at 16:48 -0700, Teres Alexis, Alan Previn wrote: > Because of the additional firmware, component-driver and > initialization depedencies required on MTL platform before a > PXP context can be created, UMD calling for PXP creation as a > way to get-caps can take a long time. An actual real world > customer stack has seen this happen in the 4-to-8 second range > after the kernel starts (which sees MESA's init appear in the > middle of this range as the compositor comes up). To avoid > unncessary delays experienced by the UMD for get-caps purposes, > add a GET_PARAM for I915_PARAM_PXP_SUPPORT. > alan:snip. Progress update on the UMD side - I'm working on patch for PR here: https://gitlab.freedesktop.org/alan_previn_intel/mesa-alan-previn-features/-/commit/fb9d4fbfbef7dfd3f41df335cd31549fd39ddb57 but taking time to verify certain code paths
[PATCH v4 4/4] drm: sun4i: calculate proper DCLK rate for DSI
In DSI mode, TCON0's data clock is required to run at 1/4 the per-lane
bit rate.
Signed-off-by: Roman Beranek
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 36 +-
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index eec26b1faa4b..b263de7a8237 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -291,18 +291,6 @@ static int sun4i_tcon_get_clk_delay(const struct
drm_display_mode *mode,
return delay;
}
-static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
- const struct drm_display_mode *mode)
-{
- /* Configure the dot clock */
- clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
-
- /* Set the resolution */
- regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
-SUN4I_TCON0_BASIC0_X(mode->crtc_hdisplay) |
-SUN4I_TCON0_BASIC0_Y(mode->crtc_vdisplay));
-}
-
static void sun4i_tcon0_mode_set_dithering(struct sun4i_tcon *tcon,
const struct drm_connector
*connector)
{
@@ -367,10 +355,18 @@ static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon
*tcon,
u32 block_space, start_delay;
u32 tcon_div;
+ /*
+* dclk is required to run at 1/4 the DSI per-lane bit rate.
+*/
tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;
+ clk_set_rate(tcon->dclk, mode->crtc_clock * 1000 * (bpp / lanes)
+ / SUN6I_DSI_TCON_DIV);
- sun4i_tcon0_mode_set_common(tcon, mode);
+ /* Set the resolution */
+ regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
+SUN4I_TCON0_BASIC0_X(mode->crtc_hdisplay) |
+SUN4I_TCON0_BASIC0_Y(mode->crtc_vdisplay));
/* Set dithering if needed */
sun4i_tcon0_mode_set_dithering(tcon, sun4i_tcon_get_connector(encoder));
@@ -438,7 +434,12 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon
*tcon,
tcon->dclk_min_div = 7;
tcon->dclk_max_div = 7;
- sun4i_tcon0_mode_set_common(tcon, mode);
+ clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
+
+ /* Set the resolution */
+ regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
+SUN4I_TCON0_BASIC0_X(mode->crtc_hdisplay) |
+SUN4I_TCON0_BASIC0_Y(mode->crtc_vdisplay));
/* Set dithering if needed */
sun4i_tcon0_mode_set_dithering(tcon, sun4i_tcon_get_connector(encoder));
@@ -515,7 +516,12 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
tcon->dclk_min_div = tcon->quirks->dclk_min_div;
tcon->dclk_max_div = 127;
- sun4i_tcon0_mode_set_common(tcon, mode);
+ clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
+
+ /* Set the resolution */
+ regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
+SUN4I_TCON0_BASIC0_X(mode->crtc_hdisplay) |
+SUN4I_TCON0_BASIC0_Y(mode->crtc_vdisplay));
/* Set dithering if needed */
sun4i_tcon0_mode_set_dithering(tcon, connector);
--
2.32.0 (Apple Git-132)
[PATCH v4 3/4] drm: sun4i: rename sun4i_dotclock to sun4i_tcon_dclk
While the rate of TCON0's DCLK matches dotclock for parallel and LVDS
outputs, this doesn't hold for DSI. The 'D' in DCLK actually stands for
'Data' according to Allwinner's manuals. The clock is mostly referred to
as dclk throughout this driver already anyway, so stick with that.
Signed-off-by: Roman Beranek
---
drivers/gpu/drm/sun4i/Makefile | 2 +-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 10 +-
.../drm/sun4i/{sun4i_dotclock.c => sun4i_tcon_dclk.c} | 2 +-
.../drm/sun4i/{sun4i_dotclock.h => sun4i_tcon_dclk.h} | 0
4 files changed, 7 insertions(+), 7 deletions(-)
rename drivers/gpu/drm/sun4i/{sun4i_dotclock.c => sun4i_tcon_dclk.c} (99%)
rename drivers/gpu/drm/sun4i/{sun4i_dotclock.h => sun4i_tcon_dclk.h} (100%)
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 0d04f2447b01..bad7497a0d11 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -19,7 +19,7 @@ sun8i-mixer-y += sun8i_mixer.o
sun8i_ui_layer.o \
sun8i_vi_scaler.o sun8i_csc.o
sun4i-tcon-y += sun4i_crtc.o
-sun4i-tcon-y += sun4i_dotclock.o
+sun4i-tcon-y += sun4i_tcon_dclk.o
sun4i-tcon-y += sun4i_lvds.o
sun4i-tcon-y += sun4i_tcon.o
sun4i-tcon-y += sun4i_rgb.o
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 523a6d787921..eec26b1faa4b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -31,12 +31,12 @@
#include
#include "sun4i_crtc.h"
-#include "sun4i_dotclock.h"
#include "sun4i_drv.h"
#include "sun4i_lvds.h"
#include "sun4i_rgb.h"
#include "sun4i_tcon.h"
#include "sun6i_mipi_dsi.h"
+#include "sun4i_tcon_dclk.h"
#include "sun8i_tcon_top.h"
#include "sunxi_engine.h"
@@ -1237,14 +1237,14 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
ret = sun4i_tcon_init_irq(dev, tcon);
if (ret) {
dev_err(dev, "Couldn't init our TCON interrupts\n");
- goto err_free_dotclock;
+ goto err_free_dclk;
}
tcon->crtc = sun4i_crtc_init(drm, engine, tcon);
if (IS_ERR(tcon->crtc)) {
dev_err(dev, "Couldn't create our CRTC\n");
ret = PTR_ERR(tcon->crtc);
- goto err_free_dotclock;
+ goto err_free_dclk;
}
if (tcon->quirks->has_channel_0) {
@@ -1264,7 +1264,7 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
of_node_put(remote);
if (ret < 0)
- goto err_free_dotclock;
+ goto err_free_dclk;
}
if (tcon->quirks->needs_de_be_mux) {
@@ -1290,7 +1290,7 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
return 0;
-err_free_dotclock:
+err_free_dclk:
if (tcon->quirks->has_channel_0)
sun4i_dclk_free(tcon);
err_free_clocks:
diff --git a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
b/drivers/gpu/drm/sun4i/sun4i_tcon_dclk.c
similarity index 99%
rename from drivers/gpu/drm/sun4i/sun4i_dotclock.c
rename to drivers/gpu/drm/sun4i/sun4i_tcon_dclk.c
index 417ade3d2565..03d7de1911cd 100644
--- a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon_dclk.c
@@ -10,7 +10,7 @@
#include
#include "sun4i_tcon.h"
-#include "sun4i_dotclock.h"
+#include "sun4i_tcon_dclk.h"
struct sun4i_dclk {
struct clk_hw hw;
diff --git a/drivers/gpu/drm/sun4i/sun4i_dotclock.h
b/drivers/gpu/drm/sun4i/sun4i_tcon_dclk.h
similarity index 100%
rename from drivers/gpu/drm/sun4i/sun4i_dotclock.h
rename to drivers/gpu/drm/sun4i/sun4i_tcon_dclk.h
--
2.32.0 (Apple Git-132)
[PATCH v4 2/4] ARM: dts: sunxi: rename tcon's clock output
While the rate of TCON0's DCLK matches dotclock for parallel and LVDS
outputs, this doesn't hold for DSI. According manuals from Allwinner,
DCLK is an abbreviation of Data Clock, not dotclock, so go with that
instead.
Signed-off-by: Roman Beranek
---
arch/arm/boot/dts/sun5i.dtsi | 2 +-
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 2 +-
arch/arm/boot/dts/sun8i-a83t.dtsi | 2 +-
arch/arm/boot/dts/sun8i-v3s.dtsi | 2 +-
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 250d6b87ab4d..2f901a013676 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -286,7 +286,7 @@ tcon0: lcd-controller@1c0c000 {
clock-names = "ahb",
"tcon-ch0",
"tcon-ch1";
- clock-output-names = "tcon-pixel-clock";
+ clock-output-names = "tcon-data-clock";
#clock-cells = <0>;
status = "disabled";
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index f630ab55bb6a..ddc87cc15e51 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -190,7 +190,7 @@ tcon0: lcd-controller@1c0c000 {
clock-names = "ahb",
"tcon-ch0",
"lvds-alt";
- clock-output-names = "tcon-pixel-clock";
+ clock-output-names = "tcon-data-clock";
#clock-cells = <0>;
resets = < RST_BUS_LCD>,
< RST_BUS_LVDS>;
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 82fdb04122ca..94eb3bfc989e 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -456,7 +456,7 @@ tcon0: lcd-controller@1c0c000 {
interrupts = ;
clocks = < CLK_BUS_TCON0>, < CLK_TCON0>;
clock-names = "ahb", "tcon-ch0";
- clock-output-names = "tcon-pixel-clock";
+ clock-output-names = "tcon-data-clock";
#clock-cells = <0>;
resets = < RST_BUS_TCON0>, < RST_BUS_LVDS>;
reset-names = "lcd", "lvds";
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index db194c606fdc..ab2a0e1235e4 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -191,7 +191,7 @@ tcon0: lcd-controller@1c0c000 {
< CLK_TCON0>;
clock-names = "ahb",
"tcon-ch0";
- clock-output-names = "tcon-pixel-clock";
+ clock-output-names = "tcon-data-clock";
#clock-cells = <0>;
resets = < RST_BUS_TCON0>;
reset-names = "lcd";
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 62f45f71ec65..e3b17575699c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -407,7 +407,7 @@ tcon0: lcd-controller@1c0c000 {
interrupts = ;
clocks = < CLK_BUS_TCON0>, < CLK_TCON0>;
clock-names = "ahb", "tcon-ch0";
- clock-output-names = "tcon-pixel-clock";
+ clock-output-names = "tcon-data-clock";
#clock-cells = <0>;
resets = < RST_BUS_TCON0>, < RST_BUS_LVDS>;
reset-names = "lcd", "lvds";
--
2.32.0 (Apple Git-132)
[PATCH v4 1/4] clk: sunxi-ng: a64: force select PLL_MIPI in TCON0 mux
TCON0's source clock can be fed from either PLL_MIPI, or PLL_VIDEO0(2X),
however MIPI DSI output only seems to work when PLL_MIPI is selected and
thus the choice must be hardcoded in.
Currently, this driver can't propagate rate change from N-K-M clocks
(such as PLL_MIPI) upwards. This prevents PLL_VIDEO0 from participating
in setting of the TCON0 data clock rate, limiting the precision with
which a target pixel clock can be matched.
For outputs with fixed TCON0 divider, that is DSI and LVDS, the dotclock
can deviate up to 8% off target.
Signed-off-by: Roman Beranek
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 41519185600a..eb36f8f77d55 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -528,11 +528,18 @@ static SUNXI_CCU_M_WITH_MUX_GATE(de_clk, "de", de_parents,
0x104, 0, 4, 24, 3, BIT(31),
CLK_SET_RATE_PARENT);
+/*
+ * DSI output seems to work only when PLL_MIPI selected. Set it and prevent
+ * the mux from reparenting.
+ */
+#define SUN50I_A64_TCON0_CLK_REG 0x118
+
static const char * const tcon0_parents[] = { "pll-mipi", "pll-video0-2x" };
static const u8 tcon0_table[] = { 0, 2, };
static SUNXI_CCU_MUX_TABLE_WITH_GATE(tcon0_clk, "tcon0", tcon0_parents,
tcon0_table, 0x118, 24, 3, BIT(31),
-CLK_SET_RATE_PARENT);
+CLK_SET_RATE_PARENT |
+CLK_SET_RATE_NO_REPARENT);
static const char * const tcon1_parents[] = { "pll-video0", "pll-video1" };
static const u8 tcon1_table[] = { 0, 2, };
@@ -953,6 +960,11 @@ static int sun50i_a64_ccu_probe(struct platform_device
*pdev)
writel(0x515, reg + SUN50I_A64_PLL_MIPI_REG);
+ /* Set PLL MIPI as parent for TCON0 */
+ val = readl(reg + SUN50I_A64_TCON0_CLK_REG);
+ val &= ~GENMASK(26, 24);
+ writel(val | (0 << 24), reg + SUN50I_A64_TCON0_CLK_REG);
+
ret = devm_sunxi_ccu_probe(>dev, reg, _a64_ccu_desc);
if (ret)
return ret;
--
2.32.0 (Apple Git-132)
[PATCH v4 0/4] drm: sun4i: set proper TCON0 DCLK rate in DSI mode
According to Allwinner's BSP code, in DSI mode, TCON0 clock needs to be
running at what's effectively the per-lane datarate of the DSI link.
Given that the TCON DCLK divider is fixed to 4 (SUN6I_DSI_TCON_DIV),
DCLK can't be set equal to the dotclock. Therefore labeling TCON DCLK
as sun4i_dotclock or tcon-pixel-clock shall be avoided.
With bpp bits per pixel transmitted over n DSI lanes, the target DCLK
rate for a given pixel clock is obtained as follows:
DCLK rate = 1/4 * bpp / n * pixel clock
Effect of this change can be observed through the rate of Vblank IRQs
which should now match refresh rate implied by set display mode. It
was verified to do so on a A64 board with a 2-lane and a 4-lane panel.
v2:
1. prevent reparent of tcon0 to pll-video0-2x
2. include pll-video0 in setting TCON0 DCLK rate
3. tested the whole thing also on a PinePhone
v3:
1. accept that pll-video0 can't be included in setting TCON0 DCLK rate
2. reset pll-video0 to its default rate in case u-boot changed it
v4:
1. keep pll-video0 as is
2. assign parent to TCON0 mux in sun50i_a64_ccu_probe (not in DT)
Roman Beranek (4):
clk: sunxi-ng: a64: force select PLL_MIPI in TCON0 mux
ARM: dts: sunxi: rename tcon's clock output
drm: sun4i: rename sun4i_dotclock to sun4i_tcon_dclk
drm: sun4i: calculate proper DCLK rate for DSI
arch/arm/boot/dts/sun5i.dtsi | 2 +-
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 2 +-
arch/arm/boot/dts/sun8i-a83t.dtsi | 2 +-
arch/arm/boot/dts/sun8i-v3s.dtsi | 2 +-
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 2 +-
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 14 +-
drivers/gpu/drm/sun4i/Makefile| 2 +-
drivers/gpu/drm/sun4i/sun4i_tcon.c| 46 +++
.../{sun4i_dotclock.c => sun4i_tcon_dclk.c} | 2 +-
.../{sun4i_dotclock.h => sun4i_tcon_dclk.h} | 0
10 files changed, 46 insertions(+), 28 deletions(-)
rename drivers/gpu/drm/sun4i/{sun4i_dotclock.c => sun4i_tcon_dclk.c} (99%)
rename drivers/gpu/drm/sun4i/{sun4i_dotclock.h => sun4i_tcon_dclk.h} (100%)
base-commit: 8a91b29f1f50ce7742cdbe5cf11d17f128511f3f
--
2.32.0 (Apple Git-132)
[PATCH] drm/amdgpu/display: Enable DC_FP for LoongArch
Now LoongArch provides kernel_fpu_begin() and kernel_fpu_end() so we can
enable DC_FP for DCN devices.
Signed-off-by: WANG Xuerui
Signed-off-by: Huacai Chen
---
drivers/gpu/drm/amd/display/Kconfig| 2 +-
drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c | 6 --
drivers/gpu/drm/amd/display/dc/dml/Makefile| 5 +
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/Kconfig
b/drivers/gpu/drm/amd/display/Kconfig
index 2d8e55e29637..49df073962d5 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -8,7 +8,7 @@ config DRM_AMD_DC
depends on BROKEN || !CC_IS_CLANG || X86_64 || SPARC64 || ARM64
select SND_HDA_COMPONENT if SND_HDA_CORE
# !CC_IS_CLANG: https://github.com/ClangBuiltLinux/linux/issues/1752
- select DRM_AMD_DC_FP if (X86 || (PPC64 && ALTIVEC) || (ARM64 &&
KERNEL_MODE_NEON && !CC_IS_CLANG))
+ select DRM_AMD_DC_FP if (X86 || LOONGARCH || (PPC64 && ALTIVEC) ||
(ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG))
help
Choose this option if you want to use the new display engine
support for AMDGPU. This adds required support for Vega and
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
index 1743ca0a3641..86f4c0e04654 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
@@ -33,6 +33,8 @@
#include
#elif defined(CONFIG_ARM64)
#include
+#elif defined(CONFIG_LOONGARCH)
+#include
#endif
/**
@@ -88,7 +90,7 @@ void dc_fpu_begin(const char *function_name, const int line)
*pcpu += 1;
if (*pcpu == 1) {
-#if defined(CONFIG_X86)
+#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
kernel_fpu_begin();
#elif defined(CONFIG_PPC64)
if (cpu_has_feature(CPU_FTR_VSX_COMP)) {
@@ -127,7 +129,7 @@ void dc_fpu_end(const char *function_name, const int line)
pcpu = get_cpu_ptr(_recursion_depth);
*pcpu -= 1;
if (*pcpu <= 0) {
-#if defined(CONFIG_X86)
+#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
kernel_fpu_end();
#elif defined(CONFIG_PPC64)
if (cpu_has_feature(CPU_FTR_VSX_COMP)) {
diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile
b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index 01db035589c5..542962a93e8f 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -38,6 +38,11 @@ ifdef CONFIG_ARM64
dml_rcflags := -mgeneral-regs-only
endif
+ifdef CONFIG_LOONGARCH
+dml_ccflags := -mabi=lp64s -mfpu=64
+dml_rcflags := -msoft-float
+endif
+
ifdef CONFIG_CC_IS_GCC
ifneq ($(call gcc-min-version, 70100),y)
IS_OLD_GCC = 1
--
2.39.1
[Bug 217398] amdgpu module loading breaks display output - no signal
https://bugzilla.kernel.org/show_bug.cgi?id=217398 The Linux kernel's regression tracker (Thorsten Leemhuis) (regressi...@leemhuis.info) changed: What|Removed |Added CC||regressi...@leemhuis.info --- Comment #4 from The Linux kernel's regression tracker (Thorsten Leemhuis) (regressi...@leemhuis.info) --- This report here will likely not be seen by the amdgpu developers, they expect bugs to be filed here instead: https://gitlab.freedesktop.org/drm/amd/-/issues If you file it there, please drop a link to the report here. BTW, did it work on earlier kernels? Which ones? there is a report about a problem in earlier kernels that sound somewhat similar (but it might be something totally different): https://lore.kernel.org/all/46a7eb80-5f09-4f6a-4fd3-9550dafd4...@felixrichter.tech/ -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 217398] amdgpu module loading breaks display output - no signal
https://bugzilla.kernel.org/show_bug.cgi?id=217398 --- Comment #3 from The Linux kernel's regression tracker (Thorsten Leemhuis) (regressi...@leemhuis.info) --- *** Bug 217397 has been marked as a duplicate of this bug. *** -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 217397] amdgpu module loading breaks display output - no signal
https://bugzilla.kernel.org/show_bug.cgi?id=217397 The Linux kernel's regression tracker (Thorsten Leemhuis) (regressi...@leemhuis.info) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from The Linux kernel's regression tracker (Thorsten Leemhuis) (regressi...@leemhuis.info) --- *** This bug has been marked as a duplicate of bug 217398 *** -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 217397] amdgpu module loading breaks display output - no signal
https://bugzilla.kernel.org/show_bug.cgi?id=217397 The Linux kernel's regression tracker (Thorsten Leemhuis) (regressi...@leemhuis.info) changed: What|Removed |Added CC||regressi...@leemhuis.info --- Comment #1 from The Linux kernel's regression tracker (Thorsten Leemhuis) (regressi...@leemhuis.info) --- This report here will likely not be seen by the amdgpu developers, they expect bugs to be filed here instead: https://gitlab.freedesktop.org/drm/amd/-/issues If you file it there, please drop a link to the report here. BTW, did it work on earlier kernels? Which ones? there is a report about a problem in earlier kernels that sound somewhat similar (but it might be something totally different): https://lore.kernel.org/all/46a7eb80-5f09-4f6a-4fd3-9550dafd4...@felixrichter.tech/ -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[git pull] drm fixes part 2 for 6.4-rc1
Hi Linus, This is the fixes for the last couple of weeks for i915 and last 3 weeks for amdgpu, lots of them but pretty scattered around and all pretty small. Dave. drm-next-2023-05-05: drm fixes part 2 for 6.4-rc1 amdgpu: - SR-IOV fixes - DCN 3.2 fixes - DC mclk handling fixes - eDP fixes - SubVP fixes - HDCP regression fix - DSC fixes - DC FP fixes - DCN 3.x fixes - Display flickering fix when switching between vram and gtt - Z8 power saving fix - Fix hang when skipping modeset - GPU reset fixes - Doorbell fix when resizing BARs - Fix spurious warnings in gmc - Locking fix for AMDGPU_SCHED IOCTL - SR-IOV fix - DCN 3.1.4 fix - DCN 3.2 fix - Fix job cleanup when CS is aborted i915: - skl pipe source size check - mtl transcoder mask fix - DSI power on sequence fix - GuC versioning corner case fix The following changes since commit cf03e2956af307dc25e8c41fd4cffe44482a6ec1: Merge tag 'drm-misc-next-fixes-2023-04-26' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2023-04-27 11:29:34 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-next-2023-05-05 for you to fetch changes up to 1bef84af084e981550d9ecc3359baa22533d7b99: Merge tag 'drm-intel-next-fixes-2023-05-04-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2023-05-05 11:27:26 +1000) drm fixes part 2 for 6.4-rc1 amdgpu: - SR-IOV fixes - DCN 3.2 fixes - DC mclk handling fixes - eDP fixes - SubVP fixes - HDCP regression fix - DSC fixes - DC FP fixes - DCN 3.x fixes - Display flickering fix when switching between vram and gtt - Z8 power saving fix - Fix hang when skipping modeset - GPU reset fixes - Doorbell fix when resizing BARs - Fix spurious warnings in gmc - Locking fix for AMDGPU_SCHED IOCTL - SR-IOV fix - DCN 3.1.4 fix - DCN 3.2 fix - Fix job cleanup when CS is aborted i915: - skl pipe source size check - mtl transcoder mask fix - DSI power on sequence fix - GuC versioning corner case fix Alex Hung (1): drm/amd/display: allow edp updates for virtual signal Alvin Lee (1): drm/amd/display: Reduce SubVP + DRR stretch margin Aurabindo Pillai (5): drm/amd/display: Fix hang when skipping modeset drm/amd/display: remove incorrect early return drm/amd/display: Fixes for dcn32_clk_mgr implementation drm/amd/display: Do not clear GPINT register when releasing DMUB from reset drm/amd/display: Update bounding box values for DCN321 Chia-I Wu (1): drm/amdgpu: add a missing lock for AMDGPU_SCHED Chong Li (1): drm/amdgpu: release gpu full access after "amdgpu_device_ip_late_init" Cruise Hung (1): drm/amd/display: Reset OUTBOX0 r/w pointer on DMUB reset Dave Airlie (4): Merge tag 'amd-drm-fixes-6.4-2023-04-26' of https://gitlab.freedesktop.org/agd5f/linux into drm-next Merge tag 'drm-intel-next-fixes-2023-04-27' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Merge tag 'amd-drm-fixes-6.4-2023-05-03' of https://gitlab.freedesktop.org/agd5f/linux into drm-next Merge tag 'drm-intel-next-fixes-2023-05-04-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Guchun Chen (1): drm/amdgpu: drop redundant sched job cleanup when cs is aborted Hamza Mahfooz (2): drm/amd/display: fix flickering caused by S/G mode drm/amdgpu: fix an amdgpu_irq_put() issue in gmc_v9_0_hw_fini() Hans de Goede (1): drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep() Hersen Wu (3): drm/amd/display: fix memleak in aconnector->timing_requested drm/amd/display: fix access hdcp_workqueue assert drm/amd/display: Return error code on DSC atomic check failure Horace Chen (1): drm/amdgpu: disable SDMA WPTR_POLL_ENABLE for SR-IOV Horatio Zhang (2): drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v11_0_hw_fini drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v10_0_hw_fini Igor Kravchenko (1): drm/amd/display: Set min_width and min_height capability for DCN30 Jane Jian (1): drm/amdgpu/vcn: fix mmsch ctx table size Jasdeep Dhillon (1): drm/amd/display: Isolate remaining FPU code in DCN32 Jingwen Zhu (1): drm/amd/display: Improvement for handling edp link training fails John Harrison (1): drm/i915/guc: Actually return an error if GuC version range check fails Josip Pavic (1): drm/amd/display: copy dmub caps to dc on dcn31 Leo Chen (2): drm/amd/display: Lowering min Z8 residency time drm/amd/display: Change default Z8 watermark values Michael Mityushkin (1): drm/amd/display: Apply correct panel mode when reinitializing hardware Radhakrishna Sripada (1): drm/i915/mtl: Add the missing CPU transcoder mask in intel_device_info Rodrigo Siqueira (8): drm/amd/display: Update bouding box values for DCN32 drm/amd/display: Add
[PATCH] dma-buf/sync_file: Use fdget()
From: Ye Xingchen
convert the fget() use to fdget().
Signed-off-by: Ye Xingchen
---
drivers/dma-buf/sync_file.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index af57799c86ce..222b13b1bdb8 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -78,18 +78,18 @@ EXPORT_SYMBOL(sync_file_create);
static struct sync_file *sync_file_fdget(int fd)
{
- struct file *file = fget(fd);
+ struct struct fd f = fdget(fd);
- if (!file)
+ if (!f.file)
return NULL;
- if (file->f_op != _file_fops)
+ if (f.file->f_op != _file_fops)
goto err;
- return file->private_data;
+ return f.file->private_data;
err:
- fput(file);
+ fdput(f);
return NULL;
}
--
2.25.1
[linux-next:master] BUILD REGRESSION 145e5cddfe8b4bf607510b2dcf630d95f4db420f
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 145e5cddfe8b4bf607510b2dcf630d95f4db420f Add linux-next specific files for 20230504 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202304102354.q4voxgte-...@intel.com https://lore.kernel.org/oe-kbuild-all/202304220119.94pw6ysd-...@intel.com https://lore.kernel.org/oe-kbuild-all/202304230014.ybscpx20-...@intel.com https://lore.kernel.org/oe-kbuild-all/202304250419.ytcltuhg-...@intel.com https://lore.kernel.org/oe-kbuild-all/202305042329.gyk53ked-...@intel.com https://lore.kernel.org/oe-kbuild-all/202305050237.1cq4fbks-...@intel.com Error/Warning: (recently discovered and may have been fixed) arch/um/drivers/harddog_user.c:6:10: fatal error: stdio.h: No such file or directory drivers/accel/habanalabs/gaudi/gaudi.c:117:19: warning: unused variable 'gaudi_irq_name' [-Wunused-const-variable] drivers/base/regmap/regcache-maple.c:113:23: warning: 'lower_index' is used uninitialized [-Wuninitialized] drivers/base/regmap/regcache-maple.c:113:36: warning: 'lower_last' is used uninitialized [-Wuninitialized] drivers/bluetooth/btnxpuart.c:1332:34: warning: unused variable 'nxpuart_of_match_table' [-Wunused-const-variable] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6339:6: warning: no previous prototype for 'amdgpu_dm_connector_funcs_force' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6395:21: warning: variable 'count' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:494:13: warning: variable 'j' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:48:38: warning: unused variable 'golden_settings_gc_9_4_3' [-Wunused-const-variable] drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:62: warning: wrong kernel-doc identifier on line: drivers/gpu/drm/i915/i915_pmu.h:41: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/i915/i915_request.h:176: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/i915/i915_vma.h:145: warning: expecting prototype for i915_vma_offset(). Prototype was for i915_vma_size() instead drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: warning: variable 'ret' is uninitialized when used here [-Wuninitialized] mm/gup.c:2813:14: error: implicit declaration of function 'folio_fast_pin_allowed'; did you mean 'folio_test_pinned'? [-Werror=implicit-function-declaration] mm/gup.c:2813:7: error: call to undeclared function 'folio_fast_pin_allowed'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] phy-mtk-hdmi-mt8195.c:(.text+0x186): undefined reference to `__floatundidf' riscv64-linux-ld: phy-mtk-hdmi-mt8195.c:(.text+0x198): undefined reference to `__ltdf2' riscv64-linux-ld: phy-mtk-hdmi-mt8195.c:(.text+0x1b8): undefined reference to `__gedf2' Unverified Error/Warning (likely false positive, please contact us if interested): drivers/cpufreq/pcc-cpufreq.c: linux/platform_device.h is included more than once. drivers/gpu/host1x/context.c:82 host1x_memory_context_list_init() warn: missing error code 'err' drivers/gpu/host1x/dev.c:417 host1x_iommu_attach() warn: passing zero to 'ERR_PTR' fs/ext4/super.c:4722 ext4_check_feature_compatibility() warn: bitwise AND condition is false here Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:no-previous-prototype-for-amdgpu_dm_connector_funcs_force | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- alpha-randconfig-r003-20230501 | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- arc-allyesconfig | |-- drivers-base-regmap-regcache-maple.c:warning:lower_index-is-used-uninitialized | |-- drivers-base-regmap-regcache-maple.c:warning:lower_last-is-used-uninitialized | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:no-previous-prototype-for-amdgpu_dm_connector_funcs_force | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- arc-buildonly-randconfig-r001-20230430 | |-- drivers-base-regmap-regcache-maple.c:warning:lower_index-is-used-uninitialized | `-- drivers-base-regmap-regcache-maple.c:warning:lower_last-is-used-uninitialized |-- arc-buildonly-randconfig-r002-20230502 | |-- drivers-base-regmap-regcache-maple.c:warning:lower_index-is-used-uninitialized | `-- drivers-base-regmap-regcache-maple.c:warning:lower_last-is-used
[PATCH] dma-buf: Use fdget()
From: Ye Xingchen
convert the fget() use to fdget().
Signed-off-by: Ye Xingchen
---
drivers/dma-buf/dma-buf.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index aa4ea8530cb3..bf4980b6f80c 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -729,19 +729,17 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_fd, DMA_BUF);
*/
struct dma_buf *dma_buf_get(int fd)
{
- struct file *file;
-
- file = fget(fd);
+ struct fd f = fdget(fd);
- if (!file)
+ if (!f.file)
return ERR_PTR(-EBADF);
- if (!is_dma_buf_file(file)) {
- fput(file);
+ if (!is_dma_buf_file(f.file)) {
+ fdput(f);
return ERR_PTR(-EINVAL);
}
- return file->private_data;
+ return f.file->private_data;
}
EXPORT_SYMBOL_NS_GPL(dma_buf_get, DMA_BUF);
--
2.25.
[PATCH] phy: mediatek: Remove unusued ret and check
From: Palmer Dabbelt
This trips up a maybe-uninitialized warning, but it's actually just not
used.
Signed-off-by: Palmer Dabbelt
---
I just stumbled into this one when trying to test Linus' master. I'm
not sure it's a sane fix, but I'm not using the driver. No rush no my
end, I'll just keep the fix around in my local tree for now.
---
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
index abfc077fb0a8..3fc0913ec73b 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
@@ -213,7 +213,7 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy *hdmi_phy,
struct clk_hw *hw,
u64 tmds_clk, pixel_clk, da_hdmitx21_ref_ck, ns_hdmipll_ck, pcw;
u8 txpredivs[4] = { 2, 4, 6, 12 };
u32 fbkdiv_low;
- int i, ret;
+ int i;
pixel_clk = rate;
tmds_clk = pixel_clk;
@@ -295,8 +295,6 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy *hdmi_phy,
struct clk_hw *hw,
mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
PLL_FBKDIV_HS3, posdiv1, posdiv2, txprediv,
txposdiv, digital_div);
- if (ret)
- return -EINVAL;
return 0;
}
--
2.40.0
Re: [PATCH v6 6/7] drm/msm/dsi: update hdisplay calculation for dsi_timing_setup
On 5/4/2023 2:56 PM, Marijn Suijten wrote: On 2023-04-12 16:25:20, Jessica Zhang wrote: hdisplay for compressed images should be calculated as bytes_per_slice * slice_count. Thus, use MSM DSC helper to calculate hdisplay for dsi_timing_setup instead of directly using mode->hdisplay. Changes in v3: - Split from previous patch - Initialized hdisplay as uncompressed pclk per line at the beginning of dsi_timing_setup as to not break dual DSI calculations Changes in v4: - Moved pclk_per_intf calculations to DSC hdisplay adjustments Signed-off-by: Jessica Zhang Reviewed-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index 508577c596ff..ae966d4e349d 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -952,7 +952,7 @@ static void dsi_timing_setup(struct msm_dsi_host *msm_host, bool is_bonded_dsi) * pulse width same */ h_total -= hdisplay; - hdisplay /= 3; + hdisplay = msm_dsc_get_pclk_per_intf(msm_host->dsc) / 3; This patch is unfortunately regressing the Sony Xperia XZ3 (sdm845, single DSI), which will only show garbage when it is applied. Are you sure this is correct, and the helper is returning the right values? I'll see if I can help review and validate those later, and debug if necessary. Hi Marijn, Just checking, are you testing this with the DSI for DSC v1.2 changes? That series includes a fix to the word count calculation [1] needed to get DSC working. Thanks, Jessica Zhang [1] https://patchwork.freedesktop.org/patch/535115/?series=117219=1 - Marijn h_total += hdisplay; ha_end = ha_start + hdisplay; } -- 2.40.0
Re: [PATCH v5 3/7] drm/msm/dpu: add DPU_PINGPONG_DSC bits into PP_BLK and PP_BLK_TE marcos
On 05/05/2023 00:39, Marijn Suijten wrote: On 2023-05-04 12:50:57, Abhinav Kumar wrote: On 5/4/2023 12:36 PM, Marijn Suijten wrote: On 2023-05-04 11:25:44, Abhinav Kumar wrote: Sure, if you really prefer a split I'd go for two patches: 1. Add the flag to the enum and catalog; 2. Add the ops guard (functional change). Then don't forget to reword the commit message, following the guidelines below and the suggestion for 2/7. - Marijn Plan sounds good to me. Marijn, we will wait for a couple of days to post the next rev but would be hard more than that as we need to pick up other things which are pending on top of this. Hence would appreciate if you can finish reviews by then. It depends on how many more revisions are needed after that, and not all patches in this series have an r-b just yet. Given the amount of review comments that are still trickling in (also on patches that already have maintainer r-b) I don't think we're quite there to start thinging about picking this up in drm-msm just yet. I doubt anyone wants a repeat of the original DSC series, which went through many review rounds yet still required multiple series of bugfixes (some of which were pointed out and ignored in review) to be brought to a working state. But the split across topics per series already makes this a lot less likely, many thanks for that. I think the outstanding comments shouldnt last more than 1-2 revs more on this one as its mostly due to multiple patches on the list touching catalog at the same time. I have been monitoring the comments closely even though I dont respond to all of them. One of the major reasons of the number of issues with DSC 1.1 was QC didn't really have the devices or panels to support it. Thats why I changed that this time around to take more control of validation of DSC 1.2 and ofcourse decided to break up of series into the least amount of functionality needed to keep the DPU driver intact. Really glad that you are able to test and validate it now, that goes a long way. Does that also mean you can post the panel patches quickly, so that everyone has a point of reference? As you said that is one of the main points where DSC 1.1 "went wrong" (a misunderstanding of drm_dsc_config). All that being said, we still value your comments and would gladly wait for a couple of days like I already wrote. But there are more incremental series on top of this: -> DSI changes for DSC 1.2 -> proper teardown for DSC -> DSC pair allocation support -> DSC 1.2 over DP Yeah, I'm familiar with the concept of having many dependent series, and now DSC series are even rebasing on DPU (catalog) cleanups to preempt conflicts, which is really hard to follow. Dmitry just pushed v5 of "drm/i915/dsc: change DSC param tables to follow the DSC model" [1] and seems to have dropped some patches that some of these series are depending on, resulting in compilation failures. Other series don't seem to fully mention all their dependencies. We'd have to pick them into our code or submit directly to drm-misc. I removed the patches which we can get in w/o Intel review. [1]: https://lore.kernel.org/linux-arm-msm/20230504153511.4007320-1-dmitry.barysh...@linaro.org/T/#u So, for this to go as convenient as possible, do you have a list of series, in a desired order that they should be reviewed and tested? That way I can direct my priorities and help achieve the goal of picking base dependencies as early as possible. For example, one of the many series regresses DSC on the Xperia XZ3 (SDM845), but I have yet to bisect and understand which patch it is. Will let you know as soon as I get my tree in order. - Marijn -- With best wishes Dmitry
Re: [PATCH v6 6/7] drm/msm/dsi: update hdisplay calculation for dsi_timing_setup
On 5/4/2023 2:56 PM, Marijn Suijten wrote: On 2023-04-12 16:25:20, Jessica Zhang wrote: hdisplay for compressed images should be calculated as bytes_per_slice * slice_count. Thus, use MSM DSC helper to calculate hdisplay for dsi_timing_setup instead of directly using mode->hdisplay. Changes in v3: - Split from previous patch - Initialized hdisplay as uncompressed pclk per line at the beginning of dsi_timing_setup as to not break dual DSI calculations Changes in v4: - Moved pclk_per_intf calculations to DSC hdisplay adjustments Signed-off-by: Jessica Zhang Reviewed-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index 508577c596ff..ae966d4e349d 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -952,7 +952,7 @@ static void dsi_timing_setup(struct msm_dsi_host *msm_host, bool is_bonded_dsi) * pulse width same */ h_total -= hdisplay; - hdisplay /= 3; + hdisplay = msm_dsc_get_pclk_per_intf(msm_host->dsc) / 3; This patch is unfortunately regressing the Sony Xperia XZ3 (sdm845, single DSI), which will only show garbage when it is applied. Are you sure this is correct, and the helper is returning the right values? I'll see if I can help review and validate those later, and debug if necessary. - Marijn To help us debug these kind of issues, can you pls point us to your panel driver? h_total += hdisplay; ha_end = ha_start + hdisplay; } -- 2.40.0
Re: [PATCH v5 3/7] drm/msm/dpu: add DPU_PINGPONG_DSC bits into PP_BLK and PP_BLK_TE marcos
On 5/4/2023 1:03 PM, Abhinav Kumar wrote: On 5/4/2023 12:59 PM, Dmitry Baryshkov wrote: On 04/05/2023 22:50, Abhinav Kumar wrote: On 5/4/2023 12:36 PM, Marijn Suijten wrote: On 2023-05-04 11:25:44, Abhinav Kumar wrote: Sure, if you really prefer a split I'd go for two patches: 1. Add the flag to the enum and catalog; 2. Add the ops guard (functional change). Then don't forget to reword the commit message, following the guidelines below and the suggestion for 2/7. - Marijn Plan sounds good to me. Marijn, we will wait for a couple of days to post the next rev but would be hard more than that as we need to pick up other things which are pending on top of this. Hence would appreciate if you can finish reviews by then. It depends on how many more revisions are needed after that, and not all patches in this series have an r-b just yet. Given the amount of review comments that are still trickling in (also on patches that already have maintainer r-b) I don't think we're quite there to start thinging about picking this up in drm-msm just yet. I doubt anyone wants a repeat of the original DSC series, which went through many review rounds yet still required multiple series of bugfixes (some of which were pointed out and ignored in review) to be brought to a working state. But the split across topics per series already makes this a lot less likely, many thanks for that. I think the outstanding comments shouldnt last more than 1-2 revs more on this one as its mostly due to multiple patches on the list touching catalog at the same time. I have been monitoring the comments closely even though I dont respond to all of them. One of the major reasons of the number of issues with DSC 1.1 was QC didn't really have the devices or panels to support it. Thats why I changed that this time around to take more control of validation of DSC 1.2 and ofcourse decided to break up of series into the least amount of functionality needed to keep the DPU driver intact. All that being said, we still value your comments and would gladly wait for a couple of days like I already wrote. But there are more incremental series on top of this: -> DSI changes for DSC 1.2 -> proper teardown for DSC -> DSC pair allocation support -> DSC 1.2 over DP We will be posting all of these within next couple of weeks on top of this. I'd say, it's fine to post them now, as we have more or less agreed on the helper series. The interface between the series should be stable then. The RM series is probably the one having bigger dependencies/conflicts on other pending patches (include virtual wide planes) 1 is already posted, will keep fixing review comments 2 will be posted pretty soon DSC1.2 over DSI will be complete with this set. I will finish up virtual planes review by early next week. Already underway ... 3 & 4 will be posted soon after that. Hi all, Just want to add to this list of series -- I'm planning to post the r66451 panel driver + dts changes next week after I post the v2 of DSI for DSC v1.2. Thanks, Jessica Zhang In other words, let's take it slow and do things properly this time. And who knows, perhaps the rest of these patches are more straightforward. Ack. the intent is always to do things right the first time. - Marijn
Re: [PATCH v6 6/7] drm/msm/dsi: update hdisplay calculation for dsi_timing_setup
On 2023-04-12 16:25:20, Jessica Zhang wrote: > hdisplay for compressed images should be calculated as bytes_per_slice * > slice_count. Thus, use MSM DSC helper to calculate hdisplay for > dsi_timing_setup instead of directly using mode->hdisplay. > > Changes in v3: > - Split from previous patch > - Initialized hdisplay as uncompressed pclk per line at the beginning of > dsi_timing_setup as to not break dual DSI calculations > > Changes in v4: > - Moved pclk_per_intf calculations to DSC hdisplay adjustments > > Signed-off-by: Jessica Zhang > Reviewed-by: Dmitry Baryshkov > --- > drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c > b/drivers/gpu/drm/msm/dsi/dsi_host.c > index 508577c596ff..ae966d4e349d 100644 > --- a/drivers/gpu/drm/msm/dsi/dsi_host.c > +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c > @@ -952,7 +952,7 @@ static void dsi_timing_setup(struct msm_dsi_host > *msm_host, bool is_bonded_dsi) >* pulse width same >*/ > h_total -= hdisplay; > - hdisplay /= 3; > + hdisplay = msm_dsc_get_pclk_per_intf(msm_host->dsc) / 3; This patch is unfortunately regressing the Sony Xperia XZ3 (sdm845, single DSI), which will only show garbage when it is applied. Are you sure this is correct, and the helper is returning the right values? I'll see if I can help review and validate those later, and debug if necessary. - Marijn > h_total += hdisplay; > ha_end = ha_start + hdisplay; > } > > -- > 2.40.0 >
Re: [PATCH v5 3/7] drm/msm/dpu: add DPU_PINGPONG_DSC bits into PP_BLK and PP_BLK_TE marcos
On 2023-05-04 12:50:57, Abhinav Kumar wrote: > > > On 5/4/2023 12:36 PM, Marijn Suijten wrote: > > On 2023-05-04 11:25:44, Abhinav Kumar wrote: > > > >>> Sure, if you really prefer a split I'd go for two patches: > >>> 1. Add the flag to the enum and catalog; > >>> 2. Add the ops guard (functional change). > >>> > >>> Then don't forget to reword the commit message, following the guidelines > >>> below and the suggestion for 2/7. > >>> > >>> - Marijn > >> > >> Plan sounds good to me. > >> > >> Marijn, we will wait for a couple of days to post the next rev but would > >> be hard more than that as we need to pick up other things which are > >> pending on top of this. Hence would appreciate if you can finish reviews > >> by then. > > > > It depends on how many more revisions are needed after that, and not all > > patches in this series have an r-b just yet. Given the amount of review > > comments that are still trickling in (also on patches that already have > > maintainer r-b) I don't think we're quite there to start thinging about > > picking this up in drm-msm just yet. I doubt anyone wants a repeat of > > the original DSC series, which went through many review rounds yet still > > required multiple series of bugfixes (some of which were pointed out and > > ignored in review) to be brought to a working state. But the split > > across topics per series already makes this a lot less likely, many > > thanks for that. > > > > I think the outstanding comments shouldnt last more than 1-2 revs more > on this one as its mostly due to multiple patches on the list touching > catalog at the same time. I have been monitoring the comments closely > even though I dont respond to all of them. > > One of the major reasons of the number of issues with DSC 1.1 was QC > didn't really have the devices or panels to support it. Thats why I > changed that this time around to take more control of validation of DSC > 1.2 and ofcourse decided to break up of series into the least amount of > functionality needed to keep the DPU driver intact. Really glad that you are able to test and validate it now, that goes a long way. Does that also mean you can post the panel patches quickly, so that everyone has a point of reference? As you said that is one of the main points where DSC 1.1 "went wrong" (a misunderstanding of drm_dsc_config). > All that being said, we still value your comments and would gladly wait > for a couple of days like I already wrote. But there are more > incremental series on top of this: > > -> DSI changes for DSC 1.2 > -> proper teardown for DSC > -> DSC pair allocation support > -> DSC 1.2 over DP Yeah, I'm familiar with the concept of having many dependent series, and now DSC series are even rebasing on DPU (catalog) cleanups to preempt conflicts, which is really hard to follow. Dmitry just pushed v5 of "drm/i915/dsc: change DSC param tables to follow the DSC model" [1] and seems to have dropped some patches that some of these series are depending on, resulting in compilation failures. Other series don't seem to fully mention all their dependencies. [1]: https://lore.kernel.org/linux-arm-msm/20230504153511.4007320-1-dmitry.barysh...@linaro.org/T/#u So, for this to go as convenient as possible, do you have a list of series, in a desired order that they should be reviewed and tested? That way I can direct my priorities and help achieve the goal of picking base dependencies as early as possible. For example, one of the many series regresses DSC on the Xperia XZ3 (SDM845), but I have yet to bisect and understand which patch it is. Will let you know as soon as I get my tree in order. - Marijn
[PATCH] Documentation/gpu: Requirements for driver-specific KMS uAPIs
We have steered away for a long time now from driver-specific KMS APIs for good reasons but never codified our stance. With the proposal of new, driver-specific color management uAPIs [1] it is important to outline the requirements for the rare times when driver-specific KMS uAPIs are desired in order to move complex topics along. [1] https://patchwork.freedesktop.org/series/116862/ Signed-off-by: Harry Wentland Cc: Simon Ser Cc: Joshua Ashton Cc: Michel Dänzer Cc: Sebastian Wick Cc: Jonas Ådahl Cc: Alex Goins Cc: Pekka Paalanen Cc: Melissa Wen Cc: Aleix Pol Cc: Xaver Hugl Cc: Victoria Brekenfeld Cc: Daniel Vetter Cc: Dave Airlie Cc: Ville Syrjälä Cc: Uma Shankar To: dri-devel@lists.freedesktop.org --- Documentation/gpu/drm-uapi.rst | 32 1 file changed, 32 insertions(+) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index ce47b4292481..eaefc3ed980c 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -118,6 +118,38 @@ is already rather painful for the DRM subsystem, with multiple different uAPIs for the same thing co-existing. If we add a few more complete mistakes into the mix every year it would be entirely unmanageable. +.. _driver_specific: + +Driver-Specific DRM/KMS uAPI + + +Driver-specific interfaces are strongly discouraged for DRM/KMS interfaces. +Kernel-modesetting (KMS) functionality does in principle apply to all drivers. +Driver-specific uAPIs tends to lead to unique implementations in userspace and +are often hard to maintain, especially when different drivers implement similar +but subtly different uAPIs. + +At times arriving at a consensus uAPI can be a difficult and lengthy process and +might benefit from experimentation. This experimentation might warrant +introducing driver specific APIs in order to move the eosystem forward. If a +driver decides to go down this path we ask for the following: + +- An agreement within the community that introducing driver-specific uAPIs is + warranted in this case; + +- The new uAPI is behind a CONFIG option that is clearly marked EXPERIMENTAL and + is disabled by default; + +- The new uAPI is enabled when a module parameter for the driver is set, and + defaults to 'off' otherwise; + +- The new uAPI follows all open-source userspace requirements outlined above; + +- The focus is maintained on development of a vendor-neutral uAPI and progress + toward such an uAPI needs to be apparent on public forums. If no such progress + is visible within a reasonable timeframe (1-2 years) anybody is within their + right to send, review, and merge patches that remove the driver-specific uAPI. + .. _drm_render_node: Render nodes -- 2.40.1
Re: [PATCH 1/4] drm/msm/dsi: Adjust pclk rate for compression
On 2023-05-04 22:33:17, Marijn Suijten wrote:
> Title suggestion: use the wording "reduce pclk rate" :)
>
> (Eventually "when DSC is enabled", instead of "for compression")
>
> On 2023-05-02 18:19:12, Jessica Zhang wrote:
> > Divide the pclk rate by the compression ratio when DSC is enabled
> >
> > Signed-off-by: Jessica Zhang
>
> Thank you so much for sending this. The compression ratio was applied
> to hdisplay
In hindsight, on the note of hdisplay, dsi_timing_setup() actually only
divides the visual portion - that is hdisplay out of htotal - without
affecting the back and front porch.
Since this clock inside the mode is based on the full htotal * vtotal *
..., should we compensate for that and only divide the visual portion of
the clock signal by 3? Otherwise we might not have enough clockticks to
perform the front and back porch (even though CMD mode doesn't really
have porches, I have yet to properly understand that part of the
signal).
- Marijn
> , but not the clocks yet, and with this patch I get a massive
> reduction in clock speeds on the Xperia XZ3, without regressions nor
> affecting performance/fps:
>
> gcc_sys_noc_cpuss_ahb_clk 1101920
> 0 0 5 Y
> gcc_cpuss_ahb_clk 1101920
> 0 0 5 Y
> bi_tcxo 6601920
> 0 0 5 Y
>dsi0vco_clk110
> [-1873793994-]{+1249195898+} 0 0 5 Y
> dsi0_pll_out_div_clk110
> [-1873793994-]{+624597949+} 0 0 5 Y
> dsi0_pll_post_out_div_clk 000
> [-468448498-]{+156149487+} 0 0 5 Y
> dsi0_pll_bit_clk 220
> [-1873793994-]{+624597949+} 0 0 5 Y
> dsi0_pclk_mux 110
> [-1873793994-]{+624597949+} 0 0 5 Y
>dsi0_phy_pll_out_dsiclk 110
> [-312298999-]{+104099659+} 0 0 5 Y
> disp_cc_mdss_pclk0_clk_src 110
> [-312298999-]{+104099659+} 0 0 5 Y
> disp_cc_mdss_pclk0_clk 110
> [-312298999-]{+104099659+} 0 0 5 Y
> dsi0_pll_by_2_bit_clk 000
> [-936896997-]{+312298974+} 0 0 5 Y
> dsi0_phy_pll_out_byteclk 110
> [-234224249-]{+78074743+} 0 0 5 Y
>disp_cc_mdss_byte0_clk_src 220
> [-234224249-]{+78074743+} 0 0 5 Y
> disp_cc_mdss_byte0_div_clk_src 11
> 0[-117112125-]{+39037372+} 0 0 5 Y
> disp_cc_mdss_byte0_intf_clk 11
> 0[-117112125-]{+39037372+} 0 0 5 Y
> disp_cc_mdss_byte0_clk 110
> [-234224249-]{+78074743+} 0 0 5 Y
>gpu_cc_pll1000 50097
> 0 0 5 N
>disp_cc_mdss_dp_pixel_clk_src 0001920
> 0 0 5 N
> disp_cc_mdss_dp_pixel_clk 0001920
> 0 0 5 N
>
> Reviewed-by: Marijn Suijten
>
> > ---
> > drivers/gpu/drm/msm/dsi/dsi_host.c | 14 ++
> > 1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> > b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > index 43a5ec33eee8..35c69dbe5f6f 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> > +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > @@ -561,7 +561,8 @@ void dsi_link_clk_disable_v2(struct msm_dsi_host
> > *msm_host)
> > clk_disable_unprepare(msm_host->byte_clk);
> > }
> >
> > -static unsigned long dsi_get_pclk_rate(const struct drm_display_mode
> > *mode, bool is_bonded_dsi)
> > +static unsigned long dsi_get_pclk_rate(const struct drm_display_mode *mode,
>
> It is a bit unfortunate that this function is called so often with the
> same parameters, doing the same calculation over and over.
>
> > + struct drm_dsc_config *dsc, bool is_bonded_dsi)
> > {
> > unsigned long pclk_rate;
> >
> > @@ -576,6 +577,11 @@ static unsigned long dsi_get_pclk_rate(const struct
> > drm_display_mode *mode, bool
> > if (is_bonded_dsi)
> > pclk_rate /= 2;
> >
> > + /* If DSC is enabled, divide pclk by compression ratio */
> > + if (dsc)
> > + pclk_rate =
Re: [RFC] Plane color pipeline KMS uAPI
On 5/4/23 11:22, Simon Ser wrote:
Hi all,
The goal of this RFC is to expose a generic KMS uAPI to configure the color
pipeline before blending, ie. after a pixel is tapped from a plane's
framebuffer and before it's blended with other planes. With this new uAPI we
aim to reduce the battery life impact of color management and HDR on mobile
devices, to improve performance and to decrease latency by skipping
composition on the 3D engine. This proposal is the result of discussions at
the Red Hat HDR hackfest [1] which took place a few days ago. Engineers
familiar with the AMD, Intel and NVIDIA hardware have participated in the
discussion.
Thanks for typing this up. It does a great job describing the vision.
This proposal takes a prescriptive approach instead of a descriptive approach.
Drivers describe the available hardware blocks in terms of low-level
mathematical operations, then user-space configures each block. We decided
against a descriptive approach where user-space would provide a high-level
description of the colorspace and other parameters: we want to give more
control and flexibility to user-space, e.g. to be able to replicate exactly the
color pipeline with shaders and switch between shaders and KMS pipelines
seamlessly, and to avoid forcing user-space into a particular color management
policy.
We've decided against mirroring the existing CRTC properties
DEGAMMA_LUT/CTM/GAMMA_LUT onto KMS planes. Indeed, the color management
pipeline can significantly differ between vendors and this approach cannot
accurately abstract all hardware. In particular, the availability, ordering and
capabilities of hardware blocks is different on each display engine. So, we've
decided to go for a highly detailed hardware capability discovery.
This new uAPI should not be in conflict with existing standard KMS properties,
since there are none which control the pre-blending color pipeline at the
moment. It does conflict with any vendor-specific properties like
NV_INPUT_COLORSPACE or the patches on the mailing list adding AMD-specific
properties. Drivers will need to either reject atomic commits configuring both
uAPIs, or alternatively we could add a DRM client cap which hides the vendor
properties and shows the new generic properties when enabled.
To use this uAPI, first user-space needs to discover hardware capabilities via
KMS objects and properties, then user-space can configure the hardware via an
atomic commit. This works similarly to the existing KMS uAPI, e.g. planes.
Our proposal introduces a new "color_pipeline" plane property, and a new KMS
object type, "COLOROP" (short for color operation). The "color_pipeline" plane
property is an enum, each enum entry represents a color pipeline supported by
the hardware. The special zero entry indicates that the pipeline is in
"bypass"/"no-op" mode. For instance, the following plane properties describe a
primary plane with 2 supported pipelines but currently configured in bypass
mode:
Plane 10
├─ "type": immutable enum {Overlay, Primary, Cursor} = Primary
├─ …
└─ "color_pipeline": enum {0, 42, 52} = 0
The non-zero entries describe color pipelines as a linked list of COLOROP KMS
objects. The entry value is an object ID pointing to the head of the linked
list (the first operation in the color pipeline).
The new COLOROP objects also expose a number of KMS properties. Each has a
type, a reference to the next COLOROP object in the linked list, and other
type-specific properties. Here is an example for a 1D LUT operation:
Color operation 42
├─ "type": enum {Bypass, 1D curve} = 1D curve
├─ "1d_curve_type": enum {LUT, sRGB, PQ, BT.709, HLG, …} = LUT
├─ "lut_size": immutable range = 4096
├─ "lut_data": blob
└─ "next": immutable color operation ID = 43
To configure this hardware block, user-space can fill a KMS blob with 4096 u32
entries, then set "lut_data" to the blob ID. Other color operation types might
have different properties.
Here is another example with a 3D LUT:
Color operation 42
├─ "type": enum {Bypass, 3D LUT} = 3D LUT
├─ "lut_size": immutable range = 33
├─ "lut_data": blob
└─ "next": immutable color operation ID = 43
And one last example with a matrix:
Color operation 42
├─ "type": enum {Bypass, Matrix} = Matrix
├─ "matrix_data": blob
└─ "next": immutable color operation ID = 43
[Simon note: having "Bypass" in the "type" enum, and making "type" mutable is
a bit weird. Maybe we can just add an "active"/"bypass" boolean property on
blocks which can be bypassed instead.]
I would favor a "bypass" boolean property.
[Jonas note: perhaps a single "data" property for both LUTs and matrices
would make more sense. And a "size" prop for both 1D and 3D LUTs.]
I concur. We'll probably want to document for which types a property
applies.
If some hardware supports re-ordering operations in the color pipeline, the
driver can expose multiple pipelines with
Re: [Intel-gfx] [PATCH 2/2] drm/i915/mtl: Update GuC firmware version for MTL to 70.6.6
On 5/4/2023 13:29, Lucas De Marchi wrote: On Thu, May 04, 2023 at 01:22:52PM -0700, john.c.harri...@intel.com wrote: From: John Harrison Also switch to using reduced version file naming as it is no longer such a work-in-progress and likely to change. Signed-off-by: John Harrison commit message here will be bogus as it will be the first time MTL will actually have the define. Oh. Because the current line is coming from the for-CI branch and is not actually upstream already. Yeah, forgot that! Better to do it like this: git revert 5c71b8b8ac87 then this patch, with a better commit message or I can change the commit message of this commit while applying to: drm/i915/mtl: Define GuC firmware version for MTL First release of GuC for Meteorlake. Signed-off-by: John Harrison Reviewed-by: Lucas De Marchi Lucas De Marchi That works for me :). --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index 55e50bd08d7ff..10e48cbcf494a 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -79,7 +79,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * security fixes, etc. to be enabled. */ #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ - fw_def(METEORLAKE, 0, guc_mmp(mtl, 70, 6, 5)) \ + fw_def(METEORLAKE, 0, guc_maj(mtl, 70, 6, 6)) \ fw_def(DG2, 0, guc_maj(dg2, 70, 5, 1)) \ fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 5, 1)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \ -- 2.39.1
Re: [PATCH 1/4] drm/msm/dsi: Adjust pclk rate for compression
Title suggestion: use the wording "reduce pclk rate" :)
(Eventually "when DSC is enabled", instead of "for compression")
On 2023-05-02 18:19:12, Jessica Zhang wrote:
> Divide the pclk rate by the compression ratio when DSC is enabled
>
> Signed-off-by: Jessica Zhang
Thank you so much for sending this. The compression ratio was applied
to hdisplay, but not the clocks yet, and with this patch I get a massive
reduction in clock speeds on the Xperia XZ3, without regressions nor
affecting performance/fps:
gcc_sys_noc_cpuss_ahb_clk 1101920
0 0 5 Y
gcc_cpuss_ahb_clk 1101920
0 0 5 Y
bi_tcxo 6601920
0 0 5 Y
dsi0vco_clk110
[-1873793994-]{+1249195898+} 0 0 5 Y
dsi0_pll_out_div_clk110
[-1873793994-]{+624597949+} 0 0 5 Y
dsi0_pll_post_out_div_clk 000
[-468448498-]{+156149487+} 0 0 5 Y
dsi0_pll_bit_clk 220
[-1873793994-]{+624597949+} 0 0 5 Y
dsi0_pclk_mux 110
[-1873793994-]{+624597949+} 0 0 5 Y
dsi0_phy_pll_out_dsiclk 110
[-312298999-]{+104099659+} 0 0 5 Y
disp_cc_mdss_pclk0_clk_src 110
[-312298999-]{+104099659+} 0 0 5 Y
disp_cc_mdss_pclk0_clk 110
[-312298999-]{+104099659+} 0 0 5 Y
dsi0_pll_by_2_bit_clk 000
[-936896997-]{+312298974+} 0 0 5 Y
dsi0_phy_pll_out_byteclk 110
[-234224249-]{+78074743+} 0 0 5 Y
disp_cc_mdss_byte0_clk_src 220
[-234224249-]{+78074743+} 0 0 5 Y
disp_cc_mdss_byte0_div_clk_src 110
[-117112125-]{+39037372+} 0 0 5 Y
disp_cc_mdss_byte0_intf_clk 110
[-117112125-]{+39037372+} 0 0 5 Y
disp_cc_mdss_byte0_clk 110
[-234224249-]{+78074743+} 0 0 5 Y
gpu_cc_pll1000 50097
0 0 5 N
disp_cc_mdss_dp_pixel_clk_src 0001920
0 0 5 N
disp_cc_mdss_dp_pixel_clk 0001920
0 0 5 N
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 43a5ec33eee8..35c69dbe5f6f 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -561,7 +561,8 @@ void dsi_link_clk_disable_v2(struct msm_dsi_host
> *msm_host)
> clk_disable_unprepare(msm_host->byte_clk);
> }
>
> -static unsigned long dsi_get_pclk_rate(const struct drm_display_mode *mode,
> bool is_bonded_dsi)
> +static unsigned long dsi_get_pclk_rate(const struct drm_display_mode *mode,
It is a bit unfortunate that this function is called so often with the
same parameters, doing the same calculation over and over.
> + struct drm_dsc_config *dsc, bool is_bonded_dsi)
> {
> unsigned long pclk_rate;
>
> @@ -576,6 +577,11 @@ static unsigned long dsi_get_pclk_rate(const struct
> drm_display_mode *mode, bool
> if (is_bonded_dsi)
> pclk_rate /= 2;
>
> + /* If DSC is enabled, divide pclk by compression ratio */
> + if (dsc)
> + pclk_rate = DIV_ROUND_UP(pclk_rate,
> + dsc->bits_per_component * 3 /
> msm_dsc_get_bpp_int(dsc));
Don't forget to mention that this series depends on the DSC helpers. I
don't think the linked DSC 1.2 series depends on it (at least it doesn't
mention it):
https://lore.kernel.org/linux-arm-msm/20230329-rfc-msm-dsc-helper-v6-2-cb7f59f0f...@quicinc.com/
- Marijn
> +
> return pclk_rate;
> }
>
> @@ -585,7 +591,7 @@ unsigned long dsi_byte_clk_get_rate(struct mipi_dsi_host
> *host, bool is_bonded_d
> struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
> u8 lanes = msm_host->lanes;
> u32 bpp = dsi_get_bpp(msm_host->format);
> - unsigned long pclk_rate = dsi_get_pclk_rate(mode, is_bonded_dsi);
> + unsigned long
Re: [PATCH v5 3/3] drm/i915: make sure correct pte encode is used
On Wed, May 03, 2023 at 03:51:00PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> PTE encode is platform dependent. After replacing cache_level with
> pat_index, the newly introduced mtl_pte_encode is actually generic
> for all gen12 platforms, thus rename it to gen12_pte_encode and
> apply it to all gen12 platforms.
>
> Cc: Chris Wilson
> Cc: Matt Roper
> Signed-off-by: Fei Yang
> Reviewed-by: Andi Shyti
Bspec: 63019
Reviewed-by: Matt Roper
I think it's important to include the bspec reference here since we have
so much trouble finding proper documentation on PTE formats (other pages
like 45030, 45040, etc. never got updated in a sensible way).
Matt
> ---
> drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> index f2334a713c4e..d1e3d3b90e95 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> @@ -55,9 +55,9 @@ static u64 gen8_pte_encode(dma_addr_t addr,
> return pte;
> }
>
> -static u64 mtl_pte_encode(dma_addr_t addr,
> - unsigned int pat_index,
> - u32 flags)
> +static u64 gen12_pte_encode(dma_addr_t addr,
> + unsigned int pat_index,
> + u32 flags)
> {
> gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
>
> @@ -995,8 +995,8 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
>*/
> ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
>
> - if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
> - ppgtt->vm.pte_encode = mtl_pte_encode;
> + if (GRAPHICS_VER(gt->i915) >= 12)
> + ppgtt->vm.pte_encode = gen12_pte_encode;
> else
> ppgtt->vm.pte_encode = gen8_pte_encode;
>
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [Intel-gfx] [PATCH 2/2] drm/i915/mtl: Update GuC firmware version for MTL to 70.6.6
On Thu, May 04, 2023 at 01:22:52PM -0700, john.c.harri...@intel.com wrote: From: John Harrison Also switch to using reduced version file naming as it is no longer such a work-in-progress and likely to change. Signed-off-by: John Harrison commit message here will be bogus as it will be the first time MTL will actually have the define. Better to do it like this: git revert 5c71b8b8ac87 then this patch, with a better commit message or I can change the commit message of this commit while applying to: drm/i915/mtl: Define GuC firmware version for MTL First release of GuC for Meteorlake. Signed-off-by: John Harrison Reviewed-by: Lucas De Marchi Lucas De Marchi --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index 55e50bd08d7ff..10e48cbcf494a 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -79,7 +79,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * security fixes, etc. to be enabled. */ #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ - fw_def(METEORLAKE, 0, guc_mmp(mtl, 70, 6, 5)) \ + fw_def(METEORLAKE, 0, guc_maj(mtl, 70, 6, 6)) \ fw_def(DG2, 0, guc_maj(dg2, 70, 5, 1)) \ fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 5, 1)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \ -- 2.39.1
[PATCH 1/2] drm/i915/uc: Track patch level versions on reduced version firmware files
From: John Harrison
When reduced version firmware files were added (matching major
component being the only strict requirement), the minor version was
still tracked and a notification reported if it was older. However,
the patch version should really be tracked as well for the same
reasons. The KMD can work without the change but if the effort has
been taken to release a new firmware with the change then there must
be a valid reason for doing so - important bug fix, security fix, etc.
And in that case it would be good to alert the user if they are
missing out on that new fix.
v2: Use correct patch version number and drop redunant debug print
(review by Daniele / CI results).
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 30 +++-
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 6b71b9febd74c..55e50bd08d7ff 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -80,14 +80,14 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
*/
#define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \
fw_def(METEORLAKE, 0, guc_mmp(mtl, 70, 6, 5)) \
- fw_def(DG2, 0, guc_maj(dg2, 70, 5)) \
- fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 5)) \
+ fw_def(DG2, 0, guc_maj(dg2, 70, 5, 1)) \
+ fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 5, 1)) \
fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \
fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 69, 0, 3)) \
- fw_def(ALDERLAKE_S, 0, guc_maj(tgl, 70, 5)) \
+ fw_def(ALDERLAKE_S, 0, guc_maj(tgl, 70, 5, 1)) \
fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 70, 1, 1)) \
fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 69, 0, 3)) \
- fw_def(DG1, 0, guc_maj(dg1, 70, 5)) \
+ fw_def(DG1, 0, guc_maj(dg1, 70, 5, 1)) \
fw_def(ROCKETLAKE, 0, guc_mmp(tgl, 70, 1, 1)) \
fw_def(TIGERLAKE,0, guc_mmp(tgl, 70, 1, 1)) \
fw_def(JASPERLAKE, 0, guc_mmp(ehl, 70, 1, 1)) \
@@ -141,7 +141,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
__stringify(patch_) ".bin"
/* Minor for internal driver use, not part of file name */
-#define MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_) \
+#define MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_, patch_) \
__MAKE_UC_FW_PATH_MAJOR(prefix_, "guc", major_)
#define MAKE_GUC_FW_PATH_MMP(prefix_, major_, minor_, patch_) \
@@ -197,9 +197,9 @@ struct __packed uc_fw_blob {
{ UC_FW_BLOB_BASE(major_, minor_, patch_, path_) \
.legacy = true }
-#define GUC_FW_BLOB(prefix_, major_, minor_) \
- UC_FW_BLOB_NEW(major_, minor_, 0, false, \
- MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_))
+#define GUC_FW_BLOB(prefix_, major_, minor_, patch_) \
+ UC_FW_BLOB_NEW(major_, minor_, patch_, false, \
+ MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_, patch_))
#define GUC_FW_BLOB_MMP(prefix_, major_, minor_, patch_) \
UC_FW_BLOB_OLD(major_, minor_, patch_, \
@@ -296,6 +296,7 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct
intel_uc_fw *uc_fw)
uc_fw->file_wanted.path = blob->path;
uc_fw->file_wanted.ver.major = blob->major;
uc_fw->file_wanted.ver.minor = blob->minor;
+ uc_fw->file_wanted.ver.patch = blob->patch;
uc_fw->loaded_via_gsc = blob->loaded_via_gsc;
found = true;
break;
@@ -794,6 +795,9 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
} else {
if (uc_fw->file_selected.ver.minor <
uc_fw->file_wanted.ver.minor)
old_ver = true;
+ else if ((uc_fw->file_selected.ver.minor ==
uc_fw->file_wanted.ver.minor) &&
+(uc_fw->file_selected.ver.patch <
uc_fw->file_wanted.ver.patch))
+ old_ver = true;
}
}
@@ -801,12 +805,16 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
/* Preserve the version that was really wanted */
memcpy(_fw->file_wanted, _ideal,
sizeof(uc_fw->file_wanted));
- gt_notice(gt, "%s firmware %s (%d.%d) is recommended, but only
%s (%d.%d) was found\n",
+ gt_notice(gt, "%s firmware %s (%d.%d.%d) is recommended, but
only %s (%d.%d.%d) was found\n",
intel_uc_fw_type_repr(uc_fw->type),
uc_fw->file_wanted.path,
- uc_fw->file_wanted.ver.major,
uc_fw->file_wanted.ver.minor,
+ uc_fw->file_wanted.ver.major,
+ uc_fw->file_wanted.ver.minor,
+ uc_fw->file_wanted.ver.patch,
[PATCH 0/2] Update MTL GuC firmware
From: John Harrison Update MTL to the latest GuC release and switch to using reduced version file names. Also, pull in a patch from an earlier series that is waiting to merge to prevent merge conflicts later. Signed-off-by: John Harrison John Harrison (2): drm/i915/uc: Track patch level versions on reduced version firmware files drm/i915/mtl: Update GuC firmware version for MTL to 70.6.6 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 32 +++- 1 file changed, 20 insertions(+), 12 deletions(-) -- 2.39.1
[PATCH 2/2] drm/i915/mtl: Update GuC firmware version for MTL to 70.6.6
From: John Harrison Also switch to using reduced version file naming as it is no longer such a work-in-progress and likely to change. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index 55e50bd08d7ff..10e48cbcf494a 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -79,7 +79,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * security fixes, etc. to be enabled. */ #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ - fw_def(METEORLAKE, 0, guc_mmp(mtl, 70, 6, 5)) \ + fw_def(METEORLAKE, 0, guc_maj(mtl, 70, 6, 6)) \ fw_def(DG2, 0, guc_maj(dg2, 70, 5, 1)) \ fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 5, 1)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \ -- 2.39.1
Re: [PATCH v5 2/3] drm/i915: use pat_index instead of cache_level
On Wed, May 03, 2023 at 03:50:59PM -0700, fei.y...@intel.com wrote: > From: Fei Yang > > Currently the KMD is using enum i915_cache_level to set caching policy for > buffer objects. This is flaky because the PAT index which really controls > the caching behavior in PTE has far more levels than what's defined in the > enum. In addition, the PAT index is platform dependent, having to translate > between i915_cache_level and PAT index is not reliable, and makes the code > more complicated. > > From UMD's perspective there is also a necessity to set caching policy for > performance fine tuning. It's much easier for the UMD to directly use PAT > index because the behavior of each PAT index is clearly defined in Bspec. > Having the abstracted i915_cache_level sitting in between would only cause > more ambiguity. It may be worth mentioning here that PAT is expected to work much like MOCS already works today --- the contract on the exact platform-specific meaning of each index is documented in the hardware spec and userspace is expected to select the index that exactly matches the behavior it desires. > > For these reasons this patch replaces i915_cache_level with PAT index. Also > note, the cache_level is not completely removed yet, because the KMD still > has the need of creating buffer objects with simple cache settings such as > cached, uncached, or writethrough. For such simple cases, using cache_level > would help simplify the code. See my comment farther down, but the implementation of i915_gem_object_has_cache_level() seems a bit confusing and you may want to elaborate on it here. Also somewhat confusing from a high-level skim is if/how we're still using obj->cache_coherent once userspace has taken direct control of the cache behavior. Some PAT indices give coherency and others don't (and the combinations will likely get more complicated on future platforms). If obj->cache_coherent is still being considered even once PAT indices are being controlled by userspace, I think we need some explanation of how that works in the commit message (and likely in the kerneldoc for that field too). > > Cc: Chris Wilson > Cc: Matt Roper > Signed-off-by: Fei Yang > Reviewed-by: Andi Shyti > --- > drivers/gpu/drm/i915/display/intel_dpt.c | 12 +-- > drivers/gpu/drm/i915/gem/i915_gem_domain.c| 45 ++ > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 ++- > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 3 +- > drivers/gpu/drm/i915/gem/i915_gem_object.c| 51 +++- > drivers/gpu/drm/i915/gem/i915_gem_object.h| 4 + > .../gpu/drm/i915/gem/i915_gem_object_types.h | 25 +- > drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 4 +- > drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 16 ++-- > .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- > .../drm/i915/gem/selftests/i915_gem_migrate.c | 2 +- > .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +- > drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 10 ++- > drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 71 > drivers/gpu/drm/i915/gt/gen8_ppgtt.h | 3 +- > drivers/gpu/drm/i915/gt/intel_ggtt.c | 82 +-- > drivers/gpu/drm/i915/gt/intel_gtt.h | 20 ++--- > drivers/gpu/drm/i915/gt/intel_migrate.c | 47 ++- > drivers/gpu/drm/i915/gt/intel_migrate.h | 13 ++- > drivers/gpu/drm/i915/gt/intel_ppgtt.c | 6 +- > drivers/gpu/drm/i915/gt/selftest_migrate.c| 47 ++- > drivers/gpu/drm/i915/gt/selftest_reset.c | 8 +- > drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 +- > drivers/gpu/drm/i915/gt/selftest_tlb.c| 4 +- > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 10 ++- > drivers/gpu/drm/i915/i915_debugfs.c | 52 +--- > drivers/gpu/drm/i915/i915_gem.c | 16 +++- > drivers/gpu/drm/i915/i915_gpu_error.c | 8 +- > drivers/gpu/drm/i915/i915_vma.c | 16 ++-- > drivers/gpu/drm/i915/i915_vma.h | 2 +- > drivers/gpu/drm/i915/i915_vma_types.h | 2 - > drivers/gpu/drm/i915/selftests/i915_gem.c | 5 +- > .../gpu/drm/i915/selftests/i915_gem_evict.c | 4 +- > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 15 ++-- > .../drm/i915/selftests/intel_memory_region.c | 4 +- > drivers/gpu/drm/i915/selftests/mock_gtt.c | 8 +- > 36 files changed, 391 insertions(+), 240 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c > b/drivers/gpu/drm/i915/display/intel_dpt.c > index c5eacfdba1a5..7c5fddb203ba 100644 > --- a/drivers/gpu/drm/i915/display/intel_dpt.c > +++ b/drivers/gpu/drm/i915/display/intel_dpt.c > @@ -43,24 +43,24 @@ static void gen8_set_pte(void __iomem *addr, gen8_pte_t > pte) > static void dpt_insert_page(struct i915_address_space *vm, > dma_addr_t addr, > u64 offset, > - enum i915_cache_level level, > +
Re: [PATCH v5 3/7] drm/msm/dpu: add DPU_PINGPONG_DSC bits into PP_BLK and PP_BLK_TE marcos
On 5/4/2023 12:59 PM, Dmitry Baryshkov wrote: On 04/05/2023 22:50, Abhinav Kumar wrote: On 5/4/2023 12:36 PM, Marijn Suijten wrote: On 2023-05-04 11:25:44, Abhinav Kumar wrote: Sure, if you really prefer a split I'd go for two patches: 1. Add the flag to the enum and catalog; 2. Add the ops guard (functional change). Then don't forget to reword the commit message, following the guidelines below and the suggestion for 2/7. - Marijn Plan sounds good to me. Marijn, we will wait for a couple of days to post the next rev but would be hard more than that as we need to pick up other things which are pending on top of this. Hence would appreciate if you can finish reviews by then. It depends on how many more revisions are needed after that, and not all patches in this series have an r-b just yet. Given the amount of review comments that are still trickling in (also on patches that already have maintainer r-b) I don't think we're quite there to start thinging about picking this up in drm-msm just yet. I doubt anyone wants a repeat of the original DSC series, which went through many review rounds yet still required multiple series of bugfixes (some of which were pointed out and ignored in review) to be brought to a working state. But the split across topics per series already makes this a lot less likely, many thanks for that. I think the outstanding comments shouldnt last more than 1-2 revs more on this one as its mostly due to multiple patches on the list touching catalog at the same time. I have been monitoring the comments closely even though I dont respond to all of them. One of the major reasons of the number of issues with DSC 1.1 was QC didn't really have the devices or panels to support it. Thats why I changed that this time around to take more control of validation of DSC 1.2 and ofcourse decided to break up of series into the least amount of functionality needed to keep the DPU driver intact. All that being said, we still value your comments and would gladly wait for a couple of days like I already wrote. But there are more incremental series on top of this: -> DSI changes for DSC 1.2 -> proper teardown for DSC -> DSC pair allocation support -> DSC 1.2 over DP We will be posting all of these within next couple of weeks on top of this. I'd say, it's fine to post them now, as we have more or less agreed on the helper series. The interface between the series should be stable then. The RM series is probably the one having bigger dependencies/conflicts on other pending patches (include virtual wide planes) 1 is already posted, will keep fixing review comments 2 will be posted pretty soon DSC1.2 over DSI will be complete with this set. I will finish up virtual planes review by early next week. Already underway ... 3 & 4 will be posted soon after that. In other words, let's take it slow and do things properly this time. And who knows, perhaps the rest of these patches are more straightforward. Ack. the intent is always to do things right the first time. - Marijn
Re: [PATCH v5 3/7] drm/msm/dpu: add DPU_PINGPONG_DSC bits into PP_BLK and PP_BLK_TE marcos
On 04/05/2023 22:50, Abhinav Kumar wrote: On 5/4/2023 12:36 PM, Marijn Suijten wrote: On 2023-05-04 11:25:44, Abhinav Kumar wrote: Sure, if you really prefer a split I'd go for two patches: 1. Add the flag to the enum and catalog; 2. Add the ops guard (functional change). Then don't forget to reword the commit message, following the guidelines below and the suggestion for 2/7. - Marijn Plan sounds good to me. Marijn, we will wait for a couple of days to post the next rev but would be hard more than that as we need to pick up other things which are pending on top of this. Hence would appreciate if you can finish reviews by then. It depends on how many more revisions are needed after that, and not all patches in this series have an r-b just yet. Given the amount of review comments that are still trickling in (also on patches that already have maintainer r-b) I don't think we're quite there to start thinging about picking this up in drm-msm just yet. I doubt anyone wants a repeat of the original DSC series, which went through many review rounds yet still required multiple series of bugfixes (some of which were pointed out and ignored in review) to be brought to a working state. But the split across topics per series already makes this a lot less likely, many thanks for that. I think the outstanding comments shouldnt last more than 1-2 revs more on this one as its mostly due to multiple patches on the list touching catalog at the same time. I have been monitoring the comments closely even though I dont respond to all of them. One of the major reasons of the number of issues with DSC 1.1 was QC didn't really have the devices or panels to support it. Thats why I changed that this time around to take more control of validation of DSC 1.2 and ofcourse decided to break up of series into the least amount of functionality needed to keep the DPU driver intact. All that being said, we still value your comments and would gladly wait for a couple of days like I already wrote. But there are more incremental series on top of this: -> DSI changes for DSC 1.2 -> proper teardown for DSC -> DSC pair allocation support -> DSC 1.2 over DP We will be posting all of these within next couple of weeks on top of this. I'd say, it's fine to post them now, as we have more or less agreed on the helper series. The interface between the series should be stable then. The RM series is probably the one having bigger dependencies/conflicts on other pending patches (include virtual wide planes) In other words, let's take it slow and do things properly this time. And who knows, perhaps the rest of these patches are more straightforward. Ack. the intent is always to do things right the first time. - Marijn -- With best wishes Dmitry
Re: [PATCH v5 3/7] drm/msm/dpu: add DPU_PINGPONG_DSC bits into PP_BLK and PP_BLK_TE marcos
On 5/4/2023 12:36 PM, Marijn Suijten wrote: On 2023-05-04 11:25:44, Abhinav Kumar wrote: Sure, if you really prefer a split I'd go for two patches: 1. Add the flag to the enum and catalog; 2. Add the ops guard (functional change). Then don't forget to reword the commit message, following the guidelines below and the suggestion for 2/7. - Marijn Plan sounds good to me. Marijn, we will wait for a couple of days to post the next rev but would be hard more than that as we need to pick up other things which are pending on top of this. Hence would appreciate if you can finish reviews by then. It depends on how many more revisions are needed after that, and not all patches in this series have an r-b just yet. Given the amount of review comments that are still trickling in (also on patches that already have maintainer r-b) I don't think we're quite there to start thinging about picking this up in drm-msm just yet. I doubt anyone wants a repeat of the original DSC series, which went through many review rounds yet still required multiple series of bugfixes (some of which were pointed out and ignored in review) to be brought to a working state. But the split across topics per series already makes this a lot less likely, many thanks for that. I think the outstanding comments shouldnt last more than 1-2 revs more on this one as its mostly due to multiple patches on the list touching catalog at the same time. I have been monitoring the comments closely even though I dont respond to all of them. One of the major reasons of the number of issues with DSC 1.1 was QC didn't really have the devices or panels to support it. Thats why I changed that this time around to take more control of validation of DSC 1.2 and ofcourse decided to break up of series into the least amount of functionality needed to keep the DPU driver intact. All that being said, we still value your comments and would gladly wait for a couple of days like I already wrote. But there are more incremental series on top of this: -> DSI changes for DSC 1.2 -> proper teardown for DSC -> DSC pair allocation support -> DSC 1.2 over DP We will be posting all of these within next couple of weeks on top of this. In other words, let's take it slow and do things properly this time. And who knows, perhaps the rest of these patches are more straightforward. Ack. the intent is always to do things right the first time. - Marijn
Re: [PATCH v5 3/7] drm/msm/dpu: add DPU_PINGPONG_DSC bits into PP_BLK and PP_BLK_TE marcos
On 2023-05-04 11:25:44, Abhinav Kumar wrote: > > Sure, if you really prefer a split I'd go for two patches: > > 1. Add the flag to the enum and catalog; > > 2. Add the ops guard (functional change). > > > > Then don't forget to reword the commit message, following the guidelines > > below and the suggestion for 2/7. > > > > - Marijn > > Plan sounds good to me. > > Marijn, we will wait for a couple of days to post the next rev but would > be hard more than that as we need to pick up other things which are > pending on top of this. Hence would appreciate if you can finish reviews > by then. It depends on how many more revisions are needed after that, and not all patches in this series have an r-b just yet. Given the amount of review comments that are still trickling in (also on patches that already have maintainer r-b) I don't think we're quite there to start thinging about picking this up in drm-msm just yet. I doubt anyone wants a repeat of the original DSC series, which went through many review rounds yet still required multiple series of bugfixes (some of which were pointed out and ignored in review) to be brought to a working state. But the split across topics per series already makes this a lot less likely, many thanks for that. In other words, let's take it slow and do things properly this time. And who knows, perhaps the rest of these patches are more straightforward. - Marijn
Re: [PATCH v1] drm/mipi-dsi: Set the fwnode for mipi_dsi_device
On Thu, May 4, 2023 at 12:51 AM Maxime Ripard wrote:
>
> Hi Saravana,
>
> On Wed, May 03, 2023 at 09:40:05PM -0700, Saravana Kannan wrote:
> > On Fri, Mar 17, 2023 at 3:36 PM Saravana Kannan
> > wrote:
> > >
> > > On Sun, Mar 12, 2023 at 7:45 AM Martin Kepplinger
> > > wrote:
> > > >
> > > > Am Donnerstag, dem 09.03.2023 um 22:39 -0800 schrieb Saravana Kannan:
> > > > > After commit 3fb16866b51d ("driver core: fw_devlink: Make cycle
> > > > > detection more robust"), fw_devlink prints an error when consumer
> > > > > devices don't have their fwnode set. This used to be ignored
> > > > > silently.
> > > > >
> > > > > Set the fwnode mipi_dsi_device so fw_devlink can find them and
> > > > > properly
> > > > > track their dependencies.
> > > > >
> > > > > This fixes errors like this:
> > > > > [0.334054] nwl-dsi 30a0.mipi-dsi: Failed to create device
> > > > > link with regulator-lcd-1v8
> > > > > [0.346964] nwl-dsi 30a0.mipi-dsi: Failed to create device
> > > > > link with backlight-dsi
> > > > >
> > > > > Reported-by: Martin Kepplinger
> > > >
> > > > Reported-and-tested-by: Martin Kepplinger
> > >
> > > Maintainers,
> > >
> > > Nudge nudge. Will this be picked up for 6.3-rcX?
> >
> > Greg,
> >
> > Can you pick this up please? It's a fix that hasn't been picked up for
> > a few months.
> >
> > Here's the link to the actual patch for your convenience:
> > https://lore.kernel.org/lkml/20230310063910.2474472-1-sarava...@google.com/#t
>
> Sorry, I'm not quite sure what happened. I've applied it to drm-misc-fixes
No worries. Thanks Maxime!
-Saravana
Re: [PATCH v2 4/4] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
On Tue, Mar 7, 2023 at 7:07 AM Richard Leitner wrote: > > Hi Lucas, > > hope I got the latest version of this series. If not, please feel free > to point me to the correct one. > > On Fri, Dec 16, 2022 at 10:07:42PM +0100, Lucas Stach wrote: > > This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a > > full timing generator and can switch between different video sources. On > > the i.MX8MP however the only supported source is the LCDIF. The block > > just needs to be powered up and told about the polarity of the video > > sync signals to act in bypass mode. > > > > Signed-off-by: Lucas Stach > > Tested-by: Marek Vasut > > I've successfully tested this patch on our custom i.MX8MP board. The > test case was basically "cat /dev/urandom > /dev/fb1" with a 800x480 > HDMI display. > > Therefore please feel free to add: > > Tested-by: Richard Leitner > Lucas, Is there going to be a subsequent rev of this series? It seems to be stuck somewhere without any movement. thanks adam > > --- > > drivers/gpu/drm/bridge/imx/Kconfig | 7 + > > drivers/gpu/drm/bridge/imx/Makefile | 1 + > > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 202 +++ > > 3 files changed, 210 insertions(+) > > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c > >
Re: [PATCH v5 3/7] drm/msm/dpu: add DPU_PINGPONG_DSC bits into PP_BLK and PP_BLK_TE marcos
On 5/4/2023 11:23 AM, Marijn Suijten wrote:
On 2023-05-04 20:53:33, Dmitry Baryshkov wrote:
On Thu, 4 May 2023 at 20:49, Marijn Suijten
wrote:
PP_BLK_TE is no longer there.
marcos -> macros.
On 2023-05-04 09:46:41, Kuogee Hsieh wrote:
At legacy chipsets, it required DPU_PINGPONG_DSC bit be set to indicate
I may have not made this clear, but the comments on patch 2/7
(introducing the DPU_PINGPONG_DSC bit) also apply to this patch: clarify
DPU 7.0.0 exactly in favour of "legacy", which has no definition at all
and changes over time.
pingpong ops functions are required to complete DSC data path setup if
this chipset has DSC hardware block presented. This patch add
DPU_PINGPONG_DSC bit to both PP_BLK and PP_BLK_TE marcos if it has DSC
hardware block presented.
Strictly speaking this patch together with 2/7 is not bisectable, as 2/7
first disables the callbacks for _all_ hardware and then this patch adds
it back by adding the flag to all DPU < 7.0.0 catalog descriptions.
I asked to split these into two patches, but I see your point and
partially agree with it. However if we mix the catalog changes with
functional changes, it is too easy to overlook or misjudge the
functional changes.
I did the same in the INTF TE series for patches that have very little
and/or very obvious functional changes: exactly this combination of
guarding a few callbacks behind a feature bit, and setting that feature
bit on a few specific catalog entries.
As you are correct about bisectability, I'd probably suggest either
having three patches (define flag, update catalog, handle flag in the
driver) or squashing first two patches to have two patches (add flag +
catalog, separate functional changes).
Sure, if you really prefer a split I'd go for two patches:
1. Add the flag to the enum and catalog;
2. Add the ops guard (functional change).
Then don't forget to reword the commit message, following the guidelines
below and the suggestion for 2/7.
- Marijn
Plan sounds good to me.
Marijn, we will wait for a couple of days to post the next rev but would
be hard more than that as we need to pick up other things which are
pending on top of this. Hence would appreciate if you can finish reviews
by then.
To solve that, as we do in other DPU patch-series, just squash this
patch into 2/7. That way you also don't have to spend extra time
rewording this commit message either to match the improvements we made
in 2/7 (for example, you mention that "ops functions are required to
complete DSC data path setup", but those were already available before
2/7, despite sounding as if this is a new thing that was previously
missing entirely).
But please wait at least a couple days before sending v6. I only have a
few hours every day/week but would appreciate to review and test all the
other patches.
Signed-off-by: Kuogee Hsieh
---
.../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h| 16 +++
.../gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 16 +++
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 24 +++---
.../drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h| 24 +++---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 24 +++---
5 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index 521cfd5..ef92545 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -112,17 +112,17 @@ static const struct dpu_lm_cfg msm8998_lm[] = {
};
static const struct dpu_pingpong_cfg msm8998_pp[] = {
- PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SDM845_TE2_MASK, 0,
sdm845_pp_sblk_te,
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
+ PP_BLK("pingpong_0", PINGPONG_0, 0x7,
PINGPONG_SDM845_TE2_MASK|BIT(DPU_PINGPONG_DSC),
This should be added to the MASK (add new #define's where necessary).
- Marijn
Re: [PATCH 1/2] iommu/arm-smmu-qcom: Fix missing adreno_smmu's
On 04/05/2023 21:08, Rob Clark wrote:
On Thu, May 4, 2023 at 10:41 AM Konrad Dybcio wrote:
On 2.05.2023 18:09, Rob Clark wrote:
From: Rob Clark
When the special handling of qcom,adreno-smmu was moved into
qcom_smmu_create(), it was overlooked that we didn't have all the
required entries in qcom_smmu_impl_of_match. So we stopped getting
adreno_smmu_priv on sc7180, breaking per-process pgtables.
Fixes: 30b912a03d91 ("iommu/arm-smmu-qcom: Move the qcom,adreno-smmu check into
qcom_smmu_create")
Signed-off-by: Rob Clark
---
I believe the issue here is the lack of qcom,sc7180-smmu-v2 instead.
qcom,adreno-smmu does not have to imply the "qcom smmu v2" impl
Yes, but the ordering after "qcom,smmu-500" does. Currently we just
need the one missing "qcom,sc7180-smmu-v2" but that seemed kind of
fragile to me, which is why I went with "qcom,adreno-smmu" as a
catch-all
I think, the order is not relevant when comparing compatible entries,
see __of_match_node(). It uses scoring and the more specific compatible
wins. This way, "qcom,adreno-smmu", "qcom,smmu-500" will always end up
with the v2 ops instead smmu500. It was not included into the list
intentionally, rather than being by omission.
Thus I'd also suggest adding "qcom,sc7180-smmu-v2" to the list, as we
currently do for all SMMU_v2 devices.
BR,
-R
Konrad
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index d1b296b95c86..88c89424485b 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -512,20 +512,25 @@ static const struct of_device_id __maybe_unused
qcom_smmu_impl_of_match[] = {
{ .compatible = "qcom,sm6115-smmu-500", .data =
_smmu_500_impl0_data},
{ .compatible = "qcom,sm6125-smmu-500", .data =
_smmu_500_impl0_data },
{ .compatible = "qcom,sm6350-smmu-v2", .data = _smmu_v2_data },
{ .compatible = "qcom,sm6350-smmu-500", .data =
_smmu_500_impl0_data },
{ .compatible = "qcom,sm6375-smmu-500", .data =
_smmu_500_impl0_data },
{ .compatible = "qcom,sm8150-smmu-500", .data =
_smmu_500_impl0_data },
{ .compatible = "qcom,sm8250-smmu-500", .data =
_smmu_500_impl0_data },
{ .compatible = "qcom,sm8350-smmu-500", .data =
_smmu_500_impl0_data },
{ .compatible = "qcom,sm8450-smmu-500", .data =
_smmu_500_impl0_data },
{ .compatible = "qcom,smmu-500", .data = _smmu_500_impl0_data },
+ /*
+ * Should come after the qcom,smmu-500 fallback so smmu-500 variants of
+ * adreno-smmu get qcom_adreno_smmu_500_impl:
+ */
+ { .compatible = "qcom,adreno-smmu", .data = _smmu_v2_data },
{ }
};
#ifdef CONFIG_ACPI
static struct acpi_platform_list qcom_acpi_platlist[] = {
{ "LENOVO", "CB-01 ", 0x8180, ACPI_SIG_IORT, equal, "QCOM SMMU" },
{ "QCOM ", "QCOMEDK2", 0x8180, ACPI_SIG_IORT, equal, "QCOM SMMU" },
{ }
};
#endif
--
With best wishes
Dmitry
Re: [PATCH v5 3/7] drm/msm/dpu: add DPU_PINGPONG_DSC bits into PP_BLK and PP_BLK_TE marcos
On 2023-05-04 20:53:33, Dmitry Baryshkov wrote:
> On Thu, 4 May 2023 at 20:49, Marijn Suijten
> wrote:
> >
> > PP_BLK_TE is no longer there.
> >
> > marcos -> macros.
> >
> > On 2023-05-04 09:46:41, Kuogee Hsieh wrote:
> > > At legacy chipsets, it required DPU_PINGPONG_DSC bit be set to indicate
> >
> > I may have not made this clear, but the comments on patch 2/7
> > (introducing the DPU_PINGPONG_DSC bit) also apply to this patch: clarify
> > DPU 7.0.0 exactly in favour of "legacy", which has no definition at all
> > and changes over time.
> >
> > > pingpong ops functions are required to complete DSC data path setup if
> > > this chipset has DSC hardware block presented. This patch add
> > > DPU_PINGPONG_DSC bit to both PP_BLK and PP_BLK_TE marcos if it has DSC
> > > hardware block presented.
> >
> > Strictly speaking this patch together with 2/7 is not bisectable, as 2/7
> > first disables the callbacks for _all_ hardware and then this patch adds
> > it back by adding the flag to all DPU < 7.0.0 catalog descriptions.
>
> I asked to split these into two patches, but I see your point and
> partially agree with it. However if we mix the catalog changes with
> functional changes, it is too easy to overlook or misjudge the
> functional changes.
I did the same in the INTF TE series for patches that have very little
and/or very obvious functional changes: exactly this combination of
guarding a few callbacks behind a feature bit, and setting that feature
bit on a few specific catalog entries.
> As you are correct about bisectability, I'd probably suggest either
> having three patches (define flag, update catalog, handle flag in the
> driver) or squashing first two patches to have two patches (add flag +
> catalog, separate functional changes).
Sure, if you really prefer a split I'd go for two patches:
1. Add the flag to the enum and catalog;
2. Add the ops guard (functional change).
Then don't forget to reword the commit message, following the guidelines
below and the suggestion for 2/7.
- Marijn
> > To solve that, as we do in other DPU patch-series, just squash this
> > patch into 2/7. That way you also don't have to spend extra time
> > rewording this commit message either to match the improvements we made
> > in 2/7 (for example, you mention that "ops functions are required to
> > complete DSC data path setup", but those were already available before
> > 2/7, despite sounding as if this is a new thing that was previously
> > missing entirely).
> >
> > But please wait at least a couple days before sending v6. I only have a
> > few hours every day/week but would appreciate to review and test all the
> > other patches.
> >
> > > Signed-off-by: Kuogee Hsieh
> > > ---
> > > .../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h| 16 +++
> > > .../gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 16 +++
> > > .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 24
> > > +++---
> > > .../drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h| 24
> > > +++---
> > > .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 24
> > > +++---
> > > 5 files changed, 52 insertions(+), 52 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> > > b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> > > index 521cfd5..ef92545 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> > > @@ -112,17 +112,17 @@ static const struct dpu_lm_cfg msm8998_lm[] = {
> > > };
> > >
> > > static const struct dpu_pingpong_cfg msm8998_pp[] = {
> > > - PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SDM845_TE2_MASK,
> > > 0, sdm845_pp_sblk_te,
> > > - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
> > > + PP_BLK("pingpong_0", PINGPONG_0, 0x7,
> > > PINGPONG_SDM845_TE2_MASK|BIT(DPU_PINGPONG_DSC),
> >
> > This should be added to the MASK (add new #define's where necessary).
> >
> > - Marijn
Re: [PATCH 1/2] iommu/arm-smmu-qcom: Fix missing adreno_smmu's
On Thu, May 4, 2023 at 10:41 AM Konrad Dybcio wrote:
>
>
>
> On 2.05.2023 18:09, Rob Clark wrote:
> > From: Rob Clark
> >
> > When the special handling of qcom,adreno-smmu was moved into
> > qcom_smmu_create(), it was overlooked that we didn't have all the
> > required entries in qcom_smmu_impl_of_match. So we stopped getting
> > adreno_smmu_priv on sc7180, breaking per-process pgtables.
> >
> > Fixes: 30b912a03d91 ("iommu/arm-smmu-qcom: Move the qcom,adreno-smmu check
> > into qcom_smmu_create")
> > Signed-off-by: Rob Clark
> > ---
> I believe the issue here is the lack of qcom,sc7180-smmu-v2 instead.
>
> qcom,adreno-smmu does not have to imply the "qcom smmu v2" impl
Yes, but the ordering after "qcom,smmu-500" does. Currently we just
need the one missing "qcom,sc7180-smmu-v2" but that seemed kind of
fragile to me, which is why I went with "qcom,adreno-smmu" as a
catch-all
BR,
-R
>
> Konrad
> > drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> > b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> > index d1b296b95c86..88c89424485b 100644
> > --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> > @@ -512,20 +512,25 @@ static const struct of_device_id __maybe_unused
> > qcom_smmu_impl_of_match[] = {
> > { .compatible = "qcom,sm6115-smmu-500", .data =
> > _smmu_500_impl0_data},
> > { .compatible = "qcom,sm6125-smmu-500", .data =
> > _smmu_500_impl0_data },
> > { .compatible = "qcom,sm6350-smmu-v2", .data = _smmu_v2_data },
> > { .compatible = "qcom,sm6350-smmu-500", .data =
> > _smmu_500_impl0_data },
> > { .compatible = "qcom,sm6375-smmu-500", .data =
> > _smmu_500_impl0_data },
> > { .compatible = "qcom,sm8150-smmu-500", .data =
> > _smmu_500_impl0_data },
> > { .compatible = "qcom,sm8250-smmu-500", .data =
> > _smmu_500_impl0_data },
> > { .compatible = "qcom,sm8350-smmu-500", .data =
> > _smmu_500_impl0_data },
> > { .compatible = "qcom,sm8450-smmu-500", .data =
> > _smmu_500_impl0_data },
> > { .compatible = "qcom,smmu-500", .data = _smmu_500_impl0_data },
> > + /*
> > + * Should come after the qcom,smmu-500 fallback so smmu-500 variants
> > of
> > + * adreno-smmu get qcom_adreno_smmu_500_impl:
> > + */
> > + { .compatible = "qcom,adreno-smmu", .data = _smmu_v2_data },
> > { }
> > };
> >
> > #ifdef CONFIG_ACPI
> > static struct acpi_platform_list qcom_acpi_platlist[] = {
> > { "LENOVO", "CB-01 ", 0x8180, ACPI_SIG_IORT, equal, "QCOM SMMU" },
> > { "QCOM ", "QCOMEDK2", 0x8180, ACPI_SIG_IORT, equal, "QCOM SMMU" },
> > { }
> > };
> > #endif
Re: [PATCH v5 3/7] drm/msm/dpu: add DPU_PINGPONG_DSC bits into PP_BLK and PP_BLK_TE marcos
On Thu, 4 May 2023 at 20:49, Marijn Suijten
wrote:
>
> PP_BLK_TE is no longer there.
>
> marcos -> macros.
>
> On 2023-05-04 09:46:41, Kuogee Hsieh wrote:
> > At legacy chipsets, it required DPU_PINGPONG_DSC bit be set to indicate
>
> I may have not made this clear, but the comments on patch 2/7
> (introducing the DPU_PINGPONG_DSC bit) also apply to this patch: clarify
> DPU 7.0.0 exactly in favour of "legacy", which has no definition at all
> and changes over time.
>
> > pingpong ops functions are required to complete DSC data path setup if
> > this chipset has DSC hardware block presented. This patch add
> > DPU_PINGPONG_DSC bit to both PP_BLK and PP_BLK_TE marcos if it has DSC
> > hardware block presented.
>
> Strictly speaking this patch together with 2/7 is not bisectable, as 2/7
> first disables the callbacks for _all_ hardware and then this patch adds
> it back by adding the flag to all DPU < 7.0.0 catalog descriptions.
I asked to split these into two patches, but I see your point and
partially agree with it. However if we mix the catalog changes with
functional changes, it is too easy to overlook or misjudge the
functional changes.
As you are correct about bisectability, I'd probably suggest either
having three patches (define flag, update catalog, handle flag in the
driver) or squashing first two patches to have two patches (add flag +
catalog, separate functional changes).
>
> To solve that, as we do in other DPU patch-series, just squash this
> patch into 2/7. That way you also don't have to spend extra time
> rewording this commit message either to match the improvements we made
> in 2/7 (for example, you mention that "ops functions are required to
> complete DSC data path setup", but those were already available before
> 2/7, despite sounding as if this is a new thing that was previously
> missing entirely).
>
> But please wait at least a couple days before sending v6. I only have a
> few hours every day/week but would appreciate to review and test all the
> other patches.
>
> > Signed-off-by: Kuogee Hsieh
> > ---
> > .../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h| 16 +++
> > .../gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 16 +++
> > .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 24
> > +++---
> > .../drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h| 24
> > +++---
> > .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 24
> > +++---
> > 5 files changed, 52 insertions(+), 52 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> > b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> > index 521cfd5..ef92545 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> > @@ -112,17 +112,17 @@ static const struct dpu_lm_cfg msm8998_lm[] = {
> > };
> >
> > static const struct dpu_pingpong_cfg msm8998_pp[] = {
> > - PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SDM845_TE2_MASK,
> > 0, sdm845_pp_sblk_te,
> > - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
> > + PP_BLK("pingpong_0", PINGPONG_0, 0x7,
> > PINGPONG_SDM845_TE2_MASK|BIT(DPU_PINGPONG_DSC),
>
> This should be added to the MASK (add new #define's where necessary).
>
> - Marijn
>
> > + 0, sdm845_pp_sblk_te, DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR,
> > 8),
> > DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),
> > - PP_BLK("pingpong_1", PINGPONG_1, 0x70800, PINGPONG_SDM845_TE2_MASK,
> > 0, sdm845_pp_sblk_te,
> > - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
> > + PP_BLK("pingpong_1", PINGPONG_1, 0x70800,
> > PINGPONG_SDM845_TE2_MASK|BIT(DPU_PINGPONG_DSC),
> > + 0, sdm845_pp_sblk_te,
> > DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
> > DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 13)),
> > - PP_BLK("pingpong_2", PINGPONG_2, 0x71000, PINGPONG_SDM845_MASK, 0,
> > sdm845_pp_sblk,
> > - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
> > + PP_BLK("pingpong_2", PINGPONG_2, 0x71000,
> > PINGPONG_SDM845_MASK|BIT(DPU_PINGPONG_DSC),
> > + 0, sdm845_pp_sblk, DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR,
> > 10),
> > DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 14)),
> > - PP_BLK("pingpong_3", PINGPONG_3, 0x71800, PINGPONG_SDM845_MASK, 0,
> > sdm845_pp_sblk,
> > - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
> > + PP_BLK("pingpong_3", PINGPONG_3, 0x71800,
> > PINGPONG_SDM845_MASK|BIT(DPU_PINGPONG_DSC),
> > + 0, sdm845_pp_sblk, DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR,
> > 11),
> > DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
> > };
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> > b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> > index b109757..697fbd8 100644
> > ---
Re: [PATCH] arm64: dts: qcom: enable dual ("bonded") DSI mode for DB845c
On 4.05.2023 19:47, Dmitry Baryshkov wrote:
> On Thu, 4 May 2023 at 20:11, Konrad Dybcio wrote:
>>
>>
>>
>> On 4.05.2023 18:04, Dmitry Baryshkov wrote:
>>> Now as both lt9611 and drm/msm drivers were updated to handle the 4k
>>> modes over DSI, enable "bonded" DSI mode on DB845c. This way the board
>>> utilizes both DSI links and thus can support 4k on the HDMI output.
>>>
>>> Cc: Amit Pundir
>>> Signed-off-by: Dmitry Baryshkov
>>> ---
>> Reviewed-by: Konrad Dybcio
>>
>> Konrad
>>> arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 36 ++
>>> 1 file changed, 36 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
>>> b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
>>> index e14fe9bbb386..4dea2c04b22f 100644
>>> --- a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
>>> +++ b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
>>> @@ -419,6 +419,9 @@ {
>>> status = "okay";
>> P.S. wanna move status last by chance?
>
> Not within this patch, it is not relevant to bonded DSI mode.
Of course.
Konrad
>
>>
>> Konrad
>>> vdda-supply = <_l26a_1p2>;
>>>
>>> + qcom,dual-dsi-mode;
>>> + qcom,master-dsi;
>>> +
>>> ports {
>>> port@1 {
>>> endpoint {
>>> @@ -434,6 +437,31 @@ _phy {
>>> vdds-supply = <_l1a_0p875>;
>>> };
>>>
>>> + {
>>> + vdda-supply = <_l26a_1p2>;
>>> +
>>> + qcom,dual-dsi-mode;
>>> +
>>> + /* DSI1 is slave, so use DSI0 clocks */
>>> + assigned-clock-parents = <_phy 0>, <_phy 1>;
>>> +
>>> + status = "okay";
>>> +
>>> + ports {
>>> + port@1 {
>>> + endpoint {
>>> + remote-endpoint = <_b>;
>>> + data-lanes = <0 1 2 3>;
>>> + };
>>> + };
>>> + };
>>> +};
>>> +
>>> +_phy {
>>> + vdds-supply = <_l1a_0p875>;
>>> + status = "okay";
>>> +};
>>> +
>>> {
>>> protected-clocks = ,
>>> ,
>>> @@ -493,6 +521,14 @@ lt9611_a: endpoint {
>>> };
>>> };
>>>
>>> + port@1 {
>>> + reg = <1>;
>>> +
>>> + lt9611_b: endpoint {
>>> + remote-endpoint = <_out>;
>>> + };
>>> + };
>>> +
>>> port@2 {
>>> reg = <2>;
>>>
>
>
>
Re: [PATCH v5 3/7] drm/msm/dpu: add DPU_PINGPONG_DSC bits into PP_BLK and PP_BLK_TE marcos
PP_BLK_TE is no longer there.
marcos -> macros.
On 2023-05-04 09:46:41, Kuogee Hsieh wrote:
> At legacy chipsets, it required DPU_PINGPONG_DSC bit be set to indicate
I may have not made this clear, but the comments on patch 2/7
(introducing the DPU_PINGPONG_DSC bit) also apply to this patch: clarify
DPU 7.0.0 exactly in favour of "legacy", which has no definition at all
and changes over time.
> pingpong ops functions are required to complete DSC data path setup if
> this chipset has DSC hardware block presented. This patch add
> DPU_PINGPONG_DSC bit to both PP_BLK and PP_BLK_TE marcos if it has DSC
> hardware block presented.
Strictly speaking this patch together with 2/7 is not bisectable, as 2/7
first disables the callbacks for _all_ hardware and then this patch adds
it back by adding the flag to all DPU < 7.0.0 catalog descriptions.
To solve that, as we do in other DPU patch-series, just squash this
patch into 2/7. That way you also don't have to spend extra time
rewording this commit message either to match the improvements we made
in 2/7 (for example, you mention that "ops functions are required to
complete DSC data path setup", but those were already available before
2/7, despite sounding as if this is a new thing that was previously
missing entirely).
But please wait at least a couple days before sending v6. I only have a
few hours every day/week but would appreciate to review and test all the
other patches.
> Signed-off-by: Kuogee Hsieh
> ---
> .../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h| 16 +++
> .../gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 16 +++
> .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 24
> +++---
> .../drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h| 24
> +++---
> .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 24
> +++---
> 5 files changed, 52 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> index 521cfd5..ef92545 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> @@ -112,17 +112,17 @@ static const struct dpu_lm_cfg msm8998_lm[] = {
> };
>
> static const struct dpu_pingpong_cfg msm8998_pp[] = {
> - PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SDM845_TE2_MASK, 0,
> sdm845_pp_sblk_te,
> - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
> + PP_BLK("pingpong_0", PINGPONG_0, 0x7,
> PINGPONG_SDM845_TE2_MASK|BIT(DPU_PINGPONG_DSC),
This should be added to the MASK (add new #define's where necessary).
- Marijn
> + 0, sdm845_pp_sblk_te, DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR,
> 8),
> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),
> - PP_BLK("pingpong_1", PINGPONG_1, 0x70800, PINGPONG_SDM845_TE2_MASK, 0,
> sdm845_pp_sblk_te,
> - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
> + PP_BLK("pingpong_1", PINGPONG_1, 0x70800,
> PINGPONG_SDM845_TE2_MASK|BIT(DPU_PINGPONG_DSC),
> + 0, sdm845_pp_sblk_te, DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR,
> 9),
> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 13)),
> - PP_BLK("pingpong_2", PINGPONG_2, 0x71000, PINGPONG_SDM845_MASK, 0,
> sdm845_pp_sblk,
> - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
> + PP_BLK("pingpong_2", PINGPONG_2, 0x71000,
> PINGPONG_SDM845_MASK|BIT(DPU_PINGPONG_DSC),
> + 0, sdm845_pp_sblk, DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 14)),
> - PP_BLK("pingpong_3", PINGPONG_3, 0x71800, PINGPONG_SDM845_MASK, 0,
> sdm845_pp_sblk,
> - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
> + PP_BLK("pingpong_3", PINGPONG_3, 0x71800,
> PINGPONG_SDM845_MASK|BIT(DPU_PINGPONG_DSC),
> + 0, sdm845_pp_sblk, DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
> };
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> index b109757..697fbd8 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> @@ -110,17 +110,17 @@ static const struct dpu_lm_cfg sdm845_lm[] = {
> };
>
> static const struct dpu_pingpong_cfg sdm845_pp[] = {
> - PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SDM845_TE2_MASK, 0,
> sdm845_pp_sblk_te,
> - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
> + PP_BLK("pingpong_0", PINGPONG_0, 0x7,
> PINGPONG_SDM845_TE2_MASK|BIT(DPU_PINGPONG_DSC),
> + 0, sdm845_pp_sblk_te, DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR,
> 8),
> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),
> - PP_BLK("pingpong_1", PINGPONG_1, 0x70800, PINGPONG_SDM845_TE2_MASK, 0,
>
Re: [PATCH] arm64: dts: qcom: enable dual ("bonded") DSI mode for DB845c
On Thu, 4 May 2023 at 20:11, Konrad Dybcio wrote:
>
>
>
> On 4.05.2023 18:04, Dmitry Baryshkov wrote:
> > Now as both lt9611 and drm/msm drivers were updated to handle the 4k
> > modes over DSI, enable "bonded" DSI mode on DB845c. This way the board
> > utilizes both DSI links and thus can support 4k on the HDMI output.
> >
> > Cc: Amit Pundir
> > Signed-off-by: Dmitry Baryshkov
> > ---
> Reviewed-by: Konrad Dybcio
>
> Konrad
> > arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 36 ++
> > 1 file changed, 36 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
> > b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
> > index e14fe9bbb386..4dea2c04b22f 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
> > +++ b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
> > @@ -419,6 +419,9 @@ {
> > status = "okay";
> P.S. wanna move status last by chance?
Not within this patch, it is not relevant to bonded DSI mode.
>
> Konrad
> > vdda-supply = <_l26a_1p2>;
> >
> > + qcom,dual-dsi-mode;
> > + qcom,master-dsi;
> > +
> > ports {
> > port@1 {
> > endpoint {
> > @@ -434,6 +437,31 @@ _phy {
> > vdds-supply = <_l1a_0p875>;
> > };
> >
> > + {
> > + vdda-supply = <_l26a_1p2>;
> > +
> > + qcom,dual-dsi-mode;
> > +
> > + /* DSI1 is slave, so use DSI0 clocks */
> > + assigned-clock-parents = <_phy 0>, <_phy 1>;
> > +
> > + status = "okay";
> > +
> > + ports {
> > + port@1 {
> > + endpoint {
> > + remote-endpoint = <_b>;
> > + data-lanes = <0 1 2 3>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +_phy {
> > + vdds-supply = <_l1a_0p875>;
> > + status = "okay";
> > +};
> > +
> > {
> > protected-clocks = ,
> > ,
> > @@ -493,6 +521,14 @@ lt9611_a: endpoint {
> > };
> > };
> >
> > + port@1 {
> > + reg = <1>;
> > +
> > + lt9611_b: endpoint {
> > + remote-endpoint = <_out>;
> > + };
> > + };
> > +
> > port@2 {
> > reg = <2>;
> >
--
With best wishes
Dmitry
Re: [PATCH 1/2] iommu/arm-smmu-qcom: Fix missing adreno_smmu's
On 2.05.2023 18:09, Rob Clark wrote:
> From: Rob Clark
>
> When the special handling of qcom,adreno-smmu was moved into
> qcom_smmu_create(), it was overlooked that we didn't have all the
> required entries in qcom_smmu_impl_of_match. So we stopped getting
> adreno_smmu_priv on sc7180, breaking per-process pgtables.
>
> Fixes: 30b912a03d91 ("iommu/arm-smmu-qcom: Move the qcom,adreno-smmu check
> into qcom_smmu_create")
> Signed-off-by: Rob Clark
> ---
I believe the issue here is the lack of qcom,sc7180-smmu-v2 instead.
qcom,adreno-smmu does not have to imply the "qcom smmu v2" impl
Konrad
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index d1b296b95c86..88c89424485b 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -512,20 +512,25 @@ static const struct of_device_id __maybe_unused
> qcom_smmu_impl_of_match[] = {
> { .compatible = "qcom,sm6115-smmu-500", .data =
> _smmu_500_impl0_data},
> { .compatible = "qcom,sm6125-smmu-500", .data =
> _smmu_500_impl0_data },
> { .compatible = "qcom,sm6350-smmu-v2", .data = _smmu_v2_data },
> { .compatible = "qcom,sm6350-smmu-500", .data =
> _smmu_500_impl0_data },
> { .compatible = "qcom,sm6375-smmu-500", .data =
> _smmu_500_impl0_data },
> { .compatible = "qcom,sm8150-smmu-500", .data =
> _smmu_500_impl0_data },
> { .compatible = "qcom,sm8250-smmu-500", .data =
> _smmu_500_impl0_data },
> { .compatible = "qcom,sm8350-smmu-500", .data =
> _smmu_500_impl0_data },
> { .compatible = "qcom,sm8450-smmu-500", .data =
> _smmu_500_impl0_data },
> { .compatible = "qcom,smmu-500", .data = _smmu_500_impl0_data },
> + /*
> + * Should come after the qcom,smmu-500 fallback so smmu-500 variants of
> + * adreno-smmu get qcom_adreno_smmu_500_impl:
> + */
> + { .compatible = "qcom,adreno-smmu", .data = _smmu_v2_data },
> { }
> };
>
> #ifdef CONFIG_ACPI
> static struct acpi_platform_list qcom_acpi_platlist[] = {
> { "LENOVO", "CB-01 ", 0x8180, ACPI_SIG_IORT, equal, "QCOM SMMU" },
> { "QCOM ", "QCOMEDK2", 0x8180, ACPI_SIG_IORT, equal, "QCOM SMMU" },
> { }
> };
> #endif
Re: [PATCH v5 2/7] drm/msm/dpu: add DPU_PINGPONG_DSC feature bit
On 2023-05-04 09:46:40, Kuogee Hsieh wrote:
> DPU < 7.0.0 requires the PINGPONG block to be involved during
Nit: double space.
> DSC setting up. Since DPU < 7.0.0, enabling and starting the DSC
That should be >=.
> encoder engine moved to INTF with the help of the flush mechanism.
> Add a DPU_PINGPONG_DSC feature bit to restrict the availability of
> dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() on the
> PINGPONG block to DPU < 7.0.0 hardware, as the registers are not
> available [in the PINGPONG block] on DPU 7.0.0 and higher anymore.
> Existing call-sites to these callbacks already skip calling into
> them if the function pointer is NULL.
>
> Changes in v4:
> -- add more details commit text
>
> Changes in v5:
> -- reword commit text suggested by Marijn
> -- delet comma
> -- use test_bit()
>
> Reported-by: Marijn Suijten
> Signed-off-by: Kuogee Hsieh
> Reviewed-by: Dmitry Baryshkov
This patch isn't strictly bisectable, but I'll explain in patch 3/7.
After addressing the '<' -> '>=' typo above, this is:
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +++-
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 6 ++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> index 6ee48f0..dc0a4da 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> @@ -144,7 +144,8 @@ enum {
> * @DPU_PINGPONG_TE2Additional tear check block for split pipes
> * @DPU_PINGPONG_SPLIT PP block supports split fifo
> * @DPU_PINGPONG_SLAVE PP block is a suitable slave for split fifo
> - * @DPU_PINGPONG_DITHER,Dither blocks
> + * @DPU_PINGPONG_DITHER Dither blocks
> + * @DPU_PINGPONG_DSCPP ops functions required for DSC
> * @DPU_PINGPONG_MAX
> */
> enum {
> @@ -153,6 +154,7 @@ enum {
> DPU_PINGPONG_SPLIT,
> DPU_PINGPONG_SLAVE,
> DPU_PINGPONG_DITHER,
> + DPU_PINGPONG_DSC,
> DPU_PINGPONG_MAX
> };
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> index 79e4576..e7f47a4 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> @@ -295,6 +295,12 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong
> *c,
> c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
> c->ops.disable_dsc = dpu_hw_pp_dsc_disable;
>
> + if (test_bit(DPU_PINGPONG_DSC, )) {
> + c->ops.setup_dsc = dpu_hw_pp_setup_dsc;
> + c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
> + c->ops.disable_dsc = dpu_hw_pp_dsc_disable;
> + }
> +
> if (test_bit(DPU_PINGPONG_DITHER, ))
> c->ops.setup_dither = dpu_hw_pp_setup_dither;
> };
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Re: [PATCH v5 4/7] drm/msm/dpu: Introduce PINGPONG_NONE to disconnect DSC from PINGPONG
On 2023-05-04 09:46:42, Kuogee Hsieh wrote:
> Disabling the crossbar mux between DSC and PINGPONG currently
> requires a bogus enum dpu_pingpong value to be passed when calling
> dsc_bind_pingpong_blk() with enable=false, even though the register
> value written is independent of the current PINGPONG block. Replace
> that `bool enable` parameter with a new PINGPONG_NONE dpu_pingpong
> flag that triggers the write of the "special" 0xF "crossbar
> disabled" value to the register instead.
>
> Changes in v4:
> -- more details to commit text
>
> Changes in v5:
> -- rewording commit text suggested by Marijn
> -- add DRM_DEBUG_KMS for DSC unbinding case
>
> Signed-off-by: Kuogee Hsieh
> Reviewed-by: Dmitry Baryshkov
Thanks for bearing with all the comments thus far!
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 15 ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h | 1 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 3 ++-
> 4 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index cf1de5d..ffa6f04 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -1850,7 +1850,7 @@ static void dpu_encoder_dsc_pipe_cfg(struct dpu_hw_dsc
> *hw_dsc,
> hw_pp->ops.setup_dsc(hw_pp);
>
> if (hw_dsc->ops.dsc_bind_pingpong_blk)
> - hw_dsc->ops.dsc_bind_pingpong_blk(hw_dsc, true, hw_pp->idx);
> + hw_dsc->ops.dsc_bind_pingpong_blk(hw_dsc, hw_pp->idx);
>
> if (hw_pp->ops.enable_dsc)
> hw_pp->ops.enable_dsc(hw_pp);
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
> index 4a6bbcc..47cb9f3 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
> @@ -157,7 +157,6 @@ static void dpu_hw_dsc_config_thresh(struct dpu_hw_dsc
> *hw_dsc,
>
> static void dpu_hw_dsc_bind_pingpong_blk(
> struct dpu_hw_dsc *hw_dsc,
> - bool enable,
> const enum dpu_pingpong pp)
> {
> struct dpu_hw_blk_reg_map *c = _dsc->hw;
> @@ -166,14 +165,16 @@ static void dpu_hw_dsc_bind_pingpong_blk(
>
> dsc_ctl_offset = DSC_CTL(hw_dsc->idx);
>
> - if (enable)
> + if (pp)
> mux_cfg = (pp - PINGPONG_0) & 0x7;
>
> - DRM_DEBUG_KMS("%s dsc:%d %s pp:%d\n",
> - enable ? "Binding" : "Unbinding",
> - hw_dsc->idx - DSC_0,
> - enable ? "to" : "from",
> - pp - PINGPONG_0);
> + if (pp)
> + DRM_DEBUG_KMS("Binding dsc:%d to pp:%d\n",
> + hw_dsc->idx - DSC_0,
> + pp - PINGPONG_0);
> + else
> + DRM_DEBUG_KMS("Unbinding dsc:%d from any pp\n",
> + hw_dsc->idx - DSC_0);
>
> DPU_REG_WRITE(c, dsc_ctl_offset, mux_cfg);
> }
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
> index 287ec5f..138080a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
> @@ -44,7 +44,6 @@ struct dpu_hw_dsc_ops {
> struct drm_dsc_config *dsc);
>
> void (*dsc_bind_pingpong_blk)(struct dpu_hw_dsc *hw_dsc,
> - bool enable,
> enum dpu_pingpong pp);
> };
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> index 1913a19..02a0f48 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> @@ -191,7 +191,8 @@ enum dpu_dsc {
> };
>
> enum dpu_pingpong {
> - PINGPONG_0 = 1,
> + PINGPONG_NONE,
> + PINGPONG_0,
> PINGPONG_1,
> PINGPONG_2,
> PINGPONG_3,
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Re: [PATCH] arm64: dts: qcom: enable dual ("bonded") DSI mode for DB845c
On 4.05.2023 18:04, Dmitry Baryshkov wrote:
> Now as both lt9611 and drm/msm drivers were updated to handle the 4k
> modes over DSI, enable "bonded" DSI mode on DB845c. This way the board
> utilizes both DSI links and thus can support 4k on the HDMI output.
>
> Cc: Amit Pundir
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Konrad Dybcio
Konrad
> arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 36 ++
> 1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
> b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
> index e14fe9bbb386..4dea2c04b22f 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
> @@ -419,6 +419,9 @@ {
> status = "okay";
P.S. wanna move status last by chance?
Konrad
> vdda-supply = <_l26a_1p2>;
>
> + qcom,dual-dsi-mode;
> + qcom,master-dsi;
> +
> ports {
> port@1 {
> endpoint {
> @@ -434,6 +437,31 @@ _phy {
> vdds-supply = <_l1a_0p875>;
> };
>
> + {
> + vdda-supply = <_l26a_1p2>;
> +
> + qcom,dual-dsi-mode;
> +
> + /* DSI1 is slave, so use DSI0 clocks */
> + assigned-clock-parents = <_phy 0>, <_phy 1>;
> +
> + status = "okay";
> +
> + ports {
> + port@1 {
> + endpoint {
> + remote-endpoint = <_b>;
> + data-lanes = <0 1 2 3>;
> + };
> + };
> + };
> +};
> +
> +_phy {
> + vdds-supply = <_l1a_0p875>;
> + status = "okay";
> +};
> +
> {
> protected-clocks = ,
> ,
> @@ -493,6 +521,14 @@ lt9611_a: endpoint {
> };
> };
>
> + port@1 {
> + reg = <1>;
> +
> + lt9611_b: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> port@2 {
> reg = <2>;
>
Re: [PATCH v3 29/65] clk: socfpga: gate: Add a determine_rate hook
Hi Dinh,
On Thu, Apr 27, 2023 at 02:09:48PM -0500, Dinh Nguyen wrote:
> Hi Maxime,
>
> On 4/25/23 09:48, Maxime Ripard wrote:
> > Hi Dinh,
> >
> > On Mon, Apr 24, 2023 at 01:32:28PM -0500, Dinh Nguyen wrote:
> > > On 4/4/23 05:11, Maxime Ripard wrote:
> > > > The SoCFGPA gate clock implements a mux with a set_parent hook, but
> > > > doesn't provide a determine_rate implementation.
> > > >
> > > > This is a bit odd, since set_parent() is there to, as its name implies,
> > > > change the parent of a clock. However, the most likely candidate to
> > > > trigger that parent change is a call to clk_set_rate(), with
> > > > determine_rate() figuring out which parent is the best suited for a
> > > > given rate.
> > > >
> > > > The other trigger would be a call to clk_set_parent(), but it's far less
> > > > used, and it doesn't look like there's any obvious user for that clock.
> > > >
> > > > So, the set_parent hook is effectively unused, possibly because of an
> > > > oversight. However, it could also be an explicit decision by the
> > > > original author to avoid any reparenting but through an explicit call to
> > > > clk_set_parent().
> > > >
> > > > The latter case would be equivalent to setting the flag
> > > > CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook
> > > > to __clk_mux_determine_rate(). Indeed, if no determine_rate
> > > > implementation is provided, clk_round_rate() (through
> > > > clk_core_round_rate_nolock()) will call itself on the parent if
> > > > CLK_SET_RATE_PARENT is set, and will not change the clock rate
> > > > otherwise. __clk_mux_determine_rate() has the exact same behavior when
> > > > CLK_SET_RATE_NO_REPARENT is set.
> > > >
> > > > And if it was an oversight, then we are at least explicit about our
> > > > behavior now and it can be further refined down the line.
> > > >
> > > > Signed-off-by: Maxime Ripard
> > > > ---
> > > >drivers/clk/socfpga/clk-gate.c | 3 ++-
> > > >1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/clk/socfpga/clk-gate.c
> > > > b/drivers/clk/socfpga/clk-gate.c
> > > > index 32ccda960f28..cbba8462a09e 100644
> > > > --- a/drivers/clk/socfpga/clk-gate.c
> > > > +++ b/drivers/clk/socfpga/clk-gate.c
> > > > @@ -110,6 +110,7 @@ static unsigned long socfpga_clk_recalc_rate(struct
> > > > clk_hw *hwclk,
> > > >static struct clk_ops gateclk_ops = {
> > > > .recalc_rate = socfpga_clk_recalc_rate,
> > > > + .determine_rate = __clk_mux_determine_rate,
> > > > .get_parent = socfpga_clk_get_parent,
> > > > .set_parent = socfpga_clk_set_parent,
> > > >};
> > > > @@ -166,7 +167,7 @@ void __init socfpga_gate_init(struct device_node
> > > > *node)
> > > > init.name = clk_name;
> > > > init.ops = ops;
> > > > - init.flags = 0;
> > > > + init.flags = CLK_SET_RATE_NO_REPARENT;
> > > > init.num_parents = of_clk_parent_fill(node, parent_name,
> > > > SOCFPGA_MAX_PARENTS);
> > > > if (init.num_parents < 2) {
> > > >
> > >
> > > This patch broke SoCFPGA boot serial port. The characters are mangled.
> >
> > Do you have any other access to that board? If so, could you dump
> > clk_summary in debugfs with and without that patch?
> >
>
> That dump from the clk_summary are identical for both cases.
Thanks for testing
I'm a bit confused, there should be no difference in behaviour, and if
there was any difference I would expect the clock tree to be somewhat
different.
Could you still paste the clk_summary (and dmesg) output? Which UART
driver is being used?
Also, is there a way for me to test it somehow?
Thanks,
Maxime
signature.asc
Description: PGP signature
Re: [PATCH v3 43/65] ASoC: tlv320aic32x4: Add a determine_rate hook
Hi Mark, On Wed, Apr 05, 2023 at 04:34:31PM +0100, Mark Brown wrote: > On Wed, Apr 05, 2023 at 05:17:21PM +0200, Maxime Ripard wrote: > > On Tue, Apr 04, 2023 at 04:26:18PM +0100, Mark Brown wrote: > > > > To be honest it's surprising that we'd have to manually specify this, I > > > would expect to be able to reparent. I suspect it'd be better to go the > > > other way here and allow reparenting. > > > Yeah, I think I'd prefer to allow reparenting too, but as can be seen > > from the other reviewers in that thread, it seems like we have a very > > split community here, so that doesn't sound very realistic without some > > major pushback :) > > For these ASoC drivers I think we should just do the reparenting, > they're very much at the leaf of the tree so the considerations that > make it a problem sometimes are unlikely to apply. I'd still prefer to remain conservative on this series and try not to change the behaviour in it. It's pretty massive already, I'd like to avoid tracking regressions left and right :) Would sending a subsequent series that would do this acceptable for you? Maxime signature.asc Description: PGP signature
[PATCH v5 7/7] drm/msm/dpu: add DSC 1.2 hw blocks for relevant chipsets
From: Abhinav Kumar
Add DSC 1.2 hardware blocks to the catalog with necessary sub-block and
feature flag information. Each display compression engine (DCE) contains
dual hard slice DSC encoders so both share same base address but with
its own different sub block address.
changes in v4:
-- delete DPU_DSC_HW_REV_1_1
-- re arrange sc8280xp_dsc[]
Signed-off-by: Abhinav Kumar
Signed-off-by: Kuogee Hsieh
Reviewed-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 14
.../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 7 ++
.../drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 16 ++
.../gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 14
.../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 14
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 25 +-
6 files changed, 89 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
index 500cfd0..c4c93c8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
@@ -153,6 +153,18 @@ static const struct dpu_merge_3d_cfg sm8350_merge_3d[] = {
MERGE_3D_BLK("merge_3d_2", MERGE_3D_2, 0x5),
};
+/*
+ * NOTE: Each display compression engine (DCE) contains dual hard
+ * slice DSC encoders so both share same base address but with
+ * its own different sub block address.
+ */
+static const struct dpu_dsc_cfg sm8350_dsc[] = {
+ DSC_BLK_1_2("dce_0", DSC_0, 0x8, 0x100, 0, dsc_sblk_0),
+ DSC_BLK_1_2("dce_0", DSC_1, 0x8, 0x100, 0, dsc_sblk_1),
+ DSC_BLK_1_2("dce_1", DSC_2, 0x81000, 0x100, BIT(DPU_DSC_NATIVE_422_EN),
dsc_sblk_0),
+ DSC_BLK_1_2("dce_1", DSC_3, 0x81000, 0x100, BIT(DPU_DSC_NATIVE_422_EN),
dsc_sblk_1),
+};
+
static const struct dpu_intf_cfg sm8350_intf[] = {
INTF_BLK("intf_0", INTF_0, 0x34000, 0x280, INTF_DP,
MSM_DP_CONTROLLER_0, 24, INTF_SC7280_MASK,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
@@ -215,6 +227,8 @@ const struct dpu_mdss_cfg dpu_sm8350_cfg = {
.dspp = sm8350_dspp,
.pingpong_count = ARRAY_SIZE(sm8350_pp),
.pingpong = sm8350_pp,
+ .dsc = sm8350_dsc,
+ .dsc_count = ARRAY_SIZE(sm8350_dsc),
.merge_3d_count = ARRAY_SIZE(sm8350_merge_3d),
.merge_3d = sm8350_merge_3d,
.intf_count = ARRAY_SIZE(sm8350_intf),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index 5646713..42c66fe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -93,6 +93,11 @@ static const struct dpu_pingpong_cfg sc7280_pp[] = {
PP_BLK_DITHER("pingpong_3", PINGPONG_3, 0x6c000, 0, sc7280_pp_sblk, -1,
-1),
};
+/* NOTE: sc7280 only has one dsc hard slice encoder */
+static const struct dpu_dsc_cfg sc7280_dsc[] = {
+ DSC_BLK_1_2("dce_0", DSC_0, 0x8, 0x100, BIT(DPU_DSC_NATIVE_422_EN),
dsc_sblk_0),
+};
+
static const struct dpu_intf_cfg sc7280_intf[] = {
INTF_BLK("intf_0", INTF_0, 0x34000, 0x280, INTF_DP,
MSM_DP_CONTROLLER_0, 24, INTF_SC7280_MASK,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
@@ -149,6 +154,8 @@ const struct dpu_mdss_cfg dpu_sc7280_cfg = {
.mixer = sc7280_lm,
.pingpong_count = ARRAY_SIZE(sc7280_pp),
.pingpong = sc7280_pp,
+ .dsc_count = ARRAY_SIZE(sc7280_dsc),
+ .dsc = sc7280_dsc,
.intf_count = ARRAY_SIZE(sc7280_intf),
.intf = sc7280_intf,
.vbif_count = ARRAY_SIZE(sdm845_vbif),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
index 808aacd..508479f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
@@ -141,6 +141,20 @@ static const struct dpu_merge_3d_cfg sc8280xp_merge_3d[] =
{
MERGE_3D_BLK("merge_3d_2", MERGE_3D_2, 0x5),
};
+/*
+ * NOTE: Each display compression engine (DCE) contains dual hard
+ * slice DSC encoders so both share same base address but with
+ * its own different sub block address.
+ */
+static const struct dpu_dsc_cfg sc8280xp_dsc[] = {
+ DSC_BLK_1_2("dce_0", DSC_0, 0x8, 0x100, 0, dsc_sblk_0),
+ DSC_BLK_1_2("dce_0", DSC_1, 0x8, 0x100, 0, dsc_sblk_1),
+ DSC_BLK_1_2("dce_1", DSC_2, 0x81000, 0x100, BIT(DPU_DSC_NATIVE_422_EN),
dsc_sblk_0),
+ DSC_BLK_1_2("dce_1", DSC_3, 0x81000, 0x100, BIT(DPU_DSC_NATIVE_422_EN),
dsc_sblk_1),
+ DSC_BLK_1_2("dce_2", DSC_4, 0x82000, 0x100, 0, dsc_sblk_0),
+ DSC_BLK_1_2("dce_2", DSC_5, 0x82000, 0x100, 0, dsc_sblk_1),
+};
+
/* TODO: INTF 3, 8 and 7 are used for MST, marked as INTF_NONE for now */
static const struct dpu_intf_cfg
[PATCH v5 6/7] drm/msm/dpu: separate DSC flush update out of interface
Current DSC flush update is piggyback inside dpu_hw_ctl_intf_cfg_v1().
This patch separates DSC flush away from dpu_hw_ctl_intf_cfg_v1() by
adding dpu_hw_ctl_update_pending_flush_dsc_v1() to handle both per
DSC engine and DSC flush bits at same time to make it consistent with
the location of flush programming of other dpu sub blocks.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 14 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 22 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 10 ++
3 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index ffa6f04..94b805b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1834,12 +1834,18 @@ dpu_encoder_dsc_initial_line_calc(struct drm_dsc_config
*dsc,
return DIV_ROUND_UP(total_pixels, dsc->slice_width);
}
-static void dpu_encoder_dsc_pipe_cfg(struct dpu_hw_dsc *hw_dsc,
+static void dpu_encoder_dsc_pipe_cfg(struct dpu_encoder_virt *dpu_enc,
+struct dpu_hw_dsc *hw_dsc,
struct dpu_hw_pingpong *hw_pp,
struct drm_dsc_config *dsc,
u32 common_mode,
u32 initial_lines)
{
+ struct dpu_encoder_phys *cur_master = dpu_enc->cur_master;
+ struct dpu_hw_ctl *ctl;
+
+ ctl = cur_master->hw_ctl;
+
if (hw_dsc->ops.dsc_config)
hw_dsc->ops.dsc_config(hw_dsc, dsc, common_mode, initial_lines);
@@ -1854,6 +1860,9 @@ static void dpu_encoder_dsc_pipe_cfg(struct dpu_hw_dsc
*hw_dsc,
if (hw_pp->ops.enable_dsc)
hw_pp->ops.enable_dsc(hw_pp);
+
+ if (ctl->ops.update_pending_flush_dsc)
+ ctl->ops.update_pending_flush_dsc(ctl, hw_dsc->idx);
}
static void dpu_encoder_prep_dsc(struct dpu_encoder_virt *dpu_enc,
@@ -1898,7 +1907,8 @@ static void dpu_encoder_prep_dsc(struct dpu_encoder_virt
*dpu_enc,
initial_lines = dpu_encoder_dsc_initial_line_calc(dsc, enc_ip_w);
for (i = 0; i < MAX_CHANNELS_PER_ENC; i++)
- dpu_encoder_dsc_pipe_cfg(hw_dsc[i], hw_pp[i], dsc,
dsc_common_mode, initial_lines);
+ dpu_encoder_dsc_pipe_cfg(dpu_enc, hw_dsc[i], hw_pp[i], dsc,
+ dsc_common_mode, initial_lines);
}
void dpu_encoder_prepare_for_kickoff(struct drm_encoder *drm_enc)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 4f7cfa9..832a6a7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -139,6 +139,11 @@ static inline void dpu_hw_ctl_trigger_flush_v1(struct
dpu_hw_ctl *ctx)
CTL_DSPP_n_FLUSH(dspp - DSPP_0),
ctx->pending_dspp_flush_mask[dspp - DSPP_0]);
}
+
+ if (ctx->pending_flush_mask & BIT(DSC_IDX))
+ DPU_REG_WRITE(>hw, CTL_DSC_FLUSH,
+ ctx->pending_dsc_flush_mask);
+
DPU_REG_WRITE(>hw, CTL_FLUSH, ctx->pending_flush_mask);
}
@@ -285,6 +290,13 @@ static void
dpu_hw_ctl_update_pending_flush_merge_3d_v1(struct dpu_hw_ctl *ctx,
ctx->pending_flush_mask |= BIT(MERGE_3D_IDX);
}
+static void dpu_hw_ctl_update_pending_flush_dsc_v1(struct dpu_hw_ctl *ctx,
+ enum dpu_dsc dsc_num)
+{
+ ctx->pending_dsc_flush_mask |= BIT(dsc_num - DSC_0);
+ ctx->pending_flush_mask |= BIT(DSC_IDX);
+}
+
static void dpu_hw_ctl_update_pending_flush_dspp(struct dpu_hw_ctl *ctx,
enum dpu_dspp dspp, u32 dspp_sub_blk)
{
@@ -502,9 +514,6 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if ((test_bit(DPU_CTL_VM_CFG, >caps->features)))
mode_sel = CTL_DEFAULT_GROUP_ID << 28;
- if (cfg->dsc)
- DPU_REG_WRITE(>hw, CTL_DSC_FLUSH, cfg->dsc);
-
if (cfg->intf_mode_sel == DPU_CTL_MODE_SEL_CMD)
mode_sel |= BIT(17);
@@ -524,10 +533,8 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
BIT(cfg->merge_3d - MERGE_3D_0));
- if (cfg->dsc) {
- DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
+ if (cfg->dsc)
DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
- }
}
static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
@@ -630,6 +637,9 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops,
ops->update_pending_flush_merge_3d =
dpu_hw_ctl_update_pending_flush_merge_3d_v1;
ops->update_pending_flush_wb =
dpu_hw_ctl_update_pending_flush_wb_v1;
+
[PATCH v5 5/7] drm/msm/dpu: add support for DSC encoder v1.2 engine
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Changes in v3:
-- fixed kernel test rebot report that "__iomem *off" is declared but not
used at dpu_hw_dsc_config_1_2()
-- unrolling thresh loops
Changes in v4:
-- delete DPU_DSC_HW_REV_1_1
-- delete off and used real register name directly
Reported-by: kernel test robot
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 32 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h | 14 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c | 385 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 7 +-
5 files changed, 435 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index b814fc8..b9af5e4 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -65,6 +65,7 @@ msm-$(CONFIG_DRM_MSM_DPU) += \
disp/dpu1/dpu_hw_catalog.o \
disp/dpu1/dpu_hw_ctl.o \
disp/dpu1/dpu_hw_dsc.o \
+ disp/dpu1/dpu_hw_dsc_1_2.o \
disp/dpu1/dpu_hw_interrupts.o \
disp/dpu1/dpu_hw_intf.o \
disp/dpu1/dpu_hw_lm.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index dc0a4da..4eda2cc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0-only */
/*
- * Copyright (c) 2022. Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2022-2023, Qualcomm Innovation Center, Inc. All rights
reserved.
* Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
*/
@@ -244,12 +244,18 @@ enum {
};
/**
- * DSC features
+ * DSC sub-blocks/features
* @DPU_DSC_OUTPUT_CTRL Configure which PINGPONG block gets
*the pixel output from this DSC.
+ * @DPU_DSC_HW_REV_1_2DSC block supports dsc 1.1 and 1.2
+ * @DPU_DSC_NATIVE_422_EN Supports native422 and native420 encoding
+ * @DPU_DSC_MAX
*/
enum {
DPU_DSC_OUTPUT_CTRL = 0x1,
+ DPU_DSC_HW_REV_1_2,
+ DPU_DSC_NATIVE_422_EN,
+ DPU_DSC_MAX
};
/**
@@ -306,6 +312,14 @@ struct dpu_pp_blk {
};
/**
+ * struct dpu_dsc_blk - DSC Encoder sub-blk information
+ * @info: HW register and features supported by this sub-blk
+ */
+struct dpu_dsc_blk {
+ DPU_HW_SUBBLK_INFO;
+};
+
+/**
* enum dpu_qos_lut_usage - define QoS LUT use cases
*/
enum dpu_qos_lut_usage {
@@ -452,6 +466,17 @@ struct dpu_pingpong_sub_blks {
};
/**
+ * struct dpu_dsc_sub_blks - DSC sub-blks
+ * @enc: DSC encoder sub block
+ * @ctl: DSC controller sub block
+ *
+ */
+struct dpu_dsc_sub_blks {
+ struct dpu_dsc_blk enc;
+ struct dpu_dsc_blk ctl;
+};
+
+/**
* dpu_clk_ctrl_type - Defines top level clock control signals
*/
enum dpu_clk_ctrl_type {
@@ -605,10 +630,13 @@ struct dpu_merge_3d_cfg {
* struct dpu_dsc_cfg - information of DSC blocks
* @id enum identifying this block
* @base register offset of this block
+ * @len: length of hardware block
* @features bit mask identifying sub-blocks/features
+ * @sblk sub-blocks information
*/
struct dpu_dsc_cfg {
DPU_HW_BLK_INFO;
+ const struct dpu_dsc_sub_blks *sblk;
};
/**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
index 138080a..bdff74d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
@@ -1,5 +1,8 @@
/* SPDX-License-Identifier: GPL-2.0-only */
-/* Copyright (c) 2020-2022, Linaro Limited */
+/*
+ * Copyright (c) 2020-2022, Linaro Limited
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
#ifndef _DPU_HW_DSC_H
#define _DPU_HW_DSC_H
@@ -69,6 +72,15 @@ struct dpu_hw_dsc *dpu_hw_dsc_init(const struct dpu_dsc_cfg
*cfg,
void __iomem *addr);
/**
+ * dpu_hw_dsc_init_1_2 - initializes the v1.2 DSC hw driver block
+ * @cfg: DSC catalog entry for which driver object is required
+ * @addr: Mapped register io address of MDP
+ * Returns: Error code or allocated dpu_hw_dsc context
+ */
+struct dpu_hw_dsc *dpu_hw_dsc_init_1_2(const struct dpu_dsc_cfg *cfg,
+ void __iomem *addr);
+
+/**
* dpu_hw_dsc_destroy - destroys dsc driver context
* @dsc: Pointer to dsc driver context returned by dpu_hw_dsc_init
*/
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c
new file mode 100644
index ..0c77c85
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c
@@ -0,0 +1,385 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2020-2021, The Linux
[PATCH v5 2/7] drm/msm/dpu: add DPU_PINGPONG_DSC feature bit
DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC setting up. Since DPU < 7.0.0, enabling and starting the DSC
encoder engine moved to INTF with the help of the flush mechanism.
Add a DPU_PINGPONG_DSC feature bit to restrict the availability of
dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() on the
PINGPONG block to DPU < 7.0.0 hardware, as the registers are not
available [in the PINGPONG block] on DPU 7.0.0 and higher anymore.
Existing call-sites to these callbacks already skip calling into
them if the function pointer is NULL.
Changes in v4:
-- add more details commit text
Changes in v5:
-- reword commit text suggested by Marijn
-- delet comma
-- use test_bit()
Reported-by: Marijn Suijten
Signed-off-by: Kuogee Hsieh
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 6 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 6ee48f0..dc0a4da 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -144,7 +144,8 @@ enum {
* @DPU_PINGPONG_TE2Additional tear check block for split pipes
* @DPU_PINGPONG_SPLIT PP block supports split fifo
* @DPU_PINGPONG_SLAVE PP block is a suitable slave for split fifo
- * @DPU_PINGPONG_DITHER,Dither blocks
+ * @DPU_PINGPONG_DITHER Dither blocks
+ * @DPU_PINGPONG_DSCPP ops functions required for DSC
* @DPU_PINGPONG_MAX
*/
enum {
@@ -153,6 +154,7 @@ enum {
DPU_PINGPONG_SPLIT,
DPU_PINGPONG_SLAVE,
DPU_PINGPONG_DITHER,
+ DPU_PINGPONG_DSC,
DPU_PINGPONG_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 79e4576..e7f47a4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -295,6 +295,12 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
c->ops.disable_dsc = dpu_hw_pp_dsc_disable;
+ if (test_bit(DPU_PINGPONG_DSC, )) {
+ c->ops.setup_dsc = dpu_hw_pp_setup_dsc;
+ c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
+ c->ops.disable_dsc = dpu_hw_pp_dsc_disable;
+ }
+
if (test_bit(DPU_PINGPONG_DITHER, ))
c->ops.setup_dither = dpu_hw_pp_setup_dither;
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v5 3/7] drm/msm/dpu: add DPU_PINGPONG_DSC bits into PP_BLK and PP_BLK_TE marcos
At legacy chipsets, it required DPU_PINGPONG_DSC bit be set to indicate
pingpong ops functions are required to complete DSC data path setup if
this chipset has DSC hardware block presented. This patch add
DPU_PINGPONG_DSC bit to both PP_BLK and PP_BLK_TE marcos if it has DSC
hardware block presented.
Signed-off-by: Kuogee Hsieh
---
.../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h| 16 +++
.../gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 16 +++
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 24 +++---
.../drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h| 24 +++---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 24 +++---
5 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index 521cfd5..ef92545 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -112,17 +112,17 @@ static const struct dpu_lm_cfg msm8998_lm[] = {
};
static const struct dpu_pingpong_cfg msm8998_pp[] = {
- PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SDM845_TE2_MASK, 0,
sdm845_pp_sblk_te,
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
+ PP_BLK("pingpong_0", PINGPONG_0, 0x7,
PINGPONG_SDM845_TE2_MASK|BIT(DPU_PINGPONG_DSC),
+ 0, sdm845_pp_sblk_te, DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR,
8),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),
- PP_BLK("pingpong_1", PINGPONG_1, 0x70800, PINGPONG_SDM845_TE2_MASK, 0,
sdm845_pp_sblk_te,
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
+ PP_BLK("pingpong_1", PINGPONG_1, 0x70800,
PINGPONG_SDM845_TE2_MASK|BIT(DPU_PINGPONG_DSC),
+0, sdm845_pp_sblk_te, DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR,
9),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 13)),
- PP_BLK("pingpong_2", PINGPONG_2, 0x71000, PINGPONG_SDM845_MASK, 0,
sdm845_pp_sblk,
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
+ PP_BLK("pingpong_2", PINGPONG_2, 0x71000,
PINGPONG_SDM845_MASK|BIT(DPU_PINGPONG_DSC),
+ 0, sdm845_pp_sblk, DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 14)),
- PP_BLK("pingpong_3", PINGPONG_3, 0x71800, PINGPONG_SDM845_MASK, 0,
sdm845_pp_sblk,
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
+ PP_BLK("pingpong_3", PINGPONG_3, 0x71800,
PINGPONG_SDM845_MASK|BIT(DPU_PINGPONG_DSC),
+ 0, sdm845_pp_sblk, DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
index b109757..697fbd8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
@@ -110,17 +110,17 @@ static const struct dpu_lm_cfg sdm845_lm[] = {
};
static const struct dpu_pingpong_cfg sdm845_pp[] = {
- PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SDM845_TE2_MASK, 0,
sdm845_pp_sblk_te,
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
+ PP_BLK("pingpong_0", PINGPONG_0, 0x7,
PINGPONG_SDM845_TE2_MASK|BIT(DPU_PINGPONG_DSC),
+ 0, sdm845_pp_sblk_te, DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR,
8),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),
- PP_BLK("pingpong_1", PINGPONG_1, 0x70800, PINGPONG_SDM845_TE2_MASK, 0,
sdm845_pp_sblk_te,
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
+ PP_BLK("pingpong_1", PINGPONG_1, 0x70800,
PINGPONG_SDM845_TE2_MASK|BIT(DPU_PINGPONG_DSC),
+ 0, sdm845_pp_sblk_te, DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR,
9),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 13)),
- PP_BLK("pingpong_2", PINGPONG_2, 0x71000, PINGPONG_SDM845_MASK, 0,
sdm845_pp_sblk,
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
+ PP_BLK("pingpong_2", PINGPONG_2, 0x71000,
PINGPONG_SDM845_MASK|BIT(DPU_PINGPONG_DSC),
+ 0, sdm845_pp_sblk, DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 14)),
- PP_BLK("pingpong_3", PINGPONG_3, 0x71800, PINGPONG_SDM845_MASK, 0,
sdm845_pp_sblk,
- DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
+ PP_BLK("pingpong_3", PINGPONG_3, 0x71800,
PINGPONG_SDM845_MASK|BIT(DPU_PINGPONG_DSC),
+ 0, sdm845_pp_sblk, DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
index 30aff2b..cb117ca 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
[PATCH v5 4/7] drm/msm/dpu: Introduce PINGPONG_NONE to disconnect DSC from PINGPONG
Disabling the crossbar mux between DSC and PINGPONG currently
requires a bogus enum dpu_pingpong value to be passed when calling
dsc_bind_pingpong_blk() with enable=false, even though the register
value written is independent of the current PINGPONG block. Replace
that `bool enable` parameter with a new PINGPONG_NONE dpu_pingpong
flag that triggers the write of the "special" 0xF "crossbar
disabled" value to the register instead.
Changes in v4:
-- more details to commit text
Changes in v5:
-- rewording commit text suggested by Marijn
-- add DRM_DEBUG_KMS for DSC unbinding case
Signed-off-by: Kuogee Hsieh
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 15 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 3 ++-
4 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index cf1de5d..ffa6f04 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1850,7 +1850,7 @@ static void dpu_encoder_dsc_pipe_cfg(struct dpu_hw_dsc
*hw_dsc,
hw_pp->ops.setup_dsc(hw_pp);
if (hw_dsc->ops.dsc_bind_pingpong_blk)
- hw_dsc->ops.dsc_bind_pingpong_blk(hw_dsc, true, hw_pp->idx);
+ hw_dsc->ops.dsc_bind_pingpong_blk(hw_dsc, hw_pp->idx);
if (hw_pp->ops.enable_dsc)
hw_pp->ops.enable_dsc(hw_pp);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 4a6bbcc..47cb9f3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -157,7 +157,6 @@ static void dpu_hw_dsc_config_thresh(struct dpu_hw_dsc
*hw_dsc,
static void dpu_hw_dsc_bind_pingpong_blk(
struct dpu_hw_dsc *hw_dsc,
- bool enable,
const enum dpu_pingpong pp)
{
struct dpu_hw_blk_reg_map *c = _dsc->hw;
@@ -166,14 +165,16 @@ static void dpu_hw_dsc_bind_pingpong_blk(
dsc_ctl_offset = DSC_CTL(hw_dsc->idx);
- if (enable)
+ if (pp)
mux_cfg = (pp - PINGPONG_0) & 0x7;
- DRM_DEBUG_KMS("%s dsc:%d %s pp:%d\n",
- enable ? "Binding" : "Unbinding",
- hw_dsc->idx - DSC_0,
- enable ? "to" : "from",
- pp - PINGPONG_0);
+ if (pp)
+ DRM_DEBUG_KMS("Binding dsc:%d to pp:%d\n",
+ hw_dsc->idx - DSC_0,
+ pp - PINGPONG_0);
+ else
+ DRM_DEBUG_KMS("Unbinding dsc:%d from any pp\n",
+ hw_dsc->idx - DSC_0);
DPU_REG_WRITE(c, dsc_ctl_offset, mux_cfg);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
index 287ec5f..138080a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
@@ -44,7 +44,6 @@ struct dpu_hw_dsc_ops {
struct drm_dsc_config *dsc);
void (*dsc_bind_pingpong_blk)(struct dpu_hw_dsc *hw_dsc,
- bool enable,
enum dpu_pingpong pp);
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
index 1913a19..02a0f48 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
@@ -191,7 +191,8 @@ enum dpu_dsc {
};
enum dpu_pingpong {
- PINGPONG_0 = 1,
+ PINGPONG_NONE,
+ PINGPONG_0,
PINGPONG_1,
PINGPONG_2,
PINGPONG_3,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v5 0/7] add DSC 1.2 dpu supports
This series adds the DPU side changes to support DSC 1.2 encoder. This was validated with both DSI DSC 1.2 panel and DP DSC 1.2 monitor. The DSI and DP parts will be pushed later on top of this change. This seriel is rebase on [1], [2] and catalog fixes from rev-4 of [3]. [1]: https://patchwork.freedesktop.org/series/116851/ [2]: https://patchwork.freedesktop.org/series/116615/ [3]: https://patchwork.freedesktop.org/series/112332/ Abhinav Kumar (2): drm/msm/dpu: add dsc blocks for remaining chipsets in catalog drm/msm/dpu: add DSC 1.2 hw blocks for relevant chipsets Kuogee Hsieh (5): drm/msm/dpu: add DPU_PINGPONG_DSC feature bit drm/msm/dpu: add DPU_PINGPONG_DSC bits into PP_BLK and PP_BLK_TE marcos drm/msm/dpu: Introduce PINGPONG_NONE to disconnect DSC from PINGPONG drm/msm/dpu: add support for DSC encoder v1.2 engine drm/msm/dpu: separate DSC flush update out of interface drivers/gpu/drm/msm/Makefile | 1 + .../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h| 23 +- .../gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 16 +- .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 24 +- .../drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h| 35 +- .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 24 +- .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 14 + .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 7 + .../drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 16 + .../gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 14 + .../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 14 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 16 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 25 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 36 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 22 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 10 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 15 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h | 15 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c | 385 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h| 3 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c| 6 + drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 7 +- 22 files changed, 652 insertions(+), 76 deletions(-) create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v5 1/7] drm/msm/dpu: add dsc blocks for remaining chipsets in catalog
From: Abhinav Kumar
There are some platforms has DSC blocks but it is not declared at catalog.
For completeness, this patch adds DSC blocks for platforms which missed
them.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 7 +++
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 11 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index c0dd477..521cfd5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -126,6 +126,11 @@ static const struct dpu_pingpong_cfg msm8998_pp[] = {
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
};
+static const struct dpu_dsc_cfg msm8998_dsc[] = {
+ DSC_BLK("dsc_0", DSC_0, 0x8, 0),
+ DSC_BLK("dsc_1", DSC_1, 0x80400, 0),
+};
+
static const struct dpu_dspp_cfg msm8998_dspp[] = {
DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_MSM8998_MASK,
_dspp_sblk),
@@ -199,6 +204,8 @@ const struct dpu_mdss_cfg dpu_msm8998_cfg = {
.dspp = msm8998_dspp,
.pingpong_count = ARRAY_SIZE(msm8998_pp),
.pingpong = msm8998_pp,
+ .dsc_count = ARRAY_SIZE(msm8998_dsc),
+ .dsc = msm8998_dsc,
.intf_count = ARRAY_SIZE(msm8998_intf),
.intf = msm8998_intf,
.vbif_count = ARRAY_SIZE(msm8998_vbif),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
index e8057a1..fec1665 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
@@ -142,6 +142,15 @@ static const struct dpu_merge_3d_cfg sc8180x_merge_3d[] = {
MERGE_3D_BLK("merge_3d_2", MERGE_3D_2, 0x83200),
};
+static const struct dpu_dsc_cfg sc8180x_dsc[] = {
+ DSC_BLK("dsc_0", DSC_0, 0x8, BIT(DPU_DSC_OUTPUT_CTRL)),
+ DSC_BLK("dsc_1", DSC_1, 0x80400, BIT(DPU_DSC_OUTPUT_CTRL)),
+ DSC_BLK("dsc_2", DSC_2, 0x80800, BIT(DPU_DSC_OUTPUT_CTRL)),
+ DSC_BLK("dsc_3", DSC_3, 0x80c00, BIT(DPU_DSC_OUTPUT_CTRL)),
+ DSC_BLK("dsc_4", DSC_4, 0x81000, BIT(DPU_DSC_OUTPUT_CTRL)),
+ DSC_BLK("dsc_5", DSC_5, 0x81400, BIT(DPU_DSC_OUTPUT_CTRL)),
+};
+
static const struct dpu_intf_cfg sc8180x_intf[] = {
INTF_BLK("intf_0", INTF_0, 0x6a000, 0x280, INTF_DP,
MSM_DP_CONTROLLER_0, 24, INTF_SC7180_MASK,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
@@ -206,6 +215,8 @@ const struct dpu_mdss_cfg dpu_sc8180x_cfg = {
.mixer = sc8180x_lm,
.pingpong_count = ARRAY_SIZE(sc8180x_pp),
.pingpong = sc8180x_pp,
+ .dsc_count = ARRAY_SIZE(sc8180x_dsc),
+ .dsc = sc8180x_dsc,
.merge_3d_count = ARRAY_SIZE(sc8180x_merge_3d),
.merge_3d = sc8180x_merge_3d,
.intf_count = ARRAY_SIZE(sc8180x_intf),
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [Intel-gfx] [PATCH v8 0/7] drm/i915: use ref_tracker library for tracking wakerefs
Hi maintainers of net and i915, On 25.04.2023 00:05, Andrzej Hajda wrote: This is revived patchset improving ref_tracker library and converting i915 internal tracker to ref_tracker. The old thread ended without consensus about small kernel allocations, which are performed under spinlock. I have tried to solve the problem by splitting the calls, but it results in complicated API, so I went back to original solution. If there are better solutions I am glad to discuss them. Meanwhile I send original patchset with addressed remaining comments. To: Jani Nikula To: Joonas Lahtinen To: Rodrigo Vivi To: Tvrtko Ursulin To: David Airlie To: Daniel Vetter To: Eric Dumazet Cc: linux-ker...@vger.kernel.org Cc: intel-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: Chris Wilson Cc: net...@vger.kernel.org Cc: Jakub Kicinski Cc: Dmitry Vyukov Cc: "David S. Miller" Cc: Andi Shyti Cc: Das, Nirmoy Signed-off-by: Andrzej Hajda --- Changes in v8: - addressed comments from Eric, Zhou and CI, thanks, - added ref_tracker_dir_init name argument to all callers in one patch - moved intel_wakeref_tracker_show to *.c - s/intel_wakeref_tracker_show/intel_ref_tracker_show/ - removed 'default n' from Kconfig - changed strlcpy to strscpy, - removed assignement from if condition, - removed long lines from patch description - added tags - Link to v7: https://lore.kernel.org/r/20230224-track_gt-v7-0-11f08358c...@intel.com Changes in v7: - removed 8th patch (hold wakeref), as it was already merged - added tags (thx Andi) - Link to v6: https://lore.kernel.org/r/20230224-track_gt-v6-0-0dc8601fd...@intel.com Changes in v6: - rebased to solve minor conflict and allow CI testing - Link to v5: https://lore.kernel.org/r/20230224-track_gt-v5-0-77be86f2c...@intel.com Changes in v5 (thx Andi for review): - use *_locked convention instead of __*, - improved commit messages, - re-worked i915 patches, squashed separation and conversion patches, - added tags, - Link to v4: https://lore.kernel.org/r/20230224-track_gt-v4-0-464e8ab4c...@intel.com Changes in v4: - split "Separate wakeref tracking" to smaller parts - fixed typos, - Link to v1-v3: https://patchwork.freedesktop.org/series/100327/ --- Andrzej Hajda (7): lib/ref_tracker: add unlocked leak print helper lib/ref_tracker: improve printing stats lib/ref_tracker: add printing to memory buffer lib/ref_tracker: remove warnings in case of allocation failure drm/i915: Correct type of wakeref variable drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library drm/i915: Track gt pm wakerefs Finally all patches are reviewed. Question to network and i915 maintainers, how to merge this patchset: 1. Patches 1-4 belongs rather to network domain (especially patch 2). 2. Patches 5-7 are for i915. What would be the best way to do it? Regards Andrzej drivers/gpu/drm/i915/Kconfig.debug | 18 ++ drivers/gpu/drm/i915/display/intel_display_power.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 7 +- .../drm/i915/gem/selftests/i915_gem_coherency.c| 10 +- drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 14 +- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c| 13 +- drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h | 3 +- drivers/gpu/drm/i915/gt/intel_context.h| 4 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 2 + drivers/gpu/drm/i915/gt/intel_engine_pm.c | 7 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 + .../gpu/drm/i915/gt/intel_execlists_submission.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 12 +- drivers/gpu/drm/i915/gt/intel_gt_pm.h | 38 +++- drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 20 +- drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 5 +- drivers/gpu/drm/i915/gt/selftest_reset.c | 10 +- drivers/gpu/drm/i915/gt/selftest_rps.c | 17 +- drivers/gpu/drm/i915/gt/selftest_slpc.c| 5 +- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 +- drivers/gpu/drm/i915/i915_driver.c | 2 +- drivers/gpu/drm/i915/i915_pmu.c| 16 +- drivers/gpu/drm/i915/intel_runtime_pm.c| 221 ++--- drivers/gpu/drm/i915/intel_runtime_pm.h| 11 +- drivers/gpu/drm/i915/intel_wakeref.c | 35 +++- drivers/gpu/drm/i915/intel_wakeref.h | 73 ++- include/linux/ref_tracker.h| 25 ++- lib/ref_tracker.c | 179 ++--- lib/test_ref_tracker.c | 2 +- net/core/dev.c | 2 +- net/core/net_namespace.c | 4 +- 32 files changed, 445 insertions(+), 332 deletions(-) ---
Re: [PATCH v5 2/5] drm/i915: use pat_index instead of cache_level
> On 04/05/2023 00:02, fei.y...@intel.com wrote: >> From: Fei Yang >> >> Currently the KMD is using enum i915_cache_level to set caching policy for >> buffer objects. This is flaky because the PAT index which really controls >> the caching behavior in PTE has far more levels than what's defined in the >> enum. In addition, the PAT index is platform dependent, having to translate >> between i915_cache_level and PAT index is not reliable, and makes the code >> more complicated. >> >>>From UMD's perspective there is also a necessity to set caching policy for >> performance fine tuning. It's much easier for the UMD to directly use PAT >> index because the behavior of each PAT index is clearly defined in Bspec. >> Having the abstracted i915_cache_level sitting in between would only cause >> more ambiguity. >> >> For these reasons this patch replaces i915_cache_level with PAT index. Also >> note, the cache_level is not completely removed yet, because the KMD still >> has the need of creating buffer objects with simple cache settings such as >> cached, uncached, or writethrough. For such simple cases, using cache_level >> would help simplify the code. >> >> Cc: Chris Wilson >> Cc: Matt Roper >> Signed-off-by: Fei Yang >> Reviewed-by: Andi Shyti > > [snip] > >> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c >> b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c >> index bb6998d67133..f2334a713c4e 100644 >> --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c >> +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c >> @@ -56,7 +56,7 @@ static u64 gen8_pte_encode(dma_addr_t addr, >> } > >^^^ > > How come there are no changes to gen8_pte_encode? For legacy platforms cache_level is equal to pat_index, so I was thinking more about reducing number of lines changed. >vvv > >> >> static u64 mtl_pte_encode(dma_addr_t addr, >> - enum i915_cache_level level, >> + unsigned int pat_index, >> u32 flags) > > Prototype and implementation changed here for mtl_pte_encode. > > And we have: > >if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70)) >ppgtt->vm.pte_encode = mtl_pte_encode; >else >ppgtt->vm.pte_encode = gen8_pte_encode; > > So should be same prototype. And: > > u64 (*pte_encode)(dma_addr_t addr, >- enum i915_cache_level level, >+ unsigned int pat_index, > u32 flags); /* Create a valid PTE */ > > Patch relies on the compiler considering enum equal to unsigned int? yes, caller is passing in unsigned int and gets used as enum. > But the implementation of gen8_pte_encode and most ggtt counterparts is > looking at the passed in pat index and thinks it is cache level. > > How is that supposed to work?! Or I am blind and am missing something? For legacy platforms translation through LEGACY_CACHELEVEL would not change the value of cache_level. The cache_level and pat_index are basically the same for these platforms. It is broken for gen12 here. I was asked to separate the gen12_pte_encode change to another patch in the series, but that breaks bisect. Should I squash 2/5 and 3/5? > Regards, > > Tvrtko
[PATCH] arm64: dts: qcom: enable dual ("bonded") DSI mode for DB845c
Now as both lt9611 and drm/msm drivers were updated to handle the 4k
modes over DSI, enable "bonded" DSI mode on DB845c. This way the board
utilizes both DSI links and thus can support 4k on the HDMI output.
Cc: Amit Pundir
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 36 ++
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
index e14fe9bbb386..4dea2c04b22f 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
@@ -419,6 +419,9 @@ {
status = "okay";
vdda-supply = <_l26a_1p2>;
+ qcom,dual-dsi-mode;
+ qcom,master-dsi;
+
ports {
port@1 {
endpoint {
@@ -434,6 +437,31 @@ _phy {
vdds-supply = <_l1a_0p875>;
};
+ {
+ vdda-supply = <_l26a_1p2>;
+
+ qcom,dual-dsi-mode;
+
+ /* DSI1 is slave, so use DSI0 clocks */
+ assigned-clock-parents = <_phy 0>, <_phy 1>;
+
+ status = "okay";
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <_b>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+};
+
+_phy {
+ vdds-supply = <_l1a_0p875>;
+ status = "okay";
+};
+
{
protected-clocks = ,
,
@@ -493,6 +521,14 @@ lt9611_a: endpoint {
};
};
+ port@1 {
+ reg = <1>;
+
+ lt9611_b: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
port@2 {
reg = <2>;
--
2.39.2
Re: [PATCH v4 4/6] fbdev: Include instead of
Hi Thomas, On Thu, May 04, 2023 at 09:45:37AM +0200, Thomas Zimmermann wrote: > Replace include statements for with . Fixes > the coding style: if a header is available in asm/ and linux/, it > is preferable to include the header from linux/. This only affects > a few source files, most of which already include . > > Suggested-by: Sam Ravnborg > Signed-off-by: Thomas Zimmermann Thanks, Reviewed-by: Sam Ravnborg
[PATCH v5 8/8] drm/display/dsc: add YCbCr 4:2:2 and 4:2:0 RC parameters
Include RC parameters for YCbCr 4:2:2 and 4:2:0 configurations.
Reviewed-by: Suraj Kandpal
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 438 +++
include/drm/display/drm_dsc_helper.h | 2 +
2 files changed, 440 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
b/drivers/gpu/drm/display/drm_dsc_helper.c
index aec6f8c201af..65e810a54257 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -740,6 +740,438 @@ static const struct rc_parameters_data
rc_parameters_1_2_444[] = {
{ /* sentinel */ }
};
+static const struct rc_parameters_data rc_parameters_1_2_422[] = {
+ {
+ .bpp = DSC_BPP(6), .bpc = 8,
+ { 512, 15, 6144, 3, 12, 11, 11, {
+ { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+ { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+ { 3, 9, -8 }, { 3, 10, -10 }, { 5, 10, -10 }, { 5, 11,
-12 },
+ { 5, 11, -12 }, { 9, 12, -12 }, { 12, 13, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(6), .bpc = 10,
+ { 512, 15, 6144, 7, 16, 15, 15, {
+ { 0, 8, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
+ { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12,
-8 },
+ { 7, 13, -8 }, { 7, 14, -10 }, { 9, 14, -10 }, { 9, 15,
-12 },
+ { 9, 15, -12 }, { 13, 16, -12 }, { 16, 17, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(6), .bpc = 12,
+ { 512, 15, 6144, 11, 20, 19, 19, {
+ { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
+ { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11,
16, -8 },
+ { 11, 17, -8 }, { 11, 18, -10 }, { 13, 18, -10 },
+ { 13, 19, -12 }, { 13, 19, -12 }, { 17, 20, -12 },
+ { 20, 21, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(6), .bpc = 14,
+ { 512, 15, 6144, 15, 24, 23, 23, {
+ { 0, 12, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2
},
+ { 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15,
20, -8 },
+ { 15, 21, -8 }, { 15, 22, -10 }, { 17, 22, -10 },
+ { 17, 23, -12 }, { 17, 23, -12 }, { 21, 24, -12 },
+ { 24, 25, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(6), .bpc = 16,
+ { 512, 15, 6144, 19, 28, 27, 27, {
+ { 0, 12, 2 }, { 6, 14, 0 }, { 13, 17, 0 }, { 15, 20, -2
},
+ { 19, 23, -4 }, { 19, 23, -6 }, { 19, 23, -8 }, { 19,
24, -8 },
+ { 19, 25, -8 }, { 19, 26, -10 }, { 21, 26, -10 },
+ { 21, 27, -12 }, { 21, 27, -12 }, { 25, 28, -12 },
+ { 28, 29, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(7), .bpc = 8,
+ { 410, 15, 5632, 3, 12, 11, 11, {
+ { 0, 3, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 2, 6, -2 },
+ { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+ { 3, 9, -8 }, { 3, 9, -10 }, { 5, 10, -10 }, { 5, 10,
-10 },
+ { 5, 11, -12 }, { 7, 11, -12 }, { 11, 12, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(7), .bpc = 10,
+ { 410, 15, 5632, 7, 16, 15, 15, {
+ { 0, 7, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 6, 10, -2 },
+ { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12,
-8 },
+ { 7, 13, -8 }, { 7, 13, -10 }, { 9, 14, -10 }, { 9, 14,
-10 },
+ { 9, 15, -12 }, { 11, 15, -12 }, { 15, 16, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(7), .bpc = 12,
+ { 410, 15, 5632, 11, 20, 19, 19, {
+ { 0, 11, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 10, 14, -2
},
+ { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11,
16, -8 },
+ { 11, 17, -8 }, { 11, 17, -10 }, { 13, 18, -10 },
+ { 13, 18, -10 }, { 13, 19, -12 }, { 15, 19, -12 },
+ { 19, 20, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(7), .bpc = 14,
+ { 410, 15, 5632, 15, 24, 23, 23, {
+ { 0, 11, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 13, 18, -2
},
+ { 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15,
20,
[PATCH v5 7/8] drm/display/dsc: include the rest of pre-SCR parameters
DSC model contains pre-SCR RC parameters for other bpp/bpc combinations,
include them here for completeness. The values were generated from the
'pre_scr_cfg_files_for_reference' files found in DSC models 20210623.
The same fileset is a part of DSC model 20161212.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 72
1 file changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
b/drivers/gpu/drm/display/drm_dsc_helper.c
index 35b39f3109c4..aec6f8c201af 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -325,6 +325,16 @@ struct rc_parameters_data {
#define DSC_BPP(bpp) ((bpp) << 4)
static const struct rc_parameters_data rc_parameters_pre_scr[] = {
+ {
+ .bpp = DSC_BPP(6), .bpc = 8,
+ { 683, 15, 6144, 3, 13, 11, 11, {
+ { 0, 2, 0 }, { 1, 4, -2 }, { 3, 6, -2 }, { 4, 6, -4 },
+ { 5, 7, -6 }, { 5, 7, -6 }, { 6, 7, -6 }, { 6, 8, -8 },
+ { 7, 9, -8 }, { 8, 10, -10 }, { 9, 11, -10 }, { 10, 12,
-12 },
+ { 10, 13, -12 }, { 12, 14, -12 }, { 15, 15, -12 }
+ }
+ }
+ },
{
.bpp = DSC_BPP(8), .bpc = 8,
{ 512, 12, 6144, 3, 12, 11, 11, {
@@ -360,6 +370,37 @@ static const struct rc_parameters_data
rc_parameters_pre_scr[] = {
}
}
},
+ {
+ .bpp = DSC_BPP(10), .bpc = 8,
+ { 410, 12, 5632, 3, 12, 11, 11, {
+ { 0, 3, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 2, 6, -2 },
+ { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+ { 3, 9, -8 }, { 3, 9, -10 }, { 5, 10, -10 }, { 5, 11,
-10 },
+ { 5, 12, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(10), .bpc = 10,
+ { 410, 12, 5632, 7, 16, 15, 15, {
+ { 0, 7, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 6, 10, -2 },
+ { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12,
-8 },
+ { 7, 13, -8 }, { 7, 13, -10 }, { 9, 14, -10 }, { 9, 15,
-10 },
+ { 9, 16, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(10), .bpc = 12,
+ { 410, 12, 5632, 11, 20, 19, 19, {
+ { 0, 11, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 10, 14, -2
},
+ { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11,
16, -8 },
+ { 11, 17, -8 }, { 11, 17, -10 }, { 13, 18, -10 },
+ { 13, 19, -10 }, { 13, 20, -12 }, { 15, 21, -12 },
+ { 21, 23, -12 }
+ }
+ }
+ },
{
.bpp = DSC_BPP(12), .bpc = 8,
{ 341, 15, 2048, 3, 12, 11, 11, {
@@ -391,6 +432,37 @@ static const struct rc_parameters_data
rc_parameters_pre_scr[] = {
}
}
},
+ {
+ .bpp = DSC_BPP(15), .bpc = 8,
+ { 273, 15, 2048, 3, 12, 11, 11, {
+ { 0, 0, 10 }, { 0, 1, 8 }, { 0, 1, 6 }, { 0, 2, 4 },
+ { 1, 2, 2 }, { 1, 3, 0 }, { 1, 4, -2 }, { 2, 4, -4 },
+ { 3, 4, -6 }, { 3, 5, -8 }, { 4, 6, -10 }, { 5, 7, -10
},
+ { 5, 8, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(15), .bpc = 10,
+ { 273, 15, 2048, 7, 16, 15, 15, {
+ { 0, 2, 10 }, { 2, 5, 8 }, { 3, 5, 6 }, { 4, 6, 4 },
+ { 5, 6, 2 }, { 5, 7, 0 }, { 5, 8, -2 }, { 6, 8, -4 },
+ { 7, 8, -6 }, { 7, 9, -8 }, { 8, 10, -10 }, { 9, 11,
-10 },
+ { 9, 12, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(15), .bpc = 12,
+ { 273, 15, 2048, 11, 20, 19, 19, {
+ { 0, 4, 10 }, { 2, 7, 8 }, { 4, 9, 6 }, { 6, 11, 4 },
+ { 9, 11, 2 }, { 9, 11, 0 }, { 9, 12, -2 }, { 10, 12, -4
},
+ { 11, 12, -6 }, { 11, 13, -8 }, { 12, 14, -10 },
+ { 13, 15, -10 }, { 13, 16, -12 }, { 15, 21, -12 },
+ { 21, 23, -12 }
+ }
+ }
+ },
{ /* sentinel */ }
};
--
2.39.2
[PATCH v5 5/8] drm/display/dsc: use flat array for rc_parameters lookup
Next commits are going to add support for additional RC parameter lookup
tables. These tables are going to use different bpp/bpc combinations,
thus it makes little sense to keep the 2d array for RC parameters.
Switch to using the flat array.
Reviewed-by: Jani Nikula
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 228 +++
1 file changed, 108 insertions(+), 120 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
b/drivers/gpu/drm/display/drm_dsc_helper.c
index 122a292bbc8f..acb93d4116e0 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -305,24 +305,6 @@ void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config
*vdsc_cfg)
}
EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
-enum ROW_INDEX_BPP {
- ROW_INDEX_6BPP = 0,
- ROW_INDEX_8BPP,
- ROW_INDEX_10BPP,
- ROW_INDEX_12BPP,
- ROW_INDEX_15BPP,
- MAX_ROW_INDEX
-};
-
-enum COLUMN_INDEX_BPC {
- COLUMN_INDEX_8BPC = 0,
- COLUMN_INDEX_10BPC,
- COLUMN_INDEX_12BPC,
- COLUMN_INDEX_14BPC,
- COLUMN_INDEX_16BPC,
- MAX_COLUMN_INDEX
-};
-
struct rc_parameters {
u16 initial_xmit_delay;
u8 first_line_bpg_offset;
@@ -334,21 +316,31 @@ struct rc_parameters {
struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
};
+struct rc_parameters_data {
+ u8 bpp;
+ u8 bpc;
+ struct rc_parameters params;
+};
+
+#define DSC_BPP(bpp) ((bpp) << 4)
+
/*
* Selected Rate Control Related Parameter Recommended Values
* from DSC_v1.11 spec & C Model release: DSC_model_20161212
*/
-static const struct rc_parameters rc_parameters[][MAX_COLUMN_INDEX] = {
+static const struct rc_parameters_data rc_parameters[] = {
{
- /* 6BPP/8BPC */
+ .bpp = DSC_BPP(6), .bpc = 8,
{ 768, 15, 6144, 3, 13, 11, 11, {
{ 0, 4, 0 }, { 1, 6, -2 }, { 3, 8, -2 }, { 4, 8, -4 },
{ 5, 9, -6 }, { 5, 9, -6 }, { 6, 9, -6 }, { 6, 10, -8 },
{ 7, 11, -8 }, { 8, 12, -10 }, { 9, 12, -10 }, { 10,
12, -12 },
{ 10, 12, -12 }, { 11, 12, -12 }, { 13, 14, -12 }
}
- },
- /* 6BPP/10BPC */
+ }
+ },
+ {
+ .bpp = DSC_BPP(6), .bpc = 10,
{ 768, 15, 6144, 7, 17, 15, 15, {
{ 0, 8, 0 }, { 3, 10, -2 }, { 7, 12, -2 }, { 8, 12, -4
},
{ 9, 13, -6 }, { 9, 13, -6 }, { 10, 13, -6 }, { 10, 14,
-8 },
@@ -356,8 +348,10 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 14, 16, -12 }, { 14, 16, -12 }, { 15, 16, -12 },
{ 17, 18, -12 }
}
- },
- /* 6BPP/12BPC */
+ }
+ },
+ {
+ .bpp = DSC_BPP(6), .bpc = 12,
{ 768, 15, 6144, 11, 21, 19, 19, {
{ 0, 12, 0 }, { 5, 14, -2 }, { 11, 16, -2 }, { 12, 16,
-4 },
{ 13, 17, -6 }, { 13, 17, -6 }, { 14, 17, -6 }, { 14,
18, -8 },
@@ -365,8 +359,10 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 18, 20, -12 }, { 18, 20, -12 }, { 19, 20, -12 },
{ 21, 22, -12 }
}
- },
- /* 6BPP/14BPC */
+ }
+ },
+ {
+ .bpp = DSC_BPP(6), .bpc = 14,
{ 768, 15, 6144, 15, 25, 23, 23, {
{ 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20,
-4 },
{ 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18,
22, -8 },
@@ -374,8 +370,10 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 22, 24, -12 }, { 22, 24, -12 }, { 23, 24, -12 },
{ 25, 26, -12 }
}
- },
- /* 6BPP/16BPC */
+ }
+ },
+ {
+ .bpp = DSC_BPP(6), .bpc = 16,
{ 768, 15, 6144, 19, 29, 27, 27, {
{ 0, 20, 0 }, { 9, 22, -2 }, { 19, 24, -2 }, { 20, 24,
-4 },
{ 21, 25, -6 }, { 21, 25, -6 }, { 22, 25, -6 }, { 22,
26, -8 },
@@ -383,18 +381,20 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 26, 28, -12 }, { 26, 28, -12 }, { 27, 28, -12 },
{ 29, 30, -12 }
}
- },
+ }
},
{
- /* 8BPP/8BPC */
+ .bpp = DSC_BPP(8), .bpc = 8,
{ 512, 12, 6144, 3, 12, 11, 11, {
{ 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
{ 3, 7, -4 }, { 3, 7, -6 }, { 3,
[PATCH v5 6/8] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters
The array of rc_parameters contains a mixture of parameters from DSC 1.1
and DSC 1.2 standards. Split these tow configuration arrays in
preparation to adding more configuration data.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 127 ++
drivers/gpu/drm/i915/display/intel_vdsc.c | 10 +-
include/drm/display/drm_dsc_helper.h | 7 +-
3 files changed, 119 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
b/drivers/gpu/drm/display/drm_dsc_helper.c
index acb93d4116e0..35b39f3109c4 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -324,11 +324,81 @@ struct rc_parameters_data {
#define DSC_BPP(bpp) ((bpp) << 4)
+static const struct rc_parameters_data rc_parameters_pre_scr[] = {
+ {
+ .bpp = DSC_BPP(8), .bpc = 8,
+ { 512, 12, 6144, 3, 12, 11, 11, {
+ { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+ { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+ { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12,
-12 },
+ { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(8), .bpc = 10,
+ { 512, 12, 6144, 7, 16, 15, 15, {
+ /*
+* DSC model/pre-SCR-cfg has 8 for range_max_qp[0],
however
+* VESA DSC 1.1 Table E-5 sets it to 4.
+*/
+ { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
+ { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12,
-8 },
+ { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16,
-12 },
+ { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(8), .bpc = 12,
+ { 512, 12, 6144, 11, 20, 19, 19, {
+ { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
+ { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11,
16, -8 },
+ { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
+ { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
+ { 21, 23, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(12), .bpc = 8,
+ { 341, 15, 2048, 3, 12, 11, 11, {
+ { 0, 2, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+ { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+ { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 },
+ { 5, 12, -12 }, { 5, 13, -12 }, { 7, 13, -12 }, { 13,
15, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(12), .bpc = 10,
+ { 341, 15, 2048, 7, 16, 15, 15, {
+ { 0, 2, 2 }, { 2, 5, 0 }, { 3, 7, 0 }, { 4, 8, -2 },
+ { 6, 9, -4 }, { 7, 10, -6 }, { 7, 11, -8 }, { 7, 12, -8
},
+ { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16,
-12 },
+ { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+ }
+ }
+ },
+ {
+ .bpp = DSC_BPP(12), .bpc = 12,
+ { 341, 15, 2048, 11, 20, 19, 19, {
+ { 0, 6, 2 }, { 4, 9, 0 }, { 7, 11, 0 }, { 8, 12, -2 },
+ { 10, 13, -4 }, { 11, 14, -6 }, { 11, 15, -8 }, { 11,
16, -8 },
+ { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
+ { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
+ { 21, 23, -12 }
+ }
+ }
+ },
+ { /* sentinel */ }
+};
+
/*
* Selected Rate Control Related Parameter Recommended Values
* from DSC_v1.11 spec & C Model release: DSC_model_20161212
*/
-static const struct rc_parameters_data rc_parameters[] = {
+static const struct rc_parameters_data rc_parameters_1_2_444[] = {
{
.bpp = DSC_BPP(6), .bpc = 8,
{ 768, 15, 6144, 3, 13, 11, 11, {
@@ -388,22 +458,18 @@ static const struct rc_parameters_data rc_parameters[] = {
{ 512, 12, 6144, 3, 12, 11, 11, {
{ 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
{ 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
- { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12,
-12 },
- { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+ { 3, 9, -8 }, { 3, 10, -10 }, { 5, 10, -10 }, { 5, 11,
-12 },
+ { 5, 11, -12 }, { 9, 12, -12 },
[PATCH v5 4/8] drm/i915/dsc: stop using interim structure for calculated params
Stop using an interim structure rc_parameters for storing calculated
params and then setting drm_dsc_config using that structure. Instead put
calculated params into the struct drm_dsc_config directly.
Reviewed-by: Jani Nikula
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 100 ++
1 file changed, 26 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index d0536582e4b9..d4340b18c18d 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -19,17 +19,6 @@
#include "intel_vdsc.h"
#include "intel_vdsc_regs.h"
-struct rc_parameters {
- u16 initial_xmit_delay;
- u8 first_line_bpg_offset;
- u16 initial_offset;
- u8 flatness_min_qp;
- u8 flatness_max_qp;
- u8 rc_quant_incr_limit0;
- u8 rc_quant_incr_limit1;
- struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
-};
-
bool intel_dsc_source_support(const struct intel_crtc_state *crtc_state)
{
const struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -64,8 +53,7 @@ static bool is_pipe_dsc(struct intel_crtc *crtc, enum
transcoder cpu_transcoder)
}
static void
-calculate_rc_params(struct rc_parameters *rc,
- struct drm_dsc_config *vdsc_cfg)
+calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
{
int bpc = vdsc_cfg->bits_per_component;
int bpp = vdsc_cfg->bits_per_pixel >> 4;
@@ -85,56 +73,57 @@ calculate_rc_params(struct rc_parameters *rc,
u32 res, buf_i, bpp_i;
if (vdsc_cfg->slice_height >= 8)
- rc->first_line_bpg_offset =
+ vdsc_cfg->first_line_bpg_offset =
12 + DIV_ROUND_UP((9 * min(34, vdsc_cfg->slice_height -
8)), 100);
else
- rc->first_line_bpg_offset = 2 * (vdsc_cfg->slice_height - 1);
+ vdsc_cfg->first_line_bpg_offset = 2 * (vdsc_cfg->slice_height -
1);
/* Our hw supports only 444 modes as of today */
if (bpp >= 12)
- rc->initial_offset = 2048;
+ vdsc_cfg->initial_offset = 2048;
else if (bpp >= 10)
- rc->initial_offset = 5632 - DIV_ROUND_UP(((bpp - 10) * 3584),
2);
+ vdsc_cfg->initial_offset = 5632 - DIV_ROUND_UP(((bpp - 10) *
3584), 2);
else if (bpp >= 8)
- rc->initial_offset = 6144 - DIV_ROUND_UP(((bpp - 8) * 512), 2);
+ vdsc_cfg->initial_offset = 6144 - DIV_ROUND_UP(((bpp - 8) *
512), 2);
else
- rc->initial_offset = 6144;
+ vdsc_cfg->initial_offset = 6144;
/* initial_xmit_delay = rc_model_size/2/compression_bpp */
- rc->initial_xmit_delay = DIV_ROUND_UP(DSC_RC_MODEL_SIZE_CONST, 2 * bpp);
+ vdsc_cfg->initial_xmit_delay = DIV_ROUND_UP(DSC_RC_MODEL_SIZE_CONST, 2
* bpp);
- rc->flatness_min_qp = 3 + qp_bpc_modifier;
- rc->flatness_max_qp = 12 + qp_bpc_modifier;
+ vdsc_cfg->flatness_min_qp = 3 + qp_bpc_modifier;
+ vdsc_cfg->flatness_max_qp = 12 + qp_bpc_modifier;
- rc->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
- rc->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
+ vdsc_cfg->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
+ vdsc_cfg->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
bpp_i = (2 * (bpp - 6));
for (buf_i = 0; buf_i < DSC_NUM_BUF_RANGES; buf_i++) {
+ u8 range_bpg_offset;
+
/* Read range_minqp and range_max_qp from qp tables */
- rc->rc_range_params[buf_i].range_min_qp =
+ vdsc_cfg->rc_range_params[buf_i].range_min_qp =
intel_lookup_range_min_qp(bpc, buf_i, bpp_i,
vdsc_cfg->native_420);
- rc->rc_range_params[buf_i].range_max_qp =
+ vdsc_cfg->rc_range_params[buf_i].range_max_qp =
intel_lookup_range_max_qp(bpc, buf_i, bpp_i,
vdsc_cfg->native_420);
- /* Calculate range_bgp_offset */
+ /* Calculate range_bpg_offset */
if (bpp <= 6) {
- rc->rc_range_params[buf_i].range_bpg_offset =
ofs_und6[buf_i];
+ range_bpg_offset = ofs_und6[buf_i];
} else if (bpp <= 8) {
res = DIV_ROUND_UP(((bpp - 6) * (ofs_und8[buf_i] -
ofs_und6[buf_i])), 2);
- rc->rc_range_params[buf_i].range_bpg_offset =
- ofs_und6[buf_i]
+ res;
+ range_bpg_offset = ofs_und6[buf_i] + res;
} else if (bpp <= 12) {
- rc->rc_range_params[buf_i].range_bpg_offset =
- ofs_und8[buf_i];
+ range_bpg_offset = ofs_und8[buf_i];
} else if (bpp <= 15)
[PATCH v5 3/8] drm/i915/dsc: move DSC tables to DRM DSC helper
Move DSC RC tables to DRM DSC helper. No additional code changes
and/or cleanups are a part of this commit, it will be cleaned up in the
followup commits.
Reviewed-by: Jani Nikula
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 372 ++
drivers/gpu/drm/i915/display/intel_vdsc.c | 319 +--
include/drm/display/drm_dsc_helper.h | 1 +
3 files changed, 380 insertions(+), 312 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
b/drivers/gpu/drm/display/drm_dsc_helper.c
index be91abe2cfb2..122a292bbc8f 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -305,6 +305,378 @@ void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config
*vdsc_cfg)
}
EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
+enum ROW_INDEX_BPP {
+ ROW_INDEX_6BPP = 0,
+ ROW_INDEX_8BPP,
+ ROW_INDEX_10BPP,
+ ROW_INDEX_12BPP,
+ ROW_INDEX_15BPP,
+ MAX_ROW_INDEX
+};
+
+enum COLUMN_INDEX_BPC {
+ COLUMN_INDEX_8BPC = 0,
+ COLUMN_INDEX_10BPC,
+ COLUMN_INDEX_12BPC,
+ COLUMN_INDEX_14BPC,
+ COLUMN_INDEX_16BPC,
+ MAX_COLUMN_INDEX
+};
+
+struct rc_parameters {
+ u16 initial_xmit_delay;
+ u8 first_line_bpg_offset;
+ u16 initial_offset;
+ u8 flatness_min_qp;
+ u8 flatness_max_qp;
+ u8 rc_quant_incr_limit0;
+ u8 rc_quant_incr_limit1;
+ struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
+};
+
+/*
+ * Selected Rate Control Related Parameter Recommended Values
+ * from DSC_v1.11 spec & C Model release: DSC_model_20161212
+ */
+static const struct rc_parameters rc_parameters[][MAX_COLUMN_INDEX] = {
+ {
+ /* 6BPP/8BPC */
+ { 768, 15, 6144, 3, 13, 11, 11, {
+ { 0, 4, 0 }, { 1, 6, -2 }, { 3, 8, -2 }, { 4, 8, -4 },
+ { 5, 9, -6 }, { 5, 9, -6 }, { 6, 9, -6 }, { 6, 10, -8 },
+ { 7, 11, -8 }, { 8, 12, -10 }, { 9, 12, -10 }, { 10,
12, -12 },
+ { 10, 12, -12 }, { 11, 12, -12 }, { 13, 14, -12 }
+ }
+ },
+ /* 6BPP/10BPC */
+ { 768, 15, 6144, 7, 17, 15, 15, {
+ { 0, 8, 0 }, { 3, 10, -2 }, { 7, 12, -2 }, { 8, 12, -4
},
+ { 9, 13, -6 }, { 9, 13, -6 }, { 10, 13, -6 }, { 10, 14,
-8 },
+ { 11, 15, -8 }, { 12, 16, -10 }, { 13, 16, -10 },
+ { 14, 16, -12 }, { 14, 16, -12 }, { 15, 16, -12 },
+ { 17, 18, -12 }
+ }
+ },
+ /* 6BPP/12BPC */
+ { 768, 15, 6144, 11, 21, 19, 19, {
+ { 0, 12, 0 }, { 5, 14, -2 }, { 11, 16, -2 }, { 12, 16,
-4 },
+ { 13, 17, -6 }, { 13, 17, -6 }, { 14, 17, -6 }, { 14,
18, -8 },
+ { 15, 19, -8 }, { 16, 20, -10 }, { 17, 20, -10 },
+ { 18, 20, -12 }, { 18, 20, -12 }, { 19, 20, -12 },
+ { 21, 22, -12 }
+ }
+ },
+ /* 6BPP/14BPC */
+ { 768, 15, 6144, 15, 25, 23, 23, {
+ { 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20,
-4 },
+ { 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18,
22, -8 },
+ { 19, 23, -8 }, { 20, 24, -10 }, { 21, 24, -10 },
+ { 22, 24, -12 }, { 22, 24, -12 }, { 23, 24, -12 },
+ { 25, 26, -12 }
+ }
+ },
+ /* 6BPP/16BPC */
+ { 768, 15, 6144, 19, 29, 27, 27, {
+ { 0, 20, 0 }, { 9, 22, -2 }, { 19, 24, -2 }, { 20, 24,
-4 },
+ { 21, 25, -6 }, { 21, 25, -6 }, { 22, 25, -6 }, { 22,
26, -8 },
+ { 23, 27, -8 }, { 24, 28, -10 }, { 25, 28, -10 },
+ { 26, 28, -12 }, { 26, 28, -12 }, { 27, 28, -12 },
+ { 29, 30, -12 }
+ }
+ },
+ },
+ {
+ /* 8BPP/8BPC */
+ { 512, 12, 6144, 3, 12, 11, 11, {
+ { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+ { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+ { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12,
-12 },
+ { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+ }
+ },
+ /* 8BPP/10BPC */
+ { 512, 12, 6144, 7, 16, 15, 15, {
+ /*
+* DSC model/pre-SCR-cfg has 8 for range_max_qp[0],
however
+* VESA DSC 1.1 Table E-5 sets it to 4.
+*/
+ { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
+
[PATCH v5 2/8] drm/i915/dsc: move rc_buf_thresh values to common helper
The rc_buf_thresh values are common to all DSC implementations. Move
them to the common helper together with the code to propagage them to
the drm_dsc_config.
Reviewed-by: Jani Nikula
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 35 +++
drivers/gpu/drm/i915/display/intel_vdsc.c | 24 +---
include/drm/display/drm_dsc_helper.h | 1 +
3 files changed, 37 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
b/drivers/gpu/drm/display/drm_dsc_helper.c
index c869c6e51e2b..be91abe2cfb2 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -270,6 +270,41 @@ void drm_dsc_pps_payload_pack(struct
drm_dsc_picture_parameter_set *pps_payload,
}
EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
+/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
+static const u16 drm_dsc_rc_buf_thresh[] = {
+ 896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
+ 7744, 7872, 8000, 8064
+};
+
+/**
+ * drm_dsc_set_rc_buf_thresh() - Set thresholds for the RC model
+ * in accordance with the DSC 1.2 specification.
+ *
+ * @vdsc_cfg: DSC Configuration data partially filled by driver
+ */
+void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg)
+{
+ int i;
+
+ BUILD_BUG_ON(ARRAY_SIZE(drm_dsc_rc_buf_thresh) !=
+DSC_NUM_BUF_RANGES - 1);
+ BUILD_BUG_ON(ARRAY_SIZE(drm_dsc_rc_buf_thresh) !=
+ARRAY_SIZE(vdsc_cfg->rc_buf_thresh));
+
+ for (i = 0; i < ARRAY_SIZE(drm_dsc_rc_buf_thresh); i++)
+ vdsc_cfg->rc_buf_thresh[i] = drm_dsc_rc_buf_thresh[i] >> 6;
+
+ /*
+* For 6bpp, RC Buffer threshold 12 and 13 need a different value
+* as per C Model
+*/
+ if (vdsc_cfg->bits_per_pixel == 6 << 4) {
+ vdsc_cfg->rc_buf_thresh[12] = 7936 >> 6;
+ vdsc_cfg->rc_buf_thresh[13] = 8000 >> 6;
+ }
+}
+EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
+
/**
* drm_dsc_compute_rc_parameters() - Write rate control
* parameters to the dsc configuration defined in
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 7003ae9f683a..2fd08375bbe3 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -37,12 +37,6 @@ enum COLUMN_INDEX_BPC {
MAX_COLUMN_INDEX
};
-/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
-static const u16 rc_buf_thresh[] = {
- 896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
- 7744, 7872, 8000, 8064
-};
-
struct rc_parameters {
u16 initial_xmit_delay;
u8 first_line_bpg_offset;
@@ -543,23 +537,7 @@ int intel_dsc_compute_params(struct intel_crtc_state
*pipe_config)
vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
- for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
- /*
-* six 0s are appended to the lsb of each threshold value
-* internally in h/w.
-* Only 8 bits are allowed for programming RcBufThreshold
-*/
- vdsc_cfg->rc_buf_thresh[i] = rc_buf_thresh[i] >> 6;
- }
-
- /*
-* For 6bpp, RC Buffer threshold 12 and 13 need a different value
-* as per C Model
-*/
- if (compressed_bpp == 6) {
- vdsc_cfg->rc_buf_thresh[12] = 0x7C;
- vdsc_cfg->rc_buf_thresh[13] = 0x7D;
- }
+ drm_dsc_set_rc_buf_thresh(vdsc_cfg);
/*
* From XE_LPD onwards we supports compression bpps in steps of 1
diff --git a/include/drm/display/drm_dsc_helper.h
b/include/drm/display/drm_dsc_helper.h
index 8b41edbbabab..706ba1d34742 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -14,6 +14,7 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header
*pps_header);
int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
const struct drm_dsc_config *dsc_cfg);
+void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
#endif /* _DRM_DSC_HELPER_H_ */
--
2.39.2
[PATCH v5 1/8] drm/i915/dsc: change DSC param tables to follow the DSC model
After cross-checking DSC models (20150914, 20161212, 20210623) change
values in rc_parameters tables to follow config files present inside
the DSC model. Handle two places, where i915 tables diverged from the
model, by patching the rc values in the code.
Note: I left one case uncorrected, 8bpp/10bpc/range_max_qp[0], because
the table in the VESA DSC 1.1 sets it to 4.
Reviewed-by: Jani Nikula
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 8e787c13d26d..7003ae9f683a 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -87,7 +87,7 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
}
},
/* 6BPP/14BPC */
- { 768, 15, 6144, 15, 25, 23, 27, {
+ { 768, 15, 6144, 15, 25, 23, 23, {
{ 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, -4 },
{ 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18, 22, -8 },
{ 19, 23, -8 }, { 20, 24, -10 }, { 21, 24, -10 },
@@ -116,6 +116,10 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
},
/* 8BPP/10BPC */
{ 512, 12, 6144, 7, 16, 15, 15, {
+ /*
+* DSC model/pre-SCR-cfg has 8 for range_max_qp[0], however
+* VESA DSC 1.1 Table E-5 sets it to 4.
+*/
{ 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
{ 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
{ 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, -12 },
@@ -133,7 +137,7 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
},
/* 8BPP/14BPC */
{ 512, 12, 6144, 15, 24, 23, 23, {
- { 0, 12, 0 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 },
+ { 0, 12, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 },
{ 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15, 20, -8 },
{ 15, 21, -8 }, { 15, 22, -10 }, { 17, 22, -10 },
{ 17, 23, -12 }, { 17, 23, -12 }, { 21, 24, -12 },
@@ -598,6 +602,20 @@ int intel_dsc_compute_params(struct intel_crtc_state
*pipe_config)
DSC_RANGE_BPG_OFFSET_MASK;
}
+ if (DISPLAY_VER(dev_priv) < 13) {
+ /*
+* FIXME: verify that the hardware actually needs these
+* modifications rather than them being simple typos.
+*/
+ if (compressed_bpp == 6 &&
+ vdsc_cfg->bits_per_component == 8)
+ vdsc_cfg->rc_quant_incr_limit1 = 23;
+
+ if (compressed_bpp == 8 &&
+ vdsc_cfg->bits_per_component == 14)
+ vdsc_cfg->rc_range_params[0].range_bpg_offset = 0;
+ }
+
/*
* BitsPerComponent value determines mux_word_size:
* When BitsPerComponent is less than or 10bpc, muxWordSize will be
equal to
--
2.39.2
[PATCH v5 0/8] drm/i915: move DSC RC tables to drm_dsc_helper.c
Other platforms (msm) will benefit from sharing the DSC config setup functions. This series moves parts of static DSC config data from the i915 driver to the common helpers to be used by other drivers. Note: the RC parameters were cross-checked against config files found in DSC model 2021062, 20161212 (and 20150914). The first patch modifies tables according to those config files, while preserving parameter values using the code. I have not changed one of the values in the pre-SCR config file as it clearly looks like a typo in the config file, considering the table E in DSC 1.1 and in the DSC 1.1 SCR. Chances since v4: - Rebased on top of drm-intel-next - Cut the first 8 patches of the series to ease merging. The rest of the patches will go afterwards. Chances since v3: - Rebased on top of drm-intel-next - Dropped the msm patch to make patchset fully mergeable through drm-intel - Made drm_dsc_set_const_params() ignore rc_model_size, picked up drm_dsc_set_initial_scale_value() patch by Jessica and switched intel_vdsc.c to use those two helpers. - Added a patch to make i915 actually use rc_tgt_offset_high, rc_tgt_offset_low and rc_edge_factor from struct drm_dsc_config. Chances since v2: - Rebased on top of drm-intel-next Chances since v1: - Made drm_dsc_rc_buf_thresh static rather than exporting it - Switched drm_dsc_rc_buf_thresh loop to use ARRAY_SIZE. Added BUILD_BUG_ON's to be sure that array sizes are correct - Fixed rc_parameters_data indentation to be logical and tidy - Fixed drm_dsc_setup_rc_params() kerneldoc - Added a clause to drm_dsc_setup_rc_params() to verify bpp and bpc being set. - Fixed range_bpg_offset programming in calculate_rc_params() - Fixed bpp vs bpc bug in intel_dsc_compute_params() - Added FIXME comment next to the customizations in intel_dsc_compute_params(). Dmitry Baryshkov (8): drm/i915/dsc: change DSC param tables to follow the DSC model drm/i915/dsc: move rc_buf_thresh values to common helper drm/i915/dsc: move DSC tables to DRM DSC helper drm/i915/dsc: stop using interim structure for calculated params drm/display/dsc: use flat array for rc_parameters lookup drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters drm/display/dsc: include the rest of pre-SCR parameters drm/display/dsc: add YCbCr 4:2:2 and 4:2:0 RC parameters drivers/gpu/drm/display/drm_dsc_helper.c | 986 ++ drivers/gpu/drm/i915/display/intel_vdsc.c | 443 ++ include/drm/display/drm_dsc_helper.h | 9 + 3 files changed, 1042 insertions(+), 396 deletions(-) -- 2.39.2
[RFC] Plane color pipeline KMS uAPI
Hi all,
The goal of this RFC is to expose a generic KMS uAPI to configure the color
pipeline before blending, ie. after a pixel is tapped from a plane's
framebuffer and before it's blended with other planes. With this new uAPI we
aim to reduce the battery life impact of color management and HDR on mobile
devices, to improve performance and to decrease latency by skipping
composition on the 3D engine. This proposal is the result of discussions at
the Red Hat HDR hackfest [1] which took place a few days ago. Engineers
familiar with the AMD, Intel and NVIDIA hardware have participated in the
discussion.
This proposal takes a prescriptive approach instead of a descriptive approach.
Drivers describe the available hardware blocks in terms of low-level
mathematical operations, then user-space configures each block. We decided
against a descriptive approach where user-space would provide a high-level
description of the colorspace and other parameters: we want to give more
control and flexibility to user-space, e.g. to be able to replicate exactly the
color pipeline with shaders and switch between shaders and KMS pipelines
seamlessly, and to avoid forcing user-space into a particular color management
policy.
We've decided against mirroring the existing CRTC properties
DEGAMMA_LUT/CTM/GAMMA_LUT onto KMS planes. Indeed, the color management
pipeline can significantly differ between vendors and this approach cannot
accurately abstract all hardware. In particular, the availability, ordering and
capabilities of hardware blocks is different on each display engine. So, we've
decided to go for a highly detailed hardware capability discovery.
This new uAPI should not be in conflict with existing standard KMS properties,
since there are none which control the pre-blending color pipeline at the
moment. It does conflict with any vendor-specific properties like
NV_INPUT_COLORSPACE or the patches on the mailing list adding AMD-specific
properties. Drivers will need to either reject atomic commits configuring both
uAPIs, or alternatively we could add a DRM client cap which hides the vendor
properties and shows the new generic properties when enabled.
To use this uAPI, first user-space needs to discover hardware capabilities via
KMS objects and properties, then user-space can configure the hardware via an
atomic commit. This works similarly to the existing KMS uAPI, e.g. planes.
Our proposal introduces a new "color_pipeline" plane property, and a new KMS
object type, "COLOROP" (short for color operation). The "color_pipeline" plane
property is an enum, each enum entry represents a color pipeline supported by
the hardware. The special zero entry indicates that the pipeline is in
"bypass"/"no-op" mode. For instance, the following plane properties describe a
primary plane with 2 supported pipelines but currently configured in bypass
mode:
Plane 10
├─ "type": immutable enum {Overlay, Primary, Cursor} = Primary
├─ …
└─ "color_pipeline": enum {0, 42, 52} = 0
The non-zero entries describe color pipelines as a linked list of COLOROP KMS
objects. The entry value is an object ID pointing to the head of the linked
list (the first operation in the color pipeline).
The new COLOROP objects also expose a number of KMS properties. Each has a
type, a reference to the next COLOROP object in the linked list, and other
type-specific properties. Here is an example for a 1D LUT operation:
Color operation 42
├─ "type": enum {Bypass, 1D curve} = 1D curve
├─ "1d_curve_type": enum {LUT, sRGB, PQ, BT.709, HLG, …} = LUT
├─ "lut_size": immutable range = 4096
├─ "lut_data": blob
└─ "next": immutable color operation ID = 43
To configure this hardware block, user-space can fill a KMS blob with 4096 u32
entries, then set "lut_data" to the blob ID. Other color operation types might
have different properties.
Here is another example with a 3D LUT:
Color operation 42
├─ "type": enum {Bypass, 3D LUT} = 3D LUT
├─ "lut_size": immutable range = 33
├─ "lut_data": blob
└─ "next": immutable color operation ID = 43
And one last example with a matrix:
Color operation 42
├─ "type": enum {Bypass, Matrix} = Matrix
├─ "matrix_data": blob
└─ "next": immutable color operation ID = 43
[Simon note: having "Bypass" in the "type" enum, and making "type" mutable is
a bit weird. Maybe we can just add an "active"/"bypass" boolean property on
blocks which can be bypassed instead.]
[Jonas note: perhaps a single "data" property for both LUTs and matrices
would make more sense. And a "size" prop for both 1D and 3D LUTs.]
If some hardware supports re-ordering operations in the color pipeline, the
driver can expose multiple pipelines with different operation ordering, and
user-space can pick the ordering it prefers by selecting the right pipeline.
The same scheme can be used to expose hardware blocks supporting multiple
precision levels.
That's pretty much all there is to it, but as always the devil
Re: [PATCH v3 14/65] clk: lochnagar: Add a determine_rate hook
On Tue, Apr 04, 2023 at 12:11:04PM +0200, Maxime Ripard wrote: > The lochnagar clocks implement a mux with a set_parent hook, but > doesn't provide a determine_rate implementation. > > This is a bit odd, since set_parent() is there to, as its name implies, > change the parent of a clock. However, the most likely candidate to > trigger that parent change is a call to clk_set_rate(), with > determine_rate() figuring out which parent is the best suited for a > given rate. > > The other trigger would be a call to clk_set_parent(), but it's far less > used, and it doesn't look like there's any obvious user for that clock. > > So, the set_parent hook is effectively unused, possibly because of an > oversight. However, it could also be an explicit decision by the > original author to avoid any reparenting but through an explicit call to > clk_set_parent(). > > The latter case would be equivalent to setting the flag > CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook > to __clk_mux_determine_rate(). Indeed, if no determine_rate > implementation is provided, clk_round_rate() (through > clk_core_round_rate_nolock()) will call itself on the parent if > CLK_SET_RATE_PARENT is set, and will not change the clock rate > otherwise. __clk_mux_determine_rate() has the exact same behavior when > CLK_SET_RATE_NO_REPARENT is set. > > And if it was an oversight, then we are at least explicit about our > behavior now and it can be further refined down the line. > > Signed-off-by: Maxime Ripard > --- Tested-by: Charles Keepax Thanks, Charles
Re: [PATCH 01/13] drm: execution context for GEM buffers v4
On 5/4/23 13:51, Christian König wrote:
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existing TTMs execbuf util and intended to replace
it in the long term.
The basic functionality is that we abstracts the necessary loop to lock
many different GEM buffers with automated deadlock and duplicate handling.
v2: drop xarray and use dynamic resized array instead, the locking
overhead is unecessary and measurable.
v3: drop duplicate tracking, radeon is really the only one needing that.
v4: fixes issues pointed out by Danilo, some typos in comments and a
helper for lock arrays of GEM objects.
Signed-off-by: Christian König
...
+/**
+ * struct drm_exec - Execution context
+ */
+struct drm_exec {
+ /**
+* @interruptible: If locks should be taken interruptible
+*/
+ boolinterruptible;
+
+ /**
+* @ticket: WW ticket used for acquiring locks
+*/
+ struct ww_acquire_ctx ticket;
+
+ /**
+* @num_objects: number of objects locked
+*/
+ unsigned intnum_objects;
+
+ /**
+* @max_objects: maximum objects in array
+*/
+ unsigned intmax_objects;
+
+ /**
+* @objects: array of the locked objects
+*/
+ struct drm_gem_object **objects;
Hi, Christian. Did you consider using a list here with links embedded in
gem objects, now that only locked objects are to be put on the list / array.
That should work as only the process owning the lock may access the list
link. Apart from getting rid of reallocing this is beneficial for the
more general types of ww transactions that are used by i915 (and to a
minor extent xe as well, I think).
In those cases we would want to unlock a temporary held object within
the while_not_all_locked() loop and would then have to search the entire
array for the correct pointer. Instead one could just remove it from the
list of locked objects.
Thanks,
Thomas
Re: [PATCH V3 3/7] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically
On Thu, May 4, 2023 at 8:18 AM Alexander Stein
wrote:
>
> Am Donnerstag, 4. Mai 2023, 14:57:01 CEST schrieb Adam Ford:
> > On Thu, May 4, 2023 at 7:40 AM Alexander Stein
> >
> > wrote:
> > > Hi Adam,
> > >
> > > Am Donnerstag, 4. Mai 2023, 14:00:08 CEST schrieb Adam Ford:
> > > > On Thu, May 4, 2023 at 4:21 AM Alexander Stein
> > > >
> > > > wrote:
> > > > > Am Dienstag, 2. Mai 2023, 03:07:55 CEST schrieb Adam Ford:
> > > > > > Make the pll-clock-frequency optional. If it's present, use it
> > > > > > to maintain backwards compatibility with existing hardware. If it
> > > > > > is absent, read clock rate of "sclk_mipi" to determine the rate.
> > > > > >
> > > > > > Signed-off-by: Adam Ford
> > > > > > Tested-by: Chen-Yu Tsai
> > > > > > ---
> > > > > >
> > > > > > drivers/gpu/drm/bridge/samsung-dsim.c | 12 ++--
> > > > > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> > > > > > b/drivers/gpu/drm/bridge/samsung-dsim.c index
> > > > > > bf4b33d2de76..2dc02a9e37c0
> > > > > > 100644
> > > > > > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > > > > > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > > > > > @@ -1726,12 +1726,20 @@ static int samsung_dsim_parse_dt(struct
> > > > > > samsung_dsim *dsi) {
> > > > > >
> > > > > > struct device *dev = dsi->dev;
> > > > > > struct device_node *node = dev->of_node;
> > > > > >
> > > > > > + struct clk *pll_clk;
> > > > > >
> > > > > > int ret;
> > > > > >
> > > > > > ret = samsung_dsim_of_read_u32(node,
> > > > > > "samsung,pll-clock-frequency",
> > > > > >
> > > > > > >pll_clk_rate);
> > > > > >
> > > > > > - if (ret < 0)
> > > > > > - return ret;
> > > > > > +
> > > > > > + /* If it doesn't exist, read it from the clock instead of
> > > > > > failing
> > > > > > */
> > > > > > + if (ret < 0) {
> > > > > > + pll_clk = devm_clk_get(dev, "sclk_mipi");
> > > > > > + if (!IS_ERR(pll_clk))
> > > > > > + dsi->pll_clk_rate = clk_get_rate(pll_clk);
> > > > > > + else
> > > > > > + return PTR_ERR(pll_clk);
> > > > > > + }
> > > > >
> > > > > Now that 'samsung,pll-clock-frequency' is optional the error in
> > > > > samsung_dsim_of_read_u32() should be changed. Otherwise you will get
> > > > >
> > > > > > /soc@0/bus@32c0/dsi@32e1: failed to get 'samsung,pll-clock-
> > > > >
> > > > > frequency' property
> > > >
> > > > I'll change the message from err to info with a message that reads "no
> > > > samsung,pll-clock-frequency, using pixel clock"
> > > >
> > > > Does that work?
> > >
> > > Having just a info is totally fine with me. Thanks.
> > > Although your suggested message somehow implies (to me) using pixel clock
> > > is just a fallback. I'm a bit concerned some might think
> > > "samsung,pll-clock- frequency" should be provided in DT. But this might
> > > just be me.
> >
> > Oops, I got the PLL and burst burst clock confused. I think both
> > burst-clock and pll clock messages should get updates.
> >
> > The pll clock should say something like "samsung,pll-clock-frequency
> > not defined, using sclk_mipi"
> >
> > The imx8m n/m/p have the sclk_mipi defined in the device tree, and
> > this patch allows them to not have
> > to manually set the pll clock since it can be read. This allows to
> > people to change the frequency of the PLL in
> > in one place and let the driver read it instead of having to set the
> > value in two places for the same clock.
>
> That's why I would like to make it sound less error-like.
> How about "Using sclk_mipi for pll clock frequency"?
>
> > For the burst clock, I'd like to propose
> > "samsung,burst-clock-frequency not defined, using pixel clock"
>
> Similar to above how about "Using pixel clock for burst clock frequency"?
I like that.
>
> > Does that work for you?
>
> But I'm okay with both ways. Up to you.
I'll wait another day or two to see if anyone else has any feedback,
and I'll submit V4 with some other items addressed too.
Thank you for your review!
adam
>
> Thanks and best regards,
> Alexander
>
>
> > > frequency
> > >
> > >
> > > Best regards,
> > > Alexander
> > >
> > > > adam
> > > >
> > > > > Best regards,
> > > > > Alexander
> > > > >
> > > > > > ret = samsung_dsim_of_read_u32(node, "samsung,burst-clock-
> > > > >
> > > > > frequency",
> > > > >
> > > > > > >burst_clk_rate);
> > > > >
> > > > > --
> > > > > TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> > > > > Amtsgericht München, HRB 105018
> > > > > Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> > > > > http://www.tq-group.com/
> > >
> > > --
> > > TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> > > Amtsgericht München, HRB 105018
> > > Geschäftsführer: Detlef Schneider, Rüdiger
Re: [Intel-gfx] [PATCH v4 2/3] drm/i915: use pat_index instead of cache_level
On 03/05/2023 21:39, Yang, Fei wrote:
[...]
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 8c70a0ec7d2f..27c948350b5b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -54,6 +54,25 @@ unsigned int i915_gem_get_pat_index(struct drm_i915_private
*i915,
return INTEL_INFO(i915)->cachelevel_to_pat[level];
}
+bool i915_gem_object_has_cache_level(const struct drm_i915_gem_object *obj,
+ enum i915_cache_level lvl)
+{
+/*
+ * cache_level == I915_CACHE_INVAL indicates the UMD's have set the
+ * caching policy through pat_index, in which case the KMD should
+ * leave the coherency to be managed by user space, simply return
+ * true here.
+ */
+if (obj->cache_level == I915_CACHE_INVAL)
+return true;
+
+/*
+ * Otherwise the pat_index should have been converted from cache_level
+ * so that the following comparison is valid.
+ */
+return obj->pat_index == i915_gem_get_pat_index(obj_to_i915(obj), lvl);
+}
+
struct drm_i915_gem_object *i915_gem_object_alloc(void)
{
struct drm_i915_gem_object *obj;
@@ -133,7 +152,7 @@ void i915_gem_object_set_cache_coherency(struct
drm_i915_gem_object *obj,
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
-obj->cache_level = cache_level;
+obj->pat_index = i915_gem_get_pat_index(i915, cache_level);
obj->cache_level is only ever set to "invalid" from the set pat
extension? Doesn't that make it a boolean so there is no need for three
bits to hold the enum, just the "pat has been externally set" bit really?
Will update.
Thanks!
if (cache_level != I915_CACHE_NONE)
obj->cache_coherent = (I915_BO_CACHE_COHERENT_FOR_READ |
[...]
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 41389a32e998..9a4922da3a71 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -139,21 +139,56 @@ static const char *stringify_vma_type(const struct
i915_vma *vma)
return "ppgtt";
}
-static const char *i915_cache_level_str(struct drm_i915_private *i915, int
type)
-{
-switch (type) {
-case I915_CACHE_NONE: return " uncached";
-case I915_CACHE_LLC: return HAS_LLC(i915) ? " LLC" : " snooped";
-case I915_CACHE_L3_LLC: return " L3+LLC";
-case I915_CACHE_WT: return " WT";
-default: return "";
+static const char *i915_cache_level_str(struct drm_i915_gem_object *obj)
+{
+struct drm_i915_private *i915 = obj_to_i915(obj);
+
+if (IS_METEORLAKE(i915)) {
+switch (obj->pat_index) {
+case 0: return " WB";
+case 1: return " WT";
+case 2: return " UC";
+case 3: return " WB (1-Way Coh)";
+case 4: return " WB (2-Way Coh)";
+default: return " not defined";
+}
+} else if (IS_PONTEVECCHIO(i915)) {
+switch (obj->pat_index) {
+case 0: return " UC";
+case 1: return " WC";
+case 2: return " WT";
+case 3: return " WB";
+case 4: return " WT (CLOS1)";
+case 5: return " WB (CLOS1)";
+case 6: return " WT (CLOS2)";
+case 7: return " WT (CLOS2)";
+default: return " not defined";
+}
+} else if (GRAPHICS_VER(i915) >= 12) {
+switch (obj->pat_index) {
+case 0: return " WB";
+case 1: return " WC";
+case 2: return " WT";
+case 3: return " UC";
+default: return " not defined";
+}
+} else {
+if (i915_gem_object_has_cache_level(obj, I915_CACHE_NONE))
+return " uncached";
This will print uncached for all legacy platforms if set pat extension
has been used, regardless of the index set.
Will update. Should just use obj->pat_index here.
Thanks, it looks better to me in v5.
Are we okay with that? I find it questionable and would say no. It
diverges from >= 12 and so is confusing.
+else if (i915_gem_object_has_cache_level(obj, I915_CACHE_LLC))
+return HAS_LLC(i915) ? " LLC" : " snooped";
+else if (i915_gem_object_has_cache_level(obj, I915_CACHE_L3_LLC))
+return " L3+LLC";
+else if (i915_gem_object_has_cache_level(obj, I915_CACHE_WT))
+return " WT";
+else
+return " not defined";
Another thing is why use different names for caching modes between
"legacy" and the rest?
For new platforms the string matches bspec. For legacy platforms I think it's
still better to inherit the strings, no surprises here. What do you think?
Not 100% sure but I fear confusion from userspace developer point of
view if they have code which uses the set pat extension on all platforms
Re: [PATCH V3 3/7] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically
Am Donnerstag, 4. Mai 2023, 14:57:01 CEST schrieb Adam Ford:
> On Thu, May 4, 2023 at 7:40 AM Alexander Stein
>
> wrote:
> > Hi Adam,
> >
> > Am Donnerstag, 4. Mai 2023, 14:00:08 CEST schrieb Adam Ford:
> > > On Thu, May 4, 2023 at 4:21 AM Alexander Stein
> > >
> > > wrote:
> > > > Am Dienstag, 2. Mai 2023, 03:07:55 CEST schrieb Adam Ford:
> > > > > Make the pll-clock-frequency optional. If it's present, use it
> > > > > to maintain backwards compatibility with existing hardware. If it
> > > > > is absent, read clock rate of "sclk_mipi" to determine the rate.
> > > > >
> > > > > Signed-off-by: Adam Ford
> > > > > Tested-by: Chen-Yu Tsai
> > > > > ---
> > > > >
> > > > > drivers/gpu/drm/bridge/samsung-dsim.c | 12 ++--
> > > > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> > > > > b/drivers/gpu/drm/bridge/samsung-dsim.c index
> > > > > bf4b33d2de76..2dc02a9e37c0
> > > > > 100644
> > > > > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > > > > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > > > > @@ -1726,12 +1726,20 @@ static int samsung_dsim_parse_dt(struct
> > > > > samsung_dsim *dsi) {
> > > > >
> > > > > struct device *dev = dsi->dev;
> > > > > struct device_node *node = dev->of_node;
> > > > >
> > > > > + struct clk *pll_clk;
> > > > >
> > > > > int ret;
> > > > >
> > > > > ret = samsung_dsim_of_read_u32(node,
> > > > > "samsung,pll-clock-frequency",
> > > > >
> > > > > >pll_clk_rate);
> > > > >
> > > > > - if (ret < 0)
> > > > > - return ret;
> > > > > +
> > > > > + /* If it doesn't exist, read it from the clock instead of
> > > > > failing
> > > > > */
> > > > > + if (ret < 0) {
> > > > > + pll_clk = devm_clk_get(dev, "sclk_mipi");
> > > > > + if (!IS_ERR(pll_clk))
> > > > > + dsi->pll_clk_rate = clk_get_rate(pll_clk);
> > > > > + else
> > > > > + return PTR_ERR(pll_clk);
> > > > > + }
> > > >
> > > > Now that 'samsung,pll-clock-frequency' is optional the error in
> > > > samsung_dsim_of_read_u32() should be changed. Otherwise you will get
> > > >
> > > > > /soc@0/bus@32c0/dsi@32e1: failed to get 'samsung,pll-clock-
> > > >
> > > > frequency' property
> > >
> > > I'll change the message from err to info with a message that reads "no
> > > samsung,pll-clock-frequency, using pixel clock"
> > >
> > > Does that work?
> >
> > Having just a info is totally fine with me. Thanks.
> > Although your suggested message somehow implies (to me) using pixel clock
> > is just a fallback. I'm a bit concerned some might think
> > "samsung,pll-clock- frequency" should be provided in DT. But this might
> > just be me.
>
> Oops, I got the PLL and burst burst clock confused. I think both
> burst-clock and pll clock messages should get updates.
>
> The pll clock should say something like "samsung,pll-clock-frequency
> not defined, using sclk_mipi"
>
> The imx8m n/m/p have the sclk_mipi defined in the device tree, and
> this patch allows them to not have
> to manually set the pll clock since it can be read. This allows to
> people to change the frequency of the PLL in
> in one place and let the driver read it instead of having to set the
> value in two places for the same clock.
That's why I would like to make it sound less error-like.
How about "Using sclk_mipi for pll clock frequency"?
> For the burst clock, I'd like to propose
> "samsung,burst-clock-frequency not defined, using pixel clock"
Similar to above how about "Using pixel clock for burst clock frequency"?
> Does that work for you?
But I'm okay with both ways. Up to you.
Thanks and best regards,
Alexander
> > frequency
> >
> >
> > Best regards,
> > Alexander
> >
> > > adam
> > >
> > > > Best regards,
> > > > Alexander
> > > >
> > > > > ret = samsung_dsim_of_read_u32(node, "samsung,burst-clock-
> > > >
> > > > frequency",
> > > >
> > > > > >burst_clk_rate);
> > > >
> > > > --
> > > > TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> > > > Amtsgericht München, HRB 105018
> > > > Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> > > > http://www.tq-group.com/
> >
> > --
> > TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> > Amtsgericht München, HRB 105018
> > Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> > http://www.tq-group.com/
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
Re: drm/sched: Replacement for drm_sched_resubmit_jobs() is deprecated
On Thu, May 04, 2023 at 01:07:29PM +0200, Christian König wrote:
> Am 04.05.23 um 06:54 schrieb Matthew Brost:
> > On Wed, May 03, 2023 at 10:47:43AM +0200, Christian König wrote:
> > > Adding Luben as well.
> > >
> > > Am 03.05.23 um 10:16 schrieb Boris Brezillon:
> > > > [SNIP]
> > > > > To sum-up, we shouldn't call drm_sched_{start,stop,resubmit_jobs}().
> > > > After the discussion I had with Matthew yesterday on IRC, I
> > > > realized there was no clear agreement on this. Matthew uses those 3
> > > > helpers in the Xe driver right now, and given he intends to use a
> > > > multi-threaded wq for its 1:1 schedulers run queue, there's no way he
> > > > can get away without calling drm_sched_{start,stop}().
> > > > drm_sched_resubmit_jobs() can be open-coded in each driver, but I'm
> > > > wondering if it wouldn't be preferable to add a ::resubmit_job() method
> > > > or extend the ::run_job() one to support the resubmit semantics, which,
> > > > AFAIU, is just about enforcing the job done fence (the one returned by
> > > > ::run_job()) doesn't transition from a signaled to an unsignaled state.
> > > >
> > > > But probably more important than providing a generic helper, we should
> > > > document the resubmit semantics (AKA, what should and/or shouldn't be
> > > > done with pending jobs when a recovery happens). Because forbidding
> > > > people to use a generic helper function doesn't give any guarantee that
> > > > they'll do the right thing when coding their own logic, unless we give
> > > > clues about what's considered right/wrong, and the current state of the
> > > > doc is pretty unclear in this regard.
> > > I should probably talk about the history of the re-submit feature a bit
> > > more.
> > >
> > > Basically AMD came up with re-submission as a cheap way of increasing the
> > > reliability of GPU resets. Problem is that it turned into an absolutely
> > > nightmare. We tried for the last 5 years or so to get that stable and it's
> > > still crashing.
> > >
> > > The first and most major problem is that the kernel doesn't even has the
> > > information if re-submitting jobs is possible or not. For example a job
> > > which has already been pushed to the hw could have grabbed a binary
> > > semaphore and re-submitting it will just wait forever for the semaphore to
> > > be released.
> > >
> > > The second problem is that the dma_fence semantics don't allow to ever
> > > transit the state of a fence from signaled back to unsignaled. This means
> > > that you can't re-use the hw fence and need to allocate a new one, but
> > > since
> > > memory allocation is forbidden inside a reset handler as well (YES we need
> > > to better document that part) you actually need to keep a bunch of hw
> > > fences
> > > pre-allocated around to make this work. Amdgpu choose to illegally re-use
> > > the hw fence instead which only works with quite extreme hacks.
> > >
> > > The third problem is that the lifetime of the job object was actually
> > > defined very well before we tried to use re-submission. Basically it's
> > > just
> > > an intermediate state used between the IOCTL and pushing things to the hw,
> > > introducing this re-submit feature completely messed that up and cause
> > > quite
> > > a number of use after free errors in the past which are again only solved
> > > by
> > > quite some hacks.
> > >
> > > What we should do in the GPU scheduler instead is the follow:
> > >
> > > 1. Don't support re-submission at all!
> > > Instead we can provide help to drivers to query which fences
> > > (scheduler
> > > or hw) are still not signaled yet.
> > > This can then be used to re-create hw state if (and only if!) the
> > > driver
> > > knows what it's doing and can actually guarantee that this will work.
> > > E.g. the case for XE where the kernel driver knows the contexts which
> > > were not running at the time and can re-create their queues.
> > >
> > > 2. We can provide both a wq to use for single threaded application as well
> > > as start/stop semantics.
> > > It's just that the start/stop semantics should never touch what was
> > > already submitted, but rather just make sure that we don't get any new
> > > submissions.
> > >
> > I pretty much agree with everything Christian has said here and Xe
> > aligns with this. Let me explain what Xe does.
> >
> > 1. Entity hang (TDR timeout of job on a entity, firmware notifies Xe that a
> > entity hung, entity IOMMU CAT error, etc...):
> > - No re-submission at all
> > - ban the entity
> > - notify the UMD
> > - cleanup all pending jobs / fences
> > 2. Entire GPU hang (worth mentioning with good HW + KMD this *should*
> > never happen):
> > - stop all schedulers (same as a entity in Xe because 1 to 1)
> > - cleanup odd entity state related to communication with the
> > firmware
> > - check if an entity has a job that started but not finished, if
> > so ban it (same mechanism as above)
Re: [PATCH] drm/connector: document enum drm_connector_tv_mode DRM_MODE_TV_MODE_MAX
Reviewed-by: Simon Ser
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, One Cc stable DSI sequence fix and missing CPU transcoders for MTL plus a smaller GuC cornern case fix. Best Regards, Joonas *** drm-intel-next-fixes-2023-05-04-1: Add missing GPU transcoder masks for MTL and fix DSI power on sequence for Nextbook Ares 8A. Fix GuC version corner case. The following changes since commit 2c69679626d5daa680d71c77ad58af0088db537f: drm/i915/dp_mst: Fix active port PLL selection for secondary MST streams (2023-04-19 17:25:29 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2023-05-04-1 for you to fetch changes up to c8c2969bfcba5fcba3a5b078315c1b586d927d9f: drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep() (2023-05-03 08:31:24 +0300) Add missing GPU transcoder masks for MTL and fix DSI power on sequence for Nextbook Ares 8A. Fix GuC version corner case. Hans de Goede (1): drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep() John Harrison (1): drm/i915/guc: Actually return an error if GuC version range check fails Radhakrishna Sripada (1): drm/i915/mtl: Add the missing CPU transcoder mask in intel_device_info Ville Syrjälä (1): drm/i915: Check pipe source size when using skl+ scalers drivers/gpu/drm/i915/display/icl_dsi.c | 2 +- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 11 --- drivers/gpu/drm/i915/display/intel_dsi_vbt.h | 1 - drivers/gpu/drm/i915/display/skl_scaler.c| 17 + drivers/gpu/drm/i915/display/vlv_dsi.c | 22 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 20 drivers/gpu/drm/i915/i915_pci.c | 2 ++ 7 files changed, 37 insertions(+), 38 deletions(-)
Re: [PATCH V3 3/7] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically
On Thu, May 4, 2023 at 7:40 AM Alexander Stein
wrote:
>
> Hi Adam,
>
> Am Donnerstag, 4. Mai 2023, 14:00:08 CEST schrieb Adam Ford:
> > On Thu, May 4, 2023 at 4:21 AM Alexander Stein
> >
> > wrote:
> > > Am Dienstag, 2. Mai 2023, 03:07:55 CEST schrieb Adam Ford:
> > > > Make the pll-clock-frequency optional. If it's present, use it
> > > > to maintain backwards compatibility with existing hardware. If it
> > > > is absent, read clock rate of "sclk_mipi" to determine the rate.
> > > >
> > > > Signed-off-by: Adam Ford
> > > > Tested-by: Chen-Yu Tsai
> > > > ---
> > > >
> > > > drivers/gpu/drm/bridge/samsung-dsim.c | 12 ++--
> > > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> > > > b/drivers/gpu/drm/bridge/samsung-dsim.c index bf4b33d2de76..2dc02a9e37c0
> > > > 100644
> > > > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > > > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > > > @@ -1726,12 +1726,20 @@ static int samsung_dsim_parse_dt(struct
> > > > samsung_dsim *dsi) {
> > > >
> > > > struct device *dev = dsi->dev;
> > > > struct device_node *node = dev->of_node;
> > > >
> > > > + struct clk *pll_clk;
> > > >
> > > > int ret;
> > > >
> > > > ret = samsung_dsim_of_read_u32(node,
> > > > "samsung,pll-clock-frequency",
> > > >
> > > > >pll_clk_rate);
> > > >
> > > > - if (ret < 0)
> > > > - return ret;
> > > > +
> > > > + /* If it doesn't exist, read it from the clock instead of failing
> > > > */
> > > > + if (ret < 0) {
> > > > + pll_clk = devm_clk_get(dev, "sclk_mipi");
> > > > + if (!IS_ERR(pll_clk))
> > > > + dsi->pll_clk_rate = clk_get_rate(pll_clk);
> > > > + else
> > > > + return PTR_ERR(pll_clk);
> > > > + }
> > >
> > > Now that 'samsung,pll-clock-frequency' is optional the error in
> > > samsung_dsim_of_read_u32() should be changed. Otherwise you will get
> > >
> > > > /soc@0/bus@32c0/dsi@32e1: failed to get 'samsung,pll-clock-
> > >
> > > frequency' property
> >
> > I'll change the message from err to info with a message that reads "no
> > samsung,pll-clock-frequency, using pixel clock"
> >
> > Does that work?
>
> Having just a info is totally fine with me. Thanks.
> Although your suggested message somehow implies (to me) using pixel clock is
> just a fallback. I'm a bit concerned some might think "samsung,pll-clock-
> frequency" should be provided in DT. But this might just be me.
Oops, I got the PLL and burst burst clock confused. I think both
burst-clock and pll clock messages should get updates.
The pll clock should say something like "samsung,pll-clock-frequency
not defined, using sclk_mipi"
The imx8m n/m/p have the sclk_mipi defined in the device tree, and
this patch allows them to not have
to manually set the pll clock since it can be read. This allows to
people to change the frequency of the PLL in
in one place and let the driver read it instead of having to set the
value in two places for the same clock.
For the burst clock, I'd like to propose
"samsung,burst-clock-frequency not defined, using pixel clock"
Does that work for you?
adam
> frequency
>
> Best regards,
> Alexander
>
> > adam
> >
> > > Best regards,
> > > Alexander
> > >
> > > > ret = samsung_dsim_of_read_u32(node, "samsung,burst-clock-
> > >
> > > frequency",
> > >
> > > > >burst_clk_rate);
> > >
> > > --
> > > TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> > > Amtsgericht München, HRB 105018
> > > Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> > > http://www.tq-group.com/
>
>
> --
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> http://www.tq-group.com/
>
>
Re: [PATCH 02/13] drm: add drm_exec selftests v2
Hi Maira,
Am 04.05.23 um 14:07 schrieb Maíra Canal:
Hi Christian,
It would be nice if you use the KUnit macros, instead of pr_info.
yeah this was initially written before the DRM tests moved to KUnit and
I only quickly converted it over. Going to give this a cleanup.
Thanks,
Christian.
On 5/4/23 08:51, Christian König wrote:
Largely just the initial skeleton.
v2: add array test as well
Signed-off-by: Christian König
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/tests/Makefile | 3 +-
drivers/gpu/drm/tests/drm_exec_test.c | 96 +++
3 files changed, 99 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/tests/drm_exec_test.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 2dc81eb062eb..068e574e234e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -80,6 +80,7 @@ config DRM_KUNIT_TEST
select DRM_BUDDY
select DRM_EXPORT_FOR_TESTS if m
select DRM_KUNIT_TEST_HELPERS
+ select DRM_EXEC
default KUNIT_ALL_TESTS
help
This builds unit tests for DRM. This option is not useful for
diff --git a/drivers/gpu/drm/tests/Makefile
b/drivers/gpu/drm/tests/Makefile
index bca726a8f483..ba7baa622675 100644
--- a/drivers/gpu/drm/tests/Makefile
+++ b/drivers/gpu/drm/tests/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \
drm_modes_test.o \
drm_plane_helper_test.o \
drm_probe_helper_test.o \
- drm_rect_test.o
+ drm_rect_test.o \
+ drm_exec_test.o
CFLAGS_drm_mm_test.o := $(DISABLE_STRUCTLEAK_PLUGIN)
diff --git a/drivers/gpu/drm/tests/drm_exec_test.c
b/drivers/gpu/drm/tests/drm_exec_test.c
new file mode 100644
index ..26aa13e62d22
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_exec_test.c
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#define pr_fmt(fmt) "drm_exec: " fmt
+
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+
+#include "../lib/drm_random.h"
+
+static struct drm_device dev;
+
+static void drm_exec_sanitycheck(struct kunit *test)
+{
+ struct drm_exec exec;
+
+ drm_exec_init(, true);
+ drm_exec_fini();
+ pr_info("%s - ok!\n", __func__);
Here you could use KUNIT_SUCCEED(test).
+}
+
+static void drm_exec_lock1(struct kunit *test)
Is there a reason to call the function drm_exec_lock1 instead of
just drm_exec_lock?
+{
+ struct drm_gem_object gobj = { };
+ struct drm_exec exec;
+ int ret;
+
+ drm_gem_private_object_init(, , PAGE_SIZE);
+
+ drm_exec_init(, true);
+ drm_exec_while_not_all_locked() {
+ ret = drm_exec_prepare_obj(, , 1);
+ drm_exec_continue_on_contention();
+ if (ret) {
+ drm_exec_fini();
+ pr_err("%s - err %d!\n", __func__, ret);
Here you could use KUNIT_FAIL. Same for the other function.
Actually, it would be better if you created a function `exit`
associated with the test suite, where you would call drm_exec_fini,
and checked the ret variable with KUNIT_EXPECT_EQ(test, ret, 0) in
the test.
+ return;
+ }
+ }
+ drm_exec_fini();
+ pr_info("%s - ok!\n", __func__);
+}
+
+static void drm_exec_lock_array(struct kunit *test)
+{
+ struct drm_gem_object gobj1 = { };
+ struct drm_gem_object gobj2 = { };
+ struct drm_gem_object *array[] = { , };
+ struct drm_exec exec;
+ int ret;
+
+ drm_gem_private_object_init(, , PAGE_SIZE);
+ drm_gem_private_object_init(, , PAGE_SIZE);
+
+ drm_exec_init(, true);
+ ret = drm_exec_prepare_array(, array, ARRAY_SIZE(array), 0);
+ if (ret) {
+ drm_exec_fini();
+ pr_err("%s - err %d!\n", __func__, ret);
+ return;
+ }
+ drm_exec_fini()> + pr_info("%s - ok!\n", __func__);
+}
+
+static int drm_exec_suite_init(struct kunit_suite *suite)
+{
+ kunit_info(suite, "Testing DRM exec manager\n");
Isn't this already clear by the name of the test?
Best Regards,
- Maíra Canal
+ return 0;
+}
+
+static struct kunit_case drm_exec_tests[] = {
+ KUNIT_CASE(drm_exec_sanitycheck),
+ KUNIT_CASE(drm_exec_lock1),
+ KUNIT_CASE(drm_exec_lock_array),
+ {}
+};
+
+static struct kunit_suite drm_exec_test_suite = {
+ .name = "drm_exec",
+ .suite_init = drm_exec_suite_init,
+ .test_cases = drm_exec_tests,
+};
+
+kunit_test_suite(drm_exec_test_suite);
+
+MODULE_AUTHOR("AMD");
+MODULE_LICENSE("GPL and additional rights");
Re: [PATCH v5 2/5] drm/i915: use pat_index instead of cache_level
On 04/05/2023 00:02, fei.y...@intel.com wrote: From: Fei Yang Currently the KMD is using enum i915_cache_level to set caching policy for buffer objects. This is flaky because the PAT index which really controls the caching behavior in PTE has far more levels than what's defined in the enum. In addition, the PAT index is platform dependent, having to translate between i915_cache_level and PAT index is not reliable, and makes the code more complicated. From UMD's perspective there is also a necessity to set caching policy for performance fine tuning. It's much easier for the UMD to directly use PAT index because the behavior of each PAT index is clearly defined in Bspec. Having the abstracted i915_cache_level sitting in between would only cause more ambiguity. For these reasons this patch replaces i915_cache_level with PAT index. Also note, the cache_level is not completely removed yet, because the KMD still has the need of creating buffer objects with simple cache settings such as cached, uncached, or writethrough. For such simple cases, using cache_level would help simplify the code. Cc: Chris Wilson Cc: Matt Roper Signed-off-by: Fei Yang Reviewed-by: Andi Shyti [snip] diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c index bb6998d67133..f2334a713c4e 100644 --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c @@ -56,7 +56,7 @@ static u64 gen8_pte_encode(dma_addr_t addr, } ^^^ How come there are no changes to gen8_pte_encode? vvv static u64 mtl_pte_encode(dma_addr_t addr, - enum i915_cache_level level, + unsigned int pat_index, u32 flags) Prototype and implementation changed here for mtl_pte_encode. And we have: if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70)) ppgtt->vm.pte_encode = mtl_pte_encode; else ppgtt->vm.pte_encode = gen8_pte_encode; So should be same prototype. And: u64 (*pte_encode)(dma_addr_t addr, - enum i915_cache_level level, + unsigned int pat_index, u32 flags); /* Create a valid PTE */ Patch relies on the compiler considering enum equal to unsigned int? But the implementation of gen8_pte_encode and most ggtt counterparts is looking at the passed in pat index and thinks it is cache level. How is that supposed to work?! Or I am blind and am missing something? Regards, Tvrtko
Re: [PATCH V3 3/7] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically
Hi Adam,
Am Donnerstag, 4. Mai 2023, 14:00:08 CEST schrieb Adam Ford:
> On Thu, May 4, 2023 at 4:21 AM Alexander Stein
>
> wrote:
> > Am Dienstag, 2. Mai 2023, 03:07:55 CEST schrieb Adam Ford:
> > > Make the pll-clock-frequency optional. If it's present, use it
> > > to maintain backwards compatibility with existing hardware. If it
> > > is absent, read clock rate of "sclk_mipi" to determine the rate.
> > >
> > > Signed-off-by: Adam Ford
> > > Tested-by: Chen-Yu Tsai
> > > ---
> > >
> > > drivers/gpu/drm/bridge/samsung-dsim.c | 12 ++--
> > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> > > b/drivers/gpu/drm/bridge/samsung-dsim.c index bf4b33d2de76..2dc02a9e37c0
> > > 100644
> > > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > > @@ -1726,12 +1726,20 @@ static int samsung_dsim_parse_dt(struct
> > > samsung_dsim *dsi) {
> > >
> > > struct device *dev = dsi->dev;
> > > struct device_node *node = dev->of_node;
> > >
> > > + struct clk *pll_clk;
> > >
> > > int ret;
> > >
> > > ret = samsung_dsim_of_read_u32(node,
> > > "samsung,pll-clock-frequency",
> > >
> > > >pll_clk_rate);
> > >
> > > - if (ret < 0)
> > > - return ret;
> > > +
> > > + /* If it doesn't exist, read it from the clock instead of failing
> > > */
> > > + if (ret < 0) {
> > > + pll_clk = devm_clk_get(dev, "sclk_mipi");
> > > + if (!IS_ERR(pll_clk))
> > > + dsi->pll_clk_rate = clk_get_rate(pll_clk);
> > > + else
> > > + return PTR_ERR(pll_clk);
> > > + }
> >
> > Now that 'samsung,pll-clock-frequency' is optional the error in
> > samsung_dsim_of_read_u32() should be changed. Otherwise you will get
> >
> > > /soc@0/bus@32c0/dsi@32e1: failed to get 'samsung,pll-clock-
> >
> > frequency' property
>
> I'll change the message from err to info with a message that reads "no
> samsung,pll-clock-frequency, using pixel clock"
>
> Does that work?
Having just a info is totally fine with me. Thanks.
Although your suggested message somehow implies (to me) using pixel clock is
just a fallback. I'm a bit concerned some might think "samsung,pll-clock-
frequency" should be provided in DT. But this might just be me.
Best regards,
Alexander
> adam
>
> > Best regards,
> > Alexander
> >
> > > ret = samsung_dsim_of_read_u32(node, "samsung,burst-clock-
> >
> > frequency",
> >
> > > >burst_clk_rate);
> >
> > --
> > TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> > Amtsgericht München, HRB 105018
> > Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> > http://www.tq-group.com/
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
[PATCH] drm/connector: document enum drm_connector_tv_mode DRM_MODE_TV_MODE_MAX
Add documentation for the DRM_MODE_TV_MODE_MAX enumerator to fix the
kernel-doc warning:
include/drm/drm_connector.h:204: warning: Enum value 'DRM_MODE_TV_MODE_MAX' not
described in enum 'drm_connector_tv_mode'
Signed-off-by: Jani Nikula
---
include/drm/drm_connector.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 7b5048516185..e6478fafa6b0 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -199,6 +199,11 @@ enum drm_connector_tv_mode {
*/
DRM_MODE_TV_MODE_SECAM,
+ /**
+* @DRM_MODE_TV_MODE_MAX: Number of analog TV output modes.
+*
+* Internal implementation detail; this is not uABI.
+*/
DRM_MODE_TV_MODE_MAX,
};
--
2.39.2
Re: [PATCH v4 2/3] vkms: Add support for multiple pipes
Hi Marius,
I'm not sure if you'll keep working in this series after the proposal of
the Chromium folks. Anyway, just a small comment.
On 4/26/23 07:40, Marius Vlad wrote:
This adds support for creating multiple virtual pipes, in case one would
need to display multiple independent things on different outputs.
We use a module parameter to specify how many to create, defaulting to
just one with the possibility of specifying a maximum of 4 possible pipes.
This is of particular importance when testing out the DRM back-end in
compositors, but also to be able to independently set different DPMS states.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/vkms/vkms_crtc.c | 3 +--
drivers/gpu/drm/vkms/vkms_drv.c | 38 ++-
drivers/gpu/drm/vkms/vkms_drv.h | 12 ++---
drivers/gpu/drm/vkms/vkms_output.c| 5 ++--
drivers/gpu/drm/vkms/vkms_writeback.c | 24 -
5 files changed, 55 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 515f6772b866..051e7b647db9 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -89,8 +89,7 @@ static bool vkms_get_vblank_timestamp(struct drm_crtc *crtc,
{
struct drm_device *dev = crtc->dev;
unsigned int pipe = crtc->index;
- struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
- struct vkms_output *output = >output;
+ struct vkms_output *output = drm_crtc_to_vkms_output(crtc);
struct drm_vblank_crtc *vblank = >vblank[pipe];
if (!READ_ONCE(vblank->enabled)) {
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index e3c9c9571c8d..0ee17065bc6f 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
[...]
@@ -230,7 +243,18 @@ static int __init vkms_init(void)
config->cursor = enable_cursor;
config->writeback = enable_writeback;
config->overlay = enable_overlay;
-
+ config->max_pipes = max_pipes;
+ if (config->max_pipes > NUM_MAX_PIPES)
+ config->max_pipes = NUM_MAX_PIPES;
+ if (config->max_pipes < NUM_MIN_PIPES)
+ config->max_pipes = NUM_MIN_PIPES;
+
+ /* with 8 overlays and 4 pipes we exceed the amount of planes we
+* have; see __drm_universal_plane_init() */
+ if (config->overlay && config->max_pipes == NUM_MAX_PIPES)
+ config->max_pipes = NUM_MAX_PIPES - 1;
Instead of reducing the number of pipes, you could change the maximum number
of overlay planes to 6-4 planes. So many overlay planes are not that needed
and it would be nice to have 4 pipes with overlay planes enabled.
Best Regards,
- Maíra Canal
+
+ DRM_INFO("Initialized with %u pipes\n", config->max_pipes);
ret = vkms_create(config);
if (ret)
kfree(config);
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index f152d54baf76..b096832ed0f2 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -21,7 +21,9 @@
#define XRES_MAX 8192
#define YRES_MAX 8192
-#define NUM_OVERLAY_PLANES 8
+#define NUM_OVERLAY_PLANES 8
+#define NUM_MAX_PIPES 4
+#define NUM_MIN_PIPES 1
struct vkms_frame_info {
struct drm_framebuffer *fb;
@@ -112,6 +114,7 @@ struct vkms_config {
bool writeback;
bool cursor;
bool overlay;
+ unsigned int max_pipes;
/* only set when instantiated */
struct vkms_device *dev;
};
@@ -119,13 +122,16 @@ struct vkms_config {
struct vkms_device {
struct drm_device drm;
struct platform_device *platform;
- struct vkms_output output;
+ struct vkms_output output[NUM_MAX_PIPES];
const struct vkms_config *config;
};
#define drm_crtc_to_vkms_output(target) \
container_of(target, struct vkms_output, crtc)
+#define wb_connector_to_vkms_output(target) \
+ container_of(target, struct vkms_output, wb_connector)
+
#define drm_device_to_vkms_device(target) \
container_of(target, struct vkms_device, drm)
@@ -157,6 +163,6 @@ void vkms_set_composer(struct vkms_output *out, bool enabled);
void vkms_compose_row(struct line_buffer *stage_buffer, struct
vkms_plane_state *plane, int y);
/* Writeback */
-int vkms_enable_writeback_connector(struct vkms_device *vkmsdev);
+int vkms_enable_writeback_connector(struct vkms_device *vkmsdev, int index);
#endif /* _VKMS_DRV_H_ */
diff --git a/drivers/gpu/drm/vkms/vkms_output.c
b/drivers/gpu/drm/vkms/vkms_output.c
index 1b8aa3a34e46..9c801b8c4c12 100644
--- a/drivers/gpu/drm/vkms/vkms_output.c
+++ b/drivers/gpu/drm/vkms/vkms_output.c
@@ -48,7 +48,7 @@ static int vkms_add_overlay_plane(struct vkms_device
*vkmsdev, int index,
int vkms_output_init(struct vkms_device *vkmsdev, int index)
{
- struct vkms_output *output = >output;
+
Re: [PATCH v2 1/8] drm: Disable the cursor plane on atomic contexts with virtualized drivers
On Thu, 4 May 2023 13:27:22 +0200 Jonas Ådahl wrote: > On Thu, May 04, 2023 at 01:39:04PM +0300, Pekka Paalanen wrote: > > On Thu, 4 May 2023 01:50:25 + > > Zack Rusin wrote: > > > > > On Wed, 2023-05-03 at 09:48 +0200, Javier Martinez Canillas wrote: > > > > Zack Rusin writes: > > > > > > > > > On Tue, 2023-05-02 at 11:32 +0200, Javier Martinez Canillas wrote: > > > > > > > > AFAICT this is the only remaining thing to be addressed for this > > > > > > series ? > > > > > > > > > > No, there was more. tbh I haven't had the time to think about whether > > > > > the above > > > > > makes sense to me, e.g. I'm not sure if having virtualized drivers > > > > > expose > > > > > "support > > > > > universal planes" and adding another plane which is not universal > > > > > (the only > > > > > "universal" plane on them being the default one) makes more sense > > > > > than a flag > > > > > that > > > > > says "this driver requires a cursor in the cursor plane". There's > > > > > certainly a > > > > > huge > > > > > difference in how userspace would be required to handle it and it's > > > > > way uglier > > > > > with > > > > > two different cursor planes. i.e. there's a lot of ways in which this > > > > > could be > > > > > cleaner in the kernel but they all require significant changes to > > > > > userspace, > > > > > that go > > > > > way beyond "attach hotspot info to this plane". I'd like to avoid > > > > > approaches > > > > > that > > > > > mean running with atomic kms requires completely separate paths for > > > > > virtualized > > > > > drivers because no one will ever support and maintain it. > > > > > > > > > > It's not a trivial thing because it's fundamentally hard to untangle > > > > > the fact > > > > > the > > > > > virtualized drivers have been advertising universal plane support > > > > > without ever > > > > > supporting universal planes. Especially because most new userspace in > > > > > general > > > > > checks > > > > > for "universal planes" to expose atomic kms paths. > > > > > > > > > > > > > After some discussion on the #dri-devel, your approach makes sense and > > > > the > > > > only contention point is the name of the driver feature flag name. The > > > > one > > > > you are using (DRIVER_VIRTUAL) seems to be too broad and generic (the > > > > fact > > > > that vkms won't set and is a virtual driver as well, is a good example). > > > > > > > > Maybe something like DRIVER_CURSOR_HOTSPOT or > > > > DRIVER_CURSOR_COMMANDEERING > > > > would be more accurate and self explanatory ? > > > > > > Sure, or even more verbose DRIVER_NEEDS_CURSOR_PLANE_HOTSPOT, but it > > > sounds like > > > Pekka doesn't agree with this approach. As I mentioned in my response to > > > him, I'd be > > > happy with any approach that gets paravirtualized drivers working with > > > atomic kms, > > > but atm I don't have enough time to be creating a new kernel subsystem or > > > a new set > > > of uapi's for paravirtualized drivers and then porting mutter/kwin to > > > those. > > > > It seems I have not been clear enough, apologies. Once more, in short: > > > > Zack, I'm worried about this statement from you (copied from above): > > > > > > > I'd like to avoid approaches that mean running with atomic kms > > > > > requires completely separate paths for virtualized drivers > > > > > because no one will ever support and maintain it. > > > > It feels like you are intentionally limiting your own design options > > for the fear of "no one will ever support it". I'm worried that over > > the coming years, that will lead to a hard to use, hard to maintain > > patchwork of vague or undocumented or just too many little UAPI details. > > > > Please, don't limit your designs. There are good reasons why nested KMS > > drivers behave fundamentally differently to most KMS hardware drivers. > > Userspace that does not or cannot take that into account is unavoidably > > crippled. > > From a compositor side, there is a valid reason to minimize the uAPI > difference between "nested virtual machine" code paths and "running on > actual hardware" code paths, which is to let virtual machines with a > viewer connected to KMS act as a testing environment, rather than a > production environment. Running a production environment in a virtual > machine doesn't really need to use KMS at all. > > When using virtual machines for testing, I want to minimize the amount > of differentation between running on hardware and running in the VM > because otherwise the parts that are tested are not the same. > > I realize that hotpspots and the cursor moving viewer side contradicts > that to some degree, but still, from a graphical testing witha VM point > of view, one has to compromise, as testing isn't just for the KMS layer, > but for the DE and distribution as a whole. Right, I'm looking at this from the production use only point of view, and not as any kind of testing
Re: [PATCH v2 0/7] drm: sun4i: set proper TCON0 DCLK rate in DSI mode
Hello everyone, I apologize for my absence from the discussion during past week, I got hit with tonsillitis. On Mon May 1, 2023 at 3:40 PM CEST, Frank Oltmanns wrote: > Looking at ccu_nkm_determine_rate(), we've found our culprit because it > does not try parent clock rates other than the current one. The same > applies to all other ccu_nkm_* functions. Yes, that's why I dropped CLK_SET_RATE_PARENT from pll-mipi in v3. > b. Add functionality to ccu_nkm_* to also update the parent clock rate. > > I'm actually interested in tackling b, but I can't make any promises as > to if and when I'll be able to solve it. I'm not certain about any side > effects this might have. It sounds like an interesting exercise. But what if HDMI is then added to the mix? Best regards Roman
Re: [RFC PATCH 0/1] Add AMDGPU_INFO_GUILTY_APP ioctl
Hi Felix, On Wed, 2023-05-03 at 11:08 -0400, Felix Kuehling wrote: > That's the worst-case scenario where you're debugging HW or FW > issues. > Those should be pretty rare post-bringup. But are there hangs caused > by > user mode driver or application bugs that are easier to debug and > probably don't even require a GPU reset? There are many GPU hangs that gamers experience while playing. We have dozens of open bug reports against RADV about GPU hangs on various GPU generations. These usually fall into two categories: 1. When the hang always happens at the same point in a game. These are painful to debug but manageable. 2. "Random" hangs that happen to users over the course of playing a game for several hours. It is absolute hell to try to even reproduce let alone diagnose these issues, and this is what we would like to improve. For these hard-to-diagnose problems, it is already a challenge to determine whether the problem is the kernel (eg. setting wrong voltages / frequencies) or userspace (eg. missing some synchronization), can be even a game bug that we need to work around. > For example most VM faults can > be handled without hanging the GPU. Similarly, a shader in an endless > loop should not require a full GPU reset. This is actually not the case, AFAIK André's test case was an app that had an infinite loop in a shader. > > It's more complicated for graphics because of the more complex > pipeline > and the lack of CWSR. But it should still be possible to do some > debugging without JTAG if the problem is in SW and not HW or FW. It's > probably worth improving that debugability without getting hung-up on > the worst case. I agree, and we welcome any constructive suggestion to improve the situation. It seems like our idea doesn't work if the kernel can't give us the information we need. How do we move forward? Best regards, Timur
2023 X.Org Foundation Election vote results
The Board of Directors election and the vote on the By-laws concluded at 14:00 UTC on May 1st 2023 and these are the results: - We had 75 members this year, of which 55 cast a vote, so the turnout is 73.3%. - On the question "Do you accept the proposed By-Law changes to make SFC the new fiscal sponsor of the X.Org foundation, replacing SPI?" 52 of the 55 members voted yes (94.5%). Among all 75 members, approval is 69.3% (52/75, over 2/3), so we can consider this change approved using the current by-law rules. - On the question "Do you accept the proposed By-Law changes to modify the special voting quorum requirements to be limited to present (meaning voting) members?" 48 of the 55 members voted yes (87.3%). Despite this, 48 votes represent only 64% of the members, which means the by-laws change does not pass. - In the election of the Directors to the Board of the X.Org Foundation, the results were that Daniel Vetter, Lyude Paul, Arkadiusz Hiler and Christopher Michael were elected for two-year terms. The old full board is: Emma Anholt, Mark Filion, Ricardo Garcia, Samuel Iglesias Gonsálvez, Manasi D Navare, Lyude Paul, Alyssa Rosenzweig and Daniel Vetter. The new full board is: Emma Anholt, Mark Filion, Ricardo Garcia, Arkadiusz Hiler, Christopher Michael, Lyude Paul, Alyssa Rosenzweig and Daniel Vetter. Full election results, sorted by points: * Daniel Vetter (367 points) * Lyude Paul (348 points) * Arkadiusz Hiler (286 points) * Christopher Michael (263 points) * Manasi Navare (195 points) * Uma Shankar (157 points) * Thomas Adam (105 points) * William Weeks-Balconi (51 points) Thanks everyone, -Ricardo Garcia, on behalf of the X.Org elections committee
[PATCH] drm:amd:amdgpu: Fix missing buffer object unlock in failure path
smatch warning -
1) drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:3615 gfx_v9_0_kiq_resume()
warn: inconsistent returns 'ring->mqd_obj->tbo.base.resv'.
2) drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:6901 gfx_v10_0_kiq_resume()
warn: inconsistent returns 'ring->mqd_obj->tbo.base.resv'.
Signed-off-by: Sukrut Bellary
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 4 +++-
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 8bd07ff59671..66d5c5d68454 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -6891,8 +6891,10 @@ static int gfx_v10_0_kiq_resume(struct amdgpu_device
*adev)
return r;
r = amdgpu_bo_kmap(ring->mqd_obj, (void **)>mqd_ptr);
- if (unlikely(r != 0))
+ if (unlikely(r != 0)) {
+ amdgpu_bo_unreserve(ring->mqd_obj);
return r;
+ }
gfx_v10_0_kiq_init_queue(ring);
amdgpu_bo_kunmap(ring->mqd_obj);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index bce6919d666a..d5715d8a4128 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -3617,8 +3617,10 @@ static int gfx_v9_0_kiq_resume(struct amdgpu_device
*adev)
return r;
r = amdgpu_bo_kmap(ring->mqd_obj, (void **)>mqd_ptr);
- if (unlikely(r != 0))
+ if (unlikely(r != 0)) {
+ amdgpu_bo_unreserve(ring->mqd_obj);
return r;
+ }
gfx_v9_0_kiq_init_queue(ring);
amdgpu_bo_kunmap(ring->mqd_obj);
--
2.34.1
Re: [PATCH 1/2] dt-bindings: display: simple: support non-default data-mapping
Hi Rob, On 4/19/23 08:29, Johannes Zink wrote: [snip] Why do you duplicate what's in display/lvds.yaml? I don't think any of the other properties from display/lvds.yaml currently make any sense to be put into simple-panel, thus I selectively picked this one. If there is a way to selectively pick only the data_mapping, please let me know and I send a V2 This also just made 'data-mapping' valid on non-LVDS panels. what is the canonical way of restricting the data-mapping property to LVDS panels only? Or ist the proper way to go to move the panel I use (innolux,g101ice-l01) to its own yaml file, include panel-simple.yaml and leave the others alone? I think other LVDS panels might benefit from this series though, which is why I think it makes sense to add the property to all LVDS panels. gentle ping. How do you suggest should I proceed here? Maybe pulling the data-mapping definition in a separate file and include it in both files? Can I enable the property selectively, e.g. only on the innolux,g101ice-l01 panel, in order not to enable it on non-LVDS panels or on LVDS-panels which might not support it? Best regards Johannes [snip] -- Pengutronix e.K.| Johannes Zink | Steuerwalder Str. 21| https://www.pengutronix.de/| 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686| Fax: +49-5121-206917-|
Re: [PATCH 02/13] drm: add drm_exec selftests v2
Hi Christian,
It would be nice if you use the KUnit macros, instead of pr_info.
On 5/4/23 08:51, Christian König wrote:
Largely just the initial skeleton.
v2: add array test as well
Signed-off-by: Christian König
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/tests/Makefile| 3 +-
drivers/gpu/drm/tests/drm_exec_test.c | 96 +++
3 files changed, 99 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/tests/drm_exec_test.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 2dc81eb062eb..068e574e234e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -80,6 +80,7 @@ config DRM_KUNIT_TEST
select DRM_BUDDY
select DRM_EXPORT_FOR_TESTS if m
select DRM_KUNIT_TEST_HELPERS
+ select DRM_EXEC
default KUNIT_ALL_TESTS
help
This builds unit tests for DRM. This option is not useful for
diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
index bca726a8f483..ba7baa622675 100644
--- a/drivers/gpu/drm/tests/Makefile
+++ b/drivers/gpu/drm/tests/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \
drm_modes_test.o \
drm_plane_helper_test.o \
drm_probe_helper_test.o \
- drm_rect_test.o
+ drm_rect_test.o \
+ drm_exec_test.o
CFLAGS_drm_mm_test.o := $(DISABLE_STRUCTLEAK_PLUGIN)
diff --git a/drivers/gpu/drm/tests/drm_exec_test.c
b/drivers/gpu/drm/tests/drm_exec_test.c
new file mode 100644
index ..26aa13e62d22
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_exec_test.c
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#define pr_fmt(fmt) "drm_exec: " fmt
+
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+
+#include "../lib/drm_random.h"
+
+static struct drm_device dev;
+
+static void drm_exec_sanitycheck(struct kunit *test)
+{
+ struct drm_exec exec;
+
+ drm_exec_init(, true);
+ drm_exec_fini();
+ pr_info("%s - ok!\n", __func__);
Here you could use KUNIT_SUCCEED(test).
+}
+
+static void drm_exec_lock1(struct kunit *test)
Is there a reason to call the function drm_exec_lock1 instead of
just drm_exec_lock?
+{
+ struct drm_gem_object gobj = { };
+ struct drm_exec exec;
+ int ret;
+
+ drm_gem_private_object_init(, , PAGE_SIZE);
+
+ drm_exec_init(, true);
+ drm_exec_while_not_all_locked() {
+ ret = drm_exec_prepare_obj(, , 1);
+ drm_exec_continue_on_contention();
+ if (ret) {
+ drm_exec_fini();
+ pr_err("%s - err %d!\n", __func__, ret);
Here you could use KUNIT_FAIL. Same for the other function.
Actually, it would be better if you created a function `exit`
associated with the test suite, where you would call drm_exec_fini,
and checked the ret variable with KUNIT_EXPECT_EQ(test, ret, 0) in
the test.
+ return;
+ }
+ }
+ drm_exec_fini();
+ pr_info("%s - ok!\n", __func__);
+}
+
+static void drm_exec_lock_array(struct kunit *test)
+{
+ struct drm_gem_object gobj1 = { };
+ struct drm_gem_object gobj2 = { };
+ struct drm_gem_object *array[] = { , };
+ struct drm_exec exec;
+ int ret;
+
+ drm_gem_private_object_init(, , PAGE_SIZE);
+ drm_gem_private_object_init(, , PAGE_SIZE);
+
+ drm_exec_init(, true);
+ ret = drm_exec_prepare_array(, array, ARRAY_SIZE(array), 0);
+ if (ret) {
+ drm_exec_fini();
+ pr_err("%s - err %d!\n", __func__, ret);
+ return;
+ }
+ drm_exec_fini()> + pr_info("%s - ok!\n", __func__);
+}
+
+static int drm_exec_suite_init(struct kunit_suite *suite)
+{
+ kunit_info(suite, "Testing DRM exec manager\n");
Isn't this already clear by the name of the test?
Best Regards,
- Maíra Canal
+ return 0;
+}
+
+static struct kunit_case drm_exec_tests[] = {
+ KUNIT_CASE(drm_exec_sanitycheck),
+ KUNIT_CASE(drm_exec_lock1),
+ KUNIT_CASE(drm_exec_lock_array),
+ {}
+};
+
+static struct kunit_suite drm_exec_test_suite = {
+ .name = "drm_exec",
+ .suite_init = drm_exec_suite_init,
+ .test_cases = drm_exec_tests,
+};
+
+kunit_test_suite(drm_exec_test_suite);
+
+MODULE_AUTHOR("AMD");
+MODULE_LICENSE("GPL and additional rights");
Re: [PATCH V3 3/7] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically
On Thu, May 4, 2023 at 4:21 AM Alexander Stein
wrote:
>
> Am Dienstag, 2. Mai 2023, 03:07:55 CEST schrieb Adam Ford:
> > Make the pll-clock-frequency optional. If it's present, use it
> > to maintain backwards compatibility with existing hardware. If it
> > is absent, read clock rate of "sclk_mipi" to determine the rate.
> >
> > Signed-off-by: Adam Ford
> > Tested-by: Chen-Yu Tsai
> > ---
> > drivers/gpu/drm/bridge/samsung-dsim.c | 12 ++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> > b/drivers/gpu/drm/bridge/samsung-dsim.c index bf4b33d2de76..2dc02a9e37c0
> > 100644
> > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > @@ -1726,12 +1726,20 @@ static int samsung_dsim_parse_dt(struct samsung_dsim
> > *dsi) {
> > struct device *dev = dsi->dev;
> > struct device_node *node = dev->of_node;
> > + struct clk *pll_clk;
> > int ret;
> >
> > ret = samsung_dsim_of_read_u32(node, "samsung,pll-clock-frequency",
> > >pll_clk_rate);
> > - if (ret < 0)
> > - return ret;
> > +
> > + /* If it doesn't exist, read it from the clock instead of failing */
> > + if (ret < 0) {
> > + pll_clk = devm_clk_get(dev, "sclk_mipi");
> > + if (!IS_ERR(pll_clk))
> > + dsi->pll_clk_rate = clk_get_rate(pll_clk);
> > + else
> > + return PTR_ERR(pll_clk);
> > + }
> >
>
> Now that 'samsung,pll-clock-frequency' is optional the error in
> samsung_dsim_of_read_u32() should be changed. Otherwise you will get
> > /soc@0/bus@32c0/dsi@32e1: failed to get 'samsung,pll-clock-
> frequency' property
I'll change the message from err to info with a message that reads "no
samsung,pll-clock-frequency, using pixel clock"
Does that work?
adam
>
> Best regards,
> Alexander
>
> > ret = samsung_dsim_of_read_u32(node, "samsung,burst-clock-
> frequency",
> > >burst_clk_rate);
>
>
> --
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> http://www.tq-group.com/
>
>
Re: [v4,5/6] fbdev: Move framebuffer I/O helpers into
Hi,
I tested the whole patch set on a LS3A5000(LoongArch)machine with efifb
driver,
with both fbtest and fbdev of IGT, The test result say passed and I can
not see anything wired happen.
Tested-by: Sui Jingfeng
On 2023/5/4 15:45, Thomas Zimmermann wrote:
Implement framebuffer I/O helpers, such as fb_read*() and fb_write*(),
in the architecture's header file or the generic one.
The common case has been the use of regular I/O functions, such as
__raw_readb() or memset_io(). A few architectures used plain system-
memory reads and writes. Sparc used helpers for its SBus.
The architectures that used special cases provide the same code in
their __raw_*() I/O helpers. So the patch replaces this code with the
__raw_*() functions and moves it to for all
architectures.
v4:
* ia64, loongarch, sparc64: add fb_mem*() to arch headers
to keep current semantics (Arnd)
v3:
* implement all architectures with generic helpers
* support reordering and native byte order (Geert, Arnd)
Signed-off-by: Thomas Zimmermann
---
arch/ia64/include/asm/fb.h | 20 +++
arch/loongarch/include/asm/fb.h | 21 +++
arch/sparc/include/asm/fb.h | 20 +++
include/asm-generic/fb.h| 101
include/linux/fb.h | 53 -
5 files changed, 162 insertions(+), 53 deletions(-)
diff --git a/arch/ia64/include/asm/fb.h b/arch/ia64/include/asm/fb.h
index 0208f64a0da0..bcf982043a5c 100644
--- a/arch/ia64/include/asm/fb.h
+++ b/arch/ia64/include/asm/fb.h
@@ -2,7 +2,9 @@
#ifndef _ASM_FB_H_
#define _ASM_FB_H_
+#include
#include
+#include
#include
@@ -18,6 +20,24 @@ static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
}
#define fb_pgprotect fb_pgprotect
+static inline void fb_memcpy_fromfb(void *to, const volatile void __iomem *from, size_t n)
+{
+ memcpy(to, (void __force *)from, n);
+}
+#define fb_memcpy_fromfb fb_memcpy_fromfb
+
+static inline void fb_memcpy_tofb(volatile void __iomem *to, const void *from,
size_t n)
+{
+ memcpy((void __force *)to, from, n);
+}
+#define fb_memcpy_tofb fb_memcpy_tofb
+
+static inline void fb_memset(volatile void __iomem *addr, int c, size_t n)
+{
+ memset((void __force *)addr, c, n);
+}
+#define fb_memset fb_memset
+
#include
#endif /* _ASM_FB_H_ */
diff --git a/arch/loongarch/include/asm/fb.h b/arch/loongarch/include/asm/fb.h
index ff82f20685c8..c6fc7ef374a4 100644
--- a/arch/loongarch/include/asm/fb.h
+++ b/arch/loongarch/include/asm/fb.h
@@ -5,6 +5,27 @@
#ifndef _ASM_FB_H_
#define _ASM_FB_H_
+#include
+#include
+
+static inline void fb_memcpy_fromfb(void *to, const volatile void __iomem
*from, size_t n)
+{
+ memcpy(to, (void __force *)from, n);
+}
+#define fb_memcpy_fromfb fb_memcpy_fromfb
+
+static inline void fb_memcpy_tofb(volatile void __iomem *to, const void *from,
size_t n)
+{
+ memcpy((void __force *)to, from, n);
+}
+#define fb_memcpy_tofb fb_memcpy_tofb
+
+static inline void fb_memset(volatile void __iomem *addr, int c, size_t n)
+{
+ memset((void __force *)addr, c, n);
+}
+#define fb_memset fb_memset
+
#include
Here works as the past, but why bother cast it to (void __force *) ?
why not use __memcpy_fromio, __memcpy_toio and __memset_io directly?
I modify it this patch as following, it still works.
static inline void fb_memcpy_fromio(void *to, const volatile void
__iomem *from, size_t n)
{
- memcpy(to, (void __force *)from, n);
+ __memcpy_fromio(to, from, n);
}
#define fb_memcpy_fromio fb_memcpy_fromio
static inline void fb_memcpy_toio(volatile void __iomem *to, const
void *from, size_t n)
{
- memcpy((void __force *)to, from, n);
+ __memcpy_toio(to, from, n);
}
#define fb_memcpy_toio fb_memcpy_toio
static inline void fb_memset_io(volatile void __iomem *addr, int c,
size_t n)
{
- memset((void __force *)addr, c, n);
+ __memset_io(addr, c, n);
}
#define fb_memset fb_memset_io
#endif /* _ASM_FB_H_ */
diff --git a/arch/sparc/include/asm/fb.h b/arch/sparc/include/asm/fb.h
index 689ee5c60054..077da91aeba1 100644
--- a/arch/sparc/include/asm/fb.h
+++ b/arch/sparc/include/asm/fb.h
@@ -2,6 +2,8 @@
#ifndef _SPARC_FB_H_
#define _SPARC_FB_H_
+#include
+
struct fb_info;
struct file;
struct vm_area_struct;
@@ -16,6 +18,24 @@ static inline void fb_pgprotect(struct file *file, struct
vm_area_struct *vma,
int fb_is_primary_device(struct fb_info *info);
#define fb_is_primary_device fb_is_primary_device
+static inline void fb_memcpy_fromfb(void *to, const volatile void __iomem *from, size_t n)
+{
+ sbus_memcpy_fromio(to, from, n);
+}
+#define fb_memcpy_fromfb fb_memcpy_fromfb
+
+static inline void fb_memcpy_tofb(volatile void __iomem *to, const void *from,
size_t n)
+{
+ sbus_memcpy_toio(to, from, n);
+}
+#define fb_memcpy_tofb fb_memcpy_tofb
+
+static inline void
[PATCH 10/13] drm/virtgpu: switch to using drm_exec
Just a straightforward conversion without any optimization.
Only compile tested for now.
Signed-off-by: Christian König
---
drivers/gpu/drm/virtio/Kconfig | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++-
drivers/gpu/drm/virtio/virtgpu_gem.c | 29 +++-
3 files changed, 6 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index ea06ff2aa4b4..a24a1ce5e666 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -5,6 +5,7 @@ config DRM_VIRTIO_GPU
select VIRTIO
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
+ select DRM_EXEC
select VIRTIO_DMA_SHARED_BUFFER
help
This is the virtual GPU driver for virtio. It can be used with
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index af6ffb696086..c12434222e51 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -116,7 +117,7 @@ struct virtio_gpu_object_vram {
container_of((virtio_gpu_object), struct virtio_gpu_object_vram, base)
struct virtio_gpu_object_array {
- struct ww_acquire_ctx ticket;
+ struct drm_exec exec;
struct list_head next;
u32 nents, total;
struct drm_gem_object *objs[];
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 7db48d17ee3a..bcab407074f4 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -171,6 +171,7 @@ struct virtio_gpu_object_array *virtio_gpu_array_alloc(u32
nents)
objs->nents = 0;
objs->total = nents;
+ drm_exec_init(>exec, true);
return objs;
}
@@ -214,36 +215,12 @@ void virtio_gpu_array_add_obj(struct
virtio_gpu_object_array *objs,
int virtio_gpu_array_lock_resv(struct virtio_gpu_object_array *objs)
{
- unsigned int i;
- int ret;
-
- if (objs->nents == 1) {
- ret = dma_resv_lock_interruptible(objs->objs[0]->resv, NULL);
- } else {
- ret = drm_gem_lock_reservations(objs->objs, objs->nents,
- >ticket);
- }
- if (ret)
- return ret;
-
- for (i = 0; i < objs->nents; ++i) {
- ret = dma_resv_reserve_fences(objs->objs[i]->resv, 1);
- if (ret) {
- virtio_gpu_array_unlock_resv(objs);
- return ret;
- }
- }
- return ret;
+ return drm_exec_prepare_array(>exec, objs->objs, objs->nents, 1);
}
void virtio_gpu_array_unlock_resv(struct virtio_gpu_object_array *objs)
{
- if (objs->nents == 1) {
- dma_resv_unlock(objs->objs[0]->resv);
- } else {
- drm_gem_unlock_reservations(objs->objs, objs->nents,
- >ticket);
- }
+ drm_exec_fini(>exec);
}
void virtio_gpu_array_add_fence(struct virtio_gpu_object_array *objs,
--
2.34.1
[PATCH 12/13] drm/v3d: switch to using drm_exec
Just a straightforward conversion without any optimization.
Only compile tested for now.
Signed-off-by: Christian König
---
drivers/gpu/drm/v3d/v3d_gem.c | 43 ---
1 file changed, 19 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 2e94ce788c71..75880ffc0cf1 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#include
#include
@@ -249,20 +250,16 @@ v3d_invalidate_caches(struct v3d_dev *v3d)
* to v3d, so we don't attach dma-buf fences to them.
*/
static int
-v3d_lock_bo_reservations(struct v3d_job *job,
-struct ww_acquire_ctx *acquire_ctx)
+v3d_lock_bo_reservations(struct v3d_job *job, struct drm_exec *exec)
{
int i, ret;
- ret = drm_gem_lock_reservations(job->bo, job->bo_count, acquire_ctx);
+ drm_exec_init(exec, true);
+ ret = drm_exec_prepare_array(exec, job->bo, job->bo_count, 1);
if (ret)
- return ret;
+ goto fail;
for (i = 0; i < job->bo_count; i++) {
- ret = dma_resv_reserve_fences(job->bo[i]->resv, 1);
- if (ret)
- goto fail;
-
ret = drm_sched_job_add_implicit_dependencies(>base,
job->bo[i], true);
if (ret)
@@ -272,7 +269,7 @@ v3d_lock_bo_reservations(struct v3d_job *job,
return 0;
fail:
- drm_gem_unlock_reservations(job->bo, job->bo_count, acquire_ctx);
+ drm_exec_fini(exec);
return ret;
}
@@ -477,7 +474,7 @@ v3d_push_job(struct v3d_job *job)
static void
v3d_attach_fences_and_unlock_reservation(struct drm_file *file_priv,
struct v3d_job *job,
-struct ww_acquire_ctx *acquire_ctx,
+struct drm_exec *exec,
u32 out_sync,
struct v3d_submit_ext *se,
struct dma_fence *done_fence)
@@ -492,7 +489,7 @@ v3d_attach_fences_and_unlock_reservation(struct drm_file
*file_priv,
DMA_RESV_USAGE_WRITE);
}
- drm_gem_unlock_reservations(job->bo, job->bo_count, acquire_ctx);
+ drm_exec_fini(exec);
/* Update the return sync object for the job */
/* If it only supports a single signal semaphore*/
@@ -669,7 +666,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
struct v3d_render_job *render = NULL;
struct v3d_job *clean_job = NULL;
struct v3d_job *last_job;
- struct ww_acquire_ctx acquire_ctx;
+ struct drm_exec exec;
int ret = 0;
trace_v3d_submit_cl_ioctl(>drm, args->rcl_start, args->rcl_end);
@@ -731,7 +728,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
if (ret)
goto fail;
- ret = v3d_lock_bo_reservations(last_job, _ctx);
+ ret = v3d_lock_bo_reservations(last_job, );
if (ret)
goto fail;
@@ -775,7 +772,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
v3d_attach_fences_and_unlock_reservation(file_priv,
last_job,
-_ctx,
+,
args->out_sync,
,
last_job->done_fence);
@@ -791,8 +788,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
fail_unreserve:
mutex_unlock(>sched_lock);
fail_perfmon:
- drm_gem_unlock_reservations(last_job->bo,
- last_job->bo_count, _ctx);
+ drm_exec_fini();
fail:
v3d_job_cleanup((void *)bin);
v3d_job_cleanup((void *)render);
@@ -819,7 +815,7 @@ v3d_submit_tfu_ioctl(struct drm_device *dev, void *data,
struct drm_v3d_submit_tfu *args = data;
struct v3d_submit_ext se = {0};
struct v3d_tfu_job *job = NULL;
- struct ww_acquire_ctx acquire_ctx;
+ struct drm_exec exec;
int ret = 0;
trace_v3d_submit_tfu_ioctl(>drm, args->iia);
@@ -870,7 +866,7 @@ v3d_submit_tfu_ioctl(struct drm_device *dev, void *data,
job->base.bo[job->base.bo_count] = bo;
}
- ret = v3d_lock_bo_reservations(>base, _ctx);
+ ret = v3d_lock_bo_reservations(>base, );
if (ret)
goto fail;
@@ -879,7 +875,7 @@ v3d_submit_tfu_ioctl(struct drm_device *dev, void *data,
mutex_unlock(>sched_lock);
v3d_attach_fences_and_unlock_reservation(file_priv,
->base, _ctx,
+
