Re: [PATCH 4/5] clk: sunxi-ng: a64: Add constraints on PLL-VIDEO0's n/m ratio
On 2023-12-20 at 16:12:42 +0100, Jernej Škrabec wrote: > Dne sreda, 20. december 2023 ob 08:09:28 CET je Frank Oltmanns napisal(a): >> >> On 2023-12-19 at 17:54:19 +0100, Jernej Škrabec >> wrote: >> > Dne ponedeljek, 18. december 2023 ob 14:35:22 CET je Frank Oltmanns >> > napisal(a): >> >> The Allwinner A64 manual lists the following constraint for the >> >> PLL-VIDEO0 clock: 8 <= N/M <= 25 >> >> >> >> Use this constraint. >> >> >> >> Signed-off-by: Frank Oltmanns >> >> --- >> >> drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 8 ++-- >> >> 1 file changed, 6 insertions(+), 2 deletions(-) >> >> >> >> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c >> >> b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c >> >> index c034ac027d1c..75d839da446c 100644 >> >> --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c >> >> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c >> >> @@ -68,7 +68,8 @@ static >> >> SUNXI_CCU_NM_WITH_SDM_GATE_LOCK(pll_audio_base_clk, "pll-audio-base", >> >> BIT(28), /* lock */ >> >> CLK_SET_RATE_UNGATE); >> >> >> >> -static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, >> >> "pll-video0", >> >> +static >> >> SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO(pll_video0_clk, >> >> + "pll-video0", >> >> "osc24M", 0x010, >> >> 19200, /* Minimum rate >> >> */ >> >> 100800, /* Maximum rate >> >> */ >> >> @@ -80,7 +81,10 @@ static >> >> SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, "pll-vid >> >> 29700, /* frac rate 1 >> >> */ >> >> BIT(31),/* gate */ >> >> BIT(28),/* lock */ >> >> - CLK_SET_RATE_UNGATE); >> >> + CLK_SET_RATE_UNGATE, >> >> + CCU_FEATURE_FRACTIONAL | >> >> + CCU_FEATURE_CLOSEST_RATE, >> > >> > Above flags are unrelated change, put them in new patch if needed. >> >> You might notice that I am using a new macro for initializing the >> pll_video0_clk struct: >> New: SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO >> Old: SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST >> >> Setting the two CCU_FEATURE flags is part of the old initialization >> macro. >> >> I'll add SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_NM_RATIO_CLOSEST which >> hopefully resolves the confusion. > > I'm in doubt if we need so many macros. How many users of these macro we'll > have? > I see that R40 SoC would also need same ratio limits, but other that that, > none? Ok, IIUC no additional macro and we keep this part of the patch as is. Best regards, Frank > > Best regards, > Jernej > >> >> Thanks, >> Frank >> >> > >> > Best regards, >> > Jernej >> > >> >> + 8, 25); /* min/max nm >> >> ratio */ >> >> >> >> static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve", >> >> "osc24M", 0x018, >> >> >> >> >>
Re: [PATCH] drm/amd/display: avoid stringop-overflow warnings for dp_decide_lane_settings()
On 11/22/23 14:13, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> gcc prints a warning about a possible array overflow for a couple of
> callers of dp_decide_lane_settings() after commit 1b56c90018f0 ("Makefile:
> Enable -Wstringop-overflow globally"):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c:
> In function 'dp_perform_fixed_vs_pe_training_sequence_legacy':
> drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c:426:25:
> error: 'dp_decide_lane_settings' accessing 4 bytes in a region of size 1
> [-Werror=stringop-overflow=]
> 426 | dp_decide_lane_settings(lt_settings,
> dpcd_lane_adjust,
> |
> ^~
> 427 |
> lt_settings->hw_lane_settings, lt_settings->dpcd_lane_settings);
> |
> ~~~
> drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c:426:25:
> note: referencing argument 4 of type 'union dpcd_training_lane[4]'
>
> I'm not entirely sure what caused this, but changing the prototype to expect
> a pointer instead of an array avoids the warnings.
>
> Fixes: 7727e7b60f82 ("drm/amd/display: Improve robustness of FIXED_VS link
> training at DP1 rates")
> Signed-off-by: Arnd Bergmann
Acked-by: Randy Dunlap
Tested-by: Randy Dunlap # build-tested
Thanks.
> ---
> .../gpu/drm/amd/display/dc/link/protocols/link_dp_training.c| 2 +-
> .../gpu/drm/amd/display/dc/link/protocols/link_dp_training.h| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c
> b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c
> index 90339c2dfd84..5a0b04518956 100644
> --- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c
> +++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c
> @@ -807,7 +807,7 @@ void dp_decide_lane_settings(
> const struct link_training_settings *lt_settings,
> const union lane_adjust ln_adjust[LANE_COUNT_DP_MAX],
> struct dc_lane_settings hw_lane_settings[LANE_COUNT_DP_MAX],
> - union dpcd_training_lane dpcd_lane_settings[LANE_COUNT_DP_MAX])
> + union dpcd_training_lane *dpcd_lane_settings)
> {
> uint32_t lane;
>
> diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.h
> b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.h
> index 7d027bac8255..851bd17317a0 100644
> --- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.h
> +++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.h
> @@ -111,7 +111,7 @@ void dp_decide_lane_settings(
> const struct link_training_settings *lt_settings,
> const union lane_adjust ln_adjust[LANE_COUNT_DP_MAX],
> struct dc_lane_settings hw_lane_settings[LANE_COUNT_DP_MAX],
> - union dpcd_training_lane dpcd_lane_settings[LANE_COUNT_DP_MAX]);
> + union dpcd_training_lane *dpcd_lane_settings);
>
> enum dc_dp_training_pattern decide_cr_training_pattern(
> const struct dc_link_settings *link_settings);
--
#Randy
https://people.kernel.org/tglx/notes-about-netiquette
https://subspace.kernel.org/etiquette.html
[git pull] drm fixes for 6.7-rc7
Hi Linus, Pretty quiet for this week, just i915 and amdgpu fixes, I think the misc tree got lost this week, but didn't seem to have too much in it, so it can wait. I've also got a bunch of nouveau GSP fixes sailing around that'll probably land next time as well. Dave. drm-fixes-2023-12-22: drm fixes for 6.7-rc7 amdgpu: - DCN 3.5 fixes - DCN 3.2 SubVP fix - GPUVM fix amdkfd: - SVM fix for APUs i915: - Fix state readout and check for DSC and bigjoiner combo - Fix a potential integer overflow - Reject async flips with bigjoiner - Fix MTL HDMI/DP PLL clock selection - Fix various issues by disabling pipe DMC events The following changes since commit ceb6a6f023fd3e8b07761ed900352ef574010bcb: Linux 6.7-rc6 (2023-12-17 15:19:28 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-12-22 for you to fetch changes up to d4b6e7f582e29acac17bcaf7f7771138d72f89d2: Merge tag 'drm-intel-fixes-2023-12-21' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2023-12-22 13:11:09 +1000) drm fixes for 6.7-rc7 amdgpu: - DCN 3.5 fixes - DCN 3.2 SubVP fix - GPUVM fix amdkfd: - SVM fix for APUs i915: - Fix state readout and check for DSC and bigjoiner combo - Fix a potential integer overflow - Reject async flips with bigjoiner - Fix MTL HDMI/DP PLL clock selection - Fix various issues by disabling pipe DMC events Alvin Lee (1): drm/amd/display: Revert " drm/amd/display: Use channel_width = 2 for vram table 3.0" Ankit Nautiyal (1): drm/i915/display: Get bigjoiner config before dsc config during readout Charlene Liu (1): drm/amd/display: get dprefclk ss info from integration info table Dave Airlie (2): Merge tag 'amd-drm-fixes-6.7-2023-12-20' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2023-12-21' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Hamza Mahfooz (1): drm/amd/display: disable FPO and SubVP for older DMUB versions on DCN32x Imre Deak (1): drm/i915/mtl: Fix HDMI/DP PLL clock selection Josip Pavic (1): drm/amd/display: dereference variable before checking for zero Karthik Poosa (1): drm/i915/hwmon: Fix static analysis tool reported issues Philip Yang (1): drm/amdkfd: svm range always mapped flag not working on APU Ville Syrjälä (2): drm/i915: Reject async flips with bigjoiner drm/i915/dmc: Don't enable any pipe DMC events Wayne Lin (1): drm/amd/display: Add case for dcn35 to support usb4 dmub hpd event ZhenGuo Yin (1): drm/amdgpu: re-create idle bo's PTE during VM state machine reset drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 1 + drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 18 ++--- drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 27 -- drivers/gpu/drm/amd/display/dc/core/dc.c | 26 + .../drm/amd/display/dc/dml2/display_mode_core.c| 2 +- .../drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c| 6 +++ .../amd/display/include/grph_object_ctrl_defs.h| 2 + drivers/gpu/drm/i915/display/intel_cx0_phy.c | 3 +- drivers/gpu/drm/i915/display/intel_display.c | 13 ++- drivers/gpu/drm/i915/display/intel_dmc.c | 43 +- drivers/gpu/drm/i915/i915_hwmon.c | 4 +- 11 files changed, 112 insertions(+), 33 deletions(-)
[PATCH 09/11] nouveau/gsp: always free the alloc messages on r535
Fixes a memory leak seen with kmemleak. Signed-off-by: Dave Airlie --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c index e2810fd1a36f..cafb82826473 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c @@ -605,8 +605,7 @@ r535_gsp_rpc_rm_alloc_push(struct nvkm_gsp_object *object, void *argv, u32 repc) ret = repc ? rpc->params : NULL; } - if (ret) - nvkm_gsp_rpc_done(gsp, rpc); + nvkm_gsp_rpc_done(gsp, rpc); return ret; } -- 2.43.0
[PATCH 08/11] nouveau/gsp: don't free ctrl messages on errors
It looks like for some messages the upper layers need to get access to the
results of the message so we can interpret it.
Rework the ctrl push interface to not free things and cleanup properly
whereever it errors out.
Requested-by: Lyude
Signed-off-by: Dave Airlie
---
.../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 17 +--
.../gpu/drm/nouveau/nvkm/engine/disp/r535.c | 108 +++---
.../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 36 +++---
3 files changed, 100 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
index 2fa0445d8928..d1437c08645f 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
@@ -187,7 +187,7 @@ struct nvkm_gsp {
void (*rpc_done)(struct nvkm_gsp *gsp, void *repv);
void *(*rm_ctrl_get)(struct nvkm_gsp_object *, u32 cmd, u32
argc);
- void *(*rm_ctrl_push)(struct nvkm_gsp_object *, void *argv, u32
repc);
+ int (*rm_ctrl_push)(struct nvkm_gsp_object *, void **argv, u32
repc);
void (*rm_ctrl_done)(struct nvkm_gsp_object *, void *repv);
void *(*rm_alloc_get)(struct nvkm_gsp_object *, u32 oclass, u32
argc);
@@ -265,7 +265,7 @@ nvkm_gsp_rm_ctrl_get(struct nvkm_gsp_object *object, u32
cmd, u32 argc)
return object->client->gsp->rm->rm_ctrl_get(object, cmd, argc);
}
-static inline void *
+static inline int
nvkm_gsp_rm_ctrl_push(struct nvkm_gsp_object *object, void *argv, u32 repc)
{
return object->client->gsp->rm->rm_ctrl_push(object, argv, repc);
@@ -275,21 +275,24 @@ static inline void *
nvkm_gsp_rm_ctrl_rd(struct nvkm_gsp_object *object, u32 cmd, u32 repc)
{
void *argv = nvkm_gsp_rm_ctrl_get(object, cmd, repc);
+ int ret;
if (IS_ERR(argv))
return argv;
- return nvkm_gsp_rm_ctrl_push(object, argv, repc);
+ ret = nvkm_gsp_rm_ctrl_push(object, , repc);
+ if (ret)
+ return ERR_PTR(ret);
+ return argv;
}
static inline int
nvkm_gsp_rm_ctrl_wr(struct nvkm_gsp_object *object, void *argv)
{
- void *repv = nvkm_gsp_rm_ctrl_push(object, argv, 0);
-
- if (IS_ERR(repv))
- return PTR_ERR(repv);
+ int ret = nvkm_gsp_rm_ctrl_push(object, , 0);
+ if (ret)
+ return ret;
return 0;
}
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
index 1c8c4cca0957..1b4f988df7ed 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
@@ -282,7 +282,7 @@ r535_sor_bl_get(struct nvkm_ior *sor)
{
struct nvkm_disp *disp = sor->disp;
NV0073_CTRL_SPECIFIC_BACKLIGHT_BRIGHTNESS_PARAMS *ctrl;
- int lvl;
+ int ret, lvl;
ctrl = nvkm_gsp_rm_ctrl_get(>rm.objcom,
NV0073_CTRL_CMD_SPECIFIC_GET_BACKLIGHT_BRIGHTNESS,
@@ -292,9 +292,11 @@ r535_sor_bl_get(struct nvkm_ior *sor)
ctrl->displayId = BIT(sor->asy.outp->index);
- ctrl = nvkm_gsp_rm_ctrl_push(>rm.objcom, ctrl, sizeof(*ctrl));
- if (IS_ERR(ctrl))
- return PTR_ERR(ctrl);
+ ret = nvkm_gsp_rm_ctrl_push(>rm.objcom, , sizeof(*ctrl));
+ if (ret) {
+ nvkm_gsp_rm_ctrl_done(>rm.objcom, ctrl);
+ return ret;
+ }
lvl = ctrl->brightness;
nvkm_gsp_rm_ctrl_done(>rm.objcom, ctrl);
@@ -649,9 +651,11 @@ r535_conn_new(struct nvkm_disp *disp, u32 id)
ctrl->subDeviceInstance = 0;
ctrl->displayId = BIT(id);
- ctrl = nvkm_gsp_rm_ctrl_push(>rm.objcom, ctrl, sizeof(*ctrl));
- if (IS_ERR(ctrl))
- return (void *)ctrl;
+ ret = nvkm_gsp_rm_ctrl_push(>rm.objcom, , sizeof(*ctrl));
+ if (ret) {
+ nvkm_gsp_rm_ctrl_done(>rm.objcom, ctrl);
+ return ERR_PTR(ret);
+ }
list_for_each_entry(conn, >conns, head) {
if (conn->index == ctrl->data[0].index) {
@@ -686,7 +690,7 @@ r535_outp_acquire(struct nvkm_outp *outp, bool hda)
struct nvkm_disp *disp = outp->disp;
struct nvkm_ior *ior;
NV0073_CTRL_DFP_ASSIGN_SOR_PARAMS *ctrl;
- int or;
+ int ret, or;
ctrl = nvkm_gsp_rm_ctrl_get(>rm.objcom,
NV0073_CTRL_CMD_DFP_ASSIGN_SOR,
sizeof(*ctrl));
@@ -699,9 +703,11 @@ r535_outp_acquire(struct nvkm_outp *outp, bool hda)
if (hda)
ctrl->flags |= NVDEF(NV0073_CTRL, DFP_ASSIGN_SOR_FLAGS, AUDIO,
OPTIMAL);
- ctrl = nvkm_gsp_rm_ctrl_push(>rm.objcom, ctrl, sizeof(*ctrl));
- if (IS_ERR(ctrl))
- return PTR_ERR(ctrl);
+ ret = nvkm_gsp_rm_ctrl_push(>rm.objcom, , sizeof(*ctrl));
+ if (ret) {
+ nvkm_gsp_rm_ctrl_done(>rm.objcom, ctrl);
+
[PATCH 11/11] drm/nouveau/dp: Honor GSP link training retry timeouts
From: Lyude Paul
Turns out that one of the ways that Nvidia's driver handles the pre-LT
timeout for eDP panels is by providing a retry timeout in their link
training callbacks that we're expected to wait for. Up until now we didn't
pay any attention to this parameter.
So, start honoring the timeout if link training fails - and retry up to 3
times. The "3 times" bit comes from OpenRM's link training code.
[airlied: this fixes the panel on one of my laptops]
Signed-off-by: Lyude Paul
Signed-off-by: Dave Airlie
---
.../gpu/drm/nouveau/nvkm/engine/disp/r535.c | 62 ---
1 file changed, 40 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
index 1b4f988df7ed..b287ab19a51f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
@@ -957,40 +957,58 @@ r535_dp_train_target(struct nvkm_outp *outp, u8 target,
bool mst, u8 link_nr, u8
{
struct nvkm_disp *disp = outp->disp;
NV0073_CTRL_DP_CTRL_PARAMS *ctrl;
- int ret;
-
- ctrl = nvkm_gsp_rm_ctrl_get(>rm.objcom, NV0073_CTRL_CMD_DP_CTRL,
sizeof(*ctrl));
- if (IS_ERR(ctrl))
- return PTR_ERR(ctrl);
+ int ret, retries;
+ u32 cmd, data;
- ctrl->subDeviceInstance = 0;
- ctrl->displayId = BIT(outp->index);
- ctrl->cmd = NVDEF(NV0073_CTRL, DP_CMD, SET_LANE_COUNT, TRUE) |
- NVDEF(NV0073_CTRL, DP_CMD, SET_LINK_BW, TRUE) |
- NVDEF(NV0073_CTRL, DP_CMD, TRAIN_PHY_REPEATER, YES);
- ctrl->data = NVVAL(NV0073_CTRL, DP_DATA, SET_LANE_COUNT, link_nr) |
-NVVAL(NV0073_CTRL, DP_DATA, SET_LINK_BW, link_bw) |
-NVVAL(NV0073_CTRL, DP_DATA, TARGET, target);
+ cmd = NVDEF(NV0073_CTRL, DP_CMD, SET_LANE_COUNT, TRUE) |
+ NVDEF(NV0073_CTRL, DP_CMD, SET_LINK_BW, TRUE) |
+ NVDEF(NV0073_CTRL, DP_CMD, TRAIN_PHY_REPEATER, YES);
+ data = NVVAL(NV0073_CTRL, DP_DATA, SET_LANE_COUNT, link_nr) |
+ NVVAL(NV0073_CTRL, DP_DATA, SET_LINK_BW, link_bw) |
+ NVVAL(NV0073_CTRL, DP_DATA, TARGET, target);
if (mst)
- ctrl->cmd |= NVDEF(NV0073_CTRL, DP_CMD, SET_FORMAT_MODE,
MULTI_STREAM);
+ cmd |= NVDEF(NV0073_CTRL, DP_CMD, SET_FORMAT_MODE,
MULTI_STREAM);
if (outp->dp.dpcd[DPCD_RC02] & DPCD_RC02_ENHANCED_FRAME_CAP)
- ctrl->cmd |= NVDEF(NV0073_CTRL, DP_CMD, SET_ENHANCED_FRAMING,
TRUE);
+ cmd |= NVDEF(NV0073_CTRL, DP_CMD, SET_ENHANCED_FRAMING, TRUE);
if (target == 0 &&
(outp->dp.dpcd[DPCD_RC02] & 0x20) &&
!(outp->dp.dpcd[DPCD_RC03] & DPCD_RC03_TPS4_SUPPORTED))
- ctrl->cmd |= NVDEF(NV0073_CTRL, DP_CMD, POST_LT_ADJ_REQ_GRANTED,
YES);
+ cmd |= NVDEF(NV0073_CTRL, DP_CMD, POST_LT_ADJ_REQ_GRANTED, YES);
- ret = nvkm_gsp_rm_ctrl_push(>rm.objcom, , sizeof(*ctrl));
- if (ret) {
- nvkm_gsp_rm_ctrl_done(>rm.objcom, ctrl);
- return ret;
+ /* We should retry up to 3 times, but only if GSP asks politely */
+ for (retries = 0; retries < 3; ++retries) {
+ ctrl = nvkm_gsp_rm_ctrl_get(>rm.objcom,
NV0073_CTRL_CMD_DP_CTRL,
+ sizeof(*ctrl));
+ if (IS_ERR(ctrl))
+ return PTR_ERR(ctrl);
+
+ ctrl->subDeviceInstance = 0;
+ ctrl->displayId = BIT(outp->index);
+ ctrl->retryTimeMs = 0;
+ ctrl->cmd = cmd;
+ ctrl->data = data;
+
+ ret = nvkm_gsp_rm_ctrl_push(>rm.objcom, ,
sizeof(*ctrl));
+ if (ret == -EAGAIN && ctrl->retryTimeMs) {
+ /* Device (likely an eDP panel) isn't ready yet, wait
for the time specified
+* by GSP before retrying again */
+ nvkm_debug(>engine.subdev,
+ "Waiting %dms for GSP LT panel delay before
retrying\n",
+ ctrl->retryTimeMs);
+ msleep(ctrl->retryTimeMs);
+ nvkm_gsp_rm_ctrl_done(>rm.objcom, ctrl);
+ } else {
+ /* GSP didn't say to retry, or we were successful */
+ if (ctrl->err)
+ ret = -EIO;
+ nvkm_gsp_rm_ctrl_done(>rm.objcom, ctrl);
+ break;
+ }
}
- ret = ctrl->err ? -EIO : 0;
- nvkm_gsp_rm_ctrl_done(>rm.objcom, ctrl);
return ret;
}
--
2.43.0
[PATCH 07/11] nouveau/gsp: convert gsp errors to generic errors
This should let the upper layers retry as needed on EAGAIN.
There may be other values we will care about in the future, but
this covers our present needs.
Signed-off-by: Dave Airlie
---
.../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 26 +++
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index 774ca47b019f..54c1fbccc013 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -70,6 +70,20 @@ struct r535_gsp_msg {
#define GSP_MSG_HDR_SIZE offsetof(struct r535_gsp_msg, data)
+static int
+r535_rpc_status_to_errno(uint32_t rpc_status)
+{
+ switch (rpc_status) {
+ case 0x55: /* NV_ERR_NOT_READY */
+ case 0x66: /* NV_ERR_TIMEOUT_RETRY */
+ return -EAGAIN;
+ case 0x51: /* NV_ERR_NO_MEMORY */
+ return -ENOMEM;
+ default:
+ return -EINVAL;
+ }
+}
+
static void *
r535_gsp_msgq_wait(struct nvkm_gsp *gsp, u32 repc, u32 *prepc, int *ptime)
{
@@ -584,8 +598,9 @@ r535_gsp_rpc_rm_alloc_push(struct nvkm_gsp_object *object,
void *argv, u32 repc)
return rpc;
if (rpc->status) {
- nvkm_error(>subdev, "RM_ALLOC: 0x%x\n", rpc->status);
- ret = ERR_PTR(-EINVAL);
+ ret = ERR_PTR(r535_rpc_status_to_errno(rpc->status));
+ if (ret != -EAGAIN)
+ nvkm_error(>subdev, "RM_ALLOC: 0x%x\n",
rpc->status);
} else {
ret = repc ? rpc->params : NULL;
}
@@ -639,9 +654,10 @@ r535_gsp_rpc_rm_ctrl_push(struct nvkm_gsp_object *object,
void *argv, u32 repc)
return rpc;
if (rpc->status) {
- nvkm_error(>subdev, "cli:0x%08x obj:0x%08x ctrl cmd:0x%08x
failed: 0x%08x\n",
- object->client->object.handle, object->handle,
rpc->cmd, rpc->status);
- ret = ERR_PTR(-EINVAL);
+ ret = ERR_PTR(r535_rpc_status_to_errno(rpc->status));
+ if (ret != -EAGAIN)
+ nvkm_error(>subdev, "cli:0x%08x obj:0x%08x ctrl
cmd:0x%08x failed: 0x%08x\n",
+ object->client->object.handle,
object->handle, rpc->cmd, rpc->status);
} else {
ret = repc ? rpc->params : NULL;
}
--
2.43.0
[PATCH 06/11] drm/nouveau/gsp: Fix ACPI MXDM/MXDS method invocations
From: Lyude Paul
Currently we get an error from ACPI because both of these arguments expect
a single argument, and we don't provide one. I'm not totally clear on what
that argument does, but we're able to find the missing value from
_acpiCacheMethodData() in src/kernel/platform/acpi_common.c in nvidia's
driver. So, let's add that - which doesn't get eDP displays to power on
quite yet, but gets rid of the argument warning at least.
Signed-off-by: Lyude Paul
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index 1a6d7c89660d..774ca47b019f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -1150,6 +1150,8 @@ static void
r535_gsp_acpi_mux_id(acpi_handle handle, u32 id, MUX_METHOD_DATA_ELEMENT *mode,
MUX_METHOD_DATA_ELEMENT *part)
{
+ union acpi_object mux_arg = { ACPI_TYPE_INTEGER };
+ struct acpi_object_list input = { 1, _arg };
acpi_handle iter = NULL, handle_mux = NULL;
acpi_status status;
unsigned long long value;
@@ -1172,14 +1174,18 @@ r535_gsp_acpi_mux_id(acpi_handle handle, u32 id,
MUX_METHOD_DATA_ELEMENT *mode,
if (!handle_mux)
return;
- status = acpi_evaluate_integer(handle_mux, "MXDM", NULL, );
+ /* I -think- 0 means "acquire" according to nvidia's driver source */
+ input.pointer->integer.type = ACPI_TYPE_INTEGER;
+ input.pointer->integer.value = 0;
+
+ status = acpi_evaluate_integer(handle_mux, "MXDM", , );
if (ACPI_SUCCESS(status)) {
mode->acpiId = id;
mode->mode = value;
mode->status = 0;
}
- status = acpi_evaluate_integer(handle_mux, "MXDS", NULL, );
+ status = acpi_evaluate_integer(handle_mux, "MXDS", , );
if (ACPI_SUCCESS(status)) {
part->acpiId = id;
part->mode = value;
--
2.43.0
[PATCH 10/11] nouveau: push event block/allowing out of the fence context
There is a deadlock between the irq and fctx locks,
the irq handling takes irq then fctx lock
the fence signalling takes fctx then irq lock
This splits the fence signalling path so the code that hits
the irq lock is done in a separate work queue.
This seems to fix crashes/hangs when using nouveau gsp with
i915 primary GPU.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 28 -
drivers/gpu/drm/nouveau/nouveau_fence.h | 5 -
2 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index ca762ea55413..5057d976fa57 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -62,7 +62,7 @@ nouveau_fence_signal(struct nouveau_fence *fence)
if (test_bit(DMA_FENCE_FLAG_USER_BITS, >base.flags)) {
struct nouveau_fence_chan *fctx = nouveau_fctx(fence);
- if (!--fctx->notify_ref)
+ if (atomic_dec_and_test(>notify_ref))
drop = 1;
}
@@ -103,6 +103,7 @@ nouveau_fence_context_kill(struct nouveau_fence_chan *fctx,
int error)
void
nouveau_fence_context_del(struct nouveau_fence_chan *fctx)
{
+ cancel_work_sync(>allow_block_work);
nouveau_fence_context_kill(fctx, 0);
nvif_event_dtor(>event);
fctx->dead = 1;
@@ -167,6 +168,18 @@ nouveau_fence_wait_uevent_handler(struct nvif_event
*event, void *repv, u32 repc
return ret;
}
+static void
+nouveau_fence_work_allow_block(struct work_struct *work)
+{
+ struct nouveau_fence_chan *fctx = container_of(work, struct
nouveau_fence_chan,
+ allow_block_work);
+
+ if (atomic_read(>notify_ref) == 0)
+ nvif_event_block(>event);
+ else
+ nvif_event_allow(>event);
+}
+
void
nouveau_fence_context_new(struct nouveau_channel *chan, struct
nouveau_fence_chan *fctx)
{
@@ -178,6 +191,7 @@ nouveau_fence_context_new(struct nouveau_channel *chan,
struct nouveau_fence_cha
} args;
int ret;
+ INIT_WORK(>allow_block_work, nouveau_fence_work_allow_block);
INIT_LIST_HEAD(>flip);
INIT_LIST_HEAD(>pending);
spin_lock_init(>lock);
@@ -521,15 +535,19 @@ static bool nouveau_fence_enable_signaling(struct
dma_fence *f)
struct nouveau_fence *fence = from_fence(f);
struct nouveau_fence_chan *fctx = nouveau_fctx(fence);
bool ret;
+ bool do_work;
- if (!fctx->notify_ref++)
- nvif_event_allow(>event);
+ if (atomic_inc_return(>notify_ref) == 0)
+ do_work = true;
ret = nouveau_fence_no_signaling(f);
if (ret)
set_bit(DMA_FENCE_FLAG_USER_BITS, >base.flags);
- else if (!--fctx->notify_ref)
- nvif_event_block(>event);
+ else if (atomic_dec_and_test(>notify_ref))
+ do_work = true;
+
+ if (do_work)
+ schedule_work(>allow_block_work);
return ret;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.h
b/drivers/gpu/drm/nouveau/nouveau_fence.h
index 64d33ae7f356..28f5cf013b89 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.h
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.h
@@ -3,6 +3,7 @@
#define __NOUVEAU_FENCE_H__
#include
+#include
#include
struct nouveau_drm;
@@ -45,7 +46,9 @@ struct nouveau_fence_chan {
char name[32];
struct nvif_event event;
- int notify_ref, dead, killed;
+ struct work_struct allow_block_work;
+ atomic_t notify_ref;
+ int dead, killed;
};
struct nouveau_fence_priv {
--
2.43.0
[PATCH 05/11] nouveau/gsp: free userd allocation.
This was being leaked. Signed-off-by: Dave Airlie --- drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c index d088e636edc3..b903785056b5 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c @@ -242,6 +242,7 @@ r535_chan_id_put(struct nvkm_chan *chan) nvkm_memory_unref(>mem); nvkm_chid_put(runl->chid, userd->chid, >cgrp->lock); list_del(>head); + kfree(userd); } break; -- 2.43.0
[PATCH 04/11] nouveau/gsp: free acpi object after use
This fixes a memory leak for the acpi dod object. Signed-off-by: Dave Airlie --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c index 365dda6c002a..1a6d7c89660d 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c @@ -1226,6 +1226,7 @@ r535_gsp_acpi_dod(acpi_handle handle, DOD_METHOD_DATA *dod) } dod->status = 0; + kfree(output.pointer); } #endif -- 2.43.0
[PATCH 03/11] nouveau: fix disp disabling with GSP
This func ptr here is normally static allocation, but gsp r535
uses a dynamic pointer, so we need to handle that better.
This fixes a crash with GSP when you use config=disp=0 to avoid
disp problems.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c
index 457ec5db794d..b24eb1e560bc 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c
@@ -209,7 +209,7 @@ nvkm_disp_dtor(struct nvkm_engine *engine)
nvkm_head_del();
}
- if (disp->func->dtor)
+ if (disp->func && disp->func->dtor)
disp->func->dtor(disp);
return data;
@@ -243,8 +243,10 @@ nvkm_disp_new_(const struct nvkm_disp_func *func, struct
nvkm_device *device,
spin_lock_init(>client.lock);
ret = nvkm_engine_ctor(_disp, device, type, inst, true,
>engine);
- if (ret)
+ if (ret) {
+ disp->func = NULL;
return ret;
+ }
if (func->super) {
disp->super.wq = create_singlethread_workqueue("nvkm-disp");
--
2.43.0
[PATCH 02/11] nouveau/gsp: drop some acpi related debug
These were leftover debug, if we need to bring them back do so
for debugging later.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c | 7 ---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 9 -
2 files changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
index 298035070b3a..1c8c4cca0957 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
@@ -1465,8 +1465,6 @@ r535_disp_oneinit(struct nvkm_disp *disp)
bool nvhg = acpi_check_dsm(handle,
_DSM_GUID, NVHG_DSM_REV,
1ULL << 0x0014);
- printk(KERN_ERR "bl: nbci:%d nvhg:%d\n", nbci,
nvhg);
-
if (nbci || nvhg) {
union acpi_object argv4 = {
.buffer.type=
ACPI_TYPE_BUFFER,
@@ -1479,9 +1477,6 @@ r535_disp_oneinit(struct nvkm_disp *disp)
if (!obj) {
acpi_handle_info(handle,
"failed to evaluate _DSM\n");
} else {
- printk(KERN_ERR "bl: obj type
%d\n", obj->type);
- printk(KERN_ERR "bl: obj len
%d\n", obj->package.count);
-
for (int i = 0; i <
obj->package.count; i++) {
union acpi_object *elt
= >package.elements[i];
u32 size;
@@ -1491,12 +1486,10 @@ r535_disp_oneinit(struct nvkm_disp *disp)
else
size = 4;
- printk(KERN_ERR "elt
%03d: type %d size %d\n", i, elt->type, size);
memcpy(>backLightData[ctrl->backLightDataSize], >integer.value,
size);
ctrl->backLightDataSize
+= size;
}
- printk(KERN_ERR "bl: data size
%d\n", ctrl->backLightDataSize);
ctrl->status = 0;
ACPI_FREE(obj);
}
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index 7f831f41b598..365dda6c002a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -1100,16 +1100,12 @@ r535_gsp_acpi_caps(acpi_handle handle, CAPS_METHOD_DATA
*caps)
if (!obj)
return;
- printk(KERN_ERR "nvop: obj type %d\n", obj->type);
- printk(KERN_ERR "nvop: obj len %d\n", obj->buffer.length);
-
if (WARN_ON(obj->type != ACPI_TYPE_BUFFER) ||
WARN_ON(obj->buffer.length != 4))
return;
caps->status = 0;
caps->optimusCaps = *(u32 *)obj->buffer.pointer;
- printk(KERN_ERR "nvop: caps %08x\n", caps->optimusCaps);
ACPI_FREE(obj);
@@ -1136,9 +1132,6 @@ r535_gsp_acpi_jt(acpi_handle handle, JT_METHOD_DATA *jt)
if (!obj)
return;
- printk(KERN_ERR "jt: obj type %d\n", obj->type);
- printk(KERN_ERR "jt: obj len %d\n", obj->buffer.length);
-
if (WARN_ON(obj->type != ACPI_TYPE_BUFFER) ||
WARN_ON(obj->buffer.length != 4))
return;
@@ -1147,7 +1140,6 @@ r535_gsp_acpi_jt(acpi_handle handle, JT_METHOD_DATA *jt)
jt->jtCaps = *(u32 *)obj->buffer.pointer;
jt->jtRevId = (jt->jtCaps & 0xfff0) >> 20;
jt->bSBIOSCaps = 0;
- printk(KERN_ERR "jt: caps %08x rev:%04x\n", jt->jtCaps, jt->jtRevId);
ACPI_FREE(obj);
@@ -1233,7 +1225,6 @@ r535_gsp_acpi_dod(acpi_handle handle, DOD_METHOD_DATA
*dod)
dod->acpiIdListLen += sizeof(dod->acpiIdList[0]);
}
- printk(KERN_ERR "_DOD: ok! len:%d\n", dod->acpiIdListLen);
dod->status = 0;
}
#endif
--
2.43.0
[PATCH 01/11] nouveau/gsp: add three notifier callbacks that we see in normal operation (v2)
Add NULL callbacks for some things GSP calls that we don't handle, but know
about
so we avoid the logging.
v2: Timur suggested allowing null fn.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index 44fb86841c05..7f831f41b598 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -298,7 +298,8 @@ r535_gsp_msg_recv(struct nvkm_gsp *gsp, int fn, u32 repc)
struct nvkm_gsp_msgq_ntfy *ntfy = >msgq.ntfy[i];
if (ntfy->fn == msg->function) {
- ntfy->func(ntfy->priv, ntfy->fn, msg->data, msg->length
- sizeof(*msg));
+ if (ntfy->func)
+ ntfy->func(ntfy->priv, ntfy->fn, msg->data,
msg->length - sizeof(*msg));
break;
}
}
@@ -2186,7 +2187,9 @@ r535_gsp_oneinit(struct nvkm_gsp *gsp)
r535_gsp_msg_ntfy_add(gsp, NV_VGPU_MSG_EVENT_MMU_FAULT_QUEUED,
r535_gsp_msg_mmu_fault_queued, gsp);
r535_gsp_msg_ntfy_add(gsp, NV_VGPU_MSG_EVENT_OS_ERROR_LOG,
r535_gsp_msg_os_error_log, gsp);
-
+ r535_gsp_msg_ntfy_add(gsp,
NV_VGPU_MSG_EVENT_PERF_BRIDGELESS_INFO_UPDATE, NULL, NULL);
+ r535_gsp_msg_ntfy_add(gsp, NV_VGPU_MSG_EVENT_UCODE_LIBOS_PRINT, NULL,
NULL);
+ r535_gsp_msg_ntfy_add(gsp, NV_VGPU_MSG_EVENT_GSP_SEND_USER_SHARED_DATA,
NULL, NULL);
ret = r535_gsp_rm_boot_ctor(gsp);
if (ret)
return ret;
--
2.43.0
nouveau GSP fixes
This is a collection of nouveau debug prints, memory leak, a very annoying race condition causing system hangs with prime scenarios, and a fix from Lyude to get the panel on my laptop working. I'd like to get these into 6.7, Dave.
[PATCH v2] drm/ci: uprev mesa version: fix kdl commit fetch
build-kdl.sh was doing a `clone --depth 1` of the default branch,
then checking out a commit that might not be the latest of that
branch, resulting in container build error.
https://gitlab.freedesktop.org/mesa/mesa/-/commit/5efa4d56 fixes
kdl commit fetch issue. Uprev mesa in drm-ci to fix this.
This commit updates the kernel tag and adds .never-post-merge-rules
due to the mesa uprev. It also fixes an issue where the virtio-gpu
pipeline was not getting created with the mesa uprev.
Reviewed-by: David Heidelberg
Acked-by: Helen Koike
Reviewed-by: Dmitry Baryshkov
Tested-by: Abhinav Kumar
Signed-off-by: Vignesh Raman
---
v2:
- Fix an issue where the virtio-gpu pipeline was not getting created with the
mesa uprev
https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1062221
---
drivers/gpu/drm/ci/gitlab-ci.yml | 14 --
drivers/gpu/drm/ci/test.yml | 1 +
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index dac92cc2777c..084e3ff8e3f4 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -1,6 +1,6 @@
variables:
DRM_CI_PROJECT_PATH: mesa/mesa
- DRM_CI_COMMIT_SHA:
edfbf74df1d4d6ce54ffe24566108be0e1a98c3d
+ DRM_CI_COMMIT_SHA:
9d162de9a05155e1c4041857a5848842749164cf
UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm
TARGET_BRANCH: drm-next
@@ -25,7 +25,9 @@ variables:
# per-job artifact storage on MinIO
JOB_ARTIFACTS_BASE: ${PIPELINE_ARTIFACTS_BASE}/${CI_JOB_ID}
# default kernel for rootfs before injecting the current kernel tree
- KERNEL_IMAGE_BASE:
https://${S3_HOST}/mesa-lava/gfx-ci/linux/v6.4.12-for-mesa-ci-f6b4ad45f48d
+ KERNEL_REPO: "gfx-ci/linux"
+ KERNEL_TAG: "v6.6.4-for-mesa-ci-e4f4c500f7fb"
+ KERNEL_IMAGE_BASE: https://${S3_HOST}/mesa-lava/${KERNEL_REPO}/${KERNEL_TAG}
LAVA_TAGS: subset-1-gfx
LAVA_JOB_PRIORITY: 30
@@ -133,6 +135,11 @@ stages:
- if: '$GITLAB_USER_LOGIN == "marge-bot" &&
$CI_PIPELINE_SOURCE == "merge_request_event"'
when: on_success
+.never-post-merge-rules:
+ rules:
+- if: *is-post-merge
+ when: never
+
# Rule to filter for only scheduled pipelines.
.scheduled_pipeline-rules:
rules:
@@ -150,6 +157,7 @@ stages:
.build-rules:
rules:
- !reference [.no_scheduled_pipelines-rules, rules]
+- !reference [.never-post-merge-rules, rules]
# Run automatically once all dependency jobs have passed
- when: on_success
@@ -157,6 +165,7 @@ stages:
.container+build-rules:
rules:
- !reference [.no_scheduled_pipelines-rules, rules]
+- !reference [.never-post-merge-rules, rules]
- when: manual
.ci-deqp-artifacts:
@@ -175,6 +184,7 @@ stages:
.container-rules:
rules:
- !reference [.no_scheduled_pipelines-rules, rules]
+- !reference [.never-post-merge-rules, rules]
# Run pipeline by default in the main project if any CI pipeline
# configuration files were changed, to ensure docker images are up to date
- if: *is-post-merge
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 2c9a1838e728..1705f268547a 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -324,6 +324,7 @@ virtio_gpu:none:
GPU_VERSION: none
extends:
- .test-gl
+- .test-rules
tags:
- kvm
script:
--
2.40.1
Re: [PATCH 1/6] drm/xe: Disable 32bits build
On Thu, Dec 21, 2023 at 02:28:04PM -0800, Lucas De Marchi wrote: > Add a dependency on CONFIG_64BIT since currently the xe driver doesn't > build on 32bits. It may be enabled again after all the issues are fixed. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/xe/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig > index 5b3da06e7ba3..a53b0fdc15a7 100644 > --- a/drivers/gpu/drm/xe/Kconfig > +++ b/drivers/gpu/drm/xe/Kconfig > @@ -1,7 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0-only > config DRM_XE > tristate "Intel Xe Graphics" > - depends on DRM && PCI && MMU && (m || (y && KUNIT=y)) > + depends on DRM && PCI && MMU && (m || (y && KUNIT=y)) && 64BIT > select INTERVAL_TREE > # we need shmfs for the swappable backing store, and in particular > # the shmem_readpage() which depends upon tmpfs > -- > 2.40.1 >
Re: [RFT PATCH v2 2/4] drm/msm/dpu: enable writeback on SC8108X
Title typo: SC8108X -> SC8180X :)
On 2023-12-03 03:32:01, Dmitry Baryshkov wrote:
> Enable WB2 hardware block, enabling writeback support on this platform.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h| 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> index 9ffc8804a6fc..d4b531752ec2 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> @@ -34,6 +34,7 @@ static const struct dpu_mdp_cfg sc8180x_mdp = {
> [DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8 },
> [DPU_CLK_CTRL_DMA2] = { .reg_off = 0x2bc, .bit_off = 8 },
> [DPU_CLK_CTRL_DMA3] = { .reg_off = 0x2c4, .bit_off = 8 },
> + [DPU_CLK_CTRL_WB2] = { .reg_off = 0x2bc, .bit_off = 16 },
> },
> };
>
> @@ -298,6 +299,21 @@ static const struct dpu_dsc_cfg sc8180x_dsc[] = {
> },
> };
>
> +static const struct dpu_wb_cfg sc8180x_wb[] = {
> + {
> + .name = "wb_2", .id = WB_2,
> + .base = 0x65000, .len = 0x2c8,
> + .features = WB_SDM845_MASK,
> + .format_list = wb2_formats,
> + .num_formats = ARRAY_SIZE(wb2_formats),
> + .clk_ctrl = DPU_CLK_CTRL_WB2,
> + .xin_id = 6,
> + .vbif_idx = VBIF_RT,
> + .maxlinewidth = 4096,
> + .intr_wb_done = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 4),
> + },
> +};
> +
> static const struct dpu_intf_cfg sc8180x_intf[] = {
> {
> .name = "intf_0", .id = INTF_0,
> @@ -411,6 +427,8 @@ const struct dpu_mdss_cfg dpu_sc8180x_cfg = {
> .pingpong = sc8180x_pp,
> .merge_3d_count = ARRAY_SIZE(sc8180x_merge_3d),
> .merge_3d = sc8180x_merge_3d,
> + .wb_count = ARRAY_SIZE(sc8180x_wb),
> + .wb = sc8180x_wb,
> .intf_count = ARRAY_SIZE(sc8180x_intf),
> .intf = sc8180x_intf,
> .vbif_count = ARRAY_SIZE(sdm845_vbif),
> --
> 2.39.2
>
Re: [PATCH v10 02/16] dt-bindings: media: mediatek: mdp3: merge the indentical RDMA under display
On Thu, Dec 21, 2023 at 10:28:52AM +0100, Krzysztof Kozlowski wrote: > On 20/12/2023 11:08, Moudy Ho wrote: > > To simplify maintenance and avoid branches, the identical component > > should be merged and placed in the path belonging to the MDP > > (from display/* to media/*). > > Combining bindings into one bigger meta-binding makes it usually more > difficult to maintain and review. Yeah, but these mediatek blocks appear to be used for both display and video codec pipelines. So having different bindings was probably wrong to start with. Rob
[PATCH 4/6] drm/xe/display: Avoid calling readq()
readq() is not available in 32bits. iosys-map already has the logic in
place to use read u64 in all cases, so simply add a helper variable for
using that.
Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Signed-off-by: Lucas De Marchi
---
.../gpu/drm/xe/compat-i915-headers/gem/i915_gem_object.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xe/compat-i915-headers/gem/i915_gem_object.h
b/drivers/gpu/drm/xe/compat-i915-headers/gem/i915_gem_object.h
index 5f19550cc845..6739dadaf1a9 100644
--- a/drivers/gpu/drm/xe/compat-i915-headers/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/xe/compat-i915-headers/gem/i915_gem_object.h
@@ -7,6 +7,7 @@
#define _I915_GEM_OBJECT_H_
#include
+#include
#include "xe_bo.h"
@@ -36,6 +37,7 @@ static inline int i915_gem_object_read_from_page(struct xe_bo
*bo,
{
struct ttm_bo_kmap_obj map;
void *virtual;
+ struct iosys_map vaddr;
bool is_iomem;
int ret;
@@ -52,10 +54,11 @@ static inline int i915_gem_object_read_from_page(struct
xe_bo *bo,
ofs &= ~PAGE_MASK;
virtual = ttm_kmap_obj_virtual(, _iomem);
if (is_iomem)
- *ptr = readq((void __iomem *)(virtual + ofs));
+ iosys_map_set_vaddr_iomem(, (void __iomem *)(virtual));
else
- *ptr = *(u64 *)(virtual + ofs);
+ iosys_map_set_vaddr(, virtual);
+ *ptr = iosys_map_rd(, ofs, u64);
ttm_bo_kunmap();
out_unlock:
xe_bo_unlock(bo);
--
2.40.1
[PATCH 5/6] drm/xe: Fix cast on trace variable
Cast the pointer to unsigned long and let it be implicitly extended to u64. This fixes the build on 32bits arch. Cc: Matthew Brost Cc: Niranjana Vishwanathapura Cc: Rodrigo Vivi Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/xe/xe_trace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_trace.h b/drivers/gpu/drm/xe/xe_trace.h index 95163c303f3e..e4e7262191ad 100644 --- a/drivers/gpu/drm/xe/xe_trace.h +++ b/drivers/gpu/drm/xe/xe_trace.h @@ -31,7 +31,7 @@ DECLARE_EVENT_CLASS(xe_gt_tlb_invalidation_fence, ), TP_fast_assign( - __entry->fence = (u64)fence; + __entry->fence = (unsigned long)fence; __entry->seqno = fence->seqno; ), -- 2.40.1
[PATCH 6/6] drm/xe: Enable 32bits build
Now that all the issues with 32bits are fixed, enable it again. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/xe/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig index a53b0fdc15a7..5b3da06e7ba3 100644 --- a/drivers/gpu/drm/xe/Kconfig +++ b/drivers/gpu/drm/xe/Kconfig @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_XE tristate "Intel Xe Graphics" - depends on DRM && PCI && MMU && (m || (y && KUNIT=y)) && 64BIT + depends on DRM && PCI && MMU && (m || (y && KUNIT=y)) select INTERVAL_TREE # we need shmfs for the swappable backing store, and in particular # the shmem_readpage() which depends upon tmpfs -- 2.40.1
[PATCH 0/6] drm/xe: Fix 32bit build
A few fixes when building xe with ARCH=i386. If getting the whole lot, we can simply skip the first and last patches. However they probably need to got through CI and be reviewed to avoid regressions. For the current pull request, simply disabling 32bits build is an alternative, so we'd apply patch 1 now and let the rest come later. Lucas De Marchi (6): drm/xe: Disable 32bits build drm/xe: Use _ULL for u64 division drm/xe/mmio: Cast to u64 when printing drm/xe/display: Avoid calling readq() drm/xe: Fix cast on trace variable drm/xe: Enable 32bits build .../gpu/drm/xe/compat-i915-headers/gem/i915_gem_object.h | 7 +-- drivers/gpu/drm/xe/xe_device.c | 2 +- drivers/gpu/drm/xe/xe_mmio.c | 4 ++-- drivers/gpu/drm/xe/xe_trace.h | 2 +- 4 files changed, 9 insertions(+), 6 deletions(-) -- 2.40.1
[PATCH 1/6] drm/xe: Disable 32bits build
Add a dependency on CONFIG_64BIT since currently the xe driver doesn't build on 32bits. It may be enabled again after all the issues are fixed. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/xe/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig index 5b3da06e7ba3..a53b0fdc15a7 100644 --- a/drivers/gpu/drm/xe/Kconfig +++ b/drivers/gpu/drm/xe/Kconfig @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_XE tristate "Intel Xe Graphics" - depends on DRM && PCI && MMU && (m || (y && KUNIT=y)) + depends on DRM && PCI && MMU && (m || (y && KUNIT=y)) && 64BIT select INTERVAL_TREE # we need shmfs for the swappable backing store, and in particular # the shmem_readpage() which depends upon tmpfs -- 2.40.1
[PATCH 3/6] drm/xe/mmio: Cast to u64 when printing
resource_size_t uses %pa format in printk since the size varies
depending on build options. However to keep the io_size/physical_size
addition in the same call we can't pass the address without adding yet
another variable in these function. Simply cast it to u64 and keep using
%llx.
Fixes: 286089ce6929 ("drm/xe: Improve vram info debug printing")
Cc: Oak Zeng
Cc: Michael J. Ruhl
Cc: Matthew Brost
Cc: Rodrigo Vivi
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/xe/xe_mmio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_mmio.c b/drivers/gpu/drm/xe/xe_mmio.c
index f660cfb79f50..5c46f2d0b6dc 100644
--- a/drivers/gpu/drm/xe/xe_mmio.c
+++ b/drivers/gpu/drm/xe/xe_mmio.c
@@ -272,8 +272,8 @@ int xe_mmio_probe_vram(struct xe_device *xe)
drm_info(>drm, "VRAM[%u, %u]: Actual physical size %pa,
usable size exclude stolen %pa, CPU accessible size %pa\n", id,
tile->id, >mem.vram.actual_physical_size,
>mem.vram.usable_size, >mem.vram.io_size);
drm_info(>drm, "VRAM[%u, %u]: DPA range: [%pa-%llx], io
range: [%pa-%llx]\n", id, tile->id,
->mem.vram.dpa_base, tile->mem.vram.dpa_base +
tile->mem.vram.actual_physical_size,
->mem.vram.io_start, tile->mem.vram.io_start +
tile->mem.vram.io_size);
+>mem.vram.dpa_base, tile->mem.vram.dpa_base +
(u64)tile->mem.vram.actual_physical_size,
+>mem.vram.io_start, tile->mem.vram.io_start +
(u64)tile->mem.vram.io_size);
/* calculate total size using tile size to get the correct HW
sizing */
total_size += tile_size;
--
2.40.1
[PATCH 2/6] drm/xe: Use _ULL for u64 division
Use DIV_ROUND_UP_ULL() so it also works on 32bit build.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/xe/xe_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index 86867d42d532..3f0dcf54277b 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -620,7 +620,7 @@ void xe_device_wmb(struct xe_device *xe)
u32 xe_device_ccs_bytes(struct xe_device *xe, u64 size)
{
return xe_device_has_flat_ccs(xe) ?
- DIV_ROUND_UP(size, NUM_BYTES_PER_CCS_BYTE(xe)) : 0;
+ DIV_ROUND_UP_ULL(size, NUM_BYTES_PER_CCS_BYTE(xe)) : 0;
}
bool xe_device_mem_access_ongoing(struct xe_device *xe)
--
2.40.1
Re: [PATCH v3 3/4] dt-bindings: display: Add SSD133x OLED controllers
On Tue, 19 Dec 2023 21:34:08 +0100, Javier Martinez Canillas wrote: > Add a Device Tree binding schema for the OLED panels based on the > Solomon SSD133x family of controllers. > > Signed-off-by: Javier Martinez Canillas > --- > > Changes in v3: > - Move solomon,ssd-common.yaml ref before the properties section and > width/height constraints after the other properties (Conor Dooley). > > Changes in v2: > - Unconditionally set the width and height constraints (Conor Dooley). > - Fix indentation in the DTS examples (Krzysztof Kozlowski). > > .../bindings/display/solomon,ssd133x.yaml | 57 +++ > 1 file changed, 57 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/solomon,ssd133x.yaml > Reviewed-by: Rob Herring
Re: [PATCH v3 2/4] dt-bindings: display: ssd132x: Add vendor prefix to width and height
On Tue, 19 Dec 2023 21:34:07 +0100, Javier Martinez Canillas wrote:
> Commit 2d23e7d6bacb ("dt-bindings: display: Add SSD132x OLED controllers")
> used the wrong properties for width and height, instead of the correct
> "solomon,width" and "solomon,height" properties.
>
> Fix this by adding the vendor prefix to the width and height properties.
>
> Fixes: 2d23e7d6bacb ("dt-bindings: display: Add SSD132x OLED controllers")
> Reported-by: Conor Dooley
> Closes:
> https://lore.kernel.org/dri-devel/20231218-example-envision-b41ca8efa251@spud/
> Signed-off-by: Javier Martinez Canillas
> ---
>
> (no changes since v1)
>
> .../devicetree/bindings/display/solomon,ssd132x.yaml | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
Acked-by: Rob Herring
Re: [PATCH v3 1/4] dt-bindings: display: ssd1307fb: Add vendor prefix to width and height
On Tue, 19 Dec 2023 21:34:06 +0100, Javier Martinez Canillas wrote:
> The commit 591825fba8a2 ("dt-bindings: display: ssd1307fb: Remove default
> width and height values") used the wrong properties for width and height,
> instead of the correct "solomon,width" and "solomon,height" properties.
>
> Fix this by adding the vendor prefix to the width and height properties.
>
> Fixes: 591825fba8a2 ("dt-bindings: display: ssd1307fb: Remove default width
> and height values")
> Reported-by: Conor Dooley
> Closes:
> https://lore.kernel.org/dri-devel/20231218-example-envision-b41ca8efa251@spud/
> Signed-off-by: Javier Martinez Canillas
> ---
>
> (no changes since v1)
>
> .../bindings/display/solomon,ssd1307fb.yaml | 20 +--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
Acked-by: Rob Herring
[PATCH] drm/bridge: parade-ps8640: Wait for HPD when doing an AUX transfer
Unlike what is claimed in commit f5aa7d46b0ee ("drm/bridge:
parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux"), if
someone manually tries to do an AUX transfer (like via `i2cdump ${bus}
0x50 i`) while the panel is off we don't just get a simple transfer
error. Instead, the whole ps8640 gets thrown for a loop and goes into
a bad state.
Let's put the function to wait for the HPD (and the magical 50 ms
after first reset) back in when we're doing an AUX transfer. This
shouldn't actually make things much slower (assuming the panel is on)
because we should immediately poll and see the HPD high. Mostly this
is just an extra i2c transfer to the bridge.
Fixes: f5aa7d46b0ee ("drm/bridge: parade-ps8640: Provide wait_hpd_asserted() in
struct drm_dp_aux")
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/bridge/parade-ps8640.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 541e4f5afc4c..fb5e9ae9ad81 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -346,6 +346,11 @@ static ssize_t ps8640_aux_transfer(struct drm_dp_aux *aux,
int ret;
pm_runtime_get_sync(dev);
+ ret = _ps8640_wait_hpd_asserted(ps_bridge, 200 * 1000);
+ if (ret) {
+ pm_runtime_put_sync_suspend(dev);
+ return ret;
+ }
ret = ps8640_aux_transfer_msg(aux, msg);
pm_runtime_mark_last_busy(dev);
pm_runtime_put_autosuspend(dev);
--
2.43.0.472.g3155946c3a-goog
[PULL] drm-xe-next v4
Hi Dave and Sima, Here goes a v4 of our first pull request. This fix the sign-off and 'Fixes:' tag issues of the top commit that was added during v3. Sorry about that, but I'm sure that after we become a drm-tip branch using dim to manage it, things like this won't happen again. v3: https://lore.kernel.org/all/zyr_1rvctfghe...@intel.com v2: https://lore.kernel.org/all/zyizv1pk6oljq...@intel.com/ v1: https://lore.kernel.org/all/zxzta75g5vhcr...@intel.com/ Thanks, Rodrigo. The following changes since commit a60501d7c2d3e70b3545b9b96576628e369d8e85: Merge tag 'drm-misc-next-2023-12-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2023-12-08 16:27:00 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-next-2023-12-21-pr1-1 for you to fetch changes up to b6e1b708176846248c87318786d22465ac96dd2c: drm/xe: Remove uninitialized variable from warning (2023-12-21 16:27:45 -0500) Introduce a new DRM driver for Intel GPUs Xe, is a new driver for Intel GPUs that supports both integrated and discrete platforms. The experimental support starts with Tiger Lake. i915 will continue be the main production driver for the platforms up to Meteor Lake and Alchemist. Then the goal is to make this Intel Xe driver the primary driver for Lunar Lake and newer platforms. It uses most, if not all, of the key drm concepts, in special: TTM, drm-scheduler, drm-exec, drm-gpuvm/gpuva and others. Alan Previn (1): drm/xe/guc: Fix h2g_write usage of GUC_CTB_MSG_MAX_LEN Alexander Usyskin (1): drm/xe/gsc: enable pvc support Andrzej Hajda (1): drm/xe: implement driver initiated function-reset Animesh Manna (1): drm/xe/dsb: DSB implementation for xe Anshuman Gupta (7): drm/xe/pm: Disable PM on unbounded pcie parent bridge drm/xe/pm: Add pci d3cold_capable support drm/xe/pm: Refactor xe_pm_runtime_init drm/xe/pm: Add vram_d3cold_threshold Sysfs drm/xe/pm: Toggle d3cold_allowed using vram_usages drm/xe/pm: Init pcode and restore vram on power lost drm/xe/pm: Add vram_d3cold_threshold for d3cold capable device Anusha Srivatsa (10): drm/xe/huc: Support for loading unversiond HuC drm/xe: Load HuC on Alderlake S drm/xe: GuC and HuC loading support for RKL drm/xe: Add Rocketlake device info drm/xe/kunit: Handle fake device creation for all platform/subplatform cases drm/xe: Add missing ADL entries to xe_test_wa drm/xe/rplu: s/ADLP/ALDERLAKE_P drm/xe/rpls: Add RPLS Support drm/xe/rpls: Add Stepping info for RPLS drm/xe: Add missing ADL entries to xe_test_wa Aravind Iddamsetty (5): drm/xe: Get GT clock to nanosecs drm/xe: Use spinlock in forcewake instead of mutex drm/xe/pmu: Enable PMU interface drm/xe/pmu: Drop interrupt pmu event drm/xe: Fix lockdep warning in xe_force_wake calls Ashutosh Dixit (2): drm/xe/uapi: Use common drm_xe_ext_set_property extension drm/xe/pmu: Remove PMU from Xe till uapi is finalized Badal Nilawar (11): drm/xe: Donot apply forcewake while reading actual frequency drm/xe/mtl: Add support to get C6 residency/status of MTL drm/xe/hwmon: Expose power attributes drm/xe/hwmon: Expose card reactive critical power drm/xe/hwmon: Expose input voltage attribute drm/xe/hwmon: Expose hwmon energy attribute drm/xe: Extend rpX values extraction for future platforms drm/xe/hwmon: Add kernel doc and refactor xe hwmon drm/xe/hwmon: Protect hwmon rw attributes with hwmon_lock drm/xe/hwmon: Expose power1_max_interval drm/xe/mtl: Use 16.67 Mhz freq scale factor to get rpX Balasubramani Vivekanandan (9): drm/xe/gt: Enable interrupt while initializing root gt drm/xe: Use max wopcm size when validating the preset GuC wopcm size drm/xe: Stop accepting value in xe_migrate_clear drm/xe: Keep all resize bar related prints inside xe_resize_vram_bar drm/xe/xe2: Add MOCS table drm/xe/lnl: Hook up MOCS table drm/xe: Leverage ComputeCS read L3 caching drm/xe: Add event tracing for CTB drm/xe/trace: Optimize trace definition Bommithi Sakeena (3): drm/xe: Ensure mutex are destroyed drm/xe: Add a missing mutex_destroy to xe_ttm_vram_mgr drm/xe: Encapsulate all the module parameters Bommu Krishnaiah (2): drm/xe/uapi: add exec_queue_id member to drm_xe_wait_user_fence structure drm/xe/uapi: Return correct error code for xe_wait_user_fence_ioctl Brian Welty (12): drm/xe: Fix BUG_ON during bind with prefetch drm/xe: Fix lockdep warning from xe_vm_madvise drm/xe: Simplify xe_res_get_buddy() drm/xe: Replace xe_ttm_vram_mgr.tile with xe_mem_region drm/xe: Remove unused xe_bo_to_tile
Re: [PATCH RESEND v1 1/8] dt-bindings: panel: lvds: Append edt,etml0700z9ndha in panel-lvds
On Thu, 21 Dec 2023 13:43:32 +0100, Raphael Gallais-Pou wrote: > List EDT ETML0700Z9NDHA in the LVDS panel enumeration. > > Signed-off-by: Raphael Gallais-Pou > --- > Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
Re: [RFC PATCH 2/2] dt-bindings: display: msm: mass-rename files
On Thu, 21 Dec 2023 12:25:06 +0200, Dmitry Baryshkov wrote:
> Rename the Qualcomm MSM Display schemas to follow the main compatible
> string instead of just using the block type. This follows the
> established practice for YAML file names.
>
> Cc: Aiqun Yu (Maria)
> Signed-off-by: Dmitry Baryshkov
> ---
> .../bindings/display/msm/{gmu.yaml => qcom,adreno-gmu.yaml} | 2 +-
> .../bindings/display/msm/{gpu.yaml => qcom,adreno.yaml} | 2 +-
> .../bindings/display/msm/{hdmi.yaml => qcom,hdmi-tx.yaml} | 2 +-
> .../bindings/display/msm/{mdp4.yaml => qcom,mdp4.yaml} | 2 +-
> .../msm/{dsi-controller-main.yaml => qcom,mdss-dsi-ctrl.yaml} | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
> rename Documentation/devicetree/bindings/display/msm/{gmu.yaml =>
> qcom,adreno-gmu.yaml} (99%)
> rename Documentation/devicetree/bindings/display/msm/{gpu.yaml =>
> qcom,adreno.yaml} (99%)
> rename Documentation/devicetree/bindings/display/msm/{hdmi.yaml =>
> qcom,hdmi-tx.yaml} (98%)
> rename Documentation/devicetree/bindings/display/msm/{mdp4.yaml =>
> qcom,mdp4.yaml} (97%)
> rename
> Documentation/devicetree/bindings/display/msm/{dsi-controller-main.yaml =>
> qcom,mdss-dsi-ctrl.yaml} (99%)
>
Acked-by: Rob Herring
Re: [RFC PATCH 1/2] dt-bindings: display: msm: move DSI PHY schema to bindings/phy
On Thu, 21 Dec 2023 12:25:05 +0200, Dmitry Baryshkov wrote:
> While the DSI PHY schema files describe the display-related hardware,
> they still describe a PHY. Move all DSI PHY schema files to the phy/
> subdir.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../msm/dsi-phy-10nm.yaml => phy/qcom,dsi-phy-10nm.yaml} | 4 ++--
> .../msm/dsi-phy-14nm.yaml => phy/qcom,dsi-phy-14nm.yaml} | 4 ++--
> .../msm/dsi-phy-20nm.yaml => phy/qcom,dsi-phy-20nm.yaml} | 4 ++--
> .../msm/dsi-phy-28nm.yaml => phy/qcom,dsi-phy-28nm.yaml} | 4 ++--
> .../msm/dsi-phy-7nm.yaml => phy/qcom,dsi-phy-7nm.yaml}| 4 ++--
> .../msm/dsi-phy-common.yaml => phy/qcom,dsi-phy-common.yaml} | 2 +-
> 6 files changed, 11 insertions(+), 11 deletions(-)
> rename Documentation/devicetree/bindings/{display/msm/dsi-phy-10nm.yaml =>
> phy/qcom,dsi-phy-10nm.yaml} (96%)
> rename Documentation/devicetree/bindings/{display/msm/dsi-phy-14nm.yaml =>
> phy/qcom,dsi-phy-14nm.yaml} (94%)
> rename Documentation/devicetree/bindings/{display/msm/dsi-phy-20nm.yaml =>
> phy/qcom,dsi-phy-20nm.yaml} (93%)
> rename Documentation/devicetree/bindings/{display/msm/dsi-phy-28nm.yaml =>
> phy/qcom,dsi-phy-28nm.yaml} (94%)
> rename Documentation/devicetree/bindings/{display/msm/dsi-phy-7nm.yaml =>
> phy/qcom,dsi-phy-7nm.yaml} (94%)
> rename Documentation/devicetree/bindings/{display/msm/dsi-phy-common.yaml =>
> phy/qcom,dsi-phy-common.yaml} (90%)
>
Acked-by: Rob Herring
Re: [PATCH RESEND v1 2/8] dt-bindings: display: add dt-bindings for STM32 LVDS device
On 21/12/2023 13:43, Raphael Gallais-Pou wrote: > Add dt-binding file for "st,stm32-lvds" compatible. > > Signed-off-by: Raphael Gallais-Pou > --- I don't know why this was resend, nothing explains it, but I already commented on other version. Please respond to comments there. In the future, unless it is obvious resend over 2 weeks, say why you are doing it and what changed. Best regards, Krzysztof
[PULL] drm-xe-next v3
Hi Dave and Sima, Here goes a v3 of our first pull request. It is basically the same, but with 2 fixed Author 'Signed-off-by:' tags plus a fix for the clang build that would fail with our W=1. v2: https://lore.kernel.org/all/zyizv1pk6oljq...@intel.com/ v1: https://lore.kernel.org/all/zxzta75g5vhcr...@intel.com/ The following changes since commit a60501d7c2d3e70b3545b9b96576628e369d8e85: Merge tag 'drm-misc-next-2023-12-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2023-12-08 16:27:00 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-next-2023-12-21-pr1 for you to fetch changes up to b0a00efafde012c890f0f3c0f5a3114f69f4ad60: drm/xe: Remove uninitialized variable from warning (2023-12-21 11:53:37 -0500) Introduce a new DRM driver for Intel GPUs Xe, is a new driver for Intel GPUs that supports both integrated and discrete platforms. The experimental support starts with Tiger Lake. i915 will continue be the main production driver for the platforms up to Meteor Lake and Alchemist. Then the goal is to make this Intel Xe driver the primary driver for Lunar Lake and newer platforms. It uses most, if not all, of the key drm concepts, in special: TTM, drm-scheduler, drm-exec, drm-gpuvm/gpuva and others. Alan Previn (1): drm/xe/guc: Fix h2g_write usage of GUC_CTB_MSG_MAX_LEN Alexander Usyskin (1): drm/xe/gsc: enable pvc support Andrzej Hajda (1): drm/xe: implement driver initiated function-reset Animesh Manna (1): drm/xe/dsb: DSB implementation for xe Anshuman Gupta (7): drm/xe/pm: Disable PM on unbounded pcie parent bridge drm/xe/pm: Add pci d3cold_capable support drm/xe/pm: Refactor xe_pm_runtime_init drm/xe/pm: Add vram_d3cold_threshold Sysfs drm/xe/pm: Toggle d3cold_allowed using vram_usages drm/xe/pm: Init pcode and restore vram on power lost drm/xe/pm: Add vram_d3cold_threshold for d3cold capable device Anusha Srivatsa (10): drm/xe/huc: Support for loading unversiond HuC drm/xe: Load HuC on Alderlake S drm/xe: GuC and HuC loading support for RKL drm/xe: Add Rocketlake device info drm/xe/kunit: Handle fake device creation for all platform/subplatform cases drm/xe: Add missing ADL entries to xe_test_wa drm/xe/rplu: s/ADLP/ALDERLAKE_P drm/xe/rpls: Add RPLS Support drm/xe/rpls: Add Stepping info for RPLS drm/xe: Add missing ADL entries to xe_test_wa Aravind Iddamsetty (5): drm/xe: Get GT clock to nanosecs drm/xe: Use spinlock in forcewake instead of mutex drm/xe/pmu: Enable PMU interface drm/xe/pmu: Drop interrupt pmu event drm/xe: Fix lockdep warning in xe_force_wake calls Ashutosh Dixit (2): drm/xe/uapi: Use common drm_xe_ext_set_property extension drm/xe/pmu: Remove PMU from Xe till uapi is finalized Badal Nilawar (11): drm/xe: Donot apply forcewake while reading actual frequency drm/xe/mtl: Add support to get C6 residency/status of MTL drm/xe/hwmon: Expose power attributes drm/xe/hwmon: Expose card reactive critical power drm/xe/hwmon: Expose input voltage attribute drm/xe/hwmon: Expose hwmon energy attribute drm/xe: Extend rpX values extraction for future platforms drm/xe/hwmon: Add kernel doc and refactor xe hwmon drm/xe/hwmon: Protect hwmon rw attributes with hwmon_lock drm/xe/hwmon: Expose power1_max_interval drm/xe/mtl: Use 16.67 Mhz freq scale factor to get rpX Balasubramani Vivekanandan (9): drm/xe/gt: Enable interrupt while initializing root gt drm/xe: Use max wopcm size when validating the preset GuC wopcm size drm/xe: Stop accepting value in xe_migrate_clear drm/xe: Keep all resize bar related prints inside xe_resize_vram_bar drm/xe/xe2: Add MOCS table drm/xe/lnl: Hook up MOCS table drm/xe: Leverage ComputeCS read L3 caching drm/xe: Add event tracing for CTB drm/xe/trace: Optimize trace definition Bommithi Sakeena (3): drm/xe: Ensure mutex are destroyed drm/xe: Add a missing mutex_destroy to xe_ttm_vram_mgr drm/xe: Encapsulate all the module parameters Bommu Krishnaiah (2): drm/xe/uapi: add exec_queue_id member to drm_xe_wait_user_fence structure drm/xe/uapi: Return correct error code for xe_wait_user_fence_ioctl Brian Welty (12): drm/xe: Fix BUG_ON during bind with prefetch drm/xe: Fix lockdep warning from xe_vm_madvise drm/xe: Simplify xe_res_get_buddy() drm/xe: Replace xe_ttm_vram_mgr.tile with xe_mem_region drm/xe: Remove unused xe_bo_to_tile drm/xe: Replace usage of mem_type_to_tile drm/xe: Fix dequeue of access counter work item drm/xe: Fix pagefault and access counter worker functions
Re: [PATCH v5 0/8] iio: new DMABUF based API, v5
Hi Jonathan, Le jeudi 21 décembre 2023 à 16:30 +, Jonathan Cameron a écrit : > On Tue, 19 Dec 2023 18:50:01 +0100 > Paul Cercueil wrote: > > > [V4 was: "iio: Add buffer write() support"][1] > > > > Hi Jonathan, > > > Hi Paul, > > > This is a respin of the V3 of my patchset that introduced a new > > interface based on DMABUF objects [2]. > > Great to see this moving forwards. > > > > > The V4 was a split of the patchset, to attempt to upstream buffer > > write() support first. But since there is no current user upstream, > > it > > was not merged. This V5 is about doing the opposite, and contains > > the > > new DMABUF interface, without adding the buffer write() support. It > > can > > already be used with the upstream adi-axi-adc driver. > > Seems like a sensible path in the short term. > > > > > In user-space, Libiio uses it to transfer back and forth blocks of > > samples between the hardware and the applications, without having > > to > > copy the data. > > > > On a ZCU102 with a FMComms3 daughter board, running Libiio from the > > pcercuei/dev-new-dmabuf-api branch [3], compiled with > > WITH_LOCAL_DMABUF_API=OFF (so that it uses fileio): > > sudo utils/iio_rwdev -b 4096 -B cf-ad9361-lpc > > Throughput: 116 MiB/s > > > > Same hardware, with the DMABUF API (WITH_LOCAL_DMABUF_API=ON): > > sudo utils/iio_rwdev -b 4096 -B cf-ad9361-lpc > > Throughput: 475 MiB/s > > > > This benchmark only measures the speed at which the data can be > > fetched > > to iio_rwdev's internal buffers, and does not actually try to read > > the > > data (e.g. to pipe it to stdout). It shows that fetching the data > > is > > more than 4x faster using the new interface. > > > > When actually reading the data, the performance difference isn't > > that > > impressive (maybe because in case of DMABUF the data is not in > > cache): > > This needs a bit more investigation ideally. Perhaps perf counters > can be > used to establish that cache misses are the main different between > dropping it on the floor and actually reading the data. Yes, we'll work on it. The other big difference is that fileio uses dma_alloc_coherent() while the DMABUFs use non-coherent mappings. I guess coherent memory is faster for the typical access pattern (which is "read/write everything sequentially once"). > > > > WITH_LOCAL_DMABUF_API=OFF (so that it uses fileio): > > sudo utils/iio_rwdev -b 4096 cf-ad9361-lpc | dd of=/dev/zero > > status=progress > > 2446422528 bytes (2.4 GB, 2.3 GiB) copied, 22 s, 111 MB/s > > > > WITH_LOCAL_DMABUF_API=ON: > > sudo utils/iio_rwdev -b 4096 cf-ad9361-lpc | dd of=/dev/zero > > status=progress > > 2334388736 bytes (2.3 GB, 2.2 GiB) copied, 21 s, 114 MB/s > > > > One interesting thing to note is that fileio is (currently) > > actually > > faster than the DMABUF interface if you increase a lot the buffer > > size. > > My explanation is that the cache invalidation routine takes more > > and > > more time the bigger the DMABUF gets. This is because the DMABUF is > > backed by small-size pages, so a (e.g.) 64 MiB DMABUF is backed by > > up > > to 16 thousands pages, that have to be invalidated one by one. This > > can > > be addressed by using huge pages, but the udmabuf driver does not > > (yet) > > support creating DMABUFs backed by huge pages. > > I'd imagine folios of reasonable size will help sort of a huge page > as then hopefully it will use the flush by va range instructions if > available. > > > > > Anyway, the real benefits happen when the DMABUFs are either shared > > between IIO devices, or between the IIO subsystem and another > > filesystem. In that case, the DMABUFs are simply passed around > > drivers, > > without the data being copied at any moment. > > > > We use that feature to transfer samples from our transceivers to > > USB, > > using a DMABUF interface to FunctionFS [4]. > > > > This drastically increases the throughput, to about 274 MiB/s over > > a > > USB3 link, vs. 127 MiB/s using IIO's fileio interface + write() to > > the > > FunctionFS endpoints, for a lower CPU usage (0.85 vs. 0.65 load > > avg.). > > This is a nice example. Where are you with getting the patch merged? I'll send a new version (mostly a [RESEND]...) in the coming days. As you can see from the review on my last attempt, the main blocker is that nobody wants to merge a new interface if the rest of the kernel bits aren't upstream yet. Kind of a chicken-and-egg problem :) > Overall, this code looks fine to me, though there are some parts that > need review by other maintainers (e.g. Vinod for the dmaengine > callback) > and I'd like a 'looks fine' at least form those who know a lot more > about dmabuf than I do. > > To actually make this useful sounds like either udmabuf needs some > perf > improvements, or there has to be an upstream case of sharing it > without > something else (e.g your functionfs patches). So what do we need to > get in before the positive benefit becomes worth
Re: [PATCH v5 7/8] iio: buffer-dmaengine: Support new DMABUF based userspace API
Hi Jonathan,
Le jeudi 21 décembre 2023 à 16:12 +, Jonathan Cameron a écrit :
> On Tue, 19 Dec 2023 18:50:08 +0100
> Paul Cercueil wrote:
>
> > Use the functions provided by the buffer-dma core to implement the
> > DMABUF userspace API in the buffer-dmaengine IIO buffer
> > implementation.
> >
> > Since we want to be able to transfer an arbitrary number of bytes
> > and
> > not necesarily the full DMABUF, the associated scatterlist is
> > converted
> > to an array of DMA addresses + lengths, which is then passed to
> > dmaengine_prep_slave_dma_array().
> >
> > Signed-off-by: Paul Cercueil
> One question inline. Otherwise looks fine to me.
>
> J
> >
> > ---
> > v3: Use the new dmaengine_prep_slave_dma_array(), and adapt the
> > code to
> > work with the new functions introduced in industrialio-buffer-
> > dma.c.
> >
> > v5: - Use the new dmaengine_prep_slave_dma_vec().
> > - Restrict to input buffers, since output buffers are not yet
> > supported by IIO buffers.
> > ---
> > .../buffer/industrialio-buffer-dmaengine.c | 52
> > ---
> > 1 file changed, 46 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > index 5f85ba38e6f6..825d76a24a67 100644
> > --- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > +++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > @@ -64,15 +64,51 @@ static int
> > iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue
> > *queue,
> > struct dmaengine_buffer *dmaengine_buffer =
> > iio_buffer_to_dmaengine_buffer(>buffer);
> > struct dma_async_tx_descriptor *desc;
> > + unsigned int i, nents;
> > + struct scatterlist *sgl;
> > + struct dma_vec *vecs;
> > + size_t max_size;
> > dma_cookie_t cookie;
> > + size_t len_total;
> >
> > - block->bytes_used = min(block->size, dmaengine_buffer-
> > >max_size);
> > - block->bytes_used = round_down(block->bytes_used,
> > - dmaengine_buffer->align);
> > + if (queue->buffer.direction != IIO_BUFFER_DIRECTION_IN) {
> > + /* We do not yet support output buffers. */
> > + return -EINVAL;
> > + }
> >
> > - desc = dmaengine_prep_slave_single(dmaengine_buffer->chan,
> > - block->phys_addr, block->bytes_used,
> > DMA_DEV_TO_MEM,
> > - DMA_PREP_INTERRUPT);
> > + if (block->sg_table) {
> > + sgl = block->sg_table->sgl;
> > + nents = sg_nents_for_len(sgl, block->bytes_used);
>
> Are we guaranteed the length in the sglist is enough? If not this
> can return an error code.
The length of the sglist will always be enough, the
iio_buffer_enqueue_dmabuf() function already checks that block-
>bytes_used is equal or smaller than the size of the DMABUF.
It is quite a few functions above in the call stack though, so I can
handle the errors of sg_nents_for_len() here if you think makes sense.
Cheers,
-Paul
> > +
> > + vecs = kmalloc_array(nents, sizeof(*vecs),
> > GFP_KERNEL);
> > + if (!vecs)
> > + return -ENOMEM;
> > +
> > + len_total = block->bytes_used;
> > +
> > + for (i = 0; i < nents; i++) {
> > + vecs[i].addr = sg_dma_address(sgl);
> > + vecs[i].len = min(sg_dma_len(sgl),
> > len_total);
> > + len_total -= vecs[i].len;
> > +
> > + sgl = sg_next(sgl);
> > + }
> > +
> > + desc =
> > dmaengine_prep_slave_dma_vec(dmaengine_buffer->chan,
> > + vecs, nents,
> > DMA_DEV_TO_MEM,
> > +
> > DMA_PREP_INTERRUPT);
> > + kfree(vecs);
> > + } else {
> > + max_size = min(block->size, dmaengine_buffer-
> > >max_size);
> > + max_size = round_down(max_size, dmaengine_buffer-
> > >align);
> > + block->bytes_used = max_size;
> > +
> > + desc =
> > dmaengine_prep_slave_single(dmaengine_buffer->chan,
> > + block-
> > >phys_addr,
> > + block-
> > >bytes_used,
> > + DMA_DEV_TO_MEM,
> > +
> > DMA_PREP_INTERRUPT);
> > + }
> > if (!desc)
> > return -ENOMEM;
> >
>
Re: [PATCH v1 2/8] dt-bindings: display: add dt-bindings for STM32 LVDS device
On 21/12/2023 13:28, Raphael Gallais-Pou wrote:
> Add dt-binding file for "st,stm32-lvds" compatible.
>
A nit, subject: drop second/last, redundant "dt-bindings for". The
"dt-bindings" prefix is already stating that these are bindings.
> Signed-off-by: Raphael Gallais-Pou
> ---
> .../bindings/display/st,stm32-lvds.yaml | 114 ++
> 1 file changed, 114 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
>
...
> +properties:
> + "#clock-cells":
> +const: 0
> +
> + compatible:
> +const: st,stm32-lvds
Please put compatible as first.
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +items:
> + - description: APB peripheral clock
> + - description: Reference clock for the internal PLL
> +
> + clock-names:
> +items:
> + - const: pclk
> + - const: ref
> +
> + resets:
> +maxItems: 1
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: |
> + LVDS input port node, connected to the LTDC RGB output port.
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: |
> + LVDS output port node, connected to a panel or bridge input port.
Ports are not required? I would assume it won't work without input and
output.
> +
> +required:
> + - "#clock-cells"
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - resets
> + - ports
> +
> +unevaluatedProperties: false
additionalProperties instead... or did I miss some $ref anywhere?
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +
> +lvds: lvds@4806 {
> +#clock-cells = <0>;
> +compatible = "st,stm32-lvds";
compatible is always the first property.
> +reg = <0x4806 0x2000>;
put clock-cells here
> +clocks = < CK_BUS_LVDS>, < CK_KER_LVDSPHY>;
> +clock-names = "pclk", "ref";
> +resets = < LVDS_R>;
Best regards,
Krzysztof
Re: [PATCH v5 5/8] iio: core: Add new DMABUF interface infrastructure
Hi Jonathan,
Le jeudi 21 décembre 2023 à 12:06 +, Jonathan Cameron a écrit :
> On Tue, 19 Dec 2023 18:50:06 +0100
> Paul Cercueil wrote:
>
> > Add the necessary infrastructure to the IIO core to support a new
> > optional DMABUF based interface.
> >
> > With this new interface, DMABUF objects (externally created) can be
> > attached to a IIO buffer, and subsequently used for data transfer.
> >
> > A userspace application can then use this interface to share DMABUF
> > objects between several interfaces, allowing it to transfer data in
> > a
> > zero-copy fashion, for instance between IIO and the USB stack.
> >
> > The userspace application can also memory-map the DMABUF objects,
> > and
> > access the sample data directly. The advantage of doing this vs.
> > the
> > read() interface is that it avoids an extra copy of the data
> > between the
> > kernel and userspace. This is particularly userful for high-speed
> > devices which produce several megabytes or even gigabytes of data
> > per
> > second.
> >
> > As part of the interface, 3 new IOCTLs have been added:
> >
> > IIO_BUFFER_DMABUF_ATTACH_IOCTL(int fd):
> > Attach the DMABUF object identified by the given file descriptor
> > to the
> > buffer.
> >
> > IIO_BUFFER_DMABUF_DETACH_IOCTL(int fd):
> > Detach the DMABUF object identified by the given file descriptor
> > from
> > the buffer. Note that closing the IIO buffer's file descriptor
> > will
> > automatically detach all previously attached DMABUF objects.
> >
> > IIO_BUFFER_DMABUF_ENQUEUE_IOCTL(struct iio_dmabuf *):
> > Request a data transfer to/from the given DMABUF object. Its file
> > descriptor, as well as the transfer size and flags are provided in
> > the
> > "iio_dmabuf" structure.
> >
> > These three IOCTLs have to be performed on the IIO buffer's file
> > descriptor, obtained using the IIO_BUFFER_GET_FD_IOCTL() ioctl.
> >
>
> Fair enough - so they don't apply to the 'legacy' buffer which
> simplifies
> things but in one place you assume that logic is used (given error
> return
> values).
>
> > Signed-off-by: Paul Cercueil
> >
> This is big and complex and I'm out of time for now, so I've made
> some
> comments but should revisit it.
> I'm also looking for review from those more familiar with dmabuf side
> of things than I am!
>
> Jonathan
>
>
> >
> > +static int iio_dma_resv_lock(struct dma_buf *dmabuf, bool
> > nonblock)
> > +{
> > + int ret;
> > +
> > + ret = dma_resv_lock_interruptible(dmabuf->resv, NULL);
> > + if (ret) {
> > + if (ret != -EDEADLK)
> > + goto out;
> > + if (nonblock) {
> > + ret = -EBUSY;
> > + goto out;
> > + }
> > +
> > + ret = dma_resv_lock_slow_interruptible(dmabuf-
> > >resv, NULL);
> > + }
> > +
> > +out:
> > + return ret;
>
> I'm not a fan gotos that do nothing. Just return in appropriate
> places above.
>
> > +}
> >
> > +static int iio_buffer_detach_dmabuf(struct iio_dev_buffer_pair
> > *ib, int *user_req)
> > +{
> > + struct dma_buf_attachment *attach;
> > + struct iio_dmabuf_priv *priv;
> > + struct dma_buf *dmabuf;
> > + int dmabuf_fd, ret = 0;
> > +
> > + if (copy_from_user(_fd, user_req,
> > sizeof(dmabuf_fd)))
> > + return -EFAULT;
> > +
> > + dmabuf = dma_buf_get(dmabuf_fd);
> > + if (IS_ERR(dmabuf))
> > + return PTR_ERR(dmabuf);
> > +
> > + attach = iio_buffer_find_attachment(ib->indio_dev,
> > dmabuf);
> > + if (IS_ERR(attach)) {
> > + ret = PTR_ERR(attach);
> > + goto out_dmabuf_put;
> > + }
> > +
> > + priv = attach->importer_priv;
> > + list_del_init(>entry);
> > +
> > + /*
> > +* Unref twice to release the reference obtained with
> > +* iio_buffer_find_attachment() above, and the one
> > obtained in
> > +* iio_buffer_attach_dmabuf().
> > +*/
> > + iio_buffer_dmabuf_put(attach);
> > + iio_buffer_dmabuf_put(attach);
> > +
> > +out_dmabuf_put:
> > + dma_buf_put(dmabuf);
> As below. Feels like a __free(dma_buf_put) bit of magic would be a
> nice to have.
Whoa, never heard about this. That looks great!
>
> > +
> > + return ret;
> > +}
> > +
> > +static const char *
> > +iio_buffer_dma_fence_get_driver_name(struct dma_fence *fence)
> > +{
> > + return "iio";
> > +}
> > +
> > +static void iio_buffer_dma_fence_release(struct dma_fence *fence)
> > +{
> > + struct iio_dma_fence *iio_fence =
> > + container_of(fence, struct iio_dma_fence, base);
> > +
> > + kfree(iio_fence);
> > +}
> > +
> > +static const struct dma_fence_ops iio_buffer_dma_fence_ops = {
> > + .get_driver_name=
> > iio_buffer_dma_fence_get_driver_name,
> > + .get_timeline_name =
> > iio_buffer_dma_fence_get_driver_name,
> > + .release= iio_buffer_dma_fence_release,
> > +};
> > +
> > +static int iio_buffer_enqueue_dmabuf(struct iio_dev_buffer_pair
> > *ib,
> > + struct iio_dmabuf
[PATCH 3/3] drm/i915/gt: Disable HW load balancing for CCS
The hardware is not able to dynamically balance the load between CCS engines. Wa_16016805146 suggests disabling it for all platforms. Signed-off-by: Andi Shyti Cc: Chris Wilson Cc: Joonas Lahtinen Cc: Niranjana Vishwanathapura Cc: Tejas Upadhyay --- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++ 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index 3e558d6d5e89..edaa446abd91 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -1478,6 +1478,7 @@ #define GEN12_RCU_MODE _MMIO(0x14800) #define GEN12_RCU_MODE_CCS_ENABLEREG_BIT(0) +#define XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE REG_BIT(1) #define CHV_FUSE_GT_MMIO(VLV_GUNIT_BASE + 0x2168) #define CHV_FGT_DISABLE_SS0 (1 << 10) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 3eacbc50caf8..a7718f7d2925 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -2978,6 +2978,12 @@ general_render_compute_wa_init(struct intel_engine_cs *engine, struct i915_wa_li wa_mcr_masked_en(wal, GEN8_HALF_SLICE_CHICKEN1, GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE); } + + /* +* Wa_16016805146: disable the CCS load balancing +* indiscriminately for all the platforms +*/ + wa_masked_en(wal, GEN12_RCU_MODE, XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE); } static void -- 2.43.0
[PATCH 2/3] drm/i915/gt: Allow user to set up the CSS mode
Now that the CCS mode is configurable, an interface has been
exposed in the GT's sysfs set of files, allowing users to set the
mode.
Additionally, another interface has been added to display the
number of available slices, named 'num_slices.'
Signed-off-by: Andi Shyti
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Niranjana Vishwanathapura
Cc: Tejas Upadhyay
---
drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c | 68 +
drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h | 1 +
drivers/gpu/drm/i915/gt/intel_gt_sysfs.c| 2 +
3 files changed, 71 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
index fab8a77bded2..88663698eb1f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
@@ -7,6 +7,7 @@
#include "intel_gt.h"
#include "intel_gt_ccs_mode.h"
+#include "intel_gt_print.h"
#include "intel_gt_regs.h"
#include "intel_gt_types.h"
@@ -79,3 +80,70 @@ void intel_gt_fini_ccs_mode(struct intel_gt *gt)
{
mutex_destroy(>ccs.mutex);
}
+
+static ssize_t
+ccs_mode_show(struct kobject *kobj, struct kobj_attribute *attr, char *buff)
+{
+ struct intel_gt *gt = container_of(kobj, struct intel_gt, sysfs_gt);
+
+ return sysfs_emit(buff, "%u\n", gt->ccs.mode);
+}
+
+static ssize_t
+ccs_mode_store(struct kobject *kobj, struct kobj_attribute *attr,
+ const char *buff, size_t count)
+{
+ struct intel_gt *gt = container_of(kobj, struct intel_gt, sysfs_gt);
+ int num_slices = hweight32(CCS_MASK(gt));
+ int err;
+ u32 val;
+
+ err = kstrtou32(buff, 0, );
+ if (err)
+ return err;
+
+ if ((!val) || (val > num_slices) || (val % num_slices))
+ return -EINVAL;
+
+ mutex_lock(>ccs.mutex);
+
+ if (val == gt->ccs.mode)
+ goto out;
+
+ gt->ccs.mode = val;
+ intel_gt_apply_ccs_mode(gt);
+
+out:
+ mutex_unlock(>ccs.mutex);
+
+ return count;
+}
+
+static ssize_t
+num_slices_show(struct kobject *kobj, struct kobj_attribute *attr, char *buff)
+{
+ struct intel_gt *gt = container_of(kobj, struct intel_gt, sysfs_gt);
+ u32 num_slices;
+
+ num_slices = hweight32(CCS_MASK(gt));
+
+ return sysfs_emit(buff, "%u\n", num_slices);
+}
+
+static struct kobj_attribute ccs_mode = __ATTR_RW(ccs_mode);
+static struct kobj_attribute num_slices = __ATTR_RO(num_slices);
+
+static const struct attribute * const ccs_mode_attrs[] = {
+ _mode.attr,
+ _slices.attr,
+ NULL
+};
+
+void intel_gt_sysfs_ccs_mode(struct intel_gt *gt)
+{
+ int ret;
+
+ ret = sysfs_create_files(>sysfs_gt, ccs_mode_attrs);
+ if (ret)
+ gt_warn(gt, "Failed to create ccs mode sysfs files");
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
index 751c5700944b..ae96de1b36c5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
@@ -12,5 +12,6 @@ void intel_gt_init_ccs_mode(struct intel_gt *gt);
void intel_gt_fini_ccs_mode(struct intel_gt *gt);
void intel_gt_apply_ccs_mode(struct intel_gt *gt);
+void intel_gt_sysfs_ccs_mode(struct intel_gt *gt);
#endif /* INTEL_GT_CCS_MODE_H */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
index 33cba406b569..a0290347938d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
@@ -12,6 +12,7 @@
#include "i915_drv.h"
#include "i915_sysfs.h"
#include "intel_gt.h"
+#include "intel_gt_ccs_mode.h"
#include "intel_gt_print.h"
#include "intel_gt_sysfs.h"
#include "intel_gt_sysfs_pm.h"
@@ -101,6 +102,7 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
goto exit_fail;
intel_gt_sysfs_pm_init(gt, >sysfs_gt);
+ intel_gt_sysfs_ccs_mode(gt);
return;
--
2.43.0
[PATCH 1/3] drm/i915/gt: Support fixed CCS mode
The CCS mode involves assigning CCS engines to slices depending
on the number of slices and the number of engines the user wishes
to set.
In this patch, the default CCS setting is established during the
initial GT settings. It involves assigning only one CCS to all
the slices.
Based on a patch by Chris Wilson
and Tejas Upadhyay .
Signed-off-by: Andi Shyti
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Niranjana Vishwanathapura
Cc: Tejas Upadhyay
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_gt.c | 6 ++
drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c | 81 +
drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h | 16
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 13
drivers/gpu/drm/i915/gt/intel_gt_types.h| 20 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
7 files changed, 139 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index e777686190ca..1dce15d6306b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -119,6 +119,7 @@ gt-y += \
gt/intel_ggtt_fencing.o \
gt/intel_gt.o \
gt/intel_gt_buffer_pool.o \
+ gt/intel_gt_ccs_mode.o \
gt/intel_gt_clock_utils.o \
gt/intel_gt_debugfs.o \
gt/intel_gt_engines_debugfs.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index a425db5ed3a2..e83c7b80c07a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -17,6 +17,7 @@
#include "intel_engine_regs.h"
#include "intel_ggtt_gmch.h"
#include "intel_gt.h"
+#include "intel_gt_ccs_mode.h"
#include "intel_gt_buffer_pool.h"
#include "intel_gt_clock_utils.h"
#include "intel_gt_debugfs.h"
@@ -47,6 +48,7 @@ void intel_gt_common_init_early(struct intel_gt *gt)
init_llist_head(>watchdog.list);
INIT_WORK(>watchdog.work, intel_gt_watchdog_work);
+ intel_gt_init_ccs_mode(gt);
intel_gt_init_buffer_pool(gt);
intel_gt_init_reset(gt);
intel_gt_init_requests(gt);
@@ -195,6 +197,9 @@ int intel_gt_init_hw(struct intel_gt *gt)
intel_gt_init_swizzling(gt);
+ /* Configure CCS mode */
+ intel_gt_apply_ccs_mode(gt);
+
/*
* At least 830 can leave some of the unused rings
* "active" (ie. head != tail) after resume which
@@ -860,6 +865,7 @@ void intel_gt_driver_late_release_all(struct
drm_i915_private *i915)
for_each_gt(gt, i915, id) {
intel_uc_driver_late_release(>uc);
+ intel_gt_fini_ccs_mode(gt);
intel_gt_fini_requests(gt);
intel_gt_fini_reset(gt);
intel_gt_fini_timelines(gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
new file mode 100644
index ..fab8a77bded2
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
@@ -0,0 +1,81 @@
+//SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#include "i915_drv.h"
+
+#include "intel_gt.h"
+#include "intel_gt_ccs_mode.h"
+#include "intel_gt_regs.h"
+#include "intel_gt_types.h"
+
+static void __intel_gt_apply_ccs_mode(struct intel_gt *gt)
+{
+ u32 mode = XEHP_CCS_MODE_CSLICE_0_3_MASK; /* disable all by default */
+ int num_slices = hweight32(CCS_MASK(gt));
+ int num_engines = gt->ccs.mode;
+ int slice = 0;
+ int i;
+
+ if (!num_engines)
+ return;
+
+ /*
+* Loop over all available slices and assign each a user engine.
+*
+* With 1 engine (ccs0):
+* slice 0, 1, 2, 3: ccs0
+*
+* With 2 engines (ccs0, ccs1):
+* slice 0, 2: ccs0
+* slice 1, 3: ccs1
+*
+* With 4 engines (ccs0, ccs1, ccs2, ccs3):
+* slice 0: ccs0
+* slice 1: ccs1
+* slice 2: ccs2
+* slice 3: ccs3
+*
+* Since the number of slices and the number of engines is
+* known, and we ensure that there is an exact multiple of
+* engines for slices, the double loop becomes a loop over each
+* slice.
+*/
+ for (i = num_slices / num_engines; i < num_slices; i++) {
+ struct intel_engine_cs *engine;
+ intel_engine_mask_t tmp;
+
+ for_each_engine_masked(engine, gt, ALL_CCS(gt), tmp) {
+ /* If a slice is fused off, leave disabled */
+ while (!(CCS_MASK(gt) & BIT(slice)))
+ slice++;
+
+ mode &= ~XEHP_CCS_MODE_CSLICE(slice,
XEHP_CCS_MODE_CSLICE_MASK);
+ mode |= XEHP_CCS_MODE_CSLICE(slice, engine->instance);
+
+ /* assign the next slice */
+
[PATCH 0/3] Disable dynamic load balancing and support fixed balancing
Hi, This series aims to disable the CCS hardware load balancing, as recommended by hardware directives in Wa_16016805146. In the meantime, we need to define and support a fixed CCS mode of balancing that can be configured by the user. Thanks, Andi Cc: Chris Wilson Cc: Joonas Lahtinen Cc: Niranjana Vishwanathapura Cc: Tejas Upadhyay Andi Shyti (3): drm/i915/gt: Support fixed CCS mode drm/i915/gt: Allow user to set up the CSS mode drm/i915/gt: Disable HW load balancing for CCS drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gt/intel_gt.c | 6 + drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c | 149 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h | 17 +++ drivers/gpu/drm/i915/gt/intel_gt_regs.h | 14 ++ drivers/gpu/drm/i915/gt/intel_gt_sysfs.c| 2 + drivers/gpu/drm/i915/gt/intel_gt_types.h| 20 +++ drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 + drivers/gpu/drm/i915/i915_drv.h | 2 + 9 files changed, 217 insertions(+) create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h -- 2.43.0
Re: [PATCH v5 0/8] iio: new DMABUF based API, v5
On Tue, 19 Dec 2023 18:50:01 +0100 Paul Cercueil wrote: > [V4 was: "iio: Add buffer write() support"][1] > > Hi Jonathan, > Hi Paul, > This is a respin of the V3 of my patchset that introduced a new > interface based on DMABUF objects [2]. Great to see this moving forwards. > > The V4 was a split of the patchset, to attempt to upstream buffer > write() support first. But since there is no current user upstream, it > was not merged. This V5 is about doing the opposite, and contains the > new DMABUF interface, without adding the buffer write() support. It can > already be used with the upstream adi-axi-adc driver. Seems like a sensible path in the short term. > > In user-space, Libiio uses it to transfer back and forth blocks of > samples between the hardware and the applications, without having to > copy the data. > > On a ZCU102 with a FMComms3 daughter board, running Libiio from the > pcercuei/dev-new-dmabuf-api branch [3], compiled with > WITH_LOCAL_DMABUF_API=OFF (so that it uses fileio): > sudo utils/iio_rwdev -b 4096 -B cf-ad9361-lpc > Throughput: 116 MiB/s > > Same hardware, with the DMABUF API (WITH_LOCAL_DMABUF_API=ON): > sudo utils/iio_rwdev -b 4096 -B cf-ad9361-lpc > Throughput: 475 MiB/s > > This benchmark only measures the speed at which the data can be fetched > to iio_rwdev's internal buffers, and does not actually try to read the > data (e.g. to pipe it to stdout). It shows that fetching the data is > more than 4x faster using the new interface. > > When actually reading the data, the performance difference isn't that > impressive (maybe because in case of DMABUF the data is not in cache): This needs a bit more investigation ideally. Perhaps perf counters can be used to establish that cache misses are the main different between dropping it on the floor and actually reading the data. > > WITH_LOCAL_DMABUF_API=OFF (so that it uses fileio): > sudo utils/iio_rwdev -b 4096 cf-ad9361-lpc | dd of=/dev/zero status=progress > 2446422528 bytes (2.4 GB, 2.3 GiB) copied, 22 s, 111 MB/s > > WITH_LOCAL_DMABUF_API=ON: > sudo utils/iio_rwdev -b 4096 cf-ad9361-lpc | dd of=/dev/zero status=progress > 2334388736 bytes (2.3 GB, 2.2 GiB) copied, 21 s, 114 MB/s > > One interesting thing to note is that fileio is (currently) actually > faster than the DMABUF interface if you increase a lot the buffer size. > My explanation is that the cache invalidation routine takes more and > more time the bigger the DMABUF gets. This is because the DMABUF is > backed by small-size pages, so a (e.g.) 64 MiB DMABUF is backed by up > to 16 thousands pages, that have to be invalidated one by one. This can > be addressed by using huge pages, but the udmabuf driver does not (yet) > support creating DMABUFs backed by huge pages. I'd imagine folios of reasonable size will help sort of a huge page as then hopefully it will use the flush by va range instructions if available. > > Anyway, the real benefits happen when the DMABUFs are either shared > between IIO devices, or between the IIO subsystem and another > filesystem. In that case, the DMABUFs are simply passed around drivers, > without the data being copied at any moment. > > We use that feature to transfer samples from our transceivers to USB, > using a DMABUF interface to FunctionFS [4]. > > This drastically increases the throughput, to about 274 MiB/s over a > USB3 link, vs. 127 MiB/s using IIO's fileio interface + write() to the > FunctionFS endpoints, for a lower CPU usage (0.85 vs. 0.65 load avg.). This is a nice example. Where are you with getting the patch merged? Overall, this code looks fine to me, though there are some parts that need review by other maintainers (e.g. Vinod for the dmaengine callback) and I'd like a 'looks fine' at least form those who know a lot more about dmabuf than I do. To actually make this useful sounds like either udmabuf needs some perf improvements, or there has to be an upstream case of sharing it without something else (e.g your functionfs patches). So what do we need to get in before the positive benefit becomes worth carrying this extra complexity? (which isn't too bad so I'm fine with a small benefit and promises of riches :) Jonathan > > Based on linux-next/next-20231219. > > Cheers, > -Paul > > [1] https://lore.kernel.org/all/20230807112113.47157-1-p...@crapouillou.net/ > [2] https://lore.kernel.org/all/20230403154800.215924-1-p...@crapouillou.net/ > [3] > https://github.com/analogdevicesinc/libiio/tree/pcercuei/dev-new-dmabuf-api > [4] https://lore.kernel.org/all/20230322092118.9213-1-p...@crapouillou.net/ > > --- > Changelog: > - [3/8]: Replace V3's dmaengine_prep_slave_dma_array() with a new > dmaengine_prep_slave_dma_vec(), which uses a new 'dma_vec' struct. > Note that at some point we will need to support cyclic transfers > using dmaengine_prep_slave_dma_vec(). Maybe with a new "flags" > parameter to the function? > > - [4/8]: Implement .device_prep_slave_dma_vec()
Re: [PATCH v5 8/8] Documentation: iio: Document high-speed DMABUF based API
On Tue, 19 Dec 2023 18:50:09 +0100 Paul Cercueil wrote: > Document the new DMABUF based API. > > Signed-off-by: Paul Cercueil One minor comment inline. > > --- > v2: - Explicitly state that the new interface is optional and is > not implemented by all drivers. > - The IOCTLs can now only be called on the buffer FD returned by > IIO_BUFFER_GET_FD_IOCTL. > - Move the page up a bit in the index since it is core stuff and not > driver-specific. > > v3: Update the documentation to reflect the new API. > > v5: Use description lists for the documentation of the three new IOCTLs > instead of abusing subsections. > --- > Documentation/iio/dmabuf_api.rst | 54 > Documentation/iio/index.rst | 2 ++ > 2 files changed, 56 insertions(+) > create mode 100644 Documentation/iio/dmabuf_api.rst > > diff --git a/Documentation/iio/dmabuf_api.rst > b/Documentation/iio/dmabuf_api.rst > new file mode 100644 > index ..1cd6cd51a582 > --- /dev/null > +++ b/Documentation/iio/dmabuf_api.rst > @@ -0,0 +1,54 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +=== > +High-speed DMABUF interface for IIO > +=== > + > +1. Overview > +=== > + > +The Industrial I/O subsystem supports access to buffers through a > +file-based interface, with read() and write() access calls through the > +IIO device's dev node. > + > +It additionally supports a DMABUF based interface, where the userspace > +can attach DMABUF objects (externally created) to a IIO buffer, and > +subsequently use them for data transfers. > + > +A userspace application can then use this interface to share DMABUF > +objects between several interfaces, allowing it to transfer data in a > +zero-copy fashion, for instance between IIO and the USB stack. > + > +The userspace application can also memory-map the DMABUF objects, and > +access the sample data directly. The advantage of doing this vs. the > +read() interface is that it avoids an extra copy of the data between the > +kernel and userspace. This is particularly useful for high-speed devices > +which produce several megabytes or even gigabytes of data per second. > +It does however increase the userspace-kernelspace synchronization > +overhead, as the DMA_BUF_SYNC_START and DMA_BUF_SYNC_END IOCTLs have to > +be used for data integrity. > + > +2. User API > +=== > + > +As part of this interface, three new IOCTLs have been added. These three > +IOCTLs have to be performed on the IIO buffer's file descriptor, > +obtained using the IIO_BUFFER_GET_FD_IOCTL() ioctl. I would call out that they do not work on the main file descriptor (which is arguably also a IIO buffer file descriptor). > + > + ``IIO_BUFFER_DMABUF_ATTACH_IOCTL(int)`` > +Attach the DMABUF object, identified by its file descriptor, to the > +IIO buffer. Returns zero on success, and a negative errno value on > +error. > + > + ``IIO_BUFFER_DMABUF_DETACH_IOCTL(int)`` > +Detach the given DMABUF object, identified by its file descriptor, > +from the IIO buffer. Returns zero on success, and a negative errno > +value on error. > + > +Note that closing the IIO buffer's file descriptor will > +automatically detach all previously attached DMABUF objects. > + > + ``IIO_BUFFER_DMABUF_ENQUEUE_IOCTL(struct iio_dmabuf *iio_dmabuf)`` > +Enqueue a previously attached DMABUF object to the buffer queue. > +Enqueued DMABUFs will be read from (if output buffer) or written to > +(if input buffer) as long as the buffer is enabled.
Re: [PATCH v5 7/8] iio: buffer-dmaengine: Support new DMABUF based userspace API
On Tue, 19 Dec 2023 18:50:08 +0100
Paul Cercueil wrote:
> Use the functions provided by the buffer-dma core to implement the
> DMABUF userspace API in the buffer-dmaengine IIO buffer implementation.
>
> Since we want to be able to transfer an arbitrary number of bytes and
> not necesarily the full DMABUF, the associated scatterlist is converted
> to an array of DMA addresses + lengths, which is then passed to
> dmaengine_prep_slave_dma_array().
>
> Signed-off-by: Paul Cercueil
One question inline. Otherwise looks fine to me.
J
>
> ---
> v3: Use the new dmaengine_prep_slave_dma_array(), and adapt the code to
> work with the new functions introduced in industrialio-buffer-dma.c.
>
> v5: - Use the new dmaengine_prep_slave_dma_vec().
> - Restrict to input buffers, since output buffers are not yet
> supported by IIO buffers.
> ---
> .../buffer/industrialio-buffer-dmaengine.c| 52 ---
> 1 file changed, 46 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> index 5f85ba38e6f6..825d76a24a67 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> @@ -64,15 +64,51 @@ static int iio_dmaengine_buffer_submit_block(struct
> iio_dma_buffer_queue *queue,
> struct dmaengine_buffer *dmaengine_buffer =
> iio_buffer_to_dmaengine_buffer(>buffer);
> struct dma_async_tx_descriptor *desc;
> + unsigned int i, nents;
> + struct scatterlist *sgl;
> + struct dma_vec *vecs;
> + size_t max_size;
> dma_cookie_t cookie;
> + size_t len_total;
>
> - block->bytes_used = min(block->size, dmaengine_buffer->max_size);
> - block->bytes_used = round_down(block->bytes_used,
> - dmaengine_buffer->align);
> + if (queue->buffer.direction != IIO_BUFFER_DIRECTION_IN) {
> + /* We do not yet support output buffers. */
> + return -EINVAL;
> + }
>
> - desc = dmaengine_prep_slave_single(dmaengine_buffer->chan,
> - block->phys_addr, block->bytes_used, DMA_DEV_TO_MEM,
> - DMA_PREP_INTERRUPT);
> + if (block->sg_table) {
> + sgl = block->sg_table->sgl;
> + nents = sg_nents_for_len(sgl, block->bytes_used);
Are we guaranteed the length in the sglist is enough? If not this
can return an error code.
> +
> + vecs = kmalloc_array(nents, sizeof(*vecs), GFP_KERNEL);
> + if (!vecs)
> + return -ENOMEM;
> +
> + len_total = block->bytes_used;
> +
> + for (i = 0; i < nents; i++) {
> + vecs[i].addr = sg_dma_address(sgl);
> + vecs[i].len = min(sg_dma_len(sgl), len_total);
> + len_total -= vecs[i].len;
> +
> + sgl = sg_next(sgl);
> + }
> +
> + desc = dmaengine_prep_slave_dma_vec(dmaengine_buffer->chan,
> + vecs, nents, DMA_DEV_TO_MEM,
> + DMA_PREP_INTERRUPT);
> + kfree(vecs);
> + } else {
> + max_size = min(block->size, dmaengine_buffer->max_size);
> + max_size = round_down(max_size, dmaengine_buffer->align);
> + block->bytes_used = max_size;
> +
> + desc = dmaengine_prep_slave_single(dmaengine_buffer->chan,
> +block->phys_addr,
> +block->bytes_used,
> +DMA_DEV_TO_MEM,
> +DMA_PREP_INTERRUPT);
> + }
> if (!desc)
> return -ENOMEM;
>
Re: [PATCH v5 6/8] iio: buffer-dma: Enable support for DMABUFs
On Tue, 19 Dec 2023 18:50:07 +0100
Paul Cercueil wrote:
> Implement iio_dma_buffer_attach_dmabuf(), iio_dma_buffer_detach_dmabuf()
> and iio_dma_buffer_transfer_dmabuf(), which can then be used by the IIO
> DMA buffer implementations.
>
> Signed-off-by: Paul Cercueil
>
Hi Paul,
A few comments in here. Mostly places where the cleanup.h guard() stuff
can simplify error paths.
Overall this looks reasonable to me.
Jonathan
> ---
> v3: Update code to provide the functions that will be used as callbacks
> for the new IOCTLs.
> ---
> drivers/iio/buffer/industrialio-buffer-dma.c | 157 +--
> include/linux/iio/buffer-dma.h | 26 +++
> 2 files changed, 170 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c
> b/drivers/iio/buffer/industrialio-buffer-dma.c
> index 5610ba67925e..adb64f975064 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dma.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dma.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -94,14 +95,24 @@ static void iio_buffer_block_release(struct kref *kref)
> {
> struct iio_dma_buffer_block *block = container_of(kref,
> struct iio_dma_buffer_block, kref);
> + struct iio_dma_buffer_queue *queue = block->queue;
>
> - WARN_ON(block->state != IIO_BLOCK_STATE_DEAD);
> + WARN_ON(block->fileio && block->state != IIO_BLOCK_STATE_DEAD);
>
> - dma_free_coherent(block->queue->dev, PAGE_ALIGN(block->size),
> - block->vaddr, block->phys_addr);
> + mutex_lock(>lock);
>
> - iio_buffer_put(>queue->buffer);
> + if (block->fileio) {
> + dma_free_coherent(queue->dev, PAGE_ALIGN(block->size),
> + block->vaddr, block->phys_addr);
> + queue->num_fileio_blocks--;
> + }
> +
> + queue->num_blocks--;
> kfree(block);
> +
> + mutex_unlock(>lock);
> +
> + iio_buffer_put(>buffer);
> }
>
> static void iio_buffer_block_get(struct iio_dma_buffer_block *block)
> @@ -163,7 +174,7 @@ static struct iio_dma_buffer_queue
> *iio_buffer_to_queue(struct iio_buffer *buf)
> }
>
> static struct iio_dma_buffer_block *iio_dma_buffer_alloc_block(
> - struct iio_dma_buffer_queue *queue, size_t size)
> + struct iio_dma_buffer_queue *queue, size_t size, bool fileio)
> {
> struct iio_dma_buffer_block *block;
>
> @@ -171,13 +182,16 @@ static struct iio_dma_buffer_block
> *iio_dma_buffer_alloc_block(
> if (!block)
> return NULL;
>
> - block->vaddr = dma_alloc_coherent(queue->dev, PAGE_ALIGN(size),
> - >phys_addr, GFP_KERNEL);
> - if (!block->vaddr) {
> - kfree(block);
> - return NULL;
> + if (fileio) {
> + block->vaddr = dma_alloc_coherent(queue->dev, PAGE_ALIGN(size),
> + >phys_addr,
> GFP_KERNEL);
> + if (!block->vaddr) {
> + kfree(block);
> + return NULL;
> + }
> }
>
> + block->fileio = fileio;
> block->size = size;
> block->state = IIO_BLOCK_STATE_DONE;
> block->queue = queue;
> @@ -186,6 +200,9 @@ static struct iio_dma_buffer_block
> *iio_dma_buffer_alloc_block(
>
> iio_buffer_get(>buffer);
>
> + queue->num_blocks++;
> + queue->num_fileio_blocks += fileio;
Adding a boolean is non intuitive.
if (fileio)
queue->num_fileio_blocks++;
probably easier to read and compiler should be able to figure out how to
optimise the condition away.
> +
> return block;
> }
>
> @@ -211,6 +228,9 @@ void iio_dma_buffer_block_done(struct
> iio_dma_buffer_block *block)
> _iio_dma_buffer_block_done(block);
> spin_unlock_irqrestore(>list_lock, flags);
>
> + if (!block->fileio)
> + iio_buffer_signal_dmabuf_done(block->attach, 0);
> +
> iio_buffer_block_put_atomic(block);
> wake_up_interruptible_poll(>buffer.pollq, EPOLLIN | EPOLLRDNORM);
> }
> @@ -237,10 +257,14 @@ void iio_dma_buffer_block_list_abort(struct
> iio_dma_buffer_queue *queue,
> list_del(>head);
> block->bytes_used = 0;
> _iio_dma_buffer_block_done(block);
> +
> + if (!block->fileio)
> + iio_buffer_signal_dmabuf_done(block->attach, -EINTR);
> iio_buffer_block_put_atomic(block);
> }
> spin_unlock_irqrestore(>list_lock, flags);
>
> + queue->fileio.enabled = false;
While this obviously doesn't need to be conditional if it can already be false
it might be easier to follow the code flow it if didn't check if we were doing
fileio or not before disabling it.
> wake_up_interruptible_poll(>buffer.pollq, EPOLLIN | EPOLLRDNORM);
> }
> EXPORT_SYMBOL_GPL(iio_dma_buffer_block_list_abort);
> @@ -261,6 +285,12 @@
Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
> Am 21.12.2023 um 09:58 schrieb Maxime Ripard : > > Cool, so what you're saying is that your plan is to support those GPUs > upstream in the imagination driver? Yes, I would like to see PowerVR Series 5 SGX supported upstream since there are still so many devices in the wild which could use it. The most advanced being the Pyra handheld gaming computer but there are omap4 based phones or other omap3/amm335x based devices. And the only reason the OpenPVRSGX group was founded (BTW not by me, I am just maintaining the code and running a mailing list because it was rejected to host it on vger.kernel.org), was to make that happen. From the GitHub description: This is about shaping existing GPL Linux kernel drivers for the PVR/SGX5 architecture so that they can become accepted into drivers/staging But nobody can currently tell if it can be integrated with the recently upstreamed Rogue driver (I wouldn't call that *the* imagination driver) or if it better stays a separate driver because the first would need touching closed user-space code and GPU firmware. And nobody knows who is capable and willing to work on it. It depends on access to (confidential) documentation and available time to make such a big task a rewarding project. And discussions like this one are not at all encouraging to even try. >> Now, IMHO all the pros and cons are on the table and the question is >> who makes a decision how to go. > > You haven't listed any pro so far, you're claiming that the one I raise > are irrelevant. I have listed some "pros" for "single file" but you apparently don't see them as such. I can't change that. The main argument is that a single file is simpler than two files duplicating parts, which are apparently the same (integration of PVR architectures into SoC doesn't differ very much: shared register block, DMA memory, clocks, resets etc.). Yours is that two files duplicating such common things is "more convenient". I just wonder for whom. But it seems as if the IMHO second best solution has already been chosen. So let it be. >> Then the currently-out-of-tree driver for the sgx5 can be reworked in >> less than half an hour without loosing functionality. > > Again, you're making it harder than it needs to be for no particular > reason other than the potential file name clash that can be addressed. What I want to avoid is a situation that upstream activities do not take the existing and working out-of-tree SGX driver into account and make porting (not even speaking of upstreaming) that driver more difficult than necessary and force device tree files to contain redundant information nobody will need and use. You can of course ignore experience and suggestions of people who have worked on an SGX driver for a while. But that is the reason why I participate in this discussion and raise my voice. Now, I am looking forward to a v2 of this patch. BR, Nikolaus
Re: [PATCH v5 3/8] dmaengine: Add API function dmaengine_prep_slave_dma_vec()
Hi Vinod,
Le jeudi 21 décembre 2023 à 20:44 +0530, Vinod Koul a écrit :
> On 19-12-23, 18:50, Paul Cercueil wrote:
> > This function can be used to initiate a scatter-gather DMA
> > transfer,
> > where the address and size of each segment is located in one entry
> > of
> > the dma_vec array.
> >
> > The major difference with dmaengine_prep_slave_sg() is that it
> > supports
> > specifying the lengths of each DMA transfer; as trying to override
> > the
> > length of the transfer with dmaengine_prep_slave_sg() is a very
> > tedious
> > process. The introduction of a new API function is also justified
> > by the
> > fact that scatterlists are on their way out.
> >
> > Note that dmaengine_prep_interleaved_dma() is not helpful either in
> > that
> > case, as it assumes that the address of each segment will be higher
> > than
> > the one of the previous segment, which we just cannot guarantee in
> > case
> > of a scatter-gather transfer.
> >
> > Signed-off-by: Paul Cercueil
> >
> > ---
> > v3: New patch
> >
> > v5: Replace with function dmaengine_prep_slave_dma_vec(), and
> > struct
> > 'dma_vec'.
> > Note that at some point we will need to support cyclic
> > transfers
> > using dmaengine_prep_slave_dma_vec(). Maybe with a new "flags"
> > parameter to the function?
> > ---
> > include/linux/dmaengine.h | 25 +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > index 3df70d6131c8..ee5931ddb42f 100644
> > --- a/include/linux/dmaengine.h
> > +++ b/include/linux/dmaengine.h
> > @@ -160,6 +160,16 @@ struct dma_interleaved_template {
> > struct data_chunk sgl[];
> > };
> >
> > +/**
> > + * struct dma_vec - DMA vector
> > + * @addr: Bus address of the start of the vector
> > + * @len: Length in bytes of the DMA vector
> > + */
> > +struct dma_vec {
> > + dma_addr_t addr;
> > + size_t len;
> > +};
>
> so you want to transfer multiple buffers, right? why not use
> dmaengine_prep_slave_sg(). If there is reason for not using that one?
Well I think I answer that in the commit message, don't I?
> Furthermore I missed replying to your email earlier on use of
> dmaengine_prep_interleaved_dma(), my apologies.
> That can be made to work for you as well. Please see the notes where
> icg
> can be ignored and it does not need icg value to be set
>
> Infact, interleaved api can be made to work in most of these cases I
> can
> think of...
So if I want to transfer 16 bytes from 0x10, then 16 bytes from 0x0,
then 16 bytes from 0x20, how should I configure the
dma_interleaved_template?
Cheers,
-Paul
> > +
> > /**
> > * enum dma_ctrl_flags - DMA flags to augment operation
> > preparation,
> > * control completion, and communicate status.
> > @@ -910,6 +920,10 @@ struct dma_device {
> > struct dma_async_tx_descriptor
> > *(*device_prep_dma_interrupt)(
> > struct dma_chan *chan, unsigned long flags);
> >
> > + struct dma_async_tx_descriptor
> > *(*device_prep_slave_dma_vec)(
> > + struct dma_chan *chan, const struct dma_vec *vecs,
> > + size_t nents, enum dma_transfer_direction
> > direction,
> > + unsigned long flags);
> > struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
> > struct dma_chan *chan, struct scatterlist *sgl,
> > unsigned int sg_len, enum dma_transfer_direction
> > direction,
> > @@ -972,6 +986,17 @@ static inline struct dma_async_tx_descriptor
> > *dmaengine_prep_slave_single(
> > dir, flags,
> > NULL);
> > }
> >
> > +static inline struct dma_async_tx_descriptor
> > *dmaengine_prep_slave_dma_vec(
> > + struct dma_chan *chan, const struct dma_vec *vecs, size_t
> > nents,
> > + enum dma_transfer_direction dir, unsigned long flags)
> > +{
> > + if (!chan || !chan->device || !chan->device-
> > >device_prep_slave_dma_vec)
> > + return NULL;
> > +
> > + return chan->device->device_prep_slave_dma_vec(chan, vecs,
> > nents,
> > + dir,
> > flags);
> > +}
> > +
> > static inline struct dma_async_tx_descriptor
> > *dmaengine_prep_slave_sg(
> > struct dma_chan *chan, struct scatterlist
> > *sgl, unsigned int sg_len,
> > enum dma_transfer_direction dir, unsigned long flags)
> > --
> > 2.43.0
>
Re: [PATCH v5 3/8] dmaengine: Add API function dmaengine_prep_slave_dma_vec()
On 19-12-23, 18:50, Paul Cercueil wrote:
> This function can be used to initiate a scatter-gather DMA transfer,
> where the address and size of each segment is located in one entry of
> the dma_vec array.
>
> The major difference with dmaengine_prep_slave_sg() is that it supports
> specifying the lengths of each DMA transfer; as trying to override the
> length of the transfer with dmaengine_prep_slave_sg() is a very tedious
> process. The introduction of a new API function is also justified by the
> fact that scatterlists are on their way out.
>
> Note that dmaengine_prep_interleaved_dma() is not helpful either in that
> case, as it assumes that the address of each segment will be higher than
> the one of the previous segment, which we just cannot guarantee in case
> of a scatter-gather transfer.
>
> Signed-off-by: Paul Cercueil
>
> ---
> v3: New patch
>
> v5: Replace with function dmaengine_prep_slave_dma_vec(), and struct
> 'dma_vec'.
> Note that at some point we will need to support cyclic transfers
> using dmaengine_prep_slave_dma_vec(). Maybe with a new "flags"
> parameter to the function?
> ---
> include/linux/dmaengine.h | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 3df70d6131c8..ee5931ddb42f 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -160,6 +160,16 @@ struct dma_interleaved_template {
> struct data_chunk sgl[];
> };
>
> +/**
> + * struct dma_vec - DMA vector
> + * @addr: Bus address of the start of the vector
> + * @len: Length in bytes of the DMA vector
> + */
> +struct dma_vec {
> + dma_addr_t addr;
> + size_t len;
> +};
so you want to transfer multiple buffers, right? why not use
dmaengine_prep_slave_sg(). If there is reason for not using that one?
Furthermore I missed replying to your email earlier on use of
dmaengine_prep_interleaved_dma(), my apologies.
That can be made to work for you as well. Please see the notes where icg
can be ignored and it does not need icg value to be set
Infact, interleaved api can be made to work in most of these cases I can
think of...
> +
> /**
> * enum dma_ctrl_flags - DMA flags to augment operation preparation,
> * control completion, and communicate status.
> @@ -910,6 +920,10 @@ struct dma_device {
> struct dma_async_tx_descriptor *(*device_prep_dma_interrupt)(
> struct dma_chan *chan, unsigned long flags);
>
> + struct dma_async_tx_descriptor *(*device_prep_slave_dma_vec)(
> + struct dma_chan *chan, const struct dma_vec *vecs,
> + size_t nents, enum dma_transfer_direction direction,
> + unsigned long flags);
> struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
> struct dma_chan *chan, struct scatterlist *sgl,
> unsigned int sg_len, enum dma_transfer_direction direction,
> @@ -972,6 +986,17 @@ static inline struct dma_async_tx_descriptor
> *dmaengine_prep_slave_single(
> dir, flags, NULL);
> }
>
> +static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_dma_vec(
> + struct dma_chan *chan, const struct dma_vec *vecs, size_t nents,
> + enum dma_transfer_direction dir, unsigned long flags)
> +{
> + if (!chan || !chan->device || !chan->device->device_prep_slave_dma_vec)
> + return NULL;
> +
> + return chan->device->device_prep_slave_dma_vec(chan, vecs, nents,
> +dir, flags);
> +}
> +
> static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_sg(
> struct dma_chan *chan, struct scatterlist *sgl, unsigned int sg_len,
> enum dma_transfer_direction dir, unsigned long flags)
> --
> 2.43.0
--
~Vinod
Re: [v5,43/44] drm/sun4i: hdmi: Consolidate atomic_check and mode_valid
Hi, On 2023/12/7 23:50, Maxime Ripard wrote: atomic_check and mode_valid do not check for the same things which can lead to surprising result if the userspace commits a mode that didn't go through mode_valid. Let's merge the two implementations into a function called by both. Signed-off-by: Maxime Ripard Acked-by: Sui Jingfeng
Re: [PATCH RESEND v1 2/8] dt-bindings: display: add dt-bindings for STM32 LVDS device
On Thu, 21 Dec 2023 13:43:33 +0100, Raphael Gallais-Pou wrote: > Add dt-binding file for "st,stm32-lvds" compatible. > > Signed-off-by: Raphael Gallais-Pou > --- > .../bindings/display/st,stm32-lvds.yaml | 114 ++ > 1 file changed, 114 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/st,stm32-lvds.yaml > 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: Documentation/devicetree/bindings/display/st,stm32-lvds.example.dts:18:18: fatal error: dt-bindings/bus/stm32mp25_sys_bus.h: No such file or directory 18 | #include | ^ compilation terminated. make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/display/st,stm32-lvds.example.dtb] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1424: dt_binding_check] Error 2 make: *** [Makefile:234: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231221124339.420119-3-raphael.gallais-...@foss.st.com 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: [v5,41/44] drm/sun4i: hdmi: Move mode_set into enable
Hi, On 2023/12/7 23:50, Maxime Ripard wrote: We're not doing anything special in atomic_mode_set so we can simply merge it into atomic_enable. Signed-off-by: Maxime Ripard Acked-by: Sui Jingfeng
Re: [v5,40/44] drm/sun4i: hdmi: Convert encoder to atomic
Hi, LGTM, On 2023/12/7 23:50, Maxime Ripard wrote: The sun4i_hdmi driver still uses the non-atomic variants of the encoder hooks, so let's convert to their atomic equivalents. Signed-off-by: Maxime Ripard Acked-by: Sui Jingfeng
Re: [PATCH] drm/ci: uprev mesa version: fix kdl commit fetch
Hi, On 14/12/23 17:50, Helen Koike wrote: On 14/12/2023 05:00, Dmitry Baryshkov wrote: On Tue, 12 Dec 2023 at 18:04, Vignesh Raman wrote: build-kdl.sh was doing a `clone --depth 1` of the default branch, then checking out a commit that might not be the latest of that branch, resulting in container build error. https://gitlab.freedesktop.org/mesa/mesa/-/commit/5efa4d56 fixes kdl commit fetch issue. Uprev mesa in drm-ci to fix this. This commit also updates the kernel tag and adds .never-post-merge-rules due to the mesa uprev. Tested-by: Abhinav Kumar Signed-off-by: Vignesh Raman Reviewed-by: Dmitry Baryshkov Acked-by: Helen Koike With this mesa uprev, the virtio-gpu jobs are not getting created and other jobs are not affected. The issue is identified and fixed, will be sending a v2. Regards, Vignesh
[PATCH] drm/nouveau: svm: fix kvcalloc() arguments order
When compiling with gcc version 14.0.0 20231220 (experimental) and W=1, I've noticed the following warning: drivers/gpu/drm/nouveau/nouveau_svm.c: In function 'nouveau_svm_fault_buffer_ctor': drivers/gpu/drm/nouveau/nouveau_svm.c:1014:40: warning: 'kvcalloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args] 1014 | buffer->fault = kvcalloc(sizeof(*buffer->fault), buffer->entries, GFP_KERNEL); |^ Since 'n' and 'size' arguments of 'kvcalloc()' are multiplied to calculate the final size, their actual order doesn't affect the result and so this is not a bug. But it's still worth to fix it. Signed-off-by: Dmitry Antipov --- drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c b/drivers/gpu/drm/nouveau/nouveau_svm.c index cc03e0c22ff3..5e4565c5011a 100644 --- a/drivers/gpu/drm/nouveau/nouveau_svm.c +++ b/drivers/gpu/drm/nouveau/nouveau_svm.c @@ -1011,7 +1011,7 @@ nouveau_svm_fault_buffer_ctor(struct nouveau_svm *svm, s32 oclass, int id) if (ret) return ret; - buffer->fault = kvcalloc(sizeof(*buffer->fault), buffer->entries, GFP_KERNEL); + buffer->fault = kvcalloc(buffer->entries, sizeof(*buffer->fault), GFP_KERNEL); if (!buffer->fault) return -ENOMEM; -- 2.43.0
Re: [PATCH RESEND v1 4/8] drm/stm: ltdc: implement bus clock
On Thu, 21 Dec 2023 at 14:45, Raphael Gallais-Pou
wrote:
>
> From: Yannick Fertre
>
> The latest hardware version of the LTDC presents the addition of a bus
> clock, which contains the global configuration registers and the interrupt
> register.
>
> Signed-off-by: Yannick Fertre
> ---
> drivers/gpu/drm/stm/ltdc.c | 8
> drivers/gpu/drm/stm/ltdc.h | 1 +
> 2 files changed, 9 insertions(+)
I might be missing something, but I don't see this clock being set
(compare this patch to the patch 5/8)
>
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 5576fdae4962..67064f47a4cb 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -1896,6 +1896,8 @@ void ltdc_suspend(struct drm_device *ddev)
>
> DRM_DEBUG_DRIVER("\n");
> clk_disable_unprepare(ldev->pixel_clk);
> + if (ldev->bus_clk)
> + clk_disable_unprepare(ldev->bus_clk);
> }
>
> int ltdc_resume(struct drm_device *ddev)
> @@ -1910,6 +1912,12 @@ int ltdc_resume(struct drm_device *ddev)
> DRM_ERROR("failed to enable pixel clock (%d)\n", ret);
> return ret;
> }
> + if (ldev->bus_clk) {
> + if (clk_prepare_enable(ldev->bus_clk)) {
> + DRM_ERROR("Unable to prepare bus clock\n");
> + return -ENODEV;
> + }
> + }
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
> index 9d488043ffdb..155d8e4a7c6b 100644
> --- a/drivers/gpu/drm/stm/ltdc.h
> +++ b/drivers/gpu/drm/stm/ltdc.h
> @@ -44,6 +44,7 @@ struct ltdc_device {
> void __iomem *regs;
> struct regmap *regmap;
> struct clk *pixel_clk; /* lcd pixel clock */
> + struct clk *bus_clk;/* bus clock */
> struct mutex err_lock; /* protecting error_status */
> struct ltdc_caps caps;
> u32 irq_status;
> --
> 2.25.1
>
--
With best wishes
Dmitry
Re: [PATCH 00/11] Introduce drm evictable lru
Hi Oak, Christian On 11/2/23 05:32, Oak Zeng wrote: We plan to implement xe driver's shared virtual memory manager (aka SVM) without buffer object concept. This means we won't build our shared virtual memory manager upon TTM infrastructure like amdgpu does. Even though this approach is more efficient, it does create a problem for memory eviction when there is memory pressure: memory allocated by SVM and memory allocated by TTM should be able to mutually evict from each other. TTM's resource manager maintains a LRU list for each memory type and this list is used to pick up the memory eviction victim. Since we don't use TTM for SVM implementation, SVM allocated memory can't be added to TTM resource manager's LRU list. Thus SVM allocated memory and TTM allocated memory are not mutually evictable. See more discussion on this topic here: https://www.spinics.net/lists/dri-devel/msg410740.html This series solve this problem by creating a shared LRU list b/t SVM and TTM, or any other resource manager. The basic idea is, abstract a drm_lru_entity structure which is supposed to be embedded in ttm_resource structure, or any other resource manager. The resource LRU list is a list of drm_lru_entity. drm_lru_entity has eviction function pointers which can be used to call back drivers' specific eviction function to evict a memory resource. Introduce global drm_lru_manager to struct drm_device to manage LRU lists. Each memory type or memory region can have a LRU list. TTM resource manager's LRU list functions including bulk move functions are moved to drm lru manager. drm lru manager provides a evict_first function to evict the first memory resource from LRU list. This function can be called from TTM, SVM or any other resource manager, so all the memory allocated in the drm sub-system can be mutually evicted. The lru_lock is also moved from struct ttm_device to struct drm_device. Opens: 1) memory accounting: currently the ttm resource manager's memory accounting functions is kept at ttm resource manager. Since memory accounting should be cross TTM and SVM, it should be ideally in the drm lru manager layer. This will be polished in the future. 2) eviction callback function interface: The current eviction function interface is designed to meet TTM memory eviction requirements. When SVM is in the picture, this interface need to be futher tunned to meet SVM requirement also. This series is not tested and it is only compiled for xe driver. Some minor changes are needed for other driver such as amdgpu, nouveau etc. I intended to send this out as a request for comment series to get some early feedback, to see whether this is the right direction to go. I will futher polish this series after a direction is agreed. Oak Zeng (11): drm/ttm: re-parameter ttm_device_init drm: move lru_lock from ttm_device to drm_device drm: introduce drm evictable LRU drm: Add evict function pointer to drm lru entity drm: Replace ttm macros with drm macros drm/ttm: Set lru manager to ttm resource manager drm/ttm: re-parameterize a few ttm functions drm: Initialize drm lru manager drm/ttm: Use drm LRU manager iterator drm/ttm: Implement ttm memory evict functions drm/ttm: Write ttm functions using drm lru manager functions drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 6 + .../gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 6 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 10 +- drivers/gpu/drm/drm_drv.c | 1 + drivers/gpu/drm/drm_evictable_lru.c | 266 ++ drivers/gpu/drm/drm_gem_vram_helper.c | 10 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 +- drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 10 + drivers/gpu/drm/i915/intel_region_ttm.c | 4 +- drivers/gpu/drm/i915/selftests/mock_region.c | 2 +- drivers/gpu/drm/loongson/lsdc_ttm.c | 10 +- drivers/gpu/drm/nouveau/nouveau_ttm.c | 22 +- drivers/gpu/drm/qxl/qxl_ttm.c | 6 +- drivers/gpu/drm/radeon/radeon_ttm.c | 10 +- drivers/gpu/drm/ttm/tests/ttm_device_test.c | 2 +- drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 2 +- drivers/gpu/drm/ttm/ttm_bo.c | 247 drivers/gpu/drm/ttm/ttm_bo_util.c | 20 +- drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +- drivers/gpu/drm/ttm/ttm_device.c | 55 ++-- drivers/gpu/drm/ttm/ttm_module.h | 3 +- drivers/gpu/drm/ttm/ttm_range_manager.c | 14 +- drivers/gpu/drm/ttm/ttm_resource.c| 242 +++- drivers/gpu/drm/ttm/ttm_sys_manager.c | 8 +- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 2 +-
[PULL] drm-intel-fixes
Hi Dave & Sima - A bit more than I'd like at this stage, but next week will be quiet. drm-intel-fixes-2023-12-21: drm/i915 fixes for v6.7-rc7: - Fix state readout and check for DSC and bigjoiner combo - Fix a potential integer overflow - Reject async flips with bigjoiner - Fix MTL HDMI/DP PLL clock selection - Fix various issues by disabling pipe DMC events BR, Jani. The following changes since commit ceb6a6f023fd3e8b07761ed900352ef574010bcb: Linux 6.7-rc6 (2023-12-17 15:19:28 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-12-21 for you to fetch changes up to 49e0a85ec3441edc6c77aa40206d6e5ee4597efc: drm/i915/dmc: Don't enable any pipe DMC events (2023-12-18 15:29:23 +0200) drm/i915 fixes for v6.7-rc7: - Fix state readout and check for DSC and bigjoiner combo - Fix a potential integer overflow - Reject async flips with bigjoiner - Fix MTL HDMI/DP PLL clock selection - Fix various issues by disabling pipe DMC events Ankit Nautiyal (1): drm/i915/display: Get bigjoiner config before dsc config during readout Imre Deak (1): drm/i915/mtl: Fix HDMI/DP PLL clock selection Karthik Poosa (1): drm/i915/hwmon: Fix static analysis tool reported issues Ville Syrjälä (2): drm/i915: Reject async flips with bigjoiner drm/i915/dmc: Don't enable any pipe DMC events drivers/gpu/drm/i915/display/intel_cx0_phy.c | 3 +- drivers/gpu/drm/i915/display/intel_display.c | 13 - drivers/gpu/drm/i915/display/intel_dmc.c | 43 ++-- drivers/gpu/drm/i915/i915_hwmon.c| 4 +-- 4 files changed, 57 insertions(+), 6 deletions(-) -- Jani Nikula, Intel
[PATCH RESEND v1 8/8] arm64: dts: st: add display support on stm32mp257f-ev
This patch enables the following IPs on stm32mp257f-ev :
* LTDC
* LVDS
* WSVGA LVDS panel (1024x600)
* Panel backlight
* Ilitek touchescreen
Signed-off-by: Raphael Gallais-Pou
---
arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 79 ++
1 file changed, 79 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
index 0ea8e69bfb3d..ca2da988d91c 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
@@ -29,6 +29,43 @@ memory@8000 {
reg = <0x0 0x8000 0x1 0x0>;
};
+ panel_lvds: panel-lvds {
+ compatible = "edt,etml0700z9ndha", "panel-lvds";
+ enable-gpios = < 15 GPIO_ACTIVE_HIGH>;
+ backlight = <_lvds_backlight>;
+ status = "okay";
+
+ width-mm = <156>;
+ height-mm = <92>;
+ data-mapping = "vesa-24";
+
+ panel-timing {
+ clock-frequency = <5400>;
+ hactive = <1024>;
+ vactive = <600>;
+ hfront-porch = <150>;
+ hback-porch = <150>;
+ hsync-len = <21>;
+ vfront-porch = <24>;
+ vback-porch = <24>;
+ vsync-len = <21>;
+ };
+
+ port {
+ lvds_panel_in: endpoint {
+ remote-endpoint = <_out0>;
+ };
+ };
+ };
+
+ panel_lvds_backlight: panel-lvds-backlight {
+ compatible = "gpio-backlight";
+ gpios = < 5 GPIO_ACTIVE_HIGH>;
+ default-on;
+ default-brightness-level = <0>;
+ status = "okay";
+ };
+
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
@@ -63,6 +100,15 @@ {
i2c-scl-falling-time-ns = <13>;
clock-frequency = <40>;
status = "okay";
+
+ ili2511: ili2511@41 {
+ compatible = "ilitek,ili251x";
+ reg = <0x41>;
+ interrupt-parent = <>;
+ interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = < 14 GPIO_ACTIVE_LOW>;
+ status = "okay";
+ };
};
{
@@ -75,6 +121,39 @@ {
status = "disabled";
};
+ {
+ status = "okay";
+
+ port {
+ ltdc_ep0_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds_in: endpoint {
+ remote-endpoint = <_ep0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ lvds_out0: endpoint {
+ remote-endpoint = <_panel_in>;
+ };
+ };
+ };
+};
+
{
pinctrl-names = "default", "opendrain", "sleep";
pinctrl-0 = <_b4_pins_a>;
--
2.25.1
[PATCH RESEND v1 5/8] drm/stm: ltdc: add lvds pixel clock
The STM32MP25x display subsystem presents a mux which feeds the loopback
pixel clock of the current bridge in use into the LTDC. This mux is only
accessible through sysconfig registers which is not yet available in the
STM32MP25x common clock framework.
While waiting for a complete update of the clock framework, this would
allow to use the LVDS.
Signed-off-by: Raphael Gallais-Pou
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/ltdc.c | 18 ++
drivers/gpu/drm/stm/ltdc.h | 1 +
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 67064f47a4cb..1cf9f16e56cc 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -838,6 +838,12 @@ ltdc_crtc_mode_valid(struct drm_crtc *crtc,
int target_max = target + CLK_TOLERANCE_HZ;
int result;
+ if (ldev->lvds_clk) {
+ result = clk_round_rate(ldev->lvds_clk, target);
+ DRM_DEBUG_DRIVER("lvds pixclk rate target %d, available %d\n",
+target, result);
+ }
+
result = clk_round_rate(ldev->pixel_clk, target);
DRM_DEBUG_DRIVER("clk rate target %d, available %d\n", target, result);
@@ -1898,6 +1904,8 @@ void ltdc_suspend(struct drm_device *ddev)
clk_disable_unprepare(ldev->pixel_clk);
if (ldev->bus_clk)
clk_disable_unprepare(ldev->bus_clk);
+ if (ldev->lvds_clk)
+ clk_disable_unprepare(ldev->lvds_clk);
}
int ltdc_resume(struct drm_device *ddev)
@@ -1918,6 +1926,12 @@ int ltdc_resume(struct drm_device *ddev)
return -ENODEV;
}
}
+ if (ldev->lvds_clk) {
+ if (clk_prepare_enable(ldev->lvds_clk)) {
+ DRM_ERROR("Unable to prepare lvds clock\n");
+ return -ENODEV;
+ }
+ }
return 0;
}
@@ -1989,6 +2003,10 @@ int ltdc_load(struct drm_device *ddev)
}
}
+ ldev->lvds_clk = devm_clk_get(dev, "lvds");
+ if (IS_ERR(ldev->lvds_clk))
+ ldev->lvds_clk = NULL;
+
rstc = devm_reset_control_get_exclusive(dev, NULL);
mutex_init(>err_lock);
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index 155d8e4a7c6b..662650a0fae2 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -44,6 +44,7 @@ struct ltdc_device {
void __iomem *regs;
struct regmap *regmap;
struct clk *pixel_clk; /* lcd pixel clock */
+ struct clk *lvds_clk; /* lvds pixel clock */
struct clk *bus_clk;/* bus clock */
struct mutex err_lock; /* protecting error_status */
struct ltdc_caps caps;
--
2.25.1
[PATCH RESEND v1 6/8] arm64: dts: st: add ltdc support on stm32mp251
The LCD-TFT Display Controller (LTDC) handles display composition,
scaling and rotation. It provides a parallel digital RGB flow to be used
by display interfaces.
Signed-off-by: Raphael Gallais-Pou
---
arch/arm64/boot/dts/st/stm32mp251.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi
b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 93bc8a8908ce..064077e98dfd 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -212,6 +212,18 @@ i2c8: i2c@4604 {
status = "disabled";
};
+ ltdc: display-controller@4801 {
+ compatible = "st,stm32-ltdc";
+ reg = <0x4801 0x400>;
+ st,syscon = <>;
+ interrupts = ,
+ ;
+ clocks = < CK_BUS_LTDC>, < CK_KER_LTDC>;
+ clock-names = "bus", "lcd";
+ resets = < LTDC_R>;
+ status = "disabled";
+ };
+
sdmmc1: mmc@4822 {
compatible = "st,stm32mp25-sdmmc2",
"arm,pl18x", "arm,primecell";
arm,primecell-periphid = <0x00353180>;
--
2.25.1
[PATCH RESEND v1 7/8] arm64: dts: st: add lvds support on stm32mp253
This patch adds LVDS support on stm32mp253. The LVDS is used on
STM32MP2 as a display interface. LVDS PLL clock is binded to the LTDC
input clock.
Signed-off-by: Raphael Gallais-Pou
---
arch/arm64/boot/dts/st/stm32mp253.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp253.dtsi
b/arch/arm64/boot/dts/st/stm32mp253.dtsi
index af48e82efe8a..bcc605e502de 100644
--- a/arch/arm64/boot/dts/st/stm32mp253.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp253.dtsi
@@ -21,3 +21,20 @@ arm-pmu {
interrupt-affinity = <>, <>;
};
};
+
+ {
+ clocks = < CK_BUS_LTDC>, < CK_KER_LTDC>, < 0>;
+ clock-names = "bus", "lcd", "lvds";
+};
+
+ {
+ lvds: lvds@4806 {
+ #clock-cells = <0>;
+ compatible = "st,stm32-lvds";
+ reg = <0x4806 0x2000>;
+ clocks = < CK_BUS_LVDS>, < CK_KER_LVDSPHY>;
+ clock-names = "pclk", "ref";
+ resets = < LVDS_R>;
+ status = "disabled";
+ };
+};
--
2.25.1
[PATCH RESEND v1 4/8] drm/stm: ltdc: implement bus clock
From: Yannick Fertre
The latest hardware version of the LTDC presents the addition of a bus
clock, which contains the global configuration registers and the interrupt
register.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/ltdc.c | 8
drivers/gpu/drm/stm/ltdc.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 5576fdae4962..67064f47a4cb 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1896,6 +1896,8 @@ void ltdc_suspend(struct drm_device *ddev)
DRM_DEBUG_DRIVER("\n");
clk_disable_unprepare(ldev->pixel_clk);
+ if (ldev->bus_clk)
+ clk_disable_unprepare(ldev->bus_clk);
}
int ltdc_resume(struct drm_device *ddev)
@@ -1910,6 +1912,12 @@ int ltdc_resume(struct drm_device *ddev)
DRM_ERROR("failed to enable pixel clock (%d)\n", ret);
return ret;
}
+ if (ldev->bus_clk) {
+ if (clk_prepare_enable(ldev->bus_clk)) {
+ DRM_ERROR("Unable to prepare bus clock\n");
+ return -ENODEV;
+ }
+ }
return 0;
}
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index 9d488043ffdb..155d8e4a7c6b 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -44,6 +44,7 @@ struct ltdc_device {
void __iomem *regs;
struct regmap *regmap;
struct clk *pixel_clk; /* lcd pixel clock */
+ struct clk *bus_clk;/* bus clock */
struct mutex err_lock; /* protecting error_status */
struct ltdc_caps caps;
u32 irq_status;
--
2.25.1
[PATCH RESEND v1 3/8] drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver
The Low-Voltage Differential Signaling (LVDS) Display Interface Transmitter handles the LVDS protocol: it maps the pixels received from the upstream Pixel-DMA LCD-TFT Display Controller (LTDC) onto the LVDS PHY. It regroups three sub blocks: * LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps its input pixels onto the data lanes of the PHY * LVDS PHY: parallelize the data and drives the LVDS data lanes * LVDS wrapper: handles top-level settings The LVDS controller driver supports the following high-level features: * FDP-Link-I and OpenLDI (v0.95) protocols * Single-Link or Dual-Link operation * Single-Display or Double-Display (with the same content duplicated on both) * Flexible Bit-Mapping, including JEIDA and VESA * RGB888 or RGB666 output * Synchronous design, with one input pixel per clock cycle Signed-off-by: Raphael Gallais-Pou --- drivers/gpu/drm/stm/Kconfig | 11 + drivers/gpu/drm/stm/Makefile |2 + drivers/gpu/drm/stm/lvds.c | 1226 ++ 3 files changed, 1239 insertions(+) create mode 100644 drivers/gpu/drm/stm/lvds.c diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig index fa49cde43bb2..9627814d027c 100644 --- a/drivers/gpu/drm/stm/Kconfig +++ b/drivers/gpu/drm/stm/Kconfig @@ -20,3 +20,14 @@ config DRM_STM_DSI select DRM_DW_MIPI_DSI help Choose this option for MIPI DSI support on STMicroelectronics SoC. + +config DRM_STM_LVDS + tristate "STMicroelectronics LVDS Display Interface Transmitter DRM driver" + depends on DRM_STM + help + Enable support for LVDS encoders on STMicroelectronics SoC. + The STM LVDS is a bridge which serialize pixel stream onto + a LVDS protocol. + + To compile this driver as a module, choose M here: the module will be + called lvds. diff --git a/drivers/gpu/drm/stm/Makefile b/drivers/gpu/drm/stm/Makefile index 4df5caf01f35..ad740d6175a6 100644 --- a/drivers/gpu/drm/stm/Makefile +++ b/drivers/gpu/drm/stm/Makefile @@ -5,4 +5,6 @@ stm-drm-y := \ obj-$(CONFIG_DRM_STM_DSI) += dw_mipi_dsi-stm.o +obj-$(CONFIG_DRM_STM_LVDS) += lvds.o + obj-$(CONFIG_DRM_STM) += stm-drm.o diff --git a/drivers/gpu/drm/stm/lvds.c b/drivers/gpu/drm/stm/lvds.c new file mode 100644 index ..f01490939ab5 --- /dev/null +++ b/drivers/gpu/drm/stm/lvds.c @@ -0,0 +1,1226 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (C) 2023, STMicroelectronics - All Rights Reserved + * Author(s): Rapha??l GALLAIS-POU for STMicroelectronics. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +/* LVDS Host registers */ +#define LVDS_CR0x /* configuration register */ +#define LVDS_DMLCR00x0004 /* data mapping lsb configuration register 0 */ +#define LVDS_DMMCR00x0008 /* data mapping msb configuration register 0 */ +#define LVDS_DMLCR10x000C /* data mapping lsb configuration register 1 */ +#define LVDS_DMMCR10x0010 /* data mapping msb configuration register 1 */ +#define LVDS_DMLCR20x0014 /* data mapping lsb configuration register 2 */ +#define LVDS_DMMCR20x0018 /* data mapping msb configuration register 2 */ +#define LVDS_DMLCR30x001C /* data mapping lsb configuration register 3 */ +#define LVDS_DMMCR30x0020 /* data mapping msb configuration register 3 */ +#define LVDS_DMLCR40x0024 /* data mapping lsb configuration register 4 */ +#define LVDS_DMMCR40x0028 /* data mapping msb configuration register 4 */ +#define LVDS_CDL1CR0x002C /* channel distrib link 1 configuration register */ +#define LVDS_CDL2CR0x0030 /* channel distrib link 2 configuration register */ + +#define CDL1CR_DEFAULT 0x04321 /* Default value for CDL1CR */ +#define CDL2CR_DEFAULT 0x59876 /* Default value for CDL2CR */ + +#define LVDS_DMLCR(bit)(LVDS_DMLCR0 + 0x8 * (bit)) +#define LVDS_DMMCR(bit)(LVDS_DMMCR0 + 0x8 * (bit)) + +/* LVDS Wrapper registers */ +#define LVDS_WCLKCR0x11B0 /* Wrapper clock control register */ + +#define LVDS_HWCFGR0x1FF0 /* HW configuration register*/ +#define LVDS_VERR 0x1FF4 /* Version register */ +#define LVDS_IPIDR 0x1FF8 /* Identification register */ +#define LVDS_SIDR 0x1FFC /* Size Identification register */ + +/* Bitfield description */ +#define CR_LVDSEN BIT(0) /* LVDS PHY Enable */ +#define CR_HSPOL BIT(1) /* Horizontal Synchronization Polarity */ +#define CR_VSPOL BIT(2) /* Vertical Synchronization Polarity */ +#define CR_DEPOL BIT(3) /* Data Enable Polarity */ +#define CR_CI BIT(4) /* Control Internal (software controlled bit) */ +#define CR_LKMOD BIT(5) /* Link Mode, for both Links */ +#define CR_LKPHA BIT(6) /* Link Phase, for
[PATCH RESEND v1 0/8] Introduce STM32 LVDS driver
This serie introduces a new DRM bridge driver for STM32MP257 platforms based on Arm Cortex-35. It also adds an instance in the device-tree and handle the inclusion of the driver within the DRM framework. First patch adds a new panel compatible in the panel-lvds driver, which is used by default on the STM32MP257. Raphael Gallais-Pou (7): dt-bindings: panel: lvds: Append edt,etml0700z9ndha in panel-lvds dt-bindings: display: add dt-bindings for STM32 LVDS device drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver drm/stm: ltdc: add lvds pixel clock arm64: dts: st: add ltdc support on stm32mp251 arm64: dts: st: add lvds support on stm32mp253 arm64: dts: st: add display support on stm32mp257f-ev Yannick Fertre (1): drm/stm: ltdc: implement bus clock .../bindings/display/panel/panel-lvds.yaml|2 + .../bindings/display/st,stm32-lvds.yaml | 114 ++ arch/arm64/boot/dts/st/stm32mp251.dtsi| 12 + arch/arm64/boot/dts/st/stm32mp253.dtsi| 17 + arch/arm64/boot/dts/st/stm32mp257f-ev1.dts| 79 ++ drivers/gpu/drm/stm/Kconfig | 11 + drivers/gpu/drm/stm/Makefile |2 + drivers/gpu/drm/stm/ltdc.c| 26 + drivers/gpu/drm/stm/ltdc.h|2 + drivers/gpu/drm/stm/lvds.c| 1226 + 10 files changed, 1491 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/st,stm32-lvds.yaml create mode 100644 drivers/gpu/drm/stm/lvds.c -- 2.25.1
[PATCH RESEND v1 2/8] dt-bindings: display: add dt-bindings for STM32 LVDS device
Add dt-binding file for "st,stm32-lvds" compatible.
Signed-off-by: Raphael Gallais-Pou
---
.../bindings/display/st,stm32-lvds.yaml | 114 ++
1 file changed, 114 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
diff --git a/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
b/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
new file mode 100644
index ..d72c9088133c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/st,stm32-lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 LVDS Display Interface Transmitter
+
+maintainers:
+ - Raphael Gallais-Pou
+ - Yannick Fertre
+
+description: |
+ The STMicroelectronics STM32 LVDS Display Interface Transmitter handles the
+ LVDS protocol: it maps the pixels received from the upstream Pixel-DMA (LTDC)
+ onto the LVDS PHY.
+
+ It regroups three sub blocks:
+- LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps its input
+ pixels onto the data lanes of the PHY
+- LVDS PHY: parallelize the data and drives the LVDS data lanes
+- LVDS wrapper: handles top-level settings
+
+ The LVDS controller driver supports the following high-level features:
+- FDP-Link-I and OpenLDI (v0.95) protocols
+- Single-Link or Dual-Link operation
+- Single-Display or Double-Display (with the same content duplicated on
both)
+- Flexible Bit-Mapping, including JEIDA and VESA
+- RGB888 or RGB666 output
+- Synchronous design, with one input pixel per clock cycle
+
+properties:
+ "#clock-cells":
+const: 0
+
+ compatible:
+const: st,stm32-lvds
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: APB peripheral clock
+ - description: Reference clock for the internal PLL
+
+ clock-names:
+items:
+ - const: pclk
+ - const: ref
+
+ resets:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: |
+ LVDS input port node, connected to the LTDC RGB output port.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: |
+ LVDS output port node, connected to a panel or bridge input port.
+
+required:
+ - "#clock-cells"
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+
+lvds: lvds@4806 {
+#clock-cells = <0>;
+compatible = "st,stm32-lvds";
+reg = <0x4806 0x2000>;
+clocks = < CK_BUS_LVDS>, < CK_KER_LVDSPHY>;
+clock-names = "pclk", "ref";
+resets = < LVDS_R>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+lvds_in: endpoint {
+ remote-endpoint = <_ep1_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+lvds_out0: endpoint {
+ remote-endpoint = <_panel_in>;
+};
+};
+};
+};
+
+...
--
2.25.1
[PATCH RESEND v1 1/8] dt-bindings: panel: lvds: Append edt, etml0700z9ndha in panel-lvds
List EDT ETML0700Z9NDHA in the LVDS panel enumeration. Signed-off-by: Raphael Gallais-Pou --- Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml index 9f1016551e0b..3fb24393529c 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml @@ -42,6 +42,8 @@ properties: - auo,b101ew05 # Chunghwa Picture Tubes Ltd. 7" WXGA (800x1280) TFT LCD LVDS panel - chunghwa,claa070wp03xg + # EDT ETML0700Z9NDHA 7.0" WSVGA (1024x600) color TFT LCD LVDS panel + - edt,etml0700z9ndha # HannStar Display Corp. HSD101PWW2 10.1" WXGA (1280x800) LVDS panel - hannstar,hsd101pww2 # Hydis Technologies 7" WXGA (800x1280) TFT LCD LVDS panel -- 2.25.1
[PATCH v1 8/8] arm64: dts: st: add display support on stm32mp257f-ev
This patch enables the following IPs on stm32mp257f-ev :
* LTDC
* LVDS
* WSVGA LVDS panel (1024x600)
* Panel backlight
* Ilitek touchescreen
Signed-off-by: Raphael Gallais-Pou
---
arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 79 ++
1 file changed, 79 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
index 0ea8e69bfb3d..ca2da988d91c 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
@@ -29,6 +29,43 @@ memory@8000 {
reg = <0x0 0x8000 0x1 0x0>;
};
+ panel_lvds: panel-lvds {
+ compatible = "edt,etml0700z9ndha", "panel-lvds";
+ enable-gpios = < 15 GPIO_ACTIVE_HIGH>;
+ backlight = <_lvds_backlight>;
+ status = "okay";
+
+ width-mm = <156>;
+ height-mm = <92>;
+ data-mapping = "vesa-24";
+
+ panel-timing {
+ clock-frequency = <5400>;
+ hactive = <1024>;
+ vactive = <600>;
+ hfront-porch = <150>;
+ hback-porch = <150>;
+ hsync-len = <21>;
+ vfront-porch = <24>;
+ vback-porch = <24>;
+ vsync-len = <21>;
+ };
+
+ port {
+ lvds_panel_in: endpoint {
+ remote-endpoint = <_out0>;
+ };
+ };
+ };
+
+ panel_lvds_backlight: panel-lvds-backlight {
+ compatible = "gpio-backlight";
+ gpios = < 5 GPIO_ACTIVE_HIGH>;
+ default-on;
+ default-brightness-level = <0>;
+ status = "okay";
+ };
+
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
@@ -63,6 +100,15 @@ {
i2c-scl-falling-time-ns = <13>;
clock-frequency = <40>;
status = "okay";
+
+ ili2511: ili2511@41 {
+ compatible = "ilitek,ili251x";
+ reg = <0x41>;
+ interrupt-parent = <>;
+ interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = < 14 GPIO_ACTIVE_LOW>;
+ status = "okay";
+ };
};
{
@@ -75,6 +121,39 @@ {
status = "disabled";
};
+ {
+ status = "okay";
+
+ port {
+ ltdc_ep0_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds_in: endpoint {
+ remote-endpoint = <_ep0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ lvds_out0: endpoint {
+ remote-endpoint = <_panel_in>;
+ };
+ };
+ };
+};
+
{
pinctrl-names = "default", "opendrain", "sleep";
pinctrl-0 = <_b4_pins_a>;
--
2.25.1
[PATCH v1 7/8] arm64: dts: st: add lvds support on stm32mp253
This patch adds LVDS support on stm32mp253. The LVDS is used on
STM32MP2 as a display interface. LVDS PLL clock is binded to the LTDC
input clock.
Signed-off-by: Raphael Gallais-Pou
---
arch/arm64/boot/dts/st/stm32mp253.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp253.dtsi
b/arch/arm64/boot/dts/st/stm32mp253.dtsi
index af48e82efe8a..bcc605e502de 100644
--- a/arch/arm64/boot/dts/st/stm32mp253.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp253.dtsi
@@ -21,3 +21,20 @@ arm-pmu {
interrupt-affinity = <>, <>;
};
};
+
+ {
+ clocks = < CK_BUS_LTDC>, < CK_KER_LTDC>, < 0>;
+ clock-names = "bus", "lcd", "lvds";
+};
+
+ {
+ lvds: lvds@4806 {
+ #clock-cells = <0>;
+ compatible = "st,stm32-lvds";
+ reg = <0x4806 0x2000>;
+ clocks = < CK_BUS_LVDS>, < CK_KER_LVDSPHY>;
+ clock-names = "pclk", "ref";
+ resets = < LVDS_R>;
+ status = "disabled";
+ };
+};
--
2.25.1
[PATCH v1 6/8] arm64: dts: st: add ltdc support on stm32mp251
The LCD-TFT Display Controller (LTDC) handles display composition,
scaling and rotation. It provides a parallel digital RGB flow to be used
by display interfaces.
Signed-off-by: Raphael Gallais-Pou
---
arch/arm64/boot/dts/st/stm32mp251.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi
b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 93bc8a8908ce..064077e98dfd 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -212,6 +212,18 @@ i2c8: i2c@4604 {
status = "disabled";
};
+ ltdc: display-controller@4801 {
+ compatible = "st,stm32-ltdc";
+ reg = <0x4801 0x400>;
+ st,syscon = <>;
+ interrupts = ,
+ ;
+ clocks = < CK_BUS_LTDC>, < CK_KER_LTDC>;
+ clock-names = "bus", "lcd";
+ resets = < LTDC_R>;
+ status = "disabled";
+ };
+
sdmmc1: mmc@4822 {
compatible = "st,stm32mp25-sdmmc2",
"arm,pl18x", "arm,primecell";
arm,primecell-periphid = <0x00353180>;
--
2.25.1
[PATCH v1 5/8] drm/stm: ltdc: add lvds pixel clock
The STM32MP25x display subsystem presents a mux which feeds the loopback
pixel clock of the current bridge in use into the LTDC. This mux is only
accessible through sysconfig registers which is not yet available in the
STM32MP25x common clock framework.
While waiting for a complete update of the clock framework, this would
allow to use the LVDS.
Signed-off-by: Raphael Gallais-Pou
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/ltdc.c | 18 ++
drivers/gpu/drm/stm/ltdc.h | 1 +
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 67064f47a4cb..1cf9f16e56cc 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -838,6 +838,12 @@ ltdc_crtc_mode_valid(struct drm_crtc *crtc,
int target_max = target + CLK_TOLERANCE_HZ;
int result;
+ if (ldev->lvds_clk) {
+ result = clk_round_rate(ldev->lvds_clk, target);
+ DRM_DEBUG_DRIVER("lvds pixclk rate target %d, available %d\n",
+target, result);
+ }
+
result = clk_round_rate(ldev->pixel_clk, target);
DRM_DEBUG_DRIVER("clk rate target %d, available %d\n", target, result);
@@ -1898,6 +1904,8 @@ void ltdc_suspend(struct drm_device *ddev)
clk_disable_unprepare(ldev->pixel_clk);
if (ldev->bus_clk)
clk_disable_unprepare(ldev->bus_clk);
+ if (ldev->lvds_clk)
+ clk_disable_unprepare(ldev->lvds_clk);
}
int ltdc_resume(struct drm_device *ddev)
@@ -1918,6 +1926,12 @@ int ltdc_resume(struct drm_device *ddev)
return -ENODEV;
}
}
+ if (ldev->lvds_clk) {
+ if (clk_prepare_enable(ldev->lvds_clk)) {
+ DRM_ERROR("Unable to prepare lvds clock\n");
+ return -ENODEV;
+ }
+ }
return 0;
}
@@ -1989,6 +2003,10 @@ int ltdc_load(struct drm_device *ddev)
}
}
+ ldev->lvds_clk = devm_clk_get(dev, "lvds");
+ if (IS_ERR(ldev->lvds_clk))
+ ldev->lvds_clk = NULL;
+
rstc = devm_reset_control_get_exclusive(dev, NULL);
mutex_init(>err_lock);
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index 155d8e4a7c6b..662650a0fae2 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -44,6 +44,7 @@ struct ltdc_device {
void __iomem *regs;
struct regmap *regmap;
struct clk *pixel_clk; /* lcd pixel clock */
+ struct clk *lvds_clk; /* lvds pixel clock */
struct clk *bus_clk;/* bus clock */
struct mutex err_lock; /* protecting error_status */
struct ltdc_caps caps;
--
2.25.1
[PATCH v1 3/8] drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver
The Low-Voltage Differential Signaling (LVDS) Display Interface Transmitter handles the LVDS protocol: it maps the pixels received from the upstream Pixel-DMA LCD-TFT Display Controller (LTDC) onto the LVDS PHY. It regroups three sub blocks: * LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps its input pixels onto the data lanes of the PHY * LVDS PHY: parallelize the data and drives the LVDS data lanes * LVDS wrapper: handles top-level settings The LVDS controller driver supports the following high-level features: * FDP-Link-I and OpenLDI (v0.95) protocols * Single-Link or Dual-Link operation * Single-Display or Double-Display (with the same content duplicated on both) * Flexible Bit-Mapping, including JEIDA and VESA * RGB888 or RGB666 output * Synchronous design, with one input pixel per clock cycle Signed-off-by: Raphael Gallais-Pou --- drivers/gpu/drm/stm/Kconfig | 11 + drivers/gpu/drm/stm/Makefile |2 + drivers/gpu/drm/stm/lvds.c | 1226 ++ 3 files changed, 1239 insertions(+) create mode 100644 drivers/gpu/drm/stm/lvds.c diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig index fa49cde43bb2..9627814d027c 100644 --- a/drivers/gpu/drm/stm/Kconfig +++ b/drivers/gpu/drm/stm/Kconfig @@ -20,3 +20,14 @@ config DRM_STM_DSI select DRM_DW_MIPI_DSI help Choose this option for MIPI DSI support on STMicroelectronics SoC. + +config DRM_STM_LVDS + tristate "STMicroelectronics LVDS Display Interface Transmitter DRM driver" + depends on DRM_STM + help + Enable support for LVDS encoders on STMicroelectronics SoC. + The STM LVDS is a bridge which serialize pixel stream onto + a LVDS protocol. + + To compile this driver as a module, choose M here: the module will be + called lvds. diff --git a/drivers/gpu/drm/stm/Makefile b/drivers/gpu/drm/stm/Makefile index 4df5caf01f35..ad740d6175a6 100644 --- a/drivers/gpu/drm/stm/Makefile +++ b/drivers/gpu/drm/stm/Makefile @@ -5,4 +5,6 @@ stm-drm-y := \ obj-$(CONFIG_DRM_STM_DSI) += dw_mipi_dsi-stm.o +obj-$(CONFIG_DRM_STM_LVDS) += lvds.o + obj-$(CONFIG_DRM_STM) += stm-drm.o diff --git a/drivers/gpu/drm/stm/lvds.c b/drivers/gpu/drm/stm/lvds.c new file mode 100644 index ..f01490939ab5 --- /dev/null +++ b/drivers/gpu/drm/stm/lvds.c @@ -0,0 +1,1226 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (C) 2023, STMicroelectronics - All Rights Reserved + * Author(s): Rapha??l GALLAIS-POU for STMicroelectronics. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +/* LVDS Host registers */ +#define LVDS_CR0x /* configuration register */ +#define LVDS_DMLCR00x0004 /* data mapping lsb configuration register 0 */ +#define LVDS_DMMCR00x0008 /* data mapping msb configuration register 0 */ +#define LVDS_DMLCR10x000C /* data mapping lsb configuration register 1 */ +#define LVDS_DMMCR10x0010 /* data mapping msb configuration register 1 */ +#define LVDS_DMLCR20x0014 /* data mapping lsb configuration register 2 */ +#define LVDS_DMMCR20x0018 /* data mapping msb configuration register 2 */ +#define LVDS_DMLCR30x001C /* data mapping lsb configuration register 3 */ +#define LVDS_DMMCR30x0020 /* data mapping msb configuration register 3 */ +#define LVDS_DMLCR40x0024 /* data mapping lsb configuration register 4 */ +#define LVDS_DMMCR40x0028 /* data mapping msb configuration register 4 */ +#define LVDS_CDL1CR0x002C /* channel distrib link 1 configuration register */ +#define LVDS_CDL2CR0x0030 /* channel distrib link 2 configuration register */ + +#define CDL1CR_DEFAULT 0x04321 /* Default value for CDL1CR */ +#define CDL2CR_DEFAULT 0x59876 /* Default value for CDL2CR */ + +#define LVDS_DMLCR(bit)(LVDS_DMLCR0 + 0x8 * (bit)) +#define LVDS_DMMCR(bit)(LVDS_DMMCR0 + 0x8 * (bit)) + +/* LVDS Wrapper registers */ +#define LVDS_WCLKCR0x11B0 /* Wrapper clock control register */ + +#define LVDS_HWCFGR0x1FF0 /* HW configuration register*/ +#define LVDS_VERR 0x1FF4 /* Version register */ +#define LVDS_IPIDR 0x1FF8 /* Identification register */ +#define LVDS_SIDR 0x1FFC /* Size Identification register */ + +/* Bitfield description */ +#define CR_LVDSEN BIT(0) /* LVDS PHY Enable */ +#define CR_HSPOL BIT(1) /* Horizontal Synchronization Polarity */ +#define CR_VSPOL BIT(2) /* Vertical Synchronization Polarity */ +#define CR_DEPOL BIT(3) /* Data Enable Polarity */ +#define CR_CI BIT(4) /* Control Internal (software controlled bit) */ +#define CR_LKMOD BIT(5) /* Link Mode, for both Links */ +#define CR_LKPHA BIT(6) /* Link Phase, for
[PATCH v1 2/8] dt-bindings: display: add dt-bindings for STM32 LVDS device
Add dt-binding file for "st,stm32-lvds" compatible.
Signed-off-by: Raphael Gallais-Pou
---
.../bindings/display/st,stm32-lvds.yaml | 114 ++
1 file changed, 114 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
diff --git a/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
b/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
new file mode 100644
index ..d72c9088133c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/st,stm32-lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 LVDS Display Interface Transmitter
+
+maintainers:
+ - Raphael Gallais-Pou
+ - Yannick Fertre
+
+description: |
+ The STMicroelectronics STM32 LVDS Display Interface Transmitter handles the
+ LVDS protocol: it maps the pixels received from the upstream Pixel-DMA (LTDC)
+ onto the LVDS PHY.
+
+ It regroups three sub blocks:
+- LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps its input
+ pixels onto the data lanes of the PHY
+- LVDS PHY: parallelize the data and drives the LVDS data lanes
+- LVDS wrapper: handles top-level settings
+
+ The LVDS controller driver supports the following high-level features:
+- FDP-Link-I and OpenLDI (v0.95) protocols
+- Single-Link or Dual-Link operation
+- Single-Display or Double-Display (with the same content duplicated on
both)
+- Flexible Bit-Mapping, including JEIDA and VESA
+- RGB888 or RGB666 output
+- Synchronous design, with one input pixel per clock cycle
+
+properties:
+ "#clock-cells":
+const: 0
+
+ compatible:
+const: st,stm32-lvds
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: APB peripheral clock
+ - description: Reference clock for the internal PLL
+
+ clock-names:
+items:
+ - const: pclk
+ - const: ref
+
+ resets:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: |
+ LVDS input port node, connected to the LTDC RGB output port.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: |
+ LVDS output port node, connected to a panel or bridge input port.
+
+required:
+ - "#clock-cells"
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+
+lvds: lvds@4806 {
+#clock-cells = <0>;
+compatible = "st,stm32-lvds";
+reg = <0x4806 0x2000>;
+clocks = < CK_BUS_LVDS>, < CK_KER_LVDSPHY>;
+clock-names = "pclk", "ref";
+resets = < LVDS_R>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+lvds_in: endpoint {
+ remote-endpoint = <_ep1_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+lvds_out0: endpoint {
+ remote-endpoint = <_panel_in>;
+};
+};
+};
+};
+
+...
--
2.25.1
[PATCH v1 4/8] drm/stm: ltdc: implement bus clock
From: Yannick Fertre
The latest hardware version of the LTDC presents the addition of a bus
clock, which contains the global configuration registers and the interrupt
register.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/ltdc.c | 8
drivers/gpu/drm/stm/ltdc.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 5576fdae4962..67064f47a4cb 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1896,6 +1896,8 @@ void ltdc_suspend(struct drm_device *ddev)
DRM_DEBUG_DRIVER("\n");
clk_disable_unprepare(ldev->pixel_clk);
+ if (ldev->bus_clk)
+ clk_disable_unprepare(ldev->bus_clk);
}
int ltdc_resume(struct drm_device *ddev)
@@ -1910,6 +1912,12 @@ int ltdc_resume(struct drm_device *ddev)
DRM_ERROR("failed to enable pixel clock (%d)\n", ret);
return ret;
}
+ if (ldev->bus_clk) {
+ if (clk_prepare_enable(ldev->bus_clk)) {
+ DRM_ERROR("Unable to prepare bus clock\n");
+ return -ENODEV;
+ }
+ }
return 0;
}
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index 9d488043ffdb..155d8e4a7c6b 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -44,6 +44,7 @@ struct ltdc_device {
void __iomem *regs;
struct regmap *regmap;
struct clk *pixel_clk; /* lcd pixel clock */
+ struct clk *bus_clk;/* bus clock */
struct mutex err_lock; /* protecting error_status */
struct ltdc_caps caps;
u32 irq_status;
--
2.25.1
[PATCH v1 1/8] dt-bindings: panel: lvds: Append edt, etml0700z9ndha in panel-lvds
List EDT ETML0700Z9NDHA in the LVDS panel enumeration. Signed-off-by: Raphael Gallais-Pou --- Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml index 9f1016551e0b..3fb24393529c 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml @@ -42,6 +42,8 @@ properties: - auo,b101ew05 # Chunghwa Picture Tubes Ltd. 7" WXGA (800x1280) TFT LCD LVDS panel - chunghwa,claa070wp03xg + # EDT ETML0700Z9NDHA 7.0" WSVGA (1024x600) color TFT LCD LVDS panel + - edt,etml0700z9ndha # HannStar Display Corp. HSD101PWW2 10.1" WXGA (1280x800) LVDS panel - hannstar,hsd101pww2 # Hydis Technologies 7" WXGA (800x1280) TFT LCD LVDS panel -- 2.25.1
[PATCH v1 0/8] Introduce STM32 LVDS driver
This serie introduces a new DRM bridge driver for STM32MP257 platforms based on Arm Cortex-35. It also adds an instance in the device-tree and handle the inclusion of the driver within the DRM framework. First patch adds a new panel compatible in the panel-lvds driver, which is used by default on the STM32MP257. Raphael Gallais-Pou (7): dt-bindings: panel: lvds: Append edt,etml0700z9ndha in panel-lvds dt-bindings: display: add dt-bindings for STM32 LVDS device drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver drm/stm: ltdc: add lvds pixel clock arm64: dts: st: add ltdc support on stm32mp251 arm64: dts: st: add lvds support on stm32mp253 arm64: dts: st: add display support on stm32mp257f-ev Yannick Fertre (1): drm/stm: ltdc: implement bus clock .../bindings/display/panel/panel-lvds.yaml|2 + .../bindings/display/st,stm32-lvds.yaml | 114 ++ arch/arm64/boot/dts/st/stm32mp251.dtsi| 12 + arch/arm64/boot/dts/st/stm32mp253.dtsi| 17 + arch/arm64/boot/dts/st/stm32mp257f-ev1.dts| 79 ++ drivers/gpu/drm/stm/Kconfig | 11 + drivers/gpu/drm/stm/Makefile |2 + drivers/gpu/drm/stm/ltdc.c| 26 + drivers/gpu/drm/stm/ltdc.h|2 + drivers/gpu/drm/stm/lvds.c| 1226 + 10 files changed, 1491 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/st,stm32-lvds.yaml create mode 100644 drivers/gpu/drm/stm/lvds.c -- 2.25.1
Re: [PATCH v3 4/4] drm/i915/guc: Use the ce_to_guc() wrapper whenever possible
On 12/6/2023 9:46 PM, Andi Shyti wrote:
Get the guc reference from the ce using the ce_to_guc() helper.
Just a leftover from previous cleanups.
Signed-off-by: Andi Shyti
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 4f51cc5f1604..3c7821ae9f0d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3513,7 +3513,7 @@ static inline void sub_context_inflight_prio(struct
intel_context *ce,
static inline void update_context_prio(struct intel_context *ce)
{
- struct intel_guc *guc = >engine->gt->uc.guc;
+ struct intel_guc *guc = ce_to_guc(ce);
int i;
BUILD_BUG_ON(GUC_CLIENT_PRIORITY_KMD_HIGH != 0);
[ANNOUNCE] libdrm 2.4.119
New libdrm has been released. Marek Olšák (2): amdgpu: add amdgpu_va_get_start_addr meson: bump libdrm version to 2.4.119 git tag: libdrm-2.4.119 https://dri.freedesktop.org/libdrm/libdrm-2.4.119.tar.xz SHA256: 0a49f12f09b5b6e68eaaaff3f02ca7cff9aa926939b212d343161d3e8ac56291 libdrm-2.4.119.tar.xz SHA512: c8dd7665e85c01a67fcce1c1c614bc05a3ec311f31cae7de5fb1cd27d0f11f1801be63de3fa3e33b2f505544fd4b1bc292965c5e8de46a3beaaedb10334945ca libdrm-2.4.119.tar.xz PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.119.tar.xz.sig See the attachment for the signed message. Marek -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 New libdrm has been released. Marek Olšák (2): amdgpu: add amdgpu_va_get_start_addr meson: bump libdrm version to 2.4.119 git tag: libdrm-2.4.119 https://dri.freedesktop.org/libdrm/libdrm-2.4.119.tar.xz SHA256: 0a49f12f09b5b6e68eaaaff3f02ca7cff9aa926939b212d343161d3e8ac56291 libdrm-2.4.119.tar.xz SHA512: c8dd7665e85c01a67fcce1c1c614bc05a3ec311f31cae7de5fb1cd27d0f11f1801be63de3fa3e33b2f505544fd4b1bc292965c5e8de46a3beaaedb10334945ca libdrm-2.4.119.tar.xz PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.119.tar.xz.sig -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEE86UtuOzp654zvEjGkXo+6XoPzRoFAmWEKx8ACgkQkXo+6XoP zRqmZQwAn7zcB2GyPFGu+jJOGpM4xN07WFNnV/SsDL/kIPsXuQvOfqzyh+3itDvu nJzldeNyWa9EDEtj40y1hLmYXgmSBcbPqsj4gmi190UVMEYyYKvKKqH++SyWa2KE 0DLjOibka2AjTAWYDf3JA86eezKn8xXa7l8/RaUIm/8DYXfL8mk0MdjrZhySnMZn zrZ5QT8rsNEaVIOHHRlYbkRQs+WZXS9W7FfXq+BGrPZjP+C4dalt5GJoaV/Ng3gH C900SRF7eSkseRwNKyE1l86aWFa8PwxoU1B0f+g1vlYAvive7BIr7WXJu+7shGHI yVhu+RlWF1AVUDscHjCOsnSxS1f4PHASMXdVreN4MpfpCHYYlzFt0kuwXJa4FOHF /w90D+HSARF+vvSyGwnFRybIJ16uwQZSSGo9FL2LhhDlGqOfd6cwyl1vLUk2gV0q tBtrahC1m0EevPxOGTowtfEIkuFkxrmHOg3HH3Wj0Te7AHA10OuOg1aJpnyDIUpr WMUmHONt =wqGI -END PGP SIGNATURE-
Re: [PATCH v5 5/8] iio: core: Add new DMABUF interface infrastructure
On Tue, 19 Dec 2023 18:50:06 +0100
Paul Cercueil wrote:
> Add the necessary infrastructure to the IIO core to support a new
> optional DMABUF based interface.
>
> With this new interface, DMABUF objects (externally created) can be
> attached to a IIO buffer, and subsequently used for data transfer.
>
> A userspace application can then use this interface to share DMABUF
> objects between several interfaces, allowing it to transfer data in a
> zero-copy fashion, for instance between IIO and the USB stack.
>
> The userspace application can also memory-map the DMABUF objects, and
> access the sample data directly. The advantage of doing this vs. the
> read() interface is that it avoids an extra copy of the data between the
> kernel and userspace. This is particularly userful for high-speed
> devices which produce several megabytes or even gigabytes of data per
> second.
>
> As part of the interface, 3 new IOCTLs have been added:
>
> IIO_BUFFER_DMABUF_ATTACH_IOCTL(int fd):
> Attach the DMABUF object identified by the given file descriptor to the
> buffer.
>
> IIO_BUFFER_DMABUF_DETACH_IOCTL(int fd):
> Detach the DMABUF object identified by the given file descriptor from
> the buffer. Note that closing the IIO buffer's file descriptor will
> automatically detach all previously attached DMABUF objects.
>
> IIO_BUFFER_DMABUF_ENQUEUE_IOCTL(struct iio_dmabuf *):
> Request a data transfer to/from the given DMABUF object. Its file
> descriptor, as well as the transfer size and flags are provided in the
> "iio_dmabuf" structure.
>
> These three IOCTLs have to be performed on the IIO buffer's file
> descriptor, obtained using the IIO_BUFFER_GET_FD_IOCTL() ioctl.
>
Fair enough - so they don't apply to the 'legacy' buffer which simplifies
things but in one place you assume that logic is used (given error return
values).
> Signed-off-by: Paul Cercueil
>
This is big and complex and I'm out of time for now, so I've made some
comments but should revisit it.
I'm also looking for review from those more familiar with dmabuf side
of things than I am!
Jonathan
>
> +static int iio_dma_resv_lock(struct dma_buf *dmabuf, bool nonblock)
> +{
> + int ret;
> +
> + ret = dma_resv_lock_interruptible(dmabuf->resv, NULL);
> + if (ret) {
> + if (ret != -EDEADLK)
> + goto out;
> + if (nonblock) {
> + ret = -EBUSY;
> + goto out;
> + }
> +
> + ret = dma_resv_lock_slow_interruptible(dmabuf->resv, NULL);
> + }
> +
> +out:
> + return ret;
I'm not a fan gotos that do nothing. Just return in appropriate places above.
> +}
>
> +static int iio_buffer_detach_dmabuf(struct iio_dev_buffer_pair *ib, int
> *user_req)
> +{
> + struct dma_buf_attachment *attach;
> + struct iio_dmabuf_priv *priv;
> + struct dma_buf *dmabuf;
> + int dmabuf_fd, ret = 0;
> +
> + if (copy_from_user(_fd, user_req, sizeof(dmabuf_fd)))
> + return -EFAULT;
> +
> + dmabuf = dma_buf_get(dmabuf_fd);
> + if (IS_ERR(dmabuf))
> + return PTR_ERR(dmabuf);
> +
> + attach = iio_buffer_find_attachment(ib->indio_dev, dmabuf);
> + if (IS_ERR(attach)) {
> + ret = PTR_ERR(attach);
> + goto out_dmabuf_put;
> + }
> +
> + priv = attach->importer_priv;
> + list_del_init(>entry);
> +
> + /*
> + * Unref twice to release the reference obtained with
> + * iio_buffer_find_attachment() above, and the one obtained in
> + * iio_buffer_attach_dmabuf().
> + */
> + iio_buffer_dmabuf_put(attach);
> + iio_buffer_dmabuf_put(attach);
> +
> +out_dmabuf_put:
> + dma_buf_put(dmabuf);
As below. Feels like a __free(dma_buf_put) bit of magic would be a nice to have.
> +
> + return ret;
> +}
> +
> +static const char *
> +iio_buffer_dma_fence_get_driver_name(struct dma_fence *fence)
> +{
> + return "iio";
> +}
> +
> +static void iio_buffer_dma_fence_release(struct dma_fence *fence)
> +{
> + struct iio_dma_fence *iio_fence =
> + container_of(fence, struct iio_dma_fence, base);
> +
> + kfree(iio_fence);
> +}
> +
> +static const struct dma_fence_ops iio_buffer_dma_fence_ops = {
> + .get_driver_name= iio_buffer_dma_fence_get_driver_name,
> + .get_timeline_name = iio_buffer_dma_fence_get_driver_name,
> + .release= iio_buffer_dma_fence_release,
> +};
> +
> +static int iio_buffer_enqueue_dmabuf(struct iio_dev_buffer_pair *ib,
> + struct iio_dmabuf __user *iio_dmabuf_req,
> + bool nonblock)
> +{
> + struct iio_dev *indio_dev = ib->indio_dev;
> + struct iio_buffer *buffer = ib->buffer;
> + struct iio_dmabuf iio_dmabuf;
> + struct dma_buf_attachment *attach;
> + struct iio_dmabuf_priv *priv;
> + enum dma_data_direction dir;
> + struct iio_dma_fence *fence;
> + struct dma_buf *dmabuf;
Re: [PATCH v5 3/8] dmaengine: Add API function dmaengine_prep_slave_dma_vec()
On Tue, 19 Dec 2023 18:50:04 +0100 Paul Cercueil wrote: > This function can be used to initiate a scatter-gather DMA transfer, > where the address and size of each segment is located in one entry of > the dma_vec array. > > The major difference with dmaengine_prep_slave_sg() is that it supports > specifying the lengths of each DMA transfer; as trying to override the > length of the transfer with dmaengine_prep_slave_sg() is a very tedious > process. The introduction of a new API function is also justified by the > fact that scatterlists are on their way out. > > Note that dmaengine_prep_interleaved_dma() is not helpful either in that > case, as it assumes that the address of each segment will be higher than > the one of the previous segment, which we just cannot guarantee in case > of a scatter-gather transfer. > > Signed-off-by: Paul Cercueil This and the next patch look fine to me as clearly simplify things for our usecases, but they are really something for the dmaengine maintainers to comment on. Jonathan
Re: [PATCH v5 2/8] iio: buffer-dma: split iio_dma_buffer_fileio_free() function
On Tue, 19 Dec 2023 18:50:03 +0100 Paul Cercueil wrote: > From: Alexandru Ardelean > > This change splits the logic into a separate function, which will be > re-used later. > > Signed-off-by: Alexandru Ardelean > Cc: Alexandru Ardelean > Signed-off-by: Paul Cercueil Harmless refactor so I'm fine taking this now to reduce noise on any v6 Applied Jonathan
Re: [PATCH v5 1/8] iio: buffer-dma: Get rid of outgoing queue
On Tue, 19 Dec 2023 18:50:02 +0100 Paul Cercueil wrote: > The buffer-dma code was using two queues, incoming and outgoing, to > manage the state of the blocks in use. > > While this totally works, it adds some complexity to the code, > especially since the code only manages 2 blocks. It is much easier to > just check each block's state manually, and keep a counter for the next > block to dequeue. > > Since the new DMABUF based API wouldn't use the outgoing queue anyway, > getting rid of it now makes the upcoming changes simpler. > > With this change, the IIO_BLOCK_STATE_DEQUEUED is now useless, and can > be removed. > > Signed-off-by: Paul Cercueil > I've applied this in interests in reducing the outstanding set of patches and because it stands fine as on its own. Applied to the togreg branch of iio.git and pushed out as testing. Note this is now almost certainly 6.9 material given timing. Jonathan
Re: [PATCH] drm/vmwgfx: Keep a gem reference to user bos in surfaces
Hi Zack,
thank you for the patch!
On Thu, 2023-09-28 at 00:13 -0400, Zack Rusin wrote:
> From: Zack Rusin
>
> Surfaces can be backed (i.e. stored in) memory objects (mob's) which
> are created and managed by the userspace as GEM buffers. Surfaces
> grab only a ttm reference which means that the gem object can
> be deleted underneath us, especially in cases where prime buffer
> export is used.
>
> Make sure that all userspace surfaces which are backed by gem objects
> hold a gem reference to make sure they're not deleted before vmw
> surfaces are done with them, which fixes:
> [ cut here ]
> refcount_t: underflow; use-after-free.
> WARNING: CPU: 2 PID: 2632 at lib/refcount.c:28
> refcount_warn_saturate+0xfb/0x150
> Modules linked in: overlay vsock_loopback vmw_vsock_virtio_transport_common
> vmw_vsock_vmci_transport vsock snd_ens1371 snd_ac97_codec ac97_bus snd_pcm
> gameport>
> CPU: 2 PID: 2632 Comm: vmw_ref_count Not tainted 6.5.0-rc2-vmwgfx #1
> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference
> Platform, BIOS 6.00 11/12/2020
> RIP: 0010:refcount_warn_saturate+0xfb/0x150
> Code: eb 9e 0f b6 1d 8b 5b a6 01 80 fb 01 0f 87 ba e4 80 00 83 e3 01 75 89 48
> c7 c7 c0 3c f9 a3 c6 05 6f 5b a6 01 01 e8 15 81 98 ff <0f> 0b e9 6f ff ff ff
> 0f b>
> RSP: 0018:bdc34344bba0 EFLAGS: 00010286
> RAX: RBX: RCX: 0027
> RDX: 960475ea1548 RSI: 0001 RDI: 960475ea1540
> RBP: bdc34344bba8 R08: 0003 R09: 65646e75203a745f
> R10: a5b32b20 R11: 72657466612d6573 R12: 96037d6a6400
> R13: 9603484805b0 R14: 000b R15: 9603bed06060
> FS: 7f5fd8520c40() GS:960475e8() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 7f5fda755000 CR3: 00010d012005 CR4: 003706e0
> Call Trace:
>
> ? show_regs+0x6e/0x80
> ? refcount_warn_saturate+0xfb/0x150
> ? __warn+0x91/0x150
> ? refcount_warn_saturate+0xfb/0x150
> ? report_bug+0x19d/0x1b0
> ? handle_bug+0x46/0x80
> ? exc_invalid_op+0x1d/0x80
> ? asm_exc_invalid_op+0x1f/0x30
> ? refcount_warn_saturate+0xfb/0x150
> drm_gem_object_handle_put_unlocked+0xba/0x110 [drm]
> drm_gem_object_release_handle+0x6e/0x80 [drm]
> drm_gem_handle_delete+0x6a/0xc0 [drm]
> ? __pfx_vmw_bo_unref_ioctl+0x10/0x10 [vmwgfx]
> vmw_bo_unref_ioctl+0x33/0x40 [vmwgfx]
> drm_ioctl_kernel+0xbc/0x160 [drm]
> drm_ioctl+0x2d2/0x580 [drm]
> ? __pfx_vmw_bo_unref_ioctl+0x10/0x10 [vmwgfx]
> ? do_vmi_munmap+0xee/0x180
> vmw_generic_ioctl+0xbd/0x180 [vmwgfx]
> vmw_unlocked_ioctl+0x19/0x20 [vmwgfx]
> __x64_sys_ioctl+0x99/0xd0
> do_syscall_64+0x5d/0x90
> ? syscall_exit_to_user_mode+0x2a/0x50
> ? do_syscall_64+0x6d/0x90
> ? handle_mm_fault+0x16e/0x2f0
> ? exit_to_user_mode_prepare+0x34/0x170
> ? irqentry_exit_to_user_mode+0xd/0x20
> ? irqentry_exit+0x3f/0x50
> ? exc_page_fault+0x8e/0x190
> entry_SYSCALL_64_after_hwframe+0x6e/0xd8
> RIP: 0033:0x7f5fda51aaff
> Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24
> 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff
> ff 7>
> RSP: 002b:7ffd536a4d30 EFLAGS: 0246 ORIG_RAX: 0010
> RAX: ffda RBX: 7ffd536a4de0 RCX: 7f5fda51aaff
> RDX: 7ffd536a4de0 RSI: 40086442 RDI: 0003
> RBP: 40086442 R08: 55fa603ada50 R09:
> R10: 0001 R11: 0246 R12: 7ffd536a51b8
> R13: 0003 R14: 55fa5ebb4c80 R15: 7f5fda90f040
>
> ---[ end trace ]---
>
> A lot of the analyis on the bug was done by Murray McAllister and
> Ian Forbes.
>
> Reported-by: Murray McAllister
> Cc: Ian Forbes
> Signed-off-by: Zack Rusin
> Fixes: a950b989ea29 ("drm/vmwgfx: Do not drop the reference to the handle too
> soon")
> Cc: # v6.2+
Do you remember the particular reason this was marked 6.2+?
We see this on Debian 6.1.67 (which at least has the mentioned
"drm/vmwgfx: Do not drop the reference to the handle too soon"):
[ cut here ]
refcount_t: underflow; use-after-free.
WARNING: CPU: 0 PID: 1945 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110
Modules linked in: ...
CPU: 0 PID: 1945 Comm: ksplashqml Tainted: G OE 6.1.0-16-amd64
#1 Debian 6.1.67-1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference
Platform, BIOS 6.00 11/12/2020
RIP: 0010:refcount_warn_saturate+0xba/0x110
Code: ...
RSP: 0018:b3cb41cfbc58 EFLAGS: 00010286
RAX: RBX: 8d7da05dde00 RCX: 0027
RDX: 8d802de203a8 RSI: 0001 RDI: 8d802de203a0
RBP: 8d7d110f5800 R08: R09: b3cb41cfbad0
R10: 0003 R11: 8d803fec1b28 R12: 0015
R13: 8d7d110f5858 R14: 8d7d110f5840 R15: 0015
FS: 7f6584cc99c0()
Re: [PATCH v3 1/2] drm/buddy: Implement tracking clear page feature
Hi Matthew,
On 12/21/2023 12:51 AM, Matthew Auld wrote:
Hi,
On 14/12/2023 13:42, Arunpravin Paneer Selvam wrote:
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the otherhand,
DRM buddy marks each block as cleared.
- Track the available cleared pages size
- If driver requests cleared memory we prefer cleared memory
but fallback to uncleared if we can't find the cleared blocks.
when driver requests uncleared memory we try to use uncleared but
fallback to cleared memory if necessary.
- When a block gets freed we clear it and mark the freed block as
cleared,
when there are buddies which are cleared as well we can merge them.
Otherwise, we prefer to keep the blocks as separated.
I was not involved, but it looks like we have also tried enabling the
clear-on-free idea for VRAM in i915 and then also tracking that in the
allocator, however that work unfortunately is not upstream. The code
is open source though:
https://github.com/intel-gpu/intel-gpu-i915-backports/blob/backport/main/drivers/gpu/drm/i915/i915_buddy.c#L300
It looks like some of the design differences there are having two
separate free lists, so mm->clean and mm->dirty (sounds reasonable to
me). And also the inclusion of a de-fragmentation routine, since buddy
blocks are now not always merged back, we might choose to run the
defrag in some cases, which also sounds reasonable. IIRC in amdgpu
userspace can control the page-size for an allocation, so perhaps you
would want to run it first if the allocation fails, before trying to
evict stuff?
Thanks, I will check the code.
Regards,
Arun.
v1: (Christian)
- Depends on the flag check DRM_BUDDY_CLEARED, enable the block as
cleared. Else, reset the clear flag for each block in the list.
- For merging the 2 cleared blocks compare as below,
drm_buddy_is_clear(block) != drm_buddy_is_clear(buddy)
Signed-off-by: Arunpravin Paneer Selvam
Suggested-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 6 +-
drivers/gpu/drm/drm_buddy.c | 169 +++---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 6 +-
drivers/gpu/drm/tests/drm_buddy_test.c | 10 +-
include/drm/drm_buddy.h | 18 +-
5 files changed, 168 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 08916538a615..d0e199cc8f17 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -556,7 +556,7 @@ static int amdgpu_vram_mgr_new(struct
ttm_resource_manager *man,
return 0;
error_free_blocks:
- drm_buddy_free_list(mm, >blocks);
+ drm_buddy_free_list(mm, >blocks, 0);
mutex_unlock(>lock);
error_fini:
ttm_resource_fini(man, >base);
@@ -589,7 +589,7 @@ static void amdgpu_vram_mgr_del(struct
ttm_resource_manager *man,
amdgpu_vram_mgr_do_reserve(man);
- drm_buddy_free_list(mm, >blocks);
+ drm_buddy_free_list(mm, >blocks, 0);
mutex_unlock(>lock);
atomic64_sub(vis_usage, >vis_usage);
@@ -897,7 +897,7 @@ void amdgpu_vram_mgr_fini(struct amdgpu_device
*adev)
kfree(rsv);
list_for_each_entry_safe(rsv, temp, >reserved_pages,
blocks) {
- drm_buddy_free_list(>mm, >allocated);
+ drm_buddy_free_list(>mm, >allocated, 0);
kfree(rsv);
}
if (!adev->gmc.is_app_apu)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index f57e6d74fb0e..d44172f23f05 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -57,6 +57,16 @@ static void list_insert_sorted(struct drm_buddy *mm,
__list_add(>link, node->link.prev, >link);
}
+static void clear_reset(struct drm_buddy_block *block)
+{
+ block->header &= ~DRM_BUDDY_HEADER_CLEAR;
+}
+
+static void mark_cleared(struct drm_buddy_block *block)
+{
+ block->header |= DRM_BUDDY_HEADER_CLEAR;
+}
+
static void mark_allocated(struct drm_buddy_block *block)
{
block->header &= ~DRM_BUDDY_HEADER_STATE;
@@ -223,6 +233,12 @@ static int split_block(struct drm_buddy *mm,
mark_free(mm, block->left);
mark_free(mm, block->right);
+ if (drm_buddy_block_is_clear(block)) {
+ mark_cleared(block->left);
+ mark_cleared(block->right);
+ clear_reset(block);
+ }
+
mark_split(block);
return 0;
@@ -273,6 +289,13 @@ static void __drm_buddy_free(struct drm_buddy *mm,
if (!drm_buddy_block_is_free(buddy))
break;
+ if (drm_buddy_block_is_clear(block) !=
+ drm_buddy_block_is_clear(buddy))
+ break;
+
+ if (drm_buddy_block_is_clear(block))
+ mark_cleared(parent);
+
list_del(>link);
drm_block_free(mm, block);
@@ -295,6 +318,9 @@ void
[RFC PATCH 2/2] dt-bindings: display: msm: mass-rename files
Rename the Qualcomm MSM Display schemas to follow the main compatible
string instead of just using the block type. This follows the
established practice for YAML file names.
Cc: Aiqun Yu (Maria)
Signed-off-by: Dmitry Baryshkov
---
.../bindings/display/msm/{gmu.yaml => qcom,adreno-gmu.yaml} | 2 +-
.../bindings/display/msm/{gpu.yaml => qcom,adreno.yaml} | 2 +-
.../bindings/display/msm/{hdmi.yaml => qcom,hdmi-tx.yaml} | 2 +-
.../bindings/display/msm/{mdp4.yaml => qcom,mdp4.yaml} | 2 +-
.../msm/{dsi-controller-main.yaml => qcom,mdss-dsi-ctrl.yaml} | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
rename Documentation/devicetree/bindings/display/msm/{gmu.yaml =>
qcom,adreno-gmu.yaml} (99%)
rename Documentation/devicetree/bindings/display/msm/{gpu.yaml =>
qcom,adreno.yaml} (99%)
rename Documentation/devicetree/bindings/display/msm/{hdmi.yaml =>
qcom,hdmi-tx.yaml} (98%)
rename Documentation/devicetree/bindings/display/msm/{mdp4.yaml =>
qcom,mdp4.yaml} (97%)
rename Documentation/devicetree/bindings/display/msm/{dsi-controller-main.yaml
=> qcom,mdss-dsi-ctrl.yaml} (99%)
diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,adreno-gmu.yaml
similarity index 99%
rename from Documentation/devicetree/bindings/display/msm/gmu.yaml
rename to Documentation/devicetree/bindings/display/msm/qcom,adreno-gmu.yaml
index 4e1c25b42908..0678cead56bf 100644
--- a/Documentation/devicetree/bindings/display/msm/gmu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,adreno-gmu.yaml
@@ -3,7 +3,7 @@
%YAML 1.2
---
-$id: http://devicetree.org/schemas/display/msm/gmu.yaml#
+$id: http://devicetree.org/schemas/display/msm/qcom,adreno-gmu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: GMU attached to certain Adreno GPUs
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,adreno.yaml
similarity index 99%
rename from Documentation/devicetree/bindings/display/msm/gpu.yaml
rename to Documentation/devicetree/bindings/display/msm/qcom,adreno.yaml
index b019db954793..ad15f0a6ead7 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,adreno.yaml
@@ -2,7 +2,7 @@
%YAML 1.2
---
-$id: http://devicetree.org/schemas/display/msm/gpu.yaml#
+$id: http://devicetree.org/schemas/display/msm/qcom,adreno.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Adreno or Snapdragon GPUs
diff --git a/Documentation/devicetree/bindings/display/msm/hdmi.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,hdmi-tx.yaml
similarity index 98%
rename from Documentation/devicetree/bindings/display/msm/hdmi.yaml
rename to Documentation/devicetree/bindings/display/msm/qcom,hdmi-tx.yaml
index 47e97669821c..a137ca0b734c 100644
--- a/Documentation/devicetree/bindings/display/msm/hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,hdmi-tx.yaml
@@ -2,7 +2,7 @@
%YAML 1.2
---
-$id: http://devicetree.org/schemas/display/msm/hdmi.yaml#
+$id: http://devicetree.org/schemas/display/msm/qcom,hdmi-tx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Adreno/Snapdragon HDMI output
diff --git a/Documentation/devicetree/bindings/display/msm/mdp4.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,mdp4.yaml
similarity index 97%
rename from Documentation/devicetree/bindings/display/msm/mdp4.yaml
rename to Documentation/devicetree/bindings/display/msm/qcom,mdp4.yaml
index 35204a287579..40c31602affd 100644
--- a/Documentation/devicetree/bindings/display/msm/mdp4.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,mdp4.yaml
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: http://devicetree.org/schemas/display/msm/mdp4.yaml#
+$id: http://devicetree.org/schemas/display/msm/qcom,mdp4.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Adreno/Snapdragon MDP4 display controller
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,mdss-dsi-ctrl.yaml
similarity index 99%
rename from
Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
rename to Documentation/devicetree/bindings/display/msm/qcom,mdss-dsi-ctrl.yaml
index 4219936eda5a..35f4facc2fdd 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss-dsi-ctrl.yaml
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
-$id: http://devicetree.org/schemas/display/msm/dsi-controller-main.yaml#
+$id: http://devicetree.org/schemas/display/msm/qcom,mdss-dsi-ctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Display DSI controller
--
2.39.2
[RFC PATCH 1/2] dt-bindings: display: msm: move DSI PHY schema to bindings/phy
While the DSI PHY schema files describe the display-related hardware,
they still describe a PHY. Move all DSI PHY schema files to the phy/
subdir.
Signed-off-by: Dmitry Baryshkov
---
.../msm/dsi-phy-10nm.yaml => phy/qcom,dsi-phy-10nm.yaml} | 4 ++--
.../msm/dsi-phy-14nm.yaml => phy/qcom,dsi-phy-14nm.yaml} | 4 ++--
.../msm/dsi-phy-20nm.yaml => phy/qcom,dsi-phy-20nm.yaml} | 4 ++--
.../msm/dsi-phy-28nm.yaml => phy/qcom,dsi-phy-28nm.yaml} | 4 ++--
.../msm/dsi-phy-7nm.yaml => phy/qcom,dsi-phy-7nm.yaml}| 4 ++--
.../msm/dsi-phy-common.yaml => phy/qcom,dsi-phy-common.yaml} | 2 +-
6 files changed, 11 insertions(+), 11 deletions(-)
rename Documentation/devicetree/bindings/{display/msm/dsi-phy-10nm.yaml =>
phy/qcom,dsi-phy-10nm.yaml} (96%)
rename Documentation/devicetree/bindings/{display/msm/dsi-phy-14nm.yaml =>
phy/qcom,dsi-phy-14nm.yaml} (94%)
rename Documentation/devicetree/bindings/{display/msm/dsi-phy-20nm.yaml =>
phy/qcom,dsi-phy-20nm.yaml} (93%)
rename Documentation/devicetree/bindings/{display/msm/dsi-phy-28nm.yaml =>
phy/qcom,dsi-phy-28nm.yaml} (94%)
rename Documentation/devicetree/bindings/{display/msm/dsi-phy-7nm.yaml =>
phy/qcom,dsi-phy-7nm.yaml} (94%)
rename Documentation/devicetree/bindings/{display/msm/dsi-phy-common.yaml =>
phy/qcom,dsi-phy-common.yaml} (90%)
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-10nm.yaml
similarity index 96%
rename from Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
rename to Documentation/devicetree/bindings/phy/qcom,dsi-phy-10nm.yaml
index 69d13867b7cf..094fbd60093a 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-10nm.yaml
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
-$id: http://devicetree.org/schemas/display/msm/dsi-phy-10nm.yaml#
+$id: http://devicetree.org/schemas/phy/qcom,dsi-phy-10nm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Display DSI 10nm PHY
@@ -10,7 +10,7 @@ maintainers:
- Krishna Manikandan
allOf:
- - $ref: dsi-phy-common.yaml#
+ - $ref: qcom,dsi-phy-common.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-14nm.yaml
similarity index 94%
rename from Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
rename to Documentation/devicetree/bindings/phy/qcom,dsi-phy-14nm.yaml
index 52bbe132e6da..308706d37944 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-14nm.yaml
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
-$id: http://devicetree.org/schemas/display/msm/dsi-phy-14nm.yaml#
+$id: http://devicetree.org/schemas/phy/qcom,dsi-phy-14nm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Display DSI 14nm PHY
@@ -10,7 +10,7 @@ maintainers:
- Krishna Manikandan
allOf:
- - $ref: dsi-phy-common.yaml#
+ - $ref: qcom,dsi-phy-common.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml
b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-20nm.yaml
similarity index 93%
rename from Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml
rename to Documentation/devicetree/bindings/phy/qcom,dsi-phy-20nm.yaml
index 7e6687cb002b..cf6f96d04150 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-20nm.yaml
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
-$id: http://devicetree.org/schemas/display/msm/dsi-phy-20nm.yaml#
+$id: http://devicetree.org/schemas/phy/qcom,dsi-phy-20nm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Display DSI 20nm PHY
@@ -10,7 +10,7 @@ maintainers:
- Krishna Manikandan
allOf:
- - $ref: dsi-phy-common.yaml#
+ - $ref: qcom,dsi-phy-common.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-28nm.yaml
similarity index 94%
rename from Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
rename to Documentation/devicetree/bindings/phy/qcom,dsi-phy-28nm.yaml
index 288d8babb76a..4fe30ca2d5f5 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-28nm.yaml
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
-$id: http://devicetree.org/schemas/display/msm/dsi-phy-28nm.yaml#
+$id: http://devicetree.org/schemas/phy/qcom,dsi-phy-28nm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
[RFC PATCH 0/2] dt-bindings: display: msm: correct schema filenames
During the email discussion Aiqun Yu (Maria) pointed out that the file
names for some of the MSM display schema files might not be obvious.
Indeed they do not fully follow the established practice of matching the
file name and one of compat strings.
Move DSI PHY schemas to the PHY subdir (renaming them meanwhile) and
rename remaining schema files.
Note, I have intentinally left dpu-common.yaml and mdss-common.yaml
untouched, they describe common properties for a family of devices.
Also I have left dp-controller.yaml intact. I could not come up with a
good enough file name. Suggestions for this file are appreciated.
Dmitry Baryshkov (2):
dt-bindings: display: msm: move DSI PHY schema to bindings/phy
dt-bindings: display: msm: mass-rename files
.../bindings/display/msm/{gmu.yaml => qcom,adreno-gmu.yaml} | 2 +-
.../bindings/display/msm/{gpu.yaml => qcom,adreno.yaml} | 2 +-
.../bindings/display/msm/{hdmi.yaml => qcom,hdmi-tx.yaml} | 2 +-
.../bindings/display/msm/{mdp4.yaml => qcom,mdp4.yaml}| 2 +-
.../msm/{dsi-controller-main.yaml => qcom,mdss-dsi-ctrl.yaml} | 2 +-
.../msm/dsi-phy-10nm.yaml => phy/qcom,dsi-phy-10nm.yaml} | 4 ++--
.../msm/dsi-phy-14nm.yaml => phy/qcom,dsi-phy-14nm.yaml} | 4 ++--
.../msm/dsi-phy-20nm.yaml => phy/qcom,dsi-phy-20nm.yaml} | 4 ++--
.../msm/dsi-phy-28nm.yaml => phy/qcom,dsi-phy-28nm.yaml} | 4 ++--
.../msm/dsi-phy-7nm.yaml => phy/qcom,dsi-phy-7nm.yaml}| 4 ++--
.../msm/dsi-phy-common.yaml => phy/qcom,dsi-phy-common.yaml} | 2 +-
11 files changed, 16 insertions(+), 16 deletions(-)
rename Documentation/devicetree/bindings/display/msm/{gmu.yaml =>
qcom,adreno-gmu.yaml} (99%)
rename Documentation/devicetree/bindings/display/msm/{gpu.yaml =>
qcom,adreno.yaml} (99%)
rename Documentation/devicetree/bindings/display/msm/{hdmi.yaml =>
qcom,hdmi-tx.yaml} (98%)
rename Documentation/devicetree/bindings/display/msm/{mdp4.yaml =>
qcom,mdp4.yaml} (97%)
rename Documentation/devicetree/bindings/display/msm/{dsi-controller-main.yaml
=> qcom,mdss-dsi-ctrl.yaml} (99%)
rename Documentation/devicetree/bindings/{display/msm/dsi-phy-10nm.yaml =>
phy/qcom,dsi-phy-10nm.yaml} (96%)
rename Documentation/devicetree/bindings/{display/msm/dsi-phy-14nm.yaml =>
phy/qcom,dsi-phy-14nm.yaml} (94%)
rename Documentation/devicetree/bindings/{display/msm/dsi-phy-20nm.yaml =>
phy/qcom,dsi-phy-20nm.yaml} (93%)
rename Documentation/devicetree/bindings/{display/msm/dsi-phy-28nm.yaml =>
phy/qcom,dsi-phy-28nm.yaml} (94%)
rename Documentation/devicetree/bindings/{display/msm/dsi-phy-7nm.yaml =>
phy/qcom,dsi-phy-7nm.yaml} (94%)
rename Documentation/devicetree/bindings/{display/msm/dsi-phy-common.yaml =>
phy/qcom,dsi-phy-common.yaml} (90%)
--
2.39.2
[PATCH 1/1] drm/virtio: Implement RESOURCE_GET_LAYOUT ioctl
From: Daniel Stone
Add a new ioctl to allow the guest VM to discover how the guest
actually allocated the underlying buffer, which allows buffers to
be used for GL<->Vulkan interop and through standard window systems.
It's also a step towards properly supporting modifiers in the guest.
Signed-off-by: Daniel Stone
Co-developed-by: Julia Zhang # support query
stride before it's created
Signed-off-by: Julia Zhang
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 22 -
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 66 ++
drivers/gpu/drm/virtio/virtgpu_kms.c | 8 +++-
drivers/gpu/drm/virtio/virtgpu_vq.c| 63
include/uapi/drm/virtgpu_drm.h | 21
include/uapi/linux/virtio_gpu.h| 30
7 files changed, 208 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 4334c7608408..98061b714b98 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -148,6 +148,7 @@ static unsigned int features[] = {
VIRTIO_GPU_F_RESOURCE_UUID,
VIRTIO_GPU_F_RESOURCE_BLOB,
VIRTIO_GPU_F_CONTEXT_INIT,
+ VIRTIO_GPU_F_RESOURCE_QUERY_LAYOUT,
};
static struct virtio_driver virtio_gpu_driver = {
.feature_table = features,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 96365a772f77..bb5edcfeda54 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -214,6 +214,16 @@ struct virtio_gpu_drv_cap_cache {
atomic_t is_valid;
};
+struct virtio_gpu_query_info {
+ uint32_t num_planes;
+ uint64_t modifier;
+ struct {
+ uint64_t offset;
+ uint32_t stride;
+ } planes[VIRTIO_GPU_MAX_RESOURCE_PLANES];
+ atomic_t is_valid;
+};
+
struct virtio_gpu_device {
struct drm_device *ddev;
@@ -246,6 +256,7 @@ struct virtio_gpu_device {
bool has_resource_blob;
bool has_host_visible;
bool has_context_init;
+ bool has_resource_query_layout;
struct virtio_shm_region host_visible_region;
struct drm_mm host_visible_mm;
@@ -277,7 +288,7 @@ struct virtio_gpu_fpriv {
};
/* virtgpu_ioctl.c */
-#define DRM_VIRTIO_NUM_IOCTLS 12
+#define DRM_VIRTIO_NUM_IOCTLS 13
extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
void virtio_gpu_create_context(struct drm_device *dev, struct drm_file *file);
@@ -420,6 +431,15 @@ virtio_gpu_cmd_set_scanout_blob(struct virtio_gpu_device
*vgdev,
uint32_t width, uint32_t height,
uint32_t x, uint32_t y);
+int
+virtio_gpu_cmd_get_resource_layout(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_query_info *bo_info,
+ uint32_t width,
+ uint32_t height,
+ uint32_t format,
+ uint32_t bind,
+ uint32_t hw_res_handle);
+
/* virtgpu_display.c */
int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev);
void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev);
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index b24b11f25197..216c04314177 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -107,6 +107,9 @@ static int virtio_gpu_getparam_ioctl(struct drm_device
*dev, void *data,
case VIRTGPU_PARAM_SUPPORTED_CAPSET_IDs:
value = vgdev->capset_id_mask;
break;
+ case VIRTGPU_PARAM_RESOURCE_QUERY_LAYOUT:
+ value = vgdev->has_resource_query_layout ? 1 : 0;
+ break;
default:
return -EINVAL;
}
@@ -668,6 +671,65 @@ static int virtio_gpu_context_init_ioctl(struct drm_device
*dev,
return ret;
}
+static int virtio_gpu_resource_query_layout_ioctl(struct drm_device *dev,
+ void *data,
+ struct drm_file *file)
+{
+ struct drm_virtgpu_resource_query_layout *args = data;
+ struct virtio_gpu_device *vgdev = dev->dev_private;
+ struct drm_gem_object *obj = NULL;
+ struct virtio_gpu_object *bo = NULL;
+ struct virtio_gpu_query_info bo_info = {0};
+ int ret = 0;
+ int i;
+
+ if (!vgdev->has_resource_query_layout) {
+ DRM_ERROR("failing: no RQL on host\n");
+ return -EINVAL;
+ }
+
+ if (args->handle > 0) {
+ obj = drm_gem_object_lookup(file, args->handle);
+ if (obj == NULL) {
+ DRM_ERROR("invalid handle 0x%x\n", args->handle);
+
[PATCH v2 0/1] Implementation of resource_query_layout
Hi all, Sorry to late reply. This is v2 of the implementation of resource_query_layout. This adds a new ioctl to let guest query information of host resource, which is originally from Daniel Stone. We add some changes to support query the correct stride of host resource before it's created, which is to support to blit data from dGPU to virtio iGPU for dGPU prime feature. Changes from v1 to v2: -Squash two patches to a single patch. -A small modification of VIRTIO_GPU_F_RESOURCE_QUERY_LAYOUT Below is description of v1: This add implementation of resource_query_layout to get the information of how the host has actually allocated the buffer. This function is now used to query the stride for guest linear resource for dGPU prime on guest VMs. v1 of kernel side: https: //lore.kernel.org/xen-devel/20231110074027.24862-1-julia.zh...@amd.com/T/#t v1 of qemu side: https: //lore.kernel.org/qemu-devel/20231110074027.24862-1-julia.zh...@amd.com/T/#t Daniel Stone (1): drm/virtio: Implement RESOURCE_GET_LAYOUT ioctl drivers/gpu/drm/virtio/virtgpu_drv.c | 1 + drivers/gpu/drm/virtio/virtgpu_drv.h | 22 - drivers/gpu/drm/virtio/virtgpu_ioctl.c | 66 ++ drivers/gpu/drm/virtio/virtgpu_kms.c | 8 +++- drivers/gpu/drm/virtio/virtgpu_vq.c| 63 include/uapi/drm/virtgpu_drm.h | 21 include/uapi/linux/virtio_gpu.h| 30 7 files changed, 208 insertions(+), 3 deletions(-) -- 2.34.1
Re: [PATCH v4] ASoC: hdmi-codec: drop drm/drm_edid.h include
On Thu, Dec 21, 2023 at 11:35:42AM +0200, Jani Nikula wrote: > On Tue, 19 Dec 2023, Jani Nikula wrote: > > hdmi-codec.h does not appear to directly need drm/drm_edid.h for > > anything. Remove it. > > > > There are some files that get drm/edid.h by proxy; include it where > > needed. > > > > v2-v4: Fix build (kernel test robot ) > > > > Signed-off-by: Jani Nikula > > > > --- > > > > I'm pretty sure I haven't compiled everything that might implicitly > > depend on the include. However, the right thing to do is to include > > drm_edid.h where needed, not from somewhat random intermediate > > headers. I hope this uncovers anything I missed. > > The kernel test robot came back with clean results. > > Added a bunch more Cc's here. Ack to merge this via drm-misc-next, > please? Acked-by: Maxime Ripard Maxime signature.asc Description: PGP signature
Re: [PATCH v4] ASoC: hdmi-codec: drop drm/drm_edid.h include
On Tue, 19 Dec 2023, Jani Nikula wrote: > hdmi-codec.h does not appear to directly need drm/drm_edid.h for > anything. Remove it. > > There are some files that get drm/edid.h by proxy; include it where > needed. > > v2-v4: Fix build (kernel test robot ) > > Signed-off-by: Jani Nikula > > --- > > I'm pretty sure I haven't compiled everything that might implicitly > depend on the include. However, the right thing to do is to include > drm_edid.h where needed, not from somewhat random intermediate > headers. I hope this uncovers anything I missed. The kernel test robot came back with clean results. Added a bunch more Cc's here. Ack to merge this via drm-misc-next, please? BR, Jani. > --- > drivers/gpu/drm/bridge/lontium-lt9611.c| 1 + > drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 1 + > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 + > drivers/gpu/drm/msm/dp/dp_display.c| 1 + > drivers/gpu/drm/vc4/vc4_hdmi.c | 1 + > include/sound/hdmi-codec.h | 1 - > 6 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c > b/drivers/gpu/drm/bridge/lontium-lt9611.c > index 9663601ce098..b9205d14d943 100644 > --- a/drivers/gpu/drm/bridge/lontium-lt9611.c > +++ b/drivers/gpu/drm/bridge/lontium-lt9611.c > @@ -18,6 +18,7 @@ > > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c > b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c > index e971b75e90ad..f3f130c1ef0a 100644 > --- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c > +++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c > @@ -21,6 +21,7 @@ > > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > index 52d91a0df85e..fa63a21bdd1c 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -31,6 +31,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/gpu/drm/msm/dp/dp_display.c > b/drivers/gpu/drm/msm/dp/dp_display.c > index 1b88fb52726f..766c8d01e6b3 100644 > --- a/drivers/gpu/drm/msm/dp/dp_display.c > +++ b/drivers/gpu/drm/msm/dp/dp_display.c > @@ -11,6 +11,7 @@ > #include > #include > #include > +#include > > #include "msm_drv.h" > #include "msm_kms.h" > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c > index f05e2c95a60d..34f807ed1c31 100644 > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c > @@ -35,6 +35,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h > index 9b162ac1e08e..5e1a9eafd10f 100644 > --- a/include/sound/hdmi-codec.h > +++ b/include/sound/hdmi-codec.h > @@ -12,7 +12,6 @@ > > #include > #include > -#include > #include > #include > #include -- Jani Nikula, Intel
[PATCH RESEND] drm/bridge: Fixed a DP link training bug
To have better compatibility for DP sink, there is a retry mechanism
for the link training process to switch between different training process.
The original driver code doesn't reset the retry counter when training
state is pass. If the system triggers link training over 3 times,
there will be a chance to causes the driver to use the wrong training
method and return a training fail result.
To Fix this, we reset the retry counter when training state is pass
each time.
Signed-off-by: Allen Chen
Signed-off-by: xiazhengqiao
---
drivers/gpu/drm/bridge/ite-it6505.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c
b/drivers/gpu/drm/bridge/ite-it6505.c
index 2f300f5ca051..b589136ca6da 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -2240,11 +2240,13 @@ static void it6505_link_training_work(struct
work_struct *work)
ret = it6505_link_start_auto_train(it6505);
DRM_DEV_DEBUG_DRIVER(dev, "auto train %s, auto_train_retry: %d",
ret ? "pass" : "failed", it6505->auto_train_retry);
- it6505->auto_train_retry--;
if (ret) {
+ it6505->auto_train_retry = AUTO_TRAIN_RETRY;
it6505_link_train_ok(it6505);
return;
+ } else {
+ it6505->auto_train_retry--;
}
it6505_dump(it6505);
--
2.17.1
Re: [PATCH v10 02/16] dt-bindings: media: mediatek: mdp3: merge the indentical RDMA under display
On 20/12/2023 11:08, Moudy Ho wrote:
> To simplify maintenance and avoid branches, the identical component
> should be merged and placed in the path belonging to the MDP
> (from display/* to media/*).
Combining bindings into one bigger meta-binding makes it usually more
difficult to maintain and review.
>
> In addition, currently only MDP utilizes RDMA through CMDQ, and the
> necessary properties for "mediatek,gce-events", and "mboxes" have been
> set up for this purpose.
> Within DISP, it directly receives component interrupt signals.
>
> Signed-off-by: Moudy Ho
> ---
> .../display/mediatek/mediatek,mdp-rdma.yaml | 92 ---
> .../bindings/media/mediatek,mdp3-rdma.yaml| 43 -
> 2 files changed, 40 insertions(+), 95 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
> deleted file mode 100644
> index 7570a0684967..
> ---
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
> +++ /dev/null
> @@ -1,92 +0,0 @@
> -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> -%YAML 1.2
>
> -$id: http://devicetree.org/schemas/display/mediatek/mediatek,mdp-rdma.yaml#
> -$schema: http://devicetree.org/meta-schemas/core.yaml#
> -
> -title: MediaTek MDP RDMA
> -
> -maintainers:
> - - Chun-Kuang Hu
> - - Philipp Zabel
> -
> -description:
> - The MediaTek MDP RDMA stands for Read Direct Memory Access.
> - It provides real time data to the back-end panel driver, such as DSI,
> - DPI and DP_INTF.
> - It contains one line buffer to store the sufficient pixel data.
> - RDMA device node must be siblings to the central MMSYS_CONFIG node.
> - For a description of the MMSYS_CONFIG binding, see
> - Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml for
> details.
> -
> -properties:
> - compatible:
> -oneOf:
> - - const: mediatek,mt8195-vdo1-rdma
> - - items:
> - - const: mediatek,mt8188-vdo1-rdma
> - - const: mediatek,mt8195-vdo1-rdma
> -
> - reg:
> -maxItems: 1
> -
> - interrupts:
> -maxItems: 1
> -
> - power-domains:
> -maxItems: 1
> -
> - clocks:
> -items:
> - - description: RDMA Clock
> -
> - iommus:
> -maxItems: 1
> -
> - mediatek,gce-client-reg:
> -description:
> - The register of display function block to be set by gce. There are 4
> arguments,
> - such as gce node, subsys id, offset and register size. The subsys id
> that is
> - mapping to the register of display function blocks is defined in the
> gce header
> - include/dt-bindings/gce/-gce.h of each chips.
> -$ref: /schemas/types.yaml#/definitions/phandle-array
> -items:
> - items:
> -- description: phandle of GCE
> -- description: GCE subsys id
> -- description: register offset
> -- description: register size
> -maxItems: 1
> -
> -required:
> - - compatible
> - - reg
> - - power-domains
> - - clocks
> - - iommus
> - - mediatek,gce-client-reg
> -
> -additionalProperties: false
> -
> -examples:
> - - |
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -soc {
> -#address-cells = <2>;
> -#size-cells = <2>;
> -
> -rdma@1c104000 {
> -compatible = "mediatek,mt8195-vdo1-rdma";
> -reg = <0 0x1c104000 0 0x1000>;
> -interrupts = ;
> -clocks = < CLK_VDO1_MDP_RDMA0>;
> -power-domains = < MT8195_POWER_DOMAIN_VDOSYS1>;
> -iommus = <_vdo M4U_PORT_L2_MDP_RDMA0>;
> -mediatek,gce-client-reg = < SUBSYS_1c10 0x4000 0x1000>;
> -};
> -};
> diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> index e1ffe7eb2cdf..e9955639ce19 100644
> --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> @@ -20,8 +20,12 @@ description: |
>
> properties:
>compatible:
> -items:
> +oneOf:
>- const: mediatek,mt8183-mdp3-rdma
> + - const: mediatek,mt8195-vdo1-rdma
> + - items:
> + - const: mediatek,mt8188-vdo1-rdma
> + - const: mediatek,mt8195-vdo1-rdma
>
>reg:
> maxItems: 1
> @@ -60,6 +64,7 @@ properties:
> items:
>- description: RDMA clock
>- description: RSZ clock
> +minItems: 1
>
>iommus:
> maxItems: 1
> @@ -68,6 +73,10 @@ properties:
> items:
>- description: used for 1st data pipe from RDMA
>- description: used for 2nd data pipe from RDMA
> +minItems: 1
> +
> + interrupts:
> +maxItems: 1
Why existing devices now support interrupts?
>
>'#dma-cells':
Re: [PATCH v3 3/4] drm/i915: Use the new gt_to_guc() wrapper
On 12/6/2023 9:46 PM, Andi Shyti wrote:
Get the guc reference from the gt using the gt_to_guc() helper.
Signed-off-by: Andi Shyti
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_debugfs_params.c | 2 +-
drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs_params.c
b/drivers/gpu/drm/i915/i915_debugfs_params.c
index 8bca02025e09..74b7f2fd8b57 100644
--- a/drivers/gpu/drm/i915/i915_debugfs_params.c
+++ b/drivers/gpu/drm/i915/i915_debugfs_params.c
@@ -43,7 +43,7 @@ static int notify_guc(struct drm_i915_private *i915)
for_each_gt(gt, i915, i) {
if (intel_uc_uses_guc_submission(>uc))
- ret = intel_guc_global_policies_update(>uc.guc);
+ ret = intel_guc_global_policies_update(gt_to_guc(gt));
}
return ret;
diff --git a/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
b/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
index 2990dd4d4a0d..d9d8f0336702 100644
--- a/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
+++ b/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
@@ -65,7 +65,7 @@ int intel_selftest_modify_policy(struct intel_engine_cs
*engine,
if (!intel_engine_uses_guc(engine))
return 0;
- err = intel_guc_global_policies_update(>gt->uc.guc);
+ err = intel_guc_global_policies_update(gt_to_guc(engine->gt));
if (err)
intel_selftest_restore_policy(engine, saved);
@@ -84,7 +84,7 @@ int intel_selftest_restore_policy(struct intel_engine_cs *engine,
if (!intel_engine_uses_guc(engine))
return 0;
- return intel_guc_global_policies_update(>gt->uc.guc);
+ return intel_guc_global_policies_update(gt_to_guc(engine->gt));
}
int intel_selftest_wait_for_rq(struct i915_request *rq)
Re: [PATCH v3 2/4] drm/i915/guc: Use the new gt_to_guc() wrapper
On 12/6/2023 9:46 PM, Andi Shyti wrote:
Get the guc reference from the gt using the gt_to_guc() helper.
Signed-off-by: Andi Shyti
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 4 +--
drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 3 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 6 ++--
.../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 28 +--
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 4 +--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 4 +--
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 2 +-
9 files changed, 28 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 e2e42b3e0d5d..3b69bc6616bd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -298,7 +298,7 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
memcpy_toio(gsc->local_vaddr, src, gsc->fw.size);
memset_io(gsc->local_vaddr + gsc->fw.size, 0, gsc->local->size -
gsc->fw.size);
- intel_guc_write_barrier(>uc.guc);
+ intel_guc_write_barrier(gt_to_guc(gt));
i915_gem_object_unpin_map(gsc->fw.obj);
@@ -351,7 +351,7 @@ static int gsc_fw_query_compatibility_version(struct intel_gsc_uc *gsc)
void *vaddr;
int err;
- err = intel_guc_allocate_and_map_vma(>uc.guc, GSC_VER_PKT_SZ * 2,
+ err = intel_guc_allocate_and_map_vma(gt_to_guc(gt), GSC_VER_PKT_SZ * 2,
, );
if (err) {
gt_err(gt, "failed to allocate vma for GSC version query\n");
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
index 40817ebcca71..a7d5465655f9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
@@ -358,7 +358,8 @@ static int proxy_channel_alloc(struct intel_gsc_uc *gsc)
void *vaddr;
int err;
- err = intel_guc_allocate_and_map_vma(>uc.guc, GSC_PROXY_CHANNEL_SIZE,
+ err = intel_guc_allocate_and_map_vma(gt_to_guc(gt),
+GSC_PROXY_CHANNEL_SIZE,
, );
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 63724e17829a..1ef470e64604 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -956,7 +956,7 @@ u32 intel_guc_engine_usage_offset(struct intel_guc *guc)
struct iosys_map intel_guc_engine_usage_record_map(struct intel_engine_cs *engine)
{
- struct intel_guc *guc = >gt->uc.guc;
+ struct intel_guc *guc = gt_to_guc(engine->gt);
u8 guc_class = engine_class_to_guc_class(engine->class);
size_t offset = offsetof(struct __guc_ads_blob,
engine_usage.engines[guc_class][ilog2(engine->logical_mask)]);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index a4da0208c883..84a8807391c5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -1441,7 +1441,7 @@ int intel_guc_capture_print_engine_node(struct
drm_i915_error_state_buf *ebuf,
if (!cap || !ee->engine)
return -ENODEV;
- guc = >engine->gt->uc.guc;
+ guc = gt_to_guc(ee->engine->gt);
i915_error_printf(ebuf, "global --- GuC Error Capture on %s command stream:\n",
ee->engine->name);
@@ -1543,7 +1543,7 @@ bool intel_guc_capture_is_matching_engine(struct intel_gt
*gt,
if (!gt || !ce || !engine)
return false;
- guc = >uc.guc;
+ guc = gt_to_guc(gt);
if (!guc->capture)
return false;
@@ -1573,7 +1573,7 @@ void intel_guc_capture_get_matching_node(struct intel_gt *gt,
if (!gt || !ee || !ce)
return;
- guc = >uc.guc;
+ guc = gt_to_guc(gt);
if (!guc->capture)
return;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
index cc9569af7f0c..b67a15f74276 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
@@ -111,7 +111,7 @@ static bool has_table(struct drm_i915_private *i915)
static int guc_hwconfig_init(struct intel_gt *gt)
{
struct intel_hwconfig *hwconfig = >info.hwconfig;
- struct intel_guc *guc = >uc.guc;
+ struct intel_guc *guc = gt_to_guc(gt);
int ret;
if (!has_table(gt->i915))
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
Re: [PATCH v3 1/4] drm/i915/gt: Create the gt_to_guc() wrapper
On 12/6/2023 9:46 PM, Andi Shyti wrote:
We already have guc_to_gt() and getting to guc from the GT it
requires some mental effort. Add the gt_to_guc().
Given the reference to the "gt", the gt_to_guc() will return the
pinter to the "guc".
Update all the files under the gt/ directory.
Signed-off-by: Andi Shyti
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_ggtt.c | 9 +++--
drivers/gpu/drm/i915/gt/intel_gt.h| 5 +
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 6 +++---
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 8
drivers/gpu/drm/i915/gt/intel_rc6.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_rps.c | 2 +-
drivers/gpu/drm/i915/gt/intel_tlb.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_slpc.c | 6 +++---
10 files changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 40687806d22a..bede7f09d4af 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -589,7 +589,7 @@ u64 intel_clamp_preempt_timeout_ms(struct intel_engine_cs
*engine, u64 value)
* NB: The GuC API only supports 32bit values. However, the limit is
further
* reduced due to internal calculations which would otherwise overflow.
*/
- if (intel_guc_submission_is_wanted(>gt->uc.guc))
+ if (intel_guc_submission_is_wanted(gt_to_guc(engine->gt)))
value = min_t(u64, value, guc_policy_max_preempt_timeout_ms());
value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
@@ -610,7 +610,7 @@ u64 intel_clamp_timeslice_duration_ms(struct
intel_engine_cs *engine, u64 value)
* NB: The GuC API only supports 32bit values. However, the limit is
further
* reduced due to internal calculations which would otherwise overflow.
*/
- if (intel_guc_submission_is_wanted(>gt->uc.guc))
+ if (intel_guc_submission_is_wanted(gt_to_guc(engine->gt)))
value = min_t(u64, value, guc_policy_max_exec_quantum_ms());
value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 21a7e3191c18..aa1e9249d393 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -230,11 +230,8 @@ static void guc_ggtt_ct_invalidate(struct intel_gt *gt)
struct intel_uncore *uncore = gt->uncore;
intel_wakeref_t wakeref;
- with_intel_runtime_pm_if_active(uncore->rpm, wakeref) {
- struct intel_guc *guc = >uc.guc;
-
- intel_guc_invalidate_tlb_guc(guc);
- }
+ with_intel_runtime_pm_if_active(uncore->rpm, wakeref)
+ intel_guc_invalidate_tlb_guc(gt_to_guc(gt));
}
static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
@@ -245,7 +242,7 @@ static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
gen8_ggtt_invalidate(ggtt);
list_for_each_entry(gt, >gt_list, ggtt_link) {
- if (intel_guc_tlb_invalidation_is_available(>uc.guc))
+ if (intel_guc_tlb_invalidation_is_available(gt_to_guc(gt)))
guc_ggtt_ct_invalidate(gt);
else if (GRAPHICS_VER(i915) >= 12)
intel_uncore_write_fw(gt->uncore,
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index b0e453e27ea8..d7c859039828 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -118,6 +118,11 @@ static inline struct intel_gt *gsc_to_gt(struct intel_gsc
*gsc)
return container_of(gsc, struct intel_gt, gsc);
}
+static inline struct intel_guc *gt_to_guc(struct intel_gt *gt)
+{
+ return >uc.guc;
+}
+
void intel_gt_common_init_early(struct intel_gt *gt);
int intel_root_gt_init_early(struct drm_i915_private *i915);
int intel_gt_assign_ggtt(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 77fb57223465..ad4c51f18d3a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -68,9 +68,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8
instance,
struct intel_gt *media_gt = gt->i915->media_gt;
if (instance == OTHER_GUC_INSTANCE)
- return guc_irq_handler(>uc.guc, iir);
+ return guc_irq_handler(gt_to_guc(gt), iir);
if (instance == OTHER_MEDIA_GUC_INSTANCE && media_gt)
- return guc_irq_handler(_gt->uc.guc, iir);
+ return guc_irq_handler(gt_to_guc(media_gt), iir);
if (instance == OTHER_GTPM_INSTANCE)
return gen11_rps_irq_handler(>rps, iir);
@@ -442,7 +442,7 @@ void
Re: [PATCH v2 2/2] drm/rockchip: rk3066_hdmi: drop custom fill_modes hook
On Tue, Dec 19, 2023 at 04:40:12PM +0100, Johan Jonker wrote:
>
>
> On 12/19/23 13:55, Maxime Ripard wrote:
> > Hi,
> >
> > On Mon, Dec 18, 2023 at 04:49:06PM +0100, Johan Jonker wrote:
> >> CRTC size validation for the display controller has been added with
> >> Commit 8e140cb60270 ("drm/rockchip: vop: limit maximum resolution to
> >> hardware capabilities"), so we can drop the custom fill_modes hook.
> >>
> >> Signed-off-by: Johan Jonker
> >
>
> > I'm not sure those two are equivalent. CRTC and connectors usually have
> > different requirements and capabilities, and thus different,
> > supplementary, mode_valid/atomic_check implementations.
>
> Rockchip RK3066 CRTC and connector resolution max_output are equivalent.
>
> From Rockchip PX2 TRM V1.0.pdf page 17:
> - Video Encoder
> Maximum frame rate is up to 30fps@1920x1080
>
> - Display Interface
> Support LCD or TFT interfaces up to 1920x1080
>
> - HDMI TX Interface
>HDMI version 1.4a, HDCP revision 1.4 and DVI version 1.0 compliant
> transmitter
>Supports DTV from 480i to 1080i/p HD resolution, and PC from VGA to UXGA
> by LCDC0 or LCDC1 in RK PX2
My point is that there's two limits: the CRTC and HDMI controller ones.
You should put the CRTC ones in the CRTC driver, and the HDMI controller
ones in the HDMI controller driver.
If they are equivalent, great, it's going to filter out the same things, but...
> Compared to the drm_helper_probe_single_connector_modes() this function added
> an extra max_output
>
> Checked in rockchip_drm_vop.c is:
> https://lore.kernel.org/linux-rockchip/20230216102447.582905-2-s.ha...@pengutronix.de/
>
> + if (vop->data->max_output.width && mode->hdisplay >
> vop->data->max_output.width)
> + return MODE_BAD_HVALUE;
> +
> + if (vop->data->max_output.height && mode->vdisplay >
> vop->data->max_output.height)
> + return MODE_BAD_VVALUE;
>
> For RK3066 VOP max_output:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/rockchip/rockchip_vop_reg.c#n506
>
> This patch was made with HDMI in mind.
>
> .max_output = { 1920, 1080 },
>
> This first part was added by Heiko, but not was not part my patch that I
> submitted:
> - if (maxX > 1920)
> - maxX = 1920;
> - if (maxY > 1080)
> - maxY = 1080;
> -
> - return drm_helper_probe_single_connector_modes(connector, maxX, maxY);
> -}
>
> Original patch:
> https://patchwork.freedesktop.org/patch/msgid/20190330095639.14626-2-jbx6...@gmail.com
>
> +static int
> +rk3066_hdmi_probe_single_connector_modes(struct drm_connector *connector,
> + uint32_t maxX, uint32_t maxY)
> +{
> + return drm_helper_probe_single_connector_modes(connector, 1920, 1080);
> +}
>
> Rockchip RK3066 CRTC and connector resolution max_output are equivalent.
... a user / dev unfamiliar with the SoC won't have to go through that
to figure out how it's handled, it will be obvious.
Maxime
signature.asc
Description: PGP signature
Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
On Tue, Dec 19, 2023 at 11:19:49AM -0600, Andrew Davis wrote: > On 12/18/23 4:54 AM, H. Nikolaus Schaller wrote: > > > > > > > Am 18.12.2023 um 11:14 schrieb Maxime Ripard : > > > > > > On Mon, Dec 18, 2023 at 10:28:09AM +0100, H. Nikolaus Schaller wrote: > > > > Hi Maxime, > > > > > > > > > Am 15.12.2023 um 14:33 schrieb Maxime Ripard : > > > > > > > > > > > > > > > > > > > It's for a separate architecture, with a separate driver, > > > > > > > maintained out > > > > > > > of tree by a separate community, with a separate set of > > > > > > > requirements as > > > > > > > evidenced by the other thread. And that's all fine in itself, but > > > > > > > there's very little reason to put these two bindings in the same > > > > > > > file. > > > > > > > > > > > > > > We could also turn this around, why is it important that it's in > > > > > > > the > > > > > > > same file? > > > > > > > > > > > > Same vendor. And enough similarity in architectures, even a logical > > > > > > sequence > > > > > > of development of versions (SGX = Version 5, Rogue = Version 6+) > > > > > > behind. > > > > > > (SGX and Rogue seem to be just trade names for their architecture > > > > > > development). > > > > > > > > > > Again, none of that matters for *where* the binding is stored. > > > > > > > > So what then speaks against extending the existing bindings file as > > > > proposed > > > > here? > > > > > > I mean, apart from everything you quoted, then sure, nothing speaks > > > against it. > > > > > > > > > AFAIK bindings should describe hardware and not communities or > > > > > > drivers > > > > > > or who is currently maintaining it. The latter can change, the > > > > > > first not. > > > > > > > > > > Bindings are supposed to describe hardware indeed. Nothing was ever > > > > > said > > > > > about where those bindings are supposed to be located. > > > > > > > > > > There's hundreds of other YAML bindings describing devices of the same > > > > > vendors and different devices from the same generation. > > > > > > > > Usually SoC seem to be split over multiple files by subsystem. Not by > > > > versions > > > > or generations. If the subsystems are similar enough they share the > > > > same bindings > > > > doc instead of having one for each generation duplicating a lot of code. > > > > > > > > Here is a comparable example that combines multiple vendors and > > > > generations: > > > > > > > > Documentation/devicetree/bindings/usb/generic-ehci.yaml > > > > > > EHCI is a single interface for USB2.0 controllers. It's a standard API, > > > and is made of a single driver that requires minor modifications to deal > > > with multiple devices. > > > > > > We're very far from the same situation here. > > > > How far are we really? And, it is the purpose of the driver to handle > > different cases. > > > > That there are currently two drivers is just a matter of history and not a > > necessity. > > > > > > > > > > If anything it'll make it easier for you. I'm really not sure why it > > > > > is > > > > > controversial and you're fighting this so hard. > > > > > > > > Well, you made it controversial by proposing to split what IMHO belongs > > > > together. > > > > > > No, reviews aren't controversial. > > > The controversy started when you chose > > > to oppose it while you could have just rolled with it. > > > > Well, you asked > > > > "I think it would be best to have a separate file for this, img,sgx.yaml > > maybe?" > > > > and > > > > "Because it's more convenient?" > > > > I understood that as an invitation for discussing the pros and cons and > > working out the > > most convenient solution. And that involves playing the devil's advocate > > which of course > > is controversial by principle. > > > > Now, IMHO all the pros and cons are on the table and the question is who > > makes a decision > > how to go. > > > > As much as I would land on the side of same file for both, the answer to this > question > is simple: the maintainer makes the decision :) So I'll respin with separate > binding files. > > The hidden unaddressed issue here is that by making these bindings separate > it implies > they are not on equal footing (i.e. pre-series6 GPUs are not true "powervr" > and so do not > belong in img,powervr.yaml). No, not really. As far as I'm concerned, the only unequal footing here is that one driver is in-tree and the other isn't, but this situation was handled nicely for Mali GPUs and lima that used to be in the same situation for example. The situation is simple, really: bindings are supposed to be backward compatible, period. If we ever make a change to that binding that isn't, you will be well within your right to complain because your driver is now broken. > So if no one objects I'd also like to do the rename of that > file as suggested before and have: > > img,powervr-sgx.yaml > img,powervr-rogue.yaml Sounds good to me. Maxime signature.asc Description: PGP
