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
