Date
1 - 3 of 3
RFC [0/3] - SoC, CPU LPS, Tickless idle and Device power management
Thomas, Ramesh
Migrating this RFC from the old server for reference. This is updated
with the feedbacks that were incorporated. This consists of the following parts: [0/3] - This overview [1/3] - SoC, CPU and Tickless Idle power management (merged) [2/3] - Device power management (under review) [3/3] - Areas to be implemented next including open feedbacks Following are the main areas to address for power management support in Zephyr: 1. Kernel SoC power management hook infrastructure in Zephyr 2. Kernel CPU low power state and Tickless idle power management hook infrastructure. 3. Device driver power management hook infrastructure Goal: This support in Zephyr kernel is added to assist system integrator's implementation of Power Management policy and service. Non-goal - Zephyr kernel will not: a) Implement any Power Management policy - The integrator's power management service app would implement power policy b) Implement any code to save/restore registers or SoC or device states. - The integrator's power management service app and device drivers should take care of that. |
|
Kalowsky, Daniel <daniel.kalowsky@...>
Hi Ramesh,
toggle quoted message
Show quoted text
-----Original Message-----When I had asked you to do a rev.next of the RFC, this isn't what I had in mind. From reading the RFC, I should be able to formulate: - A clear definition of any terminology being introduced to the kernel (i.e. Deep Sleep). - A clear idea of what you are trying to accomplish as the overall task. - An idea of how this over-arching task can be broken down to smaller sub-tasks of functionality. - A clear description of the flow that the system should follow when implementing Task A to sub-taskX. Verbal is okay, but honestly, pictures go much further. Even ASCII art pictures do plenty to help explain things more than words. - A clear idea of how the concept works for ARC, ARM, and x86; any support discrepancies, sections that are arch agnostic, and sections that are arch dependent. All of this work should become part of the cover letter, but also should be the basis for the work added to the documentation. Essentially you are teaching the rest of us about how this will work as if we've not had any experience with it. While reading these 3 posts, I avoided looking at the code. There is a lot of confusing language within that melds multiple different ideas into something that does not paint a coherent image of the power management scheme. It reads like it was forced and rushed through. I'm more than happy to help walk-through and correct where I see things missing off-list. |
|
Thomas, Ramesh
On Wed, 2016-03-02 at 01:21 +0000, Kalowsky, Daniel wrote:
Hi Ramesh,Sure. I will be glad to work with you on making it better. Thanks.-----Original Message-----When I had asked you to do a rev.next of the RFC, this isn't what I had in mind. From reading the RFC, I should be able to formulate: |
|