Re: [PATCH v8 00/11] arm64: sunxi: Initial Allwinner H616 SoC support

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 [off-list ref] wrote:

quoted

On Fri, Jul 23, 2021 at 04:38:27PM +0100, Andre Przywara wrote:

quoted

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.

quoted

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