schreite@helena.physik.uni-stuttgart.de
Wed, 30 Sep 98 14:48:33 +0100
Hi,
as discussed here a lot of weeks ago (I had several long times, when
I didn't work on this project), I implemented the support of
the various IEEE1284 modes via the functions:
* parport_ieee1284_write_block
* parport_ieee1284_read_block
* parport_ieee1284_change_channel
* parport_ieee1284_query_state
* parport_ieee1284_set_modemask
* parport_ieee1284_set_mode
The probe result from parport_probe.c, the knowledge about the parport
ability and parport_ieee1284_set_modemask determine, which IEEE1284 modes
are to be used. (As demanded here in this discussion, all probe results ...
can be overwritten by software for these functions.)
When initialized, just use parport_write_block,
parport_read_block and parport_change_channel (ECP/EPP) to
communicate to your peripheral. The write and read functions will
chose the appropriate IEEE1284 mode and will perform a negotiation
if necessary. (Channel_change won't change the IEEE1284 mode, but
report an error, if called within a mode without channels/addresses.)
This code is not ready, because it now only supports well:
- nibble mode
- byte mode
- ECP mode with PS2 parports (ECP emulated by software)
To be done is:
- support for compatibility mode
- support for EPP
- support for ECP via ECP parports
The latter will follow soon.
The main feature of this new code is, that its functions can be run
atomically: When the peripheral is busy, the functions don't call
schedule, but return immedeately and put the remaining work to be done
in task queues. This is very useful for socket driver or interrupt driven
code, which must not sleep. Of course all the functions also still can be
run "may-sleep" and won't return before having performed all work.
More about it: Read my short manual in parport_ieee1284.c!
David Campbell just sent me a copy of the IEEE1284.3 draft. I just took a
quick look on it: It seems to be important to support this standard soon.
My code just fullfills IEEE1284. Well, I think IEEE1284.3 is a question
for the whole parport team - didn't I already read some messages about it
here? I think both, a general IEEE1284.3 support for the whole parport
interface (i.e. providing new functions for it in parport_share or in
"parport_ieee1284.3.") or a little solution (i.e. just for this new
general IEEE1284 support) won't be a very difficult work to add to my
new code. My code is "almost prepared" for it. But I think,
it is not my task to decide, how to implement IEEE1284.3 for the
Linux parport interface. This new code now and here works fine with o n e
IEEE1284 peripheral attached to the parport.
Although there are lot's of things to add to "my" new code, it w o r k s
at least very stable! And the IEEE1284.4 (MLC) project inside the
HP officejet project is urgently waiting for this general IEEE1284 support.
So I hope, the responsable parport people will forward soon this patch
to Linus Torvalds, although it is not ready in every aspect.
In order not to disturb the frozen kernel, I masked the changes in
parport_probe.c via preprocessor commands.
If one doesn't uncomment the line
/* #define PROBE_FOR_IEEE1284_MODES */
in parport_probe.c, no function is changed, just new functions are added
to parport_ieee1284.c. But I hope a lot of people will uncomment that
line, for I can get feedback, whether any difficulties did occour for
any application. Further I have no peripheral able for byte mode -
perhaps somebody could test byte mode with my code. It should work,
since it follows strictly IEEE1284.
That's it. Tim, please let me know, whether we (IEEE1284.4-team inside
HP officejet project) can soon expect this IEEE1284 support in the
"official" kernels, which is frozen(!!!), or not!
Thanks, Roger.
P.S.
Tim Waugh wrote on 10 Jun 1998:
> Thanks a lot for this. Storing the well-known command-sets as a bitfield
> looks like a good plan.
I added also code, that stores the well-known command-sets as a bitfield
in parport_probe.c.
Following the parport_ieee1284.c.diff with the brief manual
and the other diffs:
-- 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:18:27 EST