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

[Terry (Sarito) Whatley]

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.

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
>