[PATCH] Dyn-tick support for S3C24xx (hack).
balrogg at gmail.com
Tue Jul 1 07:53:41 CEST 2008
2008/6/30 Andy Green <andy at openmoko.com>:
> Without this patch anyway it's 190mA here idle and 100% backlight,
> setting the level to "2" gets me down to 90mA. That's not to say that
> anything reducing it a bit is not valuable -- it is -- but that if we
> want mega battery life we should also consider stuff like gently
> bringing down the backlight over a minute of no user interaction or
Agreed, but the current blanking after 5mins or so, implemented by the
userspace, should also be good enough if the user doesn't play with
the phone every 10 mins.
> | BTW I forgot to mention what the patch is good for. It'll let me
> | cheaply ramp up HZ to 10000 or 20000 and have more accurate usleep()
> | in userspace. Right now when mplayer wants to wait, say, 150 usec for
> | the MPEG module to come out of reset, it actually has to sleep 5000
> | usec because that's the shortest the kernel lets us sleep, or poll.
> Yeah that's better for power than cranking HZ up the old way :-) No I
> like the patch if resume works then it should probably go in since you
> have to enable it down /sys and we can hear about what breaks, it's the
> kind of thing that might break this and that, but is maybe worth fixing
> the things that broke.
Ok, attached is a version that resumes. Basically there were two
things: 1. during resume we were re-enabling the non-dyntick timer
because I hadn't overriden the resume callback anywhere.
2. I had moved the clk_enable(clk) call from *_setup() to *_init()
(i.e. stuff called only once instead of on every resume) because we
never call clk_disable, so we shouldn't need to enable it more than
once, right? But apparently arch/arm/plat-s3c24xx/clock.c implements
clk_enable/_disable differently than every other arch and you need to
call clk_enable manually after resume, so I had inadvertently removed
the workaround for this. It seems that the refcounting in
arch/arm/plat-s3c24xx/clock.c is just for show and the refcount is
always increased (on resume) and never decreased. I'll see after
guadec if I can fix it.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9398 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080701/aefe9607/attachment.bin
More information about the openmoko-kernel