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.
