From: Paul Walmsley <paul@pwsan.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: "Woodruff, Richard" <r-woodruff2@ti.com>,
"linux-arm-kernel@lists.arm.linux.org.uk"
<linux-arm-kernel@lists.arm.linux.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH E 08/14] OMAP clock: move rate recalc, propagation code up to plat-omap/clock.c
Date: Tue, 3 Feb 2009 01:42:03 -0700 (MST) [thread overview]
Message-ID: <alpine.DEB.2.00.0902030133040.29513@utopia.booyaka.com> (raw)
In-Reply-To: <20090131114014.GD1394@n2100.arm.linux.org.uk>
Hello Russell,
On Sat, 31 Jan 2009, Russell King - ARM Linux wrote:
> On Fri, Jan 30, 2009 at 08:23:49AM -0600, Woodruff, Richard wrote:
> >
> > > There's one bug that your version highlights in mine - the virtual mpu
> > > clock in omap1 touches the DPLL and repropagates that rate. I've
> > > removed that repropagation, so that needs fixing.
> > >
> > > However, this raises a question: why is the virtual mpu clock touching
> > > some other part of the clock tree. I wonder whether this should be
> > > handled a different way, though the first thing that needs answering is
> > > why we have this alias for 'arm_ck' ?
> >
> > At one point in time the virtual clock allowed control for a set of clocks
> > with some dependencies. The mpu alias provided a convenient control point.
>
> >From what I can see (checking both mainline and Tony's tree), this mpu
> alias (virtual_ck_mpu) is not used on OMAP1, which seems to suggest
> that this quirk has become redundant. If it is redundant, it should
> be removed.
>
> If there is some code somewhere to use it, this quirk should live with
> the user of the quirk until such time that the user becomes ready to be
> merged.
I don't think there's any reason for virtual_ck_mpu or virt_prcm_set to
have a parent clock listed.
At some point this year, those virtual OPP clocks will be removed from the
clock tree and implemented in a different manner.
If you like, I will send a patch for removal of virtual_ck_mpu from OMAP1,
although my suspicion is that OMAP1 is just missing a CPUFreq driver to
use that OPP clock.
- Paul
next prev parent reply other threads:[~2009-02-03 8:42 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-28 19:27 [PATCH E 00/14] OMAP clock, E of F: SDRAM fixes, clock optimization Paul Walmsley
2009-01-28 19:27 ` [PATCH E 01/14] OMAP2 SDRC: move mach-omap2/memory.h into include/asm-arm/arch-omap/sdrc.h Paul Walmsley
2009-01-28 19:27 ` [PATCH E 02/14] OMAP2 SDRC: rename memory.c to sdrc2xxx.c Paul Walmsley
2009-01-28 19:27 ` [PATCH E 03/14] OMAP2 SDRC: separate common OMAP2/3 code from OMAP2xxx code Paul Walmsley
2009-01-28 19:27 ` [PATCH E 04/14] OMAP2 SDRC: add SDRAM timing parameter infrastructure Paul Walmsley
2009-01-28 19:27 ` [PATCH E 05/14] OMAP3 clock: add omap3_core_dpll_m2_set_rate() Paul Walmsley
2009-01-28 19:27 ` [PATCH E 06/14] PM: OMAP3: Make sure clk_disable_unused() order is correct Paul Walmsley
2009-01-28 19:27 ` [PATCH E 07/14] OMAP2/3 clock: use standard set_rate fn in omap2_clk_arch_init() Paul Walmsley
2009-01-28 19:27 ` [PATCH E 08/14] OMAP clock: move rate recalc, propagation code up to plat-omap/clock.c Paul Walmsley
2009-01-29 17:41 ` Russell King - ARM Linux
2009-01-30 8:42 ` Paul Walmsley
2009-01-30 8:52 ` Russell King - ARM Linux
2009-01-30 14:23 ` Woodruff, Richard
2009-01-31 11:40 ` Russell King - ARM Linux
2009-02-03 8:42 ` Paul Walmsley [this message]
2009-02-03 9:45 ` Paul Walmsley
2009-02-02 7:13 ` Paul Walmsley
2009-02-03 13:18 ` Russell King - ARM Linux
2009-01-28 19:27 ` [PATCH E 09/14] OMAP2/3 clock: drop recalc function pointers from fixed rate clocks Paul Walmsley
2009-01-28 19:27 ` [PATCH E 10/14] OMAP clock: support "dry run" rate and parent changes Paul Walmsley
2009-02-08 13:17 ` Russell King - ARM Linux
2009-02-08 19:48 ` David Brownell
2009-02-11 7:53 ` Paul Walmsley
2009-02-08 15:53 ` Russell King - ARM Linux
2009-02-11 8:18 ` Paul Walmsley
2009-01-28 19:27 ` [PATCH E 11/14] OMAP clock: track child clocks Paul Walmsley
2009-01-29 15:14 ` Russell King - ARM Linux
2009-01-29 22:06 ` Russell King - ARM Linux
2009-01-30 8:35 ` Paul Walmsley
2009-02-02 4:57 ` Paul Walmsley
2009-02-09 14:11 ` Russell King - ARM Linux
2009-02-13 7:01 ` Paul Walmsley
2009-02-14 11:23 ` Russell King - ARM Linux
2009-02-14 11:36 ` Russell King - ARM Linux
2009-02-25 9:45 ` Paul Walmsley
2009-02-19 12:19 ` Russell King - ARM Linux
2009-02-20 0:50 ` Woodruff, Richard
2009-02-23 16:03 ` Russell King - ARM Linux
2009-02-24 12:35 ` Woodruff, Richard
2009-03-02 23:02 ` Paul Walmsley
2009-03-03 16:45 ` Russell King - ARM Linux
2009-02-22 23:37 ` Paul Walmsley
2009-02-24 9:43 ` Russell King - ARM Linux
2009-01-29 19:52 ` Russell King - ARM Linux
2009-02-02 7:57 ` Paul Walmsley
2009-01-28 19:28 ` [PATCH E 12/14] OMAP clock: unnecessary clock flag removal fiesta Paul Walmsley
2009-02-23 15:50 ` Russell King - ARM Linux
2009-03-02 22:35 ` Paul Walmsley
2009-01-28 19:28 ` [PATCH E 13/14] OMAP2/3 clock: remove clk->owner Paul Walmsley
2009-01-28 19:28 ` [PATCH E 14/14] OMAP clock: rearrange clock.h structure order 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=alpine.DEB.2.00.0902030133040.29513@utopia.booyaka.com \
--to=paul@pwsan.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=r-woodruff2@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).