Riccardo Facchetti (fizban@tin.it)
Tue, 14 Apr 1998 14:43:48 +0200
Hello,
I have finished reading the M$ ECP specs.
I see that the ECP hardware have interesting features like FIFO and
Interrupt controlled Programmed I/O and DMA transfers.
The actual implementation of parport as lowlevel driver, seems to me
that lacks in generalization. It is not generic in the way could be.
The lp driver knows about parport and uses parport registers to drive
I/O. It should not be this way IMHO.
About parport sharing: who is able to explain me the utility of such a
feature ? I have 1 printer attached to the parport. How about adding
a parallel ZIP drive ? Can I print WHILE doing backup on the ZIP ?
Can I add then another device like a Xircom parallel network interface
and do network+ZIP backup+printing to the printer with all these devices
attached to the same parallel interface, all at the same time ?
A proposal of parport interface IMHO should be:
PARPORT CODE
All the low level code:
All the architecture-specific code.
Parport detection, initialization and setup
Parport release hardware resources
Parport API (midlevel drivers <-> lowlevel parport interface)
ParportOpen() - Request parport resource
ParportSetup() - Set up device-specific protocols
(e.g. mode, Int/poll, dma, etc.)
ParportWrite() - Obvious
ParportRead() - Obvious
ParportClose() - Release parport resource and leave it
in a known state
MIDLEVEL CODE
All the (attached) device code:
lp
zip
network ifaces
etc etc
All these drivers should:
handle = ParportOpen()
ParportWrite(handle, buffer, buflen)
ParportClose(handle)
Note: No need to know about parport internals !
ParportRead() and ParportWrite() should do Int/poll and/or DMA as requested
in ParportSetup(). lp, zip, netifaces, etc should not know about interrupts
and/or DMA. E.g. the only way they know they are using DMA, and interrupt
servicing is because they have called ParportSetup(handle,
PARPORT_DMA_ON|PARPORT_INT_ON).
handle should be a pointer to a structure containing all the infos gathered in
parport lowlevel detection initialization and setup; e.g. it should contain an
unsigned char PWord;
that tell us about the size of a data unit for the FIFO (1, 2 or 4 bytes) and
all the other relevant informations we should (at parport low level) know to
drive correctly the parallel port interface.
Of course these considerations come from a fresh reading of ECP specs and some
humbling about actual parport implementation, so it may be totally wrong.
Please, Tim et al, comment on this.
Ciao,
Riccardo.
-- 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 30 Dec 1998 - 10:17:37 EST