[PATCH] Dyn-tick support for S3C24xx (hack).

Andy Green andy at openmoko.com
Mon Jun 30 15:43:02 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| 2008/6/30 Andy Green <andy at openmoko.com>:
|> | dyn-ticks on ARM is enabled by passing "dyntick=enable" in the boot
|> | parameters or running
|> |  # echo 1 > /sys/devices/system/timer/timer0/dyn_tick
|> | (also lets you switch back to HZ mode later).
|>
|> When I enable this, it destroys resume.
|
| Details. :) I've not taken care of resume because I'm not sure if we
| actually want dyn-ticks.  It may make sense to measure how it affects
| power consumption before putting more effort in it (also
| s3c24xx_timer_offset_dyn_tick is left out, this makes do_gettimeofday
| less accurate, but it's also easy).

Can't be that bad if it has 13h battery life.

One thing I noticed since I hooked my battery up to a new multimeter,
100% backlight is >50% of the current when the thing is up and idle.

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
something.  Really that is >50% of the "up" consumption we can do
something about.

|> - -static void s3c2410_timer_resume_atomic(void)
|
| I only snipped this one because it's static and it's unused.

Huh fair enough then, I guess we'll see what new excitement it brought
to the resume party.

| I remove some double writes to registers in s3c2410_timer_setup which
| looked redundant and had no comment.
|
|> |   91.8% ( 99.7)       <interrupt> : lis302dl
|>
|> neod has these open its whole life not doing anything with the the bulk
|> or all of the time.  If neod just opened /dev/input/event2 & 3 when it
|> had a use for them, that would certainly be a big powersaving all by
itself.
|
| Right. Also notice that the accelerometers timer shares the prescaler
| with timer 4 which we use :(

That'd be FIQ timer, it's not used for lis302dl: that is regulated by
individual interrupts from the two sensor chips at 100Hz.

It seems the solution to the accelerometers in userspace is going to be
quenching the interrupts from them by the threshold stuff, since it's
evidently too complicated for neod to consider to open the dev nodes
only when it has a use for them for such a piffling matter as battery
power (since the driver saves power by not polling them if nobody is
listening).

| 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.

- -Andy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkho4t8ACgkQOjLpvpq7dMp12QCfb3uHZ8hpJZlwNe+xqe2xSyjl
6aAAoJMTnDE9gnZKC2SZBOQ06OlV9wuK
=XJCZ
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list