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

From: Mark Gross <mgross@linux.intel.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: pm list <linux-pm@lists.osdl.org>,
	Dominik Brodowski <linux@dominikbrodowski.net>
Subject: Re: Alternative Concept [Was: Re: [RFC] CPUFreq PowerOP integration, Intro 0/3]
Date: Mon, 16 Oct 2006 14:44:54 -0700	[thread overview]
Message-ID: <20061016214454.GA18975@linux.intel.com> (raw)
In-Reply-To: <20061013105504.GA1913@elf.ucw.cz>

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@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/linux-pm