New Ideas Under Consideration
From OMAPpedia
This wikipage stages new ideas, suggested feature additions, improvements etc. to the PM SW till they get scheduled for development.
[edit] HWMOD Framework Enhancements
The HWMOD framework enhancements were discussed as a part of PM workshop held at Bangalore 7-11 Jun, 2010. More details can be found at this link.
They are being scheduled for implementation. Once that is done, more details can be found under HWMOD wiki.
[edit] SR Voltage Control Migration to Regulator Framework Drivers
- This is nothing but phase 4 of SRF replacement work plan.
- It is well defined and may not take long (may be couple of months?)
- Current DVFS & SmartReflex work is good enough for OMAP3 & OMAP4. As a result, it can be taken care at a later time
- Currently being handled by Thomas Petazzoni
[edit] CPUFreq Ondemand Improvement to Fix Performance Issues
- How to improve ondemand governot to deal with Web performance issue, MMC throughput issue...
- The entire OPP layer and SRF replacement should be in place first before this is taken up
- Can be taken at a later time (may be during optimization phase)
[edit] Policy Framework for Other Voltage Domains
- Generalization of the CPUFreq for any kind of MPU (DSP, Ducati, IVA, SGX…)
- Need to decide - whether to do it as a part of CPUFreq or some custom way?
- May have potential impact on OMAP4 DVFS as the dependencies may not be modeled nicely
- Can be done on OMAP3/ OMAP4 board
- Needed in the long run (optimization phase?)
[edit] Dynamic Management of SMP Cores
- How to dynamically shut down a core depending of use case / load?
- Current ES2.0 PM validation is based on shutting down on core below certain threshold using CPU hotplug
- The solution is more of shortcut – even on ROM code validation
- Need to understand the transition latency of hot plug to take out one core; the main question would be – is it really bound? This also influences the threshold decision
- Looking at the bigger picture, SW design and architecture will require some long term investigative tasks
- This task requires a closer interactions with HW designers/ ROM code people etc.
[edit] CPUIdle Refinement
- How many c-states? Any reduction possible?
- should one constraint one core to the other?
- Migration of IRQs
- IRQ balancing (under development)
[edit] Extend PM QoS to Provide Per Device Granularity
- Device specific requirements as part of omap device
- This is a part of the work for latency constraints under SRF replacement
- The main question is - should it be done in omap specific way or kernel generic way?
- The generic way is what being proposed – but omap device approach should be good enough example
[edit] Memory Hotplug
- Needs some investigation
- Will become a requirement at some point of time given that more and more customers are showing interest in it
- Important from thermal management perspective
- Will be taken up at a later stage
[edit] Improve the PM Debug / Trace Capability
- Current code is OMAP3 specific and not particularly clean
- Need ASAP to improve overall debugging
[edit] CPUFreq / CPUIdle Instrumentation for Timechart Usage
- The instrumentation is needed for measurements and profiling
- Can be combined with the previous task (Improve PM debug/ trace capability)
- No immediate need to have access to SDP; first the framework be proven and then one can look at measurements
[edit] STM / ETB Support to Export HW Information without Lauterbach
- The feature was descoped on ES1.0; need to check if it is possible on ES2.0
- Taken on a lower priority as the benefit is more on eliminating the need for external debugger pod
[edit] PM Idle Code in I$/D$ Instead of SRAM
- Already some work done on this
- Need further investigation
- More of optimization; can be taken during optimization phase
[edit] Latency Modeling
- C-state instrumentation to better understand/model latency
- Could be done after the instrumentation is in place
- Will help in refining the latency modeling
- Can be taken at a later stage
[edit] Dynamic Clock Events
- Switching between 32k and high-res timers
- Kernel timer infrastructure is 32k based
- Can’t be used high-res timer
- Switching will enable usage of high res timer along with PM
- Involves dynamically enabling and disabling clock event source
- More of optimization; can be taken up at later stage
