Jean Tourrilhes <[EMAIL PROTECTED]> writes:

> Lichen Wang wrote :
> >  Jean wrote:
> > 
> > >         o actisys.c : 40 ms to move from one speed to the next
> > 
> > There must be a mistake in the Actisys Driver.  It takes 40 microseconds
> > to switch the speed. Someone mis-read microseconds as miniseconds.
> > Are you talking about the Driver in linux?
> 
>       Yes, I'm talking about the driver in Linux. Dag, I guess that
> you will have to correct this. Actually, it will make the driver code
> much more simpler and safer, because for 40us you can use the same
> method as in litelink.c and avoid all the back and forth between
> layers ;-)

The problem is really that the Linux kernel is using a HZ of 10 (10 timer
ticks pr. sec). That mean that you cannot set a timer less than 10 ms
(unless you increase HZ, but HZ is usually not changed by "normal"
people). This means that you must at least set a timeout to 10 ms even if
you just wanted wanted to sleep a ms or so. But even worse, you never know
how close you are to the next timer tick, so setting a timeout of 10 ms (1
jiffy) may give you a timeout between 0 and 10 ms (and maybe more because
of interrupt latency). Therefore you have to set a timeout of 2 jiffies (20
ms) to be sure you get at least 10 ms (which is garantied to be more than
the few ms you actually wanted). This is the historic reason why the dongle
drivers are filled with 20 ms timeouts ;-) Nothing to do with the dongle
docs.

Chris Richards gave me this code that should give the correct amount of
jiffies regardless of the current HZ:

#define MSECS_TO_JIFFIES(ms) (((ms)*HZ+999)/1000)

It will round up to the nearest jiffy, but does not however take into
accunt that the next timertick may be 1 us away. Is this a bug?

Anyway, I cannot find the docs for the ACTiSYS dongle in my machine
anymore, so somebody having this dongle will have to experiment using us
timeouts. Alan greps for udelay (busy wait), so they be sure you keep the
timeouts as low as possible.

PS. If somebody feel my understanding of this problem is not fully correct,
then I would appreciate your comments!!

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///

_______________________________________________
Linux-IrDA mailing list  -  [EMAIL PROTECTED]
http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda

Reply via email to