On Wed, Aug 05, 2009 at 09:30:53AM -0700, John Bonesio wrote:
I've retitled the email to better reflect the real patch. I believe there has been some general confusion because I originally sent the wrong patch.
Retitling again; I don't think we've diagnosed what is causing issues here. Doing a quick test here I wasn't able to reproduce this behaviour so I suspect either the AC97 controller by itself or some interaction between it and the WM9712. Like I say, the WM9712 is not a new part and the drivers aren't new either so it'd be surprising to find an issue like this now.
Like I said before, exactly which control are you adjusting here?
My description of this got lost in all the confusion. Let me try again. We are adjusting the mixer bits for mute/unmute on two of the mixer settings. The first one is general headphone mute setting on register 0x4 (bit 15). The second one is the PCM mute setting on register 0x18 (bit 15).
Hrm, so the same bit in both registers. Suspicious...
What we are seeing is that if we first unmute the general headphone (reg 0x4 bit15), then unmute the PCM (reg 0x18 bit 15) [HPL PCM in the alsamixer application], the general headphone gets muted again, even though software didn't write to that register.
Are any other bits in register 4 affected or is it only bit 15?
My money would be on the AC97 controller having problems; the quality of SoC AC97 controllers is variable. It certainly doesn't sound like a WM9712 issue; as I say I'd be very surprised if such an issue hadn't come up before given how widely deployed the part is.
We don't have access to an AC97 analyzer. Do you have any suggestions on other ways we can pinpoint the error?
Any scope that can capture would be useful to see what's going on; obviously decode would have to be by hand. Coding out the register cache may also be useful - it'd allow you to see the current hardware register values.