From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected timer binding
Date: Mon, 15 Apr 2013 14:33:37 -0700 [thread overview]
Message-ID: <516C7231.6060305@codeaurora.org> (raw)
In-Reply-To: <516C6F12.5020208@gmail.com>
On 04/15/13 14:20, Rob Herring wrote:
> On Fri, Apr 12, 2013 at 7:27 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> @@ -26,3 +30,52 @@ Example:
>> <1 10 0xf08>;
>> clock-frequency = <100000000>;
>> };
>> +
>> +** Memory mapped timer node properties
>> +
>> +- compatible : Should at least contain "arm,armv7-timer-mem".
> Everything about this timer is architecturally defined? If not, let's
> use a more specific name.
I'm not sure I'm following you, but everything described here is part of
the ARM definition. What would be a more specific name?
>
>> +
>> +- clock-frequency : The frequency of the main counter, in Hz. Optional.
>> +
>> +- reg : The control frame base address.
>> +
>> +Note that #address-cells, #size-cells, and ranges shall be present to ensure
>> +the CPU can address a frame's registers.
>> +
>> +Frame:
>> +
>> +- frame-number: 0 to 7.
> I'd really like to get rid of the frame numbers and sub-nodes. Is the
> frame number significant to software?
We need the frame number to read and write registers in the control
frame (the first base in the parent node). We currently use it to
determine if a frame has support for the virtual timer by reading the
CNTTIDR (a register with 4 bits per frame describing capabilities). If
we wanted to control access to the second view of a frame we would also
need to configure the CNTPL0ACRn register that pertains to the frame
we're controlling. Without a frame number we wouldn't know which
register to write.
>
>> +- interrupts : Interrupt list for physical and virtual timers in that order.
>> + The virtual timer interrupt is optional.
> Is that optional per frame?
Yes the virtual and physical timer interrupt is per-frame and the
virtual interrupt is optional.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2013-04-15 21:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-13 0:27 [PATCHv2 0/4] Memory mapped architected timers Stephen Boyd
2013-04-13 0:27 ` [PATCHv2 1/4] Documentation: Add memory mapped ARM architected timer binding Stephen Boyd
2013-04-15 21:20 ` Rob Herring
2013-04-15 21:33 ` Stephen Boyd [this message]
2013-04-25 18:35 ` Stephen Boyd
2013-04-25 21:47 ` Rob Herring
2013-04-25 22:48 ` Stephen Boyd
2013-04-25 23:06 ` Rob Herring
2013-04-25 23:25 ` Stephen Boyd
2013-04-26 11:09 ` Mark Rutland
2013-04-13 0:27 ` [PATCHv2 2/4] ARM: arch_timers: Pass clock event to set_mode callback Stephen Boyd
2013-04-13 0:27 ` [PATCHv2 3/4] clocksource: arch_timer: Push the read/write wrappers deeper Stephen Boyd
2013-04-13 0:27 ` [PATCHv2 4/4] clocksource: arch_timer: Add support for memory mapped timers Stephen Boyd
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=516C7231.6060305@codeaurora.org \
--to=sboyd@codeaurora.org \
--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).