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

[Taniya Das <taniya.das@oss.qualcomm.com>]

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