Message-ID: <5179A488.5050102@gmail.com>
Date: Thu, 25 Apr 2013 16:47:52 -0500
From: Rob Herring <robherring2@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Stephen Boyd <sboyd@codeaurora.org>
CC: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        "devicetree-discuss@lists.ozlabs.org" 
	<devicetree-discuss@lists.ozlabs.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected
 timer binding
References: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org> <1365812863-5367-2-git-send-email-sboyd@codeaurora.org> <516C6F12.5020208@gmail.com> <516C7231.6060305@codeaurora.org>
In-Reply-To: <516C7231.6060305@codeaurora.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2928
Lines: 72

On 04/15/2013 04:33 PM, Stephen Boyd wrote:
> 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?

Something that corresponds to the particular implementation like
cortex-a15 (obviously not an example that has this). I'm fine with
leaving this for now, but would like to see that added when specific SOC
dts are added. Better to be specific in case we need to use it for
something like errata work-arounds. Of course we haven't done that so
far with the arch timer bindings...

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

I've gone thru the memory mapped part of the spec now, so I think I
understand things better. I see how the frame number is needed, but...

The control base is only accessible in secure or hyp mode. How does a
guest know that it is a guest and can't map the control base? Seems like
we need to allow a subset of the binding that is just a reg and
interrupts properties without the frame sub nodes.

Rob

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/