public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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