Messages in this thread | | | Date | Wed, 01 Oct 2008 09:50:24 -0500 | From | Christoph Lameter <> | Subject | Re: wrong usage of MAX_DMA_ADDRESS in bootmem.h |
| |
Russell King - ARM Linux wrote:
>> Someone screwed around with the basics here. MAX_DMA_ADDRESS is no longer >> related to MAX_DMA_PFN for the x86_32 case. What is the point of relating >> MAX_DMA_ADDRESS to PAGE_OFFSET? Looks like we are creating more confusion >> about the strange DMA zone. > > Because it is a virtual address. It has to be. You're using __pa() on it, > and __pa() ONLY takes a virtual address.
Ok. I agree you need to add a __va to it in order to convert it back later. That was not really the point. MAX_DMA_PFN can be used as a base to calculate MAX_DMA_ADDRESS. Both are related and currently some arches go one way and other do vice versa. Its particularly strange that x86_32 and x86_64 go different ways. Can we unify that to one way only and put the definition of MAX_DMA_ADDRESS in core code?
Also as a result of the long type used for a kernel "virtual" address we have the strange situation that all uses of MAX_DMA_ADDRESS require a cast.
>> The best would be to rename these variables to make the semantics clearer >> >> ZONE_DMA related variables: >> >> MAX_DMA_PFN -> MAX_ZONE_DMA_PFN >> MAX_DMA_ADDRESS -> MAX_ZONE_DMA_ADDRESS >> >> MAX_DMA32_PFN -> MAX_ZONE_DMA32_PFN >> MAX_DMA32_ADDRESS -> MAX_ZONE_DMA32_ADDRESS >> >> Then the general DMAability >> >> MAX_DMA_ADDRESS -> DMA_LIMIT > > That's no clearer. Are they physical addresses? Or are they virtual > addresses? Can't guess that from the names.
It is clearer because the association with ZONE_DMA is in the name now. One no longer has the impression that MAX_DMA_ADDRESS is upper bound of any DMA transfer in the system.
Maybe we should make these physical addresses to avoid the casts? That would avoid casts in the bootmem allocator etc etc.
| |