Re: [PATCH] dt-bindings: lcdif: Add support for specifying display with timings
On Mon, Sep 23, 2024 at 07:53:57PM +0200, Marek Vasut wrote: > On 9/23/24 3:57 PM, Lukasz Majewski wrote: > > Up till now the fsl,lcdif.yaml was requiring the "port" property as a > > must have to specify the display interface on iMX devices. > > > > However, it shall also be possible to specify the display only with > > passing its timing parameters (h* and v* ones) via "display" property: > > (as in > > Documentation/devicetree/bindings/display/panel/display-timings.yaml). > > Timings should go into panel node, not into scanout engine node. > > See e.g. panel-timings in arch/arm64/boot/dts/freescale/imx8mm-phg.dts , in > your case the compatible might be "panel-dpi" . I agree, but if this is already in use, we should allow it. We can mark it deprecated though. Rob
[PATCH v2 01/22] drm: add clone mode check for CRTC
Add helper to check if the given CRTC state is in clone mode
Signed-off-by: Jessica Zhang
---
include/drm/drm_crtc.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8b48a1974da3..ecb93e2c4afc 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1323,5 +1323,12 @@ static inline struct drm_crtc *drm_crtc_find(struct
drm_device *dev,
int drm_crtc_create_scaling_filter_property(struct drm_crtc *crtc,
unsigned int supported_filters);
+static inline bool drm_crtc_in_clone_mode(struct drm_crtc_state *crtc_state)
+{
+ if (!crtc_state)
+ return false;
+
+ return hweight32(crtc_state->encoder_mask) > 1;
+}
#endif /* __DRM_CRTC_H__ */
--
2.34.1
[PATCH v2 06/22] drm/msm/dpu: fill CRTC resources in dpu_crtc.c
From: Dmitry Baryshkov
Stop poking into CRTC state from dpu_encoder.c, fill CRTC HW resources
from dpu_crtc_assign_resources().
Signed-off-by: Dmitry Baryshkov
[quic_abhin...@quicinc.com: cleaned up formatting]
Signed-off-by: Abhinav Kumar
[quic_jessz...@quicinc.com: dropped clearing num_mixers in CRTC disable
path]
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 32 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 24 ++
2 files changed, 31 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index b918c80d30b3..d53e986eee54 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1091,9 +1091,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc,
dpu_core_perf_crtc_update(crtc, 0);
- memset(cstate->mixers, 0, sizeof(cstate->mixers));
- cstate->num_mixers = 0;
-
/* disable clk & bw control until clk & bw properties are set */
cstate->bw_control = false;
cstate->bw_split_vote = false;
@@ -1164,6 +1161,7 @@ static bool dpu_crtc_needs_dirtyfb(struct drm_crtc_state
*cstate)
}
#define MAX_HDISPLAY_SPLIT 1080
+#define MAX_CHANNELS_PER_CRTC 2
static struct msm_display_topology dpu_crtc_get_topology(
struct drm_crtc *crtc,
@@ -1208,9 +1206,14 @@ static struct msm_display_topology dpu_crtc_get_topology(
static int dpu_crtc_assign_resources(struct drm_crtc *crtc, struct
drm_crtc_state *crtc_state)
{
+ struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_CRTC];
+ struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_CRTC];
+ struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_CRTC];
+ int i, num_lm, num_ctl, num_dspp;
struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
struct dpu_global_state *global_state;
struct msm_display_topology topology;
+ struct dpu_crtc_state *cstate;
int ret;
/*
@@ -1232,6 +1235,29 @@ static int dpu_crtc_assign_resources(struct drm_crtc
*crtc, struct drm_crtc_stat
if (ret)
return ret;
+ cstate = to_dpu_crtc_state(crtc_state);
+
+ num_ctl = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
+ crtc, DPU_HW_BLK_CTL, hw_ctl,
+ ARRAY_SIZE(hw_ctl));
+ num_lm = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
+ crtc, DPU_HW_BLK_LM, hw_lm,
+ ARRAY_SIZE(hw_lm));
+ num_dspp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
+crtc, DPU_HW_BLK_DSPP, hw_dspp,
+ARRAY_SIZE(hw_dspp));
+
+ for (i = 0; i < num_lm; i++) {
+ int ctl_idx = (i < num_ctl) ? i : (num_ctl-1);
+
+ cstate->mixers[i].hw_lm = to_dpu_hw_mixer(hw_lm[i]);
+ cstate->mixers[i].lm_ctl = to_dpu_hw_ctl(hw_ctl[ctl_idx]);
+ if (i < num_dspp)
+ cstate->mixers[i].hw_dspp = to_dpu_hw_dspp(hw_dspp[i]);
+ }
+
+ cstate->num_mixers = num_lm;
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index ada9119326ca..36b677cf9c7a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1049,14 +1049,11 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
struct dpu_encoder_virt *dpu_enc;
struct msm_drm_private *priv;
struct dpu_kms *dpu_kms;
- struct dpu_crtc_state *cstate;
struct dpu_global_state *global_state;
struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
- struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
- struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_ENC] = { NULL };
struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
- int num_lm, num_ctl, num_pp, num_dsc;
+ int num_pp, num_dsc;
unsigned int dsc_mask = 0;
int i;
@@ -1083,13 +1080,8 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
drm_enc->crtc, DPU_HW_BLK_PINGPONG, hw_pp,
ARRAY_SIZE(hw_pp));
- num_ctl = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
- drm_enc->crtc, DPU_HW_BLK_CTL, hw_ctl, ARRAY_SIZE(hw_ctl));
- num_lm = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
- drm_enc->crtc, DPU_HW_BLK_LM, hw_lm, ARRAY_SIZE(hw_lm));
dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
- drm_enc->crtc, DPU_HW_BLK_DSPP, hw_dsp
[PATCH v2 11/22] drm/msm/dpu: add CWB support to dpu_hw_wb
From: Esha Bharadwaj Adjust the WB_MUX configuration to account for using dedicated CWB pingpong blocks. Signed-off-by: Esha Bharadwaj Signed-off-by: Jessica Zhang --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c index 93ff01c889b5..76d6fd614b7e 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c @@ -173,7 +173,9 @@ static void dpu_hw_wb_bind_pingpong_blk( mux_cfg = DPU_REG_READ(c, WB_MUX); mux_cfg &= ~0xf; - if (pp) + if (pp >= PINGPONG_CWB_0) + mux_cfg |= (pp < PINGPONG_CWB_2) ? 0xd : 0xb; + else if (pp) mux_cfg |= (pp - PINGPONG_0) & 0x7; else mux_cfg |= 0xf; -- 2.34.1
[PATCH v2 16/22] drm/msm/dpu: Configure CWB in writeback encoder
Cache the CWB block mask in the DPU virtual encoder and configure CWB
according to the CWB block mask within the writeback phys encoder
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 83 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 16 -
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c| 4 +-
3 files changed, 100 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index b2f0bf412451..2628f2d55cb3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -24,6 +24,7 @@
#include "dpu_hw_catalog.h"
#include "dpu_hw_intf.h"
#include "dpu_hw_ctl.h"
+#include "dpu_hw_cwb.h"
#include "dpu_hw_dspp.h"
#include "dpu_hw_dsc.h"
#include "dpu_hw_merge3d.h"
@@ -139,6 +140,7 @@ enum dpu_enc_rc_states {
* num_phys_encs.
* @hw_dsc:Handle to the DSC blocks used for the display.
* @dsc_mask: Bitmask of used DSC blocks.
+ * @cwb_mask Bitmask of used CWB muxes
* @intfs_swapped: Whether or not the phys_enc interfaces have been swapped
* for partial update right-only cases, such as pingpong
* split where virtual pingpong does not generate IRQs
@@ -185,6 +187,7 @@ struct dpu_encoder_virt {
struct dpu_hw_dsc *hw_dsc[MAX_CHANNELS_PER_ENC];
unsigned int dsc_mask;
+ unsigned int cwb_mask;
bool intfs_swapped;
@@ -1063,6 +1066,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
int num_cwb = 0;
bool is_cwb_encoder;
unsigned int dsc_mask = 0;
+ unsigned int cwb_mask = 0;
int i;
if (!drm_enc) {
@@ -1103,8 +1107,12 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
ARRAY_SIZE(hw_pp));
}
- for (i = 0; i < num_cwb; i++)
+ for (i = 0; i < num_cwb; i++) {
dpu_enc->hw_cwb[i] = to_dpu_hw_cwb(hw_cwb[i]);
+ cwb_mask |= BIT(dpu_enc->hw_cwb[i]->idx - CWB_0);
+ }
+
+ dpu_enc->cwb_mask = cwb_mask;
dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
drm_enc->crtc, DPU_HW_BLK_CTL, hw_ctl,
ARRAY_SIZE(hw_ctl));
@@ -2071,6 +2079,9 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
}
}
+ if (dpu_enc->cwb_mask)
+ dpu_encoder_helper_phys_setup_cwb(phys_enc, false);
+
/* reset the merge 3D HW block */
if (phys_enc->hw_pp && phys_enc->hw_pp->merge_3d) {
phys_enc->hw_pp->merge_3d->ops.setup_3d_mode(phys_enc->hw_pp->merge_3d,
@@ -2114,6 +2125,68 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
ctl->ops.clear_pending_flush(ctl);
}
+void dpu_encoder_helper_phys_setup_cwb(struct dpu_encoder_phys *phys_enc,
+ bool enable)
+{
+ struct dpu_encoder_virt *dpu_enc =
to_dpu_encoder_virt(phys_enc->parent);
+ struct dpu_hw_cwb *hw_cwb;
+ struct dpu_hw_cwb_setup_cfg cwb_cfg;
+
+ struct dpu_kms *dpu_kms;
+ struct dpu_global_state *global_state;
+ struct dpu_hw_blk *rt_pp_list[MAX_CHANNELS_PER_ENC];
+ int num_pp, rt_pp_idx[MAX_CHANNELS_PER_ENC];
+
+ if (!phys_enc || !phys_enc->hw_wb || !dpu_enc->cwb_mask)
+ return;
+
+ dpu_kms = phys_enc->dpu_kms;
+ global_state = dpu_kms_get_existing_global_state(dpu_kms);
+ num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
+ phys_enc->parent->crtc,
+ DPU_HW_BLK_PINGPONG, rt_pp_list,
+ ARRAY_SIZE(rt_pp_list));
+
+ if (num_pp == 0 || num_pp > MAX_CHANNELS_PER_ENC) {
+ DPU_DEBUG_ENC(dpu_enc, "invalid num_pp %d\n", num_pp);
+ return;
+ }
+
+ for (int i = 0; i < num_pp; i++) {
+ struct dpu_hw_pingpong *hw_pp =
to_dpu_hw_pingpong(rt_pp_list[i]);
+
+ for (int j = 0; j < ARRAY_SIZE(dpu_enc->hw_cwb); j++) {
+ hw_cwb = dpu_enc->hw_cwb[i];
+
+ /*
+* Even CWB muxes must take input from even real-time
+* pingpongs and odd CWB muxes must take input from odd
+* pingpongs
+*/
+ if (hw_pp->idx % 2 == hw_cwb->idx % 2) {
+ rt_pp_idx[i] = enable ? hw_pp->idx :
PINGPONG_NONE;
+ break;
+ }
+ }
+ }
+
+ /*
+* The CWB mux supports using LM or DSPP as tap points. For now,
+* always use LM tap
[PATCH v2 22/22] drm/msm/dpu: Set possible clones for all encoders
Set writeback encoders as possible clones for non-writeback encoders and
vice versa.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 32 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 7 +--
3 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 87eaaf1196c2..39dabb9eb39a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2409,6 +2409,38 @@ static int dpu_encoder_virt_add_phys_encs(
return 0;
}
+/**
+ * dpu_encoder_get_clones - Calculate the possible_clones for DPU encoder
+ * @drm_enc:DRM encoder pointer
+ * Returns: possible_clones mask
+ */
+uint32_t dpu_encoder_get_clones(struct drm_encoder *drm_enc)
+{
+ struct drm_encoder *curr;
+ int type = drm_enc->encoder_type;
+ uint32_t clone_mask = drm_encoder_mask(drm_enc);
+
+ /*
+* Set writeback as possible clones of real-time encoders and real-time
+* encoders as clones of writeback.
+*
+* Writeback encoders can't be clones of each other and real-time
+* encoders can't be clones of each other.
+*/
+ drm_for_each_encoder(curr, drm_enc->dev) {
+ if (type == DRM_MODE_ENCODER_VIRTUAL &&
+ curr->encoder_type == DRM_MODE_ENCODER_VIRTUAL)
+ continue;
+ if (type != DRM_MODE_ENCODER_VIRTUAL &&
+ curr->encoder_type != DRM_MODE_ENCODER_VIRTUAL)
+ continue;
+
+ clone_mask |= drm_encoder_mask(curr);
+ }
+
+ return clone_mask;
+}
+
static int dpu_encoder_setup_display(struct dpu_encoder_virt *dpu_enc,
struct dpu_kms *dpu_kms,
struct msm_display_info *disp_info)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index deaa0463b289..1692e7de079d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -98,6 +98,8 @@ enum dpu_intf_mode dpu_encoder_get_intf_mode(struct
drm_encoder *encoder);
*/
void dpu_encoder_virt_runtime_resume(struct drm_encoder *encoder);
+uint32_t dpu_encoder_get_clones(struct drm_encoder *drm_enc);
+
/**
* dpu_encoder_init - initialize virtual encoder object
* @dev:Pointer to drm device structure
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 47e304b357e8..5effa108f328 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -2,7 +2,7 @@
/*
* Copyright (C) 2013 Red Hat
* Copyright (c) 2014-2018, The Linux Foundation. All rights reserved.
- * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2022-2024 Qualcomm Innovation Center, Inc. All rights
reserved.
*
* Author: Rob Clark
*/
@@ -793,8 +793,11 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
return ret;
num_encoders = 0;
- drm_for_each_encoder(encoder, dev)
+ drm_for_each_encoder(encoder, dev) {
num_encoders++;
+ if (catalog->cwb_count > 0)
+ encoder->possible_clones =
dpu_encoder_get_clones(encoder);
+ }
max_crtc_count = min(catalog->mixer_count, num_encoders);
--
2.34.1
[PATCH v2 00/22] drm/msm/dpu: Add Concurrent Writeback Support for DPU 10.x+
DPU supports a single writeback session running concurrently with primary display when the CWB mux is configured properly. This series enables clone mode for DPU driver and adds support for programming the CWB mux in cases where the hardware has dedicated CWB pingpong blocks. Currently, the CWB hardware blocks have only been added to the SM8650 hardware catalog. This changes are split into two parts: The first part of the series will pull in Dmitry's patches to refactor the DPU resource manager to be based off of CRTC instead of encoder. This includes some changes (noted in the relevant commits) by me and Abhinav to fix some issues with getting the global state and refactoring the CDM allocation to work with Dmitry's changes. The second part of the series will add support for CWB by doing the following: 1) Add a DRM helper to detect if the current CRTC state is in clone mode and add an "in_clone_mode" entry to the atomic state print 2) Add the CWB mux to the hardware catalog and clarify the pingpong block index enum to specifiy which pingpong blocks are dedicated to CWB only and which ones are general use pingpong blocks 3) Add CWB as part of the devcoredump 4) Add support for configuring the CWB mux via dpu_hw_cwb ops 5) Add pending flush support for CWB 6) Add support for validating clone mode in the DPU CRTC and setting up CWB within the encoder 7) Adjust the encoder trigger flush, trigger start, and kickoff order to accomodate clone mode 8) Adjust when the frame done timer is started for clone mode 9) Define the possible clones for DPU encoders so that The feature was tested on SM8650 using IGT's kms_writeback test with the following change [1] and dumping the writeback framebuffer when in clone mode. I haven't gotten the chance to test it on DP yet, but I've validated both single and dual LM on DSI. To test CWB with IGT, you'll need to apply this series [1] and run the following command: IGT_FRAME_DUMP_PATH= FRAME_PNG_FILE_NAME= \ ./build/tests/kms_writeback -d [--run-subtest dump-valid-clones] \ [1] https://patchwork.freedesktop.org/series/137933/ --- Changes in v2: - Moved CWB hardware programming to its own dpu_hw_cwb abstraction (Dmitry) - Reserve and get assigned CWB muxes using RM API and KMS global state (Dmitry) - Dropped requirement to have only one CWB session at a time - Moved valid clone mode check to DRM framework (Dmitry and Ville) - Switch to default CWB tap point to LM as the DSPP - Dropped printing clone mode status in atomic state (Dmitry) - Call dpu_vbif_clear_errors() before dpu_encoder_kickoff() (Dmitry) - Squashed setup_input_ctrl() and setup_input_mode() into a single dpu_hw_cwb op (Dmitry) - Moved function comment docs to correct place and fixed wording of comments/commit messages (Dmitry) - Grabbed old CRTC state using proper drm_atomic_state API in dpu_crtc_atomic_check() (Dmitry) - Split HW catalog changes of adding the CWB mux block and changing the dedicated CWB pingpong indices into 2 separate commits (Dmitry) - Moved clearing the dpu_crtc_state.num_mixers to "drm/msm/dpu: fill CRTC resources in dpu_crtc.c" (Dmitry) - Fixed alignment and other formatting issues (Dmitry) - Link to v1: https://lore.kernel.org/r/20240829-concurrent-wb-v1-0-502b16ae2...@quicinc.com --- Dmitry Baryshkov (4): drm/msm/dpu: get rid of struct dpu_rm_requirements drm/msm/dpu: switch RM to use crtc_id rather than enc_id for allocation drm/msm/dpu: move resource allocation to CRTC drm/msm/dpu: fill CRTC resources in dpu_crtc.c Esha Bharadwaj (3): drm/msm/dpu: Add CWB entry to catalog for SM8650 drm/msm/dpu: add devcoredumps for cwb registers drm/msm/dpu: add CWB support to dpu_hw_wb Jessica Zhang (15): drm: add clone mode check for CRTC drm: Add valid clones check drm/msm/dpu: Specify dedicated CWB pingpong blocks drm/msm/dpu: Add dpu_hw_cwb abstraction for CWB block drm/msm/dpu: Add RM support for allocating CWB drm/msm/dpu: Add CWB to msm_display_topology drm/msm/dpu: Require modeset if clone mode status changes drm/msm/dpu: Reserve resources for CWB drm/msm/dpu: Configure CWB in writeback encoder drm/msm/dpu: Support CWB in dpu_hw_ctl drm/msm/dpu: Adjust writeback phys encoder setup for CWB drm/msm/dpu: Start frame done timer after encoder kickoff drm/msm/dpu: Skip trigger flush and start for CWB drm/msm/dpu: Reorder encoder kickoff for CWB drm/msm/dpu: Set possible clones for all encoders drivers/gpu/drm/drm_atomic_helper.c| 23 ++ drivers/gpu/drm/msm/Makefile | 1 + .../drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h| 29 +- .../gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 4 +- .../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 4 +- .../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 200 +- drivers/
[PATCH v2 02/22] drm: Add valid clones check
Check that all encoders attached to a given CRTC are valid
possible_clones of each other.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/drm_atomic_helper.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 43cdf39019a4..cc4001804fdc 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -574,6 +574,25 @@ mode_valid(struct drm_atomic_state *state)
return 0;
}
+static int drm_atomic_check_valid_clones(struct drm_atomic_state *state,
+struct drm_crtc *crtc)
+{
+ struct drm_encoder *drm_enc;
+ struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
+ crtc);
+
+ drm_for_each_encoder_mask(drm_enc, crtc->dev, crtc_state->encoder_mask)
{
+ if ((crtc_state->encoder_mask & drm_enc->possible_clones) !=
+ crtc_state->encoder_mask) {
+ DRM_DEBUG("crtc%d failed valid clone check for mask
0x%x\n",
+ crtc->base.id, crtc_state->encoder_mask);
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
/**
* drm_atomic_helper_check_modeset - validate state object for modeset changes
* @dev: DRM device
@@ -745,6 +764,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
ret = drm_atomic_add_affected_planes(state, crtc);
if (ret != 0)
return ret;
+
+ ret = drm_atomic_check_valid_clones(state, crtc);
+ if (ret != 0)
+ return ret;
}
/*
--
2.34.1
[PATCH v2 07/22] drm/msm/dpu: Add CWB entry to catalog for SM8650
From: Esha Bharadwaj
Add a new block for concurrent writeback mux to the SM8650 HW catalog
Signed-off-by: Esha Bharadwaj
Signed-off-by: Jessica Zhang
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 21 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 13 +
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h
index eb5dfff2ec4f..33f5faf4833f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h
@@ -350,6 +350,25 @@ static const struct dpu_wb_cfg sm8650_wb[] = {
},
};
+static const struct dpu_cwb_cfg sm8650_cwb[] = {
+ {
+ .name = "cwb_0", .id = CWB_0,
+ .base = 0x66200, .len = 0x8,
+ },
+ {
+ .name = "cwb_1", .id = CWB_1,
+ .base = 0x66600, .len = 0x8,
+ },
+ {
+ .name = "cwb_2", .id = CWB_2,
+ .base = 0x7E200, .len = 0x8,
+ },
+ {
+ .name = "cwb_3", .id = CWB_3,
+ .base = 0x7E600, .len = 0x8,
+ },
+};
+
static const struct dpu_intf_cfg sm8650_intf[] = {
{
.name = "intf_0", .id = INTF_0,
@@ -447,6 +466,8 @@ const struct dpu_mdss_cfg dpu_sm8650_cfg = {
.merge_3d = sm8650_merge_3d,
.wb_count = ARRAY_SIZE(sm8650_wb),
.wb = sm8650_wb,
+ .cwb_count = ARRAY_SIZE(sm8650_cwb),
+ .cwb = sm8650_cwb,
.intf_count = ARRAY_SIZE(sm8650_intf),
.intf = sm8650_intf,
.vbif_count = ARRAY_SIZE(sm8650_vbif),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 37e18e820a20..b42d8b3640e2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -621,6 +621,16 @@ struct dpu_wb_cfg {
enum dpu_clk_ctrl_type clk_ctrl;
};
+/*
+ * struct dpu_cwb_cfg : MDP CWB mux instance info
+ * @id:enum identifying this block
+ * @base: register base offset to mdss
+ * @features bit mask identifying sub-blocks/features
+ */
+struct dpu_cwb_cfg {
+ DPU_HW_BLK_INFO;
+};
+
/**
* struct dpu_vbif_dynamic_ot_cfg - dynamic OT setting
* @ppspixel per seconds
@@ -823,6 +833,9 @@ struct dpu_mdss_cfg {
u32 dspp_count;
const struct dpu_dspp_cfg *dspp;
+ u32 cwb_count;
+ const struct dpu_cwb_cfg *cwb;
+
/* Add additional block data structures here */
const struct dpu_perf_cfg *perf;
--
2.34.1
[PATCH v2 03/22] drm/msm/dpu: get rid of struct dpu_rm_requirements
From: Dmitry Baryshkov
The struct dpu_rm_requirements was used to wrap display topology and
hw resources, which meant INTF indices. As of commit ef58e0ad3436
("drm/msm/dpu: get INTF blocks directly rather than through RM") the hw
resources struct was removed, leaving struct dpu_rm_requirements
containing a single field (topology). Remove the useless wrapper.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 71 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 2 +-
3 files changed, 25 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 3b171bf227d1..6293e716a1c3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -691,7 +691,7 @@ static int dpu_encoder_virt_atomic_check(
if (!crtc_state->active_changed || crtc_state->enable)
ret = dpu_rm_reserve(&dpu_kms->rm, global_state,
- drm_enc, crtc_state, topology);
+ drm_enc, crtc_state, &topology);
}
trace_dpu_enc_atomic_check_flags(DRMID(drm_enc), adj_mode->flags);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 44938ba7a2b7..8193c3d579df 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -4,6 +4,7 @@
* Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
*/
+#include "msm_drv.h"
#define pr_fmt(fmt)"[drm:%s] " fmt, __func__
#include "dpu_kms.h"
#include "dpu_hw_lm.h"
@@ -26,14 +27,6 @@ static inline bool reserved_by_other(uint32_t *res_map, int
idx,
return res_map[idx] && res_map[idx] != enc_id;
}
-/**
- * struct dpu_rm_requirements - Reservation requirements parameter bundle
- * @topology: selected topology for the display
- */
-struct dpu_rm_requirements {
- struct msm_display_topology topology;
-};
-
int dpu_rm_init(struct drm_device *dev,
struct dpu_rm *rm,
const struct dpu_mdss_cfg *cat,
@@ -231,14 +224,13 @@ static int _dpu_rm_get_lm_peer(struct dpu_rm *rm, int
primary_idx)
* mixer in rm->pingpong_blks[].
* @dspp_idx: output parameter, index of dspp block attached to the layer
* mixer in rm->dspp_blks[].
- * @reqs: input parameter, rm requirements for HW blocks needed in the
- * datapath.
+ * @topology: selected topology for the display
* Return: true if lm matches all requirements, false otherwise
*/
static bool _dpu_rm_check_lm_and_get_connected_blks(struct dpu_rm *rm,
struct dpu_global_state *global_state,
uint32_t enc_id, int lm_idx, int *pp_idx, int *dspp_idx,
- struct dpu_rm_requirements *reqs)
+ struct msm_display_topology *topology)
{
const struct dpu_lm_cfg *lm_cfg;
int idx;
@@ -263,7 +255,7 @@ static bool _dpu_rm_check_lm_and_get_connected_blks(struct
dpu_rm *rm,
}
*pp_idx = idx;
- if (!reqs->topology.num_dspp)
+ if (!topology->num_dspp)
return true;
idx = lm_cfg->dspp - DSPP_0;
@@ -285,7 +277,7 @@ static bool _dpu_rm_check_lm_and_get_connected_blks(struct
dpu_rm *rm,
static int _dpu_rm_reserve_lms(struct dpu_rm *rm,
struct dpu_global_state *global_state,
uint32_t enc_id,
- struct dpu_rm_requirements *reqs)
+ struct msm_display_topology *topology)
{
int lm_idx[MAX_BLOCKS];
@@ -293,14 +285,14 @@ static int _dpu_rm_reserve_lms(struct dpu_rm *rm,
int dspp_idx[MAX_BLOCKS] = {0};
int i, lm_count = 0;
- if (!reqs->topology.num_lm) {
- DPU_ERROR("invalid number of lm: %d\n", reqs->topology.num_lm);
+ if (!topology->num_lm) {
+ DPU_ERROR("invalid number of lm: %d\n", topology->num_lm);
return -EINVAL;
}
/* Find a primary mixer */
for (i = 0; i < ARRAY_SIZE(rm->mixer_blks) &&
- lm_count < reqs->topology.num_lm; i++) {
+ lm_count < topology->num_lm; i++) {
if (!rm->mixer_blks[i])
continue;
@@ -309,14 +301,14 @@ static int _dpu_rm_reserve_lms(struct dpu_rm *rm,
if (!_dpu_rm_check_lm_and_get_connected_blks(rm, global_state,
enc_id, i, &pp_idx[lm_count],
- &dspp_idx[lm_count], reqs)) {
+ &dspp_idx[lm_count], topology)) {
continue;
}
++lm_count;
/* Valid primary mixer found, find matching peers */
-
[PATCH v2 19/22] drm/msm/dpu: Start frame done timer after encoder kickoff
Starting the frame done timer before the encoder is finished kicking off
can lead to unnecessary frame done timeouts when the device is
experiencing heavy load (ex. when debug logs are enabled).
Thus, create a separate API for starting the encoder frame done timer and
call it after the encoder kickoff is finished
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 4 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 25 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 4 +++-
3 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index f20e44e9fc05..e8c80ea12866 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -970,8 +970,10 @@ void dpu_crtc_commit_kickoff(struct drm_crtc *crtc)
dpu_vbif_clear_errors(dpu_kms);
- drm_for_each_encoder_mask(encoder, crtc->dev, crtc->state->encoder_mask)
+ drm_for_each_encoder_mask(encoder, crtc->dev,
crtc->state->encoder_mask) {
dpu_encoder_kickoff(encoder);
+ dpu_encoder_start_frame_done_timer(encoder);
+ }
reinit_completion(&dpu_crtc->frame_done_comp);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 7337bb3ae7ca..ac3ff13b65c3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1941,18 +1941,16 @@ bool dpu_encoder_is_valid_for_commit(struct drm_encoder
*drm_enc)
return true;
}
-void dpu_encoder_kickoff(struct drm_encoder *drm_enc)
+/**
+ * dpu_encoder_start_frame_done_timer - Start the encoder frame done timer
+ * @drm_enc: Pointer to drm encoder structure
+ */
+void dpu_encoder_start_frame_done_timer(struct drm_encoder *drm_enc)
{
struct dpu_encoder_virt *dpu_enc;
- struct dpu_encoder_phys *phys;
unsigned long timeout_ms;
- unsigned int i;
- DPU_ATRACE_BEGIN("encoder_kickoff");
dpu_enc = to_dpu_encoder_virt(drm_enc);
-
- trace_dpu_enc_kickoff(DRMID(drm_enc));
-
timeout_ms = DPU_ENCODER_FRAME_DONE_TIMEOUT_FRAMES * 1000 /
drm_mode_vrefresh(&drm_enc->crtc->state->adjusted_mode);
@@ -1960,6 +1958,19 @@ void dpu_encoder_kickoff(struct drm_encoder *drm_enc)
mod_timer(&dpu_enc->frame_done_timer,
jiffies + msecs_to_jiffies(timeout_ms));
+}
+
+void dpu_encoder_kickoff(struct drm_encoder *drm_enc)
+{
+ struct dpu_encoder_virt *dpu_enc;
+ struct dpu_encoder_phys *phys;
+ unsigned int i;
+
+ DPU_ATRACE_BEGIN("encoder_kickoff");
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+
+ trace_dpu_enc_kickoff(DRMID(drm_enc));
+
/* All phys encs are ready to go, trigger the kickoff */
_dpu_encoder_kickoff_phys(dpu_enc);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 0d27e50384f0..deaa0463b289 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0-only */
/*
- * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2022-2024 Qualcomm Innovation Center, Inc. All rights
reserved.
* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
* Copyright (C) 2013 Red Hat
* Author: Rob Clark
@@ -210,4 +210,6 @@ void dpu_encoder_cleanup_wb_job(struct drm_encoder *drm_enc,
*/
bool dpu_encoder_is_valid_for_commit(struct drm_encoder *drm_enc);
+void dpu_encoder_start_frame_done_timer(struct drm_encoder *drm_enc);
+
#endif /* __DPU_ENCODER_H__ */
--
2.34.1
[PATCH v2 04/22] drm/msm/dpu: switch RM to use crtc_id rather than enc_id for allocation
From: Dmitry Baryshkov
Up to now the driver has been using encoder to allocate hardware
resources. Switch it to use CRTC id in preparation for the next step.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 12 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 182 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 12 +-
4 files changed, 108 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 6293e716a1c3..4a9edcfbcaae 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -687,11 +687,11 @@ static int dpu_encoder_virt_atomic_check(
* Dont allocate when active is false.
*/
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
- dpu_rm_release(global_state, drm_enc);
+ dpu_rm_release(global_state, crtc_state->crtc);
if (!crtc_state->active_changed || crtc_state->enable)
ret = dpu_rm_reserve(&dpu_kms->rm, global_state,
- drm_enc, crtc_state, &topology);
+ crtc_state->crtc, &topology);
}
trace_dpu_enc_atomic_check_flags(DRMID(drm_enc), adj_mode->flags);
@@ -1125,14 +1125,14 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
/* Query resource that have been reserved in atomic check step. */
num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
- drm_enc->base.id, DPU_HW_BLK_PINGPONG, hw_pp,
+ drm_enc->crtc, DPU_HW_BLK_PINGPONG, hw_pp,
ARRAY_SIZE(hw_pp));
num_ctl = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
- drm_enc->base.id, DPU_HW_BLK_CTL, hw_ctl, ARRAY_SIZE(hw_ctl));
+ drm_enc->crtc, DPU_HW_BLK_CTL, hw_ctl, ARRAY_SIZE(hw_ctl));
num_lm = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
- drm_enc->base.id, DPU_HW_BLK_LM, hw_lm, ARRAY_SIZE(hw_lm));
+ drm_enc->crtc, DPU_HW_BLK_LM, hw_lm, ARRAY_SIZE(hw_lm));
dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
- drm_enc->base.id, DPU_HW_BLK_DSPP, hw_dspp,
+ drm_enc->crtc, DPU_HW_BLK_DSPP, hw_dspp,
ARRAY_SIZE(hw_dspp));
for (i = 0; i < MAX_CHANNELS_PER_ENC; i++)
@@ -1140,7 +1140,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
: NULL;
num_dsc = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
- drm_enc->base.id,
DPU_HW_BLK_DSC,
+ drm_enc->crtc, DPU_HW_BLK_DSC,
hw_dsc, ARRAY_SIZE(hw_dsc));
for (i = 0; i < num_dsc; i++) {
dpu_enc->hw_dsc[i] = to_dpu_hw_dsc(hw_dsc[i]);
@@ -1154,7 +1154,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
struct dpu_hw_blk *hw_cdm = NULL;
dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
- drm_enc->base.id, DPU_HW_BLK_CDM,
+ drm_enc->crtc, DPU_HW_BLK_CDM,
&hw_cdm, 1);
dpu_enc->cur_master->hw_cdm = hw_cdm ? to_dpu_hw_cdm(hw_cdm) :
NULL;
}
@@ -2021,7 +2021,7 @@ static void dpu_encoder_helper_reset_mixers(struct
dpu_encoder_phys *phys_enc)
global_state = dpu_kms_get_existing_global_state(phys_enc->dpu_kms);
num_lm = dpu_rm_get_assigned_resources(&phys_enc->dpu_kms->rm,
global_state,
- phys_enc->parent->base.id, DPU_HW_BLK_LM, hw_lm,
ARRAY_SIZE(hw_lm));
+ phys_enc->parent->crtc, DPU_HW_BLK_LM, hw_lm,
ARRAY_SIZE(hw_lm));
for (i = 0; i < num_lm; i++) {
hw_mixer[i] = to_dpu_hw_mixer(hw_lm[i]);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 935ff6fd172c..4fdc5f933261 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -122,12 +122,12 @@ struct dpu_global_state {
struct dpu_rm *rm;
- uint32_t pingpong_to_enc_id[PINGPONG_MAX - PINGPONG_0];
- uint32_t mixer_to_enc_id[LM_MAX - LM_0];
- uint32_t ctl_to_enc_id[CTL_MAX - CTL_0];
- uint32_t dspp_to_enc_id[DSPP_MAX - DSPP_0];
- uint32_t dsc_to_enc_id[DSC_MAX - DSC_0];
- uint32_t cdm_to_enc_id;
+ uint32_t pingpong_to_crtc_id[PINGPONG_MAX - PINGPONG_0];
+ uint32_t mixer_to_crtc_id[LM_MAX - LM_0];
+ uint32_t ctl_to_crtc_id[CTL_MAX - CTL_0];
+
[PATCH v2 20/22] drm/msm/dpu: Skip trigger flush and start for CWB
For concurrent writeback, the real time encoder is responsible for
trigger flush and trigger start. Return early for trigger start and
trigger flush for the concurrent writeback encoders.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index ac3ff13b65c3..87eaaf1196c2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1488,6 +1488,7 @@ static void dpu_encoder_off_work(struct work_struct *work)
static void _dpu_encoder_trigger_flush(struct drm_encoder *drm_enc,
struct dpu_encoder_phys *phys, uint32_t extra_flush_bits)
{
+ struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
struct dpu_hw_ctl *ctl;
int pending_kickoff_cnt;
u32 ret = UINT_MAX;
@@ -1505,6 +1506,15 @@ static void _dpu_encoder_trigger_flush(struct
drm_encoder *drm_enc,
pending_kickoff_cnt = dpu_encoder_phys_inc_pending(phys);
+ /* Return early if encoder is writeback and in clone mode */
+ if (drm_enc->encoder_type == DRM_MODE_ENCODER_VIRTUAL &&
+ dpu_enc->cwb_mask) {
+ DPU_DEBUG("encoder %d skip flush for concurrent writeback
encoder\n",
+ DRMID(drm_enc));
+ return;
+ }
+
+
if (extra_flush_bits && ctl->ops.update_pending_flush)
ctl->ops.update_pending_flush(ctl, extra_flush_bits);
@@ -1527,6 +1537,8 @@ static void _dpu_encoder_trigger_flush(struct drm_encoder
*drm_enc,
*/
static void _dpu_encoder_trigger_start(struct dpu_encoder_phys *phys)
{
+ struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(phys->parent);
+
if (!phys) {
DPU_ERROR("invalid argument(s)\n");
return;
@@ -1537,6 +1549,12 @@ static void _dpu_encoder_trigger_start(struct
dpu_encoder_phys *phys)
return;
}
+ if (phys->parent->encoder_type == DRM_MODE_ENCODER_VIRTUAL &&
+ dpu_enc->cwb_mask) {
+ DPU_DEBUG("encoder %d CWB enabled, skipping\n",
DRMID(phys->parent));
+ return;
+ }
+
if (phys->ops.trigger_start && phys->enable_state != DPU_ENC_DISABLED)
phys->ops.trigger_start(phys);
}
--
2.34.1
[PATCH v2 08/22] drm/msm/dpu: Specify dedicated CWB pingpong blocks
Change pingpong index and names to distinguish between general use
pingpong blocks and pingpong blocks dedicated for concurrent writeback
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 8
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 8
5 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h
index 33f5faf4833f..bfb64b7c1a47 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h
@@ -252,25 +252,25 @@ static const struct dpu_pingpong_cfg sm8650_pp[] = {
.merge_3d = MERGE_3D_2,
.intr_done = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31),
}, {
- .name = "pingpong_6", .id = PINGPONG_6,
+ .name = "pingpong_cwb_0", .id = PINGPONG_CWB_0,
.base = 0x66000, .len = 0,
.features = BIT(DPU_PINGPONG_DITHER),
.sblk = &sc7280_pp_sblk,
.merge_3d = MERGE_3D_3,
}, {
- .name = "pingpong_7", .id = PINGPONG_7,
+ .name = "pingpong_cwb_1", .id = PINGPONG_CWB_1,
.base = 0x66400, .len = 0,
.features = BIT(DPU_PINGPONG_DITHER),
.sblk = &sc7280_pp_sblk,
.merge_3d = MERGE_3D_3,
}, {
- .name = "pingpong_8", .id = PINGPONG_8,
+ .name = "pingpong_cwb_2", .id = PINGPONG_CWB_2,
.base = 0x7e000, .len = 0,
.features = BIT(DPU_PINGPONG_DITHER),
.sblk = &sc7280_pp_sblk,
.merge_3d = MERGE_3D_4,
}, {
- .name = "pingpong_9", .id = PINGPONG_9,
+ .name = "pingpong_cwb_3", .id = PINGPONG_CWB_3,
.base = 0x7e400, .len = 0,
.features = BIT(DPU_PINGPONG_DITHER),
.sblk = &sc7280_pp_sblk,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
index a1779c5597ae..08742472f9cc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
@@ -257,13 +257,13 @@ static const struct dpu_pingpong_cfg sm8450_pp[] = {
.merge_3d = MERGE_3D_2,
.intr_done = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31),
}, {
- .name = "pingpong_6", .id = PINGPONG_6,
+ .name = "pingpong_cwb_0", .id = PINGPONG_CWB_0,
.base = 0x65800, .len = 0,
.features = BIT(DPU_PINGPONG_DITHER),
.sblk = &sc7280_pp_sblk,
.merge_3d = MERGE_3D_3,
}, {
- .name = "pingpong_7", .id = PINGPONG_7,
+ .name = "pingpong_cwb_1", .id = PINGPONG_CWB_1,
.base = 0x65c00, .len = 0,
.features = BIT(DPU_PINGPONG_DITHER),
.sblk = &sc7280_pp_sblk,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
index ad48defa154f..173f6f53a30c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
@@ -251,13 +251,13 @@ static const struct dpu_pingpong_cfg sm8550_pp[] = {
.merge_3d = MERGE_3D_2,
.intr_done = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31),
}, {
- .name = "pingpong_6", .id = PINGPONG_6,
+ .name = "pingpong_cwb_0", .id = PINGPONG_CWB_0,
.base = 0x66000, .len = 0,
.features = BIT(DPU_PINGPONG_DITHER),
.sblk = &sc7280_pp_sblk,
.merge_3d = MERGE_3D_3,
}, {
- .name = "pingpong_7", .id = PINGPONG_7,
+ .name = "pingpong_cwb_1", .id = PINGPONG_CWB_1,
.base = 0x66400, .len = 0,
.features = BIT(DPU_PINGPONG_DITHER),
.sblk = &sc7280_pp_sblk,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h
index a3e60ac70689..592ba9abd1ad 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h
@@ -251,13 +251,13 @@ static const struct dpu_pingpong_cfg x1e80100_pp[] = {
.merge_3d = MERGE_3D_2,
.intr_done = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31),
}, {
- .name = "pingpong_6", .id = PINGPONG_6,
+ .name = "pingpong_cwb_0", .id = PINGPONG_CWB_0,
.base = 0x66000, .l
[PATCH v2 15/22] drm/msm/dpu: Reserve resources for CWB
Add support for RM to reserve dedicated CWB pingpongs and CWB muxes
For concurrent writeback, even-indexed CWB muxes must be assigned to
even-indexed LMs and odd-indexed CWB muxes for odd-indexed LMs. The same
even/odd rule applies for dedicated CWB pingpongs.
Track the CWB muxes in the global state and add a CWB-specific helper to
reserve the correct CWB muxes and dedicated pingpongs following the
even/odd rule.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 34 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 84 +
4 files changed, 117 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 36b677cf9c7a..b2f0bf412451 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2,7 +2,7 @@
/*
* Copyright (C) 2013 Red Hat
* Copyright (c) 2014-2018, 2020-2021 The Linux Foundation. All rights
reserved.
- * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights
reserved.
+ * Copyright (c) 2022-2024 Qualcomm Innovation Center, Inc. All rights
reserved.
*
* Author: Rob Clark
*/
@@ -28,6 +28,7 @@
#include "dpu_hw_dsc.h"
#include "dpu_hw_merge3d.h"
#include "dpu_hw_cdm.h"
+#include "dpu_hw_cwb.h"
#include "dpu_formats.h"
#include "dpu_encoder_phys.h"
#include "dpu_crtc.h"
@@ -133,6 +134,9 @@ enum dpu_enc_rc_states {
* @cur_slave: As above but for the slave encoder.
* @hw_pp: Handle to the pingpong blocks used for the display. No.
* pingpong blocks can be different than num_phys_encs.
+ * @hw_cwb:Handle to the CWB muxes used for concurrent writeback
+ * display. Number of CWB muxes can be different than
+ * num_phys_encs.
* @hw_dsc:Handle to the DSC blocks used for the display.
* @dsc_mask: Bitmask of used DSC blocks.
* @intfs_swapped: Whether or not the phys_enc interfaces have been swapped
@@ -177,6 +181,7 @@ struct dpu_encoder_virt {
struct dpu_encoder_phys *cur_master;
struct dpu_encoder_phys *cur_slave;
struct dpu_hw_pingpong *hw_pp[MAX_CHANNELS_PER_ENC];
+ struct dpu_hw_cwb *hw_cwb[MAX_CHANNELS_PER_ENC];
struct dpu_hw_dsc *hw_dsc[MAX_CHANNELS_PER_ENC];
unsigned int dsc_mask;
@@ -1053,7 +1058,10 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
+ struct dpu_hw_blk *hw_cwb[MAX_CHANNELS_PER_ENC];
int num_pp, num_dsc;
+ int num_cwb = 0;
+ bool is_cwb_encoder;
unsigned int dsc_mask = 0;
int i;
@@ -1067,6 +1075,8 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
priv = drm_enc->dev->dev_private;
dpu_kms = to_dpu_kms(priv->kms);
+ is_cwb_encoder = drm_crtc_in_clone_mode(crtc_state) &&
+ dpu_enc->disp_info.intf_type == INTF_WB;
global_state = dpu_kms_get_existing_global_state(dpu_kms);
if (IS_ERR_OR_NULL(global_state)) {
@@ -1077,9 +1087,25 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
trace_dpu_enc_mode_set(DRMID(drm_enc));
/* Query resource that have been reserved in atomic check step. */
- num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
- drm_enc->crtc, DPU_HW_BLK_PINGPONG, hw_pp,
- ARRAY_SIZE(hw_pp));
+ if (is_cwb_encoder) {
+ num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm,
global_state,
+ drm_enc->crtc,
+ DPU_HW_BLK_DCWB_PINGPONG,
+ hw_pp,
ARRAY_SIZE(hw_pp));
+ num_cwb = dpu_rm_get_assigned_resources(&dpu_kms->rm,
global_state,
+ drm_enc->crtc,
+ DPU_HW_BLK_CWB,
+ hw_cwb,
ARRAY_SIZE(hw_cwb));
+ } else {
+ num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm,
global_state,
+ drm_enc->crtc,
+ DPU_HW_BLK_PINGPONG,
hw_pp,
+ ARRAY_SIZE(hw_pp));
+ }
+
+ for (i = 0; i < num_cwb; i++)
+ dpu_enc->hw_cwb[i] = to_dpu_hw_cwb(hw_cwb[i]);
+
dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
[PATCH v2 14/22] drm/msm/dpu: Require modeset if clone mode status changes
If the clone mode enabled status is changing, a modeset needs to happen
so that the resources can be reassigned
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index a7850bf844db..f20e44e9fc05 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1268,6 +1268,8 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
{
struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
crtc);
+ struct drm_crtc_state *old_crtc_state =
drm_atomic_get_old_crtc_state(state,
+
crtc);
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
@@ -1279,6 +1281,8 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
int rc = 0;
bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
+ bool clone_mode_requested = drm_crtc_in_clone_mode(old_crtc_state);
+ bool clone_mode_enabled = drm_crtc_in_clone_mode(crtc_state);
/* there might be cases where encoder needs a modeset too */
drm_for_each_encoder_mask(drm_enc, crtc->dev, crtc_state->encoder_mask)
{
@@ -1286,6 +1290,10 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
crtc_state->mode_changed = true;
}
+ if ((clone_mode_requested && !clone_mode_enabled) ||
+ (!clone_mode_requested && clone_mode_enabled))
+ crtc_state->mode_changed = true;
+
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
rc = dpu_crtc_assign_resources(crtc, crtc_state);
if (rc < 0)
--
2.34.1
[PATCH v2 09/22] drm/msm/dpu: add devcoredumps for cwb registers
From: Esha Bharadwaj
Implement instance of snapshot function to dump new registers used
for cwb
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Esha Bharadwaj
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 9bcae53c4f45..47e304b357e8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -989,6 +989,11 @@ static void dpu_kms_mdp_snapshot(struct msm_disp_state
*disp_state, struct msm_k
dpu_kms->mmio + cat->mdp[0].base, "top");
}
+ /* dump CWB sub-blocks HW regs info */
+ for (i = 0; i < cat->cwb_count; i++)
+ msm_disp_snapshot_add_block(disp_state, cat->cwb[i].len,
+ dpu_kms->mmio + cat->cwb[i].base,
cat->cwb[i].name);
+
/* dump DSC sub-blocks HW regs info */
for (i = 0; i < cat->dsc_count; i++) {
base = dpu_kms->mmio + cat->dsc[i].base;
--
2.34.1
[PATCH v2 18/22] drm/msm/dpu: Adjust writeback phys encoder setup for CWB
Adjust QoS remapper, OT limit, and CDP parameters to account for
concurrent writeback
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index d0bf23d4da5f..2fe818d38118 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -68,7 +68,7 @@ static void dpu_encoder_phys_wb_set_ot_limit(
ot_params.num = hw_wb->idx - WB_0;
ot_params.width = phys_enc->cached_mode.hdisplay;
ot_params.height = phys_enc->cached_mode.vdisplay;
- ot_params.is_wfd = true;
+ ot_params.is_wfd = !dpu_encoder_helper_get_cwb(phys_enc);
ot_params.frame_rate = drm_mode_vrefresh(&phys_enc->cached_mode);
ot_params.vbif_idx = hw_wb->caps->vbif_idx;
ot_params.rd = false;
@@ -111,7 +111,7 @@ static void dpu_encoder_phys_wb_set_qos_remap(
qos_params.vbif_idx = hw_wb->caps->vbif_idx;
qos_params.xin_id = hw_wb->caps->xin_id;
qos_params.num = hw_wb->idx - WB_0;
- qos_params.is_rt = false;
+ qos_params.is_rt = dpu_encoder_helper_get_cwb(phys_enc);
DPU_DEBUG("[qos_remap] wb:%d vbif:%d xin:%d is_rt:%d\n",
qos_params.num,
@@ -174,6 +174,7 @@ static void dpu_encoder_phys_wb_setup_fb(struct
dpu_encoder_phys *phys_enc,
struct dpu_encoder_phys_wb *wb_enc = to_dpu_encoder_phys_wb(phys_enc);
struct dpu_hw_wb *hw_wb;
struct dpu_hw_wb_cfg *wb_cfg;
+ u32 cdp_usage;
if (!phys_enc || !phys_enc->dpu_kms || !phys_enc->dpu_kms->catalog) {
DPU_ERROR("invalid encoder\n");
@@ -182,6 +183,10 @@ static void dpu_encoder_phys_wb_setup_fb(struct
dpu_encoder_phys *phys_enc,
hw_wb = phys_enc->hw_wb;
wb_cfg = &wb_enc->wb_cfg;
+ if (dpu_encoder_helper_get_cwb(phys_enc))
+ cdp_usage = DPU_PERF_CDP_USAGE_RT;
+ else
+ cdp_usage = DPU_PERF_CDP_USAGE_NRT;
wb_cfg->intf_mode = phys_enc->intf_mode;
wb_cfg->roi.x1 = 0;
@@ -199,7 +204,7 @@ static void dpu_encoder_phys_wb_setup_fb(struct
dpu_encoder_phys *phys_enc,
const struct dpu_perf_cfg *perf =
phys_enc->dpu_kms->catalog->perf;
hw_wb->ops.setup_cdp(hw_wb, wb_cfg->dest.format,
-
perf->cdp_cfg[DPU_PERF_CDP_USAGE_NRT].wr_enable);
+perf->cdp_cfg[cdp_usage].wr_enable);
}
if (hw_wb->ops.setup_outaddress)
--
2.34.1
[PATCH v2 10/22] drm/msm/dpu: Add dpu_hw_cwb abstraction for CWB block
The CWB mux has its own registers and set of operations. Add dpu_hw_cwb
abstraction to allow driver to configure the CWB mux.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/Makefile| 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cwb.c | 73 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cwb.h | 70 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 5 +-
4 files changed, 148 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 13110fcc46a8..e05bb740246b 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -77,6 +77,7 @@ msm-display-$(CONFIG_DRM_MSM_DPU) += \
disp/dpu1/dpu_hw_catalog.o \
disp/dpu1/dpu_hw_cdm.o \
disp/dpu1/dpu_hw_ctl.o \
+ disp/dpu1/dpu_hw_cwb.o \
disp/dpu1/dpu_hw_dsc.o \
disp/dpu1/dpu_hw_dsc_1_2.o \
disp/dpu1/dpu_hw_interrupts.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cwb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cwb.c
new file mode 100644
index ..5fbf52906ea9
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cwb.c
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#include
+#include "dpu_hw_cwb.h"
+
+#define CWB_MUX 0x000
+#define CWB_MODE 0x004
+
+/* CWB mux block bit definitions */
+#define CWB_MUX_MASK GENMASK(3, 0)
+#define CWB_MODE_MASKGENMASK(2, 0)
+
+static void dpu_hw_cwb_config(struct dpu_hw_cwb *ctx,
+ struct dpu_hw_cwb_setup_cfg *cwb_cfg)
+{
+ struct dpu_hw_blk_reg_map *c = &ctx->hw;
+ int cwb_mux_cfg = 0xF;
+ enum dpu_pingpong pp;
+ enum cwb_mode_input input;
+
+ if (!cwb_cfg)
+ return;
+
+ input = cwb_cfg->input;
+ pp = cwb_cfg->pp_idx;
+
+ if (input >= INPUT_MODE_MAX)
+ return;
+
+ /*
+* The CWB_MUX register takes the pingpong index for the real-time
+* display
+*/
+ if ((pp != PINGPONG_NONE) && (pp < PINGPONG_MAX))
+ cwb_mux_cfg = FIELD_PREP(CWB_MUX_MASK, pp - PINGPONG_0);
+
+ input = FIELD_PREP(CWB_MODE_MASK, input);
+
+ DPU_REG_WRITE(c, CWB_MUX, cwb_mux_cfg);
+ DPU_REG_WRITE(c, CWB_MODE, input);
+}
+
+/**
+ * dpu_hw_cwb_init() - Initializes the writeback hw driver object with cwb.
+ * @dev: Corresponding device for devres management
+ * @cfg: wb_path catalog entry for which driver object is required
+ * @addr: mapped register io address of MDP
+ * Return: Error code or allocated dpu_hw_wb context
+ */
+struct dpu_hw_cwb *dpu_hw_cwb_init(struct drm_device *dev,
+ const struct dpu_cwb_cfg *cfg,
+ void __iomem *addr)
+{
+ struct dpu_hw_cwb *c;
+
+ if (!addr)
+ return ERR_PTR(-EINVAL);
+
+ c = drmm_kzalloc(dev, sizeof(*c), GFP_KERNEL);
+ if (!c)
+ return ERR_PTR(-ENOMEM);
+
+ c->hw.blk_addr = addr + cfg->base;
+ c->hw.log_mask = DPU_DBG_MASK_CWB;
+
+ c->idx = cfg->id;
+ c->ops.config_cwb = dpu_hw_cwb_config;
+
+ return c;
+}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cwb.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cwb.h
new file mode 100644
index ..96b6edf6b2bb
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cwb.h
@@ -0,0 +1,70 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#ifndef _DPU_HW_CWB_H
+#define _DPU_HW_CWB_H
+
+#include "dpu_hw_util.h"
+
+struct dpu_hw_cwb;
+
+enum cwb_mode_input {
+ INPUT_MODE_LM_OUT,
+ INPUT_MODE_DSPP_OUT,
+ INPUT_MODE_MAX
+};
+
+/**
+ * struct dpu_hw_cwb_setup_cfg : Describes configuration for CWB mux
+ * @pp_idx:Index of the real-time pinpong that the CWB mux will
+ * feed the CWB mux
+ * @input: Input tap point
+ */
+struct dpu_hw_cwb_setup_cfg {
+ enum dpu_pingpong pp_idx;
+ enum cwb_mode_input input;
+};
+
+/**
+ *
+ * struct dpu_hw_cwb_ops : Interface to the cwb hw driver functions
+ * @config_cwb: configure CWB mux
+ */
+struct dpu_hw_cwb_ops {
+ void (*config_cwb)(struct dpu_hw_cwb *ctx,
+ struct dpu_hw_cwb_setup_cfg *cwb_cfg);
+};
+
+/**
+ * struct dpu_hw_cwb : CWB mux driver object
+ * @base: Hardware block base structure
+ * @hw: Block hardware details
+ * @idx: CWB index
+ * @ops: handle to operations possible for this CWB
+ */
+struct dpu_hw_cwb {
+ struct dpu_hw_blk base;
+ struct dpu_hw_blk_reg_map hw;
+
+ enum dpu_cwb idx;
+
+ struct dpu_hw_cwb_ops ops;
+};
+
+/**
+ * dpu_hw_cwb - convert base object dpu_hw_base to container
+ * @hw: Pointer to base hardware block
+ * return: Pointer to hardware block container
+ */
+stati
[PATCH v2 12/22] drm/msm/dpu: Add RM support for allocating CWB
Add support for allocating the concurrent writeback mux as part of the
WB allocation
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 17 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 2 ++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index bc99b04eae3a..96c80cf9f6ad 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -1,15 +1,15 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
- * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2023-2024 Qualcomm Innovation Center, Inc. All rights
reserved.
*/
-#include "msm_drv.h"
#define pr_fmt(fmt)"[drm:%s] " fmt, __func__
#include "dpu_kms.h"
#include "dpu_hw_lm.h"
#include "dpu_hw_ctl.h"
#include "dpu_hw_cdm.h"
+#include "dpu_hw_cwb.h"
#include "dpu_hw_pingpong.h"
#include "dpu_hw_sspp.h"
#include "dpu_hw_intf.h"
@@ -113,6 +113,19 @@ int dpu_rm_init(struct drm_device *dev,
rm->hw_wb[wb->id - WB_0] = hw;
}
+ for (i = 0; i < cat->cwb_count; i++) {
+ struct dpu_hw_cwb *hw;
+ const struct dpu_cwb_cfg *cwb = &cat->cwb[i];
+
+ hw = dpu_hw_cwb_init(dev, cwb, mmio);
+ if (IS_ERR(hw)) {
+ rc = PTR_ERR(hw);
+ DPU_ERROR("failed cwb object creation: err %d\n", rc);
+ goto fail;
+ }
+ rm->cwb_blks[cwb->id - CWB_0] = &hw->base;
+ }
+
for (i = 0; i < cat->ctl_count; i++) {
struct dpu_hw_ctl *hw;
const struct dpu_ctl_cfg *ctl = &cat->ctl[i];
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
index 36a0b6ed628d..8b968655d05b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
@@ -20,6 +20,7 @@ struct dpu_global_state;
* @ctl_blks: array of ctl hardware resources
* @hw_intf: array of intf hardware resources
* @hw_wb: array of wb hardware resources
+ * @hw_cwb: array of cwb hardware resources
* @dspp_blks: array of dspp hardware resources
* @hw_sspp: array of sspp hardware resources
* @cdm_blk: cdm hardware resource
@@ -30,6 +31,7 @@ struct dpu_rm {
struct dpu_hw_blk *ctl_blks[CTL_MAX - CTL_0];
struct dpu_hw_intf *hw_intf[INTF_MAX - INTF_0];
struct dpu_hw_wb *hw_wb[WB_MAX - WB_0];
+ struct dpu_hw_blk *cwb_blks[CWB_MAX - CWB_0];
struct dpu_hw_blk *dspp_blks[DSPP_MAX - DSPP_0];
struct dpu_hw_blk *merge_3d_blks[MERGE_3D_MAX - MERGE_3D_0];
struct dpu_hw_blk *dsc_blks[DSC_MAX - DSC_0];
--
2.34.1
[PATCH v2 21/22] drm/msm/dpu: Reorder encoder kickoff for CWB
Add a helper that will handle the correct order of the encoder kickoffs
for concurrent writeback.
For concurrent writeback, the realtime encoder must always kickoff last
as it will call the trigger flush and start.
This avoids the following scenario where the writeback encoder
increments the pending kickoff count after the WB_DONE interrupt is
fired:
If the realtime encoder is kicked off first, the encoder kickoff will
flush/start the encoder and increment the pending kickoff count. The
WB_DONE interrupt then fires (before the writeback encoder is kicked
off). When the writeback encoder enters its kickoff, it will skip the
flush/start (due to CWB being enabled) and hit a frame done timeout
as the frame was kicked off (and the WB_DONE interrupt fired) without
the pending kickoff count being incremented.
In addition, the writeback timer should only start after the realtime
encoder is kicked off to ensure that we don't get timeouts when the
system has a heavy load (ex. when debug logs are enabled)
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 74 ++--
1 file changed, 60 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index e8c80ea12866..4365e9cf609d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -928,6 +928,45 @@ static int _dpu_crtc_wait_for_frame_done(struct drm_crtc
*crtc)
return rc;
}
+static int dpu_crtc_kickoff_clone_mode(struct drm_crtc *crtc)
+{
+ struct drm_encoder *encoder;
+ struct drm_encoder *rt_encoder = NULL, *wb_encoder;
+ struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
+
+ /* Find encoder for real time display */
+ drm_for_each_encoder_mask(encoder, crtc->dev,
+ crtc->state->encoder_mask) {
+ if (encoder->encoder_type == DRM_MODE_ENCODER_VIRTUAL)
+ wb_encoder = encoder;
+ else
+ rt_encoder = encoder;
+ }
+
+ if (!rt_encoder || !wb_encoder) {
+ DRM_DEBUG_ATOMIC("real time or wb encoder not found\n");
+ return -EINVAL;
+ }
+
+ dpu_encoder_prepare_for_kickoff(wb_encoder);
+ dpu_encoder_prepare_for_kickoff(rt_encoder);
+
+ dpu_vbif_clear_errors(dpu_kms);
+
+ /*
+* Kickoff real time encoder last as it's the encoder that
+* will do the flush
+*/
+ dpu_encoder_kickoff(wb_encoder);
+ dpu_encoder_kickoff(rt_encoder);
+
+ /* Don't start frame done timers until the kickoffs have finished */
+ dpu_encoder_start_frame_done_timer(wb_encoder);
+ dpu_encoder_start_frame_done_timer(rt_encoder);
+
+ return 0;
+}
+
void dpu_crtc_commit_kickoff(struct drm_crtc *crtc)
{
struct drm_encoder *encoder;
@@ -952,13 +991,27 @@ void dpu_crtc_commit_kickoff(struct drm_crtc *crtc)
goto end;
}
}
- /*
-* Encoder will flush/start now, unless it has a tx pending. If so, it
-* may delay and flush at an irq event (e.g. ppdone)
-*/
- drm_for_each_encoder_mask(encoder, crtc->dev,
- crtc->state->encoder_mask)
- dpu_encoder_prepare_for_kickoff(encoder);
+
+ if (drm_crtc_in_clone_mode(crtc->state)) {
+ if (dpu_crtc_kickoff_clone_mode(crtc))
+ goto end;
+ } else {
+ /*
+* Encoder will flush/start now, unless it has a tx pending.
+* If so, it may delay and flush at an irq event (e.g. ppdone)
+*/
+ drm_for_each_encoder_mask(encoder, crtc->dev,
+ crtc->state->encoder_mask)
+ dpu_encoder_prepare_for_kickoff(encoder);
+
+ dpu_vbif_clear_errors(dpu_kms);
+
+ drm_for_each_encoder_mask(encoder, crtc->dev,
+ crtc->state->encoder_mask) {
+ dpu_encoder_kickoff(encoder);
+ dpu_encoder_start_frame_done_timer(encoder);
+ }
+ }
if (atomic_inc_return(&dpu_crtc->frame_pending) == 1) {
/* acquire bandwidth and other resources */
@@ -968,13 +1021,6 @@ void dpu_crtc_commit_kickoff(struct drm_crtc *crtc)
dpu_crtc->play_count++;
- dpu_vbif_clear_errors(dpu_kms);
-
- drm_for_each_encoder_mask(encoder, crtc->dev,
crtc->state->encoder_mask) {
- dpu_encoder_kickoff(encoder);
- dpu_encoder_start_frame_done_timer(encoder);
- }
-
reinit_completion(&dpu_crtc->frame_done_comp);
end:
--
2.34.1
[PATCH v2 05/22] drm/msm/dpu: move resource allocation to CRTC
From: Dmitry Baryshkov
All resource allocation is centered around the LMs. Then other blocks
(except DSCs) are allocated basing on the LMs that was selected, and LM
powers up the CRTC rather than the encoder.
Moreover if at some point the driver supports encoder cloning,
allocating resources from the encoder will be incorrect, as all clones
will have different encoder IDs, while LMs are to be shared by these
encoders.
Signed-off-by: Dmitry Baryshkov
[quic_abhin...@quicinc.com: Refactored resource allocation for CDM]
Signed-off-by: Abhinav Kumar
[quic_jessz...@quicinc.com: Changed to grabbing exising global state]
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 86
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 201 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 19 +++
3 files changed, 183 insertions(+), 123 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 4c1be2f0555f..b918c80d30b3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1163,6 +1163,78 @@ static bool dpu_crtc_needs_dirtyfb(struct drm_crtc_state
*cstate)
return false;
}
+#define MAX_HDISPLAY_SPLIT 1080
+
+static struct msm_display_topology dpu_crtc_get_topology(
+ struct drm_crtc *crtc,
+ struct dpu_kms *dpu_kms,
+ struct drm_crtc_state *crtc_state)
+{
+ struct drm_display_mode *mode = &crtc_state->adjusted_mode;
+ struct msm_display_topology topology = {0};
+ struct drm_encoder *drm_enc;
+
+ drm_for_each_encoder_mask(drm_enc, crtc->dev, crtc_state->encoder_mask)
+ dpu_encoder_update_topology(drm_enc, &topology,
crtc_state->state,
+ &crtc_state->adjusted_mode);
+
+ /*
+* Datapath topology selection
+*
+* Dual display
+* 2 LM, 2 INTF ( Split display using 2 interfaces)
+*
+* Single display
+* 1 LM, 1 INTF
+* 2 LM, 1 INTF (stream merge to support high resolution interfaces)
+*
+* Add dspps to the reservation requirements if ctm is requested
+*/
+
+ if (topology.num_intf == 2)
+ topology.num_lm = 2;
+ else if (topology.num_dsc == 2)
+ topology.num_lm = 2;
+ else if (dpu_kms->catalog->caps->has_3d_merge)
+ topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT) ? 2 : 1;
+ else
+ topology.num_lm = 1;
+
+ if (crtc_state->ctm)
+ topology.num_dspp = topology.num_lm;
+
+ return topology;
+}
+
+static int dpu_crtc_assign_resources(struct drm_crtc *crtc, struct
drm_crtc_state *crtc_state)
+{
+ struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
+ struct dpu_global_state *global_state;
+ struct msm_display_topology topology;
+ int ret;
+
+ /*
+* Release and Allocate resources on every modeset
+* Dont allocate when enable is false.
+*/
+ global_state = dpu_kms_get_existing_global_state(dpu_kms);
+ if (IS_ERR(global_state))
+ return PTR_ERR(global_state);
+
+ dpu_rm_release(global_state, crtc);
+
+ if (!crtc_state->enable)
+ return 0;
+
+ topology = dpu_crtc_get_topology(crtc, dpu_kms, crtc_state);
+ ret = dpu_rm_reserve(&dpu_kms->rm, global_state,
+crtc, &topology);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
@@ -1174,10 +1246,24 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
const struct drm_plane_state *pstate;
struct drm_plane *plane;
+ struct drm_encoder *drm_enc;
+
int rc = 0;
bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
+ /* there might be cases where encoder needs a modeset too */
+ drm_for_each_encoder_mask(drm_enc, crtc->dev, crtc_state->encoder_mask)
{
+ if (dpu_encoder_needs_modeset(drm_enc, crtc_state->state))
+ crtc_state->mode_changed = true;
+ }
+
+ if (drm_atomic_crtc_needs_modeset(crtc_state)) {
+ rc = dpu_crtc_assign_resources(crtc, crtc_state);
+ if (rc < 0)
+ return rc;
+ }
+
if (!crtc_state->enable ||
!drm_atomic_crtc_effectively_active(crtc_state)) {
DRM_DEBUG_ATOMIC("crtc%d -> enable %d, active %d, skip
atomic_check\n",
crtc->base.id, crtc_state->enable,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 4a9edcfbcaae..ada9119326ca 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
[PATCH v2 17/22] drm/msm/dpu: Support CWB in dpu_hw_ctl
The CWB mux has a pending flush bit and *_active register.
Add support for configuring them within the dpu_hw_ctl layer.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 13 ++
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c| 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 30 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 15 ++-
4 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 2628f2d55cb3..7337bb3ae7ca 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2108,6 +2108,7 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
intf_cfg.stream_sel = 0; /* Don't care value for video mode */
intf_cfg.mode_3d = dpu_encoder_helper_get_3d_blend_mode(phys_enc);
intf_cfg.dsc = dpu_encoder_helper_get_dsc(phys_enc);
+ intf_cfg.cwb = dpu_enc->cwb_mask;
if (phys_enc->hw_intf)
intf_cfg.intf = phys_enc->hw_intf->idx;
@@ -2130,6 +2131,7 @@ void dpu_encoder_helper_phys_setup_cwb(struct
dpu_encoder_phys *phys_enc,
{
struct dpu_encoder_virt *dpu_enc =
to_dpu_encoder_virt(phys_enc->parent);
struct dpu_hw_cwb *hw_cwb;
+ struct dpu_hw_ctl *hw_ctl;
struct dpu_hw_cwb_setup_cfg cwb_cfg;
struct dpu_kms *dpu_kms;
@@ -2140,6 +2142,14 @@ void dpu_encoder_helper_phys_setup_cwb(struct
dpu_encoder_phys *phys_enc,
if (!phys_enc || !phys_enc->hw_wb || !dpu_enc->cwb_mask)
return;
+ hw_ctl = phys_enc->hw_ctl;
+
+ if (!phys_enc->hw_ctl) {
+ DPU_DEBUG("[wb:%d] no ctl assigned\n",
+ phys_enc->hw_wb->idx - WB_0);
+ return;
+ }
+
dpu_kms = phys_enc->dpu_kms;
global_state = dpu_kms_get_existing_global_state(dpu_kms);
num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
@@ -2184,6 +2194,9 @@ void dpu_encoder_helper_phys_setup_cwb(struct
dpu_encoder_phys *phys_enc,
cwb_cfg.pp_idx = rt_pp_idx[i];
hw_cwb->ops.config_cwb(hw_cwb, &cwb_cfg);
+
+ if (hw_ctl->ops.update_pending_flush_cwb)
+ hw_ctl->ops.update_pending_flush_cwb(hw_ctl,
hw_cwb->idx);
}
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index e88c4d91041f..d0bf23d4da5f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -236,6 +236,7 @@ static void dpu_encoder_phys_wb_setup_ctl(struct
dpu_encoder_phys *phys_enc)
intf_cfg.intf = DPU_NONE;
intf_cfg.wb = hw_wb->idx;
+ intf_cfg.cwb = dpu_encoder_helper_get_cwb(phys_enc);
if (mode_3d && hw_pp && hw_pp->merge_3d)
intf_cfg.merge_3d = hw_pp->merge_3d->idx;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 2e50049f2f85..792687b010ee 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
- * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2022-2024 Qualcomm Innovation Center, Inc. All rights
reserved.
*/
#include
@@ -31,12 +31,14 @@
#define CTL_MERGE_3D_ACTIVE 0x0E4
#define CTL_DSC_ACTIVE0x0E8
#define CTL_WB_ACTIVE 0x0EC
+#define CTL_CWB_ACTIVE0x0F0
#define CTL_INTF_ACTIVE 0x0F4
#define CTL_CDM_ACTIVE0x0F8
#define CTL_FETCH_PIPE_ACTIVE 0x0FC
#define CTL_MERGE_3D_FLUSH0x100
#define CTL_DSC_FLUSH0x104
#define CTL_WB_FLUSH 0x108
+#define CTL_CWB_FLUSH 0x10C
#define CTL_INTF_FLUSH0x110
#define CTL_CDM_FLUSH0x114
#define CTL_PERIPH_FLUSH 0x128
@@ -53,6 +55,7 @@
#define PERIPH_IDX 30
#define INTF_IDX 31
#define WB_IDX 16
+#define CWB_IDX 28
#define DSPP_IDX 29 /* From DPU hw rev 7.x.x */
#define CTL_INVALID_BIT 0x
#define CTL_DEFAULT_GROUP_ID 0xf
@@ -110,6 +113,7 @@ static inline void dpu_hw_ctl_clear_pending_flush(struct
dpu_hw_ctl *ctx)
ctx->pending_flush_mask = 0x0;
ctx->pending_intf_flush_mask = 0;
ctx->pending_wb_flush_mask = 0;
+ ctx->pending_cwb_flush_mask = 0;
ctx->pending_merge_3d_flush_mask = 0;
ctx->pending_dsc_flush_mask = 0;
ctx->pending_cdm
[PATCH v2 13/22] drm/msm/dpu: Add CWB to msm_display_topology
Add the cwb_enabled flag to msm_display topology and adjust the toplogy
to account for concurrent writeback
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 10 --
drivers/gpu/drm/msm/msm_drv.h| 2 ++
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index d53e986eee54..a7850bf844db 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1176,6 +1176,8 @@ static struct msm_display_topology dpu_crtc_get_topology(
dpu_encoder_update_topology(drm_enc, &topology,
crtc_state->state,
&crtc_state->adjusted_mode);
+ topology.cwb_enabled = drm_crtc_in_clone_mode(crtc_state);
+
/*
* Datapath topology selection
*
@@ -1189,9 +1191,9 @@ static struct msm_display_topology dpu_crtc_get_topology(
* Add dspps to the reservation requirements if ctm is requested
*/
- if (topology.num_intf == 2)
+ if (topology.num_intf == 2 && !topology.cwb_enabled)
topology.num_lm = 2;
- else if (topology.num_dsc == 2)
+ else if (topology.num_dsc == 2 && !topology.cwb_enabled)
topology.num_lm = 2;
else if (dpu_kms->catalog->caps->has_3d_merge)
topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT) ? 2 : 1;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 96c80cf9f6ad..04df3056d75a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -371,8 +371,14 @@ static int _dpu_rm_reserve_ctls(
int i = 0, j, num_ctls;
bool needs_split_display;
- /* each hw_intf needs its own hw_ctrl to program its control path */
- num_ctls = top->num_intf;
+ /*
+* For non-CWB mode, each hw_intf needs its own hw_ctl to program its
+* control path. Hardcode num_ctls to 1 if CWB is enabled
+*/
+ if (top->cwb_enabled)
+ num_ctls = 1;
+ else
+ num_ctls = top->num_intf;
needs_split_display = _dpu_rm_needs_split_display(top);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 0d3adf398bc1..8a2a3705f117 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -1,5 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0-only */
/*
+ * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
* Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
* Copyright (C) 2013 Red Hat
* Author: Rob Clark
@@ -88,6 +89,7 @@ struct msm_display_topology {
u32 num_dspp;
u32 num_dsc;
bool needs_cdm;
+ bool cwb_enabled;
};
/* Commit/Event thread specific structure */
--
2.34.1
Re: [PATCH] dt-bindings: lcdif: Add support for specifying display with timings
On Mon, Sep 23, 2024 at 03:57:44PM +0200, Lukasz Majewski wrote:
> Up till now the fsl,lcdif.yaml was requiring the "port" property as a
> must have to specify the display interface on iMX devices.
>
> However, it shall also be possible to specify the display only with
> passing its timing parameters (h* and v* ones) via "display" property:
> (as in
> Documentation/devicetree/bindings/display/panel/display-timings.yaml).
>
> Such approach has already been used (also in the mainline) with several
> imx28, imx5x and imx6q devices.
>
> This change allows them to pass the DT_SCHEMA check without issues.
>
> Signed-off-by: Lukasz Majewski
> ---
> .../bindings/display/fsl,lcdif.yaml | 51 ++-
> 1 file changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> index 8e3a98aeec32..14bb64b5b72d 100644
> --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> @@ -50,6 +50,10 @@ properties:
>- const: disp_axi
> minItems: 1
>
> + display:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description: The phandle for display timing information
> +
>dmas:
> items:
>- description: DMA specifier for the RX DMA channel.
> @@ -64,6 +68,9 @@ properties:
>- description: LCDIF Error interrupt
> minItems: 1
>
> + lcd-supply:
> +description: Regulator for LCD supply voltage.
> +
>power-domains:
> maxItems: 1
>
> @@ -76,7 +83,10 @@ required:
>- reg
>- clocks
>- interrupts
> - - port
> +
> +patternProperties:
> + 'display([0-9])':
This allows for 'foodisplay0bar'. You need start and end anchors.
And it doesn't even have to be a node because there are no contraints
here. You need 'type: object' and then to define what's in the node.
> +description: Node with display timing parameters
>
> additionalProperties: false
>
> @@ -197,5 +207,42 @@ examples:
> };
> };
> };
> -
> + - |
> +lcdif: lcdif@8003 {
> +compatible = "fsl,imx28-lcdif";
> +reg = <0x8003 0x2000>;
> +interrupts = <38>;
> +clocks = <&clks 55>;
> +dmas = <&dma_apbh 13>;
> +dma-names = "rx";
> +pinctrl-names = "default";
> +pinctrl-0 = <&lcdif_24bit_pins_a>, <&lcdif_sync_pins_bttc>,
> + <&lcdif_reset_pins_bttc>;
> +lcd-supply = <®_3v3>;
> +display = <&display0>;
> +status = "okay";
Don't need status in the examples.
> +
> +bits-per-pixel = <32>;
> +bus-width = <24>;
> +display-timings {
> +native-mode = <&timing0>;
> +timing0: timing0 {
> +clock-frequency = <650>;
> +hactive = <320>;
> +vactive = <240>;
> +hfront-porch = <20>;
> +hback-porch = <38>;
> +hsync-len = <30>;
> +vfront-porch = <4>;
> +vback-porch = <14>;
> +vsync-len = <4>;
> +hsync-active = <0>;
> +vsync-active = <0>;
> +de-active = <0>;
> +pixelclk-active = <1>;
> +};
> +};
> +};
> +};
> ...
> --
> 2.39.2
>
Re: [PATCH] drm/vkms: Add missing check for CRTC initialization
Hi Louis,
On 9/6/24 13:15, Louis Chauvet wrote:
CRTC initialization call drm_mode_crtc_set_gamma_size without the proper
checks, introduce this check to avoid issues.
Signed-off-by: Louis Chauvet
Applied to misc/kernel.git (drm-misc-next).
Best Regards,
- Maíra
---
drivers/gpu/drm/vkms/vkms_crtc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 40b4d084e3ce..e4f93dfbd071 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -287,7 +287,12 @@ int vkms_crtc_init(struct drm_device *dev, struct drm_crtc
*crtc,
drm_crtc_helper_add(crtc, &vkms_crtc_helper_funcs);
- drm_mode_crtc_set_gamma_size(crtc, VKMS_LUT_SIZE);
+ ret = drm_mode_crtc_set_gamma_size(crtc, VKMS_LUT_SIZE);
+ if (ret) {
+ DRM_ERROR("Failed to set gamma size\n");
+ return ret;
+ }
+
drm_crtc_enable_color_mgmt(crtc, 0, false, VKMS_LUT_SIZE);
spin_lock_init(&vkms_out->lock);
---
base-commit: a6bb1f77a94335de67dba12e7f52651c115b82d2
change-id: 20240906-vkms-add-missing-check-e1b6ee8d1b39
Best regards,
Re: [PATCH v2 16/22] drm/msm/dpu: Configure CWB in writeback encoder
On 9/24/2024 4:41 PM, Dmitry Baryshkov wrote:
On Tue, Sep 24, 2024 at 03:59:32PM GMT, Jessica Zhang wrote:
Cache the CWB block mask in the DPU virtual encoder and configure CWB
according to the CWB block mask within the writeback phys encoder
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 83 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 16 -
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c| 4 +-
3 files changed, 100 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index b2f0bf412451..2628f2d55cb3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -24,6 +24,7 @@
#include "dpu_hw_catalog.h"
#include "dpu_hw_intf.h"
#include "dpu_hw_ctl.h"
+#include "dpu_hw_cwb.h"
#include "dpu_hw_dspp.h"
#include "dpu_hw_dsc.h"
#include "dpu_hw_merge3d.h"
@@ -139,6 +140,7 @@ enum dpu_enc_rc_states {
*num_phys_encs.
* @hw_dsc: Handle to the DSC blocks used for the display.
* @dsc_mask: Bitmask of used DSC blocks.
+ * @cwb_mask Bitmask of used CWB muxes
* @intfs_swapped:Whether or not the phys_enc interfaces have been swapped
*for partial update right-only cases, such as pingpong
*split where virtual pingpong does not generate IRQs
@@ -185,6 +187,7 @@ struct dpu_encoder_virt {
struct dpu_hw_dsc *hw_dsc[MAX_CHANNELS_PER_ENC];
unsigned int dsc_mask;
+ unsigned int cwb_mask;
bool intfs_swapped;
@@ -1063,6 +1066,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct drm_encoder *drm_enc,
int num_cwb = 0;
bool is_cwb_encoder;
unsigned int dsc_mask = 0;
+ unsigned int cwb_mask = 0;
int i;
if (!drm_enc) {
@@ -1103,8 +1107,12 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
ARRAY_SIZE(hw_pp));
}
- for (i = 0; i < num_cwb; i++)
+ for (i = 0; i < num_cwb; i++) {
dpu_enc->hw_cwb[i] = to_dpu_hw_cwb(hw_cwb[i]);
+ cwb_mask |= BIT(dpu_enc->hw_cwb[i]->idx - CWB_0);
+ }
+
+ dpu_enc->cwb_mask = cwb_mask;
dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
drm_enc->crtc, DPU_HW_BLK_CTL, hw_ctl,
ARRAY_SIZE(hw_ctl));
@@ -2071,6 +2079,9 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
}
}
+ if (dpu_enc->cwb_mask)
+ dpu_encoder_helper_phys_setup_cwb(phys_enc, false);
+
/* reset the merge 3D HW block */
if (phys_enc->hw_pp && phys_enc->hw_pp->merge_3d) {
phys_enc->hw_pp->merge_3d->ops.setup_3d_mode(phys_enc->hw_pp->merge_3d,
@@ -2114,6 +2125,68 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
ctl->ops.clear_pending_flush(ctl);
}
+void dpu_encoder_helper_phys_setup_cwb(struct dpu_encoder_phys *phys_enc,
+ bool enable)
+{
+ struct dpu_encoder_virt *dpu_enc =
to_dpu_encoder_virt(phys_enc->parent);
+ struct dpu_hw_cwb *hw_cwb;
+ struct dpu_hw_cwb_setup_cfg cwb_cfg;
+
+ struct dpu_kms *dpu_kms;
+ struct dpu_global_state *global_state;
+ struct dpu_hw_blk *rt_pp_list[MAX_CHANNELS_PER_ENC];
+ int num_pp, rt_pp_idx[MAX_CHANNELS_PER_ENC];
+
+ if (!phys_enc || !phys_enc->hw_wb || !dpu_enc->cwb_mask)
+ return;
We have already dereferened phys_enc, so checking that it's not NULL is
futile. Also we know that the function is only called if cwb_mask is not
zero, so the last check is also useless.
Hi Dmitry,
Ack.
+
+ dpu_kms = phys_enc->dpu_kms;
+ global_state = dpu_kms_get_existing_global_state(dpu_kms);
+ num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
+ phys_enc->parent->crtc,
+ DPU_HW_BLK_PINGPONG, rt_pp_list,
+ ARRAY_SIZE(rt_pp_list));
+
+ if (num_pp == 0 || num_pp > MAX_CHANNELS_PER_ENC) {
+ DPU_DEBUG_ENC(dpu_enc, "invalid num_pp %d\n", num_pp);
+ return;
+ }
+
+ for (int i = 0; i < num_pp; i++) {
+ struct dpu_hw_pingpong *hw_pp =
to_dpu_hw_pingpong(rt_pp_list[i]);
+
+ for (int j = 0; j < ARRAY_SIZE(dpu_enc->hw_cwb); j++) {
+ hw_cwb = dpu_enc->hw_cwb[i];
+
+ /*
+* Even CWB muxes must take input from even real-time
+* pingpongs and odd CWB muxes must take input from odd
+* pingpongs
+*/
+ if (hw_pp->idx %
Re: [PATCH v2 14/22] drm/msm/dpu: Require modeset if clone mode status changes
On 9/24/2024 4:25 PM, Dmitry Baryshkov wrote:
On Tue, Sep 24, 2024 at 03:59:30PM GMT, Jessica Zhang wrote:
If the clone mode enabled status is changing, a modeset needs to happen
so that the resources can be reassigned
Sima's comment regarding crtc_state->mode_changed seems to be ignored...
Not ignored. One of us has to take that up. There is a broader cleanup
required for that.
We can sync up on how to tackle this : whether it needs to be in this
series or push another one cleaning up all the instances.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index a7850bf844db..f20e44e9fc05 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1268,6 +1268,8 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
{
struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
crtc);
+ struct drm_crtc_state *old_crtc_state =
drm_atomic_get_old_crtc_state(state,
+
crtc);
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
@@ -1279,6 +1281,8 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
int rc = 0;
bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
+ bool clone_mode_requested = drm_crtc_in_clone_mode(old_crtc_state);
+ bool clone_mode_enabled = drm_crtc_in_clone_mode(crtc_state);
/* there might be cases where encoder needs a modeset too */
drm_for_each_encoder_mask(drm_enc, crtc->dev, crtc_state->encoder_mask)
{
@@ -1286,6 +1290,10 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
crtc_state->mode_changed = true;
}
+ if ((clone_mode_requested && !clone_mode_enabled) ||
+ (!clone_mode_requested && clone_mode_enabled))
+ crtc_state->mode_changed = true;
+
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
rc = dpu_crtc_assign_resources(crtc, crtc_state);
if (rc < 0)
--
2.34.1
NULL pointer dereference after ib test on ring 7 succeeded
After rebuilding current Linus git head with: dma-mapping: report unlimited DMA addressing in IOMMU DMA path b348b6d17fd1d5d89b86db602f02bea54a754bd8 applied, the radeon module load gets further before hitting another NULL pointer dereference: [ 17.777472] [drm] radeon kernel modesetting enabled. [ 17.777536] radeon :00:01.0: vgaarb: deactivate vga console [ 17.778276] Console: switching to colour dummy device 80x25 [ 17.778519] [drm] initializing kernel modesetting (ARUBA 0x1002:0x990C 0x1002:0x0123 0x00). [ 17.778600] ATOM BIOS: 113 [ 17.778658] radeon :00:01.0: VRAM: 768M 0x - 0x2FFF (768M used) [ 17.778661] radeon :00:01.0: GTT: 1024M 0x3000 - 0x6FFF [ 17.778665] [drm] Detected VRAM RAM=768M, BAR=256M [ 17.778665] [drm] RAM width 64bits DDR [ 17.778764] [drm] radeon: 768M of VRAM memory ready [ 17.778766] [drm] radeon: 1024M of GTT memory ready. [ 17.778777] [drm] Loading ARUBA Microcode [ 18.038084] [drm] Internal thermal controller without fan control [ 18.038425] [drm] radeon: dpm initialized [ 18.333508] [drm] Found VCE firmware/feedback version 50.0.1 / 17! [ 18.333548] [drm] GART: num cpu pages 262144, num gpu pages 262144 [ 18.353624] [drm] PCIE GART of 1024M enabled (table at 0x001D6000). [ 18.353755] radeon :00:01.0: WB enabled [ 18.353758] radeon :00:01.0: fence driver on ring 0 use gpu addr 0x3c00 [ 18.354136] radeon :00:01.0: fence driver on ring 5 use gpu addr 0x00075a18 [ 18.374206] radeon :00:01.0: fence driver on ring 6 use gpu addr 0x3c18 [ 18.374208] radeon :00:01.0: fence driver on ring 7 use gpu addr 0x3c1c [ 18.374210] radeon :00:01.0: fence driver on ring 1 use gpu addr 0x3c04 [ 18.374212] radeon :00:01.0: fence driver on ring 2 use gpu addr 0x3c08 [ 18.374213] radeon :00:01.0: fence driver on ring 3 use gpu addr 0x3c0c [ 18.374214] radeon :00:01.0: fence driver on ring 4 use gpu addr 0x3c10 [ 18.374469] radeon :00:01.0: radeon: MSI limited to 32-bit [ 18.374525] radeon :00:01.0: radeon: using MSI. [ 18.374604] [drm] radeon: irq initialized. [ 18.392823] [drm] ring test on 0 succeeded in 3 usecs [ 18.392831] [drm] ring test on 3 succeeded in 4 usecs [ 18.392836] [drm] ring test on 4 succeeded in 3 usecs [ 18.438526] [drm] ring test on 5 succeeded in 2 usecs [ 18.458380] [drm] UVD initialized successfully. [ 18.567616] [drm] ring test on 6 succeeded in 18 usecs [ 18.567626] [drm] ring test on 7 succeeded in 3 usecs [ 18.567627] [drm] VCE initialized successfully. [ 18.567686] snd_hda_intel :00:01.1: bound :00:01.0 (ops radeon_audio_component_bind_ops [radeon]) [ 18.567925] [drm] ib test on ring 0 succeeded in 0 usecs [ 18.567968] [drm] ib test on ring 3 succeeded in 0 usecs [ 18.568008] [drm] ib test on ring 4 succeeded in 0 usecs [ 19.094527] [drm] ib test on ring 5 succeeded [ 19.257713] mc: Linux media interface: v0.10 [ 19.638235] [drm] ib test on ring 6 succeeded [ 20.017069] usb 1-3: dvb_usb_v2: found a 'Realtek RTL2832U reference design' in warm state [ 20.048473] usb 1-3: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [ 20.048493] dvbdev: DVB: registering new adapter (Realtek RTL2832U reference design) [ 20.048497] usb 1-3: media controller created [ 20.049487] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered. [ 20.150361] [drm] ib test on ring 7 succeeded [ 20.150700] BUG: kernel NULL pointer dereference, address: 0050 [ 20.150702] #PF: supervisor read access in kernel mode [ 20.150704] #PF: error_code(0x) - not-present page [ 20.150705] PGD 0 P4D 0 [ 20.150707] Oops: Oops: [#1] PREEMPT_RT SMP NOPTI [ 20.150710] CPU: 0 UID: 0 PID: 446 Comm: udevd Not tainted 6.11.0+ #6122 [ 20.150713] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./F2A78M-HD2, BIOS F2 05/28/2014 [ 20.150714] RIP: 0010:drm_dp_aux_register+0x59/0x110 [drm_display_helper] [ 20.150732] Code: a1 c0 48 85 f6 48 89 83 b8 00 00 00 74 1c 48 8d bb b4 03 00 00 ba 30 00 00 00 e8 52 e5 60 db 48 8d 7b 08 5b 5d e9 b7 ea 37 db <48> 8b 70 50 48 85 f6 75 db 48 8b 30 eb d6 48 8d ab 88 04 00 00 48 [ 20.150734] RSP: 0018:9eb8013cb960 EFLAGS: 00010246 [ 20.150736] RAX: RBX: 8f1983bfc508 RCX: c0bd1bc0 [ 20.150737] RDX: c0a1de40 RSI: RDI: 8f1983bfc9f0 [ 20.150738] RBP: 8f1983bfc9f0 R08: 8f199ca70008 R09: c0c0c0c0 [ 20.150739] R10: R11: 0001 R12: 8f199da9af50 [ 20.150740] R13: 8f199da9b092 R14: 8f199da9af2e R15: 0018 [ 20.150741] FS: 7ff9b9e6a840() GS:8f1caf80() knlGS: [ 20.150743] CS: 0010 DS: ES:
Re: [RFC PATCH 0/4] Linaro restricted heap
Hi Jens, On Fri, 30 Aug 2024 at 08:04, Jens Wiklander wrote: > This patch set is based on top of Yong Wu's restricted heap patch set [1]. > It's also a continuation on Olivier's Add dma-buf secure-heap patch set [2]. > > The Linaro restricted heap uses genalloc in the kernel to manage the heap > carvout. This is a difference from the Mediatek restricted heap which > relies on the secure world to manage the carveout. Calling this the 'genalloc heap' would be much more clear. Cheers, Daniel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 Artem S. Tashkinov (a...@gmx.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |ANSWERED --- Comment #80 from Artem S. Tashkinov (a...@gmx.com) --- If you're still affected, please try kernels 6.10.11 or 6.11. If the bug is reproducible, please file a new one here: https://gitlab.freedesktop.org/drm/amd/-/issues -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH] MAINTAINERS: Add myself as VKMS Maintainer
Hi Louis, On 9/10/24 12:10, Louis Chauvet wrote: I've been actively working on VKMS to provide new features and participated in reviews and testing. To help Maìra with her work, add myself as co-maintainer of VKMS. Signed-off-by: Louis Chauvet I see that you're now a developer in the drm/misc repo. Therefore, I applied this patch to misc/kernel.git (drm-misc-next). Thanks for volunteering! Best Regards, - Maíra --- Hi everyone, This series [1] has been waiting for a while now, it was proposed first in February. The first iterations had few reactions (thanks to Arthur, Pekka, Maìra, ...), but since v8 (in May) no major issues were reported, Maìra seemed satisfied, and only minor cosmetic changes were reported. Two other series ([2] and [3]), that I submitted first in May, did not have receive any reactions. In addition, there is also some significant addition to VKMS being proposed, such as ConfigFS support, and without a clear maintainer having the time to review and approve these changes, these changes have very little changes to get in. VKMS is not a fundamental driver for "normal" Linux users, but I had some feedback from userspace developpers that VKMS could be a very good testing tool if only it had more features (I think P0xx formats were asked to test HDR for example). This could also help to detect issues in DRM core by emulating a wide range of configurations. I believe the only active maintainer is Maìra, but as she's mentioned before, she doesn't have much time to work on VKMS. So, I'd like to volunteer as a maintainer. I have plenty of time to dedicate to VKMS. I hope I've gained enough understanding of VKMS to be helful with this role. I am eager to move forward and improve this subsystem. I've also talked to Sean about this, and he agrees that it would be good if I could commit code to drm-misc. [1]: https://lore.kernel.org/all/20240809-yuv-v10-0-1a7c76416...@bootlin.com/ [2]: https://lore.kernel.org/all/20240814-b4-new-color-formats-v2-0-8b3499cfe...@bootlin.com/ [3]: https://lore.kernel.org/all/20240814-writeback_line_by_line-v2-0-36541c717...@bootlin.com/ --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 10430778c998b57944c1a6c5f07d676127e47faa..62f10356e11ab7fa9c8f79ba63b335eb6580d0a8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7340,6 +7340,7 @@ DRM DRIVER FOR VIRTUAL KERNEL MODESETTING (VKMS) M:Rodrigo Siqueira M:Melissa Wen M:Maíra Canal +M: Louis Chauvet R:Haneen Mohammed R:Daniel Vetter L:dri-devel@lists.freedesktop.org --- base-commit: da3ea35007d0af457a0afc87e84fddaebc4e0b63 change-id: 20240910-vkms-maintainer-7b3d2210cc1b Best regards,
[PATCH] drm: Add check for encoder in intel_get_crtc_new_encoder()
If the video card driver could not find the connector assigned to the
current video controller, or if the hardware status has changed so that
a pre-existing connector is no longer active, none of the state
connectors will meet the assignment criteria for the current crtc video
controller.
In the drm_WARN function, encoder->base.dev is called, so
'&encoder->base.dev' will be dereferenced since encoder will still be
initialized NULL.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: e12d6218fda2 ("drm/i915: Reduce bigjoiner special casing")
Cc: sta...@vger.kernel.org
Signed-off-by: George Rurikov
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index b4ef4d59da1a..1f25b12e5f67 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -819,9 +819,11 @@ intel_get_crtc_new_encoder(const struct intel_atomic_state
*state,
num_encoders++;
}
- drm_WARN(state->base.dev, num_encoders != 1,
+ if (encoder) {
+ drm_WARN(state->base.dev, num_encoders != 1,
"%d encoders for pipe %c\n",
num_encoders, pipe_name(primary_crtc->pipe));
+ }
return encoder;
}
--
2.34.1
Заявление о конфиденциальности
Данное электронное письмо и любые приложения к нему являются конфиденциальными
и предназначены исключительно для адресата. Если Вы не являетесь адресатом
данного письма, пожалуйста, уведомите немедленно отправителя, не раскрывайте
содержание другим лицам, не используйте его в каких-либо целях, не храните и не
копируйте информацию любым способом.
Re: [PATCH] MAINTAINERS: remove myself as a VKMS maintainer
Hi Siqueira, On 9/11/24 10:50, Rodrigo Siqueira wrote: I haven't been able to follow or review the work on the driver for a long time and I don't see the situation improving anytime soon. Hence, this commit removes me from the maintainers list. Signed-off-by: Rodrigo Siqueira Applied to misc/kernel.git (drm-misc-next). Best Regards, - Maíra --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 333ed0718175..1e6356a1b6c7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7346,7 +7346,6 @@ T:git https://gitlab.freedesktop.org/drm/misc/kernel.git F:drivers/gpu/drm/udl/ DRM DRIVER FOR VIRTUAL KERNEL MODESETTING (VKMS) -M: Rodrigo Siqueira M:Maíra Canal R:Haneen Mohammed R:Simona Vetter
Re: [PATCH] drm/vkms: Suppress context imbalance sparse warning
Hi Louis,
On 9/12/24 12:25, Louis Chauvet wrote:
The functions `vkms_crtc_atomic_begin` and `vkms_crtc_atomic_flush` are
responsible for locking and unlocking a mutex, respectively. Add the
`__acquires` and `__releases` annotations to these functions to prevent
the associated sparse warning about context imbalance.
Signed-off-by: Louis Chauvet
When I was applying this patch, I got the following warning:
137f51649b04 (HEAD -> drm-misc-next) drm/vkms: Suppress context
imbalance sparse warning
-:4: WARNING:EMAIL_SUBJECT: A patch subject line should describe the
change not the tool that found it
#4:
Subject: [PATCH] drm/vkms: Suppress context imbalance sparse warning
total: 0 errors, 1 warnings, 0 checks, 14 lines checked
Therefore, before pushing the patch, I changed the commit title to
"drm/vkms: Suppress context imbalance detected by sparse warning". Hope
you don't mind.
Applied to misc/kernel.git (drm-misc-next).
Best Regards,
- Maíra
---
drivers/gpu/drm/vkms/vkms_crtc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index
40b4d084e3ceef9e1e24b7338efdd9253afee8d6..2ad164b518fb93f5b6b86948116ff7ed97770b60
100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -232,6 +232,7 @@ static void vkms_crtc_atomic_disable(struct drm_crtc *crtc,
static void vkms_crtc_atomic_begin(struct drm_crtc *crtc,
struct drm_atomic_state *state)
+ __acquires(&vkms_output->lock)
{
struct vkms_output *vkms_output = drm_crtc_to_vkms_output(crtc);
@@ -243,6 +244,7 @@ static void vkms_crtc_atomic_begin(struct drm_crtc *crtc,
static void vkms_crtc_atomic_flush(struct drm_crtc *crtc,
struct drm_atomic_state *state)
+ __releases(&vkms_output->lock)
{
struct vkms_output *vkms_output = drm_crtc_to_vkms_output(crtc);
---
base-commit: d2194256049910d286cd6c308c2689df521d8842
change-id: 20240912-vkms-warnings-e0e331bc5e6d
Best regards,
Re: [PATCH v2 08/22] drm/msm/dpu: Specify dedicated CWB pingpong blocks
On Tue, Sep 24, 2024 at 03:59:24PM GMT, Jessica Zhang wrote: > Change pingpong index and names to distinguish between general use > pingpong blocks and pingpong blocks dedicated for concurrent writeback > > Signed-off-by: Jessica Zhang > --- > drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 8 > drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 4 ++-- > drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 4 ++-- > drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 4 ++-- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 8 > 5 files changed, 14 insertions(+), 14 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 07/22] drm/msm/dpu: Add CWB entry to catalog for SM8650
On Tue, Sep 24, 2024 at 03:59:23PM GMT, Jessica Zhang wrote: > From: Esha Bharadwaj > > Add a new block for concurrent writeback mux to the SM8650 HW catalog > > Signed-off-by: Esha Bharadwaj > Signed-off-by: Jessica Zhang > --- > .../gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 21 > + > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 13 + > 2 files changed, 34 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 11/22] drm/msm/dpu: add CWB support to dpu_hw_wb
On Tue, Sep 24, 2024 at 03:59:27PM GMT, Jessica Zhang wrote: > From: Esha Bharadwaj > > Adjust the WB_MUX configuration to account for using dedicated CWB > pingpong blocks. > > Signed-off-by: Esha Bharadwaj > Signed-off-by: Jessica Zhang > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 12/22] drm/msm/dpu: Add RM support for allocating CWB
On Tue, Sep 24, 2024 at 03:59:28PM GMT, Jessica Zhang wrote: > Add support for allocating the concurrent writeback mux as part of the > WB allocation > > Signed-off-by: Jessica Zhang > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 17 +++-- > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 2 ++ > 2 files changed, 17 insertions(+), 2 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 13/22] drm/msm/dpu: Add CWB to msm_display_topology
On Tue, Sep 24, 2024 at 03:59:29PM GMT, Jessica Zhang wrote:
> Add the cwb_enabled flag to msm_display topology and adjust the toplogy
> to account for concurrent writeback
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 --
> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 10 --
> drivers/gpu/drm/msm/msm_drv.h| 2 ++
> 3 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index d53e986eee54..a7850bf844db 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -1176,6 +1176,8 @@ static struct msm_display_topology
> dpu_crtc_get_topology(
> dpu_encoder_update_topology(drm_enc, &topology,
> crtc_state->state,
> &crtc_state->adjusted_mode);
>
> + topology.cwb_enabled = drm_crtc_in_clone_mode(crtc_state);
> +
> /*
>* Datapath topology selection
>*
> @@ -1189,9 +1191,9 @@ static struct msm_display_topology
> dpu_crtc_get_topology(
>* Add dspps to the reservation requirements if ctm is requested
>*/
>
> - if (topology.num_intf == 2)
> + if (topology.num_intf == 2 && !topology.cwb_enabled)
> topology.num_lm = 2;
> - else if (topology.num_dsc == 2)
> + else if (topology.num_dsc == 2 && !topology.cwb_enabled)
Is it a temporal restriction or is it a hardware limitation? Can we use
two LMs with a single WB?
> topology.num_lm = 2;
> else if (dpu_kms->catalog->caps->has_3d_merge)
> topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT) ? 2 : 1;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> index 96c80cf9f6ad..04df3056d75a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> @@ -371,8 +371,14 @@ static int _dpu_rm_reserve_ctls(
> int i = 0, j, num_ctls;
> bool needs_split_display;
>
> - /* each hw_intf needs its own hw_ctrl to program its control path */
> - num_ctls = top->num_intf;
> + /*
> + * For non-CWB mode, each hw_intf needs its own hw_ctl to program its
> + * control path. Hardcode num_ctls to 1 if CWB is enabled
> + */
> + if (top->cwb_enabled)
> + num_ctls = 1;
> + else
> + num_ctls = top->num_intf;
>
> needs_split_display = _dpu_rm_needs_split_display(top);
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 0d3adf398bc1..8a2a3705f117 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -1,5 +1,6 @@
> /* SPDX-License-Identifier: GPL-2.0-only */
> /*
> + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
> * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
> * Copyright (C) 2013 Red Hat
> * Author: Rob Clark
> @@ -88,6 +89,7 @@ struct msm_display_topology {
> u32 num_dspp;
> u32 num_dsc;
> bool needs_cdm;
> + bool cwb_enabled;
> };
>
> /* Commit/Event thread specific structure */
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
Re: [PATCH] drm/v3d: Use v3d_perfmon_find(..)
Hi Christian, On 9/23/24 12:19, Christian Gmeiner wrote: From: Christian Gmeiner Replace the open coded v3d_perfmon_find(..) with the real thing. Signed-off-by: Christian Gmeiner Thanks for your patch! Reviewed-by: Maíra Canal Applied to misc/kernel.git (drm-misc-next). Best Regards, - Maíra --- drivers/gpu/drm/v3d/v3d_perfmon.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/v3d/v3d_perfmon.c b/drivers/gpu/drm/v3d/v3d_perfmon.c index cd7f1eedf17f..54a486a9b74c 100644 --- a/drivers/gpu/drm/v3d/v3d_perfmon.c +++ b/drivers/gpu/drm/v3d/v3d_perfmon.c @@ -402,11 +402,7 @@ int v3d_perfmon_get_values_ioctl(struct drm_device *dev, void *data, if (req->pad != 0) return -EINVAL; - mutex_lock(&v3d_priv->perfmon.lock); - perfmon = idr_find(&v3d_priv->perfmon.idr, req->id); - v3d_perfmon_get(perfmon); - mutex_unlock(&v3d_priv->perfmon.lock); - + perfmon = v3d_perfmon_find(v3d_priv, req->id); if (!perfmon) return -EINVAL;
Re: [PATCH v2 06/22] drm/msm/dpu: fill CRTC resources in dpu_crtc.c
On Tue, Sep 24, 2024 at 03:59:22PM GMT, Jessica Zhang wrote:
> From: Dmitry Baryshkov
>
> Stop poking into CRTC state from dpu_encoder.c, fill CRTC HW resources
> from dpu_crtc_assign_resources().
>
> Signed-off-by: Dmitry Baryshkov
> [quic_abhin...@quicinc.com: cleaned up formatting]
> Signed-off-by: Abhinav Kumar
> [quic_jessz...@quicinc.com: dropped clearing num_mixers in CRTC disable
> path]
Same comment as before: the code is still there.
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 32
> ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 24 ++
> 2 files changed, 31 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index b918c80d30b3..d53e986eee54 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -1091,9 +1091,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc,
>
> dpu_core_perf_crtc_update(crtc, 0);
>
> - memset(cstate->mixers, 0, sizeof(cstate->mixers));
> - cstate->num_mixers = 0;
> -
> /* disable clk & bw control until clk & bw properties are set */
> cstate->bw_control = false;
> cstate->bw_split_vote = false;
> @@ -1164,6 +1161,7 @@ static bool dpu_crtc_needs_dirtyfb(struct
> drm_crtc_state *cstate)
> }
>
> #define MAX_HDISPLAY_SPLIT 1080
> +#define MAX_CHANNELS_PER_CRTC 2
>
> static struct msm_display_topology dpu_crtc_get_topology(
> struct drm_crtc *crtc,
> @@ -1208,9 +1206,14 @@ static struct msm_display_topology
> dpu_crtc_get_topology(
>
> static int dpu_crtc_assign_resources(struct drm_crtc *crtc, struct
> drm_crtc_state *crtc_state)
> {
> + struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_CRTC];
> + struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_CRTC];
> + struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_CRTC];
> + int i, num_lm, num_ctl, num_dspp;
> struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
> struct dpu_global_state *global_state;
> struct msm_display_topology topology;
> + struct dpu_crtc_state *cstate;
> int ret;
>
> /*
> @@ -1232,6 +1235,29 @@ static int dpu_crtc_assign_resources(struct drm_crtc
> *crtc, struct drm_crtc_stat
> if (ret)
> return ret;
>
> + cstate = to_dpu_crtc_state(crtc_state);
> +
> + num_ctl = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
> + crtc, DPU_HW_BLK_CTL, hw_ctl,
> + ARRAY_SIZE(hw_ctl));
> + num_lm = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
> +crtc, DPU_HW_BLK_LM, hw_lm,
> +ARRAY_SIZE(hw_lm));
> + num_dspp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
> + crtc, DPU_HW_BLK_DSPP, hw_dspp,
> + ARRAY_SIZE(hw_dspp));
> +
> + for (i = 0; i < num_lm; i++) {
> + int ctl_idx = (i < num_ctl) ? i : (num_ctl-1);
> +
> + cstate->mixers[i].hw_lm = to_dpu_hw_mixer(hw_lm[i]);
> + cstate->mixers[i].lm_ctl = to_dpu_hw_ctl(hw_ctl[ctl_idx]);
> + if (i < num_dspp)
> + cstate->mixers[i].hw_dspp = to_dpu_hw_dspp(hw_dspp[i]);
> + }
> +
> + cstate->num_mixers = num_lm;
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index ada9119326ca..36b677cf9c7a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -1049,14 +1049,11 @@ static void dpu_encoder_virt_atomic_mode_set(struct
> drm_encoder *drm_enc,
> struct dpu_encoder_virt *dpu_enc;
> struct msm_drm_private *priv;
> struct dpu_kms *dpu_kms;
> - struct dpu_crtc_state *cstate;
> struct dpu_global_state *global_state;
> struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
> struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
> - struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
> - struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_ENC] = { NULL };
> struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
> - int num_lm, num_ctl, num_pp, num_dsc;
> + int num_pp, num_dsc;
> unsigned int dsc_mask = 0;
> int i;
>
> @@ -1083,13 +1080,8 @@ static void dpu_encoder_virt_atomic_mode_set(struct
> drm_encoder *drm_enc,
> num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
> drm_enc->crtc, DPU_HW_BLK_PINGPONG, hw_pp,
> ARRAY_SIZE(hw_pp));
> - num_ctl = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
> - drm_enc->crtc, DPU_HW_BLK_CTL, hw_ctl, ARRAY_SIZE(hw_ctl));
> - num_lm = dpu_rm_get_assi
Re: [PATCH v2 10/22] drm/msm/dpu: Add dpu_hw_cwb abstraction for CWB block
On Tue, Sep 24, 2024 at 03:59:26PM GMT, Jessica Zhang wrote: > The CWB mux has its own registers and set of operations. Add dpu_hw_cwb > abstraction to allow driver to configure the CWB mux. > > Signed-off-by: Jessica Zhang > --- > drivers/gpu/drm/msm/Makefile| 1 + > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cwb.c | 73 > + > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cwb.h | 70 +++ > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 5 +- > 4 files changed, 148 insertions(+), 1 deletion(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 14/22] drm/msm/dpu: Require modeset if clone mode status changes
On Tue, Sep 24, 2024 at 03:59:30PM GMT, Jessica Zhang wrote:
> If the clone mode enabled status is changing, a modeset needs to happen
> so that the resources can be reassigned
Sima's comment regarding crtc_state->mode_changed seems to be ignored...
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index a7850bf844db..f20e44e9fc05 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -1268,6 +1268,8 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
> {
> struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
> crtc);
> + struct drm_crtc_state *old_crtc_state =
> drm_atomic_get_old_crtc_state(state,
> +
> crtc);
> struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
> struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
>
> @@ -1279,6 +1281,8 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
> int rc = 0;
>
> bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
> + bool clone_mode_requested = drm_crtc_in_clone_mode(old_crtc_state);
> + bool clone_mode_enabled = drm_crtc_in_clone_mode(crtc_state);
>
> /* there might be cases where encoder needs a modeset too */
> drm_for_each_encoder_mask(drm_enc, crtc->dev, crtc_state->encoder_mask)
> {
> @@ -1286,6 +1290,10 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
> crtc_state->mode_changed = true;
> }
>
> + if ((clone_mode_requested && !clone_mode_enabled) ||
> + (!clone_mode_requested && clone_mode_enabled))
> + crtc_state->mode_changed = true;
> +
> if (drm_atomic_crtc_needs_modeset(crtc_state)) {
> rc = dpu_crtc_assign_resources(crtc, crtc_state);
> if (rc < 0)
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
Re: [PATCH v3 1/6] drm: add DRM_SET_NAME ioctl
On 9/23/24 21:18, Dmitry Osipenko wrote: > On 9/23/24 21:09, Dmitry Osipenko wrote: >>> Sure, I can do that if others prefer this way too. >> Note that in the other email I suggested to use strndup_user(), that >> will remove the name-length limitation, but then the name var will >> remain to be a string pointer. To me best option would be to replicate >> how dma_buf_set_name works. > > My bad, strndup_user() is also size-limited. Then the point about static > string remains. To clarify a bit further, I'm fine with both variants. Having a consistent solution across kernel is also good if it's good enough. I.e. replicating the whole dma_buf_set_name using the name pointer is okay to me, though not having string pointers is more robust in general. Choose what you like more. -- Best regards, Dmitry
Re: [PATCH v2 15/22] drm/msm/dpu: Reserve resources for CWB
On Tue, Sep 24, 2024 at 03:59:31PM GMT, Jessica Zhang wrote:
> Add support for RM to reserve dedicated CWB pingpongs and CWB muxes
>
> For concurrent writeback, even-indexed CWB muxes must be assigned to
> even-indexed LMs and odd-indexed CWB muxes for odd-indexed LMs. The same
> even/odd rule applies for dedicated CWB pingpongs.
>
> Track the CWB muxes in the global state and add a CWB-specific helper to
> reserve the correct CWB muxes and dedicated pingpongs following the
> even/odd rule.
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 34 ++--
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 84
> +
> 4 files changed, 117 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 36b677cf9c7a..b2f0bf412451 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -2,7 +2,7 @@
> /*
> * Copyright (C) 2013 Red Hat
> * Copyright (c) 2014-2018, 2020-2021 The Linux Foundation. All rights
> reserved.
> - * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights
> reserved.
> + * Copyright (c) 2022-2024 Qualcomm Innovation Center, Inc. All rights
> reserved.
> *
> * Author: Rob Clark
> */
> @@ -28,6 +28,7 @@
> #include "dpu_hw_dsc.h"
> #include "dpu_hw_merge3d.h"
> #include "dpu_hw_cdm.h"
> +#include "dpu_hw_cwb.h"
> #include "dpu_formats.h"
> #include "dpu_encoder_phys.h"
> #include "dpu_crtc.h"
> @@ -133,6 +134,9 @@ enum dpu_enc_rc_states {
> * @cur_slave: As above but for the slave encoder.
> * @hw_pp: Handle to the pingpong blocks used for the display. No.
> * pingpong blocks can be different than num_phys_encs.
> + * @hw_cwb: Handle to the CWB muxes used for concurrent writeback
> + * display. Number of CWB muxes can be different than
> + * num_phys_encs.
> * @hw_dsc: Handle to the DSC blocks used for the display.
> * @dsc_mask:Bitmask of used DSC blocks.
> * @intfs_swapped: Whether or not the phys_enc interfaces have been swapped
> @@ -177,6 +181,7 @@ struct dpu_encoder_virt {
> struct dpu_encoder_phys *cur_master;
> struct dpu_encoder_phys *cur_slave;
> struct dpu_hw_pingpong *hw_pp[MAX_CHANNELS_PER_ENC];
> + struct dpu_hw_cwb *hw_cwb[MAX_CHANNELS_PER_ENC];
> struct dpu_hw_dsc *hw_dsc[MAX_CHANNELS_PER_ENC];
>
> unsigned int dsc_mask;
> @@ -1053,7 +1058,10 @@ static void dpu_encoder_virt_atomic_mode_set(struct
> drm_encoder *drm_enc,
> struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
> struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
> struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
> + struct dpu_hw_blk *hw_cwb[MAX_CHANNELS_PER_ENC];
> int num_pp, num_dsc;
> + int num_cwb = 0;
> + bool is_cwb_encoder;
> unsigned int dsc_mask = 0;
> int i;
>
> @@ -1067,6 +1075,8 @@ static void dpu_encoder_virt_atomic_mode_set(struct
> drm_encoder *drm_enc,
>
> priv = drm_enc->dev->dev_private;
> dpu_kms = to_dpu_kms(priv->kms);
> + is_cwb_encoder = drm_crtc_in_clone_mode(crtc_state) &&
> + dpu_enc->disp_info.intf_type == INTF_WB;
>
> global_state = dpu_kms_get_existing_global_state(dpu_kms);
> if (IS_ERR_OR_NULL(global_state)) {
> @@ -1077,9 +1087,25 @@ static void dpu_encoder_virt_atomic_mode_set(struct
> drm_encoder *drm_enc,
> trace_dpu_enc_mode_set(DRMID(drm_enc));
>
> /* Query resource that have been reserved in atomic check step. */
> - num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
> - drm_enc->crtc, DPU_HW_BLK_PINGPONG, hw_pp,
> - ARRAY_SIZE(hw_pp));
> + if (is_cwb_encoder) {
> + num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm,
> global_state,
> +drm_enc->crtc,
> +DPU_HW_BLK_DCWB_PINGPONG,
> +hw_pp,
> ARRAY_SIZE(hw_pp));
> + num_cwb = dpu_rm_get_assigned_resources(&dpu_kms->rm,
> global_state,
> +drm_enc->crtc,
> +DPU_HW_BLK_CWB,
> +hw_cwb,
> ARRAY_SIZE(hw_cwb));
> + } else {
> + num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm,
> global_state,
> +drm_enc->crtc,
> +DPU_HW_BLK_PINGPONG,
> hw_pp,
> +ARRAY_SIZE(hw_pp)
Re: [PATCH v2 16/22] drm/msm/dpu: Configure CWB in writeback encoder
On Tue, Sep 24, 2024 at 03:59:32PM GMT, Jessica Zhang wrote:
> Cache the CWB block mask in the DPU virtual encoder and configure CWB
> according to the CWB block mask within the writeback phys encoder
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 83
> +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 16 -
> .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c| 4 +-
> 3 files changed, 100 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index b2f0bf412451..2628f2d55cb3 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -24,6 +24,7 @@
> #include "dpu_hw_catalog.h"
> #include "dpu_hw_intf.h"
> #include "dpu_hw_ctl.h"
> +#include "dpu_hw_cwb.h"
> #include "dpu_hw_dspp.h"
> #include "dpu_hw_dsc.h"
> #include "dpu_hw_merge3d.h"
> @@ -139,6 +140,7 @@ enum dpu_enc_rc_states {
> * num_phys_encs.
> * @hw_dsc: Handle to the DSC blocks used for the display.
> * @dsc_mask:Bitmask of used DSC blocks.
> + * @cwb_mask Bitmask of used CWB muxes
> * @intfs_swapped: Whether or not the phys_enc interfaces have been swapped
> * for partial update right-only cases, such as pingpong
> * split where virtual pingpong does not generate IRQs
> @@ -185,6 +187,7 @@ struct dpu_encoder_virt {
> struct dpu_hw_dsc *hw_dsc[MAX_CHANNELS_PER_ENC];
>
> unsigned int dsc_mask;
> + unsigned int cwb_mask;
>
> bool intfs_swapped;
>
> @@ -1063,6 +1066,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct
> drm_encoder *drm_enc,
> int num_cwb = 0;
> bool is_cwb_encoder;
> unsigned int dsc_mask = 0;
> + unsigned int cwb_mask = 0;
> int i;
>
> if (!drm_enc) {
> @@ -1103,8 +1107,12 @@ static void dpu_encoder_virt_atomic_mode_set(struct
> drm_encoder *drm_enc,
> ARRAY_SIZE(hw_pp));
> }
>
> - for (i = 0; i < num_cwb; i++)
> + for (i = 0; i < num_cwb; i++) {
> dpu_enc->hw_cwb[i] = to_dpu_hw_cwb(hw_cwb[i]);
> + cwb_mask |= BIT(dpu_enc->hw_cwb[i]->idx - CWB_0);
> + }
> +
> + dpu_enc->cwb_mask = cwb_mask;
>
> dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
> drm_enc->crtc, DPU_HW_BLK_CTL, hw_ctl,
> ARRAY_SIZE(hw_ctl));
> @@ -2071,6 +2079,9 @@ void dpu_encoder_helper_phys_cleanup(struct
> dpu_encoder_phys *phys_enc)
> }
> }
>
> + if (dpu_enc->cwb_mask)
> + dpu_encoder_helper_phys_setup_cwb(phys_enc, false);
> +
> /* reset the merge 3D HW block */
> if (phys_enc->hw_pp && phys_enc->hw_pp->merge_3d) {
>
> phys_enc->hw_pp->merge_3d->ops.setup_3d_mode(phys_enc->hw_pp->merge_3d,
> @@ -2114,6 +2125,68 @@ void dpu_encoder_helper_phys_cleanup(struct
> dpu_encoder_phys *phys_enc)
> ctl->ops.clear_pending_flush(ctl);
> }
>
> +void dpu_encoder_helper_phys_setup_cwb(struct dpu_encoder_phys *phys_enc,
> +bool enable)
> +{
> + struct dpu_encoder_virt *dpu_enc =
> to_dpu_encoder_virt(phys_enc->parent);
> + struct dpu_hw_cwb *hw_cwb;
> + struct dpu_hw_cwb_setup_cfg cwb_cfg;
> +
> + struct dpu_kms *dpu_kms;
> + struct dpu_global_state *global_state;
> + struct dpu_hw_blk *rt_pp_list[MAX_CHANNELS_PER_ENC];
> + int num_pp, rt_pp_idx[MAX_CHANNELS_PER_ENC];
> +
> + if (!phys_enc || !phys_enc->hw_wb || !dpu_enc->cwb_mask)
> + return;
We have already dereferened phys_enc, so checking that it's not NULL is
futile. Also we know that the function is only called if cwb_mask is not
zero, so the last check is also useless.
> +
> + dpu_kms = phys_enc->dpu_kms;
> + global_state = dpu_kms_get_existing_global_state(dpu_kms);
> + num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
> +phys_enc->parent->crtc,
> +DPU_HW_BLK_PINGPONG, rt_pp_list,
> +ARRAY_SIZE(rt_pp_list));
> +
> + if (num_pp == 0 || num_pp > MAX_CHANNELS_PER_ENC) {
> + DPU_DEBUG_ENC(dpu_enc, "invalid num_pp %d\n", num_pp);
> + return;
> + }
> +
> + for (int i = 0; i < num_pp; i++) {
> + struct dpu_hw_pingpong *hw_pp =
> to_dpu_hw_pingpong(rt_pp_list[i]);
> +
> + for (int j = 0; j < ARRAY_SIZE(dpu_enc->hw_cwb); j++) {
> + hw_cwb = dpu_enc->hw_cwb[i];
> +
> + /*
> + * Even CWB muxes must take input from even real-time
> + * pingpongs and odd CWB muxes must take input from odd
> + * pingpongs
> +
Re: [PATCH v2 20/22] drm/msm/dpu: Skip trigger flush and start for CWB
On Tue, Sep 24, 2024 at 03:59:36PM GMT, Jessica Zhang wrote: > For concurrent writeback, the real time encoder is responsible for > trigger flush and trigger start. Return early for trigger start and > trigger flush for the concurrent writeback encoders. > > Signed-off-by: Jessica Zhang > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 ++ > 1 file changed, 18 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH] dt-bindings: lcdif: Add support for specifying display with timings
On 9/25/24 12:57 AM, Rob Herring wrote: On Mon, Sep 23, 2024 at 07:53:57PM +0200, Marek Vasut wrote: On 9/23/24 3:57 PM, Lukasz Majewski wrote: Up till now the fsl,lcdif.yaml was requiring the "port" property as a must have to specify the display interface on iMX devices. However, it shall also be possible to specify the display only with passing its timing parameters (h* and v* ones) via "display" property: (as in Documentation/devicetree/bindings/display/panel/display-timings.yaml). Timings should go into panel node, not into scanout engine node. See e.g. panel-timings in arch/arm64/boot/dts/freescale/imx8mm-phg.dts , in your case the compatible might be "panel-dpi" . I agree, but if this is already in use, we should allow it. We can mark it deprecated though. I don't think it is in use yet, at least not in upstream, so let's not allow this.
Re: [PATCH v2 22/22] drm/msm/dpu: Set possible clones for all encoders
On Tue, Sep 24, 2024 at 03:59:38PM GMT, Jessica Zhang wrote: > Set writeback encoders as possible clones for non-writeback encoders and > vice versa. > > Signed-off-by: Jessica Zhang > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 32 > + > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 2 ++ > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 7 +-- > 3 files changed, 39 insertions(+), 2 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v4] drm/vkms: Add documentation
Hi Louis,
On 9/5/24 10:27, Louis Chauvet wrote:
Add documentation around vkms_output and its initialization.
Add some documentation on pixel conversion functions.
Update of outdated comments for pixel_write functions.
Reviewed-by: José Expósito
Signed-off-by: Louis Chauvet
Applied to misc/kernel.git (drm-misc-next).
Best Regards,
- Maíra
---
This series does not introduce functionnal changes, only some
documentation and renaming to clarify the code.
---
Changes in v4:
- Applied comments from José
- Link to v3:
https://lore.kernel.org/r/20240829-google-clarifications-v3-1-f6604e2f6...@bootlin.com
Changes in v3:
- Merged https://lore.kernel.org/all/20240802-yuv-v9-3-08a706669...@bootlin.com/
as it also add documentation
- Apply José's comments, sorry
- Replace =1 by =BIT(0) for possible_crtc value
- Link to v2:
https://lore.kernel.org/r/20240826-google-clarifications-v2-1-2574655b0...@bootlin.com
Changes in v2:
- Dropped already applied patches
- Dropped useless patch as its content is deleted later
- Remove dependency on previous series
- Apply Maíra's comments
- Link to v1:
https://lore.kernel.org/r/20240814-google-clarifications-v1-0-3ee76d7d0...@bootlin.com
---
drivers/gpu/drm/vkms/vkms_composer.c | 7 +++
drivers/gpu/drm/vkms/vkms_drv.h | 101 ++-
drivers/gpu/drm/vkms/vkms_formats.c | 62 +
drivers/gpu/drm/vkms/vkms_output.c | 14 -
4 files changed, 161 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index e7441b227b3c..57a5769fc994 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -189,6 +189,13 @@ static void blend(struct vkms_writeback_job *wb,
size_t crtc_y_limit = crtc_state->base.crtc->mode.vdisplay;
+ /*
+* The planes are composed line-by-line to avoid heavy memory usage. It
is a necessary
+* complexity to avoid poor blending performance.
+*
+* The function vkms_compose_row() is used to read a line,
pixel-by-pixel, into the staging
+* buffer.
+*/
for (size_t y = 0; y < crtc_y_limit; y++) {
fill_background(&background_color, output_buffer);
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 5e46ea5b96dc..672fe191e239 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -25,6 +25,17 @@
#define VKMS_LUT_SIZE 256
+/**
+ * struct vkms_frame_info - Structure to store the state of a frame
+ *
+ * @fb: backing drm framebuffer
+ * @src: source rectangle of this frame in the source framebuffer, stored in
16.16 fixed-point form
+ * @dst: destination rectangle in the crtc buffer, stored in whole pixel units
+ * @map: see @drm_shadow_plane_state.data
+ * @rotation: rotation applied to the source.
+ *
+ * @src and @dst should have the same size modulo the rotation.
+ */
struct vkms_frame_info {
struct drm_framebuffer *fb;
struct drm_rect src, dst;
@@ -52,9 +63,11 @@ struct vkms_writeback_job {
};
/**
- * vkms_plane_state - Driver specific plane state
+ * struct vkms_plane_state - Driver specific plane state
* @base: base plane state
* @frame_info: data required for composing computation
+ * @pixel_read: function to read a pixel in this plane. The creator of a
struct vkms_plane_state
+ * must ensure that this pointer is valid
*/
struct vkms_plane_state {
struct drm_shadow_plane_state base;
@@ -73,29 +86,56 @@ struct vkms_color_lut {
};
/**
- * vkms_crtc_state - Driver specific CRTC state
+ * struct vkms_crtc_state - Driver specific CRTC state
+ *
* @base: base CRTC state
* @composer_work: work struct to compose and add CRC entries
- * @n_frame_start: start frame number for computed CRC
- * @n_frame_end: end frame number for computed CRC
+ *
+ * @num_active_planes: Number of active planes
+ * @active_planes: List containing all the active planes (counted by
+ *@num_active_planes). They should be stored in z-order.
+ * @active_writeback: Current active writeback job
+ * @gamma_lut: Look up table for gamma used in this CRTC
+ * @crc_pending: Protected by @vkms_output.composer_lock, true when the frame
CRC is not computed
+ * yet. Used by vblank to detect if the composer is too slow.
+ * @wb_pending: Protected by @vkms_output.composer_lock, true when a writeback
frame is requested.
+ * @frame_start: Protected by @vkms_output.composer_lock, saves the frame
number before the start
+ * of the composition process.
+ * @frame_end: Protected by @vkms_output.composer_lock, saves the last
requested frame number.
+ *This is used to generate enough CRC entries when the composition
worker is too slow.
*/
struct vkms_crtc_state {
struct drm_crtc_state base;
struct work_struct composer_work;
int num_acti
Re: [PATCH v2 06/22] drm/msm/dpu: fill CRTC resources in dpu_crtc.c
On 9/24/2024 4:16 PM, Dmitry Baryshkov wrote:
On Tue, Sep 24, 2024 at 03:59:22PM GMT, Jessica Zhang wrote:
From: Dmitry Baryshkov
Stop poking into CRTC state from dpu_encoder.c, fill CRTC HW resources
from dpu_crtc_assign_resources().
Signed-off-by: Dmitry Baryshkov
[quic_abhin...@quicinc.com: cleaned up formatting]
Signed-off-by: Abhinav Kumar
[quic_jessz...@quicinc.com: dropped clearing num_mixers in CRTC disable
path]
Same comment as before: the code is still there.
Hi Dmitry,
I thought the original comment was to move the dropping `num_mixers = 0`
chunk from the previous patch to this one?
Sorry if I misunderstood.
Thanks,
Jessica Zhang
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 32 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 24 ++
2 files changed, 31 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index b918c80d30b3..d53e986eee54 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1091,9 +1091,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc,
dpu_core_perf_crtc_update(crtc, 0);
- memset(cstate->mixers, 0, sizeof(cstate->mixers));
- cstate->num_mixers = 0;
-
/* disable clk & bw control until clk & bw properties are set */
cstate->bw_control = false;
cstate->bw_split_vote = false;
@@ -1164,6 +1161,7 @@ static bool dpu_crtc_needs_dirtyfb(struct drm_crtc_state
*cstate)
}
#define MAX_HDISPLAY_SPLIT 1080
+#define MAX_CHANNELS_PER_CRTC 2
static struct msm_display_topology dpu_crtc_get_topology(
struct drm_crtc *crtc,
@@ -1208,9 +1206,14 @@ static struct msm_display_topology dpu_crtc_get_topology(
static int dpu_crtc_assign_resources(struct drm_crtc *crtc, struct drm_crtc_state *crtc_state)
{
+ struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_CRTC];
+ struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_CRTC];
+ struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_CRTC];
+ int i, num_lm, num_ctl, num_dspp;
struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
struct dpu_global_state *global_state;
struct msm_display_topology topology;
+ struct dpu_crtc_state *cstate;
int ret;
/*
@@ -1232,6 +1235,29 @@ static int dpu_crtc_assign_resources(struct drm_crtc
*crtc, struct drm_crtc_stat
if (ret)
return ret;
+ cstate = to_dpu_crtc_state(crtc_state);
+
+ num_ctl = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
+ crtc, DPU_HW_BLK_CTL, hw_ctl,
+ ARRAY_SIZE(hw_ctl));
+ num_lm = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
+ crtc, DPU_HW_BLK_LM, hw_lm,
+ ARRAY_SIZE(hw_lm));
+ num_dspp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
+crtc, DPU_HW_BLK_DSPP, hw_dspp,
+ARRAY_SIZE(hw_dspp));
+
+ for (i = 0; i < num_lm; i++) {
+ int ctl_idx = (i < num_ctl) ? i : (num_ctl-1);
+
+ cstate->mixers[i].hw_lm = to_dpu_hw_mixer(hw_lm[i]);
+ cstate->mixers[i].lm_ctl = to_dpu_hw_ctl(hw_ctl[ctl_idx]);
+ if (i < num_dspp)
+ cstate->mixers[i].hw_dspp = to_dpu_hw_dspp(hw_dspp[i]);
+ }
+
+ cstate->num_mixers = num_lm;
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index ada9119326ca..36b677cf9c7a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1049,14 +1049,11 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
struct dpu_encoder_virt *dpu_enc;
struct msm_drm_private *priv;
struct dpu_kms *dpu_kms;
- struct dpu_crtc_state *cstate;
struct dpu_global_state *global_state;
struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
- struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
- struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_ENC] = { NULL };
struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
- int num_lm, num_ctl, num_pp, num_dsc;
+ int num_pp, num_dsc;
unsigned int dsc_mask = 0;
int i;
@@ -1083,13 +1080,8 @@ static void dpu_encoder_virt_atomic_mode_set(struct drm_encoder *drm_enc,
num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
drm_enc->crtc, DPU_HW_BLK_PINGPONG, hw_pp,
ARRAY_SIZE(hw_pp));
- num_ctl = dpu_rm_get_assigned_resources(&dpu_kms->rm, global
Re: [PATCH v17 0/8] Initial support Cadence MHDP8501(HDMI/DP) for i.MX8MQ
On Tue, 24 Sep 2024 15:36:45 +0800, Sandor Yu wrote:
> The patch set initial support Cadence MHDP8501(HDMI/DP) DRM bridge
> driver and Cadence HDP-TX PHY(HDMI/DP) driver for Freescale i.MX8MQ.
>
> The patch set compose of DRM bridge drivers and PHY driver.
>
> Both of them need by patch #1 and #2 to pass build.
>
> DRM bridges driver patches:
> #1: drm: bridge: Cadence: Creat mhdp helper driver
> #2: phy: Add HDMI configuration options
> #3: dt-bindings: display: bridge: Add Cadence MHDP8501
> #4: drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver
>
> PHY driver patches:
> #1: drm: bridge: Cadence: Creat mhdp helper driver
> #2: phy: Add HDMI configuration options
> #5: dt-bindings: phy: Add Freescale iMX8MQ DP and HDMI PHY
> #6: phy: freescale: Add DisplayPort/HDMI Combo-PHY driver for i.MX8MQ
>
> i.MX8M/TQMa8Mx DT patches:
> #7: Add DT nodes for DCSS/HDMI pipeline
> #8: Enable HDMI for TQMa8Mx/MBa8Mx
>
> v16->v17:
> Patch #1:
> - Replaces the local mutex mbox_mutex with a global mutex mhdp_mailbox_mutex
> Patch #2:
> - remove hdmi.h
> - add 2024 year to copyright
> - Add r-b tag.
> Patch #3:
> - Add lane-mapping property.
> Patch #4:
> - Reset the HDMI/DP link when an HPD (Hot Plug Detect) event is detected
> - Move the HDMI protocol settings from hdmi_ctrl_init() to a new function
> cdns_hdmi_set_hdmi_mode_type(), to align with the introduced link reset
> functionality.
> - Implement logic to check the type of HDMI sink.
> If the sink is not a hdmi display, set the default mode to DVI.
> - Implement hdmi_reset_infoframe function
> - Reorder certain bit definitions in the header file to follow a descending
> order.
> - Add "lane-mapping" property for both HDMI and DP, remove platform data from
> driver.
> lane-mapping should be setting in dts according different board layout.
> - Remove variable mode in struct cdns_mhdp8501_device, video mode could get
> from struct drm_crtc_state
> - Remove variable char_rate in struct cdns_mhdp8501_device, it could get
> from struct struct drm_connector_state.hdmi
> - Replaces the local mutex mbox_mutex with a global mutex mhdp_mailbox_mutex
> - Remove mutext protect for phy_api access functions.
> Patch #6:
> - Remove mbox_mutex
>
> v15->v16:
> Patch #2:
> - Remove pixel_clk_rate, bpc and color_space fields from struct
> phy_configure_opts_hdmi, they were replaced by
> unsigned long long tmds_char_rate.
> - Remove r-b and a-c tags because this patch have important change.
> Patch #4:
> - Add DRM_BRIDGE_OP_HDMI flags for HDMI driver,
> - Introduce the hdmi info frame helper functions,
> added hdmi_clear_infoframe(), hdmi_write_infoframe() and
> hdmi_tmds_char_rate_valid() according Dmitry's patch
> 'make use of the HDMI connector infrastructure' patchset ([2]).
> - mode_fixup() is replaced by atomic_check().
> - Fix video mode 4Kp30 did not work on some displays that support
> LTE_340Mcsc_scramble.
> - updated for tmds_char_rate added in patch #2.
> Patch #6:
> - updated for tmds_char_rate added in patch #2.
>
> v14->v15:
> Patch #6 + #7:
> - Merged PHY driver into a single combo PHY driver
> Patch #7 + #8:
> - Add DT patches for a running HDMI setup
>
> v13->v14:
> Patch #4:
> - Rebase to next-20240219, replace get_edid function by edid_read
> function as commits d807ad80d811b ("drm/bridge: add ->edid_read
> hook and drm_bridge_edid_read()") and 27b8f91c08d99 ("drm/bridge:
> remove ->get_edid callback") had change the API.
>
> v12->v13:
> Patch #4:
> - Explicitly include linux/platform_device.h for cdns-mhdp8501-core.c
> - Fix build warning
> - Order bit bpc and color_space in descending shit.
> Patch #7:
> - Fix build warning
>
> v11->v12:
> Patch #1:
> - Move status initialize out of mbox_mutex.
> - Reorder API functions in alphabetical.
> - Add notes for malibox access functions.
> - Add year 2024 to copyright.
> Patch #4:
> - Replace DRM_INFO with dev_info or dev_warn.
> - Replace DRM_ERROR with dev_err.
> - Return ret when cdns_mhdp_dpcd_read failed in function
> cdns_dp_aux_transferi().
> - Remove unused parmeter in function cdns_dp_get_msa_misc
> and use two separate variables for color space and bpc.
> - Add year 2024 to copyright.
> Patch #6:
> - Return error code to replace -1 for function wait_for_ack().
> - Set cdns_phy->power_up = false in phy_power_down function.
> - Remove "RATE_8_1 = 81", it is not used in driver.
> - Add year 2024 to copyright.
> Patch #7:
> - Adjust clk disable order.
> - Return error code to replace -1 for function wait_for_ack().
> - Use bool for variable pclk_in.
> - Add year 2024 to copyright.
>
> v10->v11:
> - rewrite cdns_mhdp_set_firmware_active() in mhdp8546 core driver,
> use cdns_mhdp_mailbox_send() to replace cdns_mhdp_mailbox_write()
> same as the other mailbox access functions.
> - use static for cdns_mhdp_mailbox_write() and cdns_mhdp_mailbox_read()
> and remove them from EXPORT_SYMBOL_GPL().
> - remove MODULE_ALIAS() from mhdp8501 driver.
>
> v9->v
Re: [PATCH 0/2] drm: revert some framebuffer API tests
On Tue, Sep 24, 2024 at 06:37:59AM GMT, Guenter Roeck wrote: > On 9/24/24 04:54, Maxime Ripard wrote: > > +Guenter > > > > On Tue, Sep 24, 2024 at 12:06:28PM GMT, Simona Vetter wrote: > > > On Tue, Sep 17, 2024 at 08:43:50PM +0300, Jani Nikula wrote: > > > > The tests consistently trigger WARNs in drm_framebuffer code. I'm not > > > > sure what the point is with type of belts and suspenders tests. The > > > > warnings *are* the way to flag erroneous API usage. > > > > > > > > Warnings in turn trigger failures in CI. Filtering the warnings are > > > > error prone, and, crucially, would also filter actual errors in case the > > > > kunit tests are not run. > > > > > > > > I acknowledge there may be complex test cases where you'd end up > > > > triggering warnings somewhere deep, but these are not it. These are > > > > simple. > > > > > > > > Revert the tests, back to the drawing board. > > > > > > Yeah I think long-term we might want a kunit framework so that we can > > > catch dmesg warnings we expect and test for those, without those warnings > > > actually going to dmesg. Similar to how the lockdep tests also reroute > > > locking validation, so that the expected positive tests don't wreak > > > lockdep for real. > > > > > > But until that exists, we can't have tests that splat in dmesg when they > > > work as intended. > > > > It should be pretty soon: > > https://lore.kernel.org/dri-devel/20240403131936.787234-1-li...@roeck-us.net/ > > > > I'm not sure what happened to that series, but it looks like everybody > > was mostly happy with it? > > > > Major subsystem maintainers did not provide any feedback at all, and then > there came the "it is not perfect enough" feedback, so I gave up on it. Well, if that means anything, we're interested even in something imperfect if it solves the above case :) Maxime signature.asc Description: PGP signature
Re: [PATCH] firmware/sysfb: Disable sysfb for firmware buffers with unknown parent
Thomas Zimmermann writes:
Hello Thomas,
> The sysfb framebuffer handling only operates on graphics devices
> that provide the system's firmware framebuffer. If that device is
> not known, assume that any graphics device has been initialized by
> firmware.
>
> Fixes a problem on i915 where sysfb does not release the firmware
> framebuffer after the native graphics driver loaded.
>
> Reported-by: Borah, Chaitanya Kumar
> Closes:
> https://lore.kernel.org/dri-devel/sj1pr11mb6129efb8ce63d1ef6d932f94b9...@sj1pr11mb6129.namprd11.prod.outlook.com/
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12160
> Signed-off-by: Thomas Zimmermann
> Fixes: b49420d6a1ae ("video/aperture: optionally match the device in
> sysfb_disable()")
> Cc: Javier Martinez Canillas
> Cc: Thomas Zimmermann
> Cc: Helge Deller
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: Alex Deucher
> Cc: dri-devel@lists.freedesktop.org
> Cc: Linux regression tracking (Thorsten Leemhuis)
> Cc: # v6.11+
> ---
> drivers/firmware/sysfb.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
> index 02a07d3d0d40..a3df782fa687 100644
> --- a/drivers/firmware/sysfb.c
> +++ b/drivers/firmware/sysfb.c
> @@ -67,9 +67,11 @@ static bool sysfb_unregister(void)
> void sysfb_disable(struct device *dev)
> {
> struct screen_info *si = &screen_info;
> + struct device *parent;
>
> mutex_lock(&disable_lock);
> - if (!dev || dev == sysfb_parent_dev(si)) {
> + parent = sysfb_parent_dev(si);
> + if (!dev || !parent || dev == parent) {
> sysfb_unregister();
> disabled = true;
> }
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH 2/8] drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job
On 24/09/2024 15:20, Christian König wrote:
Am 24.09.24 um 16:12 schrieb Tvrtko Ursulin:
On 24/09/2024 14:55, Christian König wrote:
I've pushed the first to drm-misc-next, but that one here fails to
apply cleanly.
This appears due 440d52b370b0 ("drm/sched: Fix dynamic job-flow
control race") in drm-misc-fixes.
In theory 1-3 from my series are fixes. Should they also go to
drm-misc-fixes? I am not too familiar with the drm-misc flow.
Ah shit, in that case you should have spitted the patches up into fixes
and next. Going to push the first 3 to fixes.
Sorry my drm-intel ways of thinking (cherry picked fixes) are hard to
get rid of. Hence the series was structured as 1-3 fixes, 4-8 refactors etc.
Now appears it is too late to pull out the first one from drm-misc-next.
Or the series now needs to wait for some backmerge?
Are the remaining 3 patches independent? If not then we need to wait for
a backmerge.
These are independent:
Fixes:
1/8 "drm/sched: Add locking to drm_sched_entity_modify_sched"
Not fixes:
5/8 "drm/sched: Stop setting current entity in FIFO mode"
6/8 "drm/sched: Re-order struct drm_sched_rq members for clarity"
While the rest touch at least some common areas.
2/8 and 3/8 are also fixes.
4/8, 7/8 and 8/8 not fixes but depend on 2/8 and 3/8.
Regards,
Tvrtko
Am 24.09.24 um 12:19 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Since drm_sched_entity_modify_sched() can modify the entities run
queue,
lets make sure to only dereference the pointer once so both adding and
waking up are guaranteed to be consistent.
Alternative of moving the spin_unlock to after the wake up would for
now
be more problematic since the same lock is taken inside
drm_sched_rq_update_fifo().
v2:
* Improve commit message. (Philipp)
* Cache the scheduler pointer directly. (Christian)
Signed-off-by: Tvrtko Ursulin
Fixes: b37aced31eb0 ("drm/scheduler: implement a function to modify
sched list")
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: Philipp Stanner
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.7+
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_entity.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 0e002c17fcb6..a75eede8bf8d 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -599,6 +599,9 @@ void drm_sched_entity_push_job(struct
drm_sched_job *sched_job)
/* first job wakes up scheduler */
if (first) {
+ struct drm_gpu_scheduler *sched;
+ struct drm_sched_rq *rq;
+
/* Add the entity to the run queue */
spin_lock(&entity->rq_lock);
if (entity->stopped) {
@@ -608,13 +611,16 @@ void drm_sched_entity_push_job(struct
drm_sched_job *sched_job)
return;
}
- drm_sched_rq_add_entity(entity->rq, entity);
+ rq = entity->rq;
+ sched = rq->sched;
+
+ drm_sched_rq_add_entity(rq, entity);
spin_unlock(&entity->rq_lock);
if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
drm_sched_rq_update_fifo(entity, submit_ts);
- drm_sched_wakeup(entity->rq->sched);
+ drm_sched_wakeup(sched);
}
}
EXPORT_SYMBOL(drm_sched_entity_push_job);
Re: [PATCH v5 10/11] drm/msm/A6xx: Enable preemption for A750
nit, lowercase "a6xx" in subject prefix
(no need to resend just for this, I can fix it up when applying
patches if needed.. but if you do resend pls fix that)
BR
-R
On Tue, Sep 24, 2024 at 4:30 AM Antonino Maniscalco
wrote:
>
> Initialize with 4 rings to enable preemption.
>
> For now only on A750 as other targets require testing.
>
> Add the "preemption_enabled" module parameter to override this for other
> A7xx targets.
>
> Tested-by: Neil Armstrong # on SM8650-QRD
> Tested-by: Neil Armstrong # on SM8550-QRD
> Tested-by: Neil Armstrong # on SM8450-HDK
> Signed-off-by: Antonino Maniscalco
> ---
> drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 3 ++-
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
> drivers/gpu/drm/msm/adreno/adreno_device.c | 4
> drivers/gpu/drm/msm/adreno/adreno_gpu.h| 1 +
> 4 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> index
> 316f23ca91671d973797f2a5b69344f376707325..0e3041b2941905f1acdc9e571e0549a960a7edfa
> 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> @@ -1240,7 +1240,8 @@ static const struct adreno_info a7xx_gpus[] = {
> .gmem = 3 * SZ_1M,
> .inactive_period = DRM_MSM_INACTIVE_PERIOD,
> .quirks = ADRENO_QUIRK_HAS_CACHED_COHERENT |
> - ADRENO_QUIRK_HAS_HW_APRIV,
> + ADRENO_QUIRK_HAS_HW_APRIV |
> + ADRENO_QUIRK_PREEMPTION,
> .init = a6xx_gpu_init,
> .zapfw = "gen70900_zap.mbn",
> .a6xx = &(const struct a6xx_info) {
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index
> edbcb6d229ba614be910ee70e75731538116e4a4..4760f9469613c0bf208f56be9608747b5aa75606
> 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -2529,6 +2529,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
> struct a6xx_gpu *a6xx_gpu;
> struct adreno_gpu *adreno_gpu;
> struct msm_gpu *gpu;
> + extern int enable_preemption;
> bool is_a7xx;
> int ret;
>
> @@ -2567,7 +2568,10 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
> return ERR_PTR(ret);
> }
>
> - if (is_a7xx)
> + if ((enable_preemption == 1) || (enable_preemption == -1 &&
> + (config->info->quirks & ADRENO_QUIRK_PREEMPTION)))
> + ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs_a7xx, 4);
> + else if (is_a7xx)
> ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs_a7xx, 1);
> else if (adreno_has_gmu_wrapper(adreno_gpu))
> ret = adreno_gpu_init(dev, pdev, adreno_gpu,
> &funcs_gmuwrapper, 1);
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index
> cfc74a9e2646d3de76a06bd67457d69afa49e309..9ffe91920fbfb4841b28aabec9fbde94539fdd83
> 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -20,6 +20,10 @@ bool allow_vram_carveout = false;
> MODULE_PARM_DESC(allow_vram_carveout, "Allow using VRAM Carveout, in place
> of IOMMU");
> module_param_named(allow_vram_carveout, allow_vram_carveout, bool, 0600);
>
> +int enable_preemption = -1;
> +MODULE_PARM_DESC(enable_preemption, "Enable preemption (A7xx only) (1=on ,
> 0=disable, -1=auto (default))");
> +module_param(enable_preemption, int, 0600);
> +
> extern const struct adreno_gpulist a2xx_gpulist;
> extern const struct adreno_gpulist a3xx_gpulist;
> extern const struct adreno_gpulist a4xx_gpulist;
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> index
> 87098567483b69c21025b80f356e0a68f0e7f172..d1cd53f05de68b3873f35520655e09e82fc40449
> 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> @@ -56,6 +56,7 @@ enum adreno_family {
> #define ADRENO_QUIRK_LMLOADKILL_DISABLEBIT(2)
> #define ADRENO_QUIRK_HAS_HW_APRIV BIT(3)
> #define ADRENO_QUIRK_HAS_CACHED_COHERENT BIT(4)
> +#define ADRENO_QUIRK_PREEMPTIONBIT(5)
>
> /* Helper for formating the chip_id in the way that userspace tools like
> * crashdec expect.
>
> --
> 2.46.1
>
Re: [PATCH v2] drm/amdgpu: add dce6 drm_panic support
On Fri, Sep 20, 2024 at 11:36 AM Jocelyn Falempe wrote:
>
> On 17/09/2024 15:21, Alex Deucher wrote:
> > On Mon, Aug 12, 2024 at 2:10 AM Lu Yao wrote:
> >>
> >> Add support for the drm_panic module, which displays a pretty user
> >> friendly message on the screen when a Linux kernel panic occurs.
> >>
> >> Signed-off-by: Lu Yao
> >
> > Patch looks good to me. Any chance you want to convert the other
> > non-DC dce files (dce_v8_0.c, dce_v10_0.c, dce_v11_0.c) while you are
> > at it?
>
> I've made a similar patch in amdgpu_dm_plane.c, and it works on a Radeon
> pro w6400.
> But it only works when I'm in a VT terminal (so the framebuffer is
> linear and CPU accessible).
> When under Gnome/Wayland, the flag AMDGPU_GEM_CREATE_NO_CPU_ACCESS is
> set, so that means I can't vmap it ?
It just means that the application does not need CPU access. Whether
or not the CPU can access the buffer or not depends on the size of the
PCI BAR. E.g., if the driver or bios has resized the PCI BAR, then
the CPU can access the entire BAR, but if not you are generally
limited to the first 256M of framebuffer.
>
> Also I don't know if there is a similar way to disable
> tiling/compression on this hardware.
UNP_GRPH_CONTROL on chips with DCE display hardware and
DCSURF_ADDR_CONFIG and DCSURF_TILING_CONFIG on DCN display hardware.
Alex
>
> Best regards,
>
> --
>
> Jocelyn
>
>
> >
> > Alex
> >
> >
> >> ---
> >> Changes in v2:
> >> 1. Drop include "drm_internal.h"
> >> 2. Add disabling DC tiling ops.
> >> Per suggestion from previous thread:
> >> https://patchwork.freedesktop.org/patch/606879/?series=136832&rev=1
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 48 +++
> >> 1 file changed, 48 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> >> b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> >> index 05c0df97f01d..ba1b7a36caa3 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> >> @@ -28,6 +28,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #include "amdgpu.h"
> >> #include "amdgpu_pm.h"
> >> @@ -2600,6 +2601,52 @@ static const struct drm_crtc_helper_funcs
> >> dce_v6_0_crtc_helper_funcs = {
> >> .get_scanout_position = amdgpu_crtc_get_scanout_position,
> >> };
> >>
> >> +static int dce_v6_0_drm_primary_plane_get_scanout_buffer(struct drm_plane
> >> *plane,
> >> +struct
> >> drm_scanout_buffer *sb)
> >> +{
> >> + struct drm_framebuffer *fb;
> >> + struct amdgpu_bo *abo;
> >> + struct amdgpu_crtc *amdgpu_crtc;
> >> + struct amdgpu_device *adev;
> >> + uint32_t fb_format;
> >> +
> >> + if (!plane->fb)
> >> + return -EINVAL;
> >> +
> >> + fb = plane->fb;
> >> +
> >> + abo = gem_to_amdgpu_bo(fb->obj[0]);
> >> + amdgpu_crtc = to_amdgpu_crtc(plane->crtc);
> >> + adev = drm_to_adev(fb->dev);
> >> +
> >> + if (!abo->kmap.virtual &&
> >> + ttm_bo_kmap(&abo->tbo, 0, PFN_UP(abo->tbo.base.size),
> >> &abo->kmap)) {
> >> + DRM_WARN("amdgpu bo map failed, panic won't be
> >> displayed\n");
> >> + return -ENOMEM;
> >> + }
> >> +
> >> + if (abo->kmap.bo_kmap_type & TTM_BO_MAP_IOMEM_MASK)
> >> + iosys_map_set_vaddr_iomem(&sb->map[0], abo->kmap.virtual);
> >> + else
> >> + iosys_map_set_vaddr(&sb->map[0], abo->kmap.virtual);
> >> +
> >> + sb->width = fb->width;
> >> + sb->height = fb->height;
> >> + sb->format = fb->format;
> >> + sb->pitch[0] = fb->pitches[0];
> >> +
> >> + /* Disable DC tiling */
> >> + fb_format = RREG32(mmGRPH_CONTROL + amdgpu_crtc->crtc_offset);
> >> + fb_format &= ~GRPH_ARRAY_MODE(0x7);
> >> + WREG32(mmGRPH_CONTROL + amdgpu_crtc->crtc_offset, fb_format);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static const struct drm_plane_helper_funcs
> >> dce_v6_0_drm_primary_plane_helper_funcs = {
> >> + .get_scanout_buffer = dce_v6_0_drm_primary_plane_get_scanout_buffer
> >> +};
> >> +
> >> static int dce_v6_0_crtc_init(struct amdgpu_device *adev, int index)
> >> {
> >> struct amdgpu_crtc *amdgpu_crtc;
> >> @@ -2627,6 +2674,7 @@ static int dce_v6_0_crtc_init(struct amdgpu_device
> >> *adev, int index)
> >> amdgpu_crtc->encoder = NULL;
> >> amdgpu_crtc->connector = NULL;
> >> drm_crtc_helper_add(&amdgpu_crtc->base,
> >> &dce_v6_0_crtc_helper_funcs);
> >> + drm_plane_helper_add(amdgpu_crtc->base.primary,
> >> &dce_v6_0_drm_primary_plane_helper_funcs);
> >>
> >> return 0;
> >> }
> >> --
> >> 2.25.1
> >>
> >
>
Re: [PATCH v7 3/3] drm/rockchip: Add basic RK3588 HDMI output support
Hi,
On Sat, Sep 14, 2024 at 09:56:53PM GMT, Cristian Ciocaltea wrote:
> The RK3588 SoC family integrates the newer Synopsys DesignWare HDMI 2.1
> Quad-Pixel (QP) TX controller IP and a HDMI/eDP TX Combo PHY based on a
> Samsung IP block.
>
> Add just the basic support for now, i.e. RGB output up to 4K@60Hz,
> without audio, CEC or any of the HDMI 2.1 specific features.
>
> Co-developed-by: Algea Cao
> Signed-off-by: Algea Cao
> Tested-by: Heiko Stuebner
> Signed-off-by: Cristian Ciocaltea
> ---
> drivers/gpu/drm/rockchip/Kconfig | 9 +
> drivers/gpu/drm/rockchip/Makefile | 1 +
> drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c | 436
> +
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 2 +
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h| 1 +
> 5 files changed, 449 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/Kconfig
> b/drivers/gpu/drm/rockchip/Kconfig
> index 23c49e91f1cc..448fadd4ba15 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -8,6 +8,7 @@ config DRM_ROCKCHIP
> select VIDEOMODE_HELPERS
> select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
> select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
> + select DRM_DW_HDMI_QP if ROCKCHIP_DW_HDMI_QP
> select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
> select GENERIC_PHY if ROCKCHIP_DW_MIPI_DSI
> select GENERIC_PHY_MIPI_DPHY if ROCKCHIP_DW_MIPI_DSI
> @@ -63,6 +64,14 @@ config ROCKCHIP_DW_HDMI
> enable HDMI on RK3288 or RK3399 based SoC, you should select
> this option.
>
> +config ROCKCHIP_DW_HDMI_QP
> + bool "Rockchip specific extensions for Synopsys DW HDMI QP"
> + select DRM_BRIDGE_CONNECTOR
> + help
> + This selects support for Rockchip SoC specific extensions
> + for the Synopsys DesignWare HDMI QP driver. If you want to
> + enable HDMI on RK3588 based SoC, you should select this option.
> +
> config ROCKCHIP_DW_MIPI_DSI
> bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
> select GENERIC_PHY_MIPI_DPHY
> diff --git a/drivers/gpu/drm/rockchip/Makefile
> b/drivers/gpu/drm/rockchip/Makefile
> index 3ff7b21c0414..3eab662a5a1d 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -11,6 +11,7 @@ rockchipdrm-$(CONFIG_ROCKCHIP_VOP) += rockchip_drm_vop.o
> rockchip_vop_reg.o
> rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
> rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI_QP) += dw_hdmi_qp-rockchip.o
> rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi-rockchip.o
> rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
> rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
> new file mode 100644
> index ..19d407c926bd
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
> @@ -0,0 +1,436 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2021-2022 Rockchip Electronics Co., Ltd.
> + * Copyright (c) 2024 Collabora Ltd.
> + *
> + * Author: Algea Cao
> + * Author: Cristian Ciocaltea
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "rockchip_drm_drv.h"
> +
> +#define RK3588_GRF_SOC_CON2 0x0308
> +#define RK3588_HDMI0_HPD_INT_MSK BIT(13)
> +#define RK3588_HDMI0_HPD_INT_CLR BIT(12)
> +#define RK3588_GRF_SOC_CON7 0x031c
> +#define RK3588_SET_HPD_PATH_MASK GENMASK(13, 12)
> +#define RK3588_GRF_SOC_STATUS1 0x0384
> +#define RK3588_HDMI0_LEVEL_INT BIT(16)
> +#define RK3588_GRF_VO1_CON3 0x000c
> +#define RK3588_SCLIN_MASKBIT(9)
> +#define RK3588_SDAIN_MASKBIT(10)
> +#define RK3588_MODE_MASK BIT(11)
> +#define RK3588_I2S_SEL_MASK BIT(13)
> +#define RK3588_GRF_VO1_CON9 0x0024
> +#define RK3588_HDMI0_GRANT_SEL BIT(10)
> +
> +#define HIWORD_UPDATE(val, mask) ((val) | (mask) << 16)
> +
> +struct rockchip_hdmi_qp {
> + struct device *dev;
> + struct regmap *regmap;
> + struct regmap *vo_regmap;
> + struct rockchip_encoder encoder;
> + struct clk *ref_clk;
> + struct dw_hdmi_qp *hdmi;
> + struct phy *phy;
> + struct gpio_desc *enable_gpio;
> + struct delayed_work hpd_work;
> +};
> +
> +static struct rockchip_hdmi_qp *to_rockchip_hdmi_qp(struct drm_encoder
> *encoder)
> +{
> + struct rockchip_encoder *rkencoder = to_rockchip_encoder(encoder);
> +
> + return container_of(rkencoder, struct rockchip_hdmi_qp, encoder);
> +}
> +
> +static void
> +dw_hdmi_qp_rockchip_enco
Re: [PATCH v4 00/11] Preemption support for A7XX
On Tue, Sep 24, 2024 at 07:47:12AM -0700, Rob Clark wrote: > On Tue, Sep 24, 2024 at 4:54 AM Antonino Maniscalco > wrote: > > > > On 9/20/24 7:09 PM, Akhil P Oommen wrote: > > > On Wed, Sep 18, 2024 at 09:46:33AM +0200, Neil Armstrong wrote: > > >> Hi, > > >> > > >> On 17/09/2024 13:14, Antonino Maniscalco wrote: > > >>> This series implements preemption for A7XX targets, which allows the > > >>> GPU to > > >>> switch to an higher priority ring when work is pushed to it, reducing > > >>> latency > > >>> for high priority submissions. > > >>> > > >>> This series enables L1 preemption with skip_save_restore which requires > > >>> the following userspace patches to function: > > >>> > > >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30544 > > >>> > > >>> A flag is added to `msm_submitqueue_create` to only allow submissions > > >>> from compatible userspace to be preempted, therefore maintaining > > >>> compatibility. > > >>> > > >>> Preemption is currently only enabled by default on A750, it can be > > >>> enabled on other targets through the `enable_preemption` module > > >>> parameter. This is because more testing is required on other targets. > > >>> > > >>> For testing on other HW it is sufficient to set that parameter to a > > >>> value of 1, then using the branch of mesa linked above, > > >>> `TU_DEBUG=hiprio` > > >>> allows to run any application as high priority therefore preempting > > >>> submissions from other applications. > > >>> > > >>> The `msm_gpu_preemption_trigger` and `msm_gpu_preemption_irq` traces > > >>> added in this series can be used to observe preemption's behavior as > > >>> well as measuring preemption latency. > > >>> > > >>> Some commits from this series are based on a previous series to enable > > >>> preemption on A6XX targets: > > >>> > > >>> https://lkml.kernel.org/1520489185-21828-1-git-send-email-smase...@codeaurora.org > > >>> > > >>> Signed-off-by: Antonino Maniscalco > > >>> --- > > >>> Changes in v4: > > >>> - Added missing register in pwrup list > > >>> - Removed and rearrange barriers > > >>> - Renamed `skip_inline_wptr` to `restore_wptr` > > >>> - Track ctx seqno per ring > > >>> - Removed secure preempt context > > >>> - NOP out postamble to disable it instantly > > >>> - Only emit pwrup reglist once > > >>> - Document bv_rptr_addr > > >>> - Removed unused A6XX_PREEMPT_USER_RECORD_SIZE > > >>> - Set name on preempt record buffer > > >>> - Link to v3: > > >>> https://lore.kernel.org/r/20240905-preemption-a750-t-v3-0-fd947699f...@gmail.com > > >>> > > >>> Changes in v3: > > >>> - Added documentation about preemption > > >>> - Use quirks to determine which target supports preemption > > >>> - Add a module parameter to force disabling or enabling preemption > > >>> - Clear postamble when profiling > > >>> - Define A6XX_CP_CONTEXT_SWITCH_CNTL_LEVEL fields in a6xx.xml > > >>> - Make preemption records MAP_PRIV > > >>> - Removed user ctx record (NON_PRIV) and patch 2/9 as it's not needed > > >>> anymore > > >>> - Link to v2: > > >>> https://lore.kernel.org/r/20240830-preemption-a750-t-v2-0-86aeead2c...@gmail.com > > >>> > > >>> Changes in v2: > > >>> - Added preept_record_size for X185 in PATCH 3/7 > > >>> - Added patches to reset perf counters > > >>> - Dropped unused defines > > >>> - Dropped unused variable (fixes warning) > > >>> - Only enable preemption on a750 > > >>> - Reject MSM_SUBMITQUEUE_ALLOW_PREEMPT for unsupported targets > > >>> - Added Akhil's Reviewed-By tags to patches 1/9,2/9,3/9 > > >>> - Added Neil's Tested-By tags > > >>> - Added explanation for UAPI changes in commit message > > >>> - Link to v1: > > >>> https://lore.kernel.org/r/20240815-preemption-a750-t-v1-0-7bda26c34...@gmail.com > > >>> > > >>> --- > > >>> Antonino Maniscalco (11): > > >>> drm/msm: Fix bv_fence being used as bv_rptr > > >>> drm/msm/A6XX: Track current_ctx_seqno per ring > > >>> drm/msm: Add a `preempt_record_size` field > > >>> drm/msm: Add CONTEXT_SWITCH_CNTL bitfields > > >>> drm/msm/A6xx: Implement preemption for A7XX targets > > >>> drm/msm/A6xx: Sync relevant adreno_pm4.xml changes > > >>> drm/msm/A6xx: Use posamble to reset counters on preemption > > >>> drm/msm/A6xx: Add traces for preemption > > >>> drm/msm/A6XX: Add a flag to allow preemption to > > >>> submitqueue_create > > >>> drm/msm/A6xx: Enable preemption for A750 > > >>> Documentation: document adreno preemption > > >>> > > >>>Documentation/gpu/msm-preemption.rst | 98 + > > >>>drivers/gpu/drm/msm/Makefile | 1 + > > >>>drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 2 +- > > >>>drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 +- > > >>>drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 2 +- > > >>>drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 +- > > >>>drivers/gpu/drm/msm/adreno/a6xx_catalog.c
Re: [PATCH 2/6] dt-bindings: iommu: mediatek: Fix interrupt count constraint for new SoCs
On Tue, Sep 24, 2024 at 06:31:52PM +0800, Macpaul Lin wrote:
> The infra-iommu node in mt8195.dtsi was triggering a CHECK_DTBS error due
> to an excessively long 'interrupts' property. The error message was:
>
> infra-iommu@10315000: interrupts: [[0, 795, 4, 0], [0, 796, 4, 0],
> [0, 797, 4, 0], [0, 798, 4, 0], [0, 799, 4, 0]]
> is too long
>
> To address this issue, add "minItems: 1" and "maxItems: 5" constraints to
> the 'interrupts' property in the DT binding schema. This change allows for
> flexibility in the number of interrupts for new SoCs
>
> Fixes: bca28426805d ("dt-bindings: iommu: mediatek: Convert IOMMU to DT
> schema")
>
This space should be removed.
> Signed-off-by: Macpaul Lin
> ---
> Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> index ea6b0f5f24de..a00f1f0045b1 100644
> --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> @@ -96,7 +96,8 @@ properties:
> maxItems: 1
>
>interrupts:
> -maxItems: 1
> +minItems: 1
> +maxItems: 5
You need to add an items list here, and probably some per compatible
constraints. What are each of the itnerrupts for?
>
>clocks:
> items:
> --
> 2.45.2
>
signature.asc
Description: PGP signature
Re: [PATCH 0/5] AMDGPU deadcode
* Alex Deucher (alexdeuc...@gmail.com) wrote: > On Sun, Sep 22, 2024 at 9:43 PM wrote: > > > > From: "Dr. David Alan Gilbert" > > > > Hi, > > This is a bunch of deadcode removal in amdgpu; > > some of the functions are ones which were previously > > used but haven't been for a while, others are functions > > that were added a few years ago and haven't ever been used. > > > > There are some others that I've not removed, which have > > been added in the last few years but not been used, > > I was worried maybe there are patches in someones tree > > about to use them (e.g. amdgpu_lsdma_copy_mem, amdgpu_mes_reg_wait, > > amdgpu_ras_unbind_aca, amdgpu_seq64_alloc, and > > amdgpu_xcp_prepare_resume) - I'd be happy to take those as > > well. Hi Alex, Thanks for taking the series, and the reply. > There are patches in flight that make use of at least some of these. > For example, the seq64 functions are used by the user queues patches > which are being reviewed now. Feel free to send out patches though if > you are inclined. If someone has plans to use something, they can > bring that up in the patch review. OK, I've made myself a note and will swing back at some point. > > One other thing I wasn't sure of; I removed > > amdgpu_device_ip_is_idle > > which has been unused since about 2016, but does that make > > the 'is_idle' methods unused or is there something else that calls > > them? > > They've been used on and off in proposed patches over the years. Some > of the IP specific code may call the IP specific is idle functions > directly rather than using the callbacks. Do you think the 'is_idle' member itself should go? Dave > Alex > > > > > (Sent from this kernel booted on my RX550 GPU) > > > > Dave > > > > Dr. David Alan Gilbert (5): > > drm/amdgpu: Remove unused amdgpu_device_ip_is_idle > > drm/amdgpu: Remove unused amdgpu_atpx functions > > drm/amdgpu: Remove unused amdgpu_gmc_vram_cpu_pa > > drm/amdgpu: Remove unused amdgpu_gfx_bit_to_me_queue > > drm/amdgpu: Remove unused amdgpu_i2c functions > > > > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 10 > > .../gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 12 - > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 24 -- > > drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 10 > > drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 2 -- > > drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 12 - > > drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 1 - > > drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 25 --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h | 4 --- > > 9 files changed, 100 deletions(-) > > > > -- > > 2.46.1 > > -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \dave @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/
Re: [PATCH] gpu: host1x: Request syncpoint IRQs only during probe
On 06/09/2024 09:38, Jon Hunter wrote:
Hi Mikko,
On 31/05/2024 08:07, Mikko Perttunen wrote:
From: Mikko Perttunen
Syncpoint IRQs are currently requested in a code path that runs
during resume. Due to this, we get multiple overlapping registered
interrupt handlers as host1x is suspended and resumed.
Rearrange interrupt code to only request IRQs during initialization.
Signed-off-by: Mikko Perttunen
...
This change is causing a boot regression on Tegra186 with the latest
-next. I have reverted this to confirm that this fixes the problem. I
don't see any crash log but the board appears to just hang.
I had a look at this and I was able to fix this by moving where
we initialise the interrupts to after the PM runtime enable ...
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index b62e4f0e8130..ff98d4903cac 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -625,12 +625,6 @@ static int host1x_probe(struct platform_device *pdev)
goto free_contexts;
}
- err = host1x_intr_init(host);
- if (err) {
- dev_err(&pdev->dev, "failed to initialize interrupts\n");
- goto deinit_syncpt;
- }
-
pm_runtime_enable(&pdev->dev);
err = devm_tegra_core_dev_init_opp_table_common(&pdev->dev);
@@ -642,6 +636,12 @@ static int host1x_probe(struct platform_device *pdev)
if (err)
goto pm_disable;
+ err = host1x_intr_init(host);
+ if (err) {
+ dev_err(&pdev->dev, "failed to initialize interrupts\n");
+ goto pm_put;
+ }
+
host1x_debug_init(host);
err = host1x_register(host);
@@ -658,14 +658,11 @@ static int host1x_probe(struct platform_device *pdev)
host1x_unregister(host);
deinit_debugfs:
host1x_debug_deinit(host);
-
+ host1x_intr_deinit(host);
+pm_put:
pm_runtime_put_sync_suspend(&pdev->dev);
pm_disable:
pm_runtime_disable(&pdev->dev);
-
- host1x_intr_deinit(host);
-deinit_syncpt:
- host1x_syncpt_deinit(host);
free_contexts:
host1x_memory_context_list_free(&host->context_list);
free_channels:
Thierry, do you want to me to send a fix for the above or do you
want to squash with the original (assuming that OK with Mikko)?
Jon
--
nvpublic
[PATCH v5 49/80] drm/fbdev-shmem: Support struct drm_driver.fbdev_probe
Rework fbdev probing to support fbdev_probe in struct drm_driver
and reimplement the old fb_probe callback on top of it. Provide an
initializer macro for struct drm_driver that sets the callback
according to the kernel configuration.
This change allows the common fbdev client to run on top of SHMEM-
based DRM drivers.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fbdev_shmem.c | 60 ++-
include/drm/drm_fbdev_shmem.h | 11 ++
2 files changed, 47 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_fbdev_shmem.c
b/drivers/gpu/drm/drm_fbdev_shmem.c
index 0c785007f11b..3bca333917d1 100644
--- a/drivers/gpu/drm/drm_fbdev_shmem.c
+++ b/drivers/gpu/drm/drm_fbdev_shmem.c
@@ -107,6 +107,40 @@ static struct page *drm_fbdev_shmem_get_page(struct
fb_info *info, unsigned long
static int drm_fbdev_shmem_helper_fb_probe(struct drm_fb_helper *fb_helper,
struct drm_fb_helper_surface_size
*sizes)
+{
+ return drm_fbdev_shmem_driver_fbdev_probe(fb_helper, sizes);
+}
+
+static int drm_fbdev_shmem_helper_fb_dirty(struct drm_fb_helper *helper,
+ struct drm_clip_rect *clip)
+{
+ struct drm_device *dev = helper->dev;
+ int ret;
+
+ /* Call damage handlers only if necessary */
+ if (!(clip->x1 < clip->x2 && clip->y1 < clip->y2))
+ return 0;
+
+ if (helper->fb->funcs->dirty) {
+ ret = helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, clip, 1);
+ if (drm_WARN_ONCE(dev, ret, "Dirty helper failed: ret=%d\n",
ret))
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct drm_fb_helper_funcs drm_fbdev_shmem_helper_funcs = {
+ .fb_probe = drm_fbdev_shmem_helper_fb_probe,
+ .fb_dirty = drm_fbdev_shmem_helper_fb_dirty,
+};
+
+/*
+ * struct drm_driver
+ */
+
+int drm_fbdev_shmem_driver_fbdev_probe(struct drm_fb_helper *fb_helper,
+ struct drm_fb_helper_surface_size *sizes)
{
struct drm_client_dev *client = &fb_helper->client;
struct drm_device *dev = fb_helper->dev;
@@ -139,6 +173,7 @@ static int drm_fbdev_shmem_helper_fb_probe(struct
drm_fb_helper *fb_helper,
goto err_drm_client_buffer_delete;
}
+ fb_helper->funcs = &drm_fbdev_shmem_helper_funcs;
fb_helper->buffer = buffer;
fb_helper->fb = fb;
@@ -182,30 +217,7 @@ static int drm_fbdev_shmem_helper_fb_probe(struct
drm_fb_helper *fb_helper,
drm_client_framebuffer_delete(buffer);
return ret;
}
-
-static int drm_fbdev_shmem_helper_fb_dirty(struct drm_fb_helper *helper,
- struct drm_clip_rect *clip)
-{
- struct drm_device *dev = helper->dev;
- int ret;
-
- /* Call damage handlers only if necessary */
- if (!(clip->x1 < clip->x2 && clip->y1 < clip->y2))
- return 0;
-
- if (helper->fb->funcs->dirty) {
- ret = helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, clip, 1);
- if (drm_WARN_ONCE(dev, ret, "Dirty helper failed: ret=%d\n",
ret))
- return ret;
- }
-
- return 0;
-}
-
-static const struct drm_fb_helper_funcs drm_fbdev_shmem_helper_funcs = {
- .fb_probe = drm_fbdev_shmem_helper_fb_probe,
- .fb_dirty = drm_fbdev_shmem_helper_fb_dirty,
-};
+EXPORT_SYMBOL(drm_fbdev_shmem_driver_fbdev_probe);
/*
* struct drm_client_funcs
diff --git a/include/drm/drm_fbdev_shmem.h b/include/drm/drm_fbdev_shmem.h
index fb43cadd1950..3a5d1efa9d55 100644
--- a/include/drm/drm_fbdev_shmem.h
+++ b/include/drm/drm_fbdev_shmem.h
@@ -4,12 +4,23 @@
#define DRM_FBDEV_SHMEM_H
struct drm_device;
+struct drm_fb_helper;
+struct drm_fb_helper_surface_size;
#ifdef CONFIG_DRM_FBDEV_EMULATION
+int drm_fbdev_shmem_driver_fbdev_probe(struct drm_fb_helper *fb_helper,
+ struct drm_fb_helper_surface_size
*sizes);
+
+#define DRM_FBDEV_SHMEM_DRIVER_OPS \
+ .fbdev_probe = drm_fbdev_shmem_driver_fbdev_probe
+
void drm_fbdev_shmem_setup(struct drm_device *dev, unsigned int preferred_bpp);
#else
static inline void drm_fbdev_shmem_setup(struct drm_device *dev, unsigned int
preferred_bpp)
{ }
+
+#define DRM_FBDEV_SHMEM_DRIVER_OPS \
+ .fbdev_probe = NULL
#endif
#endif
--
2.46.0
[PATCH v5 40/80] drm/sun4i: Run DRM default client setup
Call drm_client_setup() to run the kernel's default client setup
for DRM. Set fbdev_probe in struct drm_driver, so that the client
setup can start the common fbdev client.
The sun4i driver specifies as preferred color mode of 32. As this
is the default if no format has been given, leave it out entirely.
v5:
- select DRM_CLIENT_SELECTION
Signed-off-by: Thomas Zimmermann
Cc: Maxime Ripard
Cc: Chen-Yu Tsai
Cc: Jernej Skrabec
Cc: Samuel Holland
Acked-by: Javier Martinez Canillas
---
drivers/gpu/drm/sun4i/Kconfig | 1 +
drivers/gpu/drm/sun4i/sun4i_drv.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 4037e085430e..b56ba00aabca 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -3,6 +3,7 @@ config DRM_SUN4I
tristate "DRM Support for Allwinner A10 Display Engine"
depends on DRM && COMMON_CLK
depends on ARCH_SUNXI || COMPILE_TEST
+ select DRM_CLIENT_SELECTION
select DRM_GEM_DMA_HELPER
select DRM_KMS_HELPER
select DRM_PANEL
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 35d7a7ffd208..c3342789e3b0 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
#include
#include
@@ -55,6 +56,7 @@ static const struct drm_driver sun4i_drv_driver = {
/* GEM Operations */
DRM_GEM_DMA_DRIVER_OPS_WITH_DUMB_CREATE(drm_sun4i_gem_dumb_create),
+ DRM_FBDEV_DMA_DRIVER_OPS,
};
static int sun4i_drv_bind(struct device *dev)
@@ -111,7 +113,7 @@ static int sun4i_drv_bind(struct device *dev)
if (ret)
goto finish_poll;
- drm_fbdev_dma_setup(drm, 32);
+ drm_client_setup(drm, NULL);
dev_set_drvdata(dev, drm);
--
2.46.0
[PATCH v5 42/80] drm/tilcdc: Run DRM default client setup
Call drm_client_setup_with_color_mode() to run the kernel's default
client setup for DRM. Set fbdev_probe in struct drm_driver, so that
the client setup can start the common fbdev client.
v5:
- select DRM_CLIENT_SELECTION
v3:
- add DRM_FBDEV_DMA_DRIVER_OPS macro
Signed-off-by: Thomas Zimmermann
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Acked-by: Javier Martinez Canillas
---
drivers/gpu/drm/tilcdc/Kconfig | 1 +
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 5 -
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index d3bd2d7a181e..24f9a245ba59 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -2,6 +2,7 @@
config DRM_TILCDC
tristate "DRM Support for TI LCDC Display Controller"
depends on DRM && OF && ARM
+ select DRM_CLIENT_SELECTION
select DRM_KMS_HELPER
select DRM_GEM_DMA_HELPER
select DRM_BRIDGE
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index cd5eefa06060..8c9f3705aa6c 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -14,6 +14,7 @@
#include
#include
+#include
#include
#include
#include
@@ -374,7 +375,8 @@ static int tilcdc_init(const struct drm_driver *ddrv,
struct device *dev)
goto init_failed;
priv->is_registered = true;
- drm_fbdev_dma_setup(ddev, bpp);
+ drm_client_setup_with_color_mode(ddev, bpp);
+
return 0;
init_failed:
@@ -472,6 +474,7 @@ DEFINE_DRM_GEM_DMA_FOPS(fops);
static const struct drm_driver tilcdc_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
DRM_GEM_DMA_DRIVER_OPS,
+ DRM_FBDEV_DMA_DRIVER_OPS,
#ifdef CONFIG_DEBUG_FS
.debugfs_init = tilcdc_debugfs_init,
#endif
--
2.46.0
[PATCH v5 13/80] drm/hisilicon/kirin: Run DRM default client setup
Call drm_client_setup() to run the kernel's default client setup
for DRM. Set fbdev_probe in struct drm_driver, so that the client
setup can start the common fbdev client.
The kirin driver specifies a preferred color mode of 32. As this
is the default if no format has been given, leave it out entirely.
v5:
- select DRM_CLIENT_SELECTION
Signed-off-by: Thomas Zimmermann
Cc: Xinliang Liu
Cc: Tian Tao
Cc: Xinwei Kong
Cc: Sumit Semwal
Cc: Yongqin Liu
Cc: John Stultz
Acked-by: John Stultz
---
drivers/gpu/drm/hisilicon/kirin/Kconfig | 1 +
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 ++
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 4 ++--
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig
b/drivers/gpu/drm/hisilicon/kirin/Kconfig
index 0772f79567ef..43e8a4fd2d11 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Kconfig
+++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
@@ -2,6 +2,7 @@
config DRM_HISI_KIRIN
tristate "DRM Support for Hisilicon Kirin series SoCs Platform"
depends on DRM && OF && (ARM64 || COMPILE_TEST)
+ select DRM_CLIENT_SELECTION
select DRM_KMS_HELPER
select DRM_GEM_DMA_HELPER
select DRM_MIPI_DSI
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 871f79a6b17e..5616c3917c03 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -925,6 +926,7 @@ static const struct drm_driver ade_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops = &ade_fops,
DRM_GEM_DMA_DRIVER_OPS,
+ DRM_FBDEV_DMA_DRIVER_OPS,
.name = "kirin",
.desc = "Hisilicon Kirin620 SoC DRM Driver",
.date = "20150718",
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 12666985686b..86a3a1faff49 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -18,8 +18,8 @@
#include
#include
+#include
#include
-#include
#include
#include
#include
@@ -237,7 +237,7 @@ static int kirin_drm_bind(struct device *dev)
if (ret)
goto err_kms_cleanup;
- drm_fbdev_dma_setup(drm_dev, 32);
+ drm_client_setup(drm_dev, NULL);
return 0;
--
2.46.0
[PATCH v5 41/80] drm/tidss: Run DRM default client setup
Call drm_client_setup() to run the kernel's default client setup
for DRM. Set fbdev_probe in struct drm_driver, so that the client
setup can start the common fbdev client.
The tidss driver specifies a preferred color mode of 32. As this
is the default if no format has been given, leave it out entirely.
v5:
- select DRM_CLIENT_SELECTION
Signed-off-by: Thomas Zimmermann
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Acked-by: Javier Martinez Canillas
---
drivers/gpu/drm/tidss/Kconfig | 1 +
drivers/gpu/drm/tidss/tidss_drv.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tidss/Kconfig b/drivers/gpu/drm/tidss/Kconfig
index 2385c56493b9..31ad582b7602 100644
--- a/drivers/gpu/drm/tidss/Kconfig
+++ b/drivers/gpu/drm/tidss/Kconfig
@@ -2,6 +2,7 @@ config DRM_TIDSS
tristate "DRM Support for TI Keystone"
depends on DRM && OF
depends on ARM || ARM64 || COMPILE_TEST
+ select DRM_CLIENT_SELECTION
select DRM_KMS_HELPER
select DRM_DISPLAY_HELPER
select DRM_BRIDGE_CONNECTOR
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c
b/drivers/gpu/drm/tidss/tidss_drv.c
index d15f836dca95..2428b9aaa003 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.c
+++ b/drivers/gpu/drm/tidss/tidss_drv.c
@@ -11,6 +11,7 @@
#include
#include
+#include
#include
#include
#include
@@ -109,6 +110,7 @@ static const struct drm_driver tidss_driver = {
.fops = &tidss_fops,
.release= tidss_release,
DRM_GEM_DMA_DRIVER_OPS_VMAP,
+ DRM_FBDEV_DMA_DRIVER_OPS,
.name = "tidss",
.desc = "TI Keystone DSS",
.date = "20180215",
@@ -186,7 +188,7 @@ static int tidss_probe(struct platform_device *pdev)
goto err_irq_uninstall;
}
- drm_fbdev_dma_setup(ddev, 32);
+ drm_client_setup(ddev, NULL);
dev_dbg(dev, "%s done\n", __func__);
--
2.46.0
Re: [RFC PATCH 05/28] drm/gpusvm: Add support for GPU Shared Virtual Memory
On Fri, Sep 06, 2024 at 06:41:18PM +, Zeng, Oak wrote: > There are fundamental design conflicts with what we have aligned, see inline. > > > -Original Message- > > From: Intel-xe On Behalf > > Of Matthew Brost > > Sent: Tuesday, August 27, 2024 10:49 PM > > To: intel...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > > Cc: airl...@gmail.com; christian.koe...@amd.com; > > thomas.hellst...@linux.intel.com; Auld, Matthew > > ; dan...@ffwll.ch > > Subject: [RFC PATCH 05/28] drm/gpusvm: Add support for GPU > > Shared Virtual Memory > > > > This patch introduces support for GPU Shared Virtual Memory (SVM) > > in the > > Direct Rendering Manager (DRM) subsystem. SVM allows for > > seamless > > sharing of memory between the CPU and GPU, enhancing > > performance and > > flexibility in GPU computing tasks. > > > > The patch adds the necessary infrastructure for SVM, including data > > structures and functions for managing SVM ranges and notifiers. It > > also > > provides mechanisms for allocating, deallocating, and migrating > > memory > > regions between system RAM and GPU VRAM. > > > > This mid-layer is largely inspired by GPUVM. > > > > Cc: Dave Airlie > > Cc: Thomas Hellström > > Cc: Christian König > > Cc: > > Signed-off-by: Matthew Brost > > --- > > drivers/gpu/drm/xe/Makefile |3 +- > > drivers/gpu/drm/xe/drm_gpusvm.c | 2174 > > +++ > > drivers/gpu/drm/xe/drm_gpusvm.h | 415 ++ > > 3 files changed, 2591 insertions(+), 1 deletion(-) > > create mode 100644 drivers/gpu/drm/xe/drm_gpusvm.c > > create mode 100644 drivers/gpu/drm/xe/drm_gpusvm.h > > > > diff --git a/drivers/gpu/drm/xe/Makefile > > b/drivers/gpu/drm/xe/Makefile > > index b9670ae09a9e..b8fc2ee58f1a 100644 > > --- a/drivers/gpu/drm/xe/Makefile > > +++ b/drivers/gpu/drm/xe/Makefile > > @@ -25,7 +25,8 @@ $(obj)/generated/%_wa_oob.c > > $(obj)/generated/%_wa_oob.h: $(obj)/xe_gen_wa_oob \ > > > > # core driver code > > > > -xe-y += xe_bb.o \ > > +xe-y += drm_gpusvm.o \ > > + xe_bb.o \ > > xe_bo.o \ > > xe_bo_evict.o \ > > xe_devcoredump.o \ > > diff --git a/drivers/gpu/drm/xe/drm_gpusvm.c > > b/drivers/gpu/drm/xe/drm_gpusvm.c > > new file mode 100644 > > index ..fc1e44e6ae72 > > --- /dev/null > > +++ b/drivers/gpu/drm/xe/drm_gpusvm.c > > @@ -0,0 +1,2174 @@ > > +// SPDX-License-Identifier: MIT > > +/* > > + * Copyright © 2024 Intel Corporation > > + * > > + * Authors: > > + * Matthew Brost > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include "drm_gpusvm.h" > > + > > +/** > > + * DOC: Overview > > + * > > + * GPU Shared Virtual Memory (GPU SVM) layer for the Direct > > Rendering Manager (DRM) > > + * > > + * The GPU SVM layer is a component of the DRM framework > > designed to manage shared > > + * virtual memory between the CPU and GPU. It enables efficient > > data exchange and > > + * processing for GPU-accelerated applications by allowing memory > > sharing and > > + * synchronization between the CPU's and GPU's virtual address > > spaces. > > + * > > + * Key GPU SVM Components: > > + * - Notifiers: Notifiers: Used for tracking memory intervals and > > notifying the > > + * GPU of changes, notifiers are sized based on a GPU > > SVM > > + * initialization parameter, with a recommendation of > > 512M or > > + * larger. They maintain a Red-BlacK tree and a list of > > ranges that > > + * fall within the notifier interval. Notifiers are tracked > > within > > + * a GPU SVM Red-BlacK tree and list and are > > dynamically inserted > > + * or removed as ranges within the interval are created > > or > > + * destroyed. > > + * - Ranges: Represent memory ranges mapped in a DRM device and > > managed > > + * by GPU SVM. > > > This svm_range concept has introduced a lot of code duplications in xekmd, > Indicating that this is a wrong design. I think one of the design principle > is to > Reuse, not to duplicate. > > Look at patch 9, 11, bunch of duplicated codes to page table update, > invalidate, > And page fault handler. > > I had this range concept in v1 [1], but after we agreed to unify svm and > userptr > Codes during review, I dropped this concept, and the xe_svm concept, which > ends > Up much less duplicated codes in v2[2]. I will say more below why I thought > the svm > Concept can also be removed. > > Conceptually vma represent a range. Why duplicate? Because we cannot rely on mmap_read/write locks or vma_read/write locks without causing headaches. They are core mm datastructures that the gpu driver does not own, so for better or worse we have to do a bit of duplication. Duplication for no reaons is bad, but trying to avoid necessary duplication that's inherit to the design challenge we face is much worse. > [1] https://patchwork.freedesktop.org/patch/5
Re: [RFC PATCH 00/10] drm/panthor: Add user submission
Apologies for the late reply ... On Wed, Sep 04, 2024 at 01:34:18PM +0200, Christian König wrote: > Hi Boris, > > Am 04.09.24 um 13:23 schrieb Boris Brezillon: > > > > > > Please read up here on why that stuff isn't allowed: > > > > > > https://www.kernel.org/doc/html/latest/driver-api/dma-buf.html#indefinite-dma-fences > > > > > panthor doesn't yet have a shrinker, so all memory is pinned, which > > > > > means > > > > > memory management easy mode. > > > > Ok, that at least makes things work for the moment. > > > Ah, perhaps this should have been spelt out more clearly ;) > > > > > > The VM_BIND mechanism that's already in place jumps through some hoops > > > to ensure that memory is preallocated when the memory operations are > > > enqueued. So any memory required should have been allocated before any > > > sync object is returned. We're aware of the issue with memory > > > allocations on the signalling path and trying to ensure that we don't > > > have that. > > > > > > I'm hoping that we don't need a shrinker which deals with (active) GPU > > > memory with our design. > > That's actually what we were planning to do: the panthor shrinker was > > about to rely on fences attached to GEM objects to know if it can > > reclaim the memory. This design relies on each job attaching its fence > > to the GEM mapped to the VM at the time the job is submitted, such that > > memory that's in-use or about-to-be-used doesn't vanish before the GPU > > is done. > > Yeah and exactly that doesn't work any more when you are using user queues, > because the kernel has no opportunity to attach a fence for each submission. > > > > Memory which user space thinks the GPU might > > > need should be pinned before the GPU work is submitted. APIs which > > > require any form of 'paging in' of data would need to be implemented by > > > the GPU work completing and being resubmitted by user space after the > > > memory changes (i.e. there could be a DMA fence pending on the GPU work). > > Hard pinning memory could work (ioctl() around gem_pin/unpin()), but > > that means we can't really transparently swap out GPU memory, or we > > have to constantly pin/unpin around each job, which means even more > > ioctl()s than we have now. Another option would be to add the XGS fence > > to the BOs attached to the VM, assuming it's created before the job > > submission itself, but you're no longer reducing the number of user <-> > > kernel round trips if you do that, because you now have to create an > > XSG job for each submission, so you basically get back to one ioctl() > > per submission. > > For AMDGPU we are currently working on the following solution with memory > management and user queues: > > 1. User queues are created through an kernel IOCTL, submissions work by > writing into a ring buffer and ringing a doorbell. > > 2. Each queue can request the kernel to create fences for the currently > pushed work for a queues which can then be attached to BOs, syncobjs, > syncfiles etc... > > 3. Additional to that we have and eviction/preemption fence attached to all > BOs, page tables, whatever resources we need. > > 4. When this eviction fences are requested to signal they first wait for all > submission fences and then suspend the user queues and block creating new > submission fences until the queues are restarted again. Yup this works, at least when I play it out in my head. Note that the completion fence is only deadlock free if userspace is really, really careful. Which in practice means you need the very carefully constructed rules for e.g. vulkan winsys fences, otherwise you do indeed deadlock. But if you keep that promise in mind, then it works, and step 2 is entirely option, which means we can start userspace in a pure long-running compute mode where there's only eviction/preemption fences. And then if userspace needs a vulkan winsys fence, we can create that with step 2 as needed. But the important part is that you need really strict rules on userspace for when step 2 is ok and won't result in deadlocks. And those rules are uapi, which is why I think doing this in panthor without the shrinker and eviction fences (i.e. steps 3&4 above) is a very bad mistake. > This way you can still do your memory management inside the kernel (e.g. > move BOs from local to system memory) or even completely suspend and resume > applications without their interaction, but as Sima said it is just horrible > complicated to get right. > > We have been working on this for like two years now and it still could be > that we missed something since it is not in production testing yet. Ack. -Sima -- Simona Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v17 1/8] drm: bridge: Cadence: Create mhdp helper driver
On Tue, Sep 24, 2024 at 10:41:26AM GMT, Alexander Stein wrote: > Hi Sandor, > > Am Dienstag, 24. September 2024, 09:36:46 CEST schrieb Sandor Yu: > > MHDP8546 mailbox access functions will be share to other mhdp driver > > and Cadence HDP-TX HDMI/DP PHY drivers. > > Create a new mhdp helper driver and move all those functions into. > > > > cdns_mhdp_reg_write() is renamed to cdns_mhdp_dp_reg_write(), > > because it use the DPTX command ID DPTX_WRITE_REGISTER. > > > > New cdns_mhdp_reg_write() is created with the general command ID > > GENERAL_REGISTER_WRITE. > > > > Rewrite cdns_mhdp_set_firmware_active() in mhdp8546 core driver, > > use cdns_mhdp_mailbox_send() to replace cdns_mhdp_mailbox_write() > > same as the other mailbox access functions. > > > > Replaces the local mutex mbox_mutex with a global mutex mhdp_mailbox_mutex > > to prevent race conditions in mailbox access by multi drivers. > > > > Signed-off-by: Sandor Yu > > --- > > v16->v17: > > - Replaces the local mutex mbox_mutex with a global mutex mhdp_mailbox_mutex > > > > v12->v16: > > *No change. > > > > V11->v12: > > - Move status initialize out of mbox_mutex. > > - Reorder API functions in alphabetical. > > - Add notes for malibox access functions. > > - Add year 2024 to copyright. > > > > drivers/gpu/drm/bridge/cadence/Kconfig| 4 + > > drivers/gpu/drm/bridge/cadence/Makefile | 1 + > > .../gpu/drm/bridge/cadence/cdns-mhdp-helper.c | 307 + > > .../drm/bridge/cadence/cdns-mhdp8546-core.c | 425 -- > > .../drm/bridge/cadence/cdns-mhdp8546-core.h | 47 +- > > .../drm/bridge/cadence/cdns-mhdp8546-hdcp.c | 36 +- > > include/drm/bridge/cdns-mhdp-helper.h | 94 > > 7 files changed, 507 insertions(+), 407 deletions(-) > > create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c > > create mode 100644 include/drm/bridge/cdns-mhdp-helper.h > > > > diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig > > b/drivers/gpu/drm/bridge/cadence/Kconfig > > index cced81633ddcd..e0973339e9e33 100644 > > --- a/drivers/gpu/drm/bridge/cadence/Kconfig > > +++ b/drivers/gpu/drm/bridge/cadence/Kconfig > > @@ -21,6 +21,9 @@ config DRM_CDNS_DSI_J721E > > the routing of the DSS DPI signal to the Cadence DSI. > > endif > > > > +config CDNS_MHDP_HELPER > > + tristate > > + > > config DRM_CDNS_MHDP8546 > > tristate "Cadence DPI/DP bridge" > > select DRM_DISPLAY_DP_HELPER > > @@ -28,6 +31,7 @@ config DRM_CDNS_MHDP8546 > > select DRM_DISPLAY_HELPER > > select DRM_KMS_HELPER > > select DRM_PANEL_BRIDGE > > + select CDNS_MHDP_HELPER > > depends on OF > > help > > Support Cadence DPI to DP bridge. This is an internal > > diff --git a/drivers/gpu/drm/bridge/cadence/Makefile > > b/drivers/gpu/drm/bridge/cadence/Makefile > > index c95fd5b81d137..087dc074820d7 100644 > > --- a/drivers/gpu/drm/bridge/cadence/Makefile > > +++ b/drivers/gpu/drm/bridge/cadence/Makefile > > @@ -2,6 +2,7 @@ > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > cdns-dsi-y := cdns-dsi-core.o > > cdns-dsi-$(CONFIG_DRM_CDNS_DSI_J721E) += cdns-dsi-j721e.o > > +obj-$(CONFIG_CDNS_MHDP_HELPER) += cdns-mhdp-helper.o > > obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o > > cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o > > cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o > > diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c > > b/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c > > new file mode 100644 > > index 0..c60a6b69a5343 > > --- /dev/null > > +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c > > @@ -0,0 +1,307 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * Copyright (C) 2023, 2024 NXP Semiconductor, Inc. > > + * > > + */ > > +#include > > +#include > > +#include > > + > > +/* Protects mailbox communications with the firmware */ > > +DEFINE_MUTEX(mhdp_mailbox_mutex); > > This is not enough if the driver is built as a module: > > > ERROR: modpost: "mhdp_mailbox_mutex" > > [drivers/gpu/drm/bridge/cadence/cdns-mhdp8546.ko] undefined! ERROR: > > modpost: "mhdp_mailbox_mutex" > > [drivers/gpu/drm/bridge/cadence/cdns-mhdp8501.ko] undefined! > > Not sure if EXPORT_SYMBOL_GPL() on a mutex is considered good style. Absolutely no. The API should wrap register access, using the mutex whether required, rather than exporting the mutex for everybody else to use. > > Best regards, > Alexander > > > [snip] > -- > TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany > Amtsgericht München, HRB 105018 > Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider > http://www.tq-group.com/ > > -- With best wishes Dmitry
Re: [PATCH v2 1/1] drm/mediatek: dp: Add sdp path reset
Il 24/09/24 10:36, Liankun Yang ha scritto: When using type-c to type-c to connect to the monitor, the sound plays normally. If you unplug the type-c and connect the type-c to hdmi dongle to the monitor, there will be noise. By capturing the audio data, it is found that the data position is messy, and there is no error in the data. Through experiments, it can be restored by resetting the SDP path when unplugging it. Signed-off-by: Liankun Yang Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v2] fbcon: Fix a NULL pointer dereference issue in fbcon_putcs
Hi Qianqiang,
On 9/24/24 18:13, Qianqiang Liu wrote:
syzbot has found a NULL pointer dereference bug in fbcon.
This issue is caused by ops->putcs being a NULL pointer.
We need to ensure it is initialized properly.
Reported-by: syzbot+3d613ae53c0315026...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3d613ae53c031502687a
Tested-by: syzbot+3d613ae53c0315026...@syzkaller.appspotmail.com
Signed-off-by: Qianqiang Liu
---
Changes since v1:
- Initialize ops->putcs by calling set_blitting_type()
Thanks a lot tracking this issue down!
At first sight your patch seems correct.
But could you please document in the patch description what exactly (and why)
something goes wrong and how your patch fixes it?
E.g. why was opt->putcs missed to be initialized even earlier and why does
it need initialization now?
You did a good work in producing a reduced testcase.
If it's quite small, it's a good idea to even include it in the
commit message?
Helge
---
drivers/video/fbdev/core/fbcon.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 2e093535884b..d9abae2516d8 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -861,6 +861,8 @@ static int set_con2fb_map(int unit, int newidx, int user)
return err;
fbcon_add_cursor_work(info);
+ } else if (vc) {
+ set_blitting_type(vc, info);
}
con2fb_map[unit] = newidx;
Re: [PATCH 0/2] drm: revert some framebuffer API tests
On Tue, Sep 24, 2024 at 06:56:26PM GMT, Jani Nikula wrote: > On Tue, 24 Sep 2024, Guenter Roeck wrote: > On Tue, Sep 24, 2024 at 12:06:28PM GMT, Simona Vetter wrote: > > Yeah I think long-term we might want a kunit framework so that we can > > catch dmesg warnings we expect and test for those, without those > > warnings > > actually going to dmesg. Similar to how the lockdep tests also reroute > > locking validation, so that the expected positive tests don't wreak > > lockdep for real. > > > > But until that exists, we can't have tests that splat in dmesg when they > > work as intended. > > > > FWIW, that is arguable. More and more tests are added which do add such > > splats, > > and I don't see any hesitance by developers to adding more. So far I counted > > two alone in this commit window, and that does not include new splats from > > tests which I had already disabled. I simply disable those tests or don't > > enable them in the first place if they are new. I did the same with the drm > > unit tests due to the splats generated by the scaling unit tests, so any > > additional drm unit test splats don't make a difference for me since the > > tests are already disabled. > > What's the point of having unit tests that CI systems routinely have to > filter out of test runs? Or filter warnings generated by the tests, > potentially missing new warnings. Who is going to run the tests if the > existing CI systems choose to ignore them? If we turn this argument around, that means we can't write unit test for code that will create a warning. IMO, this creates a bad incentive, and saying that any capable CI system should reject them is certainly opiniated. Maxime signature.asc Description: PGP signature
Re: [PATCH 5/5] drm/amdgpu: Remove unused amdgpu_i2c functions
Applied the series. Thanks!
Alex
On Sun, Sep 22, 2024 at 9:43 PM wrote:
>
> From: "Dr. David Alan Gilbert"
>
> amdgpu_i2c_add and amdgpu_i2c_init were added in 2015's commit
> d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
> but never used.
>
> Remove them.
>
> Signed-off-by: Dr. David Alan Gilbert
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 25 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h | 4
> 2 files changed, 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> index 00d6211e0fbf..f0765ccde668 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> @@ -225,15 +225,6 @@ void amdgpu_i2c_destroy(struct amdgpu_i2c_chan *i2c)
> kfree(i2c);
> }
>
> -/* Add the default buses */
> -void amdgpu_i2c_init(struct amdgpu_device *adev)
> -{
> - if (amdgpu_hw_i2c)
> - DRM_INFO("hw_i2c forced on, you may experience display
> detection problems!\n");
> -
> - amdgpu_atombios_i2c_init(adev);
> -}
> -
> /* remove all the buses */
> void amdgpu_i2c_fini(struct amdgpu_device *adev)
> {
> @@ -247,22 +238,6 @@ void amdgpu_i2c_fini(struct amdgpu_device *adev)
> }
> }
>
> -/* Add additional buses */
> -void amdgpu_i2c_add(struct amdgpu_device *adev,
> - const struct amdgpu_i2c_bus_rec *rec,
> - const char *name)
> -{
> - struct drm_device *dev = adev_to_drm(adev);
> - int i;
> -
> - for (i = 0; i < AMDGPU_MAX_I2C_BUS; i++) {
> - if (!adev->i2c_bus[i]) {
> - adev->i2c_bus[i] = amdgpu_i2c_create(dev, rec, name);
> - return;
> - }
> - }
> -}
> -
> /* looks up bus based on id */
> struct amdgpu_i2c_chan *
> amdgpu_i2c_lookup(struct amdgpu_device *adev,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h
> index 63c2ff7499e1..21e3d1dad0a1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h
> @@ -28,11 +28,7 @@ struct amdgpu_i2c_chan *amdgpu_i2c_create(struct
> drm_device *dev,
> const struct amdgpu_i2c_bus_rec
> *rec,
> const char *name);
> void amdgpu_i2c_destroy(struct amdgpu_i2c_chan *i2c);
> -void amdgpu_i2c_init(struct amdgpu_device *adev);
> void amdgpu_i2c_fini(struct amdgpu_device *adev);
> -void amdgpu_i2c_add(struct amdgpu_device *adev,
> - const struct amdgpu_i2c_bus_rec *rec,
> - const char *name);
> struct amdgpu_i2c_chan *
> amdgpu_i2c_lookup(struct amdgpu_device *adev,
> const struct amdgpu_i2c_bus_rec *i2c_bus);
> --
> 2.46.1
>
Re: [PATCH 0/2] drm: revert some framebuffer API tests
On 9/24/24 09:57, Maxime Ripard wrote: On Tue, Sep 24, 2024 at 06:56:26PM GMT, Jani Nikula wrote: On Tue, 24 Sep 2024, Guenter Roeck wrote: On Tue, Sep 24, 2024 at 12:06:28PM GMT, Simona Vetter wrote: Yeah I think long-term we might want a kunit framework so that we can catch dmesg warnings we expect and test for those, without those warnings actually going to dmesg. Similar to how the lockdep tests also reroute locking validation, so that the expected positive tests don't wreak lockdep for real. But until that exists, we can't have tests that splat in dmesg when they work as intended. FWIW, that is arguable. More and more tests are added which do add such splats, and I don't see any hesitance by developers to adding more. So far I counted two alone in this commit window, and that does not include new splats from tests which I had already disabled. I simply disable those tests or don't enable them in the first place if they are new. I did the same with the drm unit tests due to the splats generated by the scaling unit tests, so any additional drm unit test splats don't make a difference for me since the tests are already disabled. What's the point of having unit tests that CI systems routinely have to filter out of test runs? Or filter warnings generated by the tests, potentially missing new warnings. Who is going to run the tests if the existing CI systems choose to ignore them? If we turn this argument around, that means we can't write unit test for code that will create a warning. IMO, this creates a bad incentive, and saying that any capable CI system should reject them is certainly opiniated. Agreed. All I am saying is that _I_ am rejecting them, but it is up to each individual testbed (or, rather, testbed maintainer) to decide how to handle the situation. Guenter
Re: [PATCH v6 1/4] drm: Introduce device wedged event
On Tue, Sep 24, 2024 at 01:23:13PM +0200, Simona Vetter wrote: > On Mon, Sep 23, 2024 at 09:28:23AM +0530, Raag Jadav wrote: > > Introduce device wedged event, which will notify userspace of wedged > > (hanged/unusable) state of the DRM device through a uevent. This is > > useful especially in cases where the device is no longer operating as > > expected and has become unrecoverable from driver context. > > > > Purpose of this implementation is to provide drivers a way to recover > > through userspace intervention. Different drivers may have different > > ideas of a "wedged device" depending on their hardware implementation, > > and hence the vendor agnostic nature of the event. It is up to the drivers > > to decide when they see the need for recovery and how they want to recover > > from the available methods. > > > > Current implementation defines three recovery methods, out of which, > > drivers can choose to support any one or multiple of them. Preferred > > recovery method will be sent in the uevent environment as WEDGED=. > > Userspace consumers (sysadmin) can define udev rules to parse this event > > and take respective action to recover the device. > > > > Method| Consumer expectations > > ---|--- > > rebind| unbind + rebind driver > > bus-reset | unbind + reset bus device + rebind > > reboot| reboot system > > > > v4: s/drm_dev_wedged/drm_dev_wedged_event > > Use drm_info() (Jani) > > Kernel doc adjustment (Aravind) > > v5: Send recovery method with uevent (Lina) > > v6: Access wedge_recovery_opts[] using helper function (Jani) > > Use snprintf() (Jani) > > > > Signed-off-by: Raag Jadav > > Finally caught up on mail, so dropping this here again: Please also add a > small section to drm-uapi.rst, pointing at these functions. Just the > kerneldoc for developers is kinda not enough I think. Would you prefer a new section or have the existing one (Device reset which looks somewhat similar but not entirely) modified? Raag
Re: [RFC PATCH 0/4] Linaro restricted heap
On Tue, Sep 24, 2024 at 01:13:18PM GMT, Andrew Davis wrote: > On 9/23/24 1:33 AM, Dmitry Baryshkov wrote: > > Hi, > > > > On Fri, Aug 30, 2024 at 09:03:47AM GMT, Jens Wiklander wrote: > > > Hi, > > > > > > This patch set is based on top of Yong Wu's restricted heap patch set [1]. > > > It's also a continuation on Olivier's Add dma-buf secure-heap patch set > > > [2]. > > > > > > The Linaro restricted heap uses genalloc in the kernel to manage the heap > > > carvout. This is a difference from the Mediatek restricted heap which > > > relies on the secure world to manage the carveout. > > > > > > I've tried to adress the comments on [2], but [1] introduces changes so > > > I'm > > > afraid I've had to skip some comments. > > > > I know I have raised the same question during LPC (in connection to > > Qualcomm's dma-heap implementation). Is there any reason why we are > > using generic heaps instead of allocating the dma-bufs on the device > > side? > > > > In your case you already have TEE device, you can use it to allocate and > > export dma-bufs, which then get imported by the V4L and DRM drivers. > > > > This goes to the heart of why we have dma-heaps in the first place. > We don't want to burden userspace with having to figure out the right > place to get a dma-buf for a given use-case on a given hardware. > That would be very non-portable, and fail at the core purpose of > a kernel: to abstract hardware specifics away. Unfortunately all proposals to use dma-buf heaps were moving in the described direction: let app select (somehow) from a platform- and vendor- specific list of dma-buf heaps. In the kernel we at least know the platform on which the system is running. Userspace generally doesn't (and shouldn't). As such, it seems better to me to keep the knowledge in the kernel and allow userspace do its job by calling into existing device drivers. > > Worse, the actual interface for dma-buf exporting changes from > framework to framework (getting a dma-buf from DRM is different > than V4L, and there would be yet another API for TEE, etc..) But if the app is working with the particular subsystem, then it already talks its language. Allocating a dma-buf is just another part of the interface, which the app already has to support. > Most subsystem don't need an allocator, they work just fine > simply being only dma-bufs importers. Recent example being the > IIO subsystem[0], for which some early posting included an > allocator, but in the end, all that was needed was to consume > buffers. > > For devices that don't actually contain memory there is no > reason to be an exporter. What most want is just to consume > normal system memory. Or system memory with some constraints > (e.g. contiguous, coherent, restricted, etc..). ... secure, accessible only to the camera and video encoder, ... or accessible only to the video decoder and the display unit. Who specifies those restrictions? Can we express them in a platform-neutral way? > > > I have a feeling (I might be completely wrong here) that by using > > generic dma-buf heaps we can easily end up in a situation when the > > userspace depends heavily on the actual platform being used (to map the > > platform to heap names). I think we should instead depend on the > > existing devices (e.g. if there is a TEE device, use an IOCTL to > > allocate secured DMA BUF from it, otherwise check for QTEE device, > > otherwise check for some other vendor device). > > > > The mental experiment to check if the API is correct is really simple: > > Can you use exactly the same rootfs on several devices without > > any additional tuning (e.g. your QEMU, HiKey, a Mediatek board, Qualcomm > > laptop, etc)? > > > > This is a great north star to follow. And exactly the reason we should > *not* be exposing device specific constraints to userspace. The constrains > change based on the platform. So a userspace would have to also pick > a different set of constraints based on each platform. Great, I totally agree here. > Userspace knows which subsystems it will attach a buffer, and the > kernel knows what constraints those devices have on a given platform. > Ideal case is then allocate from the one exporter, attach to various > devices, and have the constraints solved at map time by the exporter > based on the set of attached devices. > > For example, on one platform the display needs contiguous buffers, > but on a different platform the display can scatter-gather. So > what heap should our generic application allocate from when it > wants a buffer consumable by the display, CMA or System? > Answer *should* be always use the generic exporter, and that > exporter then picks the right backing type based on the platform. The display can support scather-gather, the GPU needs bigger stride for this particular format and the video encoder decoder can not support SG. Which set of constraints and which buffer size should generic exporter select? > Userspace shouldn't be de
Re: [PATCH v2 01/22] drm: add clone mode check for CRTC
On Tue, Sep 24, 2024 at 03:59:17PM GMT, Jessica Zhang wrote:
> Add helper to check if the given CRTC state is in clone mode
>
> Signed-off-by: Jessica Zhang
> ---
> include/drm/drm_crtc.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 8b48a1974da3..ecb93e2c4afc 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1323,5 +1323,12 @@ static inline struct drm_crtc *drm_crtc_find(struct
> drm_device *dev,
>
> int drm_crtc_create_scaling_filter_property(struct drm_crtc *crtc,
> unsigned int supported_filters);
Missing kerneldoc
> +static inline bool drm_crtc_in_clone_mode(struct drm_crtc_state *crtc_state)
> +{
> + if (!crtc_state)
> + return false;
> +
> + return hweight32(crtc_state->encoder_mask) > 1;
> +}
>
> #endif /* __DRM_CRTC_H__ */
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
Re: [PATCH v2 05/22] drm/msm/dpu: move resource allocation to CRTC
On Tue, Sep 24, 2024 at 03:59:21PM GMT, Jessica Zhang wrote:
> From: Dmitry Baryshkov
>
> All resource allocation is centered around the LMs. Then other blocks
> (except DSCs) are allocated basing on the LMs that was selected, and LM
> powers up the CRTC rather than the encoder.
>
> Moreover if at some point the driver supports encoder cloning,
> allocating resources from the encoder will be incorrect, as all clones
> will have different encoder IDs, while LMs are to be shared by these
> encoders.
>
> Signed-off-by: Dmitry Baryshkov
> [quic_abhin...@quicinc.com: Refactored resource allocation for CDM]
> Signed-off-by: Abhinav Kumar
> [quic_jessz...@quicinc.com: Changed to grabbing exising global state]
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 86
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 201
> +++-
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 19 +++
> 3 files changed, 183 insertions(+), 123 deletions(-)
>
> @@ -544,159 +542,117 @@ void dpu_encoder_helper_split_config(
> }
> }
>
> -bool dpu_encoder_use_dsc_merge(struct drm_encoder *drm_enc)
> +void dpu_encoder_update_topology(struct drm_encoder *drm_enc,
> + struct msm_display_topology *topology,
> + struct drm_atomic_state *state,
> + const struct drm_display_mode *adj_mode)
> {
> struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
> - int i, intf_count = 0, num_dsc = 0;
> + struct drm_connector *connector;
> + struct drm_connector_state *conn_state;
> + struct msm_display_info *disp_info;
> + struct drm_framebuffer *fb;
> + struct msm_drm_private *priv;
> + int i;
>
> for (i = 0; i < MAX_PHYS_ENCODERS_PER_VIRTUAL; i++)
> if (dpu_enc->phys_encs[i])
> - intf_count++;
> + topology->num_intf++;
>
> - /* See dpu_encoder_get_topology, we only support 2:2:1 topology */
> + /* We only support 2 DSC mode (with 2 LM and 1 INTF) */
> if (dpu_enc->dsc)
> - num_dsc = 2;
> + topology->num_dsc += 2;
>
> - return (num_dsc > 0) && (num_dsc > intf_count);
> -}
> + connector = drm_atomic_get_new_connector_for_encoder(state, drm_enc);
> + if (!connector)
> + return;
> + conn_state = drm_atomic_get_new_connector_state(state, connector);
> + if (!conn_state)
> + return;
>
> -struct drm_dsc_config *dpu_encoder_get_dsc_config(struct drm_encoder
> *drm_enc)
> -{
> - struct msm_drm_private *priv = drm_enc->dev->dev_private;
> - struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
> - int index = dpu_enc->disp_info.h_tile_instance[0];
> + disp_info = &dpu_enc->disp_info;
>
> - if (dpu_enc->disp_info.intf_type == INTF_DSI)
> - return msm_dsi_get_dsc_config(priv->dsi[index]);
> + priv = drm_enc->dev->dev_private;
>
> - return NULL;
> + /*
> + * Use CDM only for writeback or DP at the moment as other interfaces
> cannot handle it.
> + * If writeback itself cannot handle cdm for some reason it will fail
> in its atomic_check()
> + * earlier.
> + */
> + if (disp_info->intf_type == INTF_WB && conn_state->writeback_job) {
> + fb = conn_state->writeback_job->fb;
> +
> + if (fb && MSM_FORMAT_IS_YUV(msm_framebuffer_format(fb)))
> + topology->needs_cdm = true;
> + } else if (disp_info->intf_type == INTF_DP) {
> + if
> (msm_dp_is_yuv_420_enabled(priv->dp[disp_info->h_tile_instance[0]], adj_mode))
> + topology->needs_cdm = true;
> + }
Just to note, the needs_cdm is not enough once you introduce CWB
support. E.g. DP/YUV420 + WB/YUV case requires two CDM blocks (which we
don't have), but this doesn't get reflected in the topology.
> }
>
--
With best wishes
Dmitry
Re: [PATCH v2 1/2] drm/panel: jd9365da: Modify Kingdisplay and Melfas panel timing
On Wed, Sep 25, 2024 at 12:11 AM Jessica Zhang
wrote:
>
>
>
> On 9/23/2024 7:13 PM, zhaoxiong lv wrote:
> > On Tue, Sep 24, 2024 at 5:14 AM Jessica Zhang
> > wrote:
> >>
> >>
> >>
> >> On 9/23/2024 6:42 AM, Zhaoxiong Lv wrote:
> >>> In MTK chips, if the system starts suspending before the DRM runtime
> >>> resume has not completed, there is a possibility of a black screen
> >>> after waking the machine. Reduce the disable delay resolves this issue,
> >>
> >> Hi Zhaoxiong,
> >>
> >> Do you mean "if the system starts suspending before the DRM runtime
> >> resume *has* completed" here?
> >
> > Hi Jessica
> >
> > Sorry, my description may not be clear enough. It should be when the
> > DRM runtime resume has not yet completed and the system enters sleep
> > mode at the same time.
>
> Got it, yes I think the reworded explanation in your reply is much clearer.
>
> >
> >
> >>
> >>>
> >>> The "backlight_off_to_display_off_delay_ms" was added between
> >>> "backlight off" and "display off" to prevent "display off" from being
> >>> executed when the backlight is not fully powered off, which may cause
> >>> a white screen. However, we removed this
> >>> "backlight_off_to_display_off_delay_ms" and found that this situation
> >>> did not occur. Therefore, in order to solve the problem mentioned
> >>> above, we We reduced it from 100ms to 3ms (tCMD_OFF >= 1ms).
> >>
> >> So from my understanding of this paragraph,
> >> `backlight_off_to_display_off_delay_ms` was added to prevent the display
> >> powering off before backlight is fully powered off. You recently tested
> >> dropping this completely and saw no issue with this.
> >>
> >> If that's the case, why not drop this delay completely?
> >>
> >> Thanks,
> >>
> >> Jessica Zhang
> >
> > Yes, there are currently no other issue after removing this delay.
> > The reason why I didn't completely remove this delay is because the
> > panel spec states that a delay of more than 1ms (tCMD_OFF >= 1ms) is
> > required when entering diaplay_off (0x28H), so I reserved 3ms.
>
> Thanks for the clarification -- I see why you included the "(tCMD_OFF >=
> 1ms)" part now. Can you please specify in the commit message that the
> tCMD_OFF delay requirement is from the spec?
>
> Also can you remove the extra "We" in "we We reduced it from 100ms to 3ms"?
>
> Thanks,
>
> Jessica Zhang
OK, thanks for your correction, we will modify the commit message in
the next patch.
>
> >
> >>
> >>>
> >>> This is the timing specification for the two panels:
> >>> 1. Kingdisplay panel timing spec:
> >>> https://github.com/KD54183/-JD9365DA_Power-On-Off-Sequence_V0120240923
> >>> 2. LMFBX101117480 timing spec: https://github.com/chiohsin-lo/TDY-JD_LIB
> >>>
> >>>
> >>> Fixes: 2b976ad760dc ("drm/panel: jd9365da: Support for kd101ne3-40ti
> >>> MIPI-DSI panel")
> >>> Fixes: c4ce398cf18a ("drm/panel: jd9365da: Support for Melfas
> >>> lmfbx101117480 MIPI-DSI panel")
> >>>
> >>> Signed-off-by: Zhaoxiong Lv
> >>> ---
> >>> Changes between V2 and V1:
> >>> - 1. Modify the commit message
> >>> - 2. Modify the value of backlight_off_to_display_off_delay_ms.
> >>> v1:
> >>> https://lore.kernel.org/all/20240915080830.11318-2-lvzhaoxi...@huaqin.corp-partner.google.com/
> >>> ---
> >>>drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c | 4 ++--
> >>>1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> >>> b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> >>> index 44897e5218a6..486aa20e5518 100644
> >>> --- a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> >>> +++ b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> >>> @@ -858,7 +858,7 @@ static const struct jadard_panel_desc
> >>> kingdisplay_kd101ne3_40ti_desc = {
> >>>.reset_before_power_off_vcioo = true,
> >>>.vcioo_to_lp11_delay_ms = 5,
> >>>.lp11_to_reset_delay_ms = 10,
> >>> - .backlight_off_to_display_off_delay_ms = 100,
> >>> + .backlight_off_to_display_off_delay_ms = 3,
> >>>.display_off_to_enter_sleep_delay_ms = 50,
> >>>.enter_sleep_to_reset_down_delay_ms = 100,
> >>>};
> >>> @@ -1109,7 +1109,7 @@ static const struct jadard_panel_desc
> >>> melfas_lmfbx101117480_desc = {
> >>>.reset_before_power_off_vcioo = true,
> >>>.vcioo_to_lp11_delay_ms = 5,
> >>>.lp11_to_reset_delay_ms = 10,
> >>> - .backlight_off_to_display_off_delay_ms = 100,
> >>> + .backlight_off_to_display_off_delay_ms = 3,
> >>>.display_off_to_enter_sleep_delay_ms = 50,
> >>>.enter_sleep_to_reset_down_delay_ms = 100,
> >>>};
> >>> --
> >>> 2.17.1
> >>>
> >>
>
Re: [PATCH 6/6] dt-bindings: display: mediatek: dpi: Add mt8195 support in power domains
On 9/24/24 19:48, AngeloGioacchino Del Regno wrote:
Il 24/09/24 12:31, Macpaul Lin ha scritto:
Add power domain binding to the mediatek DPI controller for MT8185.
The dpi node in mt8195.dtsi was triggering a dtbs_check error:
dp-intf@1c113000: power-domains: False schema does not allow [[44, 18]]
Fixes: 5474d49b2f79 ("dt-bindings: display: mediatek: dpi: Add power domains")
Signed-off-by: Macpaul Lin
---
.../devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
index 3a82aec9021c..07acc8a76bfc 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -89,6 +89,7 @@ allOf:
- mediatek,mt6795-dpi
- mediatek,mt8173-dpi
- mediatek,mt8186-dpi
+- mediatek,mt8195-dp-intf
The dp_intf1 block has a power domain (VDOSYS1)... so that will break the check
for the other one.
Besides, I'm fairly sure that the right fix is to actually add the missing
VDOSYS0
power domain to dp_intf0 instead, as that block is indeed in VDO0.
So.. for this patch: nak.
Cheers,
Angelo
Tommy and I was wondering why DP-INTF0 will work without power domain.
After lookup others node in the mt8195.dtsi, I guess this is because the
power domain VDOSYS0 has been enabled by other modules.
However this patch is still required after adding power domain to DP-INTF0.
Otherwise the dpi errors will become two. :~
dp-intf@1c015000: power-domains: False schema does not allow [[44, 16]]
dp-intf@1c113000: power-domains: False schema does not allow [[44, 18]]
I'll send a separate patch to add VDOSYS0 for DP-INTF0.
Thanks
Macpaul Lin
Re: [PATCH 1/2] drm/bridge: anx7625: Drop EDID cache on bridge power off
Hi,
On Wed, Sep 25, 2024 at 12:43 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Sep 23, 2024 at 8:53 PM Pin-yen Lin wrote:
> >
> > The bridge might miss the display change events when it's powered off.
> > This happens when a user changes the external monitor when the system
> > is suspended and the embedded controller doesn't not wake AP up.
> >
> > It's also observed that one DP-to-HDMI bridge doesn't work correctly
> > when there is no EDID read after it is powered on.
> >
> > Drop the cache to force an EDID read after system resume to fix this.
> >
> > Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP")
> > Signed-off-by: Pin-yen Lin
> > ---
> >
> > drivers/gpu/drm/bridge/analogix/anx7625.c | 1 +
> > 1 file changed, 1 insertion(+)
>
> I'm not totally sure if it matters, but I wonder if you should change
> this to only delete the EDID cache if you're in DP mode and not eDP
> mode? For eDP mode the panel is not allowed to change and re-reading
> it needlessly seems like it would slow down things like
> suspend/resume. I think this would only matter if someone were using
> eDP panels in the "old" way (not under the aux-bus) because we don't
> set the "DRM_BRIDGE_OP_EDID" when we see "aux-bus", so maybe we don't
> care that much but still...
I'll update this in v2.
>
> Other than that, I know that there have been discussions in the past
> about EDID caches but I can't quite remember all the details. I know
> that panel-edp.c still caches it, so we must have concluded that it's
> at least fine/reasonable for panels. I don't remember whether caching
> is encouraged / suggested for external displays, though. Do you happen
> to know if it even makes a difference there (in other words, do you
> actually see multiple calls to read the EDID when you plug in a DP
> display)?
At least on ChromeOS, Chrome triggers two EDID reads when I plug in an
external monitor. I'm not sure if this is common for other DRM masters
though.
>
> -Doug
Regards,
Pin-yen
Re: [PATCH 2/2] drm/bridge: it6505: Drop EDID cache on bridge power off
Hi,
On Wed, Sep 25, 2024 at 1:48 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Sep 23, 2024 at 8:53 PM Pin-yen Lin wrote:
> >
> > The bridge might miss the display change events when it's powered off.
> > This happens when a user changes the external monitor when the system
> > is suspended and the embedded controller doesn't not wake AP up.
> >
> > It's also observed that one DP-to-HDMI bridge doesn't work correctly
> > when there is no EDID read after it is powered on.
> >
> > Drop the cache to force an EDID read after system resume to fix this.
> >
> > Fixes: 11feaef69d0c ("drm/bridge: it6505: Add caching for EDID")
> > Signed-off-by: Pin-yen Lin
>
> Ah, I guess this answers my question in the previous patch about
> whether caching was important even for external displays since this
> driver only supports external DP and the commit you mention in "Fixes"
> says that caching was important.
>
> So this looks reasonable. One thing I wonder is if you're totally
> guaranteed to get a PM Runtime suspend whenever you get an unplug /
> replug of a display. I tried to dig a little bit but I'm not super
> familiar with this bridge and it looks complicated enough that I guess
> I'll have to trust that it's fine. So...
it6505_remove_edid() is also called when the bridge reads HPD low in
the IRQ handler or the DPCD sink count changes to 0 after a HPD_IRQ
signal. The assumption here is that if the bridge is still powered on,
then it should be aware of the monitor change events and drop the EDID
cache when needed. This patch addresses the scenario where monitor
changes are not communicated to the bridge when it is powered off.
>
> Reviewed-by: Douglas Anderson
Regards,
Pin-yen
Re: [PATCH 3/6] dt-bindings: display: mediatek: Fix clocks count constraint for new SoCs
Il 24/09/24 12:31, Macpaul Lin ha scritto:
The display node in mt8195.dtsi was triggering a CHECK_DTBS error due
to an excessively long 'clocks' property:
display@14f06000: clocks: [[31, 14], [31, 43], [31, 44]] is too long
To resolve this issue, add "maxItems: 3" to the 'clocks' property in
the DT schema.
Fixes: 4ed545e7d100 ("dt-bindings: display: mediatek: disp: split each block to
individual yaml")
Signed-off-by: Macpaul Lin
---
.../devicetree/bindings/display/mediatek/mediatek,split.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
index e4affc854f3d..42d2d483cc29 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
@@ -57,6 +57,7 @@ properties:
clocks:
items:
- description: SPLIT Clock
That's at least confusing (granted that it works) - either add a description for
each clock and then set `minItems: 1` (preferred), or remove this "SPLIT Clock"
description and allow a maximum of 3 clocks.
Removing the description can be done - IMO - because "SPLIT Clock" is, well,
saying that the SPLIT block gets a SPLIT clock ... stating the obvious, anyway.
Cheers,
Angelo
+maxItems: 3
required:
- compatible
Re: [PATCH 1/1] mm/migrate: Trylock device page in do_swap_page
On Fri, Sep 20, 2024 at 09:59:51PM +, Matthew Brost wrote:
> On Fri, Sep 20, 2024 at 05:50:10PM -0400, Felix Kuehling wrote:
> >
> > On 2024-09-20 17:23, Matthew Brost wrote:
> > > On Fri, Sep 20, 2024 at 04:26:50PM -0400, Felix Kuehling wrote:
> > > > On 2024-09-18 11:10, Alistair Popple wrote:
> > > > > Matthew Brost writes:
> > > > >
> > > > > > On Wed, Sep 11, 2024 at 02:53:31PM +1000, Alistair Popple wrote:
> > > > > > > Matthew Brost writes:
> > > > > > >
> > > > > > > I haven't seen the same in the NVIDIA UVM driver (out-of-tree, I
> > > > > > > know)
> > > > > > Still a driver.
> > > > > Indeed, and I'm happy to answer any questions about our
> > > > > implementation.
> > > > >
> > > > > > > but theoretically it seems like it should be possible. However we
> > > > > > > serialize migrations of the same virtual address range to avoid
> > > > > > > these
> > > > > > > kind of issues as they can happen the other way too (ie. multiple
> > > > > > > threads trying to migrate to GPU).
> > > > > > >
> > > > > > > So I suspect what happens in UVM is that one thread wins and
> > > > > > > installs
> > > > > > > the migration entry while the others fail to get the driver
> > > > > > > migration
> > > > > > > lock and bail out sufficiently early in the fault path to avoid
> > > > > > > the
> > > > > > > live-lock.
> > > > > > >
> > > > > > I had to try hard to show this, doubt an actual user could trigger
> > > > > > this.
> > > > > >
> > > > > > I wrote a test which kicked 8 threads, each thread did a pthread
> > > > > > join,
> > > > > > and then tried to read the same page. This repeats in loop for like
> > > > > > 512
> > > > > > pages or something. I needed an exclusive lock in migrate_to_ram
> > > > > > vfunc
> > > > > > for it to livelock. Without an exclusive lock I think on average I
> > > > > > saw
> > > > > > about 32k retries (i.e. migrate_to_ram calls on the same page)
> > > > > > before a
> > > > > > thread won this race.
> > > > > >
> > > > > > From reading UVM, pretty sure if you tried hard enough you could
> > > > > > trigger
> > > > > > a livelock given it appears you take excluvise locks in
> > > > > > migrate_to_ram.
> > > > > Yes, I suspect you're correct here and that we just haven't tried hard
> > > > > enough to trigger it.
> > > > >
> > > > > > > > Cc: Philip Yang
> > > > > > > > Cc: Felix Kuehling
> > > > > > > > Cc: Christian König
> > > > > > > > Cc: Andrew Morton
> > > > > > > > Suggessted-by: Simona Vetter
> > > > > > > > Signed-off-by: Matthew Brost
> > > > > > > > ---
> > > > > > > >mm/memory.c | 13 +++---
> > > > > > > >mm/migrate_device.c | 60
> > > > > > > > +++--
> > > > > > > >2 files changed, 50 insertions(+), 23 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/mm/memory.c b/mm/memory.c
> > > > > > > > index 3c01d68065be..bbd97d16a96a 100644
> > > > > > > > --- a/mm/memory.c
> > > > > > > > +++ b/mm/memory.c
> > > > > > > > @@ -4046,10 +4046,15 @@ vm_fault_t do_swap_page(struct vm_fault
> > > > > > > > *vmf)
> > > > > > > > * Get a page reference while we know
> > > > > > > > the page can't be
> > > > > > > > * freed.
> > > > > > > > */
> > > > > > > > - get_page(vmf->page);
> > > > > > > > - pte_unmap_unlock(vmf->pte, vmf->ptl);
> > > > > > > > - ret =
> > > > > > > > vmf->page->pgmap->ops->migrate_to_ram(vmf);
> > > > > > > > - put_page(vmf->page);
> > > > > > > > + if (trylock_page(vmf->page)) {
> > > > > > > > + get_page(vmf->page);
> > > > > > > > + pte_unmap_unlock(vmf->pte,
> > > > > > > > vmf->ptl);
> > > > > > > This is all beginning to look a lot like
> > > > > > > migrate_vma_collect_pmd(). So
> > > > > > > rather than do this and then have to pass all this context
> > > > > > > (ie. fault_page) down to the migrate_vma_* functions could we
> > > > > > > instead
> > > > > > > just do what migrate_vma_collect_pmd() does here? Ie. we already
> > > > > > > have
> > > > > > > the PTL and the page lock so there's no reason we couldn't just
> > > > > > > setup
> > > > > > > the migration entry prior to calling migrate_to_ram().
> > > > > > >
> > > > > > > Obviously calling migrate_vma_setup() would show the page as not
> > > > > > > migrating, but drivers could easily just fill in the src_pfn info
> > > > > > > after
> > > > > > > calling migrate_vma_setup().
> > > > > > >
> > > > > > > This would eliminate the whole fault_page ugliness.
> > > > > > >
> > > > > > This seems like it would work and agree it likely be cleaner. Let me
> > > > > > play around with this and see what I come up with. Multi-tasking a
> > > > > > bit
> > > > > > so expect a bit of delay here.
> > > > > >
> > > > > > Thanks for the
Re: [PATCH 6/6] dt-bindings: display: mediatek: dpi: Add mt8195 support in power domains
Il 24/09/24 12:31, Macpaul Lin ha scritto:
Add power domain binding to the mediatek DPI controller for MT8185.
The dpi node in mt8195.dtsi was triggering a dtbs_check error:
dp-intf@1c113000: power-domains: False schema does not allow [[44, 18]]
Fixes: 5474d49b2f79 ("dt-bindings: display: mediatek: dpi: Add power domains")
Signed-off-by: Macpaul Lin
---
.../devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
index 3a82aec9021c..07acc8a76bfc 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -89,6 +89,7 @@ allOf:
- mediatek,mt6795-dpi
- mediatek,mt8173-dpi
- mediatek,mt8186-dpi
+- mediatek,mt8195-dp-intf
The dp_intf1 block has a power domain (VDOSYS1)... so that will break the check
for the other one.
Besides, I'm fairly sure that the right fix is to actually add the missing
VDOSYS0
power domain to dp_intf0 instead, as that block is indeed in VDO0.
So.. for this patch: nak.
Cheers,
Angelo
then:
properties:
power-domains: false
Re: [PATCH 0/2] drm: revert some framebuffer API tests
+Guenter On Tue, Sep 24, 2024 at 12:06:28PM GMT, Simona Vetter wrote: > On Tue, Sep 17, 2024 at 08:43:50PM +0300, Jani Nikula wrote: > > The tests consistently trigger WARNs in drm_framebuffer code. I'm not > > sure what the point is with type of belts and suspenders tests. The > > warnings *are* the way to flag erroneous API usage. > > > > Warnings in turn trigger failures in CI. Filtering the warnings are > > error prone, and, crucially, would also filter actual errors in case the > > kunit tests are not run. > > > > I acknowledge there may be complex test cases where you'd end up > > triggering warnings somewhere deep, but these are not it. These are > > simple. > > > > Revert the tests, back to the drawing board. > > Yeah I think long-term we might want a kunit framework so that we can > catch dmesg warnings we expect and test for those, without those warnings > actually going to dmesg. Similar to how the lockdep tests also reroute > locking validation, so that the expected positive tests don't wreak > lockdep for real. > > But until that exists, we can't have tests that splat in dmesg when they > work as intended. It should be pretty soon: https://lore.kernel.org/dri-devel/20240403131936.787234-1-li...@roeck-us.net/ I'm not sure what happened to that series, but it looks like everybody was mostly happy with it? Maxime signature.asc Description: PGP signature
Re: [PATCH] drm: Add check for encoder in intel_get_crtc_new_encoder()
On Tue, 24 Sep 2024, George Rurikov wrote:
> If the video card driver could not find the connector assigned to the
> current video controller, or if the hardware status has changed so that
> a pre-existing connector is no longer active, none of the state
> connectors will meet the assignment criteria for the current crtc video
> controller.
>
> In the drm_WARN function, encoder->base.dev is called, so
> '&encoder->base.dev' will be dereferenced since encoder will still be
> initialized NULL.
encoder is not dereferenced there.
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
> Fixes: e12d6218fda2 ("drm/i915: Reduce bigjoiner special casing")
> Cc: sta...@vger.kernel.org
> Signed-off-by: George Rurikov
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b4ef4d59da1a..1f25b12e5f67 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -819,9 +819,11 @@ intel_get_crtc_new_encoder(const struct
> intel_atomic_state *state,
> num_encoders++;
> }
>
> - drm_WARN(state->base.dev, num_encoders != 1,
> + if (encoder) {
> + drm_WARN(state->base.dev, num_encoders != 1,
> "%d encoders for pipe %c\n",
> num_encoders, pipe_name(primary_crtc->pipe));
> + }
>
> return encoder;
> }
> --
> 2.34.1
>
> Заявление о конфиденциальности
>
> Данное электронное письмо и любые приложения к нему являются
> конфиденциальными и предназначены исключительно для адресата. Если Вы не
> являетесь адресатом данного письма, пожалуйста, уведомите немедленно
> отправителя, не раскрывайте содержание другим лицам, не используйте его в
> каких-либо целях, не храните и не копируйте информацию любым способом.
Sorry, we can't accept patches with that boilerplate anyway.
BR,
Jani.
--
Jani Nikula, Intel
Re: [PATCH] drm: Add check for encoder in intel_get_crtc_new_encoder()
On Tue, 24 Sep 2024, Jani Nikula wrote:
> On Tue, 24 Sep 2024, George Rurikov wrote:
>> If the video card driver could not find the connector assigned to the
>> current video controller, or if the hardware status has changed so that
>> a pre-existing connector is no longer active, none of the state
>> connectors will meet the assignment criteria for the current crtc video
>> controller.
>>
>> In the drm_WARN function, encoder->base.dev is called, so
>> '&encoder->base.dev' will be dereferenced since encoder will still be
>> initialized NULL.
>
> encoder is not dereferenced there.
Looks like the issue was there ages ago, and was fixed in v6.5 by commit
3b6692357f70 ("drm/i915: Make intel_get_crtc_new_encoder() less oopsy").
Please run your analysis on recent kernels.
BR,
Jani.
>
>> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>>
>> Fixes: e12d6218fda2 ("drm/i915: Reduce bigjoiner special casing")
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: George Rurikov
>> ---
>> drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index b4ef4d59da1a..1f25b12e5f67 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -819,9 +819,11 @@ intel_get_crtc_new_encoder(const struct
>> intel_atomic_state *state,
>> num_encoders++;
>> }
>>
>> - drm_WARN(state->base.dev, num_encoders != 1,
>> + if (encoder) {
>> + drm_WARN(state->base.dev, num_encoders != 1,
>> "%d encoders for pipe %c\n",
>> num_encoders, pipe_name(primary_crtc->pipe));
>> + }
>>
>> return encoder;
>> }
>> --
>> 2.34.1
>>
>> Заявление о конфиденциальности
>>
>> Данное электронное письмо и любые приложения к нему являются
>> конфиденциальными и предназначены исключительно для адресата. Если Вы не
>> являетесь адресатом данного письма, пожалуйста, уведомите немедленно
>> отправителя, не раскрывайте содержание другим лицам, не используйте его в
>> каких-либо целях, не храните и не копируйте информацию любым способом.
>
> Sorry, we can't accept patches with that boilerplate anyway.
>
> BR,
> Jani.
--
Jani Nikula, Intel
Re: [PATCH 4/5] drm/msm/dpu: Add SA8775P support
On 9/24/2024 4:42 PM, Mahadevan P wrote:
On 9/12/2024 1:34 PM, Dmitry Baryshkov wrote:
On Thu, Sep 12, 2024 at 12:44:36PM GMT, Mahadevan wrote:
Add definitions for the display hardware used on the
Qualcomm SA8775P platform.
Signed-off-by: Mahadevan
---
.../msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h | 485
++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3 +-
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 3 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +-
4 files changed, 491 insertions(+), 3 deletions(-)
create mode 100644
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h
new file mode 100644
index ..14d65b5d4093
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h
@@ -0,0 +1,485 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights
reserved.
+ * Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights
reserved.
+ */
+
+#ifndef _DPU_8_4_SA8775P_H
+#define _DPU_8_4_SA8775P_H
+
+static const struct dpu_caps sa8775p_dpu_caps = {
+ .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .max_mixer_blendstages = 0xb,
+ .has_src_split = true,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .has_3d_merge = true,
+ .max_linewidth = 5120,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+};
+
+static const struct dpu_mdp_cfg sa8775p_mdp = {
+ .name = "top_0",
+ .base = 0x0, .len = 0x494,
+ .features = BIT(DPU_MDP_PERIPH_0_REMOVED),
+ .clk_ctrls = {
+ [DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
+ [DPU_CLK_CTRL_VIG1] = { .reg_off = 0x2b4, .bit_off = 0 },
+ [DPU_CLK_CTRL_VIG2] = { .reg_off = 0x2bc, .bit_off = 0 },
+ [DPU_CLK_CTRL_VIG3] = { .reg_off = 0x2c4, .bit_off = 0 },
+ [DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
+ [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 },
+ [DPU_CLK_CTRL_REG_DMA] = { .reg_off = 0x2bc, .bit_off = 20 },
+ },
+};
+
+/* FIXME: get rid of DPU_CTL_SPLIT_DISPLAY in favour of proper
ACTIVE_CTL support */
+static const struct dpu_ctl_cfg sa8775p_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x15000, .len = 0x204,
+ .features = BIT(DPU_CTL_SPLIT_DISPLAY) | CTL_SC7280_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+ }, {
+ .name = "ctl_1", .id = CTL_1,
+ .base = 0x16000, .len = 0x204,
+ .features = BIT(DPU_CTL_SPLIT_DISPLAY) | CTL_SC7280_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
+ }, {
+ .name = "ctl_2", .id = CTL_2,
+ .base = 0x17000, .len = 0x204,
+ .features = CTL_SC7280_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
+ }, {
+ .name = "ctl_3", .id = CTL_3,
+ .base = 0x18000, .len = 0x204,
+ .features = CTL_SC7280_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
+ }, {
+ .name = "ctl_4", .id = CTL_4,
+ .base = 0x19000, .len = 0x204,
+ .features = CTL_SC7280_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 13),
+ }, {
+ .name = "ctl_5", .id = CTL_5,
+ .base = 0x1a000, .len = 0x204,
+ .features = CTL_SC7280_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 23),
+ },
+};
+
+static const struct dpu_sspp_cfg sa8775p_sspp[] = {
+ {
+ .name = "sspp_0", .id = SSPP_VIG0,
+ .base = 0x4000, .len = 0x32c,
+ .features = VIG_SDM845_MASK_SDMA,
+ .sblk = &dpu_vig_sblk_qseed3_3_1,
+ .xin_id = 0,
+ .type = SSPP_TYPE_VIG,
+ .clk_ctrl = DPU_CLK_CTRL_VIG0,
+ }, {
+ .name = "sspp_1", .id = SSPP_VIG1,
+ .base = 0x6000, .len = 0x32c,
+ .features = VIG_SDM845_MASK_SDMA,
+ .sblk = &dpu_vig_sblk_qseed3_3_1,
+ .xin_id = 4,
+ .type = SSPP_TYPE_VIG,
+ .clk_ctrl = DPU_CLK_CTRL_VIG1,
+ }, {
+ .name = "sspp_2", .id = SSPP_VIG2,
+ .base = 0x8000, .len = 0x32c,
+ .features = VIG_SDM845_MASK_SDMA,
+ .sblk = &dpu_vig_sblk_qseed3_3_1,
+ .xin_id = 8,
+ .type = SSPP_TYPE_VIG,
+ .clk_ctrl = DPU_CLK_CTRL_VIG2,
+ }, {
+ .name = "sspp_3", .id = SSPP_VIG3,
+ .base = 0xa000, .len = 0x32c,
+ .features = VIG_SDM845_MASK_SDMA,
+ .sblk = &dpu_vig_sblk_qseed3_3_1,
+ .xin_id = 12,
+ .type = SSPP_TYPE_VIG,
+ .clk_ctrl = DPU_CLK_CTRL_VIG3,
+ }, {
+ .name = "sspp_8", .id = SSPP_DMA0,
+ .base = 0x24000, .len = 0x32c,
+ .features = DMA_SDM845_MASK_SDMA,
+
Re: [PATCH v4 00/11] Preemption support for A7XX
On 9/20/24 7:09 PM, Akhil P Oommen wrote: On Wed, Sep 18, 2024 at 09:46:33AM +0200, Neil Armstrong wrote: Hi, On 17/09/2024 13:14, Antonino Maniscalco wrote: This series implements preemption for A7XX targets, which allows the GPU to switch to an higher priority ring when work is pushed to it, reducing latency for high priority submissions. This series enables L1 preemption with skip_save_restore which requires the following userspace patches to function: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30544 A flag is added to `msm_submitqueue_create` to only allow submissions from compatible userspace to be preempted, therefore maintaining compatibility. Preemption is currently only enabled by default on A750, it can be enabled on other targets through the `enable_preemption` module parameter. This is because more testing is required on other targets. For testing on other HW it is sufficient to set that parameter to a value of 1, then using the branch of mesa linked above, `TU_DEBUG=hiprio` allows to run any application as high priority therefore preempting submissions from other applications. The `msm_gpu_preemption_trigger` and `msm_gpu_preemption_irq` traces added in this series can be used to observe preemption's behavior as well as measuring preemption latency. Some commits from this series are based on a previous series to enable preemption on A6XX targets: https://lkml.kernel.org/1520489185-21828-1-git-send-email-smase...@codeaurora.org Signed-off-by: Antonino Maniscalco --- Changes in v4: - Added missing register in pwrup list - Removed and rearrange barriers - Renamed `skip_inline_wptr` to `restore_wptr` - Track ctx seqno per ring - Removed secure preempt context - NOP out postamble to disable it instantly - Only emit pwrup reglist once - Document bv_rptr_addr - Removed unused A6XX_PREEMPT_USER_RECORD_SIZE - Set name on preempt record buffer - Link to v3: https://lore.kernel.org/r/20240905-preemption-a750-t-v3-0-fd947699f...@gmail.com Changes in v3: - Added documentation about preemption - Use quirks to determine which target supports preemption - Add a module parameter to force disabling or enabling preemption - Clear postamble when profiling - Define A6XX_CP_CONTEXT_SWITCH_CNTL_LEVEL fields in a6xx.xml - Make preemption records MAP_PRIV - Removed user ctx record (NON_PRIV) and patch 2/9 as it's not needed anymore - Link to v2: https://lore.kernel.org/r/20240830-preemption-a750-t-v2-0-86aeead2c...@gmail.com Changes in v2: - Added preept_record_size for X185 in PATCH 3/7 - Added patches to reset perf counters - Dropped unused defines - Dropped unused variable (fixes warning) - Only enable preemption on a750 - Reject MSM_SUBMITQUEUE_ALLOW_PREEMPT for unsupported targets - Added Akhil's Reviewed-By tags to patches 1/9,2/9,3/9 - Added Neil's Tested-By tags - Added explanation for UAPI changes in commit message - Link to v1: https://lore.kernel.org/r/20240815-preemption-a750-t-v1-0-7bda26c34...@gmail.com --- Antonino Maniscalco (11): drm/msm: Fix bv_fence being used as bv_rptr drm/msm/A6XX: Track current_ctx_seqno per ring drm/msm: Add a `preempt_record_size` field drm/msm: Add CONTEXT_SWITCH_CNTL bitfields drm/msm/A6xx: Implement preemption for A7XX targets drm/msm/A6xx: Sync relevant adreno_pm4.xml changes drm/msm/A6xx: Use posamble to reset counters on preemption drm/msm/A6xx: Add traces for preemption drm/msm/A6XX: Add a flag to allow preemption to submitqueue_create drm/msm/A6xx: Enable preemption for A750 Documentation: document adreno preemption Documentation/gpu/msm-preemption.rst | 98 + drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 +- drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 7 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 325 ++- drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 174 drivers/gpu/drm/msm/adreno/a6xx_preempt.c | 440 + drivers/gpu/drm/msm/adreno/adreno_gpu.h| 9 +- drivers/gpu/drm/msm/msm_drv.c | 4 + drivers/gpu/drm/msm/msm_gpu.c | 2 +- drivers/gpu/drm/msm/msm_gpu.h | 11 - drivers/gpu/drm/msm/msm_gpu_trace.h| 28 ++ drivers/gpu/drm/msm/msm_ringbuffer.h | 18 + drivers/gpu/drm/msm/msm_submitqueue.c | 3 + drivers/gpu/drm/msm/registers/adreno/a6xx.xml | 7 +- .../gpu/drm/msm/registers/adreno/adreno_pm4.xml| 39 +- include/uapi/drm/msm_drm.h | 5 +- 20 files changed, 1117 insertions(+), 66 deletions(-
Re: [PATCH 1/6] arm64: dts: mt8195: Fix dtbs_check error for infracfg_ao node
Il 24/09/24 12:31, Macpaul Lin ha scritto:
The infracfg_ao node in mt8195.dtsi was causing a dtbs_check error.
The error message was:
syscon@10001000: compatible: ['mediatek,mt8195-infracfg_ao', 'syscon',
'simple-mfd'] is too long
To resolve this, remove 'simple-mfd' from the 'compatible' property of the
infracfg_ao node.
Fixes: 37f2582883be ("arm64: dts: Add mediatek SoC mt8195 and evaluation board")
Signed-off-by: Macpaul Lin
Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH 5/6] arm64: dts: mt8195: Fix dtbs_check error for mutex node
Il 24/09/24 12:31, Macpaul Lin ha scritto:
The mutex node in mt8195.dtsi was triggering a dtbs_check error:
mutex@1c101000: 'clock-names', 'reg-names' do not match any of the
regexes: 'pinctrl-[0-9]+'
This seems no need by inspecting the DT schemas and other reference boards,
so drop 'clock-names' and 'reg-names' in mt8195.dtsi.
Fixes: 92d2c23dc269 ("arm64: dts: mt8195: add display node for vdosys1")
Signed-off-by: Macpaul Lin
Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH 4/6] arm64: dts: mediatek: mt8395-genio-1200-evk: Fix dtbs_check error for phy
Il 24/09/24 12:31, Macpaul Lin ha scritto:
The ethernet-phy node in mt8395-genio-1200-evk.dts was triggering a
dtbs_check error. The error message was:
eth-phy0@1: $nodename:0: 'eth-phy0@1' does not match
'^ethernet-phy(@[a-f0-9]+)?$'
Fix this issue by replacing 'eth-phy' node to generic 'ethernet-phy'.
Fixes: f2b543a191b6 ("arm64: dts: mediatek: add device-tree for Genio 1200 EVK
board")
Signed-off-by: Macpaul Lin
Reviewed-by: AngeloGioacchino Del Regno
Re: radeon ARUBA NULL pointer dereference
(cc: DMA and x86 folks) Hi Am 24.09.24 um 04:08 schrieb Arthur Marsh: Using current Linus git head kernel, I was able to save the dmesg output: [ 17.218724] [drm] radeon kernel modesetting enabled. [ 17.218778] radeon :00:01.0: vgaarb: deactivate vga console [ 17.219509] Console: switching to colour dummy device 80x25 [ 17.219700] [drm] initializing kernel modesetting (ARUBA 0x1002:0x990C 0x1002:0x0123 0x00). [ 17.219773] ATOM BIOS: 113 [ 17.219838] radeon :00:01.0: VRAM: 768M 0x - 0x2FFF (768M used) [ 17.219841] radeon :00:01.0: GTT: 1024M 0x3000 - 0x6FFF [ 17.219844] [drm] Detected VRAM RAM=768M, BAR=256M [ 17.219845] [drm] RAM width 64bits DDR [ 17.219851] BUG: kernel NULL pointer dereference, address: 00a0 This is 160 bytes behind NULL, which indicates a field within a struct. [ 17.219852] #PF: supervisor read access in kernel mode [ 17.219853] #PF: error_code(0x) - not-present page [ 17.219854] PGD 0 P4D 0 [ 17.219856] Oops: Oops: [#1] PREEMPT_RT SMP NOPTI [ 17.219858] CPU: 0 UID: 0 PID: 451 Comm: udevd Not tainted 6.11.0+ #6121 [ 17.219860] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./F2A78M-HD2, BIOS F2 05/28/2014 [ 17.219862] RIP: 0010:dma_get_required_mask+0x11/0x50 [ 17.219868] Code: 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 8b 87 68 02 00 00 48 85 c0 74 11 <48> 8b 80 a0 00 00 00 48 85 c0 74 1f e9 ee ed 94 00 f6 87 2c 03 00 [ 17.219870] RSP: 0018:a54bc13a7b00 EFLAGS: 00010202 [ 17.219871] RAX: RBX: 00ff RCX: [ 17.219872] RDX: RSI: 0027 RDI: 976f44e720c8 [ 17.219873] RBP: 976f44e720c8 R08: efff R09: ab2aab08 [ 17.219874] R10: f000 R11: 0002 R12: [ 17.219875] R13: 976f48a4aa30 R14: R15: 0028 [ 17.219876] FS: 7f59a070d840() GS:97726f80() knlGS: [ 17.219878] CS: 0010 DS: ES: CR0: 80050033 [ 17.219879] CR2: 00a0 CR3: 0001053b4000 CR4: 000406f0 [ 17.219880] Call Trace: [ 17.219881] [ 17.219882] ? __die_body.cold+0x19/0x1e [ 17.219885] ? page_fault_oops+0xa8/0x230 [ 17.219889] ? search_module_extables+0x4f/0x90 [ 17.219891] ? fixup_exception+0x36/0x2f0 [ 17.219894] ? exc_page_fault+0x88/0x1b0 [ 17.219897] ? asm_exc_page_fault+0x22/0x30 [ 17.219900] ? dma_get_required_mask+0x11/0x50 This is not in the radeon driver but the DMA code. I'd say it's at [1], as get_required_mask is 160 bytes within struct drm_map_ops. The call to get_arch_dma_ops() probably returns NULL. Best regards Thomas [1] https://elixir.bootlin.com/linux/v6.11/source/kernel/dma/mapping.c#L523 [2] https://elixir.bootlin.com/linux/v6.11/source/include/linux/dma-map-ops.h#L98 [ 17.219902] dma_addressing_limited+0x6c/0xb0 [ 17.219905] radeon_ttm_init+0x3f/0x210 [radeon] [ 17.219977] cayman_init+0x97/0x290 [radeon] [ 17.220057] radeon_device_init+0x5e9/0xb40 [radeon] [ 17.220115] radeon_driver_load_kms+0xb0/0x260 [radeon] [ 17.220174] radeon_pci_probe+0xff/0x170 [radeon] [ 17.220231] pci_device_probe+0xbe/0x1a0 [ 17.220234] really_probe+0xde/0x350 [ 17.220237] ? pm_runtime_barrier+0x61/0xb0 [ 17.220240] ? __pfx___driver_attach+0x10/0x10 [ 17.220242] __driver_probe_device+0x78/0x110 [ 17.220245] driver_probe_device+0x2d/0xc0 [ 17.220247] __driver_attach+0xc9/0x1c0 [ 17.220249] bus_for_each_dev+0x6a/0xb0 [ 17.220251] ? migrate_enable+0xbf/0xf0 [ 17.220254] bus_add_driver+0x139/0x220 [ 17.220256] driver_register+0x6e/0xc0 [ 17.220258] ? __pfx_radeon_module_init+0x10/0x10 [radeon] [ 17.220315] do_one_initcall+0x42/0x210 [ 17.220318] ? __kmalloc_cache_noprof+0x89/0x230 [ 17.220321] do_init_module+0x60/0x210 [ 17.220324] init_module_from_file+0x89/0xc0 [ 17.220326] __x64_sys_finit_module+0x142/0x390 [ 17.220329] do_syscall_64+0x47/0x110 [ 17.220331] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 17.220334] RIP: 0033:0x7f59a0625279 [ 17.220336] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 77 6b 0d 00 f7 d8 64 89 01 48 [ 17.220337] RSP: 002b:7ffd15ee7df8 EFLAGS: 0246 ORIG_RAX: 0139 [ 17.220339] RAX: ffda RBX: 5578ae660840 RCX: 7f59a0625279 [ 17.220340] RDX: RSI: 5578ae677fc0 RDI: 0011 [ 17.220341] RBP: R08: 7f59a06fcb20 R09: 5578ae640550 [ 17.220342] R10: 0040 R11: 0246 R12: 5578ae677fc0 [ 17.220342] R13: 0002 R14: 5578ae651750 R15: [ 17.220344] [ 17.220345]
Re: [PATCH v2 1/2] gpu: ipu-v3: vdic: Simplify ipu_vdi_setup()
On 9/4/24 11:05 AM, Philipp Zabel wrote: On Mi, 2024-07-24 at 02:19 +0200, Marek Vasut wrote: The 'code' parameter only ever selects between YUV 4:2:0 and 4:2:2 subsampling, turn it into boolean to select exactly that and update related code accordingly. Signed-off-by: Marek Vasut I'd prefer this to be an enum ipu_chroma_subsampling or similar, instead of a boolean. Otherwise, I'm afraid this introduces unnecessary back and forth conversions between the boolean and either of the two enum ipu_chroma_subsampling values in the code.
[PATCH v5 78/80] drm/tegra: Run DRM default client setup
Rework fbdev probing to support fbdev_probe in struct drm_driver
and remove the old fb_probe callback. Provide an initializer macro
for struct drm_driver that sets the callback according to the kernel
configuration.
Call drm_client_setup() to run the kernel's default client setup
for DRM. Set fbdev_probe in struct drm_driver, so that the client
setup can start the common fbdev client.
The tegra driver specifies a preferred color mode of 32. As this
is the default if no format has been given, leave it out entirely.
v5:
- select DRM_CLIENT_SELECTION
Signed-off-by: Thomas Zimmermann
Cc: Thierry Reding
Cc: Mikko Perttunen
Cc: Jonathan Hunter
Acked-by: Javier Martinez Canillas
---
drivers/gpu/drm/tegra/Kconfig | 1 +
drivers/gpu/drm/tegra/drm.c | 5 +-
drivers/gpu/drm/tegra/drm.h | 12 +++--
drivers/gpu/drm/tegra/fbdev.c | 98 +++
4 files changed, 20 insertions(+), 96 deletions(-)
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index e688d8104652..8a3b16aac5d6 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -5,6 +5,7 @@ config DRM_TEGRA
depends on COMMON_CLK
depends on DRM
depends on OF
+ select DRM_CLIENT_SELECTION
select DRM_DISPLAY_DP_HELPER
select DRM_DISPLAY_HDMI_HELPER
select DRM_DISPLAY_HELPER
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 4938960b5025..a013eb12b91c 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -891,6 +892,8 @@ static const struct drm_driver tegra_drm_driver = {
.dumb_create = tegra_bo_dumb_create,
+ TEGRA_FBDEV_DRIVER_OPS,
+
.ioctls = tegra_drm_ioctls,
.num_ioctls = ARRAY_SIZE(tegra_drm_ioctls),
.fops = &tegra_drm_fops,
@@ -1269,7 +1272,7 @@ static int host1x_drm_probe(struct host1x_device *dev)
if (err < 0)
goto hub;
- tegra_fbdev_setup(drm);
+ drm_client_setup(drm, NULL);
return 0;
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 2f3781e04b0a..0b65e69f3a8a 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -25,6 +25,9 @@
/* XXX move to include/uapi/drm/drm_fourcc.h? */
#define DRM_FORMAT_MOD_NVIDIA_SECTOR_LAYOUT BIT_ULL(22)
+struct drm_fb_helper;
+struct drm_fb_helper_surface_size;
+
struct edid;
struct reset_control;
@@ -190,10 +193,13 @@ struct drm_framebuffer *tegra_fb_create(struct drm_device
*drm,
const struct drm_mode_fb_cmd2 *cmd);
#ifdef CONFIG_DRM_FBDEV_EMULATION
-void tegra_fbdev_setup(struct drm_device *drm);
+int tegra_fbdev_driver_fbdev_probe(struct drm_fb_helper *helper,
+ struct drm_fb_helper_surface_size *sizes);
+#define TEGRA_FBDEV_DRIVER_OPS \
+ .fbdev_probe = tegra_fbdev_driver_fbdev_probe
#else
-static inline void tegra_fbdev_setup(struct drm_device *drm)
-{ }
+#define TEGRA_FBDEV_DRIVER_OPS \
+ .fbdev_probe = NULL
#endif
extern struct platform_driver tegra_display_hub_driver;
diff --git a/drivers/gpu/drm/tegra/fbdev.c b/drivers/gpu/drm/tegra/fbdev.c
index db6eaac3d30e..cd9d798f8870 100644
--- a/drivers/gpu/drm/tegra/fbdev.c
+++ b/drivers/gpu/drm/tegra/fbdev.c
@@ -66,8 +66,11 @@ static const struct fb_ops tegra_fb_ops = {
.fb_destroy = tegra_fbdev_fb_destroy,
};
-static int tegra_fbdev_probe(struct drm_fb_helper *helper,
-struct drm_fb_helper_surface_size *sizes)
+static const struct drm_fb_helper_funcs tegra_fbdev_helper_funcs = {
+};
+
+int tegra_fbdev_driver_fbdev_probe(struct drm_fb_helper *helper,
+ struct drm_fb_helper_surface_size *sizes)
{
struct tegra_drm *tegra = helper->dev->dev_private;
struct drm_device *drm = helper->dev;
@@ -112,6 +115,7 @@ static int tegra_fbdev_probe(struct drm_fb_helper *helper,
return PTR_ERR(fb);
}
+ helper->funcs = &tegra_fbdev_helper_funcs;
helper->fb = fb;
helper->info = info;
@@ -144,93 +148,3 @@ static int tegra_fbdev_probe(struct drm_fb_helper *helper,
drm_framebuffer_remove(fb);
return err;
}
-
-static const struct drm_fb_helper_funcs tegra_fb_helper_funcs = {
- .fb_probe = tegra_fbdev_probe,
-};
-
-/*
- * struct drm_client
- */
-
-static void tegra_fbdev_client_unregister(struct drm_client_dev *client)
-{
- struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
-
- if (fb_helper->info) {
- drm_fb_helper_unregister_info(fb_helper);
- } else {
- drm_client_release(&fb_helper->client);
- drm_fb_helper_unprepare(fb_helper);
- kfree(fb_helper);
- }
-}
-
-static int tegra_fbdev_client_restore(struct drm_client_dev *
[PATCH v5 18/80] drm/ili9486: Run DRM default client setup
Call drm_client_setup() to run the kernel's default client setup
for DRM. Set fbdev_probe in struct drm_driver, so that the client
setup can start the common fbdev client.
v5:
- select DRM_CLIENT_SELECTION
Signed-off-by: Thomas Zimmermann
Cc: Kamlesh Gurudasani
Acked-by: Javier Martinez Canillas
---
drivers/gpu/drm/tiny/Kconfig | 1 +
drivers/gpu/drm/tiny/ili9486.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 337ac65390c6..7ee887b55aee 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -153,6 +153,7 @@ config TINYDRM_ILI9341
config TINYDRM_ILI9486
tristate "DRM support for ILI9486 display panels"
depends on DRM && SPI
+ select DRM_CLIENT_SELECTION
select DRM_KMS_HELPER
select DRM_GEM_DMA_HELPER
select DRM_MIPI_DBI
diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
index 70d366260041..7e46a720d5e2 100644
--- a/drivers/gpu/drm/tiny/ili9486.c
+++ b/drivers/gpu/drm/tiny/ili9486.c
@@ -15,6 +15,7 @@
#include
#include
+#include
#include
#include
#include
@@ -172,6 +173,7 @@ static const struct drm_driver ili9486_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops = &ili9486_fops,
DRM_GEM_DMA_DRIVER_OPS_VMAP,
+ DRM_FBDEV_DMA_DRIVER_OPS,
.debugfs_init = mipi_dbi_debugfs_init,
.name = "ili9486",
.desc = "Ilitek ILI9486",
@@ -247,7 +249,7 @@ static int ili9486_probe(struct spi_device *spi)
spi_set_drvdata(spi, drm);
- drm_fbdev_dma_setup(drm, 0);
+ drm_client_setup(drm, NULL);
return 0;
}
--
2.46.0
Re: [PATCH v1] docs/gpu: ci: update flake tests requirements
Hi Dmitry,
On 24/09/24 11:46, Dmitry Baryshkov wrote:
On Tue, 24 Sept 2024 at 04:26, Vignesh Raman
wrote:
Update the documentation to require linking to a relevant GitLab
issue for each new flake entry instead of an email report. Added
specific GitLab issue URLs for i915, xe and other drivers.
Signed-off-by: Vignesh Raman
---
Documentation/gpu/automated_testing.rst | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/Documentation/gpu/automated_testing.rst
b/Documentation/gpu/automated_testing.rst
index 2d5a28866afe..f73b8939dc3a 100644
--- a/Documentation/gpu/automated_testing.rst
+++ b/Documentation/gpu/automated_testing.rst
@@ -67,20 +67,25 @@ Lists the tests that for a given driver on a specific
hardware revision are
known to behave unreliably. These tests won't cause a job to fail regardless
of
the result. They will still be run.
-Each new flake entry must be associated with a link to the email reporting the
-bug to the author of the affected driver, the board name or Device Tree name of
-the board, the first kernel version affected, the IGT version used for tests,
-and an approximation of the failure rate.
+Each new flake entry must include a link to the relevant GitLab issue, the
board
+name or Device Tree name, the first kernel version affected, the IGT version
used
+for tests and an approximation of the failure rate.
They should be provided under the following format::
- # Bug Report: $LORE_OR_PATCHWORK_URL
+ # Bug Report: $GITLAB_ISSUE
# Board Name: broken-board.dtb
# Linux Version: 6.6-rc1
# IGT Version: 1.28-gd2af13d9f
# Failure Rate: 100
flaky-test
+The GitLab issue must include the logs and the pipeline link. Use the
appropriate
+link below to create an issue.
+https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/ for i915 drivers
+https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/ for xe drivers
drm/msm for msm driver, please. Otherwise we can easily miss such issues.
Sure, will add it in v2. Thanks.
+https://gitlab.freedesktop.org/drm/misc/kernel/-/issues for other drivers
+
drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-skips.txt
---
--
2.43.0
Regards,
Vignesh
