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

From	Mark Rutland <mark.rutland@arm.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.
Date	2017-01-31 12:50 +0100
Message-ID	<t5F6G-bX-21@gated-at.bofh.it> (permalink)
References	(2 earlier) <t3d4S-79G-21@gated-at.bofh.it> <t3pz4-6Kn-17@gated-at.bofh.it> <t3zyr-4DC-45@gated-at.bofh.it> <t3L6x-3sr-13@gated-at.bofh.it> <t5opd-6Tg-43@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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.

Back to linux.kernel | Previous | Next | Find similar | Unroll thread

Thread

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework  counter frequency detection. Mark Rutland <mark.rutland@arm.com> - 2017-01-31 12:50 +0100

csiph-web