Re: [PATCH v2 1/3] dt-bindings: display: msm: mdss-common: describe additional block resets

[Qianhui Xu]

Hi Konrad,

One note on how this mail was written, since it matters for how you read
it: I work on this board alone and my English is not good enough to
write upstream mail unaided, so I draft with an AI assistant and edit it
myself. The content, the measurements and every decision in it are mine.

you are right, and I will drop it.

MDSS RSC is not part of the MDSS block: the RSC sits in its own node
(apps_rsc at 0x16500000 on SM8750), and the only reason I pulled
DISP_CC_MDSS_RSCC_BCR into the mdss resets list is that the reset bit
happens to be generated inside dispcc. That is a register-map argument, not
a block-ownership argument, and the block-ownership one is the one that
decides which node owns a reset.

What v3 will look like, so nobody has to guess:

 - mdss-common.yaml: resets keeps "minItems: 1" with two array entries,
   MDSS core and MDSS core INT2. The RSC entry goes away, and the
   commit message says why.
 - qcom,sm8750-mdss.yaml and sm8750.dtsi: resets drops to CORE and
   CORE_INT2.
 - drm/msm/mdss: unchanged, it still drives the whole array from DT.

One thing I would like to flag rather than paper over: the reason RSCC was
in the list at all is empirical. This board is handed over with the display
block running, and on the vendor stack both a warm reset and a cold boot can
end in the same panel-init failure (command DMA timeout, L1/L2 error
counters non-zero). Resetting MDSS core + core INT2 + RSC is what makes the
failure go away on that stack, and I have not yet isolated which of the
three is load-bearing; I have only ever measured them together. So after
dropping RSCC from the binding I will re-measure with CORE + INT2 alone. If
that turns out not to be enough, the RSC reset will be driven from the RSC
device, where you are saying it belongs, and not from mdss - I am not
proposing to add it back here.

Note also that the reset ordering caveat from the cover letter stands
independently of this: mdss consumes dispcc clocks, so dispcc has to have
programmed the PLLs before msm_mdss_reset() runs. I have no measurement for
"block reset after the PLLs are up does not disturb them" beyond the vendor
stack behaviour; that is still the open point, and if you think it should be
answered before this series goes anywhere, say so and I will hold it.

Thanks,
Qianhui Xu