Conexant CX20582 HDA codec support

Conexant CX20582 HDA codec support

[Daniel Drake]

Hi,

I'm working on some sound issues with the new OLPC XO-1.5 alpha board.
This laptop is now based on a VIA VX855 chipset and our board includes a
CX20582-10Q HDA codec. We are running kernel v2.6.30.

We have a few issues, which are:

1. Volume range is ridiculous, you can go all the way down to -74dB
gain.  Beyond -42dB you can barely hear anything from the speakers, and
I note that all my other systems only go down as far as -46.5dB.

2. No microphone automute. The internal microphone continues recording
sound while there is an external one plugged in.

3. No speaker automute. The internal speakers continue playing sound
while there are headphones plugged in.

4. Mixer arrangement is odd. There are 3 microphones: Mic, Mic 1, and
Mic 2. Mic (the default) records nothing. Mic 1 and Mic 2 both seem to
behave the same, and record from both internal and external microphones.


I looked into adding some quirks into patch_conexant.c to hopefully
solve some of the above. However I note that there is no support for the
CX20582, hence the generic HDA parser is being used. How has support for
the other CX chips been developed -- are datasheets always required?
(I'll try and get hold of one anyway)

Here is some more info.
codec dump
http://dev.laptop.org/~dsd/20090629/codec0.txt

codec graph
http://dev.laptop.org/~dsd/20090629/codecgraph.svg

lspci entry
http://dev.laptop.org/~dsd/20090629/lspci-entry.txt

verbose dmesg from probing
http://dev.laptop.org/~dsd/20090629/dmesg-probe.txt


Any thoughts/input appreciated!
Thanks,
Daniel

Re: Conexant CX20582 HDA codec support

[Mark Brown]

On Mon, Jun 29, 2009 at 01:10:53PM +0100, Daniel Drake wrote:

> 1. Volume range is ridiculous, you can go all the way down to -74dB
> gain.  Beyond -42dB you can barely hear anything from the speakers, and
> I note that all my other systems only go down as far as -46.5dB.

This is normally just a case of drivers exposing whatever control they
get from the hardware.  Devices will often expose very high degrees of
attenuation since they're doing it anyway in order to implement the mute
functionality.

Re: Conexant CX20582 HDA codec support

[Takashi Iwai]

At Mon, 29 Jun 2009 13:26:26 +0100,
Mark Brown wrote:
> 
> On Mon, Jun 29, 2009 at 01:10:53PM +0100, Daniel Drake wrote:
> 
> > 1. Volume range is ridiculous, you can go all the way down to -74dB
> > gain.  Beyond -42dB you can barely hear anything from the speakers, and
> > I note that all my other systems only go down as far as -46.5dB.
> 
> This is normally just a case of drivers exposing whatever control they
> get from the hardware.  Devices will often expose very high degrees of
> attenuation since they're doing it anyway in order to implement the mute
> functionality.

Yep.  There are some workaround for each codec chip.
See create_controls_idx() in patch_sigmatel.c, for example.


Takashi

Re: Conexant CX20582 HDA codec support

[Takashi Iwai]

At Mon, 29 Jun 2009 13:10:53 +0100,
Daniel Drake wrote:
> 
> Hi,
> 
> I'm working on some sound issues with the new OLPC XO-1.5 alpha board.
> This laptop is now based on a VIA VX855 chipset and our board includes a
> CX20582-10Q HDA codec. We are running kernel v2.6.30.
> 
> We have a few issues, which are:
> 
> 1. Volume range is ridiculous, you can go all the way down to -74dB
> gain.  Beyond -42dB you can barely hear anything from the speakers, and
> I note that all my other systems only go down as far as -46.5dB.
> 
> 2. No microphone automute. The internal microphone continues recording
> sound while there is an external one plugged in.

The generic parser doesn't support this.  It gives only a few basic
functionalities, so far.

> 3. No speaker automute. The internal speakers continue playing sound
> while there are headphones plugged in.

Ditto.

> 4. Mixer arrangement is odd. There are 3 microphones: Mic, Mic 1, and
> Mic 2. Mic (the default) records nothing. Mic 1 and Mic 2 both seem to
> behave the same, and record from both internal and external microphones.

A similar issue.  Likely a problem of the generic parser.

> I looked into adding some quirks into patch_conexant.c to hopefully
> solve some of the above. However I note that there is no support for the
> CX20582, hence the generic HDA parser is being used. How has support for
> the other CX chips been developed -- are datasheets always required?

Ideally, yes.
If the codec tree looks similar as other Conexant codecs, you can adapt
patch_conexant.c...


Takashi

Re: Conexant CX20582 HDA codec support

[Daniel Drake]

Hi,

On Mon, 2009-06-29 at 14:50 +0200, Takashi Iwai wrote:
> Ideally, yes.
> If the codec tree looks similar as other Conexant codecs, you can adapt
> patch_conexant.c...


Thanks for the quick explanations to all my issues. Makes sense.

Our contacts at Conexant pointed us to this file:
http://www.linuxant.com/alsa-driver/alsa-driver-linuxant-1.0.19ppch12-1.noarch.rpm.zip

The patch_conexant.c inside includes support for CX20582 ("Pebble") and
a few more. Complete list:

	{ .id = 0x14f15061, .name = "CX2058? (Pebble)",
	  .patch = patch_cxtppch },
	{ .id = 0x14f15066, .name = "CX20582 (Pebble)",
	  .patch = patch_cxtppch },
	{ .id = 0x14f15067, .name = "CX20583 (Pebble 56-LQFP)",
	  .patch = patch_cxtppch },
	{ .id = 0x14f15068, .name = "CX20584 (Pebble)",
	  .patch = patch_cxtppch },
	{ .id = 0x14f15069, .name = "CX20585 (Pebble 56-QFN)",
	  .patch = patch_cxtppch },
	{ .id = 0x14f15070, .name = "CX20592 (Pelican)",
	  .patch = patch_cxtppch },
	{ .id = 0x14f15071, .name = "CX20593 (Pelican 56-LQFP)",
	  .patch = patch_cxtppch },
	{ .id = 0x14f15072, .name = "CX20594 (Pelican)",
	  .patch = patch_cxtppch },
	{ .id = 0x14f15073, .name = "CX20595 (Pelican 56-QFN)",
	  .patch = patch_cxtppch },
	{ .id = 0x14f15074, .name = "CX2059? (Pelican)",
	  .patch = patch_cxtppch },
	{ .id = 0x14f150D0, .name = "CX20688 (Cabo)",
	  .patch = patch_cxtppch },
	{ .id = 0x14f150D4, .name = "CX20692 (Huntington)",
	  .patch = patch_cxtppch },
	{ .id = 0x14f150D5, .name = "CX20693 (Huntington)",
	  .patch = patch_cxtppch },
	{ .id = 0x14f150D6, .name = "CX20694 (Huntington)",
	  .patch = patch_cxtppch },
	{ .id = 0x14f150D7, .name = "CX20695 (Huntington)",
	  .patch = patch_cxtppch },
	{ .id = 0x14f12bfa, .mfg = 2, .name = "HSF",
	  .patch = patch_cxthsfmodem },
	{ .id = 0x14f12c06, .mfg = 2, .name = "HSF",
	  .patch = patch_cxthsfmodem },
	{ .id = 0x14f10000, .mask = 0xffff0000, .mfg = 2, .name = "HSF",
	  .patch = patch_cxthsfmodem },

Perhaps a useful link to keep around in future if other people come
along looking for new codec support...

Over the next few days, I plan to extract the CX20584 support, get it
working on the XO-1.5 and then send you a patch.

Thanks,
Daniel

Re: Conexant CX20582 HDA codec support

[Tony Vroon]

[-- Attachment #1.1: Type: text/plain, Size: 539 bytes --]

On Tue, 2009-06-30 at 19:48 +0100, Daniel Drake wrote:
> Our contacts at Conexant pointed us to this file:
> http://www.linuxant.com/alsa-driver/alsa-driver-linuxant-1.0.19ppch12-1.noarch.rpm.zip
> 
> The patch_conexant.c inside includes support for CX20582 ("Pebble") and
> a few more.

Daniel, if the license is favourable I'd rather extract it all.
Is it alright if I have a look at this for you on Thursday? (I might
have time tomorrow but I can't guarantee it; I'll be in data centres
most of the day)

Regards,
Tony V.

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: 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: Conexant CX20582 HDA codec support

[Daniel Drake]

On Tue, 2009-06-30 at 20:23 +0100, Tony Vroon wrote:
> Daniel, if the license is favourable I'd rather extract it all.
> Is it alright if I have a look at this for you on Thursday? (I might
> have time tomorrow but I can't guarantee it; I'll be in data centres
> most of the day)

Please go ahead :)
The code will need a little clean up, I think.

Daniel

Re: Conexant CX20582 HDA codec support

[Daniel Drake]

Hi,

On Mon, 2009-06-29 at 14:48 +0200, Takashi Iwai wrote:
> At Mon, 29 Jun 2009 13:26:26 +0100,
> Mark Brown wrote:
> > 
> > On Mon, Jun 29, 2009 at 01:10:53PM +0100, Daniel Drake wrote:
> > 
> > > 1. Volume range is ridiculous, you can go all the way down to -74dB
> > > gain.  Beyond -42dB you can barely hear anything from the speakers, and
> > > I note that all my other systems only go down as far as -46.5dB.
> > 
> > This is normally just a case of drivers exposing whatever control they
> > get from the hardware.  Devices will often expose very high degrees of
> > attenuation since they're doing it anyway in order to implement the mute
> > functionality.
> 
> Yep.  There are some workaround for each codec chip.
> See create_controls_idx() in patch_sigmatel.c, for example.

Great.
Do you have any other examples?
This does not seem so easy for a non-virtual master.

This is my kcontrol for master:
	HDA_CODEC_VOLUME("Master Playback Volume", 0x10, 0x00, HDA_OUTPUT),

Thanks,
Daniel

Re: Conexant CX20582 HDA codec support

[Takashi Iwai]

At Fri, 03 Jul 2009 21:05:37 +0100,
Daniel Drake wrote:
> 
> Hi,
> 
> On Mon, 2009-06-29 at 14:48 +0200, Takashi Iwai wrote:
> > At Mon, 29 Jun 2009 13:26:26 +0100,
> > Mark Brown wrote:
> > > 
> > > On Mon, Jun 29, 2009 at 01:10:53PM +0100, Daniel Drake wrote:
> > > 
> > > > 1. Volume range is ridiculous, you can go all the way down to -74dB
> > > > gain.  Beyond -42dB you can barely hear anything from the speakers, and
> > > > I note that all my other systems only go down as far as -46.5dB.
> > > 
> > > This is normally just a case of drivers exposing whatever control they
> > > get from the hardware.  Devices will often expose very high degrees of
> > > attenuation since they're doing it anyway in order to implement the mute
> > > functionality.
> > 
> > Yep.  There are some workaround for each codec chip.
> > See create_controls_idx() in patch_sigmatel.c, for example.
> 
> Great.
> Do you have any other examples?
> This does not seem so easy for a non-virtual master.
> 
> This is my kcontrol for master:
> 	HDA_CODEC_VOLUME("Master Playback Volume", 0x10, 0x00, HDA_OUTPUT),

Well, currently only patch_sigmatel.c uses the workaround.
But, it's relatively easy.  Define the element like

	{
	  .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
	  .name = "Master Playback Volume",
	  .access = SNDRV_CTL_ELEM_ACCESS_READWRITE |
	  	    SNDRV_CTL_ELEM_ACCESS_TLV_READ |
	  	    SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK,
	  .info = snd_hda_mixer_amp_volume_info,
	  .get = snd_hda_mixer_amp_volume_get,
	  .put = snd_hda_mixer_amp_volume_put,
	  .tlv = { .c = snd_hda_mixer_amp_tlv },
	  .private_value =
		HDA_COMPOSE_AMP_VAL_OFS(0x10, 3, 0, HDA_OUTPUT, 0x30),
	}

This is almost a plain expansion of HDA_CODE_VOLUME() macro except for
the private_value field.  It uses HDA_COMPOSE_AMP_VAL_OFS() instead.
The last argument (0x30) is the offset of the volume steps.  That is,
if the volume has 127 steps (0x7f) and you want to set the lower limit
to 0x30.  Then pass 0x30 there.

The upper limit of the volume steps can be changed by
snd_hda_override_amp_caps(), BTW.


Takashi