Re: GFP_DMA not good enough for problem hardware

Giuliano Procida (myxie@debian.org)
Mon, 18 Oct 1999 10:32:18 +0100


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/