> thanks for explaining those two cases. For the second one, i dont think an
> init sequence is too critical. (it would be critical i think if we lost a
> tick for every joystick event)
> hm, would it help if you had very precise and high-frequency timers, but
> with the restriction that they are NMI so they have to be used very
> carefully (and with a different timer interface)? On pentiums and up we
> can have periodic NMI interrupts generated by the CPU. Sustaining 100 khz
> is no problem with those. The problem is, this trick is pretty much
> Intel-specific.
Yes, this would help the Logitech init case, though I think it's overkill to
solve it this way. I'll try to avoid using cli() in the Logitech driver,
using some other timing than udelay(), and first measuring how big
differences the joystick will allow from the defined sequence and still
work. It should be possible to allow some time windows when interrupts may
happen during the init sequence without any harmful effect.
However, I will not be able to push cli()ed time in the normal case (eg.
50 times a second when joystick device is open) under about 1.2 ms for
many of the digital joysticks, though. So no chance with 1 kHz timer
frequency - you'd get a clock slowdown. (Yes, this eats 5% of CPU time.)
For analog joysticks, my drivers don't need cli() since version 1.0
(remember the joystick & timeloss thread before that?), but till 1.2.14 this
was at the cost of bad performance. Since 1.2.14 I use a more complex
algorithm that is able to detect interrupt/dma/pci-burst intervening the
measurement and discard the bad measured value.
Vojtech
-
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/