where do values in pinconfigurations in DSDT table come from?

[pink101]

I'm trying to figure out where does the values in pinconfigurations in DSDT come from. In this thread i found some DSDT patch that directly inject PinConfiguration values to DSDT

            "PinConfigurations", 
                            Buffer (0x38)
                            {
                                /* 0000 */    0x40, 0x01, 0x43, 0x99, 0xF0, 0x11, 0x11, 0x41, 
                                /* 0008 */    0x10, 0x40, 0x01, 0x01, 0x12, 0x10, 0x01, 0x01, 
                                /* 0010 */    0x11, 0x60, 0x01, 0x01, 0x14, 0x20, 0x01, 0x01, 
                                /* 0018 */    0x01, 0x50, 0x98, 0xA1, 0x01, 0x60, 0x9C, 0xA1, 
                                /* 0020 */    0x02, 0x5F, 0x30, 0x81, 0x01, 0x20, 0x4C, 0x21, 
                                /* 0028 */    0x02, 0xF0, 0x11, 0x11, 0x41, 0x01, 0xE6, 0x05, 
                                /* 0030 */    0x40, 0x30, 0x61, 0x45, 0x01, 0xF0, 0x11, 0x11
                            }

because i think it's not the same as DataConfig value you put inside AppleHDAHardwareConfiguration.kext because if i put this into PinConfigurator.app , it cannot parse the data, unlike the DataConfig that we put on AppleHDAHardwareConfiguration.kext which can be parsed using PinConfigurator.app

 

So.. my question is where does this values comes from?

[pink101]

The info is derived from a dump of the audio codec, something usually done through Linux line commands.

http://forum.osxlatitude.com/index.php?/topic/1946-complete-applehda-patching-guide/

 

the link you provide shows how to get verb commands from linux codec dump, however, the final result of the verb commands always start with codec address, for example, in the link above, the codec address is at 0 , so, all the verb command start with 0, however, the DSDT patch above start at different value each line, so it can't be a verb command...

[wern apfel]

I'm trying to figure out where does the values in pinconfigurations in DSDT come from. In this thread i found some DSDT patch that directly inject PinConfiguration values to DSDT

            "PinConfigurations", 
                            Buffer (0x38)
                            {
                                /* 0000 */    0x40, 0x01, 0x43, 0x99, 0xF0, 0x11, 0x11, 0x41, 
                                /* 0008 */    0x10, 0x40, 0x01, 0x01, 0x12, 0x10, 0x01, 0x01, 
                                /* 0010 */    0x11, 0x60, 0x01, 0x01, 0x14, 0x20, 0x01, 0x01, 
                                /* 0018 */    0x01, 0x50, 0x98, 0xA1, 0x01, 0x60, 0x9C, 0xA1, 
                                /* 0020 */    0x02, 0x5F, 0x30, 0x81, 0x01, 0x20, 0x4C, 0x21, 
                                /* 0028 */    0x02, 0xF0, 0x11, 0x11, 0x41, 0x01, 0xE6, 0x05, 
                                /* 0030 */    0x40, 0x30, 0x61, 0x45, 0x01, 0xF0, 0x11, 0x11
                            }

because i think it's not the same as DataConfig value you put inside AppleHDAHardwareConfiguration.kext because if i put this into PinConfigurator.app , it cannot parse the data, unlike the DataConfig that we put on AppleHDAHardwareConfiguration.kext which can be parsed using PinConfigurator.app

 

So.. my question is where does this values comes from?

Your DSDT snippet shows you only the parameters, while the DataConfig consists of codec address, nid, verb and parameter.

 

For example: 0x40, 0x01, 0x43, 0x99

 

0x40 association, sequence

0x01 color, misc 

0x43 device, conn type

0x99 connectivity + location

[pink101]

Your DSDT snippet shows you only the parameters, while the DataConfig consists of codec address, nid, verb and parameter.

 

For example: 0x40, 0x01, 0x43, 0x99

 

0x40 association, sequence

0x01 color, misc 

0x43 device, conn type

0x99 connectivity + location

 

 

thank's... i'm starting to get it now...

[pink101]

You can always Google for "AppleHDA pin configuration". Yes... homework... 

 

http://www.insanelymac.com/forum/topic/137188-how-to-pin-config/

http://osxarena.com/2015/03/best-all-in-one-patch-applehda-guide/

https://www.osx86.net/forums/topic/22108-guide-how-to-fix-the-applehda-for-your-codec/

http://olarila.com/forum/viewtopic.php?f=28&t=2676

https://rampagedev.wordpress.com/kext-editing/applehda-kext-alpha/

 

Now if Pin configurations ain't coming from a codec dump, I don't know what does.

 

i'm asking this because my chipset is ATI/AMD and patching kext didn't work at all, the appleHDA kext didn't even load, and in the link on my first post, people with ATI/AMD chipset was trying to put the PinConfiguration directily to the DSDT and it look like at least they can make the appleHDA kext to load even if there's still no sound. But i still confuse how do they get the values, now i know how...

On Intel based chipset we can just find the suitable ALC patch and done, but in ATI/AMD it doesn't seem to work... On other DSDT examples, the PinConfigurations snippet usually blank, but in the link in my first post, they directly put the values.

 

maybe i miss something in those link you gave, but i think this is the first time i know/read that the values in DSDT is only the parameter. thank's btw....