[PATCH v4 0/5] Memory mapped architected timers

[PATCH v4 0/5] Memory mapped architected timers

[Stephen Boyd]

This patchset adds support for memory mapped architected timers. We
don't have any other global broadcast timer in our system, so we use the
mmio timer during low power modes. The first patch changes the register
accessor to an enum per Thomas' request. The second patch is the binding.
The next two patches lay some groundwork so that the last patch is simpler.
The final patch adds support for mmio timers.

Patches are based on v3.11-rc1.

Updates since v3:
 * Rebased onto v3.11-rc1
 * New patch to use compiler warnings instead of BUILD_BUG_ON()

Updates since v2:
 * Rebased onto v3.10-rc1

Updates since v1:
 * Assigned counter reading function and commented why for arm64
 * Updated DT binding to replace frame-id with frame-number and use status
   property


Stephen Boyd (5):
  clocksource: arch_timer: Make register accessors less error-prone
  Documentation: Add memory mapped ARM architected timer binding
  clocksource: arch_timer: Pass clock event to set_mode callback
  clocksource: arch_timer: Push the read/write wrappers deeper
  clocksource: arch_timer: Add support for memory mapped timers

 .../devicetree/bindings/arm/arch_timer.txt         |  59 ++-
 arch/arm/include/asm/arch_timer.h                  |  14 +-
 arch/arm64/include/asm/arch_timer.h                |  23 +-
 drivers/clocksource/arm_arch_timer.c               | 446 +++++++++++++++++----
 include/clocksource/arm_arch_timer.h               |  10 +-
 5 files changed, 455 insertions(+), 97 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH v4 2/5] Documentation: Add memory mapped ARM architected timer binding

[Stephen Boyd]

Add a binding for the arm architected timer hardware's memory
mapped interface. The mmio timer hardware is made up of one base
frame and a collection of up to 8 timer frames, where each of the
8 timer frames can have either one or two views. A frame
typically maps to a privilege level (user/kernel, hypervisor,
secure). The first view has full access to the registers within a
frame, while the second view can be restricted to particular
registers within a frame. Each frame must support a physical
timer. It's optional for a frame to support a virtual timer.

Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: Marc Zyngier <Marc.Zyngier-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
 .../devicetree/bindings/arm/arch_timer.txt         | 59 ++++++++++++++++++++--
 1 file changed, 56 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
index 20746e5..06fc760 100644
--- a/Documentation/devicetree/bindings/arm/arch_timer.txt
+++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
@@ -1,10 +1,14 @@
 * ARM architected timer
 
-ARM cores may have a per-core architected timer, which provides per-cpu timers.
+ARM cores may have a per-core architected timer, which provides per-cpu timers,
+or a memory mapped architected timer, which provides up to 8 frames with a
+physical and optional virtual timer per frame.
 
-The timer is attached to a GIC to deliver its per-processor interrupts.
+The per-core architected timer is attached to a GIC to deliver its
+per-processor interrupts via PPIs. The memory mapped timer is attached to a GIC
+to deliver its interrupts via SPIs.
 
-** Timer node properties:
+** CP15 Timer node properties:
 
 - compatible : Should at least contain one of
 	"arm,armv7-timer"
@@ -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".
+
+- 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.
+
+A timer node has up to 8 frame sub-nodes, each with the following properties:
+
+- frame-number: 0 to 7.
+
+- interrupts : Interrupt list for physical and virtual timers in that order.
+  The virtual timer interrupt is optional.
+
+- reg : The first and second view base addresses in that order. The second view
+  base address is optional.
+
+- status : "disabled" indicates the frame is not available for use. Optional.
+
+Example:
+
+	timer@f0000000 {
+		compatible = "arm,armv7-timer-mem";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		reg = <0xf0000000 0x1000>;
+		clock-frequency = <50000000>;
+
+		frame@f0001000 {
+			frame-number = <0>
+			interrupts = <0 13 0x8>,
+				     <0 14 0x8>;
+			reg = <0xf0001000 0x1000>,
+			      <0xf0002000 0x1000>;
+		};
+
+		frame@f0003000 {
+			frame-number = <1>
+			interrupts = <0 15 0x8>;
+			reg = <0xf0003000 0x1000>;
+			status = "disabled";
+		};
+	};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

Re: [PATCH v4 0/5] Memory mapped architected timers

[Mark Rutland]

Hi Stephen,

On Fri, Jul 19, 2013 at 12:59:27AM +0100, Stephen Boyd wrote:
> This patchset adds support for memory mapped architected timers. We
> don't have any other global broadcast timer in our system, so we use the
> mmio timer during low power modes. The first patch changes the register
> accessor to an enum per Thomas' request. The second patch is the binding.
> The next two patches lay some groundwork so that the last patch is simpler.
> The final patch adds support for mmio timers.
> 
> Patches are based on v3.11-rc1.

Be aware that as of v3.11-rc2 this doesn't cleanly apply, as the
__cpuinit removal broke the final patch's context in a couple of places.
It would be nice to get rid of the new cpuinit additions too...

With that cleaned up locally, I've gave this a spin on tc2 and a
Foundation model to test the cp15/system timers, hotplugging CPUs and
running a basic test (`time sleep 5`). That all seems to work.

Unfortunately I have no way of testing the memory-mapped timer support,
but I trust you've tested that locally.

For the series:

Acked-by: Mark Rutland <mark.rutland@arm.com>

Thanks,
Mark.

> 
> Updates since v3:
>  * Rebased onto v3.11-rc1
>  * New patch to use compiler warnings instead of BUILD_BUG_ON()
> 
> Updates since v2:
>  * Rebased onto v3.10-rc1
> 
> Updates since v1:
>  * Assigned counter reading function and commented why for arm64
>  * Updated DT binding to replace frame-id with frame-number and use status
>    property
> 
> 
> Stephen Boyd (5):
>   clocksource: arch_timer: Make register accessors less error-prone
>   Documentation: Add memory mapped ARM architected timer binding
>   clocksource: arch_timer: Pass clock event to set_mode callback
>   clocksource: arch_timer: Push the read/write wrappers deeper
>   clocksource: arch_timer: Add support for memory mapped timers
> 
>  .../devicetree/bindings/arm/arch_timer.txt         |  59 ++-
>  arch/arm/include/asm/arch_timer.h                  |  14 +-
>  arch/arm64/include/asm/arch_timer.h                |  23 +-
>  drivers/clocksource/arm_arch_timer.c               | 446 +++++++++++++++++----
>  include/clocksource/arm_arch_timer.h               |  10 +-
>  5 files changed, 455 insertions(+), 97 deletions(-)
> 
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 
> 

Re: [PATCH v4 0/5] Memory mapped architected timers

[Stephen Boyd]

On 07/22, Mark Rutland wrote:
> Hi Stephen,
> 
> On Fri, Jul 19, 2013 at 12:59:27AM +0100, Stephen Boyd wrote:
> > This patchset adds support for memory mapped architected timers. We
> > don't have any other global broadcast timer in our system, so we use the
> > mmio timer during low power modes. The first patch changes the register
> > accessor to an enum per Thomas' request. The second patch is the binding.
> > The next two patches lay some groundwork so that the last patch is simpler.
> > The final patch adds support for mmio timers.
> > 
> > Patches are based on v3.11-rc1.
> 
> Be aware that as of v3.11-rc2 this doesn't cleanly apply, as the
> __cpuinit removal broke the final patch's context in a couple of places.
> It would be nice to get rid of the new cpuinit additions too...
> 
> With that cleaned up locally, I've gave this a spin on tc2 and a
> Foundation model to test the cp15/system timers, hotplugging CPUs and
> running a basic test (`time sleep 5`). That all seems to work.
> 
> Unfortunately I have no way of testing the memory-mapped timer support,
> but I trust you've tested that locally.
> 
> For the series:
> 
> Acked-by: Mark Rutland <mark.rutland@arm.com>
> 

Thanks Mark.

Daniel, can you pick up these patches please?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

Re: [PATCH v4 0/5] Memory mapped architected timers

[Stephen Boyd]

On 07/24, Stephen Boyd wrote:
> On 07/22, Mark Rutland wrote:
> > Hi Stephen,
> > 
> > On Fri, Jul 19, 2013 at 12:59:27AM +0100, Stephen Boyd wrote:
> > > This patchset adds support for memory mapped architected timers. We
> > > don't have any other global broadcast timer in our system, so we use the
> > > mmio timer during low power modes. The first patch changes the register
> > > accessor to an enum per Thomas' request. The second patch is the binding.
> > > The next two patches lay some groundwork so that the last patch is simpler.
> > > The final patch adds support for mmio timers.
> > > 
> > > Patches are based on v3.11-rc1.
> > 
> > Be aware that as of v3.11-rc2 this doesn't cleanly apply, as the
> > __cpuinit removal broke the final patch's context in a couple of places.
> > It would be nice to get rid of the new cpuinit additions too...
> > 
> > With that cleaned up locally, I've gave this a spin on tc2 and a
> > Foundation model to test the cp15/system timers, hotplugging CPUs and
> > running a basic test (`time sleep 5`). That all seems to work.
> > 
> > Unfortunately I have no way of testing the memory-mapped timer support,
> > but I trust you've tested that locally.
> > 
> > For the series:
> > 
> > Acked-by: Mark Rutland <mark.rutland@arm.com>
> > 
> 
> Thanks Mark.
> 
> Daniel, can you pick up these patches please?
> 

Ping Daniel?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

Re: [PATCH v4 0/5] Memory mapped architected timers

[Daniel Lezcano]

On 08/01/2013 12:38 AM, Stephen Boyd wrote:
> On 07/24, Stephen Boyd wrote:
>> On 07/22, Mark Rutland wrote:
>>> Hi Stephen,
>>>
>>> On Fri, Jul 19, 2013 at 12:59:27AM +0100, Stephen Boyd wrote:
>>>> This patchset adds support for memory mapped architected timers. We
>>>> don't have any other global broadcast timer in our system, so we use the
>>>> mmio timer during low power modes. The first patch changes the register
>>>> accessor to an enum per Thomas' request. The second patch is the binding.
>>>> The next two patches lay some groundwork so that the last patch is simpler.
>>>> The final patch adds support for mmio timers.
>>>>
>>>> Patches are based on v3.11-rc1.
>>>
>>> Be aware that as of v3.11-rc2 this doesn't cleanly apply, as the
>>> __cpuinit removal broke the final patch's context in a couple of places.
>>> It would be nice to get rid of the new cpuinit additions too...
>>>
>>> With that cleaned up locally, I've gave this a spin on tc2 and a
>>> Foundation model to test the cp15/system timers, hotplugging CPUs and
>>> running a basic test (`time sleep 5`). That all seems to work.
>>>
>>> Unfortunately I have no way of testing the memory-mapped timer support,
>>> but I trust you've tested that locally.
>>>
>>> For the series:
>>>
>>> Acked-by: Mark Rutland <mark.rutland@arm.com>
>>>
>>
>> Thanks Mark.
>>
>> Daniel, can you pick up these patches please?
>>
> 
> Ping Daniel?

Yes, thanks for the head up.

I will look at them and pick the patches.

  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH v4 0/5] Memory mapped architected timers

[Daniel Lezcano]

On 08/01/2013 12:38 AM, Stephen Boyd wrote:
> On 07/24, Stephen Boyd wrote:
>> On 07/22, Mark Rutland wrote:
>>> Hi Stephen,
>>>
>>> On Fri, Jul 19, 2013 at 12:59:27AM +0100, Stephen Boyd wrote:
>>>> This patchset adds support for memory mapped architected timers. We
>>>> don't have any other global broadcast timer in our system, so we use the
>>>> mmio timer during low power modes. The first patch changes the register
>>>> accessor to an enum per Thomas' request. The second patch is the binding.
>>>> The next two patches lay some groundwork so that the last patch is simpler.
>>>> The final patch adds support for mmio timers.
>>>>
>>>> Patches are based on v3.11-rc1.
>>>
>>> Be aware that as of v3.11-rc2 this doesn't cleanly apply, as the
>>> __cpuinit removal broke the final patch's context in a couple of places.
>>> It would be nice to get rid of the new cpuinit additions too...
>>>
>>> With that cleaned up locally, I've gave this a spin on tc2 and a
>>> Foundation model to test the cp15/system timers, hotplugging CPUs and
>>> running a basic test (`time sleep 5`). That all seems to work.
>>>
>>> Unfortunately I have no way of testing the memory-mapped timer support,
>>> but I trust you've tested that locally.
>>>
>>> For the series:
>>>
>>> Acked-by: Mark Rutland <mark.rutland@arm.com>
>>>
>>
>> Thanks Mark.
>>
>> Daniel, can you pick up these patches please?
>>
> 
> Ping Daniel?

Applied to my tree as 3.12 material

Thanks
  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog