[GUIDE] HWP(Intel Speed Shift) enable with full power management

[Drfrag]

syscl, are you shure that is it really needed to have pykeralpha's ssdtprgen ssdt to achieve the same results?

I am not using it and my system works just fine only with hwpenabler kext and a script to reload after sleep.

I don't have any data corruption and system is very stable anyway.

Maybe, patching frequency vectors is all that we need to have correct power management.

Looking into the picture you have posted, maximum cpu frequency achieved was about 3Ghz and it should be 3.2Ghz, isn't it?

[syscl]

i have had HWPEnable=True for awhile on my T460 skylake box (with a proper SSDT PR) so i just assumed this aspect was working!?

 

However, I was using MBP11,1 so may be not working or not 100%? 

 

... i will change to 13,1 and see what is different.

 

how is this HWP value determined and entered? 

tluck, you can use this to judge if your HWP is enable or not. Note: you need to remove this kext and rebuild kernel cache before you reboot, otherwise this kext will cause your system panic.

 

syscl

syscl, are you shure that is it really needed to have pykeralpha's ssdtprgen ssdt to achieve the same results?

I am not using it and my system works just fine only with hwpenabler kext and a script to reload after sleep.

I don't have any data corruption and system is very stable anyway.

Maybe, patching frequency vectors is all that we need to have correct power management.

Looking into the picture you have posted, maximum cpu frequency achieved was about 3Ghz and it should be 3.2Ghz, isn't it?

Hi @Drfrag, I am pretty sure we need. Actually, once I received my XPS 13 9350 in Nov. 2016, I soon found the HWP power management is incomplete. See the log from my maclog here:

2016-11-23 18:06:07.281075-0600  localhost kernel[0]: (IOPlatformPluginFamily) <IOPlatformPluginFamily`DebugPrint> WARNING: IOPlatformPluginUtil : getCPUIDInfo: this is an unknown CPU model 0x4e
  -- power management may be incomplete or unsupported

Due to the fact cpu power management was incomplete, AGPM(Apple Graphics Power Management) was not implemented either. Usually, laptop manufactures will protect MSR 0xE2(read only) which wmrsr64 would write value on it to cause kernel panic. If you are lucky enough to unlock MSR 0xE2 lock like Dell Precision M3800 or XPS 9530, then you may not need this kernel patch. 

 

BTW, a lot of people say that they have HWP enable, but they ignore whether their power management is fully implemented. A very simple/useful way is open System Preferences -> Energy Saver to see if there's 3 options in Battery and 5  4 options in Power Adapter. More accurate way you need to open ioreg to search AGPM and X86PlatformPlugin, use kextstat to list all cpu/gpu relate kexts. 

 

Tune frequency vectors is optional, only when you need more ideal situation then you can tune it to fit your CPU/GPU. I will post injector method latter(which @Sherlocks has proven worked well using my modified version of X86PlatformPlugin.kext like a dummy AppleHDA).

 

syscl

[slayer2333]

 

BTW, a lot of people say that they have HWP enable, but they ignore whether their power management is fully implemented. A very simple/useful way is open System Preferences -> Energy Saver to see if there's 3 options in Battery and 5 options in Power Adapter. More accurate way you need to open ioreg to search AGPM and X86PlatformPlugin, use kextstat to list all cpu/gpu relate kexts.

 

I have 3 options in battery and 4 in Power adapter (what is the 5th option supposed to be ? Maybe depends on the hardware ) ?

 

[syscl]

 

BTW, a lot of people say that they have HWP enable, but they ignore whether their power management is fully implemented. A very simple/useful way is open System Preferences -> Energy Saver to see if there's 3 options in Battery and 5 options in Power Adapter. More accurate way you need to open ioreg to search AGPM and X86PlatformPlugin, use kextstat to list all cpu/gpu relate kexts.

 

I have 3 options in battery and 4 in Power adapter (what is the 5th option supposed to be ? Maybe depends on the hardware ) ?

 

Screen Shot 2017-02-10 at 2.02.39 PM.png

Screen Shot 2017-02-10 at 2.02.44 PM.png

Screen Shot 2017-02-10 at 2.03.00 PM.png

 

Sorry, my typo, should be 4 options.

 

Thank you for remind, I corrected it.

 

syscl

[dpassmor]

Use Clover to active HWP, not the kext.

 

syscl

 

A couple of notes;

 

You no longer have to use Clover or HWPEnabler to enable HWP. If X86PlatformPlugin is loaded with a model identifier that supports HWP (MacBook9,1, MacBookPro13,x) the OS will enable HWP, and keep it enabled after sleep. Not only that, but the OS will dynamically manipulate the HWP request values depending on load and whether the system is on AC or battery.

 

Also, I don't believe it is necessary to use a full SSDT generated by ssdtPRGen, it should be sufficient to use one that just sets the plugin-type property on CPU0:

// inject plugin-type on CPU0 to enable GPU power management

DefinitionBlock ("ssdt_pr.aml", "SSDT", 1, "APPLE ", "CpuPm", 0x00006500)
{
    External (\_PR_.CPU0, DeviceObj)
    External (DTGP, MethodObj)
    
    Scope (\_PR_.CPU0)
    {
        Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
        {
            Debug = "Writing plugin-type to Registry!"
            Local0 = Package (0x02)
                {
                    "plugin-type", 
                    One
                }
            DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
            Return (Local0)
        }
    }
}

[PMheart]

 

A couple of notes;

 

You no longer have to use Clover or HWPEnabler to enable HWP. If X86PlatformPlugin is loaded with a model identifier that supports HWP (MacBook9,1, MacBookPro13,x) the OS will enable HWP, and keep it enabled after sleep. Not only that, but the OS will dynamically manipulate the HWP request values depending on load and whether the system is on AC or battery.

 

Also, I don't believe it is necessary to use a full SSDT generated by ssdtPRGen, it should be sufficient to use one that just sets the plugin-type property on CPU0:

// inject plugin-type on CPU0 to enable GPU power management

DefinitionBlock ("ssdt_pr.aml", "SSDT", 1, "APPLE ", "CpuPm", 0x00006500)
{
    External (\_PR_.CPU0, DeviceObj)
    External (DTGP, MethodObj)
    
    Scope (\_PR_.CPU0)
    {
        Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
        {
            Debug = "Writing plugin-type to Registry!"
            Local0 = Package (0x02)
                {
                    "plugin-type", 
                    One
                }
            DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
            Return (Local0)
        }
    }
}

Have you ever tested your theory?

Only add 'plugin-type' == '1' is not enough. At least. X86* will not load. I tested it previously. (Similar to your tiny SSDT, but I used Clover's PluginType and set that to 1.) No. X86* not loaded. You still have to inject APSS, ACST, etc. Otherwise X86* won't load. That's truth. This could be a bug in X86 but anyway. The truth is here.

 

[EDIT]

No. For Skylake with HWP enabled in FrequencyVectors we don't need APSS, ACST anymore. Thanks to dpassmor!

tluck, you can use this to judge if your HWP is enable or not. Note: you need to remove this kext and rebuild kernel cache before you reboot, otherwise this kext will cause your system panic.

 

syscl

Hi @Drfrag, I am pretty sure we need. Actually, once I received my XPS 13 9350 in Nov. 2016, I soon found the HWP power management is incomplete. See the log from my maclog here:

2016-11-23 18:06:07.281075-0600  localhost kernel[0]: (IOPlatformPluginFamily) <IOPlatformPluginFamily`DebugPrint> WARNING: IOPlatformPluginUtil : getCPUIDInfo: this is an unknown CPU model 0x4e
  -- power management may be incomplete or unsupported

Due to the fact cpu power management was incomplete, AGPM(Apple Graphics Power Management) was not implemented either. Usually, laptop manufactures will protect MSR 0xE2(read only) which wmrsr64 would write value on it to cause kernel panic. If you are lucky enough to unlock MSR 0xE2 lock like Dell Precision M3800 or XPS 9530, then you may not need this kernel patch. 

 

BTW, a lot of people say that they have HWP enable, but they ignore whether their power management is fully implemented. A very simple/useful way is open System Preferences -> Energy Saver to see if there's 3 options in Battery and 5  4 options in Power Adapter. More accurate way you need to open ioreg to search AGPM and X86PlatformPlugin, use kextstat to list all cpu/gpu relate kexts. 

 

Tune frequency vectors is optional, only when you need more ideal situation then you can tune it to fit your CPU/GPU. I will post injector method latter(which @Sherlocks has proven worked well using my modified version of X86PlatformPlugin.kext like a dummy AppleHDA).

 

syscl

The dummy X86PlatformPlugin will work. I can confirm it here as well.

Edited February 11, 2017 by PMheart

[dpassmor]

Have you ever tested your theory?

Only add 'plugin-type' == '1' is not enough. At least. X86* will not load. I tested it previously. (Similar to your tiny SSDT, but I used Clover's PluginType and set that to 1.) No. X86* not loaded. You still have to inject APSS, ACST, etc. Otherwise X86* won't load. That's truth. This could be a bug in X86 but anyway. The truth is here.

 

Yeah, I'm testing it as we speak, and have been for several days. All that's necessary is plugin-type.

 

 

bash-3.2# cd /Volumes/EFI/EFI/CLOVER/ACPI/patched/
bash-3.2# iasl SSDT-PR.aml 

Intel ACPI Component Architecture
ASL+ Optimizing Compiler version 20161210-64(RM)
Copyright (c) 2000 - 2016 Intel Corporation

Binary file appears to be a valid ACPI table, disassembling
Input file SSDT-PR.aml, Length 0x95 (149) bytes
ACPI: SSDT 0x0000000000000000 000095 (v01 APPLE  CpuPm    00006500 INTL 20160422)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed

Found 1 external control methods, reparsing with new information
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    SSDT-PR.dsl - 1180 bytes
bash-3.2# cat SSDT-PR.dsl
/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20161210-64(RM)
 * Copyright (c) 2000 - 2016 Intel Corporation
 * 
 * Disassembling to symbolic ASL+ operators
 *
 * Disassembly of SSDT-PR.aml, Fri Feb 10 20:26:13 2017
 *
 * Original Table Header:
 *     Signature        "SSDT"
 *     Length           0x00000095 (149)
 *     Revision         0x01
 *     Checksum         0xE1
 *     OEM ID           "APPLE "
 *     OEM Table ID     "CpuPm"
 *     OEM Revision     0x00006500 (25856)
 *     Compiler ID      "INTL"
 *     Compiler Version 0x20160422 (538313762)
 */
DefinitionBlock ("", "SSDT", 1, "APPLE ", "CpuPm", 0x00006500)
{
    External (_PR_.CPU0, DeviceObj)    // (from opcode)
    External (DTGP, MethodObj)    // 5 Arguments (from opcode)

    Scope (\_PR.CPU0)
    {
        Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
        {
            Debug = "Writing plugin-type to Registry!"
            Local0 = Package (0x02)
                {
                    "plugin-type", 
                    One
                }
            DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
            Return (Local0)
        }
    }
}

[PMheart]

 

Yeah, I'm testing it as we speak, and have been for several days. All that's necessary is plugin-type.

 

 

bash-3.2# cd /Volumes/EFI/EFI/CLOVER/ACPI/patched/
bash-3.2# iasl SSDT-PR.aml 

Intel ACPI Component Architecture
ASL+ Optimizing Compiler version 20161210-64(RM)
Copyright (c) 2000 - 2016 Intel Corporation

Binary file appears to be a valid ACPI table, disassembling
Input file SSDT-PR.aml, Length 0x95 (149) bytes
ACPI: SSDT 0x0000000000000000 000095 (v01 APPLE  CpuPm    00006500 INTL 20160422)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed

Found 1 external control methods, reparsing with new information
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    SSDT-PR.dsl - 1180 bytes
bash-3.2# cat SSDT-PR.dsl
/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20161210-64(RM)
 * Copyright (c) 2000 - 2016 Intel Corporation
 * 
 * Disassembling to symbolic ASL+ operators
 *
 * Disassembly of SSDT-PR.aml, Fri Feb 10 20:26:13 2017
 *
 * Original Table Header:
 *     Signature        "SSDT"
 *     Length           0x00000095 (149)
 *     Revision         0x01
 *     Checksum         0xE1
 *     OEM ID           "APPLE "
 *     OEM Table ID     "CpuPm"
 *     OEM Revision     0x00006500 (25856)
 *     Compiler ID      "INTL"
 *     Compiler Version 0x20160422 (538313762)
 */
DefinitionBlock ("", "SSDT", 1, "APPLE ", "CpuPm", 0x00006500)
{
    External (_PR_.CPU0, DeviceObj)    // (from opcode)
    External (DTGP, MethodObj)    // 5 Arguments (from opcode)

    Scope (\_PR.CPU0)
    {
        Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
        {
            Debug = "Writing plugin-type to Registry!"
            Local0 = Package (0x02)
                {
                    "plugin-type", 
                    One
                }
            DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
            Return (Local0)
        }
    }
}

I see... But weird. For me the APSS, ACST are still needed. Or (Only injecting plugin-type == 1) X86* won't load...

[EDIT]

I guessed that that bug had been fixed. Fabulous. Or for Skylake with HWP we don't need the redundant APSS, ACST, that's all HWP can do...

In any case, I think APSS ACST are still needed for the older platforms.

Edited February 11, 2017 by PMheart

[dpassmor]

I see... But weird. For me the APSS, ACST are still needed. Or (Only injecting plugin-type == 1) X86* won't load...

 

Try my SSDT. The Clover PluginType option doesn't do anything, as far as I can tell. 

[PMheart]

Try my SSDT. The Clover PluginType option doesn't do anything, as far as I can tell. 

Sorry I forgot to tell. I also tested a tiny SSDT at that time but without calling DTGP(). But I don't think it's actually related to that. BTW also check my edit at #33 

 

[EDIT]

DefinitionBlock ("", "SSDT", 1, "APPLE ", "CpuPm", 0x00021400)
{
    External (_PR_.CPU0, DeviceObj)

    Scope (\_PR.CPU0)
    {
        Method (_DSM, 4, NotSerialized)
        {
            If (LEqual (Arg2, Zero))
            {
                Return (Buffer (One)
                {
                     0x03                                           
                })
            }

            Return (Package (0x02)
            {
                "plugin-type", 
                One
            })
        }
    }
}

This is the tiny SSDT I used in the past. Which made no difference. X86* won't load for my Ivy Bridge hack. For Skylake with HWP enabled we just need this tiny SSDT! Fabulous.

Edited February 11, 2017 by PMheart

[syscl]

 

A couple of notes;

 

You no longer have to use Clover or HWPEnabler to enable HWP. If X86PlatformPlugin is loaded with a model identifier that supports HWP (MacBook9,1, MacBookPro13,x) the OS will enable HWP, and keep it enabled after sleep. Not only that, but the OS will dynamically manipulate the HWP request values depending on load and whether the system is on AC or battery.

 

Also, I don't believe it is necessary to use a full SSDT generated by ssdtPRGen, it should be sufficient to use one that just sets the plugin-type property on CPU0:

// inject plugin-type on CPU0 to enable GPU power management

DefinitionBlock ("ssdt_pr.aml", "SSDT", 1, "APPLE ", "CpuPm", 0x00006500)
{
    External (\_PR_.CPU0, DeviceObj)
    External (DTGP, MethodObj)
    
    Scope (\_PR_.CPU0)
    {
        Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
        {
            Debug = "Writing plugin-type to Registry!"
            Local0 = Package (0x02)
                {
                    "plugin-type", 
                    One
                }
            DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
            Return (Local0)
        }
    }
}

I've tried this method through Clover's Plugin Type == One, but still no full power management: lost X86PlatformPlugin to load. 

 

Actually, there's already plugin type == one in SSDT generated by ssdtPRGen.sh

Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
        {
            Store ("Method _PR_.CPU0._DSM Called", Debug)
            If (LEqual (Arg2, Zero))
            {
                Return (Buffer (One)
                {
                     0x03                                           
                })
            }

            Return (Package (0x02)
            {
                "plugin-type", 
                One
            })
        }

I will try your suggestion and let you know.

 

Yes, It did work! Simpler than my method to use ssdtPRGen.sh. 

 

I saw you use DTPG method, which may not present on all DSDT from my point of view(you can see my project here, none of them use DTPG method)

I suggest use this one(refining from DTPG method)

DefinitionBlock ("", "SSDT", 2, "CpuRef", "CpuSsdt", 0x00003000)
{
    External (_PR_.CPU0, DeviceObj)    // (from opcode)

    Scope (\_PR.CPU0)
    {
        Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
        {
            Store ("Writing plugin-type to Registry!", Debug)
            If (LEqual (Arg2, Zero))
            {
                Return (Buffer (One)
                {
                     0x03                                           
                })
            }

            Return (Package (0x02)
            {
                "plugin-type", 
                One
            })
        }
    }
}

Thank you,

syscl

[tluck]

ok switching to MBP13,1 was not enough. editing the Mac-473D31EABEB93F9B.plist to match my CPU was a key step. 

 

The default values of 3100/3400 and Freq Vector data did not match my i5-5300u proc. I figured something was wrong as battery was drained really fast yesterday. i noticed that my speed step would only go down to x13 (which matches the default 0D in the freq vector entry)

 

so now i changed frequencies to

2400/3000

and 

then in the vectors changed 0D to 05

 

and now much better.

 

i wonder what the rest of the Frequency Vector values mean?

 

questions on this using full SSDT-PR via "pike script" vs bare bones SSDT PR cpuPM etc.

what is the best approach? does it conflict in some way?

[syscl]

ok switching to MBP13,1 was not enough. editing the Mac-473D31EABEB93F9B.plist to match my CPU was a key step. 

 

The default values of 3100/3400 and Freq Vector data did not match my i5-5300u proc. I figured something was wrong as battery was drained really fast yesterday. i noticed that my speed step would only go down to x13 (which matches the default 0D in the freq vector entry)

 

so now i changed frequencies to

2300/2900

and 

then in the vectors changed 0D to 05

 

and now much better.

 

i wonder what the rest of the Frequency Vector values mean?

 

questions on this using full SSDT-PR via "pike script" vs bare bones SSDT PR cpuPM etc.

what is the best approach? does it conflict in some way?

Yes as I mentioned, edit frequency vector according to the model you select for your computer is pretty important. MacBookPro13,x can only down to 1.3Ghz which is not ideal even on a real MacBookPro13,x(IMO). We can lower it down, here's the injector I made for my XPS 13, you can use it as a template. I will post this method with more details later on.

X86PlatformPluginInjector.kext.zip

 

The first time I've figured out HWP full enable method is by using SSDT-pr generated by ssdtPRGen.sh, but later on @dpassmor reminded me using plugin type == 1 is enough. Less is more is what I propose in this scenario, though APSS will be very likely ignored by X86PlatformPlugin and mach_kernel. 

 

syscl

[tluck]

cool - so far so good!

 

- injector is working - just dropped my customized Mac-473D31EABEB93F9B.plist into the Resources

- switched to "mini-generic" SSDT for CPU above. 

- turned off generate C/P states via clover.

[Drfrag]

Yes as I mentioned, edit frequency vector according to the model you select for your computer is pretty important. MacBookPro13,x can only down to 1.3Ghz which is not ideal even on a real MacBookPro13,x(IMO).

How is it on a real MacBook9,1? Does it could not get cpu frequencies lower than 1.2Ghz?

And the turbo frequency? Have you reached 3.2ghz on full load?

[PMheart]

How is it on a real MacBook9,1? Does it could not get cpu frequencies lower than 1.2Ghz?

And the turbo frequency? Have you reached 3.2ghz on full load?

The lowest frequency of real MacBook9,1 is x12/1.2 GHz. This is due to the FrequencyVectors. (Check the bit 4, by default it's 0x0C/12 ==> 1200 MHz)

[tluck]

FWIW,

 

on my hack system with i5-6300U, AppleIntelInfo shows below

- i have never seen it go to down to x4 or to the max at x30?!

- i presume this kext tries to obtain all levels - and interesting the max obtained is x29. and perhaps for a split second it got down to x4 - parenthesis i guess indicates current state.

 

CPU Ratio Info:
------------------------------------------
Base Clock Frequency (BLCK)............. : 100 MHz
Maximum Efficiency Ratio/Frequency.......:  4 ( 400 MHz)
Maximum non-Turbo Ratio/Frequency........: 25 (2500 MHz)
Maximum Turbo Ratio/Frequency............: 30 (3000 MHz)

...

CPU P-States [ (4) 5 11 13 14 18 23 29 ] iGPU P-States [ ]

...

CPU P-States [ 4 (5) 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 ] iGPU P-States [ 6 (7) ]

[Drfrag]

The lowest frequency of real MacBook9,1 is x12/1.2 GHz. This is due to the FrequencyVectors. (Check the bit 4, by default it's 0x0C/12 ==> 1200 MHz)

 

I think 1.2Ghz is too high. How could a MacBook maintain it's battery for 10hours of iTunes or iBook?

 

 

FWIW,

 

on my hack system with i5-6300U, AppleIntelInfo shows below

- i have never seen it go to down to x4 or to the max at x30?!

- i presume this kext tries to obtain all levels - and interesting the max obtained is x29. and perhaps for a split second it got down to x4 - parenthesis i guess indicates current state.

 

CPU Ratio Info:

------------------------------------------

Base Clock Frequency (BLCK)............. : 100 MHz

Maximum Efficiency Ratio/Frequency.......:  4 ( 400 MHz)

Maximum non-Turbo Ratio/Frequency........: 25 (2500 MHz)

Maximum Turbo Ratio/Frequency............: 30 (3000 MHz)

...

CPU P-States [ (4) 5 11 13 14 18 23 29 ] iGPU P-States [ ]

...

CPU P-States [ 4 (5) 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 ] iGPU P-States [ 6 (7) ]

Did you change "D" to "4" to have 400Mhz as you lower frequency?

Just trying to understand if everybody is getting the same results.

[dpassmor]

 

I think 1.2Ghz is too high. How could a MacBook maintain it's battery for 10hours of iTunes or iBook?

 

 

Did you change "D" to "4" to have 400Mhz as you lower frequency?

Just trying to understand if everybody is getting the same results.

 

I am using a MacBookPro13,3 model identifier on my Dell XPS 9550. It has an identical CPU as one of the new MacBook Pro models. These MBPs have a default CPU floor of 1.3Ghz. Now, this is completely anecdotal, but from some rudimentary testing I can't tell the difference in battery life between the default 1.3Ghz, or when I change the frequency vectors to lower it to 800mhz (the floor for the processor itself). Both give me about six hours, and curiously enough, both hover around 1W in Intel Power Gadget when idle. 

 

It may be that HWP is doing something in the background to conserve power independently of the observed frequency, I'm curious what other folks are seeing.

[tluck]

@Drfrag - yes - i changed 0D to 04 - then i get 27 CPUPstates - from 400 to 3000. otherwise the lowest speed was step x13. now it idles at step x5 (500)

[Drfrag]

FWIW,

 

on my hack system with i5-6300U, AppleIntelInfo shows below

- i have never seen it go to down to x4 or to the max at x30?!

  

 

I saw i5 6300U has a maximum 2.9Ghz on dual core Turbo mode.

3.0 Ghz is for single core.

Maybe your tests are just showing dual core performance.

 

I am using a MacBookPro13,3 model identifier on my Dell XPS 9550. It has an identical CPU as one of the new MacBook Pro models. These MBPs have a default CPU floor of 1.3Ghz. Now, this is completely anecdotal, but from some rudimentary testing I can't tell the difference in battery life between the default 1.3Ghz, or when I change the frequency vectors to lower it to 800mhz (the floor for the processor itself). Both give me about six hours, and curiously enough, both hover around 1W in Intel Power Gadget when idle. 

 

It may be that HWP is doing something in the background to conserve power independently of the observed frequency, I'm curious what other folks are seeing.

Very interesting. I guess why does Apple keeps this vectors so high.

Maybe you are right. Changing this level down won't let any benefits on battery duration.

[PMheart]

 

I think 1.2Ghz is too high. How could a MacBook maintain it's battery for 10hours of iTunes or iBook?

 

Yep I think so. And therefore I lowered it to 0x05 ==> 500 MHz. I found that it seemed that my Core m5 cannot get a lower frequency. The lowest seems to be 500. Also I tuned EPP to 0xC0/192, it's 0x92/146 by default.

I am using a MacBookPro13,3 model identifier on my Dell XPS 9550. It has an identical CPU as one of the new MacBook Pro models. These MBPs have a default CPU floor of 1.3Ghz. Now, this is completely anecdotal, but from some rudimentary testing I can't tell the difference in battery life between the default 1.3Ghz, or when I change the frequency vectors to lower it to 800mhz (the floor for the processor itself). Both give me about six hours, and curiously enough, both hover around 1W in Intel Power Gadget when idle. 

 

It may be that HWP is doing something in the background to conserve power independently of the observed frequency, I'm curious what other folks are seeing.

Yeah I found that sometimes my MacBook9,1 can get a 800 MHz when idling although the FrequencyVectors defines the LFM is 0x0C/12. Could be related to HWP.

Very interesting. I guess why does Apple keeps this vectors so high.

Maybe you are right. Changing this level down won't let any benefits on battery duration.

I guessed that that was for a better performance?

[xtddd]

[JahStories]

Pretty interesting stuff I see here!

 

So I noticed some time ago that the cpu was not recognized just using the kext or the clover option for HWP...

Right now I'm using the kext, with the script to fix sleep, and frequencies are correctly scaling all this on a mbp13,1 smbios!

 

I tried adding the tiny SSDT, but it seems that I'm still missing AGPM, and I don't have that options under energy panel yet, what should I do too?

 

Edit: I just forgot to add it to the sorted order since I'm using drop oem!

Everything working fine here too

 

Thanks again guys!

[Drfrag]

my files.zip

 

Didn´t work for me.   The patch is not preventing the kernel panic and reboot after trying the tiny ssdt.
Maybe I am doing something wrong.