From: Ranjith Lohithakshan <ranjithl@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: "Alexander Shishkin" <virtuoso@slind.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Jouni Högander" <jouni.hogander@nokia.com>
Subject: Re: [PATCH 12/18] OMAP3 clock: split out DPLL3 M2 divider functions into clkt3xxx_dpll3m2.c
Date: Wed, 20 Jan 2010 19:26:46 +0530 [thread overview]
Message-ID: <4B570B9E.9060104@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1001191128120.3977@utopia.booyaka.com>
Paul,
On Wed, 20-Jan-10 12:06 AM +0530, Paul Walmsley wrote:
> (cc'ing Ranjith)
>
> Hi Alexander,
>
> On Fri, 15 Jan 2010, Alexander Shishkin wrote:
>
>> On Fri, Jan 15, 2010 at 02:07:04 -0700, Paul Walmsley wrote:
>>> Split the DPLL3 M2 divider clock functions out of clock34xx.c and move them
>>> into clkt3xxx_dpll3m2.c to improve maintainability.
>> I'm not very familiar with maintainability issues of dpll3m2, so
>> forgive me if it is ignorant for me to ask you to elaborate on this.
>
> That is a very good point, those original patch changelogs are pretty
> crappy. "OMAP clock code - same great taste, now with more
> maintainability!" I will update them and repost with more detail.
>
>> It does look like a bit of an overkill to have a separate file for
>> a divider. But again, I might well be missing the point.
>
> Yep, this is definitely a borderline case where it might be more
> appropriate to keep it in the clock34xx.c file. What ultimately motivated
> splitting it out was the thought that the AM3517/3505 chips probably won't
> need this function, since I don't believe they support DVFS [1], so we
> could skip compiling this function for kernels built for those devices via
> the Makefile, and not need #ifdefs.
>
> Ranjith, could you correct me if I am wrong about the DVFS part?
You are right, AM35xx devices do not support DVFS. In fact, the only
power management support planned is for the suspend/resume capability
with retention (no off mode)
>
> 1. AM35x ARM Microprocessor Technical Reference Manual,
> http://www.ti.com/litv/pdf/sprugr0
- Ranjith
WARNING: multiple messages have this Message-ID (diff)
From: ranjithl@ti.com (Ranjith Lohithakshan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 12/18] OMAP3 clock: split out DPLL3 M2 divider functions into clkt3xxx_dpll3m2.c
Date: Wed, 20 Jan 2010 19:26:46 +0530 [thread overview]
Message-ID: <4B570B9E.9060104@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1001191128120.3977@utopia.booyaka.com>
Paul,
On Wed, 20-Jan-10 12:06 AM +0530, Paul Walmsley wrote:
> (cc'ing Ranjith)
>
> Hi Alexander,
>
> On Fri, 15 Jan 2010, Alexander Shishkin wrote:
>
>> On Fri, Jan 15, 2010 at 02:07:04 -0700, Paul Walmsley wrote:
>>> Split the DPLL3 M2 divider clock functions out of clock34xx.c and move them
>>> into clkt3xxx_dpll3m2.c to improve maintainability.
>> I'm not very familiar with maintainability issues of dpll3m2, so
>> forgive me if it is ignorant for me to ask you to elaborate on this.
>
> That is a very good point, those original patch changelogs are pretty
> crappy. "OMAP clock code - same great taste, now with more
> maintainability!" I will update them and repost with more detail.
>
>> It does look like a bit of an overkill to have a separate file for
>> a divider. But again, I might well be missing the point.
>
> Yep, this is definitely a borderline case where it might be more
> appropriate to keep it in the clock34xx.c file. What ultimately motivated
> splitting it out was the thought that the AM3517/3505 chips probably won't
> need this function, since I don't believe they support DVFS [1], so we
> could skip compiling this function for kernels built for those devices via
> the Makefile, and not need #ifdefs.
>
> Ranjith, could you correct me if I am wrong about the DVFS part?
You are right, AM35xx devices do not support DVFS. In fact, the only
power management support planned is for the suspend/resume capability
with retention (no off mode)
>
> 1. AM35x ARM Microprocessor Technical Reference Manual,
> http://www.ti.com/litv/pdf/sprugr0
- Ranjith
next prev parent reply other threads:[~2010-01-20 13:57 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-15 9:06 [PATCH 00/18] OMAP2/3/4 clock: split out code for clock types and clean up Paul Walmsley
2010-01-15 9:06 ` Paul Walmsley
2010-01-15 9:06 ` [PATCH 01/18] OMAP3 clock: move OMAP3-specific DPLL functions to dpll3xxx.c Paul Walmsley
2010-01-15 9:06 ` Paul Walmsley
2010-01-15 9:06 ` [PATCH 02/18] OMAP2/3/4 clock: move DPLL clock functions into clkt_dpll.c Paul Walmsley
2010-01-15 9:06 ` Paul Walmsley
2010-01-15 9:06 ` [PATCH 03/18] OMAP2/3/4 clock: move clksel clock functions into clkt_clksel.c Paul Walmsley
2010-01-15 9:06 ` Paul Walmsley
2010-01-15 9:06 ` [PATCH 04/18] OMAP2 clock: move all static functions to the top of the file Paul Walmsley
2010-01-15 9:06 ` Paul Walmsley
2010-01-15 9:06 ` [PATCH 05/18] OMAP2/3/4 clock: combine all omap2_clk_functions Paul Walmsley
2010-01-15 9:06 ` Paul Walmsley
2010-01-15 9:06 ` [PATCH 06/18] OMAP2xxx clock: move the DPLL+CORE composite clock code into clkt2xxx_dpllcore.c Paul Walmsley
2010-01-15 9:06 ` Paul Walmsley
2010-01-15 9:06 ` [PATCH 07/18] OMAP2xxx clock: move the DVFS virtual clock code into clkt2xxx_virt_prcm_set.c Paul Walmsley
2010-01-15 9:06 ` Paul Walmsley
2010-01-15 9:07 ` [PATCH 08/18] OMAP2xxx clock: move the APLL clock code into clkt2xxx_apll.c Paul Walmsley
2010-01-15 9:07 ` Paul Walmsley
2010-01-15 9:07 ` [PATCH 09/18] OMAP2xxx clock: move osc_clk code into clkt2xxx_osc.c Paul Walmsley
2010-01-15 9:07 ` Paul Walmsley
2010-01-15 9:07 ` [PATCH 10/18] OMAP2xxx clock: move sys_clk code into clkt2xxx_sys.c Paul Walmsley
2010-01-15 9:07 ` Paul Walmsley
2010-01-15 9:07 ` [PATCH 11/18] OMAP2 clock: don't compile OMAP2430-only functions on non-2430 builds Paul Walmsley
2010-01-15 9:07 ` Paul Walmsley
2010-01-15 9:07 ` [PATCH 12/18] OMAP3 clock: split out DPLL3 M2 divider functions into clkt3xxx_dpll3m2.c Paul Walmsley
2010-01-15 9:07 ` Paul Walmsley
2010-01-15 12:50 ` Alexander Shishkin
2010-01-19 18:36 ` Paul Walmsley
2010-01-19 18:36 ` Paul Walmsley
2010-01-20 13:56 ` Ranjith Lohithakshan [this message]
2010-01-20 13:56 ` Ranjith Lohithakshan
2010-01-15 9:07 ` [PATCH 13/18] OMAP2/3 clock: clean up omap*_clk_arch_init() Paul Walmsley
2010-01-15 9:07 ` Paul Walmsley
2010-01-15 9:07 ` [PATCH 14/18] OMAP2/3 clock: remove unnecessary includes and clean up header Paul Walmsley
2010-01-15 9:07 ` Paul Walmsley
2010-01-15 9:07 ` [PATCH 15/18] OMAP2/3/4 clock: omap2_clk_prepare_for_reboot() is OMAP2xxx-only Paul Walmsley
2010-01-15 9:07 ` Paul Walmsley
2010-01-15 9:07 ` [PATCH 16/18] OMAP3 DPLL: reorganize static functions Paul Walmsley
2010-01-15 9:07 ` Paul Walmsley
2010-01-15 9:07 ` [PATCH 17/18] OMAP clock: resolve all remaining sparse warnings Paul Walmsley
2010-01-15 9:07 ` Paul Walmsley
2010-01-15 9:07 ` [PATCH 18/18] OMAP2/3/4 clock: rename and clean the omap2_clk_init() functions Paul Walmsley
2010-01-15 9:07 ` Paul Walmsley
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=4B570B9E.9060104@ti.com \
--to=ranjithl@ti.com \
--cc=jouni.hogander@nokia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=virtuoso@slind.org \
/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.