On Tue, 22 Sep 2015 09:41:52 -0400 Austin S Hemmelgarn <ahferro...@gmail.com> wrote:
> On 2015-09-21 17:36, Jacob Pan wrote: > > On Mon, 21 Sep 2015 11:48:14 +0800 > > Pengyu Ma <pengyu...@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" <r...@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....@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? > 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...@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 majord...@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] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
