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
>
>
>
next prev parent 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.