[alsa-devel] Codecs without auto-parser
david.henningsson at canonical.com
Wed Feb 2 16:16:21 CET 2011
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.
>> Hmm. I got a few things cleared up yesterday, and so I might have some
>> time to actually do this.
>> 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.
Ok. I had one more look at AD1988's auto-parser and I don't think it's
good to start off that one.
>> 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
> 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.
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
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?
David Henningsson, Canonical Ltd.
More information about the Alsa-devel