>
> On Thu, Jun 22, 2000 at 05:21:01PM -0500, Richard Bonomo wrote:
> >
> > I am struggling with writing a device driver to
> > pull data into the parallel port in ECP mode.
> > I am attempting to read in a continuing stream
> > of data (uncontrolled) and read into into a
> > LARGE RAM buffer.
>
> This is about what my parport webcam driver does, see cpia_pp.c in the
> 2.2.16 kernel. However my LARGE (about 300K IIRC) might not be as LARGE
> as yours. ;)
>
Is that available at Redhat.com or linux.org?
(Is it possible to get just the webcam driver?)
<snip>
> > 1. Can the parallel port use DMA into high memory
> > nowadays? I have the impression that parallel
> > ports using DMA are restricted to ISA address
> > space on current Intel platforms running Linux.
> > And thus to the lower 16 MB of physical memory.
> > Is this correct?
>
> If you want your code to be portable do not do it this way. You will
> get all sorts of hardware dependencies. The real big problem you will
> face with DMA this way is to have a contiguous amount of LARGE memory
> allocated in a reliable way. This is _not_ a trivial task.
>
Actually, I am not particularly concerned about portability.
I AM trying to avoid hacking the kernel though, to make
future kernel upgrades easier...
This is a speciallized application.
Anyway, am I correct about the DMA restrictions?
> > 2. If I reserve upper memory using the "mem=32m"
> > (or whatever size) option at boot, is a simple
> > call to ioremap all that is necessary to make
> > the space available to the kernel? Is there any
> > reason I cannot use a pointer to the physical
> > address when accessing from the kernel?
>
> There are ways to do such stuff. There is a kernel patch and if you
> really want to do such stuff I can search for the references. But as
> above, this is clumsy and highly non-standard.
>
I am trying to avoid messing with the kernel itself,
as I have noted. Alessandro Rubini makes some references
to reserving memory at boot time using "mem=<size>" to
restrict the OS to whatever you care to, leaving the rest
of the memory free. He indicates (if I understand correctly)
that you can then have access to the remainder of the memory
using ioremap. It is not clear to me how this works, or when
and if you have to process the results of ioremap through
something like virt_to_bus.
> > 3. If DMA direct to high memory is not possible
> > (or is not advisable to avoid tying the bus
> > up for extended periods), is there likely any advantage
> > to DMA to a very small buffer in lower memory
> > and then a copy to a high memory buffer over
> > doing an interrupt-driven programmed i/o directly
> > to a buffer in very high memory?
> > I am running on an Intel platform with a
> > SE440-BX2 motherboard, using Redhat Linux 6.1
> > (linux kernel 2.2.12).
>
> This is what I chose to do for the webcam driver. I allocate a
> PAGE_SIZE DMA-buffer and copy that in the interrupt-handler to the
> LARGE buffer allocated in more conventional way. Thruput is exept for
> the extrem cases almost independant of the DAM-buffer size. What varies
> is the interrupt congestion. So you just have to make the DMA-buffer
> big enough and PAGE_SIZE is adequate. Of cause you do copy the data
> around once but for modern boards copying data that comes in on
> parport-thruput speed is no problem. If you are restricted to a 386
> that might be a problem. :)
>
Not trying to use DMA into high memory (if that is even possible)
would make having to invoke kluges such as "mem=32m" at boot time
unnecessary, and allow the use of something like Alessandro's
"allocator" program to fetch memory (or something similar).
Do you think that DMA offers a speed advantage over interrupt-driven
programmed i/o, given the additional overhead?
> -Peter
>
> --
> Even the thought that a ship was waiting to take him back to Earth
> did not wipe out the sense of loss he felt at that moment.
> -------------------------------
> Email: Peter_Pregler@email.com
>
Rich
-- ************************************************ Richard Bonomo UW Space Astronomy Laboratory ph: (608) 263-4683 telefacsimile: (608) 263-0361 email: bonomo@sal.wisc.edu ************************************************-- 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 : Fri Jun 23 2000 - 16:41:21 EDT