Peripheral inactivity can be defined as the state when that peripheral’s driver has no pending request and is not performing background tasks.
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.
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.
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.
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.
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.
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).
Copyright ©2010 Nokia Corporation and/or its subsidiary(-ies).
All rights
reserved. Unless otherwise stated, these materials are provided under the terms of the Eclipse Public License
v1.0.