| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <b6f801fc-1d8b-420b-a439-ea0cdd12f7f6@linaro.org>
Date: Fri, 29 Sep 2023 17:25:57 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
Luca Weiss <luca.weiss@...rphone.com>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Loic Poulain <loic.poulain@...aro.org>,
Robert Foss <rfoss@...nel.org>,
Andi Shyti <andi.shyti@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
cros-qcom-dts-watchers@...omium.org
Cc: ~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org,
linux-i2c@...r.kernel.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] arm64: dts: qcom: sc7280: Add Camera Control
Interface busses
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@...rphone.com>
>>>>> ---
>>>>> 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@...0000 {
>>>>> #power-domain-cells = <1>;
>>>>> };
>>>>> + cci0: cci@...a000 {
>>>>> + 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@...a000 {
>>> 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@...0000 {
> 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@...0000 {
> compatible = "qcom,sm8550-videocc";
> reg = <0 0x0aaf0000 0 0x10000>;
> clocks = <&bi_tcxo_div2>,
> <&gcc GCC_VIDEO_AHB_CLK>;
>
> sm8250
>
> camcc: clock-controller@...0000 {
> 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@...0000 {} 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@...0000 {
> 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
Powered by blists - more mailing lists