Hi,
> (I also need to get ECP-with-DMA working .... need to get a ECP port card for
> that, though, and only have free PCI slots ...Does 2.4.x have working DMA
> support for ECP ports?)
I have a working ECP with DMA patch for 2.4.x kernels. It has been
working in a stable way for me for about a year now. At the time,
I uploaded it to the CPiA mailing list. However, for now there is a
small hack involved which prevents the patch from being put to general
use. I am pasting my old post below for reference.
I would have a little time to spend working on this, but I would like
somebody's opinion on the right way of doing things before I get
started, and so far the only (not really useful) reaction I have had is
"there is a bug somewhere in the linux parallel port DMA support".
Blaise Gassend
---------- Snip ------------
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 : Sat Dec 28 2002 - 08:20:11 EST