On Tue, Jul 3, 2018 at 2:22 PM, André Przywara <andre.przyw...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot