From: Julien Grall <julien.grall@citrix.com>
To: "Chris (Christopher) Brand" <chris.brand@broadcom.com>,
Julien Grall <julien.grall@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
"tim@xen.org" <tim@xen.org>
Subject: Re: [PATCH] xen/arm: Propagate clock-frequency to DOMU if present in the DT timer node
Date: Tue, 9 Jun 2015 19:48:08 -0400 [thread overview]
Message-ID: <55777B38.4050101@citrix.com> (raw)
In-Reply-To: <4EE5B48738DDED408878C97C8E050A8B1D7A554C@SJEXCHMB05.corp.ad.broadcom.com>
On 08/06/2015 16:44, Chris (Christopher) Brand wrote:
> Hi Julien,
Hi Chris,
>> My test was limited as I don't have a platform where CNTFRQ/CNTFRQ_EL0 is not valid. I may have done a mistake in the code.
>
> Understood. That's why I thought it would be worthwhile posting my results :-)
>
>>> What I see is that in preinit_xen_time(), the call to dt_property_read_u32() returns zero. When I built Xen, I set CONFIG_DTB_FILE, and looking at the corresponding dts file it has a timer node with a clock-frequency property. I know that our bootloader also creates a DTB, though, and it looks like that one does *not* have a clock-frequency property in the timer node, so I guess Xen ends up using that one somehow. CNTFRQ on core 0 (only) is also set to the correct frequency, so I end up with the correct frequency in my Dom0 kernel anyway.
>>
>> dt_property_read_u32 returns 0 when it cannot find a property or because the size of the value is not valid.
>>
>> The device tree provided via CONFIG_DTB_FILE will always take precedence to the one pass by the bootloader.
>>
>> How do you set CONFIG_DTB_FILE?
>
> A simple "export CONFIG_DTB_FILE=...".
Are you using an absolute path?
>> I would also look to see if by any chance the wrong device tree is set via CONFIG_DTB_FILE.
>
> I did double-check before I posted, and everything looks right to me. I certainly could have missed something. It does look like it's *somehow* getting the DT generated by the bootloader.
>
>> You can check what is the device tree used by dumping it from DOM0.
>> Thought, it may be slightly different (some nodes are rewritten). You can dump it using dtc -I fs /proc/device-tree -O dts
>
> When I do that (at a shell prompt in Dom0), the timer node does not have a clock-frequency property. So your patch isn't designed to help in this case (CNTFRQ set on core 0 only, no clock-frequency property in timer node of DT).
Well, my patch is designed to propagate the "clock-frequency" property
in DOMU via the toolstack. The propagation for Dom0 is already present
in Xen since last year [1].
I don't usually use CONFIG_DTB_FILE because my bootloader (u-boot via a
script) is creating the different node for Xen (multiboot, chosen,...).
Although, the CONFIG_DTB_FILE implementation in Xen is very obvious
(only 2 lines which override the register which store the pointer in
head.S).
Does your bootloader create Xen nodes (multiboot, chosen, ...) or the
device tree provided by the bootloader contain such nodes? If not, then
you are using an appended DT (via CONFIG_DTB_FILE) to Xen.
If you didn't yet do it, I would try to clean Xen repository and try to
rebuild Xen to see if the build system was using a stall DTB by mistake.
Regards,
[1] 94191dcee8ff9f8b925824e54741f28b954bf95e "xen/arm: Pass the timer
"clock-frequency" to DOM0 in make_timer_node()"
--
Julien Grall
next prev parent reply other threads:[~2015-06-09 23:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 14:48 [PATCH] xen/arm: Propagate clock-frequency to DOMU if present in the DT timer node Julien Grall
2015-06-03 22:45 ` Chris (Christopher) Brand
2015-06-03 23:24 ` Julien Grall
2015-06-05 20:14 ` Chris (Christopher) Brand
2015-06-07 21:04 ` Julien Grall
2015-06-08 20:44 ` Chris (Christopher) Brand
2015-06-09 23:48 ` Julien Grall [this message]
2015-06-10 17:42 ` Julien Grall
2015-06-10 21:41 ` Chris (Christopher) Brand
2015-06-11 21:43 ` Chris (Christopher) Brand
2015-06-12 11:42 ` Julien Grall
2015-06-12 15:16 ` Chris (Christopher) Brand
2015-06-17 10:57 ` Ian Campbell
2015-06-17 12:49 ` Julien Grall
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=55777B38.4050101@citrix.com \
--to=julien.grall@citrix.com \
--cc=chris.brand@broadcom.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=stefano.stabellini@citrix.com \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.