From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: ARM: EXYNOS 5410 - DOM0 not being scheduled Date: Tue, 18 Mar 2014 12:04:12 +0000 Message-ID: <5328363C.6030407@linaro.org> References: <53260A3D.5080202@citrix.com> <5326F6CC.3060303@linaro.org> <5326FE1B.3080800@linaro.org> <53277409.7010900@linaro.org> <1395136344.12847.13.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1395136344.12847.13.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Suriyan Ramasami , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org Hi Ian, On 03/18/2014 09:52 AM, Ian Campbell wrote: > On Mon, 2014-03-17 at 22:15 +0000, Julien Grall wrote: >>> 2. arch_timer_rate coming up as 0 in dom0 inspite of the dtb defining >>> clock-frequency. >> >> The clock-frequency properties is not given to dom0. It should be able >> to retrieve the frequency from the timer (CNTFRQ). That would mean that >> u-boot is not correctly set up the frequency (it's the only one able to >> do it as it need to be done in secure world). > > If the clock-frequency property is present in the host DT then that > would imply that secure world is not setting CNTFRQ or is setting it > wrong (since the property is effectively a workaround for that exact > bug). Perhaps we should propagate it if it is present? It's easy to do it for dom0, what about guests? I think it would be better to let the bootloader to set up the frequency. I'm a bit surprised that it's not already the case for this board. For instance, on the Arndale the property "clock-frequency" exists but CNTFRQ is also correctly set. > While grepping about this I noticed that make_timer_node doesn't use > DT_MATCH_TIMER, which I guess is just an accidental oversight, perhaps > if someone is fixing the clock-frequency issue they could throw in a > second patch for this too? I think it's an error during the cleanup. Regards, -- Julien Grall