CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007]

[Mark Haywood]

Terry (Sarito) Whatley wrote:
> Anup Pemmaiah wrote:
>> Artem Kachitchkine wrote:
>>  
>>> ...
>>>> The CPUFreq interface is associated with the "computer" device 
>>>> object, similar to system power management interface. Since it is 
>>>> global there will be just one method call.
>>>>       
>>> OK, so based on our little q&a, things missing from the interface table:
>>>
>>> - DBus interface name (org.freedesktop.Hal.Device.CPUFreq?)
>>> - DBus path of the objects that implement that interface 
>>> (/org/freedesktop/Hal/devices/computer?)
>>> - "processor" capability for processor objects
>>> - I think also "cpufreq_control" capability for the computer object
>>>     
>> Have updated the psarc draft with the missing interfaces. I am pasting 
>> below the additional interfaces added to the draft
>>
>> The processor specific properties interface
>>   Interface        Type             Comments
>>    ---------------------------------------------------------------
>> info.capabilities    string list    value = "processor"
>>
>>
>>     The computer device object specific properties interface. If the 
>> property
>>     already exists, then the following values will get appended
>>
>>    Interface        Type             Comments
>>    ---------------------------------------------------------------
>>    info.capabilities    string list    value = "cpufreq_control"
>>    info.interfaces    string list    value = 
>> "org.freedesktop.Hal.Device.CPUFreq"
>>    info.addons        string list    value = "hald-addon-cpufreq"  
>>    D-Bus specific Information
>>    ---------------------------
>>
>>   Interface Name:        org.freedesktop.Hal.Device.CPUFreq
>>              Path to device object        
>> /org/freedesktop/Hal/devices/computer
>>   that implements the
>>   interface
>>
>> Interfaces Imported:
>>
>>    
>> Interface                                                            
>>     Comments
>  As per PSARC 20005/267, the pm ioctls below are undocumented, 
> consolidation private interfaces.
> The current case proposes to use /etc/power.conf and pmconfig (both 
> documented and committed interfaces)
> to control the policy.  Since they already have to parse /etc/power.conf 
> to do this, it makes no
> sense to bypass /etc/power.conf (via the ioctls listed below) when 
> attempting to determine what the current
> pm state is.  It would be better to parse the power.conf file to get 
> this information, since it
> contains the necessary information in a stable format (though one that 
> needs more decoding).
>  Note that to do what is proposed below would also require adding a line 
> to the diagram
> in the case materials that bypasses power.conf and pmconfig to go 
> directly to the kernel layer ioctl
> interface.

No, I don't think that it will be sufficient to use the power.conf file 
to get the information since the power.conf file does not necessarily 
represent the current state of the system. The only way to know how the 
system is currently configured it to ask the framework. Since the HAL 
code resides in the ON consolidation I see no issue with it using the 
consolidation private interfaces?

> 
> thanks,
> Terry (Sarito) Whatley
> 
>>    
>> ----------------------------------------------------------------------------------------------------------- 
>>
>>   PM_GET_CPU_THRESHOLD       Used by GetCPUFreqPerformance to 
>> determine the
>>                                                               
>> frequency performance.
>>        PM_GET_SYSTEM_THRESHOLD     Used by GetCPUFreqPerformance to 
>> determine the
>>                                                                       
>> frequency performance.
>>
>>
>>    PM_GET_CPUPM_STATE            Used by GetCPUFreqGovernor to 
>> determine the
>>                                                              current 
>> system policy.
>>
>>    PM_GET_PM_STATE                    Used by GetCPUFreqGovernor to 
>> determine the
>>                                                              current 
>> system policy.
>>
>>
>> The new draft can be found at
>> http://sac.eng/arc/PSARC/2007/679/materials/spec.v1.txt
>>
>> Thanks
>> Anup
>>  
>>> Could you also place a copy of hal-spec.html in the case directory, 
>>> because the one at freedesktop.org changes frequently.
>>>
>>> thanks,
>>> -Artem
>>>     
>>
>> _______________________________________________
>> opensolaris-arc mailing list
>> opensolaris-arc at opensolaris.org
>>   
>