Messages in this thread | | | Subject | Re: Alpha: virt_to_bus/GFP_DMA problem | Date | Sat, 11 Dec 1999 14:22:33 +0100 (MET) | From | (Rogier Wolff) |
| |
Alan Cox wrote: > > 1) Zones for ISA DMA, 32-bit PCI DMA, 64-bit PCI DMA. If we're going to > > support all the broken PCI cards we also need zones for 24, 30, and 31 > > bit PCI DMA. This is ugly, but so are the cards that need it. (I have a > > Its probably not worth the effort. Right now we are doing fine using the ISA > zone for 64Mb limited cards for example. It isnt like we need to allocate > very large amounts of such memory (except 32bit DMA) just that we need > to be able to succeed in the allocation
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/
| |