Re: [PATCH v2] platform/x86: int3472: Use actual clock frequency for DSM method

[Fernando Rimoli <fernandorimoli11@gmail.com>]

Hi Hao,

A data point from a second machine: a Surface Pro 9 (Alder Lake-P, IPU6,
8086:465d). Its infrared sensor is the same ST VD55G0 (SMO55F0) that
Sergey reported on for the Surface Pro 11, with 24 MHz in its SSDB, and
INT3472 enables its clock through the _DSM. Without your patch it shows
the same symptom. With Sergey's vd55g0 driver at 396 MHz, every mode
runs at 47.31 fps where the controls give 59.14, and at 600 MHz at 57.20
against 71.49. The driver this machine used before behaves the same way
at both frequencies, so everything the sensor derives runs at four
fifths.

With your v2 applied to the int3472 module and loaded from a cold boot,
nothing changes. Sergey's driver still runs at 57.20 fps at 600 MHz
where its controls give 71.49, and the previous driver still at 57.60.
clk_summary reports INT3472:01-clk at 24000000, so the patch does pass 3
to the _DSM here; this firmware just does not seem to act on it. The
other two cameras, whose SSDBs ask for 19.2 MHz, are unchanged (front
28.64 fps, rear 29.95 fps), so nothing regresses.

So on this machine the patch is harmless but does not fix the clock. I
cannot tell from here whether the Alder Lake _DSM takes a different
value for 24 MHz or only produces 19.2 MHz. If you know of a way to ask
it, I can test it.

Fernando