Dale Whitfield (dale@elad.cix.co.uk)
Mon, 15 Mar 1999 19:43:50 +0000
Hi all,
I'm implementing (porting really...) the missing functionality in ECP mode as
part of the IEEE1284 support. Its necessary to enable QuickCam VC support. This
means allowing reads and writes as either address (command) or data, in both
software emulated and hardware modes.
There are a couple of ways to implement it, as I see it.
a) have explicit functions exported for the purpose, 8 of them
b) use parport_read and parport_write, where the actual function called is
determined by the current mode/state
The first is messy, I started implementing it and had explicit function
declarations all over the place. It also does not benefit from the mutexes, etc
which already exist in read/write_block.
The second has the problem in that there are 'modes' missing, currently there
are either 'hardware' or software-emulated. We need 4 new ECP read/write modes:
o software-emulated data
o software-emulated address
o hardware data
o hardware address
Now, parport_read and parport_write can switch on the mode to setup the
appropriate function call made from within read_block or write_block.
This requires one new exported function - to set the ECP mode to one in the
list above. In effect, this may not do much except store the new mode, besides
checking that the hardware is already in true ECP mode. I think its preferrable
to have a separate function, it could be done in parport_negotiate but I think
would be better kept separate.
There is a third possibility, to extend the ieee1284 states to distinguish
between address_idle and data_idle. In a previous ieee1284 parallel-port driver
implementation, I used this approach. It means that switching between hardware
and software emulated modes requires calling a set_forward_state() or
set_reverse_state() type of function, specifying address/data, which would
leave the driver in software/hardware address_idle or software/hardware
data_idle states. These are effectively forward_to_reverse(), and vice-versa,
functions. The read/write routines then behave accordingly. The new states are
not true "phases" in the IEEE1284 specified sense, but extensions to it.
I've been discussing some of this privately with Tim Waugh but its time for
further opinions. Anyone?
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 - 16:59:34 EST