All of lore.kernel.org
 help / color / mirror / Atom feed
From: khilman@kernel.org (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/3] ARM: rk3288 : Add PM Domain support
Date: Thu, 02 Oct 2014 08:36:16 -0700	[thread overview]
Message-ID: <7hr3yqtrf3.fsf@deeprootsystems.com> (raw)
In-Reply-To: <542D1F1B.8040501@ti.com> (Grygorii Strashko's message of "Thu, 2 Oct 2014 12:47:07 +0300")

Grygorii Strashko <grygorii.strashko@ti.com> writes:

> Hi,
>
> On 10/01/2014 11:25 PM, Kevin Hilman wrote:
>> Doug Anderson <dianders@chromium.org> writes:
>> 
>>>
>>> On Wed, Oct 1, 2014 at 9:51 AM, Kevin Hilman <khilman@kernel.org> wrote:
>>>> +Geert, Ulf
>>>>
>>>> "jinkun.hong" <jinkun.hong@rock-chips.com> writes:
>>>>
>>>>> From: "jinkun.hong" <jinkun.hong@rock-chips.com>
>>>>>
>>>>> Use PM Domain framework to manage the clock.
>>>>
>>>> Which clock?  This changelog needs a more thorough description.
>>>
>>>
>>> I think what he meant was:
>>>
>>> Use the generic PM Domain framework for Rockchip
>>>
>>> ...but I agree that he could describe it more.
>>>
>>>
>>>> Also,
>>>> with this series alone, it's not clear how the power-domain transitions
>>>> ever happen, since I don't see any devices hooked up to your power
>>>> domains, or do I see your platform using runtime PM.  In order for this
>>>> to be reviewed properely, it's important for reviewers to be able to see
>>>> how this PM domain support will be used.
>>>
>>> I noticed that too.  As the patchset currently stands it only ever disables...
>>>
>>>
>>>> Also, remember that the DT is supposed to reflect the hardware, not the
>>>> design choices of linux drivers.  Because of that, it's a little
>>>> surprising to see clocks as properties of a power domain because clocks
>>>> are usually properties of devices.
>>>
>>> I haven't dug all the way into the hardware to figure out why (or if
>>> this is really necessary), but right now the rockchip power domain
>>> driver only leaves these clocks on during the powering on and powering
>>> off of the power domain.  In other words to turn on the power domain:
>>>
>>> 1. Turn on all clocks
>>> 2. Flip the bit that sets the power domain on
>>> 3. Wait until hardware says power domain is on.
>>> 4. Turn off all the clocks.
>>>
>>> ...and to turn off:
>>>
>>> 1. Turn on all clocks
>>> 2. Flip the bit that sets the power domain off
>>> 3. Wait until hardware says power domain is off.
>>> 2. Turn off all the clocks.
>>>
>>> ...if the above is actually necessary when turning on and off power
>>> domains then it seems like it is actually describing the hardware.
>> 
>> Yes, I understand. The need to have some *device* clocks enabled when
>> powering on/off the power-domain itself is quite common across many
>> SoCs.
>> 
>> My point is that these clocks are actually properties of *devices*, not
>> the power-domain itself.  In the shmobile example I pointed to, the
>> clocks are properties of the devices in DT, and the devices are attached
>> to the powerdomain.  When the devices are connected to the power-domain,
>> the custom attach function looks up all the *device* clocks and and
>> addes them to the power-domain using pm_clk_add.
>
> Sorry, but this is not quite right :(
> Patches from Geert will add only first clock for device and not all
> of them. 
> The right way to add all clocks for device from DT using 
> generic PM domain represented in my series:
>  
>  ARM: keystone: pm: switch to use generic pm domains
>  http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg735601.html

Thanks for clarifying.

Kevin

WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@kernel.org>
To: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Doug Anderson <dianders@chromium.org>,
	Mark Rutland <mark.rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Russell King <linux@arm.linux.org.uk>,
	Heiko Stuebner <heiko@sntech.de>, Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	"jinkun.hong" <jinkun.hong@rock-chips.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-rockchip@lists.infradead.org,
	Rob Herring <robh+dt@kernel.org>,
	Kumar Gala <galak@codeaurora.org>,
	Grant Likely <grant.likely@linaro.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 0/3] ARM: rk3288 : Add PM Domain support
Date: Thu, 02 Oct 2014 08:36:16 -0700	[thread overview]
Message-ID: <7hr3yqtrf3.fsf@deeprootsystems.com> (raw)
In-Reply-To: <542D1F1B.8040501@ti.com> (Grygorii Strashko's message of "Thu, 2 Oct 2014 12:47:07 +0300")

Grygorii Strashko <grygorii.strashko@ti.com> writes:

> Hi,
>
> On 10/01/2014 11:25 PM, Kevin Hilman wrote:
>> Doug Anderson <dianders@chromium.org> writes:
>> 
>>>
>>> On Wed, Oct 1, 2014 at 9:51 AM, Kevin Hilman <khilman@kernel.org> wrote:
>>>> +Geert, Ulf
>>>>
>>>> "jinkun.hong" <jinkun.hong@rock-chips.com> writes:
>>>>
>>>>> From: "jinkun.hong" <jinkun.hong@rock-chips.com>
>>>>>
>>>>> Use PM Domain framework to manage the clock.
>>>>
>>>> Which clock?  This changelog needs a more thorough description.
>>>
>>>
>>> I think what he meant was:
>>>
>>> Use the generic PM Domain framework for Rockchip
>>>
>>> ...but I agree that he could describe it more.
>>>
>>>
>>>> Also,
>>>> with this series alone, it's not clear how the power-domain transitions
>>>> ever happen, since I don't see any devices hooked up to your power
>>>> domains, or do I see your platform using runtime PM.  In order for this
>>>> to be reviewed properely, it's important for reviewers to be able to see
>>>> how this PM domain support will be used.
>>>
>>> I noticed that too.  As the patchset currently stands it only ever disables...
>>>
>>>
>>>> Also, remember that the DT is supposed to reflect the hardware, not the
>>>> design choices of linux drivers.  Because of that, it's a little
>>>> surprising to see clocks as properties of a power domain because clocks
>>>> are usually properties of devices.
>>>
>>> I haven't dug all the way into the hardware to figure out why (or if
>>> this is really necessary), but right now the rockchip power domain
>>> driver only leaves these clocks on during the powering on and powering
>>> off of the power domain.  In other words to turn on the power domain:
>>>
>>> 1. Turn on all clocks
>>> 2. Flip the bit that sets the power domain on
>>> 3. Wait until hardware says power domain is on.
>>> 4. Turn off all the clocks.
>>>
>>> ...and to turn off:
>>>
>>> 1. Turn on all clocks
>>> 2. Flip the bit that sets the power domain off
>>> 3. Wait until hardware says power domain is off.
>>> 2. Turn off all the clocks.
>>>
>>> ...if the above is actually necessary when turning on and off power
>>> domains then it seems like it is actually describing the hardware.
>> 
>> Yes, I understand. The need to have some *device* clocks enabled when
>> powering on/off the power-domain itself is quite common across many
>> SoCs.
>> 
>> My point is that these clocks are actually properties of *devices*, not
>> the power-domain itself.  In the shmobile example I pointed to, the
>> clocks are properties of the devices in DT, and the devices are attached
>> to the powerdomain.  When the devices are connected to the power-domain,
>> the custom attach function looks up all the *device* clocks and and
>> addes them to the power-domain using pm_clk_add.
>
> Sorry, but this is not quite right :(
> Patches from Geert will add only first clock for device and not all
> of them. 
> The right way to add all clocks for device from DT using 
> generic PM domain represented in my series:
>  
>  ARM: keystone: pm: switch to use generic pm domains
>  http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg735601.html

Thanks for clarifying.

Kevin

WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@kernel.org>
To: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Doug Anderson <dianders@chromium.org>,
	Mark Rutland <mark.rutland@arm.com>,
	"devicetree\@vger.kernel.org" <devicetree@vger.kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Russell King <linux@arm.linux.org.uk>,
	Heiko Stuebner <heiko@sntech.de>, Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	"jinkun.hong" <jinkun.hong@rock-chips.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	"linux-doc\@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	<linux-rockchip@lists.infradead.org>,
	Rob Herring <robh+dt@kernel.org>,
	Kumar Gala <galak@codeaurora.org>,
	Grant Likely <grant.likely@linaro.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	"linux-arm-kernel\@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 0/3] ARM: rk3288 : Add PM Domain support
Date: Thu, 02 Oct 2014 08:36:16 -0700	[thread overview]
Message-ID: <7hr3yqtrf3.fsf@deeprootsystems.com> (raw)
In-Reply-To: <542D1F1B.8040501@ti.com> (Grygorii Strashko's message of "Thu, 2 Oct 2014 12:47:07 +0300")

Grygorii Strashko <grygorii.strashko@ti.com> writes:

> Hi,
>
> On 10/01/2014 11:25 PM, Kevin Hilman wrote:
>> Doug Anderson <dianders@chromium.org> writes:
>> 
>>>
>>> On Wed, Oct 1, 2014 at 9:51 AM, Kevin Hilman <khilman@kernel.org> wrote:
>>>> +Geert, Ulf
>>>>
>>>> "jinkun.hong" <jinkun.hong@rock-chips.com> writes:
>>>>
>>>>> From: "jinkun.hong" <jinkun.hong@rock-chips.com>
>>>>>
>>>>> Use PM Domain framework to manage the clock.
>>>>
>>>> Which clock?  This changelog needs a more thorough description.
>>>
>>>
>>> I think what he meant was:
>>>
>>> Use the generic PM Domain framework for Rockchip
>>>
>>> ...but I agree that he could describe it more.
>>>
>>>
>>>> Also,
>>>> with this series alone, it's not clear how the power-domain transitions
>>>> ever happen, since I don't see any devices hooked up to your power
>>>> domains, or do I see your platform using runtime PM.  In order for this
>>>> to be reviewed properely, it's important for reviewers to be able to see
>>>> how this PM domain support will be used.
>>>
>>> I noticed that too.  As the patchset currently stands it only ever disables...
>>>
>>>
>>>> Also, remember that the DT is supposed to reflect the hardware, not the
>>>> design choices of linux drivers.  Because of that, it's a little
>>>> surprising to see clocks as properties of a power domain because clocks
>>>> are usually properties of devices.
>>>
>>> I haven't dug all the way into the hardware to figure out why (or if
>>> this is really necessary), but right now the rockchip power domain
>>> driver only leaves these clocks on during the powering on and powering
>>> off of the power domain.  In other words to turn on the power domain:
>>>
>>> 1. Turn on all clocks
>>> 2. Flip the bit that sets the power domain on
>>> 3. Wait until hardware says power domain is on.
>>> 4. Turn off all the clocks.
>>>
>>> ...and to turn off:
>>>
>>> 1. Turn on all clocks
>>> 2. Flip the bit that sets the power domain off
>>> 3. Wait until hardware says power domain is off.
>>> 2. Turn off all the clocks.
>>>
>>> ...if the above is actually necessary when turning on and off power
>>> domains then it seems like it is actually describing the hardware.
>> 
>> Yes, I understand. The need to have some *device* clocks enabled when
>> powering on/off the power-domain itself is quite common across many
>> SoCs.
>> 
>> My point is that these clocks are actually properties of *devices*, not
>> the power-domain itself.  In the shmobile example I pointed to, the
>> clocks are properties of the devices in DT, and the devices are attached
>> to the powerdomain.  When the devices are connected to the power-domain,
>> the custom attach function looks up all the *device* clocks and and
>> addes them to the power-domain using pm_clk_add.
>
> Sorry, but this is not quite right :(
> Patches from Geert will add only first clock for device and not all
> of them. 
> The right way to add all clocks for device from DT using 
> generic PM domain represented in my series:
>  
>  ARM: keystone: pm: switch to use generic pm domains
>  http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg735601.html

Thanks for clarifying.

Kevin

  reply	other threads:[~2014-10-02 15:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-28 10:22 [PATCH v2 0/3] ARM: rk3288 : Add PM Domain support jinkun.hong
2014-09-28 10:22 ` jinkun.hong
2014-09-28 10:22 ` [PATCH v2 1/3] power-domain: add power domain drivers for Rockchip platform jinkun.hong
2014-09-28 10:22   ` jinkun.hong
2014-09-28 10:22 ` [PATCH v2 2/3] dt-bindings: add document of Rockchip power domain jinkun.hong
2014-09-28 10:22   ` jinkun.hong
2014-09-28 10:22   ` jinkun.hong
2014-09-28 10:22 ` [PATCH v2 3/3] ARM: dts: add rk3288 power-domain node jinkun.hong
2014-09-28 10:22   ` jinkun.hong
2014-10-01 16:51 ` [PATCH v2 0/3] ARM: rk3288 : Add PM Domain support Kevin Hilman
2014-10-01 16:51   ` Kevin Hilman
2014-10-01 20:07   ` Doug Anderson
2014-10-01 20:07     ` Doug Anderson
2014-10-01 20:25     ` Kevin Hilman
2014-10-01 20:25       ` Kevin Hilman
2014-10-01 20:25       ` Kevin Hilman
2014-10-02  9:47       ` Grygorii Strashko
2014-10-02  9:47         ` Grygorii Strashko
2014-10-02  9:47         ` Grygorii Strashko
2014-10-02 15:36         ` Kevin Hilman [this message]
2014-10-02 15:36           ` Kevin Hilman
2014-10-02 15:36           ` Kevin Hilman

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=7hr3yqtrf3.fsf@deeprootsystems.com \
    --to=khilman@kernel.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.