lkml.org 
[lkml]   [2008]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.



\
 
 \ /
  Last update: 2008-10-01 16:53    [W:0.232 / U:0.424 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site