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@lists.xen.org http://lists.xen.org/xen-devel