All of lore.kernel.org
 help / color / mirror / Atom feed
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 18:55:49 -0600	[thread overview]
Message-ID: <509C5495.1010109@ti.com> (raw)
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB686AC@DBDE01.ent.ti.com>


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?

By the way, according to the AM3358 data manual (paragraph above), even
if there is no external 32k clock source and if you don't use the
internal 32k oscillator, you can still generate a 32k clock from the PER
PLL (CLK_32KHZ). So therefore, there should always be a 32k clock source
available for the gptimer. Is that correct?

At the end of the day, I am just trying to understand if any OMAP/AM
device supports a h/w configuration where there is no 32k clock source
available for the gptimer.

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 18:55:49 -0600	[thread overview]
Message-ID: <509C5495.1010109@ti.com> (raw)
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB686AC@DBDE01.ent.ti.com>


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?

By the way, according to the AM3358 data manual (paragraph above), even
if there is no external 32k clock source and if you don't use the
internal 32k oscillator, you can still generate a 32k clock from the PER
PLL (CLK_32KHZ). So therefore, there should always be a 32k clock source
available for the gptimer. Is that correct?

At the end of the day, I am just trying to understand if any OMAP/AM
device supports a h/w configuration where there is no 32k clock source
available for the gptimer.

Jon

  parent reply	other threads:[~2012-11-09  0:55 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
2012-11-08 18:47                       ` Jon Hunter
2012-11-09  0:55                 ` Jon Hunter [this message]
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=509C5495.1010109@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.