musb is broken in master

musb is broken in master

[Yegor Yefremov]

I have bisected the musb driver on am335x (baltos system
arch/arm/dts/am335x-baltos-minimal.dts) from v2019.11.0 and this is
the result:

574eed3f6fcf056aa4c9e46c4b5224e3f7844d8d is the first bad commit
commit 574eed3f6fcf056aa4c9e46c4b5224e3f7844d8d
Author: Sascha Hauer <s.hauer@pengutronix.de>
Date:   Thu Dec 19 05:46:54 2019 +0100

    dts: update to v5.5-rc1

    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

:040000 040000 4f6416a5af14d6328ef2c8ac46d9ac4a17a37404
525e33dda1e735ef2f633f4d99c501ba938a7263 M      dts

I need only the host functionality to mount a USB drive. My defconfig
can be found here [1].

Any idea what could have happened?

[1] https://github.com/visionsystemsgmbh/onrisc_br_bsp/blob/master/board/vscom/baltos/barebox/am335x_baltos_defconfig

Thanks.

Cheers,
Yegor

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: musb is broken in master

[Ahmad Fatoum]

Hello Yegor,

On 2/18/20 10:58 AM, Yegor Yefremov wrote:
> I have bisected the musb driver on am335x (baltos system
> arch/arm/dts/am335x-baltos-minimal.dts) from v2019.11.0 and this is
> the result:
> 
> 574eed3f6fcf056aa4c9e46c4b5224e3f7844d8d is the first bad commit
> commit 574eed3f6fcf056aa4c9e46c4b5224e3f7844d8d
> Author: Sascha Hauer <s.hauer@pengutronix.de>
> Date:   Thu Dec 19 05:46:54 2019 +0100
> 
>     dts: update to v5.5-rc1
> 
>     Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> 
> :040000 040000 4f6416a5af14d6328ef2c8ac46d9ac4a17a37404
> 525e33dda1e735ef2f633f4d99c501ba938a7263 M      dts
> 
> I need only the host functionality to mount a USB drive. My defconfig
> can be found here [1].
> 
> Any idea what could have happened?

git log v5.4..v5.5-rc1 arch/arm/boot/dts/am335x*.dtsi
gives me kernel commit 12afc0cf81 ("ARM: dts: Drop pointless status changing for am3 musb").
Does reverting it fix the issue for you?

> 
> [1] https://github.com/visionsystemsgmbh/onrisc_br_bsp/blob/master/board/vscom/baltos/barebox/am335x_baltos_defconfig
> 
> Thanks.
> 
> Cheers,
> Yegor
> 
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: musb is broken in master

[Yegor Yefremov]

Hello Ahmad,

On Tue, Feb 18, 2020 at 11:57 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> Hello Yegor,
>
> On 2/18/20 10:58 AM, Yegor Yefremov wrote:
> > I have bisected the musb driver on am335x (baltos system
> > arch/arm/dts/am335x-baltos-minimal.dts) from v2019.11.0 and this is
> > the result:
> >
> > 574eed3f6fcf056aa4c9e46c4b5224e3f7844d8d is the first bad commit
> > commit 574eed3f6fcf056aa4c9e46c4b5224e3f7844d8d
> > Author: Sascha Hauer <s.hauer@pengutronix.de>
> > Date:   Thu Dec 19 05:46:54 2019 +0100
> >
> >     dts: update to v5.5-rc1
> >
> >     Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> >
> > :040000 040000 4f6416a5af14d6328ef2c8ac46d9ac4a17a37404
> > 525e33dda1e735ef2f633f4d99c501ba938a7263 M      dts
> >
> > I need only the host functionality to mount a USB drive. My defconfig
> > can be found here [1].
> >
> > Any idea what could have happened?
>
> git log v5.4..v5.5-rc1 arch/arm/boot/dts/am335x*.dtsi
> gives me kernel commit 12afc0cf81 ("ARM: dts: Drop pointless status changing for am3 musb").
> Does reverting it fix the issue for you?

Yes, it does. Though the revert result is a little bit ugly i.e. at
least one conflict.

But when I start the kernel 5.6-rc2 that already incorporates these
DTS changes, I have no problems with USB. So far only the barebox is
affected by this change.

Cheers,
Yegor

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: musb is broken in master

[Ahmad Fatoum]

On 2/18/20 12:19 PM, Yegor Yefremov wrote:
> Hello Ahmad,
> 
> On Tue, Feb 18, 2020 at 11:57 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>
>> Hello Yegor,
>>
>> On 2/18/20 10:58 AM, Yegor Yefremov wrote:
>>> I have bisected the musb driver on am335x (baltos system
>>> arch/arm/dts/am335x-baltos-minimal.dts) from v2019.11.0 and this is
>>> the result:
>>>
>>> 574eed3f6fcf056aa4c9e46c4b5224e3f7844d8d is the first bad commit
>>> commit 574eed3f6fcf056aa4c9e46c4b5224e3f7844d8d
>>> Author: Sascha Hauer <s.hauer@pengutronix.de>
>>> Date:   Thu Dec 19 05:46:54 2019 +0100
>>>
>>>     dts: update to v5.5-rc1
>>>
>>>     Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>>
>>> :040000 040000 4f6416a5af14d6328ef2c8ac46d9ac4a17a37404
>>> 525e33dda1e735ef2f633f4d99c501ba938a7263 M      dts
>>>
>>> I need only the host functionality to mount a USB drive. My defconfig
>>> can be found here [1].
>>>
>>> Any idea what could have happened?
>>
>> git log v5.4..v5.5-rc1 arch/arm/boot/dts/am335x*.dtsi
>> gives me kernel commit 12afc0cf81 ("ARM: dts: Drop pointless status changing for am3 musb").
>> Does reverting it fix the issue for you?
> 
> Yes, it does. Though the revert result is a little bit ugly i.e. at
> least one conflict.

yes, it's not meant as permanent solution.
Which status = "okay" is the one that 'fixes' it?
 
> But when I start the kernel 5.6-rc2 that already incorporates these
> DTS changes, I have no problems with USB. So far only the barebox is
> affected by this change.

Possibly a device driver in barebox for the now-disabled peripheral
turns on a clock, enables a regulator, toggles a reset or initializes
some register that also affects the USB working at all.

Best course of action would be to check which driver it is, check whether
Linux uses it, comment out stuff to find what the magic sauce is that
the driver does and add that to the driver that misses it.

(sometimes it's just that the device tree binding changed. In that case,
you can either patch in a missing property in arch/arm/dts or patch
barebox drivers to accept the new binding as well)

Cheers
Ahmad

> 
> Cheers,
> Yegor
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: musb is broken in master

[Yegor Yefremov]

Hi Ahmad, all,

On Tue, Feb 18, 2020 at 12:48 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> On 2/18/20 12:19 PM, Yegor Yefremov wrote:
> > Hello Ahmad,
> >
> > On Tue, Feb 18, 2020 at 11:57 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >>
> >> Hello Yegor,
> >>
> >> On 2/18/20 10:58 AM, Yegor Yefremov wrote:
> >>> I have bisected the musb driver on am335x (baltos system
> >>> arch/arm/dts/am335x-baltos-minimal.dts) from v2019.11.0 and this is
> >>> the result:
> >>>
> >>> 574eed3f6fcf056aa4c9e46c4b5224e3f7844d8d is the first bad commit
> >>> commit 574eed3f6fcf056aa4c9e46c4b5224e3f7844d8d
> >>> Author: Sascha Hauer <s.hauer@pengutronix.de>
> >>> Date:   Thu Dec 19 05:46:54 2019 +0100
> >>>
> >>>     dts: update to v5.5-rc1
> >>>
> >>>     Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> >>>
> >>> :040000 040000 4f6416a5af14d6328ef2c8ac46d9ac4a17a37404
> >>> 525e33dda1e735ef2f633f4d99c501ba938a7263 M      dts
> >>>
> >>> I need only the host functionality to mount a USB drive. My defconfig
> >>> can be found here [1].
> >>>
> >>> Any idea what could have happened?
> >>
> >> git log v5.4..v5.5-rc1 arch/arm/boot/dts/am335x*.dtsi
> >> gives me kernel commit 12afc0cf81 ("ARM: dts: Drop pointless status changing for am3 musb").
> >> Does reverting it fix the issue for you?
> >
> > Yes, it does. Though the revert result is a little bit ugly i.e. at
> > least one conflict.
>
> yes, it's not meant as permanent solution.
> Which status = "okay" is the one that 'fixes' it?
>
> > But when I start the kernel 5.6-rc2 that already incorporates these
> > DTS changes, I have no problems with USB. So far only the barebox is
> > affected by this change.
>
> Possibly a device driver in barebox for the now-disabled peripheral
> turns on a clock, enables a regulator, toggles a reset or initializes
> some register that also affects the USB working at all.
>
> Best course of action would be to check which driver it is, check whether
> Linux uses it, comment out stuff to find what the magic sauce is that
> the driver does and add that to the driver that misses it.
>
> (sometimes it's just that the device tree binding changed. In that case,
> you can either patch in a missing property in arch/arm/dts or patch
> barebox drivers to accept the new binding as well)

Can it be that musb was broken because of this change in the mainline
linux kernel [1]?

The kernel uses ti-sysc mechanism to get/configure the related hw
blocks. If I grep for ti-sysc in kernel, I get a lot of hits. But in
barebox, it is only drivers/bus/ti-sysc.c that I find. Seems like a
rather big update is required.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am33xx.dtsi?h=v5.6-rc3&id=0782e8572ce43f521ed6ff15e4a7ab9aa5acdc85

Yegor

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: musb is broken in master

[Ahmad Fatoum]

Hi,

On 2/24/20 12:09 PM, Yegor Yefremov wrote:
> Can it be that musb was broken because of this change in the mainline
> linux kernel [1]?

But you said that it works when you readd status = "okay" to some
of the USB device tree nodes? Which node was it in particular?

> The kernel uses ti-sysc mechanism to get/configure the related hw
> blocks. If I grep for ti-sysc in kernel, I get a lot of hits. But in
> barebox, it is only drivers/bus/ti-sysc.c that I find. Seems like a
> rather big update is required.
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am33xx.dtsi?h=v5.6-rc3&id=0782e8572ce43f521ed6ff15e4a7ab9aa5acdc85

I don't think that's the problem. Looks to me like it should work with
barebox as well. Or did you revert this patch and got USB working again?

Cheers
Ahmad

> 
> Yegor
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: musb is broken in master

[Yegor Yefremov]

On Mon, Feb 24, 2020 at 12:50 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> Hi,
>
> On 2/24/20 12:09 PM, Yegor Yefremov wrote:
> > Can it be that musb was broken because of this change in the mainline
> > linux kernel [1]?
>
> But you said that it works when you readd status = "okay" to some
> of the USB device tree nodes? Which node was it in particular?
>
> > The kernel uses ti-sysc mechanism to get/configure the related hw
> > blocks. If I grep for ti-sysc in kernel, I get a lot of hits. But in
> > barebox, it is only drivers/bus/ti-sysc.c that I find. Seems like a
> > rather big update is required.
> >
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am33xx.dtsi?h=v5.6-rc3&id=0782e8572ce43f521ed6ff15e4a7ab9aa5acdc85
>
> I don't think that's the problem. Looks to me like it should work with
> barebox as well. Or did you revert this patch and got USB working again?

Yes, I just reverted the whole patch and got USB working again. It has
nothing to do with my dts file as it is hosted only in barebox
(arch/arm/dts/am335x-baltos-minimal.dts). It just includes the common
DTS files like am33xx.dtsi.

Yegor

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: musb is broken in master

[Yegor Yefremov]

On Mon, Feb 24, 2020 at 12:54 PM Yegor Yefremov
<yegorslists@googlemail.com> wrote:
>
> On Mon, Feb 24, 2020 at 12:50 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >
> > Hi,
> >
> > On 2/24/20 12:09 PM, Yegor Yefremov wrote:
> > > Can it be that musb was broken because of this change in the mainline
> > > linux kernel [1]?
> >
> > But you said that it works when you readd status = "okay" to some
> > of the USB device tree nodes? Which node was it in particular?
> >
> > > The kernel uses ti-sysc mechanism to get/configure the related hw
> > > blocks. If I grep for ti-sysc in kernel, I get a lot of hits. But in
> > > barebox, it is only drivers/bus/ti-sysc.c that I find. Seems like a
> > > rather big update is required.
> > >
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am33xx.dtsi?h=v5.6-rc3&id=0782e8572ce43f521ed6ff15e4a7ab9aa5acdc85
> >
> > I don't think that's the problem. Looks to me like it should work with
> > barebox as well. Or did you revert this patch and got USB working again?
>
> Yes, I just reverted the whole patch and got USB working again. It has
> nothing to do with my dts file as it is hosted only in barebox
> (arch/arm/dts/am335x-baltos-minimal.dts). It just includes the common
> DTS files like am33xx.dtsi.

I mean, I have reverted only this one 574eed3f6fcf056aa4c9e46c4b5224e3f7844d8d.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: musb is broken in master

[Ahmad Fatoum]

On 2/24/20 12:55 PM, Yegor Yefremov wrote:
> On Mon, Feb 24, 2020 at 12:54 PM Yegor Yefremov
> <yegorslists@googlemail.com> wrote:
>>
>> On Mon, Feb 24, 2020 at 12:50 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>>
>>> Hi,
>>>
>>> On 2/24/20 12:09 PM, Yegor Yefremov wrote:
>>>> Can it be that musb was broken because of this change in the mainline
>>>> linux kernel [1]?
>>>
>>> But you said that it works when you readd status = "okay" to some
>>> of the USB device tree nodes? Which node was it in particular?
>>>
>>>> The kernel uses ti-sysc mechanism to get/configure the related hw
>>>> blocks. If I grep for ti-sysc in kernel, I get a lot of hits. But in
>>>> barebox, it is only drivers/bus/ti-sysc.c that I find. Seems like a
>>>> rather big update is required.
>>>>
>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am33xx.dtsi?h=v5.6-rc3&id=0782e8572ce43f521ed6ff15e4a7ab9aa5acdc85
>>>
>>> I don't think that's the problem. Looks to me like it should work with
>>> barebox as well. Or did you revert this patch and got USB working again?
>>
>> Yes, I just reverted the whole patch and got USB working again. It has
>> nothing to do with my dts file as it is hosted only in barebox
>> (arch/arm/dts/am335x-baltos-minimal.dts). It just includes the common
>> DTS files like am33xx.dtsi.
> 
> I mean, I have reverted only this one 574eed3f6fcf056aa4c9e46c4b5224e3f7844d8d.

I meant that you revert the upstream device tree patch only. Either manually or by doing
some temporary hack like symlink $BAREBOX/dts/src/arm to $LINUX/arch/arm/boot/dts
and revert inside the kernel git tree.


> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: musb is broken in master

[Yegor Yefremov]

On Mon, Feb 24, 2020 at 1:02 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> On 2/24/20 12:55 PM, Yegor Yefremov wrote:
> > On Mon, Feb 24, 2020 at 12:54 PM Yegor Yefremov
> > <yegorslists@googlemail.com> wrote:
> >>
> >> On Mon, Feb 24, 2020 at 12:50 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On 2/24/20 12:09 PM, Yegor Yefremov wrote:
> >>>> Can it be that musb was broken because of this change in the mainline
> >>>> linux kernel [1]?
> >>>
> >>> But you said that it works when you readd status = "okay" to some
> >>> of the USB device tree nodes? Which node was it in particular?
> >>>
> >>>> The kernel uses ti-sysc mechanism to get/configure the related hw
> >>>> blocks. If I grep for ti-sysc in kernel, I get a lot of hits. But in
> >>>> barebox, it is only drivers/bus/ti-sysc.c that I find. Seems like a
> >>>> rather big update is required.
> >>>>
> >>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am33xx.dtsi?h=v5.6-rc3&id=0782e8572ce43f521ed6ff15e4a7ab9aa5acdc85
> >>>
> >>> I don't think that's the problem. Looks to me like it should work with
> >>> barebox as well. Or did you revert this patch and got USB working again?
> >>
> >> Yes, I just reverted the whole patch and got USB working again. It has
> >> nothing to do with my dts file as it is hosted only in barebox
> >> (arch/arm/dts/am335x-baltos-minimal.dts). It just includes the common
> >> DTS files like am33xx.dtsi.
> >
> > I mean, I have reverted only this one 574eed3f6fcf056aa4c9e46c4b5224e3f7844d8d.
>
> I meant that you revert the upstream device tree patch only. Either manually or by doing
> some temporary hack like symlink $BAREBOX/dts/src/arm to $LINUX/arch/arm/boot/dts
> and revert inside the kernel git tree.

I've checked out barebox master and then reverted
574eed3f6fcf056aa4c9e46c4b5224e3f7844d8d (dts: update to v5.5-rc1).
After examining the changes, I found out that am33xx.dtsi was changed.
One of this changes is the following:

-               usb: usb@47400000 {
-                       compatible = "ti,am33xx-usb";
-                       reg = <0x47400000 0x1000>;
-                       ranges;
+               usb: target-module@47400000 {
+                       compatible = "ti,sysc-omap4", "ti,sysc";
+                       reg = <0x47400000 0x4>,
+                             <0x47400010 0x4>;
+                       reg-names = "rev", "sysc";
+                       ti,sysc-mask = <(SYSC_OMAP4_FREEEMU |
+                                        SYSC_OMAP2_SOFTRESET)>;
+                       ti,sysc-midle = <SYSC_IDLE_FORCE>,
+                                       <SYSC_IDLE_NO>,
+                                       <SYSC_IDLE_SMART>;
+                       ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+                                       <SYSC_IDLE_NO>,
+                                       <SYSC_IDLE_SMART>,
+                                       <SYSC_IDLE_SMART_WKUP>;
+                       clocks = <&l3s_clkctrl AM3_L3S_USB_OTG_HS_CLKCTRL 0>;
+                       clock-names = "fck";

If I understand it correctly, drivers/usb/musb/musb_am335x.c still has
the old .compatible string:

static __maybe_unused struct of_device_id am335x_child_dt_ids[] = {
        {
                .compatible = "ti,am33xx-usb",
        }, {
                /* sentinel */
        },
};

This node was removed:

-                       usb_ctrl_mod: control@44e10620 {
-                               compatible = "ti,am335x-usb-ctrl-module";
-                               reg = <0x44e10620 0x10
-                                       0x44e10648 0x4>;
-                               reg-names = "phy_ctrl", "wakeup";
-                               status = "disabled";
-                       };

So there are many changes in device tree files that are not reflected
in the drivers. I haven't debugged it but just examined the introduced
changes.

Yegor

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: musb is broken in master

[Ahmad Fatoum]

Hello,

On 2/24/20 3:08 PM, Yegor Yefremov wrote:
> I've checked out barebox master and then reverted
> 574eed3f6fcf056aa4c9e46c4b5224e3f7844d8d (dts: update to v5.5-rc1).
> After examining the changes, I found out that am33xx.dtsi was changed.
> One of this changes is the following:
> 
> -               usb: usb@47400000 {
> -                       compatible = "ti,am33xx-usb";
> -                       reg = <0x47400000 0x1000>;
> -                       ranges;
> +               usb: target-module@47400000 {
> +                       compatible = "ti,sysc-omap4", "ti,sysc";
> +                       reg = <0x47400000 0x4>,
> +                             <0x47400010 0x4>;
> +                       reg-names = "rev", "sysc";
> +                       ti,sysc-mask = <(SYSC_OMAP4_FREEEMU |
> +                                        SYSC_OMAP2_SOFTRESET)>;
> +                       ti,sysc-midle = <SYSC_IDLE_FORCE>,
> +                                       <SYSC_IDLE_NO>,
> +                                       <SYSC_IDLE_SMART>;
> +                       ti,sysc-sidle = <SYSC_IDLE_FORCE>,
> +                                       <SYSC_IDLE_NO>,
> +                                       <SYSC_IDLE_SMART>,
> +                                       <SYSC_IDLE_SMART_WKUP>;
> +                       clocks = <&l3s_clkctrl AM3_L3S_USB_OTG_HS_CLKCTRL 0>;
> +                       clock-names = "fck";
> 
> If I understand it correctly, drivers/usb/musb/musb_am335x.c still has
> the old .compatible string:
> 
> static __maybe_unused struct of_device_id am335x_child_dt_ids[] = {
>         {
>                 .compatible = "ti,am33xx-usb",
>         }, {
>                 /* sentinel */
>         },
> };
> 
> This node was removed:
> 
> -                       usb_ctrl_mod: control@44e10620 {
> -                               compatible = "ti,am335x-usb-ctrl-module";
> -                               reg = <0x44e10620 0x10
> -                                       0x44e10648 0x4>;
> -                               reg-names = "phy_ctrl", "wakeup";
> -                               status = "disabled";
> -                       };
> 
> So there are many changes in device tree files that are not reflected
> in the drivers. I haven't debugged it but just examined the introduced
> changes.

I see. I misunderstood your earlier answer to mean that reverting the _Linux_
patch in question fixed the issue for you instead of reverting the whole _barebox_
patch.

I've bisected the issue in the kernel git and arrived at the same commit about
ti,sysc that you suspected. While we have the necessary support of barebox to
support this, the new device tree structuring changed the order in which we probed
the different MUSB drivers. I have just sent out two patches to teach the MUSB
drivers to accept the new world order. Your Tested-by: would be appreciated.

Apparently, we already do some automatic testing for the BeagleBone, including
barebox, with our internal DistroKit CI. I'll amend our tests, so it may catch
new warnings after updates, like the one you encountered.

Cheers
Ahmad

> 
> Yegor
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: musb is broken in master

[Yegor Yefremov]

Hi Ahmad,

On Tue, Feb 25, 2020 at 6:13 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> Hello,
>
> On 2/24/20 3:08 PM, Yegor Yefremov wrote:
> > I've checked out barebox master and then reverted
> > 574eed3f6fcf056aa4c9e46c4b5224e3f7844d8d (dts: update to v5.5-rc1).
> > After examining the changes, I found out that am33xx.dtsi was changed.
> > One of this changes is the following:
> >
> > -               usb: usb@47400000 {
> > -                       compatible = "ti,am33xx-usb";
> > -                       reg = <0x47400000 0x1000>;
> > -                       ranges;
> > +               usb: target-module@47400000 {
> > +                       compatible = "ti,sysc-omap4", "ti,sysc";
> > +                       reg = <0x47400000 0x4>,
> > +                             <0x47400010 0x4>;
> > +                       reg-names = "rev", "sysc";
> > +                       ti,sysc-mask = <(SYSC_OMAP4_FREEEMU |
> > +                                        SYSC_OMAP2_SOFTRESET)>;
> > +                       ti,sysc-midle = <SYSC_IDLE_FORCE>,
> > +                                       <SYSC_IDLE_NO>,
> > +                                       <SYSC_IDLE_SMART>;
> > +                       ti,sysc-sidle = <SYSC_IDLE_FORCE>,
> > +                                       <SYSC_IDLE_NO>,
> > +                                       <SYSC_IDLE_SMART>,
> > +                                       <SYSC_IDLE_SMART_WKUP>;
> > +                       clocks = <&l3s_clkctrl AM3_L3S_USB_OTG_HS_CLKCTRL 0>;
> > +                       clock-names = "fck";
> >
> > If I understand it correctly, drivers/usb/musb/musb_am335x.c still has
> > the old .compatible string:
> >
> > static __maybe_unused struct of_device_id am335x_child_dt_ids[] = {
> >         {
> >                 .compatible = "ti,am33xx-usb",
> >         }, {
> >                 /* sentinel */
> >         },
> > };
> >
> > This node was removed:
> >
> > -                       usb_ctrl_mod: control@44e10620 {
> > -                               compatible = "ti,am335x-usb-ctrl-module";
> > -                               reg = <0x44e10620 0x10
> > -                                       0x44e10648 0x4>;
> > -                               reg-names = "phy_ctrl", "wakeup";
> > -                               status = "disabled";
> > -                       };
> >
> > So there are many changes in device tree files that are not reflected
> > in the drivers. I haven't debugged it but just examined the introduced
> > changes.
>
> I see. I misunderstood your earlier answer to mean that reverting the _Linux_
> patch in question fixed the issue for you instead of reverting the whole _barebox_
> patch.
>
> I've bisected the issue in the kernel git and arrived at the same commit about
> ti,sysc that you suspected. While we have the necessary support of barebox to
> support this, the new device tree structuring changed the order in which we probed
> the different MUSB drivers. I have just sent out two patches to teach the MUSB
> drivers to accept the new world order. Your Tested-by: would be appreciated.
>
> Apparently, we already do some automatic testing for the BeagleBone, including
> barebox, with our internal DistroKit CI. I'll amend our tests, so it may catch
> new warnings after updates, like the one you encountered.

Thank you very much for your fix. An addition to the CI procedure
would be really useful.

Yegor

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox