Re: So, what's the status on the recent patches here?

[Igor Stoppa <igor.stoppa@nokia.com>]

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=on, 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 => no constraints
> > low res => low freq, high voltage
> > high res => 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)