Hi,
I have written an ECP DMA read function for the parrallel port that I
have been using with my CPiA webcam for a few months now. So far it will
only work with the webcam because a little hack that I had to do, and I
am looking insight on how should get around the hack. My only experience
with ECP is with my webcam, so I might have a biased view of how things
work.
The main difficulty I am having comes from the buffer. I can tell the
DMA how many bytes I want to read, but the ECP buffer will read more
data than that. This is fine for CPiA (and I expect it is okay in most
cases) as we want to read all the data the device has to send. I simply
leave data sitting in the buffer, ready for the next read from the CPiA
driver. The problem is that if I want to leave the data in the buffer before
reads, I can't return the parallel port to PS/2 mode between reads.
However, I have to return the parallel port to PS/2 mode before the next
ECP mode negotiation takes place (the parport_negotiate function in
ieee1284.c).
This is where the hack is. Since there doesn't seem to be any way for
parport_pc to intercept the call to parport_negotiate, I have hacked the
CPiA driver so that it restores PS/2 mode just before doing ECP mode
negotiations. This is fine for me, and has been working in a stable way
since december.
But now I would like to contribute my code to the community, and so I
have to find a cleaner way of doing things. This is where I need some
insight.
1) For people who have knowledge of protocols for other parallel
devices, will reading data into the buffer prematurely cause problems?
2) How should I get around the parport_negotiate problem? Should I add
it to the functions that can be overloaded by hardware specific drivers,
or should the CPiA driver in fact be calling some other hardware
specific function that I could have intercepted in the parport_pc driver
to get back into PS/2 mode before ECP mode negocitaion.
Thanks for your insight,
Blaise Gassend
PS If anybody wants the preliminary code, just ask.
-- 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 2b29 : Wed May 15 2002 - 17:45:05 EDT