Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1440856 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/2 v3] Add pl031 RTC support for Hi6220 Arnd Bergmann <arnd@arndb.de> - 2016-07-11 22:20 +0200
    Re: [PATCH 0/2 v3] Add pl031 RTC support for Hi6220 Arnd Bergmann <arnd@arndb.de> - 2016-07-12 10:50 +0200
      Re: [PATCH 0/2 v3] Add pl031 RTC support for Hi6220 Arnd Bergmann <arnd@arndb.de> - 2016-07-14 16:40 +0200

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

On Thursday, July 7, 2016 7:10:30 PM CEST Michael Turquette wrote:
> Quoting Arnd Bergmann (2016-07-07 01:13:58)
> > On Wednesday, July 6, 2016 5:19:53 PM CEST Michael Turquette wrote:
> > > On Wed, Jul 6, 2016 at 12:38 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Wednesday, July 6, 2016 12:20:15 AM CEST John Stultz wrote:
> > > > > On Wed, Jul 6, 2016 at 12:04 AM, Olof Johansson <olof@lixom.net> wrote:
> > > > > > On Tue, Jul 5, 2016 at 11:55 PM, John Stultz <john.stultz@linaro.org> wrote:
> > > > > >> On Tue, Jul 5, 2016 at 10:22 PM, Olof Johansson <olof@lixom.net> wrote:
> > > > > >>> On Wed, Jun 29, 2016 at 05:48:43PM -0700, John Stultz wrote:
> > > > The question this raises is why that clock was missed the first time
> > > > around. I'd suggest whoever owns the clock driver can go through the
> > > > documentation again and look for others that may have been missed,
> > > > then send a patch to the driver to add *all* the missing ones for the
> > > > merge window, and one release later we add the driver depending on
> > > > previously unknown clocks.
> > > 
> > > Well, I'm kicking the ant pile on this one, but sometimes the above
> > > suggestion is not possible. I'm currently hacking on a platform with
> > > very limited docs, so I cannot understand the whole clock tree, nor
> > > how all peripherals are wired up to it.
> > 
> > That's clearly not the case here though: the hi6220 clk driver
> > was contributed by hisilicon engineers that have all the documentation.
> > 
> > > Further complicating matters is that fact that any headers in the DT
> > > include chroot constitute an unbreakable ABI that shall stand for
> > > 1,000 years at least, so I'm very remiss to dump a bunch of constant
> > > values in there with names that might need to change at a later date.
> > 
> > Can you give an example why they might need to change?
> 
> Yes, the AmLogic GXBB clk driver that I just merged is a great example.
> The names of the clock signals enumerated in the header will surely
> change as our understanding of the hardware changes. These names are
> part of the ABI and yet we cannot possibly get them right on the first
> pass.

I see. Actually the names are not part of the ABI, just the numeric
values are. Changing the names is of course still a pain, but it's
not nearly as bad as adding further constants, which requires coordinating
between the dts files and the driver.

> > Usually the
> > hardware doesn't change. There is also a risk of having a driver
> 
> It's not about the hardware changing, but our incomplete understanding
> of the hardware will certainly change.
> 
> > binding that makes sense for the first 10 clocks that get added,
> > and then it later turns out that the chip actually has hundreds
> > of clocks that could really use a completely different binding
> > to allow a simpler driver.
> 
> Can you give an example of this scenario?

My impression here was that the include/dt-bindings/clock/hi6220-clock.h
was such a case: it started out with the clocks that were initially
needed, and then the RTC driver was added and it happened to need
additional clocks. My conclusion from this was that the initial
set of clocks did not even cover the essential devices and that there
would be further additions required once we add more drivers.

However, as 	Guodong Xu said, this was just a mistake and we won't
need to make any other changes to this file in the future, so my rant
was probably misplaced here.

A better example might be include/dt-bindings/clock/exynos5410.h:
In this case, we have already had four separate patches adding
additional clocks after the driver was first written (by folks
that have direct access to the documentation and to the hardware
developers), and they even left space for the new numbers in
the initial file, so it's not like they didn't know there was
something else.

	Arnd

[toc] | [next] | [standalone]

#1441148

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:
> > > Quoting Arnd Bergmann (2016-07-07 01:13:58)
> > > > On Wednesday, July 6, 2016 5:19:53 PM CEST Michael Turquette wrote:
> > > > > On Wed, Jul 6, 2016 at 12:38 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > > On Wednesday, July 6, 2016 12:20:15 AM CEST John Stultz wrote:
> > > > > > > On Wed, Jul 6, 2016 at 12:04 AM, Olof Johansson <olof@lixom.net> wrote:
> > > > > > > > On Tue, Jul 5, 2016 at 11:55 PM, John Stultz <john.stultz@linaro.org> wrote:
> > > > > > > >> On Tue, Jul 5, 2016 at 10:22 PM, Olof Johansson <olof@lixom.net> wrote:
> > > > > > > >>> On Wed, Jun 29, 2016 at 05:48:43PM -0700, John Stultz wrote:
> > > > > > The question this raises is why that clock was missed the first time
> > > > > > around. I'd suggest whoever owns the clock driver can go through the
> > > > > > documentation again and look for others that may have been missed,
> > > > > > then send a patch to the driver to add *all* the missing ones for the
> > > > > > merge window, and one release later we add the driver depending on
> > > > > > previously unknown clocks.
> > > > > 
> > > > > Well, I'm kicking the ant pile on this one, but sometimes the above
> > > > > suggestion is not possible. I'm currently hacking on a platform with
> > > > > very limited docs, so I cannot understand the whole clock tree, nor
> > > > > how all peripherals are wired up to it.
> > > > 
> > > > That's clearly not the case here though: the hi6220 clk driver
> > > > was contributed by hisilicon engineers that have all the documentation.
> > > > 
> > > > > Further complicating matters is that fact that any headers in the DT
> > > > > include chroot constitute an unbreakable ABI that shall stand for
> > > > > 1,000 years at least, so I'm very remiss to dump a bunch of constant
> > > > > values in there with names that might need to change at a later date.
> > > > 
> > > > Can you give an example why they might need to change?
> > > 
> > > Yes, the AmLogic GXBB clk driver that I just merged is a great example.
> > > The names of the clock signals enumerated in the header will surely
> > > change as our understanding of the hardware changes. These names are
> > > part of the ABI and yet we cannot possibly get them right on the first
> > > pass.
> > 
> > I see. Actually the names are not part of the ABI, just the numeric
> > values are. Changing the names is of course still a pain, but it's
> > not nearly as bad as adding further constants, which requires coordinating
> > between the dts files and the driver.
> 
> Hmm, that's interesting. How do you feel about updates to Linux kernel
> clk driver + some consumer driver + dts, after we find out that some
> name is horribly wrong and needs to change?

That would be a bugfix and not part of the ABI, so I don't think that's
a problem.

> What about the case where the number needs to change? E.g. we find out
> later on that there is a post divider downstream that we did not know
> about, and we want the clk consumer to reference that post-divider
> instead of the parent of the post-divider?

I would never change the number that a specific name refers to.
If you have to rename a clk, I'd do it like this

- #define OLD_CLK_NAME 41
+ #define OLD_CLK_NAME 41 /* incorrect, don't use */
+ #define NEW_CLK_NAME 42

and in the example here, the DT entry for the device should be changed
to point ot the other clk.

> Would we be forced to play a tricky game of keeping the number the same,
> but just adding a new number for the post-divider and updating the
> driver & dts?

It depends on how the clk driver is structured of course. In the ideal
case, the clk driver already knows about all the dividers and doesn't
need the macros in the first place, so the update is just in the
dts, but this is probably not the case you are talking about in.

Generally speaking, I'd say the clk driver should have little or
no knowledge of how the clks are being used by drivers, that would
be a layering violation. 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.

	Arnd


commit c6e80ace83a90a410d09de0727ff9b151de6291a
Author: Xinliang Liu <xinliang.liu@linaro.org>
Date:   Wed Jun 29 16:45:54 2016 +0800

    clk: hi6220: Change syspll and media_syspll clk to 1.19GHz
    
    In the bootloader of HiKey/96boards, syspll and media_syspll clk
    was initialized to 1.19GHz. So, here changes it in kernel accordingly.
    
    1.19GHz was chosen over 1.2GHz because at 1.19GHz we get more precise
    HDMI pixel clock (1.19G/16 = 74.4MHz) for 1280x720p@60Hz HDMI
    (74.25MHz required by standards). Closer pixel clock means better
    compatibility to HDMI monitors.
    
    Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
    Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org>
    Signed-off-by: Michael Turquette <mturquette@baylibre.com>
    Link: lkml.kernel.org/r/1467189955-21694-1-git-send-email-guodong.xu@linaro.org

diff --git a/drivers/clk/hisilicon/clk-hi6220.c b/drivers/clk/hisilicon/clk-hi6220.c
index 76de9a762a86..fe364e63f8de 100644
--- a/drivers/clk/hisilicon/clk-hi6220.c
+++ b/drivers/clk/hisilicon/clk-hi6220.c
@@ -34,8 +34,8 @@ static struct hisi_fixed_rate_clock hi6220_fixed_rate_clks[] __initdata = {
 	{ HI6220_PLL_BBP,	"bbppll0",	NULL, 0, 245760000, },
 	{ HI6220_PLL_GPU,	"gpupll",	NULL, 0, 1000000000,},
 	{ HI6220_PLL1_DDR,	"ddrpll1",	NULL, 0, 1066000000,},
-	{ HI6220_PLL_SYS,	"syspll",	NULL, 0, 1200000000,},
-	{ HI6220_PLL_SYS_MEDIA,	"media_syspll",	NULL, 0, 1200000000,},
+	{ HI6220_PLL_SYS,	"syspll",	NULL, 0, 1190400000,},
+	{ HI6220_PLL_SYS_MEDIA,	"media_syspll",	NULL, 0, 1190400000,},
 	{ HI6220_DDR_SRC,	"ddr_sel_src",  NULL, 0, 1200000000,},
 	{ HI6220_PLL_MEDIA,	"media_pll",    NULL, 0, 1440000000,},
 	{ HI6220_PLL_DDR,	"ddrpll0",      NULL, 0, 1600000000,},

[toc] | [prev] | [next] | [standalone]

#1443489

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web