From: Kevin Hilman <khilman@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Rajendra Nayak <rnayak@codeaurora.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Subject: Re: [RFC/RFT 2/6] clk: qcom: Add runtime support to handle clocks using PM clocks
Date: Mon, 27 Apr 2015 13:02:02 -0700 [thread overview]
Message-ID: <7hh9s1xrut.fsf@deeprootsystems.com> (raw)
In-Reply-To: <CAMuHMdV_WD7vay-5VC20izUWFjc8rSW4wZQq6Y3xAa+SU0Quig@mail.gmail.com> (Geert Uytterhoeven's message of "Sun, 26 Apr 2015 10:49:26 +0200")
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> On Fri, Apr 24, 2015 at 12:58 PM, Rajendra Nayak <rnayak@codeaurora.org> wrote:
>>> Second, I want to see less users of pm_clk_add_notifier() since it's
>>> not the proper/long-term way of how to assign PM domain pointers to a
>>> device. Instead that shall be done at device registration point. In
>>> your case while parsing the DT nodes and adding devices onto to their
>>> buses.
>>
>> but these are devices which do not really have a controllable power
>> domain, they just have controllable clocks.
>>
>>> Yes, I understand that it will requires quite some work to adopt to
>>> this behaviour - but that how it shall be done.
>>>
>>> Finally, an important note, you don't need to use PM domains for these
>>> devices at all and thus you don't need to fix what I propose. Instead
>>> you only have to implement the runtime PM callbacks for each driver
>>> and manage the clocks from there. That is probably also a easier
>>> solution.
>>
>> But that would mean I repeat the same code in all drivers to do a
>> clk_get/prepare/enable/disable/unprepare of the same "core" and "iface"
>> clocks. I thought we have clock_ops.c just to avoid that (atleast up
>> until we have a better way of doing it)
>> And there are atleast a few architecture which have used it to avoid the
>> duplication across all drivers (omap1/davinci/sh/keystone)
>
> At least for arm/shmobile, we're planning to move away from this, cfr.
> http://www.spinics.net/lists/linux-sh/msg41114.html
Just to clarify for Rajendra's sake...
SH is moving away from the pm_clk_add_notifier(), but not duplicating
the clk_get/prepare/enable/disable/unprepare across all the drivers.
Rather, they're using a genpd to model the clock domain, and taking
advantage of the pm_domain speciic attach callback to attach the PM
clocks.
This should work for qcom also assuming that these device nodes don't
also need to belong to a different PM domain.
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: khilman@kernel.org (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC/RFT 2/6] clk: qcom: Add runtime support to handle clocks using PM clocks
Date: Mon, 27 Apr 2015 13:02:02 -0700 [thread overview]
Message-ID: <7hh9s1xrut.fsf@deeprootsystems.com> (raw)
In-Reply-To: <CAMuHMdV_WD7vay-5VC20izUWFjc8rSW4wZQq6Y3xAa+SU0Quig@mail.gmail.com> (Geert Uytterhoeven's message of "Sun, 26 Apr 2015 10:49:26 +0200")
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> On Fri, Apr 24, 2015 at 12:58 PM, Rajendra Nayak <rnayak@codeaurora.org> wrote:
>>> Second, I want to see less users of pm_clk_add_notifier() since it's
>>> not the proper/long-term way of how to assign PM domain pointers to a
>>> device. Instead that shall be done at device registration point. In
>>> your case while parsing the DT nodes and adding devices onto to their
>>> buses.
>>
>> but these are devices which do not really have a controllable power
>> domain, they just have controllable clocks.
>>
>>> Yes, I understand that it will requires quite some work to adopt to
>>> this behaviour - but that how it shall be done.
>>>
>>> Finally, an important note, you don't need to use PM domains for these
>>> devices at all and thus you don't need to fix what I propose. Instead
>>> you only have to implement the runtime PM callbacks for each driver
>>> and manage the clocks from there. That is probably also a easier
>>> solution.
>>
>> But that would mean I repeat the same code in all drivers to do a
>> clk_get/prepare/enable/disable/unprepare of the same "core" and "iface"
>> clocks. I thought we have clock_ops.c just to avoid that (atleast up
>> until we have a better way of doing it)
>> And there are atleast a few architecture which have used it to avoid the
>> duplication across all drivers (omap1/davinci/sh/keystone)
>
> At least for arm/shmobile, we're planning to move away from this, cfr.
> http://www.spinics.net/lists/linux-sh/msg41114.html
Just to clarify for Rajendra's sake...
SH is moving away from the pm_clk_add_notifier(), but not duplicating
the clk_get/prepare/enable/disable/unprepare across all the drivers.
Rather, they're using a genpd to model the clock domain, and taking
advantage of the pm_domain speciic attach callback to attach the PM
clocks.
This should work for qcom also assuming that these device nodes don't
also need to belong to a different PM domain.
Kevin
next prev parent reply other threads:[~2015-04-27 20:02 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-23 8:45 [RFC/RFT 0/6] qcom: Add runtime PM support Rajendra Nayak
2015-04-23 8:45 ` Rajendra Nayak
2015-04-23 8:45 ` [RFC/RFT 1/6] PM / clock_ops: Make pm_clk_notify() do nothing in case DT passes power-domains Rajendra Nayak
2015-04-23 8:45 ` Rajendra Nayak
2015-04-23 8:45 ` [RFC/RFT 2/6] clk: qcom: Add runtime support to handle clocks using PM clocks Rajendra Nayak
2015-04-23 8:45 ` Rajendra Nayak
2015-04-24 10:03 ` Ulf Hansson
2015-04-24 10:03 ` Ulf Hansson
2015-04-24 10:58 ` Rajendra Nayak
2015-04-24 10:58 ` Rajendra Nayak
2015-04-26 8:49 ` Geert Uytterhoeven
2015-04-26 8:49 ` Geert Uytterhoeven
2015-04-27 20:02 ` Kevin Hilman [this message]
2015-04-27 20:02 ` Kevin Hilman
2015-04-28 2:52 ` Rajendra Nayak
2015-04-28 2:52 ` Rajendra Nayak
2015-04-28 7:25 ` Geert Uytterhoeven
2015-04-28 7:25 ` Geert Uytterhoeven
2015-04-29 9:49 ` Rajendra Nayak
2015-04-29 9:49 ` Rajendra Nayak
2015-04-29 11:30 ` Geert Uytterhoeven
2015-04-29 11:30 ` Geert Uytterhoeven
2015-04-29 12:31 ` Ulf Hansson
2015-04-29 12:31 ` Ulf Hansson
2015-04-29 13:08 ` Geert Uytterhoeven
2015-04-29 13:08 ` Geert Uytterhoeven
2015-04-30 6:21 ` Ulf Hansson
2015-04-30 6:21 ` Ulf Hansson
2015-04-30 9:02 ` Ulf Hansson
2015-04-30 9:02 ` Ulf Hansson
2015-04-27 7:08 ` Ulf Hansson
2015-04-27 7:08 ` Ulf Hansson
2015-04-23 8:45 ` [RFC/RFT 3/6] serial: msm: convert driver to use runtime PM apis Rajendra Nayak
2015-04-23 8:45 ` Rajendra Nayak
2015-04-29 0:16 ` Stephen Boyd
2015-04-29 0:16 ` Stephen Boyd
2015-04-29 3:15 ` Rajendra Nayak
2015-04-29 3:15 ` Rajendra Nayak
2015-04-23 8:45 ` [RFC/RFT 4/6] mmc: sdhci-msm: " Rajendra Nayak
2015-04-23 8:45 ` Rajendra Nayak
2015-04-23 13:21 ` Ulf Hansson
2015-04-23 13:21 ` Ulf Hansson
2015-04-23 13:42 ` Rajendra Nayak
2015-04-23 13:42 ` Rajendra Nayak
2015-04-23 21:15 ` Kevin Hilman
2015-04-23 21:15 ` Kevin Hilman
2015-04-24 0:45 ` Rajendra Nayak
2015-04-24 0:45 ` Rajendra Nayak
2015-04-23 13:43 ` Rajendra Nayak
2015-04-23 13:43 ` Rajendra Nayak
2015-04-23 8:45 ` [RFC/RFT 5/6] i2c: qup: Get rid of clock handling as its done using runtime callbacks Rajendra Nayak
2015-04-23 8:45 ` Rajendra Nayak
2015-04-23 21:16 ` Kevin Hilman
2015-04-23 21:16 ` Kevin Hilman
2015-04-24 2:32 ` Rajendra Nayak
2015-04-24 2:32 ` Rajendra Nayak
2015-04-25 7:01 ` Ivan T. Ivanov
2015-04-25 7:01 ` Ivan T. Ivanov
2015-04-27 2:36 ` Rajendra Nayak
2015-04-27 2:36 ` Rajendra Nayak
2015-04-23 8:45 ` [RFC/RFT 6/6] spi: " Rajendra Nayak
2015-04-23 8:45 ` Rajendra Nayak
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=7hh9s1xrut.fsf@deeprootsystems.com \
--to=khilman@kernel.org \
--cc=geert@linux-m68k.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rnayak@codeaurora.org \
--cc=ulf.hansson@linaro.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.