Messages in this thread | | | Subject | Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi | From | Austin S Hemmelgarn <> | Date | Tue, 22 Sep 2015 13:00:52 -0400 |
| |
On 2015-09-22 11:57, Jacob Pan wrote: > On Tue, 22 Sep 2015 09:41:52 -0400 > Austin S Hemmelgarn <ahferroin7@gmail.com> wrote: > >> On 2015-09-21 17:36, Jacob Pan wrote: >>> On Mon, 21 Sep 2015 11:48:14 +0800 >>> Pengyu Ma <pengyu.ma@windriver.com> wrote: >>> >>>> >>>> >>>> On 09/18/2015 11:43 PM, Jacob Pan wrote: >>>>> On Fri, 18 Sep 2015 02:09:55 +0200 >>>>> "Rafael J. Wysocki" <rjw@rjwysocki.net> wrote: >>>>> >>>>>> On Thursday, September 17, 2015 03:31:41 PM Pengyu Ma wrote: >>>>>>> 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. >>>>>>> >>>>> Unlike Quark, I don't think we want to or do differentiate Atom >>>>> 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. >>>> As commit had exported iosf_mbi to let user use it. >>>> >>>> commit aa8e4f22ab7773352ba3895597189b8097f2c307 >>>> Author: David E. Box <david.e.box@linux.intel.com> >>>> 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. >>>> >>> True for haswell/broadwell/skylake platforms. But if we want binary >>> compatibility for Atom and Core, I can' see how simply removing the >>> dependency would work, unless we have runtime detection of IOSF. >> So make RAPL select IOSF instead of depending on it, add something to >> 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. >> > If you build a custom kernel for Core with RAPL, your kernel would still > "select" IOSF which is not needed. right? I 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). >> It's also worth noting that most of the people who care about binary >> 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. >> > true. no issue for that case. >>>> Pengyu >>>>>>> Signed-off-by: Pengyu Ma <pengyu.ma@windriver.com> >>>>>> 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] >>>> >>> >>> [Jacob Pan] >>> -- >>> To unsubscribe from this list: send the line "unsubscribe >>> linux-kernel" in the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> Please read the FAQ at http://www.tux.org/lkml/ >>> >> >> > > [Jacob Pan] >
[unhandled content-type:application/pkcs7-signature] | |