Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2016-01-21 at 19:55 +0800, Peng Fan wrote:
> Hi Ian,
> 
> On Thu, Jan 21, 2016 at 10:19:32AM +0000, Ian Campbell wrote:
> > On Thu, 2016-01-21 at 16:59 +0800, Peng Fan wrote:
> > > Â
> > > To platform device of ARM, hypervisor is responsible for the mapping
> > > between machine address and guest physical address, also responsible
> > > for the irq mapping.
> > > 
> > > But to embedded ARM SoC, the hardware clk IP is handled in Dom0.
> > 
> > Arguably Xen ought to be the one to do this, but we have determined
> > (rightly, I think) that doing so for the entirely clk tree of an SoC
> > would
> > involve importing an unmanageable amount of code into Xen[0].
> > 
> > In the meantime we defer this to Dom0.
> > 
> > I wonder though if it would be possible to manage the clocks for a
> > passthrough device from the toolstack, i.e. is there a sysfs node where
> > one
> > can say "keep the clock for this device enabled (at xMhz) even though
> > you
> > think the device is unused"?
> 
> I am afraid not. The linux device driver without xen can work well,
> because
> there is clk tree and "clk_get,clk_prepare,clk_set_rate" work well in the
> driver.
> I do not want to remove the clk apis usage from the device driver for
> xen, because the driver
> also serves when no xen support. The pvclk interface is mainly to let the
> clk api can work as no xen.

Would adding a dummy fixed-clock[0] (or several of them) to the guest
passthrough DT satisfy the driver's requirements? They would be hardcoded
to whatever rate dom0 and/or the tools has decided upon (and had set in the
real h/w).

Ian.

[0] Documentation/devicetree/bindings/clock/fixed-clock.txt


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