cannot hear any sound from dialer in GTA02

[erin_yueh@…]

1. make a phone call from NEO
2. build the chatting connection
3. cannot hear/speak sounds

[sean_chiang@…]

HI! Mickey,

After remove all files in ./tmp in oe, rebuild the root filesystem with current
audio state files, It works.

When I told you that sometimes I could hear the sound and sometimes I couldn't
even the puluseaudio is still running last night. I'm wrong, actually it should
be "sometimes the volume is loud enough and sometimes the volume is too low to
hear. I didn't change anything and have no idea what cause it different at
reboot each time. What do you think?

[graeme@…]

I have been trying to chase this down and I have got to the point I need a
hardware guy to verify that the Power, and GPIO inputs to the Amp are in the
correct state when the phone is stuck in this "quiet" mode.

I think the fault is after the codec as if you turn on the handset speaker it
has the correct loudness.

[sean_chiang@…]

Graeme, so now this problem was happened to you?

[graeme@…]

Yes it happens to me at random, some kernels suffer the problem, some don't

And some dont even always suffer the problem.

[mickey@…]

I have verified this problem. Changing to "blocker" and reassigning to kernel.
The amp for the mono speaker does not work unless the handset speaker has power.

[graeme@…]

I dont think enabling the Handset Speaker is actually powering up the Amp/Mono
Speaker its just a lot louder than the Amp/Mono Speaker.

[mickey@…]

Correct. It's very hard to confirm without opening the device, but I think
you're right.

[graeme@…]

Ok, this looks more and more like a software bug. Builds from mickeyl and
buildhost fail. DAMP Handset Spk is controlling Stereo Out for some reason.

Amp is working correctly as I can turn it on/off and note the difference.

I have objdump -d both mickeyl modules and mine and they are identical so its
not a difference in building the main driver module.

I don't understand why my builds work and other peoples fail.

[graeme@…]

Definate Heisenbug here and Im running out of ideas.

Booting a failing image will occasionally give working sound. I used objdump to
dissassemble the modules on working and non working images and found no
difference. Examined the driver code and can't see any obvious uninitialised
variables.

[graeme@…]

Ok, I would love to see the contents of
/sys/bus/platform/devices/soc-audio/codec_reg for both working and non working
situations from people.

After that please try the attached patch on your kernels and see if that makes a
difference.

[graeme@…]

A possible bandaid for the quiet sound problem

[tony@…]

solve by Sean_Chiang's alsa file and greame's driver, both function and quality

[sean_chiang@…]

Sorry, two different bug. I just fine tune the sound quality, not for this
problem. Sometimes we still could not hear ringtone.

[andy@…]

Guys is there a way I can reproduce the effect of this bug without making a
call? So if it comes up a "bad" kernel, can we see the bad behaviour in a
simpler way by using aplay from the shell, simplifying the number of things
involved in this issue?

[graeme@…]

The bug isnt actually about calls, its a general problem. Basically boot the
phone if the startup sound is really quiet or doesnt play at all you triggered
the problem.

Images from buildhost seem to trigger the problem more than other images.

Its not related to pulse as you can shut that down and use aplay and get same
results.

[andy@…]

Thanks for the clarification... comment #1 says to make a call to reproduce.

I never heard a quiet startup sound in the few times I booted on recent rootfs
with the sound.

There is a class of known problems hiding in the kernel that are driver
startup races. For example a driver wants to change a PMU setting, but maybe
the PMU device does not exist yet, since it only exists after the I2C driver
comes up and I2C is probed. This class of problems makes particular havoc
during suspend / resume due to ordering issues. I mention it because these
races are sensitive to the kernel .config.

Can it be something along those lines? Did you manage to find any difference
from dumping the codec/mixer registers down I2C when it was happy or sad?

Are we talking about the simple transducer on L/ROUT2 of the WM8753L or
L/ROUT1 which has a lot of other circuitry on it?

[graeme@…]

It seems that L/ROUT2 is working fine, its something in the L/ROUT1 system thats
the problem. My first thought was the Amp was under voltaged or some such failure.

[andy@…]

There is no shortage of things to go wrong on L/ROUT1 because it is overloaded
several different ways that already make unsolved troubles.

AMP_3V3 for the amp is connected direct to IO_3V3 which is "always on". So it
shouldn't be an issue with amp power otherwise we would see worse behaviours.
Likewise the codec / mixer is powered quite directly from IO_3V3 itself.

Here are some ways we could possibly make that symptom with that path:

There is an AMP_SHUT net that comes from CPU GPJ01, if this was asserted
(HIGH) then the amp would be in a low current standby mode. What it would do
then if audio arrived at the input is unknown, it could conceivably come out
at a low level. So this can be implicated.

Does your version of the kernel still make these ticking noises during boot?
If so then the DL_GSM (CPU GPIO GPJ6) net can be asserted (low), that can
create the trouble by driving a logic level on to the ROUT1 (but not LOUT1)
that would conflict with the amplified audio analogue levels.

Is the headphone socket occupied during this? If somehow JACK_INSERT (CPU
GPIO GPF4) and or nHOLD (CPU GPIO GPF7) were driven by the CPU that could
again conflict with the amplified audio.

Did we confirm there is nothing different with the mixer / codec I2C registers
when it is happy or sad?

Is there no way we can be doing software scaling at the CPU before sending
out?

[graeme@…]

Julian reports that the bandaid patch fixes the problem for him. Werner could
you apply this as a bandaid until I track down the real cause.

I also spoke to Liam and if this register is misset then it would account for
the too quiet sound.