PM Constraints: OMAP

Registered by Eduardo Valentin

Power Management Constraints - OMAP
1) OMAP SoC Thermal Containment
2) Power Management in Linux with a coprocessor
3) New Model for System and Devices Latency

=== OMAP SoC Thermal Containment ===


The thermal challenge is to design an end-product with high performance while keeping the junction temperature of the IC components used on this product within their limitations and which does not present a thermal discomfort for the user. OMAP4/OMAP5 System on Chips, operating at highest Operating Performance Points (OPP), is a powerful mobile applications processor. However operating at higher voltage and higher frequency in a sustained manner may cause thermal limits to be exceeded, both for silicon and user comfort. We propose extensions on existing frameworks to model per device power constraints, for containment of thermal limitations across major heat sources of a end-product device, e.g. LCD, CPU, charging, etc. The framework shall facilitate the power and thermal management performed by governor and policies, depending on device context and use case knowledge.

Topic Lead: Eduardo Valentin
Eduardo currently acting as System Software Engineer at Texas Instruments, working on OMAP Linux kernel. He has been involved with embedded Linux for some years already, contributing on products of companies like Texas Instruments, Nokia, Motorola and Samsung. The main areas of interest are (not limited to): power management, real time, performance, scheduling, system and software otimization, and recently, thermal management.

=== Power Management in Linux with a coprocessor ===


Shutting down the main processor of an SoC in the idle and standby state results in significant power savings. However, doing so requires the responsibility of reviving the system to be passed onto an independent entity in the system. Texas Instruments has taken the lead in introducing a novel approach for system power management in its AM335x processor family involving a Cortex-M3 to assist the main processor. In the future there will other devices from Texas Instruments and possibly other silicon vendors which adopt this technique.

Integrating a co-processor which is not running Linux with the PM framework comes with a new set of challenges. The co-processor needs to interact with the host processor for idle as well as standby power management. How do we communicate with a co-processor without significant overhead in the idle thread? In case the co-processor stops responding what should be recovery mechanism in the PM framework? What should be the mechanism for exporting the core details like the configured wakeup sources to the co-processor?

This session will focus on the above mentioned challenges and other issues surrounding the usage of a co-processor for power management in Linux.

Topic Lead: Vaibhav Bedia
Vaibhav Bedia, Software Systems Engineer, Texas Instruments, works on Linux kernel development for Sitara ARM microprocessors.

=== New Model for System and Devices Latency ===


Due to the nature of the new SoC architectures the Power Management needs a new model for the various system latencies. The session discusses:
- Concepts of system, devices, wake-up and resume latencies,
- Recent changes in the devices framework for the latency, why and how to make it generic,
- Links with the other PM QoS frameworks: thermal, cpuidle,
- Recent changes in the ARM/OMAP platform code for the system latency,
- Problems encountered while modelling and measuring the various latencies,
- A proposed model and how to implement it,
- Planned changes in the device framework, the platform code and the APIs.

This session is oriented towards Linux power management developers. The goal is to agree on a framework implementation and the interfaces within the kernel and with the user space.

Topic Lead: Jean Pihet <email address hidden>
Jean is working with embedded Linux since many years now, for companies like Texas Instruments, MontaVista, Motorola and Philips. Recently has been founded to provide high quality consulting services. The area of work is mainly OMAP Power Management, tracing and profiling tools (perf, ftrace, oprofile...) for recent ARM cores.

Blueprint information

Not started
Needs approval
Eduardo Valentin
Series goal:
Milestone target:

Related branches




Work Items

This blueprint contains Public information 
Everyone can see this information.