Re: [Xen-devel] [RFC PATCH 11/13] cpufreq: add xen-cpufreq driver

[Oleksandr Dmytryshyn <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx>]

On Fri, Oct 10, 2014 at 5:42 PM, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
>
> On Fri, 10 Oct 2014, Jan Beulich wrote:
> > >>> On 10.10.14 at 11:59, <Ian.Campbell@xxxxxxxxxx> wrote:
> > > A simple i2c driver (without all the generic framework/bus
> > > infrastructure which Linux has) is pretty simple.
> > >
> > > I think the biggest complexity would come from i2c busses with both
> > > cpufreq and other devices on them and managing the potentially shared
> > > accesses.
> >
> > And the recently added XENPF_resource_op would seem a pretty
> > good candidate for this (except that it requires the Dom0 kernel
> > code to stop accessing hardware directly, and instead go through
> > this hypercall).
>
>
> Oleksandr, how would you feel about this change of direction?
I see that XENPF_resource_op is used to safely read/write MSR.
In my case the cpufreq governor driver is inside XEN and the rest of the cpufreq
driver is inside Dom0. Dom0 directly changes CPUs frequency. I don't know how
to use XENPF_resource_op for ARM. If we want to change CPUs frequency that we
should change the voltage and write something to the clock control registers in
ARM. If the I2C driver will be virtualized then Regulator framework
can be inside
Dom0. But every ARM processor has own clock control registers with different
addresses. How in this case I should handle this situation? May be
Clock framework
should be virtualized too? But this is huge framework. Could XENPF_resource_op
be used to read/write given value at given address (not predefined addresses
such as MSR for X86)? If yes that this is possible to not access the hardware
directly from dom0. But Clock framework in Dom0 can read/write a lot of
registers and there will be too much hypercalls.

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