My DSDT-Focused Sabbatical

Hi all,

It isn't the end of this blog yet, I've just been very busy the last couple weeks and have been working on DSDTs in the evenings. Primarily, the DSDT for my Dell Latitude D830. Up until recently I had barely looked inside a .dsl file and had little clue of what was going on. However, I've finally come to some understanding of it and would like to share what I've found. My goal here is to look back and relate, to the best of my ability, what would have got me up to speed the fastest. I do have prior programing experience and that definitely helps.

General DSDT Editing Tips

1. Always have a working backup of your DSDT in the root folder. Sounds basic, and it is basic. However, its very easy to get ahead of yourself and rush to test your latest change. This can be especially painful when you are working on AppleIntelCPUPowerManagement without a backup. Why? Because most people can't just delete the DSDT and boot without one because you'll get an HPET kernel panic. Additionally, if you try to work in single user (CLI) mode to delete the poewr management kext it will often load before you are done typing the needed commands, and therefore panicking before you can fix it. When I have compiled a new DSDT that I want to test I first rename the current DSDT to bDSDT.aml (the name doesn't matter) and then paste the new one in. That way if it doesn't work I can reboot with the flag DSDT=bDSDT.aml
2. Make one change at a time until you are sure multiple changes would have isolated effects. Again, this is basic and conservative debugging. If your computer doesn't load with your next DSDT, you need to know for sure what change caused that. 
3. Start by cleaning up your DSDT. Don't go adding features while you are still getting warnings, as this makes it harder to figure out what's wrong if it doesn't work.
4. Be sure to watch your brackets. It usually pays (for me anyway) to spend the time formatting code properly, it helps identify those problems quicker.
5. I'm using DSDTSE, with the latest iasl dropped in, to compile. 

Vanilla Speedstep: P-States

P-States are actually pretty simple to get working, if you know what you are doing. In hindsight, I was two 'steps' away from having it working perfectly on my first try. However, it took a while to figure out what those were. This is the InsanelyMac thread that first got my attention, and it is a good place to start. I will assume you read the first post and have come to an understanding of what we are doing here. With that as a foundation, I'll simplify the procedure further. To the best of my understanding there are only two needed components to having working P-States controlled by AppleIntelCPUPowerManagement:

1. Copy "Name (_PSS, ..." into the definition of your first processor under "Scope (_PR)". Then, add a reference under all other processors. Ex. "Method (_PSS, 0, NotSerialized){Return(^^CPU0.PSS)}" Some computers have various other P-State tables under other names (Eg. NPSS, XPSS), you'll have to do some detective work to figure out which one is most likely right for your processor. More on this in a minute.
2. If you look in System Profiler and your Model Identifier is NOT MacBook5.1, MacBook5.2, MacBookPro5.1, MacBookPro5.2, MacBookPro5.3, MacBookPro5.4, MacBookPro5.5, MacPro3.1, Macmini3.1, or iMac9.1, you need to open info.plist in /System/Library/Extensions/IOPlatformFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents add an entry under "PlimitDict" for whatever your Model Identifier is. All the entries under that key are the same, just replace the name in one with whatever you have. In the thread referenced above, people elude to editing the plist for this kext, but there are at least three areas vaguely mentioned to edit. I believe this is the only edit needed for working P-States. Eventually I will incorporate this into a legacy kext.

Now, I originally got Step 1, but I missed Step 2. With both steps done, I believe the majority of people will have P-States working to some extent. I had P-States working at this point but it wasn't quite the way it should be. I had noticed for a while that the lowest state it would go into had the wrong voltage, and it wasn't the lowest listed by CPU-i. The long and short of it is that the P-States I dumped were incorrect... in some major ways. For one, I have a T9300 which has a maximum multiplier of 12.5x yet the highest P-State in the table was for a multiplier of 13.5x. It took me longer to figure this out because I was under the impression that CPU-i was supposed to list all the P-States known to the system. However, it was instead listing all the P-States that VoodooPower came up with for my machine. So, to correct this I used the P State Calculator available on the first post of the InsanelyMac thread by Mojodojo. If you temporarily load VoodooPower, it will spit out your _PSS for you and you can just put it into the DSDT. One word of caution though, it has problems calculating the CoreFreq with half multipliers (eg. 12.5x). You can correct this information with that from CPU-i. For more info on P-States, take a look here and here.

Vanilla Speedstep: C-States

I don't have C-States working yet, but I believe I'll have C1E and C2 working very soon. I'm not sure about C3 and beyond, but I think I know what is holding me up currently. I'll devote another post to this.

Miscellaneous Edits

The other DSDT edits I made were fairly small and came relatively easy. DSDTSE provides the code for nVidia injection, I just modified it for my NVS140M with an NVCAP from NVKush. I did the standard HDEF mod and coupled it with Brandon2004's LegacyAppleHDA. I added a firewire entry (In IOReg, Whatever@1,1 would have an _ADR of 0x00010001. Track down your device and adapt other DSDT device entries appropriately). And finally, I got a hold of a MacbookPro4,1 ioreg and modified my device names to match Apple's.

Final Comments

I'll be posting some more on DSDT in the coming days, but I also wanted to make mention that cleaning up your DSDT (before any mods) takes care of the D830 issue of AppleHPET knocking off the USB2.0 ports (which includes bluetooth). That means that if you can have AppleHPET, you can have AppleIntelCPUPowerManagement (even if you don't have vanilla speedstep yet), and therefore you can have sleep and your USB ports without using workaround solutions. Second thing I wanted to mention is that all these fixes work seamlessly into Snow Leopard in both 64 and 32bit. Great benefit of getting away from modifying kexts and instead using vanilla. Lastly, looks like sleep is a lot more stable and I don't get the sleepimage errors on boot anymore (go figure). So, to the more advanced this post didn't hold much (except for maybe info regarding Dell T9300 peculiarities), but hopefully it will help people in the position I was a couple weeks ago. It really does get a lot easier, looking at a DSDT now is wholly different than it was.

Stevo