All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lina Iyer <lina.iyer@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: ulf.hansson@linaro.org, khilman@kernel.org,
	linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	andy.gross@linaro.org, sboyd@codeaurora.org,
	linux-arm-msm@vger.kernel.org, brendan.jackman@arm.com,
	lorenzo.pieralisi@arm.com, sudeep.holla@arm.com,
	Juri.Lelli@arm.com
Subject: Re: [PATCH v3 [fix]] PM / doc: Update device documentation for devices in IRQ safe PM domains
Date: Mon, 24 Oct 2016 15:17:05 -0600	[thread overview]
Message-ID: <20161024211705.GG72940@linaro.org> (raw)
In-Reply-To: <3700155.5AlzjeyN5H@vostro.rjw.lan>

On Mon, Oct 24 2016 at 15:15 -0600, Rafael J. Wysocki wrote:
>On Monday, October 24, 2016 10:16:05 AM Lina Iyer wrote:
>> On Sat, Oct 22 2016 at 18:19 -0600, Rafael J. Wysocki wrote:
>> >On Friday, October 21, 2016 03:52:55 PM Lina Iyer wrote:
>> >> Update documentation to reflect the changes made to support IRQ safe PM
>> >> domains.
>> >>
>> >> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> >> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
>> >> ---
>> >> Changes since v3:
>> >> - Moved para to the end of the section
>> >> - Added clause for all IRQ safe devices in a domain
>> >> - Cleanup explanation of nested domains
>> >> ---
>> >>  Documentation/power/devices.txt | 11 ++++++++++-
>> >>  1 file changed, 10 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
>> >> index 8ba6625..9218ce6 100644
>> >> --- a/Documentation/power/devices.txt
>> >> +++ b/Documentation/power/devices.txt
>> >> @@ -607,7 +607,9 @@ individually.  Instead, a set of devices sharing a power resource can be put
>> >>  into a low-power state together at the same time by turning off the shared
>> >>  power resource.  Of course, they also need to be put into the full-power state
>> >>  together, by turning the shared power resource on.  A set of devices with this
>> >> -property is often referred to as a power domain.
>> >> +property is often referred to as a power domain. A power domain may also be
>> >> +nested inside another power domain. The nested domain is referred to as the
>> >> +sub-domain of the parent domain.
>> >>
>> >>  Support for power domains is provided through the pm_domain field of struct
>> >>  device.  This field is a pointer to an object of type struct dev_pm_domain,
>> >> @@ -629,6 +631,13 @@ support for power domains into subsystem-level callbacks, for example by
>> >>  modifying the platform bus type.  Other platforms need not implement it or take
>> >>  it into account in any way.
>> >>
>> >> +Devices and PM domains may be defined as IRQ-safe, if they can be powered
>> >> +on/off even when the IRQs are disabled.
>> >
>> >What IRQ-safe means for devices is that their runtime PM callbacks may be
>> >invoked with interrupts disabled on the local CPU.  I guess the meaning of
>> >IRQ-safe for PM domains is analogous, but the above isn't precise enough to me.
>> >
>> >> An IRQ-safe device in a domain will
>> >> +disallow power management on the domain, unless the domain is also defined as
>> >> +IRQ-safe. In other words, a domain containing all IRQ-safe devices must also
>> >> +be defined as IRQ-safe. Another restriction this framework imposes on the
>> >> +parent domain of an IRQ-safe domain is that the parent domain must also be
>> >> +defined as IRQ-safe.
>> >
>> >What about this:
>> >
>> >"Devices may be defined as IRQ-safe which indicates to the PM core that their
>> >runtime PM callbacks may be invoked with disabled interrupts (see
>> >Documentation/power/runtime_pm.txt for more information).  If an IRQ-safe
>> >device belongs to a PM domain, the runtime PM of the domain will be disallowed,
>> >unless the domain itself is defined as IRQ-safe.  However, a PM domain can only
>> >be defined as IRQ-safe if all of the devices in it are IRQ-safe.
>> >
>> This is correct. But the last line may need a bit of modification. If
>> all devices in a PM domain are IRQ-safe and the domain is NOT, then it
>> it is a valid combination just that the domain would never do runtime
>> PM.
>
>That doesn't contradict the last sentence of mine above.  I guess what you mean
>is that having a non-IRQ-safe device in an IRQ-safe domain is a valid
>configuration.  I wonder how it works then. :-)
>
>In any case, what about changing that sentence to something like:
>
>"However, it only makes sense to define a PM domain as IRQ-safe if all devices
>in it are IRQ-safe."
>
That's precise. I will add your para instead of mine to the
documentation.

Thanks,
Lina
>

WARNING: multiple messages have this Message-ID (diff)
From: lina.iyer@linaro.org (Lina Iyer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 [fix]] PM / doc: Update device documentation for devices in IRQ safe PM domains
Date: Mon, 24 Oct 2016 15:17:05 -0600	[thread overview]
Message-ID: <20161024211705.GG72940@linaro.org> (raw)
In-Reply-To: <3700155.5AlzjeyN5H@vostro.rjw.lan>

On Mon, Oct 24 2016 at 15:15 -0600, Rafael J. Wysocki wrote:
>On Monday, October 24, 2016 10:16:05 AM Lina Iyer wrote:
>> On Sat, Oct 22 2016 at 18:19 -0600, Rafael J. Wysocki wrote:
>> >On Friday, October 21, 2016 03:52:55 PM Lina Iyer wrote:
>> >> Update documentation to reflect the changes made to support IRQ safe PM
>> >> domains.
>> >>
>> >> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> >> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
>> >> ---
>> >> Changes since v3:
>> >> - Moved para to the end of the section
>> >> - Added clause for all IRQ safe devices in a domain
>> >> - Cleanup explanation of nested domains
>> >> ---
>> >>  Documentation/power/devices.txt | 11 ++++++++++-
>> >>  1 file changed, 10 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
>> >> index 8ba6625..9218ce6 100644
>> >> --- a/Documentation/power/devices.txt
>> >> +++ b/Documentation/power/devices.txt
>> >> @@ -607,7 +607,9 @@ individually.  Instead, a set of devices sharing a power resource can be put
>> >>  into a low-power state together at the same time by turning off the shared
>> >>  power resource.  Of course, they also need to be put into the full-power state
>> >>  together, by turning the shared power resource on.  A set of devices with this
>> >> -property is often referred to as a power domain.
>> >> +property is often referred to as a power domain. A power domain may also be
>> >> +nested inside another power domain. The nested domain is referred to as the
>> >> +sub-domain of the parent domain.
>> >>
>> >>  Support for power domains is provided through the pm_domain field of struct
>> >>  device.  This field is a pointer to an object of type struct dev_pm_domain,
>> >> @@ -629,6 +631,13 @@ support for power domains into subsystem-level callbacks, for example by
>> >>  modifying the platform bus type.  Other platforms need not implement it or take
>> >>  it into account in any way.
>> >>
>> >> +Devices and PM domains may be defined as IRQ-safe, if they can be powered
>> >> +on/off even when the IRQs are disabled.
>> >
>> >What IRQ-safe means for devices is that their runtime PM callbacks may be
>> >invoked with interrupts disabled on the local CPU.  I guess the meaning of
>> >IRQ-safe for PM domains is analogous, but the above isn't precise enough to me.
>> >
>> >> An IRQ-safe device in a domain will
>> >> +disallow power management on the domain, unless the domain is also defined as
>> >> +IRQ-safe. In other words, a domain containing all IRQ-safe devices must also
>> >> +be defined as IRQ-safe. Another restriction this framework imposes on the
>> >> +parent domain of an IRQ-safe domain is that the parent domain must also be
>> >> +defined as IRQ-safe.
>> >
>> >What about this:
>> >
>> >"Devices may be defined as IRQ-safe which indicates to the PM core that their
>> >runtime PM callbacks may be invoked with disabled interrupts (see
>> >Documentation/power/runtime_pm.txt for more information).  If an IRQ-safe
>> >device belongs to a PM domain, the runtime PM of the domain will be disallowed,
>> >unless the domain itself is defined as IRQ-safe.  However, a PM domain can only
>> >be defined as IRQ-safe if all of the devices in it are IRQ-safe.
>> >
>> This is correct. But the last line may need a bit of modification. If
>> all devices in a PM domain are IRQ-safe and the domain is NOT, then it
>> it is a valid combination just that the domain would never do runtime
>> PM.
>
>That doesn't contradict the last sentence of mine above.  I guess what you mean
>is that having a non-IRQ-safe device in an IRQ-safe domain is a valid
>configuration.  I wonder how it works then. :-)
>
>In any case, what about changing that sentence to something like:
>
>"However, it only makes sense to define a PM domain as IRQ-safe if all devices
>in it are IRQ-safe."
>
That's precise. I will add your para instead of mine to the
documentation.

Thanks,
Lina
>

  reply	other threads:[~2016-10-24 21:17 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-14 17:47 [PATCH v3 0/8] PM / Domains: DT support for domain idle states & atomic PM domains Lina Iyer
2016-10-14 17:47 ` Lina Iyer
2016-10-14 17:47 ` [PATCH v3 1/8] PM / Domains: Make genpd state allocation dynamic Lina Iyer
2016-10-14 17:47   ` Lina Iyer
2016-10-14 17:47 ` [PATCH v3 2/8] PM / Domain: Add residency property to genpd states Lina Iyer
2016-10-14 17:47   ` Lina Iyer
2016-10-14 17:47 ` [PATCH v3 3/8] PM / Domains: Allow domain power states to be read from DT Lina Iyer
2016-10-14 17:47   ` Lina Iyer
2016-10-24 13:39   ` Sudeep Holla
2016-10-24 13:39     ` Sudeep Holla
2016-10-24 16:48     ` Lina Iyer
2016-10-24 16:48       ` Lina Iyer
2016-10-24 17:27       ` Sudeep Holla
2016-10-24 17:27         ` Sudeep Holla
2016-10-24 21:00         ` Lina Iyer
2016-10-24 21:00           ` Lina Iyer
2016-10-24 17:41       ` Sudeep Holla
2016-10-24 17:41         ` Sudeep Holla
2016-10-14 17:47 ` [PATCH v3 4/8] PM / Domains: Save the fwnode in genpd_power_state Lina Iyer
2016-10-14 17:47   ` Lina Iyer
     [not found] ` <1476467276-75094-1-git-send-email-lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-10-14 17:47   ` [PATCH v3 5/8] dt/bindings: Update binding for PM domain idle states Lina Iyer
2016-10-14 17:47     ` Lina Iyer
2016-10-14 17:47 ` [PATCH v3 6/8] PM / Domains: Abstract genpd locking Lina Iyer
2016-10-14 17:47   ` Lina Iyer
2016-10-14 17:47 ` [PATCH v3 7/8] PM / Domains: Support IRQ safe PM domains Lina Iyer
2016-10-14 17:47   ` Lina Iyer
2016-10-14 17:47 ` [PATCH v3 8/8] PM / doc: Update device documentation for devices in " Lina Iyer
2016-10-14 17:47   ` Lina Iyer
2016-10-21 13:07   ` Rafael J. Wysocki
2016-10-21 13:07     ` Rafael J. Wysocki
2016-10-21 15:23     ` Lina Iyer
2016-10-21 15:23       ` Lina Iyer
2016-10-21 22:52       ` [PATCH v3 [fix]] " Lina Iyer
2016-10-21 22:52         ` Lina Iyer
2016-10-22  0:26         ` Rafael J. Wysocki
2016-10-22  0:26           ` Rafael J. Wysocki
2016-10-24 16:16           ` Lina Iyer
2016-10-24 16:16             ` Lina Iyer
2016-10-24 21:22             ` Rafael J. Wysocki
2016-10-24 21:22               ` Rafael J. Wysocki
2016-10-24 21:17               ` Lina Iyer [this message]
2016-10-24 21:17                 ` Lina Iyer
2016-10-24 21:38         ` [PATCH v3 [fix-2]] " Lina Iyer
2016-10-24 21:38           ` Lina Iyer
2016-10-17  7:30 ` [PATCH v3 0/8] PM / Domains: DT support for domain idle states & atomic " Ulf Hansson
2016-10-17  7:30   ` Ulf Hansson
2016-10-20 22:44   ` Lina Iyer
2016-10-20 22:44     ` Lina Iyer
2016-10-20 22:48     ` Rafael J. Wysocki
2016-10-20 22:48       ` Rafael J. Wysocki
2016-10-21  1:33       ` Lina Iyer
2016-10-21  1:33         ` Lina Iyer
2016-10-21 13:09         ` Rafael J. Wysocki
2016-10-21 13:09           ` Rafael J. Wysocki
2016-10-21 18:35   ` Kevin Hilman
2016-10-21 18:35     ` 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=20161024211705.GG72940@linaro.org \
    --to=lina.iyer@linaro.org \
    --cc=Juri.Lelli@arm.com \
    --cc=andy.gross@linaro.org \
    --cc=brendan.jackman@arm.com \
    --cc=khilman@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=sboyd@codeaurora.org \
    --cc=sudeep.holla@arm.com \
    --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.