Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
Hi Tony, On 08/30/2012 03:14 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@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-omapm=134687188921835w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
* Jon Hunter jon-hun...@ti.com [120907 13:27]: Hi Tony, On 08/30/2012 03:14 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@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-omapm=134687188921835w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
On 09/07/2012 03:56 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [120907 13:27]: Hi Tony, On 08/30/2012 03:14 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
* Jon Hunter jon-hun...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
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-disc...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
* Jon Hunter jon-hun...@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 0x8000 #define OMAP_TIMER_ALWON0x4000 #define OMAP_TIMER_HAS_PWM 0x2000 ... 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
Hi Tony, On 07/18/2012 02:19 AM, Tony Lindgren wrote: * Jon Hunter jon-hun...@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 0x8000 #define OMAP_TIMER_ALWON0x4000 #define OMAP_TIMER_HAS_PWM 0x2000 ... 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
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 0x8000
#define OMAP_TIMER_ALWON0x4000
#define OMAP_TIMER_HAS_PWM 0x2000
...
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
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-cous...@ti.com
Signed-off-by: Jon Hunter jon-hun...@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 000..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:
+ timerX, 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;
+ };
+
+
