Even if that's the "workaround" for now, I would really prefer to have
a DMA_24 flag (replacing the current ISA DMA which can reach 24 bits
of addressing), and an identically defined 30, 31 and 32bit (and 28,
26?), so that the code is clearly marked.
We need to watch the future, where we may want to change it. Finding
out after the fact which devices have what limits (suppose on the
surface a DMA address register is 28 bits, but the 28th bit is
broken. So the developer may know that only 27 bits should be
used. This is something that is better "documented" in the code while
someone is really "into" the device, rather than a few years later...)
Machines with ISA Olicom cards, often run out of DMA memory. We really
want to allocate a new buffer on every packet that comes in. That way
the software copy is prevented. Maybe it doesn't matter all that much
because of cache warming and effects like that, but the driver is
designed to grab a new DMA-able-buffer for every packet. Turns out
that when there is turnaround in both buffers for the card and memory
for user-applications, the end result is that we run out of DMA
buffers. The Olicom driver has logic in it to continue to work in that
case: it won't let go of last buffer it gets from the system. That one
will be used as a bounce buffer, and that keeps everything from
breaking down. Now, there have been improvements in this area, but
it sure was tricky to get right....
Roger.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* "I didn't say it was your fault. I said I was going to blame it on you."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/