At Thu, 9 Aug 2012 11:35:15 +0800, Chen Jie wrote: > > Hi, > > 2012/8/3 Takashi Iwai <tiwai@xxxxxxx>: > > 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 >
