Quoting Bob Tanner <tanner@real-time.com>:
...
> Writing bytes to a custom piece of hardware. Speed is #1 priority and dma was
> brought up as a factor in speed.
>
> It's a bit if a screwy situation, since the code is in user-space, and I'd
> think a kernel driver would be much faster.
Hi,
Nononono etc.
All of the neccessary kernel-mode code has already been written for you. It is
much "nicer" to leave the rest in userspace for all sorts of reasons (eg,
security, stability, and portability). The speed difference should be
negligable with well written code, so unless you have some specific requirements
that force you into writing a kernel module, it's better to avoid it.
The parport_pc module will use DMA when given the appropriate parameters. ppdev
(and in turn libieee1284 if you use it) will then use it for transfers and
you'll receive the benefits without having to worry about the implementation at all.
eg:
cheesypoof:/home/stauff# modprobe parport_pc dma=3 irq=5 io=0x278
(in /var/log/messages):
May 3 15:29:38 cheesypoof kernel: parport0: PC-style at 0x278 (0x678), irq 5,
dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
When doing large transfers you'll definately notice the difference in the level
of CPU usage when DMA is enabled, but it's still best not to *rely* on it if you
can avoid it because older systems won't support it.
Cheers,
- Matthew Duggan
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Sat May 03 2003 - 01:50:47 EDT