[Regression v3] SM8750: cambistmclkcc + camcc together hard-reset the SoC on display blank

[Qianhui Xu]

Hi,

Third revision of a regression report about SM8750 (Lenovo Y700 4th gen tablet,
TB322FC, board dts sm8750-lenovo-elden) being hard-reset by the camera clock
controllers when the display is blanked.

DELIVERY NOTE (please read): the two earlier revisions (2026-10-08 and
2026-10-10) do not appear in the linux-arm-msm archive, and neither does any
[Regression] mail from this address. If an older copy of this report reaches you
later from a moderation queue, please ignore it and review this revision: the
data below supersedes it, and it also withdraws two of its claims.

### Corrections to the earlier revisions

1. "The trigger is the cambistmclkcc block specifically" is wrong. With a strict
   user-space gate on the same kernel (modules probed, all clocks unprepared, no
   consumers, no camss/cci/regulator drivers loaded):

     cam = 0                     blank, hold 60 s, resume  -> alive
     camcc-sm8750 only           blank, hold, resume       -> alive
     cambistmclkcc-sm8750 only   blank, hold, resume       -> alive
     both loaded                 first real blank           -> SoC reset

   The earlier single-module results were gate artifacts: our older blank test
   did not verify that the panel actually left the active state.

2. The "bind cambistmclkcc to MX only" workaround (be79b256d, attached to the
   previous revision) is withdrawn. We rebuilt the device tree only, restoring
   the upstream binding (power-domains = <&rpmhpd RPMHPD_MMCX>, <&rpmhpd
   RPMHPD_MX> + low_svs) and verified that the control build reproduces our
   baseline DTB byte for byte. The SoC still resets, with an RPMh vote tail
   identical to the MX-only build. The power-domain binding is not the lever,
   and our "half-built bare clock controller collides with a collapsing rail"
   story is therefore not confirmed - please treat it as an open question, not
   as a root cause. No fix patch is attached to this revision.

### Death signature (what we can measure)

- SoC level reset, not a software crash: no pstore and no kernel message, the
  USB PHY drops, and the device reboots by itself into the flashed OS. In the
  five death events we instrumented today the recovery was always automatic,
  28-42 s after the USB disconnect; two of them were confirmed by an SSH login
  showing a new boot_id.
- PMIC: dumping all SPMI slaves through debugfs before and after the event shows
  the PON register block (0x1300..0x13ff of the main PMIC) byte-identical, i.e.
  no latched PON reason and no fault bit. The SoC hardware watchdog is disabled
  ("Hard watchdog permanently disabled"), so this is not a watchdog reset.
- Tracing: the last frames are the compositor enabling disp_cc_mdss_* clocks
  (blank direction). On a bench where the panel did not initialize, the death
  moves to the resume direction (GPU domain bring-up) - the death point follows
  the display power transition.
- Interconnect: BCM/RPMh votes during a dying blank are identical in address and
  shape to a surviving blank (MC0, SH0, SH1, ACV) and icc_set_bw paths look
  normal, so this does not look like a NoC bandwidth vote problem.
- Pinning the GPU power/control to "on" (no GPU runtime resume on resume) does
  not prevent the reset.

### Reproduction

- mainline 7.2 based tree, no vendor patches affecting clocks or genpd.
- modprobe cambistmclkcc-sm8750 and camcc-sm8750.
- real display blank from userspace (org.gnome.ScreenSaver.SetActive(true),
  DSI DPMS off; no s2idle or system suspend involved) -> reset within seconds.
- on benches where the panel fails to initialize, the same reset is provoked by
  the resume direction instead (SetActive(false)).

### Questions

1. Is cambistmclkcc supposed to be usable as a bare clock controller with no
   GDSC and no consumer? The failure needs BOTH camcc and cambistmclkcc to be
   probed. Is there a hardware coupling that requires the camcc side to be
   powered while the camera BIST block keeps its AHB clock and PLL programmed?
   (The maili/hawi camss RFC adds both nodes together, which makes us suspect
   they are not independent on this generation.)
2. Is there a documented ordering constraint between the camera BIST block and
   display power/clock collapse (dispcc) on the shared MMCX/MX domains? Any
   display power transition, blank or resume, with both controllers loaded
   takes the SoC down instantly, and we cannot see that interaction in the clock
   or genpd code paths.
3. Which reset-reason source exists on SM8750 that we could read from Linux after
   such an event? PON latches nothing and there is no pstore. Is there an AOP or
   CPUCp crash/health register, or a smem scatter area, that records
   "PS_HOLD dropped" versus "cold reset"?
4. Until the root cause is known, what default would you recommend for
   distributions: an always-on vote for cambistmclkcc, a required vdd_mx supply
   binding, or deferring cambistmclkcc probe until the display is off? We can
   test any of these on hardware and report back.

We can run further experiments (registers, traces, chip revisions) on request.

Thanks,
Xuqianhui (elden bring-up, Lenovo Y700 Gen4 / SM8750)