lkml.org 
[lkml]   [2015]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] powercap / RAPL : remove dependency on iosf_mbi
From
Date
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]
\
 
 \ /
  Last update: 2015-09-22 19:21    [W:0.164 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site