Hi! > That's it. Bottom line is: what you are talking about is NOT an Alternative > Concept but a particular case instead. While PowerOP design is > generic case. Fine then; submit powerOP with interface Dominik suggested. Notice that his solution exposes all the knobs to userspace directly, so his interface _is_ different to yours. "i_am_special" is just one of knobs. > The last remark about 256 CPU case. Leveraging POwerOP such systems will be > built using just one (current) operating point approach as described > above. Notice that Dominik's solution still allows to have more than one operating point for each of 256 CPUs without explosion of number of states. Pavel > > F) So, how would this work for OMAP1? > > > > Let's limit it, to keep it somewhat simple, to the values contained in your > > "struct pm_core_point" for OMAP: > > > > int cpu_vltg; /* voltage in mV */ > > int dpll; /* in KHz */ > > int cpu; /* CPU frequency in KHz */ > > int tc; /* in KHz */ > > int per; /* in KHz */ > > int dsp; /* in KHz */ > > int dspmmu; /* in KHz */ > > int lcd; /* in KHz */ > > > > and let's also add a > > > > int i_am_special; > > > > Let's assume that there is an OMAP1 PM module which implements a ->set and > > ->get function for all of them. A yet-to-be-defined interface then tells > > this PM module -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html