[PATCH 0/5] k3-j721e: beagleboneai: Fix USB
Hi,
This series fixes USB operation on k3-j721e based boards.
CI testing: https://github.com/u-boot/u-boot/pull/468
cheers, -roger
Roger Quadros (5): board: ti: j721e: Drop SERDES PHY init from board file usb: cdns3: avoid error messages if phys don't exist arm: dts: k3-j721e: Fix USB0 operation arm: dts: k3-j721e-beagleboneai64: Fix USB operation configs/j721e_beagleboneai64_a72_defconfig: Enable Sierra PHY
.../dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 + .../k3-j721e-common-proc-board-u-boot.dtsi | 8 ++ arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 8 ++ board/ti/j721e/evm.c | 77 ------------------- configs/j721e_beagleboneai64_a72_defconfig | 2 + drivers/usb/cdns3/core.c | 28 ++++--- 6 files changed, 38 insertions(+), 87 deletions(-)
base-commit: f28a77589e7505535a4eebdc7269df98f67dbe68
Since commit 69b19ca67bcb ("arm: dts: k3-j721e: Sync with v6.6-rc1"), the following error message is seen at u-boot "Sierra init failed:-19"
Probing and initializing the SERDES PHY from board file is not a clean solution so drop it.
Proper use case should be via PHY_UCLASS APIs.
Signed-off-by: Roger Quadros rogerq@kernel.org --- board/ti/j721e/evm.c | 77 -------------------------------------------- 1 file changed, 77 deletions(-)
diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c index c541880107..b77cffc5ef 100644 --- a/board/ti/j721e/evm.c +++ b/board/ti/j721e/evm.c @@ -352,77 +352,6 @@ static int probe_daughtercards(void) } #endif
-void configure_serdes_torrent(void) -{ - struct udevice *dev; - struct phy serdes; - int ret; - - if (!IS_ENABLED(CONFIG_PHY_CADENCE_TORRENT)) - return; - - ret = uclass_get_device_by_driver(UCLASS_PHY, - DM_DRIVER_GET(torrent_phy_provider), - &dev); - if (ret) { - printf("Torrent init failed:%d\n", ret); - return; - } - - serdes.dev = dev; - serdes.id = 0; - - ret = generic_phy_init(&serdes); - if (ret) { - printf("phy_init failed!!: %d\n", ret); - return; - } - - ret = generic_phy_power_on(&serdes); - if (ret) { - printf("phy_power_on failed!!: %d\n", ret); - return; - } -} - -void configure_serdes_sierra(void) -{ - struct udevice *dev, *link_dev; - struct phy link; - int ret, count, i; - int link_count = 0; - - if (!IS_ENABLED(CONFIG_PHY_CADENCE_SIERRA)) - return; - - ret = uclass_get_device_by_driver(UCLASS_MISC, - DM_DRIVER_GET(sierra_phy_provider), - &dev); - if (ret) { - printf("Sierra init failed:%d\n", ret); - return; - } - - count = device_get_child_count(dev); - for (i = 0; i < count; i++) { - ret = device_get_child(dev, i, &link_dev); - if (ret) { - printf("probe of sierra child node %d failed: %d\n", i, ret); - return; - } - if (link_dev->driver->id == UCLASS_PHY) { - link.dev = link_dev; - link.id = link_count++; - - ret = generic_phy_power_on(&link); - if (ret) { - printf("phy_power_on failed!!: %d\n", ret); - return; - } - } - } -} - #ifdef CONFIG_BOARD_LATE_INIT static void setup_board_eeprom_env(void) { @@ -476,12 +405,6 @@ int board_late_init(void) probe_daughtercards(); }
- if (board_is_j7200_som()) - configure_serdes_torrent(); - - if (board_is_j721e_som()) - configure_serdes_sierra(); - return 0; } #endif
The phys property is optional so don't complain if it doesn't exist in device tree.
Signed-off-by: Roger Quadros rogerq@kernel.org --- drivers/usb/cdns3/core.c | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c index 644a9791b9..12a741c6ea 100644 --- a/drivers/usb/cdns3/core.c +++ b/drivers/usb/cdns3/core.c @@ -333,20 +333,28 @@ static int cdns3_probe(struct cdns3 *cdns) mutex_init(&cdns->mutex);
ret = generic_phy_get_by_name(dev, "cdns3,usb2-phy", &cdns->usb2_phy); - if (ret) - dev_warn(dev, "Unable to get USB2 phy (ret %d)\n", ret); - - ret = generic_phy_init(&cdns->usb2_phy); - if (ret) + if (!ret) { + ret = generic_phy_init(&cdns->usb2_phy); + if (ret) { + dev_err(dev, "USB2 PHY init failed: %d\n", ret); + return ret; + } + } else if (ret != -ENOENT && ret != -ENODATA) { + dev_err(dev, "Couldn't get USB2 PHY: %d\n", ret); return ret; + }
ret = generic_phy_get_by_name(dev, "cdns3,usb3-phy", &cdns->usb3_phy); - if (ret) - dev_warn(dev, "Unable to get USB3 phy (ret %d)\n", ret); - - ret = generic_phy_init(&cdns->usb3_phy); - if (ret) + if (!ret) { + ret = generic_phy_init(&cdns->usb3_phy); + if (ret) { + dev_err(dev, "USB3 PHY init failed: %d\n", ret); + return ret; + } + } else if (ret != -ENOENT && ret != -ENODATA) { + dev_err(dev, "Couldn't get USB3 PHY: %d\n", ret); return ret; + }
ret = generic_phy_power_on(&cdns->usb2_phy); if (ret)
Without correct SERDES MUX and Lane control settings USB0 will be broken. Set the MUX and Lane control devices to be auto probed so they are configured correctly.
Fixes: 69b19ca67bcb ("arm: dts: k3-j721e: Sync with v6.6-rc1") Signed-off-by: Roger Quadros rogerq@kernel.org --- arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 8 ++++++++ arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 8 ++++++++ 2 files changed, 16 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi index b77f8d92de..7ae7cf3d4c 100644 --- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi +++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi @@ -93,6 +93,14 @@ bootph-all; };
+&serdes_ln_ctrl { + u-boot,mux-autoprobe; +}; + +&usb_serdes_mux { + u-boot,mux-autoprobe; +}; + &main_usbss0_pins_default { bootph-all; }; diff --git a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi index 370fe5190b..479b7bcd6f 100644 --- a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi +++ b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi @@ -89,6 +89,14 @@ bootph-all; };
+&serdes_ln_ctrl { + u-boot,mux-autoprobe; +}; + +&usb_serdes_mux { + u-boot,mux-autoprobe; +}; + &main_usbss0_pins_default { bootph-all; };
Without correct SERDES MUX and Lane control settings USB0 will be broken. Set the MUX and Lane control devices to be auto probed so they are configured correctly.
Signed-off-by: Roger Quadros rogerq@kernel.org --- arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi index f83caf7998..017a5a722e 100644 --- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi +++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi @@ -165,6 +165,7 @@
&serdes_ln_ctrl { bootph-all; + u-boot,mux-autoprobe; };
&serdes2_usb_link { @@ -173,6 +174,7 @@
&usb_serdes_mux { bootph-all; + u-boot,mux-autoprobe; };
&serdes_wiz2 {
On 14:49-20240112, Roger Quadros wrote:
Without correct SERDES MUX and Lane control settings USB0 will be broken. Set the MUX and Lane control devices to be auto probed so they are configured correctly.
Signed-off-by: Roger Quadros rogerq@kernel.org
arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi index f83caf7998..017a5a722e 100644 --- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi +++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi @@ -165,6 +165,7 @@
&serdes_ln_ctrl { bootph-all;
- u-boot,mux-autoprobe;
};
&serdes2_usb_link { @@ -173,6 +174,7 @@
&usb_serdes_mux { bootph-all;
- u-boot,mux-autoprobe;
};
&serdes_wiz2 {
2.34.1
Is this a u-boot thing? or a driver limitation?
On 12/01/2024 15:02, Nishanth Menon wrote:
On 14:49-20240112, Roger Quadros wrote:
Without correct SERDES MUX and Lane control settings USB0 will be broken. Set the MUX and Lane control devices to be auto probed so they are configured correctly.
Signed-off-by: Roger Quadros rogerq@kernel.org
arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi index f83caf7998..017a5a722e 100644 --- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi +++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi @@ -165,6 +165,7 @@
&serdes_ln_ctrl { bootph-all;
- u-boot,mux-autoprobe;
};
&serdes2_usb_link { @@ -173,6 +174,7 @@
&usb_serdes_mux { bootph-all;
- u-boot,mux-autoprobe;
};
&serdes_wiz2 {
2.34.1
Is this a u-boot thing? or a driver limitation?
u-boot specific. We just want the mux driver to probe and apply the settings.
from drivers/mux/mux-uclass.c
int dm_mux_init(void) { struct uclass *uc; struct udevice *dev; int ret;
ret = uclass_get(UCLASS_MUX, &uc); if (ret < 0) { log_debug("unable to get MUX uclass\n"); return ret; } uclass_foreach_dev(dev, uc) { if (dev_read_bool(dev, "u-boot,mux-autoprobe")) { ret = device_probe(dev); if (ret) log_debug("unable to probe device %s\n", dev->name); } }
return 0; }
On 15:06-20240112, Roger Quadros wrote:
On 12/01/2024 15:02, Nishanth Menon wrote:
On 14:49-20240112, Roger Quadros wrote:
Without correct SERDES MUX and Lane control settings USB0 will be broken. Set the MUX and Lane control devices to be auto probed so they are configured correctly.
Signed-off-by: Roger Quadros rogerq@kernel.org
arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi index f83caf7998..017a5a722e 100644 --- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi +++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi @@ -165,6 +165,7 @@
&serdes_ln_ctrl { bootph-all;
- u-boot,mux-autoprobe;
};
&serdes2_usb_link { @@ -173,6 +174,7 @@
&usb_serdes_mux { bootph-all;
- u-boot,mux-autoprobe;
};
&serdes_wiz2 {
2.34.1
Is this a u-boot thing? or a driver limitation?
u-boot specific. We just want the mux driver to probe and apply the settings.
from drivers/mux/mux-uclass.c
int dm_mux_init(void) { struct uclass *uc; struct udevice *dev; int ret;
ret = uclass_get(UCLASS_MUX, &uc); if (ret < 0) { log_debug("unable to get MUX uclass\n"); return ret; } uclass_foreach_dev(dev, uc) { if (dev_read_bool(dev, "u-boot,mux-autoprobe")) { ret = device_probe(dev); if (ret) log_debug("unable to probe device %s\n", dev->name); } } return 0;}
Uggh.. We need to see eventually how to get rid of this. This makes https://lore.kernel.org/u-boot/20240110103547.719757-1-sumit.garg@linaro.org... harder now?
On Fri, Jan 12, 2024 at 07:14:50AM -0600, Nishanth Menon wrote:
On 15:06-20240112, Roger Quadros wrote:
On 12/01/2024 15:02, Nishanth Menon wrote:
On 14:49-20240112, Roger Quadros wrote:
Without correct SERDES MUX and Lane control settings USB0 will be broken. Set the MUX and Lane control devices to be auto probed so they are configured correctly.
Signed-off-by: Roger Quadros rogerq@kernel.org
arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi index f83caf7998..017a5a722e 100644 --- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi +++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi @@ -165,6 +165,7 @@
&serdes_ln_ctrl { bootph-all;
- u-boot,mux-autoprobe;
};
&serdes2_usb_link { @@ -173,6 +174,7 @@
&usb_serdes_mux { bootph-all;
- u-boot,mux-autoprobe;
};
&serdes_wiz2 {
OK, so both of these are compatible = "mmio-mux", is the problem they aren't probed in time or something else?
-- 2.34.1
Is this a u-boot thing? or a driver limitation?
u-boot specific. We just want the mux driver to probe and apply the settings.
from drivers/mux/mux-uclass.c
int dm_mux_init(void) { struct uclass *uc; struct udevice *dev; int ret;
ret = uclass_get(UCLASS_MUX, &uc); if (ret < 0) { log_debug("unable to get MUX uclass\n"); return ret; } uclass_foreach_dev(dev, uc) { if (dev_read_bool(dev, "u-boot,mux-autoprobe")) { ret = device_probe(dev); if (ret) log_debug("unable to probe device %s\n", dev->name); } } return 0;}
Uggh.. We need to see eventually how to get rid of this. This makes https://lore.kernel.org/u-boot/20240110103547.719757-1-sumit.garg@linaro.org... harder now?
No, it should be fine, Sumit's series handles -u-boot.dtsi files.
On 12/01/2024 15:21, Tom Rini wrote:
On Fri, Jan 12, 2024 at 07:14:50AM -0600, Nishanth Menon wrote:
On 15:06-20240112, Roger Quadros wrote:
On 12/01/2024 15:02, Nishanth Menon wrote:
On 14:49-20240112, Roger Quadros wrote:
Without correct SERDES MUX and Lane control settings USB0 will be broken. Set the MUX and Lane control devices to be auto probed so they are configured correctly.
Signed-off-by: Roger Quadros rogerq@kernel.org
arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi index f83caf7998..017a5a722e 100644 --- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi +++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi @@ -165,6 +165,7 @@
&serdes_ln_ctrl { bootph-all;
- u-boot,mux-autoprobe;
};
&serdes2_usb_link { @@ -173,6 +174,7 @@
&usb_serdes_mux { bootph-all;
- u-boot,mux-autoprobe;
};
&serdes_wiz2 {
OK, so both of these are compatible = "mmio-mux", is the problem they aren't probed in time or something else?
That's correct. They aren't probed ever. But that is because there are no explicit consumers for them. Since this is a platform wide configuration, we have been relying on the "idle-states" property and that they are auto-probed.
-- 2.34.1
Is this a u-boot thing? or a driver limitation?
u-boot specific. We just want the mux driver to probe and apply the settings.
from drivers/mux/mux-uclass.c
int dm_mux_init(void) { struct uclass *uc; struct udevice *dev; int ret;
ret = uclass_get(UCLASS_MUX, &uc); if (ret < 0) { log_debug("unable to get MUX uclass\n"); return ret; } uclass_foreach_dev(dev, uc) { if (dev_read_bool(dev, "u-boot,mux-autoprobe")) { ret = device_probe(dev); if (ret) log_debug("unable to probe device %s\n", dev->name); } } return 0;}
Uggh.. We need to see eventually how to get rid of this. This makes https://lore.kernel.org/u-boot/20240110103547.719757-1-sumit.garg@linaro.org... harder now?
No, it should be fine, Sumit's series handles -u-boot.dtsi files.
On Mon, Jan 15, 2024 at 01:40:00PM +0200, Roger Quadros wrote:
On 12/01/2024 15:21, Tom Rini wrote:
On Fri, Jan 12, 2024 at 07:14:50AM -0600, Nishanth Menon wrote:
On 15:06-20240112, Roger Quadros wrote:
On 12/01/2024 15:02, Nishanth Menon wrote:
On 14:49-20240112, Roger Quadros wrote:
Without correct SERDES MUX and Lane control settings USB0 will be broken. Set the MUX and Lane control devices to be auto probed so they are configured correctly.
Signed-off-by: Roger Quadros rogerq@kernel.org
arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi index f83caf7998..017a5a722e 100644 --- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi +++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi @@ -165,6 +165,7 @@
&serdes_ln_ctrl { bootph-all;
- u-boot,mux-autoprobe;
};
&serdes2_usb_link { @@ -173,6 +174,7 @@
&usb_serdes_mux { bootph-all;
- u-boot,mux-autoprobe;
};
&serdes_wiz2 {
OK, so both of these are compatible = "mmio-mux", is the problem they aren't probed in time or something else?
That's correct. They aren't probed ever. But that is because there are no explicit consumers for them. Since this is a platform wide configuration, we have been relying on the "idle-states" property and that they are auto-probed.
OK. Could we borrow the "wrap" logic that drivers/led/led_gpio.c for example does to get the probe to happen inside drivers/mux/mmio.c instead? I feel like there might have been assumptions about grander needs back when the framework for muxers was done that has not panned out since.
On 20/01/2024 18:50, Tom Rini wrote:
On Mon, Jan 15, 2024 at 01:40:00PM +0200, Roger Quadros wrote:
On 12/01/2024 15:21, Tom Rini wrote:
On Fri, Jan 12, 2024 at 07:14:50AM -0600, Nishanth Menon wrote:
On 15:06-20240112, Roger Quadros wrote:
On 12/01/2024 15:02, Nishanth Menon wrote:
On 14:49-20240112, Roger Quadros wrote: > Without correct SERDES MUX and Lane control settings > USB0 will be broken. Set the MUX and Lane control devices > to be auto probed so they are configured correctly. > > Signed-off-by: Roger Quadros rogerq@kernel.org > --- > arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi > index f83caf7998..017a5a722e 100644 > --- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi > +++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi > @@ -165,6 +165,7 @@ > > &serdes_ln_ctrl { > bootph-all; > + u-boot,mux-autoprobe; > }; > > &serdes2_usb_link { > @@ -173,6 +174,7 @@ > > &usb_serdes_mux { > bootph-all; > + u-boot,mux-autoprobe; > }; > > &serdes_wiz2 {
OK, so both of these are compatible = "mmio-mux", is the problem they aren't probed in time or something else?
That's correct. They aren't probed ever. But that is because there are no explicit consumers for them. Since this is a platform wide configuration, we have been relying on the "idle-states" property and that they are auto-probed.
OK. Could we borrow the "wrap" logic that drivers/led/led_gpio.c for example does to get the probe to happen inside drivers/mux/mmio.c instead? I feel like there might have been assumptions about grander needs back when the framework for muxers was done that has not panned out since.
We only need the MUX driver to probe if the MUX node contains the "idle-states" property.
So maybe the MUX UCLASS code should be checking for that instead of/along with the custom u-boot,mux-autoprobe property?
How does this look?
diff --git a/drivers/mux/mux-uclass.c b/drivers/mux/mux-uclass.c index c98576ceb8..8833888ded 100644 --- a/drivers/mux/mux-uclass.c +++ b/drivers/mux/mux-uclass.c @@ -318,7 +318,8 @@ int dm_mux_init(void) return ret; } uclass_foreach_dev(dev, uc) { - if (dev_read_bool(dev, "u-boot,mux-autoprobe")) { + if (dev_read_bool(dev, "u-boot,mux-autoprobe") || + dev_read_bool(dev, "idle-states")) { ret = device_probe(dev); if (ret) log_debug("unable to probe device %s\n",
On Mon, Jan 22, 2024 at 01:39:06PM +0200, Roger Quadros wrote:
On 20/01/2024 18:50, Tom Rini wrote:
On Mon, Jan 15, 2024 at 01:40:00PM +0200, Roger Quadros wrote:
On 12/01/2024 15:21, Tom Rini wrote:
On Fri, Jan 12, 2024 at 07:14:50AM -0600, Nishanth Menon wrote:
On 15:06-20240112, Roger Quadros wrote:
On 12/01/2024 15:02, Nishanth Menon wrote: > On 14:49-20240112, Roger Quadros wrote: >> Without correct SERDES MUX and Lane control settings >> USB0 will be broken. Set the MUX and Lane control devices >> to be auto probed so they are configured correctly. >> >> Signed-off-by: Roger Quadros rogerq@kernel.org >> --- >> arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi >> index f83caf7998..017a5a722e 100644 >> --- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi >> +++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi >> @@ -165,6 +165,7 @@ >> >> &serdes_ln_ctrl { >> bootph-all; >> + u-boot,mux-autoprobe; >> }; >> >> &serdes2_usb_link { >> @@ -173,6 +174,7 @@ >> >> &usb_serdes_mux { >> bootph-all; >> + u-boot,mux-autoprobe; >> }; >> >> &serdes_wiz2 {
OK, so both of these are compatible = "mmio-mux", is the problem they aren't probed in time or something else?
That's correct. They aren't probed ever. But that is because there are no explicit consumers for them. Since this is a platform wide configuration, we have been relying on the "idle-states" property and that they are auto-probed.
OK. Could we borrow the "wrap" logic that drivers/led/led_gpio.c for example does to get the probe to happen inside drivers/mux/mmio.c instead? I feel like there might have been assumptions about grander needs back when the framework for muxers was done that has not panned out since.
We only need the MUX driver to probe if the MUX node contains the "idle-states" property.
So maybe the MUX UCLASS code should be checking for that instead of/along with the custom u-boot,mux-autoprobe property?
How does this look?
diff --git a/drivers/mux/mux-uclass.c b/drivers/mux/mux-uclass.c index c98576ceb8..8833888ded 100644 --- a/drivers/mux/mux-uclass.c +++ b/drivers/mux/mux-uclass.c @@ -318,7 +318,8 @@ int dm_mux_init(void) return ret; } uclass_foreach_dev(dev, uc) {
if (dev_read_bool(dev, "u-boot,mux-autoprobe")) {
if (dev_read_bool(dev, "u-boot,mux-autoprobe") ||dev_read_bool(dev, "idle-states")) { ret = device_probe(dev); if (ret) log_debug("unable to probe device %s\n",
I would just drop "u-boot,mux-autoprobe" as TI platforms are the only users of this uclass and mmio driver, iirc.
This is required for USB Super-Speed operation.
Signed-off-by: Roger Quadros rogerq@kernel.org --- configs/j721e_beagleboneai64_a72_defconfig | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/configs/j721e_beagleboneai64_a72_defconfig b/configs/j721e_beagleboneai64_a72_defconfig index 959f86844d..f66206f6e3 100644 --- a/configs/j721e_beagleboneai64_a72_defconfig +++ b/configs/j721e_beagleboneai64_a72_defconfig @@ -127,6 +127,8 @@ CONFIG_PHY_TI_DP83867=y CONFIG_PHY_FIXED=y CONFIG_TI_AM65_CPSW_NUSS=y CONFIG_PHY=y +CONFIG_PHY_J721E_WIZ=y +CONFIG_PHY_CADENCE_SIERRA=y CONFIG_SPL_PHY=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set
On Fri, 12 Jan 2024 14:49:46 +0200, Roger Quadros wrote:
This series fixes USB operation on k3-j721e based boards.
CI testing: https://github.com/u-boot/u-boot/pull/468
cheers, -roger
[...]
Applied to u-boot/master, thanks!
participants (3)
-
Nishanth Menon -
Roger Quadros -
Tom Rini