All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.