On Tue, 22 Sep 2015 09:41:52 -0400I think so, select behaves inconsistently in my experience with stuff that can be built as a module though. It might also be necessary to ensure that if IOSF is built as a module, then RAPL has to be a module too (not sure if this is the case though).
Austin S Hemmelgarn <ahferroin7@xxxxxxxxx> wrote:
On 2015-09-21 17:36, Jacob Pan wrote:If you build a custom kernel for Core with RAPL, your kernel would still
On Mon, 21 Sep 2015 11:48:14 +0800So make RAPL select IOSF instead of depending on it, add something to
Pengyu Ma <pengyu.ma@xxxxxxxxxxxxx> wrote:
True for haswell/broadwell/skylake platforms. But if we want binary
On 09/18/2015 11:43 PM, Jacob Pan wrote:
On Fri, 18 Sep 2015 02:09:55 +0200As commit had exported iosf_mbi to let user use it.
"Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx> wrote:
On Thursday, September 17, 2015 03:31:41 PM Pengyu Ma wrote:Unlike Quark, I don't think we want to or do differentiate Atom
iosf_mbi is supported on Quark, Braswell, Baytrail and some Atom
SoC, but RAPL is not limited to these SoC, it supports almost
Intel CPUs. Remove this dependece to make RAPL support more
Intel CPUs.
Please select IOSF_MBI on Atom SoCs.
from other x86 at compile time. IOSF driver can be compiled as a
module also, therefore RAPL driver needs this explicit dependency
at compile time.
commit aa8e4f22ab7773352ba3895597189b8097f2c307
Author: David E. Box <david.e.box@xxxxxxxxxxxxxxx>
Date: Wed Aug 27 14:40:39 2014 -0700
x86/iosf: Add Kconfig prompt for IOSF_MBI selection
While selecting IOSF_MBI is preferred, it does mean carrying extra
code on non-SoC architectures.
We can NOT force user to build in iosf_mbi if they want use RAPL on
haswell/broadwell/skylake.
And RAPL can be compiled and worked well on
haswell/broadwell/skylake without IOSF_MBI.
RAPL is really NOT depended on IOSF_MBI.
compatibility for Atom and Core, I can' see how simply removing the
dependency would work, unless we have runtime detection of IOSF.
the RAPL help text saying that IOSF is needed for it to work on
SoC's, and make IOSF=y in the defconfig.
This way, people who just turn on RAPL support should get IOSF,
whereas people like me who actually build custom kernels for each
system we own aren't forced to include yet more code that is 100%
useless for us.
"select" IOSF which is not needed. right?
It's also worth noting that most of the people who care about binarytrue. no issue for that case.
compatibility for a wide variety of chips in one kernel (read as
'distro maintainers') will be turning IOSF on anyway, because it's
needed for other things on chips that have it to work right as well.
Pengyu
[Jacob Pan]Signed-off-by: Pengyu Ma <pengyu.ma@xxxxxxxxxxxxx>Jacob?
---
drivers/powercap/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/powercap/Kconfig b/drivers/powercap/Kconfig
index 85727ef..a7c81b5 100644
--- a/drivers/powercap/Kconfig
+++ b/drivers/powercap/Kconfig
@@ -17,7 +17,7 @@ if POWERCAP
# Client driver configurations go here.
config INTEL_RAPL
tristate "Intel RAPL Support"
- depends on X86 && IOSF_MBI
+ depends on X86
default n
---help---
This enables support for the Intel Running Average
Power Limit (RAPL)
[Jacob Pan]
--
To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Jacob Pan]
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature