Re: ASoC: wm9712: Microphone doesn't work, "Capture Volume" inverted

On Fri, May 04, 2012 at 03:28:45PM +0200, Christoph Fritz wrote:

On Fri, Apr 27, 2012 at 02:46:39PM +0100, Mark Brown wrote:

quoted

On Fri, Apr 27, 2012 at 10:00:02AM +0200, Christoph Fritz wrote:

quoted

On Thu, 2012-04-26 at 22:37 +0100, Mark Brown wrote:

quoted

quoted

  The write will be suppresed if the register contents don't
change which looks like what you're seeing here - 

quoted

Can you imagine why the registers don't change?

I can't immediately think of any reason, no - I'd step through or
annotate the code and have a look.

I'm still on.

And while testing WM9712 its touchpad interface, connecting a 800x600
display (instead of the default 640x480 one) results in a gone sound and
input-device - pretty queer:

WM9711/WM9712 SoC Audio Codec 0.4
asoc: platform pcm constructor failed
asoc: can't create pcm HiFi
asoc: failed to instantiate card PhyCORE-ac97-audio: -12

I have to admit that I used this time a 3.2 kernel. I'll test with
current later these days.

Same behaviour with 3.4.0-rc6:

Framebuffer driver mx3fb configured for a 800x600 display:

  soc-audio soc-audio: ASoC machine PhyCORE-ac97-audio should use snd_soc_register_card()
  asoc: platform pcm constructor failed
  asoc: can't create pcm HiFi :-12
  asoc: failed to instantiate card PhyCORE-ac97-audio: -12


mx3fb configured for a 640x480 display:
  soc-audio soc-audio: ASoC machine PhyCORE-ac97-audio should use
  snd_soc_register_card()
  asoc: wm9712-hifi <-> imx-ssi.0 mapping ok

 
Thanks,
 -- Christoph

On Mon, May 07, 2012 at 11:55:06PM +0200, Christoph Fritz wrote:

On Fri, May 04, 2012 at 03:28:45PM +0200, Christoph Fritz wrote:

quoted

On Fri, Apr 27, 2012 at 02:46:39PM +0100, Mark Brown wrote:

quoted

On Fri, Apr 27, 2012 at 10:00:02AM +0200, Christoph Fritz wrote:

quoted

On Thu, 2012-04-26 at 22:37 +0100, Mark Brown wrote:

quoted

quoted

  The write will be suppresed if the register contents don't
change which looks like what you're seeing here - 

quoted

Can you imagine why the registers don't change?

I can't immediately think of any reason, no - I'd step through or
annotate the code and have a look.

I'm still on.

And while testing WM9712 its touchpad interface, connecting a 800x600
display (instead of the default 640x480 one) results in a gone sound and
input-device - pretty queer:

WM9711/WM9712 SoC Audio Codec 0.4
asoc: platform pcm constructor failed
asoc: can't create pcm HiFi
asoc: failed to instantiate card PhyCORE-ac97-audio: -12

I have to admit that I used this time a 3.2 kernel. I'll test with
current later these days.

Same behaviour with 3.4.0-rc6:

Framebuffer driver mx3fb configured for a 800x600 display:

  soc-audio soc-audio: ASoC machine PhyCORE-ac97-audio should use snd_soc_register_card()
  asoc: platform pcm constructor failed
  asoc: can't create pcm HiFi :-12
  asoc: failed to instantiate card PhyCORE-ac97-audio: -12

When I do decrease from 800x600 to 800x594, wm9712 works. 

Any ideas?

mx3fb configured for a 640x480 display:
  soc-audio soc-audio: ASoC machine PhyCORE-ac97-audio should use
  snd_soc_register_card()
  asoc: wm9712-hifi <-> imx-ssi.0 mapping ok

 
Thanks,
 -- Christoph

quoted

Framebuffer driver mx3fb configured for a 800x600 display:

  soc-audio soc-audio: ASoC machine PhyCORE-ac97-audio should use snd_soc_register_card()
  asoc: platform pcm constructor failed
  asoc: can't create pcm HiFi :-12
  asoc: failed to instantiate card PhyCORE-ac97-audio: -12

When I do decrease from 800x600 to 800x594, wm9712 works. 

Any ideas?

It seems to be a dma problem and not directly related to wm9712.


But the not working microphone input still bothers me. I suppose this
is related to not beeing able to change some muxes:

$ amixer sset "Mic Select Source" 'Mic 2'
 Simple mixer control 'Mic Select Source',0
   Capabilities: enum
   Items: 'Mic 1' 'Differential' 'Mic 2' 'Stereo'
   Item0: 'Mic 1'

$ amixer sset "Differential Source" 'Line'
Simple mixer control 'Differential Source',0
  Capabilities: enum
  Items: 'Mic' 'Line'
  Item0: 'Mic'

They refuse to change their Item0 because they are defined as
SND_SOC_DAPM_MUX without a correlating path->name so that
snd_soc_dapm_mux_update_power() (in sound/soc/soc-dapmc) doesn't
change anything.

It works in 2.6.33, but current kernel has different mux handling and
it seems that no one since cared that much about microphone support.

Mark, can you confirm this, purpose a fix or even come up with
a patch?


Thanks,
 -- Christoph

On Sat, May 12, 2012 at 02:15:56AM +0200, Christoph Fritz wrote:

They refuse to change their Item0 because they are defined as
SND_SOC_DAPM_MUX without a correlating path->name so that
snd_soc_dapm_mux_update_power() (in sound/soc/soc-dapmc) doesn't
change anything.

A route into a mux without a path name (other than a supply) just isn't
meaningful and I'm surprised it ever worked.

It works in 2.6.33, but current kernel has different mux handling and
it seems that no one since cared that much about microphone support.

It's nothing to do with microphones really, it's more that AC'97 CODECs
are rarely used with modern kernels as the boards that use AC'97 are
mostly quite old and suffer performance issues with modern software
stacks so newer kernels haven't been getting much testing with them.

Mark, can you confirm this, purpose a fix or even come up with
a patch?

Just filling in the appropriate mux value in the relevant route should
do the trick.  Looking at the code it looks like the widget isn't hooked
into the audio routing map at all so I'm a little surprised.  I'm out of
the office at the minute and so can't readily set up a test system
myself.

On Sat, May 12, 2012 at 12:51:31PM +0100, Mark Brown wrote:

On Sat, May 12, 2012 at 02:15:56AM +0200, Christoph Fritz wrote:

quoted

They refuse to change their Item0 because they are defined as
SND_SOC_DAPM_MUX without a correlating path->name so that
snd_soc_dapm_mux_update_power() (in sound/soc/soc-dapmc) doesn't
change anything.

A route into a mux without a path name (other than a supply) just isn't
meaningful and I'm surprised it ever worked.

quoted

It works in 2.6.33, but current kernel has different mux handling and
it seems that no one since cared that much about microphone support.

It's nothing to do with microphones really, it's more that AC'97 CODECs
are rarely used with modern kernels as the boards that use AC'97 are
mostly quite old and suffer performance issues with modern software
stacks so newer kernels haven't been getting much testing with them.

quoted

Mark, can you confirm this, purpose a fix or even come up with
a patch?

Just filling in the appropriate mux value in the relevant route should
do the trick.  Looking at the code it looks like the widget isn't hooked
into the audio routing map at all so I'm a little surprised.  I'm out of
the office at the minute and so can't readily set up a test system
myself.

Thanks Mark, I'm pretty interested in testing too :-)

 -- Christoph

On Sun, May 13, 2012 at 05:56:53AM +0200, Christoph Fritz wrote:

On Sat, May 12, 2012 at 12:51:31PM +0100, Mark Brown wrote:

quoted

On Sat, May 12, 2012 at 02:15:56AM +0200, Christoph Fritz wrote:

quoted

They refuse to change their Item0 because they are defined as
SND_SOC_DAPM_MUX without a correlating path->name so that
snd_soc_dapm_mux_update_power() (in sound/soc/soc-dapmc) doesn't
change anything.

A route into a mux without a path name (other than a supply) just isn't
meaningful and I'm surprised it ever worked.

quoted

It works in 2.6.33, but current kernel has different mux handling and
it seems that no one since cared that much about microphone support.

It's nothing to do with microphones really, it's more that AC'97 CODECs
are rarely used with modern kernels as the boards that use AC'97 are
mostly quite old and suffer performance issues with modern software
stacks so newer kernels haven't been getting much testing with them.

quoted

Mark, can you confirm this, purpose a fix or even come up with
a patch?

Just filling in the appropriate mux value in the relevant route should
do the trick.

Do you mean filling in to wm9712_audio_map or wm9712_enum?

quoted

Looking at the code it looks like the widget isn't hooked
into the audio routing map at all so I'm a little surprised.

Does that mean that wm9712_dapm_widgets should be referred by a
struct snd_kcontrol_new ?

quoted

I'm out of
the office at the minute and so can't readily set up a test system
myself.

I'm not that into alsa and would greatly appreciate if you could have
a look with your test system.

Thanks,
 -- Christoph

On Tue, May 15, 2012 at 11:15:41AM +0200, Christoph Fritz wrote:

On Sun, May 13, 2012 at 05:56:53AM +0200, Christoph Fritz wrote:

quoted

quoted

Just filling in the appropriate mux value in the relevant route should
do the trick.

Do you mean filling in to wm9712_audio_map or wm9712_enum?

There will need to be routes in the audio map.  Don't know if there are
any fixes needed in the enum, it was the routing I noticed was missing.

quoted

quoted

Looking at the code it looks like the widget isn't hooked
into the audio routing map at all so I'm a little surprised.

Does that mean that wm9712_dapm_widgets should be referred by a
struct snd_kcontrol_new ?

No, that should never happen.

quoted

quoted

I'm out of
the office at the minute and so can't readily set up a test system
myself.

I'm not that into alsa and would greatly appreciate if you could have
a look with your test system.

For personal reasons I don't really have an ETA for when I'll be in the
office, sorry.