From: Tony Lindgren <tony@atomide.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
linux-omap@vger.kernel.org,
linux-arm-kernel@lists.arm.linux.org.uk,
linux-arm@vger.kernel.org
Subject: Re: [PATCH 04/13] OMAP2/3 clock: ensure each clock has a unique name
Date: Mon, 17 Aug 2009 13:24:37 +0300 [thread overview]
Message-ID: <20090817102436.GP7278@atomide.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0908170339380.7023@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [090817 13:06]:
> Hello Russell,
>
> On Mon, 17 Aug 2009, Russell King - ARM Linux wrote:
>
> > On Mon, Aug 17, 2009 at 03:14:45AM -0600, Paul Walmsley wrote:
> > > What it does remove is the need for internal core code to fake up a struct
> > > device simply to access a clock. It also allows us to harmonize the
> > > clock names, used internally in core code, with the hardware reality,
> > > which uses unique names to identify clocks.
> >
> > That problem is already solved. clk_get_sys()
>
> That solves the first problem, but not the second. Is there some reason
> that OMAP core code (aside from the clkdev mapping structures in
> mach-omap2/clock*.c) should know, or care, whether a platform device name
> is bound to that clock?
>
> On OMAP, we have uniquely-named clock lines in the technical
> documentation. It is possible that other platforms don't have this. But
> for us, I'd submit that it makes more sense for internal core code to
> fetch a clock documented as "MMC1_FCLK" with:
>
> c = omap_clk_get_by_name("mmc1_fck");
>
> rather than:
>
> c = clk_get_sys("mmci-omap-hs.0", "ick");
>
> (* ideally, of course, we'd use "mmc1_fclk" rather than "mmc1_fck", this
> is a legacy issue that has been left for a future patch.)
>
> As a side benefit, it also makes our clock debugfs setup easier, so a
> clock can be identified in the path as simply
> /debugfs/clock/.../mmc1_fck/, rather than something like
> /debugfs/clock/.../mmci-omap-hs.0-mmc1_fck/ or
> /debugfs/clock/.../mmci-omap-hs.0/mmc1_fck.
>
> Thoughts?
I guess if we wanted to do this in a generic way, we could have
clkdev_get_hw_name() in arch/arm/common/clkdev.c. Then we could
have struct omap_clk contain the hardware clock name.
But then we're wasting memory and duplicating parts of the names,
so I don't think that it would be any better solution compared to
renaming the clocks like you're doing.
Tony
next prev parent reply other threads:[~2009-08-17 10:24 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-15 11:18 [PATCH 00/13] OMAP PM, clock, and SDRC updates for the 2.6.32 merge window Paul Walmsley
2009-08-15 11:18 ` [PATCH 01/13] [PATCH] OMAP: powerdomain: Fix overflow when doing powerdomain deps lookups Paul Walmsley
2009-08-15 11:19 ` [PATCH 02/13] OMAP: SDRC: Add several new register definitions Paul Walmsley
2009-08-15 11:19 ` [PATCH 03/13] [PATCH] OMAP3 clock: Fixed processing of bootarg 'mpurate' Paul Walmsley
2009-08-15 11:19 ` [PATCH 04/13] OMAP2/3 clock: ensure each clock has a unique name Paul Walmsley
[not found] ` <20090815111944.7384.13541.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2009-08-17 8:47 ` Tony Lindgren
2009-08-17 9:14 ` Paul Walmsley
[not found] ` <alpine.DEB.2.00.0908170259250.18309-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
2009-08-17 9:29 ` Russell King - ARM Linux
2009-08-17 10:06 ` Paul Walmsley
2009-08-17 10:24 ` Tony Lindgren [this message]
[not found] ` <alpine.DEB.2.00.0908170339380.7023-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
2009-08-17 16:59 ` Russell King - ARM Linux
[not found] ` <20090817165913.GS10764-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2009-08-17 17:37 ` Paul Walmsley
2009-08-15 11:19 ` [PATCH 05/13] OMAP clock: add omap_clk_get_by_name() Paul Walmsley
2009-08-15 11:20 ` [PATCH 06/13] OMAP clock: associate MPU clocks with the mpu_clkdm Paul Walmsley
2009-08-15 11:20 ` [PATCH 07/13] OMAP3 clock: remove superfluous calls to omap2_init_clk_clkdm Paul Walmsley
2009-08-15 11:20 ` [PATCH 08/13] OMAP2/3 PM: create the OMAP PM interface and add a default OMAP PM no-op layer Paul Walmsley
2009-08-15 11:20 ` [PATCH 09/13] OMAP2/3/4 PRCM: add module IDLEST wait code Paul Walmsley
2009-08-15 11:20 ` [PATCH 10/13] OMAP2/3 board-*.c files: read bootloader configuration earlier Paul Walmsley
2009-08-15 11:20 ` [PATCH 11/13] OMAP2/3/4: create omap_hwmod layer Paul Walmsley
2009-08-15 11:20 ` [PATCH 12/13] OMAP: omap_hwmod: call omap_hwmod init at boot; create interconnects Paul Walmsley
2009-08-15 11:20 ` [PATCH 13/13] OMAP2/3/4 core: create omap_device layer 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=20090817102436.GP7278@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-arm@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=paul@pwsan.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.