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

[Vasily Khoruzhick]

On Tue, Jul 3, 2018 at 2:22 PM, André Przywara <andre.przywara at arm.com> wrote:

>> Adding a few more people to the list.  It looks like b62cdbddedc3 was in
>> response to fef73766d9ad.  So, this close to the release, what do we
>> need to do to get things back to the state things were in for v2018.05?
>> And then what are the combinations that aren't working and need to be
>> addressed again in v2018.09 so that we can make forward progress?
>
> Without going into much detail here, the clock dependency for two
> companion controllers on those A64 is weird, and we hack it somehow
> since we don't have a DM_CLK driver for sunxi (yet, see below). That
> works for init, since we just set already set bits. For shutdown, we
> *happen* to take down the AHB gate clocks and resets correctly, because
> the order of shutdown matches the dependency (EHCI first, the OHCI). Not
> sure if this is intentional, though. It's fragile, but works.
>
> What we don't (and can't easily) model is another oddity: the USB clock
> for [OE]HCI0 is actually the parent of [OE]HCI1. So if we need to bring
> down *two* controllers and do it in the natural order, the second one is
> dead before it can be disabled properly.
>
> This was somewhat hidden before, since we had only one controller in
> operation. b62cdbddedc3 somewhat fixed that, but the DT for the Pine64
> (which was the test vehicle) has the controller still disabled. Enabling
> this (what I did) or using other boards (BananaPi and NanoPi from Jagan)
> triggered this bug though.
> AFAICS this parent relation only affects the A64 with its two
> controllers, so:
> - We could just fix it for now by *not* disabling the USB clocks (and
> only those, gates and reset still go down) at all. This is basically one
> part of my patch from yesterday (the second part is not needed).
> - We do more effort and skip disabling for OHCI0, but disable both
> clocks for OHCI1. This still relies on the order, but would probably
> shut down the controllers. A bit hackish to implement, though.
> I will try the second solution now and let you decide on the list.
>
> Long term:
> The proper solution is a DT based DM_CLK driver, which models it like
> Linux does. Work is underway[1], but this somewhat opens a can of worms
> (needs DM support for UART, MMC, a DM_RESET driver, pinctrl ...), so it
> takes a bit of time.

I tried enabling DM for MMC on A64 recently and unfortunately it results in
SPL exceeding 32kb size limit.
So I guess we'll have to find a workaround for this issue as well...

> Fixing the current ad-hoc solution somewhat properly with ref-counting
> is not easy (two driver files) and not really worthwhile, I believe, but
> we can make it work like described above until the proper solution comes
> into play.
>
> Cheers,
> Andre.