[linux-pm] Alternative Concept [Was: Re: [RFC] CPUFreq PowerOP integration, Intro 0/3]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux