From: Nishanth Menon <nm@ti.com>
To: Tero Kristo <t-kristo@ti.com>,
"J.D. Schroeder" <Linux.HWI@garmin.com>,
Tony Lindgren <tony@atomide.com>
Cc: linux-kernel@vger.kernel.org, bcousson@baylibre.com,
robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
linux@arm.linux.org.uk, linux-omap@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
jay.schroeder@garmin.com,
Matthijs van Duin <matthijsvanduin@gmail.com>
Subject: Re: [PATCH v2 2/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency
Date: Tue, 3 May 2016 18:17:38 -0500 [thread overview]
Message-ID: <57293192.7060802@ti.com> (raw)
In-Reply-To: <5728E936.2010503@ti.com>
On 05/03/2016 01:08 PM, Tero Kristo wrote:
> On 03/05/16 20:49, J.D. Schroeder wrote:
>> On 05/03/2016 12:32 PM, Tero Kristo wrote:
>>> Personally I would not recommend using this clock for any timing sensitive
>>> applications. May I ask why you are interested in the exact clock rate of this
>>> clock anyway?
>>
>> I'm not interested in using this clock and I'm not sure how anyone would use
>> this clock outside of the processor. See the inline comment that is part of
>> the change and the commit message for the change. There is no hint in my
>> change that this is an exact clock rate. It is a clarifying change to help
>> others avoid using this clock as a 32 kHz clock (which the current clock name
>> and frequency imply) and it more accurately represents the actual hardware
>> behavior.
>>
>
> Imo, if you want to clarify things up, the whole secure_32k_ck should be
> removed from linux kernel.
This is actually the RC oscillator clock[1] which also happens to
source the secure_32k_clk. Jay is right that this is not an accurate
32k clock, however the actual range of this internal clock source is
pretty wide (I am trying to get that information into public domain
TRM - but that will take some time - since this patch just started the
internal thread on the topic). since it is infact an accurate clock
source from inside the SoC, how do we model that (a clock with a
frequency range with nominal frequency expected to be around 32k - but
not exactly 32k?). I think having a rename makes sense and modelling
it as an in-accurate clock source is probably the need.
[1] Search for "On-die 32K RC Osc" in http://www.ti.com/lit/pdf/spruhz6
--
Regards,
Nishanth Menon
WARNING: multiple messages have this Message-ID (diff)
From: nm@ti.com (Nishanth Menon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency
Date: Tue, 3 May 2016 18:17:38 -0500 [thread overview]
Message-ID: <57293192.7060802@ti.com> (raw)
In-Reply-To: <5728E936.2010503@ti.com>
On 05/03/2016 01:08 PM, Tero Kristo wrote:
> On 03/05/16 20:49, J.D. Schroeder wrote:
>> On 05/03/2016 12:32 PM, Tero Kristo wrote:
>>> Personally I would not recommend using this clock for any timing sensitive
>>> applications. May I ask why you are interested in the exact clock rate of this
>>> clock anyway?
>>
>> I'm not interested in using this clock and I'm not sure how anyone would use
>> this clock outside of the processor. See the inline comment that is part of
>> the change and the commit message for the change. There is no hint in my
>> change that this is an exact clock rate. It is a clarifying change to help
>> others avoid using this clock as a 32 kHz clock (which the current clock name
>> and frequency imply) and it more accurately represents the actual hardware
>> behavior.
>>
>
> Imo, if you want to clarify things up, the whole secure_32k_ck should be
> removed from linux kernel.
This is actually the RC oscillator clock[1] which also happens to
source the secure_32k_clk. Jay is right that this is not an accurate
32k clock, however the actual range of this internal clock source is
pretty wide (I am trying to get that information into public domain
TRM - but that will take some time - since this patch just started the
internal thread on the topic). since it is infact an accurate clock
source from inside the SoC, how do we model that (a clock with a
frequency range with nominal frequency expected to be around 32k - but
not exactly 32k?). I think having a rename makes sense and modelling
it as an in-accurate clock source is probably the need.
[1] Search for "On-die 32K RC Osc" in http://www.ti.com/lit/pdf/spruhz6
--
Regards,
Nishanth Menon
WARNING: multiple messages have this Message-ID (diff)
From: Nishanth Menon <nm@ti.com>
To: Tero Kristo <t-kristo@ti.com>,
"J.D. Schroeder" <Linux.HWI@garmin.com>,
Tony Lindgren <tony@atomide.com>
Cc: <linux-kernel@vger.kernel.org>, <bcousson@baylibre.com>,
<robh+dt@kernel.org>, <pawel.moll@arm.com>,
<mark.rutland@arm.com>, <ijc+devicetree@hellion.org.uk>,
<galak@codeaurora.org>, <linux@arm.linux.org.uk>,
<linux-omap@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<jay.schroeder@garmin.com>,
Matthijs van Duin <matthijsvanduin@gmail.com>
Subject: Re: [PATCH v2 2/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency
Date: Tue, 3 May 2016 18:17:38 -0500 [thread overview]
Message-ID: <57293192.7060802@ti.com> (raw)
In-Reply-To: <5728E936.2010503@ti.com>
On 05/03/2016 01:08 PM, Tero Kristo wrote:
> On 03/05/16 20:49, J.D. Schroeder wrote:
>> On 05/03/2016 12:32 PM, Tero Kristo wrote:
>>> Personally I would not recommend using this clock for any timing sensitive
>>> applications. May I ask why you are interested in the exact clock rate of this
>>> clock anyway?
>>
>> I'm not interested in using this clock and I'm not sure how anyone would use
>> this clock outside of the processor. See the inline comment that is part of
>> the change and the commit message for the change. There is no hint in my
>> change that this is an exact clock rate. It is a clarifying change to help
>> others avoid using this clock as a 32 kHz clock (which the current clock name
>> and frequency imply) and it more accurately represents the actual hardware
>> behavior.
>>
>
> Imo, if you want to clarify things up, the whole secure_32k_ck should be
> removed from linux kernel.
This is actually the RC oscillator clock[1] which also happens to
source the secure_32k_clk. Jay is right that this is not an accurate
32k clock, however the actual range of this internal clock source is
pretty wide (I am trying to get that information into public domain
TRM - but that will take some time - since this patch just started the
internal thread on the topic). since it is infact an accurate clock
source from inside the SoC, how do we model that (a clock with a
frequency range with nominal frequency expected to be around 32k - but
not exactly 32k?). I think having a rename makes sense and modelling
it as an in-accurate clock source is probably the need.
[1] Search for "On-die 32K RC Osc" in http://www.ti.com/lit/pdf/spruhz6
--
Regards,
Nishanth Menon
next prev parent reply other threads:[~2016-05-03 23:17 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-26 17:54 [PATCH 0/3] AM57/DRA7 Clock Tree DTSI Fix-ups J.D. Schroeder
2016-04-26 17:54 ` J.D. Schroeder
2016-04-26 17:54 ` J.D. Schroeder
2016-04-26 17:54 ` [PATCH 1/3] DRA7: Fix clock data for gmac_gmii_ref_clk_div J.D. Schroeder
2016-04-26 17:54 ` J.D. Schroeder
2016-04-26 17:54 ` J.D. Schroeder
2016-04-27 11:21 ` Tero Kristo
2016-04-27 11:21 ` Tero Kristo
2016-04-27 11:21 ` Tero Kristo
2016-04-27 16:36 ` Tony Lindgren
2016-04-27 16:36 ` Tony Lindgren
[not found] ` <20160427163640.GZ5995-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2016-04-27 17:16 ` Tony Lindgren
2016-04-27 17:16 ` Tony Lindgren
2016-04-27 17:16 ` Tony Lindgren
2016-05-02 17:12 ` [PATCH v2 0/3] AM57/DRA7 Clock Tree DTSI Fix-ups J.D. Schroeder
2016-05-02 17:12 ` J.D. Schroeder
2016-05-02 17:12 ` J.D. Schroeder
2016-05-02 17:12 ` [PATCH v2 1/3] DRA7: Fix clock data for gmac_gmii_ref_clk_div J.D. Schroeder
2016-05-02 17:12 ` J.D. Schroeder
2016-05-02 17:12 ` J.D. Schroeder
2016-05-02 17:12 ` [PATCH v2 2/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency J.D. Schroeder
2016-05-02 17:12 ` J.D. Schroeder
2016-05-02 17:12 ` J.D. Schroeder
2016-05-03 8:16 ` Tero Kristo
2016-05-03 8:16 ` Tero Kristo
2016-05-03 8:16 ` Tero Kristo
2016-05-03 13:31 ` J.D. Schroeder
2016-05-03 13:31 ` J.D. Schroeder
2016-05-03 13:31 ` J.D. Schroeder
2016-05-03 16:43 ` Tony Lindgren
2016-05-03 16:43 ` Tony Lindgren
[not found] ` <20160503164323.GN5995-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2016-05-03 17:32 ` Tero Kristo
2016-05-03 17:32 ` Tero Kristo
2016-05-03 17:32 ` Tero Kristo
[not found] ` <5728E0BC.3080509-l0cyMroinI0@public.gmane.org>
2016-05-03 17:49 ` J.D. Schroeder
2016-05-03 17:49 ` J.D. Schroeder
2016-05-03 17:49 ` J.D. Schroeder
[not found] ` <5728E495.4010502-UF6BFNFdnjXQT0dZR+AlfA@public.gmane.org>
2016-05-03 18:08 ` Tony Lindgren
2016-05-03 18:08 ` Tony Lindgren
2016-05-03 18:08 ` Tony Lindgren
2016-05-03 18:08 ` Tero Kristo
2016-05-03 18:08 ` Tero Kristo
2016-05-03 18:08 ` Tero Kristo
2016-05-03 23:17 ` Nishanth Menon [this message]
2016-05-03 23:17 ` Nishanth Menon
2016-05-03 23:17 ` Nishanth Menon
2016-05-04 14:09 ` Matthijs van Duin
2016-05-04 14:09 ` Matthijs van Duin
2016-05-04 14:09 ` Matthijs van Duin
[not found] ` <1462209123-7332-1-git-send-email-Linux.HWI-UF6BFNFdnjXQT0dZR+AlfA@public.gmane.org>
2016-05-02 17:12 ` [PATCH v2 3/3] ARM: dts: dra7: fix clock node definition to avoid build warning J.D. Schroeder
2016-05-02 17:12 ` J.D. Schroeder
2016-05-02 17:12 ` J.D. Schroeder
2016-05-03 4:20 ` [PATCH v2 0/3] AM57/DRA7 Clock Tree DTSI Fix-ups Lokesh Vutla
2016-05-03 4:20 ` Lokesh Vutla
2016-05-03 4:20 ` Lokesh Vutla
2016-04-26 17:54 ` [PATCH 2/3] ARM: DRA7x: dts: Fix the 32kHz clock calculation J.D. Schroeder
2016-04-26 17:54 ` J.D. Schroeder
2016-04-26 17:54 ` J.D. Schroeder
2016-04-27 11:40 ` Tero Kristo
2016-04-27 11:40 ` Tero Kristo
2016-04-27 11:40 ` Tero Kristo
[not found] ` <5720A51E.2000900-l0cyMroinI0@public.gmane.org>
2016-04-27 14:06 ` J.D. Schroeder
2016-04-27 14:06 ` J.D. Schroeder
2016-04-27 14:06 ` J.D. Schroeder
[not found] ` <5720C77A.3020708-UF6BFNFdnjXQT0dZR+AlfA@public.gmane.org>
2016-04-27 19:47 ` Tero Kristo
2016-04-27 19:47 ` Tero Kristo
2016-04-27 19:47 ` Tero Kristo
2016-04-27 20:13 ` J.D. Schroeder
2016-04-27 20:13 ` J.D. Schroeder
2016-04-27 20:13 ` J.D. Schroeder
2016-04-26 17:54 ` [PATCH 3/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency J.D. Schroeder
2016-04-26 17:54 ` J.D. Schroeder
2016-04-26 17:54 ` J.D. Schroeder
2016-04-27 11:49 ` Tero Kristo
2016-04-27 11:49 ` Tero Kristo
2016-04-27 11:49 ` Tero Kristo
[not found] ` <5720A73B.6050408-l0cyMroinI0@public.gmane.org>
2016-04-27 14:20 ` J.D. Schroeder
2016-04-27 14:20 ` J.D. Schroeder
2016-04-27 14:20 ` J.D. Schroeder
[not found] ` <1461693269-19436-1-git-send-email-Linux.HWI-UF6BFNFdnjXQT0dZR+AlfA@public.gmane.org>
2016-04-26 18:13 ` [PATCH 0/3] AM57/DRA7 Clock Tree DTSI Fix-ups Tony Lindgren
2016-04-26 18:13 ` Tony Lindgren
2016-04-26 18:13 ` Tony Lindgren
2016-04-26 19:18 ` J.D. Schroeder
2016-04-26 19:18 ` J.D. Schroeder
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=57293192.7060802@ti.com \
--to=nm@ti.com \
--cc=Linux.HWI@garmin.com \
--cc=bcousson@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=jay.schroeder@garmin.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=matthijsvanduin@gmail.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=t-kristo@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.