Dag wrote :
> Jean Tourrilhes <[EMAIL PROTECTED]> writes:
>
> > 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.
Dag, I think this is not correct. First you can have sleep
below 10ms, and second you didn't read carefully my sentence above.
1) The kernel allows you to "sleep" for a few microseconds,
and it's used in so many drivers. The magic formula is :
udelay(20); /* Wait 20us */
Note that usually if you want 20us, it's no use trying to
schedule another task, because you don't have enough time anyway and
that would be too much penalty. By the way, udelay is based one a busy
loop calibrated by the bogomips calculation.
2) If you look carefully in the litelink.c file, as I was
pointing out, you will realise that it uses udelay. Magic !
> 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?
I've no idea, in my driver I always make heavy use of udelay.
> 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.
Bummer !
> Alan greps for udelay (busy wait), so they be sure you keep the
> timeouts as low as possible.
That's why the spec is necessary. udelay are a necessary evil,
because setting a timer, scheduling in another task, calling the timer
and all the associated complexity is also a penalty.
> PS. If somebody feel my understanding of this problem is not fully correct,
> then I would appreciate your comments!!
>
> -- Dag
Jean
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
