| Message ID | 1358174788-24439-2-git-send-email-mika.westerberg@linux.intel.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
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? Rafael > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> > --- > arch/x86/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 79795af..decda04 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -114,6 +114,7 @@ config X86 > select MODULES_USE_ELF_RELA if X86_64 > select CLONE_BACKWARDS if X86_32 > select GENERIC_SIGALTSTACK > + select COMMON_CLK > > config INSTRUCTION_DECODER > def_bool y >
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. 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@st.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. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@st.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
On Wed, Jan 16, 2013 at 04:01:20PM +0100, Rafael J. Wysocki wrote: > 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? There are few. I tried how many I get on my config and there were 9 new questions with 'make oldconfig'. Grepping (if I did it correctly) reveals: % git grep 'depends .*HAVE_CLK' -- '*/Kconfig' | wc -l 27 > 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. If a driver depends only on HAVE_CLK and doesn't work everywhere, there is a problem in that particular driver and its Kconfig options (some dependencies are missing). These drivers should be fixed. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday, January 16, 2013 05:28:07 PM Mika Westerberg wrote: > On Wed, Jan 16, 2013 at 04:01:20PM +0100, Rafael J. Wysocki wrote: > > 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? > > There are few. I tried how many I get on my config and there were 9 new > questions with 'make oldconfig'. > > Grepping (if I did it correctly) reveals: > > % git grep 'depends .*HAVE_CLK' -- '*/Kconfig' | wc -l > 27 > > > 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. > > If a driver depends only on HAVE_CLK and doesn't work everywhere, there is > a problem in that particular driver and its Kconfig options (some > dependencies are missing). These drivers should be fixed. Well, on a second thought it might be better to add a new Kconfig option for x86, say CONFIG_INTEL_LPSS ("Intel LPSS Support") that will select COMMON_CLK and depend on ACPI. This way we'll only compile the clocks stuff when explicitly requested (although distros will probably set that to 'y' anyway). Thanks, Rafael
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 79795af..decda04 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -114,6 +114,7 @@ config X86 select MODULES_USE_ELF_RELA if X86_64 select CLONE_BACKWARDS if X86_32 select GENERIC_SIGALTSTACK + select COMMON_CLK config INSTRUCTION_DECODER def_bool y
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. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> --- arch/x86/Kconfig | 1 + 1 file changed, 1 insertion(+)