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 <rog...@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
signature.asc
Description: PGP signature
