[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56015AA0.1020104@gmail.com>
Date: Tue, 22 Sep 2015 09:41:52 -0400
From: Austin S Hemmelgarn <ahferroin7@...il.com>
To: Jacob Pan <jacob.jun.pan@...ux.intel.com>,
Pengyu Ma <pengyu.ma@...driver.com>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
rafael.j.wysocki@...el.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi
On 2015-09-21 17:36, Jacob Pan wrote:
> On Mon, 21 Sep 2015 11:48:14 +0800
> Pengyu Ma <pengyu.ma@...driver.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@...ysocki.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@...ux.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.
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.
>
>> Pengyu
>>>>> Signed-off-by: Pengyu Ma <pengyu.ma@...driver.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@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Download attachment "smime.p7s" of type "application/pkcs7-signature" (3019 bytes)
Powered by blists - more mailing lists