Date:	Wed, 16 Jan 2013 16:01:20 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	"H. Peter Anvin" <hpa@...or.com>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
	Len Brown <lenb@...nel.org>,
	Mike Turquette <mturquette@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	linux-acpi@...r.kernel.org
Subject: Re: [PATCH 1/3] x86: enable common clk on x86

On Wednesday, January 16, 2013 07:20:54 AM Mika Westerberg wrote:
> On Wed, Jan 16, 2013 at 12:59:17AM +0100, Rafael J. Wysocki wrote:
> > On Monday, January 14, 2013 04:46:26 PM Mika Westerberg wrote:
> > > We are starting to see traditional SoC peripherals also in the x86 world,
> > > things like UART, I2C and SPI controllers that might already have a working
> > > device driver. These drivers typically take advantage of the Linux clk
> > > framework to control and retrieve information about the peripheral clock.
> > > 
> > > There hasn't been a standard way on x86 to pass the clock rate from
> > > whatever configuration system is used to the driver, but instead different
> > > variations have emerged, like adding this information to the platform data.
> > > 
> > > In order to use the standard Linux way we enable the common clk subsystem
> > > also on x86. This allows us to re-use the drivers with little or no
> > > modification wrt. clock API usage.
> > > 
> > > This patch was originally proposed by Mark Brown.
> > 
> > Are there any side effects of selecting COMMON_CLK by an arch and if so then
> > what are they?
> 
> Selecting COMMON_CLK also selects HAVE_CLK, so drivers that are dependent
> on that option become available when you run make config.

Well, that's not very nice.  Do you know how many of them there are?

Distros often build all drivers available regardless of whether or not they
are going to be used and it would be kind of wasteful for them to build drivers
that aren't even going to work.

> It also makes clk_get() and friends to return errors if the clock is not
> found (instead of returning NULL as in case with !HAVE_CLK). This means
> that if there is a driver that counted on the stubbed out clocks on x86 it
> will fail to get the clock after this patch. However, the patch that adds
> the stub functions was merged only lately:
> 
> 	commit 93abe8e4b13ae9a0428ce940a8a03ac72a7626f1
> 	Author: Viresh Kumar <viresh.kumar@...com>
> 	Date:   Mon Jul 30 14:39:27 2012 -0700
> 
> 	    clk: add non CONFIG_HAVE_CLK routines
> 	    
> 	    Many drivers are shared between architectures that may or may not have
> 	    HAVE_CLK selected for them.  To remove compilation errors for them we
> 	    enclose clk_*() calls in these drivers within #ifdef CONFIG_HAVE_CLK,
> 	    #endif.
> 	    
> 	    This patch removes the need of these CONFIG_HAVE_CLK statements, by
> 	    introducing dummy routines when HAVE_CLK is not selected by platforms.
> 	    So, definition of these routines will always be available.  These calls
> 	    will return error for platforms that don't select HAVE_CLK.
> --

That should be fine, then.

Peter, what do you think?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists