Hi Andre, On Mon, Aug 02, 2021 at 01:38:51AM +0100, Andre Przywara wrote: > On Mon, 26 Jul 2021 16:52:30 +0200 > Maxime Ripard <max...@cerno.tech> wrote: > > On Fri, Jul 23, 2021 at 04:38:27PM +0100, Andre Przywara wrote: > > > Hi, > > > > > > another try on the basic Allwinner H616 support, now on top of 5.14-rc1. > > > > > > This time I dropped the USB support from the basic series, to split off > > > the discussion, and simplify the core SoC support. I will post the USB > > > series soon, to be applied on top. > > > I kept the RTC support in, even though this is still under discussion, > > > because this is important to keep future DT files compatible with this > > > kernel. > > > > Honestly, I don't want to support something we don't guarantee if it's > > at the expense of making something we do guarantee more complicated. > > I don't ask for or provide guarantees, but I think we can at least *try* > to keep this compatible. This version works at the moment, and should > also work with future DTs - within the limits of the current driver, so > only using the RC clock. It allows to later improve the accuracy by > adding better input clocks - and later DT/driver combinations can make > use of this.
Again, at the expense of having to deal with more bindings combinations in the driver. This driver is already a nightmare to get all the one we have to support already. You asked to keep the same driver, fair enough, but then let's do our best to not make the situation worse there. > > Delaying the clock tree description to sometime in the future will only > > further complicate the probe part of the driver, and there's far too > > many special cases already. > > I don't see how this would complicate probing beyond what Allwinner > brought upon us already anyway: no LOSC crystal input in this package > version, but having this pin in some other SoC sharing this die > (according to some BSP) sources. We can't expect a super clean driver > with those HW design choices. > > If we really cannot keep the DT compatible, fair enough: that's what > it is (there is no guarantee!), but at least we have tried. I mean, we didn't really try though? The whole clock tree has basically a big TODO all over it. I know that it can be hard to figure out. It's why I suggested to rely on fixed clock for the moment as placeholders to get the rest of the series in. But for some reason you don't want to do that either. Maxime -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20210817073030.jcvpfipsikllursv%40gilmour.
signature.asc
Description: PGP signature
