Thread (47 messages) 47 messages, 4 authors, 2017-01-31

[PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

From: Fu Wei <hidden>
Date: 2017-01-31 19:08:08
Also in: linux-acpi, linux-watchdog, lkml

Hi Mark,

On 1 February 2017 at 02:49, Mark Rutland [off-list ref] wrote:
On Wed, Feb 01, 2017 at 02:43:02AM +0800, Fu Wei wrote:
quoted
On 31 January 2017 at 01:49, Mark Rutland [off-list ref] wrote:
quoted
On Thu, Jan 26, 2017 at 01:49:03PM +0800, Fu Wei wrote:
quoted
On 26 January 2017 at 01:25, Mark Rutland [off-list ref] wrote:
quoted
On Wed, Jan 25, 2017 at 02:46:12PM +0800, Fu Wei wrote:
quoted
On 25 January 2017 at 01:24, Mark Rutland [off-list ref] wrote:
quoted
On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu.wei at linaro.org wrote:
quoted
From: Fu Wei <redacted>
quoted
But according to another document(ARMv8-A Foundation Platform User
Guide  ARM DUI0677K),
Table 3-2 ARMv8-A Foundation Platform memory map (continued)

AP_REFCLK CNTBase0, Generic Timer 64KB   S
AP_REFCLK CNTBase1, Generic Timer 64KB   S/NS

Dose it means the timer frame 0 can be accessed in SECURE status  only,
and the timer frame 1 can be accessed in both status?
That does appear to be what it says.

I assume in this case CNTCTLBase.CNTSAR<0> is RES0.
quoted
And because Linux kernel is running on Non-secure EL1, so should we
skip "SECURE" timer in Linux?
I guess you mean by checking the GTx Common flags, to see if the timer
is secure? Yes, we must skip those.
Yes, exactly.

I think we can check the  GTx Common flags, if the timer is set as
SECURE, this driver should just skip this timer.
I completely agree that we must skip these.
quoted
quoted
Looking further at this, the ACPI spec is sorely lacking any statement
as to the configuration of CNTCTLBase.{CNTSAR,CNTTIDR,CNTACR}, so it's
not clear if we can access anything in a frame, even if it is listed as
being a non-secure timer.

I think we need a stronger statement here. Otherwise, we will encounter
problems. Linux currently assumes that CNTCTLBase.CNTACR<N> is
writeable, given a non-secure frame N. This is only the case if
CNTCTLBase.CNTSAR.NS<N> == 1.
the original driver has checked these registers, but the problem is:
What if the timer frame is designed to be a secure timer, all the
register in this frame is only can be accessed in secure status, just
like foundation model?
Note: for foundation model, Please check Table 3-1 Access permissions
of 3.1 ARMv8-A Foundation Platform memory map in ARMv8-A Foundation
Platform User Guide

So I think we should check the GTDT first, if it's not a secure timer,
then we can go on checking CNTSAR. :-)
I've clearly confused matters here. I completely agree that we must skip
timers the GTDT descrbies as secure.
Yes, got it :-)
My complaint here is that the spec does not explicitly state that
CNTCTLBase.CNTSAR.NS<N> must be set for timers *not* marked as secure
(though I believe that is the intent). That is a spec issue, not a code
issue.
agree :-)
We unfortunately can't check CNTNSAR, as it is secure-only. :(
yes, the spec says:
In a system that implements both Secure and Non-secure states, this
register is only accessible by Secure accesses.

So I think the firmware(from vendor) can decide which timer frame
should be marked as secure according to the GTDT, then kernel just get
this info from GTDT instead of checking CNTNSAR.

Thanks,
Mark.


-- 
Best regards,

Fu Wei
Software Engineer
Red Hat
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help