Camera power management
Power management modes
The off-System on a Chip (SoC) components of the camera subsystem must support two power management modes. The camera components must support an active mode in which the camera device is actively streaming content to an application. In addition, the camera components must support a power-removed mode in which the camera device is turned off, power is removed, and the camera device consumes zero watts. The following table describes the active and power-removed power management modes for the camera device.
| Mode | Description | Device power state (Dx) | Average power consumption | Exit latency to active | Transition mechanism |
|---|---|---|---|---|---|
Active (streaming) |
The camera device is actively streaming content to an application. The content might be full-motion, preview, or still photo capture. |
Yes |
Sensor, AF, and flash-specific. |
N/A |
Software-initiated D0 transition. (An application has initiated streaming by setting the state of a capture pin to KSSTATE_ACQUIRE.) |
Power - removed |
The camera device is not streaming content to any applications. No context is preserved on the camera sensor, the flash device, or the auto-focus engine. |
Yes |
0 watts |
< 200 milliseconds to first frame (See note following table.) |
Software-initiated D3 transition. (The state of all streaming pins has been set to any value other than KSSTATE_RUN.) |
Note Windows expects the transition time from the active mode to the power-removed mode (the off latency) to be less than 100 milliseconds. Most power management effort is focused on reducing the transition time from power-removed mode to active mode (the on latency).
The same two power management modes, active and power-removed, must be supported by the on-SoC image processing units. The SoC vendor defines the individual components that comprise the image processing units and their power management states. We recommend that a single driver control the on-SoC image processing units, and that all the image processing units for camera capture be presented to the power engine plug-in (PEP) as a single power-managed component.
Software power management mechanisms
Both the on-System on a Chip (SoC) image processing units and the off-SoC camera components are expected to consume no power (zero watts) when the system is in connected standby and the display is turned off. The primary software mechanism for power management is reference counting of the camera capture pin. This reference count is maintained by the camera controller driver, which is an AVStream minidriver. This basic power management mechanism can be used any time the system is turned on, including times when the system display is powered on.
The camera controller driver should forward power management state transitions to the drivers that control off-SoC components such as the camera sensor, auto-focuser, and flash. In response, the drivers that control these devices should take specific action to change power states and to remove or apply power.
Recommended driver architecture
The camera subsystem should be exposed to Windows through a single AVStream minidriver called a camera controller driver. We recommend that the camera controller driver not access hardware directly and not directly power-manage hardware components. Instead, the camera controller driver should forward power management and hardware requests to other the drivers that comprise the camera subsystem.
The on-SoC image processing hardware should be power-managed by the SoC power engine plug-in (PEP). The image processing hardware should be managed by a Windows Driver Frameworks (WDF) driver and this driver should enable cooperation with the PEP by setting the IdleTimeout member in the WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS structure to SystemManagedIdleTimeout. This setting enables the PEP to control any clock and power-rail sharing topology that is unique to the SoC hardware. The driver that controls the image processing unit on the SoC should represent the entire image processing unit as a single power-managed component so that the default WDF capabilities for power management can be used.
The off-SoC camera subsystem components should be managed by one or more Kernel-Mode Driver Framework (KMDF) drivers. The drivers for the off-SoC components must transition to the power-removed (D3) state when their components are no longer required for camera capture. Additionally, the drivers for the off-SoC components must enable D3cold, which allows the underlying ACPI subsystem to change the state of GPIO lines to apply and remove power. For more information, see Supporting D3cold in a Driver.
The following block diagram shows the recommended driver architecture.
All of the drivers that comprise the camera subsystem—including the camera controller driver, the image processing unit driver, and the drivers for the off-SoC camera components—must be enumerated in the same driver installation (.inf) file. All camera subsystem drivers must be members of the imaging PnP device setup class. The ClassGuid for imaging devices is {6bdd1fc6-810f-11d0-bec7-08002be2092f}.
Each driver that represents a single camera component should be enumerated as a single device in the ACPI namespace.
Active and power-removed states
The camera controller driver must transition the camera devices to the power-removed state when no applications are streaming content from the camera device. An application may stop streaming because it has been closed by the user or is transitioned to the background and is suspended.
If an application initiates streaming from a camera whose devices are in the power-removed state, the camera controller driver must transition the camera devices back to the active state within 100 milliseconds.
To change the power states of the various camera subsystem components, camera controller drivers use proprietary interfaces to communicate with the other drivers that comprise the camera subsystem. To query for the appropriate interface, a camera subsystem driver should use the standard method, which is to send an IRP_MN_QUERY_INTERFACE I/O request that retrieves a set of function pointers.
The camera controller driver must place the camera device in the power-removed state when all of the streaming pins have entered the KSSTATE_STOP state. Windows automatically suspends foreground applications when the user presses the power button and the system enters connected standby. When a capture application is suspended, the camera capture APIs provided by the Windows Runtime are notified and will change the state of the camera capture pins, causing them to enter the KSSTATE_STOP state.
When the first streaming pin enters the KSSTATE_ACQUIRE state, the camera controller driver must place the camera device—including the on-SoC image processing unit—in the active state.
Associated camera functionality
The camera sensor and flash devices might have additional platform-level functions that must be managed by the driver. These functions can include the following:
- Enabling, disabling, and configuring the camera sensor over the I2C bus.
- Configuring the flash burst rate and brightness level over the I2C bus.
- Detecting thermal conditions from the flash module through GPIO lines from the flash module to the SoC.
To implement these functions, camera device driver developers should use the methods and guidance summarized in the following table.
| Function | Description | Hardware/firmware connection | Software mechanism |
|---|---|---|---|
| Sensor configuration | Enumerate the capabilities of the camera sensor hardware or configure its current mode of operation. | Communication over I2C bus. I2C resources are described in the _CRS method under the camera device in the ACPI namespace. | Simple peripheral bus (SPB) input/output (I/O) request interface is used to communicate with I2C host controller and camera sensor device. |
| Sensor event detection | Raise events or indicate status using GPIO lines from the camera sensor to the SoC. | GPIO resources provided to the camera device. These resources are described in the _CRS method under the camera device in the ACPI namespace. GPIO pins that signal events must be described as GPIO interrupt resources. | Interrupt is processed by driver in response to GPIO event. SPB I/O request interface is used to communicate with sensor device to determine the cause of the interrupt. |
| Flash configuration | Configure the flash device for burst rate, number of connected LEDs, or other properties. | Communication over I2C bus. I2C resources are described in the _CRS method under the camera device in the ACPI namespace. | SPB I/O request interface is used to communicate with I2C host controller and camera sensor device. |
| Coordination with image processing unit driver | Initiate and coordinate capture with the image processing circuitry on the SoC. | N/A | Private interface is exposed by the driver that manages the image processing units. |
Camera device enumeration
To identify camera devices in the platform, applications typically query the Plug and Play (PnP) manager for instances of camera devices. Each PnP instance corresponds to a single camera device. To identify such an instance, the system integrator defines a camera device in the ACPI namespace. A camera device can stream content to only one application at a time. However, an application can stream from multiple camera devices simultaneously.
Each camera device that is represented by the camera controller driver (the AVStream minidriver) must be enumerated in the ACPI namespace as a separate device that is a child of the graphics driver.
As a special case, if the SoC platform is not capable of simultaneously streaming content from all camera devices in the platform at any combination of their reported resolutions or modes, a single camera device can be enumerated instead. However, this implementation requires careful consideration and should be undertaken only in direct collaboration with Microsoft.
The devices that represent the remainder of the camera subsystem—including the on-SoC image processing unit and the off-SoC camera sensor, auto-focuser, and flash—should be enumerated as one or more devices in the ACPI namespace. The on-SoC image processing unit should be enumerated as a device that is separate from the devices that represent the off-SoC components of the camera.
Camera power management checklist
System integrators, camera sensor vendors, and System on a Chip (SoC) vendors should use the checklist in this article to ensure that their system power management design is compatible with Windows 10.
- The system integrator must communicate and collaborate with the SoC vendor when selecting camera sensor components and integrating camera devices.
- The camera controller driver developer must do the following:
- Turn off power to the camera hardware when applications are no longer streaming content from the camera device. (This occurs when all capture pins are in the KSSTATE_STOP state.)
- Turn on power to the camera hardware when an application starts streaming from any of the capture pins on the camera device.
- Develop one KMDF driver that manages the on-SoC image processing unit. The camera controller driver should use custom driver interfaces to tell the image processing unit driver to initiate or end camera capture.
- Ensure the image processing unit driver is registered with the Windows power management framework (PoFx) so that the SoC vendor-provided PEP can control the power management of the image processing unit hardware.
- Develop one Windows Driver Frameworks (WDF) driver to manage each hardware component that manages the off-SoC camera hardware, including the camera sensor, auto-focuser, and optional flash. The camera controller driver should use custom driver interfaces to tell the drivers for the off-SoC camera hardware to initiate or end camera capture.
- Ensure that the drivers that manage the off-SoC camera hardware initiate a D3 transition when the camera components should be powered down so that ACPI is informed of the D3 transition and can remove power from the components. • Ensure that the drivers that manage the off-SoC camera hardware initiate a D0 transition when the camera components should be powered on so that ACPI is informed of the D0 transition and can apply power to the components.
- Develop any driver code for managing the configuration of the camera sensor hardware or the flash device.
- Inform the system integrator about the expected ordering of any GPIO and I2C resources that are required to manage the camera sensor hardware or the flash device.
- Ensure that all of the drivers that comprise the camera subsystem are enumerated in the same driver installation (.inf) file.
- Ensure that all of the drivers that comprise the camera subsystem are members of the imaging PnP device setup class. The ClassGuid for imaging devices is {6bdd1fc6-810f-11d0-bec7-08002be2092f}.
- The system integrator must design the platform ACPI firmware to do the following:
- Enumerate each camera device as a separate device in the ACPI namespace.
- Include a _PLD object under each camera device in the ACPI namespace to indicate whether the camera is on the front or back of the computer.
- Include a power resource in the root of the ACPI namespace for each camera device. All of the off-SoC hardware components for a given camera device (sensor, AF, flash, and so on) should be in one power resource.
- Implement the _ON and _OFF control methods for each power resource to change the state of the GPIO pin from the SoC that drives the power rail switching hardware.
- Provide the _PR0 and _PR3 methods under each camera device in the namespace to reference the power resource for each camera device and its associated hardware.
- Provide a _CRS object under each camera device in the ACPI namespace to enumerate the GPIO and I2C resources for the camera sensor and flash hardware. The GPIO and I2C resources must be in the order that is specified by the camera sensor driver developer.
- The system integrator should design the platform hardware and power routing so that:
- Each camera device has its own power rail, which can be controlled independently of the power rails for the other camera devices, and which can be switched on and off by a GPIO pin from the SoC.
- The system integrator must test and verify that:
- The camera device hardware consumes no power (zero watts) when the camera device is not in use by an application. The system integrator should use instrumented hardware to measure this power consumption.