Re: cpufreq implementation for OMAP under xen hypervisor.

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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

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