Re: [PATCH 0/2 v3] Add pl031 RTC support for Hi6220

[Arnd Bergmann]

On Thursday, July 7, 2016 7:21:51 PM CEST Michael Turquette wrote:
> Quoting Arnd Bergmann (2016-07-07 01:22:30)
> > On Wednesday, July 6, 2016 5:58:14 PM CEST John Stultz wrote:

> > 
> > We typically have it easier for other subsystems like irqchip or gpio
> > where nobody would consider writing a driver that can only handle
> > the I/O lines that are used on their board with a minimal set of
> > drivers, but for some reason it seems acceptable to do it for clock
> > controllers just because they are harder to describe.
> 
> gpio and irqchip are interesting analogues. It makes pretty good sense
> to expose all of those lines via DT, since those are resources that
> consumer drivers may be interested in. But is the same true for clock
> signals?
> 
> Clearly drivers will care about their input clocks, which are often leaf
> gates. But the mess and tangle of "root" and "branch" clocks above that?
> Why expose it to DT if we don't need to? These are resources that are
> often internal to the clock controller IP block. In an ideal world we
> would never need to provide a way for clock consumer drivers to get at
> these root and branch clocks, just the peripheral leaf clocks.
> 
> As an example of this, ccf has tried to be smart about propagating rate
> requests up the chain of parents since it was originally merged, and
> that directly has led to lots of consolidation around the cpufreq-dt.c
> driver, where a single leaf clock can ultimately affect a PLL or
> post-divider without the cpufreq driver needing to know the details of
> the clock hierarchy internal to the clock controller IP block.
> 
> (in reality we do need to expose root and branch clocks for drivers some
> times, but I disagree that we should expose every single clock signal
> just because it is there)

(sorry for coming back to this late)

I still don't fully understand how we ended up with the missing
clk in the specific example here, but it seems to me that what
was missing here is indeed a leaf clock, not one of the clocks
above it. This is a simple gate that is controlled by a bit in the
same register as a number of other clocks, so if I understand you
right, it should have been there even if we don't want to expose
the internal clocks, correct?

	Arnd