Inactivity +Monitoring and Peripheral Low Power States

It is recommended that peripheral drivers monitor peripheral inactivity +because they are in the best position to understand the current hardware requirement.

The preferred approach is to implement inactivity monitoring in the platform +specific portion of peripheral drivers. However it is not always possible +to safely do it that way. In this case, an interface between the platform +specific and generic portions of the driver might need to be devised leading +to, in the future, inactivity monitoring functionality or assistance being +included in generic components.

In some cases the developer of the driver might decide to implement inactivity +monitoring with a grace delay, using timers. For example, consider a peripheral +used as a data input device. If the only way that the platform specific layer +of the peripheral driver has any knowledge that an input request is pending, +and that data is arriving, is when an incoming unit of data causes an interrupt, +then the resulting ISR (or deferred DFC) could re-start a timer with a suitable +period. Inactivity could be monitored in the timer callback. This guarantees +that if another unit of data arrives before the timer expiration, the peripheral +is still in its operational power state.

Peripheral Power States
Peripheral standby
Moving peripherals to a low power state
High latency low power states and non-transparent transitions
Peripheral power state diagram and transitions

Peripheral +Power States

It is possible that a particular ASSP allows peripheral +hardware blocks to be independently transitioned to a low power state. From +the point of view of power consumption, the base port might consider that +those peripherals have three logical power states:

Operational Power – +the peripheral is either processing some request, or performing a background +task with data transactions to or from it, or the peripheral is being kept +in this state in anticipation that data will be input to it, and is drawing +an amount of power corresponding to one of its possible modes of operation.
Low Power – +the peripheral is “idling” after a period of inactivity has been detected, +drawing a minimal amount of power required to preserve its internal state. +The peripheral should be able to keep its internal state and transition from +this to the Operational Power state with a negligible delay and with no impact +on the performance of either the peripheral driver or the upper layer components +that use it.
Off – the peripheral +power has been cut off, and only leakage accounts for power consumption. No +state is preserved and the delay to a return to full power is not negligible.

Note that peripheral power states are a notion that only applies +to the peripheral hardware block, and not to the driver. The peripheral driver +is the component that requests the peripheral to transition between these +states.

Note also that both Operational and Low Power states are subsets +of the Peripheral "Active" state. In some cases the differences in power consumption +between the Operational and Low Power modes might not be significant as, with +some hardware, only part of the peripheral needs to be operational to service +a particular type of request.

Peripheral +standby

Some ASSPs make provision for a peripheral standby mode, +where individual peripherals can be transitioned to a low power consumption +mode of operation under software control, usually by writing to an ASIC internal +register.

If the peripheral is capable of keeping its internal state, +and the transition out of this mode is either done automatically on hardware, +or controlled by software, but has no impact on the performance of the peripheral +driver or on the users of this peripheral, and can be done with negligible +delay, then the peripheral standby mode could be considered a low power state +as above.

Moving peripherals +to a low power state

It is assumed that peripherals can be transitioned +between power states under the peripheral driver's software control. However, +transitioning peripherals to a low power state should only be performed if +it can be done transparently to the users and consumers of the services provided +by that peripheral. Negligible interactive delays may be acceptable, data +loss is not acceptable.

The transition of a peripheral to a low power +state can be requested by the platform-dependent layers of that peripheral +driver after inactivity, as defined above, has been detected. That request +usually assumes the form of a request to turn a controllable power resource +off. The request should be handled by the ASSP/Variant component that manages +platform power resources (the resource manager).

It can also assume +the form of an operation required to put the peripheral in standby mode. In +this case the peripheral driver is totally responsible for handling the transition +to the low power state.

High latency +low power states and non-transparent transitions

This guide is +only concerned with peripheral low power states that can be reached and left +with no impact on system performance. However, it is possible that transitions +to and from a peripheral low power state are long enough to have an impact +on system performance, or cause loss of data, or the peripheral is not capable +of detecting the hardware events required to guarantee correct operation while +in a low power state. If this is the case, then the decision to transition +to a low power state cannot be taken solely by the peripheral driver, and +will have to be taken in agreement with the users and consumers of the services +provided by this peripheral.

Peripheral +power state diagram and transitions +Peripheral power state diagram + +

It can be assumed that when the peripheral driver is loaded, the +peripheral is put into the Low Power state. If a new request is asserted +on that peripheral driver from a user of that peripheral (which can include +another dependent peripheral driver or user side Engine/server/application), +the peripheral should move to its Operational Power state. The driver +can then start monitoring for peripheral inactivity, and when that is detected, +and no other dependent peripheral is using this peripheral, it can move the +peripheral back to the Low Power state.

If, however, the power +manager requests the driver to power down the peripheral and no other dependent +peripheral is using it, it then moves into its Off state from which +it can only return to the Operational Power state when the power manager +issues a power up request. Moving from the Off state to the Operational +Power state is a relatively lengthy operation and requires resetting the +internal state of the peripheral.

If another dependent peripheral +is using this peripheral, and the power manager issues a power down request, +then the driver keeps the peripheral in its operational power state until +the dependent peripheral relinquishes its request on it.

From the Low +Power state, a peripheral can also be turned Off (unconditionally) if +the power manager so requests. It can be moved back to the Operational +Power state on an internal event (Interrupt, Timer).

+Peripheral power states + +