[alsa-devel] Codecs without auto-parser (was: ALSA: HDA: Fix microphone(s) on Lenovo Edge 13)

[Takashi Iwai]

At Tue, 01 Feb 2011 08:37:25 +0100,
David Henningsson wrote:
> 
> On 2011-01-28 13:10, Takashi Iwai wrote:
> > At Fri, 28 Jan 2011 12:51:30 +0100,
> > David Henningsson wrote:
> >>
> >> On 2011-01-28 09:01, Takashi Iwai wrote:
> >>> And I hope that we should go further a bit for now -- more clean up of
> >>> the cxt5066 code either checking BIOS pins or hp/mic/spk pre-defined
> >>> pins.  Currently, the code is fairly messy (partly because of olpc
> >>> support), and now is a good chance to improve it a bit more.
> >>
> >> Maybe so. I'm not sure I can commit to doing that work right now, as I
> >> have other work commitments waiting for me to take care of them.
> >
> > OK.
> 
> Hmm. I got a few things cleared up yesterday, and so I might have some 
> time to actually do this.

Great.

> However, it also seems like I have to fix an 
> AD1984A machine, and that driver is in equally bad shape (as in: no 
> auto-parser, just a list of models).

Yeah, I know...

> I could add another model, but 
> suppose I'd do this the right way, how would I do it?
> 
> I guess there are three options to start off with:
> 
> 1) ad1988 seems to have an auto-parser. There are a lot of hardcoded 
> nids in there, but I guess I could copy-and-paste some into a new 
> auto-parser for ad1984a.

Well... AD1988 and AD1984A aren't so similar, IIRC.
AD1984A is more straightforward hardware implementation while AD1988
can have more connections.  Also AD1988 auto-parser isn't in the best
form in comparison with other codecs.

That being said, if AD1984A can fit with AD1988's auto-parser (i.e.
my memory was too vague), it's fine.  We can adapt it.

If this is hard, one more quirk model won't be too bad for AD1984A
since this is a pretty simple codec, and there won't be so more devices
with this old chip.

> 2) It seems to me like the most competent candidate for auto-parser 
> currently is the cx_auto stuff - compared to other auto-parsers the 
> hardcoded nids are fewer. Perhaps this one could be extended to also do 
> auto-parsing for codecs from other vendors? Or at least some convenience 
> functions moved to hda_codec.c in order to remove duplication between 
> vendors?

Yes, I can loudly tell people "I have a dream, unify all codec parsers!" :)
But, I'm afraid that a big hammer doesn't work.  The topology is fairly
different between codecs, and resolving all makes the parser complex.
So, some hints would be needed to simplify the logic, after all.

> 3) There is also the generic parser. It seems to be the one most capable 
> of handling randomly complex graphs, but is lacking automute/jack-detect 
> support, and maybe other functions as well (?).

The generic parser is the very first parser, and it never worked rightly.
This should be really replaced with a more clever one.


thanks,

Takashi