hm...i like this problem.....someone got the same problem too: http://lkml.indiana.edu/hypermail/linux/kernel/0009.3/0906.html does your problem look similar? On Thu, Jan 8, 2009 at 11:41 PM, Bruce Rowen <browen@xxxxxxxxxxxx> wrote: >>> >>> Some delays are shorter (i.e. 20us). >>> >>> What (if any) taboos exist for using sleep() in a kernel ioctl call and >>> what >>> alternatives exist? >> >> it's not a taboo. In your case, i think it's simply because you can >> not reschedule because it will screw something (are you holding a lock >> or something? probably some sequences of inb/outb must be done in >> sequence ?). If yes, then busy wait is probably your only way to >> delay. > > > I don't think it's due to a lock, for some of the shorter sleeps where I > just need to make sure the bit stays set for a microsecond or more I use > schedule() which even if it decides to run the current process, the calling > delay is sufficient. Basically the register is read (readl(), bit set, then > written (writel()). > > I'll look into busy wait but there are some delays that should be shorter > than the system tick (1KHz) just so the process doesn't take too long. For > example, I have a FIFO to fill and I must wait 20uS between writes. It would > be nice to use a usleep() for this but anything that has the granularity of > the system tick would end up taking too long. Of course not much else can > get done on the CPU during the 20uS sleeps anyway so spinning on the > rdtscl() count is not a total waste. > > Thanks, > -Bruce > >> >>> Kernel is 2.6.13 w/preemption, soon to be moving to a later version, >> >> regards, >> >> Mulyadi. -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
