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