Re: Codecs without auto-parser

[David Henningsson <david.henningsson@canonical.com>]

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:
>>
>> 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
>> 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.

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?

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic