[PATCH 0/9] various mainly pcf50633 resume improvements / Ooooh
Sean McNeil
sean at mcneil.com
Sun Jun 15 08:38:43 CEST 2008
Andy Green wrote:
> Somebody in the thread at some point said:
>
> |> Despite we made some real progress in fact the whole suspend / resume
> |> thing remains extremely fragile due to probably just one or two more
> |> monsters in the deep shadows we never understood yet. And they're the
> |> kind of monsters that attack if you go hunting for them:
> |> no_console_suspend on the kernel commandline kills resume the same way
> |> as mdelay() in glamo suspend stuff, and equally with no real trace of
> |> how or why it blew chunks.
>
> | It works for a few times, then seems to crash. If I comment out the
> | dev_info ()and msleep() calls in pcf50633_work it seems to be OK. Also,
>
> OK I think I just had a "major breakthrough in understanding" why
> suspend action can be time-critical :-)
>
> We turn off our CPU core voltage quite early during suspend :-)))
> basically after pcf50633 suspends we are "running on fumes" for core_1v3
> in 23.3uF of capacitance for the rest of the suspend action. :-))) So
> this is why the odd dev_info() (which has to be flushed on serial
> console) and msleep() can make a difference to if you are gonna resume.
>
> I'm going to meditate on this a bit, it is a serious issue because
> pcf50633 being an i2c peripheral from Linux's POV, it is suspended very
> early, and the i2c bus goes down a little while after so deferral is not
> really possible (unless we bitbang it ourselves I suppose). But surely
> sawing off the branch you are sitting on by turning off your CPU core
> voltage is something your should preferably be doing at the END of
> suspend action not the start :-)
>
>
> Also I went back to look at why I could never make any change to the
> white flash that happens on suspend, I stuck mdelay(1000) in various
> places up the chain of suspends starting from Glamo going backwards,
> until I was able to delay the flash coming, which was when the delay was
> in pcf50633 suspend. Further examination showed it was when we take the
> regulators down in preparation for suspend.
>
> I checked mach_gta02.c and I had told it to leave the lcm regulator up,
> but I could see it was taking it down. When I told it to leave them all
> up, it still took lcm and some others down. After some head scratching
> I saw that it meddles with that platform struct at runtime elsewhere in
> the file, so I forced it up there too. Now there is no white flash (and
> I believe this will solve the monochrome LCM issue, since the power was
> getting taken until now).
>
> So that's up on andy branch now.
>
> | I still have it resuming as greyscale and the audio pops are still
> present.
>
> Greyscale I think will be fixed now.
>
> Audio pops... can you clarify where they come from... the earpiece or
> the sounder at the back / side.
This is so much better. Screen is now resuming in color. Resume is much
more reliable as well. Yet even more reliable when I take out the
dev_info() call in the _irq routine. I still get a complete lockup
eventually, though. Seems like the longer I leave it in suspend the less
likely it will resume.
The pops must be coming from the speaker on the side. I heard them even
with the top off so the earpiece isn't even connected, right? They only
happen on resume.
At the time of the suspend/resume I have audio opened as a pseudo alsa
device which configures with the same info as stereoout.state. Here is
the actual states:
{ name 'PCM Volume' value [ 235 235 ] }
{ name 'ADC Capture Volume' value [ 195 195 ] }
{ name 'Headphone Playback Volume' value [ 127 127 ] }
{ name 'Speaker Playback Volume' value [ 0 0 ] }
{ name 'Mono Playback Volume' value 121 }
{ name 'Bypass Playback Volume' value [ 2 2 ] }
{ name 'Sidetone Playback Volume' value [ 2 2 ] }
{ name 'Voice Playback Volume' value [ 2 2 ] }
{ name 'Headphone Playback ZC Switch' value [ false false ] }
{ name 'Speaker Playback ZC Switch' value [ false false ] }
{ name 'Mono Bypass Playback Volume' value 2 }
{ name 'Mono Sidetone Playback Volume' value 2 }
{ name 'Mono Voice Playback Volume' value 2 }
{ name 'Mono Playback ZC Switch' value false }
{ name 'Bass Boost' value 'Linear Control' }
{ name 'Bass Filter' value '130Hz @ 48kHz' }
{ name 'Bass Volume' value 0 }
{ name 'Treble Volume' value 0 }
{ name 'Treble Cut-off' value '8kHz' }
{ name 'Sidetone Capture Volume' value [ 2 2 ] }
{ name 'Voice Sidetone Capture Volume' value 2 }
{ name 'Capture Volume' value [ 23 23 ] }
{ name 'Capture ZC Switch' value [ false false ] }
{ name 'Capture Switch' value [ false false ] }
{ name 'Capture Filter Select' value '3.4Hz @ 48kHz' }
{ name 'Capture Filter Cut-off' value HiFi }
{ name 'Capture Filter Switch' value true }
{ name 'ALC Capture Target Volume' value 3 }
{ name 'ALC Capture Max Volume' value 7 }
{ name 'ALC Capture Function' value Off }
{ name 'ALC Capture ZC Switch' value false }
{ name 'ALC Capture Hold Time' value 15 }
{ name 'ALC Capture Decay Time' value 12 }
{ name 'ALC Capture Attack Time' value 2 }
{ name 'ALC Capture NG Threshold' value 0 }
{ name 'ALC Capture NG Type' value 'Constant PGA Gain' }
{ name 'ALC Capture NG Switch' value false }
{ name '3D Function' value Capture }
{ name '3D Upper Cut-off' value '2.2kHz' }
{ name '3D Lower Cut-off' value '200Hz' }
{ name '3D Volume' value 0 }
{ name '3D Switch' value false }
{ name 'Capture 6dB Attenuate' value false }
{ name 'Playback 6dB Attenuate' value false }
{ name De-emphasis value None }
{ name 'Playback Mono Mix' value Stereo }
{ name 'Playback Phase' value 'Non Inverted' }
{ name 'Mic2 Capture Volume' value 0 }
{ name 'Mic1 Capture Volume' value 0 }
{ name 'DAI Mode' value 'DAI 0' }
{ name 'ADC Data Select' value Stereo }
{ name 'ROUT2 Phase' value Inverted }
{ name 'Mic Selection Mux' value 'Mic 1' }
{ name 'Rx Mixer' value 'RXP - RXN' }
{ name 'Line Mixer' value 'Line 1 + 2' }
{ name 'Line Mono Mux' value 'Line Mix' }
{ name 'Line Right Mux' value 'Rx Mix' }
{ name 'Line Left Mux' value 'Rx Mix' }
{ name 'ALC Mixer Line Capture Switch' value false }
{ name 'ALC Mixer Mic2 Capture Switch' value false }
{ name 'ALC Mixer Mic1 Capture Switch' value false }
{ name 'ALC Mixer Rx Capture Switch' value false }
{ name 'Mic Sidetone Mux' value 'Left PGA' }
{ name 'Capture Right Mux' value PGA }
{ name 'Capture Left Mux' value PGA }
{ name 'Capture Right Mixer' value Stereo }
{ name 'Capture Left Mixer' value Stereo }
{ name 'Playback Mixer Voice Capture Sw' value false }
{ name 'Playback Mixer Left Capture Swi' value false }
{ name 'Playback Mixer Right Capture Sw' value false }
{ name 'Out4 Mux' value VREF }
{ name 'Out3 Mux' value VREF }
{ name 'Mono 2 Mux' value 'Inverted Mono 1' }
{ name 'Mono Mixer Left Playback Switch' value false }
{ name 'Mono Mixer Right Playback Switc' value false }
{ name 'Mono Mixer Voice Playback Switc' value false }
{ name 'Mono Mixer Sidetone Playback Sw' value false }
{ name 'Mono Mixer Bypass Playback Swit' value false }
{ name 'Right Mixer Voice Playback Swit' value false }
{ name 'Right Mixer Sidetone Playback S' value false }
{ name 'Right Mixer Right Playback Swit' value true }
{ name 'Right Mixer Bypass Playback Swi' value false }
{ name 'Left Mixer Voice Playback Switc' value false }
{ name 'Left Mixer Sidetone Playback Sw' value false }
{ name 'Left Mixer Left Playback Switch' value true }
{ name 'Left Mixer Bypass Playback Swit' value false }
{ name 'DAPM Stereo Out Switch' value true }
{ name 'DAPM GSM Line Out Switch' value false }
{ name 'DAPM GSM Line In Switch' value false }
{ name 'DAPM Headset Mic Switch' value false }
{ name 'DAPM Handset Mic Switch' value false }
{ name 'DAPM Handset Spk Switch' value false }
{ name 'Amp State Switch' value true }
{ name 'Amp Spk Switch' value true }
I'm now trying to see if I can monitor and capture what it is doing via.
JTAG. It doesn't look like this is possible, though. All is ok up until
it goes into suspend. I can ctrl-c and see whats going on:
Program received signal SIGINT, Interrupt.
s3c24xx_default_idle () at include/asm/arch/system.h:41
41 for (i = 0; i < 50; i++) {
(gdb) bt
#0 s3c24xx_default_idle () at include/asm/arch/system.h:41
#1 0xc0063278 in default_idle () at include/asm/arch/system.h:56
#2 0xc0062fb8 in cpu_idle () at arch/arm/kernel/process.c:170
#3 0xc0329b2c in rest_init () at init/main.c:453
#4 0xc0008d18 in start_kernel () at init/main.c:648
#5 0x30008034 in ?? ()
(gdb) c
Continuing.
but when it suspends I get
timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0
timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0
timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0
timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0
Program received signal SIGTRAP, Trace/breakpoint trap.
0xffffffec in ?? ()
and then its pretty much dead.
More information about the openmoko-kernel
mailing list