Re: [PATCH v12 1/2] MAINTAINERS: add maintainers for DRM LOONGSON driver
Hi, Jingfeng, I think you should exchange the order of these two patches. Huacai On Thu, May 4, 2023 at 4:04 PM Sui Jingfeng wrote: > > This patch add myself as maintainer to drm loongson driver > > Signed-off-by: Sui Jingfeng > --- > MAINTAINERS | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 73b3298b7232..1f5aa8756d87 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6922,6 +6922,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc > F: drivers/gpu/drm/lima/ > F: include/uapi/drm/lima_drm.h > > +DRM DRIVERS FOR LOONGSON > +M: Sui Jingfeng > +L: dri-devel@lists.freedesktop.org > +S: Supported > +T: git git://anongit.freedesktop.org/drm/drm-misc > +F: drivers/gpu/drm/loongson/ > + > DRM DRIVERS FOR MEDIATEK > M: Chun-Kuang Hu > M: Philipp Zabel > -- > 2.25.1 >
[PATCH V4 5/6] drm: bridge: samsung-dsim: Dynamically configure DPHY timing
The DPHY timings are currently hard coded. Since the input
clock can be variable, the phy timings need to be variable
too. Add an additional variable to the driver data to enable
this feature to prevent breaking boards that don't support it.
The phy_mipi_dphy_get_default_config function configures the
DPHY timings in pico-seconds, and a small macro converts those
timings into clock cycles based on the pixel clock rate.
Signed-off-by: Adam Ford
Tested-by: Chen-Yu Tsai
Tested-by: Frieder Schrempf
Reviewed-by: Frieder Schrempf
Tested-by: Michael Walle
---
drivers/gpu/drm/bridge/samsung-dsim.c | 74 ---
include/drm/bridge/samsung-dsim.h | 1 +
2 files changed, 68 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 2dc02a9e37c0..1b98c4e040b0 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -218,6 +218,8 @@
#define OLD_SCLK_MIPI_CLK_NAME "pll_clk"
+#define PS_TO_CYCLE(ps, hz) DIV64_U64_ROUND_CLOSEST(((ps) * (hz)),
1ULL)
+
static const char *const clk_names[5] = {
"bus_clk",
"sclk_mipi",
@@ -487,6 +489,7 @@ static const struct samsung_dsim_driver_data
imx8mm_dsi_driver_data = {
.m_min = 64,
.m_max = 1023,
.min_freq = 1050,
+ .dynamic_dphy = 1,
};
static const struct samsung_dsim_driver_data *
@@ -698,13 +701,50 @@ static void samsung_dsim_set_phy_ctrl(struct samsung_dsim
*dsi)
const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
const unsigned int *reg_values = driver_data->reg_values;
u32 reg;
+ struct drm_display_mode *m = >mode;
+ int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
+ struct phy_configure_opts_mipi_dphy cfg;
+ int clk_prepare, lpx, clk_zero, clk_post, clk_trail;
+ int hs_exit, hs_prepare, hs_zero, hs_trail;
+ unsigned long long clock_in_hz = m->clock * 1000;
if (driver_data->has_freqband)
return;
+ /* The dynamic_phy has the ability to adjust PHY Timing settings */
+ if (driver_data->dynamic_dphy) {
+ phy_mipi_dphy_get_default_config(clock_in_hz, bpp, dsi->lanes,
);
+
+ /*
+* TODO:
+* The tech reference manual for i.MX8M Mini/Nano/Plus
+* doesn't state what the definition of the PHYTIMING
+* bits are beyond their address and bit position.
+* After reviewing NXP's downstream code, it appears
+* that the various PHYTIMING registers take the number
+* of cycles and use various dividers on them. This
+* calculation does not result in an exact match to the
+* downstream code, but it is very close, and it appears
+* to sync at a variety of resolutions. If someone
+* can get a more accurate mathematical equation needed
+* for these registers, this should be updated.
+*/
+
+ lpx = PS_TO_CYCLE(cfg.lpx, clock_in_hz);
+ hs_exit = PS_TO_CYCLE(cfg.hs_exit, clock_in_hz);
+ clk_prepare = PS_TO_CYCLE(cfg.clk_prepare, clock_in_hz);
+ clk_zero = PS_TO_CYCLE(cfg.clk_zero, clock_in_hz);
+ clk_post = PS_TO_CYCLE(cfg.clk_post, clock_in_hz);
+ clk_trail = PS_TO_CYCLE(cfg.clk_trail, clock_in_hz);
+ hs_prepare = PS_TO_CYCLE(cfg.hs_prepare, clock_in_hz);
+ hs_zero = PS_TO_CYCLE(cfg.hs_zero, clock_in_hz);
+ hs_trail = PS_TO_CYCLE(cfg.hs_trail, clock_in_hz);
+ }
+
/* B D-PHY: D-PHY Master & Slave Analog Block control */
reg = reg_values[PHYCTRL_ULPS_EXIT] | reg_values[PHYCTRL_VREG_LP] |
reg_values[PHYCTRL_SLEW_UP];
+
samsung_dsim_write(dsi, DSIM_PHYCTRL_REG, reg);
/*
@@ -712,7 +752,11 @@ static void samsung_dsim_set_phy_ctrl(struct samsung_dsim
*dsi)
* T HS-EXIT: Time that the transmitter drives LP-11 following a HS
* burst
*/
- reg = reg_values[PHYTIMING_LPX] | reg_values[PHYTIMING_HS_EXIT];
+ if (driver_data->dynamic_dphy)
+ reg = DSIM_PHYTIMING_LPX(lpx) |
DSIM_PHYTIMING_HS_EXIT(hs_exit);
+ else
+ reg = reg_values[PHYTIMING_LPX] | reg_values[PHYTIMING_HS_EXIT];
+
samsung_dsim_write(dsi, DSIM_PHYTIMING_REG, reg);
/*
@@ -728,10 +772,17 @@ static void samsung_dsim_set_phy_ctrl(struct samsung_dsim
*dsi)
* T CLK-TRAIL: Time that the transmitter drives the HS-0 state after
* the last payload clock bit of a HS transmission burst
*/
- reg = reg_values[PHYTIMING_CLK_PREPARE] |
- reg_values[PHYTIMING_CLK_ZERO] |
- reg_values[PHYTIMING_CLK_POST] |
- reg_values[PHYTIMING_CLK_TRAIL];
+
[PATCH V4 6/6] drm: bridge: samsung-dsim: Support non-burst mode
The high-speed clock is hard-coded to the burst-clock
frequency specified in the device tree. However, when
using devices like certain bridge chips without burst mode
and varying resolutions and refresh rates, it may be
necessary to set the high-speed clock dynamically based
on the desired pixel clock for the connected device.
This also removes the need to set a clock speed from
the device tree for non-burst mode operation, since the
pixel clock rate is the rate requested from the attached
device like a bridge chip. This should have no impact
for people using burst-mode and setting the burst clock
rate is still required for those users.
Lastly, if the burst clock is 0, and the clock is set
from the pixel clock, cache the clock rate configured
from of samsung_dsim_set_pll in order to properly
calculate the blanking.
Signed-off-by: Adam Ford
Tested-by: Chen-Yu Tsai
Tested-by: Frieder Schrempf
Reviewed-by: Frieder Schrempf
---
drivers/gpu/drm/bridge/samsung-dsim.c | 21 +
include/drm/bridge/samsung-dsim.h | 1 +
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 1b98c4e040b0..b79db009c98b 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -654,16 +654,28 @@ static unsigned long samsung_dsim_set_pll(struct
samsung_dsim *dsi,
reg = samsung_dsim_read(dsi, DSIM_STATUS_REG);
} while ((reg & DSIM_PLL_STABLE) == 0);
+ dsi->hs_clock = fout;
+
return fout;
}
static int samsung_dsim_enable_clock(struct samsung_dsim *dsi)
{
- unsigned long hs_clk, byte_clk, esc_clk;
+ unsigned long hs_clk, byte_clk, esc_clk, pix_clk;
unsigned long esc_div;
u32 reg;
+ struct drm_display_mode *m = >mode;
+ int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
+
+ /* m->clock is in KHz */
+ pix_clk = m->clock * 1000;
+
+ /* Use burst_clk_rate if available, otherwise use the pix_clk */
+ if (dsi->burst_clk_rate)
+ hs_clk = samsung_dsim_set_pll(dsi, dsi->burst_clk_rate);
+ else
+ hs_clk = samsung_dsim_set_pll(dsi, DIV_ROUND_UP(pix_clk * bpp,
dsi->lanes));
- hs_clk = samsung_dsim_set_pll(dsi, dsi->burst_clk_rate);
if (!hs_clk) {
dev_err(dsi->dev, "failed to configure DSI PLL\n");
return -EFAULT;
@@ -952,7 +964,7 @@ static void samsung_dsim_set_display_mode(struct
samsung_dsim *dsi)
u32 reg;
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
- int byte_clk_khz = dsi->burst_clk_rate / 1000 / 8;
+ int byte_clk_khz = dsi->hs_clock / 1000 / 8;
int hfp = (m->hsync_start - m->hdisplay) * byte_clk_khz /
m->clock;
int hbp = (m->htotal - m->hsync_end) * byte_clk_khz / m->clock;
int hsa = (m->hsync_end - m->hsync_start) * byte_clk_khz /
m->clock;
@@ -1801,10 +1813,11 @@ static int samsung_dsim_parse_dt(struct samsung_dsim
*dsi)
return PTR_ERR(pll_clk);
}
+ /* If it doesn't exist, use pixel clock instead of failing */
ret = samsung_dsim_of_read_u32(node, "samsung,burst-clock-frequency",
>burst_clk_rate);
if (ret < 0)
- return ret;
+ dsi->burst_clk_rate = 0;
ret = samsung_dsim_of_read_u32(node, "samsung,esc-clock-frequency",
>esc_clk_rate);
diff --git a/include/drm/bridge/samsung-dsim.h
b/include/drm/bridge/samsung-dsim.h
index 76ea8a1720cc..14176e6e9040 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -94,6 +94,7 @@ struct samsung_dsim {
u32 pll_clk_rate;
u32 burst_clk_rate;
+ u32 hs_clock;
u32 esc_clk_rate;
u32 lanes;
u32 mode_flags;
--
2.39.2
[PATCH V4 4/6] drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY
In order to support variable DPHY timings, it's necessary to enable GENERIC_PHY_MIPI_DPHY so phy_mipi_dphy_get_default_config can be used to determine the nominal values for a given resolution and refresh rate. Signed-off-by: Adam Ford Tested-by: Frieder Schrempf Reviewed-by: Frieder Schrempf --- drivers/gpu/drm/bridge/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index f076a09afac0..82c68b042444 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -227,6 +227,7 @@ config DRM_SAMSUNG_DSIM select DRM_KMS_HELPER select DRM_MIPI_DSI select DRM_PANEL_BRIDGE + select GENERIC_PHY_MIPI_DPHY help The Samsung MIPI DSIM bridge controller driver. This MIPI DSIM bridge can be found it on Exynos SoCs and -- 2.39.2
[PATCH V4 3/6] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically
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
Tested-by: Frieder Schrempf
Reviewed-by: Frieder Schrempf
---
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);
+ }
ret = samsung_dsim_of_read_u32(node, "samsung,burst-clock-frequency",
>burst_clk_rate);
--
2.39.2
[PATCH V4 2/6] drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp]
According to Table 13-45 of the i.MX8M Mini Reference Manual, the min
and max values for M and the frequency range for the VCO_out
calculator were incorrect. This information was contradicted in other
parts of the mini, nano and plus manuals. After reaching out to my
NXP Rep, when confronting him about discrepencies in the Nano manual,
he responded with:
"Yes it is definitely wrong, the one that is part
of the NOTE in MIPI_DPHY_M_PLLPMS register table against PMS_P,
PMS_M and PMS_S is not correct. I will report this to Doc team,
the one customer should be take into account is the Table 13-40
DPHY PLL Parameters and the Note above."
These updated values also match what is used in the NXP downstream
kernel.
To fix this, make new variables to hold the min and max values of m
and the minimum value of VCO_out, and update the PMS calculator to
use these new variables instead of using hard-coded values to keep
the backwards compatibility with other parts using this driver.
Fixes: 4d562c70c4dc ("drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support")
Signed-off-by: Adam Ford
Reviewed-by: Lucas Stach
Tested-by: Chen-Yu Tsai
Tested-by: Frieder Schrempf
Reviewed-by: Frieder Schrempf
---
drivers/gpu/drm/bridge/samsung-dsim.c | 22 --
include/drm/bridge/samsung-dsim.h | 3 +++
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 2be3b58624c3..bf4b33d2de76 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -405,6 +405,9 @@ static const struct samsung_dsim_driver_data
exynos3_dsi_driver_data = {
.num_bits_resol = 11,
.pll_p_offset = 13,
.reg_values = reg_values,
+ .m_min = 41,
+ .m_max = 125,
+ .min_freq = 500,
};
static const struct samsung_dsim_driver_data exynos4_dsi_driver_data = {
@@ -418,6 +421,9 @@ static const struct samsung_dsim_driver_data
exynos4_dsi_driver_data = {
.num_bits_resol = 11,
.pll_p_offset = 13,
.reg_values = reg_values,
+ .m_min = 41,
+ .m_max = 125,
+ .min_freq = 500,
};
static const struct samsung_dsim_driver_data exynos5_dsi_driver_data = {
@@ -429,6 +435,9 @@ static const struct samsung_dsim_driver_data
exynos5_dsi_driver_data = {
.num_bits_resol = 11,
.pll_p_offset = 13,
.reg_values = reg_values,
+ .m_min = 41,
+ .m_max = 125,
+ .min_freq = 500,
};
static const struct samsung_dsim_driver_data exynos5433_dsi_driver_data = {
@@ -441,6 +450,9 @@ static const struct samsung_dsim_driver_data
exynos5433_dsi_driver_data = {
.num_bits_resol = 12,
.pll_p_offset = 13,
.reg_values = exynos5433_reg_values,
+ .m_min = 41,
+ .m_max = 125,
+ .min_freq = 500,
};
static const struct samsung_dsim_driver_data exynos5422_dsi_driver_data = {
@@ -453,6 +465,9 @@ static const struct samsung_dsim_driver_data
exynos5422_dsi_driver_data = {
.num_bits_resol = 12,
.pll_p_offset = 13,
.reg_values = exynos5422_reg_values,
+ .m_min = 41,
+ .m_max = 125,
+ .min_freq = 500,
};
static const struct samsung_dsim_driver_data imx8mm_dsi_driver_data = {
@@ -469,6 +484,9 @@ static const struct samsung_dsim_driver_data
imx8mm_dsi_driver_data = {
*/
.pll_p_offset = 14,
.reg_values = imx8mm_dsim_reg_values,
+ .m_min = 64,
+ .m_max = 1023,
+ .min_freq = 1050,
};
static const struct samsung_dsim_driver_data *
@@ -547,12 +565,12 @@ static unsigned long samsung_dsim_pll_find_pms(struct
samsung_dsim *dsi,
tmp = (u64)fout * (_p << _s);
do_div(tmp, fin);
_m = tmp;
- if (_m < 41 || _m > 125)
+ if (_m < driver_data->m_min || _m > driver_data->m_max)
continue;
tmp = (u64)_m * fin;
do_div(tmp, _p);
- if (tmp < 500 * MHZ ||
+ if (tmp < driver_data->min_freq * MHZ ||
tmp > driver_data->max_freq * MHZ)
continue;
diff --git a/include/drm/bridge/samsung-dsim.h
b/include/drm/bridge/samsung-dsim.h
index ba5484de2b30..a1a5b2b89a7a 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -54,11 +54,14 @@ struct samsung_dsim_driver_data {
unsigned int has_freqband:1;
unsigned int has_clklane_stop:1;
unsigned int num_clks;
+ unsigned int min_freq;
unsigned int max_freq;
unsigned int wait_for_reset;
unsigned int num_bits_resol;
unsigned int pll_p_offset;
const unsigned int *reg_values;
+ u16 m_min;
+ u16 m_max;
};
struct samsung_dsim_host_ops {
--
2.39.2
[PATCH V4 1/6] drm: bridge: samsung-dsim: fix blanking packet size calculation
From: Lucas Stach
Scale the blanking packet sizes to match the ratio between HS clock
and DPI interface clock. The controller seems to do internal scaling
to the number of active lanes, so we don't take those into account.
Signed-off-by: Lucas Stach
Signed-off-by: Adam Ford
Tested-by: Chen-Yu Tsai
Tested-by: Frieder Schrempf
---
drivers/gpu/drm/bridge/samsung-dsim.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index e0a402a85787..2be3b58624c3 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -874,17 +874,29 @@ static void samsung_dsim_set_display_mode(struct
samsung_dsim *dsi)
u32 reg;
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
+ int byte_clk_khz = dsi->burst_clk_rate / 1000 / 8;
+ int hfp = (m->hsync_start - m->hdisplay) * byte_clk_khz /
m->clock;
+ int hbp = (m->htotal - m->hsync_end) * byte_clk_khz / m->clock;
+ int hsa = (m->hsync_end - m->hsync_start) * byte_clk_khz /
m->clock;
+
+ /* remove packet overhead when possible */
+ hfp = max(hfp - 6, 0);
+ hbp = max(hbp - 6, 0);
+ hsa = max(hsa - 6, 0);
+
+ dev_dbg(dsi->dev, "calculated hfp: %u, hbp: %u, hsa: %u",
+ hfp, hbp, hsa);
+
reg = DSIM_CMD_ALLOW(0xf)
| DSIM_STABLE_VFP(m->vsync_start - m->vdisplay)
| DSIM_MAIN_VBP(m->vtotal - m->vsync_end);
samsung_dsim_write(dsi, DSIM_MVPORCH_REG, reg);
- reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay)
- | DSIM_MAIN_HBP(m->htotal - m->hsync_end);
+ reg = DSIM_MAIN_HFP(hfp) | DSIM_MAIN_HBP(hbp);
samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
- | DSIM_MAIN_HSA(m->hsync_end - m->hsync_start);
+ | DSIM_MAIN_HSA(hsa);
samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
}
reg = DSIM_MAIN_HRESOL(m->hdisplay, num_bits_resol) |
--
2.39.2
[PATCH V4 0/6] drm: bridge: samsung-dsim: Support variable clocking
This series fixes the blanking pack size and the PMS calculation. It then adds support to allows the DSIM to dynamically DPHY clocks, and support non-burst mode while allowing the removal of the hard-coded clock values for the PLL for imx8m mini/nano/plus, and it allows the removal of the burst-clock device tree entry when burst-mode isn't supported by connected devices like an HDMI brige. In that event, the HS clock is set to the value requested by the bridge chip. This has been tested on both an i.MX8M Nano and i.MX8M Plus, and should work on i.MX8M Mini as well. Adam Ford (5): drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY drm: bridge: samsung-dsim: Dynamically configure DPHY timing drm: bridge: samsung-dsim: Support non-burst mode Lucas Stach (1): drm: bridge: samsung-dsim: fix blanking packet size calculation drivers/gpu/drm/bridge/Kconfig| 1 + drivers/gpu/drm/bridge/samsung-dsim.c | 145 +++--- include/drm/bridge/samsung-dsim.h | 5 + 3 files changed, 134 insertions(+), 17 deletions(-) --- V4: Undo some accidental whitespace changes, rename PS_TO_CYCLE variables to ps and hz from PS and MHz. Remove if check before the samsung_dsim_set_phy_ctrl call since it's unnecessary. Added additional tested-by and reviewed-by comments. Squash patches 6 and 7 together since the supporting non-burst (patch 6) mode doesn't really work until patch 7 was applied. V3: When checking if the bust-clock is present, only check for it in the device tree, and don't check the presence of the MIPI_DSI_MODE_VIDEO_BURST flag as it breaks an existing Exynos board. Add a new patch to the series to select GENERIC_PHY_MIPI_DPHY in Kconfig otherwise the build breaks on the 32-bit Exynos. Change vco_min variable name to min_freq Added tested-by from Chen-Yu Tsai V2: Instead of using my packet blanking calculation, this integrates on from Lucas Stach which gets modified later in the series to cache the value of the HS-clock instead of having to do the calucations again. Instead of completely eliminating the PLL clock frequency from the device tree, this makes it optional to avoid breaking some Samsung devices. When the samsung,pll-clock-frequency is not found, it reads the value of the clock named "sclk_mipi" This also maintains backwords compatibility with older device trees. This also changes the DPHY calcuation from a Look-up table, a reverse engineered algorithm which uses phy_mipi_dphy_get_default_config to determine the standard nominal values and calculates the cycles necessary to update the DPHY timings accordingly. -- 2.39.2
Re: [PATCH v3 05/12] dt-bindings: display/msm: Add SM6375 MDSS
On Fri, 05 May 2023 23:40:31 +0200, Konrad Dybcio wrote:
> Document the SM6375 MDSS.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6375-mdss.yaml | 216
> +
> 1 file changed, 216 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.example.dtb:
dsi@5e94000: compatible: 'oneOf' conditional failed, one must be fixed:
'qcom,sm6375-dsi-ctrl' is not one of ['qcom,apq8064-dsi-ctrl',
'qcom,msm8916-dsi-ctrl', 'qcom,msm8953-dsi-ctrl', 'qcom,msm8974-dsi-ctrl',
'qcom,msm8996-dsi-ctrl', 'qcom,msm8998-dsi-ctrl', 'qcom,qcm2290-dsi-ctrl',
'qcom,sc7180-dsi-ctrl', 'qcom,sc7280-dsi-ctrl', 'qcom,sdm660-dsi-ctrl',
'qcom,sdm845-dsi-ctrl', 'qcom,sm8150-dsi-ctrl', 'qcom,sm8250-dsi-ctrl',
'qcom,sm8350-dsi-ctrl', 'qcom,sm8450-dsi-ctrl', 'qcom,sm8550-dsi-ctrl']
'qcom,sm6375-dsi-ctrl' is not one of ['dsi-ctrl-6g-qcm2290']
From schema:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.example.dtb:
dsi@5e94000: Unevaluated properties are not allowed ('compatible' was
unexpected)
From schema:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230411-topic-straitlagoon_mdss-v3-5-9837d6b35...@linaro.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v3 04/12] dt-bindings: display/msm: Add SM6350 MDSS
On Fri, 05 May 2023 23:40:30 +0200, Konrad Dybcio wrote:
> Document the SM6350 MDSS.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6350-mdss.yaml | 214
> +
> 1 file changed, 214 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.example.dtb:
dsi@ae94000: compatible: 'oneOf' conditional failed, one must be fixed:
'qcom,sm6350-dsi-ctrl' is not one of ['qcom,apq8064-dsi-ctrl',
'qcom,msm8916-dsi-ctrl', 'qcom,msm8953-dsi-ctrl', 'qcom,msm8974-dsi-ctrl',
'qcom,msm8996-dsi-ctrl', 'qcom,msm8998-dsi-ctrl', 'qcom,qcm2290-dsi-ctrl',
'qcom,sc7180-dsi-ctrl', 'qcom,sc7280-dsi-ctrl', 'qcom,sdm660-dsi-ctrl',
'qcom,sdm845-dsi-ctrl', 'qcom,sm8150-dsi-ctrl', 'qcom,sm8250-dsi-ctrl',
'qcom,sm8350-dsi-ctrl', 'qcom,sm8450-dsi-ctrl', 'qcom,sm8550-dsi-ctrl']
'qcom,sm6350-dsi-ctrl' is not one of ['dsi-ctrl-6g-qcm2290']
From schema:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.example.dtb:
dsi@ae94000: Unevaluated properties are not allowed ('compatible' was
unexpected)
From schema:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230411-topic-straitlagoon_mdss-v3-4-9837d6b35...@linaro.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Re: [RFC] Plane color pipeline KMS uAPI
On Fri, May 5, 2023 at 10:40 PM Dave Airlie wrote: > > On Fri, 5 May 2023 at 01:23, 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. > > > > 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. > > I'm not 100% sold on the prescriptive here, let's see if someone can > get me over the line with some questions later. > > My feeling is color pipeline hw is not a done deal, and that hw > vendors will be revising/evolving/churning the hw blocks for a while > longer, as there is no real standards in the area to aim for, all the > vendors are mostly just doing whatever gets Windows over the line and > keeps hw engineers happy. So I have some concerns here around forwards > compatibility and hence the API design. > > I guess my main concern is if you expose a bunch of hw blocks and > someone comes up with a novel new thing, will all existing userspace > work, without falling back to shaders? > Do we have minimum guarantees on what hardware blocks have to be > exposed to build a useable pipeline? > If a hardware block goes away in a new silicon revision, do I have to > rewrite my compositor? or will it be expected that the kernel will > emulate the old pipelines on top of whatever new fancy thing exists. I think there are two answers to those questions. The first one is that right now KMS already doesn't guarantee that every property is supported on all hardware. The guarantee we have is that properties that are supported on a piece of hardware on a specific kernel will be supported on the same hardware on later kernels. The color pipeline is no different here. For a specific piece of hardware a newer kernel might only change the pipelines in a backwards compatible way and add new pipelines. So to answer your question: if some hardware with a novel pipeline will show up it might not be supported and that's fine. We already have cases where some hardware does not support the gamma lut property but only the CSC property and that breaks night light because we never bothered to write a shader fallback. KMS provides ways to offload work but a generic user space always has to provide a fallback and this doesn't change. Hardware specific user space on the other hand will keep working with the forward compatibility guarantees we want to provide. The second answer is that we want to provide a user space library which takes a description of a color pipeline and tries to map that to the available KMS color pipelines. If there is a novel color operation, adding support in this library would then make it possible to offload compatible color pipelines on this new hardware for all consumers of the library. Obviously there is no guarantee that whatever color pipeline compositors come up with can actually be realized on specific hardware but that's just an inherent hardware issue. > We are not Android, or even Steam OS on a Steamdeck, we have to be > able to independently update the kernel for new hardware and not > require every compositor currently providing HDR to need to support > new hardware blocks and models at the same time. > > Dave. >
Re: [PATCH v2 1/4] drm/msm/dsi: Adjust pclk rate for compression
On 5/5/2023 2:23 PM, Jessica Zhang wrote:
Adjust the pclk rate to divide hdisplay by the compression ratio when DSC
is enabled.
Changes in v2:
- Adjusted pclk_rate math to divide only the hdisplay value by
compression ratio
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 17 +
1 file changed, 13 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..0e5778e8091f 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,
+ struct drm_dsc_config *dsc, bool is_bonded_dsi)
{
unsigned long pclk_rate;
@@ -576,6 +577,14 @@ 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 hdisplay by compression ratio */
+ if (dsc) {
+ int new_hdisplay = DIV_ROUND_UP(mode->hdisplay *
msm_dsc_get_bpp_int(dsc),
+ dsc->bits_per_component * 3);
+ int fps = DIV_ROUND_UP(pclk_rate, mode->htotal * mode->vtotal);
Should've used drm_mode_vrefresh() here... Will spin a v3 with that
change (along with any additional comments)
+ pclk_rate = (new_hdisplay + (mode->htotal - mode->hdisplay)) *
mode->vtotal * fps;
+ }
+
return pclk_rate;
}
@@ -585,7 +594,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 pclk_rate = dsi_get_pclk_rate(mode, msm_host->dsc,
is_bonded_dsi);
u64 pclk_bpp = (u64)pclk_rate * bpp;
if (lanes == 0) {
@@ -604,7 +613,7 @@ unsigned long dsi_byte_clk_get_rate(struct mipi_dsi_host
*host, bool is_bonded_d
static void dsi_calc_pclk(struct msm_dsi_host *msm_host, bool is_bonded_dsi)
{
- msm_host->pixel_clk_rate = dsi_get_pclk_rate(msm_host->mode,
is_bonded_dsi);
+ msm_host->pixel_clk_rate = dsi_get_pclk_rate(msm_host->mode,
msm_host->dsc, is_bonded_dsi);
msm_host->byte_clk_rate = dsi_byte_clk_get_rate(_host->base,
is_bonded_dsi,
msm_host->mode);
@@ -634,7 +643,7 @@ int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host, bool is_bonded_dsi)
dsi_calc_pclk(msm_host, is_bonded_dsi);
- pclk_bpp = (u64)dsi_get_pclk_rate(msm_host->mode, is_bonded_dsi) * bpp;
+ pclk_bpp = (u64)dsi_get_pclk_rate(msm_host->mode, msm_host->dsc,
is_bonded_dsi) * bpp;
do_div(pclk_bpp, 8);
msm_host->src_clk_rate = pclk_bpp;
--
2.40.1
Re: [PATCH v2 1/2] dt-bindings: display: novatek,nt35950: define ports
On Tue, May 02, 2023 at 02:00:35PM +0200, Krzysztof Kozlowski wrote: > The panel-common schema does not define what "ports" property is, so > bring the definition to enforce the type. Panels can be single- or > dual-link, thus require only one port@0. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changes since v1: > 1. Rework to add ports to device schema, not to panel-common. > https://lore.kernel.org/all/20230420160905.ga2952736-r...@kernel.org/ > --- > .../bindings/display/panel/novatek,nt35950.yaml | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml > b/Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml > index 377a05d48a02..c93cc1018b41 100644 > --- a/Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml > +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml > @@ -47,8 +47,13 @@ properties: >vddio-supply: > description: regulator that supplies the I/O voltage > > + ports: > +$ref: /schemas/graph.yaml#/properties/ports Similarly needed on this one. Perhaps what you want here is a dual-link panel schema? > + > +required: > + - port@0 > + >backlight: true > - ports: true >reg: true > > required: > @@ -59,6 +64,7 @@ required: >- avee-supply >- dvdd-supply >- vddio-supply > + - ports > > additionalProperties: false > > -- > 2.34.1 >
Re: [PATCH v2 2/2] dt-bindings: display: novatek,nt36523: define ports
On Tue, May 02, 2023 at 02:00:36PM +0200, Krzysztof Kozlowski wrote: > The panel-common schema does not define what "ports" property is, so > bring the definition to enforce the type. All panels described by > binding are dual-link, thus require both ports. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changes since v1: > 1. Rework to add ports to device schema, not to panel-common. > https://lore.kernel.org/all/20230420160905.ga2952736-r...@kernel.org/ > --- > .../bindings/display/panel/novatek,nt36523.yaml | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml > b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml > index 0039561ef04c..a2a8c4e39573 100644 > --- a/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml > +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml > @@ -32,8 +32,14 @@ properties: >vddio-supply: > description: regulator that supplies the I/O voltage > > + ports: > +$ref: /schemas/graph.yaml#/properties/ports > + > +required: > + - port@0 > + - port@1 What is each port? You need: additionalProperties: false properties: port@0: $ref: ... description: ... port@1: $ref: ... description: ...
[PATCH v3 12/12] iommu/arm-smmu-qcom: Add SM6350 DPU compatible
From: Konrad Dybcio
Add the SM6350 DPU compatible to clients compatible list, as it also
needs the workarounds.
Signed-off-by: Konrad Dybcio
Acked-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index d7d5d1dbee17..e64c737724c4 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -253,6 +253,7 @@ static const struct of_device_id
qcom_smmu_client_of_match[] __maybe_unused = {
{ .compatible = "qcom,sc8280xp-mdss" },
{ .compatible = "qcom,sdm845-mdss" },
{ .compatible = "qcom,sdm845-mss-pil" },
+ { .compatible = "qcom,sm6350-mdss" },
{ .compatible = "qcom,sm6375-mdss" },
{ .compatible = "qcom,sm8150-mdss" },
{ .compatible = "qcom,sm8250-mdss" },
--
2.40.1
[PATCH v3 11/12] iommu/arm-smmu-qcom: Add SM6375 DPU compatible
Add the SM6375 DPU compatible to clients compatible list, as it also
needs the workarounds.
Acked-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index f945ae3d9d06..d7d5d1dbee17 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -253,6 +253,7 @@ static const struct of_device_id
qcom_smmu_client_of_match[] __maybe_unused = {
{ .compatible = "qcom,sc8280xp-mdss" },
{ .compatible = "qcom,sdm845-mdss" },
{ .compatible = "qcom,sdm845-mss-pil" },
+ { .compatible = "qcom,sm6375-mdss" },
{ .compatible = "qcom,sm8150-mdss" },
{ .compatible = "qcom,sm8250-mdss" },
{ }
--
2.40.1
[PATCH v3 10/12] iommu/arm-smmu-qcom: Sort the compatible list alphabetically
It got broken at some point, fix it up.
Signed-off-by: Konrad Dybcio
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index ae09c627bc84..f945ae3d9d06 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -251,10 +251,10 @@ static const struct of_device_id
qcom_smmu_client_of_match[] __maybe_unused = {
{ .compatible = "qcom,sc7280-mss-pil" },
{ .compatible = "qcom,sc8180x-mdss" },
{ .compatible = "qcom,sc8280xp-mdss" },
- { .compatible = "qcom,sm8150-mdss" },
- { .compatible = "qcom,sm8250-mdss" },
{ .compatible = "qcom,sdm845-mdss" },
{ .compatible = "qcom,sdm845-mss-pil" },
+ { .compatible = "qcom,sm8150-mdss" },
+ { .compatible = "qcom,sm8250-mdss" },
{ }
};
--
2.40.1
[PATCH v3 09/12] drm/msm: mdss: Add SM6375 support
Add support for MDSS on SM6375.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/msm_mdss.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 4e3a5f0c303c..05648c910c68 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -580,6 +580,7 @@ static const struct of_device_id mdss_dt_match[] = {
{ .compatible = "qcom,sc8280xp-mdss", .data = _data },
{ .compatible = "qcom,sm6115-mdss", .data = _data },
{ .compatible = "qcom,sm6350-mdss", .data = _data },
+ { .compatible = "qcom,sm6375-mdss", .data = _data },
{ .compatible = "qcom,sm8150-mdss", .data = _data },
{ .compatible = "qcom,sm8250-mdss", .data = _data },
{ .compatible = "qcom,sm8350-mdss", .data = _data },
--
2.40.1
[PATCH v3 05/12] dt-bindings: display/msm: Add SM6375 MDSS
Document the SM6375 MDSS.
Signed-off-by: Konrad Dybcio
---
.../bindings/display/msm/qcom,sm6375-mdss.yaml | 216 +
1 file changed, 216 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml
new file mode 100644
index ..fb56971ea2a1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml
@@ -0,0 +1,216 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm6375-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6375 Display MDSS
+
+maintainers:
+ - Konrad Dybcio
+
+description:
+ SM6375 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks
+ like DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+items:
+ - const: qcom,sm6375-mdss
+
+ clocks:
+items:
+ - description: Display AHB clock from gcc
+ - description: Display AHB clock
+ - description: Display core clock
+
+ clock-names:
+items:
+ - const: iface
+ - const: ahb
+ - const: core
+
+ iommus:
+maxItems: 1
+
+ interconnects:
+maxItems: 2
+
+ interconnect-names:
+maxItems: 2
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+type: object
+properties:
+ compatible:
+const: qcom,sm6375-dpu
+
+ "^dsi@[0-9a-f]+$":
+type: object
+properties:
+ compatible:
+items:
+ - const: qcom,sm6375-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+type: object
+properties:
+ compatible:
+const: qcom,sm6375-dsi-phy-7nm
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+#include
+
+display-subsystem@5e0 {
+compatible = "qcom,sm6375-mdss";
+reg = <0x05e0 0x1000>;
+reg-names = "mdss";
+
+power-domains = < MDSS_GDSC>;
+
+clocks = < GCC_DISP_AHB_CLK>,
+ < DISP_CC_MDSS_AHB_CLK>,
+ < DISP_CC_MDSS_MDP_CLK>;
+clock-names = "iface", "ahb", "core";
+
+interrupts = ;
+interrupt-controller;
+#interrupt-cells = <1>;
+
+iommus = <_smmu 0x820 0x2>;
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+
+display-controller@5e01000 {
+compatible = "qcom,sm6375-dpu";
+reg = <0x05e01000 0x8e030>,
+ <0x05eb 0x2008>;
+reg-names = "mdp", "vbif";
+
+clocks = < DISP_CC_MDSS_AHB_CLK>,
+ < GCC_DISP_HF_AXI_CLK>,
+ < DISP_CC_MDSS_MDP_CLK>,
+ < DISP_CC_MDSS_MDP_LUT_CLK>,
+ < DISP_CC_MDSS_ROT_CLK>,
+ < DISP_CC_MDSS_VSYNC_CLK>,
+ < GCC_DISP_THROTTLE_CORE_CLK>;
+clock-names = "iface",
+ "bus",
+ "core",
+ "lut",
+ "rot",
+ "vsync",
+ "throttle";
+
+assigned-clocks = < DISP_CC_MDSS_VSYNC_CLK>;
+assigned-clock-rates = <1920>;
+
+operating-points-v2 = <_opp_table>;
+power-domains = < SM6375_VDDCX>;
+
+interrupt-parent = <>;
+interrupts = <0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+dpu_intf1_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+
+port@1 {
+reg = <1>;
+dpu_intf2_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
+
+dsi@5e94000 {
+compatible = "qcom,sm6375-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+reg = <0x05e94000 0x400>;
+reg-names = "dsi_ctrl";
+
+interrupt-parent = <>;
+interrupts = <4>;
+
+clocks = < DISP_CC_MDSS_BYTE0_CLK>,
+ < DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ < DISP_CC_MDSS_PCLK0_CLK>,
+ < DISP_CC_MDSS_ESC0_CLK>,
+ < DISP_CC_MDSS_AHB_CLK>,
+ < GCC_DISP_HF_AXI_CLK>;
+clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+assigned-clocks = < DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <
[PATCH v3 08/12] drm/msm/dpu: Add SM6375 support
Add basic SM6375 support to the DPU1 driver to enable display output.
Signed-off-by: Konrad Dybcio
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h | 152 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 +
4 files changed, 155 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h
new file mode 100644
index ..c7f303b0557e
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h
@@ -0,0 +1,152 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022. Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+#ifndef _DPU_6_9_SM6375_H
+#define _DPU_6_9_SM6375_H
+
+static const struct dpu_caps sm6375_dpu_caps = {
+ .max_mixer_width = DEFAULT_DPU_LINE_WIDTH,
+ .max_mixer_blendstages = 0x4,
+ .qseed_type = DPU_SSPP_SCALER_QSEED4,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .max_linewidth = 2160,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+};
+
+static const struct dpu_ubwc_cfg sm6375_ubwc_cfg = {
+ .ubwc_version = DPU_HW_UBWC_VER_20,
+ .ubwc_swizzle = 6,
+ .highest_bank_bit = 1,
+};
+
+static const struct dpu_mdp_cfg sm6375_mdp[] = {
+ {
+ .name = "top_0", .id = MDP_TOP,
+ .base = 0x0, .len = 0x494,
+ .features = 0,
+ .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
+ .clk_ctrls[DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
+ },
+};
+
+static const struct dpu_ctl_cfg sm6375_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x1000, .len = 0x1dc,
+ .features = BIT(DPU_CTL_ACTIVE_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+ },
+};
+
+static const struct dpu_sspp_cfg sm6375_sspp[] = {
+ SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, 0x1f8, VIG_SC7180_MASK,
+ sm6115_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
+ SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, 0x1f8, DMA_SDM845_MASK,
+ sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
+};
+
+static const struct dpu_lm_cfg sm6375_lm[] = {
+ LM_BLK("lm_0", LM_0, 0x44000, MIXER_QCM2290_MASK,
+ _lm_sblk, PINGPONG_0, 0, DSPP_0),
+};
+
+static const struct dpu_dspp_cfg sm6375_dspp[] = {
+ DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_SC7180_MASK,
+ _dspp_sblk),
+};
+
+static const struct dpu_pingpong_cfg sm6375_pp[] = {
+ PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SM8150_MASK, 0,
sdm845_pp_sblk,
+ DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
+ -1),
+};
+
+static const struct dpu_intf_cfg sm6375_intf[] = {
+ INTF_BLK("intf_0", INTF_0, 0x0, 0x2c0, INTF_NONE, 0, 0, 0, 0, 0),
+ INTF_BLK_DSI_TE("intf_1", INTF_1, 0x6a800, 0x2c0, INTF_DSI, 0, 24,
INTF_SC7280_MASK,
+ DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
+ DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27),
+ DPU_IRQ_IDX(MDP_INTF1_TEAR_INTR, 2)),
+};
+
+static const struct dpu_vbif_cfg sm6375_vbif[] = {
+ {
+ .name = "vbif_0", .id = VBIF_RT,
+ .base = 0, .len = 0x2008,
+ .features = BIT(DPU_VBIF_QOS_REMAP),
+ .xin_halt_timeout = 0x4000,
+ .qos_rp_remap_size = 0x40,
+ .qos_rt_tbl = {
+ .npriority_lvl = ARRAY_SIZE(sdm845_rt_pri_lvl),
+ .priority_lvl = sdm845_rt_pri_lvl,
+ },
+ .qos_nrt_tbl = {
+ .npriority_lvl = ARRAY_SIZE(sdm845_nrt_pri_lvl),
+ .priority_lvl = sdm845_nrt_pri_lvl,
+ },
+ .memtype_count = 14,
+ .memtype = {3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3},
+ },
+};
+
+static const struct dpu_perf_cfg sm6375_perf_data = {
+ .max_bw_low = 520,
+ .max_bw_high = 620,
+ .min_core_ib = 250,
+ .min_llcc_ib = 0, /* No LLCC on this SoC */
+ .min_dram_ib = 160,
+ .min_prefill_lines = 24,
+ /* TODO: confirm danger_lut_tbl */
+ .danger_lut_tbl = {0x, 0x, 0x0, 0x0, 0x},
+ .qos_lut_tbl = {
+ {.nentry = ARRAY_SIZE(sm6350_qos_linear_macrotile),
+ .entries = sm6350_qos_linear_macrotile
+ },
+ {.nentry = ARRAY_SIZE(sm6350_qos_linear_macrotile),
+ .entries = sm6350_qos_linear_macrotile
+ },
+ {.nentry = ARRAY_SIZE(sc7180_qos_nrt),
+ .entries = sc7180_qos_nrt
+ },
+ },
+ .cdp_cfg = {
+ {.rd_enable = 1, .wr_enable = 1},
+ {.rd_enable = 1, .wr_enable = 0}
+ },
+ .clk_inefficiency_factor = 105,
+
[PATCH v3 06/12] drm/msm/dpu: Add SM6350 support
Add SM6350 support to the DPU1 driver to enable display output.
It's worth noting that one entry dpu_qos_lut_entry was trimmed off:
{.fl = 0, .lut = 0x0011223344556677 },
due to the fact that newer SoCs dropped the .fl (fill level)-based
logic and don't provide real values, resulting in all entries but
the last one being unused.
Signed-off-by: Konrad Dybcio
Reviewed-by: Marijn Suijten
Signed-off-by: Konrad Dybcio
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h | 187 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 5 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 3 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 +
4 files changed, 196 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
new file mode 100644
index ..e8bfbd468e0a
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h
@@ -0,0 +1,187 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022. Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+#ifndef _DPU_6_4_SM6350_H
+#define _DPU_6_4_SM6350_H
+
+static const struct dpu_caps sm6350_dpu_caps = {
+ .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .max_mixer_blendstages = 0x7,
+ .qseed_type = DPU_SSPP_SCALER_QSEED4,
+ .has_src_split = true,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+};
+
+static const struct dpu_ubwc_cfg sm6350_ubwc_cfg = {
+ .ubwc_version = DPU_HW_UBWC_VER_20,
+ .ubwc_swizzle = 6,
+ .highest_bank_bit = 1,
+};
+
+static const struct dpu_mdp_cfg sm6350_mdp[] = {
+ {
+ .name = "top_0", .id = MDP_TOP,
+ .base = 0x0, .len = 0x494,
+ .features = 0,
+ .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
+ .clk_ctrls[DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
+ .clk_ctrls[DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8 },
+ .clk_ctrls[DPU_CLK_CTRL_DMA2] = { .reg_off = 0x2c4, .bit_off = 8 },
+ .clk_ctrls[DPU_CLK_CTRL_REG_DMA] = { .reg_off = 0x2bc, .bit_off = 20 },
+ },
+};
+
+static const struct dpu_ctl_cfg sm6350_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x1000, .len = 0x1dc,
+ .features = BIT(DPU_CTL_ACTIVE_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+ },
+ {
+ .name = "ctl_1", .id = CTL_1,
+ .base = 0x1200, .len = 0x1dc,
+ .features = BIT(DPU_CTL_ACTIVE_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
+ },
+ {
+ .name = "ctl_2", .id = CTL_2,
+ .base = 0x1400, .len = 0x1dc,
+ .features = BIT(DPU_CTL_ACTIVE_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
+ },
+ {
+ .name = "ctl_3", .id = CTL_3,
+ .base = 0x1600, .len = 0x1dc,
+ .features = BIT(DPU_CTL_ACTIVE_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
+ },
+};
+
+static const struct dpu_sspp_cfg sm6350_sspp[] = {
+ SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, 0x1f8, VIG_SC7180_MASK,
+ sc7180_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
+ SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, 0x1f8, DMA_SDM845_MASK,
+ sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
+ SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, 0x1f8, DMA_CURSOR_SDM845_MASK,
+ sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA1),
+ SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, 0x1f8, DMA_CURSOR_SDM845_MASK,
+ sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA2),
+};
+
+static const struct dpu_lm_cfg sm6350_lm[] = {
+ LM_BLK("lm_0", LM_0, 0x44000, MIXER_SDM845_MASK,
+ _lm_sblk, PINGPONG_0, LM_1, DSPP_0),
+ LM_BLK("lm_1", LM_1, 0x45000, MIXER_SDM845_MASK,
+ _lm_sblk, PINGPONG_1, LM_0, 0),
+};
+
+static const struct dpu_dspp_cfg sm6350_dspp[] = {
+ DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_SC7180_MASK,
+ _dspp_sblk),
+};
+
+static struct dpu_pingpong_cfg sm6350_pp[] = {
+ PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SM8150_MASK, 0,
sdm845_pp_sblk,
+ DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
+ -1),
+ PP_BLK("pingpong_1", PINGPONG_1, 0x70800, PINGPONG_SM8150_MASK, 0,
sdm845_pp_sblk,
+ DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
+ -1),
+};
+
+static const struct dpu_intf_cfg sm6350_intf[] = {
+ INTF_BLK("intf_0", INTF_0, 0x6a000, 0x2c0, INTF_DP, 0, 35,
INTF_SC7180_MASK,
+ DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
+ DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 25)),
+
[PATCH v3 07/12] drm/msm: mdss: Add SM6350 support
Add support for MDSS on SM6350.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/msm_mdss.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index e8c93731aaa1..4e3a5f0c303c 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -538,6 +538,14 @@ static const struct msm_mdss_data sdm845_data = {
.highest_bank_bit = 2,
};
+static const struct msm_mdss_data sm6350_data = {
+ .ubwc_version = UBWC_2_0,
+ .ubwc_dec_version = UBWC_2_0,
+ .ubwc_swizzle = 6,
+ .ubwc_static = 0x1e,
+ .highest_bank_bit = 1,
+};
+
static const struct msm_mdss_data sm8150_data = {
.ubwc_version = UBWC_3_0,
.ubwc_dec_version = UBWC_3_0,
@@ -571,6 +579,7 @@ static const struct of_device_id mdss_dt_match[] = {
{ .compatible = "qcom,sc8180x-mdss", .data = _data },
{ .compatible = "qcom,sc8280xp-mdss", .data = _data },
{ .compatible = "qcom,sm6115-mdss", .data = _data },
+ { .compatible = "qcom,sm6350-mdss", .data = _data },
{ .compatible = "qcom,sm8150-mdss", .data = _data },
{ .compatible = "qcom,sm8250-mdss", .data = _data },
{ .compatible = "qcom,sm8350-mdss", .data = _data },
--
2.40.1
[PATCH v3 03/12] dt-bindings: display/msm: sc7180-dpu: Describe SM6350 and SM6375
SC7180, SM6350 and SM6375 use a rather similar hw setup for DPU, with the main exception being that the last one requires an additional throttle clock. It is not well understood yet, but failing to toggle it on makes the display hardware stall and not output any frames. Document SM6350 and SM6375 DPU. Signed-off-by: Konrad Dybcio --- .../bindings/display/msm/qcom,sc7180-dpu.yaml | 23 +- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml index 1fb8321d9ee8..630b11480496 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml @@ -13,7 +13,10 @@ $ref: /schemas/display/msm/dpu-common.yaml# properties: compatible: -const: qcom,sc7180-dpu +enum: + - qcom,sc7180-dpu + - qcom,sm6350-dpu + - qcom,sm6375-dpu reg: items: @@ -26,6 +29,7 @@ properties: - const: vbif clocks: +minItems: 6 items: - description: Display hf axi clock - description: Display ahb clock @@ -33,8 +37,10 @@ properties: - description: Display lut clock - description: Display core clock - description: Display vsync clock + - description: Display core throttle clock clock-names: +minItems: 6 items: - const: bus - const: iface @@ -42,6 +48,7 @@ properties: - const: lut - const: core - const: vsync + - const: throttle required: - compatible @@ -52,6 +59,20 @@ required: unevaluatedProperties: false +allOf: + - if: + properties: +compatible: + const: qcom,sm6375-dpu + +then: + properties: +clocks: + minItems: 7 + +clock-names: + minItems: 7 + examples: - | #include -- 2.40.1
[PATCH v3 04/12] dt-bindings: display/msm: Add SM6350 MDSS
Document the SM6350 MDSS.
Signed-off-by: Konrad Dybcio
---
.../bindings/display/msm/qcom,sm6350-mdss.yaml | 214 +
1 file changed, 214 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
new file mode 100644
index ..6674040d2172
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
@@ -0,0 +1,214 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm6350-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6350 Display MDSS
+
+maintainers:
+ - Krishna Manikandan
+
+description:
+ SM6350 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks
+ like DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+items:
+ - const: qcom,sm6350-mdss
+
+ clocks:
+items:
+ - description: Display AHB clock from gcc
+ - description: Display AXI clock from gcc
+ - description: Display core clock
+
+ clock-names:
+items:
+ - const: iface
+ - const: bus
+ - const: core
+
+ iommus:
+maxItems: 1
+
+ interconnects:
+maxItems: 2
+
+ interconnect-names:
+maxItems: 2
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+type: object
+properties:
+ compatible:
+const: qcom,sm6350-dpu
+
+ "^dsi@[0-9a-f]+$":
+type: object
+properties:
+ compatible:
+items:
+ - const: qcom,sm6350-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+type: object
+properties:
+ compatible:
+const: qcom,dsi-phy-10nm
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+#include
+
+display-subsystem@ae0 {
+compatible = "qcom,sm6350-mdss";
+reg = <0x0ae0 0x1000>;
+reg-names = "mdss";
+
+power-domains = < MDSS_GDSC>;
+
+clocks = < GCC_DISP_AHB_CLK>,
+ < GCC_DISP_AXI_CLK>,
+ < DISP_CC_MDSS_MDP_CLK>;
+clock-names = "iface", "bus", "core";
+
+interrupts = ;
+interrupt-controller;
+#interrupt-cells = <1>;
+
+iommus = <_smmu 0x800 0x2>;
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+
+display-controller@ae01000 {
+compatible = "qcom,sm6350-dpu";
+reg = <0x0ae01000 0x8f000>,
+ <0x0aeb 0x2008>;
+reg-names = "mdp", "vbif";
+
+clocks = < GCC_DISP_AXI_CLK>,
+ < DISP_CC_MDSS_AHB_CLK>,
+ < DISP_CC_MDSS_ROT_CLK>,
+ < DISP_CC_MDSS_MDP_LUT_CLK>,
+ < DISP_CC_MDSS_MDP_CLK>,
+ < DISP_CC_MDSS_VSYNC_CLK>;
+clock-names = "bus", "iface", "rot", "lut", "core",
+"vsync";
+
+assigned-clocks = < DISP_CC_MDSS_MDP_CLK>,
+ < DISP_CC_MDSS_VSYNC_CLK>,
+ < DISP_CC_MDSS_ROT_CLK>,
+ < DISP_CC_MDSS_AHB_CLK>;
+assigned-clock-rates = <3>,
+ <1920>,
+ <1920>,
+ <1920>;
+
+interrupt-parent = <>;
+interrupts = <0>;
+operating-points-v2 = <_opp_table>;
+power-domains = < SM6350_CX>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+dpu_intf1_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+
+port@1 {
+reg = <1>;
+dpu_intf2_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
+
+dsi@ae94000 {
+compatible = "qcom,sm6350-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+reg = <0x0ae94000 0x400>;
+reg-names = "dsi_ctrl";
+
+interrupt-parent = <>;
+interrupts = <4>;
+
+clocks = < DISP_CC_MDSS_BYTE0_CLK>,
+ < DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ < DISP_CC_MDSS_PCLK0_CLK>,
+ < DISP_CC_MDSS_ESC0_CLK>,
+ < DISP_CC_MDSS_AHB_CLK>,
+ < GCC_DISP_AXI_CLK>;
+clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+assigned-clocks = <
[PATCH v3 01/12] dt-bindings: display/msm: dsi-controller-main: Add SM6350
Add the DSI host found on SM6350. Acked-by: Rob Herring Signed-off-by: Konrad Dybcio --- Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index e6c1ebfe8a32..6f367a1fabf8 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -26,6 +26,7 @@ properties: - qcom,sdm660-dsi-ctrl - qcom,sdm845-dsi-ctrl - qcom,sm6115-dsi-ctrl + - qcom,sm6350-dsi-ctrl - qcom,sm8150-dsi-ctrl - qcom,sm8250-dsi-ctrl - qcom,sm8350-dsi-ctrl @@ -285,6 +286,7 @@ allOf: contains: enum: - qcom,msm8998-dsi-ctrl + - qcom,sm6350-dsi-ctrl then: properties: clocks: -- 2.40.1
[PATCH v3 00/12] SM63(50|75) DPU support
v2 -> v3: - Don't duplicate qcm2290_lm_sblk - Use DEFAULT_DPU_LINE_WIDTH defines - Fix up sspp clk assignments for sm6350 - Add 6350-6375-common QoS data straight to the common file instead of moving it around after adding it - Fix up iommu compatible order before adding new entries - Reuse sm6350 msm_mdss_data for sm6375 - INTF_SC7180_MASK -> INTF_SC7280_MASK (enable HCTL) on 6375 - use double tabs in catalog headers - remove one unused entry in 6350 dpu_qos_lut_entry - add missing tear IRQs, drop INTF0 irq on 6375 - don't overduplicate DPU bindings, reuse 7180 - Pick up tags - Rebase on INTF_TE v4 and next-20230504 Depends on: - https://lore.kernel.org/linux-arm-msm/20230411-dpu-intf-te-v4-0-27ce1a5ab...@somainline.org/ v2: https://lore.kernel.org/r/20230411-topic-straitlagoon_mdss-v2-0-5def73f50...@linaro.org v1 -> v2: - Rebase on the DPU catalog rework and INTF_TE - Fix QSEED(3L/4) discrepancies - Fixed DMA/cursor discrepancies for 6350 - No deduplication, that's gonna be handled in catalogrework 2: "the return of the catalogrework" - Split MDSS & DPU binding additions - Drop "Allow variable SSPP/INTF_BLK size", that got in w/ the rework - Split MDSS and DPU additions - Pick up Rob's acks Depends on (and based on): https://lore.kernel.org/linux-arm-msm/20230411-dpu-intf-te-v2-0-ef76c877e...@somainline.org/T/#t v1: https://lore.kernel.org/linux-arm-msm/20230211122656.1479141-1-konrad.dyb...@linaro.org/ Signed-off-by: Konrad Dybcio --- Konrad Dybcio (12): dt-bindings: display/msm: dsi-controller-main: Add SM6350 dt-bindings: display/msm: dsi-controller-main: Add SM6375 dt-bindings: display/msm: sc7180-dpu: Describe SM6350 and SM6375 dt-bindings: display/msm: Add SM6350 MDSS dt-bindings: display/msm: Add SM6375 MDSS drm/msm/dpu: Add SM6350 support drm/msm: mdss: Add SM6350 support drm/msm/dpu: Add SM6375 support drm/msm: mdss: Add SM6375 support iommu/arm-smmu-qcom: Sort the compatible list alphabetically iommu/arm-smmu-qcom: Add SM6375 DPU compatible iommu/arm-smmu-qcom: Add SM6350 DPU compatible .../bindings/display/msm/dsi-controller-main.yaml | 4 + .../bindings/display/msm/qcom,sc7180-dpu.yaml | 23 ++- .../bindings/display/msm/qcom,sm6350-mdss.yaml | 214 .../bindings/display/msm/qcom,sm6375-mdss.yaml | 216 + .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h | 187 ++ .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h | 152 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 2 + drivers/gpu/drm/msm/msm_mdss.c | 10 + drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 6 +- 11 files changed, 821 insertions(+), 3 deletions(-) --- base-commit: 0d71ecbdb3913e04dcf7f4de0929970cfb4376cb change-id: 20230411-topic-straitlagoon_mdss-8f34cacd5e26 Best regards, -- Konrad Dybcio
[PATCH v3 02/12] dt-bindings: display/msm: dsi-controller-main: Add SM6375
Add the DSI host found on SM6375. Acked-by: Rob Herring Signed-off-by: Konrad Dybcio --- Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 6f367a1fabf8..f7dc05a65420 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -27,6 +27,7 @@ properties: - qcom,sdm845-dsi-ctrl - qcom,sm6115-dsi-ctrl - qcom,sm6350-dsi-ctrl + - qcom,sm6375-dsi-ctrl - qcom,sm8150-dsi-ctrl - qcom,sm8250-dsi-ctrl - qcom,sm8350-dsi-ctrl @@ -354,6 +355,7 @@ allOf: enum: - qcom,sdm845-dsi-ctrl - qcom,sm6115-dsi-ctrl + - qcom,sm6375-dsi-ctrl then: properties: clocks: -- 2.40.1
[PATCH v2 1/4] drm/msm/dsi: Adjust pclk rate for compression
Adjust the pclk rate to divide hdisplay by the compression ratio when DSC
is enabled.
Changes in v2:
- Adjusted pclk_rate math to divide only the hdisplay value by
compression ratio
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 17 +
1 file changed, 13 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..0e5778e8091f 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,
+ struct drm_dsc_config *dsc, bool is_bonded_dsi)
{
unsigned long pclk_rate;
@@ -576,6 +577,14 @@ 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 hdisplay by compression ratio */
+ if (dsc) {
+ int new_hdisplay = DIV_ROUND_UP(mode->hdisplay *
msm_dsc_get_bpp_int(dsc),
+ dsc->bits_per_component * 3);
+ int fps = DIV_ROUND_UP(pclk_rate, mode->htotal * mode->vtotal);
+ pclk_rate = (new_hdisplay + (mode->htotal - mode->hdisplay)) *
mode->vtotal * fps;
+ }
+
return pclk_rate;
}
@@ -585,7 +594,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 pclk_rate = dsi_get_pclk_rate(mode, msm_host->dsc,
is_bonded_dsi);
u64 pclk_bpp = (u64)pclk_rate * bpp;
if (lanes == 0) {
@@ -604,7 +613,7 @@ unsigned long dsi_byte_clk_get_rate(struct mipi_dsi_host
*host, bool is_bonded_d
static void dsi_calc_pclk(struct msm_dsi_host *msm_host, bool is_bonded_dsi)
{
- msm_host->pixel_clk_rate = dsi_get_pclk_rate(msm_host->mode,
is_bonded_dsi);
+ msm_host->pixel_clk_rate = dsi_get_pclk_rate(msm_host->mode,
msm_host->dsc, is_bonded_dsi);
msm_host->byte_clk_rate = dsi_byte_clk_get_rate(_host->base,
is_bonded_dsi,
msm_host->mode);
@@ -634,7 +643,7 @@ int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host,
bool is_bonded_dsi)
dsi_calc_pclk(msm_host, is_bonded_dsi);
- pclk_bpp = (u64)dsi_get_pclk_rate(msm_host->mode, is_bonded_dsi) * bpp;
+ pclk_bpp = (u64)dsi_get_pclk_rate(msm_host->mode, msm_host->dsc,
is_bonded_dsi) * bpp;
do_div(pclk_bpp, 8);
msm_host->src_clk_rate = pclk_bpp;
--
2.40.1
[PATCH v2 4/4] drm/msm/dpu: Set DATA_COMPRESS for command mode
Add a DPU INTF op to set DATA_COMPRESS register for command mode panels if
the DPU_INTF_DATA_COMPRESS feature flag is set. This flag needs to be
enabled in order for DSC v1.2 to work.
Note: These changes are for command mode only. Video mode changes will
be posted along with the DSC v1.2 support for DP.
Changes in v2:
- Fixed whitespace issue in macro definition
- Read INTF_CONFIG2 before writing to DATA_COMPRESS bit
- Only set dpu_hw_intf_ops.data_compress if DATA_COMPRESS feature is set
- Removed `inline` from dpu_hw_intf_enable_compression declaration
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 11 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 2 ++
3 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index d8ed85a238af..1a4c20f02312 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -68,6 +68,9 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
phys_enc->hw_intf,
true,
phys_enc->hw_pp->idx);
+
+ if (phys_enc->hw_intf->ops.enable_compression)
+ phys_enc->hw_intf->ops.enable_compression(phys_enc->hw_intf);
}
static void dpu_encoder_phys_cmd_pp_tx_done_irq(void *arg, int irq_idx)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 6485500eedb8..322c55a5042c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -91,6 +91,14 @@
#define INTF_CFG2_DATABUS_WIDENBIT(0)
#define INTF_CFG2_DATA_HCTL_EN BIT(4)
+#define INTF_CFG2_DCE_DATA_COMPRESS BIT(12)
+
+static void dpu_hw_intf_enable_compression(struct dpu_hw_intf *ctx)
+{
+ u32 intf_cfg2 = DPU_REG_READ(>hw, INTF_CONFIG2);
+
+ DPU_REG_WRITE(>hw, INTF_CONFIG2, intf_cfg2 |
INTF_CFG2_DCE_DATA_COMPRESS);
+}
static void dpu_hw_intf_setup_timing_engine(struct dpu_hw_intf *ctx,
const struct intf_timing_params *p,
@@ -542,6 +550,9 @@ static void _setup_intf_ops(struct dpu_hw_intf_ops *ops,
ops->vsync_sel = dpu_hw_intf_vsync_sel;
ops->disable_autorefresh = dpu_hw_intf_disable_autorefresh;
}
+
+ if (cap & BIT(DPU_INTF_DATA_COMPRESS))
+ ops->enable_compression = dpu_hw_intf_enable_compression;
}
struct dpu_hw_intf *dpu_hw_intf_init(const struct dpu_intf_cfg *cfg,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
index 73b0885918f8..a8def68a5ec2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
@@ -70,6 +70,7 @@ struct intf_status {
* @get_autorefresh:Retrieve autorefresh config from hardware
* Return: 0 on success, -ETIMEDOUT on timeout
* @vsync_sel: Select vsync signal for tear-effect
configuration
+ * @enable_compression: Enable data compression
*/
struct dpu_hw_intf_ops {
void (*setup_timing_gen)(struct dpu_hw_intf *intf,
@@ -107,6 +108,7 @@ struct dpu_hw_intf_ops {
* Disable autorefresh if enabled
*/
void (*disable_autorefresh)(struct dpu_hw_intf *intf, uint32_t
encoder_id, u16 vdisplay);
+ void (*enable_compression)(struct dpu_hw_intf *intf);
};
struct dpu_hw_intf {
--
2.40.1
[PATCH v2 2/4] drm/msm/dsi: Fix compressed word count calculation
Currently, word count is calculated using slice_count. This is incorrect
as downstream uses slice per packet, which is different from
slice_count.
Slice count represents the number of soft slices per interface, and its
value will not always match that of slice per packet. For example, it is
possible to have cases where there are multiple soft slices per interface
but the panel specifies only one slice per packet.
Thus, use the default value of one slice per packet and remove slice_count
from the word count calculation.
Changes in v2:
- "drm_panel" -> "mipi_dsi_device" in TODO comment
Fixes: bc6b6ff8135c ("drm/msm/dsi: Use DSC slice(s) packet size to compute word
count")
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 0e5778e8091f..f6fb32e2223c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -999,7 +999,14 @@ static void dsi_timing_setup(struct msm_dsi_host
*msm_host, bool is_bonded_dsi)
if (!msm_host->dsc)
wc = hdisplay * dsi_get_bpp(msm_host->format) / 8 + 1;
else
- wc = msm_host->dsc->slice_chunk_size *
msm_host->dsc->slice_count + 1;
+ /*
+* When DSC is enabled, WC = slice_chunk_size *
slice_per_packet + 1.
+* Currently, the driver only supports default value of
slice_per_packet = 1
+*
+* TODO: Expand mipi_dsi_device struct to hold
slice_per_packet info
+* and adjust DSC math to account for
slice_per_packet.
+*/
+ wc = msm_host->dsc->slice_chunk_size + 1;
dsi_write(msm_host, REG_DSI_CMD_MDP_STREAM0_CTRL,
DSI_CMD_MDP_STREAM0_CTRL_WORD_COUNT(wc) |
--
2.40.1
[PATCH v2 0/4] Add DSC v1.2 Support for DSI
This is a series of changes for DSI to enable command mode support for DSC v1.2. This includes: 1) Adjusting pclk_rate to account for compression 2) Fixing the word count calculation for DSC 3) Setting the DATA_COMPRESS bit when DSC is enabled With these changes (and the dependency below), DSC v1.2 should work over DSI in command mode. Note: Changes that add DSC v1.2 support for video mode will be posted with the DP support changes. Depends-on: "add DSC 1.2 dpu supports" [1] and "Introduce MSM-specific DSC helpers" [2] [1] https://patchwork.freedesktop.org/series/116789/ [2] https://patchwork.freedesktop.org/series/115833/ Signed-off-by: Jessica Zhang --- Changes in v2: - Changed pclk math to only divide hdisplay by compression ratio - Reworded word count TODO comment - Make DATA_COMPRESS an INTF flag - Read INTF_CFG2 before setting DATA_COMRPESS register - Reworded commit messages and cover letter for clarity - Link to v1: https://lore.kernel.org/r/20230405-add-dsc-support-v1-0-6bc6f03ae...@quicinc.com --- Jessica Zhang (4): drm/msm/dsi: Adjust pclk rate for compression drm/msm/dsi: Fix compressed word count calculation drm/msm/dpu: Add DPU_INTF_DATA_COMPRESS feature flag drm/msm/dpu: Set DATA_COMPRESS for command mode .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c| 11 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h| 2 ++ drivers/gpu/drm/msm/dsi/dsi_host.c | 26 +- 6 files changed, 40 insertions(+), 6 deletions(-) --- base-commit: 70e08302e024bfac485b12972099237f7f39d829 change-id: 20230405-add-dsc-support-fe130ba49841 Best regards, -- Jessica Zhang
[PATCH v2 3/4] drm/msm/dpu: Add DPU_INTF_DATA_COMPRESS feature flag
Add DATA_COMPRESS feature flag to DPU INTF block.
In DPU 7.x and later, DSC/DCE enablement registers have been moved from
PINGPONG to INTF.
As core_rev (and related macros) was removed from the dpu_kms struct, the
most straightforward way to indicate the presence of this register would be
to have a feature flag.
Changes in v2:
- Changed has_data_compress dpu_cap to a DATA_COMPRESS INTF feature flag
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 7944481d0a33..c74051906d05 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -104,7 +104,7 @@
#define INTF_SC7180_MASK \
(BIT(DPU_INTF_INPUT_CTRL) | BIT(DPU_INTF_TE) |
BIT(DPU_INTF_STATUS_SUPPORTED))
-#define INTF_SC7280_MASK INTF_SC7180_MASK | BIT(DPU_DATA_HCTL_EN)
+#define INTF_SC7280_MASK INTF_SC7180_MASK | BIT(DPU_DATA_HCTL_EN) |
BIT(DPU_INTF_DATA_COMPRESS)
#define WB_SM8250_MASK (BIT(DPU_WB_LINE_MODE) | \
BIT(DPU_WB_UBWC) | \
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 4eda2cc847ef..01c65f940f2a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -185,6 +185,7 @@ enum {
* @DPU_DATA_HCTL_ENAllows data to be transferred at different
rate
* than video timing
* @DPU_INTF_STATUS_SUPPORTED INTF block has INTF_STATUS register
+ * @DPU_INTF_DATA_COMPRESS INTF block has DATA_COMPRESS register
* @DPU_INTF_MAX
*/
enum {
@@ -192,6 +193,7 @@ enum {
DPU_INTF_TE,
DPU_DATA_HCTL_EN,
DPU_INTF_STATUS_SUPPORTED,
+ DPU_INTF_DATA_COMPRESS,
DPU_INTF_MAX
};
--
2.40.1
Re: [PATCH v4 1/3] dt-bindings: display: panel: Add Samsung S6D7AA0 LCD panel controller
On Mon, May 01, 2023 at 08:51:01PM +0200, Artur Weber wrote:
> Add bindings for the S6D7AA0 LCD panel controller, including the
> S6D7AA0-LSL080AL02 panel used in the Samsung Galaxy Tab 3 8.0 family
> of tablets, and the S6D7AA0-LSL080AL03 and S6D7AA0-LTL101AT01 panels
> used in the Samsung Galaxy Tab A 8.0 and 9.7 2015.
>
> Signed-off-by: Artur Weber
> ---
> Changed in v2:
> - Updated commit message
> - Applied suggestions from Krzysztof Kozlowski
> Changed in v3:
> - Correctly applied suggestions
> Changed in v4:
> - Added LSL080AL03, LTL101AT01 compatibles
> - Added description to reset-gpios
> - Added vmipi-supply, renamed enable-supply to power-supply
> ---
> .../display/panel/samsung,s6d7aa0.yaml| 68 +++
> 1 file changed, 68 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml
> b/Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml
> new file mode 100644
> index ..918f62a78ecd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml
> @@ -0,0 +1,68 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license please.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/samsung,s6d7aa0.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung S6D7AA0 MIPI-DSI LCD panel controller
> +
> +maintainers:
> + - Artur Weber
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +enum:
> + # 1280x800 LSL080AL02 panel
> + - samsung,s6d7aa0-lsl080al02
> + # 1024x768 LSL080AL03 panel
> + - samsung,s6d7aa0-lsl080al03
> + # 1024x768 LTL101AT01 panel
> + - samsung,s6d7aa0-ltl101at01
> +
> + reg: true
> +
> + backlight:
> +description: |
> + Backlight to use for the panel. If this property is set on panels
> + that have DSI-based backlight control (LSL080AL03 and LTL101AT01),
> + it overrides the DSI-based backlight.
> +
> + reset-gpios:
> +description: Reset GPIO pin, usually GPIO_ACTIVE_LOW.
> +
> + power-supply:
> +description: |
> + Main power supply for the panel; the exact voltage differs between
> + panels, and is usually somewhere around 3.3-5v.
> +
> + vmipi-supply:
> +description: VMIPI supply, usually 1.8v.
> +
> +required:
> + - compatible
> + - reg
> + - reset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +panel@0 {
> +compatible = "samsung,s6d7aa0-lsl080al02";
> +reg = <0>;
> +power-supply = <_3v3_supply>;
> +reset-gpios = < 4 GPIO_ACTIVE_LOW>;
> +backlight = <>;
> +};
> +};
> +
> +...
> --
> 2.40.1
>
Re: [RFC] Plane color pipeline KMS uAPI
On Fri, 5 May 2023 at 01:23, 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. > > 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. I'm not 100% sold on the prescriptive here, let's see if someone can get me over the line with some questions later. My feeling is color pipeline hw is not a done deal, and that hw vendors will be revising/evolving/churning the hw blocks for a while longer, as there is no real standards in the area to aim for, all the vendors are mostly just doing whatever gets Windows over the line and keeps hw engineers happy. So I have some concerns here around forwards compatibility and hence the API design. I guess my main concern is if you expose a bunch of hw blocks and someone comes up with a novel new thing, will all existing userspace work, without falling back to shaders? Do we have minimum guarantees on what hardware blocks have to be exposed to build a useable pipeline? If a hardware block goes away in a new silicon revision, do I have to rewrite my compositor? or will it be expected that the kernel will emulate the old pipelines on top of whatever new fancy thing exists. We are not Android, or even Steam OS on a Steamdeck, we have to be able to independently update the kernel for new hardware and not require every compositor currently providing HDR to need to support new hardware blocks and models at the same time. Dave.
[PATCH] drm/drm_fb_helper.c: fix a typo
Signed-off-by: Sui Jingfeng --- drivers/gpu/drm/drm_fb_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 6bb1b8b27d7a..3f34bcd8145c 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1442,7 +1442,7 @@ int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, /* * Only wait for a vblank event if the CRTC is -* enabled, otherwise just don't do anythintg, +* enabled, otherwise just don't do anything, * not even report an error. */ ret = drm_crtc_vblank_get(crtc); -- 2.25.1
Re: [PATCH 1/4] dt-bindings: backlight: lp855x: convert to YAML and modernize
On Sat, Apr 29, 2023 at 12:45:31PM +0200, Artur Weber wrote:
> Notable changes:
> - ROM child nodes use dashes instead of underscores; the driver
> reads all child nodes regardless of their names, so this doesn't
> break ABI.
> - pwm-period argument is deprecated, as it effectively duplicates
> the period value provided in pwms. The driver continues to accept
> the property, so this should not break ABI.
>
> Signed-off-by: Artur Weber
> ---
> .../leds/backlight/lp855x-backlight.yaml | 148 ++
> .../bindings/leds/backlight/lp855x.txt| 72 -
> 2 files changed, 148 insertions(+), 72 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/leds/backlight/lp855x-backlight.yaml
> delete mode 100644
> Documentation/devicetree/bindings/leds/backlight/lp855x.txt
>
> diff --git
> a/Documentation/devicetree/bindings/leds/backlight/lp855x-backlight.yaml
> b/Documentation/devicetree/bindings/leds/backlight/lp855x-backlight.yaml
> new file mode 100644
> index ..dfe8131d2a32
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/lp855x-backlight.yaml
> @@ -0,0 +1,148 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/backlight/lp855x-backlight.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments LP855X backlight controllers
> +
> +maintainers:
> + - Artur Weber
> +
> +properties:
> + compatible:
> +enum:
> + - ti,lp8550
> + - ti,lp8551
> + - ti,lp8552
> + - ti,lp8553
> + - ti,lp8555
> + - ti,lp8556
> + - ti,lp8557
> +
> + reg:
> +maxItems: 1
> +
> + dev-ctrl:
> +$ref: /schemas/types.yaml#/definitions/uint8
> +description:
> + Value of device control register. This is a device-specific value.
> +
> + bl-name:
> +$ref: /schemas/types.yaml#/definitions/string
> +description: Backlight device name.
> +
> + init-brt:
> +$ref: /schemas/types.yaml#/definitions/uint8
> +description: Initial value of backlight brightness.
> +
> + power-supply:
> +description: Regulator which controls the 3V rail.
> +
> + enable-supply:
> +description: Regulator which controls the EN/VDDIO input.
> +
> + pwms:
> +maxItems: 1
> +description: |
> + PWM channel to use for controlling the backlight; setting this
> + enables the PWM-based backlight control mode.
> +
> + pwm-names: true
> +
> + pwm-period:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description:
> + PWM period value. Deprecated; set the period value in the pwms
> + property instead.
> +deprecated: true
> +
> +patternProperties:
> + "^rom-[0-9a-f]{2}h$":
> +type: object
> +description: Nodes containing the values of configuration registers.
additionalProperties: false
With that,
Reviewed-by: Rob Herring
> +properties:
> + rom-addr:
> +$ref: /schemas/types.yaml#/definitions/uint8
> +description: Register address of ROM area to be updated.
> +
> + rom-val:
> +$ref: /schemas/types.yaml#/definitions/uint8
> +description: Value to write to the ROM register.
> +
> +required:
> + - compatible
> + - reg
> + - dev-ctrl
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +backlight@2c {
> +compatible = "ti,lp8555";
> +reg = <0x2c>;
> +
> +dev-ctrl = /bits/ 8 <0x00>;
> +
> +pwms = < 0 1>;
> +pwm-names = "lp8555";
> +
> +/* 4V OV, 4 output LED0 string enabled */
> +rom-14h {
> + rom-addr = /bits/ 8 <0x14>;
> + rom-val = /bits/ 8 <0xcf>;
> +};
> +
> +/* Heavy smoothing, 24ms ramp time step */
> +rom-15h {
> + rom-addr = /bits/ 8 <0x15>;
> + rom-val = /bits/ 8 <0xc7>;
> +};
> +
> +/* 4 output LED1 string enabled */
> +rom-19h {
> + rom-addr = /bits/ 8 <0x19>;
> + rom-val = /bits/ 8 <0x0f>;
> +};
> +};
> +};
> + - |
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +backlight@2c {
> +compatible = "ti,lp8556";
> +reg = <0x2c>;
> +
> +bl-name = "lcd-bl";
> +dev-ctrl = /bits/ 8 <0x85>;
> +init-brt = /bits/ 8 <0x10>;
> +};
> + };
> + - |
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +backlight@2c {
> +compatible = "ti,lp8557";
> +reg = <0x2c>;
> +enable-supply = <_vddio>;
> +power-supply = <_vdd>;
> +
> +dev-ctrl = /bits/ 8 <0x41>;
> +init-brt = /bits/ 8 <0x0a>;
> +
> +/* 4V OV, 4 output LED
Re: [Intel-gfx] [PATCH v8 0/7] drm/i915: use ref_tracker library for tracking wakerefs
On Thu, May 04, 2023 at 06:27:53PM +0200, Andrzej Hajda wrote: > 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. Well, probably the easiest way to avoid conflicts would be to send this right now through the net repo. And hold patches 5-7 after drm-intel-next can backmerge them. At this point I believe we would be looking at 6.5-rc2 backmerge to drm-intel-next in likely 11 weeks from now. Do we have any urgency on them? Looking to all the changes in i915 I believe we will get many conflicts if we let all these i915 patches go through net tree as well. > > 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
Re: [RFC] Plane color pipeline KMS uAPI
On Fri, May 05, 2023 at 04:06:26PM +, Simon Ser wrote: > On Friday, May 5th, 2023 at 17:28, Daniel Vetter wrote: > > > Ok no comments from me on the actual color operations and semantics of all > > that, because I have simply nothing to bring to that except confusion :-) > > > > Some higher level thoughts instead: > > > > - I really like that we just go with graph nodes here. I think that was > > bound to happen sooner or later with kms (we almost got there with > > writeback, and with hindsight maybe should have). > > I'd really rather not do graphs here. We only need linked lists as Sebastian > said. Graphs would significantly add more complexity to this proposal, and > I don't think that's a good idea unless there is a strong use-case. You have a graph, because a graph is just nodes + links. I did _not_ propose a full generic graph structure, the link pointer would be in the class/type specific structure only. Like how we have the plane->crtc or connector->crtc links already like that (which already _is_ is full blown graph). Maybe explain what exactly you're thinking under "do graphs here" so I understand what you mean differently than me? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [RFC] Plane color pipeline KMS uAPI
On Fri, May 05, 2023 at 05:57:37PM +0200, Sebastian Wick wrote:
> On Fri, May 5, 2023 at 5:28 PM Daniel Vetter wrote:
> >
> > On Thu, May 04, 2023 at 03:22:59PM +, 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.
> > >
> > > 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.
> >
> > Ack on the prescriptive approach, but generic imo. Descriptive pretty much
> > means you need the shaders at the same api level for fallback purposes,
> > and we're not going to have that ever in kms. That would need something
> > like hwc in userspace to work.
>
> Which would be nice to have but that would be forcing a specific color
> pipeline on everyone and we explicitly want to avoid that. There are
> just too many trade-offs to consider.
>
> > And not generic in it's ultimate consquence would mean we just do a blob
> > for a crtc with all the vendor register stuff like adf (android display
> > framework) does, because I really don't see a point in trying a
> > generic-looking-but-not vendor uapi with each color op/stage split out.
> >
> > So from very far and pure gut feeling, this seems like a good middle
> > ground in the uapi design space we have here.
>
> Good to hear!
>
> > > 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
> >
> > A bit confused, why is this an enum, and not just an immutable prop that
> > points at the first element? You already can disable elements with the
> > bypass thing, also bypassing by changing the pointers to the next node in
> > the graph seems a bit confusing and redundant.
>
> We want to allow multiple pipelines to exist and a plane can choose
> the pipeline by selecting the first element of the pipeline. The enum
> here lists all the possible
Re: [RFC PATCH 0/4] Add support for DRM cgroup memory accounting.
Hello, On Wed, May 03, 2023 at 10:34:56AM +0200, Maarten Lankhorst wrote: > RFC as I'm looking for comments. > > For long running compute, it can be beneficial to partition the GPU memory > between cgroups, so each cgroup can use its maximum amount of memory without > interfering with other scheduled jobs. Done properly, this can alleviate the > need for eviction, which might result in a job being terminated if the GPU > doesn't support mid-thread preemption or recoverable page faults. > > This is done by adding a bunch of knobs to cgroup: > drm.capacity: Shows maximum capacity of each resource region. > drm.max: Display or limit max amount of memory. > drm.current: Current amount of memory in use. > > TTM has not been made cgroup aware yet, so instead of evicting from > the current cgroup to stay within the cgroup limits, it simply returns > the error -ENOSPC to userspace. > > I've used Tvrtko's cgroup controller series as a base, but it implemented > scheduling weight, not memory accounting, so I only ended up keeping the > base patch. > > Xe is not upstream yet, so the driver specific patch will only apply on > https://gitlab.freedesktop.org/drm/xe/kernel Some high-level feedbacks. * There have been multiple attempts at this but the track record is kinda poor. People don't seem to agree what should constitute DRM memory and how they should be accounted / controlled. * I like Tvrtko's scheduling patchset because it exposes a generic interface which makes sense regardless of hardware details and then each driver can implement the configured control in whatever way they can. However, even for that, there doesn't seem much buy-in from other drivers. * This proposal seems narrowly scoped trying to solve a specific problem which may not translate to different hardware configurations. Please let me know if I got that wrong, but if that's the case, I think a better and easier approach might be just being a part of the misc controller. That doesn't require much extra code and should be able to provide everything necessary for statically limiting specific resources. Thanks. -- tejun
Re: [PATCH 1/3] iommu/dma: Clean up Kconfig
On Fri, May 05, 2023 at 03:53:54PM +0100, Robin Murphy wrote: > > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > > > index 5c5cb5bee8b6..1d99c2d984fb 100644 > > > --- a/drivers/iommu/Kconfig > > > +++ b/drivers/iommu/Kconfig > > > @@ -137,7 +137,7 @@ config OF_IOMMU > > > # IOMMU-agnostic DMA-mapping layer > > > config IOMMU_DMA > > > - bool > > > + def_bool ARM64 || IA64 || X86 > > > > Robin, do you remember why you added IA64 here? What is the Itanimum > > IOMMU driver? > > config INTEL_IOMMU > bool "Support for Intel IOMMU using DMA Remapping Devices" > depends on PCI_MSI && ACPI && (X86 || IA64) > > Yes, really :) Wowo, thanks! Jason
Re: [git pull] drm fixes part 2 for 6.4-rc1
The pull request you sent on Fri, 5 May 2023 13:10:28 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-next-2023-05-05 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/084f51d473cd566eab310d5da56fe7b68d0b10be Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [Freedreno] [PATCH v2 1/9] drm/msm/dpu: fix SSPP register definitions
On Fri, 5 May 2023 at 20:24, Jeykumar Sankaran wrote: > > > > On 5/2/2023 8:05 AM, Dmitry Baryshkov wrote: > > Reorder SSPP register definitions to sort them in the ascending order. > > Move register bitfields after the register definitions. > > > > Signed-off-by: Dmitry Baryshkov > > --- > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 66 +++-- > > 1 file changed, 34 insertions(+), 32 deletions(-) > > > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c > > index 6b68ec5c7a5a..1bf717290dab 100644 > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c > > @@ -26,45 +26,18 @@ > > #define SSPP_SRC_FORMAT0x30 > > #define SSPP_SRC_UNPACK_PATTERN0x34 > > #define SSPP_SRC_OP_MODE 0x38 > > - > > -/* SSPP_MULTIRECT*/ > > -#define SSPP_SRC_SIZE_REC1 0x16C > > -#define SSPP_SRC_XY_REC1 0x168 > > -#define SSPP_OUT_SIZE_REC1 0x160 > > -#define SSPP_OUT_XY_REC1 0x164 > > -#define SSPP_SRC_FORMAT_REC1 0x174 > > -#define SSPP_SRC_UNPACK_PATTERN_REC1 0x178 > > -#define SSPP_SRC_OP_MODE_REC1 0x17C > > -#define SSPP_MULTIRECT_OPMODE 0x170 > > -#define SSPP_SRC_CONSTANT_COLOR_REC1 0x180 > > -#define SSPP_EXCL_REC_SIZE_REC10x184 > > -#define SSPP_EXCL_REC_XY_REC1 0x188 > > - > > -#define MDSS_MDP_OP_DEINTERLACEBIT(22) > > -#define MDSS_MDP_OP_DEINTERLACE_ODDBIT(23) > > -#define MDSS_MDP_OP_IGC_ROM_1 BIT(18) > > -#define MDSS_MDP_OP_IGC_ROM_0 BIT(17) > > -#define MDSS_MDP_OP_IGC_EN BIT(16) > > -#define MDSS_MDP_OP_FLIP_UDBIT(14) > > -#define MDSS_MDP_OP_FLIP_LRBIT(13) > > -#define MDSS_MDP_OP_BWC_EN BIT(0) > > -#define MDSS_MDP_OP_PE_OVERRIDEBIT(31) > > -#define MDSS_MDP_OP_BWC_LOSSLESS (0 << 1) > > -#define MDSS_MDP_OP_BWC_Q_HIGH (1 << 1) > > -#define MDSS_MDP_OP_BWC_Q_MED (2 << 1) > > - > > #define SSPP_SRC_CONSTANT_COLOR0x3c > > #define SSPP_EXCL_REC_CTL 0x40 > > #define SSPP_UBWC_STATIC_CTRL 0x44 > > -#define SSPP_FETCH_CONFIG 0x048 > > +#define SSPP_FETCH_CONFIG 0x48 > > #define SSPP_DANGER_LUT0x60 > > #define SSPP_SAFE_LUT 0x64 > > #define SSPP_CREQ_LUT 0x68 > > #define SSPP_QOS_CTRL 0x6C > > -#define SSPP_DECIMATION_CONFIG 0xB4 > > #define SSPP_SRC_ADDR_SW_STATUS0x70 > > #define SSPP_CREQ_LUT_00x74 > > #define SSPP_CREQ_LUT_10x78 > > +#define SSPP_DECIMATION_CONFIG 0xB4 > > #define SSPP_SW_PIX_EXT_C0_LR 0x100 > > #define SSPP_SW_PIX_EXT_C0_TB 0x104 > > #define SSPP_SW_PIX_EXT_C0_REQ_PIXELS 0x108 > > @@ -81,11 +54,33 @@ > > #define SSPP_TRAFFIC_SHAPER_PREFILL0x150 > > #define SSPP_TRAFFIC_SHAPER_REC1_PREFILL 0x154 > > #define SSPP_TRAFFIC_SHAPER_REC1 0x158 > > +#define SSPP_OUT_SIZE_REC1 0x160 > > +#define SSPP_OUT_XY_REC1 0x164 > > +#define SSPP_SRC_XY_REC1 0x168 > > +#define SSPP_SRC_SIZE_REC1 0x16C > > +#define SSPP_MULTIRECT_OPMODE 0x170 > > +#define SSPP_SRC_FORMAT_REC1 0x174 > > +#define SSPP_SRC_UNPACK_PATTERN_REC1 0x178 > > +#define SSPP_SRC_OP_MODE_REC1 0x17C > > +#define SSPP_SRC_CONSTANT_COLOR_REC1 0x180 > > +#define SSPP_EXCL_REC_SIZE_REC10x184 > > +#define SSPP_EXCL_REC_XY_REC1 0x188 > > #define SSPP_EXCL_REC_SIZE 0x1B4 > > #define SSPP_EXCL_REC_XY 0x1B8 > > -#define SSPP_VIG_OP_MODE 0x0 > > -#define SSPP_VIG_CSC_10_OP_MODE0x0 > > -#define SSPP_TRAFFIC_SHAPER_BPC_MAX0xFF > > + > > +/* SSPP_SRC_OP_MODE & OP_MODE_REC1 */ > > +#define MDSS_MDP_OP_DEINTERLACEBIT(22) > > +#define MDSS_MDP_OP_DEINTERLACE_ODDBIT(23) > > +#define MDSS_MDP_OP_IGC_ROM_1 BIT(18) > > +#define MDSS_MDP_OP_IGC_ROM_0 BIT(17) > > +#define MDSS_MDP_OP_IGC_EN BIT(16) > > +#define MDSS_MDP_OP_FLIP_UDBIT(14) > > +#define MDSS_MDP_OP_FLIP_LRBIT(13) > > +#define MDSS_MDP_OP_BWC_EN BIT(0) > > +#define MDSS_MDP_OP_PE_OVERRIDEBIT(31) > > +#define MDSS_MDP_OP_BWC_LOSSLESS (0 << 1) > > +#define MDSS_MDP_OP_BWC_Q_HIGH (1 << 1) > > +#define MDSS_MDP_OP_BWC_Q_MED (2 << 1) > > > > /* SSPP_QOS_CTRL */ > > #define SSPP_QOS_CTRL_VBLANK_ENBIT(16) > > @@ -96,6 +91,7 @@ > >
Re: [PATCH 1/4] drm/msm/dsi: Adjust pclk rate for compression
On 5/4/2023 2:17 PM, Marijn Suijten wrote:
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).
Hi Marijn,
That's a fair point. Will change the pclk math accordingly.
Thanks,
Jessica Zhang
- 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 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,
+
Re: [PATCH] drm/amdgpu: remove unneeded semicolon
Applied. Thanks! Alex On Fri, May 5, 2023 at 3:43 AM Jiapeng Chong wrote: > > No functional modification involved. > > ./drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c:146:2-3: Unneeded semicolon. > > Reported-by: Abaci Robot > Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4871 > Signed-off-by: Jiapeng Chong > --- > drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c > b/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c > index 24d12075ca3a..a331a59c49e3 100644 > --- a/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c > +++ b/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c > @@ -143,7 +143,7 @@ static void nbio_v7_9_sdma_doorbell_range(struct > amdgpu_device *adev, int instan > break; > default: > break; > - }; > + } > > return; > } > -- > 2.20.1.7.g153144c >
Re: [PATCH v3 1/2] drm/atomic: Allow vblank-enabled + self-refresh "disable"
On Mon, Jan 09, 2023 at 05:18:16PM -0800, Brian Norris wrote:
> The self-refresh helper framework overloads "disable" to sometimes mean
> "go into self-refresh mode," and this mode activates automatically
> (e.g., after some period of unchanging display output). In such cases,
> the display pipe is still considered "on", and user-space is not aware
> that we went into self-refresh mode. Thus, users may expect that
> vblank-related features (such as DRM_IOCTL_WAIT_VBLANK) still work
> properly.
>
> However, we trigger the WARN_ONCE() here if a CRTC driver tries to leave
> vblank enabled.
>
> Add a different expectation: that CRTCs *should* leave vblank enabled
> when going into self-refresh.
>
> This patch is preparation for another patch -- "drm/rockchip: vop: Leave
> vblank enabled in self-refresh" -- which resolves conflicts between the
> above self-refresh behavior and the API tests in IGT's kms_vblank test
> module.
>
> == Some alternatives discussed: ==
>
> It's likely that on many display controllers, vblank interrupts will
> turn off when the CRTC is disabled, and so in some cases, self-refresh
> may not support vblank. To support such cases, we might consider
> additions to the generic helpers such that we fire vblank events based
> on a timer.
>
> However, there is currently only one driver using the common
> self-refresh helpers (i.e., rockchip), and at least as of commit
> bed030a49f3e ("drm/rockchip: Don't fully disable vop on self refresh"),
> the CRTC hardware is powered enough to continue to generate vblank
> interrupts.
>
> So we chose the simpler option of leaving vblank interrupts enabled. We
> can reevaluate this decision and perhaps augment the helpers if/when we
> gain a second driver that has different requirements.
>
> v3:
> * include discussion summary
>
> v2:
> * add 'ret != 0' warning case for self-refresh
> * describe failing test case and relation to drm/rockchip patch better
>
> Cc: # dependency for "drm/rockchip: vop: Leave
> # vblank enabled in self-refresh"
> Signed-off-by: Brian Norris
Pushed both patches to drm-misc-next, thanks Brian
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index d579fd8f7cb8..a22485e3e924 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1209,7 +1209,16 @@ disable_outputs(struct drm_device *dev, struct
> drm_atomic_state *old_state)
> continue;
>
> ret = drm_crtc_vblank_get(crtc);
> - WARN_ONCE(ret != -EINVAL, "driver forgot to call
> drm_crtc_vblank_off()\n");
> + /*
> + * Self-refresh is not a true "disable"; ensure vblank remains
> + * enabled.
> + */
> + if (new_crtc_state->self_refresh_active)
> + WARN_ONCE(ret != 0,
> + "driver disabled vblank in self-refresh\n");
> + else
> + WARN_ONCE(ret != -EINVAL,
> + "driver forgot to call
> drm_crtc_vblank_off()\n");
> if (ret == 0)
> drm_crtc_vblank_put(crtc);
> }
> --
> 2.39.0.314.g84b9a713c41-goog
>
--
Sean Paul, Software Engineer, Google / Chromium OS
Re: [PATCH V2] drm/amdgpu/display: Enable DC_FP for LoongArch
On Fri, May 5, 2023 at 2:39 PM WANG Xuerui wrote: > > On 5/6/23 02:00, Alex Deucher wrote: > > On Fri, May 5, 2023 at 1:57 PM WANG Xuerui wrote: > >> > >> On a side note, I had to modprobe amdgpu with runpm=0, otherwise my > >> dmesg gets flooded with PSP getting resumed every 8~10 seconds or so. I > >> currently have none of the connectors plugged in. I didn't notice any > >> similar reports on the Internet so I don't know if it's due to platform > >> quirks or not. > > That might just be part of the normal suspend/resume process. If it > > happens at regular intervals, it sounds like something is waking the > > GPU at a regular interval. We should probably remove that message to > > avoid it being too chatty, but you may want to check what is waking it > > so much as doing so sort of negates the value of runtime power > > management. > > Ah. This is extremely helpful as I'm immediately able to confirm it's > node_exporter trying to access the hwmon readings (I have a monitoring > infra for all my devboxes). Every sufficiently spaced read from say > temp1_input wakes up the GPU. Not many people have their boxes working > like this I guess... but at least we could probably reduce the log spam > a bit if it's not feasible to get GPU metrics while avoiding to resume > it? (Currently it's 25 lines per resume, mostly SMU resume logs and ring Well, there are no metrics to pull because the GPU is powered down when in runtime suspend. Alex > info.) > > And of course this is not a big deal, I can always work around it > locally. Thanks for the hint again. > > -- > WANG "xen0n" Xuerui > > Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/ >
Re: [PATCH v1 0/9] drm/bridge: tc358768: various fixes on PLL calculation and DSI timings
From: Robert Foss On Thu, 27 Apr 2023 16:29:25 +0200, Francesco Dolcini wrote: > From: Francesco Dolcini > > This series includes multiple fixes on the tc358768 parallel RGB to DSI > driver. > > With the following changes I am able to have a stable display output using a > TI > SN65DSI83 (DSI-LVDS bridge) and a 1280 x 800 LVDS display panel and the > register values are coherent with Toshiba documentation and configuration > spreadsheet, I was not able to test any other display sink. > > [...] Applied, thanks! [1/9] drm/bridge: tc358768: always enable HS video mode https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ee18698e212b [2/9] drm/bridge: tc358768: fix PLL parameters computation https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ee18698e212b [3/9] drm/bridge: tc358768: fix PLL target frequency https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ee18698e212b [4/9] drm/bridge: tc358768: fix TCLK_ZEROCNT computation https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ee18698e212b [5/9] drm/bridge: tc358768: fix TCLK_TRAILCNT computation https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ee18698e212b [6/9] drm/bridge: tc358768: fix THS_ZEROCNT computation https://cgit.freedesktop.org/drm/drm-misc/commit/?id=77a089328da7 [7/9] drm/bridge: tc358768: fix TXTAGOCNT computation https://cgit.freedesktop.org/drm/drm-misc/commit/?id=3666aad8185a [8/9] drm/bridge: tc358768: fix THS_TRAILCNT computation https://cgit.freedesktop.org/drm/drm-misc/commit/?id=bac7842cd179 [9/9] drm/bridge: tc358768: remove unused variable https://cgit.freedesktop.org/drm/drm-misc/commit/?id=e4a5e4442a80 Rob
Re: [PATCH v1 9/9] drm/bridge: tc358768: remove unused variable
On Thu, Apr 27, 2023 at 4:34 PM Francesco Dolcini wrote: > > From: Francesco Dolcini > > Remove the unused phy_delay_nsk variable, before it was wrongly used > to compute some register value, the fixed computation is no longer using > it and therefore can be removed. > > Signed-off-by: Francesco Dolcini > --- > drivers/gpu/drm/bridge/tc358768.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/tc358768.c > b/drivers/gpu/drm/bridge/tc358768.c > index 947c7dca567a..d3af42a16e69 100644 > --- a/drivers/gpu/drm/bridge/tc358768.c > +++ b/drivers/gpu/drm/bridge/tc358768.c > @@ -641,7 +641,7 @@ static void tc358768_bridge_pre_enable(struct drm_bridge > *bridge) > u32 val, val2, lptxcnt, hact, data_type; > s32 raw_val; > const struct drm_display_mode *mode; > - u32 dsibclk_nsk, dsiclk_nsk, ui_nsk, phy_delay_nsk; > + u32 dsibclk_nsk, dsiclk_nsk, ui_nsk; > u32 dsiclk, dsibclk, video_start; > const u32 internal_delay = 40; > int ret, i; > @@ -725,11 +725,9 @@ static void tc358768_bridge_pre_enable(struct drm_bridge > *bridge) > dsibclk); > dsiclk_nsk = (u32)div_u64((u64)10 * TC358768_PRECISION, > dsiclk); > ui_nsk = dsiclk_nsk / 2; > - phy_delay_nsk = dsibclk_nsk + 2 * dsiclk_nsk; > dev_dbg(priv->dev, "dsiclk_nsk: %u\n", dsiclk_nsk); > dev_dbg(priv->dev, "ui_nsk: %u\n", ui_nsk); > dev_dbg(priv->dev, "dsibclk_nsk: %u\n", dsibclk_nsk); > - dev_dbg(priv->dev, "phy_delay_nsk: %u\n", phy_delay_nsk); > > /* LP11 > 100us for D-PHY Rx Init */ > val = tc358768_ns_to_cnt(100 * 1000, dsibclk_nsk) - 1; > -- > 2.25.1 > Reviewed-by: Robert Foss
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:45:24PM -0700, John Harrison wrote: 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 :). applied both commits to drm-intel-gt-next branch and removed the other one from topic/core-for-CI. Closing https://gitlab.freedesktop.org/drm/intel/-/issues/8343 Thanks 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
Re: [PATCH v3 1/3] Input: ads7846 - Convert to use software nodes
Hi Linus,
On Fri, May 05, 2023 at 01:16:55PM +0200, Linus Walleij wrote:
>
> Populate the devices on the Nokia 770 CBUS I2C using software
> nodes instead of platform data quirks. This includes the LCD
> and the ADS7846 touchscreen so the conversion just brings the LCD
> along with it as software nodes is an all-or-nothing design
> pattern.
Wow, so that worked , awesome!
> +static const struct property_entry nokia770_ads7846_props[] = {
> + PROPERTY_ENTRY_U32("touchscreen-size-x", 4096),
> + PROPERTY_ENTRY_U32("touchscreen-size-y", 4096),
> + PROPERTY_ENTRY_U32("touchscreen-max-pressure", 256),
> + PROPERTY_ENTRY_U32("touchscreen-average-samples", 10),
> + PROPERTY_ENTRY_U16("ti,x-plate-ohms", 180),
> + PROPERTY_ENTRY_U16("ti,debounce-tol", 3),
> + PROPERTY_ENTRY_U16("ti,debounce-rep", 1),
> + PROPERTY_ENTRY_GPIO("pendown-gpios", _gpiochip1_node,
> + ADS7846_PENDOWN_GPIO, GPIO_ACTIVE_HIGH),
Looking at the driver this actually needs to be GPIO_ACTIVE_LOW.
>
> +static struct gpiod_lookup_table spitz_ads7846_gpio_table = {
> + .dev_id = "spi2.0",
> + .table = {
> + GPIO_LOOKUP("gpio-pxa", SPITZ_GPIO_TP_INT,
> + "pendown", GPIO_ACTIVE_HIGH),
GPIO_ACTIVE_LOW here too.
> +static struct gpiod_lookup_table db1100_touch_gpio_table = {
> + .dev_id = "spi0.0",
> + .table = {
> + GPIO_LOOKUP("alchemy-gpio2", 21,
> + "pendown", GPIO_ACTIVE_HIGH),
And here as well.
> @@ -223,7 +220,7 @@ static int get_pendown_state(struct ads7846 *ts)
> if (ts->get_pendown_state)
> return ts->get_pendown_state();
>
> - return !gpio_get_value(ts->gpio_pendown);
> + return !gpiod_get_value(ts->gpio_pendown);
This needs to be
return !gpiod_get_value_raw(ts->gpio_pendown);
I looked at various DTSes we have and they use a mix of active high and
active low annotations, so we have to go with the "raw" variant for now,
and then update to normal one once we update bad DTSes.
Thanks!
--
Dmitry
Re: [PATCH v1 8/9] drm/bridge: tc358768: fix THS_TRAILCNT computation
On Thu, Apr 27, 2023 at 4:34 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> Correct computation of THS_TRAILCNT register.
>
> This register must be set to a value that ensure that
> THS_TRAIL > 60 ns + 4 x UI
> and
> THS_TRAIL > 8 x UI
> and
> THS_TRAIL < TEOT
> with
> TEOT = 105 ns + (12 x UI)
>
> with the actual value of THS_TRAIL being
>
> (1 + THS_TRAILCNT) x ByteClk cycle + ((1 to 2) + 2) xHSBYTECLK cycle +
> - (PHY output delay)
>
> with PHY output delay being about
>
> (8 + (5 to 6)) x MIPIBitClk cycle in the BitClk conversion.
>
> Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
> Signed-off-by: Francesco Dolcini
> ---
> drivers/gpu/drm/bridge/tc358768.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358768.c
> b/drivers/gpu/drm/bridge/tc358768.c
> index 854fc04f08d0..947c7dca567a 100644
> --- a/drivers/gpu/drm/bridge/tc358768.c
> +++ b/drivers/gpu/drm/bridge/tc358768.c
> @@ -779,9 +779,10 @@ static void tc358768_bridge_pre_enable(struct drm_bridge
> *bridge)
> dev_dbg(priv->dev, "TCLK_POSTCNT: 0x%x\n", val);
> tc358768_write(priv, TC358768_TCLK_POSTCNT, val);
>
> - /* 60ns + 4*UI < THS_PREPARE < 105ns + 12*UI */
> - val = tc358768_ns_to_cnt(60 + tc358768_to_ns(15 * ui_nsk),
> -dsibclk_nsk) - 5;
> + /* max(60ns + 4*UI, 8*UI) < THS_TRAILCNT < 105ns + 12*UI */
> + raw_val = tc358768_ns_to_cnt(60 + tc358768_to_ns(18 * ui_nsk),
> +dsibclk_nsk) - 4;
> + val = clamp(raw_val, 0, 15);
> dev_dbg(priv->dev, "THS_TRAILCNT: 0x%x\n", val);
> tc358768_write(priv, TC358768_THS_TRAILCNT, val);
>
> --
> 2.25.1
>
Reviewed-by: Robert Foss
Re: [PATCH v1 7/9] drm/bridge: tc358768: fix TXTAGOCNT computation
On Thu, Apr 27, 2023 at 4:35 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> Correct computation of TXTAGOCNT register.
>
> This register must be set to a value that ensure that the
> TTA-GO period = (4 x TLPX)
>
> with the actual value of TTA-GO being
>
> 4 x (TXTAGOCNT + 1) x (HSByteClk cycle)
>
> Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
> Signed-off-by: Francesco Dolcini
> ---
> drivers/gpu/drm/bridge/tc358768.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358768.c
> b/drivers/gpu/drm/bridge/tc358768.c
> index 36e33cba59a2..854fc04f08d0 100644
> --- a/drivers/gpu/drm/bridge/tc358768.c
> +++ b/drivers/gpu/drm/bridge/tc358768.c
> @@ -795,7 +795,7 @@ static void tc358768_bridge_pre_enable(struct drm_bridge
> *bridge)
>
> /* TXTAGOCNT[26:16] RXTASURECNT[10:0] */
> val = tc358768_to_ns((lptxcnt + 1) * dsibclk_nsk * 4);
> - val = tc358768_ns_to_cnt(val, dsibclk_nsk) - 1;
> + val = tc358768_ns_to_cnt(val, dsibclk_nsk) / 4 - 1;
> val2 = tc358768_ns_to_cnt(tc358768_to_ns((lptxcnt + 1) * dsibclk_nsk),
> dsibclk_nsk) - 2;
> val = val << 16 | val2;
> --
> 2.25.1
>
Reviewed-by: Robert Foss
Re: [PATCH V2] drm/amdgpu/display: Enable DC_FP for LoongArch
On Fri, May 5, 2023 at 1:57 PM WANG Xuerui wrote:
>
> Hi,
>
> On 5/5/23 21:39, Hamza Mahfooz wrote:
> >
> > Hey Huacai,
> >
> > On 5/5/23 07:32, Huacai Chen wrote:
> >> Now LoongArch provides kernel_fpu_begin() and kernel_fpu_end() in commit
> >> 2b3bd32ea3a22ea2d ("LoongArch: Provide kernel fpu functions"), so we can
> >> enable DC_FP for DCN devices.
> >
> > Have you had the chance to test how well this is working on actual
> > hardware, or was it only compile tested? If it was only compile tested,
> > it would be great if you could run some tests. Please see the following
> > for more details:
> > https://lore.kernel.org/amd-gfx/8eb69dfb-ae35-dbf2-3f82-e8cc00e53...@amd.com/
> >
> >
> Thanks for the helpful link!
>
> I did test an earlier version of this patch along with the
> arch/loongarch kernel FPU bits before that patch got upstreamed, with a
> RX 6400 (BEIGE_GOBY) on a Loongson 3A5000 + LS7A1000 system (by far the
> most popular combination for LoongArch desktops). Things like Plasma
> Wayland session or glmark2 work just fine, although I didn't go for the
> more complete testing as detailed in the mail you linked to. I'll try
> going through that procedure in the next 1~2 days when I have time & get
> physical access to that box.
>
> On a side note, I had to modprobe amdgpu with runpm=0, otherwise my
> dmesg gets flooded with PSP getting resumed every 8~10 seconds or so. I
> currently have none of the connectors plugged in. I didn't notice any
> similar reports on the Internet so I don't know if it's due to platform
> quirks or not.
That might just be part of the normal suspend/resume process. If it
happens at regular intervals, it sounds like something is waking the
GPU at a regular interval. We should probably remove that message to
avoid it being too chatty, but you may want to check what is waking it
so much as doing so sort of negates the value of runtime power
management.
Alex
>
> >>
> >> Signed-off-by: WANG Xuerui
> >> Signed-off-by: Huacai Chen
> >> ---
> >> V2: Update commit message to add the commit which provides kernel fpu
> >> functions.
> >>
> >> 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();
> This is going to conflict with commit b1bcdd409d2d ("drm/amd/display:
> Disable migration to ensure consistency of per-CPU variable"), which is
> present in next-20230505. Resolution is trivial though.
> >> #elif defined(CONFIG_PPC64)
> >> if (cpu_has_feature(CPU_FTR_VSX_COMP)) {
> >&g
Re: [PATCH v1 6/9] drm/bridge: tc358768: fix THS_ZEROCNT computation
On Thu, Apr 27, 2023 at 4:33 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> Correct computation of THS_ZEROCNT register.
>
> This register must be set to a value that ensure that
> THS_PREPARE + THS_ZERO > 145ns + 10*UI
>
> with the actual value of (THS_PREPARE + THS_ZERO) being
>
> ((1 to 2) + 1 + (TCLK_ZEROCNT + 1) + (3 to 4)) x ByteClk cycle +
> + HSByteClk x (2 + (1 to 2)) + (PHY delay)
>
> with PHY delay being about
>
> (8 + (5 to 6)) x MIPIBitClk cycle in the BitClk conversion.
>
> Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
> Signed-off-by: Francesco Dolcini
> ---
> drivers/gpu/drm/bridge/tc358768.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358768.c
> b/drivers/gpu/drm/bridge/tc358768.c
> index 360c7c65f8c4..36e33cba59a2 100644
> --- a/drivers/gpu/drm/bridge/tc358768.c
> +++ b/drivers/gpu/drm/bridge/tc358768.c
> @@ -760,9 +760,10 @@ static void tc358768_bridge_pre_enable(struct drm_bridge
> *bridge)
> /* 40ns + 4*UI < THS_PREPARE < 85ns + 6*UI */
> val = 50 + tc358768_to_ns(4 * ui_nsk);
> val = tc358768_ns_to_cnt(val, dsibclk_nsk) - 1;
> - /* THS_ZERO > 145ns + 10*UI */
> - val2 = tc358768_ns_to_cnt(145 - tc358768_to_ns(ui_nsk), dsibclk_nsk);
> - val |= (val2 - tc358768_to_ns(phy_delay_nsk)) << 8;
> + /* THS_PREPARE + THS_ZERO > 145ns + 10*UI */
> + raw_val = tc358768_ns_to_cnt(145 - tc358768_to_ns(3 * ui_nsk),
> dsibclk_nsk) - 10;
> + val2 = clamp(raw_val, 0, 127);
> + val |= val2 << 8;
> dev_dbg(priv->dev, "THS_HEADERCNT: 0x%x\n", val);
> tc358768_write(priv, TC358768_THS_HEADERCNT, val);
>
> --
> 2.25.1
>
Reviewed-by: Robert Foss
Re: [PATCH v1 5/9] drm/bridge: tc358768: fix TCLK_TRAILCNT computation
On Thu, Apr 27, 2023 at 4:35 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> Correct computation of TCLK_TRAILCNT register.
>
> The driver does not implement non-continuous clock mode, so the actual
> value doesn't make a practical difference yet. However this change also
> ensures that the value does not write to reserved registers bits in case
> of under/overflow.
>
> This register must be set to a value that ensures that
>
> TCLK-TRAIL > 60ns
> and
> TEOT <= (105 ns + 12 x UI)
>
> with the actual value of TCLK-TRAIL being
>
> (TCLK_TRAILCNT + (1 to 2)) xHSByteClkCycle +
> (2 + (1 to 2)) * HSBYTECLKCycle - (PHY output delay)
>
> with PHY output delay being about
>
> (2 to 3) x MIPIBitClk cycle in the BitClk conversion.
>
> Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
> Signed-off-by: Francesco Dolcini
> ---
> drivers/gpu/drm/bridge/tc358768.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358768.c
> b/drivers/gpu/drm/bridge/tc358768.c
> index aff400c36066..360c7c65f8c4 100644
> --- a/drivers/gpu/drm/bridge/tc358768.c
> +++ b/drivers/gpu/drm/bridge/tc358768.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -638,6 +639,7 @@ static void tc358768_bridge_pre_enable(struct drm_bridge
> *bridge)
> struct mipi_dsi_device *dsi_dev = priv->output.dev;
> unsigned long mode_flags = dsi_dev->mode_flags;
> u32 val, val2, lptxcnt, hact, data_type;
> + s32 raw_val;
> const struct drm_display_mode *mode;
> u32 dsibclk_nsk, dsiclk_nsk, ui_nsk, phy_delay_nsk;
> u32 dsiclk, dsibclk, video_start;
> @@ -749,9 +751,9 @@ static void tc358768_bridge_pre_enable(struct drm_bridge
> *bridge)
> dev_dbg(priv->dev, "TCLK_HEADERCNT: 0x%x\n", val);
> tc358768_write(priv, TC358768_TCLK_HEADERCNT, val);
>
> - /* TCLK_TRAIL > 60ns + 3*UI */
> - val = 60 + tc358768_to_ns(3 * ui_nsk);
> - val = tc358768_ns_to_cnt(val, dsibclk_nsk) - 5;
> + /* TCLK_TRAIL > 60ns AND TEOT <= 105 ns + 12*UI */
> + raw_val = tc358768_ns_to_cnt(60 + tc358768_to_ns(2 * ui_nsk),
> dsibclk_nsk) - 5;
> + val = clamp(raw_val, 0, 127);
> dev_dbg(priv->dev, "TCLK_TRAILCNT: 0x%x\n", val);
> tc358768_write(priv, TC358768_TCLK_TRAILCNT, val);
>
> --
> 2.25.1
>
Reviewed-by: Robert Foss
Re: [PATCH v1 4/9] drm/bridge: tc358768: fix TCLK_ZEROCNT computation
On Thu, Apr 27, 2023 at 4:35 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> Correct computation of TCLK_ZEROCNT register.
>
> This register must be set to a value that ensure that
> (TCLK-PREPARECNT + TCLK-ZERO) > 300ns
>
> with the actual value of (TCLK-PREPARECNT + TCLK-ZERO) being
>
> (1 to 2) + (TCLK_ZEROCNT + 1)) x HSByteClkCycle + (PHY output delay)
>
> with PHY output delay being about
>
> (2 to 3) x MIPIBitClk cycle in the BitClk conversion.
>
> Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
> Signed-off-by: Francesco Dolcini
> ---
> drivers/gpu/drm/bridge/tc358768.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358768.c
> b/drivers/gpu/drm/bridge/tc358768.c
> index dba1bf3912f1..aff400c36066 100644
> --- a/drivers/gpu/drm/bridge/tc358768.c
> +++ b/drivers/gpu/drm/bridge/tc358768.c
> @@ -742,10 +742,10 @@ static void tc358768_bridge_pre_enable(struct
> drm_bridge *bridge)
>
> /* 38ns < TCLK_PREPARE < 95ns */
> val = tc358768_ns_to_cnt(65, dsibclk_nsk) - 1;
> - /* TCLK_PREPARE > 300ns */
> - val2 = tc358768_ns_to_cnt(300 + tc358768_to_ns(3 * ui_nsk),
> - dsibclk_nsk);
> - val |= (val2 - tc358768_to_ns(phy_delay_nsk - dsibclk_nsk)) << 8;
> + /* TCLK_PREPARE + TCLK_ZERO > 300ns */
> + val2 = tc358768_ns_to_cnt(300 - tc358768_to_ns(2 * ui_nsk),
> + dsibclk_nsk) - 2;
> + val |= val2 << 8;
> dev_dbg(priv->dev, "TCLK_HEADERCNT: 0x%x\n", val);
> tc358768_write(priv, TC358768_TCLK_HEADERCNT, val);
>
> --
> 2.25.1
>
Reviewed-by: Robert Foss
Re: [PATCH v1 3/9] drm/bridge: tc358768: fix PLL target frequency
On Thu, Apr 27, 2023 at 4:32 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> Correctly compute the PLL target frequency, the current formula works
> correctly only when the input bus width is 24bit, actually to properly
> compute the PLL target frequency what is relevant is the bits-per-pixel
> on the DSI link.
>
> No regression expected since the DSI format is currently hard-coded as
> MIPI_DSI_FMT_RGB888.
>
> Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
> Signed-off-by: Francesco Dolcini
> ---
> drivers/gpu/drm/bridge/tc358768.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358768.c
> b/drivers/gpu/drm/bridge/tc358768.c
> index e9e3f9e02bba..dba1bf3912f1 100644
> --- a/drivers/gpu/drm/bridge/tc358768.c
> +++ b/drivers/gpu/drm/bridge/tc358768.c
> @@ -146,6 +146,7 @@ struct tc358768_priv {
>
> u32 pd_lines; /* number of Parallel Port Input Data Lines */
> u32 dsi_lanes; /* number of DSI Lanes */
> + u32 dsi_bpp; /* number of Bits Per Pixel over DSI */
>
> /* Parameters for PLL programming */
> u32 fbd;/* PLL feedback divider */
> @@ -284,12 +285,12 @@ static void tc358768_hw_disable(struct tc358768_priv
> *priv)
>
> static u32 tc358768_pll_to_pclk(struct tc358768_priv *priv, u32 pll_clk)
> {
> - return (u32)div_u64((u64)pll_clk * priv->dsi_lanes, priv->pd_lines);
> + return (u32)div_u64((u64)pll_clk * priv->dsi_lanes, priv->dsi_bpp);
> }
>
> static u32 tc358768_pclk_to_pll(struct tc358768_priv *priv, u32 pclk)
> {
> - return (u32)div_u64((u64)pclk * priv->pd_lines, priv->dsi_lanes);
> + return (u32)div_u64((u64)pclk * priv->dsi_bpp, priv->dsi_lanes);
> }
>
> static int tc358768_calc_pll(struct tc358768_priv *priv,
> @@ -426,6 +427,7 @@ static int tc358768_dsi_host_attach(struct mipi_dsi_host
> *host,
> priv->output.panel = panel;
>
> priv->dsi_lanes = dev->lanes;
> + priv->dsi_bpp = mipi_dsi_pixel_format_to_bpp(dev->format);
>
> /* get input ep (port0/endpoint0) */
> ret = -EINVAL;
> @@ -437,7 +439,7 @@ static int tc358768_dsi_host_attach(struct mipi_dsi_host
> *host,
> }
>
> if (ret)
> - priv->pd_lines = mipi_dsi_pixel_format_to_bpp(dev->format);
> + priv->pd_lines = priv->dsi_bpp;
>
> drm_bridge_add(>bridge);
>
> --
> 2.25.1
>
Reviewed-by: Robert Foss
Re: [PATCH v1 2/9] drm/bridge: tc358768: fix PLL parameters computation
On Thu, Apr 27, 2023 at 4:35 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> According to Toshiba documentation the PLL input clock after the divider
> should be not less than 4MHz, fix the PLL parameters computation
> accordingly.
>
> Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
> Signed-off-by: Francesco Dolcini
> ---
> drivers/gpu/drm/bridge/tc358768.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358768.c
> b/drivers/gpu/drm/bridge/tc358768.c
> index 8f349bf4fc32..e9e3f9e02bba 100644
> --- a/drivers/gpu/drm/bridge/tc358768.c
> +++ b/drivers/gpu/drm/bridge/tc358768.c
> @@ -334,13 +334,17 @@ static int tc358768_calc_pll(struct tc358768_priv *priv,
> u32 fbd;
>
> for (fbd = 0; fbd < 512; ++fbd) {
> - u32 pll, diff;
> + u32 pll, diff, pll_in;
>
> pll = (u32)div_u64((u64)refclk * (fbd + 1), divisor);
>
> if (pll >= max_pll || pll < min_pll)
> continue;
>
> + pll_in = (u32)div_u64((u64)refclk, prd + 1);
> + if (pll_in < 400)
> + continue;
> +
> diff = max(pll, target_pll) - min(pll, target_pll);
>
> if (diff < best_diff) {
> --
> 2.25.1
>
Reviewed-by: Robert Foss
Re: [PATCH v1 1/9] drm/bridge: tc358768: always enable HS video mode
On Thu, Apr 27, 2023 at 4:34 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> Always enable HS video mode setting the TXMD bit, without this change no
> video output is present with DSI sinks that are setting
> MIPI_DSI_MODE_LPM flag (tested with LT8912B DSI-HDMI bridge).
>
> Previously the driver was enabling HS mode only when the DSI sink was
> not explicitly setting the MIPI_DSI_MODE_LPM, however this is not
> correct.
>
> The MIPI_DSI_MODE_LPM is supposed to indicate that the sink is willing
> to receive data in low power mode, however clearing the
> TC358768_DSI_CONTROL_TXMD bit will make the TC358768 send video in
> LP mode that is not the intended behavior.
>
> Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
> Signed-off-by: Francesco Dolcini
> ---
> drivers/gpu/drm/bridge/tc358768.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358768.c
> b/drivers/gpu/drm/bridge/tc358768.c
> index 7c0cbe84611b..8f349bf4fc32 100644
> --- a/drivers/gpu/drm/bridge/tc358768.c
> +++ b/drivers/gpu/drm/bridge/tc358768.c
> @@ -866,8 +866,7 @@ static void tc358768_bridge_pre_enable(struct drm_bridge
> *bridge)
> val = TC358768_DSI_CONFW_MODE_SET |
> TC358768_DSI_CONFW_ADDR_DSI_CONTROL;
> val |= (dsi_dev->lanes - 1) << 1;
>
> - if (!(dsi_dev->mode_flags & MIPI_DSI_MODE_LPM))
> - val |= TC358768_DSI_CONTROL_TXMD;
> + val |= TC358768_DSI_CONTROL_TXMD;
>
> if (!(mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS))
> val |= TC358768_DSI_CONTROL_HSCKMD;
> --
> 2.25.1
>
Reviewed-by: Robert Foss
Re: [PATCH v4 04/68] clk: Introduce clk_hw_determine_rate_no_reparent()
Hi Maxime, kernel test robot noticed the following build errors: [auto build test ERROR on 145e5cddfe8b4bf607510b2dcf630d95f4db420f] url: https://github.com/intel-lab-lkp/linux/commits/Maxime-Ripard/clk-Export-clk_hw_forward_rate_request/20230505-193724 base: 145e5cddfe8b4bf607510b2dcf630d95f4db420f patch link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-4-971d5077e7d2%40cerno.tech patch subject: [PATCH v4 04/68] clk: Introduce clk_hw_determine_rate_no_reparent() config: m68k-allmodconfig (https://download.01.org/0day-ci/archive/20230506/202305060103.z9ddfq9a-...@intel.com/config) compiler: m68k-linux-gcc (GCC) 12.1.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/3acd93f10087c4a2905407786d6dc7af83c2a58c git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Maxime-Ripard/clk-Export-clk_hw_forward_rate_request/20230505-193724 git checkout 3acd93f10087c4a2905407786d6dc7af83c2a58c # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=m68k olddefconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=m68k SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot | Link: https://lore.kernel.org/oe-kbuild-all/202305060103.z9ddfq9a-...@intel.com/ All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: "clk_hw_determine_rate_no_reparent" >> [drivers/clk/clk_test.ko] undefined! -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests
Re: [RFC] Plane color pipeline KMS uAPI
On 5/5/23 15:16, Pekka Paalanen wrote:
On Fri, 5 May 2023 14:30:11 +0100
Joshua Ashton wrote:
Some corrections and replies inline.
On Fri, 5 May 2023 at 12:42, Pekka Paalanen wrote:
On Thu, 04 May 2023 15:22:59 +
Simon Ser wrote:
...
To wrap things up, let's take a real-world example: how would gamescope [2]
configure the AMD DCN 3.0 hardware for its color pipeline? The gamescope color
pipeline is described in [3]. The AMD DCN 3.0 hardware is described in [4].
AMD would expose the following objects and properties:
Plane 10
├─ "type": immutable enum {Overlay, Primary, Cursor} = Primary
└─ "color_pipeline": enum {0, 42} = 0
Color operation 42 (input CSC)
├─ "type": enum {Bypass, Matrix} = Matrix
├─ "matrix_data": blob
└─ "next": immutable color operation ID = 43
Color operation 43
├─ "type": enum {Scaling} = Scaling
└─ "next": immutable color operation ID = 44
Color operation 44 (DeGamma)
├─ "type": enum {Bypass, 1D curve} = 1D curve
├─ "1d_curve_type": enum {sRGB, PQ, …} = sRGB
└─ "next": immutable color operation ID = 45
Some vendors have per-tap degamma and some have a degamma after the sample.
How do we distinguish that behaviour?
It is important to know.
...
Btw. ISTR that if you want to do scaling properly with alpha channel,
you need optical values multiplied by alpha. Alpha vs. scaling is just
yet another thing to look into, and TF operations do not work with
pre-mult.
What are your concerns here?
I believe this is exactly the same question as yours about sampling, at
least for up-scaling where sampling the framebuffer interpolates in
some way.
Oh, interpolation mode would fit in the scaling COLOROP...
Having pre-multiplied alpha is fine with a TF: the alpha was
premultiplied in linear, then encoded with the TF by the client.
There are two different ways to pre-multiply: into optical values
(okay), and into electrical values (what everyone actually does, and
what Wayland assumes by default).
What you described is the thing mostly no-one does in GUI graphics.
Even in the web.
Yeah, I have seen this problem many times before in different fields.
There are not many transparent clients that I know of (most of them are
Gamescope Overlays), but the ones I do know of do actually do the
premultiply in linear space (mainly because they use sRGB image views
for their color attachments so it gets handled for them).
From my perspective and experience, we definitely shouldn't do anything
to try and 'fix' apps doing their premultiply in the wrong space.
I've had to deal with this before in game development on a transparent
HUD, and my solution and thinking for that was:
It was authored (or "mastered") with this behaviour in mind. So that's
what we should do.
It felt bad to 'break' the blending on the HUD of that game, but it
looked better, and it was what was intended before it was 'fixed' in a
later engine version.
It is still definitely interesting to think about, but I don't think
presents a problem at all.
In fact, doing anything would just 'break' the expected behaviour of apps.
If you think of a TF as something something relative to a bunch of
reference state or whatever then you might think "oh you can't do
that!", but you really can.
It's really best to just think of it as a mathematical encoding of a
value in all instances that we touch.
True, except when it's false. If you assume that decoding is the exact
mathematical inverse of encoding, then your conclusion follows.
Unfortunately many video standards do not have it so. BT.601, BT.709,
and I forget if BT.2020 (SDR) as well encode with one function and
decode with something that is not the inverse, and it is totally
intentional and necessary mangling of the values to get the expected
result on screen. Someone has called this "implicit color management".
So one needs to be very careful here what the actual characteristics
are.
The only issue is that you lose precision from having pre-multiplied
alpha as it's quantized to fit into the DRM format rather than using
the full range then getting divided by the alpha at blend time.
It doesn't end up being a visible issue ever however in my experience, at 8bpc.
That's true. Wait, why would you divide by alpha for blending?
Blending/interpolation is the only operation where pre-mult is useful.
I mis-spoke, I meant multiply.
- Joshie ✨
Thanks,
pq
Thanks
- Joshie ✨
Thanks,
pq
I hope comparing these properties to the diagrams linked above can help
understand how the uAPI would be used and give an idea of its viability.
Please feel free to provide feedback! It would be especially useful to have
someone familiar with Arm SoCs look at this, to confirm that this proposal
would work there.
Unless there is a show-stopper, we plan to follow up this RFC with
implementations for AMD, Intel, NVIDIA, gamescope, and IGT.
Many thanks to everybody who contributed to
Re: [Intel-gfx] [PATCH v3 4/6] drm/i915/uc: Enhancements to firmware table validation
On 5/3/2023 1:40 AM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation of the firmware table was being done inside the code
for scanning the table for the next available firmware blob. Which is
unnecessary. So pull it out into a separate function that is only
called once per blob type at init time.
Also, drop the CONFIG_SELFTEST requirement and make errors terminal.
It was mentioned that potential issues with backports would not be
caught by regular pre-merge CI as that only occurs on tip not stable
branches. Making the validation unconditional and failing driver load
on detecting of a problem ensures that such backports will also be
validated correctly.
This requires adding a firmware global flag to indicate an issue with
any of the per firmware tables. This is done rather than adding a new
state enum as a new enum value would be a much more invasive change -
lots of places would need updating to support the new error state.
Note also that this change means that a table error will cause the
driver to wedge even on platforms that don't require firmware files.
This is intentional as per the above backport concern - someone doing
backports is not guaranteed to test on every platform that they may
potential affect. So forcing a failure on all platforms ensures that
the problem will be noticed and corrected immediately.
v2: Change to unconditionally fail module load on a validation error
(review feedback/discussion with Daniele).
v3: Add a new flag to track table validation errors (review
feedback/discussion with Daniele).
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 3 +
drivers/gpu/drm/i915/gt/uc/intel_uc.h| 1 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 161 +--
3 files changed, 99 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 996168312340e..1381943b8973d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -432,6 +432,9 @@ static bool uc_is_wopcm_locked(struct intel_uc *uc)
static int __uc_check_hw(struct intel_uc *uc)
{
+ if (uc->fw_table_invalid)
+ return -EIO;
+
if (!intel_uc_supports_guc(uc))
return 0;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index 5d0f1bcc381e8..d585524d94deb 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -36,6 +36,7 @@ struct intel_uc {
struct drm_i915_gem_object *load_err_log;
bool reset_in_progress;
+ bool fw_table_invalid;
};
void intel_uc_init_early(struct intel_uc *uc);
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..64e19688788d1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -233,20 +233,22 @@ struct fw_blobs_by_type {
u32 count;
};
+static const struct uc_fw_platform_requirement blobs_guc[] = {
+ INTEL_GUC_FIRMWARE_DEFS(MAKE_FW_LIST, GUC_FW_BLOB, GUC_FW_BLOB_MMP)
+};
+
+static const struct uc_fw_platform_requirement blobs_huc[] = {
+ INTEL_HUC_FIRMWARE_DEFS(MAKE_FW_LIST, HUC_FW_BLOB, HUC_FW_BLOB_MMP,
HUC_FW_BLOB_GSC)
+};
+
+static const struct fw_blobs_by_type blobs_all[INTEL_UC_FW_NUM_TYPES] = {
+ [INTEL_UC_FW_TYPE_GUC] = { blobs_guc, ARRAY_SIZE(blobs_guc) },
+ [INTEL_UC_FW_TYPE_HUC] = { blobs_huc, ARRAY_SIZE(blobs_huc) },
+};
+
static void
__uc_fw_auto_select(struct drm_i915_private *i915, struct intel_uc_fw *uc_fw)
{
- static const struct uc_fw_platform_requirement blobs_guc[] = {
- INTEL_GUC_FIRMWARE_DEFS(MAKE_FW_LIST, GUC_FW_BLOB,
GUC_FW_BLOB_MMP)
- };
- static const struct uc_fw_platform_requirement blobs_huc[] = {
- INTEL_HUC_FIRMWARE_DEFS(MAKE_FW_LIST, HUC_FW_BLOB,
HUC_FW_BLOB_MMP, HUC_FW_BLOB_GSC)
- };
- static const struct fw_blobs_by_type blobs_all[INTEL_UC_FW_NUM_TYPES] =
{
- [INTEL_UC_FW_TYPE_GUC] = { blobs_guc, ARRAY_SIZE(blobs_guc) },
- [INTEL_UC_FW_TYPE_HUC] = { blobs_huc, ARRAY_SIZE(blobs_huc) },
- };
- static bool verified[INTEL_UC_FW_NUM_TYPES];
const struct uc_fw_platform_requirement *fw_blobs;
enum intel_platform p = INTEL_INFO(i915)->platform;
u32 fw_count;
@@ -286,6 +288,11 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct
intel_uc_fw *uc_fw)
continue;
if (uc_fw->file_selected.path) {
+ /*
+* Continuing an earlier search after a found blob
failed to load.
+* Once the previously chosen path has been found,
clear it out
+* and let the search continue from there.
+
[PATCH 1/6] DO NOT REVIEW: drm/i915: HuC loading and authentication for MTL
This is a of the HuC support for MTL series [1]. It's been included
because one of the new patches in this series depend on it, but it
should be reviewd separately in its own thread.
[1] https://patchwork.freedesktop.org/series/117080/
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 +
.../drm/i915/gt/uc/intel_gsc_meu_headers.h| 74 ++
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 31 ++-
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 182 ++
drivers/gpu/drm/i915/gt/uc/intel_huc.h| 26 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 233 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 6 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_print.h | 21 ++
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 120 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 9 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 6 -
drivers/gpu/drm/i915/i915_getparam.c | 6 +-
drivers/gpu/drm/i915/i915_reg.h | 3 +
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 14 +-
drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 2 +-
include/uapi/drm/i915_drm.h | 3 +-
20 files changed, 621 insertions(+), 134 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 20915edc8bd9..ab71ed11de79 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1322,6 +1322,9 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
ggtt->vm.scratch_range(>vm, ggtt->error_capture.start,
ggtt->error_capture.size);
+ list_for_each_entry(gt, >gt_list, ggtt_link)
+ intel_uc_resume_mappings(>uc);
+
ggtt->invalidate(ggtt);
if (flush)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
new file mode 100644
index ..d55a66202576
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
@@ -0,0 +1,74 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#ifndef _INTEL_GSC_MEU_H_
+#define _INTEL_GSC_MEU_H_
+
+#include
+
+/* Code partition directory (CPD) structures */
+struct intel_gsc_cpd_header_v2 {
+ u32 header_marker;
+#define INTEL_GSC_CPD_HEADER_MARKER 0x44504324
+
+ u32 num_of_entries;
+ u8 header_version;
+ u8 entry_version;
+ u8 header_length; /* in bytes */
+ u8 flags;
+ u32 partition_name;
+ u32 crc32;
+} __packed;
+
+struct intel_gsc_cpd_entry {
+ u8 name[12];
+
+ /*
+* Bits 0-24: offset from the beginning of the code partition
+* Bit 25: huffman compressed
+* Bits 26-31: reserved
+*/
+ u32 offset;
+#define INTEL_GSC_CPD_ENTRY_OFFSET_MASK GENMASK(24, 0)
+#define INTEL_GSC_CPD_ENTRY_HUFFMAN_COMP BIT(25)
+
+ /*
+* Module/Item length, in bytes. For Huffman-compressed modules, this
+* refers to the uncompressed size. For software-compressed modules,
+* this refers to the compressed size.
+*/
+ u32 length;
+
+ u8 reserved[4];
+} __packed;
+
+struct intel_gsc_meu_version {
+ u16 major;
+ u16 minor;
+ u16 hotfix;
+ u16 build;
+} __packed;
+
+struct intel_gsc_manifest_header {
+ u32 header_type; /* 0x4 for manifest type */
+ u32 header_length; /* in dwords */
+ u32 header_version;
+ u32 flags;
+ u32 vendor;
+ u32 date;
+ u32 size; /* In dwords, size of entire manifest (header + extensions) */
+ u32 header_id;
+ u32 internal_data;
+ struct intel_gsc_meu_version fw_version;
+ u32 security_version;
+ struct intel_gsc_meu_version meu_kit_version;
+ u32 meu_manifest_version;
+ u8 general_data[4];
+ u8 reserved3[56];
+ u32 modulus_size; /* in dwords */
+ u32 exponent_size; /* in dwords */
+} __packed;
+
+#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index fb0984f875f9..bbf21b93fc8d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -29,13 +29,29 @@ static void gsc_work(struct work_struct *work)
if (actions & GSC_ACTION_FW_LOAD) {
ret = intel_gsc_uc_fw_upload(gsc);
- if (ret == -EEXIST) /* skip proxy if not a new load */
- actions &= ~GSC_ACTION_FW_LOAD;
- else if (ret)
+ if (!ret)
+
[PATCH 2/6] drm/i915/uc/gsc: fixes and updates for GSC memory allocation
A few fixes/updates are required around the GSC memory allocation and it
is easier to do them all at the same time. The changes are as follows:
1 - Switch the memory allocation to stolen memory. We need to avoid
accesses from GSC FW to normal memory after the suspend function has
completed and to do so we can either switch to using stolen or make sure
the GSC is gone to sleep before the end of the suspend function. Given
that the GSC waits for a bit before going idle even if there are no
pending operations, it is easier and quicker to just use stolen memory.
2 - Reduce the GSC allocation size to 4MBs, which is the POR requirement.
The 8MBs were needed only for early FW and I had misunderstood that as
being the expected POR size when I sent the original patch.
3 - Perma-map the GSC allocation. This isn't required immediately, but it
will be needed later to be able to quickly extract the GSC logs, which are
inside the allocation. Since the mapping code needs to be rewritten due to
switching to stolen, it makes sense to do the switch immediately to avoid
having to change it again later.
Note that the explicit setting of CACHE_NONE for Wa_22016122933 has been
dropped because that's the default setting for stolen memory on !LLC
platforms.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Cc: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 29 ++---
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 77 ---
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h | 1 +
3 files changed, 75 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index f46eb17a7a98..4814901fac9e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -3,6 +3,7 @@
* Copyright © 2022 Intel Corporation
*/
+#include "gem/i915_gem_lmem.h"
#include "gt/intel_engine_pm.h"
#include "gt/intel_gpu_commands.h"
#include "gt/intel_gt.h"
@@ -109,38 +110,21 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
{
struct intel_gt *gt = gsc_uc_to_gt(gsc);
struct drm_i915_private *i915 = gt->i915;
- struct drm_i915_gem_object *obj;
- void *src, *dst;
+ void *src;
if (!gsc->local)
return -ENODEV;
- obj = gsc->local->obj;
-
- if (obj->base.size < gsc->fw.size)
+ if (gsc->local->size < gsc->fw.size)
return -ENOSPC;
- /*
-* Wa_22016122933: For MTL the shared memory needs to be mapped
-* as WC on CPU side and UC (PAT index 2) on GPU side
-*/
- if (IS_METEORLAKE(i915))
- i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
-
- dst = i915_gem_object_pin_map_unlocked(obj,
- i915_coherent_map_type(i915,
obj, true));
- if (IS_ERR(dst))
- return PTR_ERR(dst);
-
src = i915_gem_object_pin_map_unlocked(gsc->fw.obj,
i915_coherent_map_type(i915,
gsc->fw.obj, true));
- if (IS_ERR(src)) {
- i915_gem_object_unpin_map(obj);
+ if (IS_ERR(src))
return PTR_ERR(src);
- }
- memset(dst, 0, obj->base.size);
- memcpy(dst, src, gsc->fw.size);
+ memset_io(gsc->local_vaddr, 0, gsc->local->size);
+ memcpy_toio(gsc->local_vaddr, src, gsc->fw.size);
/*
* Wa_22016122933: Making sure the data in dst is
@@ -149,7 +133,6 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
intel_guc_write_barrier(>uc.guc);
i915_gem_object_unpin_map(gsc->fw.obj);
- i915_gem_object_unpin_map(obj);
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index bbf21b93fc8d..2ae693b01b49 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -130,26 +130,85 @@ void intel_gsc_uc_init_early(struct intel_gsc_uc *gsc)
}
}
+static int gsc_allocate_and_map_vma(struct intel_gsc_uc *gsc, u32 size)
+{
+ struct intel_gt *gt = gsc_uc_to_gt(gsc);
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ void __iomem *vaddr;
+ int ret = 0;
+
+ /*
+* The GSC FW doesn't immediately suspend after becoming idle, so there
+* is a chance that it could still be awake after we successfully
+* return from the pci suspend function, even if there are no pending
+* operations.
+* The FW might therefore try to access memory for its suspend operation
+* after the kernel has completed the HW suspend flow; this can cause
+* issues if the FW is mapped in normal RAM memory, as some of the
+* involved HW units might've already lost power.
+* The driver must therefore avoid this situation and the recommended
+
[PATCH 6/6] drm/i915/uc/gsc: Add a gsc_info debugfs
Add a new debugfs to dump information about the GSC. This includes:
- the FW path and SW tracking status;
- the release, security and compatibility versions;
- the HECI1 status registers.
Note that those are the same registers that the mei driver dumps in
their own status sysfs on DG2 (where mei owns the GSC).
To make it simpler to loop through the status register, the code has
been update to use a PICK macro and the existing code using the regs had
been adapted to match.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 29 +---
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 46 ++-
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h | 2 +
.../gpu/drm/i915/gt/uc/intel_gsc_uc_debugfs.c | 38 +++
.../gpu/drm/i915/gt/uc/intel_gsc_uc_debugfs.h | 14 ++
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 6 +--
drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c | 2 +
drivers/gpu/drm/i915/i915_reg.h | 26 ++-
9 files changed, 142 insertions(+), 24 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_debugfs.c
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_debugfs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d97d45ae1a0d..fd6a1ae542bd 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -196,7 +196,8 @@ i915-y += \
gt/uc/intel_gsc_fw.o \
gt/uc/intel_gsc_proxy.o \
gt/uc/intel_gsc_uc.o \
- gt/uc/intel_gsc_uc_heci_cmd_submit.o\
+ gt/uc/intel_gsc_uc_debugfs.o \
+ gt/uc/intel_gsc_uc_heci_cmd_submit.o \
gt/uc/intel_guc.o \
gt/uc/intel_guc_ads.o \
gt/uc/intel_guc_capture.o \
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index 0b6dcd982b14..3014e982aab2 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -12,36 +12,31 @@
#include "intel_gsc_fw.h"
#include "intel_gsc_meu_headers.h"
#include "intel_gsc_uc_heci_cmd_submit.h"
-
-#define GSC_FW_STATUS_REG _MMIO(0x116C40)
-#define GSC_FW_CURRENT_STATE REG_GENMASK(3, 0)
-#define GSC_FW_CURRENT_STATE_RESET 0
-#define GSC_FW_PROXY_STATE_NORMAL5
-#define GSC_FW_INIT_COMPLETE_BIT REG_BIT(9)
+#include "i915_reg.h"
static bool gsc_is_in_reset(struct intel_uncore *uncore)
{
- u32 fw_status = intel_uncore_read(uncore, GSC_FW_STATUS_REG);
+ u32 fw_status = intel_uncore_read(uncore,
HECI_FWSTS(MTL_GSC_HECI1_BASE, 1));
- return REG_FIELD_GET(GSC_FW_CURRENT_STATE, fw_status) ==
- GSC_FW_CURRENT_STATE_RESET;
+ return REG_FIELD_GET(HECI1_FWSTS1_CURRENT_STATE, fw_status) ==
+ HECI1_FWSTS1_CURRENT_STATE_RESET;
}
bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc)
{
struct intel_uncore *uncore = gsc_uc_to_gt(gsc)->uncore;
- u32 fw_status = intel_uncore_read(uncore, GSC_FW_STATUS_REG);
+ u32 fw_status = intel_uncore_read(uncore,
HECI_FWSTS(MTL_GSC_HECI1_BASE, 1));
- return REG_FIELD_GET(GSC_FW_CURRENT_STATE, fw_status) ==
- GSC_FW_PROXY_STATE_NORMAL;
+ return REG_FIELD_GET(HECI1_FWSTS1_CURRENT_STATE, fw_status) ==
+ HECI1_FWSTS1_PROXY_STATE_NORMAL;
}
bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
{
struct intel_uncore *uncore = gsc_uc_to_gt(gsc)->uncore;
- u32 fw_status = intel_uncore_read(uncore, GSC_FW_STATUS_REG);
+ u32 fw_status = intel_uncore_read(uncore,
HECI_FWSTS(MTL_GSC_HECI1_BASE, 1));
- return fw_status & GSC_FW_INIT_COMPLETE_BIT;
+ return fw_status & HECI1_FWSTS1_INIT_COMPLETE;
}
static inline u32 cpd_entry_offset(const struct intel_gsc_cpd_entry *entry)
@@ -265,9 +260,9 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
static int gsc_fw_wait(struct intel_gt *gt)
{
return intel_wait_for_register(gt->uncore,
- GSC_FW_STATUS_REG,
- GSC_FW_INIT_COMPLETE_BIT,
- GSC_FW_INIT_COMPLETE_BIT,
+ HECI_FWSTS(MTL_GSC_HECI1_BASE, 1),
+ HECI1_FWSTS1_INIT_COMPLETE,
+ HECI1_FWSTS1_INIT_COMPLETE,
500);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index 2ae693b01b49..5475e95d61c6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -9,8 +9,9 @@
#include "gt/intel_gt_print.h"
#include "intel_gsc_uc.h"
#include "intel_gsc_fw.h"
-#include "i915_drv.h"
#include
[PATCH 4/6] drm/i915/uc/gsc: query the GSC FW for its compatibility version
The compatibility version is queried via an MKHI command. Right now, the
only existing interface is 1.0
This is basically the interface version for the GSC FW, so the plan is
to use it as the main tracked version, including for the binary naming
in the fetch code.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 91 ++-
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 44 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 1 +
4 files changed, 120 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index df53c13e99a3..0b6dcd982b14 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -11,6 +11,7 @@
#include "gt/intel_ring.h"
#include "intel_gsc_fw.h"
#include "intel_gsc_meu_headers.h"
+#include "intel_gsc_uc_heci_cmd_submit.h"
#define GSC_FW_STATUS_REG _MMIO(0x116C40)
#define GSC_FW_CURRENT_STATE REG_GENMASK(3, 0)
@@ -270,6 +271,84 @@ static int gsc_fw_wait(struct intel_gt *gt)
500);
}
+struct intel_gsc_mkhi_header {
+ u8 group_id;
+#define MKHI_GROUP_ID_GFX_SRV 0x30
+
+ u8 command;
+#define MKHI_GFX_SRV_GET_HOST_COMPATIBILITY_VERSION (0x42)
+
+ u8 reserved;
+ u8 result;
+} __packed;
+
+struct mtl_gsc_ver_msg_in {
+ struct intel_gsc_mtl_header header;
+ struct intel_gsc_mkhi_header mkhi;
+} __packed;
+
+struct mtl_gsc_ver_msg_out {
+ struct intel_gsc_mtl_header header;
+ struct intel_gsc_mkhi_header mkhi;
+ u16 proj_major;
+ u16 compat_major;
+ u16 compat_minor;
+ u16 reserved[5];
+} __packed;
+
+static int gsc_fw_query_compatibility_version(struct intel_gsc_uc *gsc)
+{
+ struct intel_gt *gt = gsc_uc_to_gt(gsc);
+ struct mtl_gsc_ver_msg_in *msg_in;
+ struct mtl_gsc_ver_msg_out *msg_out;
+ struct i915_vma *vma;
+ u64 offset;
+ void *vaddr;
+ int err;
+
+ err = intel_guc_allocate_and_map_vma(>uc.guc, PAGE_SIZE * 2,
+, );
+ if (err) {
+ gt_err(gt, "failed to allocate vma for GSC version query\n");
+ return err;
+ }
+
+ offset = i915_ggtt_offset(vma);
+ msg_in = vaddr;
+ msg_out = vaddr + SZ_4K;
+
+ intel_gsc_uc_heci_cmd_emit_mtl_header(_in->header,
+ HECI_MEADDRESS_MKHI,
+ sizeof(*msg_in), 0);
+ msg_in->mkhi.group_id = MKHI_GROUP_ID_GFX_SRV;
+ msg_in->mkhi.command = MKHI_GFX_SRV_GET_HOST_COMPATIBILITY_VERSION;
+
+ err = intel_gsc_uc_heci_cmd_submit_packet(>uc.gsc,
+ offset, sizeof(*msg_in),
+ offset + SZ_4K, SZ_4K);
+ if (err) {
+ gt_err(gt,
+ "failed to submit GSC request for compatibility version:
%d\n",
+ err);
+ goto out_vma;
+ }
+
+ if (msg_out->header.message_size != sizeof(*msg_out)) {
+ gt_err(gt, "invalid GSC reply length %u [expected %zu], s=0x%x,
f=0x%x, r=0x%x\n",
+ msg_out->header.message_size, sizeof(*msg_out),
+ msg_out->header.status, msg_out->header.flags,
msg_out->mkhi.result);
+ err = -EPROTO;
+ goto out_vma;
+ }
+
+ gsc->fw.file_selected.ver.major = msg_out->compat_major;
+ gsc->fw.file_selected.ver.minor = msg_out->compat_minor;
+
+out_vma:
+ i915_vma_unpin_and_release(, I915_VMA_RELEASE_MAP);
+ return err;
+}
+
int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc)
{
struct intel_gt *gt = gsc_uc_to_gt(gsc);
@@ -327,11 +406,21 @@ int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc)
if (err)
goto fail;
+ err = gsc_fw_query_compatibility_version(gsc);
+ if (err)
+ goto fail;
+
+ /* we only support compatibility version 1.0 at the moment */
+ err = intel_uc_check_file_version(gsc_fw, NULL);
+ if (err)
+ goto fail;
+
/* FW is not fully operational until we enable SW proxy */
intel_uc_fw_change_status(gsc_fw, INTEL_UC_FIRMWARE_TRANSFERRED);
- gt_info(gt, "Loaded GSC firmware %s (r%u.%u.%u.%u, svn%u)\n",
+ gt_info(gt, "Loaded GSC firmware %s (cv%u.%u, r%u.%u.%u.%u, svn %u)\n",
gsc_fw->file_selected.path,
+ gsc_fw->file_selected.ver.major,
gsc_fw->file_selected.ver.minor,
gsc->release.major, gsc->release.minor,
gsc->release.patch, gsc->release.build,
gsc->security_version);
diff --git
[PATCH 5/6] drm/i915/uc/gsc: define gsc fw
Add FW definition and the matching override modparam.
The GSC FW has both a release version, based on platform and a rolling
counter, and a compatibility version, which is the one tracking
interface changes. Since what we care about is the interface, we use
the compatibility version in the buinary names.
Same as with the GuC, a major version bump indicate a
backward-incompatible change, while a minor version bump indicates a
backward-compatible one, so we use only the former in the file name.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 32 ++--
1 file changed, 24 insertions(+), 8 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 36ee96c02d74..531cd172151d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -124,6 +124,18 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
fw_def(BROXTON, 0, huc_mmp(bxt, 2, 0, 0)) \
fw_def(SKYLAKE, 0, huc_mmp(skl, 2, 0, 0))
+/*
+ * The GSC FW has both a release version, based on platform and a rolling
+ * counter, and a compatibility version, which is the one tracking
+ * interface changes. Since what we care about is the interface, we use
+ * the compatibility version in the buinary names.
+ * Same as with the GuC, a major version bump indicate a
+ * backward-incompatible change, while a minor version bump indicates a
+ * backward-compatible one, so we use only the former in the file name.
+ */
+#define INTEL_GSC_FIRMWARE_DEFS(fw_def, gsc_def) \
+ fw_def(METEORLAKE, 0, gsc_def(mtl, 1, 0))
+
/*
* Set of macros for producing a list of filenames from the above table.
*/
@@ -159,6 +171,9 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
#define MAKE_HUC_FW_PATH_MMP(prefix_, major_, minor_, patch_) \
__MAKE_UC_FW_PATH_MMP(prefix_, "huc", major_, minor_, patch_)
+#define MAKE_GSC_FW_PATH(prefix_, major_, minor_) \
+ __MAKE_UC_FW_PATH_MAJOR(prefix_, "gsc", major_)
+
/*
* All blobs need to be declared via MODULE_FIRMWARE().
* This first expansion of the table macros is solely to provide
@@ -169,6 +184,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
INTEL_GUC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_GUC_FW_PATH_MAJOR,
MAKE_GUC_FW_PATH_MMP)
INTEL_HUC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_HUC_FW_PATH_BLANK,
MAKE_HUC_FW_PATH_MMP, MAKE_HUC_FW_PATH_GSC)
+INTEL_GSC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_GSC_FW_PATH)
/*
* The next expansion of the table macros (in __uc_fw_auto_select below)
provides
@@ -218,6 +234,10 @@ struct __packed uc_fw_blob {
#define HUC_FW_BLOB_GSC(prefix_) \
UC_FW_BLOB_NEW(0, 0, 0, true, MAKE_HUC_FW_PATH_GSC(prefix_))
+#define GSC_FW_BLOB(prefix_, major_, minor_) \
+ UC_FW_BLOB_NEW(major_, minor_, 0, true, \
+ MAKE_GSC_FW_PATH(prefix_, major_, minor_))
+
struct __packed uc_fw_platform_requirement {
enum intel_platform p;
u8 rev; /* first platform rev using this FW */
@@ -245,9 +265,13 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct
intel_uc_fw *uc_fw)
static const struct uc_fw_platform_requirement blobs_huc[] = {
INTEL_HUC_FIRMWARE_DEFS(MAKE_FW_LIST, HUC_FW_BLOB,
HUC_FW_BLOB_MMP, HUC_FW_BLOB_GSC)
};
+ static const struct uc_fw_platform_requirement blobs_gsc[] = {
+ INTEL_GSC_FIRMWARE_DEFS(MAKE_FW_LIST, GSC_FW_BLOB)
+ };
static const struct fw_blobs_by_type blobs_all[INTEL_UC_FW_NUM_TYPES] =
{
[INTEL_UC_FW_TYPE_GUC] = { blobs_guc, ARRAY_SIZE(blobs_guc) },
[INTEL_UC_FW_TYPE_HUC] = { blobs_huc, ARRAY_SIZE(blobs_huc) },
+ [INTEL_UC_FW_TYPE_GSC] = { blobs_gsc, ARRAY_SIZE(blobs_gsc) },
};
static bool verified[INTEL_UC_FW_NUM_TYPES];
const struct uc_fw_platform_requirement *fw_blobs;
@@ -257,14 +281,6 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct
intel_uc_fw *uc_fw)
int i;
bool found;
- /*
-* GSC FW support is still not fully in place, so we're not defining
-* the FW blob yet because we don't want the driver to attempt to load
-* it until we're ready for it.
-*/
- if (uc_fw->type == INTEL_UC_FW_TYPE_GSC)
- return;
-
/*
* The only difference between the ADL GuC FWs is the HWConfig support.
* ADL-N does not support HWConfig, so we should use the same binary as
--
2.40.0
[PATCH 3/6] drm/i915/uc/gsc: extract release and security versions from the gsc binary
The release and security versions of the GSC binary are not used at
runtime to decide interface compatibility (there is a separate version
for that), but they're still useful for debug, so it is still worth
extracting them and printing them out in dmesg.
To get to these version, we need to navigate through various headers in
the binary. See in-code comment for details.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 130 +-
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h | 2 +
.../drm/i915/gt/uc/intel_gsc_meu_headers.h| 83 ++-
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h | 3 +
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 13 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 30 ++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 3 +
7 files changed, 237 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index 4814901fac9e..df53c13e99a3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -10,6 +10,7 @@
#include "gt/intel_gt_print.h"
#include "gt/intel_ring.h"
#include "intel_gsc_fw.h"
+#include "intel_gsc_meu_headers.h"
#define GSC_FW_STATUS_REG _MMIO(0x116C40)
#define GSC_FW_CURRENT_STATE REG_GENMASK(3, 0)
@@ -42,6 +43,129 @@ bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
return fw_status & GSC_FW_INIT_COMPLETE_BIT;
}
+static inline u32 cpd_entry_offset(const struct intel_gsc_cpd_entry *entry)
+{
+ return entry->offset & INTEL_GSC_CPD_ENTRY_OFFSET_MASK;
+}
+
+int intel_gsc_fw_get_binary_info(struct intel_uc_fw *gsc_fw, const void *data,
size_t size)
+{
+ struct intel_gsc_uc *gsc = container_of(gsc_fw, struct intel_gsc_uc,
fw);
+ struct intel_gt *gt = gsc_uc_to_gt(gsc);
+ const struct intel_gsc_layout_pointers *layout = data;
+ const struct intel_gsc_bpdt_header *bpdt_header = NULL;
+ const struct intel_gsc_bpdt_entry *bpdt_entry = NULL;
+ const struct intel_gsc_cpd_header_v2 *cpd_header = NULL;
+ const struct intel_gsc_cpd_entry *cpd_entry = NULL;
+ const struct intel_gsc_manifest_header *manifest;
+ size_t min_size = sizeof(*layout);
+ int i;
+
+ if (size < min_size) {
+ gt_err(gt, "GSC FW too small! %zu < %zu\n", size, min_size);
+ return -ENODATA;
+ }
+
+ /*
+* The GSC binary starts with the pointer layout, which contains the
+* locations of the various partitions of the binary. The one we're
+* interested in to get the version is the boot1 partition, where we can
+* find a BPDT header followed by entries, one of which points to the
+* RBE sub-section of the partition. From here, we can parse the CPD
+* header and the following entries to find the manifest location
+* (entry identified by the "RBEP.man" name), from which we can finally
+* extract the version.
+*
+* --
+* [ intel_gsc_layout_pointers ]
+* [ ... ]
+* [ boot1_offset >---]--o
+* [ ... ] |
+* -- |
+* |
+* -- |
+* [ intel_gsc_bpdt_header ]<-o
+* --
+* [ intel_gsc_bpdt_entry[]]
+* [ entry1]
+* [ ... ]
+* [ entryX]
+* [ type == GSC_RBE ]
+* [ offset >-]--o
+* [ ... ] |
+* -- |
+* |
+* -- |
+* [ intel_gsc_cpd_header_v2 ]<-o
+* --
+* [ intel_gsc_cpd_entry[] ]
+* [ entry1]
+* [ ... ]
+* [ entryX]
+* [ "RBEP.man"]
+* [ ... ]
+* [ offset >]--o
+
[PATCH 0/6] drm/i915: GSC FW support for MTL
Last chunk of the required support for the GSC FW. This includes some fixes to the GSC memory allocation, FW idefinition and version management, plus a new debugfs for debug information. Adding the FW definition will enable all the features that are dependent on the GSC being loaded (Media C6, HuC loading, SW proxy, PXP, HDCP). The HuC series [1] has been included, squashed in a single patch, as one of the patches in this series depends on it, but it should be reviewd in its own thread. [1] https://patchwork.freedesktop.org/series/117080/ Cc: Alan Previn Cc: John Harrison Cc: Suraj Kandpal Daniele Ceraolo Spurio (6): DO NOT REVIEW: drm/i915: HuC loading and authentication for MTL drm/i915/uc/gsc: fixes and updates for GSC memory allocation drm/i915/uc/gsc: extract release and security versions from the gsc binary drm/i915/uc/gsc: query the GSC FW for its compatibility version drm/i915/uc/gsc: define gsc fw drm/i915/uc/gsc: Add a gsc_info debugfs drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 + drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 277 +++--- drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h | 2 + .../drm/i915/gt/uc/intel_gsc_meu_headers.h| 143 + drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 154 +- drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h | 6 + .../gpu/drm/i915/gt/uc/intel_gsc_uc_debugfs.c | 38 +++ .../gpu/drm/i915/gt/uc/intel_gsc_uc_debugfs.h | 14 + .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 2 +- .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 1 + drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +- drivers/gpu/drm/i915/gt/uc/intel_huc.c| 182 drivers/gpu/drm/i915/gt/uc/intel_huc.h| 26 +- drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 224 +- drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 6 +- drivers/gpu/drm/i915/gt/uc/intel_huc_print.h | 21 ++ drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10 +- drivers/gpu/drm/i915/gt/uc/intel_uc.h | 2 + drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c | 2 + drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 218 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 13 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 6 - drivers/gpu/drm/i915/i915_getparam.c | 6 +- drivers/gpu/drm/i915/i915_reg.h | 25 ++ .../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 14 +- drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 2 +- include/uapi/drm/i915_drm.h | 3 +- 28 files changed, 1191 insertions(+), 214 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_debugfs.c create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_debugfs.h create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h -- 2.40.0
Re: [RFC] Plane color pipeline KMS uAPI
On Friday, May 5th, 2023 at 17:28, Daniel Vetter wrote: > Ok no comments from me on the actual color operations and semantics of all > that, because I have simply nothing to bring to that except confusion :-) > > Some higher level thoughts instead: > > - I really like that we just go with graph nodes here. I think that was > bound to happen sooner or later with kms (we almost got there with > writeback, and with hindsight maybe should have). I'd really rather not do graphs here. We only need linked lists as Sebastian said. Graphs would significantly add more complexity to this proposal, and I don't think that's a good idea unless there is a strong use-case.
Re: [RFC] Plane color pipeline KMS uAPI
On Fri, May 5, 2023 at 5:28 PM Daniel Vetter wrote:
>
> On Thu, May 04, 2023 at 03:22:59PM +, 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.
> >
> > 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.
>
> Ack on the prescriptive approach, but generic imo. Descriptive pretty much
> means you need the shaders at the same api level for fallback purposes,
> and we're not going to have that ever in kms. That would need something
> like hwc in userspace to work.
Which would be nice to have but that would be forcing a specific color
pipeline on everyone and we explicitly want to avoid that. There are
just too many trade-offs to consider.
> And not generic in it's ultimate consquence would mean we just do a blob
> for a crtc with all the vendor register stuff like adf (android display
> framework) does, because I really don't see a point in trying a
> generic-looking-but-not vendor uapi with each color op/stage split out.
>
> So from very far and pure gut feeling, this seems like a good middle
> ground in the uapi design space we have here.
Good to hear!
> > 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
>
> A bit confused, why is this an enum, and not just an immutable prop that
> points at the first element? You already can disable elements with the
> bypass thing, also bypassing by changing the pointers to the next node in
> the graph seems a bit confusing and redundant.
We want to allow multiple pipelines to exist and a plane can choose
the pipeline by selecting the first element of the pipeline. The enum
here lists all the possible pipelines that can be attached to the
surface.
> > 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
Re: [PATCH 4/4] drm/mgag200: Use DMA to copy the framebuffer to the VRAM
Hi Jocelyn,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 457391b0380335d5e9a5babdec90ac53928b23b4]
url:
https://github.com/intel-lab-lkp/linux/commits/Jocelyn-Falempe/drm-mgag200-Rename-constant-MGAREG_Status-to-MGAREG_STATUS/20230505-204705
base: 457391b0380335d5e9a5babdec90ac53928b23b4
patch link:
https://lore.kernel.org/r/20230505124337.854845-5-jfalempe%40redhat.com
patch subject: [PATCH 4/4] drm/mgag200: Use DMA to copy the framebuffer to the
VRAM
config: i386-randconfig-a013-20230501
(https://download.01.org/0day-ci/archive/20230505/202305052344.taifbcmz-...@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/b3cab0043427adee56c6f3169cdfa15526dd331c
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Jocelyn-Falempe/drm-mgag200-Rename-constant-MGAREG_Status-to-MGAREG_STATUS/20230505-204705
git checkout b3cab0043427adee56c6f3169cdfa15526dd331c
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/mgag200/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202305052344.taifbcmz-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/mgag200/mgag200_dma.c:86:6: warning: variable 'ret' set but
>> not used [-Wunused-but-set-variable]
int ret;
^
1 warning generated.
vim +/ret +86 drivers/gpu/drm/mgag200/mgag200_dma.c
81
82 void mgag200_dma_run_cmd(struct mga_device *mdev)
83 {
84 struct drm_device *dev = >base;
85 u32 primend;
> 86 int ret;
87
88 /* Add a last block to trigger the softrap interrupt */
89 mgag200_dma_add_block(mdev,
90 MGAREG_DMAPAD, 0,
91 MGAREG_DMAPAD, 0,
92 MGAREG_DMAPAD, 0,
93 MGAREG_SOFTRAP, 0);
94
95 primend = mdev->cmd_handle + mdev->cmd_idx * sizeof(struct
mga_cmd_block);
96
97 // Use primary DMA to send the commands
98 WREG32(MGAREG_PRIMADDR, (u32) mdev->cmd_handle);
99 WREG32(MGAREG_PRIMEND, primend);
100 mdev->dma_in_use = 1;
101
102 ret = wait_event_timeout(mdev->waitq, mdev->dma_in_use == 0,
HZ);
103
104 if (mdev->dma_in_use) {
105 drm_err(dev, "DMA transfert timed out\n");
106 /* something goes wrong, reset the DMA engine */
107 WREG8(MGAREG_OPMODE, MGAOPM_DMA_BLIT);
108 mdev->dma_in_use = 0;
109 }
110
111 /* reset command index to start a new sequence */
112 mdev->cmd_idx = 0;
113 }
114
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [PATCH] phy: mediatek: fix returning garbage
On 05/05/2023 11:28, Vinod Koul wrote: On 14-04-23, 08:22, Tom Rix wrote: clang reports drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: error: variable 'ret' is uninitialized when used here [-Werror,-Wuninitialized] if (ret) ^~~ ret should have been set by the preceding call to mtk_hdmi_pll_set_hw. I have applied "phy: mediatek: hdmi: mt8195: fix uninitialized variable usage in pll_calc" Thanks Vinod, that was on my list for today as well. I was a bit puzzled because you took the patch that added it, but I wasn't sure if you would take the fix. How do you want to handle things like this in the future? Regards, Matthias
Re: [RFC] Plane color pipeline KMS uAPI
On Thu, May 04, 2023 at 03:22:59PM +, 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.
>
> 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.
Ack on the prescriptive approach, but generic imo. Descriptive pretty much
means you need the shaders at the same api level for fallback purposes,
and we're not going to have that ever in kms. That would need something
like hwc in userspace to work.
And not generic in it's ultimate consquence would mean we just do a blob
for a crtc with all the vendor register stuff like adf (android display
framework) does, because I really don't see a point in trying a
generic-looking-but-not vendor uapi with each color op/stage split out.
So from very far and pure gut feeling, this seems like a good middle
ground in the uapi design space we have here.
> 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
A bit confused, why is this an enum, and not just an immutable prop that
points at the first element? You already can disable elements with the
bypass thing, also bypassing by changing the pointers to the next node in
the graph seems a bit confusing and redundant.
> 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:
Ok no comments from me on the actual color operations and semantics of all
that, because I have simply nothing to bring to that except confusion :-)
Some higher level thoughts instead:
- I really like that we just go with graph nodes here. I think that was
bound to happen sooner or later with kms (we almost got there with
writeback, and with hindsight maybe should have).
- Since there's other use-cases for graph nodes (maybe scaler modes, or
histogram
Re: [PATCH 4/4] drm/mgag200: Use DMA to copy the framebuffer to the VRAM
Hi Jocelyn,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 457391b0380335d5e9a5babdec90ac53928b23b4]
url:
https://github.com/intel-lab-lkp/linux/commits/Jocelyn-Falempe/drm-mgag200-Rename-constant-MGAREG_Status-to-MGAREG_STATUS/20230505-204705
base: 457391b0380335d5e9a5babdec90ac53928b23b4
patch link:
https://lore.kernel.org/r/20230505124337.854845-5-jfalempe%40redhat.com
patch subject: [PATCH 4/4] drm/mgag200: Use DMA to copy the framebuffer to the
VRAM
config: x86_64-randconfig-a001-20230501
(https://download.01.org/0day-ci/archive/20230505/202305052238.7ofmzu5q-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-12) 11.3.0
reproduce (this is a W=1 build):
#
https://github.com/intel-lab-lkp/linux/commit/b3cab0043427adee56c6f3169cdfa15526dd331c
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Jocelyn-Falempe/drm-mgag200-Rename-constant-MGAREG_Status-to-MGAREG_STATUS/20230505-204705
git checkout b3cab0043427adee56c6f3169cdfa15526dd331c
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 olddefconfig
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash
drivers/gpu/drm/mgag200/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202305052238.7ofmzu5q-...@intel.com/
All warnings (new ones prefixed by >>):
drivers/gpu/drm/mgag200/mgag200_dma.c: In function 'mgag200_dma_run_cmd':
>> drivers/gpu/drm/mgag200/mgag200_dma.c:86:13: warning: variable 'ret' set but
>> not used [-Wunused-but-set-variable]
86 | int ret;
| ^~~
vim +/ret +86 drivers/gpu/drm/mgag200/mgag200_dma.c
81
82 void mgag200_dma_run_cmd(struct mga_device *mdev)
83 {
84 struct drm_device *dev = >base;
85 u32 primend;
> 86 int ret;
87
88 /* Add a last block to trigger the softrap interrupt */
89 mgag200_dma_add_block(mdev,
90 MGAREG_DMAPAD, 0,
91 MGAREG_DMAPAD, 0,
92 MGAREG_DMAPAD, 0,
93 MGAREG_SOFTRAP, 0);
94
95 primend = mdev->cmd_handle + mdev->cmd_idx * sizeof(struct
mga_cmd_block);
96
97 // Use primary DMA to send the commands
98 WREG32(MGAREG_PRIMADDR, (u32) mdev->cmd_handle);
99 WREG32(MGAREG_PRIMEND, primend);
100 mdev->dma_in_use = 1;
101
102 ret = wait_event_timeout(mdev->waitq, mdev->dma_in_use == 0,
HZ);
103
104 if (mdev->dma_in_use) {
105 drm_err(dev, "DMA transfert timed out\n");
106 /* something goes wrong, reset the DMA engine */
107 WREG8(MGAREG_OPMODE, MGAOPM_DMA_BLIT);
108 mdev->dma_in_use = 0;
109 }
110
111 /* reset command index to start a new sequence */
112 mdev->cmd_idx = 0;
113 }
114
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [PATCH 3/4] drm/mgag200: Add IRQ support
Hi Jocelyn,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 457391b0380335d5e9a5babdec90ac53928b23b4]
url:
https://github.com/intel-lab-lkp/linux/commits/Jocelyn-Falempe/drm-mgag200-Rename-constant-MGAREG_Status-to-MGAREG_STATUS/20230505-204705
base: 457391b0380335d5e9a5babdec90ac53928b23b4
patch link:
https://lore.kernel.org/r/20230505124337.854845-4-jfalempe%40redhat.com
patch subject: [PATCH 3/4] drm/mgag200: Add IRQ support
config: i386-randconfig-a013-20230501
(https://download.01.org/0day-ci/archive/20230505/202305052227.ggoicr9j-...@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/cbbd69ea02ffdcee64621b76bf22cb360d943294
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Jocelyn-Falempe/drm-mgag200-Rename-constant-MGAREG_Status-to-MGAREG_STATUS/20230505-204705
git checkout cbbd69ea02ffdcee64621b76bf22cb360d943294
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/mgag200/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202305052227.ggoicr9j-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/mgag200/mgag200_drv.c:113:13: warning: no previous prototype
>> for function 'mgag200_driver_irq_handler' [-Wmissing-prototypes]
irqreturn_t mgag200_driver_irq_handler(int irq, void *arg)
^
drivers/gpu/drm/mgag200/mgag200_drv.c:113:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
irqreturn_t mgag200_driver_irq_handler(int irq, void *arg)
^
static
>> drivers/gpu/drm/mgag200/mgag200_drv.c:129:6: warning: no previous prototype
>> for function 'mgag200_init_irq' [-Wmissing-prototypes]
void mgag200_init_irq(struct mga_device *mdev)
^
drivers/gpu/drm/mgag200/mgag200_drv.c:129:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
void mgag200_init_irq(struct mga_device *mdev)
^
static
>> drivers/gpu/drm/mgag200/mgag200_drv.c:137:6: warning: no previous prototype
>> for function 'mgag200_enable_irq' [-Wmissing-prototypes]
void mgag200_enable_irq(struct mga_device *mdev)
^
drivers/gpu/drm/mgag200/mgag200_drv.c:137:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
void mgag200_enable_irq(struct mga_device *mdev)
^
static
3 warnings generated.
vim +/mgag200_driver_irq_handler +113 drivers/gpu/drm/mgag200/mgag200_drv.c
112
> 113 irqreturn_t mgag200_driver_irq_handler(int irq, void *arg)
114 {
115 struct mga_device *mdev = (struct mga_device *) arg;
116 u32 status;
117
118 status = RREG32(MGAREG_STATUS);
119
120 if (status & MGAIRQ_SOFTRAP) {
121 WREG32(MGAREG_ICLEAR, MGAIRQ_SOFTRAP);
122 mdev->dma_in_use = 0;
123 wake_up(>waitq);
124 return IRQ_HANDLED;
125 }
126 return IRQ_NONE;
127 }
128
> 129 void mgag200_init_irq(struct mga_device *mdev)
130 {
131 /* Disable *all* interrupts */
132 WREG32(MGAREG_IEN, 0);
133 /* Clear bits if they're already high */
134 WREG32(MGAREG_ICLEAR, 0xf);
135 }
136
> 137 void mgag200_enable_irq(struct mga_device *mdev)
138 {
139 /* Enable only Softrap IRQ */
140 WREG32(MGAREG_IEN, MGAIRQ_SOFTRAP);
141 }
142
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [PATCH 1/3] iommu/dma: Clean up Kconfig
On 2023-05-05 15:50, Jason Gunthorpe wrote: On Tue, Aug 16, 2022 at 06:28:03PM +0100, Robin Murphy wrote: Although iommu-dma is a per-architecture chonce, that is currently implemented in a rather haphazard way. Selecting from the arch Kconfig was the original logical approach, but is complicated by having to manage dependencies; conversely, selecting from drivers ends up hiding the architecture dependency *too* well. Instead, let's just have it enable itself automatically when IOMMU API support is enabled for the relevant architectures. It can't get much clearer than that. Signed-off-by: Robin Murphy --- arch/arm64/Kconfig | 1 - drivers/iommu/Kconfig | 3 +-- drivers/iommu/amd/Kconfig | 1 - drivers/iommu/intel/Kconfig | 1 - 4 files changed, 1 insertion(+), 5 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 571cc234d0b3..59af600445c2 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -209,7 +209,6 @@ config ARM64 select HAVE_KPROBES select HAVE_KRETPROBES select HAVE_GENERIC_VDSO - select IOMMU_DMA if IOMMU_SUPPORT select IRQ_DOMAIN select IRQ_FORCED_THREADING select KASAN_VMALLOC if KASAN diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 5c5cb5bee8b6..1d99c2d984fb 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -137,7 +137,7 @@ config OF_IOMMU # IOMMU-agnostic DMA-mapping layer config IOMMU_DMA - bool + def_bool ARM64 || IA64 || X86 Robin, do you remember why you added IA64 here? What is the Itanimum IOMMU driver? config INTEL_IOMMU bool "Support for Intel IOMMU using DMA Remapping Devices" depends on PCI_MSI && ACPI && (X86 || IA64) Yes, really :) Robin.
Re: [PATCH 1/3] iommu/dma: Clean up Kconfig
On Tue, Aug 16, 2022 at 06:28:03PM +0100, Robin Murphy wrote: > Although iommu-dma is a per-architecture chonce, that is currently > implemented in a rather haphazard way. Selecting from the arch Kconfig > was the original logical approach, but is complicated by having to > manage dependencies; conversely, selecting from drivers ends up hiding > the architecture dependency *too* well. Instead, let's just have it > enable itself automatically when IOMMU API support is enabled for the > relevant architectures. It can't get much clearer than that. > > Signed-off-by: Robin Murphy > --- > arch/arm64/Kconfig | 1 - > drivers/iommu/Kconfig | 3 +-- > drivers/iommu/amd/Kconfig | 1 - > drivers/iommu/intel/Kconfig | 1 - > 4 files changed, 1 insertion(+), 5 deletions(-) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 571cc234d0b3..59af600445c2 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -209,7 +209,6 @@ config ARM64 > select HAVE_KPROBES > select HAVE_KRETPROBES > select HAVE_GENERIC_VDSO > - select IOMMU_DMA if IOMMU_SUPPORT > select IRQ_DOMAIN > select IRQ_FORCED_THREADING > select KASAN_VMALLOC if KASAN > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > index 5c5cb5bee8b6..1d99c2d984fb 100644 > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -137,7 +137,7 @@ config OF_IOMMU > > # IOMMU-agnostic DMA-mapping layer > config IOMMU_DMA > - bool > + def_bool ARM64 || IA64 || X86 Robin, do you remember why you added IA64 here? What is the Itanimum IOMMU driver? Thanks, Jason
Re: [PATCH 3/4] drm/mgag200: Add IRQ support
Hi Jocelyn,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 457391b0380335d5e9a5babdec90ac53928b23b4]
url:
https://github.com/intel-lab-lkp/linux/commits/Jocelyn-Falempe/drm-mgag200-Rename-constant-MGAREG_Status-to-MGAREG_STATUS/20230505-204705
base: 457391b0380335d5e9a5babdec90ac53928b23b4
patch link:
https://lore.kernel.org/r/20230505124337.854845-4-jfalempe%40redhat.com
patch subject: [PATCH 3/4] drm/mgag200: Add IRQ support
config: s390-allyesconfig
(https://download.01.org/0day-ci/archive/20230505/202305052227.4o72gpi8-...@intel.com/config)
compiler: s390-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/cbbd69ea02ffdcee64621b76bf22cb360d943294
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Jocelyn-Falempe/drm-mgag200-Rename-constant-MGAREG_Status-to-MGAREG_STATUS/20230505-204705
git checkout cbbd69ea02ffdcee64621b76bf22cb360d943294
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=s390 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=s390 SHELL=/bin/bash drivers/gpu/drm/mgag200/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202305052227.4o72gpi8-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/mgag200/mgag200_drv.c:113:13: warning: no previous prototype
>> for 'mgag200_driver_irq_handler' [-Wmissing-prototypes]
113 | irqreturn_t mgag200_driver_irq_handler(int irq, void *arg)
| ^~
>> drivers/gpu/drm/mgag200/mgag200_drv.c:129:6: warning: no previous prototype
>> for 'mgag200_init_irq' [-Wmissing-prototypes]
129 | void mgag200_init_irq(struct mga_device *mdev)
| ^~~~
>> drivers/gpu/drm/mgag200/mgag200_drv.c:137:6: warning: no previous prototype
>> for 'mgag200_enable_irq' [-Wmissing-prototypes]
137 | void mgag200_enable_irq(struct mga_device *mdev)
| ^~
vim +/mgag200_driver_irq_handler +113 drivers/gpu/drm/mgag200/mgag200_drv.c
112
> 113 irqreturn_t mgag200_driver_irq_handler(int irq, void *arg)
114 {
115 struct mga_device *mdev = (struct mga_device *) arg;
116 u32 status;
117
118 status = RREG32(MGAREG_STATUS);
119
120 if (status & MGAIRQ_SOFTRAP) {
121 WREG32(MGAREG_ICLEAR, MGAIRQ_SOFTRAP);
122 mdev->dma_in_use = 0;
123 wake_up(>waitq);
124 return IRQ_HANDLED;
125 }
126 return IRQ_NONE;
127 }
128
> 129 void mgag200_init_irq(struct mga_device *mdev)
130 {
131 /* Disable *all* interrupts */
132 WREG32(MGAREG_IEN, 0);
133 /* Clear bits if they're already high */
134 WREG32(MGAREG_ICLEAR, 0xf);
135 }
136
> 137 void mgag200_enable_irq(struct mga_device *mdev)
138 {
139 /* Enable only Softrap IRQ */
140 WREG32(MGAREG_IEN, MGAIRQ_SOFTRAP);
141 }
142
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [PATCH] drm/i915/dp: prevent potential div-by-zero
On Tue, Apr 18, 2023 at 07:04:30AM -0700, Nikita Zhandarovich wrote:
> drm_dp_dsc_sink_max_slice_count() may return 0 if something goes
> wrong on the part of the DSC sink and its DPCD register. This null
> value may be later used as a divisor in intel_dsc_compute_params(),
> which will lead to an error.
> In the unlikely event that this issue occurs, fix it by testing the
> return value of drm_dp_dsc_sink_max_slice_count() against zero.
>
> Found by Linux Verification Center (linuxtesting.org) with static
> analysis tool SVACE.
>
> Fixes: a4a15c80 ("drm/i915/dp: Compute DSC pipe config in atomic check")
> Signed-off-by: Nikita Zhandarovich
Reviewed-by: Rodrigo Vivi
and pushed.
Thanks for the patch and sorry for the delay.
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 62cbab7402e9..c1825f8f885c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1533,6 +1533,11 @@ int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
> pipe_config->dsc.slice_count =
> drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd,
> true);
> + if (!pipe_config->dsc.slice_count) {
> + drm_dbg_kms(_priv->drm, "Unsupported Slice Count
> %d\n",
> + pipe_config->dsc.slice_count);
> + return -EINVAL;
> + }
> } else {
> u16 dsc_max_output_bpp = 0;
> u8 dsc_dp_slice_count;
> --
> 2.25.1
>
Re: [Intel-gfx] [RFC PATCH 2/4] drm/cgroup: Add memory accounting to DRM cgroup
I just now noticed the other comments. Wiill address them. On 2023-05-03 17:31, Tvrtko Ursulin wrote: On 03/05/2023 09:34, Maarten Lankhorst wrote: Based roughly on the rdma and misc cgroup controllers, with a lot of the accounting code borrowed from rdma. The interface is simple: - populate drmcgroup_device->regions[..] name and size for each active region. - Call drm(m)cg_register_device() - Use drmcg_try_charge to check if you can allocate a chunk of memory, use drmcg_uncharge when freeing it. This may return an error code, or -EAGAIN when the cgroup limit is reached. The ttm code transforms -EAGAIN back to -ENOSPC since it has specific logic for -ENOSPC, and returning -EAGAIN to userspace causes drmIoctl to restart infinitely. This API allows you to limit stuff with cgroups. You can see the supported cards in /sys/fs/cgroup/drm.capacity You need to echo +drm to cgroup.subtree_control, and then you can partition memory. In each cgroup subdir: drm.max shows the current limits of the cgroup. drm.current the current amount of allocated memory used by this cgroup. drm.events shows the amount of time max memory was reached. Events is not in the patch? Signed-off-by: Maarten Lankhorst --- Documentation/admin-guide/cgroup-v2.rst | 46 ++ Documentation/gpu/drm-compute.rst | 54 +++ include/linux/cgroup_drm.h | 81 kernel/cgroup/drm.c | 539 +++- 4 files changed, 699 insertions(+), 21 deletions(-) create mode 100644 Documentation/gpu/drm-compute.rst diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index f67c0829350b..b858d99cb2ef 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -2374,6 +2374,52 @@ RDMA Interface Files mlx4_0 hca_handle=1 hca_object=20 ocrdma1 hca_handle=1 hca_object=23 +DRM + + +The "drm" controller regulates the distribution and accounting of +DRM resources. + +DRM Interface Files + + + drm.max + A readwrite nested-keyed file that exists for all the cgroups + except root that describes current configured resource limit + for a DRM device. + + Lines are keyed by device name and are not ordered. + Each line contains space separated resource name and its configured + limit that can be distributed. + + The following nested keys are defined. + + == === + region.* Maximum amount of bytes that allocatable in this region + == === + + An example for xe follows:: + + :03:00.0 region.vram0=1073741824 region.stolen=max + + drm.capacity + A read-only file that describes maximum region capacity. + It only exists on the root cgroup. Not all memory can be + allocated by cgroups, as the kernel reserves some for + internal use. + + An example for xe follows:: + + :03:00.0 region.vram0=8514437120 region.stolen=67108864 + + drm.current + A read-only file that describes current resource usage. + It exists for all the cgroup except root. + + An example for xe follows:: + + :03:00.0 region.vram0=12550144 region.stolen=8650752 + HugeTLB --- diff --git a/Documentation/gpu/drm-compute.rst b/Documentation/gpu/drm-compute.rst new file mode 100644 index ..116270976ef7 --- /dev/null +++ b/Documentation/gpu/drm-compute.rst @@ -0,0 +1,54 @@ +== +Long running workloads and compute +== + +Long running workloads (compute) are workloads that will not complete in 10 +seconds. (The time let the user wait before he reaches for the power button). +This means that other techniques need to be used to manage those workloads, +that cannot use fences. + +Some hardware may schedule compute jobs, and have no way to pre-empt them, or +have their memory swapped out from them. Or they simply want their workload +not to be preempted or swapped out at all. + +This means that it differs from what is described in driver-api/dma-buf.rst. + +As with normal compute jobs, dma-fence may not be used at all. In this case, +not even to force preemption. The driver with is simply forced to unmap a BO +from the long compute job's address space on unbind immediately, not even +waiting for the workload to complete. Effectively this terminates the workload +when there is no hardware support to recover. + +Since this is undesirable, there need to be mitigations to prevent a workload +from being terminated. There are several possible approach, all with their +advantages and drawbacks. + +The first approach you will likely try is to pin all buffers used by compute. +This guarantees that the job will run uninterrupted, but also allows a very +denial of service attack by pinning as much memory as
[RFC PATCH] drm/ttm: Allow the driver to resolve a WW transaction rollback
Allow drivers to resolve a WW transaction rollback. This allows for
1) Putting a lower-priority transaction to sleep allowing another to
succeed instead both fighting using trylocks.
2) Letting the driver know whether a received -ENOMEM is the result of
competition with another WW transaction, which can be resolved using
rollback and retry or a real -ENOMEM which should be propagated back
to user-space as a failure.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo.c | 17 +++--
include/drm/ttm/ttm_bo.h | 2 ++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bd5dae4d1624..c3ccbea2be3e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -561,6 +561,10 @@ static int ttm_mem_evict_wait_busy(struct
ttm_buffer_object *busy_bo,
if (!busy_bo || !ticket)
return -EBUSY;
+ /* We want to resolve contention before trying to lock again. */
+ if (ctx->propagate_edeadlk && ctx->contended_bo)
+ return -EDEADLK;
+
if (ctx->interruptible)
r = dma_resv_lock_interruptible(busy_bo->base.resv,
ticket);
@@ -575,7 +579,15 @@ static int ttm_mem_evict_wait_busy(struct
ttm_buffer_object *busy_bo,
if (!r)
dma_resv_unlock(busy_bo->base.resv);
- return r == -EDEADLK ? -EBUSY : r;
+ if (r == -EDEADLK) {
+ if (ctx->propagate_edeadlk) {
+ ttm_bo_get(busy_bo);
+ ctx->contended_bo = busy_bo;
+ }
+ r = -EBUSY;
+ }
+
+ return r;
}
int ttm_mem_evict_first(struct ttm_device *bdev,
@@ -816,7 +828,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
goto error;
}
- ret = -ENOMEM;
+ ret = (ctx->propagate_edeadlk && ctx->contended_bo) ? -EDEADLK :
-ENOMEM;
if (!type_found) {
pr_err(TTM_PFX "No compatible memory type found\n");
ret = -EINVAL;
@@ -913,6 +925,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
if (ret)
return ret;
}
+
return 0;
}
EXPORT_SYMBOL(ttm_bo_validate);
diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h
index 8b113c384236..d8e35a794ce5 100644
--- a/include/drm/ttm/ttm_bo.h
+++ b/include/drm/ttm/ttm_bo.h
@@ -181,8 +181,10 @@ struct ttm_operation_ctx {
bool gfp_retry_mayfail;
bool allow_res_evict;
bool force_alloc;
+ bool propagate_edeadlk;
struct dma_resv *resv;
uint64_t bytes_moved;
+ struct ttm_buffer_object *contended_bo;
};
/**
--
2.39.2
Re: [RFC] Plane color pipeline KMS uAPI
On Fri, 5 May 2023 14:30:11 +0100
Joshua Ashton wrote:
> Some corrections and replies inline.
>
> On Fri, 5 May 2023 at 12:42, Pekka Paalanen wrote:
> >
> > On Thu, 04 May 2023 15:22:59 +
> > Simon Ser wrote:
...
> > > To wrap things up, let's take a real-world example: how would gamescope
> > > [2]
> > > configure the AMD DCN 3.0 hardware for its color pipeline? The gamescope
> > > color
> > > pipeline is described in [3]. The AMD DCN 3.0 hardware is described in
> > > [4].
> > >
> > > AMD would expose the following objects and properties:
> > >
> > > Plane 10
> > > ├─ "type": immutable enum {Overlay, Primary, Cursor} = Primary
> > > └─ "color_pipeline": enum {0, 42} = 0
> > > Color operation 42 (input CSC)
> > > ├─ "type": enum {Bypass, Matrix} = Matrix
> > > ├─ "matrix_data": blob
> > > └─ "next": immutable color operation ID = 43
> > > Color operation 43
> > > ├─ "type": enum {Scaling} = Scaling
> > > └─ "next": immutable color operation ID = 44
> > > Color operation 44 (DeGamma)
> > > ├─ "type": enum {Bypass, 1D curve} = 1D curve
> > > ├─ "1d_curve_type": enum {sRGB, PQ, …} = sRGB
> > > └─ "next": immutable color operation ID = 45
>
> Some vendors have per-tap degamma and some have a degamma after the sample.
> How do we distinguish that behaviour?
> It is important to know.
...
> > Btw. ISTR that if you want to do scaling properly with alpha channel,
> > you need optical values multiplied by alpha. Alpha vs. scaling is just
> > yet another thing to look into, and TF operations do not work with
> > pre-mult.
>
> What are your concerns here?
I believe this is exactly the same question as yours about sampling, at
least for up-scaling where sampling the framebuffer interpolates in
some way.
Oh, interpolation mode would fit in the scaling COLOROP...
> Having pre-multiplied alpha is fine with a TF: the alpha was
> premultiplied in linear, then encoded with the TF by the client.
There are two different ways to pre-multiply: into optical values
(okay), and into electrical values (what everyone actually does, and
what Wayland assumes by default).
What you described is the thing mostly no-one does in GUI graphics.
Even in the web.
> If you think of a TF as something something relative to a bunch of
> reference state or whatever then you might think "oh you can't do
> that!", but you really can.
> It's really best to just think of it as a mathematical encoding of a
> value in all instances that we touch.
True, except when it's false. If you assume that decoding is the exact
mathematical inverse of encoding, then your conclusion follows.
Unfortunately many video standards do not have it so. BT.601, BT.709,
and I forget if BT.2020 (SDR) as well encode with one function and
decode with something that is not the inverse, and it is totally
intentional and necessary mangling of the values to get the expected
result on screen. Someone has called this "implicit color management".
So one needs to be very careful here what the actual characteristics
are.
> The only issue is that you lose precision from having pre-multiplied
> alpha as it's quantized to fit into the DRM format rather than using
> the full range then getting divided by the alpha at blend time.
> It doesn't end up being a visible issue ever however in my experience, at
> 8bpc.
That's true. Wait, why would you divide by alpha for blending?
Blending/interpolation is the only operation where pre-mult is useful.
Thanks,
pq
>
> Thanks
> - Joshie ✨
>
> >
> >
> > Thanks,
> > pq
> >
> > >
> > > I hope comparing these properties to the diagrams linked above can help
> > > understand how the uAPI would be used and give an idea of its viability.
> > >
> > > Please feel free to provide feedback! It would be especially useful to
> > > have
> > > someone familiar with Arm SoCs look at this, to confirm that this proposal
> > > would work there.
> > >
> > > Unless there is a show-stopper, we plan to follow up this RFC with
> > > implementations for AMD, Intel, NVIDIA, gamescope, and IGT.
> > >
> > > Many thanks to everybody who contributed to the hackfest, on-site or
> > > remotely!
> > > Let's work together to make this happen!
> > >
> > > Simon, on behalf of the hackfest participants
> > >
> > > [1]: https://wiki.gnome.org/Hackfests/ShellDisplayNext2023
> > > [2]: https://github.com/ValveSoftware/gamescope
> > > [3]:
> > > https://github.com/ValveSoftware/gamescope/blob/5af321724c8b8a29cef5ae9e31293fd5d560c4ec/src/docs/Steam%20Deck%20Display%20Pipeline.png
> > > [4]: https://kernel.org/doc/html/latest/_images/dcn3_cm_drm_current.svg
> >
pgpFKEwG8wI8J.pgp
Description: OpenPGP digital signature
Re: [PATCH] Documentation/gpu: Requirements for driver-specific KMS uAPIs
On 5/5/23 09:35, Daniel Vetter wrote: > On Fri, May 05, 2023 at 09:20:26AM -0400, Harry Wentland wrote: >> >> >> On 5/5/23 06:16, Daniel Vetter wrote: >>> On Fri, May 05, 2023 at 11:43:20AM +0300, Pekka Paalanen wrote: On Thu, 4 May 2023 17:25:57 -0400 Harry Wentland wrote: > 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: >>> >>> I don't like this for two fairly fundamental reasons, neither of which are >>> that sometimes merging stuff that's not great is the right thing to do to >>> move the community and ecosystem forward. >>> Hi, should it be "require" instead of "ask"? > + > +- 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 Seems fine to me. I have another addition to suggest: When such UAPI is introduced, require that it comes with an expiration date. This date should be unmissable, not just documented. The kernel module parameter name to enable the UAPI could contain the expiry date, for example. After all, the most important thing to get through to users is that this *will* go away and not just theoretically. >>> >>> There's no taking-backsies with uapi. If there is a regression report, >>> we'll have to keep it around, for the usual approximation of "forever" >>> >>> And this is the first reason I don't like this, from other write-ups and >>> talking with people it seems like there's the assumption that if we just >>> hide this behind enough knobs, we can remove the uapi again. >>> >>> We can't. >>> >> >> Yeah, that last bullet was least sure about. FWIW, I'm prepared to maintain >> AMD driver-specific properties for this "forever." > > I guess a middle ground would be to up-front limit this to one generation > only. > > And then accept reality that the
Re: [PATCH V2] drm/amdgpu/display: Enable DC_FP for LoongArch
Hey Huacai,
On 5/5/23 07:32, Huacai Chen wrote:
Now LoongArch provides kernel_fpu_begin() and kernel_fpu_end() in commit
2b3bd32ea3a22ea2d ("LoongArch: Provide kernel fpu functions"), so we can
enable DC_FP for DCN devices.
Have you had the chance to test how well this is working on actual
hardware, or was it only compile tested? If it was only compile tested,
it would be great if you could run some tests. Please see the following
for more details:
https://lore.kernel.org/amd-gfx/8eb69dfb-ae35-dbf2-3f82-e8cc00e53...@amd.com/
Signed-off-by: WANG Xuerui
Signed-off-by: Huacai Chen
---
V2: Update commit message to add the commit which provides kernel fpu
functions.
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 := -mfpu=64
+dml_rcflags := -msoft-float
+endif
+
ifdef CONFIG_CC_IS_GCC
ifneq ($(call gcc-min-version, 70100),y)
IS_OLD_GCC = 1
--
Hamza
Re: [PATCH] Documentation/gpu: Requirements for driver-specific KMS uAPIs
On Fri, May 05, 2023 at 09:20:26AM -0400, Harry Wentland wrote: > > > On 5/5/23 06:16, Daniel Vetter wrote: > > On Fri, May 05, 2023 at 11:43:20AM +0300, Pekka Paalanen wrote: > >> On Thu, 4 May 2023 17:25:57 -0400 > >> Harry Wentland wrote: > >> > >>> 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: > > > > I don't like this for two fairly fundamental reasons, neither of which are > > that sometimes merging stuff that's not great is the right thing to do to > > move the community and ecosystem forward. > > > >> Hi, > >> > >> should it be "require" instead of "ask"? > >> > >>> + > >>> +- 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 > >> > >> Seems fine to me. I have another addition to suggest: > >> > >> When such UAPI is introduced, require that it comes with an expiration > >> date. This date should be unmissable, not just documented. The kernel > >> module parameter name to enable the UAPI could contain the expiry date, > >> for example. > >> > >> After all, the most important thing to get through to users is that > >> this *will* go away and not just theoretically. > > > > There's no taking-backsies with uapi. If there is a regression report, > > we'll have to keep it around, for the usual approximation of "forever" > > > > And this is the first reason I don't like this, from other write-ups and > > talking with people it seems like there's the assumption that if we just > > hide this behind enough knobs, we can remove the uapi again. > > > > We can't. > > > > Yeah, that last bullet was least sure about. FWIW, I'm prepared to maintain > AMD driver-specific properties for this "forever." I guess a middle ground would be to up-front limit this to one generation only. And then accept reality that the generic solution takes a bit longer and end up
Re: [PATCH] Documentation/gpu: Requirements for driver-specific KMS uAPIs
On 05/05, Pekka Paalanen wrote: On Fri, 5 May 2023 12:16:55 +0200 Daniel Vetter wrote: > On Fri, May 05, 2023 at 11:43:20AM +0300, Pekka Paalanen wrote: > > On Thu, 4 May 2023 17:25:57 -0400 > > Harry Wentland wrote: > > > > > 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: > > I don't like this for two fairly fundamental reasons, neither of which are > that sometimes merging stuff that's not great is the right thing to do to > move the community and ecosystem forward. > > > Hi, > > > > should it be "require" instead of "ask"? > > > > > + > > > +- 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 > > > > Seems fine to me. I have another addition to suggest: > > > > When such UAPI is introduced, require that it comes with an expiration > > date. This date should be unmissable, not just documented. The kernel > > module parameter name to enable the UAPI could contain the expiry date, > > for example. > > > > After all, the most important thing to get through to users is that > > this *will* go away and not just theoretically. > > There's no taking-backsies with uapi. If there is a regression report, > we'll have to keep it around, for the usual approximation of "forever" > > And this is the first reason I don't like this, from other write-ups and > talking with people it seems like there's the assumption that if we just > hide this behind enough knobs, we can remove the uapi again. > > We can't. > > The times we've hidden uapi behind knobs was _not_ for uapi we > fundamentally didn't want, at least for the long term. But for the cases > where the overall scope was simply too big, and we needed some time > in-tree to shake out all the bugs (across both kernel and userspace), and > fill out any of the details. Some examples: > > - intel hiding new hw enabling behind the alpha support is not about > hiding that uapi so we can change
Re: [RFC] Plane color pipeline KMS uAPI
Some corrections and replies inline.
On Fri, 5 May 2023 at 12:42, Pekka Paalanen wrote:
>
> On Thu, 04 May 2023 15:22:59 +
> 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.
>
> Hi Simon,
>
> this is an excellent write-up, thank you!
>
> Harry's question about what constitutes UAPI is a good one for danvet.
>
> I don't really have much to add here, a couple inline comments. I think
> this could work.
>
> >
> > 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
> > ├─
Re: [PATCH] Documentation/gpu: Requirements for driver-specific KMS uAPIs
On 5/5/23 06:16, Daniel Vetter wrote: > On Fri, May 05, 2023 at 11:43:20AM +0300, Pekka Paalanen wrote: >> On Thu, 4 May 2023 17:25:57 -0400 >> Harry Wentland wrote: >> >>> 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: > > I don't like this for two fairly fundamental reasons, neither of which are > that sometimes merging stuff that's not great is the right thing to do to > move the community and ecosystem forward. > >> Hi, >> >> should it be "require" instead of "ask"? >> >>> + >>> +- 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 >> >> Seems fine to me. I have another addition to suggest: >> >> When such UAPI is introduced, require that it comes with an expiration >> date. This date should be unmissable, not just documented. The kernel >> module parameter name to enable the UAPI could contain the expiry date, >> for example. >> >> After all, the most important thing to get through to users is that >> this *will* go away and not just theoretically. > > There's no taking-backsies with uapi. If there is a regression report, > we'll have to keep it around, for the usual approximation of "forever" > > And this is the first reason I don't like this, from other write-ups and > talking with people it seems like there's the assumption that if we just > hide this behind enough knobs, we can remove the uapi again. > > We can't. > Yeah, that last bullet was least sure about. FWIW, I'm prepared to maintain AMD driver-specific properties for this "forever." > The times we've hidden uapi behind knobs was _not_ for uapi we > fundamentally didn't want, at least for the long term. But for the cases > where the overall scope was simply too big, and we needed some time > in-tree to shake out all the bugs (across both kernel and userspace), and > fill out any of the details. Some examples: > > - intel hiding new hw enabling behind the alpha support is not about > hiding that uapi so we can change it. It's about the fact that not yet > all enabling
Re: [PATCH] Documentation/gpu: Requirements for driver-specific KMS uAPIs
On Fri, May 05, 2023 at 02:20:39PM +0300, Pekka Paalanen wrote: > On Fri, 5 May 2023 12:16:55 +0200 > Daniel Vetter wrote: > > > On Fri, May 05, 2023 at 11:43:20AM +0300, Pekka Paalanen wrote: > > > On Thu, 4 May 2023 17:25:57 -0400 > > > Harry Wentland wrote: > > > > > > > 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: > > > > I don't like this for two fairly fundamental reasons, neither of which are > > that sometimes merging stuff that's not great is the right thing to do to > > move the community and ecosystem forward. > > > > > Hi, > > > > > > should it be "require" instead of "ask"? > > > > > > > + > > > > +- 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 > > > > > > Seems fine to me. I have another addition to suggest: > > > > > > When such UAPI is introduced, require that it comes with an expiration > > > date. This date should be unmissable, not just documented. The kernel > > > module parameter name to enable the UAPI could contain the expiry date, > > > for example. > > > > > > After all, the most important thing to get through to users is that > > > this *will* go away and not just theoretically. > > > > There's no taking-backsies with uapi. If there is a regression report, > > we'll have to keep it around, for the usual approximation of "forever" > > > > And this is the first reason I don't like this, from other write-ups and > > talking with people it seems like there's the assumption that if we just > > hide this behind enough knobs, we can remove the uapi again. > > > > We can't. > > > > The times we've hidden uapi behind knobs was _not_ for uapi we > >
[PATCH 3/4] drm/mgag200: Add IRQ support
Register irq, and enable the softrap irq.
This patch has no functional impact since softrap
irq can't be triggered without DMA.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 41 +++
drivers/gpu/drm/mgag200/mgag200_drv.h | 3 ++
drivers/gpu/drm/mgag200/mgag200_reg.h | 3 ++
3 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index 976f0ab2006b..3566fcdfe1e4 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -110,12 +110,43 @@ resource_size_t mgag200_device_probe_vram(struct
mga_device *mdev)
return mgag200_probe_vram(mdev->vram, resource_size(mdev->vram_res));
}
+irqreturn_t mgag200_driver_irq_handler(int irq, void *arg)
+{
+ struct mga_device *mdev = (struct mga_device *) arg;
+ u32 status;
+
+ status = RREG32(MGAREG_STATUS);
+
+ if (status & MGAIRQ_SOFTRAP) {
+ WREG32(MGAREG_ICLEAR, MGAIRQ_SOFTRAP);
+ mdev->dma_in_use = 0;
+ wake_up(>waitq);
+ return IRQ_HANDLED;
+ }
+ return IRQ_NONE;
+}
+
+void mgag200_init_irq(struct mga_device *mdev)
+{
+ /* Disable *all* interrupts */
+ WREG32(MGAREG_IEN, 0);
+ /* Clear bits if they're already high */
+ WREG32(MGAREG_ICLEAR, 0xf);
+}
+
+void mgag200_enable_irq(struct mga_device *mdev)
+{
+ /* Enable only Softrap IRQ */
+ WREG32(MGAREG_IEN, MGAIRQ_SOFTRAP);
+}
+
int mgag200_device_preinit(struct mga_device *mdev)
{
struct drm_device *dev = >base;
struct pci_dev *pdev = to_pci_dev(dev->dev);
resource_size_t start, len;
struct resource *res;
+ int ret;
/* BAR 1 contains registers */
@@ -153,6 +184,16 @@ int mgag200_device_preinit(struct mga_device *mdev)
if (!mdev->vram)
return -ENOMEM;
+ mgag200_init_irq(mdev);
+ ret = devm_request_irq(dev->dev, pdev->irq, mgag200_driver_irq_handler,
+ IRQF_SHARED, "mgag200_irq", mdev);
+ if (ret < 0) {
+ drm_err(dev, "devm_request_irq(VRAM) failed %d\n", ret);
+ return -ENXIO;
+ }
+ init_waitqueue_head(>waitq);
+
+ mgag200_enable_irq(mdev);
return 0;
}
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 9e604dbb8e44..02175bfaf5a8 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -291,6 +291,9 @@ struct mga_device {
void __iomem*vram;
resource_size_t vram_available;
+ wait_queue_head_t waitq;
+ int dma_in_use;
+
struct drm_plane primary_plane;
struct drm_crtc crtc;
struct drm_encoder encoder;
diff --git a/drivers/gpu/drm/mgag200/mgag200_reg.h
b/drivers/gpu/drm/mgag200/mgag200_reg.h
index aa73463674e4..748c8e18e938 100644
--- a/drivers/gpu/drm/mgag200/mgag200_reg.h
+++ b/drivers/gpu/drm/mgag200/mgag200_reg.h
@@ -107,6 +107,9 @@
#defineMGAREG_ICLEAR 0x1e18
#defineMGAREG_IEN 0x1e1c
+/* same bit shift for MGAREG_IEN, MGAREG_ICLEAR and MGAREG_STATUS */
+#define MGAIRQ_SOFTRAP BIT(0)
+
#defineMGAREG_VCOUNT 0x1e20
#defineMGAREG_Reset0x1e40
--
2.39.2
[PATCH 4/4] drm/mgag200: Use DMA to copy the framebuffer to the VRAM
Even if the transfer is not faster, it brings significant
improvement in latencies and CPU usage.
CPU usage drops from 100% of one core to 3% when continuously
refreshing the screen.
The primary DMA is used to send commands (register write), and
the secondary DMA to send the pixel data.
It uses the ILOAD command (chapter 4.5.7 in G200 specification),
which allows to load an image, or a part of an image from system
memory to VRAM.
The last command sent, is a softrap command, which triggers an IRQ
when the DMA transfer is complete.
For 16bits and 24bits pixel width, each line is padded to make sure,
the DMA transfer is a multiple of 32bits. The padded bytes won't be
drawn on the screen, so they don't need to be initialized.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/Makefile | 3 +-
drivers/gpu/drm/mgag200/mgag200_dma.c | 114 +
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +
drivers/gpu/drm/mgag200/mgag200_drv.h | 25 +
drivers/gpu/drm/mgag200/mgag200_mode.c | 131 -
drivers/gpu/drm/mgag200/mgag200_reg.h | 25 +
6 files changed, 295 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/mgag200/mgag200_dma.c
diff --git a/drivers/gpu/drm/mgag200/Makefile b/drivers/gpu/drm/mgag200/Makefile
index 182e224c460d..96e23dc5572c 100644
--- a/drivers/gpu/drm/mgag200/Makefile
+++ b/drivers/gpu/drm/mgag200/Makefile
@@ -11,6 +11,7 @@ mgag200-y := \
mgag200_g200se.o \
mgag200_g200wb.o \
mgag200_i2c.o \
- mgag200_mode.o
+ mgag200_mode.o \
+ mgag200_dma.o
obj-$(CONFIG_DRM_MGAG200) += mgag200.o
diff --git a/drivers/gpu/drm/mgag200/mgag200_dma.c
b/drivers/gpu/drm/mgag200/mgag200_dma.c
new file mode 100644
index ..fe063fa2b5f1
--- /dev/null
+++ b/drivers/gpu/drm/mgag200/mgag200_dma.c
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2023 Red Hat
+ *
+ * Authors: Jocelyn Falempe
+ *
+ */
+
+#include
+#include
+
+#include "mgag200_drv.h"
+#include "mgag200_reg.h"
+
+/* Maximum number of command block for one DMA transfert
+ * iload should only use 4 blocks
+ */
+#define MGA_MAX_CMD50
+
+#define MGA_DMA_SIZE (4 * 1024 * 1024)
+#define MGA_MIN_DMA_SIZE (64 * 1024)
+
+/*
+ * Allocate coherent buffers for DMA transfert.
+ * We need two buffers, one for the commands, and one for the data.
+ * If allocation fails, mdev->dma_buf will be NULL, and the driver will
+ * fallback to memcpy().
+ */
+void mgag200_dma_allocate(struct mga_device *mdev)
+{
+ struct drm_device *dev = >base;
+ int size;
+ /* Allocate the command buffer */
+ mdev->cmd = dmam_alloc_coherent(dev->dev, MGA_MAX_CMD *
sizeof(*mdev->cmd),
+ >cmd_handle, GFP_KERNEL);
+
+ if (!mdev->cmd) {
+ drm_warn(dev, "DMA command buffer allocation failed, fallback
to cpu copy\n");
+ return;
+ }
+
+ for (size = MGA_DMA_SIZE; size >= MGA_MIN_DMA_SIZE; size = size >> 1) {
+ mdev->dma_buf = dmam_alloc_coherent(dev->dev, size,
>dma_handle, GFP_KERNEL);
+ if (mdev->dma_buf)
+ break;
+ }
+ if (!mdev->dma_buf) {
+ drm_warn(dev, "DMA data buffer allocation failed, fallback to
cpu copy\n");
+ return;
+ }
+ mdev->dma_size = size;
+ drm_info(dev, "Using DMA with a %dk data buffer\n", size / 1024);
+}
+
+/*
+ * Matrox uses commands block to program the hardware through DMA.
+ * Each command is a register write, and each block contains 4 commands
+ * packed in 5 words(u32).
+ * First word is the 4 register index (8bit) to write for the 4 commands,
+ * followed by the four values to be written.
+ */
+void mgag200_dma_add_block(struct mga_device *mdev,
+ u32 reg0, u32 val0,
+ u32 reg1, u32 val1,
+ u32 reg2, u32 val2,
+ u32 reg3, u32 val3)
+{
+ if (mdev->cmd_idx >= MGA_MAX_CMD) {
+ pr_err("mgag200: exceeding the DMA command buffer size\n");
+ return;
+ }
+
+ mdev->cmd[mdev->cmd_idx] = (struct mga_cmd_block) {
+ .cmd = DMAREG(reg0) | DMAREG(reg1) << 8 | DMAREG(reg2) << 16 |
DMAREG(reg3) << 24,
+ .v0 = val0,
+ .v1 = val1,
+ .v2 = val2,
+ .v3 = val3};
+ mdev->cmd_idx++;
+}
+
+void mgag200_dma_run_cmd(struct mga_device *mdev)
+{
+ struct drm_device *dev = >base;
+ u32 primend;
+ int ret;
+
+ /* Add a last block to trigger the softrap interrupt */
+ mgag200_dma_add_block(mdev,
+ MGAREG_DMAPAD, 0,
+ MGAREG_DMAPAD, 0,
+ MGAREG_DMAPAD, 0,
+ MGAREG_SOFTRAP, 0);
+
+ primend = mdev->cmd_handle + mdev->cmd_idx * sizeof(struct
mga_cmd_block);
+
[RFC PATCH 0/4] drm/mgag200: Use DMA to copy the framebuffer to the VRAM
This series adds DMA and IRQ for the mgag200 driver. Unfortunately the DMA doesn't make the driver faster. But it's still a big improvement regarding CPU usage and latency. CPU usage goes from 100% of 1 CPU to 3% (using top and refreshing the screen continuously). top without DMA, and a bash script to refresh the screen continuously PID S %CPU TIME+ COMMAND 1536 R 100.0 4:02.78 kworker/1:0+events 1612 S 3.0 0:03.82 bash 16 I 0.3 0:01.56 rcu_preempt 1467 I 0.3 0:00.11 kworker/u64:1-events_unbound 3650 R 0.3 0:00.02 top top with DMA, and the same bash script: PID S %CPU TIME+ COMMAND 1335 D 3.0 0:01.26 kworker/2:0+events 1486 S 0.3 0:00.14 bash 1846 R 0.3 0:00.03 top 1 S 0.0 0:01.87 systemd 2 S 0.0 0:00.00 kthreadd Latency, measured with cyclictest -s -l 1: Without DMA: # /dev/cpu_dma_latency set to 0us policy: other/other: loadavg: 1.52 0.52 0.33 3/358 2025 T: 0 ( 1977) P: 0 I:1000 C: 1 Min: 7 Act: 56 Avg: 85 Max:2542 With DMA: # /dev/cpu_dma_latency set to 0us policy: other/other: loadavg: 1.27 0.48 0.18 2/363 2498 T: 0 ( 2403) P: 0 I:1000 C: 1 Min: 8 Act: 62 Avg: 59 Max: 339 Last benchmark is glxgears. It's still software rendering, but on my 2 core CPU, freeing one CPU constantly doing memcpy(), allows it to draw more frames. Without DMA: 415 frames in 5.0 seconds = 82.973 FPS 356 frames in 5.0 seconds = 71.167 FPS with DMA: 717 frames in 5.0 seconds = 143.343 FPS 720 frames in 5.0 seconds = 143.993 FPS Regarding the implementation: The driver uses primary DMA to send drawing engine commands, and secondary DMA to send the pixels to an ILOAD command. You can directly program the ILOAD command, and use Primary DMA to send the pixels, but in this case, you can't use the softrap interrupt to wait for the DMA completion. The pixels are copied from the gem framebuffer to the DMA buffer, but as system memory is much faster than VRAM, it has a negligible impact. DMA buffer size: On my test machine, I can allocate only 4MB of dma coherent memory, and the framebuffer is 5MB. So the driver has to cut it into small chunks when the full framebuffer is refreshed. My implementation tries to allocate 4MB, and then smaller allocation until it succeeds. If it fails to allocate, DMA will be disabled. That's probably not perfect, but at least it's simple. It's also possible to do some kind of scatter gather DMA, by sending multiple ILOAD/SECDMA, but that increases the complexity a bit. Adding a module parameter to disable DMA: I think before merging this work, I will add a module parameter to disable DMA, so that if something goes wrong it's easy to turn it off. Pixel width: I tested this in 16 bits per pixels RGB565 and 32 bits per pixels (XRGB). I didn't find a userspace able to use 24 bits (RGB888), Xorg uses XRGB when specifying "DefaultDepth" to 24. Big endian: The DMA can be configured to handle the be->le conversion, but I can't test it, so it's not done yet. As I don't know if there are still big endian systems with mgag200, maybe disabling DMA for big endian is the safest option ? I think the complexity is low, as it only adds ~350 lines, less than 10% of the whole mgag200 driver (~5000 lines). drivers/gpu/drm/mgag200/Makefile | 3 +- drivers/gpu/drm/mgag200/mgag200_dma.c | 114 ++ drivers/gpu/drm/mgag200/mgag200_drv.c | 43 +++ drivers/gpu/drm/mgag200/mgag200_drv.h | 28 ++ drivers/gpu/drm/mgag200/mgag200_mode.c | 200 ++- drivers/gpu/drm/mgag200/mgag200_reg.h | 30 ++- 6 files changed, 362 insertions(+), 56 deletions(-) Signed-off-by: Jocelyn Falempe base-commit: 457391b0380335d5 (tag: v6.3)
[PATCH 1/4] drm/mgag200: Rename constant MGAREG_Status to MGAREG_STATUS
From: Thomas Zimmermann
Register constants are upper case. Fix MGAREG_Status accordingly.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Gerd Hoffmann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +++---
drivers/gpu/drm/mgag200/mgag200_reg.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 0a5aaf78172a..9a24b9c00745 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -109,12 +109,12 @@ static inline void mga_wait_vsync(struct mga_device *mdev)
unsigned int status = 0;
do {
- status = RREG32(MGAREG_Status);
+ status = RREG32(MGAREG_STATUS);
} while ((status & 0x08) && time_before(jiffies, timeout));
timeout = jiffies + HZ/10;
status = 0;
do {
- status = RREG32(MGAREG_Status);
+ status = RREG32(MGAREG_STATUS);
} while (!(status & 0x08) && time_before(jiffies, timeout));
}
@@ -123,7 +123,7 @@ static inline void mga_wait_busy(struct mga_device *mdev)
unsigned long timeout = jiffies + HZ;
unsigned int status = 0;
do {
- status = RREG8(MGAREG_Status + 2);
+ status = RREG8(MGAREG_STATUS + 2);
} while ((status & 0x01) && time_before(jiffies, timeout));
}
diff --git a/drivers/gpu/drm/mgag200/mgag200_reg.h
b/drivers/gpu/drm/mgag200/mgag200_reg.h
index 1019ffd6c260..aa73463674e4 100644
--- a/drivers/gpu/drm/mgag200/mgag200_reg.h
+++ b/drivers/gpu/drm/mgag200/mgag200_reg.h
@@ -102,7 +102,7 @@
#define MGAREG_EXEC0x0100
#defineMGAREG_FIFOSTATUS 0x1e10
-#defineMGAREG_Status 0x1e14
+#defineMGAREG_STATUS 0x1e14
#define MGAREG_CACHEFLUSH 0x1fff
#defineMGAREG_ICLEAR 0x1e18
#defineMGAREG_IEN 0x1e1c
--
2.39.2
[PATCH 2/4] drm/mgag200: Simplify offset and scale computation.
Now that the driver handles only 16, 24 and 32-bit framebuffer,
it can be simplified.
No functional changes.
offset:
16bit: (bppshift = 1)
offset = width >> (4 - bppshift) => width / 8 => pitch / 16
24bit: (bppshift = 0)
offset = (width * 3) >> (4 - bppshift) => width * 3 / 16 => pitch / 16
32bit: (bppshift = 2)
offset = width >> (4 - bppshift) => width / 4 => pitch / 16
scale:
16bit:
scale = (1 << bppshift) - 1 => 1
24bit:
scale = ((1 << bppshift) * 3) - 1 => 2
32bit:
scale = (1 << bppshift) - 1 => 3
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 63 +++---
1 file changed, 16 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 9a24b9c00745..7d8c65372ac4 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -280,30 +280,16 @@ void mgag200_set_mode_regs(struct mga_device *mdev, const
struct drm_display_mod
WREG8(MGA_MISC_OUT, misc);
}
-static u8 mgag200_get_bpp_shift(const struct drm_format_info *format)
-{
- static const u8 bpp_shift[] = {0, 1, 0, 2};
-
- return bpp_shift[format->cpp[0] - 1];
-}
-
/*
* Calculates the HW offset value from the framebuffer's pitch. The
* offset is a multiple of the pixel size and depends on the display
- * format.
+ * format. With width in pixels and pitch in bytes, the formula is:
+ * offset = width * bpp / 128 = pitch / 16
*/
static u32 mgag200_calculate_offset(struct mga_device *mdev,
const struct drm_framebuffer *fb)
{
- u32 offset = fb->pitches[0] / fb->format->cpp[0];
- u8 bppshift = mgag200_get_bpp_shift(fb->format);
-
- if (fb->format->cpp[0] * 8 == 24)
- offset = (offset * 3) >> (4 - bppshift);
- else
- offset = offset >> (4 - bppshift);
-
- return offset;
+ return fb->pitches[0] >> 4;
}
static void mgag200_set_offset(struct mga_device *mdev,
@@ -326,48 +312,25 @@ static void mgag200_set_offset(struct mga_device *mdev,
void mgag200_set_format_regs(struct mga_device *mdev, const struct
drm_format_info *format)
{
struct drm_device *dev = >base;
- unsigned int bpp, bppshift, scale;
+ unsigned int scale;
u8 crtcext3, xmulctrl;
- bpp = format->cpp[0] * 8;
-
- bppshift = mgag200_get_bpp_shift(format);
- switch (bpp) {
- case 24:
- scale = ((1 << bppshift) * 3) - 1;
- break;
- default:
- scale = (1 << bppshift) - 1;
- break;
- }
-
- RREG_ECRT(3, crtcext3);
-
- switch (bpp) {
- case 8:
- xmulctrl = MGA1064_MUL_CTL_8bits;
- break;
- case 16:
- if (format->depth == 15)
- xmulctrl = MGA1064_MUL_CTL_15bits;
- else
- xmulctrl = MGA1064_MUL_CTL_16bits;
+ switch (format->format) {
+ case DRM_FORMAT_RGB565:
+ xmulctrl = MGA1064_MUL_CTL_16bits;
break;
- case 24:
+ case DRM_FORMAT_RGB888:
xmulctrl = MGA1064_MUL_CTL_24bits;
break;
- case 32:
+ case DRM_FORMAT_XRGB:
xmulctrl = MGA1064_MUL_CTL_32_24bits;
break;
default:
/* BUG: We should have caught this problem already. */
- drm_WARN_ON(dev, "invalid format depth\n");
+ drm_WARN_ON(dev, "invalid drm format\n");
return;
}
- crtcext3 &= ~GENMASK(2, 0);
- crtcext3 |= scale;
-
WREG_DAC(MGA1064_MUL_CTL, xmulctrl);
WREG_GFX(0, 0x00);
@@ -383,6 +346,12 @@ void mgag200_set_format_regs(struct mga_device *mdev,
const struct drm_format_in
WREG_GFX(7, 0x0f);
WREG_GFX(8, 0x0f);
+ /* scale is the number of bytes per pixels - 1 */
+ scale = format->cpp[0] - 1;
+
+ RREG_ECRT(3, crtcext3);
+ crtcext3 &= ~GENMASK(2, 0);
+ crtcext3 |= scale;
WREG_ECRT(3, crtcext3);
}
--
2.39.2
Re: [PATCH v2 03/13] dt-bindings: display/msm: Add SM6350 DPU
On 25.04.2023 19:03, Rob Herring wrote: > On Fri, Apr 21, 2023 at 12:31:12AM +0200, Konrad Dybcio wrote: >> Document the SM6350 DPU. >> >> Signed-off-by: Konrad Dybcio >> --- >> .../bindings/display/msm/qcom,sm6350-dpu.yaml | 94 >> ++ >> 1 file changed, 94 insertions(+) >> >> diff --git >> a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-dpu.yaml >> b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-dpu.yaml >> new file mode 100644 >> index ..979fcf81afc9 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-dpu.yaml >> @@ -0,0 +1,94 @@ >> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/display/msm/qcom,sm6350-dpu.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Qualcomm Display DPU dt properties for SM6350 target >> + >> +maintainers: >> + - Konrad Dybcio >> + >> +$ref: /schemas/display/msm/dpu-common.yaml# >> + >> +properties: >> + compatible: >> +items: >> + - const: qcom,sm6350-dpu >> + >> + reg: >> +items: >> + - description: Address offset and size for mdp register set >> + - description: Address offset and size for vbif register set >> + >> + reg-names: >> +items: >> + - const: mdp >> + - const: vbif >> + >> + clocks: >> +items: >> + - description: Display axi clock >> + - description: Display ahb clock >> + - description: Display rot clock >> + - description: Display lut clock >> + - description: Display core clock >> + - description: Display vsync clock >> + >> + clock-names: >> +items: >> + - const: bus >> + - const: iface >> + - const: rot >> + - const: lut >> + - const: core >> + - const: vsync > > Is there some reason the clocks are in different order? Nope, I'll sort this out They appear to > be the same minus the 'throttle' clock. Is there really no 'throttle' > clock? Looks like GCC_DISP_THROTTLE_AXI_CLK does exist on sm6350 as well, no idea how/if it's used though.. Perhaps I can just remove it from sm6375 and if it turns out necessary we can reintroduce it another day. Maybe this platform just tied it to one of the same clocks in the > above? Unlikely, most likely it's for some dire deep power saving stuff that does not seem to be used/exposed, even on the bsp kernel > > I really hate the mess that is clocks. We have the same or related > blocks with just totally different names and order. The result is > if/then schemas or separate schemas like this. Neither option is great, > but at least the if/then schemas provides some motivation to not have > pointless variations like this. It's a totally valid rant.. > > As it seems the only difference between these 2 bindings is 1 extra > clock, can't they be shared? Sounds like a plan! Konrad > > Rob
Re: [PATCH v2 08/13] drm/panel: sitronix-st7789v: avoid hardcoding mode info
Hi Sebastian,
Thanks for the v2 of your series. Looks great!
One nitpick though: you seem to wrap the patch message lines at ~50
characters sometimes, which is awfully short.
Another comment below:
On 4/22/23 22:50, Sebastian Reichel wrote:
> Avoid hard-coding the default_mode and supply it from match data. One
> additional layer of abstraction has been introduced, which will be
> needed for specifying other panel information (e.g. bus flags) in the
> next steps.
>
> Signed-off-by: Sebastian Reichel
> ---
> .../gpu/drm/panel/panel-sitronix-st7789v.c| 24 ++-
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
> index a6d6155ef45c..29c2a91f8299 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
> @@ -108,8 +108,13 @@
> return val; \
> } while (0)
>
> +struct st7789_panel_info {
> + const struct drm_display_mode *mode;
> +};
> +
> struct st7789v {
> struct drm_panel panel;
> + const struct st7789_panel_info *info;
> struct spi_device *spi;
> struct gpio_desc *reset;
> struct regulator *power;
> @@ -160,16 +165,21 @@ static const struct drm_display_mode default_mode = {
> .vtotal = 320 + 8 + 4 + 4,
> };
>
> +struct st7789_panel_info default_panel = {
> + .mode = _mode,
> +};
Shouldn't this be "static const struct st7789_panel_info default_panel"?
(Same holds for "struct st7789_panel_info t28cp45tn89_panel" in patch
13/13.)
With the comments above addressed, feel free to add my
Reviewed-by: Michael Riesch
to the whole v3 of your series.
Thanks and best regards,
Michael
> +
> static int st7789v_get_modes(struct drm_panel *panel,
>struct drm_connector *connector)
> {
> + struct st7789v *ctx = panel_to_st7789v(panel);
> struct drm_display_mode *mode;
>
> - mode = drm_mode_duplicate(connector->dev, _mode);
> + mode = drm_mode_duplicate(connector->dev, ctx->info->mode);
> if (!mode) {
> - dev_err(panel->dev, "failed to add mode %ux%ux@%u\n",
> - default_mode.hdisplay, default_mode.vdisplay,
> - drm_mode_vrefresh(_mode));
> + dev_err(panel->dev, "failed to add mode %ux%u@%u\n",
> + ctx->info->mode->hdisplay, ctx->info->mode->vdisplay,
> + drm_mode_vrefresh(ctx->info->mode));
> return -ENOMEM;
> }
>
> @@ -359,6 +369,8 @@ static int st7789v_probe(struct spi_device *spi)
> spi_set_drvdata(spi, ctx);
> ctx->spi = spi;
>
> + ctx->info = device_get_match_data(>dev);
> +
> drm_panel_init(>panel, dev, _drm_funcs,
> DRM_MODE_CONNECTOR_DPI);
>
> @@ -389,13 +401,13 @@ static void st7789v_remove(struct spi_device *spi)
> }
>
> static const struct spi_device_id st7789v_spi_id[] = {
> - { "st7789v" },
> + { "st7789v", (unsigned long) _panel },
> { }
> };
> MODULE_DEVICE_TABLE(spi, st7789v_spi_id);
>
> static const struct of_device_id st7789v_of_match[] = {
> - { .compatible = "sitronix,st7789v" },
> + { .compatible = "sitronix,st7789v", .data = _panel },
> { }
> };
> MODULE_DEVICE_TABLE(of, st7789v_of_match);
Re: [PATCH v2 07/13] drm/msm/dpu: Add SM6350 support
On 27/04/2023 18:37, Marijn Suijten wrote:
On 2023-04-21 00:31:16, Konrad Dybcio wrote:
Add SM6350 support to the DPU1 driver to enable display output.
Signed-off-by: Konrad Dybcio
Signed-off-by: Konrad Dybcio
After addressing the comments from Dmitry (CURSOR0->DMA1 and
CURSOR1->DMA2), this is:
Reviewed-by: Marijn Suijten
See below for some nits.
[...]
+static const struct dpu_mdp_cfg sm6350_mdp[] = {
+ {
+ .name = "top_0", .id = MDP_TOP,
+ .base = 0x0, .len = 0x494,
+ .features = 0,
+ .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
+ .clk_ctrls[DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
+ .clk_ctrls[DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8 },
+ .clk_ctrls[DPU_CLK_CTRL_DMA2] = { .reg_off = 0x2c4, .bit_off = 8 },
+ .clk_ctrls[DPU_CLK_CTRL_REG_DMA] = { .reg_off = 0x2bc, .bit_off = 20 },
+ },
+};
+
+static const struct dpu_ctl_cfg sm6350_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x1000, .len = 0x1dc,
+ .features = BIT(DPU_CTL_ACTIVE_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+ },
+ {
+ .name = "ctl_1", .id = CTL_1,
+ .base = 0x1200, .len = 0x1dc,
+ .features = BIT(DPU_CTL_ACTIVE_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
+ },
+ {
+ .name = "ctl_2", .id = CTL_2,
+ .base = 0x1400, .len = 0x1dc,
+ .features = BIT(DPU_CTL_ACTIVE_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
+ },
+ {
+ .name = "ctl_3", .id = CTL_3,
+ .base = 0x1600, .len = 0x1dc,
+ .features = BIT(DPU_CTL_ACTIVE_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
+ },
+};
+
+static const struct dpu_sspp_cfg sm6350_sspp[] = {
+ SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, 0x1f8, VIG_SC7180_MASK,
+sc7180_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
+ SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, 0x1f8, DMA_SDM845_MASK,
+sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
+ SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, 0x1f8, DMA_CURSOR_SDM845_MASK,
+sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR0),
+ SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, 0x1f8, DMA_CURSOR_SDM845_MASK,
+sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1),
+};
+
+static const struct dpu_lm_cfg sm6350_lm[] = {
+ LM_BLK("lm_0", LM_0, 0x44000, MIXER_SDM845_MASK,
+ _lm_sblk, PINGPONG_0, LM_1, DSPP_0),
+ LM_BLK("lm_1", LM_1, 0x45000, MIXER_SDM845_MASK,
+ _lm_sblk, PINGPONG_1, LM_0, 0),
These two entries are indented with two tabs and have one character too
many to align with the opening parenthesis on the previous line. Can we
please settle on a single style, as this commit mostly uses tabs+spaces
to align with the opening parenthesis?
Dmitry vouched for `cino=(0` (when in unclosed parenthesis, align next
line with zero extra characters to the opening parenthesis), but I find
double tabs more convenient as it doesn't require reindenting when
changing the name of the macro (which happened too often in my INTF TE
series).
I mainly vote for 'cino=(0' for indenting conditions (where double tab
is confusing) and for function calls. I do not have a strong opinion
about macros expansions. We have been using double-tab there, which is
fine with me.
Another option (which I personally find more appealing, but it doesn't
play well with the current guidelines) is to have all macro arguments in
a single line. It makes it easier to compare things.
And another option would be to expand these macros up to some point.
Previous experience with clock and interconnect drivers showed that
expanding such multi-arg acros makes it _easier_ to handle the data.
Counterintuitive, but true.
+};
+
+static const struct dpu_dspp_cfg sm6350_dspp[] = {
+ DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_SC7180_MASK,
+_dspp_sblk),
+};
+
+static struct dpu_pingpong_cfg sm6350_pp[] = {
+ PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SM8150_MASK, 0,
sdm845_pp_sblk,
+ DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
+ -1),
+ PP_BLK("pingpong_1", PINGPONG_1, 0x70800, PINGPONG_SM8150_MASK, 0,
sdm845_pp_sblk,
+ DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
+ -1),
[skipped the rest]
--
With best wishes
Dmitry
Re: [RFC] Plane color pipeline KMS uAPI
On Thu, 04 May 2023 15:22:59 +
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.
Hi Simon,
this is an excellent write-up, thank you!
Harry's question about what constitutes UAPI is a good one for danvet.
I don't really have much to add here, a couple inline comments. I think
this could work.
>
> 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
