On Mon, Jul 02, 2018 at 11:57:45PM +0200, Marek Vasut wrote: > On 07/02/2018 11:40 PM, Tom Rini wrote: > > On Mon, Jul 02, 2018 at 11:27:58PM +0200, Marek Vasut wrote: > >> On 07/02/2018 10:53 PM, Jagan Teki wrote: > >>> During usb shutdown or 'usb reset' all the necessary clocks > >>> on the specific controller will disable. Usually this shutdown > >>> happen during U-Boot proper handoff to Linux. > >> > >> No, 'usb reset' can be triggered by the user any time. > > > > Yes, and it's also triggered as part of the hand-off, which is the use > > case in question. > > No, that's not true. The USB controllers are torn down when starting the > OS, which is a different thing from usb reset, which brings them back up > and rescans the bus too. > > >>> There is an issue in Allwinner A64, is during OHCI1 shutdown > >>> the controller is unable to access the register space > >>> so the Linux boot hangs at this place. > >> > >> This doesn't make any sense, Linux should enable the necessary clock > >> before accessing any controller registers, unless there is a bug in Linux. > > > > Should but doesn't always? So yes, there's possibly / hopefully a bug > > in the dts files. > > How did you reach that conclusion about the DTS files ? There is a bug > in Linux, but it's likely in the driver which doesn't enable the clock > before accessing the registers. > > But maybe the description here is completely confusing, since the output > down below would indicate this hang is still in U-Boot. > > >>> This particular condition occur when we enable both the > >>> controllers, so this patch will disable OHCI1 and EHCI1 for > >>> bananapi-m64 and nanopi-a64 boards. It will re-enable the same > >>> once the issue got fixed. > >>> > >>> Log: > >>> => usb reset > >>> resetting USB... > >>> > >>> PHY0: mask = 0x101, usb_clk_cfg = 0x30202 > >>> sunxi_musb_exit: ahb_gate0 = 0x33004540, reset0_cfg = 0x33004540 > >>> EHCI failed to shut down host controller. > >>> ehci_usb_remove: ahb_gate0 = 0x32004540, reset0_cfg = 0x32004540 > >>> ohci_usb_remove: ahb_gate0 = 0x22004540, reset0_cfg = 0x22004540 > >>> ohci_usb_remove: mask = 0x10000, usb_clk_cfg = 0x20202 > >>> > >>> PHY1: mask = 0x202, usb_clk_cfg = 0x0 > >>> ehci_usb_remove: ahb_gate0 = 0x20004540, reset0_cfg = 0x20004540 > >> > >> Why is this usb reset so noisy ? > > > > ... I would assume additional debug messages. > > > >>> << hang here >> > >> > >> Please fix this properly, this patch is pure attempt to hide a bug. > >> NAK from me. > > > > Well, the point of this patch as Jagan says is to hide the bug for the > > release so that Linux can boot, which is an important case. > > But the above implies that Linux can boot and the hang happens while > still in U-Boot due to some ordering bug between clock and register > access in the .remove function of some driver (I guess). That is what > needs to be debugged and fixed.
Yeah, I agree. If we have a bug in U-Boot or in Linux, we should fix whatever it is. Papering over it will just keep it, with no one interested in fixing it anymore. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
