All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH/RFC 1/5] clk: shmobile: rcar-gen2: Add CPG Clock Domain support
Date: Wed, 01 Apr 2015 12:13:12 +0000	[thread overview]
Message-ID: <CAMuHMdWuVdOgk6RAzoUtskC3pzz3xs6HmGf5RyrAa3Rs-y56uQ@mail.gmail.com> (raw)
In-Reply-To: <3861934.bVCAbQmBJW@avalon>

Hi Laurent,

On Tue, Mar 31, 2015 at 1:53 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Wednesday 18 March 2015 20:46:53 Geert Uytterhoeven wrote:
>> Add Clock Domain support to the R-Car Gen2 Clock Pulse Generator (CPG)
>> driver using the generic PM Domain.  This allows to power-manage the
>> module clocks of SoC devices that are part of the CPG Clock Domain using
>> Runtime PM, or for system suspend/resume.
>>
>> SoC devices that are part of the CPG Clock Domain and can be
>> power-managed through their primary clock should be tagged in DT with a
>> proper "power-domains" property.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> There's one thing that bothers me: the implementation is tied to the CPG
> driver, but the code is quite generic. That feels a bit wrong, it would be
> nice to come up with a generic implementation. On the other hand, the
> platform-dependent part is the list of clocks to manage, specified implicitly
> through the "pm_clk_add(dev, NULL)" call. That list needs to be specified
> somewhere, and adding it to the CPG driver is likely the best solution we can
> have at the moment.

This clock management code is identical to the one in pm-rmobile.c.
We may consolidate in the future, if we have more PM Domain support (e.g.
for R-Car Gen2 SYSC). Let's see...

> I'm slightly worried that adding the power-domains property to the DT node
> will introduce backward compatibility issues if we later switch to a different
> way to specify the clocks to manage automatically. I have no specific example
> though.

Specifying the clocks is indeed the hard part. I use the primary clocks, as
that is compatible with what we did in the past in drivers/sh/pm_runtime.c.
I thought about using a special clock name instead, but that may conflict
with an existing driver-specific DT binding for clk-names, and may cause
problems if you have to specify the same clock twice with different clk-names.

> For those reasons,
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>,
	Mike Turquette <mturquette@linaro.org>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Simon Horman <horms@verge.net.au>,
	Magnus Damm <magnus.damm@gmail.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Kevin Hilman <khilman@kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Linux PM list <linux-pm@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH/RFC 1/5] clk: shmobile: rcar-gen2: Add CPG Clock Domain support
Date: Wed, 1 Apr 2015 14:13:12 +0200	[thread overview]
Message-ID: <CAMuHMdWuVdOgk6RAzoUtskC3pzz3xs6HmGf5RyrAa3Rs-y56uQ@mail.gmail.com> (raw)
In-Reply-To: <3861934.bVCAbQmBJW@avalon>

Hi Laurent,

On Tue, Mar 31, 2015 at 1:53 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Wednesday 18 March 2015 20:46:53 Geert Uytterhoeven wrote:
>> Add Clock Domain support to the R-Car Gen2 Clock Pulse Generator (CPG)
>> driver using the generic PM Domain.  This allows to power-manage the
>> module clocks of SoC devices that are part of the CPG Clock Domain using
>> Runtime PM, or for system suspend/resume.
>>
>> SoC devices that are part of the CPG Clock Domain and can be
>> power-managed through their primary clock should be tagged in DT with a
>> proper "power-domains" property.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> There's one thing that bothers me: the implementation is tied to the CPG
> driver, but the code is quite generic. That feels a bit wrong, it would be
> nice to come up with a generic implementation. On the other hand, the
> platform-dependent part is the list of clocks to manage, specified implicitly
> through the "pm_clk_add(dev, NULL)" call. That list needs to be specified
> somewhere, and adding it to the CPG driver is likely the best solution we can
> have at the moment.

This clock management code is identical to the one in pm-rmobile.c.
We may consolidate in the future, if we have more PM Domain support (e.g.
for R-Car Gen2 SYSC). Let's see...

> I'm slightly worried that adding the power-domains property to the DT node
> will introduce backward compatibility issues if we later switch to a different
> way to specify the clocks to manage automatically. I have no specific example
> though.

Specifying the clocks is indeed the hard part. I use the primary clocks, as
that is compatible with what we did in the past in drivers/sh/pm_runtime.c.
I thought about using a special clock name instead, but that may conflict
with an existing driver-specific DT binding for clk-names, and may cause
problems if you have to specify the same clock twice with different clk-names.

> For those reasons,
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

WARNING: multiple messages have this Message-ID (diff)
From: geert@linux-m68k.org (Geert Uytterhoeven)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH/RFC 1/5] clk: shmobile: rcar-gen2: Add CPG Clock Domain support
Date: Wed, 1 Apr 2015 14:13:12 +0200	[thread overview]
Message-ID: <CAMuHMdWuVdOgk6RAzoUtskC3pzz3xs6HmGf5RyrAa3Rs-y56uQ@mail.gmail.com> (raw)
In-Reply-To: <3861934.bVCAbQmBJW@avalon>

Hi Laurent,

On Tue, Mar 31, 2015 at 1:53 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Wednesday 18 March 2015 20:46:53 Geert Uytterhoeven wrote:
>> Add Clock Domain support to the R-Car Gen2 Clock Pulse Generator (CPG)
>> driver using the generic PM Domain.  This allows to power-manage the
>> module clocks of SoC devices that are part of the CPG Clock Domain using
>> Runtime PM, or for system suspend/resume.
>>
>> SoC devices that are part of the CPG Clock Domain and can be
>> power-managed through their primary clock should be tagged in DT with a
>> proper "power-domains" property.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> There's one thing that bothers me: the implementation is tied to the CPG
> driver, but the code is quite generic. That feels a bit wrong, it would be
> nice to come up with a generic implementation. On the other hand, the
> platform-dependent part is the list of clocks to manage, specified implicitly
> through the "pm_clk_add(dev, NULL)" call. That list needs to be specified
> somewhere, and adding it to the CPG driver is likely the best solution we can
> have at the moment.

This clock management code is identical to the one in pm-rmobile.c.
We may consolidate in the future, if we have more PM Domain support (e.g.
for R-Car Gen2 SYSC). Let's see...

> I'm slightly worried that adding the power-domains property to the DT node
> will introduce backward compatibility issues if we later switch to a different
> way to specify the clocks to manage automatically. I have no specific example
> though.

Specifying the clocks is indeed the hard part. I use the primary clocks, as
that is compatible with what we did in the past in drivers/sh/pm_runtime.c.
I thought about using a special clock name instead, but that may conflict
with an existing driver-specific DT binding for clk-names, and may cause
problems if you have to specify the same clock twice with different clk-names.

> For those reasons,
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  reply	other threads:[~2015-04-01 12:13 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-18 19:46 [PATCH/RFC 0/5] ARM: shmobile: rcar-gen2: Add CPG Clock Domain Geert Uytterhoeven
2015-03-18 19:46 ` Geert Uytterhoeven
2015-03-18 19:46 ` Geert Uytterhoeven
2015-03-18 19:46 ` [PATCH/RFC 1/5] clk: shmobile: rcar-gen2: Add CPG Clock Domain support Geert Uytterhoeven
2015-03-18 19:46   ` Geert Uytterhoeven
2015-03-18 19:46   ` Geert Uytterhoeven
2015-03-24 23:00   ` Michael Turquette
2015-03-24 23:00     ` Michael Turquette
2015-03-24 23:00     ` Michael Turquette
2015-03-25  1:04     ` Simon Horman
2015-03-25  1:04       ` Simon Horman
2015-03-25  1:04       ` Simon Horman
2015-03-30  9:58       ` Geert Uytterhoeven
2015-03-30  9:58         ` Geert Uytterhoeven
2015-03-30  9:58         ` Geert Uytterhoeven
2015-03-31  0:16         ` Simon Horman
2015-03-31  0:16           ` Simon Horman
2015-03-31  0:16           ` Simon Horman
2015-03-30 23:53   ` Laurent Pinchart
2015-03-30 23:53     ` Laurent Pinchart
2015-03-30 23:53     ` Laurent Pinchart
2015-04-01 12:13     ` Geert Uytterhoeven [this message]
2015-04-01 12:13       ` Geert Uytterhoeven
2015-04-01 12:13       ` Geert Uytterhoeven
2015-04-01 13:45       ` Laurent Pinchart
2015-04-01 13:45         ` Laurent Pinchart
2015-04-01 13:45         ` Laurent Pinchart
2015-03-31 22:25   ` Kevin Hilman
2015-03-31 22:25     ` Kevin Hilman
2015-03-31 22:25     ` Kevin Hilman
2015-03-18 19:46 ` [PATCH/RFC 2/5] ARM: shmobile: r8a7790 dtsi: Add CPG Clock Domain Geert Uytterhoeven
2015-03-18 19:46   ` Geert Uytterhoeven
2015-03-18 19:46   ` Geert Uytterhoeven
2015-03-18 19:46 ` [PATCH/RFC 3/5] ARM: shmobile: r8a7791 " Geert Uytterhoeven
2015-03-18 19:46   ` Geert Uytterhoeven
2015-03-18 19:46   ` Geert Uytterhoeven
2015-03-18 19:46 ` [PATCH/RFC 4/5] ARM: shmobile: r8a7794 " Geert Uytterhoeven
2015-03-18 19:46   ` Geert Uytterhoeven
2015-03-18 19:46   ` Geert Uytterhoeven
2015-03-18 19:46 ` [PATCH/RFC 5/5] drivers: sh: Disable PM runtime for multi-platform R-Car Gen2 with genpd Geert Uytterhoeven
2015-03-18 19:46   ` Geert Uytterhoeven
2015-03-18 19:46   ` Geert Uytterhoeven
2015-03-20  8:54 ` [PATCH/RFC 0/5] ARM: shmobile: rcar-gen2: Add CPG Clock Domain Ulf Hansson
2015-03-20  8:54   ` Ulf Hansson
2015-03-20  8:54   ` Ulf Hansson

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=CAMuHMdWuVdOgk6RAzoUtskC3pzz3xs6HmGf5RyrAa3Rs-y56uQ@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=linux-arm-kernel@lists.infradead.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.