[RFC PATCH 0/3] Add current load setting for qcom camss csiphy

[RFC PATCH 0/3] Add current load setting for qcom camss csiphy

[Wenmeng Liu]

Currently qcom camss csiphy drivers don’t set regulator’s currents
load properly using Linux regulator framework. This causes every 
regulator’s initial mode set as HPM (high current mode), 
which may have higher power consumption.
To address this issue, add current configuration for CSIPHY.

Wenmeng Liu (3):
  media: dt-bindings: Add regulator current load
  media: qcom: camss: csiphy: Add regulator current load setting
  arm64: dts: qcom: qcs6490-rb3gen2: Add csiphy current support

 .../bindings/media/qcom,sc7280-camss.yaml     |  6 ++++
 .../qcs6490-rb3gen2-vision-mezzanine.dtso     |  1 +
 .../media/platform/qcom/camss/camss-csiphy.c  | 29 +++++++++++++++++++
 .../media/platform/qcom/camss/camss-csiphy.h  |  1 +
 4 files changed, 37 insertions(+)

-- 
2.34.1

[RFC PATCH 1/3] media: dt-bindings: Add regulator current load

[Wenmeng Liu]

Add regulator current load support for vdda-phy vdda-pll.

Signed-off-by: Wenmeng Liu <quic_wenmliu@quicinc.com>
---
 .../devicetree/bindings/media/qcom,sc7280-camss.yaml        | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/qcom,sc7280-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sc7280-camss.yaml
index ee35e3bc97ff..a1ae4701d178 100644
--- a/Documentation/devicetree/bindings/media/qcom,sc7280-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sc7280-camss.yaml
@@ -131,6 +131,12 @@ properties:
     description:
       Phandle to 1.8V regulator supply to PHY refclk pll block.
 
+  regulator-load-current:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description: |
+      Specifies the load current (in microamperes) for the regulators used by the device.
+      The first value corresponds to vdda-phy, and the second to vdda-pll.
+
   ports:
     $ref: /schemas/graph.yaml#/properties/ports
 
-- 
2.34.1

[RFC PATCH 2/3] media: qcom: camss: csiphy: Add regulator current load setting

[Wenmeng Liu]

Add support for current load in csiphy.

Signed-off-by: Wenmeng Liu <quic_wenmliu@quicinc.com>
---
 .../media/platform/qcom/camss/camss-csiphy.c  | 29 +++++++++++++++++++
 .../media/platform/qcom/camss/camss-csiphy.h  |  1 +
 2 files changed, 30 insertions(+)

diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c b/drivers/media/platform/qcom/camss/camss-csiphy.c
index c622efcc92ff..c3069e8a6b62 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
@@ -209,6 +209,7 @@ static int csiphy_set_power(struct v4l2_subdev *sd, int on)
 {
 	struct csiphy_device *csiphy = v4l2_get_subdevdata(sd);
 	struct device *dev = csiphy->camss->dev;
+	int i;
 
 	if (on) {
 		int ret;
@@ -217,6 +218,15 @@ static int csiphy_set_power(struct v4l2_subdev *sd, int on)
 		if (ret < 0)
 			return ret;
 
+		if (csiphy->load_currents) {
+			for (i = 0; i < csiphy->num_supplies; i++) {
+				ret = regulator_set_load(csiphy->supplies[i].consumer,
+							 csiphy->load_currents[i]);
+			if (ret)
+				return ret;
+			}
+		}
+
 		ret = regulator_bulk_enable(csiphy->num_supplies,
 					    csiphy->supplies);
 		if (ret < 0) {
@@ -250,6 +260,11 @@ static int csiphy_set_power(struct v4l2_subdev *sd, int on)
 
 		camss_disable_clocks(csiphy->nclocks, csiphy->clock);
 
+		if (csiphy->load_currents) {
+			for (i = 0; i < csiphy->num_supplies; i++)
+				regulator_set_load(csiphy->supplies[i].consumer, 0);
+		}
+
 		regulator_bulk_disable(csiphy->num_supplies, csiphy->supplies);
 
 		pm_runtime_put_sync(dev);
@@ -717,6 +732,20 @@ int msm_csiphy_subdev_init(struct camss *camss,
 
 	ret = devm_regulator_bulk_get(camss->dev, csiphy->num_supplies,
 				      csiphy->supplies);
+
+	if (device_property_present(camss->dev, "regulator-load-current")) {
+		csiphy->load_currents = kcalloc(csiphy->num_supplies, sizeof(u32), GFP_KERNEL);
+		if (!csiphy->load_currents)
+			return -ENOMEM;
+
+		ret = device_property_read_u32_array(camss->dev,
+						     "regulator-load-current",
+						     csiphy->load_currents,
+						     csiphy->num_supplies);
+		for (i = 0; i < csiphy->num_supplies; i++)
+			regulator_set_load(csiphy->supplies[i].consumer, 0);
+	}
+
 	return ret;
 }
 
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.h b/drivers/media/platform/qcom/camss/camss-csiphy.h
index ab91273303b9..74ebfc67a375 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.h
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.h
@@ -106,6 +106,7 @@ struct csiphy_device {
 	int nclocks;
 	u32 timer_clk_rate;
 	struct regulator_bulk_data *supplies;
+	u32 *load_currents;
 	int num_supplies;
 	struct csiphy_config cfg;
 	struct v4l2_mbus_framefmt fmt[MSM_CSIPHY_PADS_NUM];
-- 
2.34.1

[RFC PATCH 3/3] arm64: dts: qcom: qcs6490-rb3gen2: Add csiphy current support

[Wenmeng Liu]

Add csiphy current value to support csiphy current load setting.

Signed-off-by: Wenmeng Liu <quic_wenmliu@quicinc.com>
---
 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-vision-mezzanine.dtso | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-vision-mezzanine.dtso b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-vision-mezzanine.dtso
index b9e4a5214f70..60e7d46db394 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-vision-mezzanine.dtso
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-vision-mezzanine.dtso
@@ -16,6 +16,7 @@
 &camss {
 	vdda-phy-supply = <&vreg_l10c_0p88>;
 	vdda-pll-supply = <&vreg_l6b_1p2>;
+	regulator-load-current = <54000 96400>;
 
 	status = "okay";
 
-- 
2.34.1

Re: [RFC PATCH 0/3] Add current load setting for qcom camss csiphy

[Bryan O'Donoghue]

On 20/06/2025 05:07, Wenmeng Liu wrote:
> Currently qcom camss csiphy drivers don’t set regulator’s currents
> load properly using Linux regulator framework. This causes every
> regulator’s initial mode set as HPM (high current mode),
> which may have higher power consumption.
> To address this issue, add current configuration for CSIPHY.
> 
> Wenmeng Liu (3):
>    media: dt-bindings: Add regulator current load
>    media: qcom: camss: csiphy: Add regulator current load setting
>    arm64: dts: qcom: qcs6490-rb3gen2: Add csiphy current support
> 
>   .../bindings/media/qcom,sc7280-camss.yaml     |  6 ++++
>   .../qcs6490-rb3gen2-vision-mezzanine.dtso     |  1 +
>   .../media/platform/qcom/camss/camss-csiphy.c  | 29 +++++++++++++++++++
>   .../media/platform/qcom/camss/camss-csiphy.h  |  1 +
>   4 files changed, 37 insertions(+)
> 

How are these load-currents determined ?

Looking at other instances of setting current for PHYs

  grep -r regulator_set_load * | grep com 
  
            [git:camss-bugfix-6.17] ✖
drivers/phy/qualcomm/phy-qcom-edp.c:	ret = 
regulator_set_load(edp->supplies[0].consumer, 21800); /* 1.2 V vdda-phy */
drivers/phy/qualcomm/phy-qcom-edp.c:	ret = 
regulator_set_load(edp->supplies[1].consumer, 36000); /* 0.9 V vdda-pll */
drivers/phy/qualcomm/phy-qcom-usb-hs.c:	ret = 
regulator_set_load(uphy->v1p8, 50000);
drivers/phy/qualcomm/phy-qcom-usb-hs.c:	ret = 
regulator_set_load(uphy->v3p3, 50000);
drivers/phy/qualcomm/phy-qcom-usb-hs-28nm.c:	ret = 
regulator_set_load(priv->vregs[VDDA_1P8].consumer, 19000);
drivers/phy/qualcomm/phy-qcom-usb-hs-28nm.c:	ret = 
regulator_set_load(priv->vregs[VDDA_3P3].consumer, 16000);
drivers/phy/qualcomm/phy-qcom-usb-hs-28nm.c: 
regulator_set_load(priv->vregs[VDDA_1P8].consumer, 0);
drivers/phy/qualcomm/phy-qcom-qmp-combo.c:		ret = 
regulator_set_load(qmp->vregs[i].consumer,
drivers/remoteproc/qcom_q6v5_pas.c:		regulator_set_load(adsp->cx_supply, 
100000);
drivers/remoteproc/qcom_wcnss.c:			regulator_set_load(bulk[i].consumer, 
info[i].load_uA);
drivers/remoteproc/qcom_wcnss_iris.c:		 
regulator_set_load(iris->vregs[i].consumer,
drivers/remoteproc/qcom_q6v5_mss.c:			ret = regulator_set_load(regs[i].reg,
drivers/remoteproc/qcom_q6v5_mss.c:			regulator_set_load(regs[i].reg, 0);
drivers/remoteproc/qcom_q6v5_mss.c:			regulator_set_load(regs[i].reg, 0);
drivers/remoteproc/qcom_q6v5_wcss.c:	regulator_set_load(wcss->cx_supply, 
100000);

I think this is the type of thing we should bury in SoC resources not in DT.

I can think of how we might want to change the current depending on the 
pixel rate.. but then I think that is something we could calculate based 
on pixel rate with descriptions as a base in

driver/media/platfrom/qcom/camss/camss.c::static const struct 
camss_subdev_resources csiphy_res_SoCNumber[];

---
bod

Re: [RFC PATCH 3/3] arm64: dts: qcom: qcs6490-rb3gen2: Add csiphy current support

[Krzysztof Kozlowski]

On 20/06/2025 06:07, Wenmeng Liu wrote:
> Add csiphy current value to support csiphy current load setting.

Why? Why doing this? Why is this needed?

Best regards,
Krzysztof

Re: [RFC PATCH 1/3] media: dt-bindings: Add regulator current load

[Krzysztof Kozlowski]

On 20/06/2025 06:07, Wenmeng Liu wrote:
> Add regulator current load support for vdda-phy vdda-pll.
> 
> Signed-off-by: Wenmeng Liu <quic_wenmliu@quicinc.com>
> ---
>  .../devicetree/bindings/media/qcom,sc7280-camss.yaml        | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

This patch fails on so many levels... do internal reviews first.

Use existing properties, see regulators. If not, use existing unit
suffixes. Otherwise it is just another downstream property you send us,
to which we responded many times - don't.

Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters

Read meeting notes from internal discussions where you discussed this
already.

Best regards,
Krzysztof

Re: [RFC PATCH 0/3] Add current load setting for qcom camss csiphy

[Wenmeng Liu]

On 2025/6/20 16:23, Bryan O'Donoghue wrote:
> On 20/06/2025 05:07, Wenmeng Liu wrote:
>> Currently qcom camss csiphy drivers don’t set regulator’s currents
>> load properly using Linux regulator framework. This causes every
>> regulator’s initial mode set as HPM (high current mode),
>> which may have higher power consumption.
>> To address this issue, add current configuration for CSIPHY.
>>
>> Wenmeng Liu (3):
>>    media: dt-bindings: Add regulator current load
>>    media: qcom: camss: csiphy: Add regulator current load setting
>>    arm64: dts: qcom: qcs6490-rb3gen2: Add csiphy current support
>>
>>   .../bindings/media/qcom,sc7280-camss.yaml     |  6 ++++
>>   .../qcs6490-rb3gen2-vision-mezzanine.dtso     |  1 +
>>   .../media/platform/qcom/camss/camss-csiphy.c  | 29 +++++++++++++++++++
>>   .../media/platform/qcom/camss/camss-csiphy.h  |  1 +
>>   4 files changed, 37 insertions(+)
>>
> 
> How are these load-currents determined ?

According to my discussion with hw colleague,current value is decided 
based on post silicon calibration, this value is fixed for the 
corresponding chip.

> Looking at other instances of setting current for PHYs
> 
>   grep -r regulator_set_load * | grep com
>             [git:camss-bugfix-6.17] ✖
> drivers/phy/qualcomm/phy-qcom-edp.c:    ret = regulator_set_load(edp- 
>  >supplies[0].consumer, 21800); /* 1.2 V vdda-phy */
> drivers/phy/qualcomm/phy-qcom-edp.c:    ret = regulator_set_load(edp- 
>  >supplies[1].consumer, 36000); /* 0.9 V vdda-pll */
> drivers/phy/qualcomm/phy-qcom-usb-hs.c:    ret = 
> regulator_set_load(uphy->v1p8, 50000);
> drivers/phy/qualcomm/phy-qcom-usb-hs.c:    ret = 
> regulator_set_load(uphy->v3p3, 50000);
> drivers/phy/qualcomm/phy-qcom-usb-hs-28nm.c:    ret = 
> regulator_set_load(priv->vregs[VDDA_1P8].consumer, 19000);
> drivers/phy/qualcomm/phy-qcom-usb-hs-28nm.c:    ret = 
> regulator_set_load(priv->vregs[VDDA_3P3].consumer, 16000);
> drivers/phy/qualcomm/phy-qcom-usb-hs-28nm.c: regulator_set_load(priv- 
>  >vregs[VDDA_1P8].consumer, 0);
> drivers/phy/qualcomm/phy-qcom-qmp-combo.c:        ret = 
> regulator_set_load(qmp->vregs[i].consumer,
> drivers/remoteproc/qcom_q6v5_pas.c:        regulator_set_load(adsp- 
>  >cx_supply, 100000);
> drivers/remoteproc/qcom_wcnss.c:            
> regulator_set_load(bulk[i].consumer, info[i].load_uA);
> drivers/remoteproc/qcom_wcnss_iris.c: regulator_set_load(iris- 
>  >vregs[i].consumer,
> drivers/remoteproc/qcom_q6v5_mss.c:            ret = 
> regulator_set_load(regs[i].reg,
> drivers/remoteproc/qcom_q6v5_mss.c:            
> regulator_set_load(regs[i].reg, 0);
> drivers/remoteproc/qcom_q6v5_mss.c:            
> regulator_set_load(regs[i].reg, 0);
> drivers/remoteproc/qcom_q6v5_wcss.c:    regulator_set_load(wcss- 
>  >cx_supply, 100000);
> 
> I think this is the type of thing we should bury in SoC resources not in 
> DT.
> 
> I can think of how we might want to change the current depending on the 
> pixel rate.. but then I think that is something we could calculate based 
> on pixel rate with descriptions as a base in
> 
> driver/media/platfrom/qcom/camss/camss.c::static const struct 
> camss_subdev_resources csiphy_res_SoCNumber[];
> 
> ---
> bod
> 

Yes, it's more common to put the current value in the code.Will be 
updated in v2.

Thanks,
Wenmeng