On Mon, Aug 28, 2006 at 07:39:57PM +0200, Pavel Machek wrote: > On Mon 2006-08-28 09:40:38, Mark Gross wrote: > > On Sat, Aug 26, 2006 at 03:46:53PM +0200, Pavel Machek wrote: > > > On Sat 2006-08-26 17:30:40, Vitaly Wool wrote: > > > > On 8/26/06, Pavel Machek <pavel at suse.cz> wrote: > > > Because 8388608 policies is clearly not reasonable, powerop can not > > > help here, and something better should be developed... like power > > > domains someone proposed here. > > > > > > (Or to say it in another words, powerop forces one big power domain, > > > which is bad model for notebook-style machine). > > > > I doubt notebook-style machines will ever us power op in any > > significant way. HPC and embedded will be the first users. > > I agree here... power op look useless for notebooks. But I doubt power > op authors would agree... Concluding that it will be useless for notebooks may be premature. I see powerop as the bottom of an future PM stack. As the upper layers take shape who knows what platforms will use it? > > > Power domains will likely build on top power op. > > > > Power domains adds complexities themselves. Dealing with > > dependencies and constraints between domains will be a challenge. > > Once we have power domains in/solved... do we still need power op? I > thought power op could be useful for solving constrains _inside_ one > domain, but... Power domains and the components within them will likely be accessed as operating points. I think we need to build the power domain abstractions on top of operating points. This is why I want to see support for multiple power_op_driver instances or a story for how operating points are added to a running system or even platform to enable and deal with domains. --mgross
