Re: [PATCH V3] cpufreq: qoriq: Register cooling device based on device tree

2 messages, 2 authors, 2016-02-27 · open the first message on its own page

Re: [PATCH V3] cpufreq: qoriq: Register cooling device based on device tree

From: Li Yang <hidden>
Date: 2016-02-27 00:04:17

On Fri, Feb 26, 2016 at 5:31 PM, Li Yang [off-list ref] wrote:
quoted hunk
On Fri, Feb 26, 2016 at 5:16 PM, Arnd Bergmann [off-list ref] wrote:
quoted
On Friday 26 February 2016 17:07:09 Li Yang wrote:
quoted
I don't have a perfect solution either.  But I think this is still
better than making cpufreq not usable.  The cpufreq driver will print
out an error message if thermal is not reachable.  Maybe this can
relief the confusion a little bit?
With my patch, the configuration will just force the cpufreq
driver to be a loadable module as well if thermal is a module,
so the dependency can be resolved by loading the thermal module first.
It would be perfect if this it true.  But I tried with the following
change, it just makes QORIQ_CPUFREQ non-selectable if THERMAL=m.
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index dcb972a38fbc..ca05037dd565 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -297,6 +297,7 @@ endif
 config QORIQ_CPUFREQ
        tristate "CPU frequency scaling driver for Freescale QorIQ SoCs"
        depends on OF && COMMON_CLK && (PPC_E500MC || ARM)
+       depends on !CPU_THERMAL || THERMAL=y
        select CLK_QORIQ
        help
          This adds the CPUFreq driver support for Freescale QorIQ SoCs

I find we can achieve your desired result with the following change instead:

+       depends on (THERMAL=m && m) || THERMAL=y || THERMAL=n

Regards,
Leo

Re: [PATCH V3] cpufreq: qoriq: Register cooling device based on device tree

From: Scott Wood <oss@buserror.net>
Date: 2016-02-27 00:08:24

On Fri, 2016-02-26 at 18:04 -0600, Li Yang wrote:
On Fri, Feb 26, 2016 at 5:31 PM, Li Yang [off-list ref] wrote:
quoted
On Fri, Feb 26, 2016 at 5:16 PM, Arnd Bergmann [off-list ref] wrote:
quoted
On Friday 26 February 2016 17:07:09 Li Yang wrote:
quoted
I don't have a perfect solution either.  But I think this is still
better than making cpufreq not usable.  The cpufreq driver will print
out an error message if thermal is not reachable.  Maybe this can
relief the confusion a little bit?
With my patch, the configuration will just force the cpufreq
driver to be a loadable module as well if thermal is a module,
so the dependency can be resolved by loading the thermal module first.
It would be perfect if this it true.  But I tried with the following
change, it just makes QORIQ_CPUFREQ non-selectable if THERMAL=m.
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index dcb972a38fbc..ca05037dd565 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -297,6 +297,7 @@ endif
 config QORIQ_CPUFREQ
        tristate "CPU frequency scaling driver for Freescale QorIQ SoCs"
        depends on OF && COMMON_CLK && (PPC_E500MC || ARM)
+       depends on !CPU_THERMAL || THERMAL=y
        select CLK_QORIQ
        help
          This adds the CPUFreq driver support for Freescale QorIQ SoCs

I find we can achieve your desired result with the following change instead:

+       depends on (THERMAL=m && m) || THERMAL=y || THERMAL=n
"depends on THERMAL || !THERMAL" should also work.

-Scott
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help