Hi, On Sun, Oct 08, 2006 at 09:28:15AM -0500, Woodruff, Richard wrote: > > D) Verification > > > > So, how to do this verification? Basically, there are two approaches: > > > > 1) ask every other subsystem whether the new value is OK with it. > > This is what cpufreq currently suggests to do. It is evident > > that this gets overly complicated with lots of dependencies > > and dependencies within the dependencies -- both in terms > > of concept and in terms of time the verification code takes > > to execute. > > Advantages: > > - easy to expand, also in runtime (e.g. USB system is > > modprobed and telling you of a new minimum voltage > > requirement on certain circumstances) > > - does not limit choices for each knob > > Disadvantages: > > - might get very complex > > > > 2) look up all valid states in a table > > This is basically what PowerOP and the "operating points" > > concept suggests: if you want to change one value, you check > > what operating points a) contain the new value and b) is > > most suitable to you. > > Advantages: > > - fast > > - pre-defined set of operating points which the system > > designer is comfortable with > > Disadvantages: > > - needs to be limited to "core" of the system as else > > the tables may get overly large > > - limits the choices > > That is a pretty good summary. > > Depending on your operating point definition you don't always have to > limit yourself here. An operating point parameter need not directly be > associated with the physical value of the domain it represents. Meaning > you don't need to put 1.05 volts in for the parameter, you can define it > as some other value which needs translating/defining by the core. First, thanks for your insightful comments. Second, well, we can of course use some discrete values instead of "real" values -- however, if we get the chance, I think it's nicer to put the "real" values there. Unless we need floating point ;) Thanks, Dominik
