ARM: bcm281xx: Add timer driver

This adds support for the Broadcom timer, used in the following SoCs:
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155

This patch needs the arm-soc/soc/next branch

Updates from V2:
- prepend static fns + fields with kona_

Updates from V1:
- Rename bcm_timer.c to bcm_kona_timer.c
- Pull .h into bcm_kona_timer.c
- Make timers static
- Clean up comment block
- Switched to using clockevents_config_and_register
- Added an error to the get_timer loop if it repeats too much
- Added to Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt
- Added missing readl to timer_disable_and_clear

Note: bcm,kona-timer was kept as the 'compatible' field to make it specific enough for when there are multiple bcm timers (bcm,timer is too generic).

new file mode 100644
index 0000000..59fa6e6
@@ -0,0 +1,19 @@
+Broadcom Kona Family timer
+-----------------------------------------------------
+This timer is used in the following Broadcom SoCs:
+ BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
+
+Required properties:
+- compatible : "bcm,kona-timer"
+- reg : Register range for the timer
+- interrupts : interrupt for the timer
+- clock-frequency: frequency that the clock operates
+
+Example:
+	timer at 35006000 {
+		compatible = "bcm,kona-timer";
+		reg = <0x35006000 0x1000>;
+		interrupts = <0x0 7 0x4>;
+		clock-frequency = <32768>;
+	};
+

index ad13588..8f71f40 100644
@@ -47,4 +47,12 @@
 		    cache-unified;
 		    cache-level = <2>;
 	};
+
+	timer at 35006000 {
+		compatible = "bcm,kona-timer";
+		reg = <0x35006000 0x1000>;
+		interrupts = <0x0 7 0x4>;
+		clock-frequency = <32768>;
+	};
+
 };

index 3a62f1b..7929857 100644
@@ -27,12 +27,10 @@ static const struct of_device_id irq_match[] = {
 	{}
 };
 
-static void timer_init(void)
-{
-}
+extern void kona_timer_init(void);
 
 static struct sys_timer timer = {
-	.init = timer_init,
+	.init = kona_timer_init,
 };
 
 static void __init init_irq(void)

index 603be36..885afc5 100644
@@ -14,5 +14,6 @@ obj-$(CONFIG_DW_APB_TIMER_OF)	+= dw_apb_timer_of.o
 obj-$(CONFIG_CLKSRC_DBX500_PRCMU)	+= clksrc-dbx500-prcmu.o
 obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
 obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
+obj-$(CONFIG_ARCH_BCM)		+= bcm_kona_timer.o
 
 obj-$(CONFIG_CLKSRC_ARM_GENERIC)	+= arm_generic.o

1.7.1

Only if it goes into 3.8, which I assume it won't?

For 3.9, you'll need to rebase it on top of my struct sys_timer removal series, which I hope to put into linux-next ASAP after 3.8-rc1 comes out.

Thanks.

Ok, I wasn't clear on that. I meant that this patch only applies on top of arm-soc/soc/next as it needs the mach-bcm patch which is sitting only there at the moment. I'm fine with having this in 3.8 as this patch only affects the above SoCs. But I'll leave that to Olof and Arnd.

Is there a git repo where I can look into this right now ? If so I can already look at what diffs will be required for this.

Thanks,
csd

Let's aim for 3.9 at this time. Once we've merged all our stuff for 3.8, if there is time left, I might revisit this but by default 3.9 is the appropriate target right now.

-Olof

Sure, it's at:

git://nv-tegra.nvidia.com/user/swarren/linux-2.6 arm_timer_rework

Note that branch gets rebased, as I move it forward on to newer linux next periodically. Once 3.8-rc1 comes out and I have a final stable version, I'll arrange to get it into arm-soc, so it can be used as a base for other people's patches.

Olof, Arnd, that brings me to the question of:

Should I:

a) Add that branch into linux-next (e.g. via the Tegra tree's for-next) right after v3.8-rc1, let is sit there for a week or two (to allow rebasing to squash in any fixes that show up as being needed), and then send a pull request to arm-soc as a stable branch,

or:

b) Send a pull request to arm-soc right after 3.8-rc1, and let you do any rebasing/squashing needed, before declaring it stable say around 3.8-rc2 or 3.8-rc3?

I think either way works fine. The first one is less work for us though ;-)

Arnd

Ah, looks like I hit "reply" instead of "reply all" earlier when I said:

We can pull it in as a non-stable branch that we can rebase if you send us replacement branches, and then move it to a "stable" version around rc2/3. I think that's probably easier than doing it all the way "up" through linux-next for other subarch maintainers.

So, yeah, whatever will be easier for everyone.

-Olof