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

[Maxime Ripard]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180703/fa590659/attachment.sig>