| Message ID | 1342218413-30116-2-git-send-email-jon-hunter@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
> 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
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
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
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.
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
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
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.
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
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
* 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
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
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
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
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
* 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
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
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
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
* 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
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 --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; + }; }; };
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