diff mbox series

[v2,01/14] arm64: dts: qcom: msm8916: Drop RPM bus clocks

Message ID 20230721-topic-rpm_clk_cleanup-v2-1-1e506593b1bd@linaro.org
State New
Headers
Series Clean up RPM bus clocks remnants |

Commit Message

Konrad Dybcio Sept. 12, 2023, 1:31 p.m. UTC 
  These clocks are now handled from within the icc framework and are
no longer registered from within the CCF. Remove them.

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 9 ---------
 1 file changed, 9 deletions(-)

Comments

Krzysztof Kozlowski Sept. 13, 2023, 7:07 a.m. UTC | #1 
On 12/09/2023 15:31, Konrad Dybcio wrote:
> These clocks are now handled from within the icc framework and are

That's a driver behavior, not hardware.

> no longer registered from within the CCF. Remove them.
> 

Changes in Linux clock drivers should not cause some clocks to disappear
from DTS...


Best regards,
Krzysztof
Konrad Dybcio Sept. 13, 2023, 8:47 a.m. UTC | #2 
On 13.09.2023 09:07, Krzysztof Kozlowski wrote:
> On 12/09/2023 15:31, Konrad Dybcio wrote:
>> These clocks are now handled from within the icc framework and are
> 
> That's a driver behavior, not hardware.
I believe we've been over this already..

The rationale behind this change is: that hardware, which falls
under the "interconnect" class, was previously misrepresented as
a bunch of clocks. There are clocks underneath, but accessing them
directly would be equivalent to e.g. circumventing the PHY subsystem
and initializing your UFS PHY from within the UFS device.

Konrad
> 
>> no longer registered from within the CCF. Remove them.
>>
> 
> Changes in Linux clock drivers should not cause some clocks to disappear
> from DTS...
> 
> 
> Best regards,
> Krzysztof
>
Krzysztof Kozlowski Sept. 13, 2023, 8:53 a.m. UTC | #3 
On 13/09/2023 10:47, Konrad Dybcio wrote:
> On 13.09.2023 09:07, Krzysztof Kozlowski wrote:
>> On 12/09/2023 15:31, Konrad Dybcio wrote:
>>> These clocks are now handled from within the icc framework and are
>>
>> That's a driver behavior, not hardware.
> I believe we've been over this already..
> 
> The rationale behind this change is: that hardware, which falls
> under the "interconnect" class, was previously misrepresented as
> a bunch of clocks. There are clocks underneath, but accessing them
> directly would be equivalent to e.g. circumventing the PHY subsystem
> and initializing your UFS PHY from within the UFS device.

And every time one write such commit msg, how should we remember there
is some exception and actually it is about clock representation not CCF
or ICC framework.

Best regards,
Krzysztof
Konrad Dybcio Sept. 13, 2023, 10:48 a.m. UTC | #4 
On 13.09.2023 10:53, Krzysztof Kozlowski wrote:
> On 13/09/2023 10:47, Konrad Dybcio wrote:
>> On 13.09.2023 09:07, Krzysztof Kozlowski wrote:
>>> On 12/09/2023 15:31, Konrad Dybcio wrote:
>>>> These clocks are now handled from within the icc framework and are
>>>
>>> That's a driver behavior, not hardware.
>> I believe we've been over this already..
>>
>> The rationale behind this change is: that hardware, which falls
>> under the "interconnect" class, was previously misrepresented as
>> a bunch of clocks. There are clocks underneath, but accessing them
>> directly would be equivalent to e.g. circumventing the PHY subsystem
>> and initializing your UFS PHY from within the UFS device.
> 
> And every time one write such commit msg, how should we remember there
> is some exception and actually it is about clock representation not CCF
> or ICC framework.
So is your reply essentially "fine, but please make it clear in
each commit message"?

Konrad
Krzysztof Kozlowski Sept. 13, 2023, 11:14 a.m. UTC | #5 
On 13/09/2023 12:48, Konrad Dybcio wrote:
> On 13.09.2023 10:53, Krzysztof Kozlowski wrote:
>> On 13/09/2023 10:47, Konrad Dybcio wrote:
>>> On 13.09.2023 09:07, Krzysztof Kozlowski wrote:
>>>> On 12/09/2023 15:31, Konrad Dybcio wrote:
>>>>> These clocks are now handled from within the icc framework and are
>>>>
>>>> That's a driver behavior, not hardware.
>>> I believe we've been over this already..
>>>
>>> The rationale behind this change is: that hardware, which falls
>>> under the "interconnect" class, was previously misrepresented as
>>> a bunch of clocks. There are clocks underneath, but accessing them
>>> directly would be equivalent to e.g. circumventing the PHY subsystem
>>> and initializing your UFS PHY from within the UFS device.
>>
>> And every time one write such commit msg, how should we remember there
>> is some exception and actually it is about clock representation not CCF
>> or ICC framework.
> So is your reply essentially "fine, but please make it clear in
> each commit message"?

I am fine with this change. If commit msg had such statement, I would
not have doubts :/

Best regards,
Krzysztof
Konrad Dybcio Sept. 13, 2023, 11:14 a.m. UTC | #6 
On 13.09.2023 13:14, Krzysztof Kozlowski wrote:
> On 13/09/2023 12:48, Konrad Dybcio wrote:
>> On 13.09.2023 10:53, Krzysztof Kozlowski wrote:
>>> On 13/09/2023 10:47, Konrad Dybcio wrote:
>>>> On 13.09.2023 09:07, Krzysztof Kozlowski wrote:
>>>>> On 12/09/2023 15:31, Konrad Dybcio wrote:
>>>>>> These clocks are now handled from within the icc framework and are
>>>>>
>>>>> That's a driver behavior, not hardware.
>>>> I believe we've been over this already..
>>>>
>>>> The rationale behind this change is: that hardware, which falls
>>>> under the "interconnect" class, was previously misrepresented as
>>>> a bunch of clocks. There are clocks underneath, but accessing them
>>>> directly would be equivalent to e.g. circumventing the PHY subsystem
>>>> and initializing your UFS PHY from within the UFS device.
>>>
>>> And every time one write such commit msg, how should we remember there
>>> is some exception and actually it is about clock representation not CCF
>>> or ICC framework.
>> So is your reply essentially "fine, but please make it clear in
>> each commit message"?
> 
> I am fine with this change. If commit msg had such statement, I would
> not have doubts :/
Ok, I'll resend, thanks for confirming!

Konrad
Aiqun Yu (Maria) Jan. 2, 2024, 10:01 a.m. UTC | #7 
On 9/13/2023 7:14 PM, Konrad Dybcio wrote:
> On 13.09.2023 13:14, Krzysztof Kozlowski wrote:
>> On 13/09/2023 12:48, Konrad Dybcio wrote:
>>> On 13.09.2023 10:53, Krzysztof Kozlowski wrote:
>>>> On 13/09/2023 10:47, Konrad Dybcio wrote:
>>>>> On 13.09.2023 09:07, Krzysztof Kozlowski wrote:
>>>>>> On 12/09/2023 15:31, Konrad Dybcio wrote:
>>>>>>> These clocks are now handled from within the icc framework and are
>>>>>>
>>>>>> That's a driver behavior, not hardware.
>>>>> I believe we've been over this already..
>>>>>
>>>>> The rationale behind this change is: that hardware, which falls
>>>>> under the "interconnect" class, was previously misrepresented as
>>>>> a bunch of clocks. There are clocks underneath, but accessing them
>>>>> directly would be equivalent to e.g. circumventing the PHY subsystem
>>>>> and initializing your UFS PHY from within the UFS device.
>>>>
>>>> And every time one write such commit msg, how should we remember there
>>>> is some exception and actually it is about clock representation not CCF
>>>> or ICC framework.
>>> So is your reply essentially "fine, but please make it clear in
>>> each commit message"?
>>
>> I am fine with this change. If commit msg had such statement, I would
>> not have doubts :/
> Ok, I'll resend, thanks for confirming!
Is there any one continue working on this?

The bindings already merged while the dtb is not consistent with current 
binding files. So dt bindings checks are failed actually.
> 
> Konrad
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
diff mbox series

Patch

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 33fb65d73104..8c2ec09f57c4 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -519,9 +519,6 @@  bimc: interconnect@400000 {
 			compatible = "qcom,msm8916-bimc";
 			reg = <0x00400000 0x62000>;
 			#interconnect-cells = <1>;
-			clock-names = "bus", "bus_a";
-			clocks = <&rpmcc RPM_SMD_BIMC_CLK>,
-				 <&rpmcc RPM_SMD_BIMC_A_CLK>;
 		};
 
 		tsens: thermal-sensor@4a9000 {
@@ -554,18 +551,12 @@  pcnoc: interconnect@500000 {
 			compatible = "qcom,msm8916-pcnoc";
 			reg = <0x00500000 0x11000>;
 			#interconnect-cells = <1>;
-			clock-names = "bus", "bus_a";
-			clocks = <&rpmcc RPM_SMD_PCNOC_CLK>,
-				 <&rpmcc RPM_SMD_PCNOC_A_CLK>;
 		};
 
 		snoc: interconnect@580000 {
 			compatible = "qcom,msm8916-snoc";
 			reg = <0x00580000 0x14000>;
 			#interconnect-cells = <1>;
-			clock-names = "bus", "bus_a";
-			clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
-				 <&rpmcc RPM_SMD_SNOC_A_CLK>;
 		};
 
 		stm: stm@802000 {