Thanks for your comment. > > Suppose we have a SoC with an on-chip multimedia codec. The codec can either > > be clock-gated or power-gated, and it shares its power domain with a > > neighboring IP, say a 3D engine. Clock gating can be done by the driver > > since the clock can be controlled separately. However, the codec driver can > > never perform power-gating since it does not know if the 3D engine is active > > or not. We would prefer a centralized device power manager in this case. > > This is a common case for state-of-the-art mobile handsets such as a DMB > > phone. > > In which case a centralized power manager would handle things. But > there's no reason that power manager couldn't be part of the kernel's > infrastructure. The individual device drivers would tell it when they > need power, and it would gate off the power when nobody needs any. In > this case no userspace API is required. It's merely a platform-level > design issue. We can have the device power manager in the kernel and let the platform designers hardcode the rules specific to their platform. It is easier to implement and we can use that scheme right away. In the future however, I think it is more clear to have a "power/voltage domain framework, and an extensible framework for system-wide operating (and non-operating sleep) states," quoting from what David said in his response to my message. Ikhwan
