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

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

[Hao Yao]

The third argument (args[2]) to the _DSM method was hardcoded to 1,
which corresponds to 19.2MHz. However, this argument should reflect
the actual clock frequency from the sensor's ACPI data.

According to the DSM specification:
- 1 = 19.2MHz
- 3 = 24MHz

Read the frequency from clk->frequency and set the DSM argument
accordingly, with 19.2MHz as the default for unsupported frequencies.

This ensures the sensor receives the correct clock frequency as
specified in its ACPI configuration.

Signed-off-by: Hao Yao <hao.yao@intel.com>
---
 .../x86/intel/int3472/clk_and_regulator.c     | 21 ++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/intel/int3472/clk_and_regulator.c b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
index 9e052b164a1a..c834fd59ec0c 100644
--- a/drivers/platform/x86/intel/int3472/clk_and_regulator.c
+++ b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
@@ -19,23 +19,42 @@ static const guid_t img_clk_guid =
 	GUID_INIT(0x82c0d13a, 0x78c5, 0x4244,
 		  0x9b, 0xb1, 0xeb, 0x8b, 0x53, 0x9a, 0x8d, 0x11);
 
+/*
+ * The PCH clock frequency argument to the _DSM method:
+ * PCH_CLK_FREQ_19M2 = 19.2MHz (default)
+ * PCH_CLK_FREQ_24M = 24MHz
+ */
+#define PCH_CLK_FREQ_19M2	1
+#define PCH_CLK_FREQ_24M	3
+
 static void skl_int3472_enable_clk(struct int3472_clock *clk, int enable)
 {
 	struct int3472_discrete_device *int3472 = to_int3472_device(clk);
 	union acpi_object args[3];
 	union acpi_object argv4;
+	u32 dsm_freq_arg;
 
 	if (clk->ena_gpio) {
 		gpiod_set_value_cansleep(clk->ena_gpio, enable);
 		return;
 	}
 
+	switch (clk->frequency) {
+	case 24000000:
+		dsm_freq_arg = PCH_CLK_FREQ_24M;
+		break;
+	case 19200000:
+	default:
+		dsm_freq_arg = PCH_CLK_FREQ_19M2;
+		break;
+	}
+
 	args[0].integer.type = ACPI_TYPE_INTEGER;
 	args[0].integer.value = clk->imgclk_index;
 	args[1].integer.type = ACPI_TYPE_INTEGER;
 	args[1].integer.value = enable;
 	args[2].integer.type = ACPI_TYPE_INTEGER;
-	args[2].integer.value = 1;
+	args[2].integer.value = dsm_freq_arg;
 
 	argv4.type = ACPI_TYPE_PACKAGE;
 	argv4.package.count = 3;
-- 
2.43.0

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

[Dan Scally]

Morning Hao, thanks for the patch

On 08/12/2025 03:51, Hao Yao wrote:
> The third argument (args[2]) to the _DSM method was hardcoded to 1,
> which corresponds to 19.2MHz. However, this argument should reflect
> the actual clock frequency from the sensor's ACPI data.
> 
> According to the DSM specification:
> - 1 = 19.2MHz
> - 3 = 24MHz
> 
> Read the frequency from clk->frequency and set the DSM argument
> accordingly, with 19.2MHz as the default for unsupported frequencies.
> 
> This ensures the sensor receives the correct clock frequency as
> specified in its ACPI configuration.
> 
> Signed-off-by: Hao Yao <hao.yao@intel.com>

Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>

> ---
>   .../x86/intel/int3472/clk_and_regulator.c     | 21 ++++++++++++++++++-
>   1 file changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/intel/int3472/clk_and_regulator.c b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
> index 9e052b164a1a..c834fd59ec0c 100644
> --- a/drivers/platform/x86/intel/int3472/clk_and_regulator.c
> +++ b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
> @@ -19,23 +19,42 @@ static const guid_t img_clk_guid =
>   	GUID_INIT(0x82c0d13a, 0x78c5, 0x4244,
>   		  0x9b, 0xb1, 0xeb, 0x8b, 0x53, 0x9a, 0x8d, 0x11);
>   
> +/*
> + * The PCH clock frequency argument to the _DSM method:
> + * PCH_CLK_FREQ_19M2 = 19.2MHz (default)
> + * PCH_CLK_FREQ_24M = 24MHz
> + */
> +#define PCH_CLK_FREQ_19M2	1
> +#define PCH_CLK_FREQ_24M	3
> +
>   static void skl_int3472_enable_clk(struct int3472_clock *clk, int enable)
>   {
>   	struct int3472_discrete_device *int3472 = to_int3472_device(clk);
>   	union acpi_object args[3];
>   	union acpi_object argv4;
> +	u32 dsm_freq_arg;
>   
>   	if (clk->ena_gpio) {
>   		gpiod_set_value_cansleep(clk->ena_gpio, enable);
>   		return;
>   	}
>   
> +	switch (clk->frequency) {
> +	case 24000000:
> +		dsm_freq_arg = PCH_CLK_FREQ_24M;
> +		break;
> +	case 19200000:
> +	default:
> +		dsm_freq_arg = PCH_CLK_FREQ_19M2;
> +		break;
> +	}
> +
>   	args[0].integer.type = ACPI_TYPE_INTEGER;
>   	args[0].integer.value = clk->imgclk_index;
>   	args[1].integer.type = ACPI_TYPE_INTEGER;
>   	args[1].integer.value = enable;
>   	args[2].integer.type = ACPI_TYPE_INTEGER;
> -	args[2].integer.value = 1;
> +	args[2].integer.value = dsm_freq_arg;
>   
>   	argv4.type = ACPI_TYPE_PACKAGE;
>   	argv4.package.count = 3;

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

[johannes.goede]

Hi,

On 8-Dec-25 4:51 AM, Hao Yao wrote:
> The third argument (args[2]) to the _DSM method was hardcoded to 1,
> which corresponds to 19.2MHz. However, this argument should reflect
> the actual clock frequency from the sensor's ACPI data.
> 
> According to the DSM specification:
> - 1 = 19.2MHz
> - 3 = 24MHz
> 
> Read the frequency from clk->frequency and set the DSM argument
> accordingly, with 19.2MHz as the default for unsupported frequencies.
> 
> This ensures the sensor receives the correct clock frequency as
> specified in its ACPI configuration.
> 
> Signed-off-by: Hao Yao <hao.yao@intel.com>

Thanks patch looks good to me:

Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>

Regards,

Hans


> ---
>  .../x86/intel/int3472/clk_and_regulator.c     | 21 ++++++++++++++++++-
>  1 file changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/intel/int3472/clk_and_regulator.c b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
> index 9e052b164a1a..c834fd59ec0c 100644
> --- a/drivers/platform/x86/intel/int3472/clk_and_regulator.c
> +++ b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
> @@ -19,23 +19,42 @@ static const guid_t img_clk_guid =
>  	GUID_INIT(0x82c0d13a, 0x78c5, 0x4244,
>  		  0x9b, 0xb1, 0xeb, 0x8b, 0x53, 0x9a, 0x8d, 0x11);
>  
> +/*
> + * The PCH clock frequency argument to the _DSM method:
> + * PCH_CLK_FREQ_19M2 = 19.2MHz (default)
> + * PCH_CLK_FREQ_24M = 24MHz
> + */
> +#define PCH_CLK_FREQ_19M2	1
> +#define PCH_CLK_FREQ_24M	3
> +
>  static void skl_int3472_enable_clk(struct int3472_clock *clk, int enable)
>  {
>  	struct int3472_discrete_device *int3472 = to_int3472_device(clk);
>  	union acpi_object args[3];
>  	union acpi_object argv4;
> +	u32 dsm_freq_arg;
>  
>  	if (clk->ena_gpio) {
>  		gpiod_set_value_cansleep(clk->ena_gpio, enable);
>  		return;
>  	}
>  
> +	switch (clk->frequency) {
> +	case 24000000:
> +		dsm_freq_arg = PCH_CLK_FREQ_24M;
> +		break;
> +	case 19200000:
> +	default:
> +		dsm_freq_arg = PCH_CLK_FREQ_19M2;
> +		break;
> +	}
> +
>  	args[0].integer.type = ACPI_TYPE_INTEGER;
>  	args[0].integer.value = clk->imgclk_index;
>  	args[1].integer.type = ACPI_TYPE_INTEGER;
>  	args[1].integer.value = enable;
>  	args[2].integer.type = ACPI_TYPE_INTEGER;
> -	args[2].integer.value = 1;
> +	args[2].integer.value = dsm_freq_arg;
>  
>  	argv4.type = ACPI_TYPE_PACKAGE;
>  	argv4.package.count = 3;

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

[Sakari Ailus]

Hi Hao,

On Mon, Dec 08, 2025 at 11:51:14AM +0800, Hao Yao wrote:
> The third argument (args[2]) to the _DSM method was hardcoded to 1,
> which corresponds to 19.2MHz. However, this argument should reflect
> the actual clock frequency from the sensor's ACPI data.
> 
> According to the DSM specification:
> - 1 = 19.2MHz
> - 3 = 24MHz
> 
> Read the frequency from clk->frequency and set the DSM argument
> accordingly, with 19.2MHz as the default for unsupported frequencies.
> 
> This ensures the sensor receives the correct clock frequency as
> specified in its ACPI configuration.
> 
> Signed-off-by: Hao Yao <hao.yao@intel.com>

Thanks for the update.

Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>

-- 
Kind regards,

Sakari Ailus

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

[Ilpo Järvinen]

On Mon, 8 Dec 2025, Hao Yao wrote:

> The third argument (args[2]) to the _DSM method was hardcoded to 1,
> which corresponds to 19.2MHz. However, this argument should reflect
> the actual clock frequency from the sensor's ACPI data.
> 
> According to the DSM specification:
> - 1 = 19.2MHz
> - 3 = 24MHz
> 
> Read the frequency from clk->frequency and set the DSM argument
> accordingly, with 19.2MHz as the default for unsupported frequencies.
> 
> This ensures the sensor receives the correct clock frequency as
> specified in its ACPI configuration.
> 
> Signed-off-by: Hao Yao <hao.yao@intel.com>

Should this have a Fixes tag?

Could you please also mention what you discovered about values 0 and 2 in 
the changelog as it seems useful information (I requested this in v1).

> ---
>  .../x86/intel/int3472/clk_and_regulator.c     | 21 ++++++++++++++++++-
>  1 file changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/intel/int3472/clk_and_regulator.c b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
> index 9e052b164a1a..c834fd59ec0c 100644
> --- a/drivers/platform/x86/intel/int3472/clk_and_regulator.c
> +++ b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
> @@ -19,23 +19,42 @@ static const guid_t img_clk_guid =
>  	GUID_INIT(0x82c0d13a, 0x78c5, 0x4244,
>  		  0x9b, 0xb1, 0xeb, 0x8b, 0x53, 0x9a, 0x8d, 0x11);
>  
> +/*
> + * The PCH clock frequency argument to the _DSM method:
> + * PCH_CLK_FREQ_19M2 = 19.2MHz (default)
> + * PCH_CLK_FREQ_24M = 24MHz
> + */
> +#define PCH_CLK_FREQ_19M2	1
> +#define PCH_CLK_FREQ_24M	3
> +
>  static void skl_int3472_enable_clk(struct int3472_clock *clk, int enable)
>  {
>  	struct int3472_discrete_device *int3472 = to_int3472_device(clk);
>  	union acpi_object args[3];
>  	union acpi_object argv4;
> +	u32 dsm_freq_arg;
>  
>  	if (clk->ena_gpio) {
>  		gpiod_set_value_cansleep(clk->ena_gpio, enable);
>  		return;
>  	}
>  
> +	switch (clk->frequency) {
> +	case 24000000:
> +		dsm_freq_arg = PCH_CLK_FREQ_24M;
> +		break;
> +	case 19200000:
> +	default:
> +		dsm_freq_arg = PCH_CLK_FREQ_19M2;
> +		break;
> +	}
> +
>  	args[0].integer.type = ACPI_TYPE_INTEGER;
>  	args[0].integer.value = clk->imgclk_index;
>  	args[1].integer.type = ACPI_TYPE_INTEGER;
>  	args[1].integer.value = enable;
>  	args[2].integer.type = ACPI_TYPE_INTEGER;
> -	args[2].integer.value = 1;
> +	args[2].integer.value = dsm_freq_arg;
>  
>  	argv4.type = ACPI_TYPE_PACKAGE;
>  	argv4.package.count = 3;
> 


-- 
 i.

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

[Hao Yao]

Hi,

Sorry for missing this mail,

On 12/29/25 20:06, Ilpo Järvinen wrote:
> On Mon, 8 Dec 2025, Hao Yao wrote:
> 
>> The third argument (args[2]) to the _DSM method was hardcoded to 1,
>> which corresponds to 19.2MHz. However, this argument should reflect
>> the actual clock frequency from the sensor's ACPI data.
>>
>> According to the DSM specification:
>> - 1 = 19.2MHz
>> - 3 = 24MHz
>>
>> Read the frequency from clk->frequency and set the DSM argument
>> accordingly, with 19.2MHz as the default for unsupported frequencies.
>>
>> This ensures the sensor receives the correct clock frequency as
>> specified in its ACPI configuration.
>>
>> Signed-off-by: Hao Yao <hao.yao@intel.com>
> 
> Should this have a Fixes tag?
> 

Fixes: e4543de8b6ff ("platform/x86: int3472: Evaluate device's _DSM 
method to control imaging clock")

> Could you please also mention what you discovered about values 0 and 2 in
> the changelog as it seems useful information (I requested this in v1).
> 

When I send value 0 or 2, the clock doesn't change (checked by 
oscilloscope). I guess that values other than 1 and 3 is ignored 
currently, maybe reserved for future usage.


Best Regards,
Hao Yao

>> ---
>>   .../x86/intel/int3472/clk_and_regulator.c     | 21 ++++++++++++++++++-
>>   1 file changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/platform/x86/intel/int3472/clk_and_regulator.c b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
>> index 9e052b164a1a..c834fd59ec0c 100644
>> --- a/drivers/platform/x86/intel/int3472/clk_and_regulator.c
>> +++ b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
>> @@ -19,23 +19,42 @@ static const guid_t img_clk_guid =
>>   	GUID_INIT(0x82c0d13a, 0x78c5, 0x4244,
>>   		  0x9b, 0xb1, 0xeb, 0x8b, 0x53, 0x9a, 0x8d, 0x11);
>>   
>> +/*
>> + * The PCH clock frequency argument to the _DSM method:
>> + * PCH_CLK_FREQ_19M2 = 19.2MHz (default)
>> + * PCH_CLK_FREQ_24M = 24MHz
>> + */
>> +#define PCH_CLK_FREQ_19M2	1
>> +#define PCH_CLK_FREQ_24M	3
>> +
>>   static void skl_int3472_enable_clk(struct int3472_clock *clk, int enable)
>>   {
>>   	struct int3472_discrete_device *int3472 = to_int3472_device(clk);
>>   	union acpi_object args[3];
>>   	union acpi_object argv4;
>> +	u32 dsm_freq_arg;
>>   
>>   	if (clk->ena_gpio) {
>>   		gpiod_set_value_cansleep(clk->ena_gpio, enable);
>>   		return;
>>   	}
>>   
>> +	switch (clk->frequency) {
>> +	case 24000000:
>> +		dsm_freq_arg = PCH_CLK_FREQ_24M;
>> +		break;
>> +	case 19200000:
>> +	default:
>> +		dsm_freq_arg = PCH_CLK_FREQ_19M2;
>> +		break;
>> +	}
>> +
>>   	args[0].integer.type = ACPI_TYPE_INTEGER;
>>   	args[0].integer.value = clk->imgclk_index;
>>   	args[1].integer.type = ACPI_TYPE_INTEGER;
>>   	args[1].integer.value = enable;
>>   	args[2].integer.type = ACPI_TYPE_INTEGER;
>> -	args[2].integer.value = 1;
>> +	args[2].integer.value = dsm_freq_arg;
>>   
>>   	argv4.type = ACPI_TYPE_PACKAGE;
>>   	argv4.package.count = 3;
>>
> 
> 

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

[Fernando Rimoli]

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

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

[Sergey Lebedev]

Hi Fernando, Hao,

On 25/10/2026 15:50, Fernando Rimoli wrote:
> 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.

The Surface Pro 9 DSDT in linux-surface/acpidumps (surface_pro_9_intel,
a 2022 dump) suggests it takes 0. Its _DSM calls ICLK.CLKC with the
enable, which goes into bit 1, and then ICLK.CLKF with Arg3[2], which
does

	CLKx = (CLKx & ~1) | Arg1

That is the Tiger Lake and Alder Lake layout in coreboot
(src/soc/intel/alderlake/acpi/camera_clock_ctl.asl), where bit 0 is
"0: 24MHz, 1: 19.2MHz". So 3 sets bit 0, which is 19.2 MHz, and bit 1,
the enable. On disable, CLKC clears bit 1 and CLKF sets it again, so
with v2 the clock would never be switched off either.

On the Surface Pro 11 (Lunar Lake), CLKF writes Arg1 & 3 to bits 1:0
and the enable is bit 2. That is the Meteor Lake layout, where 3 is
"24 IMG" and 0 and 2 are 19.2 MHz from other sources. It fits both
Hao's oscilloscope reading (0 and 2 do not change the clock) and 3
working on the Surface Pro 11.

Fernando, a run with 0 in place of 3 would tell, and your own DSDT
whether it still matches the dump. If it gives 59.14 fps at 396 MHz,
the value depends on the generation, and v3 would need to pick it per
platform.

Sergey

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

[Sergey Lebedev]

Hi Hans,

Thank you, noted: if I resend it, it will be based on media-committers
next. The v2 applies to it unchanged, at d7e7bca7169, which is the tree
I tested it on.

Sergey

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

[Hans de Goede]

Hi,

On 16-Oct-26 13:28, Sergey Lebedev wrote:
> Hi Hao,
> 
> This fixes a camera on the Surface Pro 11 with Intel (Lunar Lake), for
> your v2:
> https://lore.kernel.org/all/20251208035122.2147678-1-hao.yao@intel.com/
> 
> Its infrared sensor, an ST VD55G0 (SMO55F0), has 24 MHz in its SSDB,
> and INT3472 turns its clock on through the _DSM with 1, 19.2 MHz. The
> sensor driver sets the sensor up for 24 MHz, so everything the sensor
> derives runs at four fifths: it streamed at 47.31 fps where its
> configuration gives 59.14, which also puts its MIPI output at 633.6
> Mbps, below the sensor's minimum of 750. With your v2 on media next and
> my vd55g0 driver, the sensor runs at 59.14 fps in every mode, as computed.
> A value of 0 did not change the clock here either, as you saw on the
> oscilloscope.
> 
> Tested-by: Sergey Lebedev <lsa.uz@pm.me> # Surface Pro 11 (Intel), VD55G0
> 
> Would you send a v3 with the Fixes tag and the note on 0 and 2 that Ilpo
> asked for? I will repeat the Tested-by on it. If you are busy, I can
> resend it with your authorship.

Note that from now on int3472 patches are routed through the media-committers
tree since these are related to camera support:

https://gitlab.freedesktop.org/linux-media/media-committers/-/commits/next/drivers/platform/x86/intel/int3472?ref_type=heads

If you send a new version please base it on top of media-committers/next .

Regards,

Hans

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

[Sergey Lebedev]

Hi Hao,

This fixes a camera on the Surface Pro 11 with Intel (Lunar Lake), for
your v2:
https://lore.kernel.org/all/20251208035122.2147678-1-hao.yao@intel.com/

Its infrared sensor, an ST VD55G0 (SMO55F0), has 24 MHz in its SSDB,
and INT3472 turns its clock on through the _DSM with 1, 19.2 MHz. The
sensor driver sets the sensor up for 24 MHz, so everything the sensor
derives runs at four fifths: it streamed at 47.31 fps where its
configuration gives 59.14, which also puts its MIPI output at 633.6
Mbps, below the sensor's minimum of 750. With your v2 on media next and
my vd55g0 driver, the sensor runs at 59.14 fps in every mode, as computed.
A value of 0 did not change the clock here either, as you saw on the
oscilloscope.

Tested-by: Sergey Lebedev <lsa.uz@pm.me> # Surface Pro 11 (Intel), VD55G0

Would you send a v3 with the Fixes tag and the note on 0 and 2 that Ilpo
asked for? I will repeat the Tested-by on it. If you are busy, I can
resend it with your authorship.

Sergey