Platform Framework Standby Operation for IHS Power Management
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing Information Handling Systems (IHSs) face inefficiencies in managing power states during standby operations, leading to unnecessary resource consumption and battery drain, as each application must independently handle power mode transitions, resulting in overlapping code and inefficiencies.
Innovation Solution
Implementing a platform framework that uses an Application Programming Interface (API) to identify and manage applications, putting them in either a throttled or suspended state based on whitelist entries, power mode, battery metrics, and user presence, allowing the system to distribute platform framework binaries to Embedded Controller (EC) or System-on-Chip (SoC) cores for optimized power management.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If each application independently handles power mode transitions, then applications can maintain full control over their own power management, but system resource consumption increases and battery drain accelerates due to overlapping code and inefficiencies
Solution Approach 1:
The patent merges individual application power management into a centralized platform framework. The framework identifies applications and manages their power states collectively, eliminating redundant independent power management code and reducing overall system resource consumption during standby operations.
Solution Approach 2:
The platform framework serves as a universal power management mechanism that handles multiple applications simultaneously. It provides a multi-functional solution that can identify, whitelist, and manage various applications in different power states (throttled or suspended) based on system conditions.
2Loss of energy
If the system puts applications in a suspended state during standby, then power consumption is reduced, but application responsiveness and functionality are limited
Solution Approach 1:
The system dynamically adjusts application power states based on real-time conditions. Applications can be in throttled state (reduced activity but still executable) or suspended state (not executable) depending on whether they are whitelisted and on system conditions such as power mode, battery metrics, and user presence.
Solution Approach 2:
Different applications receive different power management treatments based on their specific characteristics and importance. The whitelist mechanism allows critical applications to maintain higher responsiveness (throttled state) while less critical applications can be fully suspended, creating localized quality differences in power management.
3Productivity
If the system whitelists specific applications for throttled state, then power management efficiency improves, but system complexity increases due to whitelist management and identification mechanisms
Solution Approach 1:
The platform framework acts as an intermediary layer between the operating system and applications. It provides the whitelist management and identification mechanisms, simplifying the overall system architecture by centralizing complex power management logic in a dedicated framework rather than scattering it across multiple components.
4Loss of energy
If the system distributes platform framework binaries to EC or SoC cores, then power management is optimized for standby operation, but hardware complexity and distribution overhead increase
Solution Approach 1:
The system segments the platform framework binaries and distributes them to specific hardware components (EC or selected SoC cores) based on power mode, battery metrics, and other conditions. This segmentation allows optimized power management in standby by placing the framework in hardware that remains active or can be quickly activated, while reducing the burden on the main processor.
Data Source
AI summary
Embodiments of systems and methods for standby operation in a platform framework are described. In some embodiments, an Information Handling System (IHS) may include a processor and a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution, cause the IHS to: identify an application registered with a platform framework via an Application Programming Interface (API); and at least one of: in response to the identification matching any entry in a whitelist, put the application in a throttled state during standby operation of the IHS; or in response to the identification not matching any entry in the whitelist, put the application in a suspended state during standby operation of the IHS.