[PATCH 0/2] arm64: dts: qcom: sm8550: camcc: Manage MMCX and MXC

[PATCH 0/2] arm64: dts: qcom: sm8550: camcc: Manage MMCX and MXC

[Vladimir Zapolskiy]

It was discovered that on SM8550 platform Camera Clock controller shall
manage MMCX and MXC power domains, otherwise MMIO access to CCI or CAMSS
breaks the execution, the problem has been discussed with Jagadeesh at
https://lore.kernel.org/all/a5540676-9402-45c4-b647-02fdc2b92233@quicinc.com/

Since 'power-domains' property becomes generalized, Rob asked to remove
its description, which is done in the first patch of the series, see
https://lore.kernel.org/all/20240927224833.GA159707-robh@kernel.org/

Vladimir Zapolskiy (2):
  dt-bindings: clock: qcom: sm8450-camcc: Allow to specify two power domains
  arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

 .../devicetree/bindings/clock/qcom,sm8450-camcc.yaml          | 4 +---
 arch/arm64/boot/dts/qcom/sm8550.dtsi                          | 3 ++-
 2 files changed, 3 insertions(+), 4 deletions(-)

-- 
2.43.0

[PATCH 1/2] dt-bindings: clock: qcom: sm8450-camcc: Allow to specify two power domains

[Vladimir Zapolskiy]

During the tests it was unveiled and later it was confirmed that SM8550
Camera Clock Controller shall enable both MXC and MMCX power domains.

Since power-domains property is not specific to MMCX anymore, its
description is removed.

Fixes: 9cbc64745fc6 ("dt-bindings: clock: qcom: Add SM8550 camera clock controller")
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 .../devicetree/bindings/clock/qcom,sm8450-camcc.yaml          | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
index 9e79f8fec437..d7fc9e5a2d20 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
@@ -37,9 +37,7 @@ properties:
       - description: Sleep clock source
 
   power-domains:
-    maxItems: 1
-    description:
-      A phandle and PM domain specifier for the MMCX power domain.
+    maxItems: 2
 
   required-opps:
     maxItems: 1
-- 
2.43.0

Re: [PATCH 1/2] dt-bindings: clock: qcom: sm8450-camcc: Allow to specify two power domains

[Dmitry Baryshkov]

On Tue, Mar 04, 2025 at 12:55:20AM +0200, Vladimir Zapolskiy wrote:
> During the tests it was unveiled and later it was confirmed that SM8550
> Camera Clock Controller shall enable both MXC and MMCX power domains.
> 
> Since power-domains property is not specific to MMCX anymore, its
> description is removed.
> 
> Fixes: 9cbc64745fc6 ("dt-bindings: clock: qcom: Add SM8550 camera clock controller")
> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> ---
>  .../devicetree/bindings/clock/qcom,sm8450-camcc.yaml          | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
> index 9e79f8fec437..d7fc9e5a2d20 100644
> --- a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
> @@ -37,9 +37,7 @@ properties:
>        - description: Sleep clock source
>  
>    power-domains:
> -    maxItems: 1
> -    description:
> -      A phandle and PM domain specifier for the MMCX power domain.
> +    maxItems: 2

items:
 - description: foo
 - description: bar

Also, don't we need power-domain-names now?

>  
>    required-opps:
>      maxItems: 1
> -- 
> 2.43.0
> 

-- 
With best wishes
Dmitry

Re: [PATCH 1/2] dt-bindings: clock: qcom: sm8450-camcc: Allow to specify two power domains

[Rob Herring (Arm)]

On Tue, 04 Mar 2025 00:55:20 +0200, Vladimir Zapolskiy wrote:
> During the tests it was unveiled and later it was confirmed that SM8550
> Camera Clock Controller shall enable both MXC and MMCX power domains.
> 
> Since power-domains property is not specific to MMCX anymore, its
> description is removed.
> 
> Fixes: 9cbc64745fc6 ("dt-bindings: clock: qcom: Add SM8550 camera clock controller")
> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> ---
>  .../devicetree/bindings/clock/qcom,sm8450-camcc.yaml          | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.example.dtb: clock-controller@ade0000: power-domains: [[4294967295, 6]] is too short
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.example.dtb: clock-controller@ade0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250303225521.1780611-2-vladimir.zapolskiy@linaro.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

[PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Vladimir Zapolskiy]

SM8550 Camera Clock Controller shall enable both MXC and MMCX power
domains.

Fixes: e271b59e39a6f ("arm64: dts: qcom: sm8550: Add camera clock controller")
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8550.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index d02d80d731b9..d22b1753d521 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -3329,7 +3329,8 @@ camcc: clock-controller@ade0000 {
 				 <&bi_tcxo_div2>,
 				 <&bi_tcxo_ao_div2>,
 				 <&sleep_clk>;
-			power-domains = <&rpmhpd SM8550_MMCX>;
+			power-domains = <&rpmhpd SM8550_MXC>,
+					<&rpmhpd SM8550_MMCX>;
 			required-opps = <&rpmhpd_opp_low_svs>;
 			#clock-cells = <1>;
 			#reset-cells = <1>;
-- 
2.43.0

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Dmitry Baryshkov]

On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
> domains.

Are those really required to access the registers of the cammcc? Or is
one of those (MXC?) required to setup PLLs? Also, is this applicable
only to sm8550 or to other similar clock controllers?

> 
> Fixes: e271b59e39a6f ("arm64: dts: qcom: sm8550: Add camera clock controller")
> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> ---
>  arch/arm64/boot/dts/qcom/sm8550.dtsi | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> index d02d80d731b9..d22b1753d521 100644
> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> @@ -3329,7 +3329,8 @@ camcc: clock-controller@ade0000 {
>  				 <&bi_tcxo_div2>,
>  				 <&bi_tcxo_ao_div2>,
>  				 <&sleep_clk>;
> -			power-domains = <&rpmhpd SM8550_MMCX>;
> +			power-domains = <&rpmhpd SM8550_MXC>,
> +					<&rpmhpd SM8550_MMCX>;
>  			required-opps = <&rpmhpd_opp_low_svs>;
>  			#clock-cells = <1>;
>  			#reset-cells = <1>;
> -- 
> 2.43.0
> 

-- 
With best wishes
Dmitry

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Vladimir Zapolskiy]

Hi Dmitry,

On 3/4/25 01:53, Dmitry Baryshkov wrote:
> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>> domains.
> 
> Are those really required to access the registers of the cammcc? Or is
> one of those (MXC?) required to setup PLLs? Also, is this applicable
> only to sm8550 or to other similar clock controllers?

as it is stated in the cover letter, both power domans shall be on
to access CCI or CAMSS.

>>
>> Fixes: e271b59e39a6f ("arm64: dts: qcom: sm8550: Add camera clock controller")
>> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
>> ---
>>   arch/arm64/boot/dts/qcom/sm8550.dtsi | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
>> index d02d80d731b9..d22b1753d521 100644
>> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
>> @@ -3329,7 +3329,8 @@ camcc: clock-controller@ade0000 {
>>   				 <&bi_tcxo_div2>,
>>   				 <&bi_tcxo_ao_div2>,
>>   				 <&sleep_clk>;
>> -			power-domains = <&rpmhpd SM8550_MMCX>;
>> +			power-domains = <&rpmhpd SM8550_MXC>,
>> +					<&rpmhpd SM8550_MMCX>;
>>   			required-opps = <&rpmhpd_opp_low_svs>;
>>   			#clock-cells = <1>;
>>   			#reset-cells = <1>;
>> -- 
>> 2.43.0
>>
> 

--
Best wishes,
Vladimir

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Vladimir Zapolskiy]

On 3/4/25 01:53, Dmitry Baryshkov wrote:
> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>> domains.
> 
> Are those really required to access the registers of the cammcc? Or is
> one of those (MXC?) required to setup PLLs? Also, is this applicable
> only to sm8550 or to other similar clock controllers?

Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
not on any SM8450 or SM8650 powered board for instance, however it does
not exclude an option that the problem has to be fixed for other clock
controllers, but it's Qualcomm to confirm any other touched platforms,
for instance x1e80100-camcc has it resolved right at the beginning.

To my understanding here 'required-opps' shall also be generalized, so
the done copy from x1e80100-camcc was improper, and the latter dt-binding
should be fixed.

--
Best wishes,
Vladimir

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Dmitry Baryshkov]

On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
<vladimir.zapolskiy@linaro.org> wrote:
>
> On 3/4/25 01:53, Dmitry Baryshkov wrote:
> > On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
> >> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
> >> domains.
> >
> > Are those really required to access the registers of the cammcc? Or is
> > one of those (MXC?) required to setup PLLs? Also, is this applicable
> > only to sm8550 or to other similar clock controllers?
>
> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
> not on any SM8450 or SM8650 powered board for instance, however it does
> not exclude an option that the problem has to be fixed for other clock
> controllers, but it's Qualcomm to confirm any other touched platforms,

Please work with Taniya to identify used power domains.

> for instance x1e80100-camcc has it resolved right at the beginning.
>
> To my understanding here 'required-opps' shall also be generalized, so
> the done copy from x1e80100-camcc was improper, and the latter dt-binding
> should be fixed.

Yes



-- 
With best wishes
Dmitry

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Taniya Das]

On 3/4/2025 2:10 PM, Dmitry Baryshkov wrote:
> On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
> <vladimir.zapolskiy@linaro.org> wrote:
>>
>> On 3/4/25 01:53, Dmitry Baryshkov wrote:
>>> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>>>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>>>> domains.
>>>
>>> Are those really required to access the registers of the cammcc? Or is
>>> one of those (MXC?) required to setup PLLs? Also, is this applicable
>>> only to sm8550 or to other similar clock controllers?
>>
>> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
>> not on any SM8450 or SM8650 powered board for instance, however it does
>> not exclude an option that the problem has to be fixed for other clock
>> controllers, but it's Qualcomm to confirm any other touched platforms,
> 
> Please work with Taniya to identify used power domains.
> 

CAMCC requires both MMCX and MXC to be functional.

>> for instance x1e80100-camcc has it resolved right at the beginning.
>>
>> To my understanding here 'required-opps' shall also be generalized, so
>> the done copy from x1e80100-camcc was improper, and the latter dt-binding
>> should be fixed.
> 
> Yes
> 

required-opps is not mandatory for MXC as we ensure that MxC would never
hit retention.

https://lore.kernel.org/r/20240625-avoid_mxc_retention-v2-1-af9c2f549a5f@quicinc.com


> 
> 

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Dmitry Baryshkov]

On Thu, Mar 13, 2025 at 10:09:05AM +0530, Taniya Das wrote:
> 
> 
> On 3/4/2025 2:10 PM, Dmitry Baryshkov wrote:
> > On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
> > <vladimir.zapolskiy@linaro.org> wrote:
> >>
> >> On 3/4/25 01:53, Dmitry Baryshkov wrote:
> >>> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
> >>>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
> >>>> domains.
> >>>
> >>> Are those really required to access the registers of the cammcc? Or is
> >>> one of those (MXC?) required to setup PLLs? Also, is this applicable
> >>> only to sm8550 or to other similar clock controllers?
> >>
> >> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
> >> not on any SM8450 or SM8650 powered board for instance, however it does
> >> not exclude an option that the problem has to be fixed for other clock
> >> controllers, but it's Qualcomm to confirm any other touched platforms,
> > 
> > Please work with Taniya to identify used power domains.
> > 
> 
> CAMCC requires both MMCX and MXC to be functional.
> 
> >> for instance x1e80100-camcc has it resolved right at the beginning.
> >>
> >> To my understanding here 'required-opps' shall also be generalized, so
> >> the done copy from x1e80100-camcc was improper, and the latter dt-binding
> >> should be fixed.
> > 
> > Yes
> > 
> 
> required-opps is not mandatory for MXC as we ensure that MxC would never
> hit retention.
> 
> https://lore.kernel.org/r/20240625-avoid_mxc_retention-v2-1-af9c2f549a5f@quicinc.com

Yes. And the code in genpd_set_required_opp() tolerates not seting the
extra opps. However I'd certainly suggest not doing that (I think
passing <0> should work). Having different number of items in
power-domains and required-opps makes it harder to read the DT.

-- 
With best wishes
Dmitry

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Luca Weiss]

Hi Taniya,

On Thu Mar 13, 2025 at 5:39 AM CET, Taniya Das wrote:
>
>
> On 3/4/2025 2:10 PM, Dmitry Baryshkov wrote:
>> On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
>> <vladimir.zapolskiy@linaro.org> wrote:
>>>
>>> On 3/4/25 01:53, Dmitry Baryshkov wrote:
>>>> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>>>>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>>>>> domains.
>>>>
>>>> Are those really required to access the registers of the cammcc? Or is
>>>> one of those (MXC?) required to setup PLLs? Also, is this applicable
>>>> only to sm8550 or to other similar clock controllers?
>>>
>>> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
>>> not on any SM8450 or SM8650 powered board for instance, however it does
>>> not exclude an option that the problem has to be fixed for other clock
>>> controllers, but it's Qualcomm to confirm any other touched platforms,
>> 
>> Please work with Taniya to identify used power domains.
>> 
>
> CAMCC requires both MMCX and MXC to be functional.

Could you check whether any clock controllers on SM6350/SM7225 (Bitra)
need multiple power domains, or in general which clock controller uses
which power domain.

That SoC has camcc, dispcc, gcc, gpucc, npucc and videocc.

That'd be highly appreciated since I've been hitting weird issues there
that could be explained by some missing power domains.

Regards
Luca

>
>>> for instance x1e80100-camcc has it resolved right at the beginning.
>>>
>>> To my understanding here 'required-opps' shall also be generalized, so
>>> the done copy from x1e80100-camcc was improper, and the latter dt-binding
>>> should be fixed.
>> 
>> Yes
>> 
>
> required-opps is not mandatory for MXC as we ensure that MxC would never
> hit retention.
>
> https://lore.kernel.org/r/20240625-avoid_mxc_retention-v2-1-af9c2f549a5f@quicinc.com
>
>
>> 
>> 

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Taniya Das]

On 3/13/2025 1:22 PM, Luca Weiss wrote:
> Hi Taniya,
> 
> On Thu Mar 13, 2025 at 5:39 AM CET, Taniya Das wrote:
>>
>>
>> On 3/4/2025 2:10 PM, Dmitry Baryshkov wrote:
>>> On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
>>> <vladimir.zapolskiy@linaro.org> wrote:
>>>>
>>>> On 3/4/25 01:53, Dmitry Baryshkov wrote:
>>>>> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>>>>>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>>>>>> domains.
>>>>>
>>>>> Are those really required to access the registers of the cammcc? Or is
>>>>> one of those (MXC?) required to setup PLLs? Also, is this applicable
>>>>> only to sm8550 or to other similar clock controllers?
>>>>
>>>> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
>>>> not on any SM8450 or SM8650 powered board for instance, however it does
>>>> not exclude an option that the problem has to be fixed for other clock
>>>> controllers, but it's Qualcomm to confirm any other touched platforms,
>>>
>>> Please work with Taniya to identify used power domains.
>>>
>>
>> CAMCC requires both MMCX and MXC to be functional.
> 
> Could you check whether any clock controllers on SM6350/SM7225 (Bitra)
> need multiple power domains, or in general which clock controller uses
> which power domain.
> 
> That SoC has camcc, dispcc, gcc, gpucc, npucc and videocc.
> 
> That'd be highly appreciated since I've been hitting weird issues there
> that could be explained by some missing power domains.
> 

Hi Luca,

The targets you mentioned does not have any have multiple rail
dependency, but could you share the weird issues with respect to clock
controller I can take a look.

> Regards
> Luca
> 
>>
>>>> for instance x1e80100-camcc has it resolved right at the beginning.
>>>>
>>>> To my understanding here 'required-opps' shall also be generalized, so
>>>> the done copy from x1e80100-camcc was improper, and the latter dt-binding
>>>> should be fixed.
>>>
>>> Yes
>>>
>>
>> required-opps is not mandatory for MXC as we ensure that MxC would never
>> hit retention.
>>
>> https://lore.kernel.org/r/20240625-avoid_mxc_retention-v2-1-af9c2f549a5f@quicinc.com
>>
>>
>>>
>>>
> 

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Luca Weiss]

Hi Taniya,

On Thu Mar 13, 2025 at 12:57 PM CET, Taniya Das wrote:
>
>
> On 3/13/2025 1:22 PM, Luca Weiss wrote:
>> Hi Taniya,
>> 
>> On Thu Mar 13, 2025 at 5:39 AM CET, Taniya Das wrote:
>>>
>>>
>>> On 3/4/2025 2:10 PM, Dmitry Baryshkov wrote:
>>>> On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
>>>> <vladimir.zapolskiy@linaro.org> wrote:
>>>>>
>>>>> On 3/4/25 01:53, Dmitry Baryshkov wrote:
>>>>>> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>>>>>>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>>>>>>> domains.
>>>>>>
>>>>>> Are those really required to access the registers of the cammcc? Or is
>>>>>> one of those (MXC?) required to setup PLLs? Also, is this applicable
>>>>>> only to sm8550 or to other similar clock controllers?
>>>>>
>>>>> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
>>>>> not on any SM8450 or SM8650 powered board for instance, however it does
>>>>> not exclude an option that the problem has to be fixed for other clock
>>>>> controllers, but it's Qualcomm to confirm any other touched platforms,
>>>>
>>>> Please work with Taniya to identify used power domains.
>>>>
>>>
>>> CAMCC requires both MMCX and MXC to be functional.
>> 
>> Could you check whether any clock controllers on SM6350/SM7225 (Bitra)
>> need multiple power domains, or in general which clock controller uses
>> which power domain.
>> 
>> That SoC has camcc, dispcc, gcc, gpucc, npucc and videocc.
>> 
>> That'd be highly appreciated since I've been hitting weird issues there
>> that could be explained by some missing power domains.
>> 
>
> Hi Luca,
>
> The targets you mentioned does not have any have multiple rail
> dependency, but could you share the weird issues with respect to clock
> controller I can take a look.

Coming back to this, I've taken a shot at camera on SM6350 (Fairphone 4)
again, but again hitting some clock issues.

For reference, I am testing with following change:
https://lore.kernel.org/linux-arm-msm/20250911011218.861322-3-vladimir.zapolskiy@linaro.org/

Trying to enable CAMCC_MCLK1_CLK - wired up to the IMX576 camera sensor
on this phone - results in following error.

[    3.140232] ------------[ cut here ]------------
[    3.141264] camcc_mclk1_clk status stuck at 'off'
[    3.141276] WARNING: CPU: 6 PID: 12 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190

Checking the driver against downstream driver, it looks like the RCGs
should be using clk_rcg2_shared_ops because of enable_safe_config in
downstream, but changing that doesn't really improve the situation, but
it does change the error message to this:

[    2.933254] ------------[ cut here ]------------
[    2.933961] camcc_mclk1_clk_src: rcg didn't update its configuration.
[    2.933970] WARNING: CPU: 7 PID: 12 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xe4

I've also noticed that some camcc drivers take in GCC_CAMERA_AHB_CLK as
iface clk, could something like this be missing on sm6350?

I'd appreciate any help or tips for resolving this.

Regards
Luca

>
>> Regards
>> Luca
>> 
>>>
>>>>> for instance x1e80100-camcc has it resolved right at the beginning.
>>>>>
>>>>> To my understanding here 'required-opps' shall also be generalized, so
>>>>> the done copy from x1e80100-camcc was improper, and the latter dt-binding
>>>>> should be fixed.
>>>>
>>>> Yes
>>>>
>>>
>>> required-opps is not mandatory for MXC as we ensure that MxC would never
>>> hit retention.
>>>
>>> https://lore.kernel.org/r/20240625-avoid_mxc_retention-v2-1-af9c2f549a5f@quicinc.com
>>>
>>>
>>>>
>>>>
>> 

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Konrad Dybcio]

On 10/17/25 4:05 PM, Luca Weiss wrote:
> Hi Taniya,
> 
> On Thu Mar 13, 2025 at 12:57 PM CET, Taniya Das wrote:
>>
>>
>> On 3/13/2025 1:22 PM, Luca Weiss wrote:
>>> Hi Taniya,
>>>
>>> On Thu Mar 13, 2025 at 5:39 AM CET, Taniya Das wrote:
>>>>
>>>>
>>>> On 3/4/2025 2:10 PM, Dmitry Baryshkov wrote:
>>>>> On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
>>>>> <vladimir.zapolskiy@linaro.org> wrote:
>>>>>>
>>>>>> On 3/4/25 01:53, Dmitry Baryshkov wrote:
>>>>>>> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>>>>>>>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>>>>>>>> domains.
>>>>>>>
>>>>>>> Are those really required to access the registers of the cammcc? Or is
>>>>>>> one of those (MXC?) required to setup PLLs? Also, is this applicable
>>>>>>> only to sm8550 or to other similar clock controllers?
>>>>>>
>>>>>> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
>>>>>> not on any SM8450 or SM8650 powered board for instance, however it does
>>>>>> not exclude an option that the problem has to be fixed for other clock
>>>>>> controllers, but it's Qualcomm to confirm any other touched platforms,
>>>>>
>>>>> Please work with Taniya to identify used power domains.
>>>>>
>>>>
>>>> CAMCC requires both MMCX and MXC to be functional.
>>>
>>> Could you check whether any clock controllers on SM6350/SM7225 (Bitra)
>>> need multiple power domains, or in general which clock controller uses
>>> which power domain.
>>>
>>> That SoC has camcc, dispcc, gcc, gpucc, npucc and videocc.
>>>
>>> That'd be highly appreciated since I've been hitting weird issues there
>>> that could be explained by some missing power domains.
>>>
>>
>> Hi Luca,
>>
>> The targets you mentioned does not have any have multiple rail
>> dependency, but could you share the weird issues with respect to clock
>> controller I can take a look.
> 
> Coming back to this, I've taken a shot at camera on SM6350 (Fairphone 4)
> again, but again hitting some clock issues.
> 
> For reference, I am testing with following change:
> https://lore.kernel.org/linux-arm-msm/20250911011218.861322-3-vladimir.zapolskiy@linaro.org/
> 
> Trying to enable CAMCC_MCLK1_CLK - wired up to the IMX576 camera sensor
> on this phone - results in following error.
> 
> [    3.140232] ------------[ cut here ]------------
> [    3.141264] camcc_mclk1_clk status stuck at 'off'
> [    3.141276] WARNING: CPU: 6 PID: 12 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
> 
> Checking the driver against downstream driver, it looks like the RCGs
> should be using clk_rcg2_shared_ops because of enable_safe_config in
> downstream, but changing that doesn't really improve the situation, but
> it does change the error message to this:
> 
> [    2.933254] ------------[ cut here ]------------
> [    2.933961] camcc_mclk1_clk_src: rcg didn't update its configuration.
> [    2.933970] WARNING: CPU: 7 PID: 12 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xe4
> 
> I've also noticed that some camcc drivers take in GCC_CAMERA_AHB_CLK as
> iface clk, could something like this be missing on sm6350?
> 
> I'd appreciate any help or tips for resolving this.

Is CAMCC_PLL2 online?

Konrad

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Bryan O'Donoghue]

On 20/10/2025 13:21, Konrad Dybcio wrote:
> On 10/17/25 4:05 PM, Luca Weiss wrote:
>> Hi Taniya,
>>
>> On Thu Mar 13, 2025 at 12:57 PM CET, Taniya Das wrote:
>>>
>>>
>>> On 3/13/2025 1:22 PM, Luca Weiss wrote:
>>>> Hi Taniya,
>>>>
>>>> On Thu Mar 13, 2025 at 5:39 AM CET, Taniya Das wrote:
>>>>>
>>>>>
>>>>> On 3/4/2025 2:10 PM, Dmitry Baryshkov wrote:
>>>>>> On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
>>>>>> <vladimir.zapolskiy@linaro.org> wrote:
>>>>>>>
>>>>>>> On 3/4/25 01:53, Dmitry Baryshkov wrote:
>>>>>>>> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>>>>>>>>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>>>>>>>>> domains.
>>>>>>>>
>>>>>>>> Are those really required to access the registers of the cammcc? Or is
>>>>>>>> one of those (MXC?) required to setup PLLs? Also, is this applicable
>>>>>>>> only to sm8550 or to other similar clock controllers?
>>>>>>>
>>>>>>> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
>>>>>>> not on any SM8450 or SM8650 powered board for instance, however it does
>>>>>>> not exclude an option that the problem has to be fixed for other clock
>>>>>>> controllers, but it's Qualcomm to confirm any other touched platforms,
>>>>>>
>>>>>> Please work with Taniya to identify used power domains.
>>>>>>
>>>>>
>>>>> CAMCC requires both MMCX and MXC to be functional.
>>>>
>>>> Could you check whether any clock controllers on SM6350/SM7225 (Bitra)
>>>> need multiple power domains, or in general which clock controller uses
>>>> which power domain.
>>>>
>>>> That SoC has camcc, dispcc, gcc, gpucc, npucc and videocc.
>>>>
>>>> That'd be highly appreciated since I've been hitting weird issues there
>>>> that could be explained by some missing power domains.
>>>>
>>>
>>> Hi Luca,
>>>
>>> The targets you mentioned does not have any have multiple rail
>>> dependency, but could you share the weird issues with respect to clock
>>> controller I can take a look.
>>
>> Coming back to this, I've taken a shot at camera on SM6350 (Fairphone 4)
>> again, but again hitting some clock issues.
>>
>> For reference, I am testing with following change:
>> https://lore.kernel.org/linux-arm-msm/20250911011218.861322-3-vladimir.zapolskiy@linaro.org/
>>
>> Trying to enable CAMCC_MCLK1_CLK - wired up to the IMX576 camera sensor
>> on this phone - results in following error.
>>
>> [    3.140232] ------------[ cut here ]------------
>> [    3.141264] camcc_mclk1_clk status stuck at 'off'
>> [    3.141276] WARNING: CPU: 6 PID: 12 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
>>
>> Checking the driver against downstream driver, it looks like the RCGs
>> should be using clk_rcg2_shared_ops because of enable_safe_config in
>> downstream, but changing that doesn't really improve the situation, but
>> it does change the error message to this:
>>
>> [    2.933254] ------------[ cut here ]------------
>> [    2.933961] camcc_mclk1_clk_src: rcg didn't update its configuration.
>> [    2.933970] WARNING: CPU: 7 PID: 12 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xe4
>>
>> I've also noticed that some camcc drivers take in GCC_CAMERA_AHB_CLK as
>> iface clk, could something like this be missing on sm6350?
>>
>> I'd appreciate any help or tips for resolving this.
> 
> Is CAMCC_PLL2 online?
> 
> Konrad

Usually if you can't switch on a clock its because a power-domain is off 
or a GDSC is off.

I'd guess one of the power-domains is missing.

Looks...

@Luca Is this actually right ?

camcc: clock-controller@ad00000 {
          compatible = "qcom,sm6350-camcc";
          reg = <0x0 0x0ad00000 0x0 0x16000>;
          clocks = <&rpmhcc RPMH_CXO_CLK>;
          #clock-cells = <1>;
          #reset-cells = <1>;
          #power-domain-cells = <1>;
};

Isn't this clock controller missing at least one power-domain ?

camcc: clock-controller@ad00000 {
          compatible = "qcom,sm6350-camcc";
          reg = <0x0 0x0ad00000 0x0 0x16000>;
          clocks = <&rpmhcc RPMH_CXO_CLK>;
+        power-domains = <&rpmhpd SM6350_CX>;
          #clock-cells = <1>;
          #reset-cells = <1>;
          #power-domain-cells = <1>;
};

Hmm but CX should already be on realistically..

---
bod

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Luca Weiss]

On Mon Oct 20, 2025 at 3:00 PM CEST, Bryan O'Donoghue wrote:
> On 20/10/2025 13:21, Konrad Dybcio wrote:
>> On 10/17/25 4:05 PM, Luca Weiss wrote:
>>> Hi Taniya,
>>>
>>> On Thu Mar 13, 2025 at 12:57 PM CET, Taniya Das wrote:
>>>>
>>>>
>>>> On 3/13/2025 1:22 PM, Luca Weiss wrote:
>>>>> Hi Taniya,
>>>>>
>>>>> On Thu Mar 13, 2025 at 5:39 AM CET, Taniya Das wrote:
>>>>>>
>>>>>>
>>>>>> On 3/4/2025 2:10 PM, Dmitry Baryshkov wrote:
>>>>>>> On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
>>>>>>> <vladimir.zapolskiy@linaro.org> wrote:
>>>>>>>>
>>>>>>>> On 3/4/25 01:53, Dmitry Baryshkov wrote:
>>>>>>>>> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>>>>>>>>>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>>>>>>>>>> domains.
>>>>>>>>>
>>>>>>>>> Are those really required to access the registers of the cammcc? Or is
>>>>>>>>> one of those (MXC?) required to setup PLLs? Also, is this applicable
>>>>>>>>> only to sm8550 or to other similar clock controllers?
>>>>>>>>
>>>>>>>> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
>>>>>>>> not on any SM8450 or SM8650 powered board for instance, however it does
>>>>>>>> not exclude an option that the problem has to be fixed for other clock
>>>>>>>> controllers, but it's Qualcomm to confirm any other touched platforms,
>>>>>>>
>>>>>>> Please work with Taniya to identify used power domains.
>>>>>>>
>>>>>>
>>>>>> CAMCC requires both MMCX and MXC to be functional.
>>>>>
>>>>> Could you check whether any clock controllers on SM6350/SM7225 (Bitra)
>>>>> need multiple power domains, or in general which clock controller uses
>>>>> which power domain.
>>>>>
>>>>> That SoC has camcc, dispcc, gcc, gpucc, npucc and videocc.
>>>>>
>>>>> That'd be highly appreciated since I've been hitting weird issues there
>>>>> that could be explained by some missing power domains.
>>>>>
>>>>
>>>> Hi Luca,
>>>>
>>>> The targets you mentioned does not have any have multiple rail
>>>> dependency, but could you share the weird issues with respect to clock
>>>> controller I can take a look.
>>>
>>> Coming back to this, I've taken a shot at camera on SM6350 (Fairphone 4)
>>> again, but again hitting some clock issues.
>>>
>>> For reference, I am testing with following change:
>>> https://lore.kernel.org/linux-arm-msm/20250911011218.861322-3-vladimir.zapolskiy@linaro.org/
>>>
>>> Trying to enable CAMCC_MCLK1_CLK - wired up to the IMX576 camera sensor
>>> on this phone - results in following error.
>>>
>>> [    3.140232] ------------[ cut here ]------------
>>> [    3.141264] camcc_mclk1_clk status stuck at 'off'
>>> [    3.141276] WARNING: CPU: 6 PID: 12 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
>>>
>>> Checking the driver against downstream driver, it looks like the RCGs
>>> should be using clk_rcg2_shared_ops because of enable_safe_config in
>>> downstream, but changing that doesn't really improve the situation, but
>>> it does change the error message to this:
>>>
>>> [    2.933254] ------------[ cut here ]------------
>>> [    2.933961] camcc_mclk1_clk_src: rcg didn't update its configuration.
>>> [    2.933970] WARNING: CPU: 7 PID: 12 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xe4
>>>
>>> I've also noticed that some camcc drivers take in GCC_CAMERA_AHB_CLK as
>>> iface clk, could something like this be missing on sm6350?
>>>
>>> I'd appreciate any help or tips for resolving this.
>> 
>> Is CAMCC_PLL2 online?
>> 
>> Konrad
>
> Usually if you can't switch on a clock its because a power-domain is off 
> or a GDSC is off.
>
> I'd guess one of the power-domains is missing.
>
> Looks...
>
> @Luca Is this actually right ?
>
> camcc: clock-controller@ad00000 {
>           compatible = "qcom,sm6350-camcc";
>           reg = <0x0 0x0ad00000 0x0 0x16000>;
>           clocks = <&rpmhcc RPMH_CXO_CLK>;
>           #clock-cells = <1>;
>           #reset-cells = <1>;
>           #power-domain-cells = <1>;
> };
>
> Isn't this clock controller missing at least one power-domain ?
>
> camcc: clock-controller@ad00000 {
>           compatible = "qcom,sm6350-camcc";
>           reg = <0x0 0x0ad00000 0x0 0x16000>;
>           clocks = <&rpmhcc RPMH_CXO_CLK>;
> +        power-domains = <&rpmhpd SM6350_CX>;
>           #clock-cells = <1>;
>           #reset-cells = <1>;
>           #power-domain-cells = <1>;
> };
>
> Hmm but CX should already be on realistically..

Downstream does reference both CX and MX in the camcc-lagoon.c driver

static DEFINE_VDD_REGULATORS(vdd_cx, VDD_NUM, 1, vdd_corner);
static DEFINE_VDD_REGULATORS(vdd_mx, VDD_NUM, 1, vdd_corner);

I'd expect both to be enabled at boot though, CX and MX is at least both
used for display (which is already on from bootloader).

Also adding "power-domains = <&rpmhpd SM6350_MX>;" to camcc
unsurprisingly doesn't change anything.

Regards
Luca

>
> ---
> bod

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Luca Weiss]

On Mon Oct 20, 2025 at 2:21 PM CEST, Konrad Dybcio wrote:
> On 10/17/25 4:05 PM, Luca Weiss wrote:
>> Hi Taniya,
>> 
>> On Thu Mar 13, 2025 at 12:57 PM CET, Taniya Das wrote:
>>>
>>>
>>> On 3/13/2025 1:22 PM, Luca Weiss wrote:
>>>> Hi Taniya,
>>>>
>>>> On Thu Mar 13, 2025 at 5:39 AM CET, Taniya Das wrote:
>>>>>
>>>>>
>>>>> On 3/4/2025 2:10 PM, Dmitry Baryshkov wrote:
>>>>>> On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
>>>>>> <vladimir.zapolskiy@linaro.org> wrote:
>>>>>>>
>>>>>>> On 3/4/25 01:53, Dmitry Baryshkov wrote:
>>>>>>>> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>>>>>>>>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>>>>>>>>> domains.
>>>>>>>>
>>>>>>>> Are those really required to access the registers of the cammcc? Or is
>>>>>>>> one of those (MXC?) required to setup PLLs? Also, is this applicable
>>>>>>>> only to sm8550 or to other similar clock controllers?
>>>>>>>
>>>>>>> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
>>>>>>> not on any SM8450 or SM8650 powered board for instance, however it does
>>>>>>> not exclude an option that the problem has to be fixed for other clock
>>>>>>> controllers, but it's Qualcomm to confirm any other touched platforms,
>>>>>>
>>>>>> Please work with Taniya to identify used power domains.
>>>>>>
>>>>>
>>>>> CAMCC requires both MMCX and MXC to be functional.
>>>>
>>>> Could you check whether any clock controllers on SM6350/SM7225 (Bitra)
>>>> need multiple power domains, or in general which clock controller uses
>>>> which power domain.
>>>>
>>>> That SoC has camcc, dispcc, gcc, gpucc, npucc and videocc.
>>>>
>>>> That'd be highly appreciated since I've been hitting weird issues there
>>>> that could be explained by some missing power domains.
>>>>
>>>
>>> Hi Luca,
>>>
>>> The targets you mentioned does not have any have multiple rail
>>> dependency, but could you share the weird issues with respect to clock
>>> controller I can take a look.
>> 
>> Coming back to this, I've taken a shot at camera on SM6350 (Fairphone 4)
>> again, but again hitting some clock issues.
>> 
>> For reference, I am testing with following change:
>> https://lore.kernel.org/linux-arm-msm/20250911011218.861322-3-vladimir.zapolskiy@linaro.org/
>> 
>> Trying to enable CAMCC_MCLK1_CLK - wired up to the IMX576 camera sensor
>> on this phone - results in following error.
>> 
>> [    3.140232] ------------[ cut here ]------------
>> [    3.141264] camcc_mclk1_clk status stuck at 'off'
>> [    3.141276] WARNING: CPU: 6 PID: 12 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
>> 
>> Checking the driver against downstream driver, it looks like the RCGs
>> should be using clk_rcg2_shared_ops because of enable_safe_config in
>> downstream, but changing that doesn't really improve the situation, but
>> it does change the error message to this:
>> 
>> [    2.933254] ------------[ cut here ]------------
>> [    2.933961] camcc_mclk1_clk_src: rcg didn't update its configuration.
>> [    2.933970] WARNING: CPU: 7 PID: 12 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xe4
>> 
>> I've also noticed that some camcc drivers take in GCC_CAMERA_AHB_CLK as
>> iface clk, could something like this be missing on sm6350?
>> 
>> I'd appreciate any help or tips for resolving this.
>
> Is CAMCC_PLL2 online?

I'd assume so given nothing in dmesg is complaining about that?

But not sure how to check. Debugcc can't do PLLs, right?

In any case adding CLK_IS_CRITICAL to the camcc_pll2 doesn't change
anything.

Regards
Luca

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Konrad Dybcio]

On 10/21/25 12:36 PM, Luca Weiss wrote:
> On Mon Oct 20, 2025 at 2:21 PM CEST, Konrad Dybcio wrote:
>> On 10/17/25 4:05 PM, Luca Weiss wrote:
>>> Hi Taniya,
>>>
>>> On Thu Mar 13, 2025 at 12:57 PM CET, Taniya Das wrote:
>>>>
>>>>
>>>> On 3/13/2025 1:22 PM, Luca Weiss wrote:
>>>>> Hi Taniya,
>>>>>
>>>>> On Thu Mar 13, 2025 at 5:39 AM CET, Taniya Das wrote:
>>>>>>
>>>>>>
>>>>>> On 3/4/2025 2:10 PM, Dmitry Baryshkov wrote:
>>>>>>> On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
>>>>>>> <vladimir.zapolskiy@linaro.org> wrote:
>>>>>>>>
>>>>>>>> On 3/4/25 01:53, Dmitry Baryshkov wrote:
>>>>>>>>> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>>>>>>>>>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>>>>>>>>>> domains.
>>>>>>>>>
>>>>>>>>> Are those really required to access the registers of the cammcc? Or is
>>>>>>>>> one of those (MXC?) required to setup PLLs? Also, is this applicable
>>>>>>>>> only to sm8550 or to other similar clock controllers?
>>>>>>>>
>>>>>>>> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
>>>>>>>> not on any SM8450 or SM8650 powered board for instance, however it does
>>>>>>>> not exclude an option that the problem has to be fixed for other clock
>>>>>>>> controllers, but it's Qualcomm to confirm any other touched platforms,
>>>>>>>
>>>>>>> Please work with Taniya to identify used power domains.
>>>>>>>
>>>>>>
>>>>>> CAMCC requires both MMCX and MXC to be functional.
>>>>>
>>>>> Could you check whether any clock controllers on SM6350/SM7225 (Bitra)
>>>>> need multiple power domains, or in general which clock controller uses
>>>>> which power domain.
>>>>>
>>>>> That SoC has camcc, dispcc, gcc, gpucc, npucc and videocc.
>>>>>
>>>>> That'd be highly appreciated since I've been hitting weird issues there
>>>>> that could be explained by some missing power domains.
>>>>>
>>>>
>>>> Hi Luca,
>>>>
>>>> The targets you mentioned does not have any have multiple rail
>>>> dependency, but could you share the weird issues with respect to clock
>>>> controller I can take a look.
>>>
>>> Coming back to this, I've taken a shot at camera on SM6350 (Fairphone 4)
>>> again, but again hitting some clock issues.
>>>
>>> For reference, I am testing with following change:
>>> https://lore.kernel.org/linux-arm-msm/20250911011218.861322-3-vladimir.zapolskiy@linaro.org/
>>>
>>> Trying to enable CAMCC_MCLK1_CLK - wired up to the IMX576 camera sensor
>>> on this phone - results in following error.
>>>
>>> [    3.140232] ------------[ cut here ]------------
>>> [    3.141264] camcc_mclk1_clk status stuck at 'off'
>>> [    3.141276] WARNING: CPU: 6 PID: 12 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
>>>
>>> Checking the driver against downstream driver, it looks like the RCGs
>>> should be using clk_rcg2_shared_ops because of enable_safe_config in
>>> downstream, but changing that doesn't really improve the situation, but
>>> it does change the error message to this:
>>>
>>> [    2.933254] ------------[ cut here ]------------
>>> [    2.933961] camcc_mclk1_clk_src: rcg didn't update its configuration.
>>> [    2.933970] WARNING: CPU: 7 PID: 12 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xe4
>>>
>>> I've also noticed that some camcc drivers take in GCC_CAMERA_AHB_CLK as
>>> iface clk, could something like this be missing on sm6350?
>>>
>>> I'd appreciate any help or tips for resolving this.
>>
>> Is CAMCC_PLL2 online?
> 
> I'd assume so given nothing in dmesg is complaining about that?
> 
> But not sure how to check. Debugcc can't do PLLs, right?

The PLLs have a .is_enabled, so you can take a look in debugfs

> In any case adding CLK_IS_CRITICAL to the camcc_pll2 doesn't change
> anything.

Was worth a shot :(

Konrad

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Vladimir Zapolskiy]

Hi Luca.

On 10/17/25 17:05, Luca Weiss wrote:
> Hi Taniya,
> 
> On Thu Mar 13, 2025 at 12:57 PM CET, Taniya Das wrote:
>>
>>
>> On 3/13/2025 1:22 PM, Luca Weiss wrote:
>>> Hi Taniya,
>>>
>>> On Thu Mar 13, 2025 at 5:39 AM CET, Taniya Das wrote:
>>>>
>>>>
>>>> On 3/4/2025 2:10 PM, Dmitry Baryshkov wrote:
>>>>> On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
>>>>> <vladimir.zapolskiy@linaro.org> wrote:
>>>>>>
>>>>>> On 3/4/25 01:53, Dmitry Baryshkov wrote:
>>>>>>> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>>>>>>>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>>>>>>>> domains.
>>>>>>>
>>>>>>> Are those really required to access the registers of the cammcc? Or is
>>>>>>> one of those (MXC?) required to setup PLLs? Also, is this applicable
>>>>>>> only to sm8550 or to other similar clock controllers?
>>>>>>
>>>>>> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
>>>>>> not on any SM8450 or SM8650 powered board for instance, however it does
>>>>>> not exclude an option that the problem has to be fixed for other clock
>>>>>> controllers, but it's Qualcomm to confirm any other touched platforms,
>>>>>
>>>>> Please work with Taniya to identify used power domains.
>>>>>
>>>>
>>>> CAMCC requires both MMCX and MXC to be functional.
>>>
>>> Could you check whether any clock controllers on SM6350/SM7225 (Bitra)
>>> need multiple power domains, or in general which clock controller uses
>>> which power domain.
>>>
>>> That SoC has camcc, dispcc, gcc, gpucc, npucc and videocc.
>>>
>>> That'd be highly appreciated since I've been hitting weird issues there
>>> that could be explained by some missing power domains.
>>>
>>
>> Hi Luca,
>>
>> The targets you mentioned does not have any have multiple rail
>> dependency, but could you share the weird issues with respect to clock
>> controller I can take a look.
> 
> Coming back to this, I've taken a shot at camera on SM6350 (Fairphone 4)
> again, but again hitting some clock issues.
> 
> For reference, I am testing with following change:
> https://lore.kernel.org/linux-arm-msm/20250911011218.861322-3-vladimir.zapolskiy@linaro.org/
> 
> Trying to enable CAMCC_MCLK1_CLK - wired up to the IMX576 camera sensor
> on this phone - results in following error.
> 
> [    3.140232] ------------[ cut here ]------------
> [    3.141264] camcc_mclk1_clk status stuck at 'off'
> [    3.141276] WARNING: CPU: 6 PID: 12 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
> 
> Checking the driver against downstream driver, it looks like the RCGs
> should be using clk_rcg2_shared_ops because of enable_safe_config in
> downstream, but changing that doesn't really improve the situation, but
> it does change the error message to this:
> 
> [    2.933254] ------------[ cut here ]------------
> [    2.933961] camcc_mclk1_clk_src: rcg didn't update its configuration.
> [    2.933970] WARNING: CPU: 7 PID: 12 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xe4
> 
> I've also noticed that some camcc drivers take in GCC_CAMERA_AHB_CLK as
> iface clk, could something like this be missing on sm6350?
> 
> I'd appreciate any help or tips for resolving this.
> 

Recently one particular problem related to MCLK was identified by me on
QRB5165/RB5, and it was reported to Bjorn over IRC, namely it's not possible
to toggle MCLK clock enable/disable state, when TITAN GDSC power domain is
set off. I'm working on fixing the issue (a change under clk/qcom), since
it's of an importance for a customer as well.

I can't be totally sure that it's right the same problem as the one reported
by you above, but it looks very similar, as a fast workaround please consider
to set an ALWAYS_ON flag of TITAN GDSC, and at least a report from you that
this actually helps would be nice to get.

-- 
Best wishes,
Vladimir

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Luca Weiss]

Hi Vladimir,

On Tue Oct 21, 2025 at 11:48 AM CEST, Vladimir Zapolskiy wrote:
> Hi Luca.
>
> On 10/17/25 17:05, Luca Weiss wrote:
>> Hi Taniya,
>> 
>> On Thu Mar 13, 2025 at 12:57 PM CET, Taniya Das wrote:
>>>
>>>
>>> On 3/13/2025 1:22 PM, Luca Weiss wrote:
>>>> Hi Taniya,
>>>>
>>>> On Thu Mar 13, 2025 at 5:39 AM CET, Taniya Das wrote:
>>>>>
>>>>>
>>>>> On 3/4/2025 2:10 PM, Dmitry Baryshkov wrote:
>>>>>> On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
>>>>>> <vladimir.zapolskiy@linaro.org> wrote:
>>>>>>>
>>>>>>> On 3/4/25 01:53, Dmitry Baryshkov wrote:
>>>>>>>> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>>>>>>>>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>>>>>>>>> domains.
>>>>>>>>
>>>>>>>> Are those really required to access the registers of the cammcc? Or is
>>>>>>>> one of those (MXC?) required to setup PLLs? Also, is this applicable
>>>>>>>> only to sm8550 or to other similar clock controllers?
>>>>>>>
>>>>>>> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
>>>>>>> not on any SM8450 or SM8650 powered board for instance, however it does
>>>>>>> not exclude an option that the problem has to be fixed for other clock
>>>>>>> controllers, but it's Qualcomm to confirm any other touched platforms,
>>>>>>
>>>>>> Please work with Taniya to identify used power domains.
>>>>>>
>>>>>
>>>>> CAMCC requires both MMCX and MXC to be functional.
>>>>
>>>> Could you check whether any clock controllers on SM6350/SM7225 (Bitra)
>>>> need multiple power domains, or in general which clock controller uses
>>>> which power domain.
>>>>
>>>> That SoC has camcc, dispcc, gcc, gpucc, npucc and videocc.
>>>>
>>>> That'd be highly appreciated since I've been hitting weird issues there
>>>> that could be explained by some missing power domains.
>>>>
>>>
>>> Hi Luca,
>>>
>>> The targets you mentioned does not have any have multiple rail
>>> dependency, but could you share the weird issues with respect to clock
>>> controller I can take a look.
>> 
>> Coming back to this, I've taken a shot at camera on SM6350 (Fairphone 4)
>> again, but again hitting some clock issues.
>> 
>> For reference, I am testing with following change:
>> https://lore.kernel.org/linux-arm-msm/20250911011218.861322-3-vladimir.zapolskiy@linaro.org/
>> 
>> Trying to enable CAMCC_MCLK1_CLK - wired up to the IMX576 camera sensor
>> on this phone - results in following error.
>> 
>> [    3.140232] ------------[ cut here ]------------
>> [    3.141264] camcc_mclk1_clk status stuck at 'off'
>> [    3.141276] WARNING: CPU: 6 PID: 12 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
>> 
>> Checking the driver against downstream driver, it looks like the RCGs
>> should be using clk_rcg2_shared_ops because of enable_safe_config in
>> downstream, but changing that doesn't really improve the situation, but
>> it does change the error message to this:
>> 
>> [    2.933254] ------------[ cut here ]------------
>> [    2.933961] camcc_mclk1_clk_src: rcg didn't update its configuration.
>> [    2.933970] WARNING: CPU: 7 PID: 12 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xe4
>> 
>> I've also noticed that some camcc drivers take in GCC_CAMERA_AHB_CLK as
>> iface clk, could something like this be missing on sm6350?
>> 
>> I'd appreciate any help or tips for resolving this.
>> 
>
> Recently one particular problem related to MCLK was identified by me on
> QRB5165/RB5, and it was reported to Bjorn over IRC, namely it's not possible
> to toggle MCLK clock enable/disable state, when TITAN GDSC power domain is
> set off. I'm working on fixing the issue (a change under clk/qcom), since
> it's of an importance for a customer as well.
>
> I can't be totally sure that it's right the same problem as the one reported
> by you above, but it looks very similar, as a fast workaround please consider
> to set an ALWAYS_ON flag of TITAN GDSC, and at least a report from you that
> this actually helps would be nice to get.

Unfortunately that doesn't seem to help on sm6350.

diff --git a/drivers/clk/qcom/camcc-sm6350.c b/drivers/clk/qcom/camcc-sm6350.c
index 12a469ce7e2f..cf87ad55d318 100644
--- a/drivers/clk/qcom/camcc-sm6350.c
+++ b/drivers/clk/qcom/camcc-sm6350.c
@@ -1767,6 +1767,7 @@ static struct gdsc titan_top_gdsc = {
 		.name = "titan_top_gdsc",
 	},
 	.pwrsts = PWRSTS_OFF_ON,
+	.flags = ALWAYS_ON,
 };
 
 static struct clk_hw *camcc_sm6350_hws[] = {


$ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
[...]
titan_top_gdsc                  on                              0
                                                bps_gdsc, ipe_0_gdsc, ife_0_gdsc, ife_1_gdsc, ife_2_gdsc
    ac4a000.cci                     suspended                   0           SW
    ac4b000.cci                     suspended                   0           SW
    genpd:3:acb3000.camss           suspended                   0           SW
[...]

but still the same clock stuck warning...

[    3.093431] ------------[ cut here ]------------
[    3.094614] camcc_mclk1_clk status stuck at 'off'
[    3.094629] WARNING: CPU: 6 PID: 65 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190

Thanks for the suggestion though.

Regards
Luca

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Taniya Das]

On 10/21/2025 3:28 PM, Luca Weiss wrote:
> Hi Vladimir,
> 
> On Tue Oct 21, 2025 at 11:48 AM CEST, Vladimir Zapolskiy wrote:
>> Hi Luca.
>>
>> On 10/17/25 17:05, Luca Weiss wrote:
>>> Hi Taniya,
>>>
>>> On Thu Mar 13, 2025 at 12:57 PM CET, Taniya Das wrote:
>>>>
>>>>
>>>> On 3/13/2025 1:22 PM, Luca Weiss wrote:
>>>>> Hi Taniya,
>>>>>
>>>>> On Thu Mar 13, 2025 at 5:39 AM CET, Taniya Das wrote:
>>>>>>
>>>>>>
>>>>>> On 3/4/2025 2:10 PM, Dmitry Baryshkov wrote:
>>>>>>> On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
>>>>>>> <vladimir.zapolskiy@linaro.org> wrote:
>>>>>>>>
>>>>>>>> On 3/4/25 01:53, Dmitry Baryshkov wrote:
>>>>>>>>> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>>>>>>>>>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>>>>>>>>>> domains.
>>>>>>>>>
>>>>>>>>> Are those really required to access the registers of the cammcc? Or is
>>>>>>>>> one of those (MXC?) required to setup PLLs? Also, is this applicable
>>>>>>>>> only to sm8550 or to other similar clock controllers?
>>>>>>>>
>>>>>>>> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
>>>>>>>> not on any SM8450 or SM8650 powered board for instance, however it does
>>>>>>>> not exclude an option that the problem has to be fixed for other clock
>>>>>>>> controllers, but it's Qualcomm to confirm any other touched platforms,
>>>>>>>
>>>>>>> Please work with Taniya to identify used power domains.
>>>>>>>
>>>>>>
>>>>>> CAMCC requires both MMCX and MXC to be functional.
>>>>>
>>>>> Could you check whether any clock controllers on SM6350/SM7225 (Bitra)
>>>>> need multiple power domains, or in general which clock controller uses
>>>>> which power domain.
>>>>>
>>>>> That SoC has camcc, dispcc, gcc, gpucc, npucc and videocc.
>>>>>
>>>>> That'd be highly appreciated since I've been hitting weird issues there
>>>>> that could be explained by some missing power domains.
>>>>>
>>>>
>>>> Hi Luca,
>>>>
>>>> The targets you mentioned does not have any have multiple rail
>>>> dependency, but could you share the weird issues with respect to clock
>>>> controller I can take a look.
>>>
>>> Coming back to this, I've taken a shot at camera on SM6350 (Fairphone 4)
>>> again, but again hitting some clock issues.
>>>
>>> For reference, I am testing with following change:
>>> https://lore.kernel.org/linux-arm-msm/20250911011218.861322-3-vladimir.zapolskiy@linaro.org/
>>>
>>> Trying to enable CAMCC_MCLK1_CLK - wired up to the IMX576 camera sensor
>>> on this phone - results in following error.
>>>
>>> [    3.140232] ------------[ cut here ]------------
>>> [    3.141264] camcc_mclk1_clk status stuck at 'off'
>>> [    3.141276] WARNING: CPU: 6 PID: 12 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
>>>
>>> Checking the driver against downstream driver, it looks like the RCGs
>>> should be using clk_rcg2_shared_ops because of enable_safe_config in
>>> downstream, but changing that doesn't really improve the situation, but
>>> it does change the error message to this:
>>>
>>> [    2.933254] ------------[ cut here ]------------
>>> [    2.933961] camcc_mclk1_clk_src: rcg didn't update its configuration.
>>> [    2.933970] WARNING: CPU: 7 PID: 12 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xe4
>>>
>>> I've also noticed that some camcc drivers take in GCC_CAMERA_AHB_CLK as
>>> iface clk, could something like this be missing on sm6350?
>>>
>>> I'd appreciate any help or tips for resolving this.
>>>
>>
>> Recently one particular problem related to MCLK was identified by me on
>> QRB5165/RB5, and it was reported to Bjorn over IRC, namely it's not possible
>> to toggle MCLK clock enable/disable state, when TITAN GDSC power domain is
>> set off. I'm working on fixing the issue (a change under clk/qcom), since
>> it's of an importance for a customer as well.
>>
>> I can't be totally sure that it's right the same problem as the one reported
>> by you above, but it looks very similar, as a fast workaround please consider
>> to set an ALWAYS_ON flag of TITAN GDSC, and at least a report from you that
>> this actually helps would be nice to get.
> 
> Unfortunately that doesn't seem to help on sm6350.
> 
> diff --git a/drivers/clk/qcom/camcc-sm6350.c b/drivers/clk/qcom/camcc-sm6350.c
> index 12a469ce7e2f..cf87ad55d318 100644
> --- a/drivers/clk/qcom/camcc-sm6350.c
> +++ b/drivers/clk/qcom/camcc-sm6350.c
> @@ -1767,6 +1767,7 @@ static struct gdsc titan_top_gdsc = {
>  		.name = "titan_top_gdsc",
>  	},
>  	.pwrsts = PWRSTS_OFF_ON,
> +	.flags = ALWAYS_ON,
>  };
>  
>  static struct clk_hw *camcc_sm6350_hws[] = {
> 
> 
> $ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
> [...]
> titan_top_gdsc                  on                              0
>                                                 bps_gdsc, ipe_0_gdsc, ife_0_gdsc, ife_1_gdsc, ife_2_gdsc
>     ac4a000.cci                     suspended                   0           SW
>     ac4b000.cci                     suspended                   0           SW
>     genpd:3:acb3000.camss           suspended                   0           SW
> [...]
> 
> but still the same clock stuck warning...
> 
> [    3.093431] ------------[ cut here ]------------
> [    3.094614] camcc_mclk1_clk status stuck at 'off'
> [    3.094629] WARNING: CPU: 6 PID: 65 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
> 
> Thanks for the suggestion though.
> 

Hi Luca,

Seems like the CAMCC_PLL2_OUT_EARLY output could be OFF here, which is
sourcing the mclk RCG's.

The user_ctl is not properly configured to enable the PLL early output.
Can you please try below change and check if it helps?

diff --git a/drivers/clk/qcom/camcc-sm6350.c
b/drivers/clk/qcom/camcc-sm6350.c
index 8aac97d29ce3..d33db530b7c9 100644
--- a/drivers/clk/qcom/camcc-sm6350.c
+++ b/drivers/clk/qcom/camcc-sm6350.c
@@ -154,6 +154,7 @@ static const struct alpha_pll_config
camcc_pll2_config = {
        .config_ctl_hi_val = 0x400003d2,
        .test_ctl_val = 0x04000400,
        .test_ctl_hi_val = 0x00004000,
+       .user_ctl_val = 0x0000030F,
};

-- 
Thanks,
Taniya Das

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Luca Weiss]

Hi Taniya,

On Tue Oct 21, 2025 at 1:12 PM CEST, Taniya Das wrote:
>
>
> On 10/21/2025 3:28 PM, Luca Weiss wrote:
>> Hi Vladimir,
>> 
>> On Tue Oct 21, 2025 at 11:48 AM CEST, Vladimir Zapolskiy wrote:
>>> Hi Luca.
>>>
>>> On 10/17/25 17:05, Luca Weiss wrote:
>>>> Hi Taniya,
>>>>
>>>> On Thu Mar 13, 2025 at 12:57 PM CET, Taniya Das wrote:
>>>>>
>>>>>
>>>>> On 3/13/2025 1:22 PM, Luca Weiss wrote:
>>>>>> Hi Taniya,
>>>>>>
>>>>>> On Thu Mar 13, 2025 at 5:39 AM CET, Taniya Das wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 3/4/2025 2:10 PM, Dmitry Baryshkov wrote:
>>>>>>>> On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
>>>>>>>> <vladimir.zapolskiy@linaro.org> wrote:
>>>>>>>>>
>>>>>>>>> On 3/4/25 01:53, Dmitry Baryshkov wrote:
>>>>>>>>>> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>>>>>>>>>>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>>>>>>>>>>> domains.
>>>>>>>>>>
>>>>>>>>>> Are those really required to access the registers of the cammcc? Or is
>>>>>>>>>> one of those (MXC?) required to setup PLLs? Also, is this applicable
>>>>>>>>>> only to sm8550 or to other similar clock controllers?
>>>>>>>>>
>>>>>>>>> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
>>>>>>>>> not on any SM8450 or SM8650 powered board for instance, however it does
>>>>>>>>> not exclude an option that the problem has to be fixed for other clock
>>>>>>>>> controllers, but it's Qualcomm to confirm any other touched platforms,
>>>>>>>>
>>>>>>>> Please work with Taniya to identify used power domains.
>>>>>>>>
>>>>>>>
>>>>>>> CAMCC requires both MMCX and MXC to be functional.
>>>>>>
>>>>>> Could you check whether any clock controllers on SM6350/SM7225 (Bitra)
>>>>>> need multiple power domains, or in general which clock controller uses
>>>>>> which power domain.
>>>>>>
>>>>>> That SoC has camcc, dispcc, gcc, gpucc, npucc and videocc.
>>>>>>
>>>>>> That'd be highly appreciated since I've been hitting weird issues there
>>>>>> that could be explained by some missing power domains.
>>>>>>
>>>>>
>>>>> Hi Luca,
>>>>>
>>>>> The targets you mentioned does not have any have multiple rail
>>>>> dependency, but could you share the weird issues with respect to clock
>>>>> controller I can take a look.
>>>>
>>>> Coming back to this, I've taken a shot at camera on SM6350 (Fairphone 4)
>>>> again, but again hitting some clock issues.
>>>>
>>>> For reference, I am testing with following change:
>>>> https://lore.kernel.org/linux-arm-msm/20250911011218.861322-3-vladimir.zapolskiy@linaro.org/
>>>>
>>>> Trying to enable CAMCC_MCLK1_CLK - wired up to the IMX576 camera sensor
>>>> on this phone - results in following error.
>>>>
>>>> [    3.140232] ------------[ cut here ]------------
>>>> [    3.141264] camcc_mclk1_clk status stuck at 'off'
>>>> [    3.141276] WARNING: CPU: 6 PID: 12 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
>>>>
>>>> Checking the driver against downstream driver, it looks like the RCGs
>>>> should be using clk_rcg2_shared_ops because of enable_safe_config in
>>>> downstream, but changing that doesn't really improve the situation, but
>>>> it does change the error message to this:
>>>>
>>>> [    2.933254] ------------[ cut here ]------------
>>>> [    2.933961] camcc_mclk1_clk_src: rcg didn't update its configuration.
>>>> [    2.933970] WARNING: CPU: 7 PID: 12 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xe4
>>>>
>>>> I've also noticed that some camcc drivers take in GCC_CAMERA_AHB_CLK as
>>>> iface clk, could something like this be missing on sm6350?
>>>>
>>>> I'd appreciate any help or tips for resolving this.
>>>>
>>>
>>> Recently one particular problem related to MCLK was identified by me on
>>> QRB5165/RB5, and it was reported to Bjorn over IRC, namely it's not possible
>>> to toggle MCLK clock enable/disable state, when TITAN GDSC power domain is
>>> set off. I'm working on fixing the issue (a change under clk/qcom), since
>>> it's of an importance for a customer as well.
>>>
>>> I can't be totally sure that it's right the same problem as the one reported
>>> by you above, but it looks very similar, as a fast workaround please consider
>>> to set an ALWAYS_ON flag of TITAN GDSC, and at least a report from you that
>>> this actually helps would be nice to get.
>> 
>> Unfortunately that doesn't seem to help on sm6350.
>> 
>> diff --git a/drivers/clk/qcom/camcc-sm6350.c b/drivers/clk/qcom/camcc-sm6350.c
>> index 12a469ce7e2f..cf87ad55d318 100644
>> --- a/drivers/clk/qcom/camcc-sm6350.c
>> +++ b/drivers/clk/qcom/camcc-sm6350.c
>> @@ -1767,6 +1767,7 @@ static struct gdsc titan_top_gdsc = {
>>  		.name = "titan_top_gdsc",
>>  	},
>>  	.pwrsts = PWRSTS_OFF_ON,
>> +	.flags = ALWAYS_ON,
>>  };
>>  
>>  static struct clk_hw *camcc_sm6350_hws[] = {
>> 
>> 
>> $ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
>> [...]
>> titan_top_gdsc                  on                              0
>>                                                 bps_gdsc, ipe_0_gdsc, ife_0_gdsc, ife_1_gdsc, ife_2_gdsc
>>     ac4a000.cci                     suspended                   0           SW
>>     ac4b000.cci                     suspended                   0           SW
>>     genpd:3:acb3000.camss           suspended                   0           SW
>> [...]
>> 
>> but still the same clock stuck warning...
>> 
>> [    3.093431] ------------[ cut here ]------------
>> [    3.094614] camcc_mclk1_clk status stuck at 'off'
>> [    3.094629] WARNING: CPU: 6 PID: 65 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
>> 
>> Thanks for the suggestion though.
>> 
>
> Hi Luca,
>
> Seems like the CAMCC_PLL2_OUT_EARLY output could be OFF here, which is
> sourcing the mclk RCG's.
>
> The user_ctl is not properly configured to enable the PLL early output.
> Can you please try below change and check if it helps?
>
> diff --git a/drivers/clk/qcom/camcc-sm6350.c
> b/drivers/clk/qcom/camcc-sm6350.c
> index 8aac97d29ce3..d33db530b7c9 100644
> --- a/drivers/clk/qcom/camcc-sm6350.c
> +++ b/drivers/clk/qcom/camcc-sm6350.c
> @@ -154,6 +154,7 @@ static const struct alpha_pll_config
> camcc_pll2_config = {
>         .config_ctl_hi_val = 0x400003d2,
>         .test_ctl_val = 0x04000400,
>         .test_ctl_hi_val = 0x00004000,
> +       .user_ctl_val = 0x0000030F,
> };

Yes! Indeed that makes the clock not be stuck, and debugcc is also
correctly reporting ~24MHz from that clock when it's enabled!

  cam_cc_mclk1_clk: 23.999592MHz (23999592Hz)

Is this PLL also missing a value for .user_ctl_hi_val? The other PLLs
have that set as well.

Out of curiousity, where's this magic value from? Only some sort of HPG
doc, or is this also somewhere referenced in downstream? Curious why
this is not set there for this PLL.

This is one major step toward camss & camera support for this phone!

Regards
Luca

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Luca Weiss]

On Tue Oct 21, 2025 at 4:24 PM CEST, Luca Weiss wrote:
> Hi Taniya,
>
> On Tue Oct 21, 2025 at 1:12 PM CEST, Taniya Das wrote:
>>
>>
>> On 10/21/2025 3:28 PM, Luca Weiss wrote:
>>> Hi Vladimir,
>>> 
>>> On Tue Oct 21, 2025 at 11:48 AM CEST, Vladimir Zapolskiy wrote:
>>>> Hi Luca.
>>>>
>>>> On 10/17/25 17:05, Luca Weiss wrote:
>>>>> Hi Taniya,
>>>>>
>>>>> On Thu Mar 13, 2025 at 12:57 PM CET, Taniya Das wrote:
>>>>>>
>>>>>>
>>>>>> On 3/13/2025 1:22 PM, Luca Weiss wrote:
>>>>>>> Hi Taniya,
>>>>>>>
>>>>>>> On Thu Mar 13, 2025 at 5:39 AM CET, Taniya Das wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/4/2025 2:10 PM, Dmitry Baryshkov wrote:
>>>>>>>>> On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
>>>>>>>>> <vladimir.zapolskiy@linaro.org> wrote:
>>>>>>>>>>
>>>>>>>>>> On 3/4/25 01:53, Dmitry Baryshkov wrote:
>>>>>>>>>>> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>>>>>>>>>>>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>>>>>>>>>>>> domains.
>>>>>>>>>>>
>>>>>>>>>>> Are those really required to access the registers of the cammcc? Or is
>>>>>>>>>>> one of those (MXC?) required to setup PLLs? Also, is this applicable
>>>>>>>>>>> only to sm8550 or to other similar clock controllers?
>>>>>>>>>>
>>>>>>>>>> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
>>>>>>>>>> not on any SM8450 or SM8650 powered board for instance, however it does
>>>>>>>>>> not exclude an option that the problem has to be fixed for other clock
>>>>>>>>>> controllers, but it's Qualcomm to confirm any other touched platforms,
>>>>>>>>>
>>>>>>>>> Please work with Taniya to identify used power domains.
>>>>>>>>>
>>>>>>>>
>>>>>>>> CAMCC requires both MMCX and MXC to be functional.
>>>>>>>
>>>>>>> Could you check whether any clock controllers on SM6350/SM7225 (Bitra)
>>>>>>> need multiple power domains, or in general which clock controller uses
>>>>>>> which power domain.
>>>>>>>
>>>>>>> That SoC has camcc, dispcc, gcc, gpucc, npucc and videocc.
>>>>>>>
>>>>>>> That'd be highly appreciated since I've been hitting weird issues there
>>>>>>> that could be explained by some missing power domains.
>>>>>>>
>>>>>>
>>>>>> Hi Luca,
>>>>>>
>>>>>> The targets you mentioned does not have any have multiple rail
>>>>>> dependency, but could you share the weird issues with respect to clock
>>>>>> controller I can take a look.
>>>>>
>>>>> Coming back to this, I've taken a shot at camera on SM6350 (Fairphone 4)
>>>>> again, but again hitting some clock issues.
>>>>>
>>>>> For reference, I am testing with following change:
>>>>> https://lore.kernel.org/linux-arm-msm/20250911011218.861322-3-vladimir.zapolskiy@linaro.org/
>>>>>
>>>>> Trying to enable CAMCC_MCLK1_CLK - wired up to the IMX576 camera sensor
>>>>> on this phone - results in following error.
>>>>>
>>>>> [    3.140232] ------------[ cut here ]------------
>>>>> [    3.141264] camcc_mclk1_clk status stuck at 'off'
>>>>> [    3.141276] WARNING: CPU: 6 PID: 12 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
>>>>>
>>>>> Checking the driver against downstream driver, it looks like the RCGs
>>>>> should be using clk_rcg2_shared_ops because of enable_safe_config in
>>>>> downstream, but changing that doesn't really improve the situation, but
>>>>> it does change the error message to this:
>>>>>
>>>>> [    2.933254] ------------[ cut here ]------------
>>>>> [    2.933961] camcc_mclk1_clk_src: rcg didn't update its configuration.
>>>>> [    2.933970] WARNING: CPU: 7 PID: 12 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xe4
>>>>>
>>>>> I've also noticed that some camcc drivers take in GCC_CAMERA_AHB_CLK as
>>>>> iface clk, could something like this be missing on sm6350?
>>>>>
>>>>> I'd appreciate any help or tips for resolving this.
>>>>>
>>>>
>>>> Recently one particular problem related to MCLK was identified by me on
>>>> QRB5165/RB5, and it was reported to Bjorn over IRC, namely it's not possible
>>>> to toggle MCLK clock enable/disable state, when TITAN GDSC power domain is
>>>> set off. I'm working on fixing the issue (a change under clk/qcom), since
>>>> it's of an importance for a customer as well.
>>>>
>>>> I can't be totally sure that it's right the same problem as the one reported
>>>> by you above, but it looks very similar, as a fast workaround please consider
>>>> to set an ALWAYS_ON flag of TITAN GDSC, and at least a report from you that
>>>> this actually helps would be nice to get.
>>> 
>>> Unfortunately that doesn't seem to help on sm6350.
>>> 
>>> diff --git a/drivers/clk/qcom/camcc-sm6350.c b/drivers/clk/qcom/camcc-sm6350.c
>>> index 12a469ce7e2f..cf87ad55d318 100644
>>> --- a/drivers/clk/qcom/camcc-sm6350.c
>>> +++ b/drivers/clk/qcom/camcc-sm6350.c
>>> @@ -1767,6 +1767,7 @@ static struct gdsc titan_top_gdsc = {
>>>  		.name = "titan_top_gdsc",
>>>  	},
>>>  	.pwrsts = PWRSTS_OFF_ON,
>>> +	.flags = ALWAYS_ON,
>>>  };
>>>  
>>>  static struct clk_hw *camcc_sm6350_hws[] = {
>>> 
>>> 
>>> $ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
>>> [...]
>>> titan_top_gdsc                  on                              0
>>>                                                 bps_gdsc, ipe_0_gdsc, ife_0_gdsc, ife_1_gdsc, ife_2_gdsc
>>>     ac4a000.cci                     suspended                   0           SW
>>>     ac4b000.cci                     suspended                   0           SW
>>>     genpd:3:acb3000.camss           suspended                   0           SW
>>> [...]
>>> 
>>> but still the same clock stuck warning...
>>> 
>>> [    3.093431] ------------[ cut here ]------------
>>> [    3.094614] camcc_mclk1_clk status stuck at 'off'
>>> [    3.094629] WARNING: CPU: 6 PID: 65 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
>>> 
>>> Thanks for the suggestion though.
>>> 
>>
>> Hi Luca,
>>
>> Seems like the CAMCC_PLL2_OUT_EARLY output could be OFF here, which is
>> sourcing the mclk RCG's.
>>
>> The user_ctl is not properly configured to enable the PLL early output.
>> Can you please try below change and check if it helps?
>>
>> diff --git a/drivers/clk/qcom/camcc-sm6350.c
>> b/drivers/clk/qcom/camcc-sm6350.c
>> index 8aac97d29ce3..d33db530b7c9 100644
>> --- a/drivers/clk/qcom/camcc-sm6350.c
>> +++ b/drivers/clk/qcom/camcc-sm6350.c
>> @@ -154,6 +154,7 @@ static const struct alpha_pll_config
>> camcc_pll2_config = {
>>         .config_ctl_hi_val = 0x400003d2,
>>         .test_ctl_val = 0x04000400,
>>         .test_ctl_hi_val = 0x00004000,
>> +       .user_ctl_val = 0x0000030F,
>> };
>
> Yes! Indeed that makes the clock not be stuck, and debugcc is also
> correctly reporting ~24MHz from that clock when it's enabled!
>
>   cam_cc_mclk1_clk: 23.999592MHz (23999592Hz)
>
> Is this PLL also missing a value for .user_ctl_hi_val? The other PLLs
> have that set as well.
>
> Out of curiousity, where's this magic value from? Only some sort of HPG
> doc, or is this also somewhere referenced in downstream? Curious why
> this is not set there for this PLL.

Ah, just saw this part in downstream
https://git.codelinaro.org/clo/la/kernel/msm-4.19/-/blob/LA.UM.9.12.c25-02800-SMxx50.QSSI13c28.0/drivers/clk/qcom/clk-alpha-pll.c#L2443-2463

That's quite different to the simple

	clk_alpha_pll_write_config(regmap, PLL_USER_CTL(pll),
							config->user_ctl_val);

that's in upstream.

Also explains makes it clear that .user_ctl_hi_val is not applicable to
this agera PLL.

From looking at camcc-sm7150, I guess they have the same problem over
there. A bunch of post_div and _mask's set, but no .user_ctl_val set for
PLL2. But camcc-sc7180 is fine though.

Regards
Luca

>
> This is one major step toward camss & camera support for this phone!
>
> Regards
> Luca

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Taniya Das]

On 10/21/2025 8:26 PM, Luca Weiss wrote:
> On Tue Oct 21, 2025 at 4:24 PM CEST, Luca Weiss wrote:
>> Hi Taniya,
>>
>> On Tue Oct 21, 2025 at 1:12 PM CEST, Taniya Das wrote:
>>>
>>>
>>> On 10/21/2025 3:28 PM, Luca Weiss wrote:
>>>> Hi Vladimir,
>>>>
>>>> On Tue Oct 21, 2025 at 11:48 AM CEST, Vladimir Zapolskiy wrote:
>>>>> Hi Luca.
>>>>>
>>>>> On 10/17/25 17:05, Luca Weiss wrote:
>>>>>> Hi Taniya,
>>>>>>
>>>>>> On Thu Mar 13, 2025 at 12:57 PM CET, Taniya Das wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 3/13/2025 1:22 PM, Luca Weiss wrote:
>>>>>>>> Hi Taniya,
>>>>>>>>
>>>>>>>> On Thu Mar 13, 2025 at 5:39 AM CET, Taniya Das wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3/4/2025 2:10 PM, Dmitry Baryshkov wrote:
>>>>>>>>>> On Tue, 4 Mar 2025 at 09:37, Vladimir Zapolskiy
>>>>>>>>>> <vladimir.zapolskiy@linaro.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 3/4/25 01:53, Dmitry Baryshkov wrote:
>>>>>>>>>>>> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>>>>>>>>>>>>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>>>>>>>>>>>>> domains.
>>>>>>>>>>>>
>>>>>>>>>>>> Are those really required to access the registers of the cammcc? Or is
>>>>>>>>>>>> one of those (MXC?) required to setup PLLs? Also, is this applicable
>>>>>>>>>>>> only to sm8550 or to other similar clock controllers?
>>>>>>>>>>>
>>>>>>>>>>> Due to the described problem I experience a fatal CPU stall on SM8550-QRD,
>>>>>>>>>>> not on any SM8450 or SM8650 powered board for instance, however it does
>>>>>>>>>>> not exclude an option that the problem has to be fixed for other clock
>>>>>>>>>>> controllers, but it's Qualcomm to confirm any other touched platforms,
>>>>>>>>>>
>>>>>>>>>> Please work with Taniya to identify used power domains.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> CAMCC requires both MMCX and MXC to be functional.
>>>>>>>>
>>>>>>>> Could you check whether any clock controllers on SM6350/SM7225 (Bitra)
>>>>>>>> need multiple power domains, or in general which clock controller uses
>>>>>>>> which power domain.
>>>>>>>>
>>>>>>>> That SoC has camcc, dispcc, gcc, gpucc, npucc and videocc.
>>>>>>>>
>>>>>>>> That'd be highly appreciated since I've been hitting weird issues there
>>>>>>>> that could be explained by some missing power domains.
>>>>>>>>
>>>>>>>
>>>>>>> Hi Luca,
>>>>>>>
>>>>>>> The targets you mentioned does not have any have multiple rail
>>>>>>> dependency, but could you share the weird issues with respect to clock
>>>>>>> controller I can take a look.
>>>>>>
>>>>>> Coming back to this, I've taken a shot at camera on SM6350 (Fairphone 4)
>>>>>> again, but again hitting some clock issues.
>>>>>>
>>>>>> For reference, I am testing with following change:
>>>>>> https://lore.kernel.org/linux-arm-msm/20250911011218.861322-3-vladimir.zapolskiy@linaro.org/
>>>>>>
>>>>>> Trying to enable CAMCC_MCLK1_CLK - wired up to the IMX576 camera sensor
>>>>>> on this phone - results in following error.
>>>>>>
>>>>>> [    3.140232] ------------[ cut here ]------------
>>>>>> [    3.141264] camcc_mclk1_clk status stuck at 'off'
>>>>>> [    3.141276] WARNING: CPU: 6 PID: 12 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
>>>>>>
>>>>>> Checking the driver against downstream driver, it looks like the RCGs
>>>>>> should be using clk_rcg2_shared_ops because of enable_safe_config in
>>>>>> downstream, but changing that doesn't really improve the situation, but
>>>>>> it does change the error message to this:
>>>>>>
>>>>>> [    2.933254] ------------[ cut here ]------------
>>>>>> [    2.933961] camcc_mclk1_clk_src: rcg didn't update its configuration.
>>>>>> [    2.933970] WARNING: CPU: 7 PID: 12 at drivers/clk/qcom/clk-rcg2.c:136 update_config+0xd4/0xe4
>>>>>>
>>>>>> I've also noticed that some camcc drivers take in GCC_CAMERA_AHB_CLK as
>>>>>> iface clk, could something like this be missing on sm6350?
>>>>>>
>>>>>> I'd appreciate any help or tips for resolving this.
>>>>>>
>>>>>
>>>>> Recently one particular problem related to MCLK was identified by me on
>>>>> QRB5165/RB5, and it was reported to Bjorn over IRC, namely it's not possible
>>>>> to toggle MCLK clock enable/disable state, when TITAN GDSC power domain is
>>>>> set off. I'm working on fixing the issue (a change under clk/qcom), since
>>>>> it's of an importance for a customer as well.
>>>>>
>>>>> I can't be totally sure that it's right the same problem as the one reported
>>>>> by you above, but it looks very similar, as a fast workaround please consider
>>>>> to set an ALWAYS_ON flag of TITAN GDSC, and at least a report from you that
>>>>> this actually helps would be nice to get.
>>>>
>>>> Unfortunately that doesn't seem to help on sm6350.
>>>>
>>>> diff --git a/drivers/clk/qcom/camcc-sm6350.c b/drivers/clk/qcom/camcc-sm6350.c
>>>> index 12a469ce7e2f..cf87ad55d318 100644
>>>> --- a/drivers/clk/qcom/camcc-sm6350.c
>>>> +++ b/drivers/clk/qcom/camcc-sm6350.c
>>>> @@ -1767,6 +1767,7 @@ static struct gdsc titan_top_gdsc = {
>>>>  		.name = "titan_top_gdsc",
>>>>  	},
>>>>  	.pwrsts = PWRSTS_OFF_ON,
>>>> +	.flags = ALWAYS_ON,
>>>>  };
>>>>  
>>>>  static struct clk_hw *camcc_sm6350_hws[] = {
>>>>
>>>>
>>>> $ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
>>>> [...]
>>>> titan_top_gdsc                  on                              0
>>>>                                                 bps_gdsc, ipe_0_gdsc, ife_0_gdsc, ife_1_gdsc, ife_2_gdsc
>>>>     ac4a000.cci                     suspended                   0           SW
>>>>     ac4b000.cci                     suspended                   0           SW
>>>>     genpd:3:acb3000.camss           suspended                   0           SW
>>>> [...]
>>>>
>>>> but still the same clock stuck warning...
>>>>
>>>> [    3.093431] ------------[ cut here ]------------
>>>> [    3.094614] camcc_mclk1_clk status stuck at 'off'
>>>> [    3.094629] WARNING: CPU: 6 PID: 65 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
>>>>
>>>> Thanks for the suggestion though.
>>>>
>>>
>>> Hi Luca,
>>>
>>> Seems like the CAMCC_PLL2_OUT_EARLY output could be OFF here, which is
>>> sourcing the mclk RCG's.
>>>
>>> The user_ctl is not properly configured to enable the PLL early output.
>>> Can you please try below change and check if it helps?
>>>
>>> diff --git a/drivers/clk/qcom/camcc-sm6350.c
>>> b/drivers/clk/qcom/camcc-sm6350.c
>>> index 8aac97d29ce3..d33db530b7c9 100644
>>> --- a/drivers/clk/qcom/camcc-sm6350.c
>>> +++ b/drivers/clk/qcom/camcc-sm6350.c
>>> @@ -154,6 +154,7 @@ static const struct alpha_pll_config
>>> camcc_pll2_config = {
>>>         .config_ctl_hi_val = 0x400003d2,
>>>         .test_ctl_val = 0x04000400,
>>>         .test_ctl_hi_val = 0x00004000,
>>> +       .user_ctl_val = 0x0000030F,
>>> };
>>
>> Yes! Indeed that makes the clock not be stuck, and debugcc is also
>> correctly reporting ~24MHz from that clock when it's enabled!
>>
>>   cam_cc_mclk1_clk: 23.999592MHz (23999592Hz)
>>
>> Is this PLL also missing a value for .user_ctl_hi_val? The other PLLs
>> have that set as well.
>>
>> Out of curiousity, where's this magic value from? Only some sort of HPG
>> doc, or is this also somewhere referenced in downstream? Curious why
>> this is not set there for this PLL.
> 

These are part of recommended PLL settings from design.

> Ah, just saw this part in downstream
> https://git.codelinaro.org/clo/la/kernel/msm-4.19/-/blob/LA.UM.9.12.c25-02800-SMxx50.QSSI13c28.0/drivers/clk/qcom/clk-alpha-pll.c#L2443-2463
> 
> That's quite different to the simple
> 
> 	clk_alpha_pll_write_config(regmap, PLL_USER_CTL(pll),
> 							config->user_ctl_val);
> 
> that's in upstream.
> 

yes, we can set all the required configs in the user_ctl_val.

> Also explains makes it clear that .user_ctl_hi_val is not applicable to
> this agera PLL.
> 

Yes you are correct.

> From looking at camcc-sm7150, I guess they have the same problem over
> there. A bunch of post_div and _mask's set, but no .user_ctl_val set for
> PLL2. But camcc-sc7180 is fine though.
> 

In SC7180, we agreed to take care of all configurations as part of the
user_ctl_val.

>>
>> This is one major step toward camss & camera support for this phone!
>>
>> Regards
>> Luca
> 

-- 
Thanks,
Taniya Das

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Bryan O'Donoghue]

On 03/03/2025 23:53, Dmitry Baryshkov wrote:
> On Tue, Mar 04, 2025 at 12:55:21AM +0200, Vladimir Zapolskiy wrote:
>> SM8550 Camera Clock Controller shall enable both MXC and MMCX power
>> domains.
> 
> Are those really required to access the registers of the cammcc? Or is
> one of those (MXC?) required to setup PLLs? Also, is this applicable
> only to sm8550 or to other similar clock controllers?
> 
>>
>> Fixes: e271b59e39a6f ("arm64: dts: qcom: sm8550: Add camera clock controller")
>> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
>> ---
>>   arch/arm64/boot/dts/qcom/sm8550.dtsi | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
>> index d02d80d731b9..d22b1753d521 100644
>> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
>> @@ -3329,7 +3329,8 @@ camcc: clock-controller@ade0000 {
>>   				 <&bi_tcxo_div2>,
>>   				 <&bi_tcxo_ao_div2>,
>>   				 <&sleep_clk>;
>> -			power-domains = <&rpmhpd SM8550_MMCX>;
>> +			power-domains = <&rpmhpd SM8550_MXC>,
>> +					<&rpmhpd SM8550_MMCX>;
>>   			required-opps = <&rpmhpd_opp_low_svs>;
>>   			#clock-cells = <1>;
>>   			#reset-cells = <1>;
>> -- 
>> 2.43.0
>>
> 

I think both of these are required.

Its a pattern we see again and again with videocc and camcc controllers. 
The GDSCs and => the hard-coded always on PLLs need to ensure these 
rails are on.

---
bod

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Taniya Das]

On 3/4/2025 5:23 AM, Dmitry Baryshkov wrote:
> @@ -3329,7 +3329,8 @@ camcc: clock-controller@ade0000 {
>  				 <&bi_tcxo_div2>,
>  				 <&bi_tcxo_ao_div2>,
>  				 <&sleep_clk>;
> -			power-domains = <&rpmhpd SM8550_MMCX>;
> +			power-domains = <&rpmhpd SM8550_MXC>,
> +					<&rpmhpd SM8550_MMCX>;

power-domains = <&rpmhpd SM8550_MMCX>,
		<&rpmhpd SM8550_MXC>;

Once the above change is incorporated, please add

Reviewed-by: Taniya Das <quic_tdas@quicinc.com>

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Bryan O'Donoghue]

On 13/03/2025 04:39, Taniya Das wrote:
> power-domains = <&rpmhpd SM8550_MMCX>,
> 		<&rpmhpd SM8550_MXC>;
> 
> Once the above change is incorporated, please add
> 
> Reviewed-by: Taniya Das<quic_tdas@quicinc.com>

Why does the ordering matter ?

It shouldn't, right ?

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Bryan O'Donoghue]

On 13/03/2025 09:10, Bryan O'Donoghue wrote:
> On 13/03/2025 04:39, Taniya Das wrote:
>> power-domains = <&rpmhpd SM8550_MMCX>,
>>         <&rpmhpd SM8550_MXC>;
>>
>> Once the above change is incorporated, please add
>>
>> Reviewed-by: Taniya Das<quic_tdas@quicinc.com>
> 
> Why does the ordering matter ?
> 
> It shouldn't, right ?

Being clear.

I just want to check that you aren't implying a dependency between the 
two domains, its just alphanumeric sorting you mean here, right ?

---
bod

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc

[Taniya Das]

On 3/13/2025 2:55 PM, Bryan O'Donoghue wrote:
> On 13/03/2025 09:10, Bryan O'Donoghue wrote:
>> On 13/03/2025 04:39, Taniya Das wrote:
>>> power-domains = <&rpmhpd SM8550_MMCX>,
>>>         <&rpmhpd SM8550_MXC>;
>>>
>>> Once the above change is incorporated, please add
>>>
>>> Reviewed-by: Taniya Das<quic_tdas@quicinc.com>
>>
>> Why does the ordering matter ?
>>
>> It shouldn't, right ?
> 

The ordering does not matter, it is to keep the newly added domain at
the end.

> Being clear.
> 
> I just want to check that you aren't implying a dependency between the
> two domains, its just alphanumeric sorting you mean here, right ?
> 
> ---
> bod

Re: [PATCH 0/2] arm64: dts: qcom: sm8550: camcc: Manage MMCX and MXC

[Rob Herring (Arm)]

On Tue, 04 Mar 2025 00:55:19 +0200, Vladimir Zapolskiy wrote:
> It was discovered that on SM8550 platform Camera Clock controller shall
> manage MMCX and MXC power domains, otherwise MMIO access to CCI or CAMSS
> breaks the execution, the problem has been discussed with Jagadeesh at
> https://lore.kernel.org/all/a5540676-9402-45c4-b647-02fdc2b92233@quicinc.com/
> 
> Since 'power-domains' property becomes generalized, Rob asked to remove
> its description, which is done in the first patch of the series, see
> https://lore.kernel.org/all/20240927224833.GA159707-robh@kernel.org/
> 
> Vladimir Zapolskiy (2):
>   dt-bindings: clock: qcom: sm8450-camcc: Allow to specify two power domains
>   arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc
> 
>  .../devicetree/bindings/clock/qcom,sm8450-camcc.yaml          | 4 +---
>  arch/arm64/boot/dts/qcom/sm8550.dtsi                          | 3 ++-
>  2 files changed, 3 insertions(+), 4 deletions(-)
> 
> --
> 2.43.0
> 
> 
> 


My bot found new DTB warnings on the .dts files added or changed in this
series.

Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.

If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:

  pip3 install dtschema --upgrade


New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/qcom/' for 20250303225521.1780611-1-vladimir.zapolskiy@linaro.org:

arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dtb: clock-controller@ad00000: power-domains: [[54, 7]] is too short
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dtb: clock-controller@ad00000: Unevaluated properties are not allowed ('power-domains' was unexpected)
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dtb: clock-controller@ad00000: power-domains: [[54, 7]] is too short
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dtb: clock-controller@ad00000: Unevaluated properties are not allowed ('power-domains' was unexpected)
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sm8650-hdk.dtb: clock-controller@ade0000: power-domains: [[161, 6]] is too short
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sm8650-hdk.dtb: clock-controller@ade0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sm8450-hdk.dtb: clock-controller@ade0000: power-domains: [[106, 6]] is too short
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sm8450-qrd.dtb: clock-controller@ade0000: power-domains: [[98, 6]] is too short
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sa8295p-adp.dtb: clock-controller@ad00000: power-domains: [[54, 7]] is too short
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sa8295p-adp.dtb: clock-controller@ad00000: Unevaluated properties are not allowed ('power-domains' was unexpected)
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sm8650-mtp.dtb: clock-controller@ade0000: power-domains: [[143, 6]] is too short
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sm8650-mtp.dtb: clock-controller@ade0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dtb: clock-controller@ad00000: power-domains: [[54, 7]] is too short
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dtb: clock-controller@ad00000: Unevaluated properties are not allowed ('power-domains' was unexpected)
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sc8280xp-microsoft-blackrock.dtb: clock-controller@ad00000: power-domains: [[54, 7]] is too short
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sc8280xp-microsoft-blackrock.dtb: clock-controller@ad00000: Unevaluated properties are not allowed ('power-domains' was unexpected)
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sm8650-qrd.dtb: clock-controller@ade0000: power-domains: [[159, 6]] is too short
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sm8650-qrd.dtb: clock-controller@ade0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sc8280xp-crd.dtb: clock-controller@ad00000: power-domains: [[54, 7]] is too short
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sc8280xp-crd.dtb: clock-controller@ad00000: Unevaluated properties are not allowed ('power-domains' was unexpected)
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sa8540p-ride.dtb: clock-controller@ad00000: power-domains: [[60, 7]] is too short
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sa8540p-ride.dtb: clock-controller@ad00000: Unevaluated properties are not allowed ('power-domains' was unexpected)
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sm8450-sony-xperia-nagara-pdx224.dtb: clock-controller@ade0000: power-domains: [[98, 6]] is too short
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
arch/arm64/boot/dts/qcom/sm8450-sony-xperia-nagara-pdx223.dtb: clock-controller@ade0000: power-domains: [[98, 6]] is too short
	from schema $id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#

Re: [PATCH 0/2] arm64: dts: qcom: sm8550: camcc: Manage MMCX and MXC

[Taniya Das]

On 3/4/2025 4:25 AM, Vladimir Zapolskiy wrote:
> It was discovered that on SM8550 platform Camera Clock controller shall
> manage MMCX and MXC power domains, otherwise MMIO access to CCI or CAMSS
> breaks the execution, the problem has been discussed with Jagadeesh at
> https://lore.kernel.org/all/a5540676-9402-45c4-b647-02fdc2b92233@quicinc.com/
> 
> Since 'power-domains' property becomes generalized, Rob asked to remove
> its description, which is done in the first patch of the series, see
> https://lore.kernel.org/all/20240927224833.GA159707-robh@kernel.org/
> 
> Vladimir Zapolskiy (2):
>   dt-bindings: clock: qcom: sm8450-camcc: Allow to specify two power domains
>   arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc
> 

Hi Vladimir, as we are preparing to submit the code for multi-power
domain support for the clock controller in our series
(https://lore.kernel.org/all/20250306-videocc-pll-multi-pd-voting-v2-0-0cd00612bc0e@quicinc.com),
there has been a request to incorporate the CAMCC-related changes as
well. If you are okay with us including this series changes(maintaining
your authorship) in our series, then we can integrate them and address
any comments in our next submission.

>  .../devicetree/bindings/clock/qcom,sm8450-camcc.yaml          | 4 +---
>  arch/arm64/boot/dts/qcom/sm8550.dtsi                          | 3 ++-
>  2 files changed, 3 insertions(+), 4 deletions(-)
> 

Re: [PATCH 0/2] arm64: dts: qcom: sm8550: camcc: Manage MMCX and MXC

[Jagadeesh Kona]

On 3/13/2025 5:08 PM, Taniya Das wrote:
> 
> 
> On 3/4/2025 4:25 AM, Vladimir Zapolskiy wrote:
>> It was discovered that on SM8550 platform Camera Clock controller shall
>> manage MMCX and MXC power domains, otherwise MMIO access to CCI or CAMSS
>> breaks the execution, the problem has been discussed with Jagadeesh at
>> https://lore.kernel.org/all/a5540676-9402-45c4-b647-02fdc2b92233@quicinc.com/
>>
>> Since 'power-domains' property becomes generalized, Rob asked to remove
>> its description, which is done in the first patch of the series, see
>> https://lore.kernel.org/all/20240927224833.GA159707-robh@kernel.org/
>>
>> Vladimir Zapolskiy (2):
>>   dt-bindings: clock: qcom: sm8450-camcc: Allow to specify two power domains
>>   arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc
>>
> 
> Hi Vladimir, as we are preparing to submit the code for multi-power
> domain support for the clock controller in our series
> (https://lore.kernel.org/all/20250306-videocc-pll-multi-pd-voting-v2-0-0cd00612bc0e@quicinc.com),
> there has been a request to incorporate the CAMCC-related changes as
> well. If you are okay with us including this series changes(maintaining
> your authorship) in our series, then we can integrate them and address
> any comments in our next submission.
> 

Hi Vladimir,

I will be including your above 2 patches in the next version of my series[1] which adds
MXC PD support for SM8450, SM8650 camcc DT nodes since my series is dependent on above
bindings change. Doing so will fix the bot warnings reported[2] in this series as well
and I will fix if there are still any more warnings left and post.

[1] https://lore.kernel.org/all/cd092022-cf6d-421a-a29d-69f7f4f068b6@quicinc.com/
[2] https://lore.kernel.org/all/174105227313.195955.8409784191665720030.robh@kernel.org/

Thanks,
Jagadeesh

>>  .../devicetree/bindings/clock/qcom,sm8450-camcc.yaml          | 4 +---
>>  arch/arm64/boot/dts/qcom/sm8550.dtsi                          | 3 ++-
>>  2 files changed, 3 insertions(+), 4 deletions(-)
>>
> 
>