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

andrzej zaborowski balrogg at gmail.com
Mon Jun 30 14:58:10 CEST 2008

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

> You may have been a bit too fast snipping this kind of thing without
> testing for consequences from the dire warnings left by previous
> travellers in this land:
> - -/* ooh a nasty situation arises if we try to call s3c2410_timer_setup()
> from
> - - * the resume handler.  It is called in atomic context but the clock APIs
> - - * try to lock a mutex which may sleep.  We are in a bit of an unusual
> - - * situation because we don't have a tick source right now, but it
> should be
> - - * okay to try to schedule a work item... hopefully
> - - */
> - -
> - -static void s3c2410_timer_resume_atomic(void)

I only snipped this one because it's static and it's unused.

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 :(

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.


More information about the openmoko-kernel mailing list