[PATCH] selecting CONFIG_S3C2410_PWM

Werner Almesberger werner at openmoko.org
Mon Jan 19 03:17:45 CET 2009


Andy Green wrote:
> I sent most of the patches today on andy-tracking, but this and the
> msleep / mdelay one went on stable-tracking instead.

Thanks ! Whichever place works best :-)

By the way, after the msleep change, I thought that there might be
a chance to reduce suspend time by further tweaking the 2 seconds
reset delay in ar6000_reset_device.

The result is rather interesting - or confusing ;-)

This is a the time it takes to suspend in andy-tracking before the
msleep changes. The signal rises right before we printk "PM: Syncing
filesystems ..." and falls just before calling s3c_pm_save_gpios.

http://people.openmoko.org/werner/suspend-original.png

The 3.x seconds are the time it normally takes the kernel to
complete a suspend. The one that's about 1.6 seconds is the
very first suspend.

The 1.6s despite having a 2s mdelay in the group of things that
contribute to the total time need an explanation. My hypothesis
is that the calibration of the delay loop isn't correct, but I
have yet to verify this.

Then I tried to reduce the reset delay, but the results weren't
encouraging: it seems that we only really need about 100ms plus
the ability to retry, but there's a huge penalty: if the timing
is too aggressive, we may never get a good response from the chip.

However, given that the next thing to do is to power down the
function, it doesn't really seem to make sense to do a controlled
reset. (I verified that avoiding the reset does not affect
functionality but I still need to check the current to be sure
that there isn't anything weird going on that would cause other
problems.)

Now, when skipping the reset, I get this:
http://people.openmoko.org/werner/suspend-noreset.png

The first suspend is very fast now, confirming that WLAN was the
principal element slowing everything down. But all subsequent
suspends are as slow as they've ever been.

This suggests that there's something in the suspend path that
creates a fairly large delay on suspend (> 3s) and that only
comes alive after a resume.

Since you've been poking around suspend/resume quite a bit, does
this ring any bells ?

- Werner



More information about the openmoko-kernel mailing list