| Message ID | 20240326185627.29852-2-afd@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] arm64: dts: ti: k3-am65: Add full compatible to SerDes control nodes | expand |
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) Jan
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 >
On 14.06.24 18:19, Andrew Davis wrote: > 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 { > Yes, this works. Jan
On 15.06.24 09:35, Jan Kiszka wrote: > On 14.06.24 18:19, Andrew Davis wrote: >> 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 { >> > > Yes, this works. > Did I miss the real fix, or is it still under development? Jan
On 6/24/24 12:13 AM, Jan Kiszka wrote: > On 15.06.24 09:35, Jan Kiszka wrote: >> On 14.06.24 18:19, Andrew Davis wrote: >>> 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 { >>> >> >> Yes, this works. >> > > Did I miss the real fix, or is it still under development? I was on travel last week, just sent the fix now with you on CC. Andrew > > Jan >
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 {
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(-)