diff mbox

[RFC,RESEND,1/4] arm/dts: OMAP: Add timer nodes

Message ID 1342218413-30116-2-git-send-email-jon-hunter@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Hunter, Jon July 13, 2012, 10:26 p.m. UTC
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 <b-cousson@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 .../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

Comments

Rob Herring July 14, 2012, 2:15 a.m. UTC | #1
On 07/13/2012 05:26 PM, Jon Hunter wrote:
> 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.

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.

Rob

> 
> Cc: Benoit Cousson <b-cousson@ti.com>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
>  .../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
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt
> new file mode 100644
> index 0000000..dcbb451
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
> @@ -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@48304000 {
> +	compatible = "ti,omap3-timer";
> +	reg = <0x48304000 0xfff>;
> +	interrupts = <95>;
> +	ti,hwmods = "timer12"
> +	ti,timer-alwon;
> +	ti,timer-secure;
> +};
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 8109471..f309f2a 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -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@48318000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x48318000 0xfff>;
> +			interrupts = <37>;
> +			ti,hwmods = "timer1";
> +			ti,timer-alwon;
> +		};
> +
> +		timer2: timer@49032000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x49032000 0xfff>;
> +			interrupts = <38>;
> +			ti,hwmods = "timer2";
> +		};
> +
> +		timer3: timer@49034000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x49034000 0xfff>;
> +			interrupts = <39>;
> +			ti,hwmods = "timer3";
> +		};
> +
> +		timer4: timer@49036000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x49036000 0xfff>;
> +			interrupts = <40>;
> +			ti,hwmods = "timer4";
> +		};
> +
> +		timer5: timer@49038000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x49038000 0xfff>;
> +			interrupts = <41>;
> +			ti,hwmods = "timer5";
> +		};
> +
> +		timer6: timer@4903a000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x4903a000 0xfff>;
> +			interrupts = <42>;
> +			ti,hwmods = "timer6";
> +		};
> +
> +		timer7: timer@4903c000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x4903c000 0xfff>;
> +			interrupts = <43>;
> +			ti,hwmods = "timer7";
> +		};
> +
> +		timer8: timer@4903e000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x4903e000 0xfff>;
> +			interrupts = <44>;
> +			ti,hwmods = "timer8";
> +			ti,timer-pwm;
> +		};
> +
> +		timer9: timer@49040000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x49040000 0xfff>;
> +			interrupts = <45>;
> +			ti,hwmods = "timer9";
> +			ti,timer-pwm;
> +		};
> +
> +		timer10: timer@48086000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x48086000 0xfff>;
> +			interrupts = <46>;
> +			ti,hwmods = "timer10";
> +			ti,timer-pwm;
> +		};
> +
> +		timer11: timer@48088000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x48088000 0xfff>;
> +			interrupts = <47>;
> +			ti,hwmods = "timer11";
> +			ti,timer-pwm;
> +		};
> +
> +		timer12: timer@48304000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x48304000 0xfff>;
> +			interrupts = <95>;
> +			ti,hwmods = "timer12";
> +			ti,timer-alwon;
> +			ti,timer-secure;
> +		};
>  	};
>  };
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 04cbbcb..39716c5 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -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@4a318000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x4a318000 0x7f>;
> +			interrupts = <0 37 0x4>;
> +			ti,hwmods = "timer1";
> +			ti,timer-alwon;
> +		};
> +
> +		timer2: timer@48032000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x48032000 0x7f>;
> +			interrupts = <0 38 0x4>;
> +			ti,hwmods = "timer2";
> +		};
> +
> +		timer3: timer@48034000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x48034000 0x7f>;
> +			interrupts = <0 39 0x4>;
> +			ti,hwmods = "timer3";
> +		};
> +
> +		timer4: timer@48036000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x48036000 0x7f>;
> +			interrupts = <0 40 0x4>;
> +			ti,hwmods = "timer4";
> +		};
> +
> +		timer5: timer@49038000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x49038000 0x7f>;
> +			interrupts = <0 41 0x4>;
> +			ti,hwmods = "timer5";
> +		};
> +
> +		timer6: timer@4903a000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x4903a000 0x7f>;
> +			interrupts = <0 42 0x4>;
> +			ti,hwmods = "timer6";
> +		};
> +
> +		timer7: timer@4903c000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x4903c000 0x7f>;
> +			interrupts = <0 43 0x4>;
> +			ti,hwmods = "timer7";
> +		};
> +
> +		timer8: timer@4903e000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x4903e000 0x7f>;
> +			interrupts = <0 44 0x4>;
> +			ti,hwmods = "timer8";
> +			ti,timer-pwm;
> +		};
> +
> +		timer9: timer@4803e000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x4803e000 0x7f>;
> +			interrupts = <0 45 0x4>;
> +			ti,hwmods = "timer9";
> +			ti,timer-pwm;
> +		};
> +
> +		timer10: timer@48086000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x48086000 0x7f>;
> +			interrupts = <0 46 0x4>;
> +			ti,hwmods = "timer10";
> +			ti,timer-pwm;
> +		};
> +
> +		timer11: timer@48088000 {
> +			compatible = "ti,omap3-timer";
> +			reg = <0x48088000 0x7f>;
> +			interrupts = <0 47 0x4>;
> +			ti,hwmods = "timer11";
> +			ti,timer-pwm;
> +		};
>  	};
>  };
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mitch Bradley July 14, 2012, 5:30 a.m. UTC | #2
> 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.

Mitch
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Paul Walmsley July 14, 2012, 6:56 a.m. UTC | #3
Hi

On Fri, 13 Jul 2012, Rob Herring wrote:

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rob Herring July 14, 2012, 2:01 p.m. UTC | #4
On 07/14/2012 01:56 AM, Paul Walmsley wrote:
> Hi
> 
> On Fri, 13 Jul 2012, Rob Herring wrote:
> 
>> 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.

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.

Rob

> 
> 
> - Paul
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Gibson July 14, 2012, 4:37 p.m. UTC | #5
On Fri, Jul 13, 2012 at 07:30:42PM -1000, Mitch Bradley wrote:
> > 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.

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.

> 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.
Mitch Bradley July 14, 2012, 5:07 p.m. UTC | #6
On 7/14/2012 6:37 AM, David Gibson wrote:
> On Fri, Jul 13, 2012 at 07:30:42PM -1000, Mitch Bradley wrote:
>>> 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.
> 
> 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.

> 
> 	prop = <&fred>;
> Will generate a phandle valued property, but
> 	prop = &fred;
> Will generate a string (path) valued property.
> 
>> 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".

For historical reference: The original use of /aliases was as a
component of pathname resolution, which is a "global" function.  In that
usage model, a given alias does not necessarily refer specifically to
exactly one node, so "localizing" an alias inside a node doesn't work.

The new usage for binding to a Linux name could be localized.  My
general preference is to localize whenever possible.  But, again,
breaking that rule in this case is not a huge problem.

Thanks again for zeroing in on my mistake.

Mitch


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Paul Walmsley July 14, 2012, 5:42 p.m. UTC | #7
Hi Rob,

thanks for your response.

On Sat, 14 Jul 2012, Rob Herring wrote:

> On 07/14/2012 01:56 AM, Paul Walmsley wrote:
> > On Fri, 13 Jul 2012, Rob Herring wrote:
> > 
> >> 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.
> 
> Yes, I understand that. So you

(just to clarify, these are Jon's patches)

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

Right, agreed.

> 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?


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Gibson July 15, 2012, 7:39 a.m. UTC | #8
On Sat, Jul 14, 2012 at 07:07:17AM -1000, Mitch Bradley wrote:
> On 7/14/2012 6:37 AM, David Gibson wrote:
> > On Fri, Jul 13, 2012 at 07:30:42PM -1000, Mitch Bradley wrote:
> >>> 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.
> > 
> > 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.

Right, it's all about the context.  &label is always a reference to
another node, but in cell context < ... > that's expanded as a
phandle, in bare context it's expanded as a path.

> > 	prop = <&fred>;
> > Will generate a phandle valued property, but
> > 	prop = &fred;
> > Will generate a string (path) valued property.
> > 
> >> 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".

So, I think aliases was suggested for this sort of numbering precisely
because it _isn't_ local.  Particularly when numbering similar devices
across unrelated busses, the ordering more or less has to be a global
platform convention, and may not be derived from - or even contradict
- local numbering conventions from individual busses or components.
Hunter, Jon July 16, 2012, 3:56 p.m. UTC | #9
Hi Rob,

On 07/13/2012 09:15 PM, Rob Herring wrote:
> On 07/13/2012 05:26 PM, Jon Hunter wrote:
>> 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.
> 
> 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.

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

Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Paul Walmsley July 16, 2012, 5:48 p.m. UTC | #10
Hi Rob,

On Sat, 14 Jul 2012, Paul Walmsley wrote:

> 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?

Please disregard this question, I think I'm misunderstanding something 
from a previous mail...


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren July 18, 2012, 7:19 a.m. UTC | #11
* Jon Hunter <jon-hunter@ti.com> [120716 09:01]:
> 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
> ...

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.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hunter, Jon July 18, 2012, 3:11 p.m. UTC | #12
Hi Tony,

On 07/18/2012 02:19 AM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter@ti.com> [120716 09:01]:
>> 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
>> ...
> 
> 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.

I have seen that timers are used by the GPU and Ducati. Maybe I can
check with the authors to see if we can get them to request by
capability instead. If we can't then I need to figure out a way to
resolve the timer ID when using DT. Per Rob's comments using alias is
not the intended use. An alternative would be to extract the ID from the
hwmod name, but was not sure if that would be appropriate either :-(

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

Yes, that is handled by patch 2/4. If we are on a secure device, then
will not register any timers marked with the "ti,timer-secure" property.

Cheers
Jon

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hunter, Jon July 23, 2012, 3:24 p.m. UTC | #13
Hi Rob,

On 07/16/2012 10:56 AM, Jon Hunter wrote:
> Hi Rob,
> 
> On 07/13/2012 09:15 PM, Rob Herring wrote:
>> On 07/13/2012 05:26 PM, Jon Hunter wrote:
>>> 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.
>>
>> 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.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Vaibhav Hiremath Aug. 15, 2012, 9:11 a.m. UTC | #14
On 7/23/2012 8:54 PM, Jon Hunter wrote:
> Hi Rob,
> 
> On 07/16/2012 10:56 AM, Jon Hunter wrote:
>> Hi Rob,
>>
>> On 07/13/2012 09:15 PM, Rob Herring wrote:
>>> On 07/13/2012 05:26 PM, Jon Hunter wrote:
>>>> 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.
>>>
>>> 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.
> 
> 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.


Thanks,
Vaibhav

> Cheers
> Jon
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hunter, Jon Aug. 16, 2012, 3:04 p.m. UTC | #15
Hi Vaibhav,

On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote:
> 
> 
> On 7/23/2012 8:54 PM, Jon Hunter wrote:
>> Hi Rob,
>>
>> On 07/16/2012 10:56 AM, Jon Hunter wrote:
>>> Hi Rob,
>>>
>>> On 07/13/2012 09:15 PM, Rob Herring wrote:
>>>> On 07/13/2012 05:26 PM, Jon Hunter wrote:
>>>>> 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.
>>>>
>>>> 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.
>>
>> 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.

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.

Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren Aug. 30, 2012, 8:14 p.m. UTC | #16
* Jon Hunter <jon-hunter@ti.com> [120816 08:05]:
> On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote:
> > 
> > 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.

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

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rob Herring Sept. 6, 2012, 1:45 p.m. UTC | #17
On 07/23/2012 10:24 AM, Jon Hunter wrote:
> Hi Rob,
> 
> On 07/16/2012 10:56 AM, Jon Hunter wrote:
>> Hi Rob,
>>
>> On 07/13/2012 09:15 PM, Rob Herring wrote:
>>> On 07/13/2012 05:26 PM, Jon Hunter wrote:
>>>> 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.
>>>
>>> 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.
> 
> 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?

Rob

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hunter, Jon Sept. 7, 2012, 2:09 a.m. UTC | #18
On 09/06/2012 08:45 AM, Rob Herring wrote:
> On 07/23/2012 10:24 AM, Jon Hunter wrote:

[snip]

>> 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?

I agree. Currently, I am looking into implementing something that will
use timer properties to select the system timers for the kernel and not
require us to select them in the device-tree. Once I have something
working I will send out for review.

Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hunter, Jon Sept. 7, 2012, 8:26 p.m. UTC | #19
Hi Tony,

On 08/30/2012 03:14 PM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter@ti.com> [120816 08:05]:
>> On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote:
>>>
>>> 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.
> 
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren Sept. 7, 2012, 8:56 p.m. UTC | #20
* Jon Hunter <jon-hunter@ti.com> [120907 13:27]:
> Hi Tony,
> 
> On 08/30/2012 03:14 PM, Tony Lindgren wrote:
> > * Jon Hunter <jon-hunter@ti.com> [120816 08:05]:
> >> On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote:
> >>>
> >>> 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.
> > 
> > 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.

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?

Regards,

Tony
 
> Cheers
> Jon
> 
> [1] https://github.com/jonhunter/linux/tree/dev-dt-timer
> [2] http://marc.info/?l=linux-omap&m=134687188921835&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hunter, Jon Sept. 7, 2012, 9:16 p.m. UTC | #21
On 09/07/2012 03:56 PM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter@ti.com> [120907 13:27]:
>> Hi Tony,
>>
>> On 08/30/2012 03:14 PM, Tony Lindgren wrote:
>>> * Jon Hunter <jon-hunter@ti.com> [120816 08:05]:
>>>> On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote:
>>>>>
>>>>> 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.
>>>
>>> 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.
> 
> 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?

The fixes series should already be based on top of 3.6-rc4 but will
update based upon comments. The only outstanding comment on those were
the implementation of the __omap_dm_timer_populate_errata() function.
Not sure if you have any comments. Vaibhav and myself are not completely
happy with it. I proposed something else but no feedback on that yet.

Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt
new file mode 100644
index 0000000..dcbb451
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -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@48304000 {
+	compatible = "ti,omap3-timer";
+	reg = <0x48304000 0xfff>;
+	interrupts = <95>;
+	ti,hwmods = "timer12"
+	ti,timer-alwon;
+	ti,timer-secure;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 8109471..f309f2a 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -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@48318000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48318000 0xfff>;
+			interrupts = <37>;
+			ti,hwmods = "timer1";
+			ti,timer-alwon;
+		};
+
+		timer2: timer@49032000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x49032000 0xfff>;
+			interrupts = <38>;
+			ti,hwmods = "timer2";
+		};
+
+		timer3: timer@49034000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x49034000 0xfff>;
+			interrupts = <39>;
+			ti,hwmods = "timer3";
+		};
+
+		timer4: timer@49036000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x49036000 0xfff>;
+			interrupts = <40>;
+			ti,hwmods = "timer4";
+		};
+
+		timer5: timer@49038000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x49038000 0xfff>;
+			interrupts = <41>;
+			ti,hwmods = "timer5";
+		};
+
+		timer6: timer@4903a000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x4903a000 0xfff>;
+			interrupts = <42>;
+			ti,hwmods = "timer6";
+		};
+
+		timer7: timer@4903c000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x4903c000 0xfff>;
+			interrupts = <43>;
+			ti,hwmods = "timer7";
+		};
+
+		timer8: timer@4903e000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x4903e000 0xfff>;
+			interrupts = <44>;
+			ti,hwmods = "timer8";
+			ti,timer-pwm;
+		};
+
+		timer9: timer@49040000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x49040000 0xfff>;
+			interrupts = <45>;
+			ti,hwmods = "timer9";
+			ti,timer-pwm;
+		};
+
+		timer10: timer@48086000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48086000 0xfff>;
+			interrupts = <46>;
+			ti,hwmods = "timer10";
+			ti,timer-pwm;
+		};
+
+		timer11: timer@48088000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48088000 0xfff>;
+			interrupts = <47>;
+			ti,hwmods = "timer11";
+			ti,timer-pwm;
+		};
+
+		timer12: timer@48304000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48304000 0xfff>;
+			interrupts = <95>;
+			ti,hwmods = "timer12";
+			ti,timer-alwon;
+			ti,timer-secure;
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 04cbbcb..39716c5 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -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@4a318000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x4a318000 0x7f>;
+			interrupts = <0 37 0x4>;
+			ti,hwmods = "timer1";
+			ti,timer-alwon;
+		};
+
+		timer2: timer@48032000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48032000 0x7f>;
+			interrupts = <0 38 0x4>;
+			ti,hwmods = "timer2";
+		};
+
+		timer3: timer@48034000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48034000 0x7f>;
+			interrupts = <0 39 0x4>;
+			ti,hwmods = "timer3";
+		};
+
+		timer4: timer@48036000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48036000 0x7f>;
+			interrupts = <0 40 0x4>;
+			ti,hwmods = "timer4";
+		};
+
+		timer5: timer@49038000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x49038000 0x7f>;
+			interrupts = <0 41 0x4>;
+			ti,hwmods = "timer5";
+		};
+
+		timer6: timer@4903a000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x4903a000 0x7f>;
+			interrupts = <0 42 0x4>;
+			ti,hwmods = "timer6";
+		};
+
+		timer7: timer@4903c000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x4903c000 0x7f>;
+			interrupts = <0 43 0x4>;
+			ti,hwmods = "timer7";
+		};
+
+		timer8: timer@4903e000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x4903e000 0x7f>;
+			interrupts = <0 44 0x4>;
+			ti,hwmods = "timer8";
+			ti,timer-pwm;
+		};
+
+		timer9: timer@4803e000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x4803e000 0x7f>;
+			interrupts = <0 45 0x4>;
+			ti,hwmods = "timer9";
+			ti,timer-pwm;
+		};
+
+		timer10: timer@48086000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48086000 0x7f>;
+			interrupts = <0 46 0x4>;
+			ti,hwmods = "timer10";
+			ti,timer-pwm;
+		};
+
+		timer11: timer@48088000 {
+			compatible = "ti,omap3-timer";
+			reg = <0x48088000 0x7f>;
+			interrupts = <0 47 0x4>;
+			ti,hwmods = "timer11";
+			ti,timer-pwm;
+		};
 	};
 };