linux-kernel.vger.kernel.org archive mirror
 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: Thu, 14 Jul 2016 16:30:59 +0200	[thread overview]
Message-ID: <5159238.dTvZjzNLNR@wuerfel> (raw)
In-Reply-To: <146834751937.73491.12265160509757545340@resonance>

On Tuesday, July 12, 2016 11:18:39 AM CEST Michael Turquette wrote:
> Quoting Arnd Bergmann (2016-07-12 01:51:36)
> > On Monday, July 11, 2016 3:00:13 PM CEST Michael Turquette wrote:
> > > Quoting Arnd Bergmann (2016-07-11 13:21:17)
> > > > On Thursday, July 7, 2016 7:10:30 PM CEST Michael Turquette wrote:
> > A similar problem is the patch below
> > that was just added: what in the world does the clk driver care about
> > the settings that the bootloader sets? If something comes from the
> > bootloader, the driver should get it from the DT rather than hardcode it.
> 
> Clock drivers are hard. Strictly speaking, any clock that is consumed
> and controlled by a clock consumer driver in Linux should *not* need the
> kind of hack you see below in the clock consumer driver. The best fix is
> for a display driver to call clk_get() and clk_set_rate() on the clock.

Makes sense.

> However there are two examples of where this doesn't work:
> 
> 1) There is no consumer driver (e.g. DDR)
> 2) Support is coming for the consumer driver Some Day(tm), but we want
> things to work for now.

I have some vague memory that we talked about initializing clocks
from values in DT at some point, which would avoid the need for
hardcoding them in the driver. Am I misremembering that, or is it
something that just never happened?

> The hi6220 clk provider driver was already setting the PLLs, and the
> patch below merely tweaks the chosen rate. That's why I accepted it.
> Clearly it would be better for the PLL rate to set by the display
> driver.

Right, my comment wasn't about the fact that you merged this patch
on top, but rather about the fact that the driver started out by
hardcoding clockrates that are assumed to match whatever the boot
loader sets.

	Arnd

  parent reply	other threads:[~2016-07-14 14:31 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 [this message]
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
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=5159238.dTvZjzNLNR@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;
as well as URLs for NNTP newsgroup(s).