[PATCH V3 0/2] Add regulator load support for QMP UFS PHY

[PATCH V3 0/2] Add regulator load support for QMP UFS PHY

[Nitin Rawat]

The series improves regulator handling in the QMP UFS PHY driver and
adds load configuration support for SM8650 and SM8750 platforms.

On some SoCs, regulators are shared between the UFS PHY and other IP
blocks. To maintain stability and power efficiency, the regulator
framework needs to know the UFS PHY's peak load, as it determines the
regulator's operating mode.

The first update replaces devm_regulator_bulk_get() with
devm_regulator_bulk_get_const(), converts the regulator name array to
a bulk data structure, and uses the init_load_uA field to automatically
apply regulator_set_load() before the first enable.

The second update adds platform-specific load settings for SM8650 and
SM8750 to ensure proper power management where regulators are shared.

Changes from v2:
1. Addressed Dmitry's comment to replace devm_regulator_bulk_get() with
   devm_regulator_bulk_get_const.
2. inline the qmp_ufs_vreg_init() function

Changes from v1:
1. Addressed comments to move load configuration from device tree to
   hardcoded, per-compatible data within the driver.
2. Accordingly updated commit text to reflect the same.
3. Addressed Manivannan's comment to avoid initialization of load.

Nitin Rawat (2):
  phy: qcom-qmp-ufs: Add regulator load voting for UFS QMP PHY
  phy: qcom-qmp-ufs: Add regulator loads for SM8650 and SM8750

 drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 48 ++++++++++++-------------
 1 file changed, 23 insertions(+), 25 deletions(-)

--
2.48.1

[PATCH V3 1/2] phy: qcom-qmp-ufs: Add regulator load voting for UFS QMP PHY

[Nitin Rawat]

On certain SoCs, power regulators are shared between the QMP UFS PHY
and other IP blocks. To ensure proper operation, the regulator
framework must be informed of the UFS PHY's load requirements.
This is essential because the regulator's operating mode—whether Low
Power or High Power—depends on the maximum expected load at any given
time, which the regulator driver needs to manage accordingly.

To support this, replace devm_regulator_bulk_get() with
devm_regulator_bulk_get_const() and inline the qmp_ufs_vreg_init()
function. additionally replace the array of regulator names with a
bulk regulator data structure, and utilize the init_load_uA field
provided by the regulator framework. This ensures that
regulator_set_load() is automatically invoked before the
first enable operation.

Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com>
---
 drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 29 +++++++------------------
 1 file changed, 8 insertions(+), 21 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
index 9c69c77d10c8..aaa88ca0ef07 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
@@ -1107,7 +1107,7 @@ struct qmp_phy_cfg {
 	const struct qmp_phy_cfg_tbls tbls_hs_overlay[NUM_OVERLAY];

 	/* regulators to be requested */
-	const char * const *vreg_list;
+	const struct regulator_bulk_data *vreg_list;
 	int num_vregs;

 	/* array of registers with different offsets */
@@ -1164,9 +1164,10 @@ static inline void qphy_clrbits(void __iomem *base, u32 offset, u32 val)
 	readl(base + offset);
 }

-/* list of regulators */
-static const char * const qmp_phy_vreg_l[] = {
-	"vdda-phy", "vdda-pll",
+/* Default regulator bulk data (no load used) */
+static const struct regulator_bulk_data qmp_phy_vreg_l[] = {
+	{ .supply = "vdda-phy" },
+	{ .supply = "vdda-pll" },
 };

 static const struct qmp_ufs_offsets qmp_ufs_offsets = {
@@ -1890,22 +1891,6 @@ static const struct phy_ops qcom_qmp_ufs_phy_ops = {
 	.owner		= THIS_MODULE,
 };

-static int qmp_ufs_vreg_init(struct qmp_ufs *qmp)
-{
-	const struct qmp_phy_cfg *cfg = qmp->cfg;
-	struct device *dev = qmp->dev;
-	int num = cfg->num_vregs;
-	int i;
-
-	qmp->vregs = devm_kcalloc(dev, num, sizeof(*qmp->vregs), GFP_KERNEL);
-	if (!qmp->vregs)
-		return -ENOMEM;
-
-	for (i = 0; i < num; i++)
-		qmp->vregs[i].supply = cfg->vreg_list[i];
-
-	return devm_regulator_bulk_get(dev, num, qmp->vregs);
-}

 static int qmp_ufs_clk_init(struct qmp_ufs *qmp)
 {
@@ -2068,7 +2053,9 @@ static int qmp_ufs_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;

-	ret = qmp_ufs_vreg_init(qmp);
+	ret = devm_regulator_bulk_get_const(dev, qmp->cfg->num_vregs,
+					    qmp->cfg->vreg_list,
+					    &qmp->vregs);
 	if (ret)
 		return ret;

--
2.48.1

[PATCH V3 2/2] phy: qcom-qmp-ufs: Add regulator loads for SM8650 and SM8750

[Nitin Rawat]

Add regulator load voting support for SM8650 and SM8750 platforms by
introducing dedicated regulator bulk data arrays with their load
values.

The load requirements are:
- SM8650: vdda-phy (205mA), vdda-pll (17.5mA)
- SM8750: vdda-phy (213mA), vdda-pll (18.3mA)

This ensures stable operation and proper power management for these
platforms where regulators are shared between the QMP USB PHY and
other IP blocks by setting appropriate regulator load currents during PHY
operations.

Configurations without specific load requirements will continue to work
unchanged, as init_load_uA remains zero-initialized when .init_load_uA
is not provided.

Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com>
---
 drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
index aaa88ca0ef07..1c3ce0fa6adf 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
@@ -1170,6 +1170,17 @@ static const struct regulator_bulk_data qmp_phy_vreg_l[] = {
 	{ .supply = "vdda-pll" },
 };

+/* Regulator bulk data with load values for specific configurations */
+static const struct regulator_bulk_data sm8650_ufsphy_vreg_l[] = {
+	{ .supply = "vdda-phy", .init_load_uA = 205000 },
+	{ .supply = "vdda-pll", .init_load_uA = 17500 },
+};
+
+static const struct regulator_bulk_data sm8750_ufsphy_vreg_l[] = {
+	{ .supply = "vdda-phy", .init_load_uA = 213000 },
+	{ .supply = "vdda-pll", .init_load_uA = 18300 },
+};
+
 static const struct qmp_ufs_offsets qmp_ufs_offsets = {
 	.serdes		= 0,
 	.pcs		= 0xc00,
@@ -1638,8 +1649,8 @@ static const struct qmp_phy_cfg sm8650_ufsphy_cfg = {
 		.max_gear	= UFS_HS_G5,
 	},

-	.vreg_list		= qmp_phy_vreg_l,
-	.num_vregs		= ARRAY_SIZE(qmp_phy_vreg_l),
+	.vreg_list		= sm8650_ufsphy_vreg_l,
+	.num_vregs		= ARRAY_SIZE(sm8650_ufsphy_vreg_l),
 	.regs			= ufsphy_v6_regs_layout,
 };

@@ -1676,8 +1687,8 @@ static const struct qmp_phy_cfg sm8750_ufsphy_cfg = {
 		.max_gear	= UFS_HS_G5,
 	},

-	.vreg_list		= qmp_phy_vreg_l,
-	.num_vregs		= ARRAY_SIZE(qmp_phy_vreg_l),
+	.vreg_list		= sm8750_ufsphy_vreg_l,
+	.num_vregs		= ARRAY_SIZE(sm8750_ufsphy_vreg_l),
 	.regs			= ufsphy_v6_regs_layout,

 };
--
2.48.1

Re: [PATCH V3 1/2] phy: qcom-qmp-ufs: Add regulator load voting for UFS QMP PHY

[Dmitry Baryshkov]

On Wed, Aug 20, 2025 at 03:58:25AM +0530, Nitin Rawat wrote:
> On certain SoCs, power regulators are shared between the QMP UFS PHY
> and other IP blocks. To ensure proper operation, the regulator
> framework must be informed of the UFS PHY's load requirements.
> This is essential because the regulator's operating mode—whether Low
> Power or High Power—depends on the maximum expected load at any given
> time, which the regulator driver needs to manage accordingly.
> 
> To support this, replace devm_regulator_bulk_get() with
> devm_regulator_bulk_get_const() and inline the qmp_ufs_vreg_init()
> function. additionally replace the array of regulator names with a
> bulk regulator data structure, and utilize the init_load_uA field
> provided by the regulator framework. This ensures that
> regulator_set_load() is automatically invoked before the
> first enable operation.
> 
> Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com>
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 29 +++++++------------------
>  1 file changed, 8 insertions(+), 21 deletions(-)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

Re: [PATCH V3 2/2] phy: qcom-qmp-ufs: Add regulator loads for SM8650 and SM8750

[Dmitry Baryshkov]

On Wed, Aug 20, 2025 at 03:58:26AM +0530, Nitin Rawat wrote:
> Add regulator load voting support for SM8650 and SM8750 platforms by
> introducing dedicated regulator bulk data arrays with their load
> values.
> 
> The load requirements are:
> - SM8650: vdda-phy (205mA), vdda-pll (17.5mA)
> - SM8750: vdda-phy (213mA), vdda-pll (18.3mA)
> 
> This ensures stable operation and proper power management for these
> platforms where regulators are shared between the QMP USB PHY and
> other IP blocks by setting appropriate regulator load currents during PHY
> operations.
> 
> Configurations without specific load requirements will continue to work
> unchanged, as init_load_uA remains zero-initialized when .init_load_uA
> is not provided.

Can we please get configuration for the rest of the platforms?

> 
> Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com>
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 19 +++++++++++++++----
>  1 file changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> index aaa88ca0ef07..1c3ce0fa6adf 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> @@ -1170,6 +1170,17 @@ static const struct regulator_bulk_data qmp_phy_vreg_l[] = {
>  	{ .supply = "vdda-pll" },
>  };
> 
> +/* Regulator bulk data with load values for specific configurations */
> +static const struct regulator_bulk_data sm8650_ufsphy_vreg_l[] = {
> +	{ .supply = "vdda-phy", .init_load_uA = 205000 },
> +	{ .supply = "vdda-pll", .init_load_uA = 17500 },
> +};
> +
> +static const struct regulator_bulk_data sm8750_ufsphy_vreg_l[] = {
> +	{ .supply = "vdda-phy", .init_load_uA = 213000 },
> +	{ .supply = "vdda-pll", .init_load_uA = 18300 },
> +};
> +
>  static const struct qmp_ufs_offsets qmp_ufs_offsets = {
>  	.serdes		= 0,
>  	.pcs		= 0xc00,
> @@ -1638,8 +1649,8 @@ static const struct qmp_phy_cfg sm8650_ufsphy_cfg = {
>  		.max_gear	= UFS_HS_G5,
>  	},
> 
> -	.vreg_list		= qmp_phy_vreg_l,
> -	.num_vregs		= ARRAY_SIZE(qmp_phy_vreg_l),
> +	.vreg_list		= sm8650_ufsphy_vreg_l,
> +	.num_vregs		= ARRAY_SIZE(sm8650_ufsphy_vreg_l),
>  	.regs			= ufsphy_v6_regs_layout,
>  };
> 
> @@ -1676,8 +1687,8 @@ static const struct qmp_phy_cfg sm8750_ufsphy_cfg = {
>  		.max_gear	= UFS_HS_G5,
>  	},
> 
> -	.vreg_list		= qmp_phy_vreg_l,
> -	.num_vregs		= ARRAY_SIZE(qmp_phy_vreg_l),
> +	.vreg_list		= sm8750_ufsphy_vreg_l,
> +	.num_vregs		= ARRAY_SIZE(sm8750_ufsphy_vreg_l),
>  	.regs			= ufsphy_v6_regs_layout,
> 
>  };
> --
> 2.48.1
> 

-- 
With best wishes
Dmitry

Re: [PATCH V3 2/2] phy: qcom-qmp-ufs: Add regulator loads for SM8650 and SM8750

[Nitin Rawat]

On 8/20/2025 6:19 AM, Dmitry Baryshkov wrote:
> On Wed, Aug 20, 2025 at 03:58:26AM +0530, Nitin Rawat wrote:
>> Add regulator load voting support for SM8650 and SM8750 platforms by
>> introducing dedicated regulator bulk data arrays with their load
>> values.
>>
>> The load requirements are:
>> - SM8650: vdda-phy (205mA), vdda-pll (17.5mA)
>> - SM8750: vdda-phy (213mA), vdda-pll (18.3mA)
>>
>> This ensures stable operation and proper power management for these
>> platforms where regulators are shared between the QMP USB PHY and
>> other IP blocks by setting appropriate regulator load currents during PHY
>> operations.
>>
>> Configurations without specific load requirements will continue to work
>> unchanged, as init_load_uA remains zero-initialized when .init_load_uA
>> is not provided.
> 
> Can we please get configuration for the rest of the platforms?

Hi Dmitry,

If you're okay with it, can I merge the configuration for the remaining 
platforms in the next patch series after I complete testing on all 
remaining platforms.

Regards,
Nitin

> 
>>
>> Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com>
>> ---
>>   drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 19 +++++++++++++++----
>>   1 file changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
>> index aaa88ca0ef07..1c3ce0fa6adf 100644
>> --- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
>> @@ -1170,6 +1170,17 @@ static const struct regulator_bulk_data qmp_phy_vreg_l[] = {
>>   	{ .supply = "vdda-pll" },
>>   };
>>
>> +/* Regulator bulk data with load values for specific configurations */
>> +static const struct regulator_bulk_data sm8650_ufsphy_vreg_l[] = {
>> +	{ .supply = "vdda-phy", .init_load_uA = 205000 },
>> +	{ .supply = "vdda-pll", .init_load_uA = 17500 },
>> +};
>> +
>> +static const struct regulator_bulk_data sm8750_ufsphy_vreg_l[] = {
>> +	{ .supply = "vdda-phy", .init_load_uA = 213000 },
>> +	{ .supply = "vdda-pll", .init_load_uA = 18300 },
>> +};
>> +
>>   static const struct qmp_ufs_offsets qmp_ufs_offsets = {
>>   	.serdes		= 0,
>>   	.pcs		= 0xc00,
>> @@ -1638,8 +1649,8 @@ static const struct qmp_phy_cfg sm8650_ufsphy_cfg = {
>>   		.max_gear	= UFS_HS_G5,
>>   	},
>>
>> -	.vreg_list		= qmp_phy_vreg_l,
>> -	.num_vregs		= ARRAY_SIZE(qmp_phy_vreg_l),
>> +	.vreg_list		= sm8650_ufsphy_vreg_l,
>> +	.num_vregs		= ARRAY_SIZE(sm8650_ufsphy_vreg_l),
>>   	.regs			= ufsphy_v6_regs_layout,
>>   };
>>
>> @@ -1676,8 +1687,8 @@ static const struct qmp_phy_cfg sm8750_ufsphy_cfg = {
>>   		.max_gear	= UFS_HS_G5,
>>   	},
>>
>> -	.vreg_list		= qmp_phy_vreg_l,
>> -	.num_vregs		= ARRAY_SIZE(qmp_phy_vreg_l),
>> +	.vreg_list		= sm8750_ufsphy_vreg_l,
>> +	.num_vregs		= ARRAY_SIZE(sm8750_ufsphy_vreg_l),
>>   	.regs			= ufsphy_v6_regs_layout,
>>
>>   };
>> --
>> 2.48.1
>>
> 

Re: [PATCH V3 2/2] phy: qcom-qmp-ufs: Add regulator loads for SM8650 and SM8750

[Dmitry Baryshkov]

On Wed, Aug 20, 2025 at 12:07:57PM +0530, Nitin Rawat wrote:
> 
> 
> On 8/20/2025 6:19 AM, Dmitry Baryshkov wrote:
> > On Wed, Aug 20, 2025 at 03:58:26AM +0530, Nitin Rawat wrote:
> > > Add regulator load voting support for SM8650 and SM8750 platforms by
> > > introducing dedicated regulator bulk data arrays with their load
> > > values.
> > > 
> > > The load requirements are:
> > > - SM8650: vdda-phy (205mA), vdda-pll (17.5mA)
> > > - SM8750: vdda-phy (213mA), vdda-pll (18.3mA)
> > > 
> > > This ensures stable operation and proper power management for these
> > > platforms where regulators are shared between the QMP USB PHY and
> > > other IP blocks by setting appropriate regulator load currents during PHY
> > > operations.
> > > 
> > > Configurations without specific load requirements will continue to work
> > > unchanged, as init_load_uA remains zero-initialized when .init_load_uA
> > > is not provided.
> > 
> > Can we please get configuration for the rest of the platforms?
> 
> Hi Dmitry,
> 
> If you're okay with it, can I merge the configuration for the remaining
> platforms in the next patch series after I complete testing on all remaining
> platforms.

You don't need to test, finding MSM8996 or 98 might be troublesome. Just
fill in the values from the hardware documentation.

-- 
With best wishes
Dmitry

Re: [PATCH V3 2/2] phy: qcom-qmp-ufs: Add regulator loads for SM8650 and SM8750

[Nitin Rawat]

On 8/20/2025 5:24 PM, Dmitry Baryshkov wrote:
> On Wed, Aug 20, 2025 at 12:07:57PM +0530, Nitin Rawat wrote:
>>
>>
>> On 8/20/2025 6:19 AM, Dmitry Baryshkov wrote:
>>> On Wed, Aug 20, 2025 at 03:58:26AM +0530, Nitin Rawat wrote:
>>>> Add regulator load voting support for SM8650 and SM8750 platforms by
>>>> introducing dedicated regulator bulk data arrays with their load
>>>> values.
>>>>
>>>> The load requirements are:
>>>> - SM8650: vdda-phy (205mA), vdda-pll (17.5mA)
>>>> - SM8750: vdda-phy (213mA), vdda-pll (18.3mA)
>>>>
>>>> This ensures stable operation and proper power management for these
>>>> platforms where regulators are shared between the QMP USB PHY and
>>>> other IP blocks by setting appropriate regulator load currents during PHY
>>>> operations.
>>>>
>>>> Configurations without specific load requirements will continue to work
>>>> unchanged, as init_load_uA remains zero-initialized when .init_load_uA
>>>> is not provided.
>>>
>>> Can we please get configuration for the rest of the platforms?
>>
>> Hi Dmitry,
>>
>> If you're okay with it, can I merge the configuration for the remaining
>> platforms in the next patch series after I complete testing on all remaining
>> platforms.
> 
> You don't need to test, finding MSM8996 or 98 might be troublesome. Just
> fill in the values from the hardware documentation.

Hi Dmitry,

While implementing changes for all remaining platform, I noticed that 
the "regulator-allow-set-load" property is defined only for SM8750 and 
SM8850 within the PMIC PHY and PLL device tree nodes which means that 
even if the UFS PHY driver is updated to vote for this configuration on 
other platforms, it will have no impact.

Should I still proceed with applying the change across all platform, or 
limit it to just the SM8750 and SM8850 drivers? What’s your recommendation?

===========================================================================
// Device tree:
vreg_l1j_0p91: ldo1 {
     regulator-name = "vreg_l1j_0p91";
     regulator-min-microvolt = <880000>;
     regulator-max-microvolt = <920000>;
     regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
     regulator-allow-set-load;
     regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM 
RPMH_REGULATOR_MODE_HPM>;
};

===========================================================================
drivers/regulator/of_regulator.c


if (of_property_read_bool(np, "regulator-allow-set-load"))
		constraints->valid_ops_mask |= REGULATOR_CHANGE_DRMS;

===========================================================================
//drivers/regulator/core.c
static int drms_uA_update(struct regulator_dev *rdev)
{
     ...
     if (!regulator_ops_is_valid(rdev, REGULATOR_CHANGE_DRMS)) {
         rdev_dbg(rdev, "DRMS operation not allowed\n");
         return 0;
     }
     ...
}


Regards,
Nitin




> 

Re: [PATCH V3 2/2] phy: qcom-qmp-ufs: Add regulator loads for SM8650 and SM8750

[Nitin Rawat]

On 8/21/2025 9:32 PM, Nitin Rawat wrote:
> 
> 
> On 8/20/2025 5:24 PM, Dmitry Baryshkov wrote:
>> On Wed, Aug 20, 2025 at 12:07:57PM +0530, Nitin Rawat wrote:
>>>
>>>
>>> On 8/20/2025 6:19 AM, Dmitry Baryshkov wrote:
>>>> On Wed, Aug 20, 2025 at 03:58:26AM +0530, Nitin Rawat wrote:
>>>>> Add regulator load voting support for SM8650 and SM8750 platforms by
>>>>> introducing dedicated regulator bulk data arrays with their load
>>>>> values.
>>>>>
>>>>> The load requirements are:
>>>>> - SM8650: vdda-phy (205mA), vdda-pll (17.5mA)
>>>>> - SM8750: vdda-phy (213mA), vdda-pll (18.3mA)
>>>>>
>>>>> This ensures stable operation and proper power management for these
>>>>> platforms where regulators are shared between the QMP USB PHY and
>>>>> other IP blocks by setting appropriate regulator load currents 
>>>>> during PHY
>>>>> operations.
>>>>>
>>>>> Configurations without specific load requirements will continue to 
>>>>> work
>>>>> unchanged, as init_load_uA remains zero-initialized when .init_load_uA
>>>>> is not provided.
>>>>
>>>> Can we please get configuration for the rest of the platforms?
>>>
>>> Hi Dmitry,
>>>
>>> If you're okay with it, can I merge the configuration for the remaining
>>> platforms in the next patch series after I complete testing on all 
>>> remaining
>>> platforms.
>>
>> You don't need to test, finding MSM8996 or 98 might be troublesome. Just
>> fill in the values from the hardware documentation.
> 
> Hi Dmitry,
> 
> While implementing changes for all remaining platform, I noticed that 
> the "regulator-allow-set-load" property is defined only for SM8750 and 
> SM8850 within the PMIC PHY and PLL device tree nodes which means that 
> even if the UFS PHY driver is updated to vote for this configuration on 
> other platforms, it will have no impact.
> 
> Should I still proceed with applying the change across all platform, or 
> limit it to just the SM8750 and *SM8850* drivers? What’s your recommendation?

Sorry for the typo. It's SM8650 and SM8750.

> 
> ===========================================================================
> // Device tree:
> vreg_l1j_0p91: ldo1 {
>      regulator-name = "vreg_l1j_0p91";
>      regulator-min-microvolt = <880000>;
>      regulator-max-microvolt = <920000>;
>      regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
>      regulator-allow-set-load;
>      regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM 
> RPMH_REGULATOR_MODE_HPM>;
> };
> 
> ===========================================================================
> drivers/regulator/of_regulator.c
> 
> 
> if (of_property_read_bool(np, "regulator-allow-set-load"))
>          constraints->valid_ops_mask |= REGULATOR_CHANGE_DRMS;
> 
> ===========================================================================
> //drivers/regulator/core.c
> static int drms_uA_update(struct regulator_dev *rdev)
> {
>      ...
>      if (!regulator_ops_is_valid(rdev, REGULATOR_CHANGE_DRMS)) {
>          rdev_dbg(rdev, "DRMS operation not allowed\n");
>          return 0;
>      }
>      ...
> }
> 
> 
> Regards,
> Nitin
> 
> 
> 
> 
>>
> 

Re: [PATCH V3 1/2] phy: qcom-qmp-ufs: Add regulator load voting for UFS QMP PHY

[Manivannan Sadhasivam]

On Wed, Aug 20, 2025 at 03:58:25AM GMT, Nitin Rawat wrote:
> On certain SoCs, power regulators are shared between the QMP UFS PHY
> and other IP blocks. To ensure proper operation, the regulator
> framework must be informed of the UFS PHY's load requirements.
> This is essential because the regulator's operating mode—whether Low
> Power or High Power—depends on the maximum expected load at any given
> time, which the regulator driver needs to manage accordingly.
> 
> To support this, replace devm_regulator_bulk_get() with
> devm_regulator_bulk_get_const() and inline the qmp_ufs_vreg_init()
> function.

Use of 'inline' is confusing. Please reword it to sound like you are just
getting rid of this function in favor of devm_regulator_bulk_get_const().

> additionally replace the array of regulator names with a
> bulk regulator data structure, and utilize the init_load_uA field
> provided by the regulator framework. This ensures that
> regulator_set_load() is automatically invoked before the
> first enable operation.
> 
> Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com>
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 29 +++++++------------------
>  1 file changed, 8 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> index 9c69c77d10c8..aaa88ca0ef07 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> @@ -1107,7 +1107,7 @@ struct qmp_phy_cfg {
>  	const struct qmp_phy_cfg_tbls tbls_hs_overlay[NUM_OVERLAY];
> 
>  	/* regulators to be requested */
> -	const char * const *vreg_list;
> +	const struct regulator_bulk_data *vreg_list;
>  	int num_vregs;
> 
>  	/* array of registers with different offsets */
> @@ -1164,9 +1164,10 @@ static inline void qphy_clrbits(void __iomem *base, u32 offset, u32 val)
>  	readl(base + offset);
>  }
> 
> -/* list of regulators */
> -static const char * const qmp_phy_vreg_l[] = {
> -	"vdda-phy", "vdda-pll",
> +/* Default regulator bulk data (no load used) */
> +static const struct regulator_bulk_data qmp_phy_vreg_l[] = {
> +	{ .supply = "vdda-phy" },
> +	{ .supply = "vdda-pll" },
>  };
> 
>  static const struct qmp_ufs_offsets qmp_ufs_offsets = {
> @@ -1890,22 +1891,6 @@ static const struct phy_ops qcom_qmp_ufs_phy_ops = {
>  	.owner		= THIS_MODULE,
>  };
> 
> -static int qmp_ufs_vreg_init(struct qmp_ufs *qmp)
> -{
> -	const struct qmp_phy_cfg *cfg = qmp->cfg;
> -	struct device *dev = qmp->dev;
> -	int num = cfg->num_vregs;
> -	int i;
> -
> -	qmp->vregs = devm_kcalloc(dev, num, sizeof(*qmp->vregs), GFP_KERNEL);
> -	if (!qmp->vregs)
> -		return -ENOMEM;
> -
> -	for (i = 0; i < num; i++)
> -		qmp->vregs[i].supply = cfg->vreg_list[i];
> -
> -	return devm_regulator_bulk_get(dev, num, qmp->vregs);
> -}
> 

Stray new line.

With above changes,

Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH V3 2/2] phy: qcom-qmp-ufs: Add regulator loads for SM8650 and SM8750

[Manivannan Sadhasivam]

On Wed, Aug 20, 2025 at 03:58:26AM GMT, Nitin Rawat wrote:
> Add regulator load voting support for SM8650 and SM8750 platforms by
> introducing dedicated regulator bulk data arrays with their load
> values.
> 
> The load requirements are:
> - SM8650: vdda-phy (205mA), vdda-pll (17.5mA)
> - SM8750: vdda-phy (213mA), vdda-pll (18.3mA)
> 
> This ensures stable operation and proper power management for these
> platforms where regulators are shared between the QMP USB PHY and
> other IP blocks by setting appropriate regulator load currents during PHY
> operations.
> 

So it is fixing stability issues on these platforms. Hence, 'Fixes' tag pointing
to the commits that added these platform support should be added.

> Configurations without specific load requirements will continue to work
> unchanged, as init_load_uA remains zero-initialized when .init_load_uA
> is not provided.
> 
> Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com>

Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>

- Mani

> ---
>  drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 19 +++++++++++++++----
>  1 file changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> index aaa88ca0ef07..1c3ce0fa6adf 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> @@ -1170,6 +1170,17 @@ static const struct regulator_bulk_data qmp_phy_vreg_l[] = {
>  	{ .supply = "vdda-pll" },
>  };
> 
> +/* Regulator bulk data with load values for specific configurations */
> +static const struct regulator_bulk_data sm8650_ufsphy_vreg_l[] = {
> +	{ .supply = "vdda-phy", .init_load_uA = 205000 },
> +	{ .supply = "vdda-pll", .init_load_uA = 17500 },
> +};
> +
> +static const struct regulator_bulk_data sm8750_ufsphy_vreg_l[] = {
> +	{ .supply = "vdda-phy", .init_load_uA = 213000 },
> +	{ .supply = "vdda-pll", .init_load_uA = 18300 },
> +};
> +
>  static const struct qmp_ufs_offsets qmp_ufs_offsets = {
>  	.serdes		= 0,
>  	.pcs		= 0xc00,
> @@ -1638,8 +1649,8 @@ static const struct qmp_phy_cfg sm8650_ufsphy_cfg = {
>  		.max_gear	= UFS_HS_G5,
>  	},
> 
> -	.vreg_list		= qmp_phy_vreg_l,
> -	.num_vregs		= ARRAY_SIZE(qmp_phy_vreg_l),
> +	.vreg_list		= sm8650_ufsphy_vreg_l,
> +	.num_vregs		= ARRAY_SIZE(sm8650_ufsphy_vreg_l),
>  	.regs			= ufsphy_v6_regs_layout,
>  };
> 
> @@ -1676,8 +1687,8 @@ static const struct qmp_phy_cfg sm8750_ufsphy_cfg = {
>  		.max_gear	= UFS_HS_G5,
>  	},
> 
> -	.vreg_list		= qmp_phy_vreg_l,
> -	.num_vregs		= ARRAY_SIZE(qmp_phy_vreg_l),
> +	.vreg_list		= sm8750_ufsphy_vreg_l,
> +	.num_vregs		= ARRAY_SIZE(sm8750_ufsphy_vreg_l),
>  	.regs			= ufsphy_v6_regs_layout,
> 
>  };
> --
> 2.48.1
> 

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH V3 2/2] phy: qcom-qmp-ufs: Add regulator loads for SM8650 and SM8750

[Manivannan Sadhasivam]

On Wed, Aug 20, 2025 at 03:49:31AM GMT, Dmitry Baryshkov wrote:
> On Wed, Aug 20, 2025 at 03:58:26AM +0530, Nitin Rawat wrote:
> > Add regulator load voting support for SM8650 and SM8750 platforms by
> > introducing dedicated regulator bulk data arrays with their load
> > values.
> > 
> > The load requirements are:
> > - SM8650: vdda-phy (205mA), vdda-pll (17.5mA)
> > - SM8750: vdda-phy (213mA), vdda-pll (18.3mA)
> > 
> > This ensures stable operation and proper power management for these
> > platforms where regulators are shared between the QMP USB PHY and
> > other IP blocks by setting appropriate regulator load currents during PHY
> > operations.
> > 
> > Configurations without specific load requirements will continue to work
> > unchanged, as init_load_uA remains zero-initialized when .init_load_uA
> > is not provided.
> 
> Can we please get configuration for the rest of the platforms?
> 

Only if the rest of the platforms require setting the load... It is not very
clear if the older platforms share the regulators with other IPs or not.

- Mani

> > 
> > Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com>
> > ---
> >  drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 19 +++++++++++++++----
> >  1 file changed, 15 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> > index aaa88ca0ef07..1c3ce0fa6adf 100644
> > --- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> > +++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> > @@ -1170,6 +1170,17 @@ static const struct regulator_bulk_data qmp_phy_vreg_l[] = {
> >  	{ .supply = "vdda-pll" },
> >  };
> > 
> > +/* Regulator bulk data with load values for specific configurations */
> > +static const struct regulator_bulk_data sm8650_ufsphy_vreg_l[] = {
> > +	{ .supply = "vdda-phy", .init_load_uA = 205000 },
> > +	{ .supply = "vdda-pll", .init_load_uA = 17500 },
> > +};
> > +
> > +static const struct regulator_bulk_data sm8750_ufsphy_vreg_l[] = {
> > +	{ .supply = "vdda-phy", .init_load_uA = 213000 },
> > +	{ .supply = "vdda-pll", .init_load_uA = 18300 },
> > +};
> > +
> >  static const struct qmp_ufs_offsets qmp_ufs_offsets = {
> >  	.serdes		= 0,
> >  	.pcs		= 0xc00,
> > @@ -1638,8 +1649,8 @@ static const struct qmp_phy_cfg sm8650_ufsphy_cfg = {
> >  		.max_gear	= UFS_HS_G5,
> >  	},
> > 
> > -	.vreg_list		= qmp_phy_vreg_l,
> > -	.num_vregs		= ARRAY_SIZE(qmp_phy_vreg_l),
> > +	.vreg_list		= sm8650_ufsphy_vreg_l,
> > +	.num_vregs		= ARRAY_SIZE(sm8650_ufsphy_vreg_l),
> >  	.regs			= ufsphy_v6_regs_layout,
> >  };
> > 
> > @@ -1676,8 +1687,8 @@ static const struct qmp_phy_cfg sm8750_ufsphy_cfg = {
> >  		.max_gear	= UFS_HS_G5,
> >  	},
> > 
> > -	.vreg_list		= qmp_phy_vreg_l,
> > -	.num_vregs		= ARRAY_SIZE(qmp_phy_vreg_l),
> > +	.vreg_list		= sm8750_ufsphy_vreg_l,
> > +	.num_vregs		= ARRAY_SIZE(sm8750_ufsphy_vreg_l),
> >  	.regs			= ufsphy_v6_regs_layout,
> > 
> >  };
> > --
> > 2.48.1
> > 
> 
> -- 
> With best wishes
> Dmitry

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH V3 2/2] phy: qcom-qmp-ufs: Add regulator loads for SM8650 and SM8750

[Dmitry Baryshkov]

On 22/08/2025 11:53, Manivannan Sadhasivam wrote:
> On Wed, Aug 20, 2025 at 03:49:31AM GMT, Dmitry Baryshkov wrote:
>> On Wed, Aug 20, 2025 at 03:58:26AM +0530, Nitin Rawat wrote:
>>> Add regulator load voting support for SM8650 and SM8750 platforms by
>>> introducing dedicated regulator bulk data arrays with their load
>>> values.
>>>
>>> The load requirements are:
>>> - SM8650: vdda-phy (205mA), vdda-pll (17.5mA)
>>> - SM8750: vdda-phy (213mA), vdda-pll (18.3mA)
>>>
>>> This ensures stable operation and proper power management for these
>>> platforms where regulators are shared between the QMP USB PHY and
>>> other IP blocks by setting appropriate regulator load currents during PHY
>>> operations.
>>>
>>> Configurations without specific load requirements will continue to work
>>> unchanged, as init_load_uA remains zero-initialized when .init_load_uA
>>> is not provided.
>>
>> Can we please get configuration for the rest of the platforms?
>>
> 
> Only if the rest of the platforms require setting the load... It is not very
> clear if the older platforms share the regulators with other IPs or not.

Yes, they are usually shared. USB. PCIe and DSI frequently sit on the 
same voltage rails.


-- 
With best wishes
Dmitry

Re: [PATCH V3 2/2] phy: qcom-qmp-ufs: Add regulator loads for SM8650 and SM8750

[Dmitry Baryshkov]

On 21/08/2025 19:02, Nitin Rawat wrote:
> 
> 
> On 8/20/2025 5:24 PM, Dmitry Baryshkov wrote:
>> On Wed, Aug 20, 2025 at 12:07:57PM +0530, Nitin Rawat wrote:
>>>
>>>
>>> On 8/20/2025 6:19 AM, Dmitry Baryshkov wrote:
>>>> On Wed, Aug 20, 2025 at 03:58:26AM +0530, Nitin Rawat wrote:
>>>>> Add regulator load voting support for SM8650 and SM8750 platforms by
>>>>> introducing dedicated regulator bulk data arrays with their load
>>>>> values.
>>>>>
>>>>> The load requirements are:
>>>>> - SM8650: vdda-phy (205mA), vdda-pll (17.5mA)
>>>>> - SM8750: vdda-phy (213mA), vdda-pll (18.3mA)
>>>>>
>>>>> This ensures stable operation and proper power management for these
>>>>> platforms where regulators are shared between the QMP USB PHY and
>>>>> other IP blocks by setting appropriate regulator load currents 
>>>>> during PHY
>>>>> operations.
>>>>>
>>>>> Configurations without specific load requirements will continue to 
>>>>> work
>>>>> unchanged, as init_load_uA remains zero-initialized when .init_load_uA
>>>>> is not provided.
>>>>
>>>> Can we please get configuration for the rest of the platforms?
>>>
>>> Hi Dmitry,
>>>
>>> If you're okay with it, can I merge the configuration for the remaining
>>> platforms in the next patch series after I complete testing on all 
>>> remaining
>>> platforms.
>>
>> You don't need to test, finding MSM8996 or 98 might be troublesome. Just
>> fill in the values from the hardware documentation.
> 
> Hi Dmitry,
> 
> While implementing changes for all remaining platform, I noticed that 
> the "regulator-allow-set-load" property is defined only for SM8750 and 
> SM8850 within the PMIC PHY and PLL device tree nodes which means that 
> even if the UFS PHY driver is updated to vote for this configuration on 
> other platforms, it will have no impact.

If I remember correctly, on other platforms we don't allow setting the 
load exactly because consumers were not voting on the current/power 
requirements.

> 
> Should I still proceed with applying the change across all platform, or 
> limit it to just the SM8750 and SM8850 drivers? What’s your recommendation?

I think, we should proceed, then once all PHYs get those votes we can 
enable load toggling on those platforms too.

> 
> ===========================================================================
> // Device tree:
> vreg_l1j_0p91: ldo1 {
>      regulator-name = "vreg_l1j_0p91";
>      regulator-min-microvolt = <880000>;
>      regulator-max-microvolt = <920000>;
>      regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
>      regulator-allow-set-load;
>      regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM 
> RPMH_REGULATOR_MODE_HPM>;
> };
> 
> ===========================================================================
> drivers/regulator/of_regulator.c
> 
> 
> if (of_property_read_bool(np, "regulator-allow-set-load"))
>          constraints->valid_ops_mask |= REGULATOR_CHANGE_DRMS;
> 
> ===========================================================================
> //drivers/regulator/core.c
> static int drms_uA_update(struct regulator_dev *rdev)
> {
>      ...
>      if (!regulator_ops_is_valid(rdev, REGULATOR_CHANGE_DRMS)) {
>          rdev_dbg(rdev, "DRMS operation not allowed\n");
>          return 0;
>      }
>      ...
> }
> 
> 
> Regards,
> Nitin
> 
> 
> 
> 
>>
> 


-- 
With best wishes
Dmitry

Re: [PATCH V3 2/2] phy: qcom-qmp-ufs: Add regulator loads for SM8650 and SM8750

[Nitin Rawat]

On 8/22/2025 2:45 PM, Dmitry Baryshkov wrote:
> On 22/08/2025 11:53, Manivannan Sadhasivam wrote:
>> On Wed, Aug 20, 2025 at 03:49:31AM GMT, Dmitry Baryshkov wrote:
>>> On Wed, Aug 20, 2025 at 03:58:26AM +0530, Nitin Rawat wrote:
>>>> Add regulator load voting support for SM8650 and SM8750 platforms by
>>>> introducing dedicated regulator bulk data arrays with their load
>>>> values.
>>>>
>>>> The load requirements are:
>>>> - SM8650: vdda-phy (205mA), vdda-pll (17.5mA)
>>>> - SM8750: vdda-phy (213mA), vdda-pll (18.3mA)
>>>>
>>>> This ensures stable operation and proper power management for these
>>>> platforms where regulators are shared between the QMP USB PHY and
>>>> other IP blocks by setting appropriate regulator load currents 
>>>> during PHY
>>>> operations.
>>>>
>>>> Configurations without specific load requirements will continue to work
>>>> unchanged, as init_load_uA remains zero-initialized when .init_load_uA
>>>> is not provided.
>>>
>>> Can we please get configuration for the rest of the platforms?
>>>
>>
>> Only if the rest of the platforms require setting the load... It is 
>> not very
>> clear if the older platforms share the regulators with other IPs or not.
> 
> Yes, they are usually shared. USB. PCIe and DSI frequently sit on the 
> same voltage rails.

Yes, it’s typically shared across multiple clients.

However, as I mentioned earlier, in the current upstream codebase, the 
"regulator-allow-set-load" property is defined only for SM8750 and 
SM8650 within the PMIC PHY and PLL device tree nodes. This means that 
even if the UFS PHY driver is updated to vote for this configuration on 
other platforms, it will have no effect, as the property is not 
supported there.


> 
> 

Re: [PATCH V3 2/2] phy: qcom-qmp-ufs: Add regulator loads for SM8650 and SM8750

[Nitin Rawat]

On 8/22/2025 2:49 PM, Dmitry Baryshkov wrote:
> On 21/08/2025 19:02, Nitin Rawat wrote:
>>
>>
>> On 8/20/2025 5:24 PM, Dmitry Baryshkov wrote:
>>> On Wed, Aug 20, 2025 at 12:07:57PM +0530, Nitin Rawat wrote:
>>>>
>>>>
>>>> On 8/20/2025 6:19 AM, Dmitry Baryshkov wrote:
>>>>> On Wed, Aug 20, 2025 at 03:58:26AM +0530, Nitin Rawat wrote:
>>>>>> Add regulator load voting support for SM8650 and SM8750 platforms by
>>>>>> introducing dedicated regulator bulk data arrays with their load
>>>>>> values.
>>>>>>
>>>>>> The load requirements are:
>>>>>> - SM8650: vdda-phy (205mA), vdda-pll (17.5mA)
>>>>>> - SM8750: vdda-phy (213mA), vdda-pll (18.3mA)
>>>>>>
>>>>>> This ensures stable operation and proper power management for these
>>>>>> platforms where regulators are shared between the QMP USB PHY and
>>>>>> other IP blocks by setting appropriate regulator load currents 
>>>>>> during PHY
>>>>>> operations.
>>>>>>
>>>>>> Configurations without specific load requirements will continue to 
>>>>>> work
>>>>>> unchanged, as init_load_uA remains zero-initialized 
>>>>>> when .init_load_uA
>>>>>> is not provided.
>>>>>
>>>>> Can we please get configuration for the rest of the platforms?
>>>>
>>>> Hi Dmitry,
>>>>
>>>> If you're okay with it, can I merge the configuration for the remaining
>>>> platforms in the next patch series after I complete testing on all 
>>>> remaining
>>>> platforms.
>>>
>>> You don't need to test, finding MSM8996 or 98 might be troublesome. Just
>>> fill in the values from the hardware documentation.
>>
>> Hi Dmitry,
>>
>> While implementing changes for all remaining platform, I noticed that 
>> the "regulator-allow-set-load" property is defined only for SM8750 and 
>> SM8850 within the PMIC PHY and PLL device tree nodes which means that 
>> even if the UFS PHY driver is updated to vote for this configuration 
>> on other platforms, it will have no impact.
> 
> If I remember correctly, on other platforms we don't allow setting the 
> load exactly because consumers were not voting on the current/power 
> requirements.
> 
>>
>> Should I still proceed with applying the change across all platform, 
>> or limit it to just the SM8750 and SM8850 drivers? What’s your 
>> recommendation?
> 
> I think, we should proceed, then once all PHYs get those votes we can 
> enable load toggling on those platforms too.

Sure Dmitry. I'll make the change in next patchset.



> 
>>
>> ===========================================================================
>> // Device tree:
>> vreg_l1j_0p91: ldo1 {
>>      regulator-name = "vreg_l1j_0p91";
>>      regulator-min-microvolt = <880000>;
>>      regulator-max-microvolt = <920000>;
>>      regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
>>      regulator-allow-set-load;
>>      regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM 
>> RPMH_REGULATOR_MODE_HPM>;
>> };
>>
>> ===========================================================================
>> drivers/regulator/of_regulator.c
>>
>>
>> if (of_property_read_bool(np, "regulator-allow-set-load"))
>>          constraints->valid_ops_mask |= REGULATOR_CHANGE_DRMS;
>>
>> ===========================================================================
>> //drivers/regulator/core.c
>> static int drms_uA_update(struct regulator_dev *rdev)
>> {
>>      ...
>>      if (!regulator_ops_is_valid(rdev, REGULATOR_CHANGE_DRMS)) {
>>          rdev_dbg(rdev, "DRMS operation not allowed\n");
>>          return 0;
>>      }
>>      ...
>> }
>>
>>
>> Regards,
>> Nitin
>>
>>
>>
>>
>>>
>>
> 
> 

Re: [PATCH V3 2/2] phy: qcom-qmp-ufs: Add regulator loads for SM8650 and SM8750

[Manivannan Sadhasivam]

On Fri, Aug 22, 2025 at 02:53:31PM GMT, Nitin Rawat wrote:
> 
> 
> On 8/22/2025 2:45 PM, Dmitry Baryshkov wrote:
> > On 22/08/2025 11:53, Manivannan Sadhasivam wrote:
> > > On Wed, Aug 20, 2025 at 03:49:31AM GMT, Dmitry Baryshkov wrote:
> > > > On Wed, Aug 20, 2025 at 03:58:26AM +0530, Nitin Rawat wrote:
> > > > > Add regulator load voting support for SM8650 and SM8750 platforms by
> > > > > introducing dedicated regulator bulk data arrays with their load
> > > > > values.
> > > > > 
> > > > > The load requirements are:
> > > > > - SM8650: vdda-phy (205mA), vdda-pll (17.5mA)
> > > > > - SM8750: vdda-phy (213mA), vdda-pll (18.3mA)
> > > > > 
> > > > > This ensures stable operation and proper power management for these
> > > > > platforms where regulators are shared between the QMP USB PHY and
> > > > > other IP blocks by setting appropriate regulator load
> > > > > currents during PHY
> > > > > operations.
> > > > > 
> > > > > Configurations without specific load requirements will continue to work
> > > > > unchanged, as init_load_uA remains zero-initialized when .init_load_uA
> > > > > is not provided.
> > > > 
> > > > Can we please get configuration for the rest of the platforms?
> > > > 
> > > 
> > > Only if the rest of the platforms require setting the load... It is
> > > not very
> > > clear if the older platforms share the regulators with other IPs or not.
> > 
> > Yes, they are usually shared. USB. PCIe and DSI frequently sit on the
> > same voltage rails.
> 
> Yes, it’s typically shared across multiple clients.
> 
> However, as I mentioned earlier, in the current upstream codebase, the
> "regulator-allow-set-load" property is defined only for SM8750 and SM8650
> within the PMIC PHY and PLL device tree nodes. This means that even if the
> UFS PHY driver is updated to vote for this configuration on other platforms,
> it will have no effect, as the property is not supported there.
> 

Which means:

1. Those platforms are still prone to this stability issue.
2. Only UFS is setting the regulator constraint, but not other drivers sharing
the same regulator.

IMO, both cases are bad. At leat, you can update the UFS driver to set the load
now and later on add the DTS property as a follow-up series for those platforms.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH V3 2/2] phy: qcom-qmp-ufs: Add regulator loads for SM8650 and SM8750

[Nitin Rawat]

On 8/22/2025 4:26 PM, Manivannan Sadhasivam wrote:
> On Fri, Aug 22, 2025 at 02:53:31PM GMT, Nitin Rawat wrote:
>>
>>
>> On 8/22/2025 2:45 PM, Dmitry Baryshkov wrote:
>>> On 22/08/2025 11:53, Manivannan Sadhasivam wrote:
>>>> On Wed, Aug 20, 2025 at 03:49:31AM GMT, Dmitry Baryshkov wrote:
>>>>> On Wed, Aug 20, 2025 at 03:58:26AM +0530, Nitin Rawat wrote:
>>>>>> Add regulator load voting support for SM8650 and SM8750 platforms by
>>>>>> introducing dedicated regulator bulk data arrays with their load
>>>>>> values.
>>>>>>
>>>>>> The load requirements are:
>>>>>> - SM8650: vdda-phy (205mA), vdda-pll (17.5mA)
>>>>>> - SM8750: vdda-phy (213mA), vdda-pll (18.3mA)
>>>>>>
>>>>>> This ensures stable operation and proper power management for these
>>>>>> platforms where regulators are shared between the QMP USB PHY and
>>>>>> other IP blocks by setting appropriate regulator load
>>>>>> currents during PHY
>>>>>> operations.
>>>>>>
>>>>>> Configurations without specific load requirements will continue to work
>>>>>> unchanged, as init_load_uA remains zero-initialized when .init_load_uA
>>>>>> is not provided.
>>>>>
>>>>> Can we please get configuration for the rest of the platforms?
>>>>>
>>>>
>>>> Only if the rest of the platforms require setting the load... It is
>>>> not very
>>>> clear if the older platforms share the regulators with other IPs or not.
>>>
>>> Yes, they are usually shared. USB. PCIe and DSI frequently sit on the
>>> same voltage rails.
>>
>> Yes, it’s typically shared across multiple clients.
>>
>> However, as I mentioned earlier, in the current upstream codebase, the
>> "regulator-allow-set-load" property is defined only for SM8750 and SM8650
>> within the PMIC PHY and PLL device tree nodes. This means that even if the
>> UFS PHY driver is updated to vote for this configuration on other platforms,
>> it will have no effect, as the property is not supported there.
>>
> 
> Which means:
> 
> 1. Those platforms are still prone to this stability issue.
> 2. Only UFS is setting the regulator constraint, but not other drivers sharing
> the same regulator.

You understanding is correct.

> 
> IMO, both cases are bad. At leat, you can update the UFS driver to set the load
> now and later on add the DTS property as a follow-up series for those platforms.


sure will take care of this.>
> - Mani



>