Patent Application
20150074436
A central processing unit (CPU) of an electronic device may operate according to a power-management (PM) strategy. The PM strategy may be configured to limit overall power consumption in the device while also ensuring responsiveness to user input. One way to limit power consumption is to detect an idle condition—i.e., a condition where no computational work is necessary and no user input is being received—and to reduce the CPU clock speed during the idle condition. In some examples, the CPU clock speed may be reduced by a factor of 10 to 100. In this state, the CPU can still process certain background tasks, such as polling the input hardware for user input. However, the power dissipation within the CPU will be greatly reduced because of the lower clock speed, which is especially important if the electronic device is battery powered.
If, during the idle condition, the polling of the input hardware should reveal that a user input has been received—e.g., if the user depresses a key switch on the device or touches a touch-enabled display screen—then various actions may be required of the CPU. Depending on the nature of the user input, the CPU may be required to exit the idle condition by increasing the clock speed to its normal operational speed. Depending on the nature of the electronic device, various other actions may be required besides increasing the clock speed—powering up a display screen, communications system, or mass-storage device, for example. Naturally, one measure of the responsiveness of the electronic device is the latency associated with such tasks.
Currently, two state-of-the-art methods are used to boost the CPU clock speed in an idle electronic device on receipt of an indication of user input—typically an interrupt request (IRQ). One method is to boost the CPU clock speed in so-called user space—i.e., starting from the point where a user-event reader receives process control. However, this method provides an incomplete solution to the problem, as many processing steps may be required from receipt of the IRQ to execution of the user-event reader. When these steps are enacted at reduced clock speed, the resulting latency can be significant. Another method is to incorporate, within the kernel driver of the device, functionality that continuously receives raw data from the input hardware and parses the data for an indication of user activity. When such activity is detected, the CPU clock rate is boosted directly from the kernel—i.e., before execution is passed to the user-event reader. One disadvantage of this approach is that it requires a dedicated kernel process to remain active in the idle state, listening for user-input events in the raw data from the input hardware. Moreover, it too may exhibit significant latency, as the parsing of the raw data is enacted at reduced clock speed.
In the embodiment of
In some embodiments, the CPU may be a multicore unit configured for simultaneous execution of a plurality of software threads. For example, the CPU may include two to four main processing cores with cache memory associated with each core, and in some cases shared between or among cores. In more particular embodiments, the CPU may include an additional low-power core to accomplish various background tasks with reduced power consumption.
In the embodiment of
In the illustrated embodiment, activity from the various 10 componentry of electronic device 10 is signaled via an array of interrupt requests (IRQs) 36 to CPU 22. In this manner, the input hardware intended to wake electronic device 10 from an idle condition may be configured to assert in the CPU an IRQ indicative of user input. In one embodiment, such hardware may include a touch-screen display, which may assert an IRQ to indicate user touch—e.g., any touch, touch conforming to a predetermined set of conditions, or touch received in a predetermined region of the touch screen. In another embodiment, the input hardware may include a networking component (e.g., Wi-Fi radio 30, Bluetooth radio 32, or a cellular radio); such hardware may assert an IRQ to indicate receipt of a packet—e.g., any packet, a packet of a particular kind, etc. In yet another embodiment, the input hardware may be a key switch of the electronic device—e.g., an ON/OFF push button. The key switch may assert an IRQ to indicate key depression by a user of the electronic device—any depression, depression for more than a predetermined period of time, etc.
Continuing in
In the embodiment of
In one embodiment, kernel 42 may be a Linux® kernel. It may include various hardware driver modules: a display driver, a camera driver, a Bluetooth driver, a flash-memory driver, a binder driver, a universal serial bus (USB) driver, a keypad driver, a Wi-Fi driver, and one or more audio drivers, for example. In the embodiment shown in
Continuing in
In contrast to certain prior solutions, the boosting of the CPU clock speed in the present approach is enacted directly from the OS kernel of the electronic device. Thus, the boosting can occur promptly, without having to wait for the IRQ to filter up to a user-event reader. Nevertheless, the overall device-waking approach remains IRQ-based, and does not require the CPU to continuously parse raw data from the input componentry simply to detect user action. When implemented on a modern, multicore device that supports a 600 megahertz clock rate, this approach has reduced the latency of response to a touch-screen event from an initial range of 60 to 100 milliseconds down to a range of 20 to 25 milliseconds.
No aspect of the drawings should be interpreted in a limiting sense, for numerous other configurations lay fully within the spirit and scope of this disclosure. For example, while
The configurations described above enable various methods to wake an electronic device from an idle condition. Accordingly, some such methods are now described, by way of example, with continued reference to the above configurations. It will be understood, however, that the methods here described, and others within the scope of this disclosure, may be enabled by different configurations as well. Naturally, each execution of a method may change the entry conditions for a subsequent execution and thereby invoke a complex decision-making logic. Such logic is fully contemplated in this disclosure. Further, some of the process steps described and/or illustrated herein may, in some embodiments, be omitted without departing from the scope of this disclosure. Likewise, the indicated sequence of the process steps may not always be required to achieve the intended results, but is provided for ease of illustration and description. One or more of the illustrated actions, functions, or operations may be performed repeatedly, depending on the particular strategy being used.
At 62 of method 60, a worker queue is created in an interrupt-request (IRQ) driver module of an OS kernel of the electronic device. At 60 an indication of user input in the form of an IRQ is received in the kernel. Then, in response to receiving the indication of user input, at 64 a request to boost the CPU clock speed is posted in the worker queue. At 66, the request to boost the CPU clock speed is processed, which results in the desired increase in CPU clock speed. The range of increase of the CPU clock speed may differ in the different embodiments of this disclosure. In one example, the CPU clock speed may be less than 100 megahertz during the idle condition and may be boosted to more than 600 megahertz after processing the request. Naturally, the request to boost the CPU clock speed may be one of a plurality of requests posted to the worker queue and subsequently processed. The plurality of requests may further include activation of a display component of the electronic device, for example.
In one embodiment, processing the request to boost the CPU clock speed may include passing a value representing the desired CPU clock speed to a process module configured to change the CPU clock speed. More particularly, processing the request to boost the CPU clock speed may include invoking a PM_QoS helper function residing in a PM module of the kernel.
It will be noted that the method steps detailed herein are non-limiting in nature. In some embodiments, such steps may be used in conjunction with other methods. For example, method 60 may be used as part of an overall PM scheme that also detects an idle condition of the electronic device and lowers the CPU clock speed upon detection of the idle condition—e.g., at a predetermined period of time following detection of the idle condition.
It will be noted that the drawing figures included in this disclosure are schematic and generally not drawn to scale. Rather, the various drawing scales, aspect ratios, and numbers of components shown in the figures may be purposely distorted to make certain features or relationships easier to see. It will be understood that the configurations and/or approaches described herein are exemplary in nature, and that these specific embodiments or examples are not to be considered in a limiting sense, because numerous variations are possible. The subject matter of the present disclosure includes all novel and non-obvious combinations and sub-combinations of the various processes, systems and configurations, and other features, functions, acts, and/or properties disclosed herein, as well as any and all equivalents thereof.
