Re: [PATCH v2] drm/ttm: Support 52-bit PAs in ttm_place

[Christian König <christian.koenig@amd.com>]

On 5/13/26 16:50, Tvrtko Ursulin wrote:
> On 13/05/2026 15:12, Felix Kuehling wrote:
>> fpfn and lpfn in struct ttm_place are 32-bit page numbers. With 4KB page
>> size this can support up to 44-bit physical addressing. Grow these to
>> unsigned long to support larger physical addresses.
>>
>> Signed-off-by: Felix Kuehling <felix.kuehling@amd.com>
>> ---
>>   include/drm/ttm/ttm_placement.h | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/drm/ttm/ttm_placement.h b/include/drm/ttm/ttm_placement.h
>> index b510a4812609..ab2639e42c54 100644
>> --- a/include/drm/ttm/ttm_placement.h
>> +++ b/include/drm/ttm/ttm_placement.h
>> @@ -81,8 +81,8 @@
>>    * Structure indicating a possible place to put an object.
>>    */
>>   struct ttm_place {
>> -    unsigned    fpfn;
>> -    unsigned    lpfn;
>> +    uint64_t    fpfn;
>> +    uint64_t    lpfn;
>>       uint32_t    mem_type;
>>       uint32_t    flags;
>>   };
> 
> Maybe audit of usage sites is required to make sure no compiler warnings on 32-bit builds if nothing else. Things like:
> 
> amdgpu_vram_mgr_intersects()
> ...
>         if (place->fpfn < lpfn &&
>             (!place->lpfn || place->lpfn > fpfn))
>             return true;
> 
> Etc. Probably are all best adjusted to match the new type.
> 
> There is also:
> 
> struct ttm_resource {
>     unsigned long start;
> 
> Which also may need aligning. I know no one cares about 32-bit builds but some automated systems will probably test it and send reports.

Yeah I have been trying to remove ttm_resource.start exactly for that reason for a very very long time now.

Drivers shouldn't use that and instead rely on their own backends to give the actual placement.

Regards,
Christian.

> 
> Regards,
> 
> Tvrtko
>