Explanation of Power Manager and Speedstep Modification for DC7800 and DC7900

[pete...@cruzio.com]

The DSDTSE application contains this hint in re: the HPET device and
Speedstep (the following text is directly from the DSDTSE hint):

HPET FIX

This fix allows us to load the driver Appleintelcpupowermanagement.kext,
and in that way have the option to use the native speedstep available in
osx

This is the HPET code from a Mac:


Device (HPET)
{
Name (_HID, EisaId ("PNP0103"))
Name (BUF0, ResourceTemplate ()
{
IRQNoFlags ()
{0}
IRQNoFlags ()
{8}
Memory32Fixed (ReadOnly,
0xFED00000, // Address Base
0x00000400, // Address Length
_Y09)
})


This is the HPET code from a PC:


Device (HPET)
{
Name (_HID, EisaId ("PNP0103"))
Name (_CID, EisaId ("PNP0C01"))
Name (BUF0, ResourceTemplate ()
{
Memory32Fixed (ReadOnly,
0xFED00000, // Address Base
0x00000400, // Address Length
_Y0F)
})

We only have to add the "Irqnoflags" and that would fix it.

IRQNoFlags ()
{0}
IRQNoFlags ()
{8}


After adding "Irqnoflags", here is what it would look like on your DSDT:


Device (HPET)
{
Name (_HID, EisaId ("PNP0103"))
Name (_CID, EisaId ("PNP0C01"))
Name (BUF0, ResourceTemplate ()
{
IRQNoFlags ()
{0}
IRQNoFlags ()
{8}
Memory32Fixed (ReadOnly,
0xFED00000, // Address Base
0x00000400, // Address Length
_Y0F)
})


However, for the DC7800 and DC7900, I implemented it in this way:

Device (HPET)
{
Name (_HID, EisaId ("PNP0103"))
Name (_CID, EisaId ("PNP0C01"))
Name (_UID, One)
Name (BUF6, ResourceTemplate ()
{
IRQNoFlags ()
{0}
IRQNoFlags ()
{8}
Memory32Fixed (ReadWrite,
0x00000000, // Address Base
0x00000000, // Address Length
_Y09)
})
Method (_CRS, 0, NotSerialized)
{
CreateDWordField (BUF6, \_SB.PCI0.LPCB.HPET._Y09._BAS, BASE)
CreateDWordField (BUF6, \_SB.PCI0.LPCB.HPET._Y09._LEN, LNTH)
Store (HPTB, BASE)
Store (0x0400, LNTH)
Return (BUF6)
}

Method (_STA, 0, NotSerialized)
{
Return (0x0F)
}
}

You can see that there are some differences, but, in the main, the change
is pretty much the same.

In this way, the Appleintelcpupowermanagement.kext is used and native
Speedstep is honored.

Also, why the /Extra folder contains no NullIntelPowerManagement kext or
other ersatz hacks. In fact, the only contents of my /Extra folder are:
FakeSMC and PXHCD.

My goal was to make the DC7800/DC7900 as Mac-like as was possible.


Although I am presently using Voodoo 0.2.1 for sound, I am not completely
pleased with it.

When it works, it works well.

When it doesn't work, you have no sound at all.

When it KPs, it really spoils your day.

My belief is the best solution is to hack the AppleHDA kext to support the
AD codec.

Alas, Taruga's AppleHDA Patcher application does not know about the
DC7800/DC7900 codec (although it DOES know about earlier AD codecs).

[mosslack]

On Oct 8, 2012, at 1:49 PM, pete...@cruzio.com wrote:

My belief is the best solution is to hack the AppleHDA kext to support the
AD codec.

Alas, Taruga's AppleHDA Patcher application does not know about the
DC7800/DC7900 codec (although it DOES know about earlier AD codecs).

Is is possible that the codec would work if it were correctly mapped as to I/O? IOW perhaps an earlier AD hacked AppleHDA would work if the input and output devices/ports were correctly identified?

From the main system of mosslack...

______________________________

Alt-OS <+> GG <+> TBIE <+> Hack List

[pete...@cruzio.com]

>> Alas, Taruga's AppleHDA Patcher application does not know about the
>> DC7800/DC7900 codec (although it DOES know about earlier AD codecs).
>
> Is is possible that the codec would work if it were correctly mapped as to
> I/O? IOW perhaps an earlier AD hacked AppleHDA would work if the input and
> output devices/ports were correctly identified?

Possible, but I don't have any specific information on that.

When I presented Taruga's application with a DC7800/DC7900 codec dump,
obtained using Ubuntu, it said the codec was NOT SUPPORTED.