Re: [PATCH 1/1] ASoC: TWL4030: Headset VMID ramp fix

[Peter Ujfalusi <peter.ujfalusi@nokia.com>]

On Friday 08 May 2009 14:56:50 Ujfalusi Peter (Nokia-D/Tampere) wrote:
> On Friday 08 May 2009 09:40:44 ext Jarkko Nikula wrote:
> > It really does fix the power-up & -down pops on Beagle. By listening
> > carefully I can hear slight power-up and -down pops but only if really
> > focusing on it.
> >
> > But now the audio output is distorted and volume level is a little bit
> > lower. Without the patch it plays fine. Is it possible that now the
> > output voltage is not correctly biased? Worth to check with a scope.
>
> Well, that's what you get, when you are testing audio with /dev/zero and
> /dev/urandom... I have not noticed that the random noise got more random ;)
> What you have described is correct, it is heavily distorted.
>
> But I have debugged this further and I believe I know what is going on:
> The sequence for disable according to the documentation:
> HS_POP_SET:RAMP_EN = 0
> HS_POP_GAIN:HSL_GAIN, HSR_GAIN = 0
> HS_POP_SET:VMID_EN = 0
>
> Now what is missing from this is that after setting the HS_POP_SET:RAMP_EN
> = 0 it will take RAMP_DELAY time for the VMID to reach 0.
> Since we are not waiting between RAMP_EN = 0 and VMID_EN = 0, the VMID has
> been cut, which causes the 'tuck' on the headset output.
>
> In case of the Beagle board the ramp delay can be configured(MCLK=26MHz):
> 20ms - 2581ms, by default it is 20ms.
> To verify this I have added mdelay(30) after the RAMP_EN = 0, and there
> were no 'tuck'. However when I increased the RAMP_DELAY (to 40ms, or
> longer) the 'tuck' reappeared.
>
> How to solve this?
> Realistically we can not add 2581ms delay to the headsetl_event function...
> We could keep the VMID enabled all the time (which increases the idle power
> consumption by ~0.001A), but then the muting of the headset
> (HS_POP_GAIN:HSL_GAIN, HSR_GAIN = 0) will give the 'tuck'...
> In power consumption the difference between
> HS_POP_GAIN:HSL_GAIN, HSR_GAIN == 0 and
> HS_POP_GAIN:HSL_GAIN, HSR_GAIN != 0 is about ~0.01A, which is significant
> in my opinion.
> Using a timer to finish the ramp down?
>
> Anyways, this seams quite bad. I will think about it over the weekend...
>
> Any ideas?

We could fixate the RAMP_DELAY to 0 (27/20/14 ms, MCLK = 19.2/26/38.4 MHz) and 
add mdelay(28/21/15) in the headsetl_event function... But I'm not sure is it 
allowed, at least it looks hackish. Mark?

-- 
Péter