From: Arnd Bergmann <arnd@arndb.de>
To: Michael Turquette <mturquette@baylibre.com>
Cc: John Stultz <john.stultz@linaro.org>,
Olof Johansson <olof@lixom.net>,
lkml <linux-kernel@vger.kernel.org>,
"arm@kernel.org" <arm@kernel.org>,
Stephen Boyd <sboyd@codeaurora.org>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Wei Xu <xuwei5@hisilicon.com>, Guodong Xu <guodong.xu@linaro.org>,
Zhangfei Gao <zhangfei.gao@linaro.org>
Subject: Re: [PATCH 0/2 v3] Add pl031 RTC support for Hi6220
Date: Fri, 15 Jul 2016 10:06:32 +0200 [thread overview]
Message-ID: <1736252.WAIVArieDJ@wuerfel> (raw)
In-Reply-To: <146794451180.73491.16184621585178119543@resonance>
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
next prev parent reply other threads:[~2016-07-15 8:07 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-30 0:48 [PATCH 0/2 v3] Add pl031 RTC support for Hi6220 John Stultz
2016-06-30 0:48 ` [PATCH 1/2 v3] clk: hi6220: Add RTC clock for pl031 John Stultz
2016-06-30 19:15 ` Stephen Boyd
2016-06-30 19:23 ` John Stultz
2016-06-30 0:48 ` [PATCH 2/2 v3] arm64: dts: hi6220: Add pl031 RTC support John Stultz
2016-06-30 15:12 ` [PATCH 0/2 v3] Add pl031 RTC support for Hi6220 Wei Xu
2016-07-06 5:22 ` Olof Johansson
2016-07-06 6:55 ` John Stultz
2016-07-06 7:04 ` Olof Johansson
2016-07-06 7:20 ` John Stultz
2016-07-06 7:38 ` Arnd Bergmann
2016-07-06 8:13 ` Wei Xu
2016-07-12 1:03 ` John Stultz
2016-07-07 0:19 ` Michael Turquette
2016-07-07 8:13 ` Arnd Bergmann
[not found] ` <146794382979.73491.3322475351079454720@resonance>
2016-07-11 20:21 ` Arnd Bergmann
[not found] ` <146827441381.73491.4865692343236492728@resonance>
2016-07-12 8:51 ` Arnd Bergmann
[not found] ` <146834751937.73491.12265160509757545340@resonance>
2016-07-14 14:30 ` Arnd Bergmann
2016-07-07 0:58 ` John Stultz
2016-07-07 8:22 ` Arnd Bergmann
2016-07-08 2:21 ` Michael Turquette
2016-07-15 8:06 ` Arnd Bergmann [this message]
2016-07-11 1:30 ` Guodong Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1736252.WAIVArieDJ@wuerfel \
--to=arnd@arndb.de \
--cc=arm@kernel.org \
--cc=guodong.xu@linaro.org \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=olof@lixom.net \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@codeaurora.org \
--cc=xuwei5@hisilicon.com \
--cc=zhangfei.gao@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox