Dale Whitfield (dale@elad.cix.co.uk)
Sat, 20 Mar 1999 12:42:42 +0000
>> Problem is you can justify a fastpath function for most of the 8
>> variations of ecp-mode read/write calls alone.
>
>Dale, there are not 8 variations. Don't start saying software vs.
>hardware again, because the client doesn't get a choice on that, at least
>not on a per-call basis.
I still disagree, I'm afraid Tim :-) The client is, as is being pointed out,
generally a mid-level driver because it does no buffer verification and
functions can be called on an interrupt. Therefore the client has knowledge of
the hardware and does not need to be abstracted from it.
>Parport is supposed to be independent from the architecture. I'm not
>saying it's perfect in that regard _now_ -- as Joerg pointed out, it's
>very PC-biased. But independence is the aim, and so moving _toward_ the
>hardware is counter-productive.
Parport can try and be completely independent from the system achitecture but
it cannot be independent of the parallel-port hardware.
A driver such as parport should firstly, serialise and manage access to the
hardware and secondly should make functionality available which enables other
drivers to use all features of the hardware. It must not attempt to anticipate
how the hardware will be used. Therefore, if there is functionality such as a
choice between using hardware ecp-writes vs software-emulated writes then it is
up to an app or mid-level driver to decide how to drive its peripheral using
the parallel-port hardware, not parport.
>If you really want separate functions to do the transfer handshaking in
>software rather than hardware, there had better be a _very_ good reason.
>So far you haven't convinced me that there is. (You are welcome to keep
>trying though.)
Because it won't work. Simple. its not a case of convincing anyone about
anything, it just won't work using hardware transfers. No more to say. If I
have to implement the functions locally using inb & outb then so be it. I don't
design the hardware and I have some here which needs this functionality. I
implemented it using these modes under OS/2 with guidance from engineers who
designed the hardware. All I'm doing is porting working code. I'm not creating
an artifical scenario. If you need exceptions to the rule, this is one.
For those unsure of what this means, the issue is simply that it is possible
using ecp-mode to send/receive an address/data byte in hardware mode (hardware
handshakes control lines) or software mode (handshaking of control lines done
in software). The QuickCam VC using both hardware and software modes in
differing circumstances.
Dale.
-- 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 Sun 28 Mar 1999 - 17:03:56 EST