Re: [PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation
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
> >>> ---
> >>> 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 @@
> >>>
> >>> _ln_ctrl {
> >>> bootph-all;
> >>> + u-boot,mux-autoprobe;
> >>> };
> >>>
> >>> _usb_link {
> >>> @@ -173,6 +174,7 @@
> >>>
> >>> _serdes_mux {
> >>> bootph-all;
> >>> + u-boot,mux-autoprobe;
> >>> };
> >>>
> >>> _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
Re: [PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation
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
>>> ---
>>> 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 @@
>>>
>>> _ln_ctrl {
>>> bootph-all;
>>> + u-boot,mux-autoprobe;
>>> };
>>>
>>> _usb_link {
>>> @@ -173,6 +174,7 @@
>>>
>>> _serdes_mux {
>>> bootph-all;
>>> + u-boot,mux-autoprobe;
>>> };
>>>
>>> _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",
--
cheers,
-roger
Re: [PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation
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
> > ---
> > 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 @@
> >
> > _ln_ctrl {
> > bootph-all;
> > + u-boot,mux-autoprobe;
> > };
> >
> > _usb_link {
> > @@ -173,6 +174,7 @@
> >
> > _serdes_mux {
> > bootph-all;
> > + u-boot,mux-autoprobe;
> > };
> >
> > _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.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation
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
> ---
> 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 @@
>
> _ln_ctrl {
> bootph-all;
> + u-boot,mux-autoprobe;
> };
>
> _usb_link {
> @@ -173,6 +174,7 @@
>
> _serdes_mux {
> bootph-all;
> + u-boot,mux-autoprobe;
> };
>
> _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, );
>>> 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.g...@linaro.org/#t
>> harder now?
>
> No, it should be fine, Sumit's series handles -u-boot.dtsi files.
>
--
cheers,
-roger
Re: [PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation
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
> > >> ---
> > >> 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 @@
> > >>
> > >> _ln_ctrl {
> > >> bootph-all;
> > >> +u-boot,mux-autoprobe;
> > >> };
> > >>
> > >> _usb_link {
> > >> @@ -173,6 +174,7 @@
> > >>
> > >> _serdes_mux {
> > >> bootph-all;
> > >> +u-boot,mux-autoprobe;
> > >> };
> > >>
> > >> _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, );
> > 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.g...@linaro.org/#t
> harder now?
No, it should be fine, Sumit's series handles -u-boot.dtsi files.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation
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
> >> ---
> >> 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 @@
> >>
> >> _ln_ctrl {
> >>bootph-all;
> >> + u-boot,mux-autoprobe;
> >> };
> >>
> >> _usb_link {
> >> @@ -173,6 +174,7 @@
> >>
> >> _serdes_mux {
> >>bootph-all;
> >> + u-boot,mux-autoprobe;
> >> };
> >>
> >> _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, );
> 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.g...@linaro.org/#t
harder now?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation
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
>> ---
>> 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 @@
>>
>> _ln_ctrl {
>> bootph-all;
>> +u-boot,mux-autoprobe;
>> };
>>
>> _usb_link {
>> @@ -173,6 +174,7 @@
>>
>> _serdes_mux {
>> bootph-all;
>> +u-boot,mux-autoprobe;
>> };
>>
>> _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, );
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;
}
--
cheers,
-roger
Re: [PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation
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
> ---
> 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 @@
>
> _ln_ctrl {
> bootph-all;
> + u-boot,mux-autoprobe;
> };
>
> _usb_link {
> @@ -173,6 +174,7 @@
>
> _serdes_mux {
> bootph-all;
> + u-boot,mux-autoprobe;
> };
>
> _wiz2 {
> --
> 2.34.1
>
Is this a u-boot thing? or a driver limitation?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
[PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation
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
---
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 @@
_ln_ctrl {
bootph-all;
+ u-boot,mux-autoprobe;
};
_usb_link {
@@ -173,6 +174,7 @@
_serdes_mux {
bootph-all;
+ u-boot,mux-autoprobe;
};
_wiz2 {
--
2.34.1
