On 20.07.2016 14:46, Geert Uytterhoeven wrote:
Hi Julien,
On Wed, Jul 20, 2016 at 2:10 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
On 20/07/16 12:49, Geert Uytterhoeven wrote:
On Wed, Jul 20, 2016 at 1:01 PM, Julien Grall <julien.grall@xxxxxxx>
wrote:
On 20/07/16 10:43, Geert Uytterhoeven wrote:
On Tue, Jul 12, 2016 at 9:46 AM, Dirk Behme <dirk.behme@xxxxxxxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
