Re: [PATCH v6 8/8] drm/msm/dpu: tear down DSC data path when DSC disabled

2023-05-10 Thread Dmitry Baryshkov

On 11/05/2023 01:07, Kuogee Hsieh wrote:

Unset DSC_ACTIVE bit at dpu_hw_ctl_reset_intf_cfg_v1(),
dpu_encoder_unprep_dsc() and dpu_encoder_dsc_pipe_clr() functions
to tear down DSC data path if DSC data path was setup previous.

Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 44 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c  |  7 +
  2 files changed, 51 insertions(+)



Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry



Re: [PATCH v6 8/8] drm/msm/dpu: tear down DSC data path when DSC disabled

2023-05-10 Thread Dmitry Baryshkov

On 11/05/2023 01:07, Kuogee Hsieh wrote:

Unset DSC_ACTIVE bit at dpu_hw_ctl_reset_intf_cfg_v1(),
dpu_encoder_unprep_dsc() and dpu_encoder_dsc_pipe_clr() functions
to tear down DSC data path if DSC data path was setup previous.

Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 44 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c  |  7 +
  2 files changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 94b805b..6500589 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1214,6 +1214,45 @@ static void dpu_encoder_virt_atomic_enable(struct 
drm_encoder *drm_enc,
mutex_unlock(_enc->enc_lock);
  }
  
+static void dpu_encoder_dsc_pipe_clr(struct dpu_encoder_virt *dpu_enc,

+ struct dpu_hw_dsc *hw_dsc,
+ struct dpu_hw_pingpong *hw_pp)
+{
+   struct dpu_encoder_phys *cur_master = dpu_enc->cur_master;
+   struct dpu_hw_ctl *ctl;
+
+   ctl = cur_master->hw_ctl;
+
+   if (hw_dsc->ops.dsc_disable)
+   hw_dsc->ops.dsc_disable(hw_dsc);
+
+   if (hw_pp->ops.disable_dsc)
+   hw_pp->ops.disable_dsc(hw_pp);
+
+   if (hw_dsc->ops.dsc_bind_pingpong_blk)
+   hw_dsc->ops.dsc_bind_pingpong_blk(hw_dsc, PINGPONG_NONE);
+
+   if (ctl->ops.update_pending_flush_dsc)
+   ctl->ops.update_pending_flush_dsc(ctl, hw_dsc->idx);
+}
+
+static void dpu_encoder_unprep_dsc(struct dpu_encoder_virt *dpu_enc)
+{
+   /* coding only for 2LM, 2enc, 1 dsc config */
+   struct dpu_hw_dsc *hw_dsc[MAX_CHANNELS_PER_ENC];
+   struct dpu_hw_pingpong *hw_pp[MAX_CHANNELS_PER_ENC];
+   int i;
+
+   for (i = 0; i < MAX_CHANNELS_PER_ENC; i++) {
+   hw_pp[i] = dpu_enc->hw_pp[i];
+   hw_dsc[i] = dpu_enc->hw_dsc[i];
+
+   if (hw_pp[i] && hw_dsc[i])
+   dpu_encoder_dsc_pipe_clr(dpu_enc, hw_dsc[i], hw_pp[i]);
+   }
+
+}
+
  static void dpu_encoder_virt_atomic_disable(struct drm_encoder *drm_enc,
struct drm_atomic_state *state)
  {
@@ -2090,6 +2129,9 @@ void dpu_encoder_helper_phys_cleanup(struct 
dpu_encoder_phys *phys_enc)
phys_enc->hw_pp->merge_3d->idx);
}
  
+	if (dpu_enc->dsc)

+   dpu_encoder_unprep_dsc(dpu_enc);
+
intf_cfg.stream_sel = 0; /* Don't care value for video mode */
intf_cfg.mode_3d = dpu_encoder_helper_get_3d_blend_mode(phys_enc);
  
@@ -2101,6 +2143,8 @@ void dpu_encoder_helper_phys_cleanup(struct dpu_encoder_phys *phys_enc)

if (phys_enc->hw_pp->merge_3d)
intf_cfg.merge_3d = phys_enc->hw_pp->merge_3d->idx;
  
+	intf_cfg.dsc = dpu_encoder_helper_get_dsc(phys_enc);

+
if (ctl->ops.reset_intf_cfg)
ctl->ops.reset_intf_cfg(ctl, _cfg);
  
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 832a6a7..b34dac5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -577,6 +577,7 @@ static void dpu_hw_ctl_reset_intf_cfg_v1(struct dpu_hw_ctl 
*ctx,
u32 intf_active = 0;
u32 wb_active = 0;
u32 merge3d_active = 0;
+   u32 dsc_active;
  
  	/*

 * This API resets each portion of the CTL path namely,
@@ -606,6 +607,12 @@ static void dpu_hw_ctl_reset_intf_cfg_v1(struct dpu_hw_ctl 
*ctx,
wb_active &= ~BIT(cfg->wb - WB_0);
DPU_REG_WRITE(c, CTL_WB_ACTIVE, wb_active);
}
+
+   if (cfg->dsc) {
+   dsc_active = DPU_REG_READ(c, CTL_DSC_ACTIVE);
+   dsc_active &= ~cfg->dsc;
+   DPU_REG_WRITE(c, CTL_DSC_ACTIVE, dsc_active);
+   }
  }
  
  static void dpu_hw_ctl_set_fetch_pipe_active(struct dpu_hw_ctl *ctx,


--
With best wishes
Dmitry



Re: [PATCH v6 5/8] drm/msm/dpu: add support for DSC encoder v1.2 engine

2023-05-10 Thread Dmitry Baryshkov

On 11/05/2023 01:07, Kuogee Hsieh wrote:

Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.

Changes in v3:
-- fixed kernel test rebot report that "__iomem *off" is declared but not
used at dpu_hw_dsc_config_1_2()
-- unrolling thresh loops

Changes in v4:
-- delete DPU_DSC_HW_REV_1_1
-- delete off and used real register name directly

Reported-by: kernel test robot 
Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/Makefile   |   1 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  32 +-
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h |  14 +-
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c | 385 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |   7 +-
  5 files changed, 435 insertions(+), 4 deletions(-)
  create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index b814fc8..b9af5e4 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -65,6 +65,7 @@ msm-$(CONFIG_DRM_MSM_DPU) += \
disp/dpu1/dpu_hw_catalog.o \
disp/dpu1/dpu_hw_ctl.o \
disp/dpu1/dpu_hw_dsc.o \
+   disp/dpu1/dpu_hw_dsc_1_2.o \
disp/dpu1/dpu_hw_interrupts.o \
disp/dpu1/dpu_hw_intf.o \
disp/dpu1/dpu_hw_lm.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index dc0a4da..4eda2cc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -1,6 +1,6 @@
  /* SPDX-License-Identifier: GPL-2.0-only */
  /*
- * Copyright (c) 2022. Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2022-2023, Qualcomm Innovation Center, Inc. All rights 
reserved.
   * Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
   */
  
@@ -244,12 +244,18 @@ enum {

  };
  
  /**

- * DSC features
+ * DSC sub-blocks/features
   * @DPU_DSC_OUTPUT_CTRL   Configure which PINGPONG block gets
   *the pixel output from this DSC.
+ * @DPU_DSC_HW_REV_1_2DSC block supports dsc 1.1 and 1.2
+ * @DPU_DSC_NATIVE_422_EN Supports native422 and native420 encoding
+ * @DPU_DSC_MAX
   */
  enum {
DPU_DSC_OUTPUT_CTRL = 0x1,
+   DPU_DSC_HW_REV_1_2,
+   DPU_DSC_NATIVE_422_EN,
+   DPU_DSC_MAX
  };
  
  /**

@@ -306,6 +312,14 @@ struct dpu_pp_blk {
  };
  
  /**

+ * struct dpu_dsc_blk - DSC Encoder sub-blk information
+ * @info:   HW register and features supported by this sub-blk
+ */
+struct dpu_dsc_blk {
+   DPU_HW_SUBBLK_INFO;
+};
+
+/**
   * enum dpu_qos_lut_usage - define QoS LUT use cases
   */
  enum dpu_qos_lut_usage {
@@ -452,6 +466,17 @@ struct dpu_pingpong_sub_blks {
  };
  
  /**

+ * struct dpu_dsc_sub_blks - DSC sub-blks
+ * @enc: DSC encoder sub block
+ * @ctl: DSC controller sub block
+ *
+ */
+struct dpu_dsc_sub_blks {
+   struct dpu_dsc_blk enc;
+   struct dpu_dsc_blk ctl;
+};
+
+/**
   * dpu_clk_ctrl_type - Defines top level clock control signals
   */
  enum dpu_clk_ctrl_type {
@@ -605,10 +630,13 @@ struct dpu_merge_3d_cfg  {
   * struct dpu_dsc_cfg - information of DSC blocks
   * @id enum identifying this block
   * @base   register offset of this block
+ * @len:   length of hardware block
   * @features   bit mask identifying sub-blocks/features
+ * @sblk   sub-blocks information
   */
  struct dpu_dsc_cfg {
DPU_HW_BLK_INFO;
+   const struct dpu_dsc_sub_blks *sblk;
  };
  
  /**

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
index 138080a..bdff74d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
@@ -1,5 +1,8 @@
  /* SPDX-License-Identifier: GPL-2.0-only */
-/* Copyright (c) 2020-2022, Linaro Limited */
+/*
+ * Copyright (c) 2020-2022, Linaro Limited
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
  
  #ifndef _DPU_HW_DSC_H

  #define _DPU_HW_DSC_H
@@ -69,6 +72,15 @@ struct dpu_hw_dsc *dpu_hw_dsc_init(const struct dpu_dsc_cfg 
*cfg,
void __iomem *addr);
  
  /**

+ * dpu_hw_dsc_init_1_2 - initializes the v1.2 DSC hw driver block
+ * @cfg:  DSC catalog entry for which driver object is required
+ * @addr: Mapped register io address of MDP
+ * Returns: Error code or allocated dpu_hw_dsc context
+ */
+struct dpu_hw_dsc *dpu_hw_dsc_init_1_2(const struct dpu_dsc_cfg *cfg,
+   void __iomem *addr);
+
+/**
   * dpu_hw_dsc_destroy - destroys dsc driver context
   * @dsc:   Pointer to dsc driver context returned by dpu_hw_dsc_init
   */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c
new file mode 100644
index ..0c77c85
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c

Re: [PATCH v6 2/8] drm/msm/dpu: add DPU_PINGPONG_DSC feature bit for DPU < 7.0.0

2023-05-10 Thread Dmitry Baryshkov

On 11/05/2023 07:42, Abhinav Kumar wrote:



On 5/10/2023 9:39 PM, Dmitry Baryshkov wrote:

On 11/05/2023 07:38, Abhinav Kumar wrote:



On 5/10/2023 9:29 PM, Dmitry Baryshkov wrote:

On 11/05/2023 01:07, Kuogee Hsieh wrote:

DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC setting up. Since DPU >= 7.0.0, enabling and starting the DSC
encoder engine moved to INTF with the help of the flush mechanism.


Nit: was moved.


Add a DPU_PINGPONG_DSC feature bit to restrict the availability of
dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() on the
PINGPONG block to DPU < 7.0.0 hardware, as the registers are not
available [in the PINGPONG block] on DPU 7.0.0 and higher anymore.


this looks good


Existing call-sites to these callbacks already skip calling into
them if the function pointer is NULL.


This is more relevant for patch 3 commit message.


Add DPU_PINGPONG_DSC feature
bit to all chipset with DPU < 7.0.0.


This is incorrect, as we do not change the catalog in this patch.



Sorry but why not? The changes done to dpu_hw_catalog.c do exactly that.


Because the patch does not add this feature bit to any of the 
chipsets. I think the relevant patch was lost somewhere during the 
rework/rebase.






This is adding it right?

   #define PINGPONG_SDM845_MASK \
-    (BIT(DPU_PINGPONG_DITHER) | BIT(DPU_PINGPONG_TE))
+    (BIT(DPU_PINGPONG_DITHER) | BIT(DPU_PINGPONG_TE) | 
BIT(DPU_PINGPONG_DSC))

   #define PINGPONG_SDM845_TE2_MASK \



Ah, I see now. I was expecting changes to the actual catlog files. 
Please excuse me.


As we are using PINGPONG_SDM845_MASK only up to and including DPU 6.x, 
this is correct.


I'd then suggest rephrasing this sentence to be more explicit:

Add DPU_PINGPONG_DSC to PINGPONG_SDM845_MASK, which is used for all DPU 
< 7.0 chipsets.


--
With best wishes
Dmitry



Re: [PATCH v6 2/8] drm/msm/dpu: add DPU_PINGPONG_DSC feature bit for DPU < 7.0.0

2023-05-10 Thread Abhinav Kumar




On 5/10/2023 9:39 PM, Dmitry Baryshkov wrote:

On 11/05/2023 07:38, Abhinav Kumar wrote:



On 5/10/2023 9:29 PM, Dmitry Baryshkov wrote:

On 11/05/2023 01:07, Kuogee Hsieh wrote:

DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC setting up. Since DPU >= 7.0.0, enabling and starting the DSC
encoder engine moved to INTF with the help of the flush mechanism.


Nit: was moved.


Add a DPU_PINGPONG_DSC feature bit to restrict the availability of
dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() on the
PINGPONG block to DPU < 7.0.0 hardware, as the registers are not
available [in the PINGPONG block] on DPU 7.0.0 and higher anymore.


this looks good


Existing call-sites to these callbacks already skip calling into
them if the function pointer is NULL.


This is more relevant for patch 3 commit message.


Add DPU_PINGPONG_DSC feature
bit to all chipset with DPU < 7.0.0.


This is incorrect, as we do not change the catalog in this patch.



Sorry but why not? The changes done to dpu_hw_catalog.c do exactly that.


Because the patch does not add this feature bit to any of the chipsets. 
I think the relevant patch was lost somewhere during the rework/rebase.






This is adding it right?

  #define PINGPONG_SDM845_MASK \
-(BIT(DPU_PINGPONG_DITHER) | BIT(DPU_PINGPONG_TE))
+(BIT(DPU_PINGPONG_DITHER) | BIT(DPU_PINGPONG_TE) | 
BIT(DPU_PINGPONG_DSC))

  #define PINGPONG_SDM845_TE2_MASK \


Re: [PATCH v6 2/8] drm/msm/dpu: add DPU_PINGPONG_DSC feature bit for DPU < 7.0.0

2023-05-10 Thread Dmitry Baryshkov

On 11/05/2023 07:38, Abhinav Kumar wrote:



On 5/10/2023 9:29 PM, Dmitry Baryshkov wrote:

On 11/05/2023 01:07, Kuogee Hsieh wrote:

DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC setting up. Since DPU >= 7.0.0, enabling and starting the DSC
encoder engine moved to INTF with the help of the flush mechanism.


Nit: was moved.


Add a DPU_PINGPONG_DSC feature bit to restrict the availability of
dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() on the
PINGPONG block to DPU < 7.0.0 hardware, as the registers are not
available [in the PINGPONG block] on DPU 7.0.0 and higher anymore.


this looks good


Existing call-sites to these callbacks already skip calling into
them if the function pointer is NULL.


This is more relevant for patch 3 commit message.


Add DPU_PINGPONG_DSC feature
bit to all chipset with DPU < 7.0.0.


This is incorrect, as we do not change the catalog in this patch.



Sorry but why not? The changes done to dpu_hw_catalog.c do exactly that.


Because the patch does not add this feature bit to any of the chipsets. 
I think the relevant patch was lost somewhere during the rework/rebase.




--
With best wishes
Dmitry



Re: [PATCH v6 2/8] drm/msm/dpu: add DPU_PINGPONG_DSC feature bit for DPU < 7.0.0

2023-05-10 Thread Abhinav Kumar




On 5/10/2023 9:29 PM, Dmitry Baryshkov wrote:

On 11/05/2023 01:07, Kuogee Hsieh wrote:

DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC setting up. Since DPU >= 7.0.0, enabling and starting the DSC
encoder engine moved to INTF with the help of the flush mechanism.


Nit: was moved.


Add a DPU_PINGPONG_DSC feature bit to restrict the availability of
dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() on the
PINGPONG block to DPU < 7.0.0 hardware, as the registers are not
available [in the PINGPONG block] on DPU 7.0.0 and higher anymore.


this looks good


Existing call-sites to these callbacks already skip calling into
them if the function pointer is NULL.


This is more relevant for patch 3 commit message.


Add DPU_PINGPONG_DSC feature
bit to all chipset with DPU < 7.0.0.


This is incorrect, as we do not change the catalog in this patch.



Sorry but why not? The changes done to dpu_hw_catalog.c do exactly that.



changes in v6:
-- split patches and rearrange to keep catalog related files at this 
patch


Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 +++---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +++-
  2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c

index 82b58c6..78e4bf6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -76,13 +76,13 @@
  (BIT(DPU_DIM_LAYER) | BIT(DPU_MIXER_COMBINED_ALPHA))
  #define PINGPONG_SDM845_MASK \
-    (BIT(DPU_PINGPONG_DITHER) | BIT(DPU_PINGPONG_TE))
+    (BIT(DPU_PINGPONG_DITHER) | BIT(DPU_PINGPONG_TE) | 
BIT(DPU_PINGPONG_DSC))

  #define PINGPONG_SDM845_TE2_MASK \
-    (PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
+    (PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2) | 
BIT(DPU_PINGPONG_DSC))

  #define PINGPONG_SM8150_MASK \
-    (BIT(DPU_PINGPONG_DITHER))
+    (BIT(DPU_PINGPONG_DITHER) | BIT(DPU_PINGPONG_DSC))
  #define CTL_SC7280_MASK \
  (BIT(DPU_CTL_ACTIVE_CFG) | \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h

index 6ee48f0..dc0a4da 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -144,7 +144,8 @@ enum {
   * @DPU_PINGPONG_TE2    Additional tear check block for split pipes
   * @DPU_PINGPONG_SPLIT  PP block supports split fifo
   * @DPU_PINGPONG_SLAVE  PP block is a suitable slave for split fifo
- * @DPU_PINGPONG_DITHER,    Dither blocks
+ * @DPU_PINGPONG_DITHER Dither blocks
+ * @DPU_PINGPONG_DSC    PP ops functions required for DSC
   * @DPU_PINGPONG_MAX
   */
  enum {
@@ -153,6 +154,7 @@ enum {
  DPU_PINGPONG_SPLIT,
  DPU_PINGPONG_SLAVE,
  DPU_PINGPONG_DITHER,
+    DPU_PINGPONG_DSC,
  DPU_PINGPONG_MAX
  };




Re: [PATCH v6 3/8] drm/msm/dpu: test DPU_PINGPONG_DSC bit before assign DSC ops to PINGPONG

2023-05-10 Thread Dmitry Baryshkov

On 11/05/2023 01:07, Kuogee Hsieh wrote:

DPU < 7.0.0 has DPU_PINGPONG_DSC feature bit set to indicate it requires
both dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() to be
executed to complete DSC configuration if DSC hardware block is present.
Hence test DPU_PINGPONG_DSC feature bit and assign DSC related functions
to the ops of PINGPONG block accordingly if DPU_PINGPONG_DSC bit is set.

changes in v6:
-- split patches and keep the function file handles DPU_PINGPONG_DSC bit at 
this patch

Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 6 ++
  1 file changed, 6 insertions(+)


For the patch itself:
Reviewed-by: Dmitry Baryshkov 



diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 79e4576..e7f47a4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -295,6 +295,12 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
c->ops.disable_dsc = dpu_hw_pp_dsc_disable;
  
+	if (test_bit(DPU_PINGPONG_DSC, )) {

+   c->ops.setup_dsc = dpu_hw_pp_setup_dsc;
+   c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
+   c->ops.disable_dsc = dpu_hw_pp_dsc_disable;
+   }
+
if (test_bit(DPU_PINGPONG_DITHER, ))
c->ops.setup_dither = dpu_hw_pp_setup_dither;
  };


--
With best wishes
Dmitry



Re: [PATCH v6 3/8] drm/msm/dpu: test DPU_PINGPONG_DSC bit before assign DSC ops to PINGPONG

2023-05-10 Thread Dmitry Baryshkov

On 11/05/2023 01:07, Kuogee Hsieh wrote:

DPU < 7.0.0 has DPU_PINGPONG_DSC feature bit set to indicate it requires
both dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() to be
executed to complete DSC configuration if DSC hardware block is present.
Hence test DPU_PINGPONG_DSC feature bit and assign DSC related functions
to the ops of PINGPONG block accordingly if DPU_PINGPONG_DSC bit is set.

changes in v6:
-- split patches and keep the function file handles DPU_PINGPONG_DSC bit at 
this patch


Please correct me if I'm wrong, the overall suggestion was to have 
actual catalog changes before this patch. However I do not see this 
feature bit being enabled at all!




Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 79e4576..e7f47a4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -295,6 +295,12 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
c->ops.disable_dsc = dpu_hw_pp_dsc_disable;
  
+	if (test_bit(DPU_PINGPONG_DSC, )) {

+   c->ops.setup_dsc = dpu_hw_pp_setup_dsc;
+   c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
+   c->ops.disable_dsc = dpu_hw_pp_dsc_disable;
+   }
+
if (test_bit(DPU_PINGPONG_DITHER, ))
c->ops.setup_dither = dpu_hw_pp_setup_dither;
  };


--
With best wishes
Dmitry



Re: [PATCH v6 2/8] drm/msm/dpu: add DPU_PINGPONG_DSC feature bit for DPU < 7.0.0

2023-05-10 Thread Dmitry Baryshkov

On 11/05/2023 01:07, Kuogee Hsieh wrote:

DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC setting up. Since DPU >= 7.0.0, enabling and starting the DSC
encoder engine moved to INTF with the help of the flush mechanism.


Nit: was moved.


Add a DPU_PINGPONG_DSC feature bit to restrict the availability of
dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() on the
PINGPONG block to DPU < 7.0.0 hardware, as the registers are not
available [in the PINGPONG block] on DPU 7.0.0 and higher anymore.


this looks good


Existing call-sites to these callbacks already skip calling into
them if the function pointer is NULL.


This is more relevant for patch 3 commit message.


Add DPU_PINGPONG_DSC feature
bit to all chipset with DPU < 7.0.0.


This is incorrect, as we do not change the catalog in this patch.



changes in v6:
-- split patches and rearrange to keep catalog related files at this patch

Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 +++---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +++-
  2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 82b58c6..78e4bf6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -76,13 +76,13 @@
(BIT(DPU_DIM_LAYER) | BIT(DPU_MIXER_COMBINED_ALPHA))
  
  #define PINGPONG_SDM845_MASK \

-   (BIT(DPU_PINGPONG_DITHER) | BIT(DPU_PINGPONG_TE))
+   (BIT(DPU_PINGPONG_DITHER) | BIT(DPU_PINGPONG_TE) | 
BIT(DPU_PINGPONG_DSC))
  
  #define PINGPONG_SDM845_TE2_MASK \

-   (PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
+   (PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2) | BIT(DPU_PINGPONG_DSC))
  
  #define PINGPONG_SM8150_MASK \

-   (BIT(DPU_PINGPONG_DITHER))
+   (BIT(DPU_PINGPONG_DITHER) | BIT(DPU_PINGPONG_DSC))
  
  #define CTL_SC7280_MASK \

(BIT(DPU_CTL_ACTIVE_CFG) | \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 6ee48f0..dc0a4da 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -144,7 +144,8 @@ enum {
   * @DPU_PINGPONG_TE2Additional tear check block for split pipes
   * @DPU_PINGPONG_SPLIT  PP block supports split fifo
   * @DPU_PINGPONG_SLAVE  PP block is a suitable slave for split fifo
- * @DPU_PINGPONG_DITHER,Dither blocks
+ * @DPU_PINGPONG_DITHER Dither blocks
+ * @DPU_PINGPONG_DSCPP ops functions required for DSC
   * @DPU_PINGPONG_MAX
   */
  enum {
@@ -153,6 +154,7 @@ enum {
DPU_PINGPONG_SPLIT,
DPU_PINGPONG_SLAVE,
DPU_PINGPONG_DITHER,
+   DPU_PINGPONG_DSC,
DPU_PINGPONG_MAX
  };
  


--
With best wishes
Dmitry



Re: [PATCH v7 2/8] drm/display/dsc: add helper to set semi-const parameters

2023-05-10 Thread Dmitry Baryshkov

On 11/05/2023 01:35, Jessica Zhang wrote:



On 5/9/2023 11:29 PM, Marijn Suijten wrote:

On 2023-05-09 15:06:48, Jessica Zhang wrote:

From: Dmitry Baryshkov 

Add a helper setting config values which are typically constant across
operating modes (table E-4 of the standard) and mux_word_size (which is
a const according to 3.5.2).

Signed-off-by: Dmitry Baryshkov 
Signed-off-by: Jessica Zhang 


Same question about ordering.


Hi Marijn,

This patch was authored by Dmitry and originally part of his DRM DSC 
helpers series [1], but was removed from that series for mergeability 
reasons.


Looking over the kernel documentation, the last Signed-off-by should be 
from the patch submitter [2], so I think my s-o-b tag should be at the 
bottom.


As for the order in the previous patch, I can add a duplicate s-o-b 
before Dmitry's so that it reflects the history of the patch.


I think this is an overkill. Instead you can drop my SOB from the patch 
1. We do not need this level of detail.


For this patch the ordering of tags is correct.

--
With best wishes
Dmitry



Re: [PATCH v1 1/2] drm/msm/dp: enable HDP plugin/unplugged interrupts to hpd_enable/disable

2023-05-10 Thread Dmitry Baryshkov
On Wed, 10 May 2023 at 23:31, Kuogee Hsieh  wrote:
>
> The internal_hpd flag was introduced to handle external DP HPD derived from 
> GPIO
> pinmuxed into DP controller. HPD plug/unplug interrupts cannot be enabled 
> until
> internal_hpd flag is set to true.
> At both bootup and resume time, the DP driver will enable external DP
> plugin interrupts and handle plugin interrupt accordingly. Unfortunately
> dp_bridge_hpd_enable() bridge ops function was called to set internal_hpd
> flag to true later than where DP driver expected during bootup time.
>
> This causes external DP plugin event to not get detected and display stays 
> blank.
> Move enabling HDP plugin/unplugged interrupts to 
> dp_bridge_hpd_enable()/disable() to
> set internal_hpd to true along with enabling HPD plugin/unplugged interrupts
> simultaneously to avoid timing issue during bootup and resume.
>
> Fixes: cd198caddea7 ("drm/msm/dp: Rely on hpd_enable/disable callbacks")
> Signed-off-by: Kuogee Hsieh 

Thanks for debugging this!

However after looking at the driver I think there is more than this.

We have several other places gated on internal_hpd flag, where we do
not have a strict ordering of events.
I see that dp_hpd_plug_handle() and dp_hpd_unplug_handle() also toggle
DP_DP_IRQ_HPD_INT_MASK and DP_DP_HPD_REPLUG_INT_MASK depending on
internal_hpd. Can we toggle all 4 interrupts from the
hpd_enable/hpd_disable functions? If we can do it, then I think we can
drop the internal_hpd flag completely.

I went on and checked other places where it is used:
- dp_hpd_unplug_handle(), guarding DP_DP_HPD_PLUG_INT_MASK toggling. I
think we can drop these two calls completely. The function is under
the event_mutex protection, so other events can not interfere.
- dp_bridge_hpd_notify(). What is the point of this check? If some
other party informs us of the HPD event, we'd better handle it instead
of dropping it. Correct?  In other words, I'd prefer seeing the
hpd_event_thread removal. Instead of that I think that on
HPD/plug/unplug/etc. IRQ the driver should call into the drm stack,
then the hpd_notify call should process those events.


> ---
>  drivers/gpu/drm/msm/dp/dp_display.c | 27 ++-
>  1 file changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 3e13acdf..71aa944 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -1088,13 +1088,6 @@ static void dp_display_config_hpd(struct 
> dp_display_private *dp)
> dp_display_host_init(dp);
> dp_catalog_ctrl_hpd_config(dp->catalog);
>
> -   /* Enable plug and unplug interrupts only if requested */
> -   if (dp->dp_display.internal_hpd)
> -   dp_catalog_hpd_config_intr(dp->catalog,
> -   DP_DP_HPD_PLUG_INT_MASK |
> -   DP_DP_HPD_UNPLUG_INT_MASK,
> -   true);
> -
> /* Enable interrupt first time
>  * we are leaving dp clocks on during disconnect
>  * and never disable interrupt
> @@ -1396,12 +1389,6 @@ static int dp_pm_resume(struct device *dev)
>
> dp_catalog_ctrl_hpd_config(dp->catalog);
>
> -   if (dp->dp_display.internal_hpd)
> -   dp_catalog_hpd_config_intr(dp->catalog,
> -   DP_DP_HPD_PLUG_INT_MASK |
> -   DP_DP_HPD_UNPLUG_INT_MASK,
> -   true);
> -
> if (dp_catalog_link_is_connected(dp->catalog)) {
> /*
>  * set sink to normal operation mode -- D0
> @@ -1801,15 +1788,29 @@ void dp_bridge_hpd_enable(struct drm_bridge *bridge)
>  {
> struct msm_dp_bridge *dp_bridge = to_dp_bridge(bridge);
> struct msm_dp *dp_display = dp_bridge->dp_display;
> +   struct dp_display_private *dp;
> +
> +   dp = container_of(dp_display, struct dp_display_private, dp_display);
>
> dp_display->internal_hpd = true;
> +   dp_catalog_hpd_config_intr(dp->catalog,
> +   DP_DP_HPD_PLUG_INT_MASK |
> +   DP_DP_HPD_UNPLUG_INT_MASK,
> +   true);
>  }
>
>  void dp_bridge_hpd_disable(struct drm_bridge *bridge)
>  {
> struct msm_dp_bridge *dp_bridge = to_dp_bridge(bridge);
> struct msm_dp *dp_display = dp_bridge->dp_display;
> +   struct dp_display_private *dp;
> +
> +   dp = container_of(dp_display, struct dp_display_private, dp_display);
>
> +   dp_catalog_hpd_config_intr(dp->catalog,
> +   DP_DP_HPD_PLUG_INT_MASK |
> +   DP_DP_HPD_UNPLUG_INT_MASK,
> +   false);
> dp_display->internal_hpd = false;
>  }

--
With best wishes
Dmitry


Re: [PATCH v1 1/2] drm/msm/dp: enable HDP plugin/unplugged interrupts to hpd_enable/disable

2023-05-10 Thread Abhinav Kumar




On 5/10/2023 4:55 PM, Stephen Boyd wrote:

Quoting Kuogee Hsieh (2023-05-10 13:31:04)

The internal_hpd flag was introduced to handle external DP HPD derived from GPIO
pinmuxed into DP controller.


Was it? It looks more like it was done to differentiate between eDP and
DP, because internal_hpd is set only if DRM_BRIDGE_OP_HPD is set on the
bridge and we only set the bridge op if the connector type is DP. The
assumption looks like if you have DP connector_type, you have the gpio
pinmuxed for "dp_hot" mode, which isn't exactly true. We don't treat
that gpio as an irq either, because it isn't. Instead the gpio is muxed
to the mdss inside the SoC and then that generates an mdss interrupt
that's combined with non-HPD things like "video ready".

If that all follows, then I don't quite understand why we're setting
internal_hpd to false at all at runtime. It should be set to true at
some point, but ideally that point is during probe.



Kuogee had the same thought originally but were not entirely sure of 
this part of the commit message in Bjorn's original commit which 
introduced these changes.


"This difference is not appropriately represented by the "is_edp"
boolean, but is properly represented by the frameworks invocation of the
hpd_enable() and hpd_disable() callbacks. Switch the current condition
to rely on these callbacks instead"

Does this along with below documentation mean we should generate the hpd 
interrupts only after hpd_enable callback happens?


" * Call _bridge_funcs.hpd_enable if implemented and register the 
given @cb

 * and @data as hot plug notification callback. From now on the @cb will be
 * called with @data when an output status change is detected by the 
bridge,

 * until hot plug notification gets disabled with drm_bridge_hpd_disable().
"

Bjorn, can you please clarify this?


HPD plug/unplug interrupts cannot be enabled until
internal_hpd flag is set to true.
At both bootup and resume time, the DP driver will enable external DP
plugin interrupts and handle plugin interrupt accordingly. Unfortunately
dp_bridge_hpd_enable() bridge ops function was called to set internal_hpd
flag to true later than where DP driver expected during bootup time.

This causes external DP plugin event to not get detected and display stays 
blank.
Move enabling HDP plugin/unplugged interrupts to 
dp_bridge_hpd_enable()/disable() to
set internal_hpd to true along with enabling HPD plugin/unplugged interrupts
simultaneously to avoid timing issue during bootup and resume.

Fixes: cd198caddea7 ("drm/msm/dp: Rely on hpd_enable/disable callbacks")
Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/dp/dp_display.c | 27 ++-
  1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index 3e13acdf..71aa944 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1801,15 +1788,29 @@ void dp_bridge_hpd_enable(struct drm_bridge *bridge)
  {
 struct msm_dp_bridge *dp_bridge = to_dp_bridge(bridge);
 struct msm_dp *dp_display = dp_bridge->dp_display;
+   struct dp_display_private *dp;
+
+   dp = container_of(dp_display, struct dp_display_private, dp_display);

 dp_display->internal_hpd = true;


Can we set internal_hpd to true during probe when we see that the hpd
pinmux exists? Or do any of these bits toggle in the irq status register
when the gpio isn't muxed to "dp_hot" or the controller is for eDP and
it doesn't have any gpio connection internally? I'm wondering if we can
get by with simply enabling the "dp_hot" pin interrupts
(plug/unplug/replug/irq_hpd) unconditionally and not worrying about them
if eDP is there (because the pin doesn't exist inside the SoC), or if DP
HPD is being signalled out of band through type-c framework.


Re: [PATCH] accel/ivpu: Reserve all non-command bo's using DMA_RESV_USAGE_BOOKKEEP

2023-05-10 Thread Jeffrey Hugo

On 4/13/2023 12:38 AM, Stanislaw Gruszka wrote:

Use DMA_RESV_USAGE_BOOKKEEP reservation for buffer objects, except for
command buffers for which we use DMA_RESV_USAGE_WRITE (since VPU can
write to command buffer context save area).

Fixes: 0ec8671837a6 ("accel/ivpu: Fix S3 system suspend when not idle")
Signed-off-by: Stanislaw Gruszka 


I'm pretty new to fences, but this seems sane based on what Daniel 
suggested and what I'm seeing in code.


Reviewed-by: Jeffrey Hugo 


Re: [PATCH v1 1/2] drm/msm/dp: enable HDP plugin/unplugged interrupts to hpd_enable/disable

2023-05-10 Thread Stephen Boyd
Quoting Kuogee Hsieh (2023-05-10 13:31:04)
> The internal_hpd flag was introduced to handle external DP HPD derived from 
> GPIO
> pinmuxed into DP controller.

Was it? It looks more like it was done to differentiate between eDP and
DP, because internal_hpd is set only if DRM_BRIDGE_OP_HPD is set on the
bridge and we only set the bridge op if the connector type is DP. The
assumption looks like if you have DP connector_type, you have the gpio
pinmuxed for "dp_hot" mode, which isn't exactly true. We don't treat
that gpio as an irq either, because it isn't. Instead the gpio is muxed
to the mdss inside the SoC and then that generates an mdss interrupt
that's combined with non-HPD things like "video ready".

If that all follows, then I don't quite understand why we're setting
internal_hpd to false at all at runtime. It should be set to true at
some point, but ideally that point is during probe.

> HPD plug/unplug interrupts cannot be enabled until
> internal_hpd flag is set to true.
> At both bootup and resume time, the DP driver will enable external DP
> plugin interrupts and handle plugin interrupt accordingly. Unfortunately
> dp_bridge_hpd_enable() bridge ops function was called to set internal_hpd
> flag to true later than where DP driver expected during bootup time.
>
> This causes external DP plugin event to not get detected and display stays 
> blank.
> Move enabling HDP plugin/unplugged interrupts to 
> dp_bridge_hpd_enable()/disable() to
> set internal_hpd to true along with enabling HPD plugin/unplugged interrupts
> simultaneously to avoid timing issue during bootup and resume.
>
> Fixes: cd198caddea7 ("drm/msm/dp: Rely on hpd_enable/disable callbacks")
> Signed-off-by: Kuogee Hsieh 
> ---
>  drivers/gpu/drm/msm/dp/dp_display.c | 27 ++-
>  1 file changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 3e13acdf..71aa944 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -1801,15 +1788,29 @@ void dp_bridge_hpd_enable(struct drm_bridge *bridge)
>  {
> struct msm_dp_bridge *dp_bridge = to_dp_bridge(bridge);
> struct msm_dp *dp_display = dp_bridge->dp_display;
> +   struct dp_display_private *dp;
> +
> +   dp = container_of(dp_display, struct dp_display_private, dp_display);
>
> dp_display->internal_hpd = true;

Can we set internal_hpd to true during probe when we see that the hpd
pinmux exists? Or do any of these bits toggle in the irq status register
when the gpio isn't muxed to "dp_hot" or the controller is for eDP and
it doesn't have any gpio connection internally? I'm wondering if we can
get by with simply enabling the "dp_hot" pin interrupts
(plug/unplug/replug/irq_hpd) unconditionally and not worrying about them
if eDP is there (because the pin doesn't exist inside the SoC), or if DP
HPD is being signalled out of band through type-c framework.


Re: [PATCH v1 2/2] drm/msm/dp: add mutex to protect internal_hpd against race condition between different threads

2023-05-10 Thread Abhinav Kumar

Hi Stephen

On 5/10/2023 4:19 PM, Kuogee Hsieh wrote:

internal_hpd is referenced at both plug and unplug handle.

The majority purpose of  mutext is try to serialize internal_hpd between 
dp_bridge_hpd_disable() and either plug or unplug handle.



On 5/10/2023 4:11 PM, Abhinav Kumar wrote:



On 5/10/2023 3:46 PM, Stephen Boyd wrote:

Quoting Kuogee Hsieh (2023-05-10 13:31:05)
Intrenal_hpd is referenced by event thread but set by drm bridge 
callback

context. Add mutex to protect internal_hpd to avoid conflicts between
threads.

Signed-off-by: Kuogee Hsieh 
---


This patch looks completely unnecessary. How can dp_bridge_hpd_enable()
be called at the same time that dp_bridge_hpd_disable() is called or
dp_bridge_hpd_notify() is called? Isn't there locking or ordering at a
higher layer?


Ack. We can drop this patch because we are protected by 
bridge->hpd_mutex in drm_bridge_hpd_enable() / drm_bridge_hpd_disable 
() and drm_bridge_hpd_notify().


I understood now, so what kuogee is referring to is that this 
event_mutex protection is to not protect those 3 calls from each other 
(since they are already protected as we saw above) but because 
dp_hpd_plug_handle/dp_hpd_unplug_handle still uses 
dp_display.internal_hpd to re-enable the hot-plug interrupt, this is 
making sure that flow is protected as well.


Re: [PATCH v1 2/2] drm/msm/dp: add mutex to protect internal_hpd against race condition between different threads

2023-05-10 Thread Kuogee Hsieh

internal_hpd is referenced at both plug and unplug handle.

The majority purpose of  mutext is try to serialize internal_hpd between 
dp_bridge_hpd_disable() and either plug or unplug handle.



On 5/10/2023 4:11 PM, Abhinav Kumar wrote:



On 5/10/2023 3:46 PM, Stephen Boyd wrote:

Quoting Kuogee Hsieh (2023-05-10 13:31:05)
Intrenal_hpd is referenced by event thread but set by drm bridge 
callback

context. Add mutex to protect internal_hpd to avoid conflicts between
threads.

Signed-off-by: Kuogee Hsieh 
---


This patch looks completely unnecessary. How can dp_bridge_hpd_enable()
be called at the same time that dp_bridge_hpd_disable() is called or
dp_bridge_hpd_notify() is called? Isn't there locking or ordering at a
higher layer?


Ack. We can drop this patch because we are protected by 
bridge->hpd_mutex in drm_bridge_hpd_enable() / drm_bridge_hpd_disable 
() and drm_bridge_hpd_notify().


Re: [PATCH v1 2/2] drm/msm/dp: add mutex to protect internal_hpd against race condition between different threads

2023-05-10 Thread Abhinav Kumar




On 5/10/2023 3:46 PM, Stephen Boyd wrote:

Quoting Kuogee Hsieh (2023-05-10 13:31:05)

Intrenal_hpd is referenced by event thread but set by drm bridge callback
context. Add mutex to protect internal_hpd to avoid conflicts between
threads.

Signed-off-by: Kuogee Hsieh 
---


This patch looks completely unnecessary. How can dp_bridge_hpd_enable()
be called at the same time that dp_bridge_hpd_disable() is called or
dp_bridge_hpd_notify() is called? Isn't there locking or ordering at a
higher layer?


Ack. We can drop this patch because we are protected by 
bridge->hpd_mutex in drm_bridge_hpd_enable() / drm_bridge_hpd_disable () 
and drm_bridge_hpd_notify().


[PATCH v9 6/8] drm/msm/dpu: Fix slice_last_group_size calculation

2023-05-10 Thread Jessica Zhang
Correct the math for slice_last_group_size so that it matches the
calculations downstream.

Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 1e11c0fb0545..ddaec05151cd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -56,9 +56,10 @@ static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
if (is_cmd_mode)
initial_lines += 1;
 
-   slice_last_group_size = 3 - (dsc->slice_width % 3);
+   slice_last_group_size = (dsc->slice_width + 2) % 3;
+
data = (initial_lines << 20);
-   data |= ((slice_last_group_size - 1) << 18);
+   data |= (slice_last_group_size << 18);
/* bpp is 6.4 format, 4 LSBs bits are for fractional part */
data |= (dsc->bits_per_pixel << 8);
data |= (dsc->block_pred_enable << 7);

-- 
2.40.1



[PATCH v9 8/8] drm/msm/dsi: update hdisplay calculation for dsi_timing_setup

2023-05-10 Thread Jessica Zhang
hdisplay for compressed images should be calculated as bytes_per_slice *
slice_count. Thus, use MSM DSC helper to calculate hdisplay for
dsi_timing_setup instead of directly using mode->hdisplay.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 508577c596ff..d60403372514 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -952,7 +952,7 @@ static void dsi_timing_setup(struct msm_dsi_host *msm_host, 
bool is_bonded_dsi)
 * pulse width same
 */
h_total -= hdisplay;
-   hdisplay /= 3;
+   hdisplay = msm_dsc_get_bytes_per_line(msm_host->dsc) / 3;
h_total += hdisplay;
ha_end = ha_start + hdisplay;
}

-- 
2.40.1



[PATCH v9 0/8] Introduce MSM-specific DSC helpers

2023-05-10 Thread Jessica Zhang
There are some overlap in calculations for MSM-specific DSC variables
between DP and DSI. In addition, the calculations for initial_scale_value
and det_thresh_flatness that are defined within the DSC 1.2 specifications,
but aren't yet included in drm_dsc_helper.c.

This series moves these calculations to a shared msm_dsc_helper.c file and
defines drm_dsc_helper methods for initial_scale_value and
det_thresh_flatness.

Note: For now, the MSM specific helper methods are only called for the DSI
path, but will called for DP once DSC 1.2 support for DP has been added.

Depends on: "drm/i915: move DSC RC tables to drm_dsc_helper.c" [1]

[1] https://patchwork.freedesktop.org/series/114472/

---
Changes in v9:
- Fixed incorrect math for msm_dsc_get_bytes_per_line()
- Link to v8: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v8-0-2c9b2bb12...@quicinc.com

Changes in v8:
- *_bytes_per_soft_slice --> *_bytes_per_slice
- Fixed comment doc formatting for MSM DSC helpers
- Use slice_chunk_size in msm_dsc_get_bytes_per_line calculation
- Reworded "drm/msm/dpu: Use DRM DSC helper for det_thresh_flatness"
  commit title for clarity
- Picked up "Reviewed-by" tags
- Added duplicate Signed-off-by tag to "drm/display/dsc: Add flatness
  and initial scale value calculations" to reflect patch history
- Link to v7: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v7-0-df48a2c54...@quicinc.com

Changes in v7:
- Renamed msm_dsc_get_pclk_per_intf to msm_dsc_get_bytes_per_line
- Removed duplicate msm_dsc_get_dce_bytes_per_line
- Reworded commit message for "drm/msm/dpu: Use DRM DSC helper for
  det_thresh_flatness"
- Dropped slice_per_pkt change (it will be included in the later
  "Add DSC v1.2 Support for DSI" series)
- Picked up "drm/display/dsc: Add flatness and initial scale value
  calculations" and "drm/display/dsc: add helper to set semi-const
  parameters", which were dropped from "drm/i915: move DSC RC tables to
  drm_dsc_helper.c" series
- Picked up "Reviewed-by" tags
- Removed changelog in individual patches
- Link to v6: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v6-0-cb7f59f0f...@quicinc.com

Changes in v6:
- Documented return values for MSM DSC helpers
- Fixed dependency issue in msm_dsc_helper.c
- Link to v5: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v5-0-0108401d7...@quicinc.com

Changes in v5:
- Added extra line at end of msm_dsc_helper.h
- Simplified msm_dsc_get_bytes_per_soft_slice() math
- Simplified and inlined msm_dsc_get_pclk_per_intf() math
- "Fix calculations pkt_per_line" --> "... Fix calculation for pkt_per_line"
- Split dsc->slice_width check into a separate patch
- Picked up Dmitry's msm/dsi patch ("drm/msm/dsi: use new helpers for
  DSC setup")
- Removed unused headers in MSM DSC helper files
- Picked up Reviewed-by tags
- Link to v4: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v4-0-1b79c78b3...@quicinc.com

Changes in v4:
- Changed msm_dsc_get_uncompressed_pclk_per_intf to msm_dsc_get_pclk_per_intf
- Moved pclk_per_intf calculation for dsi_timing_setup to `if
  (msm_host->dsc)` block
- Link to v3: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v3-0-6bec0d277...@quicinc.com

Changes in v3:
- Dropped src_bpp parameter from all methods -- src_bpp can be
  calculated as dsc->bits_per_component * 3- Cleaned up unused parameters
- Dropped intf_width parameter from get_bytes_per_soft_slice()
- Moved dsc->bits_per_component to numerator calculation in
  get_bytes_per_soft_slice()
- Made get_bytes_per_soft_slice() a public method (this will be called
  later to help calculate DP pclk params)- Added comment documentation to
  MSM DSC helpers
- Renamed msm_dsc_get_uncompressed_pclk_per_line to
  *_get_uncompressed_pclk_per_intf()
- Removed dsc->slice_width check from msm_dsc_get_uncompressed_pclk_per_intf()
- Added documentation in comments
- Moved extra_eol_bytes math out of msm_dsc_get_eol_byte_num()
- Renamed msm_dsc_get_eol_byte_num to *_get_bytes_per_intf.
- Reworded slice_last_group_size calculation to `(dsc->slice_width + 2) % 3`
- Used MSM DSC helper to calculate total_bytes_per_intf
- Initialized hdisplay as uncompressed pclk per line at the beginning of
  dsi_timing_setup as to not break dual DSI calculations
- Added slice_width check to dsi_timing_setup
- Dropped 78c8b81d57d8 ("drm/display/dsc: Add flatness and initial scale
  value calculations") patch as it was absorbed in Dmitry's DSC series [1]
- Split dsi_timing_setup() hdisplay calculation to a separate patch
- Link to v2: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v2-0-3c13ced53...@quicinc.com

Changes in v2:
- Changed det_thresh_flatness to flatness_det_thresh
- Set initial_scale_value directly in helper
- Moved msm_dsc_helper files to msm/ directory
- Dropped get_comp_ratio() helper
- Used drm_int2fixp() to convert to integers to fp
- Fixed type mismatch issues in MSM DSC helpers
- Changed DSC_BPP macro to drm_dsc_get_bpp_int() helper method
- Style changes to improve 

[PATCH v9 4/8] drm/msm: Add MSM-specific DSC helper methods

2023-05-10 Thread Jessica Zhang
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.

Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/Makefile |  1 +
 drivers/gpu/drm/msm/msm_dsc_helper.c | 26 ++
 drivers/gpu/drm/msm/msm_dsc_helper.h | 69 
 3 files changed, 96 insertions(+)

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 7274c41228ed..b814fc80e2d5 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -94,6 +94,7 @@ msm-y += \
msm_atomic_tracepoints.o \
msm_debugfs.o \
msm_drv.o \
+   msm_dsc_helper.o \
msm_fb.o \
msm_fence.o \
msm_gem.o \
diff --git a/drivers/gpu/drm/msm/msm_dsc_helper.c 
b/drivers/gpu/drm/msm/msm_dsc_helper.c
new file mode 100644
index ..094decad9aea
--- /dev/null
+++ b/drivers/gpu/drm/msm/msm_dsc_helper.c
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#include 
+#include 
+
+#include "msm_dsc_helper.h"
+
+s64 msm_dsc_get_bytes_per_slice(struct drm_dsc_config *dsc)
+{
+   return drm_fixp_from_fraction(dsc->slice_width * 
msm_dsc_get_bpp_int(dsc), 8);
+}
+
+u32 msm_dsc_get_bytes_per_intf(struct drm_dsc_config *dsc, int intf_width)
+{
+   u32 bytes_per_slice;
+   s64 bytes_per_slice_fp;
+   int slice_per_intf = msm_dsc_get_slice_per_intf(dsc, intf_width);
+
+   bytes_per_slice_fp = msm_dsc_get_bytes_per_slice(dsc);
+   bytes_per_slice = drm_fixp2int_ceil(bytes_per_slice_fp);
+
+   return bytes_per_slice * slice_per_intf;
+}
diff --git a/drivers/gpu/drm/msm/msm_dsc_helper.h 
b/drivers/gpu/drm/msm/msm_dsc_helper.h
new file mode 100644
index ..ba4c57df9f66
--- /dev/null
+++ b/drivers/gpu/drm/msm/msm_dsc_helper.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#ifndef MSM_DSC_HELPER_H_
+#define MSM_DSC_HELPER_H_
+
+#include 
+#include 
+#include 
+
+/*
+ * Helper methods for MSM specific DSC calculations that are common between 
timing engine,
+ * DSI, and DP.
+ */
+
+/**
+ * msm_dsc_get_bpp_int() - get bits per pixel integer value
+ * @dsc: Pointer to drm dsc config struct
+ * Returns: BPP integer value
+ */
+static inline int msm_dsc_get_bpp_int(struct drm_dsc_config *dsc)
+{
+   WARN_ON_ONCE(dsc->bits_per_pixel & 0xf);
+   return dsc->bits_per_pixel >> 4;
+}
+
+/**
+ * msm_dsc_get_slice_per_intf() - get number of slices per interface
+ * @dsc: Pointer to drm dsc config struct
+ * @intf_width: interface width
+ * Returns: Integer representing the slice per interface
+ */
+static inline int msm_dsc_get_slice_per_intf(struct drm_dsc_config *dsc, int 
intf_width)
+{
+   return DIV_ROUND_UP(intf_width, dsc->slice_width);
+}
+
+/**
+ * msm_dsc_get_bytes_per_line() - Calculate bytes per line
+ * @dsc: Pointer to drm dsc config struct
+ * Returns: Integer value representing pclk per interface
+ *
+ * Note: This value will then be passed along to DSI and DP for some more
+ * calculations. This is because DSI and DP divide the pclk_per_intf value
+ * by different values depending on if widebus is enabled.
+ */
+static inline int msm_dsc_get_bytes_per_line(struct drm_dsc_config *dsc)
+{
+   return dsc->slice_count * dsc->slice_chunk_size;
+}
+
+/**
+ * msm_dsc_get_bytes_per_slice() - get size of each slice for dsc
+ * @dsc: Pointer to drm dsc config struct
+ * Returns: s31.32 fixed point value representing bytes per slice
+ */
+s64 msm_dsc_get_bytes_per_slice(struct drm_dsc_config *dsc);
+
+/**
+ * msm_dsc_get_bytes_per_intf() - get total bytes per interface
+ * @dsc: Pointer to drm dsc config struct
+ * @intf_width: interface width
+ * Returns: u32 value representing bytes per interface
+ */
+u32 msm_dsc_get_bytes_per_intf(struct drm_dsc_config *dsc, int intf_width);
+
+#endif /* MSM_DSC_HELPER_H_ */

-- 
2.40.1



[PATCH v9 3/8] drm/msm/dsi: use DRM DSC helpers for DSC setup

2023-05-10 Thread Jessica Zhang
From: Dmitry Baryshkov 

Use new DRM DSC helpers to setup DSI DSC configuration. The
initial_scale_value needs to be adjusted according to the standard, but
this is a separate change.

Signed-off-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 61 +-
 1 file changed, 8 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 961689a255c4..74d38f90398a 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1731,28 +1731,9 @@ static int dsi_host_parse_lane_data(struct msm_dsi_host 
*msm_host,
return -EINVAL;
 }
 
-static u32 dsi_dsc_rc_buf_thresh[DSC_NUM_BUF_RANGES - 1] = {
-   0x0e, 0x1c, 0x2a, 0x38, 0x46, 0x54, 0x62,
-   0x69, 0x70, 0x77, 0x79, 0x7b, 0x7d, 0x7e
-};
-
-/* only 8bpc, 8bpp added */
-static char min_qp[DSC_NUM_BUF_RANGES] = {
-   0, 0, 1, 1, 3, 3, 3, 3, 3, 3, 5, 5, 5, 7, 13
-};
-
-static char max_qp[DSC_NUM_BUF_RANGES] = {
-   4, 4, 5, 6, 7, 7, 7, 8, 9, 10, 11, 12, 13, 13, 15
-};
-
-static char bpg_offset[DSC_NUM_BUF_RANGES] = {
-   2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -12, -12, -12, -12
-};
-
 static int dsi_populate_dsc_params(struct msm_dsi_host *msm_host, struct 
drm_dsc_config *dsc)
 {
-   int i;
-   u16 bpp = dsc->bits_per_pixel >> 4;
+   int ret;
 
if (dsc->bits_per_pixel & 0xf) {
DRM_DEV_ERROR(_host->pdev->dev, "DSI does not support 
fractional bits_per_pixel\n");
@@ -1764,49 +1745,23 @@ static int dsi_populate_dsc_params(struct msm_dsi_host 
*msm_host, struct drm_dsc
return -EOPNOTSUPP;
}
 
-   dsc->rc_model_size = 8192;
-   dsc->first_line_bpg_offset = 12;
-   dsc->rc_edge_factor = 6;
-   dsc->rc_tgt_offset_high = 3;
-   dsc->rc_tgt_offset_low = 3;
dsc->simple_422 = 0;
dsc->convert_rgb = 1;
dsc->vbr_enable = 0;
 
-   /* handle only bpp = bpc = 8 */
-   for (i = 0; i < DSC_NUM_BUF_RANGES - 1 ; i++)
-   dsc->rc_buf_thresh[i] = dsi_dsc_rc_buf_thresh[i];
+   drm_dsc_set_const_params(dsc);
+   drm_dsc_set_rc_buf_thresh(dsc);
 
-   for (i = 0; i < DSC_NUM_BUF_RANGES; i++) {
-   dsc->rc_range_params[i].range_min_qp = min_qp[i];
-   dsc->rc_range_params[i].range_max_qp = max_qp[i];
-   /*
-* Range BPG Offset contains two's-complement signed values 
that fill
-* 8 bits, yet the registers and DCS PPS field are only 6 bits 
wide.
-*/
-   dsc->rc_range_params[i].range_bpg_offset = bpg_offset[i] & 
DSC_RANGE_BPG_OFFSET_MASK;
+   /* handle only bpp = bpc = 8, pre-SCR panels */
+   ret = drm_dsc_setup_rc_params(dsc, DRM_DSC_1_1_PRE_SCR);
+   if (ret) {
+   DRM_DEV_ERROR(_host->pdev->dev, "could not find DSC RC 
parameters\n");
+   return ret;
}
 
-   dsc->initial_offset = 6144; /* Not bpp 12 */
-   if (bpp != 8)
-   dsc->initial_offset = 2048; /* bpp = 12 */
-
-   if (dsc->bits_per_component <= 10)
-   dsc->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
-   else
-   dsc->mux_word_size = DSC_MUX_WORD_SIZE_12_BPC;
-
-   dsc->initial_xmit_delay = 512;
dsc->initial_scale_value = 32;
-   dsc->first_line_bpg_offset = 12;
dsc->line_buf_depth = dsc->bits_per_component + 1;
 
-   /* bpc 8 */
-   dsc->flatness_min_qp = 3;
-   dsc->flatness_max_qp = 12;
-   dsc->rc_quant_incr_limit0 = 11;
-   dsc->rc_quant_incr_limit1 = 11;
-
return drm_dsc_compute_rc_parameters(dsc);
 }
 

-- 
2.40.1



[PATCH v9 7/8] drm/msm/dsi: Use MSM and DRM DSC helper methods

2023-05-10 Thread Jessica Zhang
Use MSM and DRM DSC helper methods to configure DSC for DSI.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 74d38f90398a..508577c596ff 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -28,6 +28,7 @@
 #include "dsi.xml.h"
 #include "sfpb.xml.h"
 #include "dsi_cfg.h"
+#include "msm_dsc_helper.h"
 #include "msm_kms.h"
 #include "msm_gem.h"
 #include "phy/dsi_phy.h"
@@ -848,7 +849,7 @@ static void dsi_update_dsc_timing(struct msm_dsi_host 
*msm_host, bool is_cmd_mod
/* first calculate dsc parameters and then program
 * compress mode registers
 */
-   slice_per_intf = DIV_ROUND_UP(hdisplay, dsc->slice_width);
+   slice_per_intf = msm_dsc_get_slice_per_intf(dsc, hdisplay);
 
/*
 * If slice_count is greater than slice_per_intf
@@ -858,7 +859,7 @@ static void dsi_update_dsc_timing(struct msm_dsi_host 
*msm_host, bool is_cmd_mod
if (dsc->slice_count > slice_per_intf)
dsc->slice_count = 1;
 
-   total_bytes_per_intf = dsc->slice_chunk_size * slice_per_intf;
+   total_bytes_per_intf = msm_dsc_get_bytes_per_intf(dsc, hdisplay);
 
eol_byte_num = total_bytes_per_intf % 3;
pkt_per_line = slice_per_intf / dsc->slice_count;
@@ -1759,7 +1760,7 @@ static int dsi_populate_dsc_params(struct msm_dsi_host 
*msm_host, struct drm_dsc
return ret;
}
 
-   dsc->initial_scale_value = 32;
+   drm_dsc_set_initial_scale_value(dsc);
dsc->line_buf_depth = dsc->bits_per_component + 1;
 
return drm_dsc_compute_rc_parameters(dsc);

-- 
2.40.1



[PATCH v9 5/8] drm/msm/dpu: Use fixed DRM DSC helper for det_thresh_flatness

2023-05-10 Thread Jessica Zhang
The current dpu_hw_dsc calculation for det_thresh_flatness does not
match the downstream calculation or the DSC spec.

Use the DRM DSC helper for det_thresh_flatness to match downstream
implementation and the DSC spec.

Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 4e1396575e6a..1e11c0fb0545 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -3,6 +3,8 @@
  * Copyright (c) 2020-2022, Linaro Limited
  */
 
+#include 
+
 #include "dpu_kms.h"
 #include "dpu_hw_catalog.h"
 #include "dpu_hwio.h"
@@ -102,7 +104,7 @@ static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
data |= dsc->final_offset;
DPU_REG_WRITE(c, DSC_DSC_OFFSET, data);
 
-   det_thresh_flatness = 7 + 2 * (dsc->bits_per_component - 8);
+   det_thresh_flatness = drm_dsc_calculate_flatness_det_thresh(dsc);
data = det_thresh_flatness << 10;
data |= dsc->flatness_max_qp << 5;
data |= dsc->flatness_min_qp;

-- 
2.40.1



[PATCH v9 2/8] drm/display/dsc: add helper to set semi-const parameters

2023-05-10 Thread Jessica Zhang
From: Dmitry Baryshkov 

Add a helper setting config values which are typically constant across
operating modes (table E-4 of the standard) and mux_word_size (which is
a const according to 3.5.2).

Signed-off-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/display/drm_dsc_helper.c | 22 ++
 include/drm/display/drm_dsc_helper.h |  1 +
 2 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index 65e810a54257..b9c4e10ced41 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -270,6 +270,28 @@ void drm_dsc_pps_payload_pack(struct 
drm_dsc_picture_parameter_set *pps_payload,
 }
 EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
 
+/**
+ * drm_dsc_set_const_params() - Set DSC parameters considered typically
+ * constant across operation modes
+ *
+ * @vdsc_cfg:
+ * DSC Configuration data partially filled by driver
+ */
+void drm_dsc_set_const_params(struct drm_dsc_config *vdsc_cfg)
+{
+   if (!vdsc_cfg->rc_model_size)
+   vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
+   vdsc_cfg->rc_edge_factor = DSC_RC_EDGE_FACTOR_CONST;
+   vdsc_cfg->rc_tgt_offset_high = DSC_RC_TGT_OFFSET_HI_CONST;
+   vdsc_cfg->rc_tgt_offset_low = DSC_RC_TGT_OFFSET_LO_CONST;
+
+   if (vdsc_cfg->bits_per_component <= 10)
+   vdsc_cfg->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
+   else
+   vdsc_cfg->mux_word_size = DSC_MUX_WORD_SIZE_12_BPC;
+}
+EXPORT_SYMBOL(drm_dsc_set_const_params);
+
 /* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
 static const u16 drm_dsc_rc_buf_thresh[] = {
896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index 422135a33d65..bfa7f3acafcb 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -21,6 +21,7 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header 
*pps_header);
 int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
 void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
  const struct drm_dsc_config *dsc_cfg);
+void drm_dsc_set_const_params(struct drm_dsc_config *vdsc_cfg);
 void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
 int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum 
drm_dsc_params_kind kind);
 int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);

-- 
2.40.1



[PATCH v9 1/8] drm/display/dsc: Add flatness and initial scale value calculations

2023-05-10 Thread Jessica Zhang
Add helpers to calculate det_thresh_flatness and initial_scale_value as
these calculations are defined within the DSC spec.

Signed-off-by: Jessica Zhang 
Signed-off-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 include/drm/display/drm_dsc_helper.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index 0bb0c3afd740..422135a33d65 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -25,5 +25,16 @@ void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config 
*vdsc_cfg);
 int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum 
drm_dsc_params_kind kind);
 int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
 
+static inline void drm_dsc_set_initial_scale_value(struct drm_dsc_config *dsc)
+{
+   dsc->initial_scale_value = 8 * dsc->rc_model_size /
+   (dsc->rc_model_size - dsc->initial_offset);
+}
+
+static inline int drm_dsc_calculate_flatness_det_thresh(struct drm_dsc_config 
*dsc)
+{
+   return 2 << (dsc->bits_per_component - 8);
+}
+
 #endif /* _DRM_DSC_HELPER_H_ */
 

-- 
2.40.1



Re: [PATCH v1 2/2] drm/msm/dp: add mutex to protect internal_hpd against race condition between different threads

2023-05-10 Thread Stephen Boyd
Quoting Kuogee Hsieh (2023-05-10 13:31:05)
> Intrenal_hpd is referenced by event thread but set by drm bridge callback
> context. Add mutex to protect internal_hpd to avoid conflicts between
> threads.
>
> Signed-off-by: Kuogee Hsieh 
> ---

This patch looks completely unnecessary. How can dp_bridge_hpd_enable()
be called at the same time that dp_bridge_hpd_disable() is called or
dp_bridge_hpd_notify() is called? Isn't there locking or ordering at a
higher layer?


[PATCH v8 5/8] drm/msm/dpu: Use fixed DRM DSC helper for det_thresh_flatness

2023-05-10 Thread Jessica Zhang
The current dpu_hw_dsc calculation for det_thresh_flatness does not
match the downstream calculation or the DSC spec.

Use the DRM DSC helper for det_thresh_flatness to match downstream
implementation and the DSC spec.

Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 4e1396575e6a..1e11c0fb0545 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -3,6 +3,8 @@
  * Copyright (c) 2020-2022, Linaro Limited
  */
 
+#include 
+
 #include "dpu_kms.h"
 #include "dpu_hw_catalog.h"
 #include "dpu_hwio.h"
@@ -102,7 +104,7 @@ static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
data |= dsc->final_offset;
DPU_REG_WRITE(c, DSC_DSC_OFFSET, data);
 
-   det_thresh_flatness = 7 + 2 * (dsc->bits_per_component - 8);
+   det_thresh_flatness = drm_dsc_calculate_flatness_det_thresh(dsc);
data = det_thresh_flatness << 10;
data |= dsc->flatness_max_qp << 5;
data |= dsc->flatness_min_qp;

-- 
2.40.1



[PATCH v8 8/8] drm/msm/dsi: update hdisplay calculation for dsi_timing_setup

2023-05-10 Thread Jessica Zhang
hdisplay for compressed images should be calculated as bytes_per_slice *
slice_count. Thus, use MSM DSC helper to calculate hdisplay for
dsi_timing_setup instead of directly using mode->hdisplay.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 508577c596ff..d60403372514 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -952,7 +952,7 @@ static void dsi_timing_setup(struct msm_dsi_host *msm_host, 
bool is_bonded_dsi)
 * pulse width same
 */
h_total -= hdisplay;
-   hdisplay /= 3;
+   hdisplay = msm_dsc_get_bytes_per_line(msm_host->dsc) / 3;
h_total += hdisplay;
ha_end = ha_start + hdisplay;
}

-- 
2.40.1



[PATCH v8 4/8] drm/msm: Add MSM-specific DSC helper methods

2023-05-10 Thread Jessica Zhang
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/Makefile |  1 +
 drivers/gpu/drm/msm/msm_dsc_helper.c | 26 ++
 drivers/gpu/drm/msm/msm_dsc_helper.h | 69 
 3 files changed, 96 insertions(+)

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 7274c41228ed..b814fc80e2d5 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -94,6 +94,7 @@ msm-y += \
msm_atomic_tracepoints.o \
msm_debugfs.o \
msm_drv.o \
+   msm_dsc_helper.o \
msm_fb.o \
msm_fence.o \
msm_gem.o \
diff --git a/drivers/gpu/drm/msm/msm_dsc_helper.c 
b/drivers/gpu/drm/msm/msm_dsc_helper.c
new file mode 100644
index ..094decad9aea
--- /dev/null
+++ b/drivers/gpu/drm/msm/msm_dsc_helper.c
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#include 
+#include 
+
+#include "msm_dsc_helper.h"
+
+s64 msm_dsc_get_bytes_per_slice(struct drm_dsc_config *dsc)
+{
+   return drm_fixp_from_fraction(dsc->slice_width * 
msm_dsc_get_bpp_int(dsc), 8);
+}
+
+u32 msm_dsc_get_bytes_per_intf(struct drm_dsc_config *dsc, int intf_width)
+{
+   u32 bytes_per_slice;
+   s64 bytes_per_slice_fp;
+   int slice_per_intf = msm_dsc_get_slice_per_intf(dsc, intf_width);
+
+   bytes_per_slice_fp = msm_dsc_get_bytes_per_slice(dsc);
+   bytes_per_slice = drm_fixp2int_ceil(bytes_per_slice_fp);
+
+   return bytes_per_slice * slice_per_intf;
+}
diff --git a/drivers/gpu/drm/msm/msm_dsc_helper.h 
b/drivers/gpu/drm/msm/msm_dsc_helper.h
new file mode 100644
index ..ed88905c15e5
--- /dev/null
+++ b/drivers/gpu/drm/msm/msm_dsc_helper.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#ifndef MSM_DSC_HELPER_H_
+#define MSM_DSC_HELPER_H_
+
+#include 
+#include 
+#include 
+
+/*
+ * Helper methods for MSM specific DSC calculations that are common between 
timing engine,
+ * DSI, and DP.
+ */
+
+/**
+ * msm_dsc_get_bpp_int() - get bits per pixel integer value
+ * @dsc: Pointer to drm dsc config struct
+ * Returns: BPP integer value
+ */
+static inline int msm_dsc_get_bpp_int(struct drm_dsc_config *dsc)
+{
+   WARN_ON_ONCE(dsc->bits_per_pixel & 0xf);
+   return dsc->bits_per_pixel >> 4;
+}
+
+/**
+ * msm_dsc_get_slice_per_intf() - get number of slices per interface
+ * @dsc: Pointer to drm dsc config struct
+ * @intf_width: interface width
+ * Returns: Integer representing the slice per interface
+ */
+static inline int msm_dsc_get_slice_per_intf(struct drm_dsc_config *dsc, int 
intf_width)
+{
+   return DIV_ROUND_UP(intf_width, dsc->slice_width);
+}
+
+/**
+ * msm_dsc_get_bytes_per_line() - Calculate bytes per line
+ * @dsc: Pointer to drm dsc config struct
+ * Returns: Integer value representing pclk per interface
+ *
+ * Note: This value will then be passed along to DSI and DP for some more
+ * calculations. This is because DSI and DP divide the pclk_per_intf value
+ * by different values depending on if widebus is enabled.
+ */
+static inline int msm_dsc_get_bytes_per_line(struct drm_dsc_config *dsc)
+{
+   return dsc->slice_count * dsc->slice_width;
+}
+
+/**
+ * msm_dsc_get_bytes_per_slice() - get size of each slice for dsc
+ * @dsc: Pointer to drm dsc config struct
+ * Returns: s31.32 fixed point value representing bytes per slice
+ */
+s64 msm_dsc_get_bytes_per_slice(struct drm_dsc_config *dsc);
+
+/**
+ * msm_dsc_get_bytes_per_intf() - get total bytes per interface
+ * @dsc: Pointer to drm dsc config struct
+ * @intf_width: interface width
+ * Returns: u32 value representing bytes per interface
+ */
+u32 msm_dsc_get_bytes_per_intf(struct drm_dsc_config *dsc, int intf_width);
+
+#endif /* MSM_DSC_HELPER_H_ */

-- 
2.40.1



[PATCH v8 6/8] drm/msm/dpu: Fix slice_last_group_size calculation

2023-05-10 Thread Jessica Zhang
Correct the math for slice_last_group_size so that it matches the
calculations downstream.

Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 1e11c0fb0545..ddaec05151cd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -56,9 +56,10 @@ static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
if (is_cmd_mode)
initial_lines += 1;
 
-   slice_last_group_size = 3 - (dsc->slice_width % 3);
+   slice_last_group_size = (dsc->slice_width + 2) % 3;
+
data = (initial_lines << 20);
-   data |= ((slice_last_group_size - 1) << 18);
+   data |= (slice_last_group_size << 18);
/* bpp is 6.4 format, 4 LSBs bits are for fractional part */
data |= (dsc->bits_per_pixel << 8);
data |= (dsc->block_pred_enable << 7);

-- 
2.40.1



[PATCH v8 3/8] drm/msm/dsi: use DRM DSC helpers for DSC setup

2023-05-10 Thread Jessica Zhang
From: Dmitry Baryshkov 

Use new DRM DSC helpers to setup DSI DSC configuration. The
initial_scale_value needs to be adjusted according to the standard, but
this is a separate change.

Signed-off-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 61 +-
 1 file changed, 8 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 961689a255c4..74d38f90398a 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1731,28 +1731,9 @@ static int dsi_host_parse_lane_data(struct msm_dsi_host 
*msm_host,
return -EINVAL;
 }
 
-static u32 dsi_dsc_rc_buf_thresh[DSC_NUM_BUF_RANGES - 1] = {
-   0x0e, 0x1c, 0x2a, 0x38, 0x46, 0x54, 0x62,
-   0x69, 0x70, 0x77, 0x79, 0x7b, 0x7d, 0x7e
-};
-
-/* only 8bpc, 8bpp added */
-static char min_qp[DSC_NUM_BUF_RANGES] = {
-   0, 0, 1, 1, 3, 3, 3, 3, 3, 3, 5, 5, 5, 7, 13
-};
-
-static char max_qp[DSC_NUM_BUF_RANGES] = {
-   4, 4, 5, 6, 7, 7, 7, 8, 9, 10, 11, 12, 13, 13, 15
-};
-
-static char bpg_offset[DSC_NUM_BUF_RANGES] = {
-   2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -12, -12, -12, -12
-};
-
 static int dsi_populate_dsc_params(struct msm_dsi_host *msm_host, struct 
drm_dsc_config *dsc)
 {
-   int i;
-   u16 bpp = dsc->bits_per_pixel >> 4;
+   int ret;
 
if (dsc->bits_per_pixel & 0xf) {
DRM_DEV_ERROR(_host->pdev->dev, "DSI does not support 
fractional bits_per_pixel\n");
@@ -1764,49 +1745,23 @@ static int dsi_populate_dsc_params(struct msm_dsi_host 
*msm_host, struct drm_dsc
return -EOPNOTSUPP;
}
 
-   dsc->rc_model_size = 8192;
-   dsc->first_line_bpg_offset = 12;
-   dsc->rc_edge_factor = 6;
-   dsc->rc_tgt_offset_high = 3;
-   dsc->rc_tgt_offset_low = 3;
dsc->simple_422 = 0;
dsc->convert_rgb = 1;
dsc->vbr_enable = 0;
 
-   /* handle only bpp = bpc = 8 */
-   for (i = 0; i < DSC_NUM_BUF_RANGES - 1 ; i++)
-   dsc->rc_buf_thresh[i] = dsi_dsc_rc_buf_thresh[i];
+   drm_dsc_set_const_params(dsc);
+   drm_dsc_set_rc_buf_thresh(dsc);
 
-   for (i = 0; i < DSC_NUM_BUF_RANGES; i++) {
-   dsc->rc_range_params[i].range_min_qp = min_qp[i];
-   dsc->rc_range_params[i].range_max_qp = max_qp[i];
-   /*
-* Range BPG Offset contains two's-complement signed values 
that fill
-* 8 bits, yet the registers and DCS PPS field are only 6 bits 
wide.
-*/
-   dsc->rc_range_params[i].range_bpg_offset = bpg_offset[i] & 
DSC_RANGE_BPG_OFFSET_MASK;
+   /* handle only bpp = bpc = 8, pre-SCR panels */
+   ret = drm_dsc_setup_rc_params(dsc, DRM_DSC_1_1_PRE_SCR);
+   if (ret) {
+   DRM_DEV_ERROR(_host->pdev->dev, "could not find DSC RC 
parameters\n");
+   return ret;
}
 
-   dsc->initial_offset = 6144; /* Not bpp 12 */
-   if (bpp != 8)
-   dsc->initial_offset = 2048; /* bpp = 12 */
-
-   if (dsc->bits_per_component <= 10)
-   dsc->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
-   else
-   dsc->mux_word_size = DSC_MUX_WORD_SIZE_12_BPC;
-
-   dsc->initial_xmit_delay = 512;
dsc->initial_scale_value = 32;
-   dsc->first_line_bpg_offset = 12;
dsc->line_buf_depth = dsc->bits_per_component + 1;
 
-   /* bpc 8 */
-   dsc->flatness_min_qp = 3;
-   dsc->flatness_max_qp = 12;
-   dsc->rc_quant_incr_limit0 = 11;
-   dsc->rc_quant_incr_limit1 = 11;
-
return drm_dsc_compute_rc_parameters(dsc);
 }
 

-- 
2.40.1



[PATCH v8 0/8] Introduce MSM-specific DSC helpers

2023-05-10 Thread Jessica Zhang
There are some overlap in calculations for MSM-specific DSC variables
between DP and DSI. In addition, the calculations for initial_scale_value
and det_thresh_flatness that are defined within the DSC 1.2 specifications,
but aren't yet included in drm_dsc_helper.c.

This series moves these calculations to a shared msm_dsc_helper.c file and
defines drm_dsc_helper methods for initial_scale_value and
det_thresh_flatness.

Note: For now, the MSM specific helper methods are only called for the DSI
path, but will called for DP once DSC 1.2 support for DP has been added.

Depends on: "drm/i915: move DSC RC tables to drm_dsc_helper.c" [1]

[1] https://patchwork.freedesktop.org/series/114472/

---
Changes in v8:
- *_bytes_per_soft_slice --> *_bytes_per_slice
- Fixed comment doc formatting for MSM DSC helpers
- Use slice_chunk_size in msm_dsc_get_bytes_per_line calculation
- Reworded "drm/msm/dpu: Use DRM DSC helper for det_thresh_flatness"
  commit title for clarity
- Picked up "Reviewed-by" tags
- Added duplicate Signed-off-by tag to "drm/display/dsc: Add flatness
  and initial scale value calculations" to reflect patch history
- Link to v7: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v7-0-df48a2c54...@quicinc.com

Changes in v7:
- Renamed msm_dsc_get_pclk_per_intf to msm_dsc_get_bytes_per_line
- Removed duplicate msm_dsc_get_dce_bytes_per_line
- Reworded commit message for "drm/msm/dpu: Use DRM DSC helper for
  det_thresh_flatness"
- Dropped slice_per_pkt change (it will be included in the later
  "Add DSC v1.2 Support for DSI" series)
- Picked up "drm/display/dsc: Add flatness and initial scale value
  calculations" and "drm/display/dsc: add helper to set semi-const
  parameters", which were dropped from "drm/i915: move DSC RC tables to
  drm_dsc_helper.c" series
- Picked up "Reviewed-by" tags
- Removed changelog in individual patches
- Link to v6: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v6-0-cb7f59f0f...@quicinc.com

Changes in v6:
- Documented return values for MSM DSC helpers
- Fixed dependency issue in msm_dsc_helper.c
- Link to v5: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v5-0-0108401d7...@quicinc.com

Changes in v5:
- Added extra line at end of msm_dsc_helper.h
- Simplified msm_dsc_get_bytes_per_soft_slice() math
- Simplified and inlined msm_dsc_get_pclk_per_intf() math
- "Fix calculations pkt_per_line" --> "... Fix calculation for pkt_per_line"
- Split dsc->slice_width check into a separate patch
- Picked up Dmitry's msm/dsi patch ("drm/msm/dsi: use new helpers for
  DSC setup")
- Removed unused headers in MSM DSC helper files
- Picked up Reviewed-by tags
- Link to v4: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v4-0-1b79c78b3...@quicinc.com

Changes in v4:
- Changed msm_dsc_get_uncompressed_pclk_per_intf to msm_dsc_get_pclk_per_intf
- Moved pclk_per_intf calculation for dsi_timing_setup to `if
  (msm_host->dsc)` block
- Link to v3: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v3-0-6bec0d277...@quicinc.com

Changes in v3:
- Dropped src_bpp parameter from all methods -- src_bpp can be
  calculated as dsc->bits_per_component * 3- Cleaned up unused parameters
- Dropped intf_width parameter from get_bytes_per_soft_slice()
- Moved dsc->bits_per_component to numerator calculation in
  get_bytes_per_soft_slice()
- Made get_bytes_per_soft_slice() a public method (this will be called
  later to help calculate DP pclk params)- Added comment documentation to
  MSM DSC helpers
- Renamed msm_dsc_get_uncompressed_pclk_per_line to
  *_get_uncompressed_pclk_per_intf()
- Removed dsc->slice_width check from msm_dsc_get_uncompressed_pclk_per_intf()
- Added documentation in comments
- Moved extra_eol_bytes math out of msm_dsc_get_eol_byte_num()
- Renamed msm_dsc_get_eol_byte_num to *_get_bytes_per_intf.
- Reworded slice_last_group_size calculation to `(dsc->slice_width + 2) % 3`
- Used MSM DSC helper to calculate total_bytes_per_intf
- Initialized hdisplay as uncompressed pclk per line at the beginning of
  dsi_timing_setup as to not break dual DSI calculations
- Added slice_width check to dsi_timing_setup
- Dropped 78c8b81d57d8 ("drm/display/dsc: Add flatness and initial scale
  value calculations") patch as it was absorbed in Dmitry's DSC series [1]
- Split dsi_timing_setup() hdisplay calculation to a separate patch
- Link to v2: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v2-0-3c13ced53...@quicinc.com

Changes in v2:
- Changed det_thresh_flatness to flatness_det_thresh
- Set initial_scale_value directly in helper
- Moved msm_dsc_helper files to msm/ directory
- Dropped get_comp_ratio() helper
- Used drm_int2fixp() to convert to integers to fp
- Fixed type mismatch issues in MSM DSC helpers
- Changed DSC_BPP macro to drm_dsc_get_bpp_int() helper method
- Style changes to improve readability
- Dropped last division step of msm_dsc_get_pclk_per_line() and changed
  method name accordingly
- Dropped unused bpp variable in msm_dsc_get_dce_bytes_per_line()

[PATCH v8 7/8] drm/msm/dsi: Use MSM and DRM DSC helper methods

2023-05-10 Thread Jessica Zhang
Use MSM and DRM DSC helper methods to configure DSC for DSI.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 74d38f90398a..508577c596ff 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -28,6 +28,7 @@
 #include "dsi.xml.h"
 #include "sfpb.xml.h"
 #include "dsi_cfg.h"
+#include "msm_dsc_helper.h"
 #include "msm_kms.h"
 #include "msm_gem.h"
 #include "phy/dsi_phy.h"
@@ -848,7 +849,7 @@ static void dsi_update_dsc_timing(struct msm_dsi_host 
*msm_host, bool is_cmd_mod
/* first calculate dsc parameters and then program
 * compress mode registers
 */
-   slice_per_intf = DIV_ROUND_UP(hdisplay, dsc->slice_width);
+   slice_per_intf = msm_dsc_get_slice_per_intf(dsc, hdisplay);
 
/*
 * If slice_count is greater than slice_per_intf
@@ -858,7 +859,7 @@ static void dsi_update_dsc_timing(struct msm_dsi_host 
*msm_host, bool is_cmd_mod
if (dsc->slice_count > slice_per_intf)
dsc->slice_count = 1;
 
-   total_bytes_per_intf = dsc->slice_chunk_size * slice_per_intf;
+   total_bytes_per_intf = msm_dsc_get_bytes_per_intf(dsc, hdisplay);
 
eol_byte_num = total_bytes_per_intf % 3;
pkt_per_line = slice_per_intf / dsc->slice_count;
@@ -1759,7 +1760,7 @@ static int dsi_populate_dsc_params(struct msm_dsi_host 
*msm_host, struct drm_dsc
return ret;
}
 
-   dsc->initial_scale_value = 32;
+   drm_dsc_set_initial_scale_value(dsc);
dsc->line_buf_depth = dsc->bits_per_component + 1;
 
return drm_dsc_compute_rc_parameters(dsc);

-- 
2.40.1



[PATCH v8 1/8] drm/display/dsc: Add flatness and initial scale value calculations

2023-05-10 Thread Jessica Zhang
Add helpers to calculate det_thresh_flatness and initial_scale_value as
these calculations are defined within the DSC spec.

Signed-off-by: Jessica Zhang 
Signed-off-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 include/drm/display/drm_dsc_helper.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index 0bb0c3afd740..422135a33d65 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -25,5 +25,16 @@ void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config 
*vdsc_cfg);
 int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum 
drm_dsc_params_kind kind);
 int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
 
+static inline void drm_dsc_set_initial_scale_value(struct drm_dsc_config *dsc)
+{
+   dsc->initial_scale_value = 8 * dsc->rc_model_size /
+   (dsc->rc_model_size - dsc->initial_offset);
+}
+
+static inline int drm_dsc_calculate_flatness_det_thresh(struct drm_dsc_config 
*dsc)
+{
+   return 2 << (dsc->bits_per_component - 8);
+}
+
 #endif /* _DRM_DSC_HELPER_H_ */
 

-- 
2.40.1



[PATCH v8 2/8] drm/display/dsc: add helper to set semi-const parameters

2023-05-10 Thread Jessica Zhang
From: Dmitry Baryshkov 

Add a helper setting config values which are typically constant across
operating modes (table E-4 of the standard) and mux_word_size (which is
a const according to 3.5.2).

Signed-off-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/display/drm_dsc_helper.c | 22 ++
 include/drm/display/drm_dsc_helper.h |  1 +
 2 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index 65e810a54257..b9c4e10ced41 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -270,6 +270,28 @@ void drm_dsc_pps_payload_pack(struct 
drm_dsc_picture_parameter_set *pps_payload,
 }
 EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
 
+/**
+ * drm_dsc_set_const_params() - Set DSC parameters considered typically
+ * constant across operation modes
+ *
+ * @vdsc_cfg:
+ * DSC Configuration data partially filled by driver
+ */
+void drm_dsc_set_const_params(struct drm_dsc_config *vdsc_cfg)
+{
+   if (!vdsc_cfg->rc_model_size)
+   vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
+   vdsc_cfg->rc_edge_factor = DSC_RC_EDGE_FACTOR_CONST;
+   vdsc_cfg->rc_tgt_offset_high = DSC_RC_TGT_OFFSET_HI_CONST;
+   vdsc_cfg->rc_tgt_offset_low = DSC_RC_TGT_OFFSET_LO_CONST;
+
+   if (vdsc_cfg->bits_per_component <= 10)
+   vdsc_cfg->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
+   else
+   vdsc_cfg->mux_word_size = DSC_MUX_WORD_SIZE_12_BPC;
+}
+EXPORT_SYMBOL(drm_dsc_set_const_params);
+
 /* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
 static const u16 drm_dsc_rc_buf_thresh[] = {
896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index 422135a33d65..bfa7f3acafcb 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -21,6 +21,7 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header 
*pps_header);
 int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
 void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
  const struct drm_dsc_config *dsc_cfg);
+void drm_dsc_set_const_params(struct drm_dsc_config *vdsc_cfg);
 void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
 int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum 
drm_dsc_params_kind kind);
 int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);

-- 
2.40.1



Re: [PATCH v7 2/8] drm/display/dsc: add helper to set semi-const parameters

2023-05-10 Thread Jessica Zhang




On 5/9/2023 11:29 PM, Marijn Suijten wrote:

On 2023-05-09 15:06:48, Jessica Zhang wrote:

From: Dmitry Baryshkov 

Add a helper setting config values which are typically constant across
operating modes (table E-4 of the standard) and mux_word_size (which is
a const according to 3.5.2).

Signed-off-by: Dmitry Baryshkov 
Signed-off-by: Jessica Zhang 


Same question about ordering.


Hi Marijn,

This patch was authored by Dmitry and originally part of his DRM DSC 
helpers series [1], but was removed from that series for mergeability 
reasons.


Looking over the kernel documentation, the last Signed-off-by should be 
from the patch submitter [2], so I think my s-o-b tag should be at the 
bottom.


As for the order in the previous patch, I can add a duplicate s-o-b 
before Dmitry's so that it reflects the history of the patch.


Thanks,

Jessica Zhang

[1] https://patchwork.freedesktop.org/patch/530512/?series=114472=4
[2] 
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by




Reviewed-by:  Marijn Suijten 


---
  drivers/gpu/drm/display/drm_dsc_helper.c | 22 ++
  include/drm/display/drm_dsc_helper.h |  1 +
  2 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index 65e810a54257..b9c4e10ced41 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -270,6 +270,28 @@ void drm_dsc_pps_payload_pack(struct 
drm_dsc_picture_parameter_set *pps_payload,
  }
  EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
  
+/**

+ * drm_dsc_set_const_params() - Set DSC parameters considered typically
+ * constant across operation modes
+ *
+ * @vdsc_cfg:
+ * DSC Configuration data partially filled by driver
+ */
+void drm_dsc_set_const_params(struct drm_dsc_config *vdsc_cfg)
+{
+   if (!vdsc_cfg->rc_model_size)
+   vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
+   vdsc_cfg->rc_edge_factor = DSC_RC_EDGE_FACTOR_CONST;
+   vdsc_cfg->rc_tgt_offset_high = DSC_RC_TGT_OFFSET_HI_CONST;
+   vdsc_cfg->rc_tgt_offset_low = DSC_RC_TGT_OFFSET_LO_CONST;
+
+   if (vdsc_cfg->bits_per_component <= 10)
+   vdsc_cfg->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
+   else
+   vdsc_cfg->mux_word_size = DSC_MUX_WORD_SIZE_12_BPC;
+}
+EXPORT_SYMBOL(drm_dsc_set_const_params);
+
  /* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
  static const u16 drm_dsc_rc_buf_thresh[] = {
896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index 422135a33d65..bfa7f3acafcb 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -21,6 +21,7 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header 
*pps_header);
  int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
  void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
  const struct drm_dsc_config *dsc_cfg);
+void drm_dsc_set_const_params(struct drm_dsc_config *vdsc_cfg);
  void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
  int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum 
drm_dsc_params_kind kind);
  int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);

--
2.40.1



Re: [Intel-gfx] [PATCH v9 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP

2023-05-10 Thread Jordan Justen
On 2023-05-10 15:00:03, Teres Alexis, Alan Previn wrote:
> 
> alan:snip
> 
> > This is why I asked if it was it was "basically certain that in a
> > production environment, then it will eventually return 1 meaning it's
> > ready". Alan's response was a little ambiguous on this point.
> alan: if we get a '2' and never transition to '1' - thats a kernel bug or
> firmware / system issue.
> 
> > Arguably a transition from 2 to -ENODEV could be considered a kernel
> > bug, but it doesn't sound like Alan would agree. :) Maybe Alan would
> > agree to saying it's either a kernel, or system integration bug.
> alan: agreed - that would be a kernel bug or a system integration bug.
> 
> I also agreed on the init-flow vs app-usage thoughts Jordan had.
> That said MESA has many ways it can use this UAPI and we can discuss
> that on the MESA patch.
> 
> 
> hmmm.. so... ack anyone? [insert big hopeful smiley here]
> apologies if I am asking too often.

Assuming that:

  2 = PXP feature is supported but should be ready soon (pending
  initialization of non-i915 system dependencies).

really means, "it'll be ready soon or there is a bug somewhere",

Acked-by: Jordan Justen 

If Mesa finds that it can't really rely on that, we may have to decide
on a different approach in how to use that return value.

Is it possible to hold on for another ~12 hours to see if Lionel wants
to Ack as well?

-Jordan


Re: [PATCH v7 4/4] drm/i915: Allow user to set cache at BO creation

2023-05-10 Thread Andi Shyti
Hi,

On Tue, May 09, 2023 at 09:59:42AM -0700, fei.y...@intel.com wrote:
> From: Fei Yang 
> 
> To comply with the design that buffer objects shall have immutable
> cache setting through out their life cycle, {set, get}_caching ioctl's
> are no longer supported from MTL onward. With that change caching
> policy can only be set at object creation time. The current code
> applies a default (platform dependent) cache setting for all objects.
> However this is not optimal for performance tuning. The patch extends
> the existing gem_create uAPI to let user set PAT index for the object
> at creation time.
> The new extension is platform independent, so UMD's can switch to using
> this extension for older platforms as well, while {set, get}_caching are
> still supported on these legacy paltforms for compatibility reason.
> 
> Cc: Chris Wilson 
> Cc: Matt Roper 
> Cc: Andi Shyti 
> Signed-off-by: Fei Yang 
> Reviewed-by: Andi Shyti 

just for a matter of completeness, this is new uapi is tested
through the "create-ext-set-pat" test case from the "gem_create"
igt test[1]. Can any of the igt maintainers give it a look,
comment and ack?

The mesa merge request is here [2]. As there is a merge request
in progress, would anyone from mesa be so kind to give an ack to
this patch, as well?

With the mesa ack in place this patch should be ready to go and
I'm looking forward to having it in.

Thanks,
Andi

[1] https://patchwork.freedesktop.org/patch/534955/?series=117185=1
[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 ++
>  drivers/gpu/drm/i915/gem/i915_gem_object.c |  6 
>  include/uapi/drm/i915_drm.h| 36 ++
>  tools/include/uapi/drm/i915_drm.h  | 36 ++
>  4 files changed, 114 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> index bfe1dbda4cb7..644a936248ad 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> @@ -245,6 +245,7 @@ struct create_ext {
>   unsigned int n_placements;
>   unsigned int placement_mask;
>   unsigned long flags;
> + unsigned int pat_index;
>  };
>  
>  static void repr_placements(char *buf, size_t size,
> @@ -394,11 +395,39 @@ static int ext_set_protected(struct i915_user_extension 
> __user *base, void *data
>   return 0;
>  }
>  
> +static int ext_set_pat(struct i915_user_extension __user *base, void *data)
> +{
> + struct create_ext *ext_data = data;
> + struct drm_i915_private *i915 = ext_data->i915;
> + struct drm_i915_gem_create_ext_set_pat ext;
> + unsigned int max_pat_index;
> +
> + BUILD_BUG_ON(sizeof(struct drm_i915_gem_create_ext_set_pat) !=
> +  offsetofend(struct drm_i915_gem_create_ext_set_pat, rsvd));
> +
> + if (copy_from_user(, base, sizeof(ext)))
> + return -EFAULT;
> +
> + max_pat_index = INTEL_INFO(i915)->max_pat_index;
> +
> + if (ext.pat_index > max_pat_index) {
> + drm_dbg(>drm, "PAT index is invalid: %u\n",
> + ext.pat_index);
> + return -EINVAL;
> + }
> +
> + ext_data->pat_index = ext.pat_index;
> +
> + return 0;
> +}
> +
>  static const i915_user_extension_fn create_extensions[] = {
>   [I915_GEM_CREATE_EXT_MEMORY_REGIONS] = ext_set_placements,
>   [I915_GEM_CREATE_EXT_PROTECTED_CONTENT] = ext_set_protected,
> + [I915_GEM_CREATE_EXT_SET_PAT] = ext_set_pat,
>  };
>  
> +#define PAT_INDEX_NOT_SET0x
>  /**
>   * i915_gem_create_ext_ioctl - Creates a new mm object and returns a handle 
> to it.
>   * @dev: drm device pointer
> @@ -418,6 +447,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
> *data,
>   if (args->flags & ~I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS)
>   return -EINVAL;
>  
> + ext_data.pat_index = PAT_INDEX_NOT_SET;
>   ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
>  create_extensions,
>  ARRAY_SIZE(create_extensions),
> @@ -454,5 +484,11 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
> *data,
>   if (IS_ERR(obj))
>   return PTR_ERR(obj);
>  
> + if (ext_data.pat_index != PAT_INDEX_NOT_SET) {
> + i915_gem_object_set_pat_index(obj, ext_data.pat_index);
> + /* Mark pat_index is set by UMD */
> + obj->pat_set_by_user = true;
> + }
> +
>   return i915_gem_publish(obj, file, >size, >handle);
>  }
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 46a19b099ec8..97ac6fb37958 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -208,6 +208,12 @@ bool i915_gem_object_can_bypass_llc(struct 
> drm_i915_gem_object 

[PATCH v6 8/8] drm/msm/dpu: tear down DSC data path when DSC disabled

2023-05-10 Thread Kuogee Hsieh
Unset DSC_ACTIVE bit at dpu_hw_ctl_reset_intf_cfg_v1(),
dpu_encoder_unprep_dsc() and dpu_encoder_dsc_pipe_clr() functions
to tear down DSC data path if DSC data path was setup previous.

Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 44 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c  |  7 +
 2 files changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 94b805b..6500589 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1214,6 +1214,45 @@ static void dpu_encoder_virt_atomic_enable(struct 
drm_encoder *drm_enc,
mutex_unlock(_enc->enc_lock);
 }
 
+static void dpu_encoder_dsc_pipe_clr(struct dpu_encoder_virt *dpu_enc,
+ struct dpu_hw_dsc *hw_dsc,
+ struct dpu_hw_pingpong *hw_pp)
+{
+   struct dpu_encoder_phys *cur_master = dpu_enc->cur_master;
+   struct dpu_hw_ctl *ctl;
+
+   ctl = cur_master->hw_ctl;
+
+   if (hw_dsc->ops.dsc_disable)
+   hw_dsc->ops.dsc_disable(hw_dsc);
+
+   if (hw_pp->ops.disable_dsc)
+   hw_pp->ops.disable_dsc(hw_pp);
+
+   if (hw_dsc->ops.dsc_bind_pingpong_blk)
+   hw_dsc->ops.dsc_bind_pingpong_blk(hw_dsc, PINGPONG_NONE);
+
+   if (ctl->ops.update_pending_flush_dsc)
+   ctl->ops.update_pending_flush_dsc(ctl, hw_dsc->idx);
+}
+
+static void dpu_encoder_unprep_dsc(struct dpu_encoder_virt *dpu_enc)
+{
+   /* coding only for 2LM, 2enc, 1 dsc config */
+   struct dpu_hw_dsc *hw_dsc[MAX_CHANNELS_PER_ENC];
+   struct dpu_hw_pingpong *hw_pp[MAX_CHANNELS_PER_ENC];
+   int i;
+
+   for (i = 0; i < MAX_CHANNELS_PER_ENC; i++) {
+   hw_pp[i] = dpu_enc->hw_pp[i];
+   hw_dsc[i] = dpu_enc->hw_dsc[i];
+
+   if (hw_pp[i] && hw_dsc[i])
+   dpu_encoder_dsc_pipe_clr(dpu_enc, hw_dsc[i], hw_pp[i]);
+   }
+
+}
+
 static void dpu_encoder_virt_atomic_disable(struct drm_encoder *drm_enc,
struct drm_atomic_state *state)
 {
@@ -2090,6 +2129,9 @@ void dpu_encoder_helper_phys_cleanup(struct 
dpu_encoder_phys *phys_enc)
phys_enc->hw_pp->merge_3d->idx);
}
 
+   if (dpu_enc->dsc)
+   dpu_encoder_unprep_dsc(dpu_enc);
+
intf_cfg.stream_sel = 0; /* Don't care value for video mode */
intf_cfg.mode_3d = dpu_encoder_helper_get_3d_blend_mode(phys_enc);
 
@@ -2101,6 +2143,8 @@ void dpu_encoder_helper_phys_cleanup(struct 
dpu_encoder_phys *phys_enc)
if (phys_enc->hw_pp->merge_3d)
intf_cfg.merge_3d = phys_enc->hw_pp->merge_3d->idx;
 
+   intf_cfg.dsc = dpu_encoder_helper_get_dsc(phys_enc);
+
if (ctl->ops.reset_intf_cfg)
ctl->ops.reset_intf_cfg(ctl, _cfg);
 
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 832a6a7..b34dac5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -577,6 +577,7 @@ static void dpu_hw_ctl_reset_intf_cfg_v1(struct dpu_hw_ctl 
*ctx,
u32 intf_active = 0;
u32 wb_active = 0;
u32 merge3d_active = 0;
+   u32 dsc_active;
 
/*
 * This API resets each portion of the CTL path namely,
@@ -606,6 +607,12 @@ static void dpu_hw_ctl_reset_intf_cfg_v1(struct dpu_hw_ctl 
*ctx,
wb_active &= ~BIT(cfg->wb - WB_0);
DPU_REG_WRITE(c, CTL_WB_ACTIVE, wb_active);
}
+
+   if (cfg->dsc) {
+   dsc_active = DPU_REG_READ(c, CTL_DSC_ACTIVE);
+   dsc_active &= ~cfg->dsc;
+   DPU_REG_WRITE(c, CTL_DSC_ACTIVE, dsc_active);
+   }
 }
 
 static void dpu_hw_ctl_set_fetch_pipe_active(struct dpu_hw_ctl *ctx,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v6 6/8] drm/msm/dpu: separate DSC flush update out of interface

2023-05-10 Thread Kuogee Hsieh
Current DSC flush update is piggyback inside dpu_hw_ctl_intf_cfg_v1().
This patch separates DSC flush away from dpu_hw_ctl_intf_cfg_v1() by
adding dpu_hw_ctl_update_pending_flush_dsc_v1() to handle both per
DSC engine and DSC flush bits at same time to make it consistent with
the location of flush programming of other dpu sub blocks.

Signed-off-by: Kuogee Hsieh 
Reviewed-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 14 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c  | 22 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h  | 10 ++
 3 files changed, 38 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index ffa6f04..94b805b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1834,12 +1834,18 @@ dpu_encoder_dsc_initial_line_calc(struct drm_dsc_config 
*dsc,
return DIV_ROUND_UP(total_pixels, dsc->slice_width);
 }
 
-static void dpu_encoder_dsc_pipe_cfg(struct dpu_hw_dsc *hw_dsc,
+static void dpu_encoder_dsc_pipe_cfg(struct dpu_encoder_virt *dpu_enc,
+struct dpu_hw_dsc *hw_dsc,
 struct dpu_hw_pingpong *hw_pp,
 struct drm_dsc_config *dsc,
 u32 common_mode,
 u32 initial_lines)
 {
+   struct dpu_encoder_phys *cur_master = dpu_enc->cur_master;
+   struct dpu_hw_ctl *ctl;
+
+   ctl = cur_master->hw_ctl;
+
if (hw_dsc->ops.dsc_config)
hw_dsc->ops.dsc_config(hw_dsc, dsc, common_mode, initial_lines);
 
@@ -1854,6 +1860,9 @@ static void dpu_encoder_dsc_pipe_cfg(struct dpu_hw_dsc 
*hw_dsc,
 
if (hw_pp->ops.enable_dsc)
hw_pp->ops.enable_dsc(hw_pp);
+
+   if (ctl->ops.update_pending_flush_dsc)
+   ctl->ops.update_pending_flush_dsc(ctl, hw_dsc->idx);
 }
 
 static void dpu_encoder_prep_dsc(struct dpu_encoder_virt *dpu_enc,
@@ -1898,7 +1907,8 @@ static void dpu_encoder_prep_dsc(struct dpu_encoder_virt 
*dpu_enc,
initial_lines = dpu_encoder_dsc_initial_line_calc(dsc, enc_ip_w);
 
for (i = 0; i < MAX_CHANNELS_PER_ENC; i++)
-   dpu_encoder_dsc_pipe_cfg(hw_dsc[i], hw_pp[i], dsc, 
dsc_common_mode, initial_lines);
+   dpu_encoder_dsc_pipe_cfg(dpu_enc, hw_dsc[i], hw_pp[i], dsc,
+   dsc_common_mode, initial_lines);
 }
 
 void dpu_encoder_prepare_for_kickoff(struct drm_encoder *drm_enc)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 4f7cfa9..832a6a7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -139,6 +139,11 @@ static inline void dpu_hw_ctl_trigger_flush_v1(struct 
dpu_hw_ctl *ctx)
CTL_DSPP_n_FLUSH(dspp - DSPP_0),
ctx->pending_dspp_flush_mask[dspp - DSPP_0]);
}
+
+   if (ctx->pending_flush_mask & BIT(DSC_IDX))
+   DPU_REG_WRITE(>hw, CTL_DSC_FLUSH,
+   ctx->pending_dsc_flush_mask);
+
DPU_REG_WRITE(>hw, CTL_FLUSH, ctx->pending_flush_mask);
 }
 
@@ -285,6 +290,13 @@ static void 
dpu_hw_ctl_update_pending_flush_merge_3d_v1(struct dpu_hw_ctl *ctx,
ctx->pending_flush_mask |= BIT(MERGE_3D_IDX);
 }
 
+static void dpu_hw_ctl_update_pending_flush_dsc_v1(struct dpu_hw_ctl *ctx,
+   enum dpu_dsc dsc_num)
+{
+   ctx->pending_dsc_flush_mask |= BIT(dsc_num - DSC_0);
+   ctx->pending_flush_mask |= BIT(DSC_IDX);
+}
+
 static void dpu_hw_ctl_update_pending_flush_dspp(struct dpu_hw_ctl *ctx,
enum dpu_dspp dspp, u32 dspp_sub_blk)
 {
@@ -502,9 +514,6 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if ((test_bit(DPU_CTL_VM_CFG, >caps->features)))
mode_sel = CTL_DEFAULT_GROUP_ID  << 28;
 
-   if (cfg->dsc)
-   DPU_REG_WRITE(>hw, CTL_DSC_FLUSH, cfg->dsc);
-
if (cfg->intf_mode_sel == DPU_CTL_MODE_SEL_CMD)
mode_sel |= BIT(17);
 
@@ -524,10 +533,8 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
  BIT(cfg->merge_3d - MERGE_3D_0));
-   if (cfg->dsc) {
-   DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
+   if (cfg->dsc)
DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
-   }
 }
 
 static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
@@ -630,6 +637,9 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops,
ops->update_pending_flush_merge_3d =
dpu_hw_ctl_update_pending_flush_merge_3d_v1;
ops->update_pending_flush_wb = 
dpu_hw_ctl_update_pending_flush_wb_v1;
+

[PATCH v6 4/8] drm/msm/dpu: Introduce PINGPONG_NONE to disconnect DSC from PINGPONG

2023-05-10 Thread Kuogee Hsieh
Disabling the crossbar mux between DSC and PINGPONG currently
requires a bogus enum dpu_pingpong value to be passed when calling
dsc_bind_pingpong_blk() with enable=false, even though the register
value written is independent of the current PINGPONG block.  Replace
that `bool enable` parameter with a new PINGPONG_NONE dpu_pingpong
flag that triggers the write of the "special" 0xF "crossbar
disabled" value to the register instead.

Changes in v4:
-- more details to commit text

Changes in v5:
-- rewording commit text suggested by Marijn
-- add DRM_DEBUG_KMS for DSC unbinding case

Signed-off-by: Kuogee Hsieh 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c  | 15 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h  |  1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h |  3 ++-
 4 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index cf1de5d..ffa6f04 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1850,7 +1850,7 @@ static void dpu_encoder_dsc_pipe_cfg(struct dpu_hw_dsc 
*hw_dsc,
hw_pp->ops.setup_dsc(hw_pp);
 
if (hw_dsc->ops.dsc_bind_pingpong_blk)
-   hw_dsc->ops.dsc_bind_pingpong_blk(hw_dsc, true, hw_pp->idx);
+   hw_dsc->ops.dsc_bind_pingpong_blk(hw_dsc, hw_pp->idx);
 
if (hw_pp->ops.enable_dsc)
hw_pp->ops.enable_dsc(hw_pp);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 4a6bbcc..47cb9f3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -157,7 +157,6 @@ static void dpu_hw_dsc_config_thresh(struct dpu_hw_dsc 
*hw_dsc,
 
 static void dpu_hw_dsc_bind_pingpong_blk(
struct dpu_hw_dsc *hw_dsc,
-   bool enable,
const enum dpu_pingpong pp)
 {
struct dpu_hw_blk_reg_map *c = _dsc->hw;
@@ -166,14 +165,16 @@ static void dpu_hw_dsc_bind_pingpong_blk(
 
dsc_ctl_offset = DSC_CTL(hw_dsc->idx);
 
-   if (enable)
+   if (pp)
mux_cfg = (pp - PINGPONG_0) & 0x7;
 
-   DRM_DEBUG_KMS("%s dsc:%d %s pp:%d\n",
-   enable ? "Binding" : "Unbinding",
-   hw_dsc->idx - DSC_0,
-   enable ? "to" : "from",
-   pp - PINGPONG_0);
+   if (pp)
+   DRM_DEBUG_KMS("Binding dsc:%d to pp:%d\n",
+   hw_dsc->idx - DSC_0,
+   pp - PINGPONG_0);
+   else
+   DRM_DEBUG_KMS("Unbinding dsc:%d from any pp\n",
+   hw_dsc->idx - DSC_0);
 
DPU_REG_WRITE(c, dsc_ctl_offset, mux_cfg);
 }
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
index 287ec5f..138080a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
@@ -44,7 +44,6 @@ struct dpu_hw_dsc_ops {
  struct drm_dsc_config *dsc);
 
void (*dsc_bind_pingpong_blk)(struct dpu_hw_dsc *hw_dsc,
- bool enable,
  enum dpu_pingpong pp);
 };
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
index 1913a19..02a0f48 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
@@ -191,7 +191,8 @@ enum dpu_dsc {
 };
 
 enum dpu_pingpong {
-   PINGPONG_0 = 1,
+   PINGPONG_NONE,
+   PINGPONG_0,
PINGPONG_1,
PINGPONG_2,
PINGPONG_3,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v6 7/8] drm/msm/dpu: add DSC 1.2 hw blocks for relevant chipsets

2023-05-10 Thread Kuogee Hsieh
From: Abhinav Kumar 

Add DSC 1.2 hardware blocks to the catalog with necessary sub-block and
feature flag information.  Each display compression engine (DCE) contains
dual hard slice DSC encoders so both share same base address but with
its own different sub block address.

changes in v4:
-- delete DPU_DSC_HW_REV_1_1
-- re arrange sc8280xp_dsc[]

Signed-off-by: Abhinav Kumar 
Signed-off-by: Kuogee Hsieh 
Reviewed-by: Dmitry Baryshkov 
---
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 14 
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h |  7 ++
 .../drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h   | 16 ++
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 14 
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 14 
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 25 +-
 6 files changed, 89 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
index 500cfd0..c4c93c8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
@@ -153,6 +153,18 @@ static const struct dpu_merge_3d_cfg sm8350_merge_3d[] = {
MERGE_3D_BLK("merge_3d_2", MERGE_3D_2, 0x5),
 };
 
+/*
+ * NOTE: Each display compression engine (DCE) contains dual hard
+ * slice DSC encoders so both share same base address but with
+ * its own different sub block address.
+ */
+static const struct dpu_dsc_cfg sm8350_dsc[] = {
+   DSC_BLK_1_2("dce_0", DSC_0, 0x8, 0x100, 0, dsc_sblk_0),
+   DSC_BLK_1_2("dce_0", DSC_1, 0x8, 0x100, 0, dsc_sblk_1),
+   DSC_BLK_1_2("dce_1", DSC_2, 0x81000, 0x100, BIT(DPU_DSC_NATIVE_422_EN), 
dsc_sblk_0),
+   DSC_BLK_1_2("dce_1", DSC_3, 0x81000, 0x100, BIT(DPU_DSC_NATIVE_422_EN), 
dsc_sblk_1),
+};
+
 static const struct dpu_intf_cfg sm8350_intf[] = {
INTF_BLK("intf_0", INTF_0, 0x34000, 0x280, INTF_DP, 
MSM_DP_CONTROLLER_0, 24, INTF_SC7280_MASK,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
@@ -215,6 +227,8 @@ const struct dpu_mdss_cfg dpu_sm8350_cfg = {
.dspp = sm8350_dspp,
.pingpong_count = ARRAY_SIZE(sm8350_pp),
.pingpong = sm8350_pp,
+   .dsc = sm8350_dsc,
+   .dsc_count = ARRAY_SIZE(sm8350_dsc),
.merge_3d_count = ARRAY_SIZE(sm8350_merge_3d),
.merge_3d = sm8350_merge_3d,
.intf_count = ARRAY_SIZE(sm8350_intf),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index 5646713..42c66fe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -93,6 +93,11 @@ static const struct dpu_pingpong_cfg sc7280_pp[] = {
PP_BLK_DITHER("pingpong_3", PINGPONG_3, 0x6c000, 0, sc7280_pp_sblk, -1, 
-1),
 };
 
+/* NOTE: sc7280 only has one dsc hard slice encoder */
+static const struct dpu_dsc_cfg sc7280_dsc[] = {
+   DSC_BLK_1_2("dce_0", DSC_0, 0x8, 0x100, BIT(DPU_DSC_NATIVE_422_EN), 
dsc_sblk_0),
+};
+
 static const struct dpu_intf_cfg sc7280_intf[] = {
INTF_BLK("intf_0", INTF_0, 0x34000, 0x280, INTF_DP, 
MSM_DP_CONTROLLER_0, 24, INTF_SC7280_MASK,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
@@ -149,6 +154,8 @@ const struct dpu_mdss_cfg dpu_sc7280_cfg = {
.mixer = sc7280_lm,
.pingpong_count = ARRAY_SIZE(sc7280_pp),
.pingpong = sc7280_pp,
+   .dsc_count = ARRAY_SIZE(sc7280_dsc),
+   .dsc = sc7280_dsc,
.intf_count = ARRAY_SIZE(sc7280_intf),
.intf = sc7280_intf,
.vbif_count = ARRAY_SIZE(sdm845_vbif),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
index 808aacd..508479f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
@@ -141,6 +141,20 @@ static const struct dpu_merge_3d_cfg sc8280xp_merge_3d[] = 
{
MERGE_3D_BLK("merge_3d_2", MERGE_3D_2, 0x5),
 };
 
+/*
+ * NOTE: Each display compression engine (DCE) contains dual hard
+ * slice DSC encoders so both share same base address but with
+ * its own different sub block address.
+ */
+static const struct dpu_dsc_cfg sc8280xp_dsc[] = {
+   DSC_BLK_1_2("dce_0", DSC_0, 0x8, 0x100, 0, dsc_sblk_0), 
+   DSC_BLK_1_2("dce_0", DSC_1, 0x8, 0x100, 0, dsc_sblk_1), 
+   DSC_BLK_1_2("dce_1", DSC_2, 0x81000, 0x100, BIT(DPU_DSC_NATIVE_422_EN), 
dsc_sblk_0), 
+   DSC_BLK_1_2("dce_1", DSC_3, 0x81000, 0x100, BIT(DPU_DSC_NATIVE_422_EN), 
dsc_sblk_1), 
+   DSC_BLK_1_2("dce_2", DSC_4, 0x82000, 0x100, 0, dsc_sblk_0), 
+   DSC_BLK_1_2("dce_2", DSC_5, 0x82000, 0x100, 0, dsc_sblk_1), 
+};
+
 /* TODO: INTF 3, 8 and 7 are used for MST, marked as INTF_NONE for now */
 static const struct dpu_intf_cfg 

[PATCH v6 5/8] drm/msm/dpu: add support for DSC encoder v1.2 engine

2023-05-10 Thread Kuogee Hsieh
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.

Changes in v3:
-- fixed kernel test rebot report that "__iomem *off" is declared but not
   used at dpu_hw_dsc_config_1_2()
-- unrolling thresh loops

Changes in v4:
-- delete DPU_DSC_HW_REV_1_1
-- delete off and used real register name directly

Reported-by: kernel test robot 
Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/Makefile   |   1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  32 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h |  14 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c | 385 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |   7 +-
 5 files changed, 435 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index b814fc8..b9af5e4 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -65,6 +65,7 @@ msm-$(CONFIG_DRM_MSM_DPU) += \
disp/dpu1/dpu_hw_catalog.o \
disp/dpu1/dpu_hw_ctl.o \
disp/dpu1/dpu_hw_dsc.o \
+   disp/dpu1/dpu_hw_dsc_1_2.o \
disp/dpu1/dpu_hw_interrupts.o \
disp/dpu1/dpu_hw_intf.o \
disp/dpu1/dpu_hw_lm.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index dc0a4da..4eda2cc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 /*
- * Copyright (c) 2022. Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2022-2023, Qualcomm Innovation Center, Inc. All rights 
reserved.
  * Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
  */
 
@@ -244,12 +244,18 @@ enum {
 };
 
 /**
- * DSC features
+ * DSC sub-blocks/features
  * @DPU_DSC_OUTPUT_CTRL   Configure which PINGPONG block gets
  *the pixel output from this DSC.
+ * @DPU_DSC_HW_REV_1_2DSC block supports dsc 1.1 and 1.2
+ * @DPU_DSC_NATIVE_422_EN Supports native422 and native420 encoding
+ * @DPU_DSC_MAX
  */
 enum {
DPU_DSC_OUTPUT_CTRL = 0x1,
+   DPU_DSC_HW_REV_1_2,
+   DPU_DSC_NATIVE_422_EN,
+   DPU_DSC_MAX
 };
 
 /**
@@ -306,6 +312,14 @@ struct dpu_pp_blk {
 };
 
 /**
+ * struct dpu_dsc_blk - DSC Encoder sub-blk information
+ * @info:   HW register and features supported by this sub-blk
+ */
+struct dpu_dsc_blk {
+   DPU_HW_SUBBLK_INFO;
+};
+
+/**
  * enum dpu_qos_lut_usage - define QoS LUT use cases
  */
 enum dpu_qos_lut_usage {
@@ -452,6 +466,17 @@ struct dpu_pingpong_sub_blks {
 };
 
 /**
+ * struct dpu_dsc_sub_blks - DSC sub-blks
+ * @enc: DSC encoder sub block
+ * @ctl: DSC controller sub block
+ *
+ */
+struct dpu_dsc_sub_blks {
+   struct dpu_dsc_blk enc;
+   struct dpu_dsc_blk ctl;
+};
+
+/**
  * dpu_clk_ctrl_type - Defines top level clock control signals
  */
 enum dpu_clk_ctrl_type {
@@ -605,10 +630,13 @@ struct dpu_merge_3d_cfg  {
  * struct dpu_dsc_cfg - information of DSC blocks
  * @id enum identifying this block
  * @base   register offset of this block
+ * @len:   length of hardware block
  * @features   bit mask identifying sub-blocks/features
+ * @sblk   sub-blocks information
  */
 struct dpu_dsc_cfg {
DPU_HW_BLK_INFO;
+   const struct dpu_dsc_sub_blks *sblk;
 };
 
 /**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
index 138080a..bdff74d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
@@ -1,5 +1,8 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
-/* Copyright (c) 2020-2022, Linaro Limited */
+/*
+ * Copyright (c) 2020-2022, Linaro Limited
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
 
 #ifndef _DPU_HW_DSC_H
 #define _DPU_HW_DSC_H
@@ -69,6 +72,15 @@ struct dpu_hw_dsc *dpu_hw_dsc_init(const struct dpu_dsc_cfg 
*cfg,
void __iomem *addr);
 
 /**
+ * dpu_hw_dsc_init_1_2 - initializes the v1.2 DSC hw driver block
+ * @cfg:  DSC catalog entry for which driver object is required
+ * @addr: Mapped register io address of MDP
+ * Returns: Error code or allocated dpu_hw_dsc context
+ */
+struct dpu_hw_dsc *dpu_hw_dsc_init_1_2(const struct dpu_dsc_cfg *cfg,
+   void __iomem *addr);
+
+/**
  * dpu_hw_dsc_destroy - destroys dsc driver context
  * @dsc:   Pointer to dsc driver context returned by dpu_hw_dsc_init
  */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c
new file mode 100644
index ..0c77c85
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c
@@ -0,0 +1,385 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2020-2021, The Linux 

[PATCH v6 3/8] drm/msm/dpu: test DPU_PINGPONG_DSC bit before assign DSC ops to PINGPONG

2023-05-10 Thread Kuogee Hsieh
DPU < 7.0.0 has DPU_PINGPONG_DSC feature bit set to indicate it requires
both dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() to be
executed to complete DSC configuration if DSC hardware block is present.
Hence test DPU_PINGPONG_DSC feature bit and assign DSC related functions
to the ops of PINGPONG block accordingly if DPU_PINGPONG_DSC bit is set.

changes in v6:
-- split patches and keep the function file handles DPU_PINGPONG_DSC bit at 
this patch

Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 79e4576..e7f47a4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -295,6 +295,12 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
c->ops.disable_dsc = dpu_hw_pp_dsc_disable;
 
+   if (test_bit(DPU_PINGPONG_DSC, )) {
+   c->ops.setup_dsc = dpu_hw_pp_setup_dsc;
+   c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
+   c->ops.disable_dsc = dpu_hw_pp_dsc_disable;
+   }
+
if (test_bit(DPU_PINGPONG_DITHER, ))
c->ops.setup_dither = dpu_hw_pp_setup_dither;
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v6 1/8] drm/msm/dpu: add dsc blocks for remaining chipsets in catalog

2023-05-10 Thread Kuogee Hsieh
From: Abhinav Kumar 

There are some platforms has DSC blocks but it is not declared at catalog.
For completeness, this patch adds DSC blocks for platforms which missed
them.

Signed-off-by: Abhinav Kumar 
Reviewed-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h |  7 +++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 11 +++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index c0dd477..521cfd5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -126,6 +126,11 @@ static const struct dpu_pingpong_cfg msm8998_pp[] = {
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
 };
 
+static const struct dpu_dsc_cfg msm8998_dsc[] = {
+   DSC_BLK("dsc_0", DSC_0, 0x8, 0),
+   DSC_BLK("dsc_1", DSC_1, 0x80400, 0),
+};
+
 static const struct dpu_dspp_cfg msm8998_dspp[] = {
DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_MSM8998_MASK,
 _dspp_sblk),
@@ -199,6 +204,8 @@ const struct dpu_mdss_cfg dpu_msm8998_cfg = {
.dspp = msm8998_dspp,
.pingpong_count = ARRAY_SIZE(msm8998_pp),
.pingpong = msm8998_pp,
+   .dsc_count = ARRAY_SIZE(msm8998_dsc),
+   .dsc = msm8998_dsc,
.intf_count = ARRAY_SIZE(msm8998_intf),
.intf = msm8998_intf,
.vbif_count = ARRAY_SIZE(msm8998_vbif),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
index e8057a1..fec1665 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
@@ -142,6 +142,15 @@ static const struct dpu_merge_3d_cfg sc8180x_merge_3d[] = {
MERGE_3D_BLK("merge_3d_2", MERGE_3D_2, 0x83200),
 };
 
+static const struct dpu_dsc_cfg sc8180x_dsc[] = {
+   DSC_BLK("dsc_0", DSC_0, 0x8, BIT(DPU_DSC_OUTPUT_CTRL)),
+   DSC_BLK("dsc_1", DSC_1, 0x80400, BIT(DPU_DSC_OUTPUT_CTRL)),
+   DSC_BLK("dsc_2", DSC_2, 0x80800, BIT(DPU_DSC_OUTPUT_CTRL)),
+   DSC_BLK("dsc_3", DSC_3, 0x80c00, BIT(DPU_DSC_OUTPUT_CTRL)),
+   DSC_BLK("dsc_4", DSC_4, 0x81000, BIT(DPU_DSC_OUTPUT_CTRL)),
+   DSC_BLK("dsc_5", DSC_5, 0x81400, BIT(DPU_DSC_OUTPUT_CTRL)),
+};
+
 static const struct dpu_intf_cfg sc8180x_intf[] = {
INTF_BLK("intf_0", INTF_0, 0x6a000, 0x280, INTF_DP, 
MSM_DP_CONTROLLER_0, 24, INTF_SC7180_MASK,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
@@ -206,6 +215,8 @@ const struct dpu_mdss_cfg dpu_sc8180x_cfg = {
.mixer = sc8180x_lm,
.pingpong_count = ARRAY_SIZE(sc8180x_pp),
.pingpong = sc8180x_pp,
+   .dsc_count = ARRAY_SIZE(sc8180x_dsc),
+   .dsc = sc8180x_dsc,
.merge_3d_count = ARRAY_SIZE(sc8180x_merge_3d),
.merge_3d = sc8180x_merge_3d,
.intf_count = ARRAY_SIZE(sc8180x_intf),
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v6 2/8] drm/msm/dpu: add DPU_PINGPONG_DSC feature bit for DPU < 7.0.0

2023-05-10 Thread Kuogee Hsieh
DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC setting up. Since DPU >= 7.0.0, enabling and starting the DSC
encoder engine moved to INTF with the help of the flush mechanism.
Add a DPU_PINGPONG_DSC feature bit to restrict the availability of
dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() on the
PINGPONG block to DPU < 7.0.0 hardware, as the registers are not
available [in the PINGPONG block] on DPU 7.0.0 and higher anymore.
Existing call-sites to these callbacks already skip calling into
them if the function pointer is NULL. Add DPU_PINGPONG_DSC feature
bit to all chipset with DPU < 7.0.0.

changes in v6:
-- split patches and rearrange to keep catalog related files at this patch

Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +++-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 82b58c6..78e4bf6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -76,13 +76,13 @@
(BIT(DPU_DIM_LAYER) | BIT(DPU_MIXER_COMBINED_ALPHA))
 
 #define PINGPONG_SDM845_MASK \
-   (BIT(DPU_PINGPONG_DITHER) | BIT(DPU_PINGPONG_TE))
+   (BIT(DPU_PINGPONG_DITHER) | BIT(DPU_PINGPONG_TE) | 
BIT(DPU_PINGPONG_DSC))
 
 #define PINGPONG_SDM845_TE2_MASK \
-   (PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
+   (PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2) | BIT(DPU_PINGPONG_DSC))
 
 #define PINGPONG_SM8150_MASK \
-   (BIT(DPU_PINGPONG_DITHER))
+   (BIT(DPU_PINGPONG_DITHER) | BIT(DPU_PINGPONG_DSC))
 
 #define CTL_SC7280_MASK \
(BIT(DPU_CTL_ACTIVE_CFG) | \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 6ee48f0..dc0a4da 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -144,7 +144,8 @@ enum {
  * @DPU_PINGPONG_TE2Additional tear check block for split pipes
  * @DPU_PINGPONG_SPLIT  PP block supports split fifo
  * @DPU_PINGPONG_SLAVE  PP block is a suitable slave for split fifo
- * @DPU_PINGPONG_DITHER,Dither blocks
+ * @DPU_PINGPONG_DITHER Dither blocks
+ * @DPU_PINGPONG_DSCPP ops functions required for DSC
  * @DPU_PINGPONG_MAX
  */
 enum {
@@ -153,6 +154,7 @@ enum {
DPU_PINGPONG_SPLIT,
DPU_PINGPONG_SLAVE,
DPU_PINGPONG_DITHER,
+   DPU_PINGPONG_DSC,
DPU_PINGPONG_MAX
 };
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v6 0/8] add DSC 1.2 dpu supports

2023-05-10 Thread Kuogee Hsieh
This series adds the DPU side changes to support DSC 1.2 encoder. This
was validated with both DSI DSC 1.2 panel and DP DSC 1.2 monitor.
The DSI and DP parts will be pushed later on top of this change.
This seriel is rebase on [1], [2] and catalog fixes from rev-4 of [3].

[1]: https://patchwork.freedesktop.org/series/116851/
[2]: https://patchwork.freedesktop.org/series/116615/
[3]: https://patchwork.freedesktop.org/series/112332/

Abhinav Kumar (2):
  drm/msm/dpu: add dsc blocks for remaining chipsets in catalog
  drm/msm/dpu: add DSC 1.2 hw blocks for relevant chipsets

Kuogee Hsieh (6):
  drm/msm/dpu: add DPU_PINGPONG_DSC feature bit for DPU < 7.0.0
  drm/msm/dpu: test DPU_PINGPONG_DSC bit before assign DSC ops to
PINGPONG
  drm/msm/dpu: Introduce PINGPONG_NONE to disconnect DSC from PINGPONG
  drm/msm/dpu: add support for DSC encoder v1.2 engine
  drm/msm/dpu: separate DSC flush update out of interface
  drm/msm/dpu: tear down DSC data path when DSC disabled

 drivers/gpu/drm/msm/Makefile   |   1 +
 .../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h|   7 +
 .../drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h|  11 +
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h |  14 +
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h |   7 +
 .../drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h   |  16 +
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h |  14 +
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h |  14 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  60 +++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  31 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  36 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c |  29 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h |  10 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c |  15 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h |  15 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c | 385 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h|   3 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c|   6 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |   7 +-
 19 files changed, 654 insertions(+), 27 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc_1_2.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



Re: [Intel-gfx] [PATCH v9 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP

2023-05-10 Thread Teres Alexis, Alan Previn

alan:snip

> This is why I asked if it was it was "basically certain that in a
> production environment, then it will eventually return 1 meaning it's
> ready". Alan's response was a little ambiguous on this point.
alan: if we get a '2' and never transition to '1' - thats a kernel bug or
firmware / system issue.

> Arguably a transition from 2 to -ENODEV could be considered a kernel
> bug, but it doesn't sound like Alan would agree. :) Maybe Alan would
> agree to saying it's either a kernel, or system integration bug.
alan: agreed - that would be a kernel bug or a system integration bug.

I also agreed on the init-flow vs app-usage thoughts Jordan had.
That said MESA has many ways it can use this UAPI and we can discuss
that on the MESA patch.


hmmm.. so... ack anyone? [insert big hopeful smiley here]
apologies if I am asking too often.


Re: [PATCH 03/53] drm/arm/malidp: Convert to platform remove callback returning void

2023-05-10 Thread Liviu Dudau
On Sun, May 07, 2023 at 06:25:26PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
> 
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
> 
> Signed-off-by: Uwe Kleine-König 

Acked-by: Liviu Dudau 

Best regards,
Liviu

> ---
>  drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 589c1c66a6dc..389ef1c3d9b6 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -936,10 +936,9 @@ static int malidp_platform_probe(struct platform_device 
> *pdev)
>  match);
>  }
>  
> -static int malidp_platform_remove(struct platform_device *pdev)
> +static void malidp_platform_remove(struct platform_device *pdev)
>  {
>   component_master_del(>dev, _master_ops);
> - return 0;
>  }
>  
>  static int __maybe_unused malidp_pm_suspend(struct device *dev)
> @@ -982,7 +981,7 @@ static const struct dev_pm_ops malidp_pm_ops = {
>  
>  static struct platform_driver malidp_platform_driver = {
>   .probe  = malidp_platform_probe,
> - .remove = malidp_platform_remove,
> + .remove_new = malidp_platform_remove,
>   .driver = {
>   .name = "mali-dp",
>   .pm = _pm_ops,
> -- 
> 2.39.2
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯


Re: [PATCH 02/53] drm/arm/hdlcd: Convert to platform remove callback returning void

2023-05-10 Thread Liviu Dudau
On Sun, May 07, 2023 at 06:25:25PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
> 
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
> 
> Signed-off-by: Uwe Kleine-König 

Acked-by: Liviu Dudau 

Best regards,
Liviu

> ---
>  drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index e3507dd6f82a..5e265c81a1b3 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -369,10 +369,9 @@ static int hdlcd_probe(struct platform_device *pdev)
>  match);
>  }
>  
> -static int hdlcd_remove(struct platform_device *pdev)
> +static void hdlcd_remove(struct platform_device *pdev)
>  {
>   component_master_del(>dev, _master_ops);
> - return 0;
>  }
>  
>  static const struct of_device_id  hdlcd_of_match[] = {
> @@ -401,7 +400,7 @@ static SIMPLE_DEV_PM_OPS(hdlcd_pm_ops, hdlcd_pm_suspend, 
> hdlcd_pm_resume);
>  
>  static struct platform_driver hdlcd_platform_driver = {
>   .probe  = hdlcd_probe,
> - .remove = hdlcd_remove,
> + .remove_new = hdlcd_remove,
>   .driver = {
>   .name = "hdlcd",
>   .pm = _pm_ops,
> -- 
> 2.39.2
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯


Re: [Intel-gfx] [PATCH v9 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP

2023-05-10 Thread Jordan Justen
...fixing some Cc email addresses I somehow mangled.

On 2023-05-10 12:40:07, Souza, Jose wrote:
> On Mon, 2023-05-08 at 17:49 +, Teres Alexis, Alan Previn wrote:
> > On Fri, 2023-05-05 at 00:39 -0700, Justen, Jordan L wrote:
> > > On 2023-05-04 22:30:07, Teres Alexis, Alan Previn wrote:
> > > > On Thu, 2023-04-27 at 16:48 -0700, Teres Alexis, Alan Previn wrote:
> > > > > Because of the additional firmware, component-driver and
> > > > > initialization depedencies required on MTL platform before a
> > > > > PXP context can be created, UMD calling for PXP creation as a
> > > > > way to get-caps can take a long time. An actual real world
> > > > > customer stack has seen this happen in the 4-to-8 second range
> > > > > after the kernel starts (which sees MESA's init appear in the
> > > > > middle of this range as the compositor comes up). To avoid
> > > > > unncessary delays experienced by the UMD for get-caps purposes,
> > > > > add a GET_PARAM for I915_PARAM_PXP_SUPPORT.
> > > > > 
> > > > alan:snip.
> > > > Progress update on the UMD side - I'm working on patch for PR here: 
> > > > https://gitlab.freedesktop.org/alan_previn_intel/mesa-alan-previn-features/-/commit/fb9d4fbfbef7dfd3f41df335cd31549fd39ddb57
> > > > but taking time to verify certain code paths
> > > 
> > > Just to confirm, if I915_PARAM_PXP_STATUS returns 2 ("will be ready
> > > soon"), then it is basically certain that in a production environment,
> > > then it will eventually return 1 meaning it's ready, right?
> > alan: yes - but not 100%. non-platform-state-machine could still
> > cause unexpected failures for example, [1] if hw was fused in a way
> > that doesnt permit PXP or [2] enabling certain BIOS debug knobs
> > doesnt allow PXP. However at the moment, there is no way for us
> > to know for sure without actually creating a protected context.
> > Of course having hw-fusing + bios-config that supports PXP have
> > always 100% succeeded for me.
> 
> In my opinion it is problematic mark that we support protected
> context but then it fails to create protected context.

This is why I asked if it was it was "basically certain that in a
production environment, then it will eventually return 1 meaning it's
ready". Alan's response was a little ambiguous on this point.

But, considering the number of applications that will need this
feature is low, combined with an extremely low chance that the kernel
will end up going from 2 (will be ready soon) to -ENODEV (will never
work), well, it seems worth considering advertising it with no delay
even if it later fails if used.

Arguably a transition from 2 to -ENODEV could be considered a kernel
bug, but it doesn't sound like Alan would agree. :) Maybe Alan would
agree to saying it's either a kernel, or system integration bug.

I think it'd also be ok if we didn't advertise support if an
application starts when the kernel is still in the 2 (will be ready
soon) state.

But, some environments might prefer to wait, so I think the kernel
uapi should stay as Alan has it now so we have the flexibility to
potentially accommodate this. (Perhaps with driconf, or a build flag,
or an env-var.)

-Jordan


Re: [PATCH 01/53] drm/komeda: Convert to platform remove callback returning void

2023-05-10 Thread Liviu Dudau
On Sun, May 07, 2023 at 06:25:24PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
> 
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
> 
> Signed-off-by: Uwe Kleine-König 

Acked-by: Liviu Dudau 

Thanks for the clean up!

Best regards,
Liviu

> ---
>  drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> index 28f76e07dd95..c597c362f689 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> @@ -131,10 +131,9 @@ static int komeda_platform_probe(struct platform_device 
> *pdev)
>   return component_master_add_with_match(dev, _master_ops, match);
>  }
>  
> -static int komeda_platform_remove(struct platform_device *pdev)
> +static void komeda_platform_remove(struct platform_device *pdev)
>  {
>   component_master_del(>dev, _master_ops);
> - return 0;
>  }
>  
>  static const struct of_device_id komeda_of_match[] = {
> @@ -189,7 +188,7 @@ static const struct dev_pm_ops komeda_pm_ops = {
>  
>  static struct platform_driver komeda_platform_driver = {
>   .probe  = komeda_platform_probe,
> - .remove = komeda_platform_remove,
> + .remove_new = komeda_platform_remove,
>   .driver = {
>   .name = "komeda",
>   .of_match_table = komeda_of_match,
> -- 
> 2.39.2
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯


Re: [PATCH v7 4/8] drm/msm: Add MSM-specific DSC helper methods

2023-05-10 Thread Jessica Zhang




On 5/9/2023 11:33 PM, Marijn Suijten wrote:

On 2023-05-09 15:06:50, Jessica Zhang wrote:

Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Jessica Zhang 
---
  drivers/gpu/drm/msm/Makefile |  1 +
  drivers/gpu/drm/msm/msm_dsc_helper.c | 26 ++
  drivers/gpu/drm/msm/msm_dsc_helper.h | 69 
  3 files changed, 96 insertions(+)

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 7274c41228ed..b814fc80e2d5 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -94,6 +94,7 @@ msm-y += \
msm_atomic_tracepoints.o \
msm_debugfs.o \
msm_drv.o \
+   msm_dsc_helper.o \
msm_fb.o \
msm_fence.o \
msm_gem.o \
diff --git a/drivers/gpu/drm/msm/msm_dsc_helper.c 
b/drivers/gpu/drm/msm/msm_dsc_helper.c
new file mode 100644
index ..29feb3e3b5a4
--- /dev/null
+++ b/drivers/gpu/drm/msm/msm_dsc_helper.c
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#include 
+#include 
+
+#include "msm_dsc_helper.h"
+
+s64 msm_dsc_get_bytes_per_soft_slice(struct drm_dsc_config *dsc)
+{
+   return drm_fixp_from_fraction(dsc->slice_width * 
msm_dsc_get_bpp_int(dsc), 8);


How about using dsc->slice_chunk_size?


Hi Marijn,

Thanks for pointing this out. However, I would prefer to keep this fixed 
point version of the slice_chunk_size math as the downstream DP math 
also uses fixed point [1].


If we are able to confirm that integer math also works for DP, we will 
make the change to use slice_chunk_size within the DP DSC series.


I also want to note that this math has stayed the same throughout all 7 
revisions. In the interest of making review more efficient, I think it 
would be helpful to point out important details like this early on in 
the process. That way we can address major concerns early on and keep 
the number of revisions per series low.


[1] 
https://github.com/ianmacd/gts6lwifi/blob/master/drivers/gpu/drm/msm/dp/dp_panel.c#L335





+}
+
+u32 msm_dsc_get_bytes_per_intf(struct drm_dsc_config *dsc, int intf_width)
+{
+   u32 bytes_per_soft_slice;
+   s64 bytes_per_soft_slice_fp;
+   int slice_per_intf = msm_dsc_get_slice_per_intf(dsc, intf_width);
+
+   bytes_per_soft_slice_fp = msm_dsc_get_bytes_per_soft_slice(dsc);
+   bytes_per_soft_slice = drm_fixp2int_ceil(bytes_per_soft_slice_fp);
+
+   return bytes_per_soft_slice * slice_per_intf;
+}
diff --git a/drivers/gpu/drm/msm/msm_dsc_helper.h 
b/drivers/gpu/drm/msm/msm_dsc_helper.h
new file mode 100644
index ..38f3651d0b79
--- /dev/null
+++ b/drivers/gpu/drm/msm/msm_dsc_helper.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#ifndef MSM_DSC_HELPER_H_
+#define MSM_DSC_HELPER_H_
+
+#include 
+#include 
+#include 
+
+/*
+ * Helper methods for MSM specific DSC calculations that are common between 
timing engine,
+ * DSI, and DP.
+ */
+
+/**
+ * msm_dsc_get_bpp_int - get bits per pixel integer value


For all function docs, don't forget the trailing parenthesis after the
function name: msm_dsc_get_bpp_int()

https://www.kernel.org/doc/html/next/doc-guide/kernel-doc.html#function-documentation


Acked.




+ * @dsc: Pointer to drm dsc config struct
+ * Returns: BPP integer value
+ */
+static inline int msm_dsc_get_bpp_int(struct drm_dsc_config *dsc)
+{
+   WARN_ON_ONCE(dsc->bits_per_pixel & 0xf);
+   return dsc->bits_per_pixel >> 4;
+}
+
+/**
+ * msm_dsc_get_slice_per_intf - get number of slices per interface
+ * @dsc: Pointer to drm dsc config struct
+ * @intf_width: interface width
+ * Returns: Integer representing the slice per interface
+ */
+static inline int msm_dsc_get_slice_per_intf(struct drm_dsc_config *dsc, int 
intf_width)
+{
+   return DIV_ROUND_UP(intf_width, dsc->slice_width);


Looks good.


+}
+
+/**
+ * msm_dsc_get_bytes_per_line - Calculate bytes per line
+ * @dsc: Pointer to drm dsc config struct
+ * Returns: Integer value representing pclk per interface
+ *
+ * Note: This value will then be passed along to DSI and DP for some more
+ * calculations. This is because DSI and DP divide the pclk_per_intf value
+ * by different values depending on if widebus is enabled.
+ */
+static inline int msm_dsc_get_bytes_per_line(struct drm_dsc_config *dsc)
+{
+   return DIV_ROUND_UP(dsc->slice_width * dsc->slice_count * 
msm_dsc_get_bpp_int(dsc), 8);


dsc->slice_chunk_size * dsc->slice_count?


Acked.




+}
+
+/**
+ * msm_dsc_get_bytes_per_soft_slice - get size of each soft slice for dsc


Explain to the reader what a "soft" slice is?


A soft slice is a slice defined in software as opposed to "hard slices" 
that are defined by hardware.


Since the slice-related 

[PATCH] drm/i1915/guc: Fix probe injection CI failures after recent change

2023-05-10 Thread John . C . Harrison
From: John Harrison 

A recent change bumped a 'notice' message up to 'error' level for
debug builds to help trap incorrect configurations in CI systems.
Unfortunaetly, tha error condition in question is triggered by the
error injection probe test. So change the message again to be 'probe
error' level instead.

Signed-off-by: John Harrison 
Fixes: 760133d42f0a ("drm/i915/uc: Make unexpected firmware versions an error 
in debug builds")
Cc: John Harrison 
Cc: Daniele Ceraolo Spurio 
Cc: Rodrigo Vivi 
Cc: Alan Previn 
Cc: Lucas De Marchi 
Cc: Jani Nikula 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 4ec7df9ed5ff3..e467d9af61876 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -18,7 +18,7 @@
 #include "i915_reg.h"
 
 #if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
-#define UNEXPECTED gt_err
+#define UNEXPECTED gt_probe_error
 #else
 #define UNEXPECTED gt_notice
 #endif
-- 
2.39.1



Re: [Intel-xe] [PATCH 0/2] drm/xe: Fix unprotected rebind_list accesses

2023-05-10 Thread Souza, Jose
On Wed, 2023-05-10 at 16:19 +0200, Thomas Hellström wrote:
> Each VM has two rebind lists, one protected by the VM resv, the other
> one protected essentially by the VM notifier.list_lock. This series
> intends to fix two points of illegal access.
> 
> Patch 1 fixes an access of VM rebind_lists' link without the VM resv held.
> Patch 2 fixes an issue where the VMA may not be removed from the
> VM notifier.rebind_list on VMA destruction.

Tested-by: José Roberto de Souza 

This improved overall stability and fixed the 'list_add corruption' errors, 
thank you.

> 
> Thomas Hellström (2):
>   drm/xe: Fix unlocked access of the vma::rebind_link
>   drm/xe: Properly remove the vma from the vm::notifer::rebind_list when
> destroyed
> 
>  drivers/gpu/drm/xe/xe_vm.c | 23 ---
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 



[PATCH v1 2/2] drm/msm/dp: add mutex to protect internal_hpd against race condition between different threads

2023-05-10 Thread Kuogee Hsieh
Intrenal_hpd is referenced by event thread but set by drm bridge callback
context. Add mutex to protect internal_hpd to avoid conflicts between
threads.

Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/dp/dp_display.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index 71aa944..b59ea7a 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1792,11 +1792,13 @@ void dp_bridge_hpd_enable(struct drm_bridge *bridge)
 
dp = container_of(dp_display, struct dp_display_private, dp_display);
 
+   mutex_lock(>event_mutex);
dp_display->internal_hpd = true;
dp_catalog_hpd_config_intr(dp->catalog,
DP_DP_HPD_PLUG_INT_MASK |
DP_DP_HPD_UNPLUG_INT_MASK,
true);
+   mutex_unlock(>event_mutex);
 }
 
 void dp_bridge_hpd_disable(struct drm_bridge *bridge)
@@ -1807,11 +1809,13 @@ void dp_bridge_hpd_disable(struct drm_bridge *bridge)
 
dp = container_of(dp_display, struct dp_display_private, dp_display);
 
+   mutex_lock(>event_mutex);
dp_catalog_hpd_config_intr(dp->catalog,
DP_DP_HPD_PLUG_INT_MASK |
DP_DP_HPD_UNPLUG_INT_MASK,
false);
dp_display->internal_hpd = false;
+   mutex_unlock(>event_mutex);
 }
 
 void dp_bridge_hpd_notify(struct drm_bridge *bridge,
@@ -1822,8 +1826,12 @@ void dp_bridge_hpd_notify(struct drm_bridge *bridge,
struct dp_display_private *dp = container_of(dp_display, struct 
dp_display_private, dp_display);
 
/* Without next_bridge interrupts are handled by the DP core directly */
-   if (dp_display->internal_hpd)
+   mutex_lock(>event_mutex);
+   if (dp_display->internal_hpd) {
+   mutex_unlock(>event_mutex);
return;
+   }
+   mutex_unlock(>event_mutex);
 
if (!dp->core_initialized) {
drm_dbg_dp(dp->drm_dev, "not initialized\n");
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v1 0/2] enable HDP plugin/unplugged interrupts to hpd_enable/disable

2023-05-10 Thread Kuogee Hsieh
There is bug report on exteranl DP display does not work.
This patch add below two patches to fix the problem.
1) enable HDP plugin/unplugged interrupts to hpd_enable/disable
2) add mutex to protect internal_hpd against race condition between different 
threads


Kuogee Hsieh (2):
  drm/msm/dp: enable HDP plugin/unplugged interrupts to
hpd_enable/disable
  drm/msm/dp: add mutex to protect internal_hpd against race condition
between different threads

 drivers/gpu/drm/msm/dp/dp_display.c | 37 +++--
 1 file changed, 23 insertions(+), 14 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v1 1/2] drm/msm/dp: enable HDP plugin/unplugged interrupts to hpd_enable/disable

2023-05-10 Thread Kuogee Hsieh
The internal_hpd flag was introduced to handle external DP HPD derived from GPIO
pinmuxed into DP controller. HPD plug/unplug interrupts cannot be enabled until
internal_hpd flag is set to true.
At both bootup and resume time, the DP driver will enable external DP
plugin interrupts and handle plugin interrupt accordingly. Unfortunately
dp_bridge_hpd_enable() bridge ops function was called to set internal_hpd
flag to true later than where DP driver expected during bootup time.

This causes external DP plugin event to not get detected and display stays 
blank.
Move enabling HDP plugin/unplugged interrupts to 
dp_bridge_hpd_enable()/disable() to
set internal_hpd to true along with enabling HPD plugin/unplugged interrupts
simultaneously to avoid timing issue during bootup and resume.

Fixes: cd198caddea7 ("drm/msm/dp: Rely on hpd_enable/disable callbacks")
Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/dp/dp_display.c | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index 3e13acdf..71aa944 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1088,13 +1088,6 @@ static void dp_display_config_hpd(struct 
dp_display_private *dp)
dp_display_host_init(dp);
dp_catalog_ctrl_hpd_config(dp->catalog);
 
-   /* Enable plug and unplug interrupts only if requested */
-   if (dp->dp_display.internal_hpd)
-   dp_catalog_hpd_config_intr(dp->catalog,
-   DP_DP_HPD_PLUG_INT_MASK |
-   DP_DP_HPD_UNPLUG_INT_MASK,
-   true);
-
/* Enable interrupt first time
 * we are leaving dp clocks on during disconnect
 * and never disable interrupt
@@ -1396,12 +1389,6 @@ static int dp_pm_resume(struct device *dev)
 
dp_catalog_ctrl_hpd_config(dp->catalog);
 
-   if (dp->dp_display.internal_hpd)
-   dp_catalog_hpd_config_intr(dp->catalog,
-   DP_DP_HPD_PLUG_INT_MASK |
-   DP_DP_HPD_UNPLUG_INT_MASK,
-   true);
-
if (dp_catalog_link_is_connected(dp->catalog)) {
/*
 * set sink to normal operation mode -- D0
@@ -1801,15 +1788,29 @@ void dp_bridge_hpd_enable(struct drm_bridge *bridge)
 {
struct msm_dp_bridge *dp_bridge = to_dp_bridge(bridge);
struct msm_dp *dp_display = dp_bridge->dp_display;
+   struct dp_display_private *dp;
+
+   dp = container_of(dp_display, struct dp_display_private, dp_display);
 
dp_display->internal_hpd = true;
+   dp_catalog_hpd_config_intr(dp->catalog,
+   DP_DP_HPD_PLUG_INT_MASK |
+   DP_DP_HPD_UNPLUG_INT_MASK,
+   true);
 }
 
 void dp_bridge_hpd_disable(struct drm_bridge *bridge)
 {
struct msm_dp_bridge *dp_bridge = to_dp_bridge(bridge);
struct msm_dp *dp_display = dp_bridge->dp_display;
+   struct dp_display_private *dp;
+
+   dp = container_of(dp_display, struct dp_display_private, dp_display);
 
+   dp_catalog_hpd_config_intr(dp->catalog,
+   DP_DP_HPD_PLUG_INT_MASK |
+   DP_DP_HPD_UNPLUG_INT_MASK,
+   false);
dp_display->internal_hpd = false;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v4] console/parisc: Fix STI console on 64-bit only machines

2023-05-10 Thread Helge Deller
Fix the STI console to be able to execute either the 64-bit STI ROM code
or the 32-bit STI ROM code.

This is necessary on 64-bit only machines (e.g. C8000 workstation) which
otherwise won't show the STI text console with HP graphic cards like
Visualize-FX5/FX10/FXe.

When calling 32-bit code from a 64-bit kernel one may need to copy
contents on the CPU stack from high memory down below the 4GB limit.

Signed-off-by: Helge Deller 
---
 arch/parisc/include/asm/pdc.h |   4 +-
 arch/parisc/kernel/firmware.c |  21 +++--
 drivers/video/fbdev/stifb.c   |   4 +-
 drivers/video/sticore.c   | 159 ++
 include/video/sticore.h   |  42 -
 5 files changed, 143 insertions(+), 87 deletions(-)

v4: resend to avoid merge conflicts, no code changes
v3: Fix check for overflow of 32-bit pointers
v2: Forward-ported to apply cleanly on drm-misc-next git tree

diff --git a/arch/parisc/include/asm/pdc.h b/arch/parisc/include/asm/pdc.h
index 2b4fad8328e8..269b9a159f01 100644
--- a/arch/parisc/include/asm/pdc.h
+++ b/arch/parisc/include/asm/pdc.h
@@ -88,8 +88,8 @@ int pdc_iodc_print(const unsigned char *str, unsigned count);

 void pdc_emergency_unlock(void);
 int pdc_sti_call(unsigned long func, unsigned long flags,
- unsigned long inptr, unsigned long outputr,
- unsigned long glob_cfg);
+   unsigned long inptr, unsigned long outputr,
+   unsigned long glob_cfg, int do_call64);

 int __pdc_cpu_rendezvous(void);
 void pdc_cpu_rendezvous_lock(void);
diff --git a/arch/parisc/kernel/firmware.c b/arch/parisc/kernel/firmware.c
index cc124d9f1f7f..71ef1640db5a 100644
--- a/arch/parisc/kernel/firmware.c
+++ b/arch/parisc/kernel/firmware.c
@@ -1389,17 +1389,24 @@ int pdc_iodc_getc(void)
 }

 int pdc_sti_call(unsigned long func, unsigned long flags,
- unsigned long inptr, unsigned long outputr,
- unsigned long glob_cfg)
+   unsigned long inptr, unsigned long outputr,
+   unsigned long glob_cfg, int do_call64)
 {
-int retval;
+   int retval = 0;
unsigned long irqflags;

-spin_lock_irqsave(_lock, irqflags);
-retval = real32_call(func, flags, inptr, outputr, glob_cfg);
-spin_unlock_irqrestore(_lock, irqflags);
+   spin_lock_irqsave(_lock, irqflags);
+   if (IS_ENABLED(CONFIG_64BIT) && do_call64) {
+#ifdef CONFIG_64BIT
+   retval = real64_call(func, flags, inptr, outputr, glob_cfg);
+#else
+   WARN_ON(1);
+#endif
+   } else
+   retval = real32_call(func, flags, inptr, outputr, glob_cfg);
+   spin_unlock_irqrestore(_lock, irqflags);

-return retval;
+   return retval;
 }
 EXPORT_SYMBOL(pdc_sti_call);

diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c
index baca6974e288..fe54ca8726e6 100644
--- a/drivers/video/fbdev/stifb.c
+++ b/drivers/video/fbdev/stifb.c
@@ -71,9 +71,9 @@

 #include 

-/* REGION_BASE(fb_info, index) returns the virtual address for region  
*/
+/* REGION_BASE(fb_info, index) returns the physical address for region  
*/
 #define REGION_BASE(fb_info, index) \
-   F_EXTEND(fb_info->sti->glob_cfg->region_ptrs[index])
+   F_EXTEND(fb_info->sti->regions_phys[index])

 #define NGLEDEVDEPROM_CRT_REGION 1

diff --git a/drivers/video/sticore.c b/drivers/video/sticore.c
index 7eb925f2ba9c..1f55cf150b96 100644
--- a/drivers/video/sticore.c
+++ b/drivers/video/sticore.c
@@ -4,7 +4,7 @@
  * core code for console driver using HP's STI firmware
  *
  * Copyright (C) 2000 Philipp Rumpf 
- * Copyright (C) 2001-2020 Helge Deller 
+ * Copyright (C) 2001-2023 Helge Deller 
  * Copyright (C) 2001-2002 Thomas Bogendoerfer 
  *
  * TODO:
@@ -41,6 +41,26 @@ static struct sti_struct *default_sti __read_mostly;
 static int num_sti_roms __read_mostly;
 static struct sti_struct *sti_roms[MAX_STI_ROMS] __read_mostly;

+static void *store_sti_val(struct sti_struct *sti, void *ptr, unsigned long 
val)
+{
+   if (IS_ENABLED(CONFIG_64BIT) && sti->do_call64) {
+   /* used for 64-bit STI ROM */
+   unsigned long *ptr64 = ptr;
+
+   ptr64 = PTR_ALIGN(ptr64, sizeof(void *));
+   *ptr64++ = val;
+   return ptr64;
+   } else {
+   /* used for 32-bit STI ROM */
+   u32 *ptr32 = ptr;
+
+   *ptr32++ = val;
+   return ptr32;
+   }
+}
+
+#define store_sti_ptr(sti, dest, ptr)  \
+   store_sti_val(sti, dest, STI_PTR(ptr))

 /* The colour indices used by STI are
  *   0 - Black
@@ -87,7 +107,7 @@ static int sti_init_graph(struct sti_struct *sti)
memset(inptr, 0, sizeof(*inptr));
inptr->text_planes = 3; /* # of text planes (max 3 for STI) */
memset(inptr_ext, 0, sizeof(*inptr_ext));
-   inptr->ext_ptr = STI_PTR(inptr_ext);
+   store_sti_ptr(sti, >ext_ptr, inptr_ext);
outptr->errno = 0;


[PATCH v3] console/parisc: Fix STI console on 64-bit only machines

2023-05-10 Thread Helge Deller
Fix the STI console to be able to execute either the 64-bit STI ROM code
or the 32-bit STI ROM code.

This is necessary on 64-bit only machines (e.g. C8000 workstation) which
otherwise won't show the STI text console with HP graphic cards like
Visualize-FX5/FX10/FXe.

When calling 32-bit code from a 64-bit kernel one may need to copy
contents on the CPU stack from high memory down below the 4GB limit.

Signed-off-by: Helge Deller 

---
v3: Fix check for overflow of 32-bit pointers
v2: Forward-ported to apply cleanly on drm-misc-next git tree

diff --git a/arch/parisc/include/asm/pdc.h b/arch/parisc/include/asm/pdc.h
index 2b4fad8328e8..269b9a159f01 100644
--- a/arch/parisc/include/asm/pdc.h
+++ b/arch/parisc/include/asm/pdc.h
@@ -88,8 +88,8 @@ int pdc_iodc_print(const unsigned char *str, unsigned count);

 void pdc_emergency_unlock(void);
 int pdc_sti_call(unsigned long func, unsigned long flags,
- unsigned long inptr, unsigned long outputr,
- unsigned long glob_cfg);
+   unsigned long inptr, unsigned long outputr,
+   unsigned long glob_cfg, int do_call64);

 int __pdc_cpu_rendezvous(void);
 void pdc_cpu_rendezvous_lock(void);
diff --git a/arch/parisc/kernel/firmware.c b/arch/parisc/kernel/firmware.c
index cc124d9f1f7f..71ef1640db5a 100644
--- a/arch/parisc/kernel/firmware.c
+++ b/arch/parisc/kernel/firmware.c
@@ -1389,17 +1389,24 @@ int pdc_iodc_getc(void)
 }

 int pdc_sti_call(unsigned long func, unsigned long flags,
- unsigned long inptr, unsigned long outputr,
- unsigned long glob_cfg)
+   unsigned long inptr, unsigned long outputr,
+   unsigned long glob_cfg, int do_call64)
 {
-int retval;
+   int retval = 0;
unsigned long irqflags;

-spin_lock_irqsave(_lock, irqflags);
-retval = real32_call(func, flags, inptr, outputr, glob_cfg);
-spin_unlock_irqrestore(_lock, irqflags);
+   spin_lock_irqsave(_lock, irqflags);
+   if (IS_ENABLED(CONFIG_64BIT) && do_call64) {
+#ifdef CONFIG_64BIT
+   retval = real64_call(func, flags, inptr, outputr, glob_cfg);
+#else
+   WARN_ON(1);
+#endif
+   } else
+   retval = real32_call(func, flags, inptr, outputr, glob_cfg);
+   spin_unlock_irqrestore(_lock, irqflags);

-return retval;
+   return retval;
 }
 EXPORT_SYMBOL(pdc_sti_call);

diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c
index baca6974e288..fe54ca8726e6 100644
--- a/drivers/video/fbdev/stifb.c
+++ b/drivers/video/fbdev/stifb.c
@@ -71,9 +71,9 @@

 #include 

-/* REGION_BASE(fb_info, index) returns the virtual address for region  
*/
+/* REGION_BASE(fb_info, index) returns the physical address for region  
*/
 #define REGION_BASE(fb_info, index) \
-   F_EXTEND(fb_info->sti->glob_cfg->region_ptrs[index])
+   F_EXTEND(fb_info->sti->regions_phys[index])

 #define NGLEDEVDEPROM_CRT_REGION 1

diff --git a/drivers/video/sticore.c b/drivers/video/sticore.c
index 7eb925f2ba9c..1f55cf150b96 100644
--- a/drivers/video/sticore.c
+++ b/drivers/video/sticore.c
@@ -4,7 +4,7 @@
  * core code for console driver using HP's STI firmware
  *
  * Copyright (C) 2000 Philipp Rumpf 
- * Copyright (C) 2001-2020 Helge Deller 
+ * Copyright (C) 2001-2023 Helge Deller 
  * Copyright (C) 2001-2002 Thomas Bogendoerfer 
  *
  * TODO:
@@ -41,6 +41,26 @@ static struct sti_struct *default_sti __read_mostly;
 static int num_sti_roms __read_mostly;
 static struct sti_struct *sti_roms[MAX_STI_ROMS] __read_mostly;

+static void *store_sti_val(struct sti_struct *sti, void *ptr, unsigned long 
val)
+{
+   if (IS_ENABLED(CONFIG_64BIT) && sti->do_call64) {
+   /* used for 64-bit STI ROM */
+   unsigned long *ptr64 = ptr;
+
+   ptr64 = PTR_ALIGN(ptr64, sizeof(void *));
+   *ptr64++ = val;
+   return ptr64;
+   } else {
+   /* used for 32-bit STI ROM */
+   u32 *ptr32 = ptr;
+
+   *ptr32++ = val;
+   return ptr32;
+   }
+}
+
+#define store_sti_ptr(sti, dest, ptr)  \
+   store_sti_val(sti, dest, STI_PTR(ptr))

 /* The colour indices used by STI are
  *   0 - Black
@@ -87,7 +107,7 @@ static int sti_init_graph(struct sti_struct *sti)
memset(inptr, 0, sizeof(*inptr));
inptr->text_planes = 3; /* # of text planes (max 3 for STI) */
memset(inptr_ext, 0, sizeof(*inptr_ext));
-   inptr->ext_ptr = STI_PTR(inptr_ext);
+   store_sti_ptr(sti, >ext_ptr, inptr_ext);
outptr->errno = 0;

ret = sti_call(sti, sti->init_graph, _init_flags, inptr,
@@ -118,7 +138,7 @@ static void sti_inq_conf(struct sti_struct *sti)
unsigned long flags;
s32 ret;

-   outptr->ext_ptr = STI_PTR(>sti_data->inq_outptr_ext);
+   store_sti_ptr(sti, >ext_ptr, >sti_data->inq_outptr_ext);

do {

Re: [RFC PATCH 0/4] Add support for DRM cgroup memory accounting.

2023-05-10 Thread Tejun Heo
Hello,

On Wed, May 10, 2023 at 04:59:01PM +0200, Maarten Lankhorst wrote:
> The misc controller is not granular enough. A single computer may have any 
> number of
> graphics cards, some of them with multiple regions of vram inside a single 
> card.

Extending the misc controller to support dynamic keys shouldn't be that
difficult.

...
> In the next version, I will move all the code for handling the resource limit 
> to
> TTM's eviction layer, because otherwise it cannot handle the resource limit 
> correctly.
> 
> The effect of moving the code to TTM, is that it will make the code even more 
> generic
> for drivers that have vram and use TTM. When using TTM, you only have to 
> describe your
> VRAM, update some fields in the TTM manager and (un)register your device with 
> the
> cgroup handler on (un)load. It's quite trivial to add vram accounting to 
> amdgpu and
> nouveau. [2]
> 
> If you want to add a knob for scheduling weight for a process, it makes sense 
> to
> also add resource usage as a knob, otherwise the effect of that knob is very
> limited. So even for Tvrtko's original proposed usecase, it would make sense.

It does make sense but unlike Tvrtko's scheduling weights what's being
proposed doesn't seem to encapsulate GPU memory resource in a generic enough
manner at least to my untrained eyes. ie. w/ drm.weight, I don't need any
specific knoweldge of how a specific GPU operates to say "this guy should
get 2x processing power over that guy". This more or less holds for other
major resources including CPU, memory and IO. What you're proposing seems a
lot more tied to hardware details and users would have to know a lot more
about how memory is configured on that particular GPU.

Now, if this is inherent to how all, or at least most, GPUs operate, sure,
but otherwise let's start small in terms of interface and not take up space
which should be for something universal. If this turns out to be the way,
expanding to take up the generic interface space isn't difficult.

I don't know GPU space so please educate me where I'm wrong.

Thanks.

-- 
tejun


Re: [PATCH v4 2/4] ARM: dts: sunxi: rename tcon's clock output

2023-05-10 Thread Jernej Škrabec
Dne petek, 05. maj 2023 ob 07:21:08 CEST je Roman Beranek napisal(a):
> While the rate of TCON0's DCLK matches dotclock for parallel and LVDS
> outputs, this doesn't hold for DSI. According manuals from Allwinner,
> DCLK is an abbreviation of Data Clock, not dotclock, so go with that
> instead.
> 
> Signed-off-by: Roman Beranek 

Acked-by: Jernej Skrabec 

Best regards,
Jernej




Re: [PATCH v4 1/4] clk: sunxi-ng: a64: force select PLL_MIPI in TCON0 mux

2023-05-10 Thread Jernej Škrabec
Dne petek, 05. maj 2023 ob 07:21:07 CEST je Roman Beranek napisal(a):
> TCON0's source clock can be fed from either PLL_MIPI, or PLL_VIDEO0(2X),
> however MIPI DSI output only seems to work when PLL_MIPI is selected and
> thus the choice must be hardcoded in.
> 
> Currently, this driver can't propagate rate change from N-K-M clocks
> (such as PLL_MIPI) upwards. This prevents PLL_VIDEO0 from participating
> in setting of the TCON0 data clock rate, limiting the precision with
> which a target pixel clock can be matched.
> 
> For outputs with fixed TCON0 divider, that is DSI and LVDS, the dotclock
> can deviate up to 8% off target.
> 
> Signed-off-by: Roman Beranek 

Reviewed-by: Jernej Skrabec 

Best regards,
Jernej




Re: [PATCH v2 0/7] drm: sun4i: set proper TCON0 DCLK rate in DSI mode

2023-05-10 Thread Jernej Škrabec
Dne ponedeljek, 08. maj 2023 ob 16:08:32 CEST je Frank Oltmanns napisal(a):
> Hello again,
> 
> On 2023-05-08 at 08:54:28 +0200, Frank Oltmanns  wrote:
> > Hello Roman,
> > 
> > On 2023-05-03 at 16:22:32 +0200, "Roman Beranek"  wrote:
> >> Hello everyone,
> >> 
> >> I apologize for my absence from the discussion during past week, I got
> >> hit with tonsillitis.
> > 
> > I hope you feel better!
> > 
> >> On Mon May 1, 2023 at 3:40 PM CEST, Frank Oltmanns wrote:
> >>> Looking at ccu_nkm_determine_rate(), we've found our culprit because it
> >>> does not try parent clock rates other than the current one. The same
> >>> applies to all other ccu_nkm_* functions.
> >> 
> >> Yes, that's why I dropped CLK_SET_RATE_PARENT from pll-mipi in v3.
> >> 
> >>>  b. Add functionality to ccu_nkm_* to also update the parent clock rate.
> >>> 
> >>> I'm actually interested in tackling b, but I can't make any promises as
> >>> to if and when I'll be able to solve it. I'm not certain about any side
> >>> effects this might have.
> >> 
> >> It sounds like an interesting exercise. But what if HDMI is then added
> >> to the mix?
> > 
> > Thanks for interest in this discussion! I really appreciate it!
> > 
> > First of all, let me admit that I'm no expert on this. But nobody else
> > has replied so far, and I want to keep this conversation going, so let
> > me share my view.
> > 
> > My understanding is that pll-mipi being able to set pll-video0's rate
> > should not have an impact on HDMI, neither positive nor negative. If I'm
> > not mistaken those two things are orthogonal.
> > 
> > The relevant part of the clk_summary with your v4 [1] patch on top of
> > 
> > drm-next looks like this:
> >  enable  protect  hardware
> >
> >clock  countcountrateenable
> > 
> > --
> > 
> > pll-video011   29400 Y
> > 
> >hdmi   00   29400 N
> >tcon1  00   29400 N
> >pll-mipi   11   43120 Y
> >
> >   tcon0   21   43120 Y
> >   
> >  tcon-data-clock  11   10780 Y
> >
> >pll-video0-2x  00   58800 Y
> > 
> > Note, that pll-video0 is protected.
> > 
> > I don't own any boards that support HDMI in mainline. For the pinephone
> > this support is added e.g. in megi's kernel, where connecting an HDMI
> > output results in pll-video0's rate being set to 297MHz, even though it
> > is 294MHz after boot.
> > 
> > So, for reference, this is the same part of the clk_summary with megi's
> > 
> > 6.3.0 kernel, USB-C dock unplugged:
> >  enable  protect  hardware
> >
> >clock  countcountrateenable
> > 
> > --
> > 
> > pll-video030   29400 Y
> > 
> >hdmi-phy-clk   107350 Y
> >hdmi   10   29400 Y
> >tcon1  00   29400 N
> >pll-mipi   10   43120 Y
> >
> >   tcon0   20   43120 Y
> >   
> >  tcon-pixel-clock 10   10780 Y
> >
> >pll-video0-2x  00   58800 Y
> > 
> > pll-video0 is not protected. When plugging in the USB-C dock with an HDMI
> 
> > monitor connected, the situation looks like this:
> Just for reference, the protection count is disabled by this commit [1]
> in megi's kernel.
> 
> In the commit message Icenowy Zheng refers to "the ability to keep TCON0
> clock stable when HDMI changes its parent's clock." She implemented this
> in these two previous commits [2] [3]. None of this is in mainline.

Those commits are good follow up series to this, if anyone wants to improve 
things further.

Best regards,
Jernej

> 
> Best regards,
>   Frank
> 
> [1]:
> https://github.com/megous/linux/commit/039f7ee3f44adfbe4c6b7c2f1798b9a70c9f
> b9ee [2]:
> https://github.com/megous/linux/commit/a927843932f16e5a7f5ff57fbfd2d5f11c71
> 2b67 [3]:
> https://github.com/megous/linux/commit/0e305371eaa49128856acce9830e6af07944
> 2ad6
> >  enable  protect  hardware
> >
> >clock  countcountrateenable
> > 
> > --
> > 
> > pll-video04   

[PATCH] drm/i915/hwmon: Silence UBSAN uninitialized bool variable warning

2023-05-10 Thread Ashutosh Dixit
Loading i915 on UBSAN enabled kernels (CONFIG_UBSAN/CONFIG_UBSAN_BOOL)
causes the following warning:

  UBSAN: invalid-load in drivers/gpu/drm/i915/gt/uc/intel_uc.c:558:2
  load of value 255 is not a valid value for type '_Bool'
  Call Trace:
   dump_stack_lvl+0x57/0x7d
   ubsan_epilogue+0x5/0x40
   __ubsan_handle_load_invalid_value.cold+0x43/0x48
   __uc_init_hw+0x76a/0x903 [i915]
   ...
   i915_driver_probe+0xfb1/0x1eb0 [i915]
   i915_pci_probe+0xbe/0x2d0 [i915]

The warning happens because during probe i915_hwmon is still not available
which results in the output boolean variable *old remaining
uninitialized. Silence the warning by initializing the variable to an
arbitrary value.

Signed-off-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/i915_hwmon.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index a3bdd9f68a458..685663861bc0b 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -502,8 +502,11 @@ void i915_hwmon_power_max_disable(struct drm_i915_private 
*i915, bool *old)
struct i915_hwmon *hwmon = i915->hwmon;
u32 r;
 
-   if (!hwmon || !i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
+   if (!hwmon || !i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit)) {
+   /* Fix uninitialized bool variable warning */
+   *old = false;
return;
+   }
 
mutex_lock(>hwmon_lock);
 
-- 
2.38.0



Re: [PATCH v6 1/6] fbdev/matrox: Remove trailing whitespaces

2023-05-10 Thread Sui Jingfeng

Hi, Thomas


I love your patch, yet something to improve:


On 2023/5/10 19:05, Thomas Zimmermann wrote:

Fix coding style. No functional changes.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Arnd Bergmann 
Reviewed-by: Sam Ravnborg 
Reviewed-by: Sui Jingfeng 
Tested-by: Sui Jingfeng 
---
  drivers/video/fbdev/matrox/matroxfb_accel.c | 6 +++---
  drivers/video/fbdev/matrox/matroxfb_base.h  | 4 ++--
  2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/video/fbdev/matrox/matroxfb_accel.c 
b/drivers/video/fbdev/matrox/matroxfb_accel.c
index 9cb0685feddd..ce51227798a1 100644
--- a/drivers/video/fbdev/matrox/matroxfb_accel.c
+++ b/drivers/video/fbdev/matrox/matroxfb_accel.c
@@ -88,7 +88,7 @@
  
  static inline void matrox_cfb4_pal(u_int32_t* pal) {

unsigned int i;
-   
+
for (i = 0; i < 16; i++) {
pal[i] = i * 0xU;
}
@@ -96,7 +96,7 @@ static inline void matrox_cfb4_pal(u_int32_t* pal) {
  
  static inline void matrox_cfb8_pal(u_int32_t* pal) {

unsigned int i;
-   
+
for (i = 0; i < 16; i++) {
pal[i] = i * 0x01010101U;
}
@@ -482,7 +482,7 @@ static void matroxfb_1bpp_imageblit(struct matrox_fb_info 
*minfo, u_int32_t fgx,
/* Tell... well, why bother... */
while (height--) {
size_t i;
-   
+
for (i = 0; i < step; i += 4) {
/* Hope that there are at least three 
readable bytes beyond the end of bitmap */

fb_writel(get_unaligned((u_int32_t*)(chardata + i)),mmio.vaddr);
diff --git a/drivers/video/fbdev/matrox/matroxfb_base.h 
b/drivers/video/fbdev/matrox/matroxfb_base.h
index 958be6805f87..c93c69bbcd57 100644
--- a/drivers/video/fbdev/matrox/matroxfb_base.h
+++ b/drivers/video/fbdev/matrox/matroxfb_base.h
@@ -301,9 +301,9 @@ struct matrox_altout {
int (*verifymode)(void* altout_dev, u_int32_t mode);
int (*getqueryctrl)(void* altout_dev,
struct v4l2_queryctrl* ctrl);


Noticed that there are plenty of coding style problems in matroxfb_base.h,

why you only fix a few of them?   Take this two line as an example, 
shouldn't


they be fixed also as following?


int (*verifymode)(void *altout_dev, u_int32_t mode);
int (*getqueryctrl)(void *altout_dev,
struct v4l2_queryctrl *ctrl);



-   int (*getctrl)(void* altout_dev,
+   int (*getctrl)(void *altout_dev,
   struct v4l2_control* ctrl);
-   int (*setctrl)(void* altout_dev,
+   int (*setctrl)(void *altout_dev,
   struct v4l2_control* ctrl);
  };
  


[PATCH v10 5/8] drm/i915/pxp: Add ARB session creation and cleanup

2023-05-10 Thread Alan Previn
Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.

While relooking at the ARB session creation flow in intel_pxp_start,
let's address missing UAPI documentation. Without actually changing
backward compatible behavior, update i915's drm-uapi comments
that describe the possible error values when creating a context
with I915_CONTEXT_PARAM_PROTECTED_CONTENT:
   Since the first merge of PXP support on ADL, i915 returns -ENXIO
   if a dependency such as firmware or component driver was yet to
   be loaded or returns -EIO if the creation attempt failed when
   requested by the PXP firmware (specific firmware error responses
   are reported in dmesg).

Add MTL's function for ARB session invalidation but this
reuses PXP firmware version 4.2 ABI structure format.

For both cases, in the back-end gsccs functions for sending messages
to the firmware inspect the GSC-CS-Mem-Header's pending-bit which
means the GSC firmware is busy and we should retry.

Given the last hw requirement, lets also update functions in
front-end layer that wait for session creation or teardown
completion to use new worst case timeout periods.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/pxp/intel_pxp.c  |  27 +++-
 .../drm/i915/pxp/intel_pxp_cmd_interface_43.h |  21 +++
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 130 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h|  12 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |  11 +-
 include/uapi/drm/i915_drm.h   |  15 ++
 6 files changed, 209 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 8949d4be7882..b600d68de2a4 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -291,6 +291,8 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
 
 static int __pxp_global_teardown_final(struct intel_pxp *pxp)
 {
+   int timeout;
+
if (!pxp->arb_is_valid)
return 0;
/*
@@ -300,7 +302,12 @@ static int __pxp_global_teardown_final(struct intel_pxp 
*pxp)
intel_pxp_mark_termination_in_progress(pxp);
intel_pxp_terminate(pxp, false);
 
-   if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(250)))
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+   else
+   timeout = 250;
+
+   if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
 
return 0;
@@ -308,6 +315,8 @@ static int __pxp_global_teardown_final(struct intel_pxp 
*pxp)
 
 static int __pxp_global_teardown_restart(struct intel_pxp *pxp)
 {
+   int timeout;
+
if (pxp->arb_is_valid)
return 0;
/*
@@ -316,7 +325,12 @@ static int __pxp_global_teardown_restart(struct intel_pxp 
*pxp)
 */
pxp_queue_termination(pxp);
 
-   if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(250)))
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+   else
+   timeout = 250;
+
+   if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
 
return 0;
@@ -354,8 +368,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
 
-   if (wait_for(pxp_component_bound(pxp), 250))
-   return -ENXIO;
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
+   if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 250))
+   return -ENXIO;
+   } else {
+   if (wait_for(pxp_component_bound(pxp), 250))
+   return -ENXIO;
+   }
 
mutex_lock(>arb_mutex);
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index c65ada99e54f..0919cd84 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -11,6 +11,7 @@
 
 /* PXP-Cmd-Op definitions */
 #define PXP43_CMDID_START_HUC_AUTH 0x003A
+#define PXP43_CMDID_INIT_SESSION 0x0036
 
 /* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
 #define PXP43_MAX_HECI_INOUT_SIZE (SZ_32K)
@@ -26,4 +27,24 @@ struct pxp43_start_huc_auth_out {
struct pxp_cmd_header header;
 } __packed;
 
+/* PXP-Input-Packet: Init PXP session */
+struct pxp43_create_arb_in {
+   struct pxp_cmd_header header;
+   /* header.stream_id fields for vesion 4.3 of Init PXP session: 
*/
+   #define PXP43_INIT_SESSION_VALID BIT(0)
+   #define PXP43_INIT_SESSION_APPTYPE BIT(1)
+   #define PXP43_INIT_SESSION_APPID GENMASK(17, 2)
+   u32 protection_mode;
+   

[PATCH v10 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP

2023-05-10 Thread Alan Previn
Because of the additional firmware, component-driver and
initialization depedencies required on MTL platform before a
PXP context can be created, UMD calling for PXP creation as a
way to get-caps can take a long time. An actual real world
customer stack has seen this happen in the 4-to-8 second range
after the kernel starts (which sees MESA's init appear in the
middle of this range as the compositor comes up). To avoid
unncessary delays experienced by the UMD for get-caps purposes,
add a GET_PARAM for I915_PARAM_PXP_SUPPORT.

However, some failures can still occur after all the depedencies
are met (such as firmware init flow failure, bios configurations
or SOC fusing not allowing PXP enablement). Those scenarios will
only be known to user space when it attempts creating a PXP context
and is documented in the GEM UAPI headers.

While making this change, create a helper that is common to both
GET_PARAM caller and intel_pxp_start since the latter does
similiar checks.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_getparam.c |  7 +++
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 29 +---
 drivers/gpu/drm/i915/pxp/intel_pxp.h |  1 +
 include/uapi/drm/i915_drm.h  | 19 ++
 4 files changed, 49 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_getparam.c 
b/drivers/gpu/drm/i915/i915_getparam.c
index 2238e096c957..6f11d7eaa91a 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -5,6 +5,8 @@
 #include "gem/i915_gem_mman.h"
 #include "gt/intel_engine_user.h"
 
+#include "pxp/intel_pxp.h"
+
 #include "i915_cmd_parser.h"
 #include "i915_drv.h"
 #include "i915_getparam.h"
@@ -102,6 +104,11 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
if (value < 0)
return value;
break;
+   case I915_PARAM_PXP_STATUS:
+   value = intel_pxp_get_readiness_status(i915->pxp);
+   if (value < 0)
+   return value;
+   break;
case I915_PARAM_MMAP_GTT_VERSION:
/* Though we've started our numbering from 1, and so class all
 * earlier versions as 0, in effect their value is undefined as
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index b600d68de2a4..f143eadbc253 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -358,23 +358,38 @@ void intel_pxp_end(struct intel_pxp *pxp)
 }
 
 /*
- * the arb session is restarted from the irq work when we receive the
- * termination completion interrupt
+ * this helper is used by both intel_pxp_start and by
+ * the GET_PARAM IOCTL that user space calls. Thus, the
+ * return values here should match the UAPI spec.
  */
-int intel_pxp_start(struct intel_pxp *pxp)
+int intel_pxp_get_readiness_status(struct intel_pxp *pxp)
 {
-   int ret = 0;
-
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
 
if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 250))
-   return -ENXIO;
+   return 2;
} else {
if (wait_for(pxp_component_bound(pxp), 250))
-   return -ENXIO;
+   return 2;
}
+   return 1;
+}
+
+/*
+ * the arb session is restarted from the irq work when we receive the
+ * termination completion interrupt
+ */
+int intel_pxp_start(struct intel_pxp *pxp)
+{
+   int ret = 0;
+
+   ret = intel_pxp_get_readiness_status(pxp);
+   if (ret < 0)
+   return ret;
+   else if (ret > 1)
+   return -EIO; /* per UAPI spec, user may retry later */
 
mutex_lock(>arb_mutex);
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 3ded0890cd27..17e6dbc86b38 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -26,6 +26,7 @@ void intel_pxp_fini_hw(struct intel_pxp *pxp);
 void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
 void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32 
arb_session_id);
 
+int intel_pxp_get_readiness_status(struct intel_pxp *pxp);
 int intel_pxp_start(struct intel_pxp *pxp);
 void intel_pxp_end(struct intel_pxp *pxp);
 
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 0aa3190e7654..ba40855dbc93 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -771,6 +771,25 @@ typedef struct drm_i915_irq_wait {
  */
 #define I915_PARAM_OA_TIMESTAMP_FREQUENCY 57
 
+/*
+ * Query the status of PXP support in i915.
+ *
+ * The query can fail in the following scenarios with the listed error codes:
+ * -ENODEV = PXP support is not available on the GPU device or in the
+ *   kernel due to 

[PATCH v10 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC

2023-05-10 Thread Alan Previn
Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.

NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
 1- GSC-SW-Proxy: This is pending upstream publication awaiting
a few remaining opens
 2- MTL-HDCP: An equivalent patch has also been published at:
https://patchwork.freedesktop.org/series/111876/. (Patch 1)
 3- PXP: This series.

NOTE2: A difference in this patch vs what is appearing is in bullet 2
above is that HDCP (and SW-Proxy) will be using priveleged submission
(GGTT and common gsc-uc-context) while PXP will be using non-priveleged
PPGTT, context and batch buffer. Therefore this patch will only slightly
overlap with the MTL-HDCP patches despite have very similar function
names (emit_foo vs emit_nonpriv_foo). This is because HECI_CMD_PKT
instructions require different flows and hw-specific code when done
via PPGTT based submission (not different from other engines). MTL-HDCP
contains the same intel_gsc_mtl_header_t structures as this but the
helpers there are different. Both add the same new file names.

NOTE3: Additional clarity about the heci-cmd-pkt layout and where the
   common helpers come in:
 - On MTL, when an i915 subsystem needs to send a command request
   to the security firmware, it will send that via the GSC-
   engine-command-streamer.
 - However those commands, (lets call them "gsc_specific_fw_api"
   calls), are not understood by the GSC command streamer hw.
 - The GSC CS only looks at the GSC_HECI_CMD_PKT instruction and
   passes it along to the GSC firmware.
 - The GSC FW on the other hand needs additional metadata to know
   which usage service is being called (PXP, HDCP, proxy, etc) along
   with session specific info. Thus an extra header called GSC-CS
   HECI Memory Header, (C) in below diagram is prepended before
   the FW specific API, (D).
 - Thus, the structural layout of the request submitted would
   need to look like the diagram below (for non-priv PXP).
 - In the diagram, the common helper for HDCP, (GSC-Sw-Proxy) and
   PXP (i.e. new function intel_gsc_uc_heci_cmd_emit_mtl_header)
   will populate blob (C) while additional helpers, different for
   PPGGTT (this patch) vs GGTT (HDCP series) will populate
   blobs (A) and (B) below.
  ___
 (A)  |  MI_BATCH_BUFFER_START (ppgtt, batchbuff-addr, ...) |
  | |   |
  |_|   |
  | (B)| GSC_HECI_CMD_PKT (pkt-addr-in, pkt-size-in,|   |
  ||   pkt-addr-out, pkt-size-out)  |
  || MI_BATCH_BUFFER_END|   |   |
  |||   |   |
  | |   |
  |_|   |
|
-
|
   \|/
  __V___
  |   _|
  |(C)|   ||
  |   | struct intel_gsc_mtl_header { ||
  |   |   validity marker ||
  |   |   heci_clent_id   ||
  |   |   ... ||
  |   |  }||
  |   |___||
  |(D)|   ||
  |   | struct gsc_fw_specific_api_foobar {   ||
  |   | ...   ||
  |   | For an example, see   ||
  |   | 'struct pxp43_create_arb_in' at   ||
  |   | intel_pxp_cmd_interface_43.h  ||
  |   |   ||
  |   | } ||
  |   |  Struture depends on command type ||
  |   | struct gsc_fw_specific_api_foobar {   ||
  |   |___||
  ||

That said, this patch provides basic helpers but leaves the
PXP subsystem (i.e. the caller) to handle (D) and everything
else such as input/output size verification or handling the
responses from security firmware (for example, requiring a retry).

Signed-off-by: Alan Previn 
---
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 102 ++
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |  23 
 2 files changed, 125 

[PATCH v10 8/8] drm/i915/pxp: Enable PXP with MTL-GSC-CS

2023-05-10 Thread Alan Previn
Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the debugfs teardown timeouts to align with
new GSC-CS + firmware specs.

Now that we have 3 places that are selecting pxp timeouts
based on tee vs gsccs back-end, let's add a helper.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_pci.c  |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 18 ++
 drivers/gpu/drm/i915/pxp/intel_pxp.h |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c |  6 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c |  2 +-
 5 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index c509ea4aa70f..116b5b5bdb91 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1152,6 +1152,7 @@ static const struct intel_device_info mtl_info = {
.has_llc = 0,
.has_mslice_steering = 0,
.has_snoop = 1,
+   .has_pxp = 1,
.__runtime.memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
.require_force_probe = 1,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index f143eadbc253..bb2e15329f34 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -289,6 +289,14 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
return bound;
 }
 
+int intel_pxp_get_backend_timeout_ms(struct intel_pxp *pxp)
+{
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   return GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+   else
+   return 250;
+}
+
 static int __pxp_global_teardown_final(struct intel_pxp *pxp)
 {
int timeout;
@@ -302,10 +310,7 @@ static int __pxp_global_teardown_final(struct intel_pxp 
*pxp)
intel_pxp_mark_termination_in_progress(pxp);
intel_pxp_terminate(pxp, false);
 
-   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
-   timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
-   else
-   timeout = 250;
+   timeout = intel_pxp_get_backend_timeout_ms(pxp);
 
if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
@@ -325,10 +330,7 @@ static int __pxp_global_teardown_restart(struct intel_pxp 
*pxp)
 */
pxp_queue_termination(pxp);
 
-   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
-   timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
-   else
-   timeout = 250;
+   timeout = intel_pxp_get_backend_timeout_ms(pxp);
 
if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 17e6dbc86b38..17254c3f1267 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -27,6 +27,7 @@ void intel_pxp_mark_termination_in_progress(struct intel_pxp 
*pxp);
 void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32 
arb_session_id);
 
 int intel_pxp_get_readiness_status(struct intel_pxp *pxp);
+int intel_pxp_get_backend_timeout_ms(struct intel_pxp *pxp);
 int intel_pxp_start(struct intel_pxp *pxp);
 void intel_pxp_end(struct intel_pxp *pxp);
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 4b8e70caa3ad..e07c5b380789 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -14,6 +14,7 @@
 
 #include "intel_pxp.h"
 #include "intel_pxp_debugfs.h"
+#include "intel_pxp_gsccs.h"
 #include "intel_pxp_irq.h"
 #include "intel_pxp_types.h"
 
@@ -45,6 +46,7 @@ static int pxp_terminate_set(void *data, u64 val)
 {
struct intel_pxp *pxp = data;
struct intel_gt *gt = pxp->ctrl_gt;
+   int timeout_ms;
 
if (!intel_pxp_is_active(pxp))
return -ENODEV;
@@ -54,8 +56,10 @@ static int pxp_terminate_set(void *data, u64 val)
intel_pxp_irq_handler(pxp, 
GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT);
spin_unlock_irq(gt->irq_lock);
 
+   timeout_ms = intel_pxp_get_backend_timeout_ms(pxp);
+
if (!wait_for_completion_timeout(>termination,
-msecs_to_jiffies(100)))
+msecs_to_jiffies(timeout_ms)))
return -ETIMEDOUT;
 
return 0;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index e4d8242302c5..0a3e66b0265e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -44,7 +44,7 @@ static int pxp_wait_for_session_state(struct intel_pxp *pxp, 
u32 id, bool in_pla
  KCR_SIP(pxp->kcr_base),
   

[PATCH v10 4/8] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages

2023-05-10 Thread Alan Previn
Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products.

Use the newly added helpers to populate the GSC-CS memory
header and send the message packet to the FW by dispatching
the GSC_HECI_CMD_PKT instruction on the GSC engine.

We use non-priveleged batches for submission to GSC engine
which require two buffers for the request:
 - a buffer for the HECI packet that contains PXP FW commands
 - a batch-buffer that contains the engine instruction for
   sending the HECI packet to the GSC firmware.

Thus, add the allocation and freeing of these buffers in gsccs
init and fini.

The GSC-fw may reply to commands with a SUCCESS but with an
additional pending-bit set in the reply packet. This bit
means the GSC-FW is currently busy and the caller needs to
try again with the gsc_message_handle the fw returned. Thus,
add a wrapper to continuously retry send_message while
replaying the gsc_message_handle. Retries need to follow the
arch-spec count and delay until GSC-FW replies with the real
SUCCESS or timeout after that spec'd delay.

The GSC-fw requires a non-zero host_session_handle provided
by the caller to enable gsc_message_handle tracking. Thus,
allocate the host_session_handle at init and destroy it
at fini (the latter requiring an FYI to the gsc-firmware).

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |   3 +-
 .../drm/i915/pxp/intel_pxp_cmd_interface_43.h |   3 +
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 240 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h|   4 +
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h|   6 +
 5 files changed, 254 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
index e790608745d4..ef70e304904a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
@@ -51,7 +51,8 @@ struct intel_gsc_mtl_header {
 * we distinguish the flags using OUTFLAG or INFLAG
 */
u32 flags;
-#define GSC_OUTFLAG_MSG_PENDING1
+#define GSC_OUTFLAG_MSG_PENDINGBIT(0)
+#define GSC_INFLAG_MSG_CLEANUP BIT(1)
 
u32 status;
 } __packed;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index ad67e3f49c20..c65ada99e54f 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -12,6 +12,9 @@
 /* PXP-Cmd-Op definitions */
 #define PXP43_CMDID_START_HUC_AUTH 0x003A
 
+/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
+#define PXP43_MAX_HECI_INOUT_SIZE (SZ_32K)
+
 /* PXP-Input-Packet: HUC-Authentication */
 struct pxp43_start_huc_auth_in {
struct pxp_cmd_header header;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index bad55719a7ac..16e3b73d0653 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -6,23 +6,232 @@
 #include "gem/i915_gem_internal.h"
 
 #include "gt/intel_context.h"
+#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
 
 #include "i915_drv.h"
 #include "intel_pxp_cmd_interface_43.h"
 #include "intel_pxp_gsccs.h"
 #include "intel_pxp_types.h"
 
+static int
+gsccs_send_message(struct intel_pxp *pxp,
+  void *msg_in, size_t msg_in_size,
+  void *msg_out, size_t msg_out_size_max,
+  size_t *msg_out_len,
+  u64 *gsc_msg_handle_retry)
+{
+   struct intel_gt *gt = pxp->ctrl_gt;
+   struct drm_i915_private *i915 = gt->i915;
+   struct gsccs_session_resources *exec_res =  >gsccs_res;
+   struct intel_gsc_mtl_header *header = exec_res->pkt_vaddr;
+   struct intel_gsc_heci_non_priv_pkt pkt;
+   size_t max_msg_size;
+   u32 reply_size;
+   int ret;
+
+   if (!exec_res->ce)
+   return -ENODEV;
+
+   max_msg_size = PXP43_MAX_HECI_INOUT_SIZE - sizeof(*header);
+
+   if (msg_in_size > max_msg_size || msg_out_size_max > max_msg_size)
+   return -ENOSPC;
+
+   if (!exec_res->pkt_vma || !exec_res->bb_vma)
+   return -ENOENT;
+
+   GEM_BUG_ON(exec_res->pkt_vma->size < (2 * PXP43_MAX_HECI_INOUT_SIZE));
+
+   mutex_lock(>tee_mutex);
+
+   memset(header, 0, sizeof(*header));
+   intel_gsc_uc_heci_cmd_emit_mtl_header(header, HECI_MEADDRESS_PXP,
+ msg_in_size + sizeof(*header),
+ exec_res->host_session_handle);
+
+   /* check if this is a host-session-handle cleanup call (empty packet) */
+   if (!msg_in && !msg_out)
+   header->flags |= GSC_INFLAG_MSG_CLEANUP;
+
+   /* copy caller provided gsc message 

[PATCH v10 7/8] drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component

2023-05-10 Thread Alan Previn
On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on a tee component
to start sending GSC-CS firmware messages.

Thus, immediately enable (or disable) KCR HW on PXP's init,
fini and resume.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 15 ++-
 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c|  3 ++-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 4bc276daca16..8dc41de3f6f7 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -10,6 +10,7 @@
 #include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
 
 #include "i915_drv.h"
+#include "intel_pxp.h"
 #include "intel_pxp_cmd_interface_42.h"
 #include "intel_pxp_cmd_interface_43.h"
 #include "intel_pxp_gsccs.h"
@@ -422,10 +423,22 @@ gsccs_allocate_execution_resource(struct intel_pxp *pxp)
 
 void intel_pxp_gsccs_fini(struct intel_pxp *pxp)
 {
+   intel_wakeref_t wakeref;
+
gsccs_destroy_execution_resource(pxp);
+   with_intel_runtime_pm(>ctrl_gt->i915->runtime_pm, wakeref)
+   intel_pxp_fini_hw(pxp);
 }
 
 int intel_pxp_gsccs_init(struct intel_pxp *pxp)
 {
-   return gsccs_allocate_execution_resource(pxp);
+   int ret;
+   intel_wakeref_t wakeref;
+
+   ret = gsccs_allocate_execution_resource(pxp);
+   if (!ret) {
+   with_intel_runtime_pm(>ctrl_gt->i915->runtime_pm, wakeref)
+   intel_pxp_init_hw(pxp);
+   }
+   return ret;
 }
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 4f836b317424..1a04067f61fc 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -43,8 +43,9 @@ void intel_pxp_resume_complete(struct intel_pxp *pxp)
 * The PXP component gets automatically unbound when we go into S3 and
 * re-bound after we come out, so in that scenario we can defer the
 * hw init to the bind call.
+* NOTE: GSC-CS backend doesn't rely on components.
 */
-   if (!pxp->pxp_component)
+   if (!HAS_ENGINE(pxp->ctrl_gt, GSC0) && !pxp->pxp_component)
return;
 
intel_pxp_init_hw(pxp);
-- 
2.39.0



[PATCH v10 1/8] drm/i915/pxp: Add GSC-CS back-end resource init and cleanup

2023-05-10 Thread Alan Previn
For MTL, the PXP back-end transport uses the GSC engine to submit
HECI packets through the HW to the GSC firmware for PXP arb
session management. This submission uses a non-priveleged
batch buffer, a buffer for the command packet and of course
a context targeting the GSC-CS.

Thus for MTL, we need to allocate and free a set of execution
submission resources for the management of the arbitration session.
Lets start with the context creation first since that object and
its usage is very straight-forward. We'll add the buffer allocation
and freeing later when we introduce the gsccs' send-message function.

Do this one time allocation of gsccs specific resources in
a new gsccs source file with intel_pxp_gsccs_init / fini functions
and hook them up from the PXP front-end.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/Makefile  |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp.c   | 20 +--
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 63 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h | 29 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c   |  2 -
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h |  8 +++
 6 files changed, 117 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d97d45ae1a0d..7587fe856e67 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -343,6 +343,7 @@ i915-y += \
 i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp_cmd.o \
pxp/intel_pxp_debugfs.o \
+   pxp/intel_pxp_gsccs.o \
pxp/intel_pxp_irq.o \
pxp/intel_pxp_pm.o \
pxp/intel_pxp_session.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 9d4c7724e98e..f93aa171aa1e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -12,6 +12,7 @@
 #include "i915_drv.h"
 
 #include "intel_pxp.h"
+#include "intel_pxp_gsccs.h"
 #include "intel_pxp_irq.h"
 #include "intel_pxp_session.h"
 #include "intel_pxp_tee.h"
@@ -132,7 +133,10 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
 
-   ret = intel_pxp_tee_component_init(pxp);
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   ret = intel_pxp_gsccs_init(pxp);
+   else
+   ret = intel_pxp_tee_component_init(pxp);
if (ret)
goto out_context;
 
@@ -165,9 +169,12 @@ static struct intel_gt 
*find_gt_for_required_protected_content(struct drm_i915_p
/*
 * For MTL onwards, PXP-controller-GT needs to have a valid GSC engine
 * on the media GT. NOTE: if we have a media-tile with a GSC-engine,
-* the VDBOX is already present so skip that check
+* the VDBOX is already present so skip that check. We also have to
+* ensure the GSC and HUC firmware are coming online
 */
-   if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0))
+   if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0) &&
+   intel_uc_fw_is_loadable(>media_gt->uc.gsc.fw) &&
+   intel_uc_fw_is_loadable(>media_gt->uc.huc.fw))
return i915->media_gt;
 
/*
@@ -207,7 +214,9 @@ int intel_pxp_init(struct drm_i915_private *i915)
if (!i915->pxp)
return -ENOMEM;
 
+   /* init common info used by all feature-mode usages*/
i915->pxp->ctrl_gt = gt;
+   mutex_init(>pxp->tee_mutex);
 
/*
 * If full PXP feature is not available but HuC is loaded by GSC on 
pre-MTL
@@ -229,7 +238,10 @@ void intel_pxp_fini(struct drm_i915_private *i915)
 
i915->pxp->arb_is_valid = false;
 
-   intel_pxp_tee_component_fini(i915->pxp);
+   if (HAS_ENGINE(i915->pxp->ctrl_gt, GSC0))
+   intel_pxp_gsccs_fini(i915->pxp);
+   else
+   intel_pxp_tee_component_fini(i915->pxp);
 
destroy_vcs_context(i915->pxp);
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
new file mode 100644
index ..bad55719a7ac
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2023 Intel Corporation.
+ */
+
+#include "gem/i915_gem_internal.h"
+
+#include "gt/intel_context.h"
+
+#include "i915_drv.h"
+#include "intel_pxp_cmd_interface_43.h"
+#include "intel_pxp_gsccs.h"
+#include "intel_pxp_types.h"
+
+static void
+gsccs_destroy_execution_resource(struct intel_pxp *pxp)
+{
+   struct gsccs_session_resources *exec_res = >gsccs_res;
+
+   if (exec_res->ce)
+   intel_context_put(exec_res->ce);
+
+   memset(exec_res, 0, sizeof(*exec_res));
+}
+
+static int
+gsccs_allocate_execution_resource(struct intel_pxp *pxp)
+{
+   struct intel_gt *gt = 

[PATCH v10 2/8] drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation

2023-05-10 Thread Alan Previn
Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:

1. Updating 'pick-gt' to get the media tile for
   KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
   (init, status-checking, etc.).

While doing #2, lets create a separate registers header file for PXP
to be consistent with other i915 global subsystems.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/intel_gt_irq.c   |  3 +-
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 32 
 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h| 27 +
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 12 +++-
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h   |  6 
 5 files changed, 58 insertions(+), 22 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 95e59ed6651d..8f888d36f16d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -107,7 +107,8 @@ static struct intel_gt *pick_gt(struct intel_gt *gt, u8 
class, u8 instance)
case OTHER_CLASS:
if (instance == OTHER_GSC_HECI_2_INSTANCE)
return media_gt;
-   if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt, 
GSC0))
+   if ((instance == OTHER_GSC_INSTANCE || instance == 
OTHER_KCR_INSTANCE) &&
+   HAS_ENGINE(media_gt, GSC0))
return media_gt;
fallthrough;
default:
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index f93aa171aa1e..8949d4be7882 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -14,6 +14,7 @@
 #include "intel_pxp.h"
 #include "intel_pxp_gsccs.h"
 #include "intel_pxp_irq.h"
+#include "intel_pxp_regs.h"
 #include "intel_pxp_session.h"
 #include "intel_pxp_tee.h"
 #include "intel_pxp_types.h"
@@ -61,21 +62,22 @@ bool intel_pxp_is_active(const struct intel_pxp *pxp)
return IS_ENABLED(CONFIG_DRM_I915_PXP) && pxp && pxp->arb_is_valid;
 }
 
-/* KCR register definitions */
-#define KCR_INIT _MMIO(0x320f0)
-/* Setting KCR Init bit is required after system boot */
-#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+static void kcr_pxp_set_status(const struct intel_pxp *pxp, bool enable)
+{
+   u32 val = enable ? _MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES) 
:
+ _MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
+
+   intel_uncore_write(pxp->ctrl_gt->uncore, KCR_INIT(pxp->kcr_base), val);
+}
 
-static void kcr_pxp_enable(struct intel_gt *gt)
+static void kcr_pxp_enable(const struct intel_pxp *pxp)
 {
-   intel_uncore_write(gt->uncore, KCR_INIT,
-  
_MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+   kcr_pxp_set_status(pxp, true);
 }
 
-static void kcr_pxp_disable(struct intel_gt *gt)
+static void kcr_pxp_disable(const struct intel_pxp *pxp)
 {
-   intel_uncore_write(gt->uncore, KCR_INIT,
-  
_MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+   kcr_pxp_set_status(pxp, false);
 }
 
 static int create_vcs_context(struct intel_pxp *pxp)
@@ -127,6 +129,11 @@ static void pxp_init_full(struct intel_pxp *pxp)
init_completion(>termination);
complete_all(>termination);
 
+   if (pxp->ctrl_gt->type == GT_MEDIA)
+   pxp->kcr_base = MTL_KCR_BASE;
+   else
+   pxp->kcr_base = GEN12_KCR_BASE;
+
intel_pxp_session_management_init(pxp);
 
ret = create_vcs_context(pxp);
@@ -369,14 +376,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
 
 void intel_pxp_init_hw(struct intel_pxp *pxp)
 {
-   kcr_pxp_enable(pxp->ctrl_gt);
+   kcr_pxp_enable(pxp);
intel_pxp_irq_enable(pxp);
 }
 
 void intel_pxp_fini_hw(struct intel_pxp *pxp)
 {
-   kcr_pxp_disable(pxp->ctrl_gt);
-
+   kcr_pxp_disable(pxp);
intel_pxp_irq_disable(pxp);
 }
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
new file mode 100644
index ..a9e7e6efa4c7
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2023, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_REGS_H__
+#define __INTEL_PXP_REGS_H__
+
+#include "i915_reg_defs.h"
+
+/* KCR subsystem register base address */
+#define GEN12_KCR_BASE 0x32000
+#define MTL_KCR_BASE 0x386000
+
+/* KCR enable/disable control */
+#define KCR_INIT(base) _MMIO((base) + 0xf0)
+
+/* Setting KCR Init bit is required after system boot */
+#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+
+/* KCR hwdrm session in play status 0-31 */
+#define KCR_SIP(base) _MMIO((base) + 0x260)
+
+/* PXP global terminate register for session termination */
+#define 

[PATCH v10 0/8] drm/i915/pxp: Add MTL PXP Support

2023-05-10 Thread Alan Previn
This series enables PXP on MTL. On ADL/TGL platforms, we rely on
the mei driver via the i915-mei PXP component interface to establish
a connection to the security firmware via the HECI device interface.
That interface is used to create and teardown the PXP ARB session.
PXP ARB session is created when protected contexts are created.

In this series, the front end behaviors and interfaces (uapi) remain
the same. We add backend support for MTL but with MTL we directly use
the GSC-CS engine on the MTL GPU device to send messages to the PXP
(a.k.a. GSC a.k.a graphics-security) firmware. With MTL, the format
of the message is slightly different with a 2-layer packetization
that is explained in detail in Patch #3. Also, the second layer
which is the actual PXP firmware packet is now rev'd to version 4.3
for MTL that is defined in Patch #5.

Take note that Patch #4 adds the buffer allocation and gsccs-send-
message without actually being called by the arb-creation code
which gets added in Patch #5. Additionally, a seperate series being
reviewed is introducing a change for session teardown (in pxp front-
end layer that will need backend support by both legacy and gsccs).
If we squash all of these together (buffer-alloc, send-message,
arb-creation and, in future, session-termination), the single patch
will be rather large. That said, we are keeping Patch #4 and #5
separate for now, but at merge time, we can squash them together
if maintainer requires it.

Changes from prior revs:
   v1 : - fixed when building with CONFIG_PXP disabled.
- more alignment with gsc_mtl_header structure from the HDCP
   v2 : - (all following changes as per reviews from Daniele)
- squashed Patch #1 from v1 into the next one.
- replaced unnecessary "uses_gsccs" boolean in the pxp
  with "HAS_ENGINE(pxp->ctrl_gt, GSC0)".
- moved the stashing of gsccs resources from a dynamically
  allocated opaque handle to an explicit sub-struct in
  'struct intel_pxp'.
- moved the buffer object allocations from Patch #1 of this
  series to Patch #5 (but keep the context allocation in
  Patch #1).
- used the kernel default ppgtt for the gsccs context.
- optimized the buffer allocation and deallocation code
  and drop the need to stash the drm_i915_gem_object.
- use a macro with the right mmio reg base (depending
  on root-tile vs media-tile) along with common relative
  offset to access all KCR registers thus minimizing
  changes to the KCR register access codes.
- fixed bugs in the heci packet request submission code
  in Patch #3 (of this series)
- add comments in the mtl-gsc-heci-header regarding the
  host-session-handle.
- re-use tee-mutex instead of introducing a gsccs specific
  cmd mutex.
- minor cosmetic improvements in Patch #5.
- before creating arb session, ensure intel_pxp_start
  first ensures the GSC FW is up and running.
- use 2 second timeout for the pending-bit scenario when
  sending command to GSC-FW as per specs.
- simplify intel_pxp_get_irq_gt with addition comments
- redo Patch #7 to minimize the changes without introducing
  a common  abstraction helper for suspend/resume/init/fini
  codes that have to change the kcr power state.
   v3 : - rebase onto latest drm-tip with the updated firmware
  session invalidation flow
- on Patch#1: move 'mutex_init(>tee_mutex)' to a common
  init place in intel_pxp_init since its needed everywhere
  (Daniele)
- on Patch#1: remove unneccasary "ce->vm = i915_vm_get(vm);"
  (Daniele)
- on Patch#2: move the introduction of host_session_handle to
  Patch#4 where it starts getting used.
- on Patch#4: move host-session-handle initialization to the
  allocate-resources during gsccs-init (away from Patch#5)
  and add the required call to PXP-firmware to cleanup the
  host-session-handle in destroy-resources during gsccs-fini
- on Patch#5: add dispatching of arb session termination
  firmware cmd during session teardown (as per latest
  upstream flows)
   v4 : - Added proper initialization and cleanup of host-session-handle
  that the gsc firmware expects.
- Fix the stream-session-key invalidation instruction for MTL.
   v5 : - In Patch #4, move the tee_mutex locking to after we check for
  valid vma allocations.
- In Patch #5, wait for intel_huc_is_authenticated instead of
  intel_uc_fw_is_running(gsc-fw) before starting ARB session.
- In Patch #5, increase the necessary timeouts at the top-level
  (PXP arb session creation / termination) to accomodate SLA of
  GSC firmware when busy with pending-bit responses.
- In Patch #5, remove redundant host_session_handle init 

Re: [PATCH v3] firmware/sysfb: Fix VESA format selection

2023-05-10 Thread Pierre Asselin
Thomas Zimmerman  writes:
>
> I found this casting mess even more unreadable. I went back to v2, fixed
> the style issues and committed the patch as v4 (still under your name).
>
> https://cgit.freedesktop.org/drm/drm-tip/commit?id=1b617bc93178912fa36f87a957c15d1f1708c299

Will this patch make it into Linux 6.4 ?

--PA



Re: [PATCH] accel/qaic: silence some uninitialized variable warnings

2023-05-10 Thread Dan Carpenter
On Wed, May 10, 2023 at 08:57:03AM -0600, Jeffrey Hugo wrote:
> On 5/3/2023 4:41 AM, Dan Carpenter wrote:
> > Smatch complains that these are not initialized if get_cntl_version()
> > fails but we still print them in the debug message.  Not the end of
> > the world, but true enough.  Let's just initialize them to a dummy value
> > to make the checker happy.
> > 
> > Signed-off-by: Dan Carpenter 
> 
> Thanks for the cleanup.
> 
> Reviewed-by: Jeffrey Hugo 
> 
> Could use a fixes tag

The fixes tag thing could have gone either way.  It's really minor.

> and also I'd prefer to maintain the style of sorting
> the variable declaration lines by line length.  Given the minor nature of
> these nits, I plan to address them.

Thanks!

regards,
dan carpenter


[PATCH v2] drm/mediatek: Stop using iommu_present()

2023-05-10 Thread Robin Murphy
Remove the pointless check. If an IOMMU is providing transparent DMA API
ops for any device(s) we care about, the DT code will have enforced the
appropriate probe ordering already.

Signed-off-by: Robin Murphy 
---

v2: Rebase to 6.4-rc1

 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 6dcb4ba2466c..3e677eb0dc70 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -5,7 +5,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -582,9 +581,6 @@ static int mtk_drm_bind(struct device *dev)
struct drm_device *drm;
int ret, i;
 
-   if (!iommu_present(_bus_type))
-   return -EPROBE_DEFER;
-
pdev = of_find_device_by_node(private->mutex_node);
if (!pdev) {
dev_err(dev, "Waiting for disp-mutex device %pOF\n",
-- 
2.39.2.101.g768bb238c484.dirty



Re: [PATCH v6 5/6] drm: lcdif: Add multiple encoders and first bridges support

2023-05-10 Thread Marek Vasut

On 5/10/23 11:24, Liu Ying wrote:

The single LCDIF embedded in i.MX93 SoC may drive multiple displays
simultaneously.  Look at LCDIF output port's remote port parents to
find all enabled first bridges.  Add an encoder for each found bridge
and attach the bridge to the encoder.  This is a preparation for
adding i.MX93 LCDIF support.

Tested-by: Alexander Stein 
Acked-by: Alexander Stein 
Signed-off-by: Liu Ying 
---
v5->v6:
* Drop MAX_DISPLAYS macro. (Marek)
* Drop the encoder member in struct lcdif_drm_private.
* Drop endpoint id check.


It might be nice to check (based on driver data for each IP variant) the 
encoder count, but that can be a separate patch.


Reviewed-by: Marek Vasut 

Thanks !

btw if this doesn't get picked by someone in like a week or two, let me 
know and I'll apply this via drm-misc .


Re: [PATCH v6 2/6] drm: lcdif: Drop unnecessary NULL pointer check on lcdif->bridge

2023-05-10 Thread Marek Vasut

On 5/10/23 11:24, Liu Ying wrote:

A valid bridge is already found in lcdif_attach_bridge() and set
to lcdif->bridge, so lcdif->bridge cannot be a NULL pointer. Drop
the unnecessary NULL pointer check in KMS stage.

Tested-by: Alexander Stein 
Reviewed-by: Alexander Stein 
Signed-off-by: Liu Ying 


Reviewed-by: Marek Vasut 


Re: [PATCH v2] backlight: lm3630a: turn off both led strings when display is blank

2023-05-10 Thread Sam Ravnborg
On Wed, May 10, 2023 at 10:52:39AM +0200, Maximilian Weigand wrote:
> From: Maximilian Weigand 
> 
> Use backlight_is_blank() to determine if the led strings should be turned
> off in the update_status() functions of both strings.
> 
> Reviewed-by: Daniel Thompson 
> Signed-off-by: Maximilian Weigand 

Looks good.
Reviewed-by: Sam Ravnborg 


Re: [PATCH 36/53] drm/panfrost: Convert to platform remove callback returning void

2023-05-10 Thread Steven Price
On 07/05/2023 17:25, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
> 
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
> 
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Steven Price 

> ---
>  drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index abb0dadd8f63..adaacc8c39d7 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -618,7 +618,7 @@ static int panfrost_probe(struct platform_device *pdev)
>   return err;
>  }
>  
> -static int panfrost_remove(struct platform_device *pdev)
> +static void panfrost_remove(struct platform_device *pdev)
>  {
>   struct panfrost_device *pfdev = platform_get_drvdata(pdev);
>   struct drm_device *ddev = pfdev->ddev;
> @@ -632,7 +632,6 @@ static int panfrost_remove(struct platform_device *pdev)
>   pm_runtime_set_suspended(pfdev->dev);
>  
>   drm_dev_put(ddev);
> - return 0;
>  }
>  
>  /*
> @@ -687,7 +686,7 @@ MODULE_DEVICE_TABLE(of, dt_match);
>  
>  static struct platform_driver panfrost_driver = {
>   .probe  = panfrost_probe,
> - .remove = panfrost_remove,
> + .remove_new = panfrost_remove,
>   .driver = {
>   .name   = "panfrost",
>   .pm = pm_ptr(_pm_ops),



[PATCH 5/5] gpu: host1x: Stop open-coding of_device_uevent()

2023-05-10 Thread Miquel Raynal
There is apparently no reasons to open-code of_device_uevent() besides:
- The helper receives a struct device while we want to use the of_node
  member of the struct device *parent*.
- of_device_uevent() could not be called by modules because of a missing
  EXPORT_SYMBOL*().

In practice, the former point is not very constraining, just calling
of_device_uevent(dev->parent, ...) would have made the trick.

The latter point is more an observation rather than a real blocking
point because nothing prevented of_uevent() (called by the inline
function of_device_uevent()) to be exported to modules. In practice,
this helper is now exported, so nothing prevent us from using
of_device_uevent() anymore.

Let's use the core helper directly instead of open-coding it.

Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Mikko Perttunen 
Cc: Rob Herring 
Cc: Frank Rowand 
Signed-off-by: Miquel Raynal 

---

This patch depends on the changes performed earlier in the series under
the drivers/of/ folder.
---
 drivers/gpu/host1x/bus.c | 31 ++-
 1 file changed, 6 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 4d16a3396c4a..6434a183fb72 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -338,34 +338,15 @@ static int host1x_device_match(struct device *dev, struct 
device_driver *drv)
return strcmp(dev_name(dev), drv->name) == 0;
 }
 
+/*
+ * Note that this is really only needed for backwards compatibility
+ * with libdrm, which parses this information from sysfs and will
+ * fail if it can't find the OF_FULLNAME, specifically.
+ */
 static int host1x_device_uevent(const struct device *dev,
struct kobj_uevent_env *env)
 {
-   struct device_node *np = dev->parent->of_node;
-   unsigned int count = 0;
-   struct property *p;
-   const char *compat;
-
-   /*
-* This duplicates most of of_device_uevent(), but the latter cannot
-* be called from modules and operates on dev->of_node, which is not
-* available in this case.
-*
-* Note that this is really only needed for backwards compatibility
-* with libdrm, which parses this information from sysfs and will
-* fail if it can't find the OF_FULLNAME, specifically.
-*/
-   add_uevent_var(env, "OF_NAME=%pOFn", np);
-   add_uevent_var(env, "OF_FULLNAME=%pOF", np);
-
-   of_property_for_each_string(np, "compatible", p, compat) {
-   add_uevent_var(env, "OF_COMPATIBLE_%u=%s", count, compat);
-   count++;
-   }
-
-   add_uevent_var(env, "OF_COMPATIBLE_N=%u", count);
-
-   return 0;
+   return of_device_uevent((const struct device *)>parent, env);
 }
 
 static int host1x_dma_configure(struct device *dev)
-- 
2.34.1



[PATCH 1/5] of: module: Mutate of_device_modalias() into two helpers

2023-05-10 Thread Miquel Raynal
Move the content of the helper providing printable modaliases in
module.c. Call this new function from an of_device.c inline helper.

There is no functional changes. However, as a side effect, we fix the
return value of the inline helper (in the !CONFIG_OF case) which should
be a ssize_t instead of int.

Signed-off-by: Miquel Raynal 
---
 drivers/of/device.c   | 25 -
 drivers/of/module.c   | 19 +++
 include/linux/of.h|  8 
 include/linux/of_device.h | 13 ++---
 4 files changed, 37 insertions(+), 28 deletions(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 0f00f1b80708..45ce83a8945f 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -246,31 +246,6 @@ const void *of_device_get_match_data(const struct device 
*dev)
 }
 EXPORT_SYMBOL(of_device_get_match_data);
 
-/**
- * of_device_modalias - Fill buffer with newline terminated modalias string
- * @dev:   Calling device
- * @str:   Modalias string
- * @len:   Size of @str
- */
-ssize_t of_device_modalias(struct device *dev, char *str, ssize_t len)
-{
-   ssize_t sl;
-
-   if (!dev || !dev->of_node || dev->of_node_reused)
-   return -ENODEV;
-
-   sl = of_modalias(dev->of_node, str, len - 2);
-   if (sl < 0)
-   return sl;
-   if (sl > len - 2)
-   return -ENOMEM;
-
-   str[sl++] = '\n';
-   str[sl] = 0;
-   return sl;
-}
-EXPORT_SYMBOL_GPL(of_device_modalias);
-
 /**
  * of_device_uevent - Display OF related uevent information
  * @dev:   Device to display the uevent information for
diff --git a/drivers/of/module.c b/drivers/of/module.c
index 0e8aa974f0f2..c05fb8ca575c 100644
--- a/drivers/of/module.c
+++ b/drivers/of/module.c
@@ -44,6 +44,25 @@ ssize_t of_modalias(const struct device_node *np, char *str, 
ssize_t len)
return tsize;
 }
 
+ssize_t of_printable_modalias(const struct device_node *np, char *str, ssize_t 
len)
+{
+   ssize_t sl;
+
+   if (!np)
+   return -ENODEV;
+
+   sl = of_modalias(np, str, len - 2);
+   if (sl < 0)
+   return sl;
+   if (sl > len - 2)
+   return -ENOMEM;
+
+   str[sl++] = '\n';
+   str[sl] = 0;
+   return sl;
+}
+EXPORT_SYMBOL_GPL(of_printable_modalias);
+
 int of_request_module(const struct device_node *np)
 {
char *str;
diff --git a/include/linux/of.h b/include/linux/of.h
index 6ecde0515677..dcdd9396ac37 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -385,6 +385,8 @@ extern int of_count_phandle_with_args(const struct 
device_node *np,
 
 /* module functions */
 extern ssize_t of_modalias(const struct device_node *np, char *str, ssize_t 
len);
+extern ssize_t of_printable_modalias(const struct device_node *np, char *str,
+ssize_t len);
 extern int of_request_module(const struct device_node *np);
 
 /* phandle iterator functions */
@@ -758,6 +760,12 @@ static inline ssize_t of_modalias(const struct device_node 
*np, char *str,
return -ENODEV;
 }
 
+static inline ssize_t of_printable_modalias(const struct device_node *np,
+   char *str, ssize_t len)
+{
+   return -ENODEV;
+}
+
 static inline int of_request_module(const struct device_node *np)
 {
return -ENODEV;
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index 2c7a3d4bc775..bca66f59814a 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -26,7 +26,14 @@ static inline int of_driver_match_device(struct device *dev,
return of_match_device(drv->of_match_table, dev) != NULL;
 }
 
-extern ssize_t of_device_modalias(struct device *dev, char *str, ssize_t len);
+static inline ssize_t of_device_modalias(struct device *dev, char *str,
+ssize_t len)
+{
+   if (!dev || !dev->of_node || dev->of_node_reused)
+   return -ENODEV;
+
+   return of_printable_modalias(dev->of_node, str, len);
+}
 
 extern void of_device_uevent(const struct device *dev, struct kobj_uevent_env 
*env);
 extern int of_device_uevent_modalias(const struct device *dev, struct 
kobj_uevent_env *env);
@@ -51,8 +58,8 @@ static inline int of_driver_match_device(struct device *dev,
 static inline void of_device_uevent(const struct device *dev,
struct kobj_uevent_env *env) { }
 
-static inline int of_device_modalias(struct device *dev,
-char *str, ssize_t len)
+static inline ssize_t of_device_modalias(struct device *dev,
+char *str, ssize_t len)
 {
return -ENODEV;
 }
-- 
2.34.1



[PATCH 3/5] of: module: Mutate of_device_uevent_modalias() into two helpers

2023-05-10 Thread Miquel Raynal
Let's move the logic of the former helper into module.c and use it from
an inline helper located under of_device.c. This way there is no change
for users while the logic gets moved to an OF-only file.

Signed-off-by: Miquel Raynal 
---
 drivers/of/device.c   | 23 ---
 drivers/of/module.c   | 21 +
 include/linux/of.h|  7 +++
 include/linux/of_device.h |  9 -
 4 files changed, 36 insertions(+), 24 deletions(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 5e538e1ed623..7909eefc650e 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -245,26 +245,3 @@ const void *of_device_get_match_data(const struct device 
*dev)
return match->data;
 }
 EXPORT_SYMBOL(of_device_get_match_data);
-
-int of_device_uevent_modalias(const struct device *dev, struct kobj_uevent_env 
*env)
-{
-   int sl;
-
-   if ((!dev) || (!dev->of_node) || dev->of_node_reused)
-   return -ENODEV;
-
-   /* Devicetree modalias is tricky, we add it in 2 steps */
-   if (add_uevent_var(env, "MODALIAS="))
-   return -ENOMEM;
-
-   sl = of_modalias(dev->of_node, >buf[env->buflen-1],
-sizeof(env->buf) - env->buflen);
-   if (sl < 0)
-   return sl;
-   if (sl >= (sizeof(env->buf) - env->buflen))
-   return -ENOMEM;
-   env->buflen += sl;
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(of_device_uevent_modalias);
diff --git a/drivers/of/module.c b/drivers/of/module.c
index c729675fdd04..874f3fb8220f 100644
--- a/drivers/of/module.c
+++ b/drivers/of/module.c
@@ -132,3 +132,24 @@ int of_uevent(struct device_node *np, struct 
kobj_uevent_env *env)
 
return 0;
 }
+
+int of_uevent_modalias(const struct device_node *np, struct kobj_uevent_env 
*env)
+{
+   int sl;
+
+   if (!np)
+   return -ENODEV;
+
+   /* Devicetree modalias is tricky, we add it in 2 steps */
+   if (add_uevent_var(env, "MODALIAS="))
+   return -ENOMEM;
+
+   sl = of_modalias(np, >buf[env->buflen-1],
+sizeof(env->buf) - env->buflen);
+   if (sl >= (sizeof(env->buf) - env->buflen))
+   return -ENOMEM;
+   env->buflen += sl;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_uevent_modalias);
diff --git a/include/linux/of.h b/include/linux/of.h
index d99f33fc25d3..203bd2895d94 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -389,6 +389,7 @@ extern ssize_t of_printable_modalias(const struct 
device_node *np, char *str,
 ssize_t len);
 extern int of_request_module(const struct device_node *np);
 extern int of_uevent(struct device_node *np, struct kobj_uevent_env *env);
+extern int of_uevent_modalias(const struct device_node *np, struct 
kobj_uevent_env *env);
 
 /* phandle iterator functions */
 extern int of_phandle_iterator_init(struct of_phandle_iterator *it,
@@ -777,6 +778,12 @@ static inline int of_uevent(struct device_node *np, struct 
kobj_uevent_env *env)
return -ENODEV;
 }
 
+static inline int of_uevent_modalias(const struct device_node *np,
+struct kobj_uevent_env *env)
+{
+   return -ENODEV;
+}
+
 static inline int of_phandle_iterator_init(struct of_phandle_iterator *it,
   const struct device_node *np,
   const char *list_name,
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index af5ee78e0c05..5e428bcf3d63 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -44,7 +44,14 @@ static inline int of_device_uevent(const struct device *dev,
return of_uevent(dev->of_node, env);
 }
 
-extern int of_device_uevent_modalias(const struct device *dev, struct 
kobj_uevent_env *env);
+static inline int of_device_uevent_modalias(const struct device *dev,
+   struct kobj_uevent_env *env)
+{
+   if (!dev || !dev->of_node || dev->of_node_reused)
+   return -ENODEV;
+
+   return of_uevent_modalias(dev->of_node, env);
+}
 
 int of_dma_configure_id(struct device *dev,
 struct device_node *np,
-- 
2.34.1



[PATCH 0/5] of: More 'device' vs. 'module' cleanups

2023-05-10 Thread Miquel Raynal
Hello,

As part of a previous series, Rob suggested that keeping too much logic
in of/device.c was backward and would benefit from a gradual cleanup
with the hope some day to move the remaining helpers into inline
functions wrapping the proper of_*() methods.

Link: 
https://lore.kernel.org/lkml/cal_jsqje43qfyzhuucjsbappbtbyx05q7ffmptjpfz3dmz_...@mail.gmail.com/

A few of these "conversions" happened in the series I was originally
working on. At this time I actually wrote a few other changes,
completely unrelated to my original series, but still following Rob's
cleanup idea: here they are.

Link: 
https://lore.kernel.org/lkml/20230307165359.225361-1-miquel.ray...@bootlin.com/

The last step of this series is to actually remove a copy of one of
these helpers which I think is not needed. This drivers/gpu/ patch
depends on the previous changes.

Thanks, Miquèl

Miquel Raynal (5):
  of: module: Mutate of_device_modalias() into two helpers
  of: module: Mutate of_device_uevent() into two helpers
  of: module: Mutate of_device_uevent_modalias() into two helpers
  of: module: Export of_uevent()
  gpu: host1x: Stop open-coding of_device_uevent()

 drivers/gpu/host1x/bus.c  | 31 +++---
 drivers/of/device.c   | 90 ---
 drivers/of/module.c   | 82 +++
 include/linux/of.h| 21 +
 include/linux/of_device.h | 39 ++---
 5 files changed, 141 insertions(+), 122 deletions(-)

-- 
2.34.1



[PATCH 4/5] of: module: Export of_uevent()

2023-05-10 Thread Miquel Raynal
The content of of_uevent() is currently hardcoded in a driver that can
be compiled as a module. Nothing prevents of_uevent() to be exported to
modules, most of the other helpers in of_device.c actually are.The
reason why this helper was not exported is because it has been so far
only useful in drivers/base, which is built-in anyway.

With the idea of getting rid of the hardcoded implementation of
of_uevent() in other places in the kernel, let's export it to GPL
modules (very much like its cousins in the same file).

Signed-off-by: Miquel Raynal 
---
 drivers/of/module.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/of/module.c b/drivers/of/module.c
index 874f3fb8220f..8b402a716951 100644
--- a/drivers/of/module.c
+++ b/drivers/of/module.c
@@ -132,6 +132,7 @@ int of_uevent(struct device_node *np, struct 
kobj_uevent_env *env)
 
return 0;
 }
+EXPORT_SYMBOL_GPL(of_uevent);
 
 int of_uevent_modalias(const struct device_node *np, struct kobj_uevent_env 
*env)
 {
-- 
2.34.1



[PATCH 2/5] of: module: Mutate of_device_uevent() into two helpers

2023-05-10 Thread Miquel Raynal
Move the OF related logic inside of/module.c and use it from of_device.h
with an inline helper so there is no visible change from the users point
of view.

Signed-off-by: Miquel Raynal 
---
 drivers/of/device.c   | 42 ---
 drivers/of/module.c   | 41 ++
 include/linux/of.h|  6 ++
 include/linux/of_device.h | 17 +---
 4 files changed, 61 insertions(+), 45 deletions(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 45ce83a8945f..5e538e1ed623 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -246,48 +246,6 @@ const void *of_device_get_match_data(const struct device 
*dev)
 }
 EXPORT_SYMBOL(of_device_get_match_data);
 
-/**
- * of_device_uevent - Display OF related uevent information
- * @dev:   Device to display the uevent information for
- * @env:   Kernel object's userspace event reference to fill up
- */
-void of_device_uevent(const struct device *dev, struct kobj_uevent_env *env)
-{
-   const char *compat, *type;
-   struct alias_prop *app;
-   struct property *p;
-   int seen = 0;
-
-   if ((!dev) || (!dev->of_node))
-   return;
-
-   add_uevent_var(env, "OF_NAME=%pOFn", dev->of_node);
-   add_uevent_var(env, "OF_FULLNAME=%pOF", dev->of_node);
-   type = of_node_get_device_type(dev->of_node);
-   if (type)
-   add_uevent_var(env, "OF_TYPE=%s", type);
-
-   /* Since the compatible field can contain pretty much anything
-* it's not really legal to split it out with commas. We split it
-* up using a number of environment variables instead. */
-   of_property_for_each_string(dev->of_node, "compatible", p, compat) {
-   add_uevent_var(env, "OF_COMPATIBLE_%d=%s", seen, compat);
-   seen++;
-   }
-   add_uevent_var(env, "OF_COMPATIBLE_N=%d", seen);
-
-   seen = 0;
-   mutex_lock(_mutex);
-   list_for_each_entry(app, _lookup, link) {
-   if (dev->of_node == app->np) {
-   add_uevent_var(env, "OF_ALIAS_%d=%s", seen,
-  app->alias);
-   seen++;
-   }
-   }
-   mutex_unlock(_mutex);
-}
-
 int of_device_uevent_modalias(const struct device *dev, struct kobj_uevent_env 
*env)
 {
int sl;
diff --git a/drivers/of/module.c b/drivers/of/module.c
index c05fb8ca575c..c729675fdd04 100644
--- a/drivers/of/module.c
+++ b/drivers/of/module.c
@@ -8,6 +8,8 @@
 #include 
 #include 
 
+#include "of_private.h"
+
 ssize_t of_modalias(const struct device_node *np, char *str, ssize_t len)
 {
const char *compat;
@@ -91,3 +93,42 @@ int of_request_module(const struct device_node *np)
return ret;
 }
 EXPORT_SYMBOL_GPL(of_request_module);
+
+int of_uevent(struct device_node *np, struct kobj_uevent_env *env)
+{
+   const char *compat, *type;
+   struct alias_prop *app;
+   struct property *p;
+   int seen = 0;
+
+   if (!np)
+   return -ENODEV;
+
+   add_uevent_var(env, "OF_NAME=%pOFn", np);
+   add_uevent_var(env, "OF_FULLNAME=%pOF", np);
+   type = of_node_get_device_type(np);
+   if (type)
+   add_uevent_var(env, "OF_TYPE=%s", type);
+
+   /* Since the compatible field can contain pretty much anything
+* it's not really legal to split it out with commas. We split it
+* up using a number of environment variables instead. */
+   of_property_for_each_string(np, "compatible", p, compat) {
+   add_uevent_var(env, "OF_COMPATIBLE_%d=%s", seen, compat);
+   seen++;
+   }
+   add_uevent_var(env, "OF_COMPATIBLE_N=%d", seen);
+
+   seen = 0;
+   mutex_lock(_mutex);
+   list_for_each_entry(app, _lookup, link) {
+   if (np == app->np) {
+   add_uevent_var(env, "OF_ALIAS_%d=%s", seen,
+  app->alias);
+   seen++;
+   }
+   }
+   mutex_unlock(_mutex);
+
+   return 0;
+}
diff --git a/include/linux/of.h b/include/linux/of.h
index dcdd9396ac37..d99f33fc25d3 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -388,6 +388,7 @@ extern ssize_t of_modalias(const struct device_node *np, 
char *str, ssize_t len)
 extern ssize_t of_printable_modalias(const struct device_node *np, char *str,
 ssize_t len);
 extern int of_request_module(const struct device_node *np);
+extern int of_uevent(struct device_node *np, struct kobj_uevent_env *env);
 
 /* phandle iterator functions */
 extern int of_phandle_iterator_init(struct of_phandle_iterator *it,
@@ -771,6 +772,11 @@ static inline int of_request_module(const struct 
device_node *np)
return -ENODEV;
 }
 
+static inline int of_uevent(struct device_node *np, struct kobj_uevent_env 
*env)
+{
+   return -ENODEV;
+}
+
 static inline int 

Re: [PATCH v6 5/6] fbdev: Move framebuffer I/O helpers into

2023-05-10 Thread Arnd Bergmann
On Wed, May 10, 2023, at 16:27, Thomas Zimmermann wrote:
> Am 10.05.23 um 16:15 schrieb Arnd Bergmann:
>> On Wed, May 10, 2023, at 16:03, kernel test robot wrote:
 
>> I think that's a preexisting bug and I have no idea what the
>> correct solution is. Looking for HD64461 shows it being used
>> both with inw/outw and readw/writew, so there is no way to have
>> the correct type. The sh __raw_readw() definition hides this bug,
>> but that is a problem with arch/sh and it probably hides others
>> as well.
>
> The constant HD64461_IOBASE is defined as integer at
>
> 
> https://elixir.bootlin.com/linux/latest/source/arch/sh/include/asm/hd64461.h#L17
>
> but fb_readw() expects a volatile-void pointer. I guess we could add a 
> cast somewhere to silence the problem. In the current upstream code, 
> that appears to be done by sh's __raw_readw() internally:
>
> 
> https://elixir.bootlin.com/linux/latest/source/arch/sh/include/asm/io.h#L35

Sure, that would make it build again, but that still doesn't make the
code correct, since it's completely unclear what base address the
HD64461_IOBASE is relative to. The hp6xx platform code only passes it
through inw()/outw(), which take an offset relative to sh_io_port_base,
but that is not initialized on hp6xx. I tried to find in the history
when it broke, apparently that was in 2007 commit 34a780a0afeb ("sh:
hp6xx pata_platform support."), which removed the custom inw/outw
implementations.

  Arnd


Re: [PATCH v6 5/6] fbdev: Move framebuffer I/O helpers into

2023-05-10 Thread Thomas Zimmermann

Hi Geert

Am 10.05.23 um 16:34 schrieb Geert Uytterhoeven:

Hi Thomas,

On Wed, May 10, 2023 at 4:20 PM Thomas Zimmermann  wrote:

Am 10.05.23 um 14:34 schrieb Geert Uytterhoeven:

On Wed, May 10, 2023 at 1:06 PM Thomas Zimmermann  wrote:

Implement framebuffer I/O helpers, such as fb_read*() and fb_write*(),
in the architecture's  header file or the generic one.

The common case has been the use of regular I/O functions, such as
__raw_readb() or memset_io(). A few architectures used plain system-
memory reads and writes. Sparc used helpers for its SBus.

The architectures that used special cases provide the same code in
their __raw_*() I/O helpers. So the patch replaces this code with the
__raw_*() functions and moves it to  for all
architectures.

v6:
  * fix fb_readq()/fb_writeq() on 64-bit mips (kernel test robot)
v5:
  * include  in ; fix s390 build
v4:
  * ia64, loongarch, sparc64: add fb_mem*() to arch headers
to keep current semantics (Arnd)
v3:
  * implement all architectures with generic helpers
  * support reordering and native byte order (Geert, Arnd)

Signed-off-by: Thomas Zimmermann 
Tested-by: Sui Jingfeng 
Reviewed-by: Arnd Bergmann 



--- a/arch/mips/include/asm/fb.h
+++ b/arch/mips/include/asm/fb.h
@@ -12,6 +12,28 @@ static inline void fb_pgprotect(struct file *file, struct 
vm_area_struct *vma,
   }
   #define fb_pgprotect fb_pgprotect

+/*
+ * MIPS doesn't define __raw_ I/O macros, so the helpers
+ * in  don't generate fb_readq() and
+ * fb_write(). We have to provide them here.


MIPS does not include ,  nor define its own


I know, that's why the TODO says to convert it to generic I/O.


__raw_readq() and __raw_writeq()...


It doesn't define those macros, but it generates function calls of the
same names. Follow the macros at


https://elixir.bootlin.com/linux/latest/source/arch/mips/include/asm/io.h#L357

It expands to a variety of helpers, including __raw_*().


Thanks, I forgot MIPS is using these grep-unfriendly factories...


+ *
+ * TODO: Convert MIPS to generic I/O. The helpers below can
+ *   then be removed.
+ */
+#ifdef CONFIG_64BIT
+static inline u64 fb_readq(const volatile void __iomem *addr)
+{
+   return __raw_readq(addr);


... so how can this call work?


On 64-bit builds, there's __raw_readq() and __raw_writeq().

At first, I tried to do the right thing and convert MIPS to work with
. But that created a ton of follow-up errors in other
headers. So for now, it's better to handle this problem in asm/fb.h.


So isn't just adding

 #define __raw_readq __raw_readq
 #define __raw_writeq __raw_writeq

to arch/mips/include/asm/io.h sufficient to make 
do the right thing?


That works. I had a patch that adds all missing defines to MIPS' io.h. 
Then I went with the current fix, which is self-contained within fbdev. 
But I'd leave it to arch maintainers.


Best regards
Thomas




Gr{oetje,eeting}s,

 Geert



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH v1] backlight: lm3630a: turn off both led strings when display is blank

2023-05-10 Thread Maximilian Weigand


>> +if (backlight_is_blank(bl) || (bl->props.brightness < 0x4))
> You could replace bl->props.brightness with backlight_get_brightness(bl)
> to avoid direct access to the properties.

Thanks. Changed in v2.

>> +/* turn the string off  */
>>  ret |= lm3630a_update(pchip, REG_CTRL, LM3630A_LEDA_ENABLE, 0);
>>  else
>>  ret |= lm3630a_update(pchip, REG_CTRL,
>> @@ -277,7 +279,9 @@ static int lm3630a_bank_b_update_status(struct 
>> backlight_device *bl)
>>  usleep_range(1000, 2000);
>>  /* minimum brightness is 0x04 */
>>  ret = lm3630a_write(pchip, REG_BRT_B, bl->props.brightness);
>> -if (bl->props.brightness < 0x4)
>> +
>> +if (backlight_is_blank(bl) || (bl->props.brightness < 0x4))

Thanks. Changed in v2.


[PATCH v2] backlight: lm3630a: turn off both led strings when display is blank

2023-05-10 Thread Maximilian Weigand
From: Maximilian Weigand 

Use backlight_is_blank() to determine if the led strings should be turned
off in the update_status() functions of both strings.

Reviewed-by: Daniel Thompson 
Signed-off-by: Maximilian Weigand 
---
Changes in v2:
- fix description, replace display_is_black() with backlight_is_black()
- use backlight_get_brightness() instead of accessing the property
  directly

 drivers/video/backlight/lm3630a_bl.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/lm3630a_bl.c 
b/drivers/video/backlight/lm3630a_bl.c
index d8c42acecb5d..faf92c8d70c1 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -202,7 +202,9 @@ static int lm3630a_bank_a_update_status(struct 
backlight_device *bl)
usleep_range(1000, 2000);
/* minimum brightness is 0x04 */
ret = lm3630a_write(pchip, REG_BRT_A, bl->props.brightness);
-   if (bl->props.brightness < 0x4)
+
+   if (backlight_is_blank(bl) || (backlight_get_brightness(bl) < 0x4))
+   /* turn the string off  */
ret |= lm3630a_update(pchip, REG_CTRL, LM3630A_LEDA_ENABLE, 0);
else
ret |= lm3630a_update(pchip, REG_CTRL,
@@ -277,7 +279,9 @@ static int lm3630a_bank_b_update_status(struct 
backlight_device *bl)
usleep_range(1000, 2000);
/* minimum brightness is 0x04 */
ret = lm3630a_write(pchip, REG_BRT_B, bl->props.brightness);
-   if (bl->props.brightness < 0x4)
+
+   if (backlight_is_blank(bl) || (backlight_get_brightness(bl) < 0x4))
+   /* turn the string off  */
ret |= lm3630a_update(pchip, REG_CTRL, LM3630A_LEDB_ENABLE, 0);
else
ret |= lm3630a_update(pchip, REG_CTRL,

base-commit: ac9a78681b921877518763ba0e89202254349d1b
--
2.39.2



Re: [PATCH v1] backlight: lm3630a: turn off both led strings when display is blank

2023-05-10 Thread Maximilian Weigand



>> Use display_is_blank() to determine if the led strings should be turned
> 
> Shouldn't this be backlight_is_blank()?

Yes, indeed. Thanks for pointing this out. Fixed in v2.


Re: [RFC PATCH 0/4] Add support for DRM cgroup memory accounting.

2023-05-10 Thread Maarten Lankhorst

Hey,

On 2023-05-05 21:50, Tejun Heo wrote:

Hello,

On Wed, May 03, 2023 at 10:34:56AM +0200, Maarten Lankhorst wrote:

RFC as I'm looking for comments.

For long running compute, it can be beneficial to partition the GPU memory
between cgroups, so each cgroup can use its maximum amount of memory without
interfering with other scheduled jobs. Done properly, this can alleviate the
need for eviction, which might result in a job being terminated if the GPU
doesn't support mid-thread preemption or recoverable page faults.

This is done by adding a bunch of knobs to cgroup:
drm.capacity: Shows maximum capacity of each resource region.
drm.max: Display or limit max amount of memory.
drm.current: Current amount of memory in use.

TTM has not been made cgroup aware yet, so instead of evicting from
the current cgroup to stay within the cgroup limits, it simply returns
the error -ENOSPC to userspace.

I've used Tvrtko's cgroup controller series as a base, but it implemented
scheduling weight, not memory accounting, so I only ended up keeping the
base patch.

Xe is not upstream yet, so the driver specific patch will only apply on
https://gitlab.freedesktop.org/drm/xe/kernel

Some high-level feedbacks.

* There have been multiple attempts at this but the track record is kinda
   poor. People don't seem to agree what should constitute DRM memory and how
   they should be accounted / controlled.


Thanks for the feedback.

I think for a lot of drivers, what is VRAM might have different meaning, but 
the intention
is it being accounted in the same way. Most drivers use TTM, which has a 
standard way
of allocating memory, and a standard way of evicting VRAM.

This makes it very useful for the usecase which I'm looking at, long running 
compute.
When you have long running jobs, you don't want them to be interrupted because 
a completely
unrelated process needs some VRAM, and one of the compute jobs buffers are 
being evicted.

Some hardware does not support mid-thread preemption or page fault recovery, 
this means that
when memory is evicted, the compute job is terminated.

The full problem statement is in drm-compute.rst in the memory accounting patch.


* I like Tvrtko's scheduling patchset because it exposes a generic interface
   which makes sense regardless of hardware details and then each driver can
   implement the configured control in whatever way they can. However, even
   for that, there doesn't seem much buy-in from other drivers.


Yeah, that is correct. But it tries to solve a different part of the problem.


* This proposal seems narrowly scoped trying to solve a specific problem
   which may not translate to different hardware configurations. Please let
   me know if I got that wrong, but if that's the case, I think a better and
   easier approach might be just being a part of the misc controller. That
   doesn't require much extra code and should be able to provide everything
   necessary for statically limiting specific resources.


The misc controller is not granular enough. A single computer may have any 
number of
graphics cards, some of them with multiple regions of vram inside a single card.

For compute and shared hosting you might want to limit the usage of a single 
memory
region on a single card, and then limit the same limits for the rest too, to 
prevent
triggering eviction.

The current version doesn't handle eviction correctly, because I was still 
working
on it and I wanted to post a RFC. As a result, the case where resource limit is 
hit
will evict the device's entire memory or get stuck in a loop. With some 
changes, the
next version will not have this bug. This results in a few changes to the core 
code. [1]

In the next version, I will move all the code for handling the resource limit to
TTM's eviction layer, because otherwise it cannot handle the resource limit 
correctly.

The effect of moving the code to TTM, is that it will make the code even more 
generic
for drivers that have vram and use TTM. When using TTM, you only have to 
describe your
VRAM, update some fields in the TTM manager and (un)register your device with 
the
cgroup handler on (un)load. It's quite trivial to add vram accounting to amdgpu 
and
nouveau. [2]

If you want to add a knob for scheduling weight for a process, it makes sense to
also add resource usage as a knob, otherwise the effect of that knob is very
limited. So even for Tvrtko's original proposed usecase, it would make sense.

Cheers,
~Maarten


[1] Compared to this version:
 static inline int drmcg_try_charge(struct drmcgroup_state **drmcs,
+  struct drmcgroup_state **limitcs,
   struct drmcgroup_device *cgdev,
   u32 index, u64 size)

This now returns which cgroup's limit is hit on -EAGAIN.

+bool drmcs_grouped(struct drmcgroup_state *limitcs,
+  struct drmcgroup_state *testcs);
Tells if testcs is the same as limitcs, or a subgroup 

Re: [PATCH] accel/qaic: silence some uninitialized variable warnings

2023-05-10 Thread Jeffrey Hugo

On 5/3/2023 4:41 AM, Dan Carpenter wrote:

Smatch complains that these are not initialized if get_cntl_version()
fails but we still print them in the debug message.  Not the end of
the world, but true enough.  Let's just initialize them to a dummy value
to make the checker happy.

Signed-off-by: Dan Carpenter 


Thanks for the cleanup.

Reviewed-by: Jeffrey Hugo 

Could use a fixes tag, and also I'd prefer to maintain the style of 
sorting the variable declaration lines by line length.  Given the minor 
nature of these nits, I plan to address them.


Re: [PATCH v6 5/6] fbdev: Move framebuffer I/O helpers into

2023-05-10 Thread Geert Uytterhoeven
Hi Thomas,

On Wed, May 10, 2023 at 4:20 PM Thomas Zimmermann  wrote:
> Am 10.05.23 um 14:34 schrieb Geert Uytterhoeven:
> > On Wed, May 10, 2023 at 1:06 PM Thomas Zimmermann  
> > wrote:
> >> Implement framebuffer I/O helpers, such as fb_read*() and fb_write*(),
> >> in the architecture's  header file or the generic one.
> >>
> >> The common case has been the use of regular I/O functions, such as
> >> __raw_readb() or memset_io(). A few architectures used plain system-
> >> memory reads and writes. Sparc used helpers for its SBus.
> >>
> >> The architectures that used special cases provide the same code in
> >> their __raw_*() I/O helpers. So the patch replaces this code with the
> >> __raw_*() functions and moves it to  for all
> >> architectures.
> >>
> >> v6:
> >>  * fix fb_readq()/fb_writeq() on 64-bit mips (kernel test robot)
> >> v5:
> >>  * include  in ; fix s390 build
> >> v4:
> >>  * ia64, loongarch, sparc64: add fb_mem*() to arch headers
> >>to keep current semantics (Arnd)
> >> v3:
> >>  * implement all architectures with generic helpers
> >>  * support reordering and native byte order (Geert, Arnd)
> >>
> >> Signed-off-by: Thomas Zimmermann 
> >> Tested-by: Sui Jingfeng 
> >> Reviewed-by: Arnd Bergmann 

> >> --- a/arch/mips/include/asm/fb.h
> >> +++ b/arch/mips/include/asm/fb.h
> >> @@ -12,6 +12,28 @@ static inline void fb_pgprotect(struct file *file, 
> >> struct vm_area_struct *vma,
> >>   }
> >>   #define fb_pgprotect fb_pgprotect
> >>
> >> +/*
> >> + * MIPS doesn't define __raw_ I/O macros, so the helpers
> >> + * in  don't generate fb_readq() and
> >> + * fb_write(). We have to provide them here.
> >
> > MIPS does not include ,  nor define its own
>
> I know, that's why the TODO says to convert it to generic I/O.
>
> > __raw_readq() and __raw_writeq()...
>
> It doesn't define those macros, but it generates function calls of the
> same names. Follow the macros at
>
>
> https://elixir.bootlin.com/linux/latest/source/arch/mips/include/asm/io.h#L357
>
> It expands to a variety of helpers, including __raw_*().

Thanks, I forgot MIPS is using these grep-unfriendly factories...

> >> + *
> >> + * TODO: Convert MIPS to generic I/O. The helpers below can
> >> + *   then be removed.
> >> + */
> >> +#ifdef CONFIG_64BIT
> >> +static inline u64 fb_readq(const volatile void __iomem *addr)
> >> +{
> >> +   return __raw_readq(addr);
> >
> > ... so how can this call work?
>
> On 64-bit builds, there's __raw_readq() and __raw_writeq().
>
> At first, I tried to do the right thing and convert MIPS to work with
> . But that created a ton of follow-up errors in other
> headers. So for now, it's better to handle this problem in asm/fb.h.

So isn't just adding

#define __raw_readq __raw_readq
#define __raw_writeq __raw_writeq

to arch/mips/include/asm/io.h sufficient to make 
do the right thing?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH] drm/sched: Check scheduler work queue before calling timeout handling

2023-05-10 Thread Luben Tuikov
On 2023-05-10 10:24, vitaly prosyak wrote:
> 
> On 2023-05-10 10:19, Luben Tuikov wrote:
>> On 2023-05-10 09:51, vitaly.pros...@amd.com wrote:
>>> From: Vitaly Prosyak 
>>>
>>> During an IGT GPU reset test we see again oops despite of
>>> commit 0c8c901aaaebc9 (drm/sched: Check scheduler ready before calling
>>> timeout handling).
>>>
>>> It uses ready condition whether to call drm_sched_fault which unwind
>>> the TDR leads to GPU reset.
>>> However it looks the ready condition is overloaded with other meanings,
>>> for example, for the following stack is related GPU reset :
>>>
>>> 0  gfx_v9_0_cp_gfx_start
>>> 1  gfx_v9_0_cp_gfx_resume
>>> 2  gfx_v9_0_cp_resume
>>> 3  gfx_v9_0_hw_init
>>> 4  gfx_v9_0_resume
>>> 5  amdgpu_device_ip_resume_phase2
>>>
>>> does the following:
>>> /* start the ring */
>>> gfx_v9_0_cp_gfx_start(adev);
>>> ring->sched.ready = true;
>>>
>>> The same approach is for other ASICs as well :
>>> gfx_v8_0_cp_gfx_resume
>>> gfx_v10_0_kiq_resume, etc...
>>>
>>> As a result, our GPU reset test causes GPU fault which calls 
>>> unconditionally gfx_v9_0_fault
>>> and then drm_sched_fault. However now it depends on whether the interrupt 
>>> service routine
>>> drm_sched_fault is executed after gfx_v9_0_cp_gfx_start is completed which 
>>> sets the ready
>>> field of the scheduler to true even  for uninitialized schedulers and 
>>> causes oops vs
>>> no fault or when ISR  drm_sched_fault is completed prior  
>>> gfx_v9_0_cp_gfx_start and
>>> NULL pointer dereference does not occur.
>>>
>>> Use the field timeout_wq  to prevent oops for uninitialized schedulers.
>>> The field could be initialized by the work queue of resetting the domain.
>>>
>>> Fixes: 0c8c901aaaebc9 ("drm/sched: Check scheduler ready before calling 
>>> timeout handling")
>>>
>>> v1: Corrections to commit message (Luben)
>>> Signed-off-by: Vitaly Prosyak 
>>> Reviewed-by: Luben Tuikov 
>> I didn't give my RB to this patch so I'm not sure what it is doing here.
> I removed your rb, also if you do not know what is doing here why do you want 
> to push this to amd-staging-drm-next and to  drm-misc-fixed?

I'll add my RB as I push it to those two branches.
I'll also add a Link tag and fix the commit SHA for the Fixes tag to
one which is found in drm-misc-fixes.

Thanks for the patch fixing this long-standing bug.

Regards,
Luben


>>
>> The fixes tag should be before the SOB tag, and the v1 line should be 
>> separated
>> by a line before the Git tags.
>>
>> Since this is a good patch and I want it in both drm-misc-fixed and 
>> amd-staging-drm-next,
>> I'll submit it to drm-misc-fixed with a Link: and RB/SOB tag there and then 
>> cherry-pick
>> that into amd-staging-drm-next.
>>
>> Don't push it to amd-staging-drm-next.
>>
>> I'll fix this and submit to amd-staging-drm-next and to drm-misc-fixed with
>> a Link: tag.
>>
>> Regards,
>> Luben
>>
>>
>>> ---
>>>  drivers/gpu/drm/scheduler/sched_main.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
>>> b/drivers/gpu/drm/scheduler/sched_main.c
>>> index 649fac2e1ccb..670b7997f389 100644
>>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>>> @@ -308,7 +308,7 @@ static void drm_sched_start_timeout(struct 
>>> drm_gpu_scheduler *sched)
>>>   */
>>>  void drm_sched_fault(struct drm_gpu_scheduler *sched)
>>>  {
>>> -   if (sched->ready)
>>> +   if (sched->timeout_wq)
>>> mod_delayed_work(sched->timeout_wq, >work_tdr, 0);
>>>  }
>>>  EXPORT_SYMBOL(drm_sched_fault);



Re: [PATCH v6 5/6] fbdev: Move framebuffer I/O helpers into

2023-05-10 Thread Thomas Zimmermann

Hi

Am 10.05.23 um 16:15 schrieb Arnd Bergmann:

On Wed, May 10, 2023, at 16:03, kernel test robot wrote:



cc1: warning: arch/sh/include/mach-hp6xx: No such file or directory
[-Wmissing-include-dirs]
cc1: warning: arch/sh/include/mach-hp6xx: No such file or directory
[-Wmissing-include-dirs]
In file included from drivers/video/fbdev/hitfb.c:27:
drivers/video/fbdev/hitfb.c: In function 'hitfb_accel_wait':

arch/sh/include/asm/hd64461.h:18:33: warning: passing argument 1 of 'fb_readw' 
makes pointer from integer without a cast [-Wint-conversion]

   18 | #define HD64461_IO_OFFSET(x)(HD64461_IOBASE + (x))
  | ^~
  | |
  | unsigned int
arch/sh/include/asm/hd64461.h:93:33: note: in expansion of macro
'HD64461_IO_OFFSET'
   93 | #define HD64461_GRCFGR  HD64461_IO_OFFSET(0x1044)
/* Accelerator Configuration Register */
  | ^
drivers/video/fbdev/hitfb.c:47:25: note: in expansion of macro
'HD64461_GRCFGR'
   47 | while (fb_readw(HD64461_GRCFGR) &
HD64461_GRCFGR_ACCSTATUS) ;


I think that's a preexisting bug and I have no idea what the
correct solution is. Looking for HD64461 shows it being used
both with inw/outw and readw/writew, so there is no way to have
the correct type. The sh __raw_readw() definition hides this bug,
but that is a problem with arch/sh and it probably hides others
as well.


The constant HD64461_IOBASE is defined as integer at


https://elixir.bootlin.com/linux/latest/source/arch/sh/include/asm/hd64461.h#L17

but fb_readw() expects a volatile-void pointer. I guess we could add a 
cast somewhere to silence the problem. In the current upstream code, 
that appears to be done by sh's __raw_readw() internally:



https://elixir.bootlin.com/linux/latest/source/arch/sh/include/asm/io.h#L35

Best regards
Thomas



Arnd


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)


OpenPGP_signature
Description: OpenPGP digital signature


  1   2   >