linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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: 28+ 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 ` [PATCH v3 1/8] PM / Domains: Make genpd state allocation dynamic 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 ` [PATCH v3 3/8] PM / Domains: Allow domain power states to be read from DT Lina Iyer
2016-10-24 13:39   ` Sudeep Holla
2016-10-24 16:48     ` Lina Iyer
2016-10-24 17:27       ` Sudeep Holla
2016-10-24 21:00         ` Lina Iyer
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 ` [PATCH v3 5/8] dt/bindings: Update binding for PM domain idle states Lina Iyer
2016-10-14 17:47 ` [PATCH v3 6/8] PM / Domains: Abstract genpd locking 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 ` [PATCH v3 8/8] PM / doc: Update device documentation for devices in " Lina Iyer
2016-10-21 13:07   ` Rafael J. Wysocki
2016-10-21 15:23     ` Lina Iyer
2016-10-21 22:52       ` [PATCH v3 [fix]] " Lina Iyer
2016-10-22  0:26         ` Rafael J. Wysocki
2016-10-24 16:16           ` Lina Iyer
2016-10-24 21:22             ` Rafael J. Wysocki
2016-10-24 21:17               ` Lina Iyer [this message]
2016-10-24 21:38         ` [PATCH v3 [fix-2]] " Lina Iyer
2016-10-17  7:30 ` [PATCH v3 0/8] PM / Domains: DT support for domain idle states & atomic " Ulf Hansson
2016-10-20 22:44   ` Lina Iyer
2016-10-20 22:48     ` Rafael J. Wysocki
2016-10-21  1:33       ` Lina Iyer
2016-10-21 13:09         ` Rafael J. Wysocki
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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).