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

[Oleksandr Dmytryshyn <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx>]

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