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.
--
Cheers,
Igor
Igor Stoppa (Nokia M - OSSO / Tampere)
