At Thu, 9 Aug 2012 11:35:15 +0800, Chen Jie wrote:
Hi,
2012/8/3 Takashi Iwai tiwai@suse.de:
At Fri, 3 Aug 2012 18:36:40 +0800, Huacai Chen wrote:
We write these quirks on 2.6.36 some time ago, and then we port them to 3.x (3.2, 3.3, 3.4 and 3.5). As you say, PMON (BIOS for Loongson) doesn't set the pins correctly. Anyway, I'll try your suggestions.
Thanks. I guess it should work by just adding a new entry for your device in cxt_fixups[] containing the right default pin-configuration table, then point it in cxt5066_fixups[] with the corresponding PCI (or codec) SSID.
Takashi
I've found it is a little difficult to get proper pincfg values. The original patch builds 'input/output path' manually, the new way does it automatically as long as providing proper pincfgs for 'end points'.
I tried to copy related pincfgs from a workable lemote a1004 laptop(kernel with the original patch, read from /proc/asound/card0/codec#0), didn't help much.
It doesn't help because your old patch doesn't change the default pin-configuration values. It changes the pin-control values or amp values, but not the former one.
I guess the pincfgs are not correct, and on the platform, the pincfgs are not touched by BIOS, so I have to calculate proper pincfgs, how?
Just follow the HD-audio specification :)
HDA spec explains a pincfg as four bytes. For each byte, it has bits indicate amp/in/out/vref/ept.
No, you are referring to pin control bits. This has nothing to do with the pin default configuration. You must misunderstand the spec completely.
Read section 7.3.3.31 (page 179) for details.
Takashi
In the kernel side, it reads a pincfg and explains it as a 32bits flag, indicating connect/location/device/jack_connect_type/jack_color/misc/association/sequence.
Why they differ? How to get proper pincfg values?
Regards, -- Chen Jie