[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170131114233.GB11191@leverpostej>
Date: Tue, 31 Jan 2017 11:42:33 +0000
From: Mark Rutland <mark.rutland@....com>
To: Fu Wei <fu.wei@...aro.org>
Cc: Linaro ACPI Mailman List <linaro-acpi@...ts.linaro.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>, rruigrok@...eaurora.org,
Wim Van Sebroeck <wim@...ana.be>, Wei Huang <wei@...hat.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Al Stone <al.stone@...aro.org>,
Tomasz Nowicki <tn@...ihalf.com>,
Timur Tabi <timur@...eaurora.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Guenter Roeck <linux@...ck-us.net>,
Len Brown <lenb@...nel.org>,
"Abdulhamid, Harb" <harba@...eaurora.org>,
Julien Grall <julien.grall@....com>,
linux-watchdog@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
Marc Zyngier <marc.zyngier@....com>,
Jon Masters <jcm@...hat.com>,
Christopher Covington <cov@...eaurora.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-arm-kernel@...ts.infradead.org,
G Gregory <graeme.gregory@...aro.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Leo Duran <leo.duran@....com>,
Hanjun Guo <hanjun.guo@...aro.org>,
Suravee Suthikulpanit <Suravee.Suthikulpanit@....com>,
Sudeep Holla <sudeep.holla@....com>,
Christoffer Dall <christoffer.dall@...aro.org>
Subject: Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework
counter frequency detection.
On Mon, Jan 30, 2017 at 05:49:59PM +0000, Mark Rutland wrote:
> On Thu, Jan 26, 2017 at 01:49:03PM +0800, Fu Wei wrote:
> > 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.
>
> 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.
Given CNTNSAR.NS<n> enables non-secure access to CNTACR<n>, I guess the
obvious interpretation is that for frames listed as non-secure, this has
been configured to permit non-secure access to the frame and associated
CNTACR<n>.
I will work to that assumption while reviewing, though I still believe
this needs to be clarified in the spec.
Thanks,
Mark.
Powered by blists - more mailing lists