On Mon, Feb 22, 2021 at 8:23 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > 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 > objects. > > # 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 > <https://lore.kernel.org/linux-acpi/20210210230800.30291-1-sakari.ailus@xxxxxxxxxxxxxxx/T/#m24e9f51119cbe6eb39f31c097ea3941d00a0baeb> > > # 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. > > > >**Arguments:** > > > > 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). This ECR has been approved as submitted.
