ARM: OMAP3+: Add device-tree support for timers

Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.

Add documentation for timer properties specific to OMAP.

For each timer an alias is being added. The purpose for doing this is because the OMAP dmtimer driver uses an ID to distinguish between the different timer instances. For example, a timer can be requested by its ID. By adding an alias for each timer we can then use the function of_alias_get_id() to extract the ID for each timer from the alias name. The same method is used for the TTY serial devices. If it is preferred that such an alias is not added and there is a better way to pass an ID from device-tree let me know.

Cc Benoit Cousson <[email protected]>

Signed-off-by Jon Hunter <[email protected]>

---
 .../devicetree/bindings/arm/omap/timer.txt         |   34 +++++++
 arch/arm/boot/dts/omap3.dtsi                       |  104 ++++++++++++++++++++
 arch/arm/boot/dts/omap4.dtsi                       |   93 +++++++++++++++++
 3 files changed, 231 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt

Documentation/devicetree/bindings/arm/omap/timer.txt new file +34 -0

new file mode 100644
index 0000000..dcbb451
@@ -0,0 +1,34 @@
+OMAP Timer controller bindings
+
+Required properties:
+- compatible:
+  - "ti,omap3-timer" for OMAP3+ controllers
+- reg: Contains timer register address range (base address and length)
+- interrupts: Contains the interrupt information for the timer. The format is
+  being dependent on which interrupt controller the OMAP device uses.
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the timer:
+  "timer<X>", <X> being the 1-based instance number from the HW spec
+- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
+- ti,timer-pwm: Indicates the timer supports can generate PWM output.
+- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device and
+  therefore cannot be used by the kernel.
+
+Note: Each timer should have an alias correctly numbered in "aliases" node. The
+      alias is used to identify the timer instance in the driver.
+
+Example:
+
+aliases {
+	timer12 = &timer12;
+};
+
+timer12: timer at 48304000 {
+	compatible = "ti,omap3-timer";
+	reg = <0x48304000 0xfff>;
+	interrupts = <95>;
+	ti,hwmods = "timer12"
+	ti,timer-alwon;
+	ti,timer-secure;
+};

arch/arm/boot/dts/omap3.dtsi +104 -0

index 8109471..f309f2a 100644
@@ -12,12 +12,25 @@
 
 / {
 	compatible = "ti,omap3430", "ti,omap3";
+	interrupt-parent = <&intc>;
 
 	aliases {
 		serial0 = &uart1;
 		serial1 = &uart2;
 		serial2 = &uart3;
 		serial3 = &uart4;
+		timer1 = &timer1;
+		timer2 = &timer2;
+		timer3 = &timer3;
+		timer4 = &timer4;
+		timer5 = &timer5;
+		timer6 = &timer6;
+		timer7 = &timer7;
+		timer8 = &timer8;
+		timer9 = &timer9;
+		timer10 = &timer10;
+		timer11 = &timer11;
+		timer12 = &timer12;
 	};
 
 	cpus {

@@ -220,5 +233,96 @@
 			compatible = "ti,omap3-wdt";
 			ti,hwmods = "wd_timer2";
 		};
+
+		timer1: timer at 48318000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48318000 0xfff>;
+			interrupts = <37>;
+			ti,hwmods = "timer1";
+			ti,timer-alwon;
+		};
+
+		timer2: timer at 49032000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x49032000 0xfff>;
+			interrupts = <38>;
+			ti,hwmods = "timer2";
+		};
+
+		timer3: timer at 49034000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x49034000 0xfff>;
+			interrupts = <39>;
+			ti,hwmods = "timer3";
+		};
+
+		timer4: timer at 49036000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x49036000 0xfff>;
+			interrupts = <40>;
+			ti,hwmods = "timer4";
+		};
+
+		timer5: timer at 49038000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x49038000 0xfff>;
+			interrupts = <41>;
+			ti,hwmods = "timer5";
+		};
+
+		timer6: timer at 4903a000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x4903a000 0xfff>;
+			interrupts = <42>;
+			ti,hwmods = "timer6";
+		};
+
+		timer7: timer at 4903c000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x4903c000 0xfff>;
+			interrupts = <43>;
+			ti,hwmods = "timer7";
+		};
+
+		timer8: timer at 4903e000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x4903e000 0xfff>;
+			interrupts = <44>;
+			ti,hwmods = "timer8";
+			ti,timer-pwm;
+		};
+
+		timer9: timer at 49040000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x49040000 0xfff>;
+			interrupts = <45>;
+			ti,hwmods = "timer9";
+			ti,timer-pwm;
+		};
+
+		timer10: timer at 48086000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48086000 0xfff>;
+			interrupts = <46>;
+			ti,hwmods = "timer10";
+			ti,timer-pwm;
+		};
+
+		timer11: timer at 48088000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48088000 0xfff>;
+			interrupts = <47>;
+			ti,hwmods = "timer11";
+			ti,timer-pwm;
+		};
+
+		timer12: timer at 48304000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48304000 0xfff>;
+			interrupts = <95>;
+			ti,hwmods = "timer12";
+			ti,timer-alwon;
+			ti,timer-secure;
+		};
 	};
 };

arch/arm/boot/dts/omap4.dtsi +93 -0

index 04cbbcb..39716c5 100644
@@ -25,6 +25,17 @@
 		serial1 = &uart2;
 		serial2 = &uart3;
 		serial3 = &uart4;
+		timer1 = &timer1;
+		timer2 = &timer2;
+		timer3 = &timer3;
+		timer4 = &timer4;
+		timer5 = &timer5;
+		timer6 = &timer6;
+		timer7 = &timer7;
+		timer8 = &timer8;
+		timer9 = &timer9;
+		timer10 = &timer10;
+		timer11 = &timer11;
 	};
 
 	cpus {

@@ -295,5 +306,87 @@
 			interrupt-parent = <&gic>;
 			ti,hwmods = "dmic";
 		};
+
+		timer1: timer at 4a318000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x4a318000 0x7f>;
+			interrupts = <0 37 0x4>;
+			ti,hwmods = "timer1";
+			ti,timer-alwon;
+		};
+
+		timer2: timer at 48032000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48032000 0x7f>;
+			interrupts = <0 38 0x4>;
+			ti,hwmods = "timer2";
+		};
+
+		timer3: timer at 48034000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48034000 0x7f>;
+			interrupts = <0 39 0x4>;
+			ti,hwmods = "timer3";
+		};
+
+		timer4: timer at 48036000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48036000 0x7f>;
+			interrupts = <0 40 0x4>;
+			ti,hwmods = "timer4";
+		};
+
+		timer5: timer at 49038000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x49038000 0x7f>;
+			interrupts = <0 41 0x4>;
+			ti,hwmods = "timer5";
+		};
+
+		timer6: timer at 4903a000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x4903a000 0x7f>;
+			interrupts = <0 42 0x4>;
+			ti,hwmods = "timer6";
+		};
+
+		timer7: timer at 4903c000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x4903c000 0x7f>;
+			interrupts = <0 43 0x4>;
+			ti,hwmods = "timer7";
+		};
+
+		timer8: timer at 4903e000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x4903e000 0x7f>;
+			interrupts = <0 44 0x4>;
+			ti,hwmods = "timer8";
+			ti,timer-pwm;
+		};
+
+		timer9: timer at 4803e000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x4803e000 0x7f>;
+			interrupts = <0 45 0x4>;
+			ti,hwmods = "timer9";
+			ti,timer-pwm;
+		};
+
+		timer10: timer at 48086000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48086000 0x7f>;
+			interrupts = <0 46 0x4>;
+			ti,hwmods = "timer10";
+			ti,timer-pwm;
+		};
+
+		timer11: timer at 48088000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48088000 0x7f>;
+			interrupts = <0 47 0x4>;
+			ti,hwmods = "timer11";
+			ti,timer-pwm;
+		};
 	};
 };

I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed.

Quoted 3 lines

I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed.

This brings up an issue that I've been meaning to comment on.

The use of phandle-valued properties in the aliases node causes real OFW implementations some amount of heartburn. The Open Firmware standard says that the properties in /aliases are string-valued. That's important, because aliases are shorthand for fragments of full device specifiers (pathnames that can include arguments to nodes). Phandles can point to nodes, but can't be relative, and can't encode per-node-component arguments.

For binding a Linux unit number to a device node, I would prefer to decorate the node with a property like "linux,unit#", instead of breaking the standard semantics of /aliases.

Quoted 6 lines · Mitch Bradley

Quoted 3 lines

I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed.

This brings up an issue that I've been meaning to comment on.

Quoted 7 lines

The use of phandle-valued properties in the aliases node causes real OFW implementations some amount of heartburn. The Open Firmware standard says that the properties in /aliases are string-valued. That's important, because aliases are shorthand for fragments of full device specifiers (pathnames that can include arguments to nodes). Phandles can point to nodes, but can't be relative, and can't encode per-node-component arguments.

Um, so, properties in /aliases should not have phandle values, flat tree or otherwise. Has this been seen in the wild, or are you being misled by the fact that dtc's reference-to-phandle and reference-to-path syntax is very similar:

	prop = <&fred>;
Will generate a phandle valued property, but
	prop = &fred;

Will generate a string (path) valued property.

Quoted 3 lines

For binding a Linux unit number to a device node, I would prefer to decorate the node with a property like "linux,unit#", instead of breaking the standard semantics of /aliases.

I don't see how using aliases for unit numbering (inherently) breaks the semantics of /aliases. If phandle valued properties are being used that is wrong, but it's not necessary for the unit numbering anyway.

Quoted 15 lines · David Gibson

Quoted 13 lines · Mitch Bradley

Quoted 3 lines

I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed.

This brings up an issue that I've been meaning to comment on.

The use of phandle-valued properties in the aliases node causes real OFW implementations some amount of heartburn. The Open Firmware standard says that the properties in /aliases are string-valued. That's important, because aliases are shorthand for fragments of full device specifiers (pathnames that can include arguments to nodes). Phandles can point to nodes, but can't be relative, and can't encode per-node-component arguments.

Quoted 4 lines

Um, so, properties in /aliases should not have phandle values, flat tree or otherwise. Has this been seen in the wild, or are you being misled by the fact that dtc's reference-to-phandle and reference-to-path syntax is very similar:

Yes, I was indeed being misled. Thanks for the clarification. The "&fred" syntax is present in the .dts files that I have looked at.

Quoted 5 lines

	prop = <&fred>;
Will generate a phandle valued property, but
	prop = &fred;

Will generate a string (path) valued property.

Quoted 8 lines

Quoted 3 lines

For binding a Linux unit number to a device node, I would prefer to decorate the node with a property like "linux,unit#", instead of breaking the standard semantics of /aliases.

I don't see how using aliases for unit numbering (inherently) breaks the semantics of /aliases. If phandle valued properties are being used that is wrong, but it's not necessary for the unit numbering anyway.

I agree, the use of string-valued /aliases is not a semantic problem. That said, I still think that decorating individual nodes is a better approach, for locality reasons. But, now that my misunderstanding has been cleared up, it's a mild preference instead of "heartburn".

I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed. IIUC, as an example you are picking timer1 because it has properties X, Y and Z. If so, then you should describe those h/w properties within the timer nodes so you can pick which timer to use based on it's h/w properties.

Hi

Quoted 6 lines · Rob Herring

I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed. IIUC, as an example you are picking timer1 because it has properties X, Y and Z. If so, then you should describe those h/w properties within the timer nodes so you can pick which timer to use based on it's h/w properties.

Some GPTIMER blocks have input and output signals that can be routed to external package balls. So it's possible that some application may need to request a specific timer ID, since that timer would be connected to a specific off-chip device.

- Paul

Quoted 9 lines · Paul Walmsley

Quoted 6 lines · Rob Herring

I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed. IIUC, as an example you are picking timer1 because it has properties X, Y and Z. If so, then you should describe those h/w properties within the timer nodes so you can pick which timer to use based on it's h/w properties.

Quoted 4 lines

Some GPTIMER blocks have input and output signals that can be routed to external package balls. So it's possible that some application may need to request a specific timer ID, since that timer would be connected to a specific off-chip device.

Yes, I understand that. So you

should be describing which ones have i/o and what they are connected to.

The PWM binding is probably a starting point.

My point, perhaps unclear, was about the aliases. Do you have a different approach in mind that applications should use, other than requesting a specific timer by ID?

Quoted 5 lines · Jon Hunter

Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.

Add documentation for timer properties specific to OMAP.

Quoted 7 lines

For each timer an alias is being added. The purpose for doing this is because the OMAP dmtimer driver uses an ID to distinguish between the different timer instances. For example, a timer can be requested by its ID. By adding an alias for each timer we can then use the function of_alias_get_id() to extract the ID for each timer from the alias name. The same method is used for the TTY serial devices. If it is preferred that such an alias is not added and there is a better way to pass an ID from device-tree let me know.

I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed. IIUC, as an example you are picking timer1 because it has properties X, Y and Z. If so, then you should describe those h/w properties within the timer nodes so you can pick which timer to use based on it's h/w properties.

On 07/13/2012 09:15 PM, Rob Herring wrote:

Tony, Tarun,

How would you feel on replacing omap_dmtimer_request_specific(int id) with say omap_dm_timer_request_by_cap(int cap)?

I was thinking of changing the name so that it is clear that the API has changed. The "int cap" passed to the above function would be an OR of the appropriate the capabilities flags we have in dmtimer.h ...

/* timer capabilities used in hwmod database */

#define OMAP_TIMER_SECURE                               0x80000000
#define OMAP_TIMER_ALWON                                0x40000000
#define OMAP_TIMER_HAS_PWM                              0x20000000

...

Quoted 11 lines · Jon Hunter

On 07/13/2012 09:15 PM, Rob Herring wrote:

Tony, Tarun,

How would you feel on replacing omap_dmtimer_request_specific(int id) with say omap_dm_timer_request_by_cap(int cap)?

I was thinking of changing the name so that it is clear that the API has changed. The "int cap" passed to the above function would be an OR of the appropriate the capabilities flags we have in dmtimer.h ...

Quoted 5 lines

/* timer capabilities used in hwmod database */

#define OMAP_TIMER_SECURE                               0x80000000
#define OMAP_TIMER_ALWON                                0x40000000
#define OMAP_TIMER_HAS_PWM                              0x20000000

...

That may break coprocessors where the firmware may expect a hardcoded specific timer.. So at least that should be checked before the change. If the specific timer is still needed for some firmware, it's best to add a separate function for the capabilities.

Also, I believe it's up to the firmware running in secure mode to select the secure timers. So unless there's some way to query which timers are claimed by the secure mode, that too needs to be passed via DT.

Hi Rob,

Quoted 14 lines · Rob Herring

Quoted 5 lines · Jon Hunter

Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.

Add documentation for timer properties specific to OMAP.

Quoted 7 lines

For each timer an alias is being added. The purpose for doing this is because the OMAP dmtimer driver uses an ID to distinguish between the different timer instances. For example, a timer can be requested by its ID. By adding an alias for each timer we can then use the function of_alias_get_id() to extract the ID for each timer from the alias name. The same method is used for the TTY serial devices. If it is preferred that such an alias is not added and there is a better way to pass an ID from device-tree let me know.

Quoted 6 lines

I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed. IIUC, as an example you are picking timer1 because it has properties X, Y and Z. If so, then you should describe those h/w properties within the timer nodes so you can pick which timer to use based on it's h/w properties.

Thanks for the feedback. What you suggest could definitely work for most timers. The only item that I would need to resolve here is the handling of system timers (ie. those used for clockevents and clocksource). These system timers (for OMAP) are reserved during early boot based upon the timer ID today and so this is before the actual main timer driver has been probed and all the attributes of the timers has been read for device-tree.

One thought would be to move the reservation of the system timers out of the kernel and into device-tree itself. Then we query device tree on start-up to see which we should use. I am wondering if this could be a better use of alias? For example, say I want to use timer1 as my clockevent timer and so I could have an alias of ...

alias {
	clockevent_timer = &timer1;
}

However, I am not sure if this is even correct, because there does not appear to be an API to search the aliases by name and return the phandle, just of_alias_get_id(). Alternatively, I could add another property called "ti,timer-clockevent" that is populated for the timer used as the clockevent timer.

Hi Rob,

Quoted 42 lines · Jon Hunter

Hi Rob,

Quoted 14 lines · Rob Herring

Quoted 5 lines · Jon Hunter

Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.

Add documentation for timer properties specific to OMAP.

Quoted 7 lines

For each timer an alias is being added. The purpose for doing this is because the OMAP dmtimer driver uses an ID to distinguish between the different timer instances. For example, a timer can be requested by its ID. By adding an alias for each timer we can then use the function of_alias_get_id() to extract the ID for each timer from the alias name. The same method is used for the TTY serial devices. If it is preferred that such an alias is not added and there is a better way to pass an ID from device-tree let me know.

Quoted 6 lines

I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed. IIUC, as an example you are picking timer1 because it has properties X, Y and Z. If so, then you should describe those h/w properties within the timer nodes so you can pick which timer to use based on it's h/w properties.

Thanks for the feedback. What you suggest could definitely work for most timers. The only item that I would need to resolve here is the handling of system timers (ie. those used for clockevents and clocksource). These system timers (for OMAP) are reserved during early boot based upon the timer ID today and so this is before the actual main timer driver has been probed and all the attributes of the timers has been read for device-tree.

One thought would be to move the reservation of the system timers out of the kernel and into device-tree itself. Then we query device tree on start-up to see which we should use. I am wondering if this could be a better use of alias? For example, say I want to use timer1 as my clockevent timer and so I could have an alias of ...

alias {
	clockevent_timer = &timer1;
}

Quoted 5 lines

However, I am not sure if this is even correct, because there does not appear to be an API to search the aliases by name and return the phandle, just of_alias_get_id(). Alternatively, I could add another property called "ti,timer-clockevent" that is populated for the timer used as the clockevent timer.

Do you have any inputs on the above? Does it make sense to reserve timer resources for kernel system timers in device-tree?

Cheers
Jon
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss at lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Quoted 45 lines · Jon Hunter

Hi Rob,

Quoted 42 lines · Jon Hunter

Hi Rob,

Quoted 14 lines · Rob Herring

Quoted 5 lines · Jon Hunter

Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.

Add documentation for timer properties specific to OMAP.

Quoted 7 lines

For each timer an alias is being added. The purpose for doing this is because the OMAP dmtimer driver uses an ID to distinguish between the different timer instances. For example, a timer can be requested by its ID. By adding an alias for each timer we can then use the function of_alias_get_id() to extract the ID for each timer from the alias name. The same method is used for the TTY serial devices. If it is preferred that such an alias is not added and there is a better way to pass an ID from device-tree let me know.

Quoted 6 lines

I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed. IIUC, as an example you are picking timer1 because it has properties X, Y and Z. If so, then you should describe those h/w properties within the timer nodes so you can pick which timer to use based on it's h/w properties.

Thanks for the feedback. What you suggest could definitely work for most timers. The only item that I would need to resolve here is the handling of system timers (ie. those used for clockevents and clocksource). These system timers (for OMAP) are reserved during early boot based upon the timer ID today and so this is before the actual main timer driver has been probed and all the attributes of the timers has been read for device-tree.

One thought would be to move the reservation of the system timers out of the kernel and into device-tree itself. Then we query device tree on start-up to see which we should use. I am wondering if this could be a better use of alias? For example, say I want to use timer1 as my clockevent timer and so I could have an alias of ...

alias {
	clockevent_timer = &timer1;
}

Quoted 9 lines

Quoted 5 lines

However, I am not sure if this is even correct, because there does not appear to be an API to search the aliases by name and return the phandle, just of_alias_get_id(). Alternatively, I could add another property called "ti,timer-clockevent" that is populated for the timer used as the clockevent timer.

Do you have any inputs on the above? Does it make sense to reserve timer resources for kernel system timers in device-tree?

Hey Jon,

Did we get conclude on this? I haven't got anything further on this thread, this may block baseport support for the new devices in omap2 family, like AM33xx and OMAP5.

Quoted 4 lines · Vaibhav Hiremath

Did we get conclude on this? I haven't got anything further on this thread, this may block baseport support for the new devices in omap2 family, like AM33xx and OMAP5.

Sorry I have been out of the office. However, no update on this so far. I need to check with Tony if he has any preference for handling this. I will follow-up with him and keep you posted.

Quoted 6 lines · Jon Hunter

Quoted 4 lines · Vaibhav Hiremath

Did we get conclude on this? I haven't got anything further on this thread, this may block baseport support for the new devices in omap2 family, like AM33xx and OMAP5.

Quoted 3 lines

Sorry I have been out of the office. However, no update on this so far. I need to check with Tony if he has any preference for handling this. I will follow-up with him and keep you posted.

Jon please repost these without the RFC in the subject line assuming the pending comments have been addressed so people can ack them.

Hi Tony,

Quoted 7 lines · Tony Lindgren

Quoted 6 lines · Jon Hunter

Quoted 4 lines · Vaibhav Hiremath

Did we get conclude on this? I haven't got anything further on this thread, this may block baseport support for the new devices in omap2 family, like AM33xx and OMAP5.

Quoted 7 lines

Quoted 3 lines

Sorry I have been out of the office. However, no update on this so far. I need to check with Tony if he has any preference for handling this. I will follow-up with him and keep you posted.

Jon please repost these without the RFC in the subject line assuming the pending comments have been addressed so people can ack them.

I have been working on updating this series to request timer by their capabilities and avoid using a device ID altogether. In the updated series using device IDs to request a timer will still work as it does today, but not when you boot with DT. I have something working now that is booting fine on omap4 with and without DT [1]. However, I need to do more thorough testing of the timers in general, probably next week.

Once I have completed my testing I would like to post for review. However, since posting the original series I have been working on some needed timer fixes/clean-up which I posted this week [2] for review. Ideally I should rebase my DT timer work on my timer fixes series but wanted to see what you thought first.

Cheers
Jon

[1] https://github.com/jonhunter/linux/tree/dev-dt-timer
[2] http://marc.info/?l=linux-omap&m=134687188921835&w=2

Quoted 25 lines · Jon Hunter

Hi Tony,

Quoted 7 lines · Tony Lindgren

Quoted 6 lines · Jon Hunter

Quoted 4 lines · Vaibhav Hiremath

Did we get conclude on this? I haven't got anything further on this thread, this may block baseport support for the new devices in omap2 family, like AM33xx and OMAP5.

Quoted 7 lines

Quoted 3 lines

Sorry I have been out of the office. However, no update on this so far. I need to check with Tony if he has any preference for handling this. I will follow-up with him and keep you posted.

Jon please repost these without the RFC in the subject line assuming the pending comments have been addressed so people can ack them.

I have been working on updating this series to request timer by their capabilities and avoid using a device ID altogether. In the updated series using device IDs to request a timer will still work as it does today, but not when you boot with DT. I have something working now that is booting fine on omap4 with and without DT [1]. However, I need to do more thorough testing of the timers in general, probably next week.

Quoted 5 lines

Once I have completed my testing I would like to post for review. However, since posting the original series I have been working on some needed timer fixes/clean-up which I posted this week [2] for review. Ideally I should rebase my DT timer work on my timer fixes series but wanted to see what you thought first.

Yeah those all look good to me. Want to do a git branch against v3.6-rc4 for those once the comments are dealt with so I can pull it in for testing to start with?

Hi Rob,

Quoted 42 lines · Jon Hunter

Hi Rob,

Quoted 14 lines · Rob Herring

Quoted 5 lines · Jon Hunter

Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.

Add documentation for timer properties specific to OMAP.

Quoted 7 lines

For each timer an alias is being added. The purpose for doing this is because the OMAP dmtimer driver uses an ID to distinguish between the different timer instances. For example, a timer can be requested by its ID. By adding an alias for each timer we can then use the function of_alias_get_id() to extract the ID for each timer from the alias name. The same method is used for the TTY serial devices. If it is preferred that such an alias is not added and there is a better way to pass an ID from device-tree let me know.

Quoted 6 lines

I'm not sure this is really a good use of aliases. UARTs use aliases because it is important that the UART number to tty number is known and fixed. IIUC, as an example you are picking timer1 because it has properties X, Y and Z. If so, then you should describe those h/w properties within the timer nodes so you can pick which timer to use based on it's h/w properties.

Thanks for the feedback. What you suggest could definitely work for most timers. The only item that I would need to resolve here is the handling of system timers (ie. those used for clockevents and clocksource). These system timers (for OMAP) are reserved during early boot based upon the timer ID today and so this is before the actual main timer driver has been probed and all the attributes of the timers has been read for device-tree.

One thought would be to move the reservation of the system timers out of the kernel and into device-tree itself. Then we query device tree on start-up to see which we should use. I am wondering if this could be a better use of alias? For example, say I want to use timer1 as my clockevent timer and so I could have an alias of ...

alias {
	clockevent_timer = &timer1;
}

Quoted 5 lines

However, I am not sure if this is even correct, because there does not appear to be an API to search the aliases by name and return the phandle, just of_alias_get_id(). Alternatively, I could add another property called "ti,timer-clockevent" that is populated for the timer used as the clockevent timer.

Do you have any inputs on the above? Does it make sense to reserve timer resources for kernel system timers in device-tree?

On 07/23/2012 10:24 AM, Jon Hunter wrote:

Quoted 2 lines

Do you have any inputs on the above? Does it make sense to reserve timer resources for kernel system timers in device-tree?

This issue is not unique to omap. So if we do specify clockevent and clocksource in dts, then it should be in a common way. I think using "linux,clockevent" either as an alias name or property within the timer node would work. I don't have a strong preference, but I tend to lean toward an alias. Primarily this is because we are already using aliases for similar purposes.

However, I still think this could be done by looking at properties. There's not really any reason you can't check properties at timer init stage. The FDT has already been un-flattened. What are the features or lack of features you care about to determine which timer to use?

OMAP3 devices may or may not have security features enabled. Security enabled devices are known as high-secure (HS) and devices without security are known as general purpose (GP).

For OMAP3 devices there are 12 general purpose timers available. On secure devices the 12th timer is reserved for secure usage and so cannot be used by the kernel, where as for a GP device it is available. We can detect the OMAP device type, secure or GP, at runtime via an on-chip register. Today, when not using DT, we do not register the 12th timer as a linux device if the device is secure.

When using device tree, device tree is going to register all the timer devices it finds in the device tree blob. To prevent device tree from registering 12th timer on a secure OMAP3 device we can add a status property to the timer binding with the value "disabled" at boot time. Note that timer 12 on a OMAP3 device has a property "ti,timer-secure" to indicate that it will not be available on a secure device and so for secure OMAP3 devices, we search for timers with this property and then disable them. Using the prom_add_property() function to dynamically add a property was a recommended approach suggested by Rob Herring [1].

I have tested this on an OMAP3 GP device and faking it to pretend to be a secure device to ensure that any timers marked with "ti,timer-secure" are not registered on boot. I have also made sure that all timers are registered as expected on a GP device by default.

[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203

Signed-off-by Jon Hunter <[email protected]>

---
 arch/arm/mach-omap2/board-generic.c |    1 +
 arch/arm/mach-omap2/common.h        |    1 +
 arch/arm/mach-omap2/timer.c         |   36 +++++++++++++++++++++++++++++++++++
 3 files changed, 38 insertions(+)

arch/arm/mach-omap2/board-generic.c +1 -0

index 6f93a20..20124d7 100644
@@ -40,6 +40,7 @@ static struct of_device_id omap_dt_match_table[] __initdata = {
 static void __init omap_generic_init(void)
 {
 	omap_sdrc_init(NULL, NULL);
+	omap_dmtimer_init();
 
 	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
 }

arch/arm/mach-omap2/common.h +1 -0

index 1f65b18..d6a4875 100644
@@ -326,6 +326,7 @@ extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
 				      struct omap_sdrc_params *sdrc_cs1);
 struct omap2_hsmmc_info;
 extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
+extern void omap_dmtimer_init(void);
 
 #endif /* __ASSEMBLER__ */
 #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */

arch/arm/mach-omap2/timer.c +17 -0

index 13d20c8..e3b9931 100644
@@ -36,6 +36,7 @@
 #include <linux/clocksource.h>
 #include <linux/clockchips.h>
 #include <linux/slab.h>
+#include <linux/of.h>
 
 #include <asm/mach/time.h>
 #include <plat/dmtimer.h>

@@ -482,6 +483,41 @@ static int __init omap2_dm_timer_init(void)
 }
 arch_initcall(omap2_dm_timer_init);
 
+static struct property timer_disabled = {
+	.name = "status",
+	.length = sizeof("disabled"),
+	.value = "disabled",
+};
+
+static struct of_device_id omap3_timer_match[] __initdata = {
+	{ .compatible = "ti,omap3-timer", },
+	{ }
+};
+
+/**
+ * omap_dmtimer_init - initialisation function when device tree is used
+ *
+ * For secure OMAP3 devices, timers with device type "timer-secure" cannot
+ * be used by the kernel as they are reserved. Therefore, to prevent the

arch/arm/mach-omap2/timer.c +9 -0

+	/* If we are a secure device, remove any secure timer nodes */
+	if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
+		for_each_matching_node(np, omap3_timer_match) {
+			if (of_get_property(np, "ti,timer-secure", NULL))
+				prom_add_property(np, &timer_disabled);
+		}
+	}
+}
+
 /**
  * omap2_override_clocksource - clocksource override with user configuration
  *

Quoted 96 lines · Jon Hunter

OMAP3 devices may or may not have security features enabled. Security enabled devices are known as high-secure (HS) and devices without security are known as general purpose (GP).

For OMAP3 devices there are 12 general purpose timers available. On secure devices the 12th timer is reserved for secure usage and so cannot be used by the kernel, where as for a GP device it is available. We can detect the OMAP device type, secure or GP, at runtime via an on-chip register. Today, when not using DT, we do not register the 12th timer as a linux device if the device is secure.

When using device tree, device tree is going to register all the timer devices it finds in the device tree blob. To prevent device tree from registering 12th timer on a secure OMAP3 device we can add a status property to the timer binding with the value "disabled" at boot time. Note that timer 12 on a OMAP3 device has a property "ti,timer-secure" to indicate that it will not be available on a secure device and so for secure OMAP3 devices, we search for timers with this property and then disable them. Using the prom_add_property() function to dynamically add a property was a recommended approach suggested by Rob Herring [1].

I have tested this on an OMAP3 GP device and faking it to pretend to be a secure device to ensure that any timers marked with "ti,timer-secure" are not registered on boot. I have also made sure that all timers are registered as expected on a GP device by default.

[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203

Signed-off-by Jon Hunter <[email protected]>

---
 arch/arm/mach-omap2/board-generic.c |    1 +
 arch/arm/mach-omap2/common.h        |    1 +
 arch/arm/mach-omap2/timer.c         |   36 +++++++++++++++++++++++++++++++++++
 3 files changed, 38 insertions(+)

arch/arm/mach-omap2/board-generic.c +1 -0

index 6f93a20..20124d7 100644
@@ -40,6 +40,7 @@ static struct of_device_id omap_dt_match_table[] __initdata = {
 static void __init omap_generic_init(void)
 {
 	omap_sdrc_init(NULL, NULL);
+	omap_dmtimer_init();
 
 	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
 }

arch/arm/mach-omap2/common.h +1 -0

index 1f65b18..d6a4875 100644
@@ -326,6 +326,7 @@ extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
 				      struct omap_sdrc_params *sdrc_cs1);
 struct omap2_hsmmc_info;
 extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
+extern void omap_dmtimer_init(void);
 
 #endif /* __ASSEMBLER__ */
 #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */

arch/arm/mach-omap2/timer.c +22 -0

index 13d20c8..e3b9931 100644
@@ -36,6 +36,7 @@
 #include <linux/clocksource.h>
 #include <linux/clockchips.h>
 #include <linux/slab.h>
+#include <linux/of.h>
 
 #include <asm/mach/time.h>
 #include <plat/dmtimer.h>

@@ -482,6 +483,41 @@ static int __init omap2_dm_timer_init(void)
 }
 arch_initcall(omap2_dm_timer_init);
 
+static struct property timer_disabled = {
+	.name = "status",
+	.length = sizeof("disabled"),
+	.value = "disabled",
+};
+
+static struct of_device_id omap3_timer_match[] __initdata = {
+	{ .compatible = "ti,omap3-timer", },
+	{ }
+};
+
+/**
+ * omap_dmtimer_init - initialisation function when device tree is used
+ *
+ * For secure OMAP3 devices, timers with device type "timer-secure" cannot
+ * be used by the kernel as they are reserved. Therefore, to prevent the
+ * kernel registering these devices remove them dynamically from the device
+ * tree on boot.
+ */
+void __init omap_dmtimer_init(void)
+{

arch/arm/mach-omap2/timer.c static int __init omap2_dm_timer_init(void) · line 511

Quoted 5 lines

arch/arm/mach-omap2/timer.c +5 -0

+	struct device_node *np;
+
+	if (!cpu_is_omap34xx())
+		return;
+

Sorry for responding so late, but why only omap34xx check here? Isn't this applicable to all omap & non-omap devices?

Quoted 99 lines · Vaibhav Hiremath

Quoted 96 lines · Jon Hunter

OMAP3 devices may or may not have security features enabled. Security enabled devices are known as high-secure (HS) and devices without security are known as general purpose (GP).

For OMAP3 devices there are 12 general purpose timers available. On secure devices the 12th timer is reserved for secure usage and so cannot be used by the kernel, where as for a GP device it is available. We can detect the OMAP device type, secure or GP, at runtime via an on-chip register. Today, when not using DT, we do not register the 12th timer as a linux device if the device is secure.

When using device tree, device tree is going to register all the timer devices it finds in the device tree blob. To prevent device tree from registering 12th timer on a secure OMAP3 device we can add a status property to the timer binding with the value "disabled" at boot time. Note that timer 12 on a OMAP3 device has a property "ti,timer-secure" to indicate that it will not be available on a secure device and so for secure OMAP3 devices, we search for timers with this property and then disable them. Using the prom_add_property() function to dynamically add a property was a recommended approach suggested by Rob Herring [1].

I have tested this on an OMAP3 GP device and faking it to pretend to be a secure device to ensure that any timers marked with "ti,timer-secure" are not registered on boot. I have also made sure that all timers are registered as expected on a GP device by default.

[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203

Signed-off-by Jon Hunter <[email protected]>

---
 arch/arm/mach-omap2/board-generic.c |    1 +
 arch/arm/mach-omap2/common.h        |    1 +
 arch/arm/mach-omap2/timer.c         |   36 +++++++++++++++++++++++++++++++++++
 3 files changed, 38 insertions(+)

arch/arm/mach-omap2/board-generic.c +1 -0

index 6f93a20..20124d7 100644
@@ -40,6 +40,7 @@ static struct of_device_id omap_dt_match_table[] __initdata = {
 static void __init omap_generic_init(void)
 {
 	omap_sdrc_init(NULL, NULL);
+	omap_dmtimer_init();
 
 	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
 }

arch/arm/mach-omap2/common.h +1 -0

index 1f65b18..d6a4875 100644
@@ -326,6 +326,7 @@ extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
 				      struct omap_sdrc_params *sdrc_cs1);
 struct omap2_hsmmc_info;
 extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
+extern void omap_dmtimer_init(void);
 
 #endif /* __ASSEMBLER__ */
 #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */

arch/arm/mach-omap2/timer.c +22 -0

index 13d20c8..e3b9931 100644
@@ -36,6 +36,7 @@
 #include <linux/clocksource.h>
 #include <linux/clockchips.h>
 #include <linux/slab.h>
+#include <linux/of.h>
 
 #include <asm/mach/time.h>
 #include <plat/dmtimer.h>

@@ -482,6 +483,41 @@ static int __init omap2_dm_timer_init(void)
 }
 arch_initcall(omap2_dm_timer_init);
 
+static struct property timer_disabled = {
+	.name = "status",
+	.length = sizeof("disabled"),
+	.value = "disabled",
+};
+
+static struct of_device_id omap3_timer_match[] __initdata = {
+	{ .compatible = "ti,omap3-timer", },
+	{ }
+};
+
+/**
+ * omap_dmtimer_init - initialisation function when device tree is used
+ *
+ * For secure OMAP3 devices, timers with device type "timer-secure" cannot
+ * be used by the kernel as they are reserved. Therefore, to prevent the
+ * kernel registering these devices remove them dynamically from the device
+ * tree on boot.
+ */
+void __init omap_dmtimer_init(void)
+{

Quoted 8 lines

arch/arm/mach-omap2/timer.c static int __init omap2_dm_timer_init(void) · line 511

Quoted 5 lines

arch/arm/mach-omap2/timer.c +5 -0

+	struct device_node *np;
+
+	if (!cpu_is_omap34xx())
+		return;
+

Sorry for responding so late, but why only omap34xx check here? Isn't this applicable to all omap & non-omap devices?

It is only applicable to omap3 devices as far as omap is concerned.

By non-omap, you are referring to the AMxxx stuff?

Do AMxxx devices even support security (ie. secure boot and have secure peripherals)? If not then this will work for AMxxx devices too.

Let me know if the changelog is not clear why this is needed for an omap3 device.

Quoted 114 lines · Jon

Quoted 99 lines · Vaibhav Hiremath

Quoted 96 lines · Jon Hunter

OMAP3 devices may or may not have security features enabled. Security enabled devices are known as high-secure (HS) and devices without security are known as general purpose (GP).

For OMAP3 devices there are 12 general purpose timers available. On secure devices the 12th timer is reserved for secure usage and so cannot be used by the kernel, where as for a GP device it is available. We can detect the OMAP device type, secure or GP, at runtime via an on-chip register. Today, when not using DT, we do not register the 12th timer as a linux device if the device is secure.

When using device tree, device tree is going to register all the timer devices it finds in the device tree blob. To prevent device tree from registering 12th timer on a secure OMAP3 device we can add a status property to the timer binding with the value "disabled" at boot time. Note that timer 12 on a OMAP3 device has a property "ti,timer-secure" to indicate that it will not be available on a secure device and so for secure OMAP3 devices, we search for timers with this property and then disable them. Using the prom_add_property() function to dynamically add a property was a recommended approach suggested by Rob Herring [1].

I have tested this on an OMAP3 GP device and faking it to pretend to be a secure device to ensure that any timers marked with "ti,timer-secure" are not registered on boot. I have also made sure that all timers are registered as expected on a GP device by default.

[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203

Signed-off-by Jon Hunter <[email protected]>

---
 arch/arm/mach-omap2/board-generic.c |    1 +
 arch/arm/mach-omap2/common.h        |    1 +
 arch/arm/mach-omap2/timer.c         |   36 +++++++++++++++++++++++++++++++++++
 3 files changed, 38 insertions(+)

arch/arm/mach-omap2/board-generic.c +1 -0

index 6f93a20..20124d7 100644
@@ -40,6 +40,7 @@ static struct of_device_id omap_dt_match_table[] __initdata = {
 static void __init omap_generic_init(void)
 {
 	omap_sdrc_init(NULL, NULL);
+	omap_dmtimer_init();
 
 	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
 }

arch/arm/mach-omap2/common.h +1 -0

index 1f65b18..d6a4875 100644
@@ -326,6 +326,7 @@ extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
 				      struct omap_sdrc_params *sdrc_cs1);
 struct omap2_hsmmc_info;
 extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
+extern void omap_dmtimer_init(void);
 
 #endif /* __ASSEMBLER__ */
 #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */

arch/arm/mach-omap2/timer.c +22 -0

index 13d20c8..e3b9931 100644
@@ -36,6 +36,7 @@
 #include <linux/clocksource.h>
 #include <linux/clockchips.h>
 #include <linux/slab.h>
+#include <linux/of.h>
 
 #include <asm/mach/time.h>
 #include <plat/dmtimer.h>

@@ -482,6 +483,41 @@ static int __init omap2_dm_timer_init(void)
 }
 arch_initcall(omap2_dm_timer_init);
 
+static struct property timer_disabled = {
+	.name = "status",
+	.length = sizeof("disabled"),
+	.value = "disabled",
+};
+
+static struct of_device_id omap3_timer_match[] __initdata = {
+	{ .compatible = "ti,omap3-timer", },
+	{ }
+};
+
+/**
+ * omap_dmtimer_init - initialisation function when device tree is used
+ *
+ * For secure OMAP3 devices, timers with device type "timer-secure" cannot
+ * be used by the kernel as they are reserved. Therefore, to prevent the
+ * kernel registering these devices remove them dynamically from the device
+ * tree on boot.
+ */
+void __init omap_dmtimer_init(void)
+{

Quoted 8 lines

arch/arm/mach-omap2/timer.c static int __init omap2_dm_timer_init(void) · line 511

Quoted 5 lines

arch/arm/mach-omap2/timer.c +5 -0

+	struct device_node *np;
+
+	if (!cpu_is_omap34xx())
+		return;
+

Sorry for responding so late, but why only omap34xx check here? Isn't this applicable to all omap & non-omap devices?

It is only applicable to omap3 devices as far as omap is concerned.

By non-omap, you are referring to the AMxxx stuff?

Quoted 3 lines

Do AMxxx devices even support security (ie. secure boot and have secure peripherals)? If not then this will work for AMxxx devices too.

Yes it does.

AM33xx has 8 timers and Timer-0 is a secure timer. As in case of OMAP3, we do not even register timer-0 to kernel.

Quoted 3 lines

Let me know if the changelog is not clear why this is needed for an omap3 device.

The changelog description is clear, but it is not only restricted to OMAP3.

Quoted 115 lines · Vaibhav

Quoted 114 lines · Jon

Quoted 99 lines · Vaibhav Hiremath

Quoted 96 lines · Jon Hunter

OMAP3 devices may or may not have security features enabled. Security enabled devices are known as high-secure (HS) and devices without security are known as general purpose (GP).

For OMAP3 devices there are 12 general purpose timers available. On secure devices the 12th timer is reserved for secure usage and so cannot be used by the kernel, where as for a GP device it is available. We can detect the OMAP device type, secure or GP, at runtime via an on-chip register. Today, when not using DT, we do not register the 12th timer as a linux device if the device is secure.

When using device tree, device tree is going to register all the timer devices it finds in the device tree blob. To prevent device tree from registering 12th timer on a secure OMAP3 device we can add a status property to the timer binding with the value "disabled" at boot time. Note that timer 12 on a OMAP3 device has a property "ti,timer-secure" to indicate that it will not be available on a secure device and so for secure OMAP3 devices, we search for timers with this property and then disable them. Using the prom_add_property() function to dynamically add a property was a recommended approach suggested by Rob Herring [1].

I have tested this on an OMAP3 GP device and faking it to pretend to be a secure device to ensure that any timers marked with "ti,timer-secure" are not registered on boot. I have also made sure that all timers are registered as expected on a GP device by default.

[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203

Signed-off-by Jon Hunter <[email protected]>

---
 arch/arm/mach-omap2/board-generic.c |    1 +
 arch/arm/mach-omap2/common.h        |    1 +
 arch/arm/mach-omap2/timer.c         |   36 +++++++++++++++++++++++++++++++++++
 3 files changed, 38 insertions(+)

arch/arm/mach-omap2/board-generic.c +1 -0

index 6f93a20..20124d7 100644
@@ -40,6 +40,7 @@ static struct of_device_id omap_dt_match_table[] __initdata = {
 static void __init omap_generic_init(void)
 {
 	omap_sdrc_init(NULL, NULL);
+	omap_dmtimer_init();
 
 	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
 }

arch/arm/mach-omap2/common.h +1 -0

index 1f65b18..d6a4875 100644
@@ -326,6 +326,7 @@ extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
 				      struct omap_sdrc_params *sdrc_cs1);
 struct omap2_hsmmc_info;
 extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
+extern void omap_dmtimer_init(void);
 
 #endif /* __ASSEMBLER__ */
 #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */

arch/arm/mach-omap2/timer.c +22 -0

index 13d20c8..e3b9931 100644
@@ -36,6 +36,7 @@
 #include <linux/clocksource.h>
 #include <linux/clockchips.h>
 #include <linux/slab.h>
+#include <linux/of.h>
 
 #include <asm/mach/time.h>
 #include <plat/dmtimer.h>

@@ -482,6 +483,41 @@ static int __init omap2_dm_timer_init(void)
 }
 arch_initcall(omap2_dm_timer_init);
 
+static struct property timer_disabled = {
+	.name = "status",
+	.length = sizeof("disabled"),
+	.value = "disabled",
+};
+
+static struct of_device_id omap3_timer_match[] __initdata = {
+	{ .compatible = "ti,omap3-timer", },
+	{ }
+};
+
+/**
+ * omap_dmtimer_init - initialisation function when device tree is used
+ *
+ * For secure OMAP3 devices, timers with device type "timer-secure" cannot
+ * be used by the kernel as they are reserved. Therefore, to prevent the
+ * kernel registering these devices remove them dynamically from the device
+ * tree on boot.
+ */
+void __init omap_dmtimer_init(void)
+{

Quoted 8 lines

arch/arm/mach-omap2/timer.c static int __init omap2_dm_timer_init(void) · line 511

Quoted 5 lines

arch/arm/mach-omap2/timer.c +5 -0

+	struct device_node *np;
+
+	if (!cpu_is_omap34xx())
+		return;
+

Sorry for responding so late, but why only omap34xx check here? Isn't this applicable to all omap & non-omap devices?

It is only applicable to omap3 devices as far as omap is concerned.

By non-omap, you are referring to the AMxxx stuff?

Quoted 8 lines

Quoted 3 lines

Do AMxxx devices even support security (ie. secure boot and have secure peripherals)? If not then this will work for AMxxx devices too.

Yes it does.

AM33xx has 8 timers and Timer-0 is a secure timer. As in case of OMAP3, we do not even register timer-0 to kernel.

Ok, however, please note that the omap3 timer 12 is a special case, because on a non-secure device it is available for general purpose use and only reserved for secure use on a secure device.

For omap4/5 timer 12 is always a secure timer and so we never register it for any device (secure or non-secure) by using the "ti,timer-secure" property in DT.

So, for AM33xx, is timer0 always reserved for secure used on non-secure and secure devices? If so, then timer0 just needs to add the "ti,timer-secure" property in device-tree file and it will not be registered and no change is needed in the above code.

1. If DT blob is present, then let HWMOD create the timer devices dynamically.

Hi

Quoted 1 line · Jon Hunter

1. If DT blob is present, then let HWMOD create the timer devices dynamically.

This probably should read "is _not_ present", yes?