DSDT - Vanilla Speedstep - Generic Scope (_PR)

FKA · September 6, 2009

How many people are working on this issue with Snow Leopard?

I've got some 'borrowed' _CST tables (they look very similar to the 3,1 tables) and whilst I get the _PSS tables all loaded via the native IntelCPUPowerManagement I still get the LPC error relating to C-states. This was all working under 10.5.7 but has raised as an issue under 10.6.

I can attach any files of relevance that people would like to see here. It is annoying me to know end at the moment

Cheers,

Brett

where have you acquired the cst tables from?

I have had to set in SMBIOS the model to MacPro3,1 - which is where i got the cst.

also an edit needed to acpi_smc_platformplugin.kext plist - see earlier post in this thread.

let us know how you go.

D.

Brett Whinnen · September 7, 2009

where have you acquired the cst tables from?
I have had to set in SMBIOS the model to MacPro3,1 - which is where i got the cst.

also an edit needed to acpi_smc_platformplugin.kext plist - see earlier post in this thread.

let us know how you go.

D.

I was using ones from a MBP5,1 which have a couple of extra defines in them. I've also tried the actual ones from my Laptop, but not set anything in ACPI_SMC_PlatformPlugin.kext

from dmesg | grep ACPI

AppleACPICPU: ProcessorId=1 LocalApicId=1 Enabled
ACPI: System State [s0 S3 S4 S5] (S3)
ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized
Got boot device = IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/IDE0@1F,2/AppleICH8AHCI/PRI@0/IOAHCIDevice@0/AppleAHCIDiskDriver/IOAHCIBlockStorageDevice/IOBlockStorageDriver/WDC WD3200BEVT-75ZCT0 Media/IOGUIDPartitionScheme/Untitled@3

Excerpt from DSDT.dsl (_PSS values are from my T9300 cpu, taken from acpidump).

    Scope (_PR)
   {
       Processor (CPU0, 0x00, 0x00001010, 0x06)
       {
		Method (_CST, 0, NotSerialized)
		{
			If (LAnd (And (CFGD, 0x01000000), LNot (And (PDC0, 0x10
				))))
			{
				Return (Package (0x02)
				{
					One, 
					Package (0x04)
					{
						ResourceTemplate ()
						{
							Register (FFixedHW, 
								0x00,			   // Bit Width
								0x00,			   // Bit Offset
								0x0000000000000000, // Address
								,)
						}, 

						One, 
						0x9D, 
						0x03E8
					}
				})
			}

			If (And (PDC0, 0x0300))
			{
				If (And (CFGD, 0x20))
				{
					Return (Package (0x03)
					{
						0x02, 
						Package (0x04)
						{
							ResourceTemplate ()
							{
								Register (FFixedHW, 
									0x01,			   // Bit Width
									0x02,			   // Bit Offset
									0x0000000000000000, // Address
									,)
							}, 

							One, 
							One, 
							0x03E8
						}, 

						Package (0x04)
						{
							ResourceTemplate ()
							{
								Register (FFixedHW, 
									0x01,			   // Bit Width
									0x02,			   // Bit Offset
									0x0000000000000010, // Address
									,)
							}, 

							0x02, 
							One, 
							0x01F4
						}
					})
				}
			}

			If (And (CFGD, 0x20))
			{
				Return (Package (0x03)
				{
					0x02, 
					Package (0x04)
					{
						ResourceTemplate ()
						{
							Register (FFixedHW, 
								0x01,			   // Bit Width
								0x02,			   // Bit Offset
								0x0000000000000000, // Address
								,)
						}, 

						One, 
						One, 
						0x03E8
					}, 

					Package (0x04)
					{
						ResourceTemplate ()
						{
							Register (SystemIO, 
								0x08,			   // Bit Width
								0x00,			   // Bit Offset
								0x000000000000000C, // Address
								,)
						}, 

						0x02, 
						One, 
						0x01F4
					}
				})
			}

			Return (Package (0x02)
			{
				One, 
				Package (0x04)
				{
					ResourceTemplate ()
					{
						Register (FFixedHW, 
							0x01,			   // Bit Width
							0x02,			   // Bit Offset
							0x0000000000000000, // Address
							,)
					}, 

					One, 
					One, 
					0x03E8
				}
			})
		}
           Name (_PSS, Package (0x06)
           {
               Package (0x06)
               {
                   0x09C5, 
                   0x7D00, 
                   0x0A, 
                   0x0A, 
                   0x4D28, 
                   0x4D28
               }, 

               Package (0x06)
               {
                   0x09C4, 
                   0x7918, 
                   0x0A, 
                   0x0A, 
                   0x4C22, 
                   0x4C22
               }, 

               Package (0x06)
               {
                   0x07D0, 
                   0x5DC0, 
                   0x0A, 
                   0x0A, 
                   0x0A1E, 
                   0x0A1E
               }, 

               Package (0x06)
               {
                   0x0640, 
                   0x4650, 
                   0x0A, 
                   0x0A, 
                   0x081B, 
                   0x081B
               }, 

               Package (0x06)
               {
                   0x04B0, 
                   0x32C8, 
                   0x0A, 
                   0x0A, 
                   0x0617, 
                   0x0617
               }, 

               Package (0x06)
               {
                   0x0320, 
                   0x2710, 
                   0x0A, 
                   0x0A, 
                   0x8813, 
                   0x8813
               }
           })
       }

       Processor (CPU1, 0x01, 0x00001010, 0x06)
       {
           Method (_CST, 0, NotSerialized)
           {
               Return (^^CPU0._CST ())
           }

           Name (_PSS, Package (0x06)
           {
               Package (0x06)
               {
                   0x09C5, 
                   0x7D00, 
                   0x0A, 
                   0x0A, 
                   0x4D28, 
                   0x4D28
               },

Excerpt from /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/Info.plist

                                <key>CStateDemotionDict</key>
                               <dict>
<!--                                    <key>MacPro4,1</key> -->
<!--                                    <key>MacBookPro5,1</key> -->
                                       <key>MacPro3,1</key>
                                       <string>CSDD_std1</string>
                                       <key>Xserve3,1</key>
                                       <string>CSDD_std1</string>
                               </dict>

And finally from /Extra/smbios.plist

        <key>SMproductname</key>
       <string>MacPro3,1</string>

Have I done it correctly?

And this is under Snow Leopard as I mentioned previously.

Thanks again.

Brett

FKA · September 7, 2009

Have I done it correctly?

And this is under Snow Leopard as I mentioned previously.

Thanks again.

Brett

Hi Brett

Try this in the info plist (may work!)

<key>CStateDemotionDict</key>

<dict>

<key>MacBookPro5,1</key>

<key>Xserve3,1</key>

</dict>

D

OK I have a question -

The following _cst package example:

Name(_CST, Package()
{
4, // There are four C-states defined here with three semantics
// The third and fourth C-states defined have the same C3 entry semantics
Package(){ResourceTemplate(){Register(FFixedHW, [color="#ff0000"]0, 0, 0)}, 1, 20, 1000[/color]},
Package(){ResourceTemplate(){Register(SystemIO, [color="#ff0000"]8, 0, 0x161)}, 2, 40, 750[/color]},
Package(){ResourceTemplate(){Register(SystemIO, [color="#ff0000"]8, 0, 0x162)}, 3, 60, 500[/color]},
Package(){ResourceTemplate(){Register(SystemIO, [color="#ff0000"]8, 0, 0x163)}, 3, 100, 250[/color]}
})

Does anybody know what the data highlited in red corresponds to?

With a view to adding correct data for a given CPU.

D.

Brett Whinnen · September 7, 2009

Hi Brett

Try this in the info plist (may work!)

<key>CStateDemotionDict</key>

<dict>

<key>MacBookPro5,1</key>

<string>CSDD_std1</string>

<key>Xserve3,1</key>

<string>CSDD_std1</string>

</dict>

D

That is what I am running now. And still get the

ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

Error. Which leads me to believe they may not be from a MBP5,1 after all. With the logs above I was using just the MP3,1 items from the linked post on the first page and the smbios was setting it to be a MP3,1 which it was displayed as in System Profiler...

Using the same method I added _cst (c-states) SSDT tables from MacPro3,1 (as my MB does not have any!) These tables are posted by roisoft in post #70 here

Cheers,

Brett

FKA · September 7, 2009

Look carefully at what I've posted - It is not the same !

<key>CStateDemotionDict</key>

<dict>

<key>MacBookPro5,1</key>

<key>Xserve3,1</key>

</dict>

***EDIT*** If the above does not work in info.plist and you are unsure if you are using the correct SSDT from MBP5,1 then you can find SSDT and DSDT tables for various Mac models in post7

here - curt' roisoft

D.

Brett Whinnen · September 7, 2009

Look carefully at what I've posted - It is not the same !

<key>CStateDemotionDict</key>

<dict>

<key>MacBookPro5,1</key>

<string>CSDD_std1</string>

<key>Xserve3,1</key>

<string>CSDD_std1</string>

</dict>

***EDIT*** If the above does not work in info.plist and you are unsure if you are using the correct SSDT from MBP5,1 then you can find SSDT and DSDT tables for various Mac models in post7

here - curt' roisoft

D.

I should have posted what I was using after those logs above (or should I say prior to). Which is as far as I can see the same as you posted above. I did go to the point of copying that and pasting it in place of what I had in there anyway. The comments were to show what was original, what I then had and what I then placed to run the 3,1 test.

But I still get the following:

AppleACPICPU: ProcessorId=0 LocalApicId=0 Enabled

AppleACPICPU: ProcessorId=1 LocalApicId=1 Enabled

ACPI: System State [s0 S3 S4 S5] (S3)

ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

Got boot device = IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/IDE0@1F,2/AppleICH8AHCI/PRI@0/IOAHCIDevice@0/AppleAHCIDiskDriver/IOAHCIBlockStorageDevice/IOBlockStorageDriver/WDC WD3200BEVT-75ZCT0 Media/IOGUIDPartitionScheme/Untitled@3

About to go in search of some other CST tables from the link you posted. Might try a different model from the MBP5,1 I am using now... MBP4,1 would be closest to my actual hardware but we'll see where we end. Will report back, I really want to get this error removed, call it being pedantic if you will.

This is great work and I think this is the best approach we can have.

Thanks,

Brett

sk1nhead · September 7, 2009

looking at the guide it's not as easy as copy paste to my DSDT unlike other guides out there..

question, anyone care to explain the advantage of this compared to voodoopower? ive seen only few members posting so im assuming not that much or really no one cared about speedstep and just happy they have OSX running.

Master Chief · September 7, 2009

OK I have a question -

The following _cst package example:

Name(_CST, Package()
{
4, // There are four C-states defined here with three semantics
// The third and fourth C-states defined have the same C3 entry semantics
Package(){ResourceTemplate(){Register(FFixedHW, [color="#ff0000"]0, 0, 0)}, 1, 20, 1000[/color]},
Package(){ResourceTemplate(){Register(SystemIO, [color="#ff0000"]8, 0, 0x161)}, 2, 40, 750[/color]},
Package(){ResourceTemplate(){Register(SystemIO, [color="#ff0000"]8, 0, 0x162)}, 3, 60, 500[/color]},
Package(){ResourceTemplate(){Register(SystemIO, [color="#ff0000"]8, 0, 0x163)}, 3, 100, 250[/color]}
})

Does anybody know what the data highlited in red corresponds to?

With a view to adding correct data for a given CPU.

Let's take the last one as example:

8 = 8 bits.

0 = index address 0.

0x163 = Register (must be unique per _CST object).

Register(SystemIO, 8, 0, 0x163) // OSPM reads 8 bits, starting at index 0, from register 0x163 to go into this state.

3 = C-State aka C3.

100 = Latency in microseconds (worse case) to change C-State.

250 = Average power consumption in milliwatt (per core).

Now assume that core 0 is in C3 (using 1000mw) but has a little less work to do, reducing the average power usage to say 750mw (in this case) for over 40us, that will make it changes into C2. Doing more work again however, increasing the power usage for 20us (in this case) will make it change back into C1 again. In other words; reducing the CPU core to a lower frequency takes a little more time, or else the OS would freeze too often.

This example, with two C3 states, makes it more difficult for the OSPM because now it needs to make decisions about when to use which register i.e. in this case 0x162 or 0x163.

But this is all from the top of my head (and I haven't checked it). Time to get some sleep now

FKA · September 7, 2009

But this is all from the top of my head (and I haven't checked it). Time to get some sleep now

Many thanks Chief

D.

looking at the guide it's not as easy as copy paste to my DSDT unlike other guides out there..

question, anyone care to explain the advantage of this compared to voodoopower? ive seen only few members posting so im assuming not that much or really no one cared about speedstep and just happy they have OSX running.

Hi

It's not that straight forward and will take some time to get to grips with.

advantages|: using AppleIntelCPUPM, no need for disabler.kext, reported lower cpu temps, removes cst errors, closer to a vanilla build.

D.

hackcat · September 7, 2009

Are c-states processor dependent? Since I didn't have c-state tables on my mobo, I just borrowed from this thread. The more I think about it, my audio stutter could have been because I was rapidly dropping in and out of a c-state. If I did a bit more activity like moving the mouse a lot, the audio stopped stuttering. So the heuristics as when to idle or not were wrong for me, i.e playing audio was just at the threshold of when to drop into a c-state (perhaps even just C0) and the latency switch back and forth accounted for the stutter.

FKA · September 7, 2009

Are c-states processor dependent? Since I didn't have c-state tables on my mobo, I just borrowed from this thread. The more I think about it, my audio stutter could have been because I was rapidly dropping in and out of a c-state. If I did a bit more activity like moving the mouse a lot, the audio stopped stuttering. So the heuristics as when to idle or not were wrong for me, i.e playing audio was just at the threshold of when to drop into a c-state (perhaps even just C0) and the latency switch back and forth accounted for the stutter.

It's unlikely you'll enter a c-state when playing video/audio. But could be a latency problem.

More likely a latency problem with p-states. Can you see if you are flip-flopping between p-states when you have audio stutter?

D.

hackcat · September 7, 2009

Just playing audio cpu-i shows me pretty much pegged at the lowest p-state x6. I only get the stutter issue by adding c-states to my dsdt.

I finally added my p-states without appending ssdt tables to the dsdt. I defined my p-states at the beginning of the dsdt. Doing so, you also only have the 0x0A latency value defined.

When I had the ssdt tables appended, the NPSS had the 0xA0 and the SPSS had the 0x0A values for transition latency. Suggesting my stutter could be fixed there?

FKA · September 7, 2009

Just playing audio cpu-i shows me pretty much pegged at the lowest p-state x6. I only get the stutter issue by adding c-states to my dsdt.

I finally added my p-states without appending ssdt tables to the dsdt. I defined my p-states at the beginning of the dsdt. Doing so, you also only have the 0x0A latency value defined.

When I had the ssdt tables appended, the NPSS had the 0xA0 and the SPSS had the 0x0A values for transition latency. Suggesting my stutter could be fixed there?

Can you post your SPSS and NPSS tables

D.

hackcat · September 7, 2009

Using your appended ssdt tables with borrowed c-states, I just changed the following:

       Name (SPSS, Package (0x03)
       {
          	Package (0x06)
               { 
                   0x0C80, 
                   0x0135BA, 
                   0xA0, 
                   0x0A, 
                   0x082A, 
                   0x082A
               },

               Package (0x06)
               {
                   0x0AF0, 
                   0x01025F, 
                   0xA0, 
                   0x0A, 
                   0x0726, 
                   0x0726
               }, 

               Package (0x06)
               {
                   0x0960, 
                   0x00CD35, 
                   0xA0, 
                   0x0A, 
                   0x0620, 
                   0x0620
               }
       })
       Name (NPSS, Package (0x03)
       {
           	Package (0x06)
               { 
                   0x0C80, 
                   0x0135BA, 
                   0x0A, 
                   0x0A, 
                   0x082A, 
                   0x082A
               },

               Package (0x06)
               {
                   0x0AF0, 
                   0x01025F, 
                   0x0A, 
                   0x0A, 
                   0x0726, 
                   0x0726
               }, 

               Package (0x06)
               {
                   0x0960, 
                   0x00CD35, 
                   0x0A, 
                   0x0A, 
                   0x0620, 
                   0x0620
               }
       })

Those p-states work for me when I put them upfront in the dsdt without appending ssdt tables:

       Processor (CPU0, 0x00, 0x00000410, 0x06)
       {
           Name (_PPC, Zero)
           Name (_PCT, Package (0x02)
           {
               ResourceTemplate ()
               {
                   Register (FFixedHW, 
                       0x10,               // Bit Width
                       0x00,               // Bit Offset
                       0x0000000000000199, // Address
                       ,)
               }, 

               ResourceTemplate ()
               {
                   Register (FFixedHW, 
                       0x10,               // Bit Width
                       0x00,               // Bit Offset
                       0x0000000000000198, // Address
                       ,)
               }
           })
           Name (_PSS, Package (0x03)
           {
               Package (0x06)
               { 
                   0x0C80, 
                   0x0135BA, 
                   0x0A, 
                   0x0A, 
                   0x082A, 
                   0x082A
               },

               Package (0x06)
               {
                   0x0AF0, 
                   0x01025F, 
                   0x0A, 
                   0x0A, 
                   0x0726, 
                   0x0726
               }, 

               Package (0x06)
               {
                   0x0960, 
                   0x00CD35, 
                   0x0A, 
                   0x0A, 
                   0x0620, 
                   0x0620
               }
           })
       }

BTW, using an overclocked e6750 which only has 3 p-states. x8 is 3200 @ 1.372v, x7 2800 @ 1.308v, x6 2400 @1.212v

Master Chief · September 7, 2009

Weird. It seems that I don't need to modify anything to get P-States working with Leopard. Snow Leopard however is a different cat, but that is about to change.

Edit: I got it working with Snow Leopard. All I had to do was to change "MacPro3,1" in:

/System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/info.plist

into "P5K PRO" – because that is what System Profiler shows for this configuration – and that was it.

I wonder if there's any bit of code in CPU-i to show C-States, because how else would I know if that works? Checking...

SA22C · September 8, 2009

Weird. It seem that I don't need to modify anything to get P-States working with Leopard. Snow Leopard however is a different cat, but that is about to change.

Edit: I got it working with Snow Leopard. All I had to do was to change "MacPro3,1" in:

/System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/info.plist

into "P5K PRO" – because that is what System Profiler shows for this configuration – and that was it.

I wonder if there's any bit of code in CPU-i to show C-States, because how else would I know if that works? Checking...

I nabbed the OP's tables and changed the p-states to match my CPU. I don't get the C-state error anymore on boot and my Hack now sleeps and shuts down normally. However, I see no evidence that the CPU is actually stepping. The frequency seems pegged at the max. I am unable to boot into 32-bit (I have no idea why, but I the GUI refuses to load in x32) so I can't use CPUi to test, but a sysctl -a | grep freq returns a current, min and max freq as the same value, leading me to believe that no stepping is taking place.

I was also curious about the difference between the NPSS and SPSS states. What do I need to do differently between those two?

Thanks.

System is as follows:

Asus P5K-E

Intel Core 2 Duo E6400

Bios version 1305

My system supplies no SSDT tables of any kind, so I hacked in the provided SSDT dump in the OP.

Brett Whinnen · September 8, 2009

I'm getting the following in IOregexplorer...

You can see that the Pstates are read in but not active? GPU is active though. And looks like the cstates aren't active either.

This DSDT was working under 10.5.7 nicely, but SL 10A432 seems a different beastie. My _CST items are from the MacPro3,1 but if I change my smbios.plist to refer to this and also the ACPI_SMC_PlatformPlugin to reference that GPU scaling turns off... smbios.plist is now set to a MacBookPro5,1 which enables the GPU scaling.

Does anyone have the _CST from the MBP5,1 handy at all? I cannot seem to find it in any of the MBP5,1 SSDT dumps around the place.

Some screenshots.

And still getting the C-states error:

AppleACPICPU: ProcessorId=0 LocalApicId=0 Enabled

AppleACPICPU: ProcessorId=1 LocalApicId=1 Enabled

ACPI: System State [s0 S3 S4 S5] (S3)

ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

Cheers,

Brett

PS this is fun in a sick kind of way Seeing what differences are made.

Master Chief · September 8, 2009

...And still getting the C-states error:

ACPI: System State [s0 S3 S4 S5] (S3)

ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

No error here. You probably just forgot something (no offense). Feel free to attach your vanilla dsdt.dsl and the modified one.

Brett Whinnen · September 8, 2009

No error here. You probably just forgot something (no offense). Feel free to attach your vanilla dsdt.dsl and the modified one.

Hahaha, no offence at all, I'm new to DSDT / SSDT so happy to take pointers from people with more experience. I will attach them a bit later this evening. Thanks in advance for having a look!

Brett

Attached:

1. acpi_dsdt.dsl is the OE extracted from Everest.

acpi_dsdt.dsl.zip

2. DSDT-T9300.dsl is modified with _PSS for the T9300 and the other fixes for my Dell.

DSDT_T9300.dsl.zip

Thanks!

FKA · September 8, 2009

I nabbed the OP's tables and changed the p-states to match my CPU. I don't get the C-state error anymore on boot and my Hack now sleeps and shuts down normally. However, I see no evidence that the CPU is actually stepping. The frequency seems pegged at the max. I am unable to boot into 32-bit (I have no idea why, but I the GUI refuses to load in x32) so I can't use CPUi to test, but a sysctl -a | grep freq returns a current, min and max freq as the same value, leading me to believe that no stepping is taking place.

I was also curious about the difference between the NPSS and SPSS states. What do I need to do differently between those two?

Thanks.

System is as follows:

Asus P5K-E

Intel Core 2 Duo E6400

Bios version 1305

My system supplies no SSDT tables of any kind, so I hacked in the provided SSDT dump in the OP.

Hi SA22C

I presume you've tried extracting SSDT in Linux? Some SSDT seem to be blocked when extracted in OS X.

Also p-states can also be added under the scope (_PR) part of DSDT rather than appending SSDT (if you can't find any SSDT then this is probably more suitable than using borrowed SSDT.)

See this example curt' mitch_de

Scope (_PR)
{
Processor (CPU0, 0x00, 0x00000410, 0x06)
{

Name (_PPC, 0x00)

Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW, // PERF_CTL
0x10, // Bit Width
0x00, // Bit Offset
0x0000000000000199, // Address
,)
},

ResourceTemplate ()
{
Register (FFixedHW, // PERF_STATUS
0x10, // Bit Width
0x00, // Bit Offset
0x0000000000000198, // Address
,)
}
})

Name (_PSS, Package (0x04) // 4 Pstates 6-9 fsb muilt * 333 FSB, E7300-2660 GHZ-266*10
{
/* multi 10 OFF Package (0x06) { 3330, 93816, 10, 10, 0xA25, 0xA25 } */
Package (0x06) { 2997, 80535, 10, 10, 0x921, 0x921 }, // 2997 MHZ = 9* 333
Package (0x06) { 2664, 68120, 10, 10, 0x81D, 0x81D },
Package (0x06) { 2331, 56571, 10, 10, 0x71A, 0x71A },
Package (0x06) { 1998, 45889, 10, 10, 0x616, 0x616 }
})


} // end CPU0


Processor (CPU1, 0x01, 0x00000410, 0x06)
{

Name (_PPC, 0x00)

Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW, // PERF_CTL
0x10, // Bit Width
0x00, // Bit Offset
0x0000000000000199, // Address
,)
},

ResourceTemplate ()
{
Register (FFixedHW, // PERF_STATUS
0x10, // Bit Width
0x00, // Bit Offset
0x0000000000000198, // Address
,)
}
})

Name (_PSS, Package (0x04) // 4 Pstates 6-9 fsb muilt
{
/* multi 10 OFF Package (0x06) { 3330, 93816, 10, 10, 0xA25, 0xA25 } */
Package (0x06) { 2997, 80535, 10, 10, 0x921, 0x921 }, // 2997 MHZ = 9* 333
Package (0x06) { 2664, 68120, 10, 10, 0x81D, 0x81D },
Package (0x06) { 2331, 56571, 10, 10, 0x71A, 0x71A },
Package (0x06) { 1998, 45889, 10, 10, 0x616, 0x616 }
})


} // end CPU1




Processor (CPU2, 0x02, 0x00000410, 0x06)
{

} // end CPU2


Processor (CPU3, 0x03, 0x00000410, 0x06)
{


} // end CPU3
}

When I get some time I'm going to try to add c-state (_cst) table in this fashion. See post #53 and page 281 section 8.4.2 of ACPI specs. This could be a more universal method?!

D.

Master Chief · September 8, 2009

Hahaha, no offence at all, I'm new to DSDT / SSDT so happy to take pointers from people with more experience. I will attach them a bit later this evening. Thanks in advance for having a look!

Hi Brett,

I looked at your files and immediately noticed something, which I expected to be honest. The problem is that you copied stuff, but it is not initialized. Not at all. Let's have a look at this:

	Scope (\)
{
	Name (SSDT, Package (0x0C)
	{
		"CPU0IST ", 
		0xDFE72CB4, 
		0x02C8, 
		"CPU1IST ", 
		0xDFE72F7C, 
		0xC4, 
		"CPU0CST ", 
		0xDFE7264A, 
		0x05E5, 
		"CPU1CST ", 
		0xDFE72C2F, 
		0x85
	})
	Name (CFGD, 0x013369F7)
	Name (PDC0, 0x80000000)
	Name (PDC1, 0x80000000)
	Name (SDTL, 0x00)
}

N.b. You don't need SSDT to get P-States working – I did not include it and everything appears to be working, and without the usual startup error yes.

Edit: I don't need SSDT because my DSDT declares it like this:

		Processor (CPU1, 0x01, 0x00000810, 0x06)
	{
		OperationRegion (STBL, SystemMemory, 0xCFF8E0D0, 0x01D2)

Which is basically the same, but quicker.

Now have a look at PDC[0/1] because like I said, nowhere in your DSDT can I find anything that initializes these two, representing the capabilities so they are pretty important. This usually is the task of the OSPM capabilities interfaces called Processor Driver Capabilities and/or Operating System Capabilities - depending on the used ACPI version. But your DSDT doesn't include them! In other words; you either need to add _PDC(){} and/or _OSC(){} to get the job done, or init the PDCn yourself with the help of the attached table (key to get C-States going).

Edit: I just had another quick look at this snippet (from FormerlyKnownAs et all):

	Scope (_PR.CPU0)
{
	Name (HI0, Zero)
	Name (HC0, Zero)
	Name (TLD0, Zero)
	Method (_PDC, 1, NotSerialized)
	{
		CreateDWordField (Arg0, 0x08, CAP0)
		Store (CAP0, PDC0)
		If (LEqual (TLD0, Zero))
		{
			If (LEqual (And (PDC0, 0x0A), 0x0A))
			{
				If (And (CFGD, 0x02))
				{
					OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, One)), DerefOf (Index (SSDT, 0x02
						)))
					Load (IST0, HI0)
				}

				Store (One, TLD0)
			}
		}
	}
}

Now note this:

			CreateDWordField (Arg0, 0x08, CAP0)
		Store (CAP0, PDC0)

Which tells me that Apple is only using/checking the revision ID, which for your info is the first argument (Arg0). That is if this snippet is really taken from a real Mac (Edit: Not, see next post).

And here's the table I mentioned earlier:

FKA · September 8, 2009

Which tells me that Apple is only using/checking the revision ID, which for your info is the first argument (Arg0). That is if this snippet is really taken from a real Mac.

Hi Master Chief

That is an SSDT IST table - as extracted from my Gigabyte MB. It's not Apple.

D.

Master Chief · September 8, 2009

Hi Master Chief

That is an SSDT IST table - as extracted from my Gigabyte MB. It's not Apple.

D.

Me ducks. I should have noticed it as it was right in my face. Thing is; I just got my morning shower - still waiting for my cappuccino after breakfast - and thus things should go better in a few minutes. Ah lovely there it is.

p.s. Any real Mac DSDT's floating around here? Got it. This should help – post #7 for the SSDT tables

Update: My _PDC() {} and OSC() {} ASL code is almost the same as the MacPro3,1 but mine doesn't Load() the CST table.

Brett Whinnen · September 9, 2009

Thanks for the pointers. I'll run through the SSDT from the MBP5,1 I have and compare them to mine for the OST and PDC fields.

The following lines from yours:

Processor (CPU1, 0x01, 0x00000810, 0x06)

{

OperationRegion (STBL, SystemMemory, 0xCFF8E0D0, 0x01D2)

What memory addresses are they referring to from your SSDT tables? The CST or IST?

I did put in my own PDC and OST but that made no difference (been playing with wireless routers all day and this is the first sit down I've had). As mentioned I'll look through the SSDT-1 from an MBP5,1 and see what they are doing to load the CST and IST from SSDT...

OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, 0x01)), DerefOf (Index (SSDT, 0x02)))

OperationRegion (CST0, SystemMemory, DerefOf (Index (SSDT, 0x07)), DerefOf (Index (SSDT, 0x08)))

(for CPU0 from mine).

Actually those are identical, and IST0 is loaded to HI0 and CST0 to HC0...

Code snippet -> from _OST for the Dell

            If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), 
               LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3)))))
           {
               Store (0x06, STS0)
               Return (Arg3)
           }

           If (LNotEqual (Arg1, 0x01))
           {
               Store (0x0A, STS0)
               Return (Arg3)
           }

           Or (And (PDC0, 0x7FFFFFFF), CAP0, PDC0)

For the MBP5,1

            If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), 
               LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3)))))
           {
               Store (0x06, Index (STS0, 0x00))
               Return (Arg3)
           }

           If (LNotEqual (Arg1, 0x01))
           {
               Store (0x0A, Index (STS0, 0x00))
               Return (Arg3)
           }

           Or (And (PDC0, 0x7FFFFFFF), CAP0, PDC0)

Just the way the Store is done is different between the two SSDT's... Not sure if that is significant at all or not, thoughts?

Thanks,

Brett

FKA · September 9, 2009

Thanks for the pointers. I'll run through the SSDT from the MBP5,1 I have and compare them to mine for the OST and PDC fields.

The following lines from yours:

Processor (CPU1, 0x01, 0x00000810, 0x06)

{

OperationRegion (STBL, SystemMemory, 0xCFF8E0D0, 0x01D2)

What memory addresses are they referring to from your SSDT tables? The CST or IST?

I did put in my own PDC and OST but that made no difference (been playing with wireless routers all day and this is the first sit down I've had). As mentioned I'll look through the SSDT-1 from an MBP5,1 and see what they are doing to load the CST and IST from SSDT...

OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, 0x01)), DerefOf (Index (SSDT, 0x02)))

OperationRegion (CST0, SystemMemory, DerefOf (Index (SSDT, 0x07)), DerefOf (Index (SSDT, 0x08)))

(for CPU0 from mine).

Actually those are identical, and IST0 is loaded to HI0 and CST0 to HC0...

Just the way the Store is done is different between the two SSDT's... Not sure if that is significant at all or not, thoughts?

Thanks,

Brett

Hi Guys

Please see post 71 here in ab__73's bootloader thread - regarding finding correct memory addresses for _cst. It involves some messing around with voodoo kernel but c-states wont load unless this is correct.

D.

DSDT - Vanilla Speedstep - Generic Scope (_PR)

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites