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

From: [email-masked] (Jon Hunter)
Date: Thu, 16 Aug 2012 10:04:14 -0500

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