[PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation

[Tom Rini]

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 at 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240122/71eaad7a/attachment.sig>