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
>
>
>
next prev parent reply other threads:[~2018-03-01 3:40 UTC|newest]
Thread overview: 16+ 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:59 ` Heiko Stübner
2018-02-28 12:17 ` Geert Uytterhoeven
2018-02-28 12:29 ` Tomasz Figa
2018-02-28 12:32 ` Geert Uytterhoeven
2018-02-28 12:49 ` Tomasz Figa
2018-02-28 13:11 ` Geert Uytterhoeven
2018-02-28 14:07 ` Tomasz Figa
2018-03-01 3:40 ` JeffyChen [this message]
2018-03-01 8:33 ` Geert Uytterhoeven
2018-03-01 9:09 ` JeffyChen
2018-03-01 10:18 ` Ulf Hansson
2018-03-01 10:37 ` Geert Uytterhoeven
2018-03-01 11:22 ` Ulf Hansson
2018-03-01 11:54 ` Geert Uytterhoeven
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox