From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Mon, 2 Jul 2018 23:57:45 +0200 Subject: [U-Boot] [PATCH] arm64: allwinner: a64: Disable ehci1 and ohci1 for bananapi, nanopi In-Reply-To: <20180702214007.GL4752@bill-the-cat.ec.rr.com> References: <20180702205302.26912-1-jagan@amarulasolutions.com> <6fa01a71-f25d-123b-4340-5226370a233c@denx.de> <20180702214007.GL4752@bill-the-cat.ec.rr.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. > Jagan, can you bisect down to when this started happening? I assume > it's a recent'ish thing. Thanks! > -- Best regards, Marek Vasut