Re: cpufreq implementation for OMAP under xen hypervisor.

[Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>]

On Thu, Sep 18, 2014 at 5:59 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>> > > 2. Driver in Dom0 will parse /cpus/cpu@0/private_data path instead of the /cpus
>> > > path and give the information about CPUs parameters to the hypervisor via
>> > > XENPF_set_processor_pminfo hypercall. (Some parameters are calculated in the
>> > > Dom0 driver and can not be calculated  in the hypervisor).
>> >
>> > Which driver? I presume it would be similar to the xen-acpi-processor.c driver
>> > in drivers/xen?
>> I meant slightly modified cpufreq-cpu0 driver in Linux kernel - driver
>> which changes
>> frequency and voltage on the OMAP CPU. And this driver will use part of the
>
> OK, is that something you would upstream as well? Which of the ARM cpufreq
> drivers is this?
I'll try to upstream it. But at first I should write and check that
cpufreq mechanism
is fully working.
This driver is drivers/cpufreq/cpufreq-cpu0.c

>> xen-acpi-processor.c driver to upload P-states for xen.
>> xen-acpi-processor.c driver only uploads the information about
>> P-states and C-states
>> to the xen and xen can change CPUs frequency and voltage via ACPI interface.
>> In this case xen works with ACPI interface directly (without Dom0 kernel).
>> In case the ARM architecture every processor has own non-standardized interface
>> to change frequency. And in addition we should change voltage on CPU when we
>> change frequency. Every ARM CPU has own external Power Management IC
>> which can change voltage. But Power Management IC has own non-standardized
>> interface and command sequence to change voltage. In my case voltage can
>> be changed via I2C commands. We can not use I2C in the same time in xen
>> and in Dom0 (in this case I2C should be virtualized). Thus if we want
>> that cpufreq
>> driver work in the same way for ARM as for x86 we should port to xen a lot of
>> the frameworks from Linux kernel (I2C, clock and regulator framework) and
>> we should virtualize each framework. But we can not do that.
>>
>> > >
>> > > 3. Cpufreq core driver in the hypervisor will communicate via some interface
>> > > with Dom0 (event channel can be used to notify Dom0) and give some commands
>> > > to the CPU driver in Dom0. Those command are set/get frequency, etc.
>> >
>> > Like the 'xenpm' which does that?
>> Not exactly. 'xenpm' communicates via hypercalls with Xen. In this case
>> xen acts as slave. And all cpufreq drivers are inside xen. In my case
>> part of the
>> cpufreq driver will be implemented in the Linux kernel (Dom0) and xen should
>> act as master and give commands to the cpufreq CPU driver in Dom0
>> (this driver will only change frequency and voltage on physical CPUs).
>
> Oh, I must have misunderstood your picture. In it the cpufreq and the
> lot seemed to be all inside Xen.
Yes, but there is a 'CPU driver' on the picture and this driver is
drivers/cpufreq/cpufreq-cpu0.c
in the Linux kernel.

>
>> I
>> > >
>> > > Can I implement cpufreq driver in this way?
>> >
>> > I don't see why not. Thought I am curious to what is the 'driver' you
>> > are referring too. I presume it is the one that reads the voltage values
>> > from something (what is that "Something" ?)?
>> I've written about this driver above. This driver (in Dom0) will read
>> information
>> about voltages and frequencies from Device Tree. This Device Tree is created
>> by xen for Dom0.
>
> And this driver is based on some Linux driver right ? Which one?
This driver is drivers/cpufreq/cpufreq-cpu0.c and it reads all information
from the Device Tree. Also this driver can change voltage and frequency
on physical CPU (using 'clock' and 'regulator' frameworks).

Oleksandr Dmytryshyn | Product Engineering and Development
GlobalLogic
M +38.067.382.2525
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt