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

[Marek Vasut]

On 07/03/2018 06:25 PM, Jagan Teki wrote:
> 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.

Given that this SoC is mostly operated from battery OR in constrained
environments where useless high thermal dissipation might cause trouble,
yes, turning off as much as possible is desired.

Besides, it's a good practice to keep things in order.

-- 
Best regards,
Marek Vasut