Re: [RFC PATCH 1/2] drm/msm/dpu: add dsc helper functions

From: Abhinav Kumar
Date: Sun Feb 26 2023 - 19:15:50 EST



On 2/26/2023 5:13 AM, Dmitry Baryshkov wrote:
On 26/02/2023 02:16, Abhinav Kumar wrote:
Hi Dmitry

On 2/24/2023 3:57 PM, Dmitry Baryshkov wrote:
On Sat, 25 Feb 2023 at 01:51, Kuogee Hsieh <quic_khsieh@xxxxxxxxxxx> wrote:


On 2/24/2023 1:13 PM, Dmitry Baryshkov wrote:
On 24/02/2023 21:40, Kuogee Hsieh wrote:
Add DSC helper functions based on DSC configuration profiles to produce
DSC related runtime parameters through both table look up and runtime
calculation to support DSC on DPU.

There are 6 different DSC configuration profiles are supported
currently.
DSC configuration profiles are differiented by 5 keys, DSC version
(V1.1),
chroma (444/422/420), colorspace (RGB/YUV), bpc(8/10),
bpp (6/7/7.5/8/9/10/12/15) and SCR (0/1).

Only DSC version V1.1 added and V1.2 will be added later.

These helpers should go to drivers/gpu/drm/display/drm_dsc_helper.c
Also please check that they can be used for i915 or for amdgpu
(ideally for both of them).

I didn't check the tables against the standard (or against the current
source code), will do that later.


Signed-off-by: Kuogee Hsieh <quic_khsieh@xxxxxxxxxxx>
---
   drivers/gpu/drm/msm/Makefile                   |   1 +
   drivers/gpu/drm/msm/disp/dpu1/dpu_dsc_helper.c | 209
+++++++++++++++++++++++++
   drivers/gpu/drm/msm/disp/dpu1/dpu_dsc_helper.h |  34 ++++
   3 files changed, 244 insertions(+)
   create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_dsc_helper.c
   create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_dsc_helper.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 7274c412..28cf52b 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_dsc_helper.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_dsc_helper.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_dsc_helper.c
new file mode 100644
index 00000000..88207e9
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_dsc_helper.c
@@ -0,0 +1,209 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023. Qualcomm Innovation Center, Inc. All rights
reserved
+ */
+
+#include <drm/display/drm_dsc_helper.h>
+#include "msm_drv.h"
+#include "dpu_kms.h"
+#include "dpu_hw_dsc.h"
+#include "dpu_dsc_helper.h"
+
+

Extra empty line

+#define DPU_DSC_PPS_SIZE       128
+
+enum dpu_dsc_ratio_type {
+    DSC_V11_8BPC_8BPP,
+    DSC_V11_10BPC_8BPP,
+    DSC_V11_10BPC_10BPP,
+    DSC_V11_SCR1_8BPC_8BPP,
+    DSC_V11_SCR1_10BPC_8BPP,
+    DSC_V11_SCR1_10BPC_10BPP,
+    DSC_RATIO_TYPE_MAX
+};
+
+
+static u16 dpu_dsc_rc_buf_thresh[DSC_NUM_BUF_RANGES - 1] = {
+        0x0e, 0x1c, 0x2a, 0x38, 0x46, 0x54,
+        0x62, 0x69, 0x70, 0x77, 0x79, 0x7b, 0x7d, 0x7e

Weird indentation

+};
+
+/*
+ * Rate control - Min QP values for each ratio type in
dpu_dsc_ratio_type
+ */
+static char
dpu_dsc_rc_range_min_qp[DSC_RATIO_TYPE_MAX][DSC_NUM_BUF_RANGES] = {
+    /* DSC v1.1 */
+    {0, 0, 1, 1, 3, 3, 3, 3, 3, 3, 5, 5, 5, 7, 13},
+    {0, 4, 5, 5, 7, 7, 7, 7, 7, 7, 9, 9, 9, 11, 17},
+    {0, 4, 5, 6, 7, 7, 7, 7, 7, 7, 9, 9, 9, 11, 15},
+    /* DSC v1.1 SCR and DSC v1.2 RGB 444 */

What is SCR? Is there any reason to use older min/max Qp params
instead of always using the ones from the VESA-DSC-1.1 standard?

Standards change request, some vendors may use scr to work with their panel.

These table value are provided by system team.

So, what will happen if we use values from 1.2 standard (aka 1.1 SCR
1) with the older panel?


Standards change request means fixing errors/errata for the given standard. Those are typically released as a different spec.

So I referred the DSC 1.1 SCR spec, and it does have a few differences in the table compared to DSC 1.1 which will get into DSC 1.2.

Hence the table entries are same between DSC 1.1 SCR and DSC 1.2

You are right, ideally DSC 1.2 should be backwards compatible with DSC 1.1 in terms of the values (thats what the spec says too) but I am not sure if we can expect every panel/DP monitor to be forward compatible without any SW change because it might need some firmware update (for the panel) or SW update to support that especially during transitions of the spec revisions (SCR to be precise).

Typically we do below for DP monitors exactly for the same reason:

DSC_ver_to_use = min(what_we_support, what_DP_monitor_supports) and use that table.

For DSI panels, typically in the panel spec it should say whether the SCR version needs to be used because we have seen that for some panels ( I dont remember exactly which one ) based on which panel and which revision of the panel, it might not.

So, what happens if we use DSC 1.1 SCR (= DSC 1.2) values with older panel? Does it result in the broken image?

I'm asking here, because I think that these parameters tune the _encoder_. The decoder should be able to handle different compressed streams as long as values fit into the required 'profile'.

Yes, this can cause screen corruption issues.

The RC parameters table is used both in the encoder and in the PPS too and will be used to decode too.

If we use the DSC 1.2 tables for a monitor/panel which advertizes that it supports only 1.1, we cannot be certain it will work.



Thats why downstream started adding qcom,mdss-dsc-scr-version to the devicetree.

+    {0, 0, 1, 1, 3, 3, 3, 3, 3, 3, 5, 5, 5, 9, 12},
+    {0, 4, 5, 5, 7, 7, 7, 7, 7, 7, 9, 9, 9, 13, 16},
+    {0, 4, 5, 6, 7, 7, 7, 7, 7, 7, 9, 9, 9, 11, 15},