On 20/07/2016 13:46, Geert Uytterhoeven wrote:
Hi Julien,
Hello Geert,
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).
Xen does not disable the clock(s). The problem is Linux thinks the clock
is not used and therefore will disable the clock.
Actually Xen does not have any knowledge how to handle clocks (i.e
setting rate, enabling/disabling). I would recommend you to read the
binding description in the patch and not the implementation which is
IHMO misleading.
Who removes the device node from the DT? If Xen, can't it just remember
which clocks were present in removed device nodes?
Xen is removing the node from the DT. Not removing the node will not
change the problem. Linux is disabling the clock because there is no
driver which used those clocks.
As the clock subsystem will disable any unused clocks (from Linux point
of view), the UART will get disabled and the console will be lost.
What we want to achieve with this patch is to let Linux knows that this
clock is in use by someone else (hypervisor or guest) and:
* If the clock is not shared: don't disable it
* If the clock is shared: don't change the rate
What to do on SoCs where the serial device is part of a power area (e.g.
Renesas SH/R-Mobile)? Who will make sure it is not powered down?
I don't have any knowledge on the Renesas SH/R-Mobile. However, we
expect some cooperation between DOM0 and Xen to handle the power.
For instance managing the clocks in Xen would require to implement clock
driver for each SOC because it does not seem to have a generic way to do it.
Given that Linux already knows a lot about the clock, we want to hand
over the clock control to the hardware domain (i.e dom0). This means
that we have to find a way to cooperate with it to keep enable clocks
that we care about.
Regards,
--
Julien Grall
--
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
