From: Jon Hunter <jon-hunter@ti.com>
To: "Hiremath, Vaibhav" <hvaibhav@ti.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>,
Tony Lindgren <tony@atomide.com>,
"Hilman, Kevin" <khilman@ti.com>, Paul Walmsley <paul@pwsan.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Shilimkar, Santosh" <santosh.shilimkar@ti.com>
Subject: Re: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
Date: Thu, 8 Nov 2012 12:47:18 -0600 [thread overview]
Message-ID: <509BFE36.5090700@ti.com> (raw)
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB6872B@DBDE01.ent.ti.com>
On 11/08/2012 12:28 PM, Hiremath, Vaibhav wrote:
> On Thu, Nov 08, 2012 at 23:43:31, Hunter, Jon wrote:
>>
>> On 11/08/2012 12:06 PM, Hiremath, Vaibhav wrote:
>>> On Thu, Nov 08, 2012 at 23:28:53, Hunter, Jon wrote:
>>>>
>>>> On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote:
>>>>> On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote:
>>>>
>>>> [snip]
>>>>
>>>>>> I think you are missing the point here. For OMAP devices we have two
>>>>>> main external clock sources which are the 32kHz clock and the sys_clk
>>>>>> (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is
>>>>>> for OMAP these clock sources are always present and AFAIK there is no
>>>>>> h/w configuration that allows you not to have the 32kHz clock source.
>>>>>> PRCM needs it and I think for OMAP1 the reset logic needs it (if memory
>>>>>> serves).
>>>>>>
>>>>>> Igor was mentioning a h/w scenario where the 32kHz source is not
>>>>>> present. However, I am not sure which devices support this and is
>>>>>> applicable too.
>>>>>>
>>>>>> So we are not discussing the 32k-sync-timer here. We are discussing
>>>>>> whether there are any device configurations where a 32k clock source
>>>>>> would not be available for the gptimer.
>>>>>>
>>>>>
>>>>> Exactly that is the point I am trying to make here,
>>>>>
>>>>> In case of AM33xx, it is certainly possible to build the system without
>>>>> this 32Khz clock.
>>>>>
>>>>> Interesting point here is, this 32KHz clock is external clock coming from
>>>>> crystal connected to in-built RTC module.
>>>>
>>>> Thanks. Looking at the AM3358 data manual it states ...
>>>>
>>>> "The OSC1 oscillator provides a 32.768-kHz reference clock to the
>>>> real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT
>>>> terminals. OSC1 is disabled by default after power is applied. This
>>>> clock input is optional and may not be required if the RTC is configured
>>>> to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or
>>>> peripheral PLL (CLK_32KHZ) which receives a reference clock from the
>>>> OSC0 input."
>>>>
>>>> So what is clear to me that an external 32k clock source is optional.
>>>> However, it still appears that you will always have an internal 32k
>>>> source and so regardless of the h/w configuration, a gptimer will always
>>>> have an 32k clock available on the AM335x devices. Is that correct?
>>>>
>>>
>>> Internal RC oscillator is not accurate at all, so not guaranteed to give
>>> accurate 32.768Hz clock. The oscillation band is from 16Khz to 64Khz.
>>>
>>> So it may not be useful as a system clocks, right?
>>
>> So I admit I am not familiar with the details on the AMxxxx stuff side
>> so much.
>>
>> So maybe I should ask this question ...
>>
>> Do you support a configuration where there is no external 32k clock AND
>> the internal oscillator and hence, RTC are not used?
>>
>
> Why not, you could give-up on persistent time across suspend/resume and use
> OSC clock as a input clock to timer.
>
> And the timer code, which we have we have added fallback mechanism for this,
> First make sure that timer is properly set for RTC32K, if yes, then use it,
> and if no, then fall back to OSC clock.
You mean sync-32k and not rtc32k right? We are just detecting the
presence of the sync-32k counter and if so use it, otherwise use a gptimer.
>> I would have expected that you would always want the RTC running, but if
>> you are saying that you don't require an external 32k and the internal
>> 32k is not accurate, then I assume that having the RTC available is not
>> mandatory either.
>>
>
> Yes, it is not mandatory, considering fact that, you will not have
> persistent time and other low-power modes.
> Actually it depends on board/EVM use-case, right?
Yes absolutely, just trying to understand if that is a valid use-case or
not. So for AM33xx the external 32k is not mandatory. Thanks.
Jon
WARNING: multiple messages have this Message-ID (diff)
From: jon-hunter@ti.com (Jon Hunter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
Date: Thu, 8 Nov 2012 12:47:18 -0600 [thread overview]
Message-ID: <509BFE36.5090700@ti.com> (raw)
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB6872B@DBDE01.ent.ti.com>
On 11/08/2012 12:28 PM, Hiremath, Vaibhav wrote:
> On Thu, Nov 08, 2012 at 23:43:31, Hunter, Jon wrote:
>>
>> On 11/08/2012 12:06 PM, Hiremath, Vaibhav wrote:
>>> On Thu, Nov 08, 2012 at 23:28:53, Hunter, Jon wrote:
>>>>
>>>> On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote:
>>>>> On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote:
>>>>
>>>> [snip]
>>>>
>>>>>> I think you are missing the point here. For OMAP devices we have two
>>>>>> main external clock sources which are the 32kHz clock and the sys_clk
>>>>>> (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is
>>>>>> for OMAP these clock sources are always present and AFAIK there is no
>>>>>> h/w configuration that allows you not to have the 32kHz clock source.
>>>>>> PRCM needs it and I think for OMAP1 the reset logic needs it (if memory
>>>>>> serves).
>>>>>>
>>>>>> Igor was mentioning a h/w scenario where the 32kHz source is not
>>>>>> present. However, I am not sure which devices support this and is
>>>>>> applicable too.
>>>>>>
>>>>>> So we are not discussing the 32k-sync-timer here. We are discussing
>>>>>> whether there are any device configurations where a 32k clock source
>>>>>> would not be available for the gptimer.
>>>>>>
>>>>>
>>>>> Exactly that is the point I am trying to make here,
>>>>>
>>>>> In case of AM33xx, it is certainly possible to build the system without
>>>>> this 32Khz clock.
>>>>>
>>>>> Interesting point here is, this 32KHz clock is external clock coming from
>>>>> crystal connected to in-built RTC module.
>>>>
>>>> Thanks. Looking at the AM3358 data manual it states ...
>>>>
>>>> "The OSC1 oscillator provides a 32.768-kHz reference clock to the
>>>> real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT
>>>> terminals. OSC1 is disabled by default after power is applied. This
>>>> clock input is optional and may not be required if the RTC is configured
>>>> to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or
>>>> peripheral PLL (CLK_32KHZ) which receives a reference clock from the
>>>> OSC0 input."
>>>>
>>>> So what is clear to me that an external 32k clock source is optional.
>>>> However, it still appears that you will always have an internal 32k
>>>> source and so regardless of the h/w configuration, a gptimer will always
>>>> have an 32k clock available on the AM335x devices. Is that correct?
>>>>
>>>
>>> Internal RC oscillator is not accurate at all, so not guaranteed to give
>>> accurate 32.768Hz clock. The oscillation band is from 16Khz to 64Khz.
>>>
>>> So it may not be useful as a system clocks, right?
>>
>> So I admit I am not familiar with the details on the AMxxxx stuff side
>> so much.
>>
>> So maybe I should ask this question ...
>>
>> Do you support a configuration where there is no external 32k clock AND
>> the internal oscillator and hence, RTC are not used?
>>
>
> Why not, you could give-up on persistent time across suspend/resume and use
> OSC clock as a input clock to timer.
>
> And the timer code, which we have we have added fallback mechanism for this,
> First make sure that timer is properly set for RTC32K, if yes, then use it,
> and if no, then fall back to OSC clock.
You mean sync-32k and not rtc32k right? We are just detecting the
presence of the sync-32k counter and if so use it, otherwise use a gptimer.
>> I would have expected that you would always want the RTC running, but if
>> you are saying that you don't require an external 32k and the internal
>> 32k is not accurate, then I assume that having the RTC available is not
>> mandatory either.
>>
>
> Yes, it is not mandatory, considering fact that, you will not have
> persistent time and other low-power modes.
> Actually it depends on board/EVM use-case, right?
Yes absolutely, just trying to understand if that is a valid use-case or
not. So for AM33xx the external 32k is not mandatory. Thanks.
Jon
next prev parent reply other threads:[~2012-11-08 18:47 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-07 14:42 [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER Igor Grinberg
2012-11-07 14:42 ` Igor Grinberg
2012-11-07 17:33 ` Tony Lindgren
2012-11-07 17:33 ` Tony Lindgren
2012-11-08 7:13 ` Igor Grinberg
2012-11-08 7:13 ` Igor Grinberg
2012-11-08 16:20 ` Tony Lindgren
2012-11-08 16:20 ` Tony Lindgren
2012-11-08 17:09 ` Hiremath, Vaibhav
2012-11-08 17:09 ` Hiremath, Vaibhav
2012-11-11 9:16 ` Igor Grinberg
2012-11-11 9:16 ` Igor Grinberg
2012-11-12 19:05 ` Jon Hunter
2012-11-12 19:05 ` Jon Hunter
2012-11-13 9:08 ` Igor Grinberg
2012-11-13 9:08 ` Igor Grinberg
2012-11-12 22:06 ` Tony Lindgren
2012-11-12 22:06 ` Tony Lindgren
2012-11-07 21:36 ` Jon Hunter
2012-11-07 21:36 ` Jon Hunter
2012-11-08 7:59 ` Igor Grinberg
2012-11-08 7:59 ` Igor Grinberg
2012-11-08 16:16 ` Jon Hunter
2012-11-08 16:16 ` Jon Hunter
2012-11-08 17:08 ` Hiremath, Vaibhav
2012-11-08 17:08 ` Hiremath, Vaibhav
2012-11-08 17:39 ` Jon Hunter
2012-11-08 17:39 ` Jon Hunter
2012-11-08 17:47 ` Hiremath, Vaibhav
2012-11-08 17:47 ` Hiremath, Vaibhav
2012-11-08 17:58 ` Jon Hunter
2012-11-08 17:58 ` Jon Hunter
2012-11-08 18:06 ` Hiremath, Vaibhav
2012-11-08 18:06 ` Hiremath, Vaibhav
2012-11-08 18:13 ` Jon Hunter
2012-11-08 18:13 ` Jon Hunter
2012-11-08 18:28 ` Hiremath, Vaibhav
2012-11-08 18:28 ` Hiremath, Vaibhav
2012-11-08 18:47 ` Jon Hunter [this message]
2012-11-08 18:47 ` Jon Hunter
2012-11-09 0:55 ` Jon Hunter
2012-11-09 0:55 ` Jon Hunter
2012-11-12 6:42 ` Hiremath, Vaibhav
2012-11-12 6:42 ` Hiremath, Vaibhav
2012-11-08 17:58 ` Paul Walmsley
2012-11-08 17:58 ` Paul Walmsley
2012-11-08 18:08 ` Jon Hunter
2012-11-08 18:08 ` Jon Hunter
2012-11-08 18:17 ` Paul Walmsley
2012-11-08 18:17 ` Paul Walmsley
2012-11-08 18:34 ` Jon Hunter
2012-11-08 18:34 ` Jon Hunter
2012-11-11 11:35 ` Igor Grinberg
2012-11-11 11:35 ` Igor Grinberg
2012-11-12 6:38 ` Hiremath, Vaibhav
2012-11-12 6:38 ` Hiremath, Vaibhav
2012-11-12 7:24 ` Igor Grinberg
2012-11-12 7:24 ` Igor Grinberg
2012-11-12 10:40 ` Hiremath, Vaibhav
2012-11-12 10:40 ` Hiremath, Vaibhav
2012-12-10 20:49 ` Paul Walmsley
2012-12-10 20:49 ` Paul Walmsley
2012-12-14 23:58 ` Russ Dill
2012-12-14 23:58 ` Russ Dill
2012-11-11 11:25 ` Igor Grinberg
2012-11-11 11:25 ` Igor Grinberg
2012-11-08 18:54 ` Jon Hunter
2012-11-08 18:54 ` Jon Hunter
2012-11-08 18:59 ` Hiremath, Vaibhav
2012-11-08 18:59 ` Hiremath, Vaibhav
2012-11-08 19:16 ` Jon Hunter
2012-11-08 19:16 ` Jon Hunter
2012-11-11 11:28 ` Igor Grinberg
2012-11-11 11:28 ` Igor Grinberg
2012-11-12 19:15 ` Jon Hunter
2012-11-12 19:15 ` Jon Hunter
2012-11-13 9:14 ` Igor Grinberg
2012-11-13 9:14 ` Igor Grinberg
2012-11-13 16:13 ` Jon Hunter
2012-11-13 16:13 ` Jon Hunter
2012-11-14 7:23 ` Igor Grinberg
2012-11-14 7:23 ` Igor Grinberg
2012-11-12 10:38 ` Hiremath, Vaibhav
2012-11-12 10:38 ` Hiremath, Vaibhav
2012-11-12 11:01 ` Benoit Cousson
2012-11-12 11:01 ` Benoit Cousson
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=509BFE36.5090700@ti.com \
--to=jon-hunter@ti.com \
--cc=grinberg@compulab.co.il \
--cc=hvaibhav@ti.com \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=santosh.shilimkar@ti.com \
--cc=tony@atomide.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.