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

[Alexey Starikovskiy <alexey_y_starikovskiy@linux.intel.com>]

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?