[PATCH v4] xen/arm: Add a clock property
Dirk Behme
dirk.behme at de.bosch.com
Wed Jul 20 05:53:44 PDT 2016
On 20.07.2016 14:46, Geert Uytterhoeven wrote:
> Hi Julien,
>
> On Wed, Jul 20, 2016 at 2:10 PM, Julien Grall <julien.grall at arm.com> wrote:
>> On 20/07/16 12:49, Geert Uytterhoeven wrote:
>>> On Wed, Jul 20, 2016 at 1:01 PM, Julien Grall <julien.grall at arm.com>
>>> wrote:
>>>> On 20/07/16 10:43, Geert Uytterhoeven wrote:
>>>>> On Tue, Jul 12, 2016 at 9:46 AM, Dirk Behme <dirk.behme at de.bosch.com>
>>>>> wrote:
>>>>>> Clocks described by this property are reserved for use by Xen, and the
>>>>>> OS
>>>>>> must not alter their state any way, such as disabling or gating a
>>>>>> clock,
>>>>>> or modifying its rate. Ensuring this may impose constraints on parent
>>>>>> clocks or other resources used by the clock tree.
>>>>>>
>>>>>> This property is used to proxy clocks for devices Xen has taken
>>>>>> ownership
>>>>>> of, such as UARTs, for which the associated clock controller(s) remain
>>>>>> under the control of Dom0.
>>>>>
>>>>> I'm not familiar with using XEN at all, but I'm a bit puzzled...
>>>>>
>>>>> Can't you just add a clocks property to the (virtual) serial device node
>>>>> in DT?
>>>>> Then the (virtual) serial device driver can get and enable the clock?
>>>>
>>>> There is no DT node for the Xen console (hvc). The UART used by Xen will
>>>> be
>>>> completely removed from the Device tree.
>>>
>>> Why is it removed?
>>
>> Because the device is used exclusively by Xen and DOM0 should not touch it
>> at all (IRQs and MMIOs are not mapped).
>
> IMHO then it's Xen's responsability to make sure not to disable the clock(s).
>
> Who removes the device node from the DT? If Xen, can't it just remember
> which clocks were present in removed device nodes?
Yes, we are trying this with "moving" the clocks of the removed nodes to
the Xen hypervisor node:
https://lists.xen.org/archives/html/xen-devel/2016-06/msg02605.html
The question discussed here is how to deal with these clocks properly in
Linux, then.
Best regards
Dirk
More information about the linux-arm-kernel
mailing list