Messages in this thread | | | Date | Mon, 18 Oct 1999 10:32:18 +0100 | From | Giuliano Procida <> | Subject | Re: GFP_DMA not good enough for problem hardware |
| |
On Mon, Oct 18, 1999 at 01:57:36AM -0700, David S. Miller wrote: > Sometimes I wish people who make such cards would think twice about > putting such restrictions into their PCI addressing logic, even for > boot time microcode loading operations.
What can I say? Me too.
It is not a hardware restriction, probably just a historical accident. At some point in the distant past, the card microcode did use the top one or two bits of addresses for its own purposes. However, this was sensibly fixed when it caused problems with tests on large-memory machines.
The card contains a bridge chip (PLX) which can be programmed to map a window into the host's PCI address space. Unfortunately, this feature is used in the boot loader (presumably for convenience). The microcode is trying to read a command block from host memory but the read access never gets through the PLX (I have checked with a logic analyser).
> I say this, because cards like the one you are working on can thus > _never_ work in an UltraSparc/PCI based system, because on such > systems, in the PCI DMA areas the top bit needs to be set, so all such > devices which "chop off" or do not implement the higher PCI addressing > bits for bus mastering, will not work on Sparc/PCI.
DMA is completely unaffected in this respect. The PLX only maps direct reads from and writes to the memory space on the other side. I believe that the microcode turns off the window and uses DMA exclusively (also handled by the PLX).
> Note also that this makes such cards out of spec, PCI wise. Many > PCI sound cards have these issues as well (most implement the lower > 24 bits, and use the upper bits in their DMA descriptors for control > information, supposedly to save logic gates in the hw or to simplify > it in some other way).
I haven't found anything obvious under drivers/sound.
Giuliano.
- 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/
| |