Re: [SPAM] Re: [PATCH v5 0/2] arm: dts: rockchip: rk3399: usb: ehci: Fix EHCI probe in rk3399 to access peripherals by USB 2.
El Sat, Jun 03, 2023 at 09:23:36AM +0200, Xavier Drudis Ferran deia: > El Fri, Jun 02, 2023 at 03:34:37PM +0530, Jagan Teki deia: > > On Fri, Jun 2, 2023 at 2:54 PM Xavier Drudis Ferran > > wrote: > > > > > > Should I try again with the current next branch and send v6 ? > > > > Please send. > > > > Thanks, > > Jagan. > > I will try asap, thanks. Done https://patchwork.ozlabs.org/project/uboot/list/?series=358005 Tests, etc. welcome. Christoph Fritz issue with his USB-ethernet adapter on XHCI may still be there, it looked unrelated and I can't test it.
Re: [SPAM] Re: [PATCH v5 0/2] arm: dts: rockchip: rk3399: usb: ehci: Fix EHCI probe in rk3399 to access peripherals by USB 2.
El Fri, Jun 02, 2023 at 03:34:37PM +0530, Jagan Teki deia: > On Fri, Jun 2, 2023 at 2:54 PM Xavier Drudis Ferran wrote: > > > > Should I try again with the current next branch and send v6 ? > > Please send. > > Thanks, > Jagan. I will try asap, thanks.
Re: [SPAM] Re: [PATCH v5 0/2] arm: dts: rockchip: rk3399: usb: ehci: Fix EHCI probe in rk3399 to access peripherals by USB 2.
On Fri, Jun 2, 2023 at 2:54 PM Xavier Drudis Ferran wrote: > > El Fri, Jun 02, 2023 at 12:11:13PM +0530, Jagan Teki deia: > > > > Any news about the next revision of this patch? RK3399 has broken > > since release due to this issue. This fix might make upcoming release > > workable. > > > > Please let us know. > > > > Sorry, I'm not sure you meant to send this to me ? > > For my side I stopped working on it after I got no feedback for my last > version: > > https://lists.denx.de/pipermail/u-boot/2023-February/510672.html > https://lists.denx.de/pipermail/u-boot/2023-February/510676.html > https://lists.denx.de/pipermail/u-boot/2023-February/510678.html > > I got no replies. > > I asked whether I should resend. > > https://lists.denx.de/pipermail/u-boot/2023-March/511621.html > > > Btw, my v5 seems not to be correctly in patchwork, should I resend ? > > I guess I messed up subject lines ? > > And I got no answer, so I thought there were still no interest and > gave up. > > Now I see I answered to a question to Eugen only, not the list, so maybe > the list kept waiting for my answer. > > Might be some misunderstanding. > > Should I try again with the current next branch and send v6 ? Please send. Thanks, Jagan.
Re: [SPAM] Re: [PATCH v5 0/2] arm: dts: rockchip: rk3399: usb: ehci: Fix EHCI probe in rk3399 to access peripherals by USB 2.
El Fri, Jun 02, 2023 at 12:11:13PM +0530, Jagan Teki deia: > > Any news about the next revision of this patch? RK3399 has broken > since release due to this issue. This fix might make upcoming release > workable. > > Please let us know. > Sorry, I'm not sure you meant to send this to me ? For my side I stopped working on it after I got no feedback for my last version: https://lists.denx.de/pipermail/u-boot/2023-February/510672.html https://lists.denx.de/pipermail/u-boot/2023-February/510676.html https://lists.denx.de/pipermail/u-boot/2023-February/510678.html I got no replies. I asked whether I should resend. https://lists.denx.de/pipermail/u-boot/2023-March/511621.html > Btw, my v5 seems not to be correctly in patchwork, should I resend ? > I guess I messed up subject lines ? And I got no answer, so I thought there were still no interest and gave up. Now I see I answered to a question to Eugen only, not the list, so maybe the list kept waiting for my answer. Might be some misunderstanding. Should I try again with the current next branch and send v6 ?
Re: [PATCH v5 0/2] arm: dts: rockchip: rk3399: usb: ehci: Fix EHCI probe in rk3399 to access peripherals by USB 2.
On Fri, Mar 3, 2023 at 3:57 PM Xavier Drudis Ferran wrote: > > El Fri, Mar 03, 2023 at 10:42:20AM +0100, Christoph Fritz deia: > > >Changes: > > > > > >v5: fixes a bug that Christoph Fritz discovered, consisting in the > > >wrong eror code returned when enabling or disabling the clock > > >because property_enable() returns an error code in linux but > > >the modified register value in U-Boot. This caused the clk > > >disable to abort before freeing the clock and it apparently > > >left things bad enough to cause a hang or a reset. > > > > > > > With your patches ontop of v2023.04-rc2, xhci works now fine on a > > rk3399 board: > > > > Fine, thanks a lot for testing. I thought the problem was with EHCI. > > > Totally unrelated to your patches, stopping usb still crashes (with or > > without your patch) but only when a USB-Ethernet-Dongle (+HUB) is > > connected: > > > > Well, but with v4 you got a couple more messages about devices not > removed but children gone. With v5 those messages don't show any > more. So v5 fixes one of the bugs you were seeing, more bugs remain. > > Unfortunately I don't think I have any usb-ethernet dongle here to test... > > > => usb start > > starting USB... > > do_usb_start, 581 > > Bus usb@fe38: USB EHCI 1.00 > > Bus usb@fe3c: USB EHCI 1.00 > > Bus usb@fe80: Register 2000140 NbrPorts 2 > > Starting the controller > > USB XHCI 1.10 > > Bus usb@fe90: Register 2000140 NbrPorts 2 > > Starting the controller > > USB XHCI 1.10 > > scanning bus usb@fe38 for devices... 3 USB Device(s) found > > scanning bus usb@fe3c for devices... 1 USB Device(s) found > > scanning bus usb@fe80 for devices... 1 USB Device(s) found > > scanning bus usb@fe90 for devices... 1 USB Device(s) found > >scanning usb for storage devices... 0 Storage Device(s) found > > => usb tree > > USB device tree: > > 1 Hub (480 Mb/s, 0mA) > > | u-boot EHCI Host Controller > > | > > +-2 Hub (480 Mb/s, 100mA) > > | USB2.0 Hub > > | > > +-3 Human Interface (12 Mb/s, 400mA) > > ILITEK ILITEK-TP > > > > 1 Hub (480 Mb/s, 0mA) > > u-boot EHCI Host Controller > > > > 1 Hub (5 Gb/s, 0mA) > > U-Boot XHCI Host Controller > > > > 1 Hub (5 Gb/s, 0mA) > > U-Boot XHCI Host Controller > > > > Ok, so this was with a keyboard or something connected to a USB 2 port > and nothing in the blue USB 3 port, right? > > > => usb stop > > stopping USB.. > > => usb start > > starting USB... > > Bus usb@fe38: USB EHCI 1.00 > > Bus usb@fe3c: USB EHCI 1.00 > > Bus usb@fe80: Register 2000140 NbrPorts 2 > > Starting the controller > > USB XHCI 1.10 > > Bus usb@fe90: Register 2000140 NbrPorts 2 > > Starting the controller > > USB XHCI 1.10 > > scanning bus usb@fe38 for devices... 4 USB Device(s) found > > scanning bus usb@fe3c for devices... 1 USB Device(s) found > > scanning bus usb@fe80 for devices... 3 USB Device(s) found > > scanning bus usb@fe90 for devices... 1 USB Device(s) found > >scanning usb for storage devices... 0 Storage Device(s) found > > => usb tree > > USB device tree: > > 1 Hub (480 Mb/s, 0mA) > > | u-boot EHCI Host Controller > > | > > +-2 Hub (480 Mb/s, 100mA) > > | USB2.0 Hub > > | > > +-3 Hub (480 Mb/s, 0mA) > > |VIA Labs, Inc. USB2.0 Hub > > | > > +-4 Human Interface (12 Mb/s, 400mA) > > ILITEK ILITEK-TP > > > > 1 Hub (480 Mb/s, 0mA) > > u-boot EHCI Host Controller > > > > 1 Hub (5 Gb/s, 0mA) > > | U-Boot XHCI Host Controller > > | > > +-2 Hub (5 Gb/s, 0mA) > > | VIA Labs, Inc. USB3.0 Hub > > | > > +-3 Vendor specific (5 Gb/s, 36mA) > > Realtek USB 10/100/1000 LAN 00E04C68034E > > > > 1 Hub (5 Gb/s, 0mA) > > U-Boot XHCI Host Controller > > > > And this was with the keyboard in USB2 and a USB3 VIA Labs hub > connected to the USB3 port and a Realtek ethernet-USB dongle attached > to that USB3 hub, right? > > > > => usb stop > > stopping USB.. > > > > > > I just quirked/masked the underlying issue by not doing usb_stop() at > > all in drivers/usb/host/usb-uclass.c. > > > > Does usb reset also hang ? If so the problem then must be that you are > left with no way to rescan for devices that were not connected at usb > start but get connected later ? > > Did you say before it all worked if you unconfigured EHCI and worked > with XHCI only? (or OHCI + XHCI but no EHCI). Might it have to do with > the same hub hanging from the EHCI and XHCI controller? (but it doesn't > sound strange to me, the hub doesn't know what devices will be > connected to it...) > > If you leave drivers/usb/host/usb-uclass.c as it was but drop some > #define DEBUG in device-remove.c does it give any hint ? > > I'll try to do some more tests with a USB3 hub and usb storage... Any news about the next revision of this patch? RK3399 has broken since release due to
Re: [PATCH v5 0/2] arm: dts: rockchip: rk3399: usb: ehci: Fix EHCI probe in rk3399 to access peripherals by USB 2.
El Fri, Mar 03, 2023 at 10:42:20AM +0100, Christoph Fritz deia: > > Changes: > > > > v5: fixes a bug that Christoph Fritz discovered, consisting in the > > wrong eror code returned when enabling or disabling the clock > > because property_enable() returns an error code in linux but > > the modified register value in U-Boot. This caused the clk > > disable to abort before freeing the clock and it apparently > > left things bad enough to cause a hang or a reset. > > > > With your patches ontop of v2023.04-rc2, xhci works now fine on a > rk3399 board: > Fine, thanks a lot for testing. I thought the problem was with EHCI. > Totally unrelated to your patches, stopping usb still crashes (with or > without your patch) but only when a USB-Ethernet-Dongle (+HUB) is > connected: > Well, but with v4 you got a couple more messages about devices not removed but children gone. With v5 those messages don't show any more. So v5 fixes one of the bugs you were seeing, more bugs remain. Unfortunately I don't think I have any usb-ethernet dongle here to test... > => usb start > starting USB... > do_usb_start, 581 > Bus usb@fe38: USB EHCI 1.00 > Bus usb@fe3c: USB EHCI 1.00 > Bus usb@fe80: Register 2000140 NbrPorts 2 > Starting the controller > USB XHCI 1.10 > Bus usb@fe90: Register 2000140 NbrPorts 2 > Starting the controller > USB XHCI 1.10 > scanning bus usb@fe38 for devices... 3 USB Device(s) found > scanning bus usb@fe3c for devices... 1 USB Device(s) found > scanning bus usb@fe80 for devices... 1 USB Device(s) found > scanning bus usb@fe90 for devices... 1 USB Device(s) found >scanning usb for storage devices... 0 Storage Device(s) found > => usb tree > USB device tree: > 1 Hub (480 Mb/s, 0mA) > | u-boot EHCI Host Controller > | > +-2 Hub (480 Mb/s, 100mA) > | USB2.0 Hub > | > +-3 Human Interface (12 Mb/s, 400mA) > ILITEK ILITEK-TP > > 1 Hub (480 Mb/s, 0mA) > u-boot EHCI Host Controller > > 1 Hub (5 Gb/s, 0mA) > U-Boot XHCI Host Controller > > 1 Hub (5 Gb/s, 0mA) > U-Boot XHCI Host Controller > Ok, so this was with a keyboard or something connected to a USB 2 port and nothing in the blue USB 3 port, right? > => usb stop > stopping USB.. > => usb start > starting USB... > Bus usb@fe38: USB EHCI 1.00 > Bus usb@fe3c: USB EHCI 1.00 > Bus usb@fe80: Register 2000140 NbrPorts 2 > Starting the controller > USB XHCI 1.10 > Bus usb@fe90: Register 2000140 NbrPorts 2 > Starting the controller > USB XHCI 1.10 > scanning bus usb@fe38 for devices... 4 USB Device(s) found > scanning bus usb@fe3c for devices... 1 USB Device(s) found > scanning bus usb@fe80 for devices... 3 USB Device(s) found > scanning bus usb@fe90 for devices... 1 USB Device(s) found >scanning usb for storage devices... 0 Storage Device(s) found > => usb tree > USB device tree: > 1 Hub (480 Mb/s, 0mA) > | u-boot EHCI Host Controller > | > +-2 Hub (480 Mb/s, 100mA) > | USB2.0 Hub > | > +-3 Hub (480 Mb/s, 0mA) > |VIA Labs, Inc. USB2.0 Hub > | > +-4 Human Interface (12 Mb/s, 400mA) > ILITEK ILITEK-TP > > 1 Hub (480 Mb/s, 0mA) > u-boot EHCI Host Controller > > 1 Hub (5 Gb/s, 0mA) > | U-Boot XHCI Host Controller > | > +-2 Hub (5 Gb/s, 0mA) > | VIA Labs, Inc. USB3.0 Hub > | > +-3 Vendor specific (5 Gb/s, 36mA) > Realtek USB 10/100/1000 LAN 00E04C68034E > > 1 Hub (5 Gb/s, 0mA) > U-Boot XHCI Host Controller > And this was with the keyboard in USB2 and a USB3 VIA Labs hub connected to the USB3 port and a Realtek ethernet-USB dongle attached to that USB3 hub, right? > => usb stop > stopping USB.. > > > I just quirked/masked the underlying issue by not doing usb_stop() at > all in drivers/usb/host/usb-uclass.c. > Does usb reset also hang ? If so the problem then must be that you are left with no way to rescan for devices that were not connected at usb start but get connected later ? Did you say before it all worked if you unconfigured EHCI and worked with XHCI only? (or OHCI + XHCI but no EHCI). Might it have to do with the same hub hanging from the EHCI and XHCI controller? (but it doesn't sound strange to me, the hub doesn't know what devices will be connected to it...) If you leave drivers/usb/host/usb-uclass.c as it was but drop some #define DEBUG in device-remove.c does it give any hint ? I'll try to do some more tests with a USB3 hub and usb storage... Thanks again for testing.
Re: [PATCH v5 0/2] arm: dts: rockchip: rk3399: usb: ehci: Fix EHCI probe in rk3399 to access peripherals by USB 2.
> Changes: > > v5: fixes a bug that Christoph Fritz discovered, consisting in the > wrong eror code returned when enabling or disabling the clock > because property_enable() returns an error code in linux but > the modified register value in U-Boot. This caused the clk > disable to abort before freeing the clock and it apparently > left things bad enough to cause a hang or a reset. > With your patches ontop of v2023.04-rc2, xhci works now fine on a rk3399 board: => usb start starting USB... Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3c: USB EHCI 1.00 Bus usb@fe80: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 Bus usb@fe90: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 4 USB Device(s) found scanning bus usb@fe3c for devices... 1 USB Device(s) found scanning bus usb@fe80 for devices... 3 USB Device(s) found scanning bus usb@fe90 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Totally unrelated to your patches, stopping usb still crashes (with or without your patch) but only when a USB-Ethernet-Dongle (+HUB) is connected: => usb start starting USB... do_usb_start, 581 Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3c: USB EHCI 1.00 Bus usb@fe80: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 Bus usb@fe90: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 3 USB Device(s) found scanning bus usb@fe3c for devices... 1 USB Device(s) found scanning bus usb@fe80 for devices... 1 USB Device(s) found scanning bus usb@fe90 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found => usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Hub (480 Mb/s, 100mA) | USB2.0 Hub | +-3 Human Interface (12 Mb/s, 400mA) ILITEK ILITEK-TP 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller 1 Hub (5 Gb/s, 0mA) U-Boot XHCI Host Controller 1 Hub (5 Gb/s, 0mA) U-Boot XHCI Host Controller => usb stop stopping USB.. => usb start starting USB... Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3c: USB EHCI 1.00 Bus usb@fe80: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 Bus usb@fe90: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 4 USB Device(s) found scanning bus usb@fe3c for devices... 1 USB Device(s) found scanning bus usb@fe80 for devices... 3 USB Device(s) found scanning bus usb@fe90 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found => usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Hub (480 Mb/s, 100mA) | USB2.0 Hub | +-3 Hub (480 Mb/s, 0mA) |VIA Labs, Inc. USB2.0 Hub | +-4 Human Interface (12 Mb/s, 400mA) ILITEK ILITEK-TP 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller 1 Hub (5 Gb/s, 0mA) | U-Boot XHCI Host Controller | +-2 Hub (5 Gb/s, 0mA) | VIA Labs, Inc. USB3.0 Hub | +-3 Vendor specific (5 Gb/s, 36mA) Realtek USB 10/100/1000 LAN 00E04C68034E 1 Hub (5 Gb/s, 0mA) U-Boot XHCI Host Controller => usb stop stopping USB.. I just quirked/masked the underlying issue by not doing usb_stop() at all in drivers/usb/host/usb-uclass.c.
