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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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.



> 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