schreite@helena.physik.uni-stuttgart.de
Mon, 15 Jun 98 10:49:49 +0200
Hi,
some peripherals do understand several IEEE1284 modes, but
for some applications/drivers it doesn't matter, which physical link is
realized to communicate to a peripheral, they just want o n e
link to the peripheral. Now I propose a set of general IEEE1284
functions:
1. parport_probe also probes for IEEE1284 capabilities of the peripheral
and stores it in a bit field (use same codes as for IEEE1284 negotiation).
2. unsigned int parport_ieee1284_set_modemask(parport *, unsigned int)
Allows certain or all IEEE1284-modes for forward and reverse channel
(-> we need to bytes and use an integer bit field for this).
It masks this input bit mask (e.g. 0xffff for all) with the capabilities
of the probed peripheral and the parort (e.g. for a SPP, for the
reverse channel only nibble mode is possible) and returns the remaining
modes for forward and reverse channel in a corresponding bit mask.
This function may be useful, if a peripheral provides some of its
functions not in all of its IEEE1284 modes. Or to see (with input
mask 0xffff), whether there is at least one mode for each direction.
3. int parport_ieee1284_set(parport *, PARPORT_FORWARD or PARPORT_REVERSE)
Negotiates the "highest" "available" mode for this direction.
Othervice the following functions will do it implicitly. But perhaps
sometimes nevertheless useful, to have this seperate function. E.g.
for a IEEE1284-reset.
Can return an error code.
4. int parport_ieee1284_get_state(parport *)
returns an error state and tells, whether the peripheral signals
"reverse data are available".
5. long parport_ieee1284_read(parport *, char *, long)
negotiate the "highest" "available" mode for the reverse channel
(if not already done) and reads the data from the peripheral.
(Later one could add the option, that parport receives IEEE1284
data automatically if available and then upcalls the driver.)
6. int parport_ieee1284_write(parport *, char *, long)
negotiate the "highest" "available" mode for the forward channel
(if not already done) and sends data to the peripheral.
(Later one could add the option, that this function returns
immediately and parport sends the data in the background and
tells the driver later via upcall, that the data are succesfully
(or not) sent.
7. void parport_ieee1284_quitmodes(parport *)
Nothing to explain.
For 5., 6. and 7. there are already a lot of things coded. These
functions call the exiting code for the EPP mode via a EPP port.
For the ECP mode via a ECP port, there is something to do (perhaps later),
but for the ECP mode via a SPP or PS2 port and emulation by software,
I have already written the most part, since we need this for the "MLC link
provider via parport" of the HP OfficeJet project. The nibble mode
also exists in parport_probe and only needs to be copied.
Any comments? Can I start to code it?
One question: How to export those functions? Add to parport->ops, export
via EXPORT_SYMBOL in parport_init or create something like a
parport->ieee1824->ops or something else?
Roger.
-- 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:50 EST