linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.
Date: Mon, 30 Jan 2017 17:49:59 +0000	[thread overview]
Message-ID: <20170130174958.GA3496@leverpostej> (raw)
In-Reply-To: <CADyBb7syNx+HJ6t5JKPMnLqvq-98kPi1knuXU=SSe6_Uz6Gg1A@mail.gmail.com>

On Thu, Jan 26, 2017 at 01:49:03PM +0800, Fu Wei wrote:
> On 26 January 2017 at 01:25, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Wed, Jan 25, 2017 at 02:46:12PM +0800, Fu Wei wrote:
> >> On 25 January 2017 at 01:24, Mark Rutland <mark.rutland@arm.com> wrote:
> >> > On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu.wei at linaro.org wrote:
> >> >> From: Fu Wei <fu.wei@linaro.org>

> > For CNT{,EL0}BaseN.CNTFRQ, I am very concerned by the wording in the
> > current ARMv8 ARM ARM. This does not match my understanding, nor does it
> > match the description in the ARMv7 ARM. I believe this may be a
> > documentation error, and I'm chasing that up internally.
> >
> > Either the currently logic in the driver which attempts to read
> > CNT{,EL0}BaseN.CNTFRQ is flawed, or the description in the ARM ARM is
> > erroneous.
> 
> Yes, those description did confuse me. :-(
> 
> 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.

> 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.

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.

Thanks,
Mark.

  reply	other threads:[~2017-01-30 17:49 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-18 13:25 [PATCH v20 00/17] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer fu.wei at linaro.org
2017-01-18 13:25 ` [PATCH v20 01/17] clocksource/drivers/arm_arch_timer: Improve printk relevant code fu.wei at linaro.org
2017-01-18 13:25 ` [PATCH v20 02/17] clocksource/drivers/arm_arch_timer: Rename the timer type macros fu.wei at linaro.org
2017-01-18 13:25 ` [PATCH v20 03/17] clocksource/drivers/arm_arch_timer: Rename the PPI enum and its values fu.wei at linaro.org
2017-01-18 13:25 ` [PATCH v20 04/17] clocksource/drivers/arm_arch_timer: Move enums and defines to header file fu.wei at linaro.org
2017-01-18 13:25 ` [PATCH v20 05/17] clocksource/drivers/arm_arch_timer: Add a new enum for spi type fu.wei at linaro.org
2017-01-18 13:25 ` [PATCH v20 06/17] clocksource/drivers/arm_arch_timer: rework PPI determination fu.wei at linaro.org
2017-01-18 13:25 ` [PATCH v20 07/17] clocksource/drivers/arm_arch_timer: Separate out device-tree code from arch_timer_detect_rate fu.wei at linaro.org
2017-01-18 13:25 ` [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection fu.wei at linaro.org
2017-01-19  8:02   ` Hanjun Guo
2017-01-19  9:44     ` Fu Wei
2017-01-19 12:41       ` Hanjun Guo
2017-01-24 17:24   ` Mark Rutland
2017-01-25  6:46     ` Fu Wei
2017-01-25  7:23       ` Fu Wei
2017-01-25 15:38       ` Christopher Covington
2017-01-25 17:36         ` Mark Rutland
2017-01-26  5:55           ` Fu Wei
2017-01-25 17:25       ` Mark Rutland
2017-01-26  5:49         ` Fu Wei
2017-01-30 17:49           ` Mark Rutland [this message]
2017-01-31 11:42             ` Mark Rutland
2017-01-31 18:43             ` Fu Wei
2017-01-31 18:49               ` Mark Rutland
2017-01-31 19:07                 ` Fu Wei
2017-01-18 13:25 ` [PATCH v20 09/17] clocksource/drivers/arm_arch_timer: Refactor arch_timer_needs_probing fu.wei at linaro.org
2017-01-18 13:25 ` [PATCH v20 10/17] clocksource/drivers/arm_arch_timer: Move arch_timer_needs_of_probing into DT init call fu.wei at linaro.org
2017-01-18 13:25 ` [PATCH v20 11/17] clocksource/drivers/arm_arch_timer: Introduce some new structs to prepare for GTDT fu.wei at linaro.org
2017-01-19  8:28   ` Hanjun Guo
2017-01-19  9:47     ` Fu Wei
2017-01-18 13:25 ` [PATCH v20 12/17] clocksource/drivers/arm_arch_timer: Refactor MMIO timer probing fu.wei at linaro.org
2017-01-18 13:25 ` [PATCH v20 13/17] acpi/arm64: Add GTDT table parse driver fu.wei at linaro.org
2017-01-19  9:11   ` Hanjun Guo
2017-01-19 10:32     ` Fu Wei
2017-01-19 11:16       ` Mark Rutland
2017-01-19 12:28         ` Fu Wei
2017-01-18 13:25 ` [PATCH v20 14/17] clocksource/drivers/arm_arch_timer: Simplify ACPI support code fu.wei at linaro.org
2017-01-18 13:25 ` [PATCH v20 15/17] acpi/arm64: Add memory-mapped timer support in GTDT driver fu.wei at linaro.org
2017-01-18 13:25 ` [PATCH v20 16/17] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer fu.wei at linaro.org
2017-01-19  9:16   ` Hanjun Guo
2017-01-19 10:02     ` Fu Wei
2017-01-19 12:42       ` Hanjun Guo
2017-01-18 13:25 ` [PATCH v20 17/17] acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver fu.wei at linaro.org
2017-01-19  9:20 ` [PATCH v20 00/17] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer Hanjun Guo
2017-01-19 11:06   ` Fu Wei
2017-01-23 18:54 ` Mark Rutland
2017-01-24  5:11   ` Fu Wei

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=20170130174958.GA3496@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).