[PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13

[PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13

[David Henningsson]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

This Edge 13 model has an internal mic at 0x1a and should
therefore use the asus quirk.

Since my backport of the asus model is now tested and working, would it 
be possible to apply that patch as well as this quirk to 2.6.38?

Thanks Takashi for keeping up with all the patches coming in! :-)

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

[-- Attachment #2: 0001-ALSA-HDA-Fix-microphone-s-on-Lenovo-Edge-13.patch --]
[-- Type: text/x-patch, Size: 1307 bytes --]

>From c8c0ca221b4de97682d2e9e5ad73c0ac6346b398 Mon Sep 17 00:00:00 2001
From: David Henningsson <david.henningsson@canonical.com>
Date: Thu, 27 Jan 2011 10:28:46 +0100
Subject: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13

BugLink: http://bugs.launchpad.net/bugs/708521

This Edge 13 model has an internal mic at 0x1a and should
therefore use the asus quirk.

Signed-off-by: David Henningsson <david.henningsson@canonical.com>
---
 sound/pci/hda/patch_conexant.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
index 9867afc..7e1ca43 100644
--- a/sound/pci/hda/patch_conexant.c
+++ b/sound/pci/hda/patch_conexant.c
@@ -3120,6 +3120,7 @@ static struct snd_pci_quirk cxt5066_cfg_tbl[] = {
 	SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT5066_OLPC_XO_1_5),
 	SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo T400s", CXT5066_THINKPAD),
 	SND_PCI_QUIRK(0x17aa, 0x21c5, "Thinkpad Edge 13", CXT5066_THINKPAD),
+	SND_PCI_QUIRK(0x17aa, 0x21c6, "Thinkpad Edge 13", CXT5066_ASUS),
  	SND_PCI_QUIRK(0x17aa, 0x215e, "Lenovo Thinkpad", CXT5066_THINKPAD),
 	SND_PCI_QUIRK(0x17aa, 0x38af, "Lenovo G560", CXT5066_ASUS),
 	SND_PCI_QUIRK_VENDOR(0x17aa, "Lenovo", CXT5066_IDEAPAD), /* Fallback for Lenovos without dock mic */
-- 
1.7.1


[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13

[Takashi Iwai]

At Thu, 27 Jan 2011 10:37:02 +0100,
David Henningsson wrote:
> 
> >From c8c0ca221b4de97682d2e9e5ad73c0ac6346b398 Mon Sep 17 00:00:00 2001
> From: David Henningsson <david.henningsson@canonical.com>
> Date: Thu, 27 Jan 2011 10:28:46 +0100
> Subject: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13
> 
> BugLink: http://bugs.launchpad.net/bugs/708521
> 
> This Edge 13 model has an internal mic at 0x1a and should
> therefore use the asus quirk.
> 
> Signed-off-by: David Henningsson <david.henningsson@canonical.com>
> ---
>  sound/pci/hda/patch_conexant.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
> index 9867afc..7e1ca43 100644
> --- a/sound/pci/hda/patch_conexant.c
> +++ b/sound/pci/hda/patch_conexant.c
> @@ -3120,6 +3120,7 @@ static struct snd_pci_quirk cxt5066_cfg_tbl[] = {
>  	SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT5066_OLPC_XO_1_5),
>  	SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo T400s", CXT5066_THINKPAD),
>  	SND_PCI_QUIRK(0x17aa, 0x21c5, "Thinkpad Edge 13", CXT5066_THINKPAD),
> +	SND_PCI_QUIRK(0x17aa, 0x21c6, "Thinkpad Edge 13", CXT5066_ASUS),

Can 21c5 and 21c6 be incompatible models?
This should be merged, I guess.

I applided the patch but currently it's for 2.6.39 since CXT5066_ASUS
changes aren't queued for 2.6.38 (as non-trivial changes).

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.


thanks,

Takashi

Re: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13

[David Henningsson]

On 2011-01-28 09:01, Takashi Iwai wrote:
> At Thu, 27 Jan 2011 10:37:02 +0100,
> David Henningsson wrote:
>>
>> > From c8c0ca221b4de97682d2e9e5ad73c0ac6346b398 Mon Sep 17 00:00:00 2001
>> From: David Henningsson<david.henningsson@canonical.com>
>> Date: Thu, 27 Jan 2011 10:28:46 +0100
>> Subject: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13
>>
>> BugLink: http://bugs.launchpad.net/bugs/708521
>>
>> This Edge 13 model has an internal mic at 0x1a and should
>> therefore use the asus quirk.
>>
>> Signed-off-by: David Henningsson<david.henningsson@canonical.com>
>> ---
>>   sound/pci/hda/patch_conexant.c |    1 +
>>   1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
>> index 9867afc..7e1ca43 100644
>> --- a/sound/pci/hda/patch_conexant.c
>> +++ b/sound/pci/hda/patch_conexant.c
>> @@ -3120,6 +3120,7 @@ static struct snd_pci_quirk cxt5066_cfg_tbl[] = {
>>   	SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT5066_OLPC_XO_1_5),
>>   	SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo T400s", CXT5066_THINKPAD),
>>   	SND_PCI_QUIRK(0x17aa, 0x21c5, "Thinkpad Edge 13", CXT5066_THINKPAD),
>> +	SND_PCI_QUIRK(0x17aa, 0x21c6, "Thinkpad Edge 13", CXT5066_ASUS),
>
> Can 21c5 and 21c6 be incompatible models?

Good question. Seems like Manoj committed that one, I'll ask him about it.

> This should be merged, I guess.
>
> I applided the patch but currently it's for 2.6.39 since CXT5066_ASUS
> changes aren't queued for 2.6.38 (as non-trivial changes).

Sorry, I was under the impression that you would accept a backport for 
2.6.38, as you said in the earlier email?

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

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

Re: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13

[Takashi Iwai]

At Fri, 28 Jan 2011 12:51:30 +0100,
David Henningsson wrote:
> 
> On 2011-01-28 09:01, Takashi Iwai wrote:
> > At Thu, 27 Jan 2011 10:37:02 +0100,
> > David Henningsson wrote:
> >>
> >> > From c8c0ca221b4de97682d2e9e5ad73c0ac6346b398 Mon Sep 17 00:00:00 2001
> >> From: David Henningsson<david.henningsson@canonical.com>
> >> Date: Thu, 27 Jan 2011 10:28:46 +0100
> >> Subject: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13
> >>
> >> BugLink: http://bugs.launchpad.net/bugs/708521
> >>
> >> This Edge 13 model has an internal mic at 0x1a and should
> >> therefore use the asus quirk.
> >>
> >> Signed-off-by: David Henningsson<david.henningsson@canonical.com>
> >> ---
> >>   sound/pci/hda/patch_conexant.c |    1 +
> >>   1 files changed, 1 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
> >> index 9867afc..7e1ca43 100644
> >> --- a/sound/pci/hda/patch_conexant.c
> >> +++ b/sound/pci/hda/patch_conexant.c
> >> @@ -3120,6 +3120,7 @@ static struct snd_pci_quirk cxt5066_cfg_tbl[] = {
> >>   	SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT5066_OLPC_XO_1_5),
> >>   	SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo T400s", CXT5066_THINKPAD),
> >>   	SND_PCI_QUIRK(0x17aa, 0x21c5, "Thinkpad Edge 13", CXT5066_THINKPAD),
> >> +	SND_PCI_QUIRK(0x17aa, 0x21c6, "Thinkpad Edge 13", CXT5066_ASUS),
> >
> > Can 21c5 and 21c6 be incompatible models?
> 
> Good question. Seems like Manoj committed that one, I'll ask him about it.
> 
> > This should be merged, I guess.
> >
> > I applided the patch but currently it's for 2.6.39 since CXT5066_ASUS
> > changes aren't queued for 2.6.38 (as non-trivial changes).
> 
> Sorry, I was under the impression that you would accept a backport for 
> 2.6.38, as you said in the earlier email?

Ah, no.  I didn't mean that.  Sorry not being clear enough.

Moving the commits from 2.6.39 tree is possible but a bit mess
because of rebase, thus I'd like to avoid it, unless it's urgently
needed.

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


thanks,

Takashi

Re: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13

[David Henningsson]

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:
>>> At Thu, 27 Jan 2011 10:37:02 +0100,
>>> David Henningsson wrote:
>>>>
>>>>>  From c8c0ca221b4de97682d2e9e5ad73c0ac6346b398 Mon Sep 17 00:00:00 2001
>>>> From: David Henningsson<david.henningsson@canonical.com>
>>>> Date: Thu, 27 Jan 2011 10:28:46 +0100
>>>> Subject: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13
>>>>
>>>> BugLink: http://bugs.launchpad.net/bugs/708521
>>>>
>>>> This Edge 13 model has an internal mic at 0x1a and should
>>>> therefore use the asus quirk.
>>>>
>>>> Signed-off-by: David Henningsson<david.henningsson@canonical.com>
>>>> ---
>>>>    sound/pci/hda/patch_conexant.c |    1 +
>>>>    1 files changed, 1 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
>>>> index 9867afc..7e1ca43 100644
>>>> --- a/sound/pci/hda/patch_conexant.c
>>>> +++ b/sound/pci/hda/patch_conexant.c
>>>> @@ -3120,6 +3120,7 @@ static struct snd_pci_quirk cxt5066_cfg_tbl[] = {
>>>>    	SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT5066_OLPC_XO_1_5),
>>>>    	SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo T400s", CXT5066_THINKPAD),
>>>>    	SND_PCI_QUIRK(0x17aa, 0x21c5, "Thinkpad Edge 13", CXT5066_THINKPAD),
>>>> +	SND_PCI_QUIRK(0x17aa, 0x21c6, "Thinkpad Edge 13", CXT5066_ASUS),
>>>
>>> Can 21c5 and 21c6 be incompatible models?
>>
>> Good question. Seems like Manoj committed that one, I'll ask him about it.

I followed the buglink for Manoj's commit and found an internal mic at 
node 0x1a, so it's likely it should be changed to the asus model.

>>
>>> This should be merged, I guess.
>>>
>>> I applided the patch but currently it's for 2.6.39 since CXT5066_ASUS
>>> changes aren't queued for 2.6.38 (as non-trivial changes).
>>
>> Sorry, I was under the impression that you would accept a backport for
>> 2.6.38, as you said in the earlier email?
>
> Ah, no.  I didn't mean that.  Sorry not being clear enough.
>
> Moving the commits from 2.6.39 tree is possible but a bit mess
> because of rebase, thus I'd like to avoid it, unless it's urgently
> needed.

Well, that's up to you - from my/Ubuntu's perspective, it's important to 
have it in 2.6.38 (Ubuntu 11.04 will have kernel 2.6.38), so if you 
don't, I'll just apply it downstream instead, in the Ubuntu kernel.

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

Re: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13

[Andy Robinson]

On Fri, Jan 28, 2011 at 3:01 AM, Takashi Iwai <tiwai@suse.de> 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.

The parsing code that was put in place for the CX206xx almost works
for the cxt5066 as well, except that it does not handle inputs
connected to the audio selector. Would it be better to add more
auto-configuration to the cxt5066 code, or to enhance the CX206xx code
to make it work with the cxt5066? I suppose the cxt5066 code is more
mature at this point, so enhancing the cxt5066 code might have less
risk of breaking something.

Also, it looks like there's a bug in cx_auto_check_auto_mic. Both "if"
statements are checking if cfg->inputs[0].pin is an external mic and
cfg->inputs[1].pin is an internal mic. The first one should be doing
the opposite.

Re: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13

[Takashi Iwai]

At Fri, 28 Jan 2011 13:40:34 +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:
> >>> At Thu, 27 Jan 2011 10:37:02 +0100,
> >>> David Henningsson wrote:
> >>>>
> >>>>>  From c8c0ca221b4de97682d2e9e5ad73c0ac6346b398 Mon Sep 17 00:00:00 2001
> >>>> From: David Henningsson<david.henningsson@canonical.com>
> >>>> Date: Thu, 27 Jan 2011 10:28:46 +0100
> >>>> Subject: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13
> >>>>
> >>>> BugLink: http://bugs.launchpad.net/bugs/708521
> >>>>
> >>>> This Edge 13 model has an internal mic at 0x1a and should
> >>>> therefore use the asus quirk.
> >>>>
> >>>> Signed-off-by: David Henningsson<david.henningsson@canonical.com>
> >>>> ---
> >>>>    sound/pci/hda/patch_conexant.c |    1 +
> >>>>    1 files changed, 1 insertions(+), 0 deletions(-)
> >>>>
> >>>> diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
> >>>> index 9867afc..7e1ca43 100644
> >>>> --- a/sound/pci/hda/patch_conexant.c
> >>>> +++ b/sound/pci/hda/patch_conexant.c
> >>>> @@ -3120,6 +3120,7 @@ static struct snd_pci_quirk cxt5066_cfg_tbl[] = {
> >>>>    	SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT5066_OLPC_XO_1_5),
> >>>>    	SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo T400s", CXT5066_THINKPAD),
> >>>>    	SND_PCI_QUIRK(0x17aa, 0x21c5, "Thinkpad Edge 13", CXT5066_THINKPAD),
> >>>> +	SND_PCI_QUIRK(0x17aa, 0x21c6, "Thinkpad Edge 13", CXT5066_ASUS),
> >>>
> >>> Can 21c5 and 21c6 be incompatible models?
> >>
> >> Good question. Seems like Manoj committed that one, I'll ask him about it.
> 
> I followed the buglink for Manoj's commit and found an internal mic at 
> node 0x1a, so it's likely it should be changed to the asus model.
> 
> >>
> >>> This should be merged, I guess.
> >>>
> >>> I applided the patch but currently it's for 2.6.39 since CXT5066_ASUS
> >>> changes aren't queued for 2.6.38 (as non-trivial changes).
> >>
> >> Sorry, I was under the impression that you would accept a backport for
> >> 2.6.38, as you said in the earlier email?
> >
> > Ah, no.  I didn't mean that.  Sorry not being clear enough.
> >
> > Moving the commits from 2.6.39 tree is possible but a bit mess
> > because of rebase, thus I'd like to avoid it, unless it's urgently
> > needed.
> 
> Well, that's up to you - from my/Ubuntu's perspective, it's important to 
> have it in 2.6.38 (Ubuntu 11.04 will have kernel 2.6.38), so if you 
> don't, I'll just apply it downstream instead, in the Ubuntu kernel.

OK, I merged all the pending conexant fixes back to fix/hda branch
for 2.6.38 tree, as fortunately there have been only clean fixes in
topic/hda branch so far.  It'll be included in the next pull request
to Linus.


thanks,

Takashi

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

[David Henningsson]

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

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?

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 (?).

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

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

Re: Codecs without auto-parser

[David Henningsson]

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

Re: Codecs without auto-parser

[Takashi Iwai]

At Wed, 02 Feb 2011 16:16:21 +0100,
David Henningsson wrote:
> 
> 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? :-)

The reality is bitter, you know :)

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

Well, Conexant auto-parser is a fairly recent one I wrote, so it's
more or less generic.  But there are still a few glitches that
Conexant parser doesn't handle properly, IIRC.

We can give it a try with different codecs using hda-emu to see what
doesn't fit.

> 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?

My initial idea was to adapt the current Conexant parser for 5066.
If it doesn't work by some reason, adjust the code, then replaces the
model quirks with the pin-config presets.

However, OLPC is a big exception.  So, this will likely stay as is.


thanks,

Takashi

Re: Codecs without auto-parser

[David Henningsson]

On 2011-02-03 14:16, Takashi Iwai wrote:
> At Wed, 02 Feb 2011 16:16:21 +0100,
> David Henningsson wrote:
>>
>> 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? :-)
>
> The reality is bitter, you know :)
>
>> 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.)
>
> Well, Conexant auto-parser is a fairly recent one I wrote, so it's
> more or less generic.  But there are still a few glitches that
> Conexant parser doesn't handle properly, IIRC.
>
> We can give it a try with different codecs using hda-emu to see what
> doesn't fit.
>
>> 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?
>
> My initial idea was to adapt the current Conexant parser for 5066.
> If it doesn't work by some reason, adjust the code, then replaces the
> model quirks with the pin-config presets.

Ok. While waiting for your answer I continued thinking and writing a 
little code - here's how I would see a generic version of auto_parse_output:

1) Make a breadth-first-search, starting at each (output) pin, to find 
what DACs are reachable from each pin.

2) Start assigning DACs to pins, start off with line-outs (similar to 
what cx_auto does today). If HP's and Speakers can't have their own 
DACs, they'll have to share with their line-out counterpart (usually Front).

3) Investigate path from pin to DAC and add mute switches as close to 
the pin:s as possible.

4) Add volume controls on all capable widgets that are a part of the 
path. For 3 and 4 the naming must be decided based on what paths they 
are a part of.

(On top of that, add a quirk system that works with snd_hda_codec_read 
so that any command can be overridden to returned a fixed value instead. 
That quirk system could then be used to not only override pin configs 
but also remove paths so the above algorithm does not discover them, and 
other things.)

What do you think? Maybe I should give up these thoughts for now and 
just go with your suggestion...but then I would still have to fix that 
model for AD1984a...

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