Re: [RFC V2] xen: interface: introduce pvclk interface

[Peng Fan <van.freenix@gmail.com>]

Hi Ian, Stefano

On Wed, Jan 20, 2016 at 12:27:07PM +0000, Ian Campbell wrote:
>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.

Thanks for clarifying. Beside this, are you ok with the xenstore node description in this file?

Thanks,
Peng.

>
>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.