From: Vaibhav Hiremath <hvaibhav@ti.com>
To: Jon Hunter <jon-hunter@ti.com>
Cc: Rob Herring <robherring2@gmail.com>,
device-tree <devicetree-discuss@lists.ozlabs.org>,
linux-omap <linux-omap@vger.kernel.org>,
Tarun Kanti DebBarma <tarun.kanti@ti.com>,
linux-arm <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
Date: Wed, 15 Aug 2012 14:41:57 +0530 [thread overview]
Message-ID: <502B67DD.6050904@ti.com> (raw)
In-Reply-To: <500D6CAB.4030504@ti.com>
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
>
WARNING: multiple messages have this Message-ID (diff)
From: hvaibhav@ti.com (Vaibhav Hiremath)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
Date: Wed, 15 Aug 2012 14:41:57 +0530 [thread overview]
Message-ID: <502B67DD.6050904@ti.com> (raw)
In-Reply-To: <500D6CAB.4030504@ti.com>
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 at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
next prev parent reply other threads:[~2012-08-15 9:12 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-13 22:26 [RFC RESEND 0/4] ARM: OMAP3+: Add device-tree support for timers Jon Hunter
2012-07-13 22:26 ` Jon Hunter
2012-07-13 22:26 ` [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes Jon Hunter
2012-07-13 22:26 ` Jon Hunter
2012-07-14 2:15 ` Rob Herring
2012-07-14 2:15 ` Rob Herring
[not found] ` <5000D647.4090200-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-07-14 5:30 ` Mis?use of aliases Mitch Bradley
[not found] ` <50010402.3050502-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-07-14 16:37 ` David Gibson
2012-07-14 16:37 ` David Gibson
[not found] ` <20120714163701.GI11326-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org>
2012-07-14 17:07 ` Mitch Bradley
2012-07-14 17:07 ` Mitch Bradley
[not found] ` <5001A745.3000509-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-07-15 7:39 ` David Gibson
2012-07-15 7:39 ` David Gibson
2012-07-14 6:56 ` [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes Paul Walmsley
2012-07-14 6:56 ` Paul Walmsley
2012-07-14 14:01 ` Rob Herring
2012-07-14 14:01 ` Rob Herring
[not found] ` <50017BB1.8010702-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-07-14 17:42 ` Paul Walmsley
2012-07-14 17:42 ` Paul Walmsley
2012-07-16 17:48 ` Paul Walmsley
2012-07-16 17:48 ` Paul Walmsley
2012-07-16 15:56 ` Jon Hunter
2012-07-16 15:56 ` Jon Hunter
2012-07-18 7:19 ` Tony Lindgren
2012-07-18 7:19 ` Tony Lindgren
2012-07-18 15:11 ` Jon Hunter
2012-07-18 15:11 ` Jon Hunter
2012-07-23 15:24 ` Jon Hunter
2012-07-23 15:24 ` Jon Hunter
2012-08-15 9:11 ` Vaibhav Hiremath [this message]
2012-08-15 9:11 ` Vaibhav Hiremath
2012-08-16 15:04 ` Jon Hunter
2012-08-16 15:04 ` Jon Hunter
2012-08-30 20:14 ` Tony Lindgren
2012-08-30 20:14 ` Tony Lindgren
2012-09-07 20:26 ` Jon Hunter
2012-09-07 20:26 ` Jon Hunter
2012-09-07 20:56 ` Tony Lindgren
2012-09-07 20:56 ` Tony Lindgren
2012-09-07 21:16 ` Jon Hunter
2012-09-07 21:16 ` Jon Hunter
2012-09-06 13:45 ` Rob Herring
2012-09-06 13:45 ` Rob Herring
[not found] ` <5048A8F6.6080108-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-09-07 2:09 ` Jon Hunter
2012-09-07 2:09 ` Jon Hunter
2012-07-13 22:26 ` [RFC RESEND 2/4] ARM: OMAP3: Dynamically disable secure timer nodes for secure devices Jon Hunter
2012-07-13 22:26 ` Jon Hunter
2012-08-15 9:13 ` Vaibhav Hiremath
2012-08-15 9:13 ` Vaibhav Hiremath
2012-08-16 16:57 ` Jon Hunter
2012-08-16 16:57 ` Jon Hunter
[not found] ` <502D2686.4090107-l0cyMroinI0@public.gmane.org>
2012-08-17 5:32 ` Hiremath, Vaibhav
2012-08-17 5:32 ` Hiremath, Vaibhav
2012-08-17 12:24 ` Jon Hunter
2012-08-17 12:24 ` Jon Hunter
2012-08-24 15:56 ` Hiremath, Vaibhav
2012-08-24 15:56 ` Hiremath, Vaibhav
2012-07-13 22:26 ` [RFC RESEND 3/4] ARM: OMAP4: Add timer clock aliases for device-tree Jon Hunter
2012-07-13 22:26 ` Jon Hunter
2012-07-13 22:26 ` [RFC RESEND 4/4] ARM: OMAP: Add DT support for timer driver Jon Hunter
2012-07-13 22:26 ` Jon Hunter
2012-07-13 23:41 ` Paul Walmsley
2012-07-13 23:41 ` Paul Walmsley
[not found] ` <alpine.DEB.2.00.1207131740460.25585-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
2012-07-14 0:57 ` Jon Hunter
2012-07-14 0:57 ` Jon Hunter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=502B67DD.6050904@ti.com \
--to=hvaibhav@ti.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=jon-hunter@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=robherring2@gmail.com \
--cc=tarun.kanti@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.