Re: Alternative Concept

Scott E. Preece
2007-03-14T22:08:56Z

| From: David Brownell<david-b@pacbell.net>
| ...
| > > > Basically a good way of thinking about parameter framework is that parameter
| > > > framework would start from existed clock framework and gradually evolve by
| > > > addressing voltages, relationship between clocks and voltages, domains.
| > > > Eventually clock framework functionality would be a part of power parameter
| > > > framework.
| > >
| > > A better way would be to say that implementions of the clock interface
| > > on a given platform can build on whatever they need to build. That might
| > > include a "parameter" framework, if such a thing were defined in such
| > > a way that it became useful to such implementations.
| > >
| > But shouldn't it be useful on every platform? As a sort of resource
| > manager (because that's what it would become if it would start adressing
| > interdependencies between clocks and voltages).
|
| I couldn't know. This "alternative concept" hasn't gotten very far
| into the hand-waving stage, much less beyond it into proposed interface
| or (gasp!) implementations. Platforms that don't *have* those particular
| interdependencies should not of course incur costs to implement them...
---

Well, that's fine if the platform you use is the current design
center. For the rest of us, though, all the stuff you're currently
doing for power management is wasted effort and why should we incur
costs to work around them? Today, we just configure it all out and put
in our own stuff. We would prefer to have a mainstream framework that
could be used to meet both Intel laptop needs and embedded device needs...

scott
--
scott preece
motorola mobile devices, il67, 1800 s. oak st., champaign, il 61820
e-mail: preece@motorola.com fax: +1-217-384-8550
phone: +1-217-384-8589 cell: +1-217-433-6114 pager: 2174336114@vtext.com