Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4214 bytes --]

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]
>



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]