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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2016-01-20 at 12:06 +0000, Stefano Stabellini wrote:
> On Wed, 20 Jan 2016, Peng Fan wrote:
> > To my use case, Dom0 and DomU both use device tree, I need to build
> > the mapping table between id and name, since I use name to lookup
> > the clk in backend, like this:
> > "clk = __clk_loopkup(clkname); clk_prepare_enable(clk)". Maybe ACPI
> > is another different case.
> 
> Theoretically on systems using ACPI there is no need to fiddle with
> clocks,

I mentioned ACPI in my replies to v1 more as a placeholder for "other
firmware descriptions than DT", in order that the pv protocol we end up
with does not end up being DT specific, which would be a mistake
irrespective of what may or may not be required for non-DT firmware
descriptions.

Ian.

>  see
> 
> Documentation/arm64/arm-acpi.txt
> 
> 
> "In DT, clocks need to be specified
> and the drivers need to take them into account.ÂÂIn ACPI, the assumption
> is that UEFI will leave the device in a reasonable default state,
> including
> any clock settings.ÂÂIf for some reason the driver needs to change a
> clock
> value, this can be done in an ACPI method; all the driver needs to do is
> invoke the method and not concern itself with what the method needs to do
> to change the clock.ÂÂChanging the hardware can then take place over time
> by changing what the ACPI method does, and not the driver.
> 
> In DT, the parameters needed by the driver to set up clocks as in the
> example
> above are known as "bindings"; in ACPI, these are known as "Device
> Properties"
> and provided to a driver via the _DSD object."
> 
> 
> However currently we don't have the ability to run ACPI in DomU guests
> on ARM. Even if we had, there is no way to call native ACPI methods from
> any guests other than Dom0, even on x86. We just have to hope that
> clocks don't need to be reset on ACPI systems.

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