[PATCH] arm64: dts: qcom: qcs615: disable the CTI device of the camera block

[PATCH] arm64: dts: qcom: qcs615: disable the CTI device of the camera block

[Jie Gan]

Disable the CTI device of the camera block to prevent potential NoC errors
during AMBA bus device matching.

The clocks for the Qualcomm Debug Subsystem (QDSS) are managed by aoss_qmp
through a mailbox. However, the camera block resides outside the AP domain,
meaning its QDSS clock cannot be controlled via aoss_qmp.

Fixes: bf469630552a ("arm64: dts: qcom: qcs615: Add coresight nodes")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/qcs615.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs615.dtsi b/arch/arm64/boot/dts/qcom/qcs615.dtsi
index 559d3a4ba605..a31920691b65 100644
--- a/arch/arm64/boot/dts/qcom/qcs615.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs615.dtsi
@@ -2462,6 +2462,7 @@ cti@6c13000 {
 
 			clocks = <&aoss_qmp>;
 			clock-names = "apb_pclk";
+			status = "disabled";
 		};
 
 		cti@6c20000 {
-- 
2.34.1

Re: [PATCH] arm64: dts: qcom: qcs615: disable the CTI device of the camera block

[Konrad Dybcio]

On 5/27/25 3:52 AM, Jie Gan wrote:
> Disable the CTI device of the camera block to prevent potential NoC errors
> during AMBA bus device matching.
> 
> The clocks for the Qualcomm Debug Subsystem (QDSS) are managed by aoss_qmp
> through a mailbox. However, the camera block resides outside the AP domain,
> meaning its QDSS clock cannot be controlled via aoss_qmp.

Which clock drives it then?

Konrad

Re: [PATCH] arm64: dts: qcom: qcs615: disable the CTI device of the camera block

[Jie Gan]

On 5/27/2025 6:23 PM, Konrad Dybcio wrote:
> On 5/27/25 3:52 AM, Jie Gan wrote:
>> Disable the CTI device of the camera block to prevent potential NoC errors
>> during AMBA bus device matching.
>>
>> The clocks for the Qualcomm Debug Subsystem (QDSS) are managed by aoss_qmp
>> through a mailbox. However, the camera block resides outside the AP domain,
>> meaning its QDSS clock cannot be controlled via aoss_qmp.
> 
> Which clock drives it then?

It's qcom,aoss-qmp.

clk_prepare->qmp_qdss_clk_prepare
https://elixir.bootlin.com/linux/v6.15-rc7/source/drivers/soc/qcom/qcom_aoss.c#L280

Thanks,
Jie

> 
> Konrad

Re: [PATCH] arm64: dts: qcom: qcs615: disable the CTI device of the camera block

[Konrad Dybcio]

On 5/27/25 12:32 PM, Jie Gan wrote:
> 
> 
> On 5/27/2025 6:23 PM, Konrad Dybcio wrote:
>> On 5/27/25 3:52 AM, Jie Gan wrote:
>>> Disable the CTI device of the camera block to prevent potential NoC errors
>>> during AMBA bus device matching.
>>>
>>> The clocks for the Qualcomm Debug Subsystem (QDSS) are managed by aoss_qmp
>>> through a mailbox. However, the camera block resides outside the AP domain,
>>> meaning its QDSS clock cannot be controlled via aoss_qmp.
>>
>> Which clock drives it then?
> 
> It's qcom,aoss-qmp.
> 
> clk_prepare->qmp_qdss_clk_prepare
> https://elixir.bootlin.com/linux/v6.15-rc7/source/drivers/soc/qcom/qcom_aoss.c#L280

I'm confused about this part:

> However, the camera block resides outside the AP domain,
> meaning its QDSS clock cannot be controlled via aoss_qmp.

Do we need to poke the QMP of another DRV?

Konrad

Re: [PATCH] arm64: dts: qcom: qcs615: disable the CTI device of the camera block

[Jie Gan]

On 5/27/2025 6:41 PM, Konrad Dybcio wrote:
> On 5/27/25 12:32 PM, Jie Gan wrote:
>>
>>
>> On 5/27/2025 6:23 PM, Konrad Dybcio wrote:
>>> On 5/27/25 3:52 AM, Jie Gan wrote:
>>>> Disable the CTI device of the camera block to prevent potential NoC errors
>>>> during AMBA bus device matching.
>>>>
>>>> The clocks for the Qualcomm Debug Subsystem (QDSS) are managed by aoss_qmp
>>>> through a mailbox. However, the camera block resides outside the AP domain,
>>>> meaning its QDSS clock cannot be controlled via aoss_qmp.
>>>
>>> Which clock drives it then?
>>
>> It's qcom,aoss-qmp.
>>
>> clk_prepare->qmp_qdss_clk_prepare
>> https://elixir.bootlin.com/linux/v6.15-rc7/source/drivers/soc/qcom/qcom_aoss.c#L280
> 
> I'm confused about this part:
> 
>> However, the camera block resides outside the AP domain,
>> meaning its QDSS clock cannot be controlled via aoss_qmp.
> 
> Do we need to poke the QMP of another DRV?

The AOSS has a clock control register for all QDSS clocks. when we vote 
the qdss clock, the aoss_qmp driver will send a message to AOSS to 
enable the clock control register, then the clock control register will 
enable all QDSS clocks.

The QDSS clock is not a single clock source, it is a term that 
representing all the clock sources utilized by the QDSS.

Thanks,
Jie

> 
> Konrad

Re: [PATCH] arm64: dts: qcom: qcs615: disable the CTI device of the camera block

[Konrad Dybcio]

On 5/28/25 5:02 AM, Jie Gan wrote:
> 
> 
> On 5/27/2025 6:41 PM, Konrad Dybcio wrote:
>> On 5/27/25 12:32 PM, Jie Gan wrote:
>>>
>>>
>>> On 5/27/2025 6:23 PM, Konrad Dybcio wrote:
>>>> On 5/27/25 3:52 AM, Jie Gan wrote:
>>>>> Disable the CTI device of the camera block to prevent potential NoC errors
>>>>> during AMBA bus device matching.
>>>>>
>>>>> The clocks for the Qualcomm Debug Subsystem (QDSS) are managed by aoss_qmp
>>>>> through a mailbox. However, the camera block resides outside the AP domain,
>>>>> meaning its QDSS clock cannot be controlled via aoss_qmp.
>>>>
>>>> Which clock drives it then?
>>>
>>> It's qcom,aoss-qmp.
>>>
>>> clk_prepare->qmp_qdss_clk_prepare
>>> https://elixir.bootlin.com/linux/v6.15-rc7/source/drivers/soc/qcom/qcom_aoss.c#L280
>>
>> I'm confused about this part:
>>
>>> However, the camera block resides outside the AP domain,
>>> meaning its QDSS clock cannot be controlled via aoss_qmp.
>>
>> Do we need to poke the QMP of another DRV?
> 
> The AOSS has a clock control register for all QDSS clocks. when we vote the qdss clock, the aoss_qmp driver will send a message to AOSS to enable the clock control register, then the clock control register will enable all QDSS clocks.
> 
> The QDSS clock is not a single clock source, it is a term that representing all the clock sources utilized by the QDSS.

What I'm trying to ask is, is there any way we could enable that
clock from Linux? Can the camera hw turn these on? Maybe we could
trick it into enabling them?

Konrad

Re: [PATCH] arm64: dts: qcom: qcs615: disable the CTI device of the camera block

[Jie Gan]

On 5/31/2025 7:05 AM, Konrad Dybcio wrote:
> On 5/28/25 5:02 AM, Jie Gan wrote:
>>
>>
>> On 5/27/2025 6:41 PM, Konrad Dybcio wrote:
>>> On 5/27/25 12:32 PM, Jie Gan wrote:
>>>>
>>>>
>>>> On 5/27/2025 6:23 PM, Konrad Dybcio wrote:
>>>>> On 5/27/25 3:52 AM, Jie Gan wrote:
>>>>>> Disable the CTI device of the camera block to prevent potential NoC errors
>>>>>> during AMBA bus device matching.
>>>>>>
>>>>>> The clocks for the Qualcomm Debug Subsystem (QDSS) are managed by aoss_qmp
>>>>>> through a mailbox. However, the camera block resides outside the AP domain,
>>>>>> meaning its QDSS clock cannot be controlled via aoss_qmp.
>>>>>
>>>>> Which clock drives it then?
>>>>
>>>> It's qcom,aoss-qmp.
>>>>
>>>> clk_prepare->qmp_qdss_clk_prepare
>>>> https://elixir.bootlin.com/linux/v6.15-rc7/source/drivers/soc/qcom/qcom_aoss.c#L280
>>>
>>> I'm confused about this part:
>>>
>>>> However, the camera block resides outside the AP domain,
>>>> meaning its QDSS clock cannot be controlled via aoss_qmp.
>>>
>>> Do we need to poke the QMP of another DRV?
>>
>> The AOSS has a clock control register for all QDSS clocks. when we vote the qdss clock, the aoss_qmp driver will send a message to AOSS to enable the clock control register, then the clock control register will enable all QDSS clocks.
>>
>> The QDSS clock is not a single clock source, it is a term that representing all the clock sources utilized by the QDSS.
> 
> What I'm trying to ask is, is there any way we could enable that
> clock from Linux? Can the camera hw turn these on? Maybe we could
> trick it into enabling them?

There is a power issue if we keep the debug clock on with a long time.

We had a discussion with AOP to check if possible to add the debug clock 
of titan to the QDSS clock list, but they need time to evaluate it.

 From Coresight view, what we can do by now is disable it in DT to 
prevent the unexpected NoC error.

Thanks,
Jie

> 
> Konrad

Re: [PATCH] arm64: dts: qcom: qcs615: disable the CTI device of the camera block

[Konrad Dybcio]

On 6/3/25 5:17 AM, Jie Gan wrote:
> 
> 
> On 5/31/2025 7:05 AM, Konrad Dybcio wrote:
>> On 5/28/25 5:02 AM, Jie Gan wrote:
>>>
>>>
>>> On 5/27/2025 6:41 PM, Konrad Dybcio wrote:
>>>> On 5/27/25 12:32 PM, Jie Gan wrote:
>>>>>
>>>>>
>>>>> On 5/27/2025 6:23 PM, Konrad Dybcio wrote:
>>>>>> On 5/27/25 3:52 AM, Jie Gan wrote:
>>>>>>> Disable the CTI device of the camera block to prevent potential NoC errors
>>>>>>> during AMBA bus device matching.
>>>>>>>
>>>>>>> The clocks for the Qualcomm Debug Subsystem (QDSS) are managed by aoss_qmp
>>>>>>> through a mailbox. However, the camera block resides outside the AP domain,
>>>>>>> meaning its QDSS clock cannot be controlled via aoss_qmp.
>>>>>>
>>>>>> Which clock drives it then?
>>>>>
>>>>> It's qcom,aoss-qmp.
>>>>>
>>>>> clk_prepare->qmp_qdss_clk_prepare
>>>>> https://elixir.bootlin.com/linux/v6.15-rc7/source/drivers/soc/qcom/qcom_aoss.c#L280
>>>>
>>>> I'm confused about this part:
>>>>
>>>>> However, the camera block resides outside the AP domain,
>>>>> meaning its QDSS clock cannot be controlled via aoss_qmp.
>>>>
>>>> Do we need to poke the QMP of another DRV?
>>>
>>> The AOSS has a clock control register for all QDSS clocks. when we vote the qdss clock, the aoss_qmp driver will send a message to AOSS to enable the clock control register, then the clock control register will enable all QDSS clocks.
>>>
>>> The QDSS clock is not a single clock source, it is a term that representing all the clock sources utilized by the QDSS.
>>
>> What I'm trying to ask is, is there any way we could enable that
>> clock from Linux? Can the camera hw turn these on? Maybe we could
>> trick it into enabling them?
> 
> There is a power issue if we keep the debug clock on with a long time.
> 
> We had a discussion with AOP to check if possible to add the debug clock of titan to the QDSS clock list, but they need time to evaluate it.

Changing the firmware is a band-aid solution, as the update will never
reach millions of devices on the market. I'm curious in whether there's
any way (or os-accessible debug register) to manage the necessary clocks
from Linux, as a workaround.

> From Coresight view, what we can do by now is disable it in DT to prevent the unexpected NoC error.

How about something like this:

diff --git a/arch/arm64/boot/dts/qcom/qcs615.dtsi b/arch/arm64/boot/dts/qcom/qcs615.dtsi
index bb8b6c3ebd03..fc2ab750f2cd 100644
--- a/arch/arm64/boot/dts/qcom/qcs615.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs615.dtsi
@@ -2461,6 +2461,9 @@ cti@6c13000 {
 
                        clocks = <&aoss_qmp>;
                        clock-names = "apb_pclk";
+
+                       /* Not all required clocks can be enabled from the OS */
+                       status = "fail";
                };
 
                cti@6c20000 {

Konrad

Re: [PATCH] arm64: dts: qcom: qcs615: disable the CTI device of the camera block

[Jie Gan]

On 6/10/2025 9:24 PM, Konrad Dybcio wrote:
> On 6/3/25 5:17 AM, Jie Gan wrote:
>>
>>
>> On 5/31/2025 7:05 AM, Konrad Dybcio wrote:
>>> On 5/28/25 5:02 AM, Jie Gan wrote:
>>>>
>>>>
>>>> On 5/27/2025 6:41 PM, Konrad Dybcio wrote:
>>>>> On 5/27/25 12:32 PM, Jie Gan wrote:
>>>>>>
>>>>>>
>>>>>> On 5/27/2025 6:23 PM, Konrad Dybcio wrote:
>>>>>>> On 5/27/25 3:52 AM, Jie Gan wrote:
>>>>>>>> Disable the CTI device of the camera block to prevent potential NoC errors
>>>>>>>> during AMBA bus device matching.
>>>>>>>>
>>>>>>>> The clocks for the Qualcomm Debug Subsystem (QDSS) are managed by aoss_qmp
>>>>>>>> through a mailbox. However, the camera block resides outside the AP domain,
>>>>>>>> meaning its QDSS clock cannot be controlled via aoss_qmp.
>>>>>>>
>>>>>>> Which clock drives it then?
>>>>>>
>>>>>> It's qcom,aoss-qmp.
>>>>>>
>>>>>> clk_prepare->qmp_qdss_clk_prepare
>>>>>> https://elixir.bootlin.com/linux/v6.15-rc7/source/drivers/soc/qcom/qcom_aoss.c#L280
>>>>>
>>>>> I'm confused about this part:
>>>>>
>>>>>> However, the camera block resides outside the AP domain,
>>>>>> meaning its QDSS clock cannot be controlled via aoss_qmp.
>>>>>
>>>>> Do we need to poke the QMP of another DRV?
>>>>
>>>> The AOSS has a clock control register for all QDSS clocks. when we vote the qdss clock, the aoss_qmp driver will send a message to AOSS to enable the clock control register, then the clock control register will enable all QDSS clocks.
>>>>
>>>> The QDSS clock is not a single clock source, it is a term that representing all the clock sources utilized by the QDSS.
>>>
>>> What I'm trying to ask is, is there any way we could enable that
>>> clock from Linux? Can the camera hw turn these on? Maybe we could
>>> trick it into enabling them?
>>
>> There is a power issue if we keep the debug clock on with a long time.
>>
>> We had a discussion with AOP to check if possible to add the debug clock of titan to the QDSS clock list, but they need time to evaluate it.
> 
> Changing the firmware is a band-aid solution, as the update will never
> reach millions of devices on the market. I'm curious in whether there's
> any way (or os-accessible debug register) to manage the necessary clocks
> from Linux, as a workaround.
> 
>>  From Coresight view, what we can do by now is disable it in DT to prevent the unexpected NoC error.
> 
> How about something like this:

Thanks for the suggestion. It makes sense for me and much better than 
current version.

I will send a new version to fix it.

Thanks,
Jie

> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs615.dtsi b/arch/arm64/boot/dts/qcom/qcs615.dtsi
> index bb8b6c3ebd03..fc2ab750f2cd 100644
> --- a/arch/arm64/boot/dts/qcom/qcs615.dtsi
> +++ b/arch/arm64/boot/dts/qcom/qcs615.dtsi
> @@ -2461,6 +2461,9 @@ cti@6c13000 {
>   
>                          clocks = <&aoss_qmp>;
>                          clock-names = "apb_pclk";
> +
> +                       /* Not all required clocks can be enabled from the OS */
> +                       status = "fail";
>                  };
>   
>                  cti@6c20000 {
> 
> Konrad