Re: [Xen-devel] cpufreq implementation for OMAP under xen hypervisor.

[Andrii Tseglytskyi <andrii.tseglytskyi@xxxxxxxxxxxxxxx>]

On Tue, Sep 2, 2014 at 4:00 AM, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Fri, 29 Aug 2014, Andrii Tseglytskyi wrote:
>> Hi,
>>
>> Stefano, Ian,
>>
>> Could you please clarify the following point:
>>
>> I agree that decision about frequency change should be taken by Xen
>> hypervisor. But what about hardware frequency changing?
>> In general when frequency changed to bigger value (for example from 1
>> GHz to 1.5 GHz) for ARM kernels sequence looks like the following:
>>
>> 1) cpufreq governor decides that frequency should be changed. This
>> decision is taken after analysing of CPU performance data taking in
>> account governor policy.
>> 2) cpufreq governor asks cpufreq driver about new frequency.
>> 3) cpufreq driver compares current and target frequencies and asks
>> cpufreq regulator about voltage change.
>> 4) cpufreq regulator send i2c command to standalone microchip, which
>> is responsible for voltage changing.
>> 5) cpufreq driver asks clock framework about new frequency for CPU clock
>> 6) clock framework performs frequency sanity checks, taking in account
>> clock parents and clock divider settings, and call platform specific
>> "set_frequency" callback.
>> 7) platform specific callback performs proper HW registers
>> configuration for newly selected frequency
>>
>> Also there are some special cases - for example for OMAP5+ when
>> frequency is changed to 1.5 GHz+, two additional HW IPs should be
>> triggered (ABB and DCC, if someone is familiar with OMAP5+ )
>>
>> So, for generic ARM kernel we have 3 entities to change frequency:
>>
>> - cpufreq governor
>> - cpufreq driver
>> - cpufreq regulator
>>
>> + 2 additional IP for OMAP5+
>> - ABB
>> - DCC
>>
>> Taking in account all above, it looks like it would be better to
>> implement only Xen cpufreq governor. Xen will take a decision about
>> new frequency, and kernel dom0 will perform other steps. Dom0 contains
>> all generic and platform specific frameworks, needed for frequency
>> changing.
>>
>> What do you think ?
>
> Keep in mind that the architecture must be able to handle the case where
> dom0 has only 1 or 2 vcpus on a 4 or 8 cores system with multiple
> physical cpus.
> Could dom0 change the frequency of a physical core or a physical cpu is
> not even running on? If that is not a problem, because cpus and
> frequency changing are decoupled enough in Linux to allow it, then I am
> OK with it. But I suspect they are not.
>

Not sure that I got your point correctly - dom0 will change frequency
on physical CPU.
And in case of OMAP - this changing affects on both ARM physical cpus
- changing is coupled.
In case of other ARM platforms - changing may be not coupled (I've
heard that Snapdragon can change cpu freqs independently on each
physical cpu)

Regrads,
Andrii

-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel