[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |