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.
>>>>> --
>>>>> 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.g...@linaro.org/#t
>> harder now?
>
> No, it should be fine, Sumit's series handles -u-boot.dtsi files.
>
--
cheers,
-roger
