Re: [PATCH v9 4/6] platform/x86: int3472: tps68470: add board data for Dell Latitude 5285

[Sakari Ailus <sakari.ailus@linux.intel.com>]

Hi Thierry,

Thanks for the update.

On Thu, Aug 27, 2026 at 10:16:09PM +0200, Thierry Chatard wrote:
> The Dell Latitude 5285 2-in-1 has two cameras connected through a TPS68470
> PMIC/clock/GPIO hub:
> 
>   Front: OV5670 (ACPI INT3479) on I2C4
>   Back:  OV8858 (ACPI INT3477) on I2C2, daisy-chained behind TPS68470
>          S_I2C port (controlled by reg 0x43 S_I2C_CTL)
> 
> GPIO mapping (TPS68470):
>   INT3479 (OV5670): GPIO3 = reset, GPIO4 = powerdown (both active-low)
>   INT3477 (OV8858): GPIO9 = s_resetn, GPIO7 = s_enable (both active-low)
>     GPIO9 and GPIO7 are the TPS68470 secondary-port GPIOs (SGPO reg 0x22
>     bits 2 and 0), not regular GPDO outputs.
> 
> Regulator mapping:
>   CORE  -> dvdd  / INT3477
>   ANA   -> avdd  / INT3477
>   VIO   -> generic (kept always_on; no direct consumers)
>   VSIO  -> dovdd / INT3477: enabling VSIO sets S_I2C_CTL (reg 0x43),
>            opening the I2C passthrough to OV8858; the ov8858 driver
>            enables dovdd at probe time, which naturally activates the
>            passthrough before any I2C transaction to the sensor.
>   AUX1  -> dvdd  / INT3479
>   AUX2  -> dovdd / INT3479
> 
> A static clock consumer list is provided for both sensors (INT3477 and
> INT3479) to work around the broken ACPI _DEP on INT3479 described in the
> previous patch.
> 
> Signed-off-by: Thierry Chatard <tchatard@gmail.com>

Is Documentation/process/coding-assistants.rst relevant for the set?

> ---
>  .../x86/intel/int3472/tps68470_board_data.c   | 170 +++++++++++++++++-
>  1 file changed, 167 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/platform/x86/intel/int3472/tps68470_board_data.c b/drivers/platform/x86/intel/int3472/tps68470_board_data.c
> index 71357a036..6961e2926 100644
> --- a/drivers/platform/x86/intel/int3472/tps68470_board_data.c
> +++ b/drivers/platform/x86/intel/int3472/tps68470_board_data.c
> @@ -74,8 +74,12 @@ static const struct regulator_init_data surface_go_tps68470_vcm_reg_init_data =
>  	.consumer_supplies = int347a_vcm_consumer_supplies,
>  };
>  
> -/* Ensure the always-on VIO regulator has the same voltage as VSIO */
> -static const struct regulator_init_data surface_go_tps68470_vio_reg_init_data = {
> +/*
> + * Keep VIO always_on.  Its voltage must exactly match VSIO on any board
> + * using the TPS68470 I2C pass-through, and must never have direct consumers
> + * (all I2C-path outputs are gated through VSIO).
> + */
> +static const struct regulator_init_data generic_tps68470_vio_reg_init_data = {
>  	.constraints = {
>  		.min_uV = 1800600,
>  		.max_uV = 1800600,
> @@ -122,7 +126,7 @@ static const struct tps68470_regulator_platform_data surface_go_tps68470_pdata =
>  		[TPS68470_CORE] = &surface_go_tps68470_core_reg_init_data,
>  		[TPS68470_ANA]  = &surface_go_tps68470_ana_reg_init_data,
>  		[TPS68470_VCM]  = &surface_go_tps68470_vcm_reg_init_data,
> -		[TPS68470_VIO] = &surface_go_tps68470_vio_reg_init_data,
> +		[TPS68470_VIO] = &generic_tps68470_vio_reg_init_data,

I think this would be better put into a separate patch before this one.
Also intel_nvl_tps68470_vio_reg_init_data is exactly the same.

>  		[TPS68470_VSIO] = &surface_go_tps68470_vsio_reg_init_data,
>  		[TPS68470_AUX1] = &surface_go_tps68470_aux1_reg_init_data,
>  		[TPS68470_AUX2] = &surface_go_tps68470_aux2_reg_init_data,

-- 
Regards,

Sakari Ailus