From: Andrew Davis <afd@ti.com>
To: Jan Kiszka <jan.kiszka@siemens.com>, Nishanth Menon <nm@ti.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
Tero Kristo <kristo@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>
Cc: <linux-arm-kernel@lists.infradead.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] arm64: dts: ti: k3-am65: Move SerDes mux nodes under the control node
Date: Fri, 14 Jun 2024 11:19:18 -0500 [thread overview]
Message-ID: <50327a4a-3653-43d7-88de-2182dc3eb4e7@ti.com> (raw)
In-Reply-To: <a15da17a-f196-4356-a744-5c8e1104e7c0@siemens.com>
On 6/14/24 2:44 AM, Jan Kiszka wrote:
> On 26.03.24 19:56, Andrew Davis wrote:
>> These SerDes lane select muxes use bits from the same register as
>> the SerDes clock select mux. Make the lane select mux a child
>> of the SerDes control node.
>>
>> This removes one more requirement on scm-conf being a syscon node
>> which will later be converted to fix a couple DTS check warnings.
>>
>> Signed-off-by: Andrew Davis <afd@ti.com>
>> ---
>> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 21 +++++++++++++--------
>> 1 file changed, 13 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> index 738c5c4acbcd2..5ce67e6a33600 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> @@ -66,7 +66,7 @@ serdes0: serdes@900000 {
>> assigned-clock-parents = <&k3_clks 153 8>, <&k3_clks 153 4>;
>> ti,serdes-clk = <&serdes0_clk>;
>> #clock-cells = <1>;
>> - mux-controls = <&serdes_mux 0>;
>> + mux-controls = <&serdes0_mux 0>;
>> };
>>
>> serdes1: serdes@910000 {
>> @@ -81,7 +81,7 @@ serdes1: serdes@910000 {
>> assigned-clock-parents = <&k3_clks 154 9>, <&k3_clks 154 5>;
>> ti,serdes-clk = <&serdes1_clk>;
>> #clock-cells = <1>;
>> - mux-controls = <&serdes_mux 1>;
>> + mux-controls = <&serdes1_mux 0>;
>> };
>>
>> main_uart0: serial@2800000 {
>> @@ -485,18 +485,23 @@ scm_conf: scm-conf@100000 {
>> serdes0_clk: clock@4080 {
>> compatible = "ti,am654-serdes-ctrl", "syscon";
>> reg = <0x4080 0x4>;
>> +
>> + serdes0_mux: mux-controller {
>> + compatible = "mmio-mux";
>> + #mux-control-cells = <1>;
>> + mux-reg-masks = <0x0 0x3>; /* lane select */
>> + };
>> };
>>
>> serdes1_clk: clock@4090 {
>> compatible = "ti,am654-serdes-ctrl", "syscon";
>> reg = <0x4090 0x4>;
>> - };
>>
>> - serdes_mux: mux-controller {
>> - compatible = "mmio-mux";
>> - #mux-control-cells = <1>;
>> - mux-reg-masks = <0x4080 0x3>, /* SERDES0 lane select */
>> - <0x4090 0x3>; /* SERDES1 lane select */
>> + serdes1_mux: mux-controller {
>> + compatible = "mmio-mux";
>> + #mux-control-cells = <1>;
>> + mux-reg-masks = <0x0 0x3>; /* lane select */
>> + };
>> };
>>
>> dss_oldi_io_ctrl: dss-oldi-io-ctrl@41e0 {
>
> This change breaks serdes setup on the IOT2050 SM (k3-am6548-iot2050-
> advanced-sm.dts), possibly on more of our devices as well:
>
> platform 5500000.pcie: deferred probe pending: platform: supplier 900000.serdes not ready
> platform 900000.serdes: deferred probe pending: (reason unknown)
>
> And PCI remains unavailable. Digging a bit into it, it seems the change
> is causing a circular consumer/provider dependency between serdes0 and
> serdes1:
>
> root@iot2050-debian:~# ls -l /sys/bus/platform/devices/900000.serdes/
> total 0
> lrwxrwxrwx 1 root root 0 Jun 14 07:10 consumer:platform:5500000.pcie -> ../../../virtual/devlink/platform:900000.serdes--platform:5500000.pcie
> lrwxrwxrwx 1 root root 0 Jun 14 07:10 consumer:platform:910000.serdes -> ../../../virtual/devlink/platform:900000.serdes--platform:910000.serdes
> -rw-r--r-- 1 root root 4096 Jun 14 07:10 driver_override
> -r--r--r-- 1 root root 4096 Jun 14 07:10 modalias
> lrwxrwxrwx 1 root root 0 Jun 14 07:10 of_node -> ../../../../firmware/devicetree/base/bus@100000/serdes@900000
> drwxr-xr-x 2 root root 0 Jun 14 07:10 power
> lrwxrwxrwx 1 root root 0 Jun 14 07:00 subsystem -> ../../../../bus/platform
> lrwxrwxrwx 1 root root 0 Jun 14 07:10 supplier:platform:44083000.system-controller:clock-controller -> ../../../virtual/devlink/platform:44083000.system-controller:clock-controller--platform:900000.serdes
> lrwxrwxrwx 1 root root 0 Jun 14 07:10 supplier:platform:44083000.system-controller:power-controller -> ../../../virtual/devlink/platform:44083000.system-controller:power-controller--platform:900000.serdes
> lrwxrwxrwx 1 root root 0 Jun 14 07:10 supplier:platform:910000.serdes -> ../../../virtual/devlink/platform:910000.serdes--platform:900000.serdes
> -rw-r--r-- 1 root root 4096 Jun 14 07:00 uevent
> -r--r--r-- 1 root root 4096 Jun 14 07:10 waiting_for_supplier
> root@iot2050-debian:~# ls -l /sys/bus/platform/devices/910000.serdes/
> total 0
> lrwxrwxrwx 1 root root 0 Jun 14 07:14 consumer:platform:900000.serdes -> ../../../virtual/devlink/platform:910000.serdes--platform:900000.serdes
> -rw-r--r-- 1 root root 4096 Jun 14 07:14 driver_override
> -r--r--r-- 1 root root 4096 Jun 14 07:14 modalias
> lrwxrwxrwx 1 root root 0 Jun 14 07:14 of_node -> ../../../../firmware/devicetree/base/bus@100000/serdes@910000
> drwxr-xr-x 2 root root 0 Jun 14 07:14 power
> lrwxrwxrwx 1 root root 0 Jun 14 07:00 subsystem -> ../../../../bus/platform
> lrwxrwxrwx 1 root root 0 Jun 14 07:14 supplier:platform:44083000.system-controller:clock-controller -> ../../../virtual/devlink/platform:44083000.system-controller:clock-controller--platform:910000.serdes
> lrwxrwxrwx 1 root root 0 Jun 14 07:14 supplier:platform:44083000.system-controller:power-controller -> ../../../virtual/devlink/platform:44083000.system-controller:power-controller--platform:910000.serdes
> lrwxrwxrwx 1 root root 0 Jun 14 07:14 supplier:platform:900000.serdes -> ../../../virtual/devlink/platform:900000.serdes--platform:910000.serdes
> -rw-r--r-- 1 root root 4096 Jun 14 07:00 uevent
> -r--r--r-- 1 root root 4096 Jun 14 07:14 waiting_for_supplier
>
> Note that we normally disable serdes1 on this device as it was not
> required so far. Enabling the node does not solve the issue, though:
>
> platform 5500000.pcie: deferred probe pending: platform: supplier 900000.serdes not ready
> platform 900000.serdes: deferred probe pending: (reason unknown)
> platform 910000.serdes: deferred probe pending: (reason unknown)
>
Thanks for the report, I think I know the issue and can
send the fix here in a bit. In the mean time, could you
see if the following fixes the issue (this isn't fully
correct and will cause a new DTB check warning, but will
let me verify the issue):
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 1af3dedde1f67..06ed74197f893 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -478,7 +478,7 @@ scm_conf: scm-conf@100000 {
ranges = <0x0 0x0 0x00100000 0x1c000>;
serdes0_clk: clock@4080 {
- compatible = "ti,am654-serdes-ctrl", "syscon";
+ compatible = "ti,am654-serdes-ctrl", "syscon", "simple-mfd";
reg = <0x4080 0x4>;
serdes0_mux: mux-controller {
@@ -489,7 +489,7 @@ serdes0_mux: mux-controller {
};
serdes1_clk: clock@4090 {
- compatible = "ti,am654-serdes-ctrl", "syscon";
+ compatible = "ti,am654-serdes-ctrl", "syscon", "simple-mfd";
reg = <0x4090 0x4>;
serdes1_mux: mux-controller {
Thanks,
Andrew
> Jan
>
next prev parent reply other threads:[~2024-06-14 16:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-26 18:56 [PATCH 1/2] arm64: dts: ti: k3-am65: Add full compatible to SerDes control nodes Andrew Davis
2024-03-26 18:56 ` [PATCH 2/2] arm64: dts: ti: k3-am65: Move SerDes mux nodes under the control node Andrew Davis
2024-06-14 7:44 ` Jan Kiszka
2024-06-14 16:19 ` Andrew Davis [this message]
2024-06-15 7:35 ` Jan Kiszka
2024-06-24 5:13 ` Jan Kiszka
2024-06-25 16:46 ` Andrew Davis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50327a4a-3653-43d7-88de-2182dc3eb4e7@ti.com \
--to=afd@ti.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jan.kiszka@siemens.com \
--cc=kristo@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nm@ti.com \
--cc=robh+dt@kernel.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).