archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <>
To: ACPI Devel Maling List <>
Cc: Sakari Ailus <>
Subject: [RFC] ACPI Code First ECR: _DSC (Deepest State for Configuration)
Date: Mon, 22 Feb 2021 20:23:13 +0100	[thread overview]
Message-ID: <> (raw)

On some systems there are devices that should better be left in their
current power state before attempting to bind drivers to them in order
to avoid some undesirable side effects of turning the power on (e.g.
blinking a privacy LED of a camera that may confuse the user to
believe that the camera sensor is in use while in fact the camera is
only being probed by a driver).

To support this use case, define a new device PM object called _DSC
(Deepest State for Configuration) returning the deepest D-state the
device can be in before evaluating its _CRS, _PRS and _SRS configuration

# Title: Introduce _DSC (Deepest State for Configuration)

# Status: Draft

# Document: ACPI Specification 6.4

# License
SPDX-License Identifier: CC-BY-4.0

# Submitter:
* Sponsor: Rafael J. Wysocki, Intel
* Creators/Contributors:
    * Rafael J. Wysocki, Intel
    * Sakari Ailus, Intel

# Summary of the Change
Introduce a new device PM object called _DSC (Deepest State for Configuration)
returning the deepest D-state the device can be in before evaluating its _CRS,
_PRS and _SRS configuration objects.

# Benefits of the Change
It will allow OSPMs to avoid putting devices into D0 in order to check and set
their resources if _DSC is present and its return value is greater than 0.  In
particular, if _DSC returns 4 (assuming that _PR3 is present for the given
device), the device can remain in D3cold during driver probe and the driver
should be able to gather all of the information needed by it to operate the
device without changing its power state.

# Impact of the Change
Enable certain device power management optimizations.

# References
Support running driver's probe for a device powered off

# Detailed Description of the Change

* Add a new row to Table 7.3 Device Power Management Child Objects:

> _DSC    Object that evaluates to the device's deepest power state for configuration.

* Add new Section 7.3.27:

> 7.3.27. _DSC (Deepest State for Configuration)
>This optional object evaluates to an integer that conveys to OSPM the deepest
>D-state the device can be in before evaluating the \_CRS, \_PRS and \_SRS
>configuration objects for it.
>If \_DSC is present and the current power state of the device is not deeper
>than the one represented by its return value, the device's \_CRS, \_PRS (if
>present) and \_SRS (if present) configuration objects (see :ref:`device-configuration-objects`)
>can be safely evaluated without putting the device into D0.
>Therefore, when present, the \_DSC object allows the OSPM to optimize device
>power management by avoiding an unnecessary change to device power state that
>would be otherwise made before evaluating configuration objects for the device.
>  None
>**Return Value:**
>  An Integer representing the deepest D-state the device can be in during
>  configuration. If OSPM has not indicated that it supports \_PR3 through the OSPM
>  Platform-Wide Capabilities (see :ref:`platform-wide-ospm-capabilities`), then
>  the value "3" corresponds to D3. If it has indicated \_PR3 support, the value
>  "3" represents D3hot and the value "4" represents D3cold.
>  The \_DSC return value must represent a D-state that is supported by the
>  device.  In particular, "4" (D3cold) can be returned only if \_PR3 is present.
>  \_DSC must return the same integer each time it is evaluated.
>  The \_DSC return value must not represent a D-state shallower then the one
>  resulting from turning ON all of the power resources listed by \_PRE (if
>  present) and evaluating \_PSE (if present).

             reply	other threads:[~2021-02-22 19:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-22 19:23 Rafael J. Wysocki [this message]
2021-05-19 14:33 ` [RFC] ACPI Code First ECR: _DSC (Deepest State for Configuration) Rafael J. Wysocki

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \

* 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).