All of lore.kernel.org
 help / color / mirror / Atom feed
From: JeffyChen <jeffy.chen@rock-chips.com>
To: Tomasz Figa <tfiga@chromium.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Caesar Wang <wxt@rock-chips.com>,
	Elaine Zhang <zhangqing@rock-chips.com>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Ulf Hansson <ulf.hansson@linaro.org>
Subject: Re: [PATCH] soc: rockchip: power-domain: remove PM clocks
Date: Thu, 01 Mar 2018 11:40:40 +0800	[thread overview]
Message-ID: <5A977638.8010506@rock-chips.com> (raw)
In-Reply-To: <CAAFQd5C0GZ9C-pAqAdpuyxaF2xthLPY62a921nmABTbbmYtBmQ@mail.gmail.com>

Hi guys,

if i'm reading the code right, the PM clk means:
1/ the clocks which would be enabled while power on
2/ these clocks are optional, it's ok if anything wrong with them
3/ controlled by pm_domain(or USE_PM_CLK_RUNTIME_OPS & pm_clk_add_notifier)

and currently we're adding all clocks of the attached device as PM clk 
in rockchip PM domain driver, which seems wrong. because we might have 
these kinds of clocks:
1/ critical, should block power on if anything wrong with it(failed to 
get/ prepare/ enable)
2/ optional, could ignore it if anything wrong
3/ only required in some special cases, for example register r/w, and 
doesn't need to stay enabled while power on

so maybe we can:
1/ let the device(dts) or driver decide which clock is PM clk, and add 
it using *pm_clk_add* APIs (even of_pm_clk_add_clks() if all clocks are 
pm clk)

2/ add support for critical PM clk, which would return error to the 
driver if anything wrong

3/ make sure PM clk always be controlled(otherwise it might be 
unexpected disabled by other clocks under the same clk parent?):
  a) make sure Runtime PM is always enabled. and as discussed, we can 
select PM in ARCH_ROCKCHIP

  b) make sure the device has a PM domain to control PM clk:
select ROCKCHIP_PM_DOMAINS for ARCH_ROCKCHIP(that would also select 
PM_GENERIC_DOMAINS)

check dev->pm_domain before hand over PM clk, since we only care about 
EPROBE_DEFER when attach PM domain:
         ret = dev_pm_domain_attach(_dev, true);
         if (ret != -EPROBE_DEFER) {
                 if (drv->probe) {
                         ret = drv->probe(dev);

or

  c) make pm_clk_suspend/pm_clk_resume part of the generic PM Runtime 
flow(even without a PM domain)


On 02/28/2018 10:07 PM, Tomasz Figa wrote:
> On Wed, Feb 28, 2018 at 10:11 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> Hi Tomasz,
>>
>> On Wed, Feb 28, 2018 at 1:49 PM, Tomasz Figa <tfiga@chromium.org> wrote:
>>> On Wed, Feb 28, 2018 at 9:32 PM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>> On Wed, Feb 28, 2018 at 1:29 PM, Tomasz Figa <tfiga@chromium.org> wrote:
>>>>> Also, how about systems where runtime PM is disabled? I think that's
>>>>> one of the reasons we control the clocks explicitly in the drivers
>>>>> anyway.
>>>>
>>>> On many platforms, Runtime PM is always enabled.
>>>
>>> Can we make such assumption? If so, could we just make an explicit
>>> "select PM_RUNTIME" in Kconfig of the SoC?
>>
>> Note that the PM_RUNTIME symbol was removed in commit 464ed18ebdb6236f
>> ("PM: Eliminate CONFIG_PM_RUNTIME"), in favor of plain PM.
>>
>> The following already select PM unconditionally:
>>    - ARCH_OMAP2PLUS_TYPICAL
>>    - ARCH_RENESAS (except EMEV2)
>>    - ARCH_TEGRA
>>    - ARCH_VEXPRESS
>
> Thanks! Sounds like we might be able to simplify a lot of things with
> doing the same for Rockchip.
>
> Best regards,
> Tomasz
>
>
>

WARNING: multiple messages have this Message-ID (diff)
From: jeffy.chen@rock-chips.com (JeffyChen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] soc: rockchip: power-domain: remove PM clocks
Date: Thu, 01 Mar 2018 11:40:40 +0800	[thread overview]
Message-ID: <5A977638.8010506@rock-chips.com> (raw)
In-Reply-To: <CAAFQd5C0GZ9C-pAqAdpuyxaF2xthLPY62a921nmABTbbmYtBmQ@mail.gmail.com>

Hi guys,

if i'm reading the code right, the PM clk means:
1/ the clocks which would be enabled while power on
2/ these clocks are optional, it's ok if anything wrong with them
3/ controlled by pm_domain(or USE_PM_CLK_RUNTIME_OPS & pm_clk_add_notifier)

and currently we're adding all clocks of the attached device as PM clk 
in rockchip PM domain driver, which seems wrong. because we might have 
these kinds of clocks:
1/ critical, should block power on if anything wrong with it(failed to 
get/ prepare/ enable)
2/ optional, could ignore it if anything wrong
3/ only required in some special cases, for example register r/w, and 
doesn't need to stay enabled while power on

so maybe we can:
1/ let the device(dts) or driver decide which clock is PM clk, and add 
it using *pm_clk_add* APIs (even of_pm_clk_add_clks() if all clocks are 
pm clk)

2/ add support for critical PM clk, which would return error to the 
driver if anything wrong

3/ make sure PM clk always be controlled(otherwise it might be 
unexpected disabled by other clocks under the same clk parent?):
  a) make sure Runtime PM is always enabled. and as discussed, we can 
select PM in ARCH_ROCKCHIP

  b) make sure the device has a PM domain to control PM clk:
select ROCKCHIP_PM_DOMAINS for ARCH_ROCKCHIP(that would also select 
PM_GENERIC_DOMAINS)

check dev->pm_domain before hand over PM clk, since we only care about 
EPROBE_DEFER when attach PM domain:
         ret = dev_pm_domain_attach(_dev, true);
         if (ret != -EPROBE_DEFER) {
                 if (drv->probe) {
                         ret = drv->probe(dev);

or

  c) make pm_clk_suspend/pm_clk_resume part of the generic PM Runtime 
flow(even without a PM domain)


On 02/28/2018 10:07 PM, Tomasz Figa wrote:
> On Wed, Feb 28, 2018 at 10:11 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> Hi Tomasz,
>>
>> On Wed, Feb 28, 2018 at 1:49 PM, Tomasz Figa <tfiga@chromium.org> wrote:
>>> On Wed, Feb 28, 2018 at 9:32 PM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>> On Wed, Feb 28, 2018 at 1:29 PM, Tomasz Figa <tfiga@chromium.org> wrote:
>>>>> Also, how about systems where runtime PM is disabled? I think that's
>>>>> one of the reasons we control the clocks explicitly in the drivers
>>>>> anyway.
>>>>
>>>> On many platforms, Runtime PM is always enabled.
>>>
>>> Can we make such assumption? If so, could we just make an explicit
>>> "select PM_RUNTIME" in Kconfig of the SoC?
>>
>> Note that the PM_RUNTIME symbol was removed in commit 464ed18ebdb6236f
>> ("PM: Eliminate CONFIG_PM_RUNTIME"), in favor of plain PM.
>>
>> The following already select PM unconditionally:
>>    - ARCH_OMAP2PLUS_TYPICAL
>>    - ARCH_RENESAS (except EMEV2)
>>    - ARCH_TEGRA
>>    - ARCH_VEXPRESS
>
> Thanks! Sounds like we might be able to simplify a lot of things with
> doing the same for Rockchip.
>
> Best regards,
> Tomasz
>
>
>

  reply	other threads:[~2018-03-01  3:40 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-28 11:11 [PATCH] soc: rockchip: power-domain: remove PM clocks Jeffy Chen
2018-02-28 11:11 ` Jeffy Chen
2018-02-28 11:59 ` Heiko Stübner
2018-02-28 11:59   ` Heiko Stübner
2018-02-28 12:17 ` Geert Uytterhoeven
2018-02-28 12:17   ` Geert Uytterhoeven
2018-02-28 12:29   ` Tomasz Figa
2018-02-28 12:29     ` Tomasz Figa
2018-02-28 12:32     ` Geert Uytterhoeven
2018-02-28 12:32       ` Geert Uytterhoeven
2018-02-28 12:49       ` Tomasz Figa
2018-02-28 12:49         ` Tomasz Figa
2018-02-28 13:11         ` Geert Uytterhoeven
2018-02-28 13:11           ` Geert Uytterhoeven
2018-02-28 14:07           ` Tomasz Figa
2018-02-28 14:07             ` Tomasz Figa
2018-03-01  3:40             ` JeffyChen [this message]
2018-03-01  3:40               ` JeffyChen
2018-03-01  8:33               ` Geert Uytterhoeven
2018-03-01  8:33                 ` Geert Uytterhoeven
2018-03-01  9:09                 ` JeffyChen
2018-03-01  9:09                   ` JeffyChen
2018-03-01 10:18                 ` Ulf Hansson
2018-03-01 10:18                   ` Ulf Hansson
2018-03-01 10:37                   ` Geert Uytterhoeven
2018-03-01 10:37                     ` Geert Uytterhoeven
2018-03-01 11:22                     ` Ulf Hansson
2018-03-01 11:22                       ` Ulf Hansson
2018-03-01 11:54                       ` Geert Uytterhoeven
2018-03-01 11:54                         ` Geert Uytterhoeven
2018-02-28 12:36   ` JeffyChen
2018-02-28 12:36     ` JeffyChen

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=5A977638.8010506@rock-chips.com \
    --to=jeffy.chen@rock-chips.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=geert@linux-m68k.org \
    --cc=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=robin.murphy@arm.com \
    --cc=tfiga@chromium.org \
    --cc=ulf.hansson@linaro.org \
    --cc=wxt@rock-chips.com \
    --cc=zhangqing@rock-chips.com \
    /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.