[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.

>> 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).

>> Oleksandr Dmytryshyn | Product Engineering and Development
>> GlobalLogic
>> M +38.067.382.2525
>> www.globallogic.com
>> http://www.globallogic.com/email_disclaimer.txt
>> On Tue, Aug 12, 2014 at 3:15 PM, Stefano Stabellini
>> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> > On Tue, 12 Aug 2014, Oleksandr Dmytryshyn wrote:
>> >> Hi to all.
>> >>
>> >> I want to implement an cpufreq support for OMAP processors in xen. I
>> >> use the Linux kernel as Dom0.
>> >>
>> >> I know that there are 2 implementations of cpufreq: Domain0 based
>> >> cpufreq and Hypervisor based cpufreq. But those implementations are
>> >> made only for x86 architecture, not for the ARM architecture.
>> >>
>> >> Could anybody give me an advise how to do that?
>> >
>> > I think that the best way would be to introduce cpufreq support directly
>> > in the Xen hypervisor.  I would:
>> >
>> > 1) get cpufreq (xen/drivers/cpufreq) to build and run on ARM, with a dummy 
>> > driver
>> > although the cpufreq infrastructure has been written with x86 in mind,
>> > it should be generalizable
>> >
>> > 2) write a cpufreq driver for OMAP
Oleksandr Dmytryshyn | Product Engineering and Development
M +38.067.382.2525


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.