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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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.


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

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