[RFC] drm/msm/dpu: glymur (DPU 12.2) second DSC block at +0x84000?

[RFC] drm/msm/dpu: glymur (DPU 12.2) second DSC block at +0x84000?

[Christian Cortner]

Hello,

This is a question about DPU 12.2 (glymur / Snapdragon X2E) rather than a
patch. Short version: on the internal eDP panel, DSC over the DP interface
gets as far as the sink accepting the stream and displaying nothing, and the
vendor's shipping Windows driver suggests the DPU has a DSC register block
that dpu1 does not model. I would like to know whether that block exists,
and if so how it is clocked.

Platform -------- ASUS Zenbook A16 UX3607OA, glymur / X2E, DPU 12.2
(catalog/dpu_12_2_glymur.h). Panel: samsung,atna33xc20, 2880x1800, 10 bpc,
120 Hz, eDP. Link: 4 lanes, HBR3 (810000). DSC 1.2, 2 slices of 1440,
slice_chunk 1440, target 8 bpp. Tree: 7.3-rc based, with a local DP+DSC
implementation (upstream has no DP+DSC path).

What is verified, so it is not the DP layer
-------------------------------------------
  - PPS packed and written to 0x184..0x1fc, byte-identical to what the
  vendor Windows driver writes on the same machine (HB 0x7f1000, per-byte
  ECC parity, 22 PPS words, 7 parity words).
  - COMPRESSION_MODE_CTRL (link block +0x180) written; read-back matches
  the written value, so +0x180 is the right register on this silicon.
  - DTO programmed (count = pclk_per_line; ratios 1/3, 8/30 and 5/12 all
  tried).
  - Data width 480 / 960 / 1440 tried; common mode with and without
  MULTIPLEX.
  - Sink accepts: DPCD 0x160 reads back 0x01 after enable.
  - DPU side reports compression active: 2 DSC blocks, common_mode 0x7,
  bpc 10, bpp 8, CTL_DSC_ACTIVE set.
  - Panel stays dark; the compositor re-prepares DSC 148-264 times per
  boot (12 measured boots, median 169).

What the vendor driver does --------------------------- Target:
qcdxkm8480.sys, PE ARM64, sha256
cc4c7ff9d09bb3aabb46e24937a66a6d927f28d0189e7517d5f53afa9e98afe7 - the
display KMD shipped for this exact machine. Decompiled with Ghidra.

  Its DSC page writes (FUN_1401ce660, called from FUN_1401c2508):

      0x000  read-modify-write, mask 0xffffffc0, 6 bits  -> COMMON_MODE
      0x004  one enable bit                              -> ENC
      0x008  value selected BY LINK RATE                 -> PICTURE
             RBR 162000 -> 0x300, HBR 270000 -> 0x301,
             HBR2 540000 -> 0x202, HBR3 810000 -> 0x103
      0x00C  written                                     -> SLICE
      0x044, 0x074, 0x084                             -> RC thresh / QP

  That is the v1 map in dpu_hw_dsc.c (COMMON_MODE 0x00, ENC 0x04, PICTURE
  0x08, SLICE 0x0C, RC_BUF_THRESH 0x3C.., RANGE_MIN_QP 0x74). The vendor
  driver writes nothing at 0x30/0x34/0x38, which are DSC_MAIN_CONF /
  DSC_PICTURE_SIZE / DSC_SLICE_SIZE in the v1.2 map.

What we measured on our side ----------------------------
  - Our encoder binds dpu_hw_dsc_init_1_2 with the sm8750 sub-block
  layout: enc 0x100 / 0x200, ctl 0xF00 / 0xF80, CMN_MAIN_CNF at 0x000. At
  runtime both DSC blocks sit on MDP+0x80000 with enc sub-blocks 0x100 and
  0x200.
  - Writing 0x004 / 0x008 on that page and reading them back returns
  0x00000000: those offsets are holes on the page we program, so the
  registers the vendor driver writes are not on our DSC page.
  - MDP+0x84000 and +0x85000 are inside the mapped DPU window (mdp:
  0xae01000, size 0x93000) but no catalog entry, for any SoC in the tree,
  describes a block there; the DT declares only "mdp" and "vbif".
  - A read at MDP+0x84000 hangs the machine - no panic, no log, just a bus
  stall - which is the usual symptom of touching a block whose clock/power
  domain is off.
  - Neither our dispcc nor the vendor's dispcc-glymur has a DSC-specific
  clock, so gating would have to go through DISP_CC_MDSS_CORE_GDSC or an
  MDP power domain.

Questions ---------
  1. Does DPU 12.2 in glymur have a second DSC encoder (or a v1-style DSC
  register block) at MDP+0x84000 / +0x85000 that the "dce" blocks do not
  describe?
  2. If yes, what enables it (clock, GDSC, power domain) and what is its
  register layout?
  3. If no, is the v1.2 "dce" block the engine that actually feeds
  INTF_DP, and is there a documented block-to-pingpong pairing for DP that
  we are missing?

I can supply register dumps, the decompiled snippets above, or any logs, and
I am happy to test a patch that models the block if someone can tell me what
it is.

Thanks,
Christian