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

From: Maxime Ripard <maxime@cerno.tech>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Rob Herring <robh@kernel.org>, Icenowy Zheng <icenowy@aosc.io>,
	Samuel Holland <samuel@sholland.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-sunxi@googlegroups.com, linux-sunxi@lists.linux.dev,
	linux-kernel@vger.kernel.org, Ondrej Jirman <megous@megous.com>
Subject: Re: [PATCH v8 00/11] arm64: sunxi: Initial Allwinner H616 SoC support
Date: Tue, 17 Aug 2021 09:30:30 +0200	[thread overview]
Message-ID: <20210817073030.jcvpfipsikllursv@gilmour> (raw)
In-Reply-To: <20210802013851.13375f0f@slackpad.fritz.box>

[-- Attachment #1: Type: text/plain, Size: 2508 bytes --]

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 <maxime@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]