From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jagan Teki Date: Tue, 3 Jul 2018 21:55:54 +0530 Subject: [U-Boot] [PATCH] arm64: allwinner: a64: Disable ehci1 and ohci1 for bananapi, nanopi In-Reply-To: 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 Tue, Jul 3, 2018 at 8:52 PM, Andre Przywara wrote: > Hi, > > On 02/07/18 22:57, 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. > > Yes, it is. There is no bug in Linux. > > U-Boot trips over its own feet when bringing down the USB controllers: > It shutdowns one part (EHCI or OHCI) on the register level, then turns > off the clocks and reset gates. But because they are shared between > controllers, this turns off the other controller as well. Then it tries > to bring down the the second part (OHCI or EHCI, respectively) on the > USB register level, which hangs, because the AHB clock is already off. > As this just happens quite late, it looks like U-Boot already said > goodbye, but it actually hasn't completely finished. > So Linux is completely fine and the bug is entirely in U-Boot. > My patch [1] tries to paper^Wsolve this in a different way, though it > isn't perfect either. I think there is a bit more to it than I assumed > yesterday, so I need to go back to the code later tonight to see what's > really going on (I suspect it's about OHCI 0 and 1 sharing a clock, not > about EHCI and OHCI). > > Cheers, > Andre. > > [1] https://lists.denx.de/pipermail/u-boot/2018-July/333533.html Do we really need turn-off ahb and reset gates? these are gracefully disabled during shutdown. Jagan.