[U-Boot] [PATCH] arm64: allwinner: a64: Disable ehci1 and ohci1 for bananapi, nanopi

[Jagan Teki]

On Tue, Jul 3, 2018 at 8:52 PM, Andre Przywara <andre.przywara at arm.com> 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.