Jump to content

DSDT - Vanilla Speedstep - Generic Scope (_PR)


FKA
 Share

1,949 posts in this topic

Recommended Posts

NumEntries Integer The number of entries in the PStateDependency package including this field. Current value is 5.

 

You have 5 entries: NumEntries,Revision,Domain,CoordType and NumProcessors.

 

I think your right - I'm not seeing a switch to x7 multi with a value of 3

 

No offense mm67 - can anyone else confirm?

Link to comment
Share on other sites

Anyway, I don't understand why CPU temperature is bigger with speedstep (55C). Without speedstep is 40C

 

if voodoo power shows you @ multi x9 all the time ( i think this is what you said) then speedstep isn't working for you.

Link to comment
Share on other sites

NumEntries Integer The number of entries in the PStateDependency package including this field. Current value is 5.

 

You have 5 entries: NumEntries,Revision,Domain,CoordType and NumProcessors.

 

YEP, but that 05 which is OK is that one (Package (0x05)) which is the number of entries in that packadge.

 Method (_PSD, 0, NotSerialized)
 {
    Return (Package (0x[b]05[/b])  // 5 entries in the packadge=[b]OK [/b]=[size=1]NumEntries,Revision,Domain,CoordType and NumProcessors[/size]
     {

NumEntries,  // also [b]05[/b]?!  or the [b]real[/b] number of Pstates=[b] 02....08[/b] ?!
Revision,
Domain,
CoordType,
NumProcessors
})
}

 

Would be fine to clear that up :(

Link to comment
Share on other sites

credit bcc9 and hnak.
Really need to credit superhai for this and the other derivative works too (cpu-i,voodoomonitor).
I did mention in post 798 that it make the transition smoother - but like you say it's hard to guage so I didn't like to say.
Note that pstatechanger will go about changing states itself if you're running it so its behavior can affect results. pstatechanger would be no good for monitoring how your _PSS changes are working out.

I think you guys really need a new application that only monitors the states at runtime with proper voltage display, without changing anything. (Kind of like voodoomonitor with open source and the identified bugs fixed). Then you can really start evaluating how your _PSS tables are working with appleintelcpupowermanagement.

Can somebody riddle this for me:

Pstatechanger and voodoopstate give me a slightly lower vid for my x7 and x6 multi so I've amended my PSS accordingly.

...But voodoomonitor shows

Yes, the lower vids are the whole point of the roundoff fix.

Voodoomonitor's pstate tab, like pstatechanger's are static calculations made by them, not read from your PSS or from your cpu's current p-state.

Link to comment
Share on other sites

YEP, but that 05 which is OK is that one (Package (0x05)) which is the number of entries in that packadge.

 Method (_PSD, 0, NotSerialized)
 {
    Return (Package (0x[b]05[/b])  // 5 entries in the packadge=[b]OK [/b]=[size=1]NumEntries,Revision,Domain,CoordType and NumProcessors[/size]
     {

NumEntries,  // also [b]05[/b]?!  or the [b]real[/b] number of Pstates=[b] 02....08[/b] ?!
Revision,
Domain,
CoordType,
NumProcessors
})
}

 

Would be fine to clear that up :(

 

No, like this:

1 . NumEntries, 2. Revision, 3. Domain, 4. CoordType and 5. NumProcessors

 

5 entries for now, may be changed in later Acpi spesifications.

Link to comment
Share on other sites

if voodoo power shows you @ multi x9 all the time ( i think this is what you said) then speedstep isn't working for you.

 

I have the opposite!

 

1. Without speedstep voodoo power shows x6 all the time! 39-43C

2. With speedstep enabled voodoo power shows x6, x7, x8 and x9. The temperature is pretty high at x9 -> 53C.

Link to comment
Share on other sites

I have the opposite!

 

1. Without speedstep voodoo power shows x6 all the time! 39-43C

2. With speedstep enabled voodoo power shows x6, x7, x8 and x9. The temperature is pretty high at x9 -> 53C.

 

I get around 50.C at my max 8x .... at rest i get around 39 or 40.C

 

I'd say that's normal.

 

D.

Link to comment
Share on other sites

Ok but my CPU with NO speedstep stay at the lowest (x6 multiplier all the time). I think this is the opposite.

The goal of speedstep is to reduce the temperature (in my case the temperature is increased because the multiplier increases to x9).

 

With NO speedstep my multiplier never increases to x9. Speedstep is like an overclock for me.

Link to comment
Share on other sites

The goal of speedstep is to reduce the temperature (in my case the temperature is increased because the multiplier increases to x9).

 

My friend - the idea of speedstep is to make the CPU voltage (vCore) and FSB multiplier (x6, x7, x8, x9) dynamic - i.e. they continually change depending on CPU load.

 

I say it again - if voodoomonitor shows your CPU to stay at multi x9 ALL THE TIME - then speedstep IS NOT WORKING for you.

 

Can you please post me your DSDT.dsl file and the FID/VID values you have taken from pstatechanger.

 

D.

Link to comment
Share on other sites

"One more thing" - mitch has an other thing to clear (perhaps some typos !) :wacko:

 

I like that reallly clean code from FormerlyKnownAs here very much!!!, but i am confused how

_PR_CPU1, PR_CPU2, _PR CPU3 return of _PSS, _PSD are implemented.

All returns :

_PR_CPU1

Return (^^CPU0._CST ()), i understand in Method _CST = OK

Links CPU1.CST to CPU0.CST, where CST was declared / values of CST set

 

 

But in Methods _PSS and _PSD should it not be like:

 

[b]_PR_CPU1[/b]....

Method ([b][color="#008000"]_PSS[/color][/b], 0, NotSerialized)
       {
               Return (^^CPU0.[b][color="#FF0000"]_CST[/color][/b] ())   /[b]/ _PSS <> _CST  in CPU0 ?![/b]
       }
Links CPU1.PSS to CPU0.CST ???, complete different values CST vs PSS linked ?


[b]into [/b]
[b]_PR_CPU1[/b]....
Method ([color="#008000"][b]_PSS[/b][/color], 0, NotSerialized)
       {
               Return (^^CPU0.[color="#008000"][b]_PSS[/b][/color] ()) 
       }

and 
     Method ([color="#008000"][b]_PSD[/b][/color], 0, NotSerialized)
       {
               Return (^^CPU0.[color="#FF0000"][b]_CST[/b][/color] ())   [b]// _PSD <> _CST  in CPU0 ?![/b]
       }

[b]into[/b] 
     Method ([color="#008000"][b]_PSD[/b][/color], 0, NotSerialized)
       {
               Return (^^CPU0.[color="#006400"][b]_PSD[/b][/color] ())   
       }

 

ORIG CODE :

 

Scope (_PR.CPU0)
   {
       Method (_PSS, 0, NotSerialized)
      [size=1] {
           ......
               }[/size]
})
}
           Method (_[b]PSD[/b], 0, NotSerialized)
           {
             [size=1]  Return (Package (0x05)
               {
                   0x05,
                   0x00,
                   0x00,
                   0xFC,
                   0x04
               })[/size]
           }

       Method (_[b]CST[/b], 0, NotSerialized)
       {
		[size=1]Return (Package (0x02)
		{
			One, 
			Package (0x04) {ResourceTemplate () {Register (....}
		})[/size]
       }
   }

   Scope ([b]_PR.CPU1[/b])
   {
       Method (_[b]PSS[/b], 0, NotSerialized)
       {
               Return (^^CPU0._[b]CST[/b] ())   [b]// ??? , why not ^^CPU0._PSS[/b]
       }

       Method (_[b]PSD[/b], 0, NotSerialized)   [b]// why not ^^CPU0._PSD[/b]
       {
               Return (^^CPU0._[b]CST[/b] ())
       }

       Method (_CST, 0, NotSerialized)
       {
         [size=1]  Return (Package (0x04)
           {
               ........
           })[/size]
       }
   }

   Scope ([b]_PR.CPU2[/b])
   {
       Method (_PSS, 0, NotSerialized)
       {
               Return (^^CPU0._CST ())   [b]// why not ^^CPU0._PSS[/b]
       }

       Method (_PSD, 0, NotSerialized)
       {
               Return (^^CPU0._CST ()) [b]// why not ^^CPU0._PSD[/b]
       }

       Method (_CST, 0, NotSerialized)
       {
               Return (^^CPU1._CST ())  /[b]/ CST > CST = OK [/b]
       }
   }
   Scope ([b]_PR.CPU3[/b])
   {
       Method (_PSS, 0, NotSerialized)
       {
               Return (^^CPU0._CST ())   [b]// why not ^^CPU0._PSS[/b]
       }

       Method (_PSD, 0, NotSerialized)   [b]// why not ^^CPU0._PSD[/b]
       {
               Return (^^CPU0._CST ())
       }

       Method (_CST, 0, NotSerialized)
       {
               Return (^^CPU1._CST ())
       }
   }

Link to comment
Share on other sites

"One more thing" - mitch has an other thing to clear (perhaps some typos !) :D

 

Sorry :) - mm67 spotted my typo(s) also !

 

Now corrected in OP - and should read:

 Scope (_PR)
{
Processor (CPU0, 0x00, 0x00000410, 0x06) {}
Processor (CPU1, 0x01, 0x00000410, 0x06) {}
Processor (CPU2, 0x02, 0x00000410, 0x06) {}
Processor (CPU3, 0x03, 0x00000410, 0x06) {}
}

Scope (_PR.CPU0)
{
Method (_PSS, 0, NotSerialized)
{
Return (Package (0x03)
{
Package (0x06)
{
Zero,
Zero,
0x0A,
0x0A,
0x0820,
Zero
},

Package (0x06)
{
Zero,
Zero,
0x0A,
0x0A,
0x071C,
One
},

Package (0x06)
{
Zero,
Zero,
0x0A,
0x0A,
0x061A,
0x02
}
})
}

Method (_PSD, 0, NotSerialized)
{
Return (Package (0x05)
{
0x05,
Zero,
Zero,
0xFC,
0x04
})
}

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

One,
0x9D,
0x03E8
}
})
}
}

Scope (_PR.CPU1)
{
Method (_PSS, 0, NotSerialized)
{
Return (^^CPU0._PSS ())
}

Method (_PSD, 0, NotSerialized)
{
Return (^^CPU0._PSD ())
}

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

One,
Zero,
0x03E8
},

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

0x02,
One,
0x01F4
},

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

0x03,
0x55,
0xFA
}
})
}
}

Scope (_PR.CPU2)
{
Method (_PSS, 0, NotSerialized)
{
Return (^^CPU0._PSS ())
}

Method (_PSD, 0, NotSerialized)
{
Return (^^CPU0._PSD ())
}

Method (_CST, 0, NotSerialized)
{
Return (^^CPU1._CST ())
}
}

Scope (_PR.CPU3)
{
Method (_PSS, 0, NotSerialized)
{
Return (^^CPU0._PSS ())
}

Method (_PSD, 0, NotSerialized)
{
Return (^^CPU0._PSD ())
}

Method (_CST, 0, NotSerialized)
{
Return (^^CPU1._CST ())
}
}

 

Odd thing is the incorrect code works: as mm67 pointed out in PM - even if you don't define the other CPU cores in Scope (PR) and just have PSS and CST tables for Core 0 (1) it still works:

 

D.

Link to comment
Share on other sites

My friend - the idea of speedstep is to make the CPU voltage (vCore) and FSB multiplier (x6, x7, x8, x9) dynamic - i.e. they continually change depending on CPU load.

 

I say it again - if voodoomonitor shows your CPU to stay at multi x9 ALL THE TIME - then speedstep IS NOT WORKING for you.

 

Can you please post me your DSDT.dsl file and the FID/VID values you have taken from pstatechanger.

 

D.

Ok. I have attached the DSDT with FID/VID values.

zoliky.zip

Link to comment
Share on other sites

Sorry :D - mm67 spotted my typo(s) also !

 

Now corrected in OP - and should read:

 

 
...
Scope (_PR.CPU0)
{
Method (_PSS, 0, NotSerialized)
{
Return (Package (0x03)
{
Package (0x06)
{
Zero, <-- Here?
Zero, <-- And here?
0x0A,
0x0A,
0x0820,
Zero
},
...

 

Odd thing is the incorrect code works: as mm67 pointed out in PM - even if you don't define the other CPU cores in Scope (PR) and just have PSS and CST tables for Core 0 (1) it still works:

 

D.

 

Question. Are people omitting Frequency and power so other people don't use them by mistake?! Or are you actually omitting them because you don't need to specify them?

 

Dam that was such a n00b question but I had to ask.

Link to comment
Share on other sites

Question. Are people omitting Frequency and power so other people don't use them by mistake?! Or are you actually omitting them because you don't need to specify them?

Good question. I guess the values should all be filled in. Though I have the power field blank because I don't know yet how to calculate it, I understand it should equal the maximum power dissipation for that performance state (any offers to show me?). But the functionality doesn't seem to be affected.

My current data is as follows

Package (0x06) { 2670, [color="#FF0000"]0[/color], 10, 10, 0x0A1D, 0 },
Package (0x06) { 2403, [color="#FF0000"]0[/color], 10, 10, 0x091D, 1 },
Package (0x06) { 2136, [color="#FF0000"]0[/color], 10, 10, 0x081C, 2 },
Package (0x06) { 1869, [color="#FF0000"]0[/color], 10, 10, 0x071B, 3 },
Package (0x06) { 1602, [color="#FF0000"]0[/color], 10, 10, 0x061A, 4 }

Link to comment
Share on other sites

Thanks FormerlyKnownAs for clearing the code of CPU (with PSS, PSD, CST ).

And of course, even it was some wrong maybe it worked.

I, for excample has no PSS, PSD returns in the CPU1...3 (last part of code) and at least PSTATES worked as they should.

So perhaps that code part is not really neaded ?

Link to comment
Share on other sites

Question. Are people omitting Frequency and power so other people don't use them by mistake?! Or are you actually omitting them because you don't need to specify them?

 

Dam that was such a n00b question but I had to ask.

 

They're omitted because they're not used.

I tried some time back putting varying power and frequency values in and it makes no differance. They can be left as Zero.

 

We only seem to need to define the Latency, FID/VID and p-state number.

 

I'm going to update post#1 with a generic Scope (PR) this afternoon - especially for all the nOObs :wacko:

Link to comment
Share on other sites

Ok. I have attached the DSDT with FID/VID values.

 

Ive corrected -MY- mistakes in this scope PR.

 

Try this zoliky.zip

 

Also the values highlighted in red below, are they the same as your origional, untouched Scope (PR) ?

You'll need to change them if they're not.

 

Scope (_PR)
   {
       Processor (CPU0, 0x00, 0x00000[b][color="#ff0000"]410[/color][/b], 0x06) {}
       Processor (CPU1, 0x01, 0x00000[b][color="#ff0000"]410[/color][/b], 0x06) {}
       Processor (CPU2, 0x02, 0x00000[b][color="#ff0000"]410[/color][/b], 0x06) {}
       Processor (CPU3, 0x03, 0x00000[b][color="#ff0000"]410[/color][/b], 0x06) {}
   }

 

D.

Link to comment
Share on other sites

Hey Friends.

It seems i got vanilla Speed stepping working . How can i check at which State the CPU is running under Snowleopard?

I use VoodooMonitor with VoodooMonitor.kext in /E/E. But I think we need a new dedicated application just for this purpose. Here's a quote from bcc9 posted yesterday.

Note that pstatechanger will go about changing states itself if you're running it so its behavior can affect results. pstatechanger would be no good for monitoring how your _PSS changes are working out.

I think you guys really need a new application that only monitors the states at runtime with proper voltage display, without changing anything. (Kind of like voodoomonitor with open source and the identified bugs fixed). Then you can really start evaluating how your _PSS tables are working with appleintelcpupowermanagement.

Yes, the lower vids are the whole point of the roundoff fix.

Voodoomonitor's pstate tab, like pstatechanger's are static calculations made by them, not read from your PSS or from your cpu's current p-state.

Link to comment
Share on other sites

They're omitted because they're not used.

I tried some time back putting varying power and frequency values in and it makes no differance. They can be left as Zero.

 

We only seem to need to define the Latency, FID/VID and p-state number.

 

I'm going to update post#1 with a generic Scope (PR) this afternoon - especially for all the nOObs :(

 

@FKA

 

So is this what you're using for your Q9450?

		Method (_PSS, 0, NotSerialized)
	{
		Return (Package (0x03)
		{
			Package (0x06) { Zero, Zero, 10, 10, 0x00000822, 0 },
			Package (0x06) { Zero, Zero, 10, 10, 0x0000071E, 1 },
			Package (0x06) { Zero, Zero, 10, 10, 0x0000061A, 2 }
		})
	}

 

I was using:

		Method (_PSS, 0, NotSerialized)
	{
		Return (Package (0x03)
		{
			Package (0x06) { 3552, 75000, 10, 10, 0x00000820, 0 },
			Package (0x06) { 3108, 65000, 10, 10, 0x0000071C, 1 },
			Package (0x06) { 2664, 60000, 10, 10, 0x0000061A, 2 }
		})
	}

 

It seems we should have arrived at the same settings since we have the same processor.

post-16858-1258466674_thumb.png

Link to comment
Share on other sites

@FKA

 

So is this what you're using for your Q9450?

 

It seems we should have arrived at the same settings since we have the same processor.

post-16858-1258466674_thumb.png

 

I was - I only ran the fixed voodoopstate-v4 yesterday and I get:

 

post-275122-1258467334_thumb.png

 

Which is what I'm using now.

Note: I'm only Oclocked to 3.36GHz

Link to comment
Share on other sites

 Share

×
×
  • Create New...