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?
