We are working on a driver for a two line LCD panel. We have a (portable)
version running on PC and SA-1100 LART[1] that does a lot of udelay()s
between the states of the LCD protocol. Yes it works, but the udelay()
effectively blocks the complete system.
The solution is to break up the write routine and use a task queue
fucntion instead, but this makes the device even slower (visibly, that
is). Each run of the task queue selects the next state in the LCD
protocol. If we use the timer task queue it is just plain slow, if we use
the scheduler task queue, the speed depends on the number of processes.
Is it possible to get the device faster without having to use udelay()?
Erik
[1] Linux Advanced Radio Terminal: 220MHz SA-1100, 32MB, > 200 mips, < 1W.
For a description and some pictures, have a look at
http://www-ict.its.tudelft.nl/~erik/open-source/LART/
-- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2785859 Fax: +31-15-2781843 Email J.A.K.Mouw@its.tudelft.nl WWW: http://www-ict.its.tudelft.nl/~erik/
- 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/