From: Konrad Dybcio <hidden> Date: 2023-09-12 13:31:55
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 <redacted>
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 9 ---------
1 file changed, 9 deletions(-)
From: Krzysztof Kozlowski <hidden> Date: 2023-09-13 07:07:50
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Konrad Dybcio <hidden> Date: 2023-09-13 08:47:41
On 13.09.2023 09:07, Krzysztof Kozlowski wrote:
On 12/09/2023 15:31, Konrad Dybcio wrote:
quoted
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
quoted
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
From: Krzysztof Kozlowski <hidden> Date: 2023-09-13 08:54:03
On 13/09/2023 10:47, Konrad Dybcio wrote:
On 13.09.2023 09:07, Krzysztof Kozlowski wrote:
quoted
On 12/09/2023 15:31, Konrad Dybcio wrote:
quoted
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Konrad Dybcio <hidden> Date: 2023-09-13 10:48:40
On 13.09.2023 10:53, Krzysztof Kozlowski wrote:
On 13/09/2023 10:47, Konrad Dybcio wrote:
quoted
On 13.09.2023 09:07, Krzysztof Kozlowski wrote:
quoted
On 12/09/2023 15:31, Konrad Dybcio wrote:
quoted
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Krzysztof Kozlowski <hidden> Date: 2023-09-13 11:15:54
On 13/09/2023 12:48, Konrad Dybcio wrote:
On 13.09.2023 10:53, Krzysztof Kozlowski wrote:
quoted
On 13/09/2023 10:47, Konrad Dybcio wrote:
quoted
On 13.09.2023 09:07, Krzysztof Kozlowski wrote:
quoted
On 12/09/2023 15:31, Konrad Dybcio wrote:
quoted
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Konrad Dybcio <hidden> Date: 2023-09-13 11:16:09
On 13.09.2023 13:14, Krzysztof Kozlowski wrote:
On 13/09/2023 12:48, Konrad Dybcio wrote:
quoted
On 13.09.2023 10:53, Krzysztof Kozlowski wrote:
quoted
On 13/09/2023 10:47, Konrad Dybcio wrote:
quoted
On 13.09.2023 09:07, Krzysztof Kozlowski wrote:
quoted
On 12/09/2023 15:31, Konrad Dybcio wrote:
quoted
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 :/
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.
From: Konrad Dybcio <hidden> Date: 2023-09-12 13:31:59
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 <redacted>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 27 ++++-----------------------
1 file changed, 4 insertions(+), 23 deletions(-)
From: Konrad Dybcio <hidden> Date: 2023-09-12 13:32:03
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 <redacted>
---
arch/arm64/boot/dts/qcom/qcs404.dtsi | 9 ---------
1 file changed, 9 deletions(-)
From: Konrad Dybcio <hidden> Date: 2023-09-12 13:32:12
SDM630 was abusingly referencing one of the internal bus clocks, that
were recently dropped from Linux (because the original implementation
did not make much sense), circumventing the interconnect framework.
Fix it by dropping the bus-mm clock (which requires separating 630 from
similar entries) and keeping the rest as-is.
Signed-off-by: Konrad Dybcio <redacted>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Konrad Dybcio <hidden> Date: 2023-09-12 13:32:19
SDM660 was abusingly referencing one of the internal bus clocks, that
were recently dropped from Linux (because the original implementation
did not make much sense), circumventing the interconnect framework.
Drop it.
Signed-off-by: Konrad Dybcio <redacted>
---
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
From: Konrad Dybcio <hidden> Date: 2023-09-12 13:32:23
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 <redacted>
---
arch/arm64/boot/dts/qcom/sdm630.dtsi | 49 +++++++-----------------------------
1 file changed, 9 insertions(+), 40 deletions(-)
From: Krzysztof Kozlowski <hidden> Date: 2023-09-13 07:13:47
On 12/09/2023 15:31, Konrad Dybcio wrote:
quoted hunk
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 <redacted>
---
arch/arm64/boot/dts/qcom/sdm630.dtsi | 49 +++++++-----------------------------
1 file changed, 9 insertions(+), 40 deletions(-)
From: Konrad Dybcio <hidden> Date: 2023-09-13 12:09:02
On 13.09.2023 09:13, Krzysztof Kozlowski wrote:
On 12/09/2023 15:31, Konrad Dybcio wrote:
quoted
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 <redacted>
---
From: Krzysztof Kozlowski <hidden> Date: 2023-09-14 06:26:50
On 13/09/2023 14:08, Konrad Dybcio wrote:
On 13.09.2023 09:13, Krzysztof Kozlowski wrote:
quoted
On 12/09/2023 15:31, Konrad Dybcio wrote:
quoted
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 <redacted>
---
This is also against bindings. After your patch #4, such bus clock (or
other combinations) is still required.
So, we have 4 SMMU instances on this platform:
MMSS (described, iface, mem, mem_iface)
GPU (described, iface-mm, iface-smmu, bus-smmu)
ANOC2 (this one, no clocks after removing rpmcc bus)
LPASS (no clocks)
Ah, I did not notice it.
Should I then create a new entry in the bindings, replicating
what's there for msm8998[1] and dropping the entry with just "bus"
from anyOf?
So this passes the bindings, right? anyOf: in the binding should allow
also no match, so this should be fine. However indeed we need to drop
the "bus" entry, because it is not valid anymore.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Konrad Dybcio <hidden> Date: 2023-09-14 07:41:15
On 14.09.2023 08:26, Krzysztof Kozlowski wrote:
On 13/09/2023 14:08, Konrad Dybcio wrote:
quoted
On 13.09.2023 09:13, Krzysztof Kozlowski wrote:
quoted
On 12/09/2023 15:31, Konrad Dybcio wrote:
quoted
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 <redacted>
---
This is also against bindings. After your patch #4, such bus clock (or
other combinations) is still required.
So, we have 4 SMMU instances on this platform:
MMSS (described, iface, mem, mem_iface)
GPU (described, iface-mm, iface-smmu, bus-smmu)
ANOC2 (this one, no clocks after removing rpmcc bus)
LPASS (no clocks)
Ah, I did not notice it.
quoted
Should I then create a new entry in the bindings, replicating
what's there for msm8998[1] and dropping the entry with just "bus"
from anyOf?
So this passes the bindings, right?
Yes
anyOf: in the binding should allow
also no match, so this should be fine. However indeed we need to drop
the "bus" entry, because it is not valid anymore.
Actually, looks like the LPASS smmu may require a single
clock. We can reuse that single-"bus"-clock entry for
HLOS1_VOTE_LPASS_ADSP_SMMU_CLK.
The device didn't crash when trying to access LPASS SMMU
with that clock absent, but I guess it may have just
been luck, things may change once more hardware is parked..
Konrad
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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 <redacted>
This makes the USB and IOMMUs probe again on SDM630 devices like the Sony Xperia
XA2 Ultra. Thanks!
Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
+cc Dmitry who was talking to me about this SoC.
From: Konrad Dybcio <hidden> Date: 2023-09-12 13:32:33
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 <redacted>
---
arch/arm64/boot/dts/qcom/msm8939.dtsi | 12 ------------
1 file changed, 12 deletions(-)
From: Krzysztof Kozlowski <hidden> Date: 2023-09-13 07:15:56
On 12/09/2023 15:31, Konrad Dybcio wrote:
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 <redacted>
---
Reviewed-by: Krzysztof Kozlowski <redacted>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Konrad Dybcio <hidden> Date: 2023-09-12 13:32:39
The AGGRE2 clock is a clock for the entire AGGRE2 bus, managed from
within the interconnect driver. Attaching it to SLPI was a total hack.
Get rid of it.
Signed-off-by: Konrad Dybcio <redacted>
---
.../devicetree/bindings/remoteproc/qcom,adsp.yaml | 20 ++------------------
1 file changed, 2 insertions(+), 18 deletions(-)
From: Krzysztof Kozlowski <hidden> Date: 2023-09-13 07:16:40
On 12/09/2023 15:31, Konrad Dybcio wrote:
The AGGRE2 clock is a clock for the entire AGGRE2 bus, managed from
within the interconnect driver. Attaching it to SLPI was a total hack.
Get rid of it.
Signed-off-by: Konrad Dybcio <redacted>
---
Reviewed-by: Krzysztof Kozlowski <redacted>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Konrad Dybcio <hidden> Date: 2023-09-12 13:32:47
The PNoC clock is a clock for the entire PNoC bus, managed from
within the interconnect driver. Attaching it to MSS was a total hack.
Get rid of it.
Acked-by: Krzysztof Kozlowski <redacted>
Signed-off-by: Konrad Dybcio <redacted>
---
Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml | 2 --
1 file changed, 2 deletions(-)
From: Konrad Dybcio <hidden> Date: 2023-09-12 13:32:53
The PNoC clock is a clock for the entire PNoC bus, managed from
within the interconnect driver. Attaching it to MSS was a total hack.
Get rid of it.
Signed-off-by: Konrad Dybcio <redacted>
---
drivers/remoteproc/qcom_q6v5_mss.c | 1 -
1 file changed, 1 deletion(-)
From: Konrad Dybcio <hidden> Date: 2023-09-12 13:32:59
The AGGRE2 clock is a clock for the entire AGGRE2 bus, managed from
within the interconnect driver. Attaching it to SLPI was a total hack.
Get rid of it.
Signed-off-by: Konrad Dybcio <redacted>
---
arch/arm64/boot/dts/qcom/msm8998.dtsi | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
From: Konrad Dybcio <hidden> Date: 2023-09-12 13:33:04
The AGGRE2 clock is a clock for the entire AGGRE2 bus, managed from
within the interconnect driver. Attaching it to SLPI was a total hack.
Get rid of it.
Signed-off-by: Konrad Dybcio <redacted>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
From: Konrad Dybcio <hidden> Date: 2023-09-12 13:33:18
The PNoC clock is a clock for the entire PNoC bus, managed from
within the interconnect driver. Attaching it to MSS was a total hack.
Get rid of it and take the liberty to make the clock-names entries
more readable.
Signed-off-by: Konrad Dybcio <redacted>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
From: Konrad Dybcio <hidden> Date: 2023-09-12 13:33:23
The last 2 clock-names entries for the USB2 controller were swapped,
resulting in schema warnings:
['cfg_noc', 'core', 'mock_utmi', 'sleep'] is too short
'iface' was expected
'sleep' was expected
'mock_utmi' was expected
Fix it and take the liberty to make the clock-names entries more
readable.
Signed-off-by: Konrad Dybcio <redacted>
---
arch/arm64/boot/dts/qcom/sdm630.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
From: Krzysztof Kozlowski <hidden> Date: 2023-09-13 07:18:04
On 12/09/2023 15:31, Konrad Dybcio wrote:
The last 2 clock-names entries for the USB2 controller were swapped,
resulting in schema warnings:
['cfg_noc', 'core', 'mock_utmi', 'sleep'] is too short
'iface' was expected
'sleep' was expected
'mock_utmi' was expected
Fix it and take the liberty to make the clock-names entries more
readable.
From: Krzysztof Kozlowski <hidden> Date: 2023-09-13 07:19:22
On 12/09/2023 15:31, Konrad Dybcio wrote:
quoted hunk
The last 2 clock-names entries for the USB2 controller were swapped,
resulting in schema warnings:
['cfg_noc', 'core', 'mock_utmi', 'sleep'] is too short
'iface' was expected
'sleep' was expected
'mock_utmi' was expected
Fix it and take the liberty to make the clock-names entries more
readable.
Signed-off-by: Konrad Dybcio <redacted>
---
arch/arm64/boot/dts/qcom/sdm630.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
From: Will Deacon <will@kernel.org> Date: 2023-09-18 11:06:51
On Tue, 12 Sep 2023 15:31:38 +0200, Konrad Dybcio wrote:
After the recent cleanups ([1], [2]) some in-tree abusers that directly
accessed the RPM bus clocks, effectively circumventing and working
against the efforts of the interconnect framework, were found.
Patches 1-5 drop deprecated references and the rest attempt to stop
direct bus clock abuses.
[...]
On Tue, 12 Sep 2023 15:31:38 +0200, Konrad Dybcio wrote:
After the recent cleanups ([1], [2]) some in-tree abusers that directly
accessed the RPM bus clocks, effectively circumventing and working
against the efforts of the interconnect framework, were found.
Patches 1-5 drop deprecated references and the rest attempt to stop
direct bus clock abuses.
[...]