On 2011-02-01 22:34, Takashi Iwai wrote:
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:
- 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.
Ok. I had one more look at AD1988's auto-parser and I don't think it's good to start off that one.
- 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.
- 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.
Hrmm...am I the only one thinking that your answer to 2) and 3) are in direct contradiction? :-)
I'm looking at fill_cx_auto_dacs. That doesn't look like Conexant specific stuff at all. cx_auto_hp_automute looks quite generic as well, except for a pointer deref in the beginning. cx_auto_build_output_controls could be merged with xxxx_create_multi_out_ctls present in the Realtek and Analog parsers. And so on.
Shouldn't we move and rename fill_cx_auto_dacs to hda_codec.c and use it for all codecs, instead of hardcoding dac nids everywhere? At least in general? (There might be exceptions, where there is a dac you don't want to use.)
Anyway, you wanted some work done to Conexant 5066. Could you clarify that a little? You likely want to call snd_hda_parse_pin_def_config - but are you expecting yet another auto-parser after that? Or just to choose model based on the result? And should we remove all the model quirks (except possibly for OLPC) afterwards?