> How do I wait in a
>multitasking friendly method?
Use schedule_timout(). Parameter is the number of ticks (1/HZ
second intervals) before you wish to be given control again.
>while ((count<3000) and (data!=BUSY)){
>parport_read_status(parport,data);
>}
>
>but that is really nasty obviously. From looking around I have seen
>udelay() and mdelay() whats the diff and how do I use them.
udelay() takes a microsecond argument, mdelay() takes a
millisecond argument. udelay() operates in a tight loop,
and so is quite multitasking-hostile for large delays (but
essential for small delays). mdelay() actually calls udelay()
in its own loop, because udelay() might fail due to overflowing
its counter on very fast machines; thus it too is not friendly
to other tasks wishing to run.
> I think I need around 1/200th of a second delay
How precisely? And how bad is it if the delay is a bit off (in
each direction)?
Since HZ is only 100 on most systems, schedule_timeout() won't
quite get you where you want to be --- you can either
schedule_timeout(HZ/100), which probably delays too long (0.01 s,
typically), or schedule_timeout(HZ/200), which probably doesn't
delay long enough (~0 s typical, though it does allow other tasks
to be scheduled before returning control to your driver).
Basically your choices for a 1/200 s delay are to hog the CPU
and be precise with mdelay(5), or to be generous to other tasks
but sloppy in your delay with schedule_timeout(0) (and a
(limited) retry loop, since if you are the only runnable task
you will regain the CPU quite rapidly).
--Ken Pizzini
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/