Tim Waugh (tim@cyberelk.demon.co.uk)
Wed, 12 May 1999 22:21:10 +0100 (GMT)
On Wed, 12 May 1999, Bert De Jonghe wrote:
> Maybe parport_pc can have a private DMA-capable buffer (private_data
> ?) allocated if DMA is configured ? The cost would be an extra copy
> of the data into this buffer, but for me that's a price I'm willing to
> pay to avoid making the high-level drivers more complex and putting PC
> artifacts all over the place.
I'd rather not take the extra copy for no reason.
We could always give the parport functions user buffers instead of kernel
buffers, so that they have to copy anyway. That way, parport_pc can copy
into a DMA-able kernel buffer to start off with.
It will mean that things like parallel printer console with need to
set_fs(get_ds()), and parport_compat_write will have to copy_from_user
from within printk -- although it can't actually hurt.
Another thing I thought of that's wrong with the interface in parport-doc
is that change_mode(IEEE1284_MODE_COMPAT) doesn't know if we want to talk
to the registers or write characters to a printer, and with some ECP
chipsets it matters, because we can get the FIFO involved with writing
characters out to a printer.
I think IEEE1284_MODE_COMPAT will have to mean 'I want to use
parport_write_compat' and IEEE1284_MODE_PS2 will have to mean 'I want to
use the registers directly'.
Tim.
*/
-- 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 2.0b3 on Wed 12 May 1999 - 17:29:05 EDT