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

[Fernando Rimoli]

Hi Sergey, Hao,

On 25/10/2026 16:26, Sergey Lebedev wrote:
> Fernando, a run with 0 in place of 3 would tell, and your own DSDT
> whether it still matches the dump.

It takes 0. The DSDT on this machine (BIOS 23.102.143, 11/25/2025) still
matches the dump: the clock _DSM on ICL0, ICL1 and ICL2 calls ICLK.CLKC
with Arg3[1] and then ICLK.CLKF with Arg3[2], and CLKF does

	CLKx = (CLKx & ~1) | Arg1

with nothing masking Arg1, so 3 also sets the enable bit again on the
way down, as you say.

I changed the int3472 discrete module to pass 0 when the SSDB asks for
24 MHz and 1 otherwise, so the two 19.2 MHz cameras get what they get
today, and swapped it in at runtime (the _DSM runs on every clock
prepare). With the previous driver at 600 MHz, the infrared sensor goes
from 57.60 fps to 72.00 fps, which is 57.60 times five fourths, and back
to 57.60 with the unmodified module loaded again. So 0 gives 24 MHz
here, and 1 and 3 both give 19.2 MHz.

So the value depends on the generation: 3 where CLKF takes two bits, as
on the Surface Pro 11, and 0 on Alder Lake, where coreboot's Tiger Lake
and Alder Lake camera_clock_ctl.asl document bit 0 as "0: 24MHz, 1:
19.2MHz". v3 would need to pick it per platform. I can test it on the
Surface Pro 9, and I will run your driver at 396 MHz with it then.

Fernando