Re: [PATCH 14/17] drm/msm/dpu: modify encoder programming for CDM over DP
On Sun, 28 Jan 2024 at 07:48, Paloma Arellano wrote:
>
>
> On 1/25/2024 1:57 PM, Dmitry Baryshkov wrote:
> > On 25/01/2024 21:38, Paloma Arellano wrote:
> >> Adjust the encoder format programming in the case of video mode for DP
> >> to accommodate CDM related changes.
> >>
> >> Signed-off-by: Paloma Arellano
> >> ---
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 16 +
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 8 +
> >> .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 35 ---
> >> drivers/gpu/drm/msm/dp/dp_display.c | 12 +++
> >> drivers/gpu/drm/msm/msm_drv.h | 9 -
> >> 5 files changed, 75 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> index b0896814c1562..99ec53446ad21 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> @@ -222,6 +222,22 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
> >> 15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
> >> };
> >> +u32 dpu_encoder_get_drm_fmt(const struct drm_encoder *drm_enc,
> >> const struct drm_display_mode *mode)
> >> +{
> >> +const struct dpu_encoder_virt *dpu_enc;
> >> +const struct msm_display_info *disp_info;
> >> +struct msm_drm_private *priv;
> >> +
> >> +dpu_enc = to_dpu_encoder_virt(drm_enc);
> >> +disp_info = &dpu_enc->disp_info;
> >> +priv = drm_enc->dev->dev_private;
> >> +
> >> +if (disp_info->intf_type == INTF_DP &&
> >> + msm_dp_is_yuv_420_enabled(priv->dp[disp_info->h_tile_instance[0]],
> >> mode))
> >
> > This should not require interacting with DP. If we got here, we must
> > be sure that 4:2:0 is supported and can be configured.
> Ack. Will drop this function and only check for if the mode is YUV420.
> >
> >> +return DRM_FORMAT_YUV420;
> >> +
> >> +return DRM_FORMAT_RGB888;
> >> +}
> >> bool dpu_encoder_is_widebus_enabled(const struct drm_encoder
> >> *drm_enc)
> >> {
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> >> index 7b4afa71f1f96..62255d0aa4487 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> >> @@ -162,6 +162,14 @@ int dpu_encoder_get_vsync_count(struct
> >> drm_encoder *drm_enc);
> >>*/
> >> bool dpu_encoder_is_widebus_enabled(const struct drm_encoder
> >> *drm_enc);
> >> +/**
> >> + * dpu_encoder_get_drm_fmt - return DRM fourcc format
> >> + * @drm_enc:Pointer to previously created drm encoder structure
> >> + * @mode:Corresponding drm_display_mode for dpu encoder
> >> + */
> >> +u32 dpu_encoder_get_drm_fmt(const struct drm_encoder *drm_enc,
> >> +const struct drm_display_mode *mode);
> >> +
> >> /**
> >>* dpu_encoder_get_crc_values_cnt - get number of physical encoders
> >> contained
> >>*in virtual encoder that can collect CRC values
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> >> index e284bf448bdda..a1dde0ff35dc8 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> >> @@ -234,6 +234,7 @@ static void
> >> dpu_encoder_phys_vid_setup_timing_engine(
> >> {
> >> struct drm_display_mode mode;
> >> struct dpu_hw_intf_timing_params timing_params = { 0 };
> >> +struct dpu_hw_cdm *hw_cdm;
> >> const struct dpu_format *fmt = NULL;
> >> u32 fmt_fourcc = DRM_FORMAT_RGB888;
> >> unsigned long lock_flags;
> >> @@ -254,17 +255,26 @@ static void
> >> dpu_encoder_phys_vid_setup_timing_engine(
> >> DPU_DEBUG_VIDENC(phys_enc, "enabling mode:\n");
> >> drm_mode_debug_printmodeline(&mode);
> >> -if (phys_enc->split_role != ENC_ROLE_SOLO) {
> >> +hw_cdm = phys_enc->hw_cdm;
> >> +if (hw_cdm) {
> >> +intf_cfg.cdm = hw_cdm->idx;
> >> +fmt_fourcc = dpu_encoder_get_drm_fmt(phys_enc->parent, &mode);
> >> +}
> >> +
> >> +if (phys_enc->split_role != ENC_ROLE_SOLO ||
> >> +dpu_encoder_get_drm_fmt(phys_enc->parent, &mode) ==
> >> DRM_FORMAT_YUV420) {
> >> mode.hdisplay >>= 1;
> >> mode.htotal >>= 1;
> >> mode.hsync_start >>= 1;
> >> mode.hsync_end >>= 1;
> >> +mode.hskew >>= 1;
> >
> > Separate patch.
> Ack.
> >
> >> DPU_DEBUG_VIDENC(phys_enc,
> >> -"split_role %d, halve horizontal %d %d %d %d\n",
> >> +"split_role %d, halve horizontal %d %d %d %d %d\n",
> >> phys_enc->split_role,
> >> mode.hdisplay, mode.htotal,
> >> -mode.hsync_start, mode.hsync_end);
> >> +mode.hsync_start, mode.hsync_end,
> >> +mode.hskew);
> >> }
> >> drm_mode_to_intf_t
Re: [PATCH 16/17] drm/msm/dpu: reserve CDM blocks for DP if mode is YUV420
On 1/25/2024 2:01 PM, Dmitry Baryshkov wrote:
On 25/01/2024 21:38, Paloma Arellano wrote:
Reserve CDM blocks for DP if the mode format is YUV420. Currently this
reservation only works for writeback and DP if the format is YUV420. But
this can be easily extented to other YUV formats for DP.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 99ec53446ad21..c7dcda3d54ae6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -613,6 +613,7 @@ static int dpu_encoder_virt_atomic_check(
struct dpu_kms *dpu_kms;
struct drm_display_mode *adj_mode;
struct msm_display_topology topology;
+ struct msm_display_info *disp_info;
struct dpu_global_state *global_state;
struct drm_framebuffer *fb;
struct drm_dsc_config *dsc;
@@ -629,6 +630,7 @@ static int dpu_encoder_virt_atomic_check(
DPU_DEBUG_ENC(dpu_enc, "\n");
priv = drm_enc->dev->dev_private;
+ disp_info = &dpu_enc->disp_info;
dpu_kms = to_dpu_kms(priv->kms);
adj_mode = &crtc_state->adjusted_mode;
global_state = dpu_kms_get_global_state(crtc_state->state);
@@ -656,8 +658,8 @@ static int dpu_encoder_virt_atomic_check(
topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode,
crtc_state, dsc);
/*
- * Use CDM only for writeback 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()
+ * 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 (dpu_enc->disp_info.intf_type == INTF_WB &&
conn_state->writeback_job) {
@@ -665,12 +667,15 @@ static int dpu_encoder_virt_atomic_check(
if (fb &&
DPU_FORMAT_IS_YUV(to_dpu_format(msm_framebuffer_format(fb
topology.needs_cdm = true;
- if (topology.needs_cdm && !dpu_enc->cur_master->hw_cdm)
- crtc_state->mode_changed = true;
- else if (!topology.needs_cdm && dpu_enc->cur_master->hw_cdm)
- crtc_state->mode_changed = true;
+ } else if (dpu_enc->disp_info.intf_type == INTF_DP) {
You can use disp_info directly here.
Ack
+ if
(msm_dp_is_yuv_420_enabled(priv->dp[disp_info->h_tile_instance[0]],
adj_mode))
+ topology.needs_cdm = true;
}
+ if (topology.needs_cdm && !dpu_enc->cur_master->hw_cdm)
+ crtc_state->mode_changed = true;
+ else if (!topology.needs_cdm && dpu_enc->cur_master->hw_cdm)
+ crtc_state->mode_changed = true;
/*
* Release and Allocate resources on every modeset
* Dont allocate when active is false.
@@ -,7 +1116,8 @@ static void
dpu_encoder_virt_atomic_mode_set(struct drm_encoder *drm_enc,
dpu_enc->dsc_mask = dsc_mask;
- if (dpu_enc->disp_info.intf_type == INTF_WB &&
conn_state->writeback_job) {
+ if ((dpu_enc->disp_info.intf_type == INTF_WB &&
conn_state->writeback_job) ||
+ dpu_enc->disp_info.intf_type == INTF_DP) {
struct dpu_hw_blk *hw_cdm = NULL;
dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
Re: [PATCH 14/17] drm/msm/dpu: modify encoder programming for CDM over DP
On 1/25/2024 1:57 PM, Dmitry Baryshkov wrote:
On 25/01/2024 21:38, Paloma Arellano wrote:
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 16 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 8 +
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 35 ---
drivers/gpu/drm/msm/dp/dp_display.c | 12 +++
drivers/gpu/drm/msm/msm_drv.h | 9 -
5 files changed, 75 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index b0896814c1562..99ec53446ad21 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -222,6 +222,22 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
};
+u32 dpu_encoder_get_drm_fmt(const struct drm_encoder *drm_enc,
const struct drm_display_mode *mode)
+{
+ const struct dpu_encoder_virt *dpu_enc;
+ const struct msm_display_info *disp_info;
+ struct msm_drm_private *priv;
+
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ disp_info = &dpu_enc->disp_info;
+ priv = drm_enc->dev->dev_private;
+
+ if (disp_info->intf_type == INTF_DP &&
+ msm_dp_is_yuv_420_enabled(priv->dp[disp_info->h_tile_instance[0]],
mode))
This should not require interacting with DP. If we got here, we must
be sure that 4:2:0 is supported and can be configured.
Ack. Will drop this function and only check for if the mode is YUV420.
+ return DRM_FORMAT_YUV420;
+
+ return DRM_FORMAT_RGB888;
+}
bool dpu_encoder_is_widebus_enabled(const struct drm_encoder
*drm_enc)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 7b4afa71f1f96..62255d0aa4487 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -162,6 +162,14 @@ int dpu_encoder_get_vsync_count(struct
drm_encoder *drm_enc);
*/
bool dpu_encoder_is_widebus_enabled(const struct drm_encoder
*drm_enc);
+/**
+ * dpu_encoder_get_drm_fmt - return DRM fourcc format
+ * @drm_enc: Pointer to previously created drm encoder structure
+ * @mode: Corresponding drm_display_mode for dpu encoder
+ */
+u32 dpu_encoder_get_drm_fmt(const struct drm_encoder *drm_enc,
+ const struct drm_display_mode *mode);
+
/**
* dpu_encoder_get_crc_values_cnt - get number of physical encoders
contained
* in virtual encoder that can collect CRC values
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index e284bf448bdda..a1dde0ff35dc8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -234,6 +234,7 @@ static void
dpu_encoder_phys_vid_setup_timing_engine(
{
struct drm_display_mode mode;
struct dpu_hw_intf_timing_params timing_params = { 0 };
+ struct dpu_hw_cdm *hw_cdm;
const struct dpu_format *fmt = NULL;
u32 fmt_fourcc = DRM_FORMAT_RGB888;
unsigned long lock_flags;
@@ -254,17 +255,26 @@ static void
dpu_encoder_phys_vid_setup_timing_engine(
DPU_DEBUG_VIDENC(phys_enc, "enabling mode:\n");
drm_mode_debug_printmodeline(&mode);
- if (phys_enc->split_role != ENC_ROLE_SOLO) {
+ hw_cdm = phys_enc->hw_cdm;
+ if (hw_cdm) {
+ intf_cfg.cdm = hw_cdm->idx;
+ fmt_fourcc = dpu_encoder_get_drm_fmt(phys_enc->parent, &mode);
+ }
+
+ if (phys_enc->split_role != ENC_ROLE_SOLO ||
+ dpu_encoder_get_drm_fmt(phys_enc->parent, &mode) ==
DRM_FORMAT_YUV420) {
mode.hdisplay >>= 1;
mode.htotal >>= 1;
mode.hsync_start >>= 1;
mode.hsync_end >>= 1;
+ mode.hskew >>= 1;
Separate patch.
Ack.
DPU_DEBUG_VIDENC(phys_enc,
- "split_role %d, halve horizontal %d %d %d %d\n",
+ "split_role %d, halve horizontal %d %d %d %d %d\n",
phys_enc->split_role,
mode.hdisplay, mode.htotal,
- mode.hsync_start, mode.hsync_end);
+ mode.hsync_start, mode.hsync_end,
+ mode.hskew);
}
drm_mode_to_intf_timing_params(phys_enc, &mode, &timing_params);
@@ -412,8 +422,15 @@ static int dpu_encoder_phys_vid_control_vblank_irq(
static void dpu_encoder_phys_vid_enable(struct dpu_encoder_phys
*phys_enc)
{
struct dpu_hw_ctl *ctl;
+ struct dpu_hw_cdm *hw_cdm;
+ const struct dpu_format *fmt = NULL;
+ u32 fmt_fourcc = DRM_FORMAT_RGB888;
ctl = phys_enc->hw_ctl;
+ hw_cdm = phys_enc->hw_cdm;
+ if (hw_cdm)
+ fmt_fourcc = dpu_encoder_get_drm_fmt(phys_enc->parent,
&phys_enc->cached_mode);
+ fmt = dpu_get_dpu_format(fmt_fourcc);
DPU_DEBUG_VI
Re: [PATCH 12/17] drm/msm/dpu: add support of new peripheral flush mechanism
On Sun, 28 Jan 2024 at 07:41, Paloma Arellano wrote:
>
>
> On 1/25/2024 1:49 PM, Dmitry Baryshkov wrote:
> > On 25/01/2024 21:38, Paloma Arellano wrote:
> >> From: Kuogee Hsieh
> >>
> >> Introduce a peripheral flushing mechanism to decouple peripheral
> >> metadata flushing from timing engine related flush.
> >>
> >> Signed-off-by: Kuogee Hsieh
> >> Signed-off-by: Paloma Arellano
> >> ---
> >> .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c| 3 +++
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 17 +
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 10 ++
> >> 3 files changed, 30 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> >> index d0f56c5c4cce9..e284bf448bdda 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> >> @@ -437,6 +437,9 @@ static void dpu_encoder_phys_vid_enable(struct
> >> dpu_encoder_phys *phys_enc)
> >> if (ctl->ops.update_pending_flush_merge_3d &&
> >> phys_enc->hw_pp->merge_3d)
> >> ctl->ops.update_pending_flush_merge_3d(ctl,
> >> phys_enc->hw_pp->merge_3d->idx);
> >> +if (ctl->ops.update_pending_flush_periph &&
> >> phys_enc->hw_intf->cap->type == INTF_DP)
> >> +ctl->ops.update_pending_flush_periph(ctl,
> >> phys_enc->hw_intf->idx);
> >> +
> >> skip_flush:
> >> DPU_DEBUG_VIDENC(phys_enc,
> >> "update pending flush ctl %d intf %d\n",
> >> 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 e76565c3e6a43..bf45afeb616d3 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> >> @@ -39,6 +39,7 @@
> >> #define CTL_WB_FLUSH 0x108
> >> #define CTL_INTF_FLUSH0x110
> >> #define CTL_CDM_FLUSH0x114
> >> +#define CTL_PERIPH_FLUSH 0x128
> >> #define CTL_INTF_MASTER 0x134
> >> #define CTL_DSPP_n_FLUSH(n) ((0x13C) + ((n) * 4))
> >> @@ -49,6 +50,7 @@
> >> #define MERGE_3D_IDX 23
> >> #define DSC_IDX22
> >> #define CDM_IDX 26
> >> +#define PERIPH_IDX 30
> >> #define INTF_IDX 31
> >> #define WB_IDX 16
> >> #define DSPP_IDX 29 /* From DPU hw rev 7.x.x */
> >> @@ -151,6 +153,10 @@ static inline void
> >> dpu_hw_ctl_trigger_flush_v1(struct dpu_hw_ctl *ctx)
> >> ctx->pending_dspp_flush_mask[dspp - DSPP_0]);
> >> }
> >> +if (ctx->pending_flush_mask & BIT(PERIPH_IDX))
> >> +DPU_REG_WRITE(&ctx->hw, CTL_PERIPH_FLUSH,
> >> + ctx->pending_periph_flush_mask);
> >> +
> >> if (ctx->pending_flush_mask & BIT(DSC_IDX))
> >> DPU_REG_WRITE(&ctx->hw, CTL_DSC_FLUSH,
> >> ctx->pending_dsc_flush_mask);
> >> @@ -311,6 +317,13 @@ static void
> >> dpu_hw_ctl_update_pending_flush_intf_v1(struct dpu_hw_ctl *ctx,
> >> ctx->pending_flush_mask |= BIT(INTF_IDX);
> >> }
> >> +static void dpu_hw_ctl_update_pending_flush_periph(struct
> >> dpu_hw_ctl *ctx,
> >> +enum dpu_intf intf)
> >
> > I assume this is _v1.
> > Also the argument is misaligned.
> Ack.
> >
> >> +{
> >> +ctx->pending_periph_flush_mask |= BIT(intf - INTF_0);
> >> +ctx->pending_flush_mask |= BIT(PERIPH_IDX);
> >> +}
> >> +
> >> static void dpu_hw_ctl_update_pending_flush_merge_3d_v1(struct
> >> dpu_hw_ctl *ctx,
> >> enum dpu_merge_3d merge_3d)
> >> {
> >> @@ -680,6 +693,10 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops
> >> *ops,
> >> ops->reset_intf_cfg = dpu_hw_ctl_reset_intf_cfg_v1;
> >> ops->update_pending_flush_intf =
> >> dpu_hw_ctl_update_pending_flush_intf_v1;
> >> +
> >> +ops->update_pending_flush_periph =
> >> +dpu_hw_ctl_update_pending_flush_periph;
> >> +
> >> ops->update_pending_flush_merge_3d =
> >> dpu_hw_ctl_update_pending_flush_merge_3d_v1;
> >> ops->update_pending_flush_wb =
> >> dpu_hw_ctl_update_pending_flush_wb_v1;
> >
> > What about the pre-active platforms?
> Pre-active does not need a peripheral flush.
Ack.
> >
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
> >> index ff85b5ee0acf8..5d86c560b6d3f 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
> >> @@ -122,6 +122,15 @@ struct dpu_hw_ctl_ops {
> >> void (*update_pending_flush_intf)(struct dpu_hw_ctl *ctx,
> >> enum dpu_intf blk);
> >> +/**
> >> + * OR in the given flushbits to the cached
> >> pending_(periph_)flush_mask
> >> + * No effect on hardware
> >> + * @ctx : ctl path ctx pointer
> >> + * @blk : interface block index
Re: [PATCH 13/17] drm/msm/dp: enable SDP and SDE periph flush update
On 1/25/2024 1:50 PM, Dmitry Baryshkov wrote:
On 25/01/2024 21:38, Paloma Arellano wrote:
DP controller can be setup to operate in either SDP update flush mode or
peripheral flush mode based on the DP controller hardware version.
Starting in DP v1.2, the hardware documents require the use of
peripheral flush mode for SDP packets such as PPS OR VSC SDP packets.
In-line with this guidance, lets program the DP controller to use
peripheral flush mode starting DP v1.2
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 18 ++
drivers/gpu/drm/msm/dp/dp_catalog.h | 1 +
drivers/gpu/drm/msm/dp/dp_ctrl.c | 1 +
drivers/gpu/drm/msm/dp/dp_reg.h | 2 ++
4 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 7e4c68be23e56..b43083b9c2df6 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -446,6 +446,24 @@ void dp_catalog_ctrl_config_misc(struct
dp_catalog *dp_catalog,
dp_write_link(catalog, REG_DP_MISC1_MISC0, misc_val);
}
+void dp_catalog_setup_peripheral_flush(struct dp_catalog *dp_catalog)
+{
+ u32 mainlink_ctrl;
+ u16 major = 0, minor = 0;
+ struct dp_catalog_private *catalog = container_of(dp_catalog,
+ struct dp_catalog_private, dp_catalog);
+
+ mainlink_ctrl = dp_read_link(catalog, REG_DP_MAINLINK_CTRL);
+
+ dp_catalog_hw_revision(dp_catalog, &major, &minor);
+ if (major >= 1 && minor >= 2)
if (major > 1 || (major == 1 && minor >= 2))
As a check, which of the values should be written for maj.min = 2.1?
Ack. My mistake
+ mainlink_ctrl |= DP_MAINLINK_FLUSH_MODE_SDE_PERIPH_UPDATE;
+ else
+ mainlink_ctrl |= DP_MAINLINK_FLUSH_MODE_UPDATE_SDP;
+
+ dp_write_link(catalog, REG_DP_MAINLINK_CTRL, mainlink_ctrl);
+}
+
void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog,
u32 rate, u32 stream_rate_khz,
bool fixed_nvid, bool is_ycbcr_420)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 6b757249c0698..1d57988aa6689 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -169,6 +169,7 @@ void dp_catalog_ctrl_config_ctrl(struct
dp_catalog *dp_catalog, u32 config);
void dp_catalog_ctrl_lane_mapping(struct dp_catalog *dp_catalog);
void dp_catalog_ctrl_mainlink_ctrl(struct dp_catalog *dp_catalog,
bool enable);
void dp_catalog_ctrl_psr_mainlink_enable(struct dp_catalog
*dp_catalog, bool enable);
+void dp_catalog_setup_peripheral_flush(struct dp_catalog *dp_catalog);
void dp_catalog_ctrl_config_misc(struct dp_catalog *dp_catalog, u32
cc, u32 tb);
void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog, u32
rate,
u32 stream_rate_khz, bool fixed_nvid, bool
is_ycbcr_420);
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index ddd92a63d5a67..c375b36f53ce1 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -170,6 +170,7 @@ static void
dp_ctrl_configure_source_params(struct dp_ctrl_private *ctrl)
dp_catalog_ctrl_lane_mapping(ctrl->catalog);
dp_catalog_ctrl_mainlink_ctrl(ctrl->catalog, true);
+ dp_catalog_setup_peripheral_flush(ctrl->catalog);
dp_ctrl_config_ctrl(ctrl);
diff --git a/drivers/gpu/drm/msm/dp/dp_reg.h
b/drivers/gpu/drm/msm/dp/dp_reg.h
index 756ddf85b1e81..05a1009d2f678 100644
--- a/drivers/gpu/drm/msm/dp/dp_reg.h
+++ b/drivers/gpu/drm/msm/dp/dp_reg.h
@@ -102,6 +102,8 @@
#define DP_MAINLINK_CTRL_ENABLE (0x0001)
#define DP_MAINLINK_CTRL_RESET (0x0002)
#define DP_MAINLINK_CTRL_SW_BYPASS_SCRAMBLER (0x0010)
+#define DP_MAINLINK_FLUSH_MODE_UPDATE_SDP (0x0080)
+#define DP_MAINLINK_FLUSH_MODE_SDE_PERIPH_UPDATE (0x0180)
#define DP_MAINLINK_FB_BOUNDARY_SEL (0x0200)
#define REG_DP_STATE_CTRL (0x0004)
Re: [PATCH 12/17] drm/msm/dpu: add support of new peripheral flush mechanism
On 1/25/2024 1:49 PM, Dmitry Baryshkov wrote:
On 25/01/2024 21:38, Paloma Arellano wrote:
From: Kuogee Hsieh
Introduce a peripheral flushing mechanism to decouple peripheral
metadata flushing from timing engine related flush.
Signed-off-by: Kuogee Hsieh
Signed-off-by: Paloma Arellano
---
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 3 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 17 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 10 ++
3 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index d0f56c5c4cce9..e284bf448bdda 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -437,6 +437,9 @@ static void dpu_encoder_phys_vid_enable(struct
dpu_encoder_phys *phys_enc)
if (ctl->ops.update_pending_flush_merge_3d &&
phys_enc->hw_pp->merge_3d)
ctl->ops.update_pending_flush_merge_3d(ctl,
phys_enc->hw_pp->merge_3d->idx);
+ if (ctl->ops.update_pending_flush_periph &&
phys_enc->hw_intf->cap->type == INTF_DP)
+ ctl->ops.update_pending_flush_periph(ctl,
phys_enc->hw_intf->idx);
+
skip_flush:
DPU_DEBUG_VIDENC(phys_enc,
"update pending flush ctl %d intf %d\n",
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 e76565c3e6a43..bf45afeb616d3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -39,6 +39,7 @@
#define CTL_WB_FLUSH 0x108
#define CTL_INTF_FLUSH 0x110
#define CTL_CDM_FLUSH 0x114
+#define CTL_PERIPH_FLUSH 0x128
#define CTL_INTF_MASTER 0x134
#define CTL_DSPP_n_FLUSH(n) ((0x13C) + ((n) * 4))
@@ -49,6 +50,7 @@
#define MERGE_3D_IDX 23
#define DSC_IDX 22
#define CDM_IDX 26
+#define PERIPH_IDX 30
#define INTF_IDX 31
#define WB_IDX 16
#define DSPP_IDX 29 /* From DPU hw rev 7.x.x */
@@ -151,6 +153,10 @@ static inline void
dpu_hw_ctl_trigger_flush_v1(struct dpu_hw_ctl *ctx)
ctx->pending_dspp_flush_mask[dspp - DSPP_0]);
}
+ if (ctx->pending_flush_mask & BIT(PERIPH_IDX))
+ DPU_REG_WRITE(&ctx->hw, CTL_PERIPH_FLUSH,
+ ctx->pending_periph_flush_mask);
+
if (ctx->pending_flush_mask & BIT(DSC_IDX))
DPU_REG_WRITE(&ctx->hw, CTL_DSC_FLUSH,
ctx->pending_dsc_flush_mask);
@@ -311,6 +317,13 @@ static void
dpu_hw_ctl_update_pending_flush_intf_v1(struct dpu_hw_ctl *ctx,
ctx->pending_flush_mask |= BIT(INTF_IDX);
}
+static void dpu_hw_ctl_update_pending_flush_periph(struct
dpu_hw_ctl *ctx,
+ enum dpu_intf intf)
I assume this is _v1.
Also the argument is misaligned.
Ack.
+{
+ ctx->pending_periph_flush_mask |= BIT(intf - INTF_0);
+ ctx->pending_flush_mask |= BIT(PERIPH_IDX);
+}
+
static void dpu_hw_ctl_update_pending_flush_merge_3d_v1(struct
dpu_hw_ctl *ctx,
enum dpu_merge_3d merge_3d)
{
@@ -680,6 +693,10 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops
*ops,
ops->reset_intf_cfg = dpu_hw_ctl_reset_intf_cfg_v1;
ops->update_pending_flush_intf =
dpu_hw_ctl_update_pending_flush_intf_v1;
+
+ ops->update_pending_flush_periph =
+ dpu_hw_ctl_update_pending_flush_periph;
+
ops->update_pending_flush_merge_3d =
dpu_hw_ctl_update_pending_flush_merge_3d_v1;
ops->update_pending_flush_wb =
dpu_hw_ctl_update_pending_flush_wb_v1;
What about the pre-active platforms?
Pre-active does not need a peripheral flush.
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
index ff85b5ee0acf8..5d86c560b6d3f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
@@ -122,6 +122,15 @@ struct dpu_hw_ctl_ops {
void (*update_pending_flush_intf)(struct dpu_hw_ctl *ctx,
enum dpu_intf blk);
+ /**
+ * OR in the given flushbits to the cached
pending_(periph_)flush_mask
+ * No effect on hardware
+ * @ctx : ctl path ctx pointer
+ * @blk : interface block index
+ */
+ void (*update_pending_flush_periph)(struct dpu_hw_ctl *ctx,
+ enum dpu_intf blk);
+
/**
* OR in the given flushbits to the cached
pending_(merge_3d_)flush_mask
* No effect on hardware
@@ -264,6 +273,7 @@ struct dpu_hw_ctl {
u32 pending_flush_mask;
u32 pending_intf_flush_mask;
u32 pending_wb_flush_mask;
+ u32 pending_periph_flush_mask;
u32 pending_merge_3d_flush_mask;
u32 pending_dspp_flush_mask[DSPP_MAX - DSPP_0];
u32 pending_dsc_flush_mask;
Re: [PATCH 11/17] drm/msm/dp: add VSC SDP support for YUV420 over DP
On Sun, 28 Jan 2024 at 07:34, Paloma Arellano wrote:
>
>
> On 1/25/2024 1:48 PM, Dmitry Baryshkov wrote:
> > On 25/01/2024 21:38, Paloma Arellano wrote:
> >> Add support to pack and send the VSC SDP packet for DP. This therefore
> >> allows the transmision of format information to the sinks which is
> >> needed for YUV420 support over DP.
> >>
> >> Signed-off-by: Paloma Arellano
> >> ---
> >> drivers/gpu/drm/msm/dp/dp_catalog.c | 147
> >> drivers/gpu/drm/msm/dp/dp_catalog.h | 4 +
> >> drivers/gpu/drm/msm/dp/dp_ctrl.c| 4 +
> >> drivers/gpu/drm/msm/dp/dp_panel.c | 47 +
> >> drivers/gpu/drm/msm/dp/dp_reg.h | 3 +
> >> 5 files changed, 205 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
> >> b/drivers/gpu/drm/msm/dp/dp_catalog.c
> >> index c025786170ba5..7e4c68be23e56 100644
> >> --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> >> +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> >> @@ -29,6 +29,9 @@
> >> #define DP_INTF_CONFIG_DATABUS_WIDEN BIT(4)
> >> +#define DP_GENERIC0_6_YUV_8_BPCBIT(0)
> >> +#define DP_GENERIC0_6_YUV_10_BPCBIT(1)
> >> +
> >> #define DP_INTERRUPT_STATUS1 \
> >> (DP_INTR_AUX_XFER_DONE| \
> >> DP_INTR_WRONG_ADDR | DP_INTR_TIMEOUT | \
> >> @@ -907,6 +910,150 @@ int dp_catalog_panel_timing_cfg(struct
> >> dp_catalog *dp_catalog)
> >> return 0;
> >> }
> >> +static void dp_catalog_panel_setup_vsc_sdp(struct dp_catalog
> >> *dp_catalog)
> >> +{
> >> +struct dp_catalog_private *catalog;
> >> +u32 header, parity, data;
> >> +u8 bpc, off = 0;
> >> +u8 buf[SZ_128];
> >> +
> >> +if (!dp_catalog) {
> >> +pr_err("invalid input\n");
> >> +return;
> >> +}
> >> +
> >> +catalog = container_of(dp_catalog, struct dp_catalog_private,
> >> dp_catalog);
> >> +
> >> +/* HEADER BYTE 1 */
> >> +header = dp_catalog->sdp.sdp_header.HB1;
> >> +parity = dp_catalog_calculate_parity(header);
> >> +data = ((header << HEADER_BYTE_1_BIT) | (parity <<
> >> PARITY_BYTE_1_BIT));
> >> +dp_write_link(catalog, MMSS_DP_GENERIC0_0, data);
> >> +memcpy(buf + off, &data, sizeof(data));
> >> +off += sizeof(data);
> >> +
> >> +/* HEADER BYTE 2 */
> >> +header = dp_catalog->sdp.sdp_header.HB2;
> >> +parity = dp_catalog_calculate_parity(header);
> >> +data = ((header << HEADER_BYTE_2_BIT) | (parity <<
> >> PARITY_BYTE_2_BIT));
> >> +dp_write_link(catalog, MMSS_DP_GENERIC0_1, data);
> >> +
> >> +/* HEADER BYTE 3 */
> >> +header = dp_catalog->sdp.sdp_header.HB3;
> >> +parity = dp_catalog_calculate_parity(header);
> >> +data = ((header << HEADER_BYTE_3_BIT) | (parity <<
> >> PARITY_BYTE_3_BIT));
> >> +data |= dp_read_link(catalog, MMSS_DP_GENERIC0_1);
> >> +dp_write_link(catalog, MMSS_DP_GENERIC0_1, data);
> >> +memcpy(buf + off, &data, sizeof(data));
> >> +off += sizeof(data);
> >
> > This seems to be common with the dp_audio code. Please extract this
> > header writing too.
> These are two different sdp's. audio and vsc, are different with
> different registers being written to and different amount of registers
> being set. Can you please clarify since in audio we only need 3
> registers to write to, and in vsc we need 10.
Bitmagic with the header is the same. Then the rest of the data is
written one dword per register, if I'm not mistaken.
> >
> >> +
> >> +data = 0;
> >> +dp_write_link(catalog, MMSS_DP_GENERIC0_2, data);
> >> +memcpy(buf + off, &data, sizeof(data));
> >> +off += sizeof(data);
> >
> > Generally this is not how these functions are expected to be written.
> > Please take a look at drivers/video/hdmi.c. It should be split into:
> > - generic function that packs the C structure into a flat byte buffer,
> > - driver-specific function that formats and writes the buffer to the
> > hardware.
> >
> >> +dp_write_link(catalog, MMSS_DP_GENERIC0_3, data);
> >> +memcpy(buf + off, &data, sizeof(data));
> >> +off += sizeof(data);
> >> +
> >> +dp_write_link(catalog, MMSS_DP_GENERIC0_4, data);
> >> +memcpy(buf + off, &data, sizeof(data));
> >> +off += sizeof(data);
> >> +
> >> +dp_write_link(catalog, MMSS_DP_GENERIC0_5, data);
> >> +memcpy(buf + off, &data, sizeof(data));
> >> +off += sizeof(data);
> >> +
> >> +switch (dp_catalog->vsc_sdp_data.bpc) {
> >> +case 10:
> >> +bpc = DP_GENERIC0_6_YUV_10_BPC;
> >> +break;
> >> +case 8:
> >> +default:
> >> +bpc = DP_GENERIC0_6_YUV_8_BPC;
> >> +break;
> >> +}
> >> +
> >> +/* VSC SDP payload as per table 2-117 of DP 1.4 specification */
> >> +data = (dp_catalog->vsc_sdp_data.colorimetry & 0xF) |
> >> + ((dp_catalog->vsc_sdp_data.pixelformat & 0xF) << 4) |
> >> + (bpc << 8) |
> >> + ((dp_catalog->vsc_sdp_data.dynamic_range & 0x1) << 15) |
> >> + ((dp_catalog->vsc_sdp_data.content_type & 0x7) << 1
Re: [PATCH] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors
On 1/26/2024 16:34, Mario Limonciello wrote:
On 1/26/2024 16:22, Hamza Mahfooz wrote:
We want programs besides the compositor to be able to enable or disable
panel power saving features. However, since they are currently only
configurable through DRM properties, that isn't possible. So, to remedy
that issue introduce a new "panel_power_savings" sysfs attribute.
Cc: Mario Limonciello
Signed-off-by: Hamza Mahfooz
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 59 +++
1 file changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index cd98b3565178..b3fcd833015d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6534,6 +6534,58 @@
amdgpu_dm_connector_atomic_duplicate_state(struct drm_connector
*connector)
return &new_state->base;
}
+static ssize_t panel_power_savings_show(struct device *device,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct drm_connector *connector = dev_get_drvdata(device);
+ struct drm_device *dev = connector->dev;
+ ssize_t val;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+ val = to_dm_connector_state(connector->state)->abm_level;
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ return sysfs_emit(buf, "%lu\n", val);
When the system is first booted up with nothing on the kernel command
line, this emits the value for ABM_LEVEL_IMMEDIATE_DISABLE, which isn't
something we normally should be showing to people.
I think you should be special casing it similar to how the store special
case works.
+}
+
+static ssize_t panel_power_savings_store(struct device *device,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct drm_connector *connector = dev_get_drvdata(device);
+ struct drm_device *dev = connector->dev;
+ long val;
+ int ret;
+
+ ret = kstrtol(buf, 0, &val);
+
+ if (ret)
+ return ret;
+
+ if (val < 0 || val > 4)
+ return -EINVAL;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+ to_dm_connector_state(connector->state)->abm_level = val ?:
+ ABM_LEVEL_IMMEDIATE_DISABLE;
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
It appears that the ABM doesn't actually take effect by writing this
value until the next modeset.
This is also reported by Dominik Förderer. I suggested he try to change
resolutions in his DE and that activated ABM.
So I think it's missing another call to flush out to the hardware.
+ return count;
+}
+
To make this more discoverable I think you want some kerneldoc.
+static DEVICE_ATTR_RW(panel_power_savings);
+
+static struct attribute *amdgpu_attrs[] = {
+ &dev_attr_panel_power_savings.attr,
+ NULL
+};
+
+static const struct attribute_group amdgpu_group = {
+ .name = "amdgpu",
+ .attrs = amdgpu_attrs
+};
+
static int
amdgpu_dm_connector_late_register(struct drm_connector *connector)
{
@@ -6541,6 +6593,13 @@ amdgpu_dm_connector_late_register(struct
drm_connector *connector)
to_amdgpu_dm_connector(connector);
int r;
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ r = sysfs_create_group(&connector->kdev->kobj,
+ &amdgpu_group);
+ if (r)
+ return r;
+ }
+
I think there should be some matching code sysfs_remove_group(), maybe
in early_unregister() callback.
amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
if ((connector->connector_type ==
DRM_MODE_CONNECTOR_DisplayPort) ||
Re: [PATCH 10/17] drm/msm/dp: modify dp_catalog_hw_revision to show major and minor val
On Sun, 28 Jan 2024 at 07:31, Paloma Arellano wrote:
>
>
> On 1/25/2024 2:07 PM, Dmitry Baryshkov wrote:
> > On 25/01/2024 21:38, Paloma Arellano wrote:
> >> Modify dp_catalog_hw_revision to make the major and minor version values
> >> known instead of outputting the entire hex value of the hardware version
> >> register in preparation of using it for VSC SDP programming.
> >>
> >> Signed-off-by: Paloma Arellano
> >> ---
> >> drivers/gpu/drm/msm/dp/dp_catalog.c | 12 +---
> >> drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +-
> >> 2 files changed, 10 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
> >> b/drivers/gpu/drm/msm/dp/dp_catalog.c
> >> index 5d84c089e520a..c025786170ba5 100644
> >> --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> >> +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> >> @@ -24,6 +24,9 @@
> >> #define DP_INTERRUPT_STATUS_ACK_SHIFT1
> >> #define DP_INTERRUPT_STATUS_MASK_SHIFT2
> >> +#define DP_HW_VERSION_MAJOR(reg)FIELD_GET(GENMASK(31, 28), reg)
> >> +#define DP_HW_VERSION_MINOR(reg)FIELD_GET(GENMASK(27, 16), reg)
> >> +
> >> #define DP_INTF_CONFIG_DATABUS_WIDEN BIT(4)
> >> #define DP_INTERRUPT_STATUS1 \
> >> @@ -531,15 +534,18 @@ int
> >> dp_catalog_ctrl_set_pattern_state_bit(struct dp_catalog *dp_catalog,
> >>*
> >>* @dp_catalog: DP catalog structure
> >>*
> >> - * Return: DP controller hw revision
> >> + * Return: void
> >>*
> >>*/
> >> -u32 dp_catalog_hw_revision(const struct dp_catalog *dp_catalog)
> >> +void dp_catalog_hw_revision(const struct dp_catalog *dp_catalog, u16
> >> *major, u16 *minor)
> >> {
> >> const struct dp_catalog_private *catalog =
> >> container_of(dp_catalog,
> >> struct dp_catalog_private, dp_catalog);
> >> +u32 reg_dp_hw_version;
> >> -return dp_read_ahb(catalog, REG_DP_HW_VERSION);
> >> +reg_dp_hw_version = dp_read_ahb(catalog, REG_DP_HW_VERSION);
> >> +*major = DP_HW_VERSION_MAJOR(reg_dp_hw_version);
> >> +*minor = DP_HW_VERSION_MINOR(reg_dp_hw_version);
> >
> > After looking at the code, it might be easier to keep
> > dp_catalog_hw_revision as is, add define for hw revision 1.2 and
> > corepare to it directly.
> I thought having a define value of the version would be harder to
> follow than what's here currently. Since having it compare to the
> version value looks a little difficult to read versus having an explicit
> major and minor value version to compare to. For example having (major
> >= 1 && minor >= 2) versus having something like (hw_version >=
> DPU_HW_VERSION_1_2)
The problem is that major + minor are harder to follow and harder to
implement. You got them wrong, btw. For example 2.1 is greater or
equal than 1.2, but it doesn't pass your test. So, I think, a single
define is easier and less error prone.
> >
> >> }
> >> /**
> >> diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
> >> b/drivers/gpu/drm/msm/dp/dp_catalog.h
> >> index 563903605b3a7..94c377ef90c35 100644
> >> --- a/drivers/gpu/drm/msm/dp/dp_catalog.h
> >> +++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
> >> @@ -170,7 +170,7 @@ void dp_catalog_ctrl_config_misc(struct
> >> dp_catalog *dp_catalog, u32 cc, u32 tb);
> >> void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog, u32
> >> rate,
> >> u32 stream_rate_khz, bool fixed_nvid, bool
> >> is_ycbcr_420);
> >> int dp_catalog_ctrl_set_pattern_state_bit(struct dp_catalog
> >> *dp_catalog, u32 pattern);
> >> -u32 dp_catalog_hw_revision(const struct dp_catalog *dp_catalog);
> >> +void dp_catalog_hw_revision(const struct dp_catalog *dp_catalog, u16
> >> *major, u16 *minor);
> >> void dp_catalog_ctrl_reset(struct dp_catalog *dp_catalog);
> >> bool dp_catalog_ctrl_mainlink_ready(struct dp_catalog *dp_catalog);
> >> void dp_catalog_ctrl_enable_irq(struct dp_catalog *dp_catalog, bool
> >> enable);
> >
--
With best wishes
Dmitry
Re: [PATCH 11/17] drm/msm/dp: add VSC SDP support for YUV420 over DP
On 1/25/2024 1:48 PM, Dmitry Baryshkov wrote:
On 25/01/2024 21:38, Paloma Arellano wrote:
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the transmision of format information to the sinks which is
needed for YUV420 support over DP.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 147
drivers/gpu/drm/msm/dp/dp_catalog.h | 4 +
drivers/gpu/drm/msm/dp/dp_ctrl.c | 4 +
drivers/gpu/drm/msm/dp/dp_panel.c | 47 +
drivers/gpu/drm/msm/dp/dp_reg.h | 3 +
5 files changed, 205 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index c025786170ba5..7e4c68be23e56 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -29,6 +29,9 @@
#define DP_INTF_CONFIG_DATABUS_WIDEN BIT(4)
+#define DP_GENERIC0_6_YUV_8_BPC BIT(0)
+#define DP_GENERIC0_6_YUV_10_BPC BIT(1)
+
#define DP_INTERRUPT_STATUS1 \
(DP_INTR_AUX_XFER_DONE| \
DP_INTR_WRONG_ADDR | DP_INTR_TIMEOUT | \
@@ -907,6 +910,150 @@ int dp_catalog_panel_timing_cfg(struct
dp_catalog *dp_catalog)
return 0;
}
+static void dp_catalog_panel_setup_vsc_sdp(struct dp_catalog
*dp_catalog)
+{
+ struct dp_catalog_private *catalog;
+ u32 header, parity, data;
+ u8 bpc, off = 0;
+ u8 buf[SZ_128];
+
+ if (!dp_catalog) {
+ pr_err("invalid input\n");
+ return;
+ }
+
+ catalog = container_of(dp_catalog, struct dp_catalog_private,
dp_catalog);
+
+ /* HEADER BYTE 1 */
+ header = dp_catalog->sdp.sdp_header.HB1;
+ parity = dp_catalog_calculate_parity(header);
+ data = ((header << HEADER_BYTE_1_BIT) | (parity <<
PARITY_BYTE_1_BIT));
+ dp_write_link(catalog, MMSS_DP_GENERIC0_0, data);
+ memcpy(buf + off, &data, sizeof(data));
+ off += sizeof(data);
+
+ /* HEADER BYTE 2 */
+ header = dp_catalog->sdp.sdp_header.HB2;
+ parity = dp_catalog_calculate_parity(header);
+ data = ((header << HEADER_BYTE_2_BIT) | (parity <<
PARITY_BYTE_2_BIT));
+ dp_write_link(catalog, MMSS_DP_GENERIC0_1, data);
+
+ /* HEADER BYTE 3 */
+ header = dp_catalog->sdp.sdp_header.HB3;
+ parity = dp_catalog_calculate_parity(header);
+ data = ((header << HEADER_BYTE_3_BIT) | (parity <<
PARITY_BYTE_3_BIT));
+ data |= dp_read_link(catalog, MMSS_DP_GENERIC0_1);
+ dp_write_link(catalog, MMSS_DP_GENERIC0_1, data);
+ memcpy(buf + off, &data, sizeof(data));
+ off += sizeof(data);
This seems to be common with the dp_audio code. Please extract this
header writing too.
These are two different sdp's. audio and vsc, are different with
different registers being written to and different amount of registers
being set. Can you please clarify since in audio we only need 3
registers to write to, and in vsc we need 10.
+
+ data = 0;
+ dp_write_link(catalog, MMSS_DP_GENERIC0_2, data);
+ memcpy(buf + off, &data, sizeof(data));
+ off += sizeof(data);
Generally this is not how these functions are expected to be written.
Please take a look at drivers/video/hdmi.c. It should be split into:
- generic function that packs the C structure into a flat byte buffer,
- driver-specific function that formats and writes the buffer to the
hardware.
+ dp_write_link(catalog, MMSS_DP_GENERIC0_3, data);
+ memcpy(buf + off, &data, sizeof(data));
+ off += sizeof(data);
+
+ dp_write_link(catalog, MMSS_DP_GENERIC0_4, data);
+ memcpy(buf + off, &data, sizeof(data));
+ off += sizeof(data);
+
+ dp_write_link(catalog, MMSS_DP_GENERIC0_5, data);
+ memcpy(buf + off, &data, sizeof(data));
+ off += sizeof(data);
+
+ switch (dp_catalog->vsc_sdp_data.bpc) {
+ case 10:
+ bpc = DP_GENERIC0_6_YUV_10_BPC;
+ break;
+ case 8:
+ default:
+ bpc = DP_GENERIC0_6_YUV_8_BPC;
+ break;
+ }
+
+ /* VSC SDP payload as per table 2-117 of DP 1.4 specification */
+ data = (dp_catalog->vsc_sdp_data.colorimetry & 0xF) |
+ ((dp_catalog->vsc_sdp_data.pixelformat & 0xF) << 4) |
+ (bpc << 8) |
+ ((dp_catalog->vsc_sdp_data.dynamic_range & 0x1) << 15) |
+ ((dp_catalog->vsc_sdp_data.content_type & 0x7) << 16);
+
+ dp_write_link(catalog, MMSS_DP_GENERIC0_6, data);
+ memcpy(buf + off, &data, sizeof(data));
+ off += sizeof(data);
+
+ data = 0;
+ dp_write_link(catalog, MMSS_DP_GENERIC0_7, data);
+ memcpy(buf + off, &data, sizeof(data));
+ off += sizeof(data);
+
+ dp_write_link(catalog, MMSS_DP_GENERIC0_8, data);
+ memcpy(buf + off, &data, sizeof(data));
+ off += sizeof(data);
+
+ dp_write_link(catalog, MMSS_DP_GENERIC0_9, data);
+ memcpy(buf + off, &data, sizeof(data));
+ off += sizeof(data);
+
+ print_hex_dump(KERN_DEBUG, "[drm-dp] VSC: ", DUMP_PREFIX_NONE,
16, 4, buf, off, false);
+}
+
+void dp_catalog_panel_config_vsc_sdp(struct dp_catalog *dp_catalog,
bool en)
+{
+
Re: [PATCH 07/17] drm/msm/dpu: disallow widebus en in INTF_CONFIG2 when DP is YUV420
On Sun, 28 Jan 2024 at 07:16, Paloma Arellano wrote: > > > On 1/25/2024 1:26 PM, Dmitry Baryshkov wrote: > > On 25/01/2024 21:38, Paloma Arellano wrote: > >> INTF_CONFIG2 register cannot have widebus enabled when DP format is > >> YUV420. Therefore, program the INTF to send 1 ppc. > > > > I think this is handled in the DP driver, where we disallow wide bus > > for YUV 4:2:0 modes. > Yes we do disallow wide bus for YUV420 modes, but we still need to > program the INTF_CFG2_DATA_HCTL_EN. Therefore, it is necessary to add > this check. As I wrote in my second email, I'd prefer to have one if which guards HCTL_EN and another one for WIDEN > > > >> > >> Signed-off-by: Paloma Arellano > >> --- > >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 4 +++- > >> 1 file changed, 3 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c > >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c > >> index 6bba531d6dc41..bfb93f02fe7c1 100644 > >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c > >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c > >> @@ -168,7 +168,9 @@ static void > >> dpu_hw_intf_setup_timing_engine(struct dpu_hw_intf *ctx, > >>* video timing. It is recommended to enable it for all cases, > >> except > >>* if compression is enabled in 1 pixel per clock mode > >>*/ > >> -if (p->wide_bus_en) > >> +if (dp_intf && fmt->base.pixel_format == DRM_FORMAT_YUV420) > >> +intf_cfg2 |= INTF_CFG2_DATA_HCTL_EN; > >> +else if (p->wide_bus_en) > >> intf_cfg2 |= INTF_CFG2_DATABUS_WIDEN | INTF_CFG2_DATA_HCTL_EN; > >> data_width = p->width; > > -- With best wishes Dmitry
Re: [PATCH 10/17] drm/msm/dp: modify dp_catalog_hw_revision to show major and minor val
On 1/25/2024 2:07 PM, Dmitry Baryshkov wrote:
On 25/01/2024 21:38, Paloma Arellano wrote:
Modify dp_catalog_hw_revision to make the major and minor version values
known instead of outputting the entire hex value of the hardware version
register in preparation of using it for VSC SDP programming.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 12 +---
drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +-
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 5d84c089e520a..c025786170ba5 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -24,6 +24,9 @@
#define DP_INTERRUPT_STATUS_ACK_SHIFT 1
#define DP_INTERRUPT_STATUS_MASK_SHIFT 2
+#define DP_HW_VERSION_MAJOR(reg) FIELD_GET(GENMASK(31, 28), reg)
+#define DP_HW_VERSION_MINOR(reg) FIELD_GET(GENMASK(27, 16), reg)
+
#define DP_INTF_CONFIG_DATABUS_WIDEN BIT(4)
#define DP_INTERRUPT_STATUS1 \
@@ -531,15 +534,18 @@ int
dp_catalog_ctrl_set_pattern_state_bit(struct dp_catalog *dp_catalog,
*
* @dp_catalog: DP catalog structure
*
- * Return: DP controller hw revision
+ * Return: void
*
*/
-u32 dp_catalog_hw_revision(const struct dp_catalog *dp_catalog)
+void dp_catalog_hw_revision(const struct dp_catalog *dp_catalog, u16
*major, u16 *minor)
{
const struct dp_catalog_private *catalog =
container_of(dp_catalog,
struct dp_catalog_private, dp_catalog);
+ u32 reg_dp_hw_version;
- return dp_read_ahb(catalog, REG_DP_HW_VERSION);
+ reg_dp_hw_version = dp_read_ahb(catalog, REG_DP_HW_VERSION);
+ *major = DP_HW_VERSION_MAJOR(reg_dp_hw_version);
+ *minor = DP_HW_VERSION_MINOR(reg_dp_hw_version);
After looking at the code, it might be easier to keep
dp_catalog_hw_revision as is, add define for hw revision 1.2 and
corepare to it directly.
I thought having a define value of the version would be harder to
follow than what's here currently. Since having it compare to the
version value looks a little difficult to read versus having an explicit
major and minor value version to compare to. For example having (major
>= 1 && minor >= 2) versus having something like (hw_version >=
DPU_HW_VERSION_1_2)
}
/**
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 563903605b3a7..94c377ef90c35 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -170,7 +170,7 @@ void dp_catalog_ctrl_config_misc(struct
dp_catalog *dp_catalog, u32 cc, u32 tb);
void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog, u32
rate,
u32 stream_rate_khz, bool fixed_nvid, bool
is_ycbcr_420);
int dp_catalog_ctrl_set_pattern_state_bit(struct dp_catalog
*dp_catalog, u32 pattern);
-u32 dp_catalog_hw_revision(const struct dp_catalog *dp_catalog);
+void dp_catalog_hw_revision(const struct dp_catalog *dp_catalog, u16
*major, u16 *minor);
void dp_catalog_ctrl_reset(struct dp_catalog *dp_catalog);
bool dp_catalog_ctrl_mainlink_ready(struct dp_catalog *dp_catalog);
void dp_catalog_ctrl_enable_irq(struct dp_catalog *dp_catalog, bool
enable);
Re: [PATCH 09/17] drm/msm/dp: move parity calculation to dp_catalog
On 1/25/2024 1:32 PM, Dmitry Baryshkov wrote:
On 25/01/2024 21:38, Paloma Arellano wrote:
Parity calculation is necessary for VSC SDP implementation, therefore
move it to dp_catalog so it usable by both SDP programming and
dp_audio.c
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_audio.c | 100
drivers/gpu/drm/msm/dp/dp_catalog.h | 72
2 files changed, 86 insertions(+), 86 deletions(-)
There is nothing catalog-uish in the parity calculation. Just add
dp_utils.c. Another options is to push it to the drm/display/
LGTM otherwise.
Ack. Will move to dp_utils.c
diff --git a/drivers/gpu/drm/msm/dp/dp_audio.c
b/drivers/gpu/drm/msm/dp/dp_audio.c
index 4a2e479723a85..7aa785018155a 100644
--- a/drivers/gpu/drm/msm/dp/dp_audio.c
+++ b/drivers/gpu/drm/msm/dp/dp_audio.c
@@ -16,13 +16,6 @@
#include "dp_panel.h"
#include "dp_display.h"
-#define HEADER_BYTE_2_BIT 0
-#define PARITY_BYTE_2_BIT 8
-#define HEADER_BYTE_1_BIT 16
-#define PARITY_BYTE_1_BIT 24
-#define HEADER_BYTE_3_BIT 16
-#define PARITY_BYTE_3_BIT 24
-
struct dp_audio_private {
struct platform_device *audio_pdev;
struct platform_device *pdev;
@@ -36,71 +29,6 @@ struct dp_audio_private {
struct dp_audio dp_audio;
};
-static u8 dp_audio_get_g0_value(u8 data)
-{
- u8 c[4];
- u8 g[4];
- u8 ret_data = 0;
- u8 i;
-
- for (i = 0; i < 4; i++)
- c[i] = (data >> i) & 0x01;
-
- g[0] = c[3];
- g[1] = c[0] ^ c[3];
- g[2] = c[1];
- g[3] = c[2];
-
- for (i = 0; i < 4; i++)
- ret_data = ((g[i] & 0x01) << i) | ret_data;
-
- return ret_data;
-}
-
-static u8 dp_audio_get_g1_value(u8 data)
-{
- u8 c[4];
- u8 g[4];
- u8 ret_data = 0;
- u8 i;
-
- for (i = 0; i < 4; i++)
- c[i] = (data >> i) & 0x01;
-
- g[0] = c[0] ^ c[3];
- g[1] = c[0] ^ c[1] ^ c[3];
- g[2] = c[1] ^ c[2];
- g[3] = c[2] ^ c[3];
-
- for (i = 0; i < 4; i++)
- ret_data = ((g[i] & 0x01) << i) | ret_data;
-
- return ret_data;
-}
-
-static u8 dp_audio_calculate_parity(u32 data)
-{
- u8 x0 = 0;
- u8 x1 = 0;
- u8 ci = 0;
- u8 iData = 0;
- u8 i = 0;
- u8 parity_byte;
- u8 num_byte = (data & 0xFF00) > 0 ? 8 : 2;
-
- for (i = 0; i < num_byte; i++) {
- iData = (data >> i*4) & 0xF;
-
- ci = iData ^ x1;
- x1 = x0 ^ dp_audio_get_g1_value(ci);
- x0 = dp_audio_get_g0_value(ci);
- }
-
- parity_byte = x1 | (x0 << 4);
-
- return parity_byte;
-}
-
static u32 dp_audio_get_header(struct dp_catalog *catalog,
enum dp_catalog_audio_sdp_type sdp,
enum dp_catalog_audio_header_type header)
@@ -134,7 +62,7 @@ static void dp_audio_stream_sdp(struct
dp_audio_private *audio)
DP_AUDIO_SDP_STREAM, DP_AUDIO_SDP_HEADER_1);
new_value = 0x02;
- parity_byte = dp_audio_calculate_parity(new_value);
+ parity_byte = dp_catalog_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_1_BIT)
| (parity_byte << PARITY_BYTE_1_BIT));
drm_dbg_dp(audio->drm_dev,
@@ -147,7 +75,7 @@ static void dp_audio_stream_sdp(struct
dp_audio_private *audio)
value = dp_audio_get_header(catalog,
DP_AUDIO_SDP_STREAM, DP_AUDIO_SDP_HEADER_2);
new_value = value;
- parity_byte = dp_audio_calculate_parity(new_value);
+ parity_byte = dp_catalog_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_2_BIT)
| (parity_byte << PARITY_BYTE_2_BIT));
drm_dbg_dp(audio->drm_dev,
@@ -162,7 +90,7 @@ static void dp_audio_stream_sdp(struct
dp_audio_private *audio)
DP_AUDIO_SDP_STREAM, DP_AUDIO_SDP_HEADER_3);
new_value = audio->channels - 1;
- parity_byte = dp_audio_calculate_parity(new_value);
+ parity_byte = dp_catalog_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_3_BIT)
| (parity_byte << PARITY_BYTE_3_BIT));
drm_dbg_dp(audio->drm_dev,
@@ -184,7 +112,7 @@ static void dp_audio_timestamp_sdp(struct
dp_audio_private *audio)
DP_AUDIO_SDP_TIMESTAMP, DP_AUDIO_SDP_HEADER_1);
new_value = 0x1;
- parity_byte = dp_audio_calculate_parity(new_value);
+ parity_byte = dp_catalog_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_1_BIT)
| (parity_byte << PARITY_BYTE_1_BIT));
drm_dbg_dp(audio->drm_dev,
@@ -198,7 +126,7 @@ static void dp_audio_timestamp_sdp(struct
dp_audio_private *audio)
DP_AUDIO_SDP_TIMESTAMP, DP_AUDIO_SDP_HEADER_2);
new_value = 0x17;
- parity_byte = dp_audio_calculate_parity(new_value);
+ parity_byte = dp_catalog_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_2_BIT)
| (parity_byte << PARITY_BYTE_2_BIT));
drm_dbg_dp(audio->drm_dev,
@@ -212,7 +140,7 @@ static void dp_audio_timestamp_sdp(struct
dp_audio_private *audio)
DP_AUDIO_SDP
Re: [PATCH 08/17] drm/msm/dp: change YUV420 related programming for DP
On 1/25/2024 1:29 PM, Dmitry Baryshkov wrote:
On 25/01/2024 21:38, Paloma Arellano wrote:
Change all relevant DP controller related programming for YUV420 cases.
Namely, change the pixel clock math to consider YUV420, program the
configuration control to indicate YUV420, as well as modify the MVID
programming to consider YUV420.
Too many items for a single commit.
Ack. In the next series, I'll keep the clock math and MVID related code
in one patch. And configuration control code in another.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 5 -
drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c | 12 +---
drivers/gpu/drm/msm/dp/dp_display.c | 8 +++-
drivers/gpu/drm/msm/msm_kms.h | 3 +++
5 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 5142aeb705a44..5d84c089e520a 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -442,7 +442,7 @@ void dp_catalog_ctrl_config_misc(struct
dp_catalog *dp_catalog,
void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog,
u32 rate, u32 stream_rate_khz,
- bool fixed_nvid)
+ bool fixed_nvid, bool is_ycbcr_420)
{
u32 pixel_m, pixel_n;
u32 mvid, nvid, pixel_div = 0, dispcc_input_rate;
@@ -485,6 +485,9 @@ void dp_catalog_ctrl_config_msa(struct dp_catalog
*dp_catalog,
nvid = temp;
}
+ if (is_ycbcr_420)
+ mvid /= 2;
+
if (link_rate_hbr2 == rate)
nvid *= 2;
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 38786e855b51a..6cb5e2a243de2 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -96,7 +96,7 @@ void dp_catalog_ctrl_mainlink_ctrl(struct
dp_catalog *dp_catalog, bool enable);
void dp_catalog_ctrl_psr_mainlink_enable(struct dp_catalog
*dp_catalog, bool enable);
void dp_catalog_ctrl_config_misc(struct dp_catalog *dp_catalog, u32
cc, u32 tb);
void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog, u32
rate,
- u32 stream_rate_khz, bool fixed_nvid);
+ u32 stream_rate_khz, bool fixed_nvid, bool
is_ycbcr_420);
int dp_catalog_ctrl_set_pattern_state_bit(struct dp_catalog
*dp_catalog, u32 pattern);
u32 dp_catalog_hw_revision(const struct dp_catalog *dp_catalog);
void dp_catalog_ctrl_reset(struct dp_catalog *dp_catalog);
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 77a8d9366ed7b..209cf2a35642f 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -128,6 +128,9 @@ static void dp_ctrl_config_ctrl(struct
dp_ctrl_private *ctrl)
/* Default-> LSCLK DIV: 1/4 LCLK */
config |= (2 << DP_CONFIGURATION_CTRL_LSCLK_DIV_SHIFT);
+ if (ctrl->panel->dp_mode.out_fmt_is_yuv_420)
+ config |= DP_CONFIGURATION_CTRL_RGB_YUV; /* YUV420 */
+
This definitely is not related to clock rate calculations.
This is related to the configuration control register.
/* Scrambler reset enable */
if (drm_dp_alternate_scrambler_reset_cap(dpcd))
config |= DP_CONFIGURATION_CTRL_ASSR;
@@ -957,7 +960,7 @@ static void dp_ctrl_calc_tu_parameters(struct
dp_ctrl_private *ctrl,
in.hporch = drm_mode->htotal - drm_mode->hdisplay;
in.nlanes = ctrl->link->link_params.num_lanes;
in.bpp = ctrl->panel->dp_mode.bpp;
- in.pixel_enc = 444;
+ in.pixel_enc = ctrl->panel->dp_mode.out_fmt_is_yuv_420 ? 420 : 444;
in.dsc_en = 0;
in.async_en = 0;
in.fec_en = 0;
@@ -1763,6 +1766,8 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
ctrl->link->link_params.rate = rate;
ctrl->link->link_params.num_lanes =
ctrl->panel->link_info.num_lanes;
+ if (ctrl->panel->dp_mode.out_fmt_is_yuv_420)
+ pixel_rate >>= 1;
}
drm_dbg_dp(ctrl->drm_dev, "rate=%d, num_lanes=%d,
pixel_rate=%lu\n",
@@ -1878,7 +1883,7 @@ int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl,
bool force_link_train)
pixel_rate = pixel_rate_orig =
ctrl->panel->dp_mode.drm_mode.clock;
- if (dp_ctrl->wide_bus_en)
+ if (dp_ctrl->wide_bus_en ||
ctrl->panel->dp_mode.out_fmt_is_yuv_420)
pixel_rate >>= 1;
drm_dbg_dp(ctrl->drm_dev, "rate=%d, num_lanes=%d,
pixel_rate=%lu\n",
@@ -1917,7 +1922,8 @@ int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl,
bool force_link_train)
dp_catalog_ctrl_config_msa(ctrl->catalog,
ctrl->link->link_params.rate,
- pixel_rate_orig, dp_ctrl_use_fixed_nvid(ctrl));
+ pixel_rate_orig, dp_ctrl_use_fixed_nvid(ctrl),
+ ctrl->panel->dp_mode.out_fmt_is_yuv_420);
dp_ctrl_setup_tr_unit(ctrl);
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
i
Re: [PATCH 07/17] drm/msm/dpu: disallow widebus en in INTF_CONFIG2 when DP is YUV420
On 1/25/2024 1:26 PM, Dmitry Baryshkov wrote: On 25/01/2024 21:38, Paloma Arellano wrote: INTF_CONFIG2 register cannot have widebus enabled when DP format is YUV420. Therefore, program the INTF to send 1 ppc. I think this is handled in the DP driver, where we disallow wide bus for YUV 4:2:0 modes. Yes we do disallow wide bus for YUV420 modes, but we still need to program the INTF_CFG2_DATA_HCTL_EN. Therefore, it is necessary to add this check. Signed-off-by: Paloma Arellano --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c index 6bba531d6dc41..bfb93f02fe7c1 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c @@ -168,7 +168,9 @@ static void dpu_hw_intf_setup_timing_engine(struct dpu_hw_intf *ctx, * video timing. It is recommended to enable it for all cases, except * if compression is enabled in 1 pixel per clock mode */ - if (p->wide_bus_en) + if (dp_intf && fmt->base.pixel_format == DRM_FORMAT_YUV420) + intf_cfg2 |= INTF_CFG2_DATA_HCTL_EN; + else if (p->wide_bus_en) intf_cfg2 |= INTF_CFG2_DATABUS_WIDEN | INTF_CFG2_DATA_HCTL_EN; data_width = p->width;
Re: [PATCH 10/17] drm/msm/dp: modify dp_catalog_hw_revision to show major and minor val
Hi Paloma,
kernel test robot noticed the following build warnings:
[auto build test WARNING on v6.8-rc1]
[also build test WARNING on linus/master next-20240125]
[cannot apply to drm-misc/drm-misc-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Paloma-Arellano/drm-msm-dpu-allow-dpu_encoder_helper_phys_setup_cdm-to-work-for-DP/20240126-034233
base: v6.8-rc1
patch link:
https://lore.kernel.org/r/20240125193834.7065-11-quic_parellan%40quicinc.com
patch subject: [PATCH 10/17] drm/msm/dp: modify dp_catalog_hw_revision to show
major and minor val
config: arm64-defconfig
(https://download.01.org/0day-ci/archive/20240128/202401280752.amrdi7ox-...@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240128/202401280752.amrdi7ox-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202401280752.amrdi7ox-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/msm/dp/dp_catalog.c:541: warning: Function parameter or
>> struct member 'major' not described in 'dp_catalog_hw_revision'
>> drivers/gpu/drm/msm/dp/dp_catalog.c:541: warning: Function parameter or
>> struct member 'minor' not described in 'dp_catalog_hw_revision'
vim +541 drivers/gpu/drm/msm/dp/dp_catalog.c
c943b4948b5848 Chandan Uddaraju 2020-08-27 531
757a2f36ab095f Kuogee Hsieh 2022-02-25 532 /**
757a2f36ab095f Kuogee Hsieh 2022-02-25 533 * dp_catalog_hw_revision() -
retrieve DP hw revision
757a2f36ab095f Kuogee Hsieh 2022-02-25 534 *
757a2f36ab095f Kuogee Hsieh 2022-02-25 535 * @dp_catalog: DP catalog
structure
757a2f36ab095f Kuogee Hsieh 2022-02-25 536 *
5febc52d5716d6 Paloma Arellano 2024-01-25 537 * Return: void
757a2f36ab095f Kuogee Hsieh 2022-02-25 538 *
757a2f36ab095f Kuogee Hsieh 2022-02-25 539 */
5febc52d5716d6 Paloma Arellano 2024-01-25 540 void
dp_catalog_hw_revision(const struct dp_catalog *dp_catalog, u16 *major, u16
*minor)
757a2f36ab095f Kuogee Hsieh 2022-02-25 @541 {
757a2f36ab095f Kuogee Hsieh 2022-02-25 542 const struct
dp_catalog_private *catalog = container_of(dp_catalog,
757a2f36ab095f Kuogee Hsieh 2022-02-25 543
struct dp_catalog_private, dp_catalog);
5febc52d5716d6 Paloma Arellano 2024-01-25 544 u32 reg_dp_hw_version;
757a2f36ab095f Kuogee Hsieh 2022-02-25 545
5febc52d5716d6 Paloma Arellano 2024-01-25 546 reg_dp_hw_version =
dp_read_ahb(catalog, REG_DP_HW_VERSION);
5febc52d5716d6 Paloma Arellano 2024-01-25 547 *major =
DP_HW_VERSION_MAJOR(reg_dp_hw_version);
5febc52d5716d6 Paloma Arellano 2024-01-25 548 *minor =
DP_HW_VERSION_MINOR(reg_dp_hw_version);
757a2f36ab095f Kuogee Hsieh 2022-02-25 549 }
757a2f36ab095f Kuogee Hsieh 2022-02-25 550
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Patch "drm: Fix TODO list mentioning non-KMS drivers" has been added to the 6.6-stable tree
This is a note to let you know that I've just added the patch titled
drm: Fix TODO list mentioning non-KMS drivers
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-fix-todo-list-mentioning-non-kms-drivers.patch
and it can be found in the queue-6.6 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 9cf5ca1f485cae406968947a92bf304603999fa1 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Wed, 22 Nov 2023 13:09:31 +0100
Subject: drm: Fix TODO list mentioning non-KMS drivers
From: Thomas Zimmermann
commit 9cf5ca1f485cae406968947a92bf304603999fa1 upstream.
Non-KMS drivers have been removed from DRM. Update the TODO list
accordingly.
Signed-off-by: Thomas Zimmermann
Fixes: a276afc19eec ("drm: Remove some obsolete drm pciids(tdfx, mga, i810,
savage, r128, sis, via)")
Cc: Cai Huoqing
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Thomas Zimmermann
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jonathan Corbet
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.3+
Cc: linux-...@vger.kernel.org
Reviewed-by: David Airlie
Reviewed-by: Daniel Vetter
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20231122122449.11588-3-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
Documentation/gpu/todo.rst | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 503d57c75215..41a264bf84ce 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -337,8 +337,8 @@ connector register/unregister fixes
Level: Intermediate
-Remove load/unload callbacks from all non-DRIVER_LEGACY drivers
+Remove load/unload callbacks
+
The load/unload callbacks in struct &drm_driver are very much midlayers, plus
for historical reasons they get the ordering wrong (and we can't fix that)
@@ -347,8 +347,7 @@ between setting up the &drm_driver structure and calling
drm_dev_register().
- Rework drivers to no longer use the load/unload callbacks, directly coding
the
load/unload sequence into the driver's probe function.
-- Once all non-DRIVER_LEGACY drivers are converted, disallow the load/unload
- callbacks for all modern drivers.
+- Once all drivers are converted, remove the load/unload callbacks.
Contact: Daniel Vetter
--
2.43.0
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-6.6/sh-ecovec24-rename-missed-backlight-field-from-fbdev.patch
queue-6.6/drm-disable-the-cursor-plane-on-atomic-contexts-with-virtualized-drivers.patch
queue-6.6/drm-fix-todo-list-mentioning-non-kms-drivers.patch
queue-6.6/revert-drivers-firmware-move-sysfb_init-from-device_initcall-to-subsys_initcall_sync.patch
queue-6.6/drm-allow-drivers-to-indicate-the-damage-helpers-to-ignore-damage-clips.patch
queue-6.6/drm-virtio-disable-damage-clipping-if-fb-changed-since-last-page-flip.patch
Patch "drm: Fix TODO list mentioning non-KMS drivers" has been added to the 6.7-stable tree
This is a note to let you know that I've just added the patch titled
drm: Fix TODO list mentioning non-KMS drivers
to the 6.7-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-fix-todo-list-mentioning-non-kms-drivers.patch
and it can be found in the queue-6.7 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 9cf5ca1f485cae406968947a92bf304603999fa1 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Wed, 22 Nov 2023 13:09:31 +0100
Subject: drm: Fix TODO list mentioning non-KMS drivers
From: Thomas Zimmermann
commit 9cf5ca1f485cae406968947a92bf304603999fa1 upstream.
Non-KMS drivers have been removed from DRM. Update the TODO list
accordingly.
Signed-off-by: Thomas Zimmermann
Fixes: a276afc19eec ("drm: Remove some obsolete drm pciids(tdfx, mga, i810,
savage, r128, sis, via)")
Cc: Cai Huoqing
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Thomas Zimmermann
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jonathan Corbet
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.3+
Cc: linux-...@vger.kernel.org
Reviewed-by: David Airlie
Reviewed-by: Daniel Vetter
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20231122122449.11588-3-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
Documentation/gpu/todo.rst |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -337,8 +337,8 @@ connector register/unregister fixes
Level: Intermediate
-Remove load/unload callbacks from all non-DRIVER_LEGACY drivers
+Remove load/unload callbacks
+
The load/unload callbacks in struct &drm_driver are very much midlayers, plus
for historical reasons they get the ordering wrong (and we can't fix that)
@@ -347,8 +347,7 @@ between setting up the &drm_driver struc
- Rework drivers to no longer use the load/unload callbacks, directly coding
the
load/unload sequence into the driver's probe function.
-- Once all non-DRIVER_LEGACY drivers are converted, disallow the load/unload
- callbacks for all modern drivers.
+- Once all drivers are converted, remove the load/unload callbacks.
Contact: Daniel Vetter
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-6.7/sh-ecovec24-rename-missed-backlight-field-from-fbdev.patch
queue-6.7/drm-disable-the-cursor-plane-on-atomic-contexts-with-virtualized-drivers.patch
queue-6.7/drm-fix-todo-list-mentioning-non-kms-drivers.patch
queue-6.7/revert-drivers-firmware-move-sysfb_init-from-device_initcall-to-subsys_initcall_sync.patch
queue-6.7/drm-allow-drivers-to-indicate-the-damage-helpers-to-ignore-damage-clips.patch
queue-6.7/drm-virtio-disable-damage-clipping-if-fb-changed-since-last-page-flip.patch
Patch "drm: Disable the cursor plane on atomic contexts with virtualized drivers" has been added to the 6.7-stable tree
This is a note to let you know that I've just added the patch titled
drm: Disable the cursor plane on atomic contexts with virtualized drivers
to the 6.7-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-disable-the-cursor-plane-on-atomic-contexts-with-virtualized-drivers.patch
and it can be found in the queue-6.7 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 4e3b70da64a53784683cfcbac2deda5d6e540407 Mon Sep 17 00:00:00 2001
From: Zack Rusin
Date: Mon, 23 Oct 2023 09:46:05 +0200
Subject: drm: Disable the cursor plane on atomic contexts with virtualized
drivers
From: Zack Rusin
commit 4e3b70da64a53784683cfcbac2deda5d6e540407 upstream.
Cursor planes on virtualized drivers have special meaning and require
that the clients handle them in specific ways, e.g. the cursor plane
should react to the mouse movement the way a mouse cursor would be
expected to and the client is required to set hotspot properties on it
in order for the mouse events to be routed correctly.
This breaks the contract as specified by the "universal planes". Fix it
by disabling the cursor planes on virtualized drivers while adding
a foundation on top of which it's possible to special case mouse cursor
planes for clients that want it.
Disabling the cursor planes makes some kms compositors which were broken,
e.g. Weston, fallback to software cursor which works fine or at least
better than currently while having no effect on others, e.g. gnome-shell
or kwin, which put virtualized drivers on a deny-list when running in
atomic context to make them fallback to legacy kms and avoid this issue.
Signed-off-by: Zack Rusin
Fixes: 681e7ec73044 ("drm: Allow userspace to ask for universal plane list
(v2)")
Cc: # v5.4+
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Hans de Goede
Cc: Gurchetan Singh
Cc: Chia-I Wu
Cc: dri-devel@lists.freedesktop.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
Acked-by: Pekka Paalanen
Reviewed-by: Javier Martinez Canillas
Acked-by: Simon Ser
Signed-off-by: Javier Martinez Canillas
Link:
https://patchwork.freedesktop.org/patch/msgid/20231023074613.41327-2-aest...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_plane.c | 13 +
drivers/gpu/drm/qxl/qxl_drv.c|2 +-
drivers/gpu/drm/vboxvideo/vbox_drv.c |2 +-
drivers/gpu/drm/virtio/virtgpu_drv.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |2 +-
include/drm/drm_drv.h|9 +
include/drm/drm_file.h | 12
7 files changed, 38 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -678,6 +678,19 @@ int drm_mode_getplane_res(struct drm_dev
!file_priv->universal_planes)
continue;
+ /*
+* If we're running on a virtualized driver then,
+* unless userspace advertizes support for the
+* virtualized cursor plane, disable cursor planes
+* because they'll be broken due to missing cursor
+* hotspot info.
+*/
+ if (plane->type == DRM_PLANE_TYPE_CURSOR &&
+ drm_core_check_feature(dev, DRIVER_CURSOR_HOTSPOT) &&
+ file_priv->atomic &&
+ !file_priv->supports_virtualized_cursor_plane)
+ continue;
+
if (drm_lease_held(file_priv, plane->base.id)) {
if (count < plane_resp->count_planes &&
put_user(plane->base.id, plane_ptr + count))
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -285,7 +285,7 @@ static const struct drm_ioctl_desc qxl_i
};
static struct drm_driver qxl_driver = {
- .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
+ .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
DRIVER_CURSOR_HOTSPOT,
.dumb_create = qxl_mode_dumb_create,
.dumb_map_offset = drm_gem_ttm_dumb_map_offset,
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -182,7 +182,7 @@ DEFINE_DRM_GEM_FOPS(vbox_fops);
static const struct drm_driver driver = {
.driver_features =
- DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
+ DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC | DRIVER_CURSOR_HOTSPOT,
.fops = &vbox_fops,
.name = DRIVER_NAME,
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -177,7 +177,7 @@ static const struct drm_driver driver =
* out via drm_device::driver_features:
*/
.
Patch "drm: Disable the cursor plane on atomic contexts with virtualized drivers" has been added to the 6.6-stable tree
This is a note to let you know that I've just added the patch titled
drm: Disable the cursor plane on atomic contexts with virtualized drivers
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-disable-the-cursor-plane-on-atomic-contexts-with-virtualized-drivers.patch
and it can be found in the queue-6.6 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 4e3b70da64a53784683cfcbac2deda5d6e540407 Mon Sep 17 00:00:00 2001
From: Zack Rusin
Date: Mon, 23 Oct 2023 09:46:05 +0200
Subject: drm: Disable the cursor plane on atomic contexts with virtualized
drivers
From: Zack Rusin
commit 4e3b70da64a53784683cfcbac2deda5d6e540407 upstream.
Cursor planes on virtualized drivers have special meaning and require
that the clients handle them in specific ways, e.g. the cursor plane
should react to the mouse movement the way a mouse cursor would be
expected to and the client is required to set hotspot properties on it
in order for the mouse events to be routed correctly.
This breaks the contract as specified by the "universal planes". Fix it
by disabling the cursor planes on virtualized drivers while adding
a foundation on top of which it's possible to special case mouse cursor
planes for clients that want it.
Disabling the cursor planes makes some kms compositors which were broken,
e.g. Weston, fallback to software cursor which works fine or at least
better than currently while having no effect on others, e.g. gnome-shell
or kwin, which put virtualized drivers on a deny-list when running in
atomic context to make them fallback to legacy kms and avoid this issue.
Signed-off-by: Zack Rusin
Fixes: 681e7ec73044 ("drm: Allow userspace to ask for universal plane list
(v2)")
Cc: # v5.4+
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Hans de Goede
Cc: Gurchetan Singh
Cc: Chia-I Wu
Cc: dri-devel@lists.freedesktop.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
Acked-by: Pekka Paalanen
Reviewed-by: Javier Martinez Canillas
Acked-by: Simon Ser
Signed-off-by: Javier Martinez Canillas
Link:
https://patchwork.freedesktop.org/patch/msgid/20231023074613.41327-2-aest...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_plane.c | 13 +
drivers/gpu/drm/qxl/qxl_drv.c|2 +-
drivers/gpu/drm/vboxvideo/vbox_drv.c |2 +-
drivers/gpu/drm/virtio/virtgpu_drv.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |2 +-
include/drm/drm_drv.h|9 +
include/drm/drm_file.h | 12
7 files changed, 38 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -678,6 +678,19 @@ int drm_mode_getplane_res(struct drm_dev
!file_priv->universal_planes)
continue;
+ /*
+* If we're running on a virtualized driver then,
+* unless userspace advertizes support for the
+* virtualized cursor plane, disable cursor planes
+* because they'll be broken due to missing cursor
+* hotspot info.
+*/
+ if (plane->type == DRM_PLANE_TYPE_CURSOR &&
+ drm_core_check_feature(dev, DRIVER_CURSOR_HOTSPOT) &&
+ file_priv->atomic &&
+ !file_priv->supports_virtualized_cursor_plane)
+ continue;
+
if (drm_lease_held(file_priv, plane->base.id)) {
if (count < plane_resp->count_planes &&
put_user(plane->base.id, plane_ptr + count))
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -283,7 +283,7 @@ static const struct drm_ioctl_desc qxl_i
};
static struct drm_driver qxl_driver = {
- .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
+ .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
DRIVER_CURSOR_HOTSPOT,
.dumb_create = qxl_mode_dumb_create,
.dumb_map_offset = drm_gem_ttm_dumb_map_offset,
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -182,7 +182,7 @@ DEFINE_DRM_GEM_FOPS(vbox_fops);
static const struct drm_driver driver = {
.driver_features =
- DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
+ DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC | DRIVER_CURSOR_HOTSPOT,
.fops = &vbox_fops,
.name = DRIVER_NAME,
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -177,7 +177,7 @@ static const struct drm_driver driver =
* out via drm_device::driver_features:
*/
.
Re: [PATCH v4 4/4] arm64: dts: rockchip: Add devicetree for Pine64 PineTab2
Hello Manuel,
thank you for the changes, and finding time to post this.
On Sat, Jan 27, 2024 at 10:48:45AM +0100, Manuel Traut wrote:
> This includes support for both the v0.1 units that were sent to developers and
> the v2.0 units from production.
>
> v1.0 is not included as no units are known to exist.
>
> Working/Tested:
> - SDMMC
> - UART
> - Buttons
> - Charging/Battery/PMIC
> - Audio
> - USB
> - Display
> - SPI NOR Flash
>
> Signed-off-by: Alexander Warnecke
> Signed-off-by: Manuel Traut
Reviewed-by: Ondrej Jirman
Tested-by: Ondrej Jirman
kind regards,
o.
> ---
> arch/arm64/boot/dts/rockchip/Makefile | 2 +
> .../boot/dts/rockchip/rk3566-pinetab2-v0.1.dts | 28 +
> .../boot/dts/rockchip/rk3566-pinetab2-v2.0.dts | 48 ++
> arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi | 943
> +
> 4 files changed, 1021 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> b/arch/arm64/boot/dts/rockchip/Makefile
> index a7b30e11beaf..ac0c72667bb7 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -78,6 +78,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg353vs.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg503.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.1.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.2.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v0.1.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v2.0.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rgb30.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rk2023.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-x55.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
> b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
> new file mode 100644
> index ..5fe6ca5da9d3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
> @@ -0,0 +1,28 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include "rk3566-pinetab2.dtsi"
> +
> +/ {
> + model = "Pine64 PineTab2 v0.1";
> + compatible = "pine64,pinetab2-v0.1", "pine64,pinetab2",
> "rockchip,rk3566";
> +};
> +
> +&lcd {
> + reset-gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_pwren_h &lcd0_rst_l>;
> +};
> +
> +&pinctrl {
> + lcd0 {
> + lcd0_rst_l: lcd0-rst-l {
> + rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +};
> +
> +&sdmmc1 {
> + vmmc-supply = <&vcc3v3_sys>;
> +};
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
> b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
> new file mode 100644
> index ..9349541cbbd0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
> @@ -0,0 +1,48 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include "rk3566-pinetab2.dtsi"
> +
> +/ {
> + model = "Pine64 PineTab2 v2.0";
> + compatible = "pine64,pinetab2-v2.0", "pine64,pinetab2",
> "rockchip,rk3566";
> +};
> +
> +&gpio_keys {
> + pinctrl-0 = <&kb_id_det>, <&hall_int_l>;
> +
> + event-hall-sensor {
> + debounce-interval = <20>;
> + gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
> + label = "Hall Sensor";
> + linux,code = ;
> + linux,input-type = ;
> + wakeup-event-action = ;
> + wakeup-source;
> + };
> +};
> +
> +&lcd {
> + reset-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_pwren_h &lcd0_rst_l>;
> +};
> +
> +&pinctrl {
> + lcd0 {
> + lcd0_rst_l: lcd0-rst-l {
> + rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + hall {
> + hall_int_l: hall-int-l {
> + rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +};
> +
> +&sdmmc1 {
> + vmmc-supply = <&vcc_sys>;
> +};
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> new file mode 100644
> index ..db40281eafbe
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> @@ -0,0 +1,943 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "rk3566.dtsi"
> +
> +/ {
> + chassis-type = "tablet";
> +
> + aliases {
> + mmc0 = &sdhci;
> + mmc1 = &sdmmc0;
> + };
> +
> + chosen {
> + stdout-path = "serial2:150n8";
> + };
> +
> + adc-keys {
> + compatible = "adc-keys";
> + io-channels = <&saradc 0>;
> + io-channel-names = "buttons";
> + keyup-threshold-microvolt = <1
Re: [GIT PULL] Enable -Wstringop-overflow globally
On 1/27/24 09:11, David Laight wrote: From: Linus Torvalds Sent: 26 January 2024 22:36 On Fri, 26 Jan 2024 at 14:24, Kees Cook wrote: I think xe has some other weird problems too. This may be related (under allocating): ../drivers/gpu/drm/xe/xe_vm.c: In function 'xe_vma_create': ../drivers/gpu/drm/xe/xe_vm.c:806:21: warning: allocation of insufficient size '224' for type 'struct xe_vma' with size '368' [-Walloc-size] 806 | vma = kzalloc(sizeof(*vma) - sizeof(struct xe_userptr), | ^ That code is indeed odd, but there's a comment in the xe_vma definition /** * @userptr: user pointer state, only allocated for VMAs that are * user pointers */ struct xe_userptr userptr; although I agree that it should probably simply be made a final variably-sized array instead (and then you make that array size be 0/1). That entire code is odd. It isn't obvious that the flag values that cause the short allocate are the same ones that control whether the extra data is accessed. Never mind the oddities with the 'flags |= ' assignments int the 'remap next' path. Anyone know how many of these actually get allocated (and their lifetimes)? How much difference would it make to allocate 368 (maybe 384?) bytes instead of 224 (likely 256). [CC+ xen list and maintainers] Probably the xen maintainer can help us out here. -- Gustavo David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors
I've applied the patch to 6.7.2. The device then shows up under:
|/sys/devices/pci:00/:00:08.1/:c1:00.0/drm/card1/card1-eDP-1/amdgpu/panel_power_savings|
|||(on Framework Laptop 13 amd 7840U with 780M).|
||
After a few tests i can say that at least in my system it’s not working.
Setting a value between 0 and 4 in /sys/.../panel_power_savings changes
nothing in the panel behavior. There are no errors in kernel log.
Setting an abmlevel via kernel option still works as intended.
||An other investigation is, that when setting abmlevel=0 via kernel
option the value shown in /sys/.../panel_power_savings is 255 instead of
0. For abmleve values 1 to 4 set via kernel option the values shown in
/sys/.../panel_power_savings are the same.
||
Am 26.01.24 um 23:22 schrieb Hamza Mahfooz:
We want programs besides the compositor to be able to enable or disable
panel power saving features. However, since they are currently only
configurable through DRM properties, that isn't possible. So, to remedy
that issue introduce a new "panel_power_savings" sysfs attribute.
Cc: Mario Limonciello
Signed-off-by: Hamza Mahfooz
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 59 +++
1 file changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index cd98b3565178..b3fcd833015d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6534,6 +6534,58 @@ amdgpu_dm_connector_atomic_duplicate_state(struct
drm_connector *connector)
return &new_state->base;
}
+static ssize_t panel_power_savings_show(struct device *device,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct drm_connector *connector = dev_get_drvdata(device);
+ struct drm_device *dev = connector->dev;
+ ssize_t val;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+ val = to_dm_connector_state(connector->state)->abm_level;
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ return sysfs_emit(buf, "%lu\n", val);
+}
+
+static ssize_t panel_power_savings_store(struct device *device,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct drm_connector *connector = dev_get_drvdata(device);
+ struct drm_device *dev = connector->dev;
+ long val;
+ int ret;
+
+ ret = kstrtol(buf, 0, &val);
+
+ if (ret)
+ return ret;
+
+ if (val < 0 || val > 4)
+ return -EINVAL;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+ to_dm_connector_state(connector->state)->abm_level = val ?:
+ ABM_LEVEL_IMMEDIATE_DISABLE;
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ return count;
+}
+
+static DEVICE_ATTR_RW(panel_power_savings);
+
+static struct attribute *amdgpu_attrs[] = {
+ &dev_attr_panel_power_savings.attr,
+ NULL
+};
+
+static const struct attribute_group amdgpu_group = {
+ .name = "amdgpu",
+ .attrs = amdgpu_attrs
+};
+
static int
amdgpu_dm_connector_late_register(struct drm_connector *connector)
{
@@ -6541,6 +6593,13 @@ amdgpu_dm_connector_late_register(struct drm_connector
*connector)
to_amdgpu_dm_connector(connector);
int r;
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ r = sysfs_create_group(&connector->kdev->kobj,
+ &amdgpu_group);
+ if (r)
+ return r;
+ }
+
amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||
--
Dominik Förderer (Netzwerkadministrator)
Windeck-Gymnasium Bühl
Humboldtstr. 3
Tel. 07223/9409585
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [PATCH v5 5/8] iio: core: Add new DMABUF interface infrastructure
> > > + iio_buffer_dmabuf_put(attach); > > > + > > > +out_dmabuf_put: > > > + dma_buf_put(dmabuf); > > As below. Feels like a __free(dma_buf_put) bit of magic would be a > > nice to have. > > I'm working on the patches right now, just one quick question. > > Having a __free(dma_buf_put) requires that dma_buf_put is first > "registered" as a freeing function using DEFINE_FREE() in buf.h>, which has not been done yet. > > That would mean carrying a dma-buf specific patch in your tree, are you > OK with that? Needs an ACK from appropriate maintainer, but otherwise I'm fine doing so. Alternative is to circle back to this later after this code is upstream. > > Cheers, > -Paul >
Re: [drm-drm-misc:drm-misc-next] dt-bindings: nt35510: document 'port' property
On Sat, Jan 27, 2024 at 5:28 PM Rob Herring wrote: > dtschema/dtc warnings/errors: > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/novatek,nt35510.example.dtb: > panel@0: compatible:0: 'hydis,hva40wv1' was expected > from schema $id: > http://devicetree.org/schemas/display/panel/novatek,nt35510.yaml# This is because the checker is applying the patch on something that is not drm-misc-next. I think the patch is fine. Yours, Linus Walleij
Re: [drm-drm-misc:drm-misc-next] dt-bindings: nt35510: document 'port' property
On Sat, 27 Jan 2024 16:28:08 +0100, Dario Binacchi wrote: > Allow 'port' property (coming from panel-common.yaml) to be used in DTS: > > st/stm32f769-disco-mb1166-reva09.dtb: panel@0: 'port' does not match any of > the regexes: 'pinctrl-[0-9]+' > > Signed-off-by: Dario Binacchi > Cc: Alexandre Torgue > > --- > > .../display/panel/novatek,nt35510.yaml| 34 +++ > 1 file changed, 34 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/novatek,nt35510.example.dtb: panel@0: compatible:0: 'hydis,hva40wv1' was expected from schema $id: http://devicetree.org/schemas/display/panel/novatek,nt35510.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240127152821.65744-1-dario.binac...@amarulasolutions.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
RE: Re: Re: [PATCH 3/5] drm/ttm: replace busy placement with flags v6
Hi Lucas,
I encountered this build issue as well. I submitted a fix for drm-tip.
Oak
> -Original Message-
> From: dri-devel On Behalf Of Lucas
> De Marchi
> Sent: Friday, January 26, 2024 5:23 PM
> To: Thomas Hellström
> Cc: kher...@redhat.com; michel.daen...@mailbox.org;
> nouv...@lists.freedesktop.org; intel-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; Christian König
> ; za...@vmware.com
> Subject: Re: Re: Re: [PATCH 3/5] drm/ttm: replace busy placement with flags v6
>
> On Fri, Jan 26, 2024 at 04:16:58PM -0600, Lucas De Marchi wrote:
> >On Thu, Jan 18, 2024 at 05:38:16PM +0100, Thomas Hellström wrote:
> >>
> >>On 1/17/24 13:27, Thomas Hellström wrote:
> >>>
> >>>On 1/17/24 11:47, Thomas Hellström wrote:
> Hi, Christian
>
> Xe changes look good. Will send the series to xe ci to check for
> regressions.
> >>>
> >>>Hmm, there are some checkpatch warnings about author / SOB email
> >>>mismatch,
> >>
> >>With those fixed, this patch is
> >>
> >>Reviewed-by: Thomas Hellström
> >
> >
> >it actually broke drm-tip now that this is merged:
> >
> >../drivers/gpu/drm/xe/xe_bo.c:41:10: error: ‘struct ttm_placement’ has no
> member named ‘num_busy_placement’; did you mean ‘num_placement’
> > 41 | .num_busy_placement = 1,
> > | ^~
> > | num_placement
> >../drivers/gpu/drm/xe/xe_bo.c:41:31: error: excess elements in struct
> >initializer
> [-Werror]
> > 41 | .num_busy_placement = 1,
> > | ^
> >
> >
> >Apparently a conflict with another patch that got applied a few days
> >ago: a201c6ee37d6 ("drm/xe/bo: Evict VRAM to TT rather than to system")
>
> oh, no... apparently that commit is from a long time ago. The problem
> was that drm-misc-next was not yet in sync with drm-next. Thomas, do you
> have a fixup for this to put in rerere?
>
> Lucas De Marchi
[PATCH] drm/xe: Fix a build error
This fixes a build failure on drm-tip. This issue was introduced during
merge of "drm/ttm: replace busy placement with flags v6". For some
reason, the xe_bo.c part of above change is not merged. Manually merge
the missing part to drm_tip
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/xe/xe_bo.c | 33 +++--
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index 686d716c5581..d6a193060cc0 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -38,22 +38,26 @@ static const struct ttm_place sys_placement_flags = {
static struct ttm_placement sys_placement = {
.num_placement = 1,
.placement = &sys_placement_flags,
- .num_busy_placement = 1,
- .busy_placement = &sys_placement_flags,
};
-static const struct ttm_place tt_placement_flags = {
- .fpfn = 0,
- .lpfn = 0,
- .mem_type = XE_PL_TT,
- .flags = 0,
+static const struct ttm_place tt_placement_flags[] = {
+ {
+ .fpfn = 0,
+ .lpfn = 0,
+ .mem_type = XE_PL_TT,
+ .flags = TTM_PL_FLAG_DESIRED,
+ },
+ {
+ .fpfn = 0,
+ .lpfn = 0,
+ .mem_type = XE_PL_SYSTEM,
+ .flags = TTM_PL_FLAG_FALLBACK,
+ }
};
static struct ttm_placement tt_placement = {
- .num_placement = 1,
- .placement = &tt_placement_flags,
- .num_busy_placement = 1,
- .busy_placement = &sys_placement_flags,
+ .num_placement = 2,
+ .placement = tt_placement_flags,
};
bool mem_type_is_vram(u32 mem_type)
@@ -230,8 +234,6 @@ static int __xe_bo_placement_for_flags(struct xe_device
*xe, struct xe_bo *bo,
bo->placement = (struct ttm_placement) {
.num_placement = c,
.placement = bo->placements,
- .num_busy_placement = c,
- .busy_placement = bo->placements,
};
return 0;
@@ -251,7 +253,6 @@ static void xe_evict_flags(struct ttm_buffer_object *tbo,
/* Don't handle scatter gather BOs */
if (tbo->type == ttm_bo_type_sg) {
placement->num_placement = 0;
- placement->num_busy_placement = 0;
return;
}
@@ -1391,8 +1392,6 @@ static int __xe_bo_fixed_placement(struct xe_device *xe,
bo->placement = (struct ttm_placement) {
.num_placement = 1,
.placement = place,
- .num_busy_placement = 1,
- .busy_placement = place,
};
return 0;
@@ -2150,9 +2149,7 @@ int xe_bo_migrate(struct xe_bo *bo, u32 mem_type)
xe_place_from_ttm_type(mem_type, &requested);
placement.num_placement = 1;
- placement.num_busy_placement = 1;
placement.placement = &requested;
- placement.busy_placement = &requested;
/*
* Stolen needs to be handled like below VRAM handling if we ever need
--
2.26.3
[drm-drm-misc:drm-misc-next] dt-bindings: nt35510: document 'port' property
Allow 'port' property (coming from panel-common.yaml) to be used in DTS:
st/stm32f769-disco-mb1166-reva09.dtb: panel@0: 'port' does not match any of
the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Dario Binacchi
Cc: Alexandre Torgue
---
.../display/panel/novatek,nt35510.yaml| 34 +++
1 file changed, 34 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
b/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
index a4afaff483b7..72913719df23 100644
--- a/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
@@ -31,6 +31,22 @@ properties:
vddi-supply:
description: regulator that supplies the vddi voltage
backlight: true
+ port:
+$ref: /schemas/graph.yaml#/properties/port
+
+if:
+ properties:
+compatible:
+ contains:
+enum:
+ - frida,frd400b25025
+then:
+ required:
+- port
+
+else:
+ properties:
+port: false
required:
- compatible
@@ -54,5 +70,23 @@ examples:
backlight = <&gpio_bl>;
};
};
+ - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "frida,frd400b25025", "novatek,nt35510";
+vddi-supply = <&vcc_3v3>;
+vdd-supply = <&vcc_3v3>;
+reg = <0>; /* dsi virtual channel (0..3) */
+reset-gpios = <&gpioj 15 GPIO_ACTIVE_LOW>;
+port {
+dsi_panel_in: endpoint {
+remote-endpoint = <&dsi_out>;
+};
+};
+};
+};
...
--
2.43.0
Re: Bug#1061449: linux-image-6.7-amd64: a boot message from amdgpu
Hi In Debian (https://bugs.debian.org/1061449) we got the following quotred report: On Wed, Jan 24, 2024 at 07:38:16PM +0100, Patrice Duroux wrote: > Package: src:linux > Version: 6.7.1-1~exp1 > Severity: normal > > Dear Maintainer, > > Giving a try to 6.7, here is a message extracted from dmesg: > > [4.177226] [ cut here ] > [4.177227] WARNING: CPU: 6 PID: 248 at > drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_factory.c:387 > construct_phy+0xb26/0xd60 [amdgpu] > [4.177658] Modules linked in: amdgpu(+) i915(+) sd_mod drm_exec amdxcp > gpu_sched drm_buddy nvme i2c_algo_bit drm_suballoc_helper drm_display_helper > ahci nvme_core hid_generic crc32_pclmul libahci crc32c_intel t10_pi cec libata > crc64_rocksoft_generic ghash_clmulni_intel rc_core drm_ttm_helper > crc64_rocksoft sha512_ssse3 i2c_hid_acpi ttm rtsx_pci_sdmmc i2c_hid xhci_pci > crc_t10dif sha512_generic mmc_core scsi_mod xhci_hcd drm_kms_helper video hid > crct10dif_generic intel_lpss_pci crct10dif_pclmul i2c_i801 sha256_ssse3 > intel_lpss crc64 thunderbolt drm e1000e usbcore sha1_ssse3 rtsx_pci i2c_smbus > scsi_common crct10dif_common idma64 usb_common battery wmi button aesni_intel > crypto_simd cryptd > [4.177689] CPU: 6 PID: 248 Comm: (udev-worker) Not tainted 6.7-amd64 #1 > Debian 6.7.1-1~exp1 > [4.177691] Hardware name: Dell Inc. Precision 7540/0T2FXT, BIOS 1.29.0 > 11/03/2023 > [4.177692] RIP: 0010:construct_phy+0xb26/0xd60 [amdgpu] > [4.178050] Code: b9 01 00 00 00 83 fe 01 74 40 48 8b 82 f8 03 00 00 89 f2 > 48 c7 c6 00 35 a7 c1 48 8b 40 10 48 8b 00 48 8b 78 08 e8 ba b7 5b fb <0f> 0b > 49 > 8b 87 d0 01 00 00 b9 0f 00 00 00 48 8b 80 e8 04 00 00 48 > [4.178052] RSP: 0018:aad300857408 EFLAGS: 00010246 > [4.178053] RAX: RBX: 96df636a1700 RCX: > c000efff > [4.178054] RDX: RSI: efff RDI: > 0001 > [4.178055] RBP: 96df4d379c00 R08: R09: > aad3008571d0 > [4.178056] R10: 0003 R11: bded2428 R12: > aad300857474 > [4.178057] R13: c1933140 R14: aad3008577d0 R15: > 96df43e82000 > [4.178058] FS: 7fcd5d9648c0() GS:96e2cc38() > knlGS: > [4.178060] CS: 0010 DS: ES: CR0: 80050033 > [4.178061] CR2: 7fcd5d932a6d CR3: 000103e9a004 CR4: > 003706f0 > [4.178062] DR0: DR1: DR2: > > [4.178063] DR3: DR6: fffe0ff0 DR7: > 0400 > [4.178063] Call Trace: > [4.178066] > [4.178067] ? construct_phy+0xb26/0xd60 [amdgpu] > [4.178422] ? __warn+0x81/0x130 > [4.178426] ? construct_phy+0xb26/0xd60 [amdgpu] > [4.178784] ? report_bug+0x171/0x1a0 > [4.178787] ? handle_bug+0x3c/0x80 > [4.178789] ? exc_invalid_op+0x17/0x70 > [4.178790] ? asm_exc_invalid_op+0x1a/0x20 > [4.178793] ? construct_phy+0xb26/0xd60 [amdgpu] > [4.179149] ? construct_phy+0xb26/0xd60 [amdgpu] > [4.179507] link_create+0x1b2/0x200 [amdgpu] > [4.179865] create_links+0x135/0x420 [amdgpu] > [4.180196] dc_create+0x321/0x640 [amdgpu] > [4.180529] amdgpu_dm_init.isra.0+0x2a0/0x1ed0 [amdgpu] > [4.180881] ? sysvec_apic_timer_interrupt+0xe/0x90 > [4.180883] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 > [4.180885] ? delay_tsc+0x37/0xa0 > [4.180889] dm_hw_init+0x12/0x30 [amdgpu] > [4.181240] amdgpu_device_init+0x1e42/0x24a0 [amdgpu] > [4.181517] amdgpu_driver_load_kms+0x19/0x190 [amdgpu] > [4.181793] amdgpu_pci_probe+0x165/0x4c0 [amdgpu] > [4.182067] local_pci_probe+0x42/0xa0 > [4.182070] pci_device_probe+0xc7/0x240 > [4.182072] really_probe+0x19b/0x3e0 > [4.182075] ? __pfx___driver_attach+0x10/0x10 > [4.182076] __driver_probe_device+0x78/0x160 > [4.182078] driver_probe_device+0x1f/0x90 > [4.182079] __driver_attach+0xd2/0x1c0 > [4.182081] bus_for_each_dev+0x85/0xd0 > [4.182083] bus_add_driver+0x116/0x220 > [4.182085] driver_register+0x59/0x100 > [4.182087] ? __pfx_amdgpu_init+0x10/0x10 [amdgpu] > [4.182356] do_one_initcall+0x58/0x320 > [4.182359] do_init_module+0x60/0x240 > [4.182361] init_module_from_file+0x89/0xe0 > [4.182364] idempotent_init_module+0x120/0x2b0 > [4.182366] __x64_sys_finit_module+0x5e/0xb0 > [4.182367] do_syscall_64+0x61/0x120 > [4.182370] ? do_syscall_64+0x70/0x120 > [4.182372] entry_SYSCALL_64_after_hwframe+0x6e/0x76 > [4.182375] RIP: 0033:0x7fcd5e130f19 > [4.182376] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 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 cf 1e 0d 00 f7 d8 64 89 01 48 > [4.182378] RSP: 002b:7ffd314afa38 EFLAGS: 0246 ORIG_RAX: > 0139 > [4.182379] RAX: ffda RBX:
Re: [PATCH v4 0/4] arm64: rockchip: Pine64 PineTab2 support
Hi Manuel, Since the BOE patches have been accepted to next, you do not need to include it in this patch series. Best regards, Dang On Saturday, January 27, 2024 4:48:41 PM +07 Manuel Traut wrote: > - BOE TH101MB31IG002 LCD Panel: > * Picked patches from https://anongit.freedesktop.org/git/drm/drm-misc.git > (drm-misc-next)
Re: [PATCH 5/5] drm/vmwgfx: Fix the lifetime of the bo cursor memory
On Fri, Jan 26, 2024 at 10:08 PM Zack Rusin wrote:
>
> The cleanup can be dispatched while the atomic update is still active,
> which means that the memory acquired in the atomic update needs to
> not be invalidated by the cleanup. The buffer objects in vmw_plane_state
> instead of using the builtin map_and_cache were trying to handle
> the lifetime of the mapped memory themselves, leading to crashes.
>
> Use the map_and_cache instead of trying to manage the lifetime of the
> buffer objects held by the vmw_plane_state.
>
> Fixes kernel oops'es in IGT's kms_cursor_legacy forked-bo.
>
> Signed-off-by: Zack Rusin
> Fixes: bb6780aa5a1d ("drm/vmwgfx: Diff cursors when using cmds")
> Cc: # v6.2+
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index e2bfaf4522a6..cd4925346ed4 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -185,13 +185,12 @@ static u32 vmw_du_cursor_mob_size(u32 w, u32 h)
> */
> static u32 *vmw_du_cursor_plane_acquire_image(struct vmw_plane_state *vps)
> {
> - bool is_iomem;
> if (vps->surf) {
> if (vps->surf_mapped)
> return
> vmw_bo_map_and_cache(vps->surf->res.guest_memory_bo);
> return vps->surf->snooper.image;
> } else if (vps->bo)
> - return ttm_kmap_obj_virtual(&vps->bo->map, &is_iomem);
> + return vmw_bo_map_and_cache(vps->bo);
> return NULL;
> }
>
> @@ -653,22 +652,12 @@ vmw_du_cursor_plane_cleanup_fb(struct drm_plane *plane,
> {
> struct vmw_cursor_plane *vcp = vmw_plane_to_vcp(plane);
> struct vmw_plane_state *vps = vmw_plane_state_to_vps(old_state);
> - bool is_iomem;
>
> if (vps->surf_mapped) {
> vmw_bo_unmap(vps->surf->res.guest_memory_bo);
> vps->surf_mapped = false;
> }
>
> - if (vps->bo && ttm_kmap_obj_virtual(&vps->bo->map, &is_iomem)) {
> - const int ret = ttm_bo_reserve(&vps->bo->tbo, true, false,
> NULL);
> -
> - if (likely(ret == 0)) {
> - ttm_bo_kunmap(&vps->bo->map);
> - ttm_bo_unreserve(&vps->bo->tbo);
> - }
> - }
> -
> vmw_du_cursor_plane_unmap_cm(vps);
> vmw_du_put_cursor_mob(vcp, vps);
>
> --
> 2.40.1
>
LGTM!
Reviewed-by: Martin Krastev
Regards,
Martin
[PATCH v4 4/4] arm64: dts: rockchip: Add devicetree for Pine64 PineTab2
This includes support for both the v0.1 units that were sent to developers and
the v2.0 units from production.
v1.0 is not included as no units are known to exist.
Working/Tested:
- SDMMC
- UART
- Buttons
- Charging/Battery/PMIC
- Audio
- USB
- Display
- SPI NOR Flash
Signed-off-by: Alexander Warnecke
Signed-off-by: Manuel Traut
---
arch/arm64/boot/dts/rockchip/Makefile | 2 +
.../boot/dts/rockchip/rk3566-pinetab2-v0.1.dts | 28 +
.../boot/dts/rockchip/rk3566-pinetab2-v2.0.dts | 48 ++
arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi | 943 +
4 files changed, 1021 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index a7b30e11beaf..ac0c72667bb7 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -78,6 +78,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg353vs.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg503.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.2.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v0.1.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v2.0.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rgb30.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rk2023.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-x55.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
new file mode 100644
index ..5fe6ca5da9d3
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3566-pinetab2.dtsi"
+
+/ {
+ model = "Pine64 PineTab2 v0.1";
+ compatible = "pine64,pinetab2-v0.1", "pine64,pinetab2",
"rockchip,rk3566";
+};
+
+&lcd {
+ reset-gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pwren_h &lcd0_rst_l>;
+};
+
+&pinctrl {
+ lcd0 {
+ lcd0_rst_l: lcd0-rst-l {
+ rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&sdmmc1 {
+ vmmc-supply = <&vcc3v3_sys>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
new file mode 100644
index ..9349541cbbd0
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3566-pinetab2.dtsi"
+
+/ {
+ model = "Pine64 PineTab2 v2.0";
+ compatible = "pine64,pinetab2-v2.0", "pine64,pinetab2",
"rockchip,rk3566";
+};
+
+&gpio_keys {
+ pinctrl-0 = <&kb_id_det>, <&hall_int_l>;
+
+ event-hall-sensor {
+ debounce-interval = <20>;
+ gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
+ label = "Hall Sensor";
+ linux,code = ;
+ linux,input-type = ;
+ wakeup-event-action = ;
+ wakeup-source;
+ };
+};
+
+&lcd {
+ reset-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pwren_h &lcd0_rst_l>;
+};
+
+&pinctrl {
+ lcd0 {
+ lcd0_rst_l: lcd0-rst-l {
+ rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ hall {
+ hall_int_l: hall-int-l {
+ rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&sdmmc1 {
+ vmmc-supply = <&vcc_sys>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
new file mode 100644
index ..db40281eafbe
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
@@ -0,0 +1,943 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "rk3566.dtsi"
+
+/ {
+ chassis-type = "tablet";
+
+ aliases {
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc0;
+ };
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+ poll-interval = <25>;
+
+ button-vol-up {
+ label = "Volume Up";
+ linux,code = ;
+ press-threshold-microvolt = <297500>;
+ };
+
+ button-vol-down {
+ label = "Volume Down";
+ linux,code = ;
+ press-threshold-microvolt = <1750>;
+ };
+
[PATCH v4 0/4] arm64: rockchip: Pine64 PineTab2 support
This adds support for the BOE TH101MB31IG002 LCD Panel used in PineTab2 [1] and PineTab-V [2] as well as the devictrees for the PineTab2 v0.1 and v2.0. The BOE LCD Panel patch was retrieved from [3]. The function-name prefix has been adapted and the LCD init section was simplified. The PineTab2 devicetree patch was retrieved from [4]. Some renaming was needed to pass the dtb-checks, the brightness-levels are specified as range and steps instead of a list of values. [5] and [6] was also used as source for this queue. [1] https://wiki.pine64.org/wiki/PineTab2 [2] https://wiki.pine64.org/wiki/PineTab-V [3] https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/mobian-6.6/debian/patches/display/0018-drm-panel-add-BOE-TH101MB31IG002-28A-driver.patch?ref_type=heads [4] https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/mobian-6.6/debian/patches/device-tree/0134-arch-arm64-add-Pine64-PineTab2-device-trees.patch?ref_type=heads [5] https://github.com/dreemurrs-embedded/linux-pinetab2/tree/v6.6.7-danctnix1 [6] https://xff.cz/git/linux?h=pt2-6.7 Signed-off-by: Manuel Traut --- Changes in v4: - Rebased on v6.8-rc1 - BOE TH101MB31IG002 LCD Panel: * Picked patches from https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) - PineTab2 dts: * Make flash-led a regulator-led and control the regulator by GPIO and set V5_MIDU as vin-supply to ensure that LED is working even if all other drivers using V5 MIDU are unloaded. * Add -regulator suffix to nodes, replace -con suffix by -connector * Set lcd pinctrl in .dts instead of .dtsi so it is more clear that this is different between pinetab v0.1 and v2.0 * Remove unused bluetooth uart configuration and pinctrl * Increase spi-nor max-speed from 24 to 100 MHz - Link to v3: https://lore.kernel.org/r/20240102-pinetab2-v3-0-cb1aa69f8...@mecka.net Changes in v3: - PineTab2 dts: * Remove useless regulator-state-mem nodes for fixed regulators * Swap mmc0 and mmc1, so mmc0 is now the internal eMMC - BOE TH101MB31IG002 LCD Panel: * Remove enabled/prepared checks since they are done in core. - Use consistent naming (PineTab2 and PineTab-V) in commit messages. - Link to v2: https://lore.kernel.org/r/20231223-pinetab2-v2-0-ec1856d00...@mecka.net Changes in v2: - Removed dtb-checker fixups, cause I am not sure if they are correct - Applied review comments for dt bindings - pinetab2 dts: * Remove unverified WLAN entries, as in [5] * Simplify flash LED definition, as in [5] * Fix headphone detection and sound routing, as in [5] * Fix CRU clock configuration - BOE TH101MB31IG002 LCD Panel: * Reworked prepare/enable unprepare/disable, as in [5] - Replaced nicknames by realnames in author and signed-offs - Link to v1: https://lore.kernel.org/r/20231222-pinetab2-v1-0-e148a7f61...@mecka.net --- Alexander Warnecke (1): drm/panel: Add driver for BOE TH101MB31IG002-28A panel Manuel Traut (3): dt-bindings: display: panel: Add BOE TH101MB31IG002-28A panel dt-bindings: arm64: rockchip: Add Pine64 PineTab2 arm64: dts: rockchip: Add devicetree for Pine64 PineTab2 .../devicetree/bindings/arm/rockchip.yaml | 8 + .../display/panel/boe,th101mb31ig002-28a.yaml | 58 ++ arch/arm64/boot/dts/rockchip/Makefile | 2 + .../boot/dts/rockchip/rk3566-pinetab2-v0.1.dts | 28 + .../boot/dts/rockchip/rk3566-pinetab2-v2.0.dts | 48 ++ arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi | 943 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile | 1 + .../gpu/drm/panel/panel-boe-th101mb31ig002-28a.c | 322 +++ 9 files changed, 1421 insertions(+) --- base-commit: 3a5879d495b226d0404098e3564462d5f1daa33b change-id: 20231222-pinetab2-faa77e01db6f Best regards, -- Manuel Traut
[PATCH v4 3/4] dt-bindings: arm64: rockchip: Add Pine64 PineTab2
Add devicvetree binding documentation for Pine64 PineTab2 which uses the Rockchip RK3566 SoC. Signed-off-by: Manuel Traut Acked-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/arm/rockchip.yaml | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 5cf5cbef2cf5..1b9740e2f3a1 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -650,6 +650,14 @@ properties: - const: pine64,pinenote - const: rockchip,rk3566 + - description: Pine64 PineTab2 +items: + - enum: + - pine64,pinetab2-v0.1 + - pine64,pinetab2-v2.0 + - const: pine64,pinetab2 + - const: rockchip,rk3566 + - description: Pine64 PinePhonePro items: - const: pine64,pinephone-pro -- 2.43.0
[PATCH v4 1/4] dt-bindings: display: panel: Add BOE TH101MB31IG002-28A panel
Add bindings for the BOE TH101MB31IG002-28A LCD panel. It is
used e.g. in the Pine64 PineTab2 and PineTab-V.
Signed-off-by: Manuel Traut
Reviewed-by: Krzysztof Kozlowski
Link: https://lore.kernel.org/r/20240102-pinetab2-v3-1-cb1aa69f8...@mecka.net
Signed-off-by: Neil Armstrong
Link:
https://patchwork.freedesktop.org/patch/msgid/20240102-pinetab2-v3-1-cb1aa69f8...@mecka.net
(cherry picked from commit baae3a0b10c499d4228514a701602f6fd2a8d6b4)
---
.../display/panel/boe,th101mb31ig002-28a.yaml | 58 ++
1 file changed, 58 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml
b/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml
new file mode 100644
index ..32df26cbfeed
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/boe,th101mb31ig002-28a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE TH101MB31IG002-28A WXGA DSI Display Panel
+
+maintainers:
+ - Manuel Traut
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+enum:
+# BOE TH101MB31IG002-28A 10.1" WXGA TFT LCD panel
+ - boe,th101mb31ig002-28a
+
+ reg: true
+ backlight: true
+ enable-gpios: true
+ power-supply: true
+ port: true
+ rotation: true
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - power-supply
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "boe,th101mb31ig002-28a";
+reg = <0>;
+backlight = <&backlight_lcd0>;
+enable-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
+rotation = <90>;
+power-supply = <&vcc_3v3>;
+port {
+panel_in_dsi: endpoint {
+remote-endpoint = <&dsi_out_con>;
+};
+};
+};
+};
+
+...
--
2.43.0
[PATCH v4 2/4] drm/panel: Add driver for BOE TH101MB31IG002-28A panel
From: Alexander Warnecke
The BOE TH101MB31IG002-28A panel is a WXGA panel.
It is used in Pine64 PineTab2 and PineTab-V.
Signed-off-by: Alexander Warnecke
Signed-off-by: Manuel Traut
Reviewed-by: Jessica Zhang
Link: https://lore.kernel.org/r/20240102-pinetab2-v3-2-cb1aa69f8...@mecka.net
Signed-off-by: Neil Armstrong
Link:
https://patchwork.freedesktop.org/patch/msgid/20240102-pinetab2-v3-2-cb1aa69f8...@mecka.net
(cherry picked from commit 420186db1483da4e16cd5d5a472f511a35dbc1b7)
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile | 1 +
.../gpu/drm/panel/panel-boe-th101mb31ig002-28a.c | 322 +
3 files changed, 334 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 8f3783742208..00a947941c19 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -67,6 +67,17 @@ config DRM_PANEL_BOE_HIMAX8279D
24 bit RGB per pixel. It provides a MIPI DSI interface to
the host and has a built-in LED backlight.
+config DRM_PANEL_BOE_TH101MB31UIG002_28A
+ tristate "Boe TH101MB31UIG002-28A panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Boe
+ TH101MB31UIG002-28A TFT-LCD modules. The panel has a 800x1280
+ resolution and uses 24 bit RGB per pixel. It provides a MIPI DSI
+ interface to the host and has a built-in LED backlight.
+
config DRM_PANEL_BOE_TV101WUM_NL6
tristate "BOE TV101WUM and AUO KD101N80 45NA 1200x1920 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d94a644d0a6c..015bb8d70fbd 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_PANEL_ASUS_Z00T_TM5P5_NT35596) +=
panel-asus-z00t-tm5p5-n35596.
obj-$(CONFIG_DRM_PANEL_AUO_A030JTN01) += panel-auo-a030jtn01.o
obj-$(CONFIG_DRM_PANEL_BOE_BF060Y8M_AJ0) += panel-boe-bf060y8m-aj0.o
obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
+obj-$(CONFIG_DRM_PANEL_BOE_TH101MB31UIG002_28A) +=
panel-boe-th101mb31ig002-28a.o
obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
obj-$(CONFIG_DRM_PANEL_DSI_CM) += panel-dsi-cm.o
obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
diff --git a/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
b/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
new file mode 100644
index ..763e9f8342d3
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
@@ -0,0 +1,322 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Alexander Warnecke
+ * Copyright (c) 2023 Manuel Traut
+ * Copyright (c) 2023 Dang Huynh
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+struct boe_th101mb31ig002 {
+ struct drm_panel panel;
+
+ struct mipi_dsi_device *dsi;
+
+ struct regulator *power;
+ struct gpio_desc *enable;
+ struct gpio_desc *reset;
+
+ enum drm_panel_orientation orientation;
+};
+
+static void boe_th101mb31ig002_reset(struct boe_th101mb31ig002 *ctx)
+{
+ gpiod_direction_output(ctx->reset, 0);
+ usleep_range(10, 100);
+ gpiod_direction_output(ctx->reset, 1);
+ usleep_range(10, 100);
+ gpiod_direction_output(ctx->reset, 0);
+ usleep_range(5000, 6000);
+}
+
+static int boe_th101mb31ig002_enable(struct drm_panel *panel)
+{
+ struct boe_th101mb31ig002 *ctx = container_of(panel,
+ struct boe_th101mb31ig002,
+ panel);
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ struct device *dev = &dsi->dev;
+ int ret;
+
+ mipi_dsi_dcs_write_seq(dsi, 0xE0, 0xAB, 0xBA);
+ mipi_dsi_dcs_write_seq(dsi, 0xE1, 0xBA, 0xAB);
+ mipi_dsi_dcs_write_seq(dsi, 0xB1, 0x10, 0x01, 0x47, 0xFF);
+ mipi_dsi_dcs_write_seq(dsi, 0xB2, 0x0C, 0x14, 0x04, 0x50, 0x50, 0x14);
+ mipi_dsi_dcs_write_seq(dsi, 0xB3, 0x56, 0x53, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xB4, 0x33, 0x30, 0x04);
+ mipi_dsi_dcs_write_seq(dsi, 0xB6, 0xB0, 0x00, 0x00, 0x10, 0x00, 0x10,
+ 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xB8, 0x05, 0x12, 0x29, 0x49, 0x48, 0x00,
+ 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xB9, 0x7C, 0x65, 0x55, 0x49, 0x46, 0x36,
+ 0x3B, 0x24, 0x3D, 0x3C, 0x3D, 0x5C, 0x4C,
+ 0x55, 0x47, 0x46, 0x39, 0x26, 0x06, 0x7C,
+ 0x65, 0x55, 0x49, 0x46, 0x36, 0x3B, 0x24,
+ 0x3D, 0x3C, 0x3D, 0x5C, 0x4C, 0x55, 0x47,
+ 0x46, 0x39, 0x26, 0x
Re: [PATCH v3 4/4] arm64: dts: rockchip: Add devicetree for Pine64 PineTab2
Hi Jonas,
On Wed, Jan 03, 2024 at 03:19:25PM +0100, Jonas Karlman wrote:
> Hi Manuel,
>
> On 2024-01-03 14:40, Manuel Traut wrote:
> > Hi Jonas and Ondřej,
> >
> +&sfc {
> +pinctrl-names = "default";
> +pinctrl-0 = <&fspi_dual_io_pins>;
> +status = "okay";
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +flash@0 {
> +compatible = "jedec,spi-nor";
> +reg = <0>;
> +spi-max-frequency = <2400>;
> >>>
> >>> That's a bit on the low side. The flash chip should work for all commands
> >>> up to
> >>> 80MHz https://megous.com/dl/tmp/b428ad9b85ac4633.png and SGM3157YC6 switch
> >>> for the FSPI-CLK should have high enough bandwidth, too.
> >>
> >> I agree that this is a little bit on the low side, it was a safe rate
> >> that I used for U-Boot. U-Boot required an exact rate of the supported
> >> sfc clk rates: 24, 50, 75, 100, 125 or 150 MHz.
> >>
> >> Please also note that the SPI NOR flash chip used in PineTab2 is not a
> >> GigaDevice GD25LQ128E, it should be a SiliconKaiser SK25LP128, same as
> >> found in the Pine64 PinePhone Pro.
> >
> > The schematics for v2.0 reference a GD25LQ128EWIGR. I never checked the
> > jedec
> > id. How did you retrieve this information, or is it maybe a difference in
> > v0.1
> > and 2.0?
>
> This was when working on mainline U-Boot for the PineTab2 (and other
> rk356x devices). See [1] for a pending U-Boot patch that is waiting on a
> proper mainline linux devicetree for the PT2.
>
> The JEDEC ID is reported as 0x257018 on my v2.0 production unit, and
> does not match the JEDEC ID for GD25LQ128E (0xc86018) referenced in
> the schematics.
>
> I found that the JEDEC ID 0x257018 was referenced in prior patches
> related to the SK25LP128 SPI NOR flash chip used in Pine64 PinePhone Pro.
>
> I have only ever tested the 24 MHz rate, but I am expecting that e.g.
> 100 MHz also should work. Will not be able to test on my PT2 until at
> earliest next week.
>
> [1]
> https://github.com/Kwiboo/u-boot-rockchip/commit/66562d6eaf2c11a9f97fcdba379d3ceda8aa70ef
I found the time to verify that 100 MHz is also working.
Will include this in v4
Thanks for your help
Manuel
[PATCH] drm/bridge: dw-hdmi: fix trivial typo in comment
s/Initializateion/Initialization
Fixes: 9aaf880ed4ee ("imx-drm: Add mx6 hdmi transmitter support")
Signed-off-by: Eugen Hristev
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index aca5bb0866f8..2fc7dae7b8f8 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2288,7 +2288,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi,
/* HDMI Initialization Step B.1 */
hdmi_av_composer(hdmi, &connector->display_info, mode);
- /* HDMI Initializateion Step B.2 */
+ /* HDMI Initialization Step B.2 */
ret = hdmi->phy.ops->init(hdmi, hdmi->phy.data,
&connector->display_info,
&hdmi->previous_mode);
--
2.34.1
