date:20221205

GSC FW is loaded by submitting a dedicated command via the GSC engine.
The memory area used for loading the FW is then re-purposed as local
memory for the GSC itself, so we use a separate allocation instead of
using the one where we keep the firmware stored for reload.

The GSC is not reset as part of GT reset, so we only need to load it on
first boot and S3/S4 exit.

v2: use REG_* for register fields definitions (Rodrigo), move to WQ
immediately

v3: mark worker function as static

Bspec: 63347, 65346
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: John Harrison 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/gt/intel_engine.h   |   2 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   7 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 187 +++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h|  15 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c|  69 ++-
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h|  11 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.c|   6 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  20 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |   1 +
 10 files changed, 313 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 69f6e9af1b56..dfa211451a1d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -189,6 +189,7 @@ i915-y += \
 
 # general-purpose microcontroller (GuC) support
 i915-y += \
+ gt/uc/intel_gsc_fw.o \
  gt/uc/intel_gsc_uc.o \
  gt/uc/intel_guc.o \
  gt/uc/intel_guc_ads.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index cbc8b857d5f7..0e24af5efee9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -172,6 +172,8 @@ intel_write_status_page(struct intel_engine_cs *engine, int 
reg, u32 value)
 #define I915_GEM_HWS_MIGRATE   (0x42 * sizeof(u32))
 #define I915_GEM_HWS_PXP   0x60
 #define I915_GEM_HWS_PXP_ADDR  (I915_GEM_HWS_PXP * sizeof(u32))
+#define I915_GEM_HWS_GSC   0x62
+#define I915_GEM_HWS_GSC_ADDR  (I915_GEM_HWS_GSC * sizeof(u32))
 #define I915_GEM_HWS_SCRATCH   0x80
 
 #define I915_HWS_CSB_BUF0_INDEX0x10
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index f50ea92910d9..49ebda141266 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -21,6 +21,7 @@
 #define INSTR_CLIENT_SHIFT  29
 #define   INSTR_MI_CLIENT   0x0
 #define   INSTR_BC_CLIENT   0x2
+#define   INSTR_GSC_CLIENT  0x2 /* MTL+ */
 #define   INSTR_RC_CLIENT   0x3
 #define INSTR_SUBCLIENT_SHIFT   27
 #define INSTR_SUBCLIENT_MASK0x1800
@@ -432,6 +433,12 @@
 #define COLOR_BLT ((0x2<<29)|(0x40<<22))
 #define SRC_COPY_BLT  ((0x2<<29)|(0x43<<22))
 
+#define GSC_INSTR(opcode, data, flags) \
+   (__INSTR(INSTR_GSC_CLIENT) | (opcode) << 22 | (data) << 9 | (flags))
+
+#define GSC_FW_LOAD GSC_INSTR(1, 0, 2)
+#define   HECI1_FW_LIMIT_VALID (1<<31)
+
 /*
  * Used to convert any address to canonical form.
  * Starting from gen8, some commands (e.g. STATE_BASE_ADDRESS,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
new file mode 100644
index ..f88069ab71ab
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -0,0 +1,187 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include "gt/intel_engine_pm.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_ring.h"
+#include "intel_gsc_fw.h"
+
+#define GSC_FW_STATUS_REG  _MMIO(0x116C40)
+#define GSC_FW_CURRENT_STATE   REG_GENMASK(3, 0)
+#define   GSC_FW_CURRENT_STATE_RESET   0
+#define GSC_FW_INIT_COMPLETE_BIT   REG_BIT(9)
+
+static bool gsc_is_in_reset(struct intel_uncore *uncore)
+{
+   u32 fw_status = intel_uncore_read(uncore, GSC_FW_STATUS_REG);
+
+   return REG_FIELD_GET(GSC_FW_CURRENT_STATE, fw_status) ==
+  GSC_FW_CURRENT_STATE_RESET;
+}
+
+bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
+{
+   struct intel_uncore *uncore = gsc_uc_to_gt(gsc)->uncore;
+   u32 fw_status = intel_uncore_read(uncore, GSC_FW_STATUS_REG);
+
+   return fw_status & GSC_FW_INIT_COMPLETE_BIT;
+}
+
+static int emit_gsc_fw_load(struct i915_request *rq, struct intel_gsc_uc *gsc)
+{
+   u32 offset = i915_ggtt_offset(gsc->local);
+   u32 *cs;
+
+   cs = intel_ring_begin(rq, 4);
+   if (IS_ERR(cs))
+   return PTR_ERR(cs);
+
+   *cs++ = GSC_FW_LOAD;
+   *cs++ = lower_32_bits(offset);
+

Re: [PATCH] drm/i915: use sysfs_emit() to instead of scnprintf()

2022-12-05 Thread Bagas Sanjaya

On Mon, Dec 05, 2022 at 12:50:53PM +0200, Jani Nikula wrote:
> On Thu, 01 Dec 2022,  wrote:
> > From: ye xingchen 
> >
> > Replace the open-code with sysfs_emit() to simplify the code.
> 
> I was going to push this, but noticed the function has a third
> scnprintf(), and the last two play together with count. It would be
> confusing to have a mix of sysfs_emit() and scnprintf(). The third one
> can't be blindly converted to sysfs_emit() because it writes at an
> offset not aligned by PAGE_SIZE.
> 
> So I'm not taking this.
> 

Hi Jani,

Fortunately you'd NAKed this patch from ZTE people, which are known for
ignoring your (and others) patch review. Remember that they were used to
send from cgel.zte gmail account [1], which after the address was banned
from LKML, they tried to send from their own corporate account but Greg
suspected that emails sent from them are spoofed [2].

Thanks.

[1]: https://lore.kernel.org/lkml/878rn1dd8l@intel.com/
[2]: https://lore.kernel.org/lkml/y3nqyddgz%2fukp...@kroah.com/

-- 
An old man doll... just what I always wanted! - Clara

signature.asc
Description: PGP signature

[PATCH] drm/msm/mdp5: Add check for kzalloc

2022-12-05 Thread Jiasheng Jiang

As kzalloc may fail and return NULL pointer,
it should be better to check the return value
in order to avoid the NULL pointer dereference.

Fixes: 1cff7440a86e ("drm/msm: Convert to using 
__drm_atomic_helper_crtc_reset() for reset.")
Signed-off-by: Jiasheng Jiang 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index e86421c69bd1..86036dd4e1e8 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -1139,7 +1139,10 @@ static void mdp5_crtc_reset(struct drm_crtc *crtc)
if (crtc->state)
mdp5_crtc_destroy_state(crtc, crtc->state);
 
-   __drm_atomic_helper_crtc_reset(crtc, _cstate->base);
+   if (mdp5_cstate)
+   __drm_atomic_helper_crtc_reset(crtc, _cstate->base);
+   else
+   __drm_atomic_helper_crtc_reset(crtc, NULL);
 }
 
 static const struct drm_crtc_funcs mdp5_crtc_no_lm_cursor_funcs = {
-- 
2.25.1

[PATCH v4 1/6] dt-bindings: mediatek: modify VDOSYS0 display device tree Documentations for MT8188

From: Nathan Lu 

modify VDOSYS0 display device tree Documentations for MT8188.

Signed-off-by: Nathan Lu 
Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: AngeloGioacchino Del Regno 

---
 .../devicetree/bindings/display/mediatek/mediatek,aal.yaml| 1 +
 .../devicetree/bindings/display/mediatek/mediatek,ccorr.yaml  | 1 +
 .../devicetree/bindings/display/mediatek/mediatek,color.yaml  | 1 +
 .../devicetree/bindings/display/mediatek/mediatek,dither.yaml | 1 +
 .../devicetree/bindings/display/mediatek/mediatek,gamma.yaml  | 1 +
 .../devicetree/bindings/display/mediatek/mediatek,ovl.yaml| 1 +
 .../bindings/display/mediatek/mediatek,postmask.yaml  | 1 +
 .../devicetree/bindings/display/mediatek/mediatek,rdma.yaml   | 4 
 8 files changed, 11 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
index d4d585485e7b..92741486c24d 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
@@ -31,6 +31,7 @@ properties:
   - items:
   - enum:
   - mediatek,mt8186-disp-aal
+  - mediatek,mt8188-disp-aal
   - mediatek,mt8192-disp-aal
   - mediatek,mt8195-disp-aal
   - const: mediatek,mt8183-disp-aal
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
index 63fb02014a56..fe444beff558 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
@@ -27,6 +27,7 @@ properties:
   - const: mediatek,mt8192-disp-ccorr
   - items:
   - enum:
+  - mediatek,mt8188-disp-ccorr
   - mediatek,mt8195-disp-ccorr
   - const: mediatek,mt8192-disp-ccorr
   - items:
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
index d2f89ee7996f..62306c88f485 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
@@ -37,6 +37,7 @@ properties:
   - enum:
   - mediatek,mt8183-disp-color
   - mediatek,mt8186-disp-color
+  - mediatek,mt8188-disp-color
   - mediatek,mt8192-disp-color
   - mediatek,mt8195-disp-color
   - const: mediatek,mt8173-disp-color
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
index 8ad8187c02d1..5c7445c174e5 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
@@ -27,6 +27,7 @@ properties:
   - items:
   - enum:
   - mediatek,mt8186-disp-dither
+  - mediatek,mt8188-disp-dither
   - mediatek,mt8192-disp-dither
   - mediatek,mt8195-disp-dither
   - const: mediatek,mt8183-disp-dither
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
index a89ea0ea7542..a5c6a91fac71 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
@@ -28,6 +28,7 @@ properties:
   - items:
   - enum:
   - mediatek,mt8186-disp-gamma
+  - mediatek,mt8188-disp-gamma
   - mediatek,mt8192-disp-gamma
   - mediatek,mt8195-disp-gamma
   - const: mediatek,mt8183-disp-gamma
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
index a2a27d0ca038..065e526f950e 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
@@ -36,6 +36,7 @@ properties:
   - const: mediatek,mt2701-disp-ovl
   - items:
   - enum:
+  - mediatek,mt8188-disp-ovl
   - mediatek,mt8195-disp-ovl
   - const: mediatek,mt8183-disp-ovl
   - items:
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
index 654080bfbdfb..27de64495401 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
@@ -26,6 +26,7 @@ properties:
   - items:

[PATCH v4 5/6] soc: mediatek: add mtk-mutex support for mt8188 vdosys0

From: Nathan Lu 

add mtk-mutex support for mt8188 vdosys0.

Signed-off-by: amy zhang 
Signed-off-by: Nathan Lu 
Reviewed-by: AngeloGioacchino Del Regno 

---
 drivers/soc/mediatek/mtk-mutex.c | 53 
 1 file changed, 53 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-mutex.c b/drivers/soc/mediatek/mtk-mutex.c
index c1a33d52038e..77d1c084cbb1 100644
--- a/drivers/soc/mediatek/mtk-mutex.c
+++ b/drivers/soc/mediatek/mtk-mutex.c
@@ -116,6 +116,21 @@
 #define MT8173_MUTEX_MOD_DISP_PWM1 24
 #define MT8173_MUTEX_MOD_DISP_OD   25
 
+#define MT8188_MUTEX_MOD_DISP_OVL0 0
+#define MT8188_MUTEX_MOD_DISP_WDMA01
+#define MT8188_MUTEX_MOD_DISP_RDMA02
+#define MT8188_MUTEX_MOD_DISP_COLOR0   3
+#define MT8188_MUTEX_MOD_DISP_CCORR0   4
+#define MT8188_MUTEX_MOD_DISP_AAL0 5
+#define MT8188_MUTEX_MOD_DISP_GAMMA0   6
+#define MT8188_MUTEX_MOD_DISP_DITHER0  7
+#define MT8188_MUTEX_MOD_DISP_DSI0 8
+#define MT8188_MUTEX_MOD_DISP_DSC_WRAP0_CORE0  9
+#define MT8188_MUTEX_MOD_DISP_VPP_MERGE20
+#define MT8188_MUTEX_MOD_DISP_DP_INTF0 21
+#define MT8188_MUTEX_MOD_DISP_POSTMASK024
+#define MT8188_MUTEX_MOD2_DISP_PWM033
+
 #define MT8195_MUTEX_MOD_DISP_OVL0 0
 #define MT8195_MUTEX_MOD_DISP_WDMA01
 #define MT8195_MUTEX_MOD_DISP_RDMA02
@@ -180,6 +195,8 @@
 #define MT8167_MUTEX_SOF_DPI1  3
 #define MT8183_MUTEX_SOF_DSI0  1
 #define MT8183_MUTEX_SOF_DPI0  2
+#define MT8188_MUTEX_SOF_DSI0  1
+#define MT8188_MUTEX_SOF_DP_INTF0  3
 #define MT8195_MUTEX_SOF_DSI0  1
 #define MT8195_MUTEX_SOF_DSI1  2
 #define MT8195_MUTEX_SOF_DP_INTF0  3
@@ -189,6 +206,8 @@
 
 #define MT8183_MUTEX_EOF_DSI0  (MT8183_MUTEX_SOF_DSI0 << 6)
 #define MT8183_MUTEX_EOF_DPI0  (MT8183_MUTEX_SOF_DPI0 << 6)
+#define MT8188_MUTEX_EOF_DSI0  (MT8188_MUTEX_SOF_DSI0 << 7)
+#define MT8188_MUTEX_EOF_DP_INTF0  (MT8188_MUTEX_SOF_DP_INTF0 << 7)
 #define MT8195_MUTEX_EOF_DSI0  (MT8195_MUTEX_SOF_DSI0 << 7)
 #define MT8195_MUTEX_EOF_DSI1  (MT8195_MUTEX_SOF_DSI1 << 7)
 #define MT8195_MUTEX_EOF_DP_INTF0  (MT8195_MUTEX_SOF_DP_INTF0 << 7)
@@ -344,6 +363,23 @@ static const unsigned int 
mt8186_mdp_mutex_table_mod[MUTEX_MOD_IDX_MAX] = {
[MUTEX_MOD_IDX_MDP_COLOR0] = MT8186_MUTEX_MOD_MDP_COLOR0,
 };
 
+static const unsigned int mt8188_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+   [DDP_COMPONENT_OVL0] = MT8188_MUTEX_MOD_DISP_OVL0,
+   [DDP_COMPONENT_WDMA0] = MT8188_MUTEX_MOD_DISP_WDMA0,
+   [DDP_COMPONENT_RDMA0] = MT8188_MUTEX_MOD_DISP_RDMA0,
+   [DDP_COMPONENT_COLOR0] = MT8188_MUTEX_MOD_DISP_COLOR0,
+   [DDP_COMPONENT_CCORR] = MT8188_MUTEX_MOD_DISP_CCORR0,
+   [DDP_COMPONENT_AAL0] = MT8188_MUTEX_MOD_DISP_AAL0,
+   [DDP_COMPONENT_GAMMA] = MT8188_MUTEX_MOD_DISP_GAMMA0,
+   [DDP_COMPONENT_POSTMASK0] = MT8188_MUTEX_MOD_DISP_POSTMASK0,
+   [DDP_COMPONENT_DITHER0] = MT8188_MUTEX_MOD_DISP_DITHER0,
+   [DDP_COMPONENT_MERGE0] = MT8188_MUTEX_MOD_DISP_VPP_MERGE,
+   [DDP_COMPONENT_DSC0] = MT8188_MUTEX_MOD_DISP_DSC_WRAP0_CORE0,
+   [DDP_COMPONENT_DSI0] = MT8188_MUTEX_MOD_DISP_DSI0,
+   [DDP_COMPONENT_PWM0] = MT8188_MUTEX_MOD2_DISP_PWM0,
+   [DDP_COMPONENT_DP_INTF0] = MT8188_MUTEX_MOD_DISP_DP_INTF0,
+};
+
 static const unsigned int mt8192_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_AAL0] = MT8192_MUTEX_MOD_DISP_AAL0,
[DDP_COMPONENT_CCORR] = MT8192_MUTEX_MOD_DISP_CCORR0,
@@ -435,6 +471,14 @@ static const unsigned int mt8186_mutex_sof[MUTEX_SOF_DSI3 
+ 1] = {
  * but also detect the error at end of frame(EAEOF) when EOF signal
  * arrives.
  */
+static const unsigned int mt8188_mutex_sof[DDP_MUTEX_SOF_MAX] = {
+   [MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
+   [MUTEX_SOF_DSI0] =
+   MT8188_MUTEX_SOF_DSI0 | MT8188_MUTEX_EOF_DSI0,
+   [MUTEX_SOF_DP_INTF0] =
+   MT8188_MUTEX_SOF_DP_INTF0 | MT8188_MUTEX_EOF_DP_INTF0,
+};
+
 static const unsigned int mt8195_mutex_sof[DDP_MUTEX_SOF_MAX] = {
[MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
[MUTEX_SOF_DSI0] = MT8195_MUTEX_SOF_DSI0 | MT8195_MUTEX_EOF_DSI0,
@@ -505,6 +549,13 @@ static const struct mtk_mutex_data 
mt8186_mutex_driver_data = {
.mutex_sof_reg = MT8183_MUTEX0_SOF0,
 };
 
+static const struct mtk_mutex_data mt8188_mutex_driver_data = {
+   .mutex_mod = mt8188_mutex_mod,
+   .mutex_sof = mt8188_mutex_sof,
+   .mutex_mod_reg = MT8183_MUTEX0_MOD0,
+   .mutex_sof_reg = MT8183_MUTEX0_SOF0,
+};
+
 static const struct mtk_mutex_data mt8192_mutex_driver_data = {
.mutex_mod = mt8192_mutex_mod,
.mutex_sof = mt8183_mutex_sof,
@@ -854,6

[PATCH v4 3/6] dt-bindings: mediatek: modify VDOSYS0 mutex device tree Documentations for MT8188

From: Nathan Lu 

modify VDOSYS0 mutex device tree Documentations for MT8188.

Signed-off-by: Nathan Lu 
Reviewed-by: AngeloGioacchino Del Regno 

Acked-by: Krzysztof Kozlowski 
---
 .../devicetree/bindings/soc/mediatek/mediatek,mutex.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml 
b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
index 9241e5fc7cff..15c133cac315 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
@@ -32,6 +32,7 @@ properties:
   - mediatek,mt8183-disp-mutex
   - mediatek,mt8186-disp-mutex
   - mediatek,mt8186-mdp3-mutex
+  - mediatek,mt8188-disp-mutex
   - mediatek,mt8192-disp-mutex
   - mediatek,mt8195-disp-mutex
 
-- 
2.18.0

[PATCH v4 4/6] soc: mediatek: add mtk-mmsys support for mt8188 vdosys0

From: Nathan Lu 

1. add mt8188 mmsys
2. add mt8188 vdosys0 routing table settings

Signed-off-by: amy zhang 
Signed-off-by: Nathan Lu 
---
 drivers/soc/mediatek/mt8188-mmsys.h | 149 
 drivers/soc/mediatek/mtk-mmsys.c|  11 ++
 2 files changed, 160 insertions(+)
 create mode 100644 drivers/soc/mediatek/mt8188-mmsys.h

diff --git a/drivers/soc/mediatek/mt8188-mmsys.h 
b/drivers/soc/mediatek/mt8188-mmsys.h
new file mode 100644
index ..448cc3761b43
--- /dev/null
+++ b/drivers/soc/mediatek/mt8188-mmsys.h
@@ -0,0 +1,149 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __SOC_MEDIATEK_MT8188_MMSYS_H
+#define __SOC_MEDIATEK_MT8188_MMSYS_H
+
+#define MT8188_VDO0_OVL_MOUT_EN0xf14
+#define MT8188_MOUT_DISP_OVL0_TO_DISP_RDMA0BIT(0)
+#define MT8188_MOUT_DISP_OVL0_TO_DISP_WDMA0BIT(1)
+#define MT8188_MOUT_DISP_OVL0_TO_DISP_OVL1 BIT(2)
+#define MT8188_MOUT_DISP_OVL1_TO_DISP_RDMA1BIT(4)
+#define MT8188_MOUT_DISP_OVL1_TO_DISP_WDMA1BIT(5)
+#define MT8188_MOUT_DISP_OVL1_TO_DISP_OVL0 BIT(6)
+
+#define MT8188_VDO0_SEL_IN 0xf34
+#define MT8188_VDO0_SEL_OUT0xf38
+
+#define MT8188_VDO0_DISP_RDMA_SEL  0xf40
+#define MT8188_SOUT_DISP_RDMA0_TO_MASK GENMASK(2, 0)
+#define MT8188_SOUT_DISP_RDMA0_TO_DISP_COLOR0  (0 << 0)
+#define MT8188_SOUT_DISP_RDMA0_TO_DISP_DSI0(1 << 0)
+#define MT8188_SOUT_DISP_RDMA0_TO_DISP_DP_INTF0(5 << 0)
+#define MT8188_SEL_IN_DISP_RDMA0_FROM_MASK GENMASK(8, 8)
+#define MT8188_SEL_IN_DISP_RDMA0_FROM_DISP_OVL0(0 << 8)
+#define MT8188_SEL_IN_DISP_RDMA0_FROM_DISP_RSZ0(1 << 8)
+
+
+#define MT8188_VDO0_DSI0_SEL_IN0xf44
+#define MT8188_SEL_IN_DSI0_FROM_MASK   BIT(0)
+#define MT8188_SEL_IN_DSI0_FROM_DSC_WRAP0_OUT  (0 << 0)
+#define MT8188_SEL_IN_DSI0_FROM_DISP_DITHER0   (1 << 0)
+
+#define MT8188_VDO0_DP_INTF0_SEL_IN0xf4C
+#define MT8188_SEL_IN_DP_INTF0_FROM_MASK   GENMASK(2, 0)
+#define MT8188_SEL_IN_DP_INTF0_FROM_DSC_WRAP0C1_OUT(0 << 0)
+#define MT8188_SEL_IN_DP_INTF0_FROM_VPP_MERGE  (1 << 0)
+#define MT8188_SEL_IN_DP_INTF0_FROM_DISP_DITHER0   (3 << 0)
+
+#define MT8188_VDO0_DISP_DITHER0_SEL_OUT   0xf58
+#define MT8188_SOUT_DISP_DITHER0_TO_MASK   GENMASK(2, 0)
+#define MT8188_SOUT_DISP_DITHER0_TO_DSC_WRAP0_IN   (0 << 0)
+#define MT8188_SOUT_DISP_DITHER0_TO_DSI0   (1 << 0)
+#define MT8188_SOUT_DISP_DITHER0_TO_VPP_MERGE0 (6 << 0)
+#define MT8188_SOUT_DISP_DITHER0_TO_DP_INTF0   (7 << 0)
+
+#define MT8188_VDO0_VPP_MERGE_SEL  0xf60
+#define MT8188_SEL_IN_VPP_MERGE_FROM_MASK  GENMASK(1, 0)
+#define MT8188_SEL_IN_VPP_MERGE_FROM_DSC_WRAP0_OUT (0 << 0)
+#define MT8188_SEL_IN_VPP_MERGE_FROM_DITHER0_OUT   (3 << 0)
+
+#define MT8188_SOUT_VPP_MERGE_TO_MASK  GENMASK(6, 4)
+#define MT8188_SOUT_VPP_MERGE_TO_DSI1  (0 << 4)
+#define MT8188_SOUT_VPP_MERGE_TO_DP_INTF0  (1 << 4)
+#define MT8188_SOUT_VPP_MERGE_TO_SINA_VIRTUAL0 (2 << 4)
+#define MT8188_SOUT_VPP_MERGE_TO_DISP_WDMA1(3 << 4)
+#define MT8188_SOUT_VPP_MERGE_TO_DSC_WRAP0_IN  (4 << 4)
+#define MT8188_SOUT_VPP_MERGE_TO_DISP_WDMA0(5 << 4)
+#define MT8188_SOUT_VPP_MERGE_TO_DSC_WRAP1_IN_MASK GENMASK(11, 11)
+#define MT8188_SOUT_VPP_MERGE_TO_DSC_WRAP1_IN  (0 << 11)
+
+#define MT8188_VDO0_DSC_WARP_SEL   0xf64
+#define MT8188_SEL_IN_DSC_WRAP0C0_IN_FROM_MASK GENMASK(0, 0)
+#define MT8188_SEL_IN_DSC_WRAP0C0_IN_FROM_DISP_DITHER0 (0 << 0)
+#define MT8188_SEL_IN_DSC_WRAP0C0_IN_FROM_VPP_MERGE(1 << 0)
+#define MT8188_SOUT_DSC_WRAP0_OUT_TO_MASK  GENMASK(19, 16)
+#define MT8188_SOUT_DSC_WRAP0_OUT_TO_DSI0  BIT(16)
+#define MT8188_SOUT_DSC_WRAP0_OUT_TO_SINB_VIRTUAL0 BIT(17)
+#define MT8188_SOUT_DSC_WRAP0_OUT_TO_VPP_MERGE BIT(18)
+#define MT8188_SOUT_DSC_WRAP0_OUT_TO_DISP_WDMA0BIT(19)
+
+static const struct mtk_mmsys_routes mmsys_mt8188_routing_table[] = {
+   {
+   DDP_COMPONENT_OVL0, DDP_COMPONENT_RDMA0,
+   MT8188_VDO0_OVL_MOUT_EN, MT8188_MOUT_DISP_OVL0_TO_DISP_RDMA0,
+   MT8188_MOUT_DISP_OVL0_TO_DISP_RDMA0
+   }, {
+   DDP_COMPONENT_OVL0, DDP_COMPONENT_WDMA0,
+   MT8188_VDO0_OVL_MOUT_EN, MT8188_MOUT_DISP_OVL0_TO_DISP_WDMA0,
+   MT8188_MOUT_DISP_OVL0_TO_DISP_WDMA0
+   }, {
+   DDP_COMPONENT_OVL0, DDP_COMPONENT_RDMA0,
+   MT8188_VDO0_DISP_RDMA_SEL, MT8188_SEL_IN_DISP_RDMA0_FROM_MASK,
+   MT8188_SEL_IN_DISP_RDMA0_FROM_DISP_OVL0
+   }, {
+

[PATCH v4 6/6] drm/mediatek: add mediatek-drm of vdosys0 support for mt8188

From: Nathan Lu 

add driver data of mt8188 vdosys0 to mediatek-drm and the sub driver.

Signed-off-by: amy zhang 
Signed-off-by: Nathan Lu 
Reviewed-by: AngeloGioacchino Del Regno 

---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index b12e5b977c50..8058a5ec2f1d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -176,6 +176,18 @@ static const enum mtk_ddp_comp_id mt8186_mtk_ddp_ext[] = {
DDP_COMPONENT_DPI0,
 };
 
+static const enum mtk_ddp_comp_id mt8188_mtk_ddp_main[] = {
+   DDP_COMPONENT_OVL0,
+   DDP_COMPONENT_RDMA0,
+   DDP_COMPONENT_COLOR0,
+   DDP_COMPONENT_CCORR,
+   DDP_COMPONENT_AAL0,
+   DDP_COMPONENT_GAMMA,
+   DDP_COMPONENT_POSTMASK0,
+   DDP_COMPONENT_DITHER0,
+   DDP_COMPONENT_DP_INTF0,
+};
+
 static const enum mtk_ddp_comp_id mt8192_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_OVL_2L0,
@@ -259,6 +271,11 @@ static const struct mtk_mmsys_driver_data 
mt8186_mmsys_driver_data = {
.ext_len = ARRAY_SIZE(mt8186_mtk_ddp_ext),
 };
 
+static const struct mtk_mmsys_driver_data mt8188_vdosys0_driver_data = {
+   .main_path = mt8188_mtk_ddp_main,
+   .main_len = ARRAY_SIZE(mt8188_mtk_ddp_main),
+};
+
 static const struct mtk_mmsys_driver_data mt8192_mmsys_driver_data = {
.main_path = mt8192_mtk_ddp_main,
.main_len = ARRAY_SIZE(mt8192_mtk_ddp_main),
@@ -516,6 +533,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
  .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt8186-disp-mutex",
  .data = (void *)MTK_DISP_MUTEX },
+   { .compatible = "mediatek,mt8188-disp-mutex",
+ .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt8192-disp-mutex",
  .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt8195-disp-mutex",
@@ -600,6 +619,8 @@ static const struct of_device_id mtk_drm_of_ids[] = {
  .data = _mmsys_driver_data},
{ .compatible = "mediatek,mt8186-mmsys",
  .data = _mmsys_driver_data},
+   { .compatible = "mediatek,mt8188-vdosys0",
+ .data = _vdosys0_driver_data},
{ .compatible = "mediatek,mt8192-mmsys",
  .data = _mmsys_driver_data},
{ .compatible = "mediatek,mt8195-mmsys",
-- 
2.18.0

[PATCH v4 2/6] dt-bindings: mediatek: modify VDOSYS0 mmsys device tree Documentations for MT8188

From: Nathan Lu 

modify VDOSYS0 mmsys device tree Documentations for MT8188.

Signed-off-by: Nathan Lu 
---
 .../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
index 0711f1834fbd..84de12709323 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
@@ -31,6 +31,7 @@ properties:
   - mediatek,mt8173-mmsys
   - mediatek,mt8183-mmsys
   - mediatek,mt8186-mmsys
+  - mediatek,mt8188-vdosys0
   - mediatek,mt8192-mmsys
   - mediatek,mt8365-mmsys
   - const: syscon
-- 
2.18.0

[PATCH v4 0/6] Add first version mt8188 vdosys0 driver

From: Nathan Lu 

This patch is to add first version mt8188 vdosys0 driver
Modify and add new files include:
1. bindings documents
2. mtk mmsys
3. mtk mutex
4. mtk drm driver

Change in V4:
- based on [1]
[1] Change mmsys compatible for mt8195 mediatek-drm
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=699386
- Modify mediatek,mmsys.yaml, move mt8188-vdosys0 to mmsys
- Modify mt8188_mmsysy.h DSI mux setting

Change in V3:
- based on [1]
[1] Change mmsys compatible for mt8195 mediatek-drm
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=699386
- Modify mediatek,mmsys.yaml mt8188-mmsys name to mt8188-vdosys0
- Modify mtk-mmsys.c compatible name to mt8188-vdosys0
- Add DSI mutex in mtk-mutex.c
- Modify mtk_drm_drv.c mt8188-mmsysy name to mt8188-vdosys0


Change in V2:
- based on [2] and [3]
[2] Add MediaTek SoC(vdosys1) support for mt8195
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=658416
[3] Add MediaTek SoC DRM (vdosys1) support for mt8195
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=665269
- Seperate bindings doucment into mmsys/mutex/display 3 parts
- Remove redundent char in mediatek,gamma.yaml
- Add another mediatek,mt8188-disp-rdma in mediatek,rdma.yaml
- Remove io_start variable setting in mtk_drm_drv.c and mtk_mmsys.c

Nathan Lu (6):
  dt-bindings: mediatek: modify VDOSYS0 display device tree
Documentations for MT8188
  dt-bindings: mediatek: modify VDOSYS0 mmsys device tree Documentations
for MT8188
  dt-bindings: mediatek: modify VDOSYS0 mutex device tree Documentations
for MT8188
  soc: mediatek: add mtk-mmsys support for mt8188 vdosys0
  soc: mediatek: add mtk-mutex support for mt8188 vdosys0
  drm/mediatek: add mediatek-drm of vdosys0 support for mt8188

 .../bindings/arm/mediatek/mediatek,mmsys.yaml |   1 +
 .../display/mediatek/mediatek,aal.yaml|   1 +
 .../display/mediatek/mediatek,ccorr.yaml  |   1 +
 .../display/mediatek/mediatek,color.yaml  |   1 +
 .../display/mediatek/mediatek,dither.yaml |   1 +
 .../display/mediatek/mediatek,gamma.yaml  |   1 +
 .../display/mediatek/mediatek,ovl.yaml|   1 +
 .../display/mediatek/mediatek,postmask.yaml   |   1 +
 .../display/mediatek/mediatek,rdma.yaml   |   4 +
 .../bindings/soc/mediatek/mediatek,mutex.yaml |   1 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c|  21 +++
 drivers/soc/mediatek/mt8188-mmsys.h   | 149 ++
 drivers/soc/mediatek/mtk-mmsys.c  |  11 ++
 drivers/soc/mediatek/mtk-mutex.c  |  53 +++
 14 files changed, 247 insertions(+)
 create mode 100644 drivers/soc/mediatek/mt8188-mmsys.h

-- 
2.18.0

[PATCH v2 6/6] drm/i915/mtl: MTL has one GSC CS on the media GT

Now that we have the GSC FW support code as a user to the GSC CS, we
can add the relevant flag to the engine mask. Note that the engine will
still be disabled until we define the GSC FW binary file.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Matt Roper 
Cc: Rodrigo Vivi 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 414b4bfd514b..3f803c1280c0 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1125,7 +1125,7 @@ static const struct intel_gt_definition xelpmp_extra_gt[] 
= {
.type = GT_MEDIA,
.name = "Standalone Media GT",
.gsi_offset = MTL_MEDIA_GSI_BASE,
-   .engine_mask = BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
+   .engine_mask = BIT(VECS0) | BIT(VCS0) | BIT(VCS2) | BIT(GSC0),
},
{}
 };
-- 
2.37.3

[PATCH v2 3/6] drm/i915/gsc: GSC firmware loading

GSC FW is loaded by submitting a dedicated command via the GSC engine.
The memory area used for loading the FW is then re-purposed as local
memory for the GSC itself, so we use a separate allocation instead of
using the one where we keep the firmware stored for reload.

The GSC is not reset as part of GT reset, so we only need to load it on
first boot and S3/S4 exit.

v2: use REG_* for register fields definitions (Rodrigo), move to WQ
immediately

Bspec: 63347, 65346
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: John Harrison 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/gt/intel_engine.h   |   2 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   7 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 187 +++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h|  15 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c|  69 ++-
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h|  11 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.c|   6 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  20 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |   1 +
 10 files changed, 313 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 69f6e9af1b56..dfa211451a1d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -189,6 +189,7 @@ i915-y += \
 
 # general-purpose microcontroller (GuC) support
 i915-y += \
+ gt/uc/intel_gsc_fw.o \
  gt/uc/intel_gsc_uc.o \
  gt/uc/intel_guc.o \
  gt/uc/intel_guc_ads.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index cbc8b857d5f7..0e24af5efee9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -172,6 +172,8 @@ intel_write_status_page(struct intel_engine_cs *engine, int 
reg, u32 value)
 #define I915_GEM_HWS_MIGRATE   (0x42 * sizeof(u32))
 #define I915_GEM_HWS_PXP   0x60
 #define I915_GEM_HWS_PXP_ADDR  (I915_GEM_HWS_PXP * sizeof(u32))
+#define I915_GEM_HWS_GSC   0x62
+#define I915_GEM_HWS_GSC_ADDR  (I915_GEM_HWS_GSC * sizeof(u32))
 #define I915_GEM_HWS_SCRATCH   0x80
 
 #define I915_HWS_CSB_BUF0_INDEX0x10
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index f50ea92910d9..49ebda141266 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -21,6 +21,7 @@
 #define INSTR_CLIENT_SHIFT  29
 #define   INSTR_MI_CLIENT   0x0
 #define   INSTR_BC_CLIENT   0x2
+#define   INSTR_GSC_CLIENT  0x2 /* MTL+ */
 #define   INSTR_RC_CLIENT   0x3
 #define INSTR_SUBCLIENT_SHIFT   27
 #define INSTR_SUBCLIENT_MASK0x1800
@@ -432,6 +433,12 @@
 #define COLOR_BLT ((0x2<<29)|(0x40<<22))
 #define SRC_COPY_BLT  ((0x2<<29)|(0x43<<22))
 
+#define GSC_INSTR(opcode, data, flags) \
+   (__INSTR(INSTR_GSC_CLIENT) | (opcode) << 22 | (data) << 9 | (flags))
+
+#define GSC_FW_LOAD GSC_INSTR(1, 0, 2)
+#define   HECI1_FW_LIMIT_VALID (1<<31)
+
 /*
  * Used to convert any address to canonical form.
  * Starting from gen8, some commands (e.g. STATE_BASE_ADDRESS,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
new file mode 100644
index ..f88069ab71ab
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -0,0 +1,187 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include "gt/intel_engine_pm.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_ring.h"
+#include "intel_gsc_fw.h"
+
+#define GSC_FW_STATUS_REG  _MMIO(0x116C40)
+#define GSC_FW_CURRENT_STATE   REG_GENMASK(3, 0)
+#define   GSC_FW_CURRENT_STATE_RESET   0
+#define GSC_FW_INIT_COMPLETE_BIT   REG_BIT(9)
+
+static bool gsc_is_in_reset(struct intel_uncore *uncore)
+{
+   u32 fw_status = intel_uncore_read(uncore, GSC_FW_STATUS_REG);
+
+   return REG_FIELD_GET(GSC_FW_CURRENT_STATE, fw_status) ==
+  GSC_FW_CURRENT_STATE_RESET;
+}
+
+bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
+{
+   struct intel_uncore *uncore = gsc_uc_to_gt(gsc)->uncore;
+   u32 fw_status = intel_uncore_read(uncore, GSC_FW_STATUS_REG);
+
+   return fw_status & GSC_FW_INIT_COMPLETE_BIT;
+}
+
+static int emit_gsc_fw_load(struct i915_request *rq, struct intel_gsc_uc *gsc)
+{
+   u32 offset = i915_ggtt_offset(gsc->local);
+   u32 *cs;
+
+   cs = intel_ring_begin(rq, 4);
+   if (IS_ERR(cs))
+   return PTR_ERR(cs);
+
+   *cs++ = GSC_FW_LOAD;
+   *cs++ = lower_32_bits(offset);
+   *cs++ = upper_32_bits(offset);

[PATCH v2 2/6] drm/i915/gsc: Skip the version check when fetching the GSC FW

The current exectation from the FW side is that the driver will query
the GSC FW version after the FW is loaded, similarly to what the mei
driver does on DG2. However, we're discussing with the FW team if there
is a way to extract the version from the bin file before loading, so we
can keep the code the same as for older FWs.

Since the GSC FW version is not currently required for functionality and
is only needed for debug purposes, we can skip the FW version for now at
fetch time and add it later on when we've agreed on the approach.

v2: rebased on uc_fw version struct changes.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: John Harrison 
Reviewed-by: Rodrigo Vivi  #v1
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 29 +++-
 1 file changed, 23 insertions(+), 6 deletions(-)

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 1d6249d4b8ef..78ab60c07a2b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -655,6 +655,26 @@ static bool guc_check_version_range(struct intel_uc_fw 
*uc_fw)
return true;
 }
 
+static int check_fw_header(struct intel_gt *gt,
+  const struct firmware *fw,
+  struct intel_uc_fw *uc_fw)
+{
+   int err = 0;
+
+   /* GSC FW version is queried after the FW is loaded */
+   if (uc_fw->type == INTEL_UC_FW_TYPE_GSC)
+   return 0;
+
+   if (uc_fw->loaded_via_gsc)
+   err = check_gsc_manifest(fw, uc_fw);
+   else
+   err = check_ccs_header(gt, fw, uc_fw);
+   if (err)
+   return err;
+
+   return 0;
+}
+
 /**
  * intel_uc_fw_fetch - fetch uC firmware
  * @uc_fw: uC firmware
@@ -724,17 +744,14 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
if (err)
goto fail;
 
-   if (uc_fw->loaded_via_gsc)
-   err = check_gsc_manifest(fw, uc_fw);
-   else
-   err = check_ccs_header(gt, fw, uc_fw);
+   err = check_fw_header(gt, fw, uc_fw);
if (err)
goto fail;
 
if (uc_fw->type == INTEL_UC_FW_TYPE_GUC && 
!guc_check_version_range(uc_fw))
goto fail;
 
-   if (uc_fw->file_wanted.ver.major) {
+   if (uc_fw->file_wanted.ver.major && uc_fw->file_selected.ver.major) {
/* Check the file's major version was as it claimed */
if (uc_fw->file_selected.ver.major != 
uc_fw->file_wanted.ver.major) {
drm_notice(>drm, "%s firmware %s: unexpected 
version: %u.%u != %u.%u\n",
@@ -751,7 +768,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
}
}
 
-   if (old_ver) {
+   if (old_ver && uc_fw->file_selected.ver.major) {
/* Preserve the version that was really wanted */
memcpy(_fw->file_wanted, _ideal, 
sizeof(uc_fw->file_wanted));
 
-- 
2.37.3

[PATCH v2 5/6] drm/i915/gsc: Disable GSC engine and power well if FW is not selected

From: Jonathan Cavitt 

The GSC CS is only used for communicating with the GSC FW, so no need to
initialize it if we're not going to use the FW. If we're not using
neither the engine nor the microcontoller, then we can also disable the
power well.

IMPORTANT: lack of GSC FW breaks media C6 due to opposing requirements
between CS setup and forcewake idleness. See in-code comment for detail.

Signed-off-by: Jonathan Cavitt 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Matt Roper 
Cc: John C Harrison 
Cc: Rodrigo Vivi 
Cc: Vinay Belgaumkar 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 18 ++
 drivers/gpu/drm/i915/intel_uncore.c   |  3 +++
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index c33e0d72d670..99c4b866addd 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -894,6 +894,24 @@ static intel_engine_mask_t init_engine_mask(struct 
intel_gt *gt)
engine_mask_apply_compute_fuses(gt);
engine_mask_apply_copy_fuses(gt);
 
+   /*
+* The only use of the GSC CS is to load and communicate with the GSC
+* FW, so we have no use for it if we don't have the FW.
+*
+* IMPORTANT: in cases where we don't have the GSC FW, we have a
+* catch-22 situation that breaks media C6 due to 2 requirements:
+* 1) once turned on, the GSC power well will not go to sleep unless the
+*GSC FW is loaded.
+* 2) to enable idling (which is required for media C6) we need to
+*initialize the IDLE_MSG register for the GSC CS and do at least 1
+*submission, which will wake up the GSC power well.
+*/
+   if (__HAS_ENGINE(info->engine_mask, GSC0) && 
!intel_uc_wants_gsc_uc(>uc)) {
+   drm_notice(>i915->drm,
+  "No GSC FW selected, disabling GSC CS and media 
C6\n");
+   info->engine_mask &= ~BIT(GSC0);
+   }
+
return info->engine_mask;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 3bfb4af0df78..cb45e4a4ace4 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2701,6 +2701,9 @@ void intel_uncore_prune_engine_fw_domains(struct 
intel_uncore *uncore,
if (fw_domains & BIT(domain_id))
fw_domain_fini(uncore, domain_id);
}
+
+   if ((fw_domains & BIT(FW_DOMAIN_ID_GSC)) && !HAS_ENGINE(gt, GSC0))
+   fw_domain_fini(uncore, FW_DOMAIN_ID_GSC);
 }
 
 /*
-- 
2.37.3

[PATCH v2 4/6] drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded

If the GSC was loaded, the only way to stop it during the driver unload
flow is to do a driver-FLR.
The driver-initiated FLR is not the same as PCI config space FLR in
that it doesn't reset the SGUnit and doesn't modify the PCI config
space. Thus, it doesn't require a re-enumeration of the PCI BARs.
However, the driver-FLR does cause a memory wipe of graphics memory
on all discrete GPU platforms or a wipe limited to stolen memory
on the integrated GPU platforms.

We perform the FLR as the last action before releasing the MMIO bar, so
that we don't have to care about the consequences of the reset on the
unload flow.

v2: rename FLR function, add comment to explain FLR impact (Rodrigo),
better explain why GSC needs FLR (Alan)

Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Alan Previn 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 23 +
 drivers/gpu/drm/i915/i915_reg.h   |  3 ++
 drivers/gpu/drm/i915/intel_uncore.c   | 58 +++
 drivers/gpu/drm/i915/intel_uncore.h   | 13 +
 4 files changed, 97 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index f88069ab71ab..e73d4440c5e8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -166,6 +166,29 @@ int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc)
if (err)
goto fail;
 
+   /*
+* GSC is only killed by an FLR, so we need to trigger one on unload to
+* make sure we stop it. This is because we assign a chunk of memory to
+* the GSC as part of the FW load , so we need to make sure it stops
+* using it when we release it to the system on driver unload. Note that
+* this is not a problem of the unload per-se, because the GSC will not
+* touch that memory unless there are requests for it coming from the
+* driver; therefore, no accesses will happen while i915 is not loaded,
+* but if we re-load the driver then the GSC might wake up and try to
+* access that old memory location again.
+* Given that an FLR is a very disruptive action (see the FLR function
+* for details), we want to do it as the last action before releasing
+* the access to the MMIO bar, which means we need to do it as part of
+* the primary uncore cleanup.
+* An alternative approach to the FLR would be to use a memory location
+* that survives driver unload, like e.g. stolen memory, and keep the
+* GSC loaded across reloads. However, this requires us to make sure we
+* preserve that memory location on unload and then determine and
+* reserve its offset on each subsequent load, which is not trivial, so
+* it is easier to just kill everything and start fresh.
+*/
+   intel_uncore_set_flr_on_fini(>i915->uncore);
+
err = gsc_fw_load(gsc);
if (err)
goto fail;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0b90fe6a28f7..b95d533652a4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -118,6 +118,9 @@
 
 #define GU_CNTL_MMIO(0x101010)
 #define   LMEM_INITREG_BIT(7)
+#define   DRIVERFLRREG_BIT(31)
+#define GU_DEBUG   _MMIO(0x101018)
+#define   DRIVERFLR_STATUS REG_BIT(31)
 
 #define GEN6_STOLEN_RESERVED   _MMIO(0x1082C0)
 #define GEN6_STOLEN_RESERVED_ADDR_MASK (0xFFF << 20)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 8006a6c61466..3bfb4af0df78 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2703,6 +2703,61 @@ void intel_uncore_prune_engine_fw_domains(struct 
intel_uncore *uncore,
}
 }
 
+/*
+ * The driver-initiated FLR is the highest level of reset that we can trigger
+ * from within the driver. It is different from the PCI FLR in that it doesn't
+ * fully reset the SGUnit and doesn't modify the PCI config space and therefore
+ * it doesn't require a re-enumeration of the PCI BARs. However, the
+ * driver-initiated FLR does still cause a reset of both GT and display and a
+ * memory wipe of local and stolen memory, so recovery would require a full HW
+ * re-init and saving/restoring (or re-populating) the wiped memory. Since we
+ * perform the FLR as the very last action before releasing access to the HW
+ * during the driver release flow, we don't attempt recovery at all, because
+ * if/when a new instance of i915 is bound to the device it will do a full
+ * re-init anyway.
+ */
+static void driver_initiated_flr(struct intel_uncore *uncore)
+{
+   struct drm_i915_private *i915 = uncore->i915;
+   const unsigned int flr_timeout_ms = 3000; /* specs recommend a 3s wait 
*/
+   int ret;
+
+

[PATCH v2 1/6] drm/i915/uc: Introduce GSC FW

On MTL the GSC FW needs to be loaded on the media GT by the graphics
driver. We're going to treat it like a new uc_fw, so add the initial
defs and init/fini functions for it.

Similarly to the other FWs, the GSC FW path can be overriden via
modparam. The modparam can also be used to disable the GSC FW loading by
setting it to an empty string.

Note that the new structure has been called intel_gsc_uc to avoid
confusion with the existing intel_gsc, which instead represents the heci
gsc interfaces.

v2: re-order Makefile list to be properly sorted (Jani, Alan), better
comment (alan)

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: John Harrison 
Cc: Jani Nikula 
Reviewed-by: Alan Previn  #v1
---
 drivers/gpu/drm/i915/Makefile | 10 ++--
 drivers/gpu/drm/i915/gt/intel_gt.h|  5 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 70 +++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h | 36 
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 17 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.h |  3 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 29 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |  7 ++-
 drivers/gpu/drm/i915/i915_params.c|  3 +
 drivers/gpu/drm/i915/i915_params.h|  1 +
 10 files changed, 172 insertions(+), 9 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 01974b82d205..69f6e9af1b56 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -188,9 +188,8 @@ i915-y += \
  i915_vma_resource.o
 
 # general-purpose microcontroller (GuC) support
-i915-y += gt/uc/intel_uc.o \
- gt/uc/intel_uc_debugfs.o \
- gt/uc/intel_uc_fw.o \
+i915-y += \
+ gt/uc/intel_gsc_uc.o \
  gt/uc/intel_guc.o \
  gt/uc/intel_guc_ads.o \
  gt/uc/intel_guc_capture.o \
@@ -205,7 +204,10 @@ i915-y += gt/uc/intel_uc.o \
  gt/uc/intel_guc_submission.o \
  gt/uc/intel_huc.o \
  gt/uc/intel_huc_debugfs.o \
- gt/uc/intel_huc_fw.o
+ gt/uc/intel_huc_fw.o \
+ gt/uc/intel_uc.o \
+ gt/uc/intel_uc_debugfs.o \
+ gt/uc/intel_uc_fw.o
 
 # graphics system controller (GSC) support
 i915-y += gt/intel_gsc.o
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index e0365d556248..d2f4fbde5f9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -39,6 +39,11 @@ static inline struct intel_gt *huc_to_gt(struct intel_huc 
*huc)
return container_of(huc, struct intel_gt, uc.huc);
 }
 
+static inline struct intel_gt *gsc_uc_to_gt(struct intel_gsc_uc *gsc_uc)
+{
+   return container_of(gsc_uc, struct intel_gt, uc.gsc);
+}
+
 static inline struct intel_gt *gsc_to_gt(struct intel_gsc *gsc)
 {
return container_of(gsc, struct intel_gt, gsc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
new file mode 100644
index ..65cbf1ce9fa1
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+
+#include "gt/intel_gt.h"
+#include "intel_gsc_uc.h"
+#include "i915_drv.h"
+
+static bool gsc_engine_supported(struct intel_gt *gt)
+{
+   intel_engine_mask_t mask;
+
+   /*
+* We reach here from i915_driver_early_probe for the primary GT before
+* its engine mask is set, so we use the device info engine mask for it.
+* For other GTs we expect the GT-specific mask to be set before we
+* call this function.
+*/
+   GEM_BUG_ON(!gt_is_root(gt) && !gt->info.engine_mask);
+
+   if (gt_is_root(gt))
+   mask = RUNTIME_INFO(gt->i915)->platform_engine_mask;
+   else
+   mask = gt->info.engine_mask;
+
+   return __HAS_ENGINE(mask, GSC0);
+}
+
+void intel_gsc_uc_init_early(struct intel_gsc_uc *gsc)
+{
+   intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GSC);
+
+   /* we can arrive here from i915_driver_early_probe for primary
+* GT with it being not fully setup hence check device info's
+* engine mask
+*/
+   if (!gsc_engine_supported(gsc_uc_to_gt(gsc))){
+   intel_uc_fw_change_status(>fw, 
INTEL_UC_FIRMWARE_NOT_SUPPORTED);
+   return;
+   }
+}
+
+int intel_gsc_uc_init(struct intel_gsc_uc *gsc)
+{
+   struct drm_i915_private *i915 = gsc_uc_to_gt(gsc)->i915;
+   int err;
+
+   err = intel_uc_fw_init(>fw);
+   if (err)
+   goto out;
+
+   intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_LOADABLE);
+
+   return 0;
+
+out:
+   i915_probe_error(i915, "failed with %d\n", err);
+   return err;
+}
+
+void intel_gsc_uc_fini(struct intel_gsc_uc *gsc)
+{
+

[PATCH v2 0/6] drm/i915: Add support for GSC FW loading

Starting from MTL, the GSC FW is runtime loaded by the driver, instead
of being stored in flash memory. Loading the GSC FW is required to allow
the media GT to go into its C6 state and for content protection features
(PXP, HDCP).

The loading happens via a submission to the GSC engine. All subsequent
communication with the FW will also happen via the engine, although no
further messages are implemented as part of this series.

This series also adds the GSC engine flag to the MTL platform, with the
engine being runtime disabled if the FW is not selected, which makes the
FW definition (not included in the series) the ultimate enabler for the
whole GSC block.

Note that just loading the FW is not enough for it to be fully
functional. We'll also need to establish and handle a communication
channel between GSC and CSME (a.k.a. SW proxy). This will require a new
mei component to handle the CSME side of things, so it will be pushed as
a separate series.

v2: Use wq to load the GSC, address minor review comments.

Cc: Alan Previn 
Cc: John Harrison 
Cc: Rodrigo Vivi 

Daniele Ceraolo Spurio (5):
  drm/i915/uc: Introduce GSC FW
  drm/i915/gsc: Skip the version check when fetching the GSC FW
  drm/i915/gsc: GSC firmware loading
  drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded
  drm/i915/mtl: MTL has one GSC CS on the media GT

Jonathan Cavitt (1):
  drm/i915/gsc: Disable GSC engine and power well if FW is not selected

 drivers/gpu/drm/i915/Makefile|  11 +-
 drivers/gpu/drm/i915/gt/intel_engine.h   |   2 +
 drivers/gpu/drm/i915/gt/intel_engine_cs.c|  18 ++
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   7 +
 drivers/gpu/drm/i915/gt/intel_gt.h   |   5 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 210 +++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h|  15 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c| 137 
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h|  47 +
 drivers/gpu/drm/i915/gt/uc/intel_uc.c|  23 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.h|   3 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  78 +--
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |   8 +-
 drivers/gpu/drm/i915/i915_params.c   |   3 +
 drivers/gpu/drm/i915/i915_params.h   |   1 +
 drivers/gpu/drm/i915/i915_pci.c  |   2 +-
 drivers/gpu/drm/i915/i915_reg.h  |   3 +
 drivers/gpu/drm/i915/intel_uncore.c  |  61 ++
 drivers/gpu/drm/i915/intel_uncore.h  |  13 ++
 19 files changed, 626 insertions(+), 21 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h

-- 
2.37.3

Re: [PATCH v2 2/2] drm/v3d: replace obj lookup steps with drm_gem_objects_lookup

2022-12-05 Thread Maíra Canal

On 12/5/22 10:55, Melissa Wen wrote:
> As v3d_lookup_bos() performs the same steps as drm_gem_objects_lookup(),
> replace the explicit code in v3d to simply use the DRM function.
> 
> Signed-off-by: Melissa Wen 

Reviewed-by: Maíra Canal 

Best Regards,
- Maíra Canal

> ---
>  drivers/gpu/drm/v3d/v3d_gem.c | 49 +++
>  1 file changed, 3 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
> index 31a37572c11d..6e152ef26358 100644
> --- a/drivers/gpu/drm/v3d/v3d_gem.c
> +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> @@ -299,10 +299,6 @@ v3d_lookup_bos(struct drm_device *dev,
>  u64 bo_handles,
>  u32 bo_count)
>  {
> - u32 *handles;
> - int ret = 0;
> - int i;
> -
>   job->bo_count = bo_count;
>  
>   if (!job->bo_count) {
> @@ -313,48 +309,9 @@ v3d_lookup_bos(struct drm_device *dev,
>   return -EINVAL;
>   }
>  
> - job->bo = kvmalloc_array(job->bo_count,
> -  sizeof(struct drm_gem_dma_object *),
> -  GFP_KERNEL | __GFP_ZERO);
> - if (!job->bo) {
> - DRM_DEBUG("Failed to allocate validated BO pointers\n");
> - return -ENOMEM;
> - }
> -
> - handles = kvmalloc_array(job->bo_count, sizeof(u32), GFP_KERNEL);
> - if (!handles) {
> - ret = -ENOMEM;
> - DRM_DEBUG("Failed to allocate incoming GEM handles\n");
> - goto fail;
> - }
> -
> - if (copy_from_user(handles,
> -(void __user *)(uintptr_t)bo_handles,
> -job->bo_count * sizeof(u32))) {
> - ret = -EFAULT;
> - DRM_DEBUG("Failed to copy in GEM handles\n");
> - goto fail;
> - }
> -
> - spin_lock(_priv->table_lock);
> - for (i = 0; i < job->bo_count; i++) {
> - struct drm_gem_object *bo = idr_find(_priv->object_idr,
> -  handles[i]);
> - if (!bo) {
> - DRM_DEBUG("Failed to look up GEM BO %d: %d\n",
> -   i, handles[i]);
> - ret = -ENOENT;
> - spin_unlock(_priv->table_lock);
> - goto fail;
> - }
> - drm_gem_object_get(bo);
> - job->bo[i] = bo;
> - }
> - spin_unlock(_priv->table_lock);
> -
> -fail:
> - kvfree(handles);
> - return ret;
> + return drm_gem_objects_lookup(file_priv,
> +   (void __user *)(uintptr_t)bo_handles,
> +   job->bo_count, >bo);
>  }
>  
>  static void

Re: [PATCH v2 1/2] drm/v3d: cleanup BOs properly when lookup_bos fails

2022-12-05 Thread Maíra Canal

On 12/5/22 10:55, Melissa Wen wrote:
> When v3d_lookup_bos fails to `allocate validated BO pointers`,
> job->bo_count was already set to args->bo_count, but job->bo points to
> NULL. In this scenario, we must verify that job->bo is not NULL before
> iterating on it to proper clean up a job. Also, drm_gem_object_put
> already checks that the object passed is not NULL, doing the job->bo[i]
> checker redundant.
> 
> Signed-off-by: Melissa Wen 

Reviewed-by: Maíra Canal 

Best Regards,
- Maíra Canal

> ---
>  drivers/gpu/drm/v3d/v3d_gem.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
> index 96af1cb5202a..31a37572c11d 100644
> --- a/drivers/gpu/drm/v3d/v3d_gem.c
> +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> @@ -363,11 +363,11 @@ v3d_job_free(struct kref *ref)
>   struct v3d_job *job = container_of(ref, struct v3d_job, refcount);
>   int i;
>  
> - for (i = 0; i < job->bo_count; i++) {
> - if (job->bo[i])
> + if (job->bo) {
> + for (i = 0; i < job->bo_count; i++)
>   drm_gem_object_put(job->bo[i]);
> + kvfree(job->bo);
>   }
> - kvfree(job->bo);
>  
>   dma_fence_put(job->irq_fence);
>   dma_fence_put(job->done_fence);

[RFC PATCH 06/17] dyndbg: dynamic_debug_init - use pointer inequality, not strcmp

dynamic_debug_init() currently uses strcmp to find the module
boundaries in the builtin _ddebug[] table.

The table is filled by the linker; for its content, pointer inequality
works, is faster, and communicates the data properties more tightly.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 5d609ff0d559..a0dc681cd215 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1410,7 +1410,7 @@ static int __init dynamic_debug_init(void)
 
for (; iter < __stop___dyndbg; iter++, i++, mod_sites++) {
 
-   if (strcmp(modname, iter->modname)) {
+   if (modname != iter->modname) {
mod_ct++;
di.num_descs = mod_sites;
di.descs = iter_mod_start;
-- 
2.38.1

[RFC PATCH 15/17] dyndbg: ddebug_sanity()

It appears that, at least for builtin drm,i915 loadable amdgpu, data
in the class_refs section is not properly linked, this works partway
towards isolating the problem.

The "NO CLI" name test is failing.
 This version of the report fails with a non-canonical address:
 // v2pr_info("NO CLI name on: %s\n", cli->map->mod_name);

[0.109299] dyndbg: add-module: main 6 sites 1.3
[0.109595] general protection fault, probably for non-canonical address 
0x726576697264: 

fwiw:
  $ perl -e ' $a = pack "H8", "726576697264"; print "a:<$a>\n"'
  a:

These records are added to __dyndbg_class_refs section by
DYNDBG_CLASSMAP_USE

This patch adds ddebug_sanity(), and calls it 3 times to characterize
what goes wrong and when.  It turns out that its contents are wrong
immediately, in 1st step of dynamic_debug_init().

[0.107327] dyndbg: classes
[0.107537] dyndbg: class[0]: module:drm base:0 len:10 ty:0 
cm:834fc4c8
[0.107592] dyndbg: class-refs
[0.107823] dyndbg: class-ref[0]: cli:834fc508 map:8293e35e 
nm: nm:(null)
[0.108554] dyndbg: class-ref[1]: cli:834fc518 map:8293fe86 
nm:834fc4c8 nm:
[0.108590] dyndbg: class-ref[2]: cli:834fc528 map:829785aa 
nm:834fc4c8 nm:

Those maps are wrong:

class-refs should all ref the same map, ie class[0]: module:drm.
the nm:s should also show module names of 3 builtin clients of drm.
So things must end poorly.

modprobing the loadable module does better:

bash-5.2# modprobe amdgpu
[ 6645.212706] AMD-Vi: AMD IOMMUv2 functionality not available on this system - 
This is not a bug.
[ 6645.653124] dyndbg: add-module: amdgpu 4425 sites 0.1
[ 6645.653582] dyndbg: classes
[ 6645.653830] dyndbg: class-refs
[ 6645.654124] dyndbg: class-ref[0]: cli:c0a31b90 map:834fc4c8 
nm:c08bc176 nm:amdgpu
[ 6645.654936] dyndbg: classes
[ 6645.655188] dyndbg: class-refs
[ 6645.655450] dyndbg: class-ref[0]: cli:c0a31b90 map:834fc4c8 
nm:c08bc176 nm:amdgpu
[ 6645.656246] dyndbg: class_ref[0] amdgpu -> drm
[ 6645.656613] dyndbg: amdgpu needs drm, 0x0
[ 6645.656953] dyndbg: apply bitmap: 0x0 to: 0x0
[ 6645.657322] dyndbg: break on 0/1
[ 6645.657592] dyndbg: 4425 debug prints in module amdgpu

Here, the maps are correct; they ref the class[0] module:drm above.
That said, apply bitmap is wrong.

Signed-off-by: Jim Cromie 

---

[1.210094] dyndbg: add-module: drm 302 sites 1.3
[1.210496] dyndbg: classes
[1.210674] dyndbg: class[0]: module:drm base:0 len:10 ty:0 
cm:834fc4c8
[1.211290] dyndbg: class-refs
[1.211548] dyndbg: class-ref[0]: cli:834fc508 map:8293e376 
nm: nm:(null)
[1.211674] dyndbg: class-ref[1]: cli:834fc518 map:8293fe9e 
nm:834fc4c8 nm:
[1.212464] dyndbg: class-ref[2]: cli:834fc528 map:829785c2 
nm:834fc4c8 nm:
[1.212675] dyndbg: classes start: class[0]: module:drm base:0 len:10 ty:0
[1.213257] dyndbg: builtin class: module:drm base:0 len:10 ty:0
[1.213675] dyndbg: controlling kp: drm.drm.debug
[1.214087] dyndbg: module:drm attached 1 classes
[1.214490] dyndbg: classes
[1.214674] dyndbg: class[0]: module:drm base:0 len:10 ty:0 
cm:834fc4c8
[1.215291] dyndbg: class-refs
[1.215552] dyndbg: class-ref[0]: cli:834fc508 map:8293e376 
nm: nm:(null)
[1.215674] dyndbg: class-ref[1]: cli:834fc518 map:8293fe9e 
nm:834fc4c8 nm:
[1.216430] dyndbg: class-ref[2]: cli:834fc528 map:829785c2 
nm:834fc4c8 nm:
[1.216674] dyndbg: NO CLI 8293e376 726576697264
[1.217149] dyndbg: 302 debug prints in module drm
[1.217549] dyndbg: add-module: drm_kms_helper 95 sites 1.3
[1.217674] dyndbg: classes
[1.217913] dyndbg: class[0]: module:drm base:0 len:10 ty:0 
cm:834fc4c8
[1.218525] dyndbg: class-refs
[1.218674] dyndbg: class-ref[0]: cli:834fc508 map:8293e376 
nm: nm:(null)
[1.219486] dyndbg: class-ref[1]: cli:834fc518 map:8293fe9e 
nm:834fc4c8 nm:
[1.219674] dyndbg: class-ref[2]: cli:834fc528 map:829785c2 
nm:834fc4c8 nm:
[1.220469] dyndbg: classes
[1.220674] dyndbg: class[0]: module:drm base:0 len:10 ty:0 
cm:834fc4c8
[1.221324] dyndbg: class-refs
[1.221606] dyndbg: class-ref[0]: cli:834fc508 map:8293e376 
nm: nm:(null)
[1.221674] dyndbg: class-ref[1]: cli:834fc518 map:8293fe9e 
nm:834fc4c8 nm:
[1.222472] dyndbg: class-ref[2]: cli:834fc528 map:829785c2 
nm:834fc4c8 nm:
[1.222674] dyndbg: NO CLI 8293e376 726576697264
[1.223173] dyndbg:  95 debug prints in module drm_kms_helper
[1.223675] dyndbg: add-module: drm_display_helper 150 sites 1.3
[

[RFC PATCH 13/17] drm_print: fix stale macro-name in comment

Cited commit uses stale macro name, fix this, and explain better.

When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
onto BITs in drm.debug.  This still uses enum drm_debug_category, but
it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
This requires that the macro args: DRM_UT_* list must be kept in sync
and in order.

Fixes: f158936b60a7 ("drm: POC drm on dyndbg - use in core, 2 helpers, 3 
drivers.")
Signed-off-by: Jim Cromie 
---
. emphasize ABI non-change despite enum val change - Jani Nikula
. reorder to back of patchset to follow API name changes.
---
 include/drm/drm_print.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 6a27e8f26770..7695ba31b3a4 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -276,7 +276,10 @@ static inline struct drm_printer drm_err_printer(const 
char *prefix)
  *
  */
 enum drm_debug_category {
-   /* These names must match those in DYNAMIC_DEBUG_CLASSBITS */
+   /*
+* Keep DYNDBG_CLASSMAP_DEFINE args in sync with changes here,
+* the enum-values define BIT()s in drm.debug, so are ABI.
+*/
/**
 * @DRM_UT_CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c,
 * drm_memory.c, ...
-- 
2.38.1

[RFC PATCH 16/17] dyndbg: mess-w-dep-class

for loadable drm, helpers, and drivers, dependent-load is failing to
apply changes, needs more investigation.
---
 lib/dynamic_debug.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 46684aa7284d..3ef1c0a1f0cd 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1248,14 +1248,14 @@ static void ddebug_find_kparam(struct ddebug_class_map 
*cm)
 
 static void ddebug_param_load_dependent_class(const struct ddebug_class_user 
*cli)
 {
-   unsigned long new_bits, old_bits = 0;
+   unsigned long *new_bits, old_bits = 0;
 
-   new_bits = *cli->map->dc_parm->bits;
+   new_bits = cli->map->dc_parm->bits;
 
vpr_info("%s needs %s, 0x%lx\n", cli->user_mod_name,
-cli->map->mod_name, new_bits);
+cli->map->mod_name, *new_bits);
 
-   ddebug_apply_class_bitmap(cli->map->dc_parm, _bits, _bits, 
cli->user_mod_name);
+   ddebug_apply_class_bitmap(cli->map->dc_parm, new_bits, _bits, 
cli->user_mod_name);
 }
 
 static void ddebug_attach_module_classes(struct ddebug_table *dt, struct 
_ddebug_info *di)
-- 
2.38.1

[RFC PATCH 17/17] dyndbg: miss-on HACK

dont break the loop, to see multiple clients.  the 3 client records
are differently wrong.
---
 lib/dynamic_debug.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 3ef1c0a1f0cd..a26eaa348731 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -629,6 +629,7 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
  ct, map->class_names[bi], *new_bits);
}
+   v2pr_info("applied bitmap: 0x%lx to: 0x%lx\n", *new_bits, *old_bits);
return matches;
 }
 
@@ -1321,8 +1322,8 @@ static void ddebug_attach_client_module_classes(struct 
ddebug_table *dt, struct
 */
v2pr_info("break on %d/%d\n", i, di->num_class_refs);
dt->num_class_refs = 1;
-   break;
-   }
+   } else
+   v2pr_info("miss on %d/%d\n", i, di->num_class_refs);
}
 }
 
-- 
2.38.1

[RFC PATCH 12/17] dyndbg-API: DYNDBG_CLASSMAP_DEFINE() improvements

patch 1 in this series fixed a CLASSMAP usage error, this improves the
api so that misuse is less likely.

changes here:

0- Add William Swanson's public domain map macro:
   https://github.com/swansontec/map-macro/blob/master/map.h
   this makes 1 possible.

1- classnames were formerly specified as strings: "DRM_UT_CORE"
   now they are the actual enum const symbols: DRM_UT_CORE
   direct use of symbols is tighter, more comprehensible by tools, grep

2- drop _base arg.
   _base was the value of the 1st classname
   that is now available due to 1, no need to require it 2x

So take _base out of the API/kdoc.  Note that the macro impl keeps the
_base arg so that it can be used to set classmap.base, but reuses it
in the MAP-stringify _base, __VA_ARGS__ expression.

Also cleanup the API usage comment in test_dynamic_debug.c, and since
comments in test-code might not be noticed, restate that here.

Using the CLASSMAP api:

  - class-specifications are enum consts/symbols,
like DRM_UT_CORE, DRM_UT_KMS, etc.
their values define bit positions to drm.debug (as before)

  - they are stringified and accepted at >control
echo class DRM_UT_CORE +p >control

  - multiple class-maps must share the per-module: 0-62 class_id space
(by setting initial enum values to non-overlapping subranges)

todo: fixup the 'i' prefix, a quick/dirty avoidance of MAP.

NOTE: test_dynamic_debug.c also has this helper macro to wire a
classmap to a drm.debug style parameter; its easier to just use it as
a model/template as needed, rather than try to make it general enough
to be an official API helper.

 define DD_SYS_WRAP(_model, _flags) \
static unsigned long bits_##_model; \
static struct ddebug_class_param _flags##_model = { \
.bits = _##_model, \
.flags = #_flags,   \
.map = _##_model,   \
};  \
module_param_cb(_flags##_##_model, _ops_dyndbg_classes, 
&_flags##_model, 0600)

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/drm_print.c   | 22 +++---
 include/drm/drm_print.h   |  1 +
 include/linux/dynamic_debug.h | 17 ++-
 include/linux/map.h   | 54 +++
 lib/test_dynamic_debug.c  | 43 ++--
 5 files changed, 95 insertions(+), 42 deletions(-)
 create mode 100644 include/linux/map.h

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 4b697e18238d..07c25241e8cc 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -56,17 +56,17 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each 
bit enables a debug cat
 module_param_named(debug, __drm_debug, ulong, 0600);
 #else
 /* classnames must match vals of enum drm_debug_category */
-DYNDBG_CLASSMAP_DEFINE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_DEFINE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS,
+  DRM_UT_CORE,
+  DRM_UT_DRIVER,
+  DRM_UT_KMS,
+  DRM_UT_PRIME,
+  DRM_UT_ATOMIC,
+  DRM_UT_VBL,
+  DRM_UT_STATE,
+  DRM_UT_LEASE,
+  DRM_UT_DP,
+  DRM_UT_DRMRES);
 
 static struct ddebug_class_param drm_debug_bitmap = {
.bits = &__drm_debug,
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index a44fb7ef257f..6a27e8f26770 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -333,6 +333,7 @@ static inline bool drm_debug_enabled_raw(enum 
drm_debug_category category)
})
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+//extern struct ddebug_class_map drm_debug_classes[];
 /*
  * the drm.debug API uses dyndbg, so each drm_*dbg macro/callsite gets
  * a descriptor, and only enabled callsites are reachable.  They use
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 0088fc354c98..6f53a687cb32 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -7,6 +7,7 @@
 #endif
 
 #include 
+#include 
 
 /*
  * An instance of this structure is created in a special
@@ -92,18 +93,16 @@ struct ddebug_class_map {
 };
 
 /**
- * DYNDBG_CLASSMAP_DEFINE - define debug-classes used by a module.
- * @_var:   name of the classmap, exported for

[RFC PATCH 09/17] dyndbg-API: replace DECLARE_DYNDBG_CLASSMAP with DYNDBG_CLASSMAP(_DEFINE|_USE)

DECLARE_DYNDBG_CLASSMAPs job was to allow modules to declare the debug
classes/categories they want dyndbg to >control on their behalf.  Its
args give the class-names, their mapping to class_ids, and the sysfs
interface style (usually a class-bitmap).  Modules wanting a drm.debug
style knob need to create the kparam, and call module_param_cb() to
wire the sysfs node to the classmap.  DRM does this is in drm_print.c

In DRM, multiple modules declare identical DRM_UT_* classmaps, so that
the class'd prdbgs are modified across those modules in a coordinated
way across the subsystem, by either explicit class DRM_UT_* queries to
>control, or by writes to /sys/module/drm/parameters/debug (drm.debug)

This coordination-by-identical-declarations is weird, so this patch
splits the macro into _DEFINE and _USE flavors.  This distinction
follows the "define-once, declare-many-uses" principle, so it improves
the api; _DEFINE is used once to specify the classmap, and multiple
users _USE the single definition explicitly.

Currently the latter just reuses the former, and still needs all the
same args, but that can be tuned later; the _DEFINE can initialize an
(extern/global) struct classmap, and _USE can, well use/reference
that struct.

Also wrap DYNDBG_CLASSMAP_USEs with ifdef DRM_USE_DYNAMIC_DEBUG to
balance with the one around drm_print's use of DYNDBG_CLASSMAP_DEFINE.

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  4 +++-
 drivers/gpu/drm/display/drm_dp_helper.c |  4 +++-
 drivers/gpu/drm/drm_crtc_helper.c   |  4 +++-
 drivers/gpu/drm/drm_print.c |  2 +-
 drivers/gpu/drm/i915/i915_params.c  |  4 +++-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  4 +++-
 include/linux/dynamic_debug.h   | 20 
 lib/test_dynamic_debug.c| 32 -
 8 files changed, 48 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index bf2d50c8c92a..0075184b5d93 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -188,7 +188,8 @@ int amdgpu_vcnfw_log;
 
 static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work);
 
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
@@ -199,6 +200,7 @@ DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, 
DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_LEASE",
"DRM_UT_DP",
"DRM_UT_DRMRES");
+#endif
 
 struct amdgpu_mgpu_info mgpu_info = {
.mutex = __MUTEX_INITIALIZER(mgpu_info.mutex),
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
b/drivers/gpu/drm/display/drm_dp_helper.c
index 16565a0a5da6..8fa7a88299e7 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -41,7 +41,8 @@
 
 #include "drm_dp_helper_internal.h"
 
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
@@ -52,6 +53,7 @@ DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, 
DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_LEASE",
"DRM_UT_DP",
"DRM_UT_DRMRES");
+#endif
 
 struct dp_aux_backlight {
struct backlight_device *base;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 7d86020b5244..2f747c9c8f60 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -51,7 +51,8 @@
 
 #include "drm_crtc_helper_internal.h"
 
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
@@ -62,6 +63,7 @@ DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, 
DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_LEASE",
"DRM_UT_DP",
"DRM_UT_DRMRES");
+#endif
 
 /**
  * DOC: overview
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 5b93c11895bb..4b697e18238d 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -56,7 +56,7 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each bit 
enables a debug cat
 module_param_named(debug, __drm_debug, ulong, 0600);
 #else
 /* classnames must match vals of enum drm_debug_category */

[RFC PATCH 11/17] dyndbg-API: DYNDBG_CLASSMAP_USE drop extra args

Drop macro args after _var.  Since DYNDBG_CLASSMAP_USE no longer
forwards to DYNDBG_CLASSMAP_DEFINE, it doesn't need those args to
forward.  Keep only the _var arg, which is the extern'd struct
classmap with all the class info.

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 +-
 drivers/gpu/drm/display/drm_dp_helper.c | 12 +-
 drivers/gpu/drm/drm_crtc_helper.c   | 12 +-
 drivers/gpu/drm/i915/i915_params.c  | 12 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 12 +-
 include/linux/dynamic_debug.h   | 30 ++---
 6 files changed, 22 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 0075184b5d93..7bcc22ef5d49 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -189,17 +189,7 @@ int amdgpu_vcnfw_log;
 static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work);
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_USE(drm_debug_classes);
 #endif
 
 struct amdgpu_mgpu_info mgpu_info = {
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
b/drivers/gpu/drm/display/drm_dp_helper.c
index 8fa7a88299e7..3bc188cb1116 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -42,17 +42,7 @@
 #include "drm_dp_helper_internal.h"
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_USE(drm_debug_classes);
 #endif
 
 struct dp_aux_backlight {
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 2f747c9c8f60..5fb83336b015 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -52,17 +52,7 @@
 #include "drm_crtc_helper_internal.h"
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_USE(drm_debug_classes);
 #endif
 
 /**
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b5b2542ae364..e959d0384ead 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -30,17 +30,7 @@
 #include "i915_drv.h"
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_USE(drm_debug_classes);
 #endif
 
 #define i915_param_named(name, T, perm, desc) \
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 2963cf5b0807..609edeb2a117 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -72,17 +72,7 @@
 #include "nouveau_dmem.h"
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");

[RFC PATCH 04/17] dyndbg: replace classmap list with a vector

Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.

This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly multiple classmaps will
be consecutive in the section, and could be treated as a vector/block,
since both start-addy and subrange length are in the ddebug_info arg.

So this changes:

struct ddebug_class_map drops list link.

struct ddebug_table drops the maps list-head, and gets: classes &
num_classes for the start-addy, and length. num_classes is placed to
improve struct packing.

The loading: in ddebug_attach_module_classes(), replace the
for-the-modname list-add loop, with a forloop that finds the module's
subrange (start,length) of matching classmaps within the possibly
builtin classmaps vector, and saves those to the ddebug_table.

The reading/using: change list-foreach loops in ddebug_class_name() &
ddebug_find_valid_class() to walk the array from start to length.

Also:
Move #define __outvar up, above an added use in a fn-prototype.
Simplify ddebug_attach_module_classes args, ref has both addy,len.

This isn't technically a bugfix, but IMO simplifies later fixes for
the chicken-egg post-init enablement regression.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h |  1 -
 lib/dynamic_debug.c   | 61 ++-
 2 files changed, 32 insertions(+), 30 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 41682278d2e8..bf47bcfad8e6 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -81,7 +81,6 @@ enum class_map_type {
 };
 
 struct ddebug_class_map {
-   struct list_head link;
struct module *mod;
const char *mod_name;   /* needed for builtins */
const char **class_names;
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 48ca1387a409..fd5296dbb40f 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -45,10 +45,11 @@ extern struct ddebug_class_map __start___dyndbg_classes[];
 extern struct ddebug_class_map __stop___dyndbg_classes[];
 
 struct ddebug_table {
-   struct list_head link, maps;
+   struct list_head link;
const char *mod_name;
-   unsigned int num_ddebugs;
struct _ddebug *ddebugs;
+   struct ddebug_class_map *classes;
+   unsigned int num_ddebugs, num_classes;
 };
 
 struct ddebug_query {
@@ -146,13 +147,15 @@ static void vpr_info_dq(const struct ddebug_query *query, 
const char *msg)
  query->first_lineno, query->last_lineno, query->class_string);
 }
 
+#define __outvar /* filled by callee */
 static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table 
const *dt,
- const char 
*class_string, int *class_id)
+   const char 
*class_string,
+   __outvar int *class_id)
 {
struct ddebug_class_map *map;
-   int idx;
+   int i, idx;
 
-   list_for_each_entry(map, >maps, link) {
+   for (map = dt->classes, i = 0; i < dt->num_classes; i++, map++) {
idx = match_string(map->class_names, map->length, class_string);
if (idx >= 0) {
*class_id = idx + map->base;
@@ -163,7 +166,6 @@ static struct ddebug_class_map 
*ddebug_find_valid_class(struct ddebug_table cons
return NULL;
 }
 
-#define __outvar /* filled by callee */
 /*
  * Search the tables for _ddebug's which match the given `query' and
  * apply the `flags' and `mask' to them.  Returns number of matching
@@ -1109,9 +,10 @@ static void *ddebug_proc_next(struct seq_file *m, void 
*p, loff_t *pos)
 
 static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug 
*dp)
 {
-   struct ddebug_class_map *map;
+   struct ddebug_class_map *map = iter->table->classes;
+   int i, nc = iter->table->num_classes;
 
-   list_for_each_entry(map, >table->maps, link)
+   for (i = 0; i < nc; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
 
@@ -1195,30 +1198,31 @@ static const struct proc_ops proc_fops = {
.proc_write = ddebug_proc_write
 };
 
-static void ddebug_attach_module_classes(struct ddebug_table *dt,
-struct ddebug_class_map *classes,
-int num_classes)
+static void ddebug_attach_module_classes(struct ddebug_table *dt, struct 
_ddebug_info *di)
 {
struct ddebug_class_map *cm;
-   int i, j, ct = 0;
+   int i, nc = 0;
 
-   for (cm = classes, i = 0; i < num_classes; i++, cm++) {
+   /*
+* Find this module's classmaps in a subrange/wholerange of
+

[RFC PATCH 05/17] dyndbg: make ddebug_apply_class_bitmap more selective

ddebug_apply_class_bitmap() currently applies the class settings to
all modules, make it more selective, by adding query_module param.

The fn now calls ddebug_exec_queries(query, NULL), where NULL is
query_modname wildcard ("*" does the same).  So just expose the
parameter, and alter users to explicitly pass the wildcard value.

This allows its more selective use later; for propagating drm.debug
settings to dependent modules when/just-after they load.  Doing this
propagation with "*" is fine, but would match with all previously
loaded modules, creating more dynamic_debug.verbose=3 logging
activity.

No functional change.

Signed-off-by: Jim Cromie 
---

after `modprobe i915`, heres the module dependencies,
though not all on drm.debug.

bash-5.2# lsmod
Module  Size  Used by
i915 3133440  0
drm_buddy  20480  1 i915
ttm90112  1 i915
i2c_algo_bit   16384  1 i915
video  61440  1 i915
wmi32768  1 video
drm_display_helper200704  1 i915
drm_kms_helper208896  2 drm_display_helper,i915
drm   606208  5 
drm_kms_helper,drm_display_helper,drm_buddy,i915,ttm
cec57344  2 drm_display_helper,i915
---
 lib/dynamic_debug.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index fd5296dbb40f..5d609ff0d559 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -600,7 +600,8 @@ static int ddebug_exec_queries(char *query, const char 
*modname)
 
 /* apply a new bitmap to the sys-knob's current bit-state */
 static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
-unsigned long *new_bits, unsigned long 
*old_bits)
+unsigned long *new_bits, unsigned long 
*old_bits,
+const char *query_modname)
 {
 #define QUERY_SIZE 128
char query[QUERY_SIZE];
@@ -617,7 +618,7 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
snprintf(query, QUERY_SIZE, "class %s %c%s", 
map->class_names[bi],
 test_bit(bi, new_bits) ? '+' : '-', dcp->flags);
 
-   ct = ddebug_exec_queries(query, NULL);
+   ct = ddebug_exec_queries(query, query_modname);
matches += ct;
 
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
@@ -678,7 +679,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
continue;
}
curr_bits ^= BIT(cls_id);
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
dcp->bits);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, 
dcp->bits, NULL);
*dcp->bits = curr_bits;
v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp), 
cls_id,
  map->class_names[cls_id]);
@@ -688,7 +689,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0 
));
 
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
_bits);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, 
_bits, NULL);
*dcp->lvl = (cls_id + (wanted ? 1 : 0));
v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n", 
KP_NAME(kp), cls_id,
  map->class_names[cls_id], old_bits, 
curr_bits);
@@ -751,7 +752,7 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
inrep &= CLASSMAP_BITMASK(map->length);
}
v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits);
+   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, 
NULL);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -764,7 +765,7 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, 
KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, _bits, _bits);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, 
NULL);
*dcp->lvl = inrep;
break;
default:
-- 
2.38.1

[RFC PATCH 07/17] dyndbg: drop NUM_TYPE_ARRAY

ARRAY_SIZE works here, since array decl is complete.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index bf47bcfad8e6..81b643ab7f6e 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -104,11 +104,9 @@ struct ddebug_class_map {
.mod_name = KBUILD_MODNAME, \
.base = _base,  \
.map_type = _maptype,   \
-   .length = NUM_TYPE_ARGS(char*, __VA_ARGS__),\
+   .length = ARRAY_SIZE(_var##_classnames),\
.class_names = _var##_classnames,   \
}
-#define NUM_TYPE_ARGS(eltype, ...) \
-(sizeof((eltype[]){__VA_ARGS__}) / sizeof(eltype))
 
 /* encapsulate linker provided built-in (or module) dyndbg data */
 struct _ddebug_info {
-- 
2.38.1

[RFC PATCH 10/17] dyndbg-API: specialize DYNDBG_CLASSMAP_(DEFINE|USE)

Now that the DECLARE_DYNDBG_CLASSMAP macro has been split into
DYNDBG_CLASSMAP_DEFINE and DYNDBG_CLASSMAP_USE variants, lets
differentiate them according to their separate jobs.

Dyndbg's existing __dyndbg_classes[] section does:

. catalogs the classmaps defined by the module (or builtin modules)
. authorizes dyndbg to >control those class'd prdbgs for the module.

This patch adds __dyndbg_class_refs[] section:

. catalogs references/uses of the above classmap definitions.
. authorizes dyndbg to >control those class'd prdbgs in ref'g module.
. maps the client module to classmap definitions
  this allows dyndbg to propagate drm.debug to the client module.

The distinction of the 2 roles yields 2 gains:

It follows the define-once-declare-elsewhere pattern that K gave us,
dumping the weird coordinated-changes-by-identical-classmaps API.

It should help solve the chicken-egg problem that drm.debug-on-dyndbg
has; the _USEr module must propagate the drm.debug setting once the
using module has loaded.

The new DYNDBG_CLASSMAP macros add records to the sections:

DYNDBG_CLASSMAP_DEFINE:
  invoked by drm_print, just once per sub-system.
  defines the classmap, names "DRM_UT_*", maps to class_id's
  authorizes dyndbg to exert >control
  populates __dyndbg_classes[] "section", __used.
  exports the classmap.

DYNDBG_CLASSMAP_USE:
  invoked by modules using classmaps defined & exported elsewhere
  populates __dyndbg_class_refs[] "section", __used.
  maps client-module name to the extern'd classmap.
  no client-name yet, but will need it.

also:

struct ddebug_info gets 2 new fields to encapsulate the new section:
  class_refs, num_class_refs.
  set by dynamic_debug_init() for builtins.
  or by kernel/module/main:load_info() for loadable modules.

. struct ddebug_class_user
  contains: user-module-name, ref to classmap-defn
  dyndbg finds drm-driver's use of a classmap, gets/applies its settings

. struct ddebug_class_map gets .knob ptr to ddebug_class_param.
  compiled null, init'd under ddebug_add_module()
  allows finding drm.debug setting.

. vmlinux.lds.h additions: linker symbols, KEEP for new section

dynamic_debug.c:

ddebug_attach_module_classes():
  as before
  foreach __dyndbg_classes: ddebug_find_kparam(classmap*)

ddebug_attach_client_module_classes():
  foreach __dyndbg_class_refs: ddebug_param_load_dependent_class(classmap*)
  called after list-add to ddebug-tables.

ddebug_load_dependent_class():

This applies >controls to the module, it needs the module to be
present in the ddebug-tables list so that ddebug_change can apply the
changes to it.  So in ddebug_add_module, call 2nd fn *after* adding
the ddebug_table to the list.

ddebug_find_kparam(classmap*):

Finds the kernel-param / sysfs-node that controls the classmap, by
verifying that dyndbg's kparam-ops are used by the kparam.  The found
kparams arg is our ddebug_class_param, and has a ref to the state-var
under the sysfs-node.

ddebug_match_attach_kparam():

tests that kparam.ops == dyndbg's, then casts arg to
ddebug_class_param, and tests modnames for equality.

ddebug_param_load_dependent_class(struct ddebug_class_user*):

Called on class_refs entries, these classmaps have already been seen
by ddebug_find_kparam() which has wired the classmap.knob to the kparam.
So this fn just calls ddebug_apply_class_bitmap() on the state-var.

ddebug_find_valid_class():

This helps ddebug_change(), doing the search over classmaps, looking
for the class given to >control.  So now it searches over
__dyndbg_class_refs[] after __dyndbg_classes[].

Thats the theory anyway.  things are still broken (differently) for
both builtins and loadables.  For loadables, the >control is applied,
but doesnt alter any callsites.

Signed-off-by: Jim Cromie 
---
 include/asm-generic/vmlinux.lds.h |   3 +
 include/linux/dynamic_debug.h |  41 ++---
 kernel/module/main.c  |   2 +
 lib/dynamic_debug.c   | 137 +++---
 4 files changed, 157 insertions(+), 26 deletions(-)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 3dc5824141cd..7100701fb68c 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -363,6 +363,9 @@
__start___dyndbg_classes = .;   \
KEEP(*(__dyndbg_classes))   \
__stop___dyndbg_classes = .;\
+   __start___dyndbg_class_refs = .;\
+   KEEP(*(__dyndbg_class_refs))\
+   __stop___dyndbg_class_refs = .; \
__start___dyndbg = .;   \
KEEP(*(__dyndbg))   \
__stop___dyndbg = .;\
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index

[RFC PATCH 08/17] dyndbg: reduce verbose/debug clutter

currently, for verbose=3, this is logged:

[ 3832.333424] dyndbg: parsed: func="" file="" module="amdgpu" format="" 
lineno=0-0 class=DRM_UT_PRIME
[ 3832.333888] dyndbg: no matches for query
[ 3832.334093] dyndbg: no-match: func="" file="" module="amdgpu" format="" 
lineno=0-0 class=DRM_UT_PRIME
[ 3832.334570] dyndbg: processed 1 queries, with 0 matches, 0 errs

This patch removes 2nd & 3rd lines;
 3 differs from 1 only by status
 2 is just status, retold in 4, with more info.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index a0dc681cd215..445f25ef2461 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -265,9 +265,6 @@ static int ddebug_change(const struct ddebug_query *query,
}
mutex_unlock(_lock);
 
-   if (!nfound && verbose)
-   pr_info("no matches for query\n");
-
return nfound;
 }
 
@@ -536,7 +533,7 @@ static int ddebug_exec_query(char *query_string, const char 
*modname)
struct flag_settings modifiers = {};
struct ddebug_query query = {};
 #define MAXWORDS 9
-   int nwords, nfound;
+   int nwords;
char *words[MAXWORDS];
 
nwords = ddebug_tokenize(query_string, words, MAXWORDS);
@@ -554,10 +551,7 @@ static int ddebug_exec_query(char *query_string, const 
char *modname)
return -EINVAL;
}
/* actually go and implement the change */
-   nfound = ddebug_change(, );
-   vpr_info_dq(, nfound ? "applied" : "no-match");
-
-   return nfound;
+   return ddebug_change(, );
 }
 
 /* handle multiple queries in query string, continue on error, return
-- 
2.38.1

[RFC PATCH 14/17] dyndbg: unwrap __ddebug_add_module inner function NOTYET

The inner func has a base arg which is unused in the body, so theres
no point in having the inner fn.  Its one-time purpose was subsumed
into the ddebug_info record, which is used in dynamic_debug_init() as
a cursor to load the builtin _ddebug[] table.

TODO: cited commit gives another reason for base, to provide an index
in support of de-duplicating column data.  Refresh that patchset to
see if its still true.

Fixes: 6afa31514977 ("dyndbg: unwrap __ddebug_add_module inner function")

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 45b8414fa130..02f36c553835 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1329,8 +1329,7 @@ static void ddebug_attach_client_module_classes(struct 
ddebug_table *dt, struct
  * Allocate a new ddebug_table for the given module
  * and add it to the global list.
  */
-static int __ddebug_add_module(struct _ddebug_info *di, unsigned int base,
-  const char *modname)
+int ddebug_add_module(struct _ddebug_info *di, const char *modname)
 {
struct ddebug_table *dt;
 
@@ -1372,11 +1371,6 @@ static int __ddebug_add_module(struct _ddebug_info *di, 
unsigned int base,
return 0;
 }
 
-int ddebug_add_module(struct _ddebug_info *di, const char *modname)
-{
-   return __ddebug_add_module(di, 0, modname);
-}
-
 /* helper for ddebug_dyndbg_(boot|module)_param_cb */
 static int ddebug_dyndbg_param_cb(char *param, char *val,
const char *modname, int on_err)
@@ -1519,7 +1513,7 @@ static int __init dynamic_debug_init(void)
mod_ct++;
di.num_descs = mod_sites;
di.descs = iter_mod_start;
-   ret = __ddebug_add_module(, i - mod_sites, modname);
+   ret = ddebug_add_module(, modname);
if (ret)
goto out_err;
 
@@ -1530,7 +1524,7 @@ static int __init dynamic_debug_init(void)
}
di.num_descs = mod_sites;
di.descs = iter_mod_start;
-   ret = __ddebug_add_module(, i - mod_sites, modname);
+   ret = ddebug_add_module(, modname);
if (ret)
goto out_err;
 
-- 
2.38.1

[RFC PATCH 03/17] dyndbg: fix readback value on LEVEL_NAMES interfaces

Since sysfs knobs should generally read-back what was just written
(unless theres a good reason to do otherwise), this result (using
test_dynamic_debug.ko) is suboptimal:

  echo L3 > p_level_names
  cat p_level_names
  4

Fix this with a -1 offset in LEVEL_NAMES readback.

NOTE:

Calling this a BUG is debatable, and the above is slightly inaccurate
wrt "read-back"; whats written is a LEVEL_NAME (a string).  Whats read
back is an integer, giving the 'edge' of the 'low-pass-filter'

The actual test looks like:

RTT: L4 -> p_level_names : 4 :: DOING: levels 4-1
[   17.509594] dyndbg: "L4" > p_level_names:0x4
[   17.510115] dyndbg: apply: 0x1f to: 0xf
[   17.510506] dyndbg: query 0: "class L4 +p" mod:*
[   17.510992] dyndbg: split into words: "class" "L4" "+p"
[   17.511521] dyndbg: op='+'
[   17.511811] dyndbg: flags=0x1
[   17.512127] dyndbg: *flagsp=0x1 *maskp=0x
[   17.512604] dyndbg: parsed: func="" file="" module="" format="" lineno=0-0 
class=L4
[   17.513414] dyndbg: applied: func="" file="" module="" format="" lineno=0-0 
class=L4
[   17.514204] dyndbg: processed 1 queries, with 1 matches, 0 errs
[   17.514809] dyndbg: bit_4: 1 matches on class: L4 -> 0x1f
[   17.515355] dyndbg: p_level_names: changed bit-4: "L4" f->1f
[   17.515933] dyndbg: total matches: 1
crap [[ 5 != 4 ]]

This -1 adjustment just reports the edge consistently with its
input-mapping.

Fixes: b9400852c080 (dyndbg: add drm.debug style (drm/parameters/debug) bitmap 
support)

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 009f2ead09c1..48ca1387a409 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -794,6 +794,8 @@ int param_get_dyndbg_classes(char *buffer, const struct 
kernel_param *kp)
return scnprintf(buffer, PAGE_SIZE, "0x%lx\n", *dcp->bits);
 
case DD_CLASS_TYPE_LEVEL_NAMES:
+   return scnprintf(buffer, PAGE_SIZE, "%d\n", *dcp->lvl - 1);
+
case DD_CLASS_TYPE_LEVEL_NUM:
return scnprintf(buffer, PAGE_SIZE, "%d\n", *dcp->lvl);
default:
-- 
2.38.1

[RFC PATCH 02/17] test-dyndbg: show that DEBUG enables prdbgs at compiletime

Dyndbg is required to enable prdbgs at compile-time if DEBUG is
defined.  Show this works; add the defn to test_dynamic_debug.c,
and manually inspect/verify its effect at module load:

[   15.292810] dyndbg: module:test_dynamic_debug attached 4 classes
[   15.293189] dyndbg:  32 debug prints in module test_dynamic_debug
[   15.293715] test_dd: init start
[   15.293716] test_dd: doing categories
[   15.293716] test_dd: LOW msg
...
[   15.293733] test_dd: L6 msg
[   15.293733] test_dd: L7 msg
[   15.293733] test_dd: init done

NOTES:

As is observable above, define DEBUG enables all prdbgs, including
those in mod_init-fn, and more notably, the "class"d ones (callsites
with non-default class_ids).

This differs from the >control interface, which in order to properly
protect a client's class'd prdbgs, requires a "class FOO" in queries
to change them.  Note that the DEBUG is in the module source file.

This yields an occaisional surprise; the following disables all the
compile-time enabled plain prdbgs, but leaves the class'd ones
enabled.

 :#> modprobe test_dynamic_debug dyndbg==_

Signed-off-by: Jim Cromie 
---
 lib/test_dynamic_debug.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index a01f0193a419..9d48689dc0ab 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -8,6 +8,8 @@
 
 #define pr_fmt(fmt) "test_dd: " fmt
 
+#define DEBUG
+
 #include 
 
 /* run tests by reading or writing sysfs node: do_prints */
-- 
2.38.1

[RFC PATCH 01/17] test-dyndbg: fixup CLASSMAP usage error

more careful reading of test output reveals:

lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing 
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n" 
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/test_dynamic_debug.c:107 [test_dynamic_debug]do_cats =_ "HI msg\n" class 
unknown, _id:13

That last line is wrong, the HI class is declared.

But the enum's 1st val (explicitly initialized) was wrong; it must be
_base, not _base+1 (a DECLARE_DYNDBG_CLASSMAP param).  So the last
enumeration exceeded the range of mapped class-id's, which triggered
the "class unknown" report.  Basically, I coded in an error, and
forgot to verify it and remove it.

RFC:

This patch fixes a bad usage of DEFINE_DYNDBG_CLASSMAP(), showing that
it is too error-prone.  As noted in test-dynamic-debug.c comments:

 * Using the CLASSMAP api:
 * - classmaps must have corresponding enum
 * - enum symbols must match/correlate with class-name strings in the map.
 * - base must equal enum's 1st value
 * - multiple maps must set their base to share the 0-62 class_id space !!
 *   (build-bug-on tips welcome)

Those shortcomings could largely be fixed with a __stringify_list
(which doesn't exist) used in DEFINE_DYNAMIC_DEBUG_CLASSMAP(), on
__VA_ARGS__ a 2nd time.  Then, DRM would pass DRM_UT_* ; all the
categories, in order, and not their stringifications, which created
all the usage complications above.

Signed-off-by: Jim Cromie 
---
 lib/test_dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 8dd250ad022b..a01f0193a419 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -75,7 +75,7 @@ DD_SYS_WRAP(disjoint_bits, p);
 DD_SYS_WRAP(disjoint_bits, T);
 
 /* symbolic input, independent bits */
-enum cat_disjoint_names { LOW = 11, MID, HI };
+enum cat_disjoint_names { LOW = 10, MID, HI };
 DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10,
"LOW", "MID", "HI");
 DD_SYS_WRAP(disjoint_names, p);
-- 
2.38.1

[RFC PATCH 00/17] DRM_USE_DYNAMIC_DEBUG regression

Hi everyone,

DRM_USE_DYNAMIC_DEBUG=y has a regression on rc-*

Regression is due to a chicken-egg problem loading modules; on
`modprobe i915`, drm is loaded 1st, and drm.debug is set.  When
drm_debug_enabled() tested __drm_debug at runtime, that just worked.

But with DRM_USE_DYNAMIC_DEBUG=y, the runtime test is replaced with a
post-load enablement of drm_dbg/dyndbg callsites (static-keys), via
dyndbg's callback on __drm_debug.  Since all drm-drivers need drm.ko,
it is loaded 1st, then drm.debug=X is applied, then drivers load, but
too late for drm_dbgs to be enabled.

STATUS

For all-loadable drm,i915,amdgpu configs, it almost works, but
propagating drm.debug to dependent modules doesnt actually apply,
though the motions are there.  This is not the problem I want to chase
here.

The more basic trouble is:

For builtin drm + helpers, things are broken pretty early; at the
beginning of dynamic_debug_init().  As the ddebug_sanity() commit-msg
describes in some detail, the records added by _USE fail to reference
the struct ddebug_class_map created and exported by _DEFINE, but get
separate addresses to "other" data that segv's when used as the
expected pointer. FWIW, the pointer val starts with "revi".

OVERVIEW

DECLARE_DYNDBG_CLASSMAP is broken: it is one-size-fits-all-poorly.
It muddles the distinction between a (single) definition, and multiple
references.  Something exported should suffice.

The core of this patchset splits it into:

DYNDBG_CLASSMAP_DEFINE  used once per subsystem to define each classmap
DYNDBG_CLASSMAP_USE declare dependence on a DEFINEd classmap

This makes the weird coordinated-changes-by-identical-classmaps
"feature" unnecessary; the DEFINE can export the var, and USE refers
to the exported var.

So this patchset adds another section: __dyndbg_class_refs.

It is like __dyndbg_classes; it is scanned under ddebug_add_module(),
and attached to each module's ddebug_table.  Once attached, it can be
used like classes to validate and apply class FOO >control queries.

It also maps the class user -> definer explicitly, so that when the
module is loaded, the section scan can find the kernel-param that is
wired to dyndbg's kparam-callback, and apply its state-var, forex:
__drm_debug to the just loaded helper/driver module.

Theres plenty to address Im sure.

Jim Cromie (17):
  test-dyndbg: fixup CLASSMAP usage error
  test-dyndbg: show that DEBUG enables prdbgs at compiletime
  dyndbg: fix readback value on LEVEL_NAMES interfaces
  dyndbg: replace classmap list with a vector
  dyndbg: make ddebug_apply_class_bitmap more selective
  dyndbg: dynamic_debug_init - use pointer inequality, not strcmp
  dyndbg: drop NUM_TYPE_ARRAY
  dyndbg: reduce verbose/debug clutter
  dyndbg-API: replace DECLARE_DYNDBG_CLASSMAP with
DYNDBG_CLASSMAP(_DEFINE|_USE)
  dyndbg-API: specialize DYNDBG_CLASSMAP_(DEFINE|USE)
  dyndbg-API: DYNDBG_CLASSMAP_USE drop extra args
  dyndbg-API: DYNDBG_CLASSMAP_DEFINE() improvements
  drm_print: fix stale macro-name in comment
  dyndbg: unwrap __ddebug_add_module inner function NOTYET
  dyndbg: ddebug_sanity()
  dyndbg: mess-w-dep-class
  dyndbg: miss-on HACK

 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  14 +-
 drivers/gpu/drm/display/drm_dp_helper.c |  14 +-
 drivers/gpu/drm/drm_crtc_helper.c   |  14 +-
 drivers/gpu/drm/drm_print.c |  22 +--
 drivers/gpu/drm/i915/i915_params.c  |  14 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  14 +-
 include/asm-generic/vmlinux.lds.h   |   3 +
 include/drm/drm_print.h |   6 +-
 include/linux/dynamic_debug.h   |  57 --
 include/linux/map.h |  54 ++
 kernel/module/main.c|   2 +
 lib/dynamic_debug.c | 240 +++-
 lib/test_dynamic_debug.c|  47 ++---
 13 files changed, 344 insertions(+), 157 deletions(-)
 create mode 100644 include/linux/map.h

-- 
2.38.1

Re: [PATCH v9 4/5] drm/msm/dp: parser link-frequencies as property of dp_out endpoint

6 декабря 2022 г. 02:08:13 GMT+03:00, Kuogee Hsieh  
пишет:
>Add capability to parser and retrieve max DP link supported rate from
>link-frequencies property of dp_out endpoint.
>
>Changes in v6:
>-- second patch after split parser patch into two patches
>
>Changes in v7:
>-- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate
>
>Changes in v9:
>-- separate parser link-frequencies out of data-lanes
>
>Signed-off-by: Kuogee Hsieh 
>---
> drivers/gpu/drm/msm/dp/dp_parser.c | 20 ++--
> drivers/gpu/drm/msm/dp/dp_parser.h |  2 ++
> 2 files changed, 20 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c 
>b/drivers/gpu/drm/msm/dp/dp_parser.c
>index b5f7e70..fdea843 100644
>--- a/drivers/gpu/drm/msm/dp/dp_parser.c
>+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
>@@ -94,15 +94,17 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
> static int dp_parser_misc(struct dp_parser *parser)
> {
>   struct device_node *of_node = parser->pdev->dev.of_node;
>+  struct device_node *endpoint;
>+  u64 frequency;
>   int cnt;
> 
>   /*
>* data-lanes is the property of dp_out endpoint
>*/
>   cnt = drm_of_get_data_lanes_count_ep(of_node, 1, 0, 1, 
> DP_MAX_NUM_DP_LANES);
>-  if (cnt > 0)
>+  if (cnt > 0) {
>   parser->max_dp_lanes = cnt;
>-  else {
>+  } else {

This belongs to the previous patch 

>   /*
>* legacy code, data-lanes is the property of mdss_dp node
>*/
>@@ -113,6 +115,20 @@ static int dp_parser_misc(struct dp_parser *parser)
>   parser->max_dp_lanes = DP_MAX_NUM_DP_LANES; /* 4 lanes 
> */
>   }
> 
>+  cnt = 0;
>+  endpoint = of_graph_get_endpoint_by_regs(of_node, 1, 0); /* port@1 */
>+  if (endpoint)
>+  cnt = of_property_count_u64_elems(endpoint, "link-frequencies");
>+  of_node_put(endpoint);
>+  if (cnt > 0) {
>+  of_property_read_u64_index(endpoint, "link-frequencies",

And this is use after free.

I still think than an additional function would make code simpler. You can 
return an error code at any point. And then handle it in the calling code.

>+  cnt - 1, );
>+  frequency /= 10;/* from symbol rate to link rate */
>+  parser->max_dp_link_rate = (frequency / 1000); /* kbits */
>+  } else {
>+  parser->max_dp_link_rate = DP_LINK_RATE_HBR2; /* 54 khz */
>+  }
>+
>   return 0;
> }
> 
>diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h 
>b/drivers/gpu/drm/msm/dp/dp_parser.h
>index 866c1a8..3ddf639 100644
>--- a/drivers/gpu/drm/msm/dp/dp_parser.h
>+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
>@@ -15,6 +15,7 @@
> #define DP_LABEL "MDSS DP DISPLAY"
> #define DP_MAX_PIXEL_CLK_KHZ  675000
> #define DP_MAX_NUM_DP_LANES   4
>+#define DP_LINK_RATE_HBR2   54
> 
> enum dp_pm_type {
>   DP_CORE_PM,
>@@ -119,6 +120,7 @@ struct dp_parser {
>   struct dp_io io;
>   struct dp_display_data disp_data;
>   u32 max_dp_lanes;
>+  u32 max_dp_link_rate;
>   struct drm_bridge *next_bridge;
> 
>   int (*parse)(struct dp_parser *parser);

[PATCH v9 3/5] drm/msm/dp: parser data-lanes as property of dp_out endpoint

Add capability to parser data-lanes as property of dp_out endpoint.
Also retain the original capability to parser data-lanes as property
of mdss_dp node to handle legacy case.

Changes in v6:
-- first patch after split parser patch into two

Changes in v7:
-- check "data-lanes" from endpoint first

Signed-off-by: Kuogee Hsieh 
Reviewed-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/dp/dp_parser.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c 
b/drivers/gpu/drm/msm/dp/dp_parser.c
index dd73221..b5f7e70 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -94,16 +94,25 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
 static int dp_parser_misc(struct dp_parser *parser)
 {
struct device_node *of_node = parser->pdev->dev.of_node;
-   int len;
-
-   len = drm_of_get_data_lanes_count(of_node, 1, DP_MAX_NUM_DP_LANES);
-   if (len < 0) {
-   DRM_WARN("Invalid property \"data-lanes\", default max DP lanes 
= %d\n",
-DP_MAX_NUM_DP_LANES);
-   len = DP_MAX_NUM_DP_LANES;
+   int cnt;
+
+   /*
+* data-lanes is the property of dp_out endpoint
+*/
+   cnt = drm_of_get_data_lanes_count_ep(of_node, 1, 0, 1, 
DP_MAX_NUM_DP_LANES);
+   if (cnt > 0)
+   parser->max_dp_lanes = cnt;
+   else {
+   /*
+* legacy code, data-lanes is the property of mdss_dp node
+*/
+   cnt = drm_of_get_data_lanes_count(of_node, 1, 
DP_MAX_NUM_DP_LANES);
+   if (cnt > 0)
+   parser->max_dp_lanes = cnt;
+   else
+   parser->max_dp_lanes = DP_MAX_NUM_DP_LANES; /* 4 lanes 
*/
}
 
-   parser->max_dp_lanes = len;
return 0;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v9 5/5] drm/msm/dp: add support of max dp link rate

By default, HBR2 (5.4G) is the max link link be supported. This patch uses the
actual limit specified by DT and removes the artificial limitation to 5.4 Gbps.
Supporting HBR3 is a consequence of that.

Changes in v2:
-- add max link rate from dtsi

Changes in v3:
-- parser max_data_lanes and max_dp_link_rate from dp_out endpoint

Changes in v4:
-- delete unnecessary pr_err

Changes in v5:
-- split parser function into different patch

Changes in v9:
-- revised commit test

Signed-off-by: Kuogee Hsieh 
Reviewed-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/dp/dp_display.c | 4 
 drivers/gpu/drm/msm/dp/dp_panel.c   | 7 ---
 drivers/gpu/drm/msm/dp/dp_panel.h   | 1 +
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index bfd0aef..edee550 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -390,6 +390,10 @@ static int dp_display_process_hpd_high(struct 
dp_display_private *dp)
struct edid *edid;
 
dp->panel->max_dp_lanes = dp->parser->max_dp_lanes;
+   dp->panel->max_dp_link_rate = dp->parser->max_dp_link_rate;
+
+   drm_dbg_dp(dp->drm_dev, "max_lanes=%d max_link_rate=%d\n",
+   dp->panel->max_dp_lanes, dp->panel->max_dp_link_rate);
 
rc = dp_panel_read_sink_caps(dp->panel, dp->dp_display.connector);
if (rc)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c 
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 5149ceb..933fa9c 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -75,12 +75,13 @@ static int dp_panel_read_dpcd(struct dp_panel *dp_panel)
link_info->rate = drm_dp_bw_code_to_link_rate(dpcd[DP_MAX_LINK_RATE]);
link_info->num_lanes = dpcd[DP_MAX_LANE_COUNT] & DP_MAX_LANE_COUNT_MASK;
 
+   /* Limit data lanes from data-lanes of endpoint properity of dtsi */
if (link_info->num_lanes > dp_panel->max_dp_lanes)
link_info->num_lanes = dp_panel->max_dp_lanes;
 
-   /* Limit support upto HBR2 until HBR3 support is added */
-   if (link_info->rate >= (drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4)))
-   link_info->rate = drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4);
+   /* Limit link rate from link-frequencies of endpoint properity of dtsi 
*/
+   if (link_info->rate > dp_panel->max_dp_link_rate)
+   link_info->rate = dp_panel->max_dp_link_rate;
 
drm_dbg_dp(panel->drm_dev, "version: %d.%d\n", major, minor);
drm_dbg_dp(panel->drm_dev, "link_rate=%d\n", link_info->rate);
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.h 
b/drivers/gpu/drm/msm/dp/dp_panel.h
index d861197a..f04d021 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.h
+++ b/drivers/gpu/drm/msm/dp/dp_panel.h
@@ -50,6 +50,7 @@ struct dp_panel {
 
u32 vic;
u32 max_dp_lanes;
+   u32 max_dp_link_rate;
 
u32 max_bw_code;
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v9 4/5] drm/msm/dp: parser link-frequencies as property of dp_out endpoint

Add capability to parser and retrieve max DP link supported rate from
link-frequencies property of dp_out endpoint.

Changes in v6:
-- second patch after split parser patch into two patches

Changes in v7:
-- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate

Changes in v9:
-- separate parser link-frequencies out of data-lanes

Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/dp/dp_parser.c | 20 ++--
 drivers/gpu/drm/msm/dp/dp_parser.h |  2 ++
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c 
b/drivers/gpu/drm/msm/dp/dp_parser.c
index b5f7e70..fdea843 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -94,15 +94,17 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
 static int dp_parser_misc(struct dp_parser *parser)
 {
struct device_node *of_node = parser->pdev->dev.of_node;
+   struct device_node *endpoint;
+   u64 frequency;
int cnt;
 
/*
 * data-lanes is the property of dp_out endpoint
 */
cnt = drm_of_get_data_lanes_count_ep(of_node, 1, 0, 1, 
DP_MAX_NUM_DP_LANES);
-   if (cnt > 0)
+   if (cnt > 0) {
parser->max_dp_lanes = cnt;
-   else {
+   } else {
/*
 * legacy code, data-lanes is the property of mdss_dp node
 */
@@ -113,6 +115,20 @@ static int dp_parser_misc(struct dp_parser *parser)
parser->max_dp_lanes = DP_MAX_NUM_DP_LANES; /* 4 lanes 
*/
}
 
+   cnt = 0;
+   endpoint = of_graph_get_endpoint_by_regs(of_node, 1, 0); /* port@1 */
+   if (endpoint)
+   cnt = of_property_count_u64_elems(endpoint, "link-frequencies");
+   of_node_put(endpoint);
+   if (cnt > 0) {
+   of_property_read_u64_index(endpoint, "link-frequencies",
+   cnt - 1, );
+   frequency /= 10;/* from symbol rate to link rate */
+   parser->max_dp_link_rate = (frequency / 1000); /* kbits */
+   } else {
+   parser->max_dp_link_rate = DP_LINK_RATE_HBR2; /* 54 khz */
+   }
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h 
b/drivers/gpu/drm/msm/dp/dp_parser.h
index 866c1a8..3ddf639 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -15,6 +15,7 @@
 #define DP_LABEL "MDSS DP DISPLAY"
 #define DP_MAX_PIXEL_CLK_KHZ   675000
 #define DP_MAX_NUM_DP_LANES4
+#define DP_LINK_RATE_HBR2   54
 
 enum dp_pm_type {
DP_CORE_PM,
@@ -119,6 +120,7 @@ struct dp_parser {
struct dp_io io;
struct dp_display_data disp_data;
u32 max_dp_lanes;
+   u32 max_dp_link_rate;
struct drm_bridge *next_bridge;
 
int (*parse)(struct dp_parser *parser);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v9 2/5] dt-bindings: msm/dp: add data-lanes and link-frequencies property

Add both data-lanes and link-frequencies property into endpoint

Changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property

Changes in v8:
-- correct Bjorn mail address to kernel.org

Signed-off-by: Kuogee Hsieh `
---
 Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml 
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index f2515af..38ce17d 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -81,6 +81,7 @@ properties:
 
   data-lanes:
 $ref: /schemas/types.yaml#/definitions/uint32-array
+deprecated: true
 minItems: 1
 maxItems: 4
 items:
@@ -104,6 +105,11 @@ properties:
   port@1:
 $ref: /schemas/graph.yaml#/properties/port
 description: Output endpoint of the controller
+  data-lanes:
+  $ref: /schemas/types.yaml#/definitions/uint32-array
+
+  link-frequencies:
+  $ref: /schemas/types.yaml#/definitions/uint64-array
 
 required:
   - compatible
@@ -193,6 +199,9 @@ examples:
 reg = <1>;
 endpoint {
 remote-endpoint = <>;
+data-lanes = <1 2>;
+link-frequencies = /bits/ 64 <162000 27
+  54 81>;
 };
 };
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v9 1/5] arm64: dts: qcom: add data-lanes and link-freuencies into dp_out endpoint

Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.

Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add _out to sc7180-trogdor.dtsi and sc7280-herobrine.dtsi

Changes in v6:
-- add data-lanes and link-frequencies to yaml

Changes in v7:
-- change 16000 to 162000
-- separate yaml to different patch

Changes in v8:
-- correct Bjorn mail address to kernel.org

Changes in v9:
-- use symbol rate (hz) for link-frequencies at dp_out at sc7180_trogdor.dtsi

Signed-off-by: Kuogee Hsieh 
---
 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi   | 6 +-
 arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi 
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index eae22e6..93b0cde 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -814,7 +814,11 @@ hp_i2c:  {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
-   data-lanes = <0 1>;
+};
+
+_out {
+data-lanes = <0  1>;
+link-frequencies = /bits/ 64 <162000 27 54>;
 };
 
 _adc {
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi 
b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
index c11e371..3c7a9d8 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -442,7 +442,11 @@ ap_i2c_tpm:  {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
-   data-lanes = <0 1>;
+};
+
+_out {
+   data-lanes = <0  1>;
+   link-frequencies = /bits/ 64 <162000 27 54 
81>;
 };
 
 _mdp {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v9 0/5] Add data-lanes and link-frequencies to dp_out endpoint

Add DP both data-lanes and link-frequencies property to dp_out endpoint and 
support
functions to DP driver.

Kuogee Hsieh (5):
  arm64: dts: qcom: add data-lanes and link-freuencies into dp_out
endpoint
  dt-bindings: msm/dp: add data-lanes and link-frequencies property
  drm/msm/dp: parser data-lanes as property of dp_out endpoint
  drm/msm/dp: parser link-frequencies as property of dp_out endpoint
  drm/msm/dp: add support of max dp link rate

 .../bindings/display/msm/dp-controller.yaml|  9 +
 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi   |  6 +++-
 arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi |  6 +++-
 drivers/gpu/drm/msm/dp/dp_display.c|  4 +++
 drivers/gpu/drm/msm/dp/dp_panel.c  |  7 ++--
 drivers/gpu/drm/msm/dp/dp_panel.h  |  1 +
 drivers/gpu/drm/msm/dp/dp_parser.c | 39 ++
 drivers/gpu/drm/msm/dp/dp_parser.h |  2 ++
 8 files changed, 62 insertions(+), 12 deletions(-)

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

Re: [PATCH v2 11/12] arm64: dts: qcom: sm6115: Add WCN node.

On Thu, Dec 01, 2022 at 11:38:16AM +0100, Krzysztof Kozlowski wrote:
> On 30/11/2022 21:09, Adam Skladowski wrote:
> > Add WCN node to allow using wifi module.
> > 
> 
> A nit: Drop full stop from commit subject.
> 

Done. Thanks for pointing it out :)

Regards,
Bjorn

> Best regards,
> Krzysztof
>

Re: [PATCH v2 01/11] pwm: Make .get_state() callback return an error code

2022-12-05 Thread Pavel Machek

Hi!

> .get_state() might fail in some cases. To make it possible that a driver
> signals such a failure change the prototype of .get_state() to return an
> error code.
> 
> This patch was created using coccinelle and the following semantic patch:
> 
> @p1@
> identifier getstatefunc;
> identifier driver;
> @@
>  struct pwm_ops driver = {
> ...,
> .get_state = getstatefunc
> ,...
>  };
> 
> @p2@
> identifier p1.getstatefunc;
> identifier chip, pwm, state;
> @@
> -void
> +int
>  getstatefunc(struct pwm_chip *chip, struct pwm_device *pwm, struct pwm_state 
> *state)
>  {
>...
> -  return;
> +  return 0;
>...
>  }
> 
> plus the actual change of the prototype in include/linux/pwm.h (plus some
> manual fixing of indentions and empty lines).
> 
> So for now all drivers return success unconditionally. They are adapted
> in the following patches to make the changes easier reviewable.
> 
> Signed-off-by: Uwe Kleine-König 

LED part:

Acked-by: Pavel Machek 

Best regards,
Pavel

>  static const struct pwm_ops ti_sn_pwm_ops = {
> diff --git a/drivers/leds/rgb/leds-qcom-lpg.c 
> b/drivers/leds/rgb/leds-qcom-lpg.c
> index 02f51cc61837..741cc2fd817d 100644
> --- a/drivers/leds/rgb/leds-qcom-lpg.c
> +++ b/drivers/leds/rgb/leds-qcom-lpg.c
> @@ -968,8 +968,8 @@ static int lpg_pwm_apply(struct pwm_chip *chip, struct 
> pwm_device *pwm,
>   return ret;
>  }
>  
> -static void lpg_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> -   struct pwm_state *state)
> +static int lpg_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> +  struct pwm_state *state)
>  {
>   struct lpg *lpg = container_of(chip, struct lpg, pwm);
>   struct lpg_channel *chan = >channels[pwm->hwpwm];
> @@ -982,20 +982,20 @@ static void lpg_pwm_get_state(struct pwm_chip *chip, 
> struct pwm_device *pwm,
>  
>   ret = regmap_read(lpg->map, chan->base + LPG_SIZE_CLK_REG, );
>   if (ret)
> - return;
> + return 0;
>  
>   refclk = lpg_clk_rates[val & PWM_CLK_SELECT_MASK];
>   if (refclk) {
>   ret = regmap_read(lpg->map, chan->base + LPG_PREDIV_CLK_REG, 
> );
>   if (ret)
> - return;
> + return 0;
>  
>   pre_div = lpg_pre_divs[FIELD_GET(PWM_FREQ_PRE_DIV_MASK, val)];
>   m = FIELD_GET(PWM_FREQ_EXP_MASK, val);
>  
>   ret = regmap_bulk_read(lpg->map, chan->base + PWM_VALUE_REG, 
> _value, sizeof(pwm_value));
>   if (ret)
> - return;
> + return 0;
>  
>   state->period = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC * 
> LPG_RESOLUTION * pre_div * (1 << m), refclk);
>   state->duty_cycle = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC * 
> pwm_value * pre_div * (1 << m), refclk);
> @@ -1006,13 +1006,15 @@ static void lpg_pwm_get_state(struct pwm_chip *chip, 
> struct pwm_device *pwm,
>  
>   ret = regmap_read(lpg->map, chan->base + PWM_ENABLE_CONTROL_REG, );
>   if (ret)
> - return;
> + return 0;
>  
>   state->enabled = FIELD_GET(LPG_ENABLE_CONTROL_OUTPUT, val);
>   state->polarity = PWM_POLARITY_NORMAL;
>  
>   if (state->duty_cycle > state->period)
>   state->duty_cycle = state->period;
> +
> + return 0;
>  }

-- 
People of Russia, stop Putin before his war on Ukraine escalates.


signature.asc
Description: PGP signature

Re: [PATCH v4 08/13] drm/msm/dp: Implement hpd_notify()

On Tue, Dec 06, 2022 at 12:29:13AM +0300, Dmitry Baryshkov wrote:
> 
> 
> On 5 December 2022 20:44:28 GMT+03:00, Bjorn Andersson 
>  wrote:
> >From: Bjorn Andersson 
> >
> >The DisplayPort controller's hot-plug mechanism is based on pinmuxing a
> >physical signal on a GPIO pin into the controller. This is not always
> >possible, either because there aren't dedicated GPIOs available or
> >because the hot-plug signal is a virtual notification, in cases such as
> >USB Type-C.
> >
> >For these cases, by implementing the hpd_notify() callback for the
> >DisplayPort controller's drm_bridge, a downstream drm_bridge
> >(next_bridge) can be used to track and signal the connection status
> >changes.
> >
> >This makes it possible to use downstream drm_bridges such as
> >display-connector or any virtual mechanism, as long as they are
> >implemented as a drm_bridge.
> >
> >Signed-off-by: Bjorn Andersson 
> >[bjorn: Drop connector->fwnode assignment and dev from struct msm_dp]
> >Signed-off-by: Bjorn Andersson 
> 
> Reviewed-by: Dmitry Baryshkov 
> 
> Minor nit: if for the next revision you reorder the patches to have
> hpd_enable first, then missing conditions, then this patch, it will
> look more logical.

You're right, that will look better. I'll do so.

Thanks,
Bjorn

> 
> >---
> >
> >Changes since v3:
> >- None
> >
> > drivers/gpu/drm/msm/dp/dp_display.c | 22 ++
> > drivers/gpu/drm/msm/dp/dp_drm.c |  1 +
> > drivers/gpu/drm/msm/dp/dp_drm.h |  2 ++
> > 3 files changed, 25 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
> >b/drivers/gpu/drm/msm/dp/dp_display.c
> >index 666b45c8ab80..17fcf8cd84cd 100644
> >--- a/drivers/gpu/drm/msm/dp/dp_display.c
> >+++ b/drivers/gpu/drm/msm/dp/dp_display.c
> >@@ -1772,3 +1772,25 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
> > dp_display->dp_mode.h_active_low =
> > !!(dp_display->dp_mode.drm_mode.flags & DRM_MODE_FLAG_NHSYNC);
> > }
> >+
> >+void dp_bridge_hpd_notify(struct drm_bridge *bridge,
> >+  enum drm_connector_status status)
> >+{
> >+struct msm_dp_bridge *dp_bridge = to_dp_bridge(bridge);
> >+struct msm_dp *dp_display = dp_bridge->dp_display;
> >+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->next_bridge)
> >+return;
> >+
> >+if (!dp->core_initialized) {
> >+drm_dbg_dp(dp->drm_dev, "not initialized\n");
> >+return;
> >+}
> >+
> >+if (!dp_display->is_connected && status == connector_status_connected)
> >+dp_add_event(dp, EV_HPD_PLUG_INT, 0, 0);
> >+else if (dp_display->is_connected && status == 
> >connector_status_disconnected)
> >+dp_add_event(dp, EV_HPD_UNPLUG_INT, 0, 0);
> >+}
> >diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c 
> >b/drivers/gpu/drm/msm/dp/dp_drm.c
> >index 6db82f9b03af..3898366ebd5e 100644
> >--- a/drivers/gpu/drm/msm/dp/dp_drm.c
> >+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
> >@@ -102,6 +102,7 @@ static const struct drm_bridge_funcs dp_bridge_ops = {
> > .get_modes= dp_bridge_get_modes,
> > .detect   = dp_bridge_detect,
> > .atomic_check = dp_bridge_atomic_check,
> >+.hpd_notify   = dp_bridge_hpd_notify,
> > };
> > 
> > struct drm_bridge *dp_bridge_init(struct msm_dp *dp_display, struct 
> > drm_device *dev,
> >diff --git a/drivers/gpu/drm/msm/dp/dp_drm.h 
> >b/drivers/gpu/drm/msm/dp/dp_drm.h
> >index 82035dbb0578..79e6b2cf2d25 100644
> >--- a/drivers/gpu/drm/msm/dp/dp_drm.h
> >+++ b/drivers/gpu/drm/msm/dp/dp_drm.h
> >@@ -32,5 +32,7 @@ enum drm_mode_status dp_bridge_mode_valid(struct 
> >drm_bridge *bridge,
> > void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
> > const struct drm_display_mode *mode,
> > const struct drm_display_mode *adjusted_mode);
> >+void dp_bridge_hpd_notify(struct drm_bridge *bridge,
> >+  enum drm_connector_status status);
> > 
> > #endif /* _DP_DRM_H_ */
> 
> -- 
> With best wishes
> Dmitry

[PATCH] fbdev: fbcon: release buffer when fbcon_do_set_font() failed

2022-12-05 Thread Tetsuo Handa

syzbot is reporting memory leak at fbcon_do_set_font() [1], for
commit a5a923038d70 ("fbdev: fbcon: Properly revert changes when
vc_resize() failed") missed that the buffer might be newly allocated
by fbcon_set_font().

Link: https://syzkaller.appspot.com/bug?extid=25bdb7b1703639abd498 [1]
Reported-by: syzbot 
Signed-off-by: Tetsuo Handa 
Tested-by: syzbot 
Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() 
failed")
---
 drivers/video/fbdev/core/fbcon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 098b62f7b701..8363f3b2b452 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2450,7 +2450,8 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, 
int h, int charcount,
 
if (userfont) {
p->userfont = old_userfont;
-   REFCOUNT(data)--;
+   if (--REFCOUNT(data) == 0)
+   kfree(data - FONT_EXTRA_WORDS * sizeof(int));
}
 
vc->vc_font.width = old_width;
-- 
2.34.1

Re: [PATCH 2/2] vfio/pci: Remove console drivers

2022-12-05 Thread m...@lab.how

Hi Thomas,

On Mon, Dec 5, 2022 at 3:11 AM Thomas Zimmermann  wrote:
>
> Hi
>
> Am 05.12.22 um 10:32 schrieb m...@lab.how:
> > I have a rtx 3070 and a 3090, I am absolutely sure I am binding vfio-pci
> > to the 3090 and not the 3070.
> >
> > I have bound the driver in two different ways, first by passing the IDs
> > to the module and alternatively by manipulating the system interface and
> > use the override (this is what I originally had to do when I used two
> > 1080s, so I know it works).
> >
> > While the 3090 doesn't show a console, there's a remnant from the refund
> > (and grub previously) there.
> >
> > The assessment Alex made previously, where
> > aperture_remove_conflicting_pci_devices() is removing the driver (EFIFB)
> > instead of the device seems correct, but it could also can be a quirky
> > of how EFIFB is implemented. I recall reading a long time ago that EFIFB
> > is a special device and once it detects changes it would simply give up.
> > There was also no way to attach a device to it again as it depends on
> > being preloaded outside the kernel; once something takes over the buffer
> > reinitializing is "impossible". I never went deeper to try and
> > understand it.
>
> We recently reworked fbdev's interaction with the aperture helpers. [1]
> All devices should now be removed iff the driver has been bound to it
> (which should be the case here) The patches went into an v6.1-rc.
>
> Could you try the most recent v6.1-rc and report if this fixes the problem?

I just tried the latest one, v6.1-rc8, and I can see all the commits
for the series you mentioned there.

The same freeze behavior happens when I load vfio-pci:

[ 6.525463] VFIO - User Level meta-driver version: 0.3
[ 6.528231] Console: switching to colour dummy device 320x90

--
Carlos

>
> Best regards
> Thomas
>
> [1] https://patchwork.freedesktop.org/series/106040/
>
> >
> >
> > On Mon, Dec 5, 2022, 2:00 AM Thomas Zimmermann  > > wrote:
> >
> > Hi
> >
> > Am 05.12.22 um 01:51 schrieb Alex Williamson:
> >  > On Sat, 3 Dec 2022 17:12:38 -0700
> >  > "m...@lab.how"  wrote:
> >  >
> >  >> Hi,
> >  >>
> >  >> I hope it is ok to reply to this old thread.
> >  >
> >  > It is, but the only relic of the thread is the subject.  For
> > reference,
> >  > the latest version of this posted is here:
> >  >
> >  >
> > https://lore.kernel.org/all/20220622140134.12763-4-tzimmerm...@suse.de/ 
> > 
> >  >
> >  > Which is committed as:
> >  >
> >  > d17378062079 ("vfio/pci: Remove console drivers")
> >  >
> >  >> Unfortunately, I found a
> >  >> problem only now after upgrading to 6.0.
> >  >>
> >  >> My setup has multiple GPUs (2), and I depend on EFIFB to have a
> > working console.
> >
> > Which GPUs do you have?
> >
> >  >> pre-patch behavior, when I bind the vfio-pci to my secondary GPU
> > both
> >  >> the passthrough and the EFIFB keep working fine.
> >  >> post-patch behavior, when I bind the vfio-pci to the secondary GPU,
> >  >> the EFIFB disappears from the system, binding the console to the
> >  >> "dummy console".
> >
> > The efifb would likely use the first GPU. And vfio-pci should only
> > remove the generic driver from the second device. Are you sure that
> > you're not somehow using the first GPU with vfio-pci.
> >
> >  >> Whenever you try to access the terminal, you have the screen
> > stuck in
> >  >> whatever was the last buffer content, which gives the impression of
> >  >> "freezing," but I can still type.
> >  >> Everything else works, including the passthrough.
> >  >
> >  > This sounds like the call to
> > aperture_remove_conflicting_pci_devices()
> >  > is removing the conflicting driver itself rather than removing the
> >  > device from the driver.  Is it not possible to unbind the GPU from
> >  > efifb before binding the GPU to vfio-pci to effectively nullify the
> >  > added call?
> >  >
> >  >> I can only think about a few options:
> >  >>
> >  >> - Is there a way to have EFIFB show up again? After all it looks
> > like
> >  >> the kernel has just abandoned it, but the buffer is still there. I
> >  >> can't find a single message about the secondary card and EFIFB in
> >  >> dmesg, but there's a message for the primary card and EFIFB.
> >  >> - Can we have a boolean controlling the behavior of vfio-pci
> >  >> altogether or at least controlling the behavior of vfio-pci for that
> >  >> specific ID? I know there's already some option for vfio-pci and VGA
> >  >> cards, would it be appropriate to attach this behavior to that
> > option?
> >  >
> >  > I suppose we could have an opt-out module option on vfio-pci to skip
> >  > the above call, but clearly it would be better if

Re: [PATCH v8 2/5] dt-bindings: msm/dp: add data-lanes and link-frequencies property




On 5 December 2022 22:14:27 GMT+03:00, Kuogee Hsieh  
wrote:
>Add both data-lanes and link-frequencies property into endpoint
>
>Changes in v7:
>-- split yaml out of dtsi patch
>-- link-frequencies from link rate to symbol rate
>-- deprecation of old data-lanes property
>
>Changes in v8:
>-- correct Bjorn mail address to kernel.org
>
>Signed-off-by: Kuogee Hsieh 
>---
> .../bindings/display/msm/dp-controller.yaml| 22 --
> 1 file changed, 16 insertions(+), 6 deletions(-)
>
>diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml 
>b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>index f2515af..13d2c3c 100644
>--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>@@ -79,12 +79,6 @@ properties:
>   aux-bus:
> $ref: /schemas/display/dp-aux-bus.yaml#
> 
>-  data-lanes:
>-$ref: /schemas/types.yaml#/definitions/uint32-array
>-minItems: 1
>-maxItems: 4
>-items:
>-  maximum: 3

These properties can still be used, e.g. Bjorn is submitting patches with the 
old property. I think this should be marked with deprecated: true instead of 
removal.

> 
>   "#sound-dai-cells":
> const: 0
>@@ -105,6 +99,19 @@ properties:
> $ref: /schemas/graph.yaml#/properties/port
> description: Output endpoint of the controller
> 
>+properties:
>+  endpoint:
>+$ref: /schemas/media/video-interfaces.yaml#
>+
>+  properties:
>+data-lanes:
>+  $ref: /schemas/types.yaml#/definitions/uint32-array
>+
>+link-frequencies:
>+  $ref: /schemas/types.yaml#/definitions/uint64-array
>+
>+  additionalProperties: false
>+
> required:
>   - compatible
>   - reg
>@@ -193,6 +200,9 @@ examples:
> reg = <1>;
> endpoint {
> remote-endpoint = <>;
>+data-lanes = <1 2>;
>+link-frequencies = /bits/ 64 <162000 27
>+  54 81>;
> };
> };
> };

-- 
With best wishes
Dmitry

Re: [PATCH v4 08/13] drm/msm/dp: Implement hpd_notify()




On 5 December 2022 20:44:28 GMT+03:00, Bjorn Andersson 
 wrote:
>From: Bjorn Andersson 
>
>The DisplayPort controller's hot-plug mechanism is based on pinmuxing a
>physical signal on a GPIO pin into the controller. This is not always
>possible, either because there aren't dedicated GPIOs available or
>because the hot-plug signal is a virtual notification, in cases such as
>USB Type-C.
>
>For these cases, by implementing the hpd_notify() callback for the
>DisplayPort controller's drm_bridge, a downstream drm_bridge
>(next_bridge) can be used to track and signal the connection status
>changes.
>
>This makes it possible to use downstream drm_bridges such as
>display-connector or any virtual mechanism, as long as they are
>implemented as a drm_bridge.
>
>Signed-off-by: Bjorn Andersson 
>[bjorn: Drop connector->fwnode assignment and dev from struct msm_dp]
>Signed-off-by: Bjorn Andersson 

Reviewed-by: Dmitry Baryshkov 

Minor nit: if for the next revision you reorder the patches to have hpd_enable 
first, then missing conditions, then this patch, it will look more logical.

>---
>
>Changes since v3:
>- None
>
> drivers/gpu/drm/msm/dp/dp_display.c | 22 ++
> drivers/gpu/drm/msm/dp/dp_drm.c |  1 +
> drivers/gpu/drm/msm/dp/dp_drm.h |  2 ++
> 3 files changed, 25 insertions(+)
>
>diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
>b/drivers/gpu/drm/msm/dp/dp_display.c
>index 666b45c8ab80..17fcf8cd84cd 100644
>--- a/drivers/gpu/drm/msm/dp/dp_display.c
>+++ b/drivers/gpu/drm/msm/dp/dp_display.c
>@@ -1772,3 +1772,25 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
>   dp_display->dp_mode.h_active_low =
>   !!(dp_display->dp_mode.drm_mode.flags & DRM_MODE_FLAG_NHSYNC);
> }
>+
>+void dp_bridge_hpd_notify(struct drm_bridge *bridge,
>+enum drm_connector_status status)
>+{
>+  struct msm_dp_bridge *dp_bridge = to_dp_bridge(bridge);
>+  struct msm_dp *dp_display = dp_bridge->dp_display;
>+  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->next_bridge)
>+  return;
>+
>+  if (!dp->core_initialized) {
>+  drm_dbg_dp(dp->drm_dev, "not initialized\n");
>+  return;
>+  }
>+
>+  if (!dp_display->is_connected && status == connector_status_connected)
>+  dp_add_event(dp, EV_HPD_PLUG_INT, 0, 0);
>+  else if (dp_display->is_connected && status == 
>connector_status_disconnected)
>+  dp_add_event(dp, EV_HPD_UNPLUG_INT, 0, 0);
>+}
>diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
>index 6db82f9b03af..3898366ebd5e 100644
>--- a/drivers/gpu/drm/msm/dp/dp_drm.c
>+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
>@@ -102,6 +102,7 @@ static const struct drm_bridge_funcs dp_bridge_ops = {
>   .get_modes= dp_bridge_get_modes,
>   .detect   = dp_bridge_detect,
>   .atomic_check = dp_bridge_atomic_check,
>+  .hpd_notify   = dp_bridge_hpd_notify,
> };
> 
> struct drm_bridge *dp_bridge_init(struct msm_dp *dp_display, struct 
> drm_device *dev,
>diff --git a/drivers/gpu/drm/msm/dp/dp_drm.h b/drivers/gpu/drm/msm/dp/dp_drm.h
>index 82035dbb0578..79e6b2cf2d25 100644
>--- a/drivers/gpu/drm/msm/dp/dp_drm.h
>+++ b/drivers/gpu/drm/msm/dp/dp_drm.h
>@@ -32,5 +32,7 @@ enum drm_mode_status dp_bridge_mode_valid(struct drm_bridge 
>*bridge,
> void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
>   const struct drm_display_mode *mode,
>   const struct drm_display_mode *adjusted_mode);
>+void dp_bridge_hpd_notify(struct drm_bridge *bridge,
>+enum drm_connector_status status);
> 
> #endif /* _DP_DRM_H_ */

-- 
With best wishes
Dmitry

Re: [PATCH] drm/i915/gen12: Apply recommended L3 hashing mask

2022-12-05 Thread Matt Roper

On Mon, Dec 05, 2022 at 04:33:29PM -0300, Gustavo Sousa wrote:
> On Thu, Dec 01, 2022 at 02:22:10PM -0800, Matt Roper wrote:
> > The TGL/RKL/DG1/ADL performance tuning guide suggests programming a
> > literal value of 0x2FC0100F for this register.  The register's hardware
> > default value is 0x2FC0108F, so this translates to just clearing one
> > bit.
> > 
> > Take this opportunity to also clean up the register definition and
> > re-write its existing bits/fields in the preferred notation.
> > 
> > Bspec: 31870
> > Signed-off-by: Matt Roper 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 9 +
> >  drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 
> >  2 files changed, 9 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index 61a5c9a83b1b..f8eb807b56f9 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -958,10 +958,11 @@
> >  #define   GEN7_DISABLE_SAMPLER_PREFETCH(1 << 30)
> >  
> >  #define GEN8_GARBCNTL  _MMIO(0xb004)
> > -#define   GEN9_GAPS_TSV_CREDIT_DISABLE (1 << 7)
> > -#define   GEN11_ARBITRATION_PRIO_ORDER_MASK(0x3f << 22)
> > -#define   GEN11_HASH_CTRL_EXCL_MASK(0x7f << 0)
> > -#define   GEN11_HASH_CTRL_EXCL_BIT0(1 << 0)
> > +#define   GEN11_ARBITRATION_PRIO_ORDER_MASKREG_GENMASK(27, 22)
> > +#define   GEN12_BUS_HASH_CTL_BIT_EXC   REG_BIT(7)
> > +#define   GEN9_GAPS_TSV_CREDIT_DISABLE REG_BIT(7)
> > +#define   GEN11_HASH_CTRL_EXCL_MASKREG_GENMASK(6, 0)
> > +#define   GEN11_HASH_CTRL_EXCL_BIT0
> > REG_FIELD_PREP(GEN11_HASH_CTRL_EXCL_MASK, 0x1)
> >  
> >  #define GEN9_SCRATCH_LNCF1 _MMIO(0xb008)
> >  #define   GEN9_LNCF_NONIA_COHERENT_ATOMICS_ENABLE  REG_BIT(0)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index 85822ebb0d64..2f13a92f77d3 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -2937,6 +2937,10 @@ add_render_compute_tuning_settings(struct 
> > drm_i915_private *i915,
> > if (INTEL_INFO(i915)->tuning_thread_rr_after_dep)
> > wa_mcr_masked_field_set(wal, GEN9_ROW_CHICKEN4, 
> > THREAD_EX_ARB_MODE,
> > THREAD_EX_ARB_MODE_RR_AFTER_DEP);
> > +
> > +   if (GRAPHICS_VER(i915) == 12 && GRAPHICS_VER_FULL(i915) < IP_VER(12, 
> > 50)) {
> > +   wa_write_clr(wal, GEN8_GARBCNTL, GEN12_BUS_HASH_CTL_BIT_EXC);
> > +   }
> 
> Removing the unnecessary braces as pointed out by dim checkpatch,
> 
> Reviewed-by: Gustavo Sousa 

Dropped the braces and applied to drm-intel-gt-next.  Thanks for the
review.


Matt

> 
> >  }
> >  
> >  /*
> > -- 
> > 2.38.1
> > 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation

Re: [PATCH v4 12/13] arm64: dts: qcom: sc8280xp-crd: Enable EDP




On 5 December 2022 20:44:32 GMT+03:00, Bjorn Andersson 
 wrote:
>From: Bjorn Andersson 
>
>The SC8280XP CRD has a EDP display on MDSS0 DP3, enable relevant nodes
>and link it together with the backlight control.
>
>Signed-off-by: Bjorn Andersson 
>Signed-off-by: Bjorn Andersson 
>---
>
>Changes since v3:
>- Added description of the regulator that powers the panel.
>
> arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 72 ++-
> 1 file changed, 71 insertions(+), 1 deletion(-)
>
>diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts 
>b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
>index f09810e3d956..a7d2384cbbe8 100644
>--- a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
>+++ b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
>@@ -20,7 +20,7 @@ aliases {
>   serial0 = _uart17;
>   };
> 
>-  backlight {
>+  backlight: backlight {
>   compatible = "pwm-backlight";
>   pwms = <_lpg 3 100>;
>   enable-gpios = <_1_gpios 8 GPIO_ACTIVE_HIGH>;
>@@ -34,6 +34,22 @@ chosen {
>   stdout-path = "serial0:115200n8";
>   };
> 
>+  vreg_edp_3p3: regulator-edp-3p3 {
>+  compatible = "regulator-fixed";
>+
>+  regulator-name = "VREG_EDP_3P3";
>+  regulator-min-microvolt = <330>;
>+  regulator-max-microvolt = <330>;
>+
>+  gpio = < 25 GPIO_ACTIVE_HIGH>;
>+  enable-active-high;
>+
>+  pinctrl-names = "default";
>+  pinctrl-0 = <_reg_en>;
>+
>+  regulator-boot-on;
>+  };
>+
>   vreg_edp_bl: regulator-edp-bl {
>   compatible = "regulator-fixed";
> 
>@@ -230,6 +246,54 @@ vreg_l9d: ldo9 {
>   };
> };
> 
>+ {
>+  status = "okay";
>+};
>+
>+ {
>+  status = "okay";
>+};
>+
>+_dp3 {
>+  compatible = "qcom,sc8280xp-edp";
>+  status = "okay";
>+
>+  data-lanes = <0 1 2 3>;
>+
>+  aux-bus {
>+  panel {
>+  compatible = "edp-panel";
>+  power-supply = <_edp_3p3>;
>+
>+  backlight = <>;
>+
>+  ports {
>+  port {
>+  edp_panel_in: endpoint {
>+  remote-endpoint = 
><_dp3_out>;
>+  };
>+  };
>+  };
>+  };
>+  };
>+
>+  ports {
>+  port@1 {
>+  reg = <1>;

You already have reg assignment in the SoC dtsi.

>+  mdss0_dp3_out: endpoint {
>+  remote-endpoint = <_panel_in>;
>+  };
>+  };
>+  };
>+};
>+
>+_dp3_phy {
>+  status = "okay";
>+
>+  vdda-phy-supply = <_l6b>;
>+  vdda-pll-supply = <_l3b>;
>+};
>+
>  {
>   perst-gpios = < 143 GPIO_ACTIVE_LOW>;
>   wake-gpios = < 145 GPIO_ACTIVE_LOW>;
>@@ -496,6 +560,12 @@ hastings_reg_en: hastings-reg-en-state {
>  {
>   gpio-reserved-ranges = <74 6>, <83 4>, <125 2>, <128 2>, <154 7>;
> 
>+  edp_reg_en: edp-reg-en-state {
>+  pins = "gpio25";
>+  function = "gpio";
>+  output-enable;
>+  };
>+
>   kybd_default: kybd-default-state {
>   disable-pins {
>   pins = "gpio102";

-- 
With best wishes
Dmitry

Re: [PATCH v4 09/13] drm/msm/dp: Don't enable HPD interrupts for edp




On 6 December 2022 00:07:12 GMT+03:00, Dmitry Baryshkov 
 wrote:
>
>
>On 5 December 2022 20:44:29 GMT+03:00, Bjorn Andersson 
> wrote:
>>From: Bjorn Andersson 
>>
>>Most instances where HPD interrupts are masked and unmasked are guareded
>>by the presence of an EDP panel being connected, but not all. Extend
>>this to cover the last few places, as HPD interrupt handling is not used
>>for the EDP case.
>
>I don't remember whether I asked that or not. Would it be possible to move hpd 
>irq enablement to bridge's hpd_enable() / hpd_disable() callbacks ? I think 
>this would allow us to drop the is_edp checks.

Ignore this. I should read the series carefully.

>
>>
>>Signed-off-by: Bjorn Andersson 
>>Reviewed-by: Dmitry Baryshkov 
>>Signed-off-by: Bjorn Andersson 
>>---
>>
>>Changes since v3:
>>- None
>>
>> drivers/gpu/drm/msm/dp/dp_display.c | 15 ++-
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
>>b/drivers/gpu/drm/msm/dp/dp_display.c
>>index 17fcf8cd84cd..bb92c33beff8 100644
>>--- a/drivers/gpu/drm/msm/dp/dp_display.c
>>+++ b/drivers/gpu/drm/msm/dp/dp_display.c
>>@@ -610,8 +610,10 @@ static int dp_hpd_plug_handle(struct dp_display_private 
>>*dp, u32 data)
>>  }
>> 
>>  /* enable HDP irq_hpd/replug interrupt */
>>- dp_catalog_hpd_config_intr(dp->catalog,
>>- DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, true);
>>+ if (!dp->dp_display.is_edp)
>>+ dp_catalog_hpd_config_intr(dp->catalog,
>>+DP_DP_IRQ_HPD_INT_MASK | 
>>DP_DP_HPD_REPLUG_INT_MASK,
>>+true);
>> 
>>  drm_dbg_dp(dp->drm_dev, "After, type=%d hpd_state=%d\n",
>>  dp->dp_display.connector_type, state);
>>@@ -651,8 +653,10 @@ static int dp_hpd_unplug_handle(struct 
>>dp_display_private *dp, u32 data)
>>  dp->dp_display.connector_type, state);
>> 
>>  /* disable irq_hpd/replug interrupts */
>>- dp_catalog_hpd_config_intr(dp->catalog,
>>- DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, false);
>>+ if (!dp->dp_display.is_edp)
>>+ dp_catalog_hpd_config_intr(dp->catalog,
>>+DP_DP_IRQ_HPD_INT_MASK | 
>>DP_DP_HPD_REPLUG_INT_MASK,
>>+false);
>> 
>>  /* unplugged, no more irq_hpd handle */
>>  dp_del_event(dp, EV_IRQ_HPD_INT);
>>@@ -678,7 +682,8 @@ static int dp_hpd_unplug_handle(struct dp_display_private 
>>*dp, u32 data)
>>  }
>> 
>>  /* disable HPD plug interrupts */
>>- dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, false);
>>+ if (!dp->dp_display.is_edp)
>>+ dp_catalog_hpd_config_intr(dp->catalog, 
>>DP_DP_HPD_PLUG_INT_MASK, false);
>> 
>>  /*
>>   * We don't need separate work for disconnect as
>

-- 
With best wishes
Dmitry

Re: [PATCH v4 10/13] drm/msm/dp: Rely on hpd_enable/disable callbacks




On 5 December 2022 20:44:30 GMT+03:00, Bjorn Andersson 
 wrote:
>From: Bjorn Andersson 
>
>The DisplayPort controller's internal HPD interrupt handling is used for
>cases where the HPD signal is connected to a GPIO which is pinmuxed into
>the DisplayPort controller. In other configurations the HPD notification
>might be delivered by the DRM framework from an associated bridge.
>
>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.
>
>This ensures appropriate handling of the three cases; no bridge
>connected, a bridge without DRM_BRIDGE_OP_HPD and a bridge with
>DRM_BRIDGE_OP_HPD.
>
>Signed-off-by: Bjorn Andersson 
>Signed-off-by: Bjorn Andersson 
>---
>
>Worth mentioning, I did look into moving the HPD enablement/disablement
>completely into these new callbacks, but that affect the entire power
>management model of the driver, so I think it's worth to tackle that in
>subsequent changes. It seems also reasonable to expect that we by such
>modifications could leave the block unclocked until the external HPD
>notification arrives...

I see... I still suppose this is the way to go in the long term.

For now:

Reviewed-by: Dmitry Baryshkov 

>
>Changes since v3:
>- Introduced reliance on hpd_enable/disable callbacks instead of next_bridge
>
> drivers/gpu/drm/msm/dp/dp_display.c | 35 -
> drivers/gpu/drm/msm/dp/dp_display.h |  1 +
> drivers/gpu/drm/msm/dp/dp_drm.c |  2 ++
> drivers/gpu/drm/msm/dp/dp_drm.h |  2 ++
> 4 files changed, 30 insertions(+), 10 deletions(-)
>
>diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
>b/drivers/gpu/drm/msm/dp/dp_display.c
>index bb92c33beff8..3e464c33ff11 100644
>--- a/drivers/gpu/drm/msm/dp/dp_display.c
>+++ b/drivers/gpu/drm/msm/dp/dp_display.c
>@@ -610,7 +610,7 @@ static int dp_hpd_plug_handle(struct dp_display_private 
>*dp, u32 data)
>   }
> 
>   /* enable HDP irq_hpd/replug interrupt */
>-  if (!dp->dp_display.is_edp)
>+  if (dp->dp_display.internal_hpd)
>   dp_catalog_hpd_config_intr(dp->catalog,
>  DP_DP_IRQ_HPD_INT_MASK | 
> DP_DP_HPD_REPLUG_INT_MASK,
>  true);
>@@ -653,7 +653,7 @@ static int dp_hpd_unplug_handle(struct dp_display_private 
>*dp, u32 data)
>   dp->dp_display.connector_type, state);
> 
>   /* disable irq_hpd/replug interrupts */
>-  if (!dp->dp_display.is_edp)
>+  if (dp->dp_display.internal_hpd)
>   dp_catalog_hpd_config_intr(dp->catalog,
>  DP_DP_IRQ_HPD_INT_MASK | 
> DP_DP_HPD_REPLUG_INT_MASK,
>  false);
>@@ -682,7 +682,7 @@ static int dp_hpd_unplug_handle(struct dp_display_private 
>*dp, u32 data)
>   }
> 
>   /* disable HPD plug interrupts */
>-  if (!dp->dp_display.is_edp)
>+  if (dp->dp_display.internal_hpd)
>   dp_catalog_hpd_config_intr(dp->catalog, 
> DP_DP_HPD_PLUG_INT_MASK, false);
> 
>   /*
>@@ -701,7 +701,7 @@ static int dp_hpd_unplug_handle(struct dp_display_private 
>*dp, u32 data)
>   dp_display_handle_plugged_change(>dp_display, false);
> 
>   /* enable HDP plug interrupt to prepare for next plugin */
>-  if (!dp->dp_display.is_edp)
>+  if (dp->dp_display.internal_hpd)
>   dp_catalog_hpd_config_intr(dp->catalog, 
> DP_DP_HPD_PLUG_INT_MASK, true);
> 
>   drm_dbg_dp(dp->drm_dev, "After, type=%d hpd_state=%d\n",
>@@ -1086,8 +1086,8 @@ 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 for external DisplayPort */
>-  if (!dp->dp_display.is_edp)
>+  /* 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,
>@@ -1379,8 +1379,7 @@ static int dp_pm_resume(struct device *dev)
> 
>   dp_catalog_ctrl_hpd_config(dp->catalog);
> 
>-
>-  if (!dp->dp_display.is_edp)
>+  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,
>@@ -1778,6 +1777,22 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
>   !!(dp_display->dp_mode.drm_mode.flags & DRM_MODE_FLAG_NHSYNC);
> }
> 
>+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;
>+
>+  dp_display->internal_hpd =

Re: [PATCH v4 01/13] dt-bindings: display/msm: Add binding for SC8280XP MDSS



On Mon, 05 Dec 2022 09:44:21 -0800, Bjorn Andersson wrote:
> From: Bjorn Andersson 
> 
> Add binding for the display subsystem and display processing unit in the
> Qualcomm SC8280XP platform.
> 
> Signed-off-by: Bjorn Andersson 
> Signed-off-by: Bjorn Andersson 
> ---
> 
> Changes since v3:
> - Reworked on top of redesigned common yaml.
> 
>  .../display/msm/qcom,sc8280xp-dpu.yaml| 122 +++
>  .../display/msm/qcom,sc8280xp-mdss.yaml   | 143 ++
>  2 files changed, 265 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-dpu.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml
> 

Reviewed-by: Rob Herring

Re: [PATCH v3 02/11] dt-bindings: display: msm: Add qcom, sm8350-mdss binding



On Mon, 05 Dec 2022 17:37:45 +0100, Robert Foss wrote:
> Mobile Display Subsystem (MDSS) encapsulates sub-blocks
> like DPU display controller, DSI etc. Add YAML schema for MDSS device
> tree bindings
> 
> Signed-off-by: Robert Foss 
> ---
>  .../display/msm/qcom,sm8350-mdss.yaml | 221 ++
>  1 file changed, 221 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml
> 

Reviewed-by: Rob Herring

Re: [PATCH v4 09/13] drm/msm/dp: Don't enable HPD interrupts for edp




On 5 December 2022 20:44:29 GMT+03:00, Bjorn Andersson 
 wrote:
>From: Bjorn Andersson 
>
>Most instances where HPD interrupts are masked and unmasked are guareded
>by the presence of an EDP panel being connected, but not all. Extend
>this to cover the last few places, as HPD interrupt handling is not used
>for the EDP case.

I don't remember whether I asked that or not. Would it be possible to move hpd 
irq enablement to bridge's hpd_enable() / hpd_disable() callbacks ? I think 
this would allow us to drop the is_edp checks.

>
>Signed-off-by: Bjorn Andersson 
>Reviewed-by: Dmitry Baryshkov 
>Signed-off-by: Bjorn Andersson 
>---
>
>Changes since v3:
>- None
>
> drivers/gpu/drm/msm/dp/dp_display.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
>b/drivers/gpu/drm/msm/dp/dp_display.c
>index 17fcf8cd84cd..bb92c33beff8 100644
>--- a/drivers/gpu/drm/msm/dp/dp_display.c
>+++ b/drivers/gpu/drm/msm/dp/dp_display.c
>@@ -610,8 +610,10 @@ static int dp_hpd_plug_handle(struct dp_display_private 
>*dp, u32 data)
>   }
> 
>   /* enable HDP irq_hpd/replug interrupt */
>-  dp_catalog_hpd_config_intr(dp->catalog,
>-  DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, true);
>+  if (!dp->dp_display.is_edp)
>+  dp_catalog_hpd_config_intr(dp->catalog,
>+ DP_DP_IRQ_HPD_INT_MASK | 
>DP_DP_HPD_REPLUG_INT_MASK,
>+ true);
> 
>   drm_dbg_dp(dp->drm_dev, "After, type=%d hpd_state=%d\n",
>   dp->dp_display.connector_type, state);
>@@ -651,8 +653,10 @@ static int dp_hpd_unplug_handle(struct dp_display_private 
>*dp, u32 data)
>   dp->dp_display.connector_type, state);
> 
>   /* disable irq_hpd/replug interrupts */
>-  dp_catalog_hpd_config_intr(dp->catalog,
>-  DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, false);
>+  if (!dp->dp_display.is_edp)
>+  dp_catalog_hpd_config_intr(dp->catalog,
>+ DP_DP_IRQ_HPD_INT_MASK | 
>DP_DP_HPD_REPLUG_INT_MASK,
>+ false);
> 
>   /* unplugged, no more irq_hpd handle */
>   dp_del_event(dp, EV_IRQ_HPD_INT);
>@@ -678,7 +682,8 @@ static int dp_hpd_unplug_handle(struct dp_display_private 
>*dp, u32 data)
>   }
> 
>   /* disable HPD plug interrupts */
>-  dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, false);
>+  if (!dp->dp_display.is_edp)
>+  dp_catalog_hpd_config_intr(dp->catalog, 
>DP_DP_HPD_PLUG_INT_MASK, false);
> 
>   /*
>* We don't need separate work for disconnect as

-- 
With best wishes
Dmitry

Re: [PATCH v8 2/5] dt-bindings: msm/dp: add data-lanes and link-frequencies property

On Mon, 05 Dec 2022 11:14:27 -0800, Kuogee Hsieh wrote:
> Add both data-lanes and link-frequencies property into endpoint
> 
> Changes in v7:
> -- split yaml out of dtsi patch
> -- link-frequencies from link rate to symbol rate
> -- deprecation of old data-lanes property
> 
> Changes in v8:
> -- correct Bjorn mail address to kernel.org
> 
> Signed-off-by: Kuogee Hsieh 
> ---
>  .../bindings/display/msm/dp-controller.yaml| 22 
> --
>  1 file changed, 16 insertions(+), 6 deletions(-)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
 properties:ports:properties:port@1:properties: 'properties' should not be 
valid under {'$ref': '#/definitions/json-schema-prop-names'}
hint: A json-schema keyword was found instead of a DT property name.
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
 properties:ports:properties:port@1:properties: 'additionalProperties' should 
not be valid under {'$ref': '#/definitions/json-schema-prop-names'}
hint: A json-schema keyword was found instead of a DT property name.
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
 properties:ports:properties:port@1:properties:properties: 'anyOf' conditional 
failed, one must be fixed:
'data-lanes' is not one of ['$ref', 'additionalItems', 
'additionalProperties', 'allOf', 'anyOf', 'const', 'contains', 'default', 
'dependencies', 'dependentRequired', 'dependentSchemas', 'deprecated', 
'description', 'else', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'items', 
'if', 'minItems', 'minimum', 'maxItems', 'maximum', 'multipleOf', 'not', 
'oneOf', 'pattern', 'patternProperties', 'properties', 'required', 'then', 
'typeSize', 'unevaluatedProperties', 'uniqueItems']
'type' was expected
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
 properties:ports:properties:port@1:properties:properties: 'anyOf' conditional 
failed, one must be fixed:
'link-frequencies' is not one of ['$ref', 'additionalItems', 
'additionalProperties', 'allOf', 'anyOf', 'const', 'contains', 'default', 
'dependencies', 'dependentRequired', 'dependentSchemas', 'deprecated', 
'description', 'else', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'items', 
'if', 'minItems', 'minimum', 'maxItems', 'maximum', 'multipleOf', 'not', 
'oneOf', 'pattern', 'patternProperties', 'properties', 'required', 'then', 
'typeSize', 'unevaluatedProperties', 'uniqueItems']
'type' was expected
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dp-controller.example.dtb:
 displayport-controller@ae9: ports:port@1:endpoint: Unevaluated properties 
are not allowed ('data-lanes', 'link-frequencies' were unexpected)
From schema: 
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dp-controller.yaml

doc reference errors (make refcheckdocs):

See 
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/1670267670-15832-3-git-send-email-quic_khs...@quicinc.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

Re: [PATCH v4 08/13] drm/msm/dp: Implement hpd_notify()




On 5 December 2022 20:44:28 GMT+03:00, Bjorn Andersson 
 wrote:
>From: Bjorn Andersson 
>
>The DisplayPort controller's hot-plug mechanism is based on pinmuxing a
>physical signal on a GPIO pin into the controller. This is not always
>possible, either because there aren't dedicated GPIOs available or
>because the hot-plug signal is a virtual notification, in cases such as
>USB Type-C.
>
>For these cases, by implementing the hpd_notify() callback for the
>DisplayPort controller's drm_bridge, a downstream drm_bridge
>(next_bridge) can be used to track and signal the connection status
>changes.
>
>This makes it possible to use downstream drm_bridges such as
>display-connector or any virtual mechanism, as long as they are
>implemented as a drm_bridge.
>
>Signed-off-by: Bjorn Andersson 
>[bjorn: Drop connector->fwnode assignment and dev from struct msm_dp]
>Signed-off-by: Bjorn Andersson 
>---
>
>Changes since v3:
>- None
>
> drivers/gpu/drm/msm/dp/dp_display.c | 22 ++
> drivers/gpu/drm/msm/dp/dp_drm.c |  1 +
> drivers/gpu/drm/msm/dp/dp_drm.h |  2 ++
> 3 files changed, 25 insertions(+)
>
>diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
>b/drivers/gpu/drm/msm/dp/dp_display.c
>index 666b45c8ab80..17fcf8cd84cd 100644
>--- a/drivers/gpu/drm/msm/dp/dp_display.c
>+++ b/drivers/gpu/drm/msm/dp/dp_display.c
>@@ -1772,3 +1772,25 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
>   dp_display->dp_mode.h_active_low =
>   !!(dp_display->dp_mode.drm_mode.flags & DRM_MODE_FLAG_NHSYNC);
> }
>+
>+void dp_bridge_hpd_notify(struct drm_bridge *bridge,
>+enum drm_connector_status status)
>+{
>+  struct msm_dp_bridge *dp_bridge = to_dp_bridge(bridge);
>+  struct msm_dp *dp_display = dp_bridge->dp_display;
>+  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->next_bridge)
>+  return;

Can we use hpd_notify in all the cases by dropping the corresponding piece of 
code from the core driver? 


>+
>+  if (!dp->core_initialized) {
>+  drm_dbg_dp(dp->drm_dev, "not initialized\n");
>+  return;
>+  }
>+
>+  if (!dp_display->is_connected && status == connector_status_connected)
>+  dp_add_event(dp, EV_HPD_PLUG_INT, 0, 0);
>+  else if (dp_display->is_connected && status == 
>connector_status_disconnected)
>+  dp_add_event(dp, EV_HPD_UNPLUG_INT, 0, 0);
>+}
>diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
>index 6db82f9b03af..3898366ebd5e 100644
>--- a/drivers/gpu/drm/msm/dp/dp_drm.c
>+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
>@@ -102,6 +102,7 @@ static const struct drm_bridge_funcs dp_bridge_ops = {
>   .get_modes= dp_bridge_get_modes,
>   .detect   = dp_bridge_detect,
>   .atomic_check = dp_bridge_atomic_check,
>+  .hpd_notify   = dp_bridge_hpd_notify,
> };
> 
> struct drm_bridge *dp_bridge_init(struct msm_dp *dp_display, struct 
> drm_device *dev,
>diff --git a/drivers/gpu/drm/msm/dp/dp_drm.h b/drivers/gpu/drm/msm/dp/dp_drm.h
>index 82035dbb0578..79e6b2cf2d25 100644
>--- a/drivers/gpu/drm/msm/dp/dp_drm.h
>+++ b/drivers/gpu/drm/msm/dp/dp_drm.h
>@@ -32,5 +32,7 @@ enum drm_mode_status dp_bridge_mode_valid(struct drm_bridge 
>*bridge,
> void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
>   const struct drm_display_mode *mode,
>   const struct drm_display_mode *adjusted_mode);
>+void dp_bridge_hpd_notify(struct drm_bridge *bridge,
>+enum drm_connector_status status);
> 
> #endif /* _DP_DRM_H_ */

-- 
With best wishes
Dmitry

Re: [PATCH v4 03/13] drm/msm: Introduce SC8280XP MDSS




On 5 December 2022 20:44:23 GMT+03:00, Bjorn Andersson 
 wrote:
>From: Bjorn Andersson 
>
>Add compatible for the SC8280XP Mobile Display Subsystem and
>initialization for version 8.0.0.
>
>Signed-off-by: Bjorn Andersson 
>Signed-off-by: Bjorn Andersson 


Reviewed-by: Dmitry Baryshkov 

>---

-- 
With best wishes
Dmitry

Re: [PATCH v8 5/5] drm/msm/dp: add support of max dp link rate




On 5 December 2022 22:14:30 GMT+03:00, Kuogee Hsieh  
wrote:
>By default, HBR2 (5.4G) is the max link link be supported. This patch add
>the capability to support max link rate at HBR3 (8.1G).

This patch uses the actual limit specified by DT and removes the artificial 
limitation to 5.4 Gbps. Supporting HBR3 is a consequence of that.


>
>Changes in v2:
>-- add max link rate from dtsi
>
>Changes in v3:
>-- parser max_data_lanes and max_dp_link_rate from dp_out endpoint
>
>Changes in v4:
>-- delete unnecessary pr_err
>
>Changes in v5:
>-- split parser function into different patch
>
>Signed-off-by: Kuogee Hsieh 
>Reviewed-by: Dmitry Baryshkov 
>---
> drivers/gpu/drm/msm/dp/dp_display.c | 4 
> drivers/gpu/drm/msm/dp/dp_panel.c   | 7 ---
> drivers/gpu/drm/msm/dp/dp_panel.h   | 1 +
> 3 files changed, 9 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
>b/drivers/gpu/drm/msm/dp/dp_display.c
>index bfd0aef..edee550 100644
>--- a/drivers/gpu/drm/msm/dp/dp_display.c
>+++ b/drivers/gpu/drm/msm/dp/dp_display.c
>@@ -390,6 +390,10 @@ static int dp_display_process_hpd_high(struct 
>dp_display_private *dp)
>   struct edid *edid;
> 
>   dp->panel->max_dp_lanes = dp->parser->max_dp_lanes;
>+  dp->panel->max_dp_link_rate = dp->parser->max_dp_link_rate;
>+
>+  drm_dbg_dp(dp->drm_dev, "max_lanes=%d max_link_rate=%d\n",
>+  dp->panel->max_dp_lanes, dp->panel->max_dp_link_rate);
> 
>   rc = dp_panel_read_sink_caps(dp->panel, dp->dp_display.connector);
>   if (rc)
>diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c 
>b/drivers/gpu/drm/msm/dp/dp_panel.c
>index 5149ceb..933fa9c 100644
>--- a/drivers/gpu/drm/msm/dp/dp_panel.c
>+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
>@@ -75,12 +75,13 @@ static int dp_panel_read_dpcd(struct dp_panel *dp_panel)
>   link_info->rate = drm_dp_bw_code_to_link_rate(dpcd[DP_MAX_LINK_RATE]);
>   link_info->num_lanes = dpcd[DP_MAX_LANE_COUNT] & DP_MAX_LANE_COUNT_MASK;
> 
>+  /* Limit data lanes from data-lanes of endpoint properity of dtsi */
>   if (link_info->num_lanes > dp_panel->max_dp_lanes)
>   link_info->num_lanes = dp_panel->max_dp_lanes;
> 
>-  /* Limit support upto HBR2 until HBR3 support is added */
>-  if (link_info->rate >= (drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4)))
>-  link_info->rate = drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4);
>+  /* Limit link rate from link-frequencies of endpoint properity of dtsi 
>*/
>+  if (link_info->rate > dp_panel->max_dp_link_rate)
>+  link_info->rate = dp_panel->max_dp_link_rate;
> 
>   drm_dbg_dp(panel->drm_dev, "version: %d.%d\n", major, minor);
>   drm_dbg_dp(panel->drm_dev, "link_rate=%d\n", link_info->rate);
>diff --git a/drivers/gpu/drm/msm/dp/dp_panel.h 
>b/drivers/gpu/drm/msm/dp/dp_panel.h
>index d861197a..f04d021 100644
>--- a/drivers/gpu/drm/msm/dp/dp_panel.h
>+++ b/drivers/gpu/drm/msm/dp/dp_panel.h
>@@ -50,6 +50,7 @@ struct dp_panel {
> 
>   u32 vic;
>   u32 max_dp_lanes;
>+  u32 max_dp_link_rate;
> 
>   u32 max_bw_code;
> };

-- 
With best wishes
Dmitry

Re: [PATCH v8 4/5] drm/msm/dp: parser link-frequencies as property of dp_out endpoint




On 5 December 2022 22:14:29 GMT+03:00, Kuogee Hsieh  
wrote:
>Add capability to parser and retrieve max DP link supported rate from
>link-frequencies property of dp_out endpoint.
>
>Changes in v6:
>-- second patch after split parser patch into two patches
>
>Changes in v7:
>-- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate
>
>Signed-off-by: Kuogee Hsieh 
>---
> drivers/gpu/drm/msm/dp/dp_parser.c | 19 +--
> drivers/gpu/drm/msm/dp/dp_parser.h |  2 ++
> 2 files changed, 19 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c 
>b/drivers/gpu/drm/msm/dp/dp_parser.c
>index b5f7e70..037dad8 100644
>--- a/drivers/gpu/drm/msm/dp/dp_parser.c
>+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
>@@ -94,15 +94,28 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
> static int dp_parser_misc(struct dp_parser *parser)
> {
>   struct device_node *of_node = parser->pdev->dev.of_node;
>+  struct device_node *endpoint;
>+  u64 frequency;
>   int cnt;
> 
>   /*
>* data-lanes is the property of dp_out endpoint
>*/
>   cnt = drm_of_get_data_lanes_count_ep(of_node, 1, 0, 1, 
> DP_MAX_NUM_DP_LANES);
>-  if (cnt > 0)
>+  if (cnt > 0) {
>   parser->max_dp_lanes = cnt;
>-  else {
>+
>+  endpoint = of_graph_get_endpoint_by_regs(of_node, 1, 0); /* 
>port@1 */
>+  cnt = of_property_count_u64_elems(endpoint, "link-frequencies");

Missing of_node_put()

>+  if (cnt > 0) {
>+  of_property_read_u64_index(endpoint, "link-frequencies",
>+  cnt - 1, );
>+  frequency /= 10;/* from symbol rate to link 
>rate */
>+  parser->max_dp_link_rate = (frequency / 1000); /* kbits 
>*/
>+  } else {
>+  parser->max_dp_link_rate = DP_LINK_RATE_HBR2; /* 54 
>khz */
>+  }
>+  } else {
>   /*
>* legacy code, data-lanes is the property of mdss_dp node
>*/
>@@ -111,6 +124,8 @@ static int dp_parser_misc(struct dp_parser *parser)
>   parser->max_dp_lanes = cnt;
>   else
>   parser->max_dp_lanes = DP_MAX_NUM_DP_LANES; /* 4 lanes 
> */
>+
>+  parser->max_dp_link_rate = DP_LINK_RATE_HBR2; /* 54 khz */

Please, don't mix the dp lanes and dp link rate code. It would be much easier 
to read. And you can remove the duplicate assignment statements too.

>   }
> 
>   return 0;
>diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h 
>b/drivers/gpu/drm/msm/dp/dp_parser.h
>index 866c1a8..3ddf639 100644
>--- a/drivers/gpu/drm/msm/dp/dp_parser.h
>+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
>@@ -15,6 +15,7 @@
> #define DP_LABEL "MDSS DP DISPLAY"
> #define DP_MAX_PIXEL_CLK_KHZ  675000
> #define DP_MAX_NUM_DP_LANES   4
>+#define DP_LINK_RATE_HBR2   54
> 
> enum dp_pm_type {
>   DP_CORE_PM,
>@@ -119,6 +120,7 @@ struct dp_parser {
>   struct dp_io io;
>   struct dp_display_data disp_data;
>   u32 max_dp_lanes;
>+  u32 max_dp_link_rate;
>   struct drm_bridge *next_bridge;
> 
>   int (*parse)(struct dp_parser *parser);

-- 
With best wishes
Dmitry

Re: [PATCH v8 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

2022-12-05 Thread Teres Alexis, Alan Previn



On Mon, 2022-12-05 at 11:53 -0800, Ceraolo Spurio, Daniele wrote:
> 
Alan:[snip]
> >   
> > ext_data->flags |= I915_BO_PROTECTED;
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 29e9e8d5b6fe..ed74d173a092 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -869,7 +869,7 @@ static struct i915_vma *eb_lookup_vma(struct 
> > i915_execbuffer *eb, u32 handle)
> >  */
> > if (i915_gem_context_uses_protected_content(eb->gem_context) &&
> > i915_gem_object_is_protected(obj)) {
> > -   err = intel_pxp_key_check(>gt->pxp, obj, true);
> > +   err = intel_pxp_key_check(vm->gt->i915->pxp, obj, true);
> 
> nit: eb->i915->pxp is one less pointer jump
> 
Alan: okay
Alan:[snip]
> 

> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c 
> > b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > index dd53641f3637..7876f4c3d0f1 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > @@ -99,7 +99,6 @@ void intel_gt_debugfs_register(struct intel_gt *gt)
> > intel_sseu_debugfs_register(gt, root);
> >   
> > intel_uc_debugfs_register(>uc, root);
> > -   intel_pxp_debugfs_register(>pxp, root);
> 
> Nit: the pxp header inclusion can now be removed from this file.
> 
Alan: okay - will fix.
Alan:[snip]

> 
> > +
> > +bool intel_pxp_is_supported(const struct intel_pxp *pxp)
> > +{
> > +   return (IS_ENABLED(CONFIG_DRM_I915_PXP) && pxp->ctrl_gt &&
> > +   INTEL_INFO(pxp->ctrl_gt->i915)->has_pxp && 
> > VDBOX_MASK(pxp->ctrl_gt));
> >   }
> >   
> >   bool intel_pxp_is_enabled(const struct intel_pxp *pxp)
> > @@ -130,7 +142,7 @@ static void pxp_init_full(struct intel_pxp *pxp)
> > if (ret)
> > goto out_context;
> >   
> > -   drm_info(>i915->drm, "Protected Xe Path (PXP) protected content 
> > support initialized\n");
> > +   drm_info(>i915->drm, "Protected Xe Path v7B (PXP) protected content 
> > support initialized\n");
> 
> This looks like a leftover debug addition
> 
Alan: ooops - yeah this was not supposed to be part of the change - my mistake.
Alan:[snip]

> > -void intel_pxp_init(struct intel_pxp *pxp)
> > +static struct intel_gt *pxp_get_ctrl_gt(struct drm_i915_private *i915)
> >   {
> > -   struct intel_gt *gt = pxp_to_gt(pxp);
> > +   struct intel_gt *gt = NULL;
> > +   int i = 0;
> > +
> > +   for_each_gt(gt, i915, i) {
> > +   /* There can be only one GT that supports PXP */
> > +   if (HAS_ENGINE(gt, GSC0))
> > +   return gt;
> > +   }
> 
> Note that the GSC engine will be disabled if the GSC FW is not 
> available, so in that case falling back to the root GT will be an error. 
> Maybe just change the below check to be:
> 
> /*
>   * The GSC engine can be turned off, but on platform that
>   * can have it we don't want to fall back to root GT.
>   * On older platforms we rely instead on the mei PXP module.
>   */
> if (IS_ENABLED(CONFIG_INTEL_MEI_PXP) && !915->media_gt)
> 
Alan: okay - makes sense. will do.
Alan:[snip]

> 
> >   
> > /* we rely on the mei PXP module */
> > -   if (!IS_ENABLED(CONFIG_INTEL_MEI_PXP))
> > -   return;
> > +   if (IS_ENABLED(CONFIG_INTEL_MEI_PXP))
> > +   return >gt0;
> > +
> > +   return NULL;
> > +}
> > +
> > +int intel_pxp_init(struct drm_i915_private *i915)
> > +{
> > +   i915->pxp = kzalloc(sizeof(*i915->pxp), GFP_KERNEL);
> > +   if (!i915->pxp)
> > +   return -ENOMEM;
> 
> A failure in intel_pxp_init is non-fatal, so we can exit here without 
> allocating i915->pxp and still complete driver load (although it's very 
> unlikely). This means that functions that can be called from outside the 
> PXP subsystem need to check if the pxp structure is allocated.
> 

Alan: Okay - this is a good catch - but in that case of kernel memory 
allocation failure, would it make sense to fail
the driver load instead? (considering its obviously a more serious system wide 
issue?).

> > +
> > +   i915->pxp->ctrl_gt = pxp_get_ctrl_gt(i915);
> > +   if (!i915->pxp->ctrl_gt)
> > +   return -ENODEV;
> 
> I would do a kfree here, so the only pointer that needs to be checked is 
> i915->pxp (i.e., guarantee that if i915->pxp is valid then 
> i915->pxp->ctrl_gt is also valid), otherwise pxp_to_gt could return NULL 
> when passing in a valid PXP pointer; although I think that all the calls 
> to pxp_to_gt are guarded via a pxp_is_enabled/supported check, it's not 
> intuitive for that function to return NULL (all other callers of that 
> type that we have do always return a valid pointer).
> 
Alan: okay sure - I guess this would also align well with a future where more 
and more subsystem structures are
allocated (as we try to reduce i915 build times by controlling the 
header-include-hierarchy) and therefore a null
subsystem

Re: [PATCH v8 1/5] arm64: dts: qcom: add data-lanes and link-freuencies into dp_out endpoint




On 5 December 2022 22:14:26 GMT+03:00, Kuogee Hsieh  
wrote:
>Move data-lanes property from mdss_dp node to dp_out endpoint. Also
>add link-frequencies property into dp_out endpoint as well. The last
>frequency specified at link-frequencies will be the max link rate
>supported by DP.
>
>Changes in v5:
>-- revert changes at sc7180.dtsi and sc7280.dtsi
>-- add _out to sc7180-trogdor.dtsi and sc7280-herobrine.dtsi
>
>Changes in v6:
>-- add data-lanes and link-frequencies to yaml
>
>Changes in v7:
>-- change 16000 to 162000
>-- separate yaml to different patch
>
>Changes in v8:
>-- correct Bjorn mail address to kernel.org
>
>Signed-off-by: Kuogee Hsieh 
>---
> arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi   | 6 +-
> arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 +-
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
>diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi 
>b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
>index eae22e6..0ad50e2 100644
>--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
>+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
>@@ -814,7 +814,11 @@ hp_i2c:  {
>   status = "okay";
>   pinctrl-names = "default";
>   pinctrl-0 = <_hot_plug_det>;
>-  data-lanes = <0 1>;
>+};
>+
>+_out {
>+data-lanes = <0  1>;
>+link-frequencies = /bits/ 64 <16200 27000 54000>;

This property still uses old values, it was not updated to Hz.

> };
> 
> _adc {
>diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi 
>b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
>index c11e371..3c7a9d8 100644
>--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
>+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
>@@ -442,7 +442,11 @@ ap_i2c_tpm:  {
>   status = "okay";
>   pinctrl-names = "default";
>   pinctrl-0 = <_hot_plug_det>;
>-  data-lanes = <0 1>;
>+};
>+
>+_out {
>+  data-lanes = <0  1>;
>+  link-frequencies = /bits/ 64 <162000 27 54 
>81>;
> };
> 
> _mdp {

-- 
With best wishes
Dmitry

Re: [PATCH v2 01/11] pwm: Make .get_state() callback return an error code

2022-12-05 Thread Jernej Škrabec

Dne sreda, 30. november 2022 ob 16:21:38 CET je Uwe Kleine-König napisal(a):
> .get_state() might fail in some cases. To make it possible that a driver
> signals such a failure change the prototype of .get_state() to return an
> error code.
> 
> This patch was created using coccinelle and the following semantic patch:
> 
> @p1@
> identifier getstatefunc;
> identifier driver;
> @@
>  struct pwm_ops driver = {
> ...,
> .get_state = getstatefunc
> ,...
>  };
> 
> @p2@
> identifier p1.getstatefunc;
> identifier chip, pwm, state;
> @@
> -void
> +int
>  getstatefunc(struct pwm_chip *chip, struct pwm_device *pwm, struct
> pwm_state *state) {
>...
> -  return;
> +  return 0;
>...
>  }
> 
> plus the actual change of the prototype in include/linux/pwm.h (plus some
> manual fixing of indentions and empty lines).
> 
> So for now all drivers return success unconditionally. They are adapted
> in the following patches to make the changes easier reviewable.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  drivers/gpio/gpio-mvebu.c |  9 ++---
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 14 --
>  drivers/leds/rgb/leds-qcom-lpg.c  | 14 --
>  drivers/pwm/pwm-atmel.c   |  6 --
>  drivers/pwm/pwm-bcm-iproc.c   |  8 +---
>  drivers/pwm/pwm-crc.c | 10 ++
>  drivers/pwm/pwm-cros-ec.c |  8 +---
>  drivers/pwm/pwm-dwc.c |  6 --
>  drivers/pwm/pwm-hibvt.c   |  6 --
>  drivers/pwm/pwm-imx-tpm.c |  8 +---
>  drivers/pwm/pwm-imx27.c   |  8 +---
>  drivers/pwm/pwm-intel-lgm.c   |  6 --
>  drivers/pwm/pwm-iqs620a.c |  6 --
>  drivers/pwm/pwm-keembay.c |  6 --
>  drivers/pwm/pwm-lpss.c|  6 --
>  drivers/pwm/pwm-meson.c   |  8 +---
>  drivers/pwm/pwm-mtk-disp.c| 12 +++-
>  drivers/pwm/pwm-pca9685.c |  8 +---
>  drivers/pwm/pwm-raspberrypi-poe.c |  8 +---
>  drivers/pwm/pwm-rockchip.c| 12 +++-
>  drivers/pwm/pwm-sifive.c  |  6 --
>  drivers/pwm/pwm-sl28cpld.c|  8 +---
>  drivers/pwm/pwm-sprd.c|  8 +---
>  drivers/pwm/pwm-stm32-lp.c|  8 +---
>  drivers/pwm/pwm-sun4i.c   | 12 +++-
>  drivers/pwm/pwm-sunplus.c |  6 --
>  drivers/pwm/pwm-visconti.c|  6 --
>  drivers/pwm/pwm-xilinx.c  |  8 +---
>  include/linux/pwm.h   |  4 ++--
>  29 files changed, 146 insertions(+), 89 deletions(-)
> 

> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index c8445b0a3339..37d75e252d4e 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -108,9 +108,9 @@ static inline void sun4i_pwm_writel(struct
> sun4i_pwm_chip *chip, writel(val, chip->base + offset);
>  }
> 
> -static void sun4i_pwm_get_state(struct pwm_chip *chip,
> - struct pwm_device *pwm,
> - struct pwm_state *state)
> +static int sun4i_pwm_get_state(struct pwm_chip *chip,
> +struct pwm_device *pwm,
> +struct pwm_state *state)
>  {
>   struct sun4i_pwm_chip *sun4i_pwm = to_sun4i_pwm_chip(chip);
>   u64 clk_rate, tmp;
> @@ -132,7 +132,7 @@ static void sun4i_pwm_get_state(struct pwm_chip *chip,
>   state->duty_cycle = DIV_ROUND_UP_ULL(state->period, 2);
>   state->polarity = PWM_POLARITY_NORMAL;
>   state->enabled = true;
> - return;
> + return 0;
>   }
> 
>   if ((PWM_REG_PRESCAL(val, pwm->hwpwm) == PWM_PRESCAL_MASK) &&
> @@ -142,7 +142,7 @@ static void sun4i_pwm_get_state(struct pwm_chip *chip,
>   prescaler = prescaler_table[PWM_REG_PRESCAL(val, pwm-
>hwpwm)];
> 
>   if (prescaler == 0)
> - return;
> + return 0;
> 
>   if (val & BIT_CH(PWM_ACT_STATE, pwm->hwpwm))
>   state->polarity = PWM_POLARITY_NORMAL;
> @@ -162,6 +162,8 @@ static void sun4i_pwm_get_state(struct pwm_chip *chip,
> 
>   tmp = (u64)prescaler * NSEC_PER_SEC * PWM_REG_PRD(val);
>   state->period = DIV_ROUND_CLOSEST_ULL(tmp, clk_rate);
> +
> + return 0;
>  }
> 
>  static int sun4i_pwm_calculate(struct sun4i_pwm_chip *sun4i_pwm,

For sun4i:

Acked-by: Jernej Skrabec 

Best regards,
Jernej

Re: [PATCH v8 3/5] drm/msm/dp: parser data-lanes as property of dp_out endpoint




On 5 December 2022 22:14:28 GMT+03:00, Kuogee Hsieh  
wrote:
>Add capability to parser data-lanes as property of dp_out endpoint.
>Also retain the original capability to parser data-lanes as property
>of mdss_dp node to handle legacy case.
>
>Changes in v6:
>-- first patch after split parser patch into two
>
>Changes in v7:
>-- check "data-lanes" from endpoint first
>
>Signed-off-by: Kuogee Hsieh 

Reviewed-by: Dmitry Baryshkov 

>---

-- 
With best wishes
Dmitry

Re: [PATCH v4 13/13] arm64: dts: qcom: sa8295-adp: Enable DP instances

2022-12-05 Thread Konrad Dybcio





On 05/12/2022 21:02, Bjorn Andersson wrote:

On Mon, Dec 05, 2022 at 07:09:45PM +0100, Konrad Dybcio wrote:

On 05/12/2022 18:44, Bjorn Andersson wrote:

diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts 
b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts

[..]

+_dp2 {
+   status = "okay";

status should go last.



Thanks for pointing that out. Would be nice if the computer told me
that...somehow...


+
+   data-lanes = <0 1 2 3>;
+
+   ports {
+   port@1 {
+   reg = <1>;
+   mdss0_dp2_phy_out: endpoint {

That's quite a lot of indentation.. couldn't these endpoints be defined in
the SoC DT?



The alternative would be to have the description of each DP controller
split over multiple nodes and rely on the reader to stitch together the
view of the node based on the label.
Based on the naming of these labels they would at least be adjacent, so
it wouldn't be that bad.

But I feel that there is enough DP-controller nodes in this board
already; I've yet to describe the two USB Type-C controllers or the two
DSI-DP bridges.
So I don't know if it's worth optimizing indentation-level within each
node like this.


And we will end up mixing this optimization between DP controllers, USB
Type-C nodes, QMP nodes, DSI-DP bridges.

Oh okay, I see, let's keep it as-is then.

Konrad


Regards,
Bjorn

Re: [PATCH v4 13/13] arm64: dts: qcom: sa8295-adp: Enable DP instances

On Mon, Dec 05, 2022 at 07:09:45PM +0100, Konrad Dybcio wrote:
> On 05/12/2022 18:44, Bjorn Andersson wrote:
> > diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts 
> > b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
[..]
> > +_dp2 {
> > +   status = "okay";
> status should go last.
> 

Thanks for pointing that out. Would be nice if the computer told me
that...somehow...

> > +
> > +   data-lanes = <0 1 2 3>;
> > +
> > +   ports {
> > +   port@1 {
> > +   reg = <1>;
> > +   mdss0_dp2_phy_out: endpoint {
> That's quite a lot of indentation.. couldn't these endpoints be defined in
> the SoC DT?
> 

The alternative would be to have the description of each DP controller
split over multiple nodes and rely on the reader to stitch together the
view of the node based on the label.
Based on the naming of these labels they would at least be adjacent, so
it wouldn't be that bad.

But I feel that there is enough DP-controller nodes in this board
already; I've yet to describe the two USB Type-C controllers or the two
DSI-DP bridges.
So I don't know if it's worth optimizing indentation-level within each
node like this.

And we will end up mixing this optimization between DP controllers, USB
Type-C nodes, QMP nodes, DSI-DP bridges.

Regards,
Bjorn

Re: [PATCH v4 08/18] dt-bindings: msm: dsi-controller-main: Add vdd* descriptions back in



On Fri, 25 Nov 2022 12:36:28 +, Bryan O'Donoghue wrote:
> When converting from .txt to .yaml we didn't include descriptions for the
> existing regulator supplies.
> 
> - vdd
> - vdda
> - vddio
> 
> Add those descriptions into the yaml now as they were prior to the
> conversion. In the .txt description we marked these regulators as required,
> however, that requirement appears to have been in error.
> 
> Taking the example of sc7180-trogdor-wormdingler.dtsi. The avdd and avee
> come from GPIO controlled external regulators, not the SoC and in this case
> there's no need for vddio to power an I/O bus. Similarly the regulators for
> the LCD are controlled by the panel driver not by the dsi-ctrl driver.
> 
> It would be possible to connect a different type of panel to the DSI bus
> here in which case we may or may not want to make use of vdd, vdda or
> vddio.
> 
> This is also the case for older chipsets like apq8064, msm8916 etc the vdd*
> regulators in the dsi-ctrl block are helpers not dependencies.
> 
> Add the description of vdd, vdda and vddio back in for the existing
> upstream dts where vdd, vdda or vddio are already declared but, don't
> declare those regulators required - they are not SoC requirements.
> 
> Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI 
> bindings")
> Signed-off-by: Bryan O'Donoghue 
> ---
>  .../bindings/display/msm/dsi-controller-main.yaml| 12 
>  1 file changed, 12 insertions(+)
> 

Acked-by: Rob Herring

Re: [PATCH v4 07/18] dt-bindings: msm: dsi-controller-main: Fix clock declarations



On Fri, 25 Nov 2022 12:36:27 +, Bryan O'Donoghue wrote:
> When converting from .txt to .yaml dt-binding descriptions we appear to
> have missed some of the previous detail on the number and names of
> permissible clocks.
> 
> Fix this by listing the clock descriptions against the clock names at a
> high level.
> 
> Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI 
> bindings")
> Signed-off-by: Bryan O'Donoghue 
> ---
>  .../display/msm/dsi-controller-main.yaml  | 20 ---
>  1 file changed, 13 insertions(+), 7 deletions(-)
> 

Acked-by: Rob Herring

Re: [PATCH v4 05/18] dt-bindings: msm: dsi-controller-main: Document clocks on a per compatible basis



On Fri, 25 Nov 2022 12:36:25 +, Bryan O'Donoghue wrote:
> Each compatible has a different set of clocks which are associated with it.
> Add in the list of clocks for each compatible.
> 
> Signed-off-by: Bryan O'Donoghue 
> ---
>  .../display/msm/dsi-controller-main.yaml  | 152 --
>  1 file changed, 142 insertions(+), 10 deletions(-)
> 

Acked-by: Rob Herring

Re: [Intel-gfx] [PATCH 7/9] drm/i915: stop using ttm_bo_wait

2022-12-05 Thread Christian König


Am 30.11.22 um 15:06 schrieb Daniel Vetter:

On Wed, 30 Nov 2022 at 14:03, Tvrtko Ursulin
 wrote:

On 29/11/2022 18:05, Matthew Auld wrote:

On Fri, 25 Nov 2022 at 11:14, Tvrtko Ursulin
 wrote:


+ Matt

On 25/11/2022 10:21, Christian König wrote:

TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.

Signed-off-by: Christian König 
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 5247d88b3c13..d409a77449a3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -599,13 +599,16 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
static int i915_ttm_truncate(struct drm_i915_gem_object *obj)
{
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
- int err;
+ long err;

WARN_ON_ONCE(obj->mm.madv == I915_MADV_WILLNEED);

- err = ttm_bo_wait(bo, true, false);
- if (err)
+ err = dma_resv_wait_timeout(bo->base.resv, DMA_RESV_USAGE_BOOKKEEP,
+ true, 15 * HZ);

This 15 second stuck out a bit for me and then on a slightly deeper look
it seems this timeout will "leak" into a few of i915 code paths. If we
look at the difference between the legacy shmem and ttm backend I am not
sure if the legacy one is blocking or not - but if it can block I don't
think it would have an arbitrary timeout like this. Matt your thoughts?

Not sure what is meant by leak here, but the legacy shmem must also
wait/block when unbinding each VMA, before calling truncate. It's the

By "leak" I meant if 15s timeout propagates into some code paths visible
from userspace which with a legacy backend instead have an indefinite
wait. If we have that it's probably not very good to have this
inconsistency, or to apply an arbitrary timeout to those path to start with.


same story for the ttm backend, except slightly more complicated in
that there might be no currently bound VMA, and yet the GPU could
still be accessing the pages due to async unbinds, kernel moves etc,
which the wait here (and in i915_ttm_shrink) is meant to protect
against. If the wait times out it should just fail gracefully. I guess
we could just use MAX_SCHEDULE_TIMEOUT here? Not sure if it really
matters though.

Right, depends if it can leak or not to userspace and diverge between
backends.

Generally lock_timeout() is a design bug. It's either
lock_interruptible (or maybe lock_killable) or try_lock, but
lock_timeout is just duct-tape. I haven't dug in to figure out what
should be here, but it smells fishy.


Independent of this discussion could I get an rb for removing 
ttm_bo_wait() from i915?


Exactly hiding this timeout inside TTM is what always made me quite 
nervous here.


Regards,
Christian.


-Daniel

Re: [PATCH v8 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

2022-12-05 Thread Ceraolo Spurio, Daniele

On 12/2/2022 3:28 PM, Alan Previn wrote:

Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pertaining to PXP
operation (such as creating the arbitration session and session
tear-down).

PXP as a global feature is accessible via batch buffer instructions
on any engine/tile and the coherency across tiles is handled implicitly
by the HW. In fact, for the foreseeable future, we are expecting this
single-control-tile for the PXP subsystem.

In MTL, it's the standalone media tile (not the root tile) because
it contains the VDBOX and KCR engine (among the assets PXP relies on
for those events).

Looking at the current code design, each tile is represented by the
intel_gt structure while the intel_pxp structure currently hangs off the
intel_gt structure.

Keeping the intel_pxp structure within the intel_gt structure makes some
internal functionalities more straight forward but adds code complexity to
code readibility and maintainibility to many external-to-pxp subsystems
which may need to pick the correct intel_gt structure. An example of this
would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
which should be viewed as a global level inquiry, not a per-gt inquiry.

That said, this series promotes the intel_pxp structure into the
drm_i915_private structure making it a top-level subsystem and the PXP
subsystem will select the control gt internally and keep a pointer to
it for internal reference.

Changes from prior revs:
v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
through out instead of local variable newpxp. (Rodrigo)
- In the case intel_pxp_fini is called during driver unload but
after i915 loading failed without pxp being allocated, check
i915->pxp before referencing it. (Alan)
v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
because : [1] introduction of 'ctrl_gt' means we correct this
for MTL's upcoming series now. [2] Also, this has little impact
globally as its only used by PXP-internal callers at the moment.
- Change intel_pxp_init/fini to take in i915 as its input to avoid
ptr-to-ptr in init/fini calls.(Jani).
- Remove the backpointer from pxp->i915 since we can use
pxp->ctrl_gt->i915 if we need it. (Rodrigo).
v5: - Switch from series to single patch (Rodrigo).
- change function name from pxp_get_kcr_owner_gt to
pxp_get_ctrl_gt.
- Fix CI BAT failure by removing redundant call to intel_pxp_fini
from driver-remove.
- NOTE: remaining open still persists on using ptr-to-ptr
and back-ptr.
v4: - Instead of maintaining intel_pxp as an intel_gt structure member
and creating a number of convoluted helpers that takes in i915 as
input and redirects to the correct intel_gt or takes any intel_gt
and internally replaces with the correct intel_gt, promote it to
be a top-level i915 structure.
v3: - Rename gt level helper functions to "intel_pxp_is_enabled/
supported/ active_on_gt" (Daniele)
- Upgrade _gt_supports_pxp to replace what was intel_gtpxp_is
supported as the new intel_pxp_is_supported_on_gt to check for
PXP feature support vs the tee support for huc authentication.
Fix pxp-debugfs-registration to use only the former to decide
support. (Daniele)
- Couple minor optimizations.
v2: - Avoid introduction of new device info or gt variables and use
existing checks / macros to differentiate the correct GT->PXP
control ownership (Daniele Ceraolo Spurio)
- Don't reuse the updated global-checkers for per-GT callers (such
as other files within PXP) to avoid unnecessary GT-reparsing,
expose a replacement helper like the prior ones. (Daniele).
v1: - Add one more patch to the series for the intel_pxp suspend/resume
for similar refactoring

References:
https://patchwork.freedesktop.org/patch/msgid/20221202011407.4068371-1-alan.previn.teres.ale...@intel.com
Signed-off-by: Alan Previn
---
.../drm/i915/display/skl_universal_plane.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +-
drivers/gpu/drm/i915/gem/i915_gem_create.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 5 --
drivers/gpu/drm/i915/gt/intel_gt_debugfs.c| 1 -
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 2 +-
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 8 --
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 -
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
drivers/gpu/drm/i915/i915_driver.c

Re: [PATCH] drm/i915/gen12: Apply recommended L3 hashing mask

2022-12-05 Thread Gustavo Sousa

On Thu, Dec 01, 2022 at 02:22:10PM -0800, Matt Roper wrote:
> The TGL/RKL/DG1/ADL performance tuning guide suggests programming a
> literal value of 0x2FC0100F for this register.  The register's hardware
> default value is 0x2FC0108F, so this translates to just clearing one
> bit.
> 
> Take this opportunity to also clean up the register definition and
> re-write its existing bits/fields in the preferred notation.
> 
> Bspec: 31870
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 9 +
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 
>  2 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 61a5c9a83b1b..f8eb807b56f9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -958,10 +958,11 @@
>  #define   GEN7_DISABLE_SAMPLER_PREFETCH  (1 << 30)
>  
>  #define GEN8_GARBCNTL_MMIO(0xb004)
> -#define   GEN9_GAPS_TSV_CREDIT_DISABLE   (1 << 7)
> -#define   GEN11_ARBITRATION_PRIO_ORDER_MASK  (0x3f << 22)
> -#define   GEN11_HASH_CTRL_EXCL_MASK  (0x7f << 0)
> -#define   GEN11_HASH_CTRL_EXCL_BIT0  (1 << 0)
> +#define   GEN11_ARBITRATION_PRIO_ORDER_MASK  REG_GENMASK(27, 22)
> +#define   GEN12_BUS_HASH_CTL_BIT_EXC REG_BIT(7)
> +#define   GEN9_GAPS_TSV_CREDIT_DISABLE   REG_BIT(7)
> +#define   GEN11_HASH_CTRL_EXCL_MASK  REG_GENMASK(6, 0)
> +#define   GEN11_HASH_CTRL_EXCL_BIT0  
> REG_FIELD_PREP(GEN11_HASH_CTRL_EXCL_MASK, 0x1)
>  
>  #define GEN9_SCRATCH_LNCF1   _MMIO(0xb008)
>  #define   GEN9_LNCF_NONIA_COHERENT_ATOMICS_ENABLEREG_BIT(0)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 85822ebb0d64..2f13a92f77d3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2937,6 +2937,10 @@ add_render_compute_tuning_settings(struct 
> drm_i915_private *i915,
>   if (INTEL_INFO(i915)->tuning_thread_rr_after_dep)
>   wa_mcr_masked_field_set(wal, GEN9_ROW_CHICKEN4, 
> THREAD_EX_ARB_MODE,
>   THREAD_EX_ARB_MODE_RR_AFTER_DEP);
> +
> + if (GRAPHICS_VER(i915) == 12 && GRAPHICS_VER_FULL(i915) < IP_VER(12, 
> 50)) {
> + wa_write_clr(wal, GEN8_GARBCNTL, GEN12_BUS_HASH_CTL_BIT_EXC);
> + }

Removing the unnecessary braces as pointed out by dim checkpatch,

Reviewed-by: Gustavo Sousa 

>  }
>  
>  /*
> -- 
> 2.38.1
>

Re: [PATCH v3 08/11] arm64: dts: qcom: sm8350: Use 2 interconnect cells

2022-12-05 Thread Georgi Djakov


Hi Robert,

On 5.12.22 18:37, Robert Foss wrote:

Use two interconnect cells in order to optionally
support a path tag.

Signed-off-by: Robert Foss 
Reviewed-by: Konrad Dybcio 
---
  arch/arm64/boot/dts/qcom/sm8350.dtsi | 28 ++--
  1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi 
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 805d53d91952..434f8e8b12c1 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -1543,56 +1543,56 @@ apps_smmu: iommu@1500 {
config_noc: interconnect@150 {
compatible = "qcom,sm8350-config-noc";
reg = <0 0x0150 0 0xa580>;
-   #interconnect-cells = <1>;
+   #interconnect-cells = <2>;
qcom,bcm-voters = <_bcm_voter>;
};
  
  		mc_virt: interconnect@158 {

compatible = "qcom,sm8350-mc-virt";
reg = <0 0x0158 0 0x1000>;
-   #interconnect-cells = <1>;
+   #interconnect-cells = <2>;
qcom,bcm-voters = <_bcm_voter>;
};

[..]

@@ -1620,8 +1620,8 @@ ipa: ipa@1e4 {
clocks = < RPMH_IPA_CLK>;
clock-names = "core";
  
-			interconnects = <_noc MASTER_IPA _virt SLAVE_EBI1>,

-   <_noc MASTER_APPSS_PROC _noc 
SLAVE_IPA_CFG>;
+   interconnects = <_noc MASTER_IPA 0 _virt 
SLAVE_EBI1 0>,
+   <_noc MASTER_APPSS_PROC 0 _noc 
SLAVE_IPA_CFG 0>;
interconnect-names = "memory",
 "config";
  
@@ -1661,7 +1661,7 @@ mpss: remoteproc@408 {

< SM8350_MSS>;
power-domain-names = "cx", "mss";
  
-			interconnects = <_virt MASTER_LLCC _virt SLAVE_EBI1>;

+   interconnects = <_virt MASTER_LLCC _virt SLAVE_EBI1 
0>;


The second cell for the first endpoint is missing, so this should be:
interconnects = <_virt MASTER_LLCC 0 _virt SLAVE_EBI1 0>;

Thanks,
Georgi

  
  			memory-region = <_modem_mem>;
  
@@ -2239,7 +2239,7 @@ cdsp: remoteproc@9890 {

< SM8350_MXC>;
power-domain-names = "cx", "mxc";
  
-			interconnects = <_noc MASTER_CDSP_PROC _virt SLAVE_EBI1>;

+   interconnects = <_noc MASTER_CDSP_PROC 0 _virt 
SLAVE_EBI1 0>;
  
  			memory-region = <_cdsp_mem>;
  
@@ -2421,14 +2421,14 @@ usb_2_ssphy: phy@88ebe00 {

dc_noc: interconnect@90c {
compatible = "qcom,sm8350-dc-noc";
reg = <0 0x090c 0 0x4200>;
-   #interconnect-cells = <1>;
+   #interconnect-cells = <2>;
qcom,bcm-voters = <_bcm_voter>;
};
  
  		gem_noc: interconnect@910 {

compatible = "qcom,sm8350-gem-noc";
reg = <0 0x0910 0 0xb4000>;
-   #interconnect-cells = <1>;
+   #interconnect-cells = <2>;
qcom,bcm-voters = <_bcm_voter>;
};

Re: [PATCH v8 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

2022-12-05 Thread Ceraolo Spurio, Daniele





On 12/5/2022 11:04 AM, Teres Alexis, Alan Previn wrote:


On Mon, 2022-12-05 at 12:57 -0500, Vivi, Rodrigo wrote:

On Fri, Dec 02, 2022 at 03:28:21PM -0800, Alan Previn wrote:




Alan: [snip]


@@ -1168,6 +1176,8 @@ static int i915_drm_prepare(struct drm_device *dev)
  {
struct drm_i915_private *i915 = to_i915(dev);
  
+	intel_pxp_suspend_prepare(i915->pxp);

+
/*
 * NB intel_display_suspend() may issue new requests after we've
 * ostensibly marked the GPU as ready-to-sleep here. We need to
@@ -1248,6 +1258,8 @@ static int i915_drm_suspend_late(struct drm_device *dev, 
bool hibernation)
  
  	disable_rpm_wakeref_asserts(rpm);
  
+	intel_pxp_suspend(dev_priv->pxp);

+

Before this patch the pxp_suspend was done right after uc_suspend.
Right now, the uc_suspend will happen couple lines below.




Okay - I see this 2nd level flow change but this has no functional change. I 
have gone through the codes and whether
intel_pxp_suspend came in after i915_gem_suspend_late or the middle of 
gt_suspend_late (after us_suspend), it does not
make any difference. intel_pxp_suspend only disables display-control-events on 
KCR register and disables CRYPTO-IRQ
registers. GuC or HuC is only ever doing any PXP related work if it receives 
workloads via exec-buf (kernel side PXP
workload subsmission is limited to arb-session creation today OR, in future, 
teardown-flows at suspend_prepare - this is
upcoming change in flight). That said, since the GT is already quiesced in 
suspend_prepare, therefore HuC or GuC should
be not doing anything inside of i915_suspend_late whether its before 
i915_gem_suspend_late or before uc_suspend.



If this is okay, why can't we move already the pxp_suspend to the
suspend function and need to keep this in the suspend late?


We can - but i dont see any difference in doing so functionally speaking - i do 
however prefer minimizing the code flow
changes to


Or we don't change the flow at all, or we already fix the unbalanced
thing.
I believe the first option is better and changing the flow in a
separated patch is better.


Actually, I rather fix the symmetry at the this level: As part of this feature 
to promote PXP - Gt becomes a dependency
of PXP. So at init, we ensure GT is init first and then we init PXP. Therefore 
we should do the opposite for fini -
ensure PXP fini is done first and the cleanup the GT. That why the move above. 
But as the global i915 level we are
keeping it within suspend_late - after everything was quiesced in 
suspend_prepare.


Specially because I don't understand if huc has any dependency on
the pxp. Maybe that was the original reason why that function end up there
at first place.

I believe Daniele is the right one to let us know that.


I spoke to Daniele and he confirmed what i explained above.


Yup, can confirm. Might be worth adding a note to the commit message 
that GT is now considered a soft-dependency of PXP and that the 
suspend_late function calls have been re-ordered accordingly, but that 
this re-order doesn't have any impact apart from code flow because at 
that point in time there can't be any PXP events, so it doesn't really 
matter when we disable the PXP HW (global irqs are off anyway, so even 
if there was a bug that generated spurious event we wouldn't see it and 
we would just clean it up on resume).


I also agree that moving calls between different suspend stages should 
be left to a separate patch.


Daniele


i915_gem_suspend_late(dev_priv);

[PATCH v8 5/5] drm/msm/dp: add support of max dp link rate

By default, HBR2 (5.4G) is the max link link be supported. This patch add
the capability to support max link rate at HBR3 (8.1G).

Changes in v2:
-- add max link rate from dtsi

Changes in v3:
-- parser max_data_lanes and max_dp_link_rate from dp_out endpoint

Changes in v4:
-- delete unnecessary pr_err

Changes in v5:
-- split parser function into different patch

Signed-off-by: Kuogee Hsieh 
Reviewed-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/dp/dp_display.c | 4 
 drivers/gpu/drm/msm/dp/dp_panel.c   | 7 ---
 drivers/gpu/drm/msm/dp/dp_panel.h   | 1 +
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index bfd0aef..edee550 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -390,6 +390,10 @@ static int dp_display_process_hpd_high(struct 
dp_display_private *dp)
struct edid *edid;
 
dp->panel->max_dp_lanes = dp->parser->max_dp_lanes;
+   dp->panel->max_dp_link_rate = dp->parser->max_dp_link_rate;
+
+   drm_dbg_dp(dp->drm_dev, "max_lanes=%d max_link_rate=%d\n",
+   dp->panel->max_dp_lanes, dp->panel->max_dp_link_rate);
 
rc = dp_panel_read_sink_caps(dp->panel, dp->dp_display.connector);
if (rc)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c 
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 5149ceb..933fa9c 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -75,12 +75,13 @@ static int dp_panel_read_dpcd(struct dp_panel *dp_panel)
link_info->rate = drm_dp_bw_code_to_link_rate(dpcd[DP_MAX_LINK_RATE]);
link_info->num_lanes = dpcd[DP_MAX_LANE_COUNT] & DP_MAX_LANE_COUNT_MASK;
 
+   /* Limit data lanes from data-lanes of endpoint properity of dtsi */
if (link_info->num_lanes > dp_panel->max_dp_lanes)
link_info->num_lanes = dp_panel->max_dp_lanes;
 
-   /* Limit support upto HBR2 until HBR3 support is added */
-   if (link_info->rate >= (drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4)))
-   link_info->rate = drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4);
+   /* Limit link rate from link-frequencies of endpoint properity of dtsi 
*/
+   if (link_info->rate > dp_panel->max_dp_link_rate)
+   link_info->rate = dp_panel->max_dp_link_rate;
 
drm_dbg_dp(panel->drm_dev, "version: %d.%d\n", major, minor);
drm_dbg_dp(panel->drm_dev, "link_rate=%d\n", link_info->rate);
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.h 
b/drivers/gpu/drm/msm/dp/dp_panel.h
index d861197a..f04d021 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.h
+++ b/drivers/gpu/drm/msm/dp/dp_panel.h
@@ -50,6 +50,7 @@ struct dp_panel {
 
u32 vic;
u32 max_dp_lanes;
+   u32 max_dp_link_rate;
 
u32 max_bw_code;
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v8 4/5] drm/msm/dp: parser link-frequencies as property of dp_out endpoint

Add capability to parser and retrieve max DP link supported rate from
link-frequencies property of dp_out endpoint.

Changes in v6:
-- second patch after split parser patch into two patches

Changes in v7:
-- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate

Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/dp/dp_parser.c | 19 +--
 drivers/gpu/drm/msm/dp/dp_parser.h |  2 ++
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c 
b/drivers/gpu/drm/msm/dp/dp_parser.c
index b5f7e70..037dad8 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -94,15 +94,28 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
 static int dp_parser_misc(struct dp_parser *parser)
 {
struct device_node *of_node = parser->pdev->dev.of_node;
+   struct device_node *endpoint;
+   u64 frequency;
int cnt;
 
/*
 * data-lanes is the property of dp_out endpoint
 */
cnt = drm_of_get_data_lanes_count_ep(of_node, 1, 0, 1, 
DP_MAX_NUM_DP_LANES);
-   if (cnt > 0)
+   if (cnt > 0) {
parser->max_dp_lanes = cnt;
-   else {
+
+   endpoint = of_graph_get_endpoint_by_regs(of_node, 1, 0); /* 
port@1 */
+   cnt = of_property_count_u64_elems(endpoint, "link-frequencies");
+   if (cnt > 0) {
+   of_property_read_u64_index(endpoint, "link-frequencies",
+   cnt - 1, );
+   frequency /= 10;/* from symbol rate to link 
rate */
+   parser->max_dp_link_rate = (frequency / 1000); /* kbits 
*/
+   } else {
+   parser->max_dp_link_rate = DP_LINK_RATE_HBR2; /* 54 
khz */
+   }
+   } else {
/*
 * legacy code, data-lanes is the property of mdss_dp node
 */
@@ -111,6 +124,8 @@ static int dp_parser_misc(struct dp_parser *parser)
parser->max_dp_lanes = cnt;
else
parser->max_dp_lanes = DP_MAX_NUM_DP_LANES; /* 4 lanes 
*/
+
+   parser->max_dp_link_rate = DP_LINK_RATE_HBR2; /* 54 khz */
}
 
return 0;
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h 
b/drivers/gpu/drm/msm/dp/dp_parser.h
index 866c1a8..3ddf639 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -15,6 +15,7 @@
 #define DP_LABEL "MDSS DP DISPLAY"
 #define DP_MAX_PIXEL_CLK_KHZ   675000
 #define DP_MAX_NUM_DP_LANES4
+#define DP_LINK_RATE_HBR2   54
 
 enum dp_pm_type {
DP_CORE_PM,
@@ -119,6 +120,7 @@ struct dp_parser {
struct dp_io io;
struct dp_display_data disp_data;
u32 max_dp_lanes;
+   u32 max_dp_link_rate;
struct drm_bridge *next_bridge;
 
int (*parse)(struct dp_parser *parser);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v8 1/5] arm64: dts: qcom: add data-lanes and link-freuencies into dp_out endpoint

Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.

Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add _out to sc7180-trogdor.dtsi and sc7280-herobrine.dtsi

Changes in v6:
-- add data-lanes and link-frequencies to yaml

Changes in v7:
-- change 16000 to 162000
-- separate yaml to different patch

Changes in v8:
-- correct Bjorn mail address to kernel.org

Signed-off-by: Kuogee Hsieh 
---
 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi   | 6 +-
 arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi 
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index eae22e6..0ad50e2 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -814,7 +814,11 @@ hp_i2c:  {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
-   data-lanes = <0 1>;
+};
+
+_out {
+data-lanes = <0  1>;
+link-frequencies = /bits/ 64 <16200 27000 54000>;
 };
 
 _adc {
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi 
b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
index c11e371..3c7a9d8 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -442,7 +442,11 @@ ap_i2c_tpm:  {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
-   data-lanes = <0 1>;
+};
+
+_out {
+   data-lanes = <0  1>;
+   link-frequencies = /bits/ 64 <162000 27 54 
81>;
 };
 
 _mdp {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v8 3/5] drm/msm/dp: parser data-lanes as property of dp_out endpoint

Add capability to parser data-lanes as property of dp_out endpoint.
Also retain the original capability to parser data-lanes as property
of mdss_dp node to handle legacy case.

Changes in v6:
-- first patch after split parser patch into two

Changes in v7:
-- check "data-lanes" from endpoint first

Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/dp/dp_parser.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c 
b/drivers/gpu/drm/msm/dp/dp_parser.c
index dd73221..b5f7e70 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -94,16 +94,25 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
 static int dp_parser_misc(struct dp_parser *parser)
 {
struct device_node *of_node = parser->pdev->dev.of_node;
-   int len;
-
-   len = drm_of_get_data_lanes_count(of_node, 1, DP_MAX_NUM_DP_LANES);
-   if (len < 0) {
-   DRM_WARN("Invalid property \"data-lanes\", default max DP lanes 
= %d\n",
-DP_MAX_NUM_DP_LANES);
-   len = DP_MAX_NUM_DP_LANES;
+   int cnt;
+
+   /*
+* data-lanes is the property of dp_out endpoint
+*/
+   cnt = drm_of_get_data_lanes_count_ep(of_node, 1, 0, 1, 
DP_MAX_NUM_DP_LANES);
+   if (cnt > 0)
+   parser->max_dp_lanes = cnt;
+   else {
+   /*
+* legacy code, data-lanes is the property of mdss_dp node
+*/
+   cnt = drm_of_get_data_lanes_count(of_node, 1, 
DP_MAX_NUM_DP_LANES);
+   if (cnt > 0)
+   parser->max_dp_lanes = cnt;
+   else
+   parser->max_dp_lanes = DP_MAX_NUM_DP_LANES; /* 4 lanes 
*/
}
 
-   parser->max_dp_lanes = len;
return 0;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v8 2/5] dt-bindings: msm/dp: add data-lanes and link-frequencies property

Add both data-lanes and link-frequencies property into endpoint

Changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property

Changes in v8:
-- correct Bjorn mail address to kernel.org

Signed-off-by: Kuogee Hsieh 
---
 .../bindings/display/msm/dp-controller.yaml| 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml 
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index f2515af..13d2c3c 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -79,12 +79,6 @@ properties:
   aux-bus:
 $ref: /schemas/display/dp-aux-bus.yaml#
 
-  data-lanes:
-$ref: /schemas/types.yaml#/definitions/uint32-array
-minItems: 1
-maxItems: 4
-items:
-  maximum: 3
 
   "#sound-dai-cells":
 const: 0
@@ -105,6 +99,19 @@ properties:
 $ref: /schemas/graph.yaml#/properties/port
 description: Output endpoint of the controller
 
+properties:
+  endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+
+  properties:
+data-lanes:
+  $ref: /schemas/types.yaml#/definitions/uint32-array
+
+link-frequencies:
+  $ref: /schemas/types.yaml#/definitions/uint64-array
+
+  additionalProperties: false
+
 required:
   - compatible
   - reg
@@ -193,6 +200,9 @@ examples:
 reg = <1>;
 endpoint {
 remote-endpoint = <>;
+data-lanes = <1 2>;
+link-frequencies = /bits/ 64 <162000 27
+  54 81>;
 };
 };
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v8 0/5] Add data-lanes and link-frequencies to dp_out endpoint

Add DP both data-lanes and link-frequencies property to dp_out endpoint and 
support
functions to DP driver.

Kuogee Hsieh (5):
  arm64: dts: qcom: add data-lanes and link-freuencies into dp_out
endpoint
  dt-bindings: msm/dp: add data-lanes and link-frequencies property
  drm/msm/dp: parser data-lanes as property of dp_out endpoint
  drm/msm/dp: parser link-frequencies as property of dp_out endpoint
  drm/msm/dp: add support of max dp link rate

 .../bindings/display/msm/dp-controller.yaml| 22 +
 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi   |  6 +++-
 arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi |  6 +++-
 drivers/gpu/drm/msm/dp/dp_display.c|  4 +++
 drivers/gpu/drm/msm/dp/dp_panel.c  |  7 ++--
 drivers/gpu/drm/msm/dp/dp_panel.h  |  1 +
 drivers/gpu/drm/msm/dp/dp_parser.c | 38 ++
 drivers/gpu/drm/msm/dp/dp_parser.h |  2 ++
 8 files changed, 68 insertions(+), 18 deletions(-)

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

Re: [PATCH v8 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

2022-12-05 Thread Teres Alexis, Alan Previn



On Mon, 2022-12-05 at 12:57 -0500, Vivi, Rodrigo wrote:
> On Fri, Dec 02, 2022 at 03:28:21PM -0800, Alan Previn wrote:
> > 
> > 
> > 

Alan: [snip]

> > @@ -1168,6 +1176,8 @@ static int i915_drm_prepare(struct drm_device *dev)
> >  {
> > struct drm_i915_private *i915 = to_i915(dev);
> >  
> > +   intel_pxp_suspend_prepare(i915->pxp);
> > +
> > /*
> >  * NB intel_display_suspend() may issue new requests after we've
> >  * ostensibly marked the GPU as ready-to-sleep here. We need to
> > @@ -1248,6 +1258,8 @@ static int i915_drm_suspend_late(struct drm_device 
> > *dev, bool hibernation)
> >  
> > disable_rpm_wakeref_asserts(rpm);
> >  
> > +   intel_pxp_suspend(dev_priv->pxp);
> > +
> 
> Before this patch the pxp_suspend was done right after uc_suspend.
> Right now, the uc_suspend will happen couple lines below.
> 
> 
> 
Okay - I see this 2nd level flow change but this has no functional change. I 
have gone through the codes and whether
intel_pxp_suspend came in after i915_gem_suspend_late or the middle of 
gt_suspend_late (after us_suspend), it does not
make any difference. intel_pxp_suspend only disables display-control-events on 
KCR register and disables CRYPTO-IRQ
registers. GuC or HuC is only ever doing any PXP related work if it receives 
workloads via exec-buf (kernel side PXP
workload subsmission is limited to arb-session creation today OR, in future, 
teardown-flows at suspend_prepare - this is
upcoming change in flight). That said, since the GT is already quiesced in 
suspend_prepare, therefore HuC or GuC should
be not doing anything inside of i915_suspend_late whether its before 
i915_gem_suspend_late or before uc_suspend.


> If this is okay, why can't we move already the pxp_suspend to the
> suspend function and need to keep this in the suspend late?
> 
We can - but i dont see any difference in doing so functionally speaking - i do 
however prefer minimizing the code flow
changes to 

> Or we don't change the flow at all, or we already fix the unbalanced
> thing.
> I believe the first option is better and changing the flow in a
> separated patch is better.
> 
Actually, I rather fix the symmetry at the this level: As part of this feature 
to promote PXP - Gt becomes a dependency
of PXP. So at init, we ensure GT is init first and then we init PXP. Therefore 
we should do the opposite for fini -
ensure PXP fini is done first and the cleanup the GT. That why the move above. 
But as the global i915 level we are
keeping it within suspend_late - after everything was quiesced in 
suspend_prepare.

> Specially because I don't understand if huc has any dependency on
> the pxp. Maybe that was the original reason why that function end up there
> at first place.
> 
> I believe Daniele is the right one to let us know that.
> 
I spoke to Daniele and he confirmed what i explained above.

> > i915_gem_suspend_late(dev_priv);
> >  
> >

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: Add GuC CT specific debug print wrappers

2022-12-05 Thread Michal Wajdeczko




On 05.12.2022 14:16, Tvrtko Ursulin wrote:
> 
> On 02/12/2022 20:14, John Harrison wrote:
> 
 and while for dbg level messages it doesn't matter, I assume we should
 be consistent for err/warn/info messages (as those will eventually show
 up to the end user) so let maintainers decide here what is
 expectation here
>>>
>>> Could we have some examples pasted here, of the end result of this
>>> series, for all message "categories" (origins, macros, whatever)?
>>
>> GT initialisation:
>> gt_err(gt, "Failed to allocate scratch page\n");
>> i915 :00:02.0: [drm] GT0: Failed to allocate scratch page
>>
>> G2H notification handler:
>> guc_err(guc, "notification: Invalid length %u for deregister done\n",
>> len);
>> i915 :00:02.0: [drm] GT0: GuC notification: Invalid length 0 for
>> deregister done

please note that today this message is coded as:

drm_err(_to_gt(guc)->i915->drm, "Invalid length %u\n", len);
-> i915 :00:02.0: [drm] Invalid length %u

which makes this rather an example of meaningless log

> 
> I'm not liking the inconsistency between gt_err and guc_err where with
> latter callers either need to start the message with lower case because
> of the unstructured "GuC " prefix added. Which then reads bad if callers
> do guc_err(guc, "Error X happend").
> 
> Looks like Michal was pointing out the same thing, AFAIU at least when
> re-reading the thread now.
> 
> Why wouldn't this work:
> 
> guc_err(guc, "Invalid length %u for deregister done notification\n", len);
> i915 :00:02.0: [drm] GT0: GuC: Invalid length 0 for deregister done
> notification

+1

> 
> Or if the use case for adding custom prefixes is strong then maybe
> consider:
> 
> guc_err(guc, "notification", "Invalid length 0 for deregister done");
> i915 :00:02.0: [drm] GT0: GuC notification: Invalid length 0 for
> deregister done
> 
> guc_err(guc, "", "Error X");
> i915 :00:02.0: [drm] GT0: GuC: Error X

-1

this will make logging macros too different from others (unless we
hide/use prefixes inside macros only, but I'm not sure there is any ROI)

> 
>> CTB initialisation:
>> ct_probe_error(ct, "Failed to control/%s CTB (%pe)\n",
>> str_enable_disable(enable), ERR_PTR(err));
>> i915 :00:02.0: [drm] GT0: GuC CT Failed to control/enable CTB
>> (EINVAL)
> 
> Okay same as above.
> 
>> Random meaningless (to me) message that is apparently a display thing:
>> drm_dbg_kms(_priv->drm, "disabling %s\n", pll->info->name);
>> i915 :00:02.0: [drm:intel_disable_shared_dpll [i915]] disabling
>> PORT PLL B
> 
> Plan is to not touch outside gt/.
> 
>> I'm sure you can extrapolate to all other forms of dbg, notice, info,
>> etc. without me having to manually type each one out, given that they
>> are all identical.
>>
>> Personally, I think the above should be just:
>> gt_err(gt, "Failed to allocate scratch page\n");
>> i915 :00:02.0: [drm] GT0: Failed to allocate scratch page
>>
>> gt_err(guc_to_gt(guc), "G2H: Invalid length for deregister done:
>> %u\n", len);
>> i915 :00:02.0: [drm] GT0: G2H: Invalid length for deregister done: 0

that's probably should be:

"Invalid length for G2H deregister done: %u\n

and it will still just look fine if we auto append the 'GuC' prefix:

i915 :00:02.0: [drm] GT0: GuC: Invalid length for G2H deregister

>>
>> gt_probe_error(ct_to_gt(ct), "Failed to %s CT %d buffer (%pe)\n",
>> str_enable_disable(enable), send ? "SEND" : "RECV", ERR_PTR(err));
>> i915 :00:02.0: [drm] GT0: Failed to enable CT SEND buffer (EINVAL)

having "GuC/CT" prefix here will also look fine:

i915 :00:02.0: [drm] GT0: GuC: Failed to enable CT SEND buffer
i915 :00:02.0: [drm] GT0: GuC: CT: Failed to enable SEND buffer
i915 :00:02.0: [drm] GT0: CT: Failed to enable SEND buffer

> 
> We could but it seems we agreed some weeks ago to consolidate the
> existing CT_ERROR macros and such in this exercise. At least no
> objections were raised to that plan.
> 
> If now we want to go back on that, and if you want to have
> guc_to_gt(guc) in all gt/uc/ call sites that's fine by me, but please
> get some acks and consensus from people who work in that area. And under
> that option someone would also need to convert the CT code to new macros.

while the main goal of this series was to have GT# appended to the log
messages but we also wanted to simplify the use of the logging macros by
passing the component pointer directly (with extra *bonus* that allows
to auto append component specific prefix, if any, like CT macros do)

IMHO adding guc_xxx() macros with "GuC:" prefix will do the trick and
since many of the existing GuC related logs are already broken or
incomplete, we might fix them accordingly.

In other words in addition to gt_xxx() I still want additional guc_xxx()
macros (as it will allow us to fix related messages) and ct_xxx() macros
(as we already have CT_xxx so no need to change anything)

Michal

> 
> Regards,
> 
> Tvrtko
> 
>> drm_dbg_kms(_priv->drm, "disabling %s\n",

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Check full IP version when applying hw steering semaphore

2022-12-05 Thread Tvrtko Ursulin




On 05/12/2022 16:27, Matt Roper wrote:

On Mon, Dec 05, 2022 at 12:50:40PM +, Tvrtko Ursulin wrote:


On 02/12/2022 22:49, Rodrigo Vivi wrote:

On Fri, Dec 02, 2022 at 02:35:28PM -0800, Matt Roper wrote:

When determining whether the platform has a hardware-level steering
semaphore (i.e., MTL and beyond), we need to use GRAPHICS_VER_FULL() to
compare the full version rather than just the major version number
returned by GRAPHICS_VER().

Reported-by: kernel test robot 
Fixes: 3100240bf846 ("drm/i915/mtl: Add hardware-level lock for steering")
Cc: Balasubramani Vivekanandan 
Signed-off-by: Matt Roper 


Reviewed-by: Rodrigo Vivi 

---
   drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index 087e4ac5b68d..41a237509dcf 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -367,7 +367,7 @@ void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long 
*flags)
 * driver threads, but also with hardware/firmware agents.  A dedicated
 * locking register is used.
 */
-   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
+   if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))


Ouch, tricky class of bugs... Anyone has an idea how to maybe coerce the 
compiler into spotting them for us, cheaply?


I believe clang can already notice these problems with
Wtautological-constant-out-of-range-compare (which is how the kernel
test robot finds them):

>> drivers/gpu/drm/i915/gt/intel_gt_mcr.c:370:29: warning: result of 
comparison of constant 3142 with expression of type 'u8' (aka 'unsigned char')
+is always false [-Wtautological-constant-out-of-range-compare]
   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
   ~~ ^  ~~
   drivers/gpu/drm/i915/gt/intel_gt_mcr.c:410:29: warning: result of 
comparison of constant 3142 with expression of type 'u8' (aka 'unsigned char')
+is always false [-Wtautological-constant-out-of-range-compare]
   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
   ~~ ^  ~~
   2 warnings generated.


Hah.. curios how IS_ENABLED then works on clang builds. Maybe it has 
some special handling for that flavour of "always false".



Unfortunately gcc doesn't seem to have anything equivalent as far as I
can see.



This one is undefined behaviour I think so not good:

-#define IP_VER(ver, rel)   ((ver) << 8 | (rel))
+typedef void * i915_full_ver_t;
+
+#define IP_VER(ver, rel) (i915_full_ver_t)(unsigned long)((ver) << 8 | (rel))


Hmm, so by casting it into a pointer, you're hoping to trigger a
"comparison of pointer and integer without cast" warning on misuse?
That's a good idea, but as you noted, the C99 spec says comparison of
pointers is only guaranteed to work if both are pointers into the same
structure/array, otherwise the results are technically undefined.


"error: comparison between pointer and integer" - it works, but yes it 
is undefined. Only == and != are allowed on random void * pointers.


Since you say clang builds report the problem we are good I guess.

Regards,

Tvrtko

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/mtl: Add hardware-level lock for steering

2022-12-05 Thread Tvrtko Ursulin




On 05/12/2022 15:52, Matt Roper wrote:

On Mon, Dec 05, 2022 at 08:58:16AM +, Tvrtko Ursulin wrote:


On 28/11/2022 23:30, Matt Roper wrote:

Starting with MTL, the driver needs to not only protect the steering
control register from simultaneous software accesses, but also protect
against races with hardware/firmware agents.  The hardware provides a
dedicated locking mechanism to support this via the MTL_STEER_SEMAPHORE
register.  Reading the register acts as a 'trylock' operation; the read
will return 0x1 if the lock is acquired or 0x0 if something else is
already holding the lock; once acquired, writing 0x1 to the register
will release the lock.

We'll continue to grab the software lock as well, just so lockdep can
track our locking; assuming the hardware lock is behaving properly,
there should never be any contention on the software lock in this case.

v2:
   - Extend hardware semaphore timeout and add a taint for CI if it ever
 happens (this would imply misbehaving hardware/firmware).  (Mika)
   - Add "MTL_" prefix to new steering semaphore register.  (Mika)

Cc: Mika Kuoppala 
Signed-off-by: Matt Roper 
---
   drivers/gpu/drm/i915/gt/intel_gt_mcr.c  | 38 ++---
   drivers/gpu/drm/i915/gt/intel_gt_regs.h |  1 +
   2 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index aa070ae57f11..087e4ac5b68d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -347,10 +347,9 @@ static u32 rw_with_mcr_steering(struct intel_gt *gt,
* @flags: storage to save IRQ flags to
*
* Performs locking to protect the steering for the duration of an MCR
- * operation.  Depending on the platform, this may be a software lock
- * (gt->mcr_lock) or a hardware lock (i.e., a register that synchronizes
- * access not only for the driver, but also for external hardware and
- * firmware agents).
+ * operation.  On MTL and beyond, a hardware lock will also be taken to
+ * serialize access not only for the driver, but also for external hardware and
+ * firmware agents.
*
* Context: Takes gt->mcr_lock.  uncore->lock should *not* be held when this
*  function is called, although it may be acquired after this
@@ -359,12 +358,40 @@ static u32 rw_with_mcr_steering(struct intel_gt *gt,
   void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long *flags)
   {
unsigned long __flags;
+   int err = 0;
lockdep_assert_not_held(>uncore->lock);
+   /*
+* Starting with MTL, we need to coordinate not only with other
+* driver threads, but also with hardware/firmware agents.  A dedicated
+* locking register is used.
+*/
+   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
+   err = wait_for(intel_uncore_read_fw(gt->uncore,
+   MTL_STEER_SEMAPHORE) == 
0x1, 100);
+


If two i915 threads enter here what happens? (Given hw locking is done
before the spinlock.)


The second thread will see a '0' when it reads the register, indicating
that something else (sw, fw, or hw) already has it locked.  As soon as
the first thread drops the lock, the next read will return '1' and allow
the second thread to proceed.


I was worried if there was a concept of request originator, but this 
then sounds good.


Regards,

Tvrtko


+   /*
+* Even on platforms with a hardware lock, we'll continue to grab
+* a software spinlock too for lockdep purposes.  If the hardware lock
+* was already acquired, there should never be contention on the
+* software lock.
+*/
spin_lock_irqsave(>mcr_lock, __flags);
*flags = __flags;
+
+   /*
+* In theory we should never fail to acquire the HW semaphore; this
+* would indicate some hardware/firmware is misbehaving and not
+* releasing it properly.
+*/
+   if (err == -ETIMEDOUT) {
+   drm_err_ratelimited(>i915->drm,
+   "GT%u hardware MCR steering semaphore timed 
out",
+   gt->info.id);
+   add_taint_for_CI(gt->i915, TAINT_WARN);  /* CI is now 
unreliable */
+   }
   }
   /**
@@ -379,6 +406,9 @@ void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long 
*flags)
   void intel_gt_mcr_unlock(struct intel_gt *gt, unsigned long flags)
   {
spin_unlock_irqrestore(>mcr_lock, flags);
+
+   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
+   intel_uncore_write_fw(gt->uncore, MTL_STEER_SEMAPHORE, 0x1);
   }
   /**
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 784152548472..1618d46cb8c7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -67,6 +67,7 @@
   #define GMD_ID_MEDIA _MMIO(MTL_MEDIA_GSI_BASE +

Re: [PATCH v4 13/13] arm64: dts: qcom: sa8295-adp: Enable DP instances

2022-12-05 Thread Konrad Dybcio





On 05/12/2022 18:44, Bjorn Andersson wrote:

From: Bjorn Andersson 

The SA8295P ADP has, among other interfaces, six MiniDP connectors which
are connected to MDSS0 DP2 and DP3, and MDSS1 DP0 through DP3.

Enable Display Clock controllers, MDSS instanced, MDPs, DP controllers,
DP PHYs and link them all together.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v3:
- None

  arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 243 ++-
  1 file changed, 241 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts 
b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
index 6c29d7d757e0..d55c8c5304cc 100644
--- a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
+++ b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
@@ -23,6 +23,90 @@ aliases {
chosen {
stdout-path = "serial0:115200n8";
};
+
+   dp2-connector {
+   compatible = "dp-connector";
+   label = "DP2";
+   type = "mini";
+
+   hpd-gpios = < 20 GPIO_ACTIVE_HIGH>;
+
+   port {
+   dp2_connector_in: endpoint {
+   remote-endpoint = <_dp0_phy_out>;
+   };
+   };
+   };
+
+   dp3-connector {
+   compatible = "dp-connector";
+   label = "DP3";
+   type = "mini";
+
+   hpd-gpios = < 45 GPIO_ACTIVE_HIGH>;
+
+   port {
+   dp3_connector_in: endpoint {
+   remote-endpoint = <_dp1_phy_out>;
+   };
+   };
+   };
+
+   edp0-connector {
+   compatible = "dp-connector";
+   label = "EDP0";
+   type = "mini";
+
+   hpd-gpios = < 2 GPIO_ACTIVE_HIGH>;
+
+   port {
+   edp0_connector_in: endpoint {
+   remote-endpoint = <_dp2_phy_out>;
+   };
+   };
+   };
+
+   edp1-connector {
+   compatible = "dp-connector";
+   label = "EDP1";
+   type = "mini";
+
+   hpd-gpios = < 3 GPIO_ACTIVE_HIGH>;
+
+   port {
+   edp1_connector_in: endpoint {
+   remote-endpoint = <_dp3_phy_out>;
+   };
+   };
+   };
+
+   edp2-connector {
+   compatible = "dp-connector";
+   label = "EDP2";
+   type = "mini";
+
+   hpd-gpios = < 7 GPIO_ACTIVE_HIGH>;
+
+   port {
+   edp2_connector_in: endpoint {
+   remote-endpoint = <_dp2_phy_out>;
+   };
+   };
+   };
+
+   edp3-connector {
+   compatible = "dp-connector";
+   label = "EDP3";
+   type = "mini";
+
+   hpd-gpios = < 6 GPIO_ACTIVE_HIGH>;
+
+   port {
+   edp3_connector_in: endpoint {
+   remote-endpoint = <_dp3_phy_out>;
+   };
+   };
+   };
  };
  
  _rsc {

@@ -163,13 +247,168 @@ vreg_l7g: ldo7 {
  
  		vreg_l8g: ldo8 {

regulator-name = "vreg_l8g";
-   regulator-min-microvolt = <88>;
-   regulator-max-microvolt = <88>;
+   regulator-min-microvolt = <912000>;
+   regulator-max-microvolt = <912000>;
+   regulator-initial-mode = ;
+   };
+
+   vreg_l11g: ldo11 {
+   regulator-name = "vreg_l11g";
+   regulator-min-microvolt = <912000>;
+   regulator-max-microvolt = <912000>;
regulator-initial-mode = ;
};
};
  };
  
+ {

+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_dp2 {
+   status = "okay";

status should go last.


+
+   data-lanes = <0 1 2 3>;
+
+   ports {
+   port@1 {
+   reg = <1>;
+   mdss0_dp2_phy_out: endpoint {
That's quite a lot of indentation.. couldn't these endpoints be defined 
in the SoC DT?


Konrad

+   remote-endpoint = <_connector_in>;
+   };
+   };
+   };
+};
+
+_dp2_phy {
+   status = "okay";
+
+   vdda-phy-supply = <_l8g>;
+   vdda-pll-supply = <_l3g>;
+};
+
+_dp3 {
+   status = "okay";
+
+   data-lanes = <0 1 2 3>;
+
+   ports {
+   port@1 {
+   reg = <1>;
+   mdss0_dp3_phy_out: endpoint {
+   remote-endpoint = <_connector_in>;
+   };
+   };
+   };
+};
+
+_dp3_phy {
+   status = "okay";

Re: [PATCH v8 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

2022-12-05 Thread Rodrigo Vivi

On Fri, Dec 02, 2022 at 03:28:21PM -0800, Alan Previn wrote:
> Starting with MTL, there will be two GT-tiles, a render and media
> tile. PXP as a service for supporting workloads with protected
> contexts and protected buffers can be subscribed by process
> workloads on any tile. However, depending on the platform,
> only one of the tiles is used for control events pertaining to PXP
> operation (such as creating the arbitration session and session
> tear-down).
> 
> PXP as a global feature is accessible via batch buffer instructions
> on any engine/tile and the coherency across tiles is handled implicitly
> by the HW. In fact, for the foreseeable future, we are expecting this
> single-control-tile for the PXP subsystem.
> 
> In MTL, it's the standalone media tile (not the root tile) because
> it contains the VDBOX and KCR engine (among the assets PXP relies on
> for those events).
> 
> Looking at the current code design, each tile is represented by the
> intel_gt structure while the intel_pxp structure currently hangs off the
> intel_gt structure.
> 
> Keeping the intel_pxp structure within the intel_gt structure makes some
> internal functionalities more straight forward but adds code complexity to
> code readibility and maintainibility to many external-to-pxp subsystems
> which may need to pick the correct intel_gt structure. An example of this
> would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
> which should be viewed as a global level inquiry, not a per-gt inquiry.
> 
> That said, this series promotes the intel_pxp structure into the
> drm_i915_private structure making it a top-level subsystem and the PXP
> subsystem will select the control gt internally and keep a pointer to
> it for internal reference.
> 
> Changes from prior revs:
>v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
>  through out instead of local variable newpxp. (Rodrigo)
>- In the case intel_pxp_fini is called during driver unload but
>  after i915 loading failed without pxp being allocated, check
>  i915->pxp before referencing it. (Alan)
>v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
>  because : [1] introduction of 'ctrl_gt' means we correct this
>  for MTL's upcoming series now. [2] Also, this has little impact
>  globally as its only used by PXP-internal callers at the moment.
>- Change intel_pxp_init/fini to take in i915 as its input to avoid
>  ptr-to-ptr in init/fini calls.(Jani).
>- Remove the backpointer from pxp->i915 since we can use
>  pxp->ctrl_gt->i915 if we need it. (Rodrigo).
>v5: - Switch from series to single patch (Rodrigo).
>- change function name from pxp_get_kcr_owner_gt to
>  pxp_get_ctrl_gt.
>- Fix CI BAT failure by removing redundant call to intel_pxp_fini
>  from driver-remove.
>- NOTE: remaining open still persists on using ptr-to-ptr
>  and back-ptr.
>v4: - Instead of maintaining intel_pxp as an intel_gt structure member
>  and creating a number of convoluted helpers that takes in i915 as
>  input and redirects to the correct intel_gt or takes any intel_gt
>  and internally replaces with the correct intel_gt, promote it to
>  be a top-level i915 structure.
>v3: - Rename gt level helper functions to "intel_pxp_is_enabled/
>  supported/ active_on_gt" (Daniele)
>- Upgrade _gt_supports_pxp to replace what was intel_gtpxp_is
>  supported as the new intel_pxp_is_supported_on_gt to check for
>  PXP feature support vs the tee support for huc authentication.
>  Fix pxp-debugfs-registration to use only the former to decide
>  support. (Daniele)
>- Couple minor optimizations.
>v2: - Avoid introduction of new device info or gt variables and use
>  existing checks / macros to differentiate the correct GT->PXP
>  control ownership (Daniele Ceraolo Spurio)
>- Don't reuse the updated global-checkers for per-GT callers (such
>  as other files within PXP) to avoid unnecessary GT-reparsing,
>  expose a replacement helper like the prior ones. (Daniele).
>v1: - Add one more patch to the series for the intel_pxp suspend/resume
>  for similar refactoring
> 
> References: 
> https://patchwork.freedesktop.org/patch/msgid/20221202011407.4068371-1-alan.previn.teres.ale...@intel.com
> Signed-off-by: Alan Previn 
> ---
>  .../drm/i915/display/skl_universal_plane.c|  2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   |  6 +-
>  drivers/gpu/drm/i915/gem/i915_gem_create.c|  2 +-
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  2 +-
>  drivers/gpu/drm/i915/gt/intel_gt.c|  5 --
>  drivers/gpu/drm/i915/gt/intel_gt_debugfs.c|  1 -
>  drivers/gpu/drm/i915/gt/intel_gt_irq.c|  2 +-
>  drivers/gpu/drm/i915/gt/intel_gt_pm.c |  8 --
>

[PATCH v7 5/5] drm/msm/dp: add support of max dp link rate

By default, HBR2 (5.4G) is the max link link be supported. This patch add
the capability to support max link rate at HBR3 (8.1G).

Changes in v2:
-- add max link rate from dtsi

Changes in v3:
-- parser max_data_lanes and max_dp_link_rate from dp_out endpoint

Changes in v4:
-- delete unnecessary pr_err

Changes in v5:
-- split parser function into different patch

Signed-off-by: Kuogee Hsieh 
Reviewed-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/dp/dp_display.c | 4 
 drivers/gpu/drm/msm/dp/dp_panel.c   | 7 ---
 drivers/gpu/drm/msm/dp/dp_panel.h   | 1 +
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index bfd0aef..edee550 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -390,6 +390,10 @@ static int dp_display_process_hpd_high(struct 
dp_display_private *dp)
struct edid *edid;
 
dp->panel->max_dp_lanes = dp->parser->max_dp_lanes;
+   dp->panel->max_dp_link_rate = dp->parser->max_dp_link_rate;
+
+   drm_dbg_dp(dp->drm_dev, "max_lanes=%d max_link_rate=%d\n",
+   dp->panel->max_dp_lanes, dp->panel->max_dp_link_rate);
 
rc = dp_panel_read_sink_caps(dp->panel, dp->dp_display.connector);
if (rc)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c 
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 5149ceb..933fa9c 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -75,12 +75,13 @@ static int dp_panel_read_dpcd(struct dp_panel *dp_panel)
link_info->rate = drm_dp_bw_code_to_link_rate(dpcd[DP_MAX_LINK_RATE]);
link_info->num_lanes = dpcd[DP_MAX_LANE_COUNT] & DP_MAX_LANE_COUNT_MASK;
 
+   /* Limit data lanes from data-lanes of endpoint properity of dtsi */
if (link_info->num_lanes > dp_panel->max_dp_lanes)
link_info->num_lanes = dp_panel->max_dp_lanes;
 
-   /* Limit support upto HBR2 until HBR3 support is added */
-   if (link_info->rate >= (drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4)))
-   link_info->rate = drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4);
+   /* Limit link rate from link-frequencies of endpoint properity of dtsi 
*/
+   if (link_info->rate > dp_panel->max_dp_link_rate)
+   link_info->rate = dp_panel->max_dp_link_rate;
 
drm_dbg_dp(panel->drm_dev, "version: %d.%d\n", major, minor);
drm_dbg_dp(panel->drm_dev, "link_rate=%d\n", link_info->rate);
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.h 
b/drivers/gpu/drm/msm/dp/dp_panel.h
index d861197a..f04d021 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.h
+++ b/drivers/gpu/drm/msm/dp/dp_panel.h
@@ -50,6 +50,7 @@ struct dp_panel {
 
u32 vic;
u32 max_dp_lanes;
+   u32 max_dp_link_rate;
 
u32 max_bw_code;
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v7 4/5] drm/msm/dp: parser link-frequencies as property of dp_out endpoint

Add capability to parser and retrieve max DP link supported rate from
link-frequencies property of dp_out endpoint.

Changes in v6:
-- second patch after split parser patch into two patches

Changes in v7:
-- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate

Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/dp/dp_parser.c | 19 +--
 drivers/gpu/drm/msm/dp/dp_parser.h |  2 ++
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c 
b/drivers/gpu/drm/msm/dp/dp_parser.c
index b5f7e70..037dad8 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -94,15 +94,28 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
 static int dp_parser_misc(struct dp_parser *parser)
 {
struct device_node *of_node = parser->pdev->dev.of_node;
+   struct device_node *endpoint;
+   u64 frequency;
int cnt;
 
/*
 * data-lanes is the property of dp_out endpoint
 */
cnt = drm_of_get_data_lanes_count_ep(of_node, 1, 0, 1, 
DP_MAX_NUM_DP_LANES);
-   if (cnt > 0)
+   if (cnt > 0) {
parser->max_dp_lanes = cnt;
-   else {
+
+   endpoint = of_graph_get_endpoint_by_regs(of_node, 1, 0); /* 
port@1 */
+   cnt = of_property_count_u64_elems(endpoint, "link-frequencies");
+   if (cnt > 0) {
+   of_property_read_u64_index(endpoint, "link-frequencies",
+   cnt - 1, );
+   frequency /= 10;/* from symbol rate to link 
rate */
+   parser->max_dp_link_rate = (frequency / 1000); /* kbits 
*/
+   } else {
+   parser->max_dp_link_rate = DP_LINK_RATE_HBR2; /* 54 
khz */
+   }
+   } else {
/*
 * legacy code, data-lanes is the property of mdss_dp node
 */
@@ -111,6 +124,8 @@ static int dp_parser_misc(struct dp_parser *parser)
parser->max_dp_lanes = cnt;
else
parser->max_dp_lanes = DP_MAX_NUM_DP_LANES; /* 4 lanes 
*/
+
+   parser->max_dp_link_rate = DP_LINK_RATE_HBR2; /* 54 khz */
}
 
return 0;
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h 
b/drivers/gpu/drm/msm/dp/dp_parser.h
index 866c1a8..3ddf639 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -15,6 +15,7 @@
 #define DP_LABEL "MDSS DP DISPLAY"
 #define DP_MAX_PIXEL_CLK_KHZ   675000
 #define DP_MAX_NUM_DP_LANES4
+#define DP_LINK_RATE_HBR2   54
 
 enum dp_pm_type {
DP_CORE_PM,
@@ -119,6 +120,7 @@ struct dp_parser {
struct dp_io io;
struct dp_display_data disp_data;
u32 max_dp_lanes;
+   u32 max_dp_link_rate;
struct drm_bridge *next_bridge;
 
int (*parse)(struct dp_parser *parser);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v7 3/5] drm/msm/dp: parser data-lanes as property of dp_out endpoint

Add capability to parser data-lanes as property of dp_out endpoint.
Also retain the original capability to parser data-lanes as property
of mdss_dp node to handle legacy case.

Changes in v6:
-- first patch after split parser patch into two

Changes in v7:
-- check "data-lanes" from endpoint first

Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/dp/dp_parser.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c 
b/drivers/gpu/drm/msm/dp/dp_parser.c
index dd73221..b5f7e70 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -94,16 +94,25 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
 static int dp_parser_misc(struct dp_parser *parser)
 {
struct device_node *of_node = parser->pdev->dev.of_node;
-   int len;
-
-   len = drm_of_get_data_lanes_count(of_node, 1, DP_MAX_NUM_DP_LANES);
-   if (len < 0) {
-   DRM_WARN("Invalid property \"data-lanes\", default max DP lanes 
= %d\n",
-DP_MAX_NUM_DP_LANES);
-   len = DP_MAX_NUM_DP_LANES;
+   int cnt;
+
+   /*
+* data-lanes is the property of dp_out endpoint
+*/
+   cnt = drm_of_get_data_lanes_count_ep(of_node, 1, 0, 1, 
DP_MAX_NUM_DP_LANES);
+   if (cnt > 0)
+   parser->max_dp_lanes = cnt;
+   else {
+   /*
+* legacy code, data-lanes is the property of mdss_dp node
+*/
+   cnt = drm_of_get_data_lanes_count(of_node, 1, 
DP_MAX_NUM_DP_LANES);
+   if (cnt > 0)
+   parser->max_dp_lanes = cnt;
+   else
+   parser->max_dp_lanes = DP_MAX_NUM_DP_LANES; /* 4 lanes 
*/
}
 
-   parser->max_dp_lanes = len;
return 0;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v7 2/5] dt-bindings: msm/dp: add data-lanes and link-frequencies property

Add both data-lanes and link-frequencies property into endpoint

changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property

Signed-off-by: Kuogee Hsieh 
---
 .../bindings/display/msm/dp-controller.yaml| 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml 
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index f2515af..13d2c3c 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -79,12 +79,6 @@ properties:
   aux-bus:
 $ref: /schemas/display/dp-aux-bus.yaml#
 
-  data-lanes:
-$ref: /schemas/types.yaml#/definitions/uint32-array
-minItems: 1
-maxItems: 4
-items:
-  maximum: 3
 
   "#sound-dai-cells":
 const: 0
@@ -105,6 +99,19 @@ properties:
 $ref: /schemas/graph.yaml#/properties/port
 description: Output endpoint of the controller
 
+properties:
+  endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+
+  properties:
+data-lanes:
+  $ref: /schemas/types.yaml#/definitions/uint32-array
+
+link-frequencies:
+  $ref: /schemas/types.yaml#/definitions/uint64-array
+
+  additionalProperties: false
+
 required:
   - compatible
   - reg
@@ -193,6 +200,9 @@ examples:
 reg = <1>;
 endpoint {
 remote-endpoint = <>;
+data-lanes = <1 2>;
+link-frequencies = /bits/ 64 <162000 27
+  54 81>;
 };
 };
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v7 1/5] arm64: dts: qcom: add data-lanes and link-freuencies into dp_out endpoint

Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.

Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add _out to sc7180-trogdor.dtsi and sc7280-herobrine.dtsi

Changes in v6:
-- add data-lanes and link-frequencies to yaml

Changes in v7:
-- change 16000 to 162000
-- separate yaml to different patch

Signed-off-by: Kuogee Hsieh 
---
 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi   | 6 +-
 arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi 
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index eae22e6..0ad50e2 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -814,7 +814,11 @@ hp_i2c:  {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
-   data-lanes = <0 1>;
+};
+
+_out {
+data-lanes = <0  1>;
+link-frequencies = /bits/ 64 <16200 27000 54000>;
 };
 
 _adc {
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi 
b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
index c11e371..3c7a9d8 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -442,7 +442,11 @@ ap_i2c_tpm:  {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
-   data-lanes = <0 1>;
+};
+
+_out {
+   data-lanes = <0  1>;
+   link-frequencies = /bits/ 64 <162000 27 54 
81>;
 };
 
 _mdp {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v7 0/5] Add data-lanes and link-frequencies to dp_out endpoint

Add DP both data-lanes and link-frequencies property to dp_out endpoint and 
support
functions to DP driver.

Kuogee Hsieh (5):
  arm64: dts: qcom: add data-lanes and link-freuencies into dp_out
endpoint
  dt-bindings: msm/dp: add data-lanes and link-frequencies property
  drm/msm/dp: parser data-lanes as property of dp_out endpoint
  drm/msm/dp: parser link-frequencies as property of dp_out endpoint
  drm/msm/dp: add support of max dp link rate

 .../bindings/display/msm/dp-controller.yaml| 22 +
 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi   |  6 +++-
 arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi |  6 +++-
 drivers/gpu/drm/msm/dp/dp_display.c|  4 +++
 drivers/gpu/drm/msm/dp/dp_panel.c  |  7 ++--
 drivers/gpu/drm/msm/dp/dp_panel.h  |  1 +
 drivers/gpu/drm/msm/dp/dp_parser.c | 38 ++
 drivers/gpu/drm/msm/dp/dp_parser.h |  2 ++
 8 files changed, 68 insertions(+), 18 deletions(-)

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

[PATCH v4 13/13] arm64: dts: qcom: sa8295-adp: Enable DP instances

From: Bjorn Andersson 

The SA8295P ADP has, among other interfaces, six MiniDP connectors which
are connected to MDSS0 DP2 and DP3, and MDSS1 DP0 through DP3.

Enable Display Clock controllers, MDSS instanced, MDPs, DP controllers,
DP PHYs and link them all together.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v3:
- None

 arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 243 ++-
 1 file changed, 241 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts 
b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
index 6c29d7d757e0..d55c8c5304cc 100644
--- a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
+++ b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
@@ -23,6 +23,90 @@ aliases {
chosen {
stdout-path = "serial0:115200n8";
};
+
+   dp2-connector {
+   compatible = "dp-connector";
+   label = "DP2";
+   type = "mini";
+
+   hpd-gpios = < 20 GPIO_ACTIVE_HIGH>;
+
+   port {
+   dp2_connector_in: endpoint {
+   remote-endpoint = <_dp0_phy_out>;
+   };
+   };
+   };
+
+   dp3-connector {
+   compatible = "dp-connector";
+   label = "DP3";
+   type = "mini";
+
+   hpd-gpios = < 45 GPIO_ACTIVE_HIGH>;
+
+   port {
+   dp3_connector_in: endpoint {
+   remote-endpoint = <_dp1_phy_out>;
+   };
+   };
+   };
+
+   edp0-connector {
+   compatible = "dp-connector";
+   label = "EDP0";
+   type = "mini";
+
+   hpd-gpios = < 2 GPIO_ACTIVE_HIGH>;
+
+   port {
+   edp0_connector_in: endpoint {
+   remote-endpoint = <_dp2_phy_out>;
+   };
+   };
+   };
+
+   edp1-connector {
+   compatible = "dp-connector";
+   label = "EDP1";
+   type = "mini";
+
+   hpd-gpios = < 3 GPIO_ACTIVE_HIGH>;
+
+   port {
+   edp1_connector_in: endpoint {
+   remote-endpoint = <_dp3_phy_out>;
+   };
+   };
+   };
+
+   edp2-connector {
+   compatible = "dp-connector";
+   label = "EDP2";
+   type = "mini";
+
+   hpd-gpios = < 7 GPIO_ACTIVE_HIGH>;
+
+   port {
+   edp2_connector_in: endpoint {
+   remote-endpoint = <_dp2_phy_out>;
+   };
+   };
+   };
+
+   edp3-connector {
+   compatible = "dp-connector";
+   label = "EDP3";
+   type = "mini";
+
+   hpd-gpios = < 6 GPIO_ACTIVE_HIGH>;
+
+   port {
+   edp3_connector_in: endpoint {
+   remote-endpoint = <_dp3_phy_out>;
+   };
+   };
+   };
 };
 
 _rsc {
@@ -163,13 +247,168 @@ vreg_l7g: ldo7 {
 
vreg_l8g: ldo8 {
regulator-name = "vreg_l8g";
-   regulator-min-microvolt = <88>;
-   regulator-max-microvolt = <88>;
+   regulator-min-microvolt = <912000>;
+   regulator-max-microvolt = <912000>;
+   regulator-initial-mode = ;
+   };
+
+   vreg_l11g: ldo11 {
+   regulator-name = "vreg_l11g";
+   regulator-min-microvolt = <912000>;
+   regulator-max-microvolt = <912000>;
regulator-initial-mode = ;
};
};
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_dp2 {
+   status = "okay";
+
+   data-lanes = <0 1 2 3>;
+
+   ports {
+   port@1 {
+   reg = <1>;
+   mdss0_dp2_phy_out: endpoint {
+   remote-endpoint = <_connector_in>;
+   };
+   };
+   };
+};
+
+_dp2_phy {
+   status = "okay";
+
+   vdda-phy-supply = <_l8g>;
+   vdda-pll-supply = <_l3g>;
+};
+
+_dp3 {
+   status = "okay";
+
+   data-lanes = <0 1 2 3>;
+
+   ports {
+   port@1 {
+   reg = <1>;
+   mdss0_dp3_phy_out: endpoint {
+   remote-endpoint = <_connector_in>;
+   };
+   };
+   };
+};
+
+_dp3_phy {
+   status = "okay";
+
+   vdda-phy-supply = <_l8g>;
+   vdda-pll-supply = <_l3g>;
+};
+
+ {
+   status = "okay";
+};
+
+_dp0 {
+   status = "okay";
+
+   data-lanes = <0 1

[PATCH v4 09/13] drm/msm/dp: Don't enable HPD interrupts for edp

From: Bjorn Andersson 

Most instances where HPD interrupts are masked and unmasked are guareded
by the presence of an EDP panel being connected, but not all. Extend
this to cover the last few places, as HPD interrupt handling is not used
for the EDP case.

Signed-off-by: Bjorn Andersson 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Bjorn Andersson 
---

Changes since v3:
- None

 drivers/gpu/drm/msm/dp/dp_display.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index 17fcf8cd84cd..bb92c33beff8 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -610,8 +610,10 @@ static int dp_hpd_plug_handle(struct dp_display_private 
*dp, u32 data)
}
 
/* enable HDP irq_hpd/replug interrupt */
-   dp_catalog_hpd_config_intr(dp->catalog,
-   DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, true);
+   if (!dp->dp_display.is_edp)
+   dp_catalog_hpd_config_intr(dp->catalog,
+  DP_DP_IRQ_HPD_INT_MASK | 
DP_DP_HPD_REPLUG_INT_MASK,
+  true);
 
drm_dbg_dp(dp->drm_dev, "After, type=%d hpd_state=%d\n",
dp->dp_display.connector_type, state);
@@ -651,8 +653,10 @@ static int dp_hpd_unplug_handle(struct dp_display_private 
*dp, u32 data)
dp->dp_display.connector_type, state);
 
/* disable irq_hpd/replug interrupts */
-   dp_catalog_hpd_config_intr(dp->catalog,
-   DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, false);
+   if (!dp->dp_display.is_edp)
+   dp_catalog_hpd_config_intr(dp->catalog,
+  DP_DP_IRQ_HPD_INT_MASK | 
DP_DP_HPD_REPLUG_INT_MASK,
+  false);
 
/* unplugged, no more irq_hpd handle */
dp_del_event(dp, EV_IRQ_HPD_INT);
@@ -678,7 +682,8 @@ static int dp_hpd_unplug_handle(struct dp_display_private 
*dp, u32 data)
}
 
/* disable HPD plug interrupts */
-   dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, false);
+   if (!dp->dp_display.is_edp)
+   dp_catalog_hpd_config_intr(dp->catalog, 
DP_DP_HPD_PLUG_INT_MASK, false);
 
/*
 * We don't need separate work for disconnect as
-- 
2.37.3

[PATCH v4 11/13] arm64: dts: qcom: sc8280xp: Define some of the display blocks