From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Stoppa Subject: Re: So, what's the status on the recent patches here? Date: Sun, 20 Aug 2006 16:19:29 +0300 Message-ID: <1156079970.23845.6.camel@Dogbert.NOE.nokia.com> References: <20060814200735.GC14099@kroah.com> <20060814224623.GH30814@redhat.com> <221e3d51950d20642b3655617527dc52@nomadgs.com> <1155638115.6736.135.camel@localhost> <20060815190439.GI7612@redhat.com> <1155733089.10017.17.camel@Dogbert.NOE.nokia.com> <20060817213903.GD6450@ucw.cz> <1155895341.22100.1.camel@Dogbert.NOE.nokia.com> <44E5DCDB.1080306@linux.intel.com> <1155923647.22100.43.camel@Dogbert.NOE.nokia.com> <44E62B84.4080005@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <44E62B84.4080005@linux.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.osdl.org Errors-To: linux-pm-bounces@lists.osdl.org To: ext Alexey Starikovskiy Cc: linux-pm@lists.osdl.org, ext Pavel Machek , "Kucheria Amit (Nokia-M/Tampere)" List-Id: linux-pm@vger.kernel.org On Sat, 2006-08-19 at 00:05 +0300, ext Alexey Starikovskiy wrote: > Igor Stoppa wrote: > > On Fri, 2006-08-18 at 18:29 +0300, ext Alexey Starikovskiy wrote: > >> Igor Stoppa wrote: > >>> On Fri, 2006-08-18 at 00:39 +0300, ext Pavel Machek wrote: > >>>> Hi! > >>>> > >>>>>> If there are dependancies inherently linking core1 and core2, > >>>> cpufreq > >>>>>> should already be programming both parts. For example, the > SA1100 > >>>>>> driver programs both CPU and SDRAM controller. If there isn't > >> any > >>>>>> dependancy > >>>>>> between them, I don't see the attraction of creating an > >> artificial > >>>> one > >>>>>> in the way suggested for no real purpose. > >>>>>> > >>>>>> Things like voltage and frequency are closely tied together, so > >>>>>> offering > >>>>>> any means of controlling them independantly makes no sense > >> afaics. > >>>>> Yet a certain subsystem (for example an onboard camera, in a > >> phone) > >>>>> might require a higher voltage when it's active, effectively > >>>> loosening > >>>>> the tight coupling between freq and voltage that the porcessor > is > >>>>> enforcing. > >>>> So... you expect userland to echo high > state before camera can > be > >>>> used? > >>>> > >>>> I'd rather have kernel automagically up the voltage > >> when /dev/video0 > >>>> is opened... > >>> Not really, I meant that the CPU is not the only customer of power > >>> domains (depend on the HW design), so the relation freq <-> > voltage > >> is > >>> not always true. > >>> > >> Then you need to introduce power domains and associate your devices > >> with them, isn't it? > >> So if your camera appears in the same domain with CPU, the voltage > of > >> that domain will go up either with camera=3Don, or CPU going to > higher > >> frequency. > > > > I used the expression "power domain" to refer to a generic domain, > > either voltage or frequency, to indicate that changing either freq > or > > voltage in a domain implies changing the domain power level. > > > > Of course it is changing linearly with frequency, while the > dependency > > from voltage is quadratic. > > > > So in the camera example we might have 2 different cases: > > > > -the one mentioned above, where the camera shares the same voltage > > domain with CPU and the correlation is the one you described > > > > -another case where the clock frequency provided to the camera is > > related to the resolution being used > > > > camera off =3D> no constraints > > low res =3D> low freq, high voltage > > high res =3D> high freq, high voltage > > > > in such case the currently active resolution would affect whatever > > device shares the camera clock, if any. > > > > But no need to introduce power domains. > > > How about introducing a frequency domain as well? The clock framework deals with clock correlations and dependencies. -- = Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere)