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

[Andrii Tseglytskyi <andrii.tseglytskyi@xxxxxxxxxxxxxxx>]

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 ?

Regards,
Andrii


On Fri, Aug 29, 2014 at 4:25 PM, Oleksandr Dmytryshyn
<oleksandr.dmytryshyn@xxxxxxxxxxxxxxx> wrote:
> On Fri, Aug 22, 2014 at 7:31 PM, Stefano Stabellini
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> On Fri, 22 Aug 2014, Oleksandr Dmytryshyn wrote:
>>> Hi, Stefano.
>>>
>>> On Fri, Aug 22, 2014 at 2:31 AM, Stefano Stabellini
>>> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>>> > CC'ing the x86 maintainers and the cpufreq original author.
>>> >
>>> >
>>> > On Thu, 21 Aug 2014, Oleksandr Dmytryshyn wrote:
>>> >> Hi to all.
>>> >>
>>> >> I'm planning to do next work:
>>> >>
>>> >> 1. Move file xen/include/acpi/cpufreq/cpufreq.h to the
>>> >> xen/include/drivers/cpufreq/cpufreq.h
>>> >> 2. Create a new file xen/arch/x86/acpi/cpufreq/cpufreq_common.c
>>> >
>>> > you can call it cpufreq.c or cpufreq_ops.c
>>> I'll call it cpufreq_ops.c
>>>
>>> >> 3. Move some acpi-specific functions from
>>> >> xen/drivers/cpufreq/cpufreq.c to the
>>> >> xen/arch/x86/acpi/cpufreq/cpufreq_common.c:
>>> >> cpufreq_limit_change(), print_PCT(), print_PSS(), print_PSD(),
>>> >> print_PPC(), set_px_pminfo().
>>> >
>>> > Why cpufreq_limit_change?
>>> The function cpufreq_limit_change() is called only in the set_px_pminfo()
>>> function and will not be used for the ARM architecture.
>>
>> I see.
>> One thing to keep in mind is that although P states are obviously an
>> Intel concept, we could abstract them away and map them into
>> arch-independent power-saving states. That way we could share functions
>> like set_px_pminfo between ARM and x86. But I would have to see the
>> patches to actually know how feasible that is.
> Here is my RFC implementation:
> http://lists.xen.org/archives/html/xen-devel/2014-08/msg02919.html
>
>>> >> 4. Create a new file xen/arch/arm/cpufreq/cpufreq_common.c
>>> >> 5. Functions cpufreq_add_cpu()/cpufreq_del_cpu() should be implemented
>>> >> separately for the x86 and ARM architecture (in the correspond file
>>> >> cpufreq_common.c).
>>> >
>>> > Why? The implementation doesn't look x86 specific.
>>> The function cpufreq_add_cpu()/cpufreq_del_cpu() uses the acpi-specific
>>> data structures. I don't know how make them common for both architectures
>>> but I'll try to do this.
>>>
>>> >> 6. Port cpufreq driver for the OMAP from the Linux kernel.
>>> >>
>>> >> In case ARM the cpufreq driver will read the settings for the
>>> >> operating-points from the device tree and the
>>> >> XENPF_set_processor_pminfo platform hypercall will not be necessary
>>> >> for ARM.
>>> >>
>>> >> Is this the right way to implement the cpufreq for OMAP under xen 
>>> >> hypervisor?
>>> >
>>> > Yes, it's more or less what I had in mind.
>>>
>>> I have a question. I see that the original file cpufreq.c contains
>>> 'Copyright (C)' fields. Could You please tell me which copyrights I should 
>>> add
>>> to the new cpufreq_ops.c files (for x86 and ARM arhitectures).
>>> In case if cpufreq_add_cpu()/cpufreq_del_cpu() functions will be common for 
>>> both
>>> architectures there will be only one cpufreq_ops.c file for x86 
>>> architecture.
>>> But there is a way when we will have two files file cpufreq_ops.c (for
>>> x86 and ARM).
>>
>> I would keep the current Copyright fields for the x86 implementation of
>> cpufreq_ops.c. You can use your own Copyright line for the ARM
>> implementation.
>
>
> --
> Oleksandr Dmytryshyn | Product Engineering and Development
> GlobalLogic
> M +38.067.382.2525
> www.globallogic.com
>
> http://www.globallogic.com/email_disclaimer.txt
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

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