Re: [PATCH 2/3] arm64: dts: qcom: sc7280: Add Camera Control Interface busses

From: Konrad Dybcio
Date: Fri Sep 29 2023 - 11:26:13 EST


On 29.09.2023 17:22, Bryan O'Donoghue wrote:
> On 29/09/2023 15:18, Konrad Dybcio wrote:
>> On 29.09.2023 16:15, Bryan O'Donoghue wrote:
>>> On 29/09/2023 14:35, Konrad Dybcio wrote:
>>>>
>>>>
>>>> On 9/29/23 10:01, Luca Weiss wrote:
>>>>> Add the CCI busses found on sc7280 and their pinctrl states.
>>>>>
>>>>> Signed-off-by: Luca Weiss <luca.weiss@xxxxxxxxxxxxx>
>>>>> ---
>>>>>    arch/arm64/boot/dts/qcom/sc7280.dtsi | 136 +++++++++++++++++++++++++++++++++++
>>>>>    1 file changed, 136 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>>>>> index 66f1eb83cca7..65550de2e4ff 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>>>>> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>>>>> @@ -3793,6 +3793,86 @@ videocc: clock-controller@aaf0000 {
>>>>>                #power-domain-cells = <1>;
>>>>>            };
>>>>> +        cci0: cci@ac4a000 {
>>>>> +            compatible = "qcom,sc7280-cci", "qcom,msm8996-cci";
>>>>> +            reg = <0 0x0ac4a000 0 0x1000>;
>>>>> +            interrupts = <GIC_SPI 460 IRQ_TYPE_EDGE_RISING>;
>>>>> +            power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
>>>>> +
>>>>> +            clocks = <&camcc CAM_CC_CAMNOC_AXI_CLK>,
>>>>> +                 <&camcc CAM_CC_SLOW_AHB_CLK_SRC>,
>>>>> +                 <&camcc CAM_CC_CPAS_AHB_CLK>,
>>>>> +                 <&camcc CAM_CC_CCI_0_CLK>,
>>>>> +                 <&camcc CAM_CC_CCI_0_CLK_SRC>;
>>>>> +            clock-names = "camnoc_axi",
>>>>> +                      "slow_ahb_src",
>>>>> +                      "cpas_ahb",
>>>>> +                      "cci",
>>>>> +                      "cci_src";
>>>> I guess this is more of a question to e.g. Bryan, but are all of these clocks actually necessary?
>>>>
>>>> Konrad
>>> Hmm its a good question, we generally take the approach of adopting all of the downstream clocks for these camera interfaces verbatim.
>>>
>>> The clock plan for this part only calls out cci_X_clk and cci_x_clk_src for the CCI however we know that to be incomplete since we *absolutely* need to have the AXI for the block clocked to access those registers, same deal with the AHB bus.
>>>
>>> AXI: registers
>>> AHB: data
>>>
>>> In the above list the only clock you might conceivably not need is CPAS_AHB_CLK.
>>>
>>> Let me zap that clock from sdm845 since I have an rb3 right in front of me and see what happens.
>>>
>>> Crash and reset
>>>
>>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> @@ -4402,13 +4402,11 @@ cci: cci@ac4a000 {
>>>                          clocks = <&clock_camcc CAM_CC_CAMNOC_AXI_CLK>,
>>>                                  <&clock_camcc CAM_CC_SOC_AHB_CLK>,
>>>                                  <&clock_camcc CAM_CC_SLOW_AHB_CLK_SRC>,
>>> -                               <&clock_camcc CAM_CC_CPAS_AHB_CLK>,
>>>                                  <&clock_camcc CAM_CC_CCI_CLK>,
>>>                                  <&clock_camcc CAM_CC_CCI_CLK_SRC>;
>>>                          clock-names = "camnoc_axi",
>>>                                  "soc_ahb",
>>>                                  "slow_ahb_src",
>>> -                               "cpas_ahb",
>>>                                  "cci",
>>>                                  "cci_src";
>>>
>>>
>>> I think the list is good tbh
>> WDYT about camcc consuming ahb, like dispcc does?
>> AXI, hmm.. not quite sure what to do with it
>>
>> Konrad
>
> Hmm on which platform, camcc clock depds on sdm845 looks very sparse to me.
>
> 8550 OTOH
>
> dispcc: clock-controller@af00000 {
>        compatible = "qcom,sm8550-dispcc";
>        reg = <0 0x0af00000 0 0x20000>;
>        clocks = <&bi_tcxo_div2>,
>                 <&bi_tcxo_ao_div2>,
>                 <&gcc GCC_DISP_AHB_CLK>,
>
> videocc: clock-controller@aaf0000 {
>        compatible = "qcom,sm8550-videocc";
>        reg = <0 0x0aaf0000 0 0x10000>;
>        clocks = <&bi_tcxo_div2>,
>                 <&gcc GCC_VIDEO_AHB_CLK>;
>
> sm8250
>
> camcc: clock-controller@ad00000 {
>         compatible = "qcom,sm8250-camcc";
>         reg = <0 0x0ad00000 0 0x10000>;
>         clocks = <&gcc GCC_CAMERA_AHB_CLK>,
>
> I think those DISP_AHB, VIDEO_AHB_CLK, CAMERA_AHB_CLKs should live in the display, video and camss blocks i.e. they are not clocks that you require to access the clock controller registers themselves...
>
> I'm seeing for the most part these MEDIAIPBLOCK_AHB_CLKs don't come from the GCC AHB clock but from another root clock generator.
>
> bi_tcxo ->
> cam_cc_pll0_out_main ->
> cam_cc_pll0_out_even ->
> cam_cc_pll0_out_odd ->
> cam_cc_pll2_out_main ->
>                         cam_cc_slow_ahb_clk_src ->
>                                    camcc_bps_ahb_clk
>                                    camcc_ipe_0_ahb_clk
>                                    ...
>                                    camcc_core_ahb_clk
>
> Lets see what happens to sm8250 if we remove CAMERA_AHB_CLK from the camera clock controller @ camcc: clock-controller@ad00000 {} I don't believe that is required.
>
> ...
>
> Yep.. does SFA
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> index 1efa07f2caff4..1e7d9ee25eeae 100644
> --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> @@ -4172,11 +4172,10 @@ port@5 {
>                 camcc: clock-controller@ad00000 {
>                         compatible = "qcom,sm8250-camcc";
>                         reg = <0 0x0ad00000 0 0x10000>;
> -                       clocks = <&gcc GCC_CAMERA_AHB_CLK>,
> -                                <&rpmhcc RPMH_CXO_CLK>,
> +                       clocks = <&rpmhcc RPMH_CXO_CLK>,
>                                  <&rpmhcc RPMH_CXO_CLK_A>,
>                                  <&sleep_clk>;
> -                       clock-names = "iface", "bi_tcxo", "bi_tcxo_ao", "sleep_clk";
> +                       clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk";
>                         power-domains = <&rpmhpd SM8250_MMCX>;
>                         required-opps = <&rpmhpd_opp_low_svs>;
>                         status = "disabled";
>
> Not actually a required clock for the clock controller.
>
> I suspect the same is true for dispcc and videocc though it would also mean the respective drivers would need to switch on <&gcc DISPx_CAMERA_AHB_CLK> or <&gcc GCC_VIDEO_AHB_CLK> prior to accessing registers inside the ip blocks which may not currently be the case.
>
> Feels like a bit of a contrary answer but my reading is the GCC_IPBLOCK_AHB_CLK clocks belong in the drivers not the clock controllers..  or at least that's true for sm8250/camcc
I believe the idea here would be that registering GCC_IP_AHB_CLK
as a pm_clk for the clock controller would make that clock turn
on when IPBLOCK_CC is accessed (e.g. when we turn on
IPBLOCK_CORE_CLK), so that it doesn't need to be duplicated in
each and every end device.

Konrad