public inbox for linux-clk@vger.kernel.org
 help / color / mirror / Atom feed
From: Dirk Behme <dirk.behme@de.bosch.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Dirk Behme <dirk.behme@gmail.com>,
	Mark Rutland <mark.rutland@arm.com>, <devicetree@vger.kernel.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Julien Grall <julien.grall@arm.com>,
	<xen-devel@lists.xenproject.org>, <linux-clk@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4] xen/arm: Add a clock property
Date: Thu, 14 Jul 2016 08:11:16 +0200	[thread overview]
Message-ID: <094be367-ff91-aec7-cbd6-cfb8dc711c54@de.bosch.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1607132002000.26575@sstabellini-ThinkPad-X260>

On 13.07.2016 21:07, Stefano Stabellini wrote:
> On Wed, 13 Jul 2016, Dirk Behme wrote:
>> On 13.07.2016 20:35, Stefano Stabellini wrote:
>>> On Tue, 12 Jul 2016, Dirk Behme 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.
>>>>
>>>> Up to now, the workaround for this has been to use the Linux kernel
>>>> command line parameter 'clk_ignore_unused'. See Xen bug
>>>>
>>>> http://bugs.xenproject.org/xen/bug/45
>>>>
>>>> too.
>>>>
>>>> Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
>>>> ---
>>>> Changes in v4: Switch to the xen.txt description proposed by Mark:
>>>>                 https://www.spinics.net/lists/arm-kernel/msg516158.html
>>>>
>>>> Changes in v3: Use the xen.txt description proposed by Michael. Thanks!
>>>>
>>>> Changes in v2: Drop the Linux implementation details like
>>>> clk_disable_unused
>>>> 	       in xen.txt.
>>>>
>>>>   Documentation/devicetree/bindings/arm/xen.txt | 12 +++++++
>>>>   arch/arm/xen/enlighten.c                      | 47
>>>> +++++++++++++++++++++++++++
>>>>   2 files changed, 59 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/xen.txt
>>>> b/Documentation/devicetree/bindings/arm/xen.txt
>>>> index c9b9321..437e50b 100644
>>>> --- a/Documentation/devicetree/bindings/arm/xen.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/xen.txt
>>>> @@ -17,6 +17,18 @@ the following properties:
>>>>     A GIC node is also required.
>>>>     This property is unnecessary when booting Dom0 using ACPI.
>>>>
>>>> +Optional properties:
>>>> +
>>>> +- clocks: a list of phandle + clock-specifier pairs
>>>> +  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.
>>>> +
>>>> +  Note: 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.
>>>> +
>>>>   To support UEFI on Xen ARM virtual platforms, Xen populates the FDT
>>>> "uefi" node
>>>>   under /hypervisor with following parameters:
>>>>
>>>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>>>> index 47acb36..5c546d0 100644
>>>> --- a/arch/arm/xen/enlighten.c
>>>> +++ b/arch/arm/xen/enlighten.c
>>>> @@ -24,6 +24,7 @@
>>>>   #include <linux/of_fdt.h>
>>>>   #include <linux/of_irq.h>
>>>>   #include <linux/of_address.h>
>>>> +#include <linux/clk-provider.h>
>>>>   #include <linux/cpuidle.h>
>>>>   #include <linux/cpufreq.h>
>>>>   #include <linux/cpu.h>
>>>> @@ -444,6 +445,52 @@ static int __init xen_pm_init(void)
>>>>   }
>>>>   late_initcall(xen_pm_init);
>>>>
>>>> +/*
>>>> + * Check if we want to register some clocks, that they
>>>> + * are not freed because unused by clk_disable_unused().
>>>> + * E.g. the serial console clock.
>>>> + */
>>>> +static int __init xen_arm_register_clks(void)
>>>> +{
>>>> +	struct clk *clk;
>>>> +	struct device_node *xen_node;
>>>> +	unsigned int i, count;
>>>> +	int ret = 0;
>>>> +
>>>> +	xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
>>>> +	if (!xen_node) {
>>>> +		pr_err("Xen support was detected before, but it has
>>>> disappeared\n");
>>>> +		return -EINVAL;
>>>> +	}
>>>
>>> Given that this is a late initcall, the following should work:
>>>
>>>      if (!xen_domain())
>>>          return -ENODEV;
>>
>>
>> Hmm, sorry, "should work" for what?
>
> As a Xen check, if (!xen_domain()) is the common pattern.
>
>> We need the xen_node from device tree, anyway.
>
> In that case, what don't you just use the global xen_node in this file?


With the recent code there is no global xen_node any more:

https://lists.xen.org/archives/html/xen-devel/2016-06/msg02878.html

-- cut --
The code in this file has changed quite a lot with the support of ACPI. 
For instance "xen_node" is not anymore a global variable. Can you rebase 
your rework on top of the branch for-linus-4.8?


You can find the branch in:

git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
-- cut --

Best regards

Dirk

  reply	other threads:[~2016-07-14  6:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-12  7:46 [PATCH v4] xen/arm: Add a clock property Dirk Behme
2016-07-12 22:26 ` Michael Turquette
2016-07-13  8:35   ` Dirk Behme
2016-07-13 18:43     ` Stefano Stabellini
2016-07-13 18:56       ` [Xen-devel] " Dirk Behme
2016-07-13 21:03         ` Michael Turquette
2016-07-14  6:31           ` Dirk Behme
2016-07-14 10:14             ` Julien Grall
2016-07-14 10:32               ` Dirk Behme
2016-07-14 10:38             ` Stefano Stabellini
2016-07-14 10:49               ` Dirk Behme
2016-07-14 15:55                 ` Stefano Stabellini
2016-07-14 16:30                   ` Dirk Behme
2016-07-14 17:14                     ` Julien Grall
2016-07-15  7:53                       ` Dirk Behme
2016-07-22  0:07               ` Michael Turquette
2016-07-22  1:16                 ` Stefano Stabellini
2016-07-27  5:05                   ` Dirk Behme
2016-07-28 11:17                     ` Julien Grall
2016-07-28 14:35                       ` Dirk Behme
2016-07-14 10:25           ` Stefano Stabellini
2016-07-13 18:35 ` Stefano Stabellini
2016-07-13 18:47   ` [Xen-devel] " Dirk Behme
2016-07-13 19:07     ` Stefano Stabellini
2016-07-14  6:11       ` Dirk Behme [this message]
2016-07-14 10:28         ` Stefano Stabellini
2016-07-20  9:43 ` Geert Uytterhoeven
2016-07-20 11:01   ` Julien Grall
2016-07-20 11:49     ` Geert Uytterhoeven
2016-07-20 12:10       ` Julien Grall
2016-07-20 12:46         ` Geert Uytterhoeven
2016-07-20 12:53           ` Dirk Behme
2016-07-20 13:21           ` Julien Grall
2016-07-22  0:14             ` Michael Turquette

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=094be367-ff91-aec7-cbd6-cfb8dc711c54@de.bosch.com \
    --to=dirk.behme@de.bosch.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dirk.behme@gmail.com \
    --cc=julien.grall@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@codeaurora.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox