Re: Alpha: virt_to_bus/GFP_DMA problem

Jes Sorensen (Jes.Sorensen@cern.ch)
10 Dec 1999 17:37:19 +0100


>>>>> "Jakma" == Jakma, Paul <Paul.Jakma@compaq.com> writes:

>> How can this work, if the device only respects the lower 24 bit of
>> the address it is given? If it sets up a DMA cycle at that address,
>> whereas system memory as seen from the bus starts at say 1GB, then
>> the behavior of the machine is unspecified: it may reject the cycle
>> (I guess, need to check PCI docs for that) or allow the DMA data to
>> go somewhere random - hopefully just into blue air.

Jakma> most of the PCI alpha's support scatter gather in the
Jakma> chipset. ie you can dynamically setup multiple bus->phys
Jakma> windows in the chipset.

Hmmm this is quite neat, my posting was of course based on the
assumption that the bus controller was simple ... doesn't change the
fact that the ESS Solo1 is a pile of j**k ;-)

Jakma> so you could map any part of pci bus address to anywhere in
Jakma> physical space. With multiple windows you could even map a
Jakma> contigious pci bus space to a fragmented range of physical
Jakma> addresses.

This would be good for low end devices that don't do scatter/gather
themselves - I seem to remember some of the frame grabber ones have
this problem.

>> Hmmm, there are several devices out there that will only do 24bit,
>> 30bit and 31bit DMA respectively - we need a generic solution I
>> think.

Jakma> support for the 21172/21174 style hardware scatter gather would
Jakma> be nice and generic.. :)

Right, this should of course be combined with generic scatter/gather
support in important places like the skbuffs (through the use of
kiobufs). Some well designed hardware (like some modern network cards)
already supports this .... and it would solve a lot of problems for
the HIPPI and Fibre Channel drivers.

Jes

-
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/