On Fri, Oct 13, 2006 at 12:55:04PM +0200, Pavel Machek wrote: > 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. I am very keen on Dominic's design concept, however; I missed his sysfs interface that exposes the knobs to userspace. I've search the archives and still don't see any interface to user space users. --mgross > > > 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 > _______________________________________________ > linux-pm mailing list > linux-pm at lists.osdl.org > https://lists.osdl.org/mailman/listinfo/linux-pm
