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

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

[Felix Kuehling]

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;
 };
-- 
2.43.0

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

[Christian König]

On 5/13/26 16: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>

Reviewed-by: Christian König <christian.koenig@amd.com>

@Arun can you pick that one up and push it to drm-misc-next?

Thanks,
Christian.

> ---
>  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;
>  };

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

[Kuehling, Felix]

On 2026-05-13 09:19, Christian König wrote:
> On 5/13/26 16: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.

I forgot to update the commit message. It still says unsigned long. 
@Arun, can you update that before you push it to drm-misc-next?

Thanks,
   Felix


>>
>> Signed-off-by: Felix Kuehling <felix.kuehling@amd.com>
> Reviewed-by: Christian König <christian.koenig@amd.com>
>
> @Arun can you pick that one up and push it to drm-misc-next?
>
> Thanks,
> Christian.
>
>> ---
>>   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;
>>   };

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

[Arunpravin Paneer Selvam]

I modified the commit message and pushed into drm-misc-next.

Regards,
Arun.

On 5/13/2026 7:57 PM, Kuehling, Felix wrote:
> On 2026-05-13 09:19, Christian König wrote:
>> On 5/13/26 16: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.
>
> I forgot to update the commit message. It still says unsigned long. 
> @Arun, can you update that before you push it to drm-misc-next?
>
> Thanks,
>   Felix
>
>
>>>
>>> Signed-off-by: Felix Kuehling <felix.kuehling@amd.com>
>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>
>> @Arun can you pick that one up and push it to drm-misc-next?
>>
>> Thanks,
>> Christian.
>>
>>> ---
>>>   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;
>>>   };

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

[Tvrtko Ursulin]

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.

Regards,

Tvrtko

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

[Christian König]

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
> 

Claude review: drm/ttm: Support 52-bit PAs in ttm_place

[Claude Code Review Bot]

Overall Series Review

Subject: drm/ttm: Support 52-bit PAs in ttm_place
Author: Felix Kuehling <felix.kuehling@amd.com>
Patches: 6
Reviewed: 2026-05-16T11:53:55.057936

---

This is a single patch (v2) that widens `fpfn` and `lpfn` in `struct ttm_place` from `unsigned` (32-bit) to `uint64_t` (64-bit) to support physical addresses beyond 44 bits (32-bit page number × 4KB page = 44-bit PA).

The change is straightforward and minimal — only the struct definition is modified. However, there is a notable discrepancy between the commit message and the actual code, and the patch lacks accompanying driver-side audit work.

**Note:** The drm-next tree already contains this exact change (`uint64_t` for both fields), so this patch has either already been merged or an equivalent fix landed independently.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/ttm: Support 52-bit PAs in ttm_place

[Claude Code Review Bot]

Patch Review

**Commit message vs. code mismatch:**

The commit message says:
> Grow these to **unsigned long** to support larger physical addresses.

But the actual diff changes the type to `uint64_t`, not `unsigned long`:

```c
-	unsigned	fpfn;
-	unsigned	lpfn;
+	uint64_t	fpfn;
+	uint64_t	lpfn;
```

The code change (`uint64_t`) is actually the better choice — `unsigned long` would only be 32 bits on 32-bit architectures, which wouldn't achieve the stated goal. The commit message should be updated to say `uint64_t` to match the code.

**Title says "52-bit" but no justification:**

The subject line says "52-bit PAs" but neither the commit message nor the code explains why 52 bits specifically. With `uint64_t` page numbers and 4KB pages, the theoretical limit is 64+12 = 76-bit addressing. The title should either say "larger PAs" generically or explain why 52-bit is the relevant target (likely ARM64's 52-bit PA extension or x86's 5-level paging).

**Missing driver-side audit:**

The patch only changes the struct definition but doesn't audit the 21+ driver files that use `fpfn`/`lpfn`. Potential issues include:

1. **Truncation on assignment:** Drivers that assign `fpfn`/`lpfn` from 32-bit variables are fine (implicit widening), but any driver storing the result of these fields back into a 32-bit variable could truncate silently.

2. **Format strings:** Any `printk`/`drm_dbg` calls that print fpfn/lpfn with `%u` or `%x` will now produce warnings or incorrect output — they need `%llu` or `PRIu64`.

3. **`struct ttm_resource.start`** is `unsigned long`, which is 32-bit on 32-bit platforms. If fpfn/lpfn values >32 bits flow into `start`, there's a truncation path. On 64-bit platforms `unsigned long` is 64-bit so this isn't an issue in practice, but it's worth noting.

4. **Structure size change:** `struct ttm_place` grows from 16 bytes to 24 bytes (with padding). Since placements are typically small static/stack arrays, this shouldn't be a performance concern, but it's worth noting for any driver that allocates large arrays of `ttm_place`.

**Verdict:**

The code change itself is correct and desirable — `uint64_t` is the right type for page frame numbers that need to exceed 32-bit range. However:

- Fix the commit message to say `uint64_t` instead of `unsigned long`.
- Consider explaining *why* 52-bit in the subject, or generalize the title.
- An audit of callers for truncation and format string issues would strengthen this patch (or could be a follow-up).

---
Generated by Claude Code Patch Reviewer

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

[Felix Kuehling]

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..3e88869c0f58 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;
+	unsigned long	fpfn;
+	unsigned long	lpfn;
 	uint32_t	mem_type;
 	uint32_t	flags;
 };
-- 
2.43.0

Claude review: drm/ttm: Support 52-bit PAs in ttm_place

[Claude Code Review Bot]

Overall Series Review

Subject: drm/ttm: Support 52-bit PAs in ttm_place
Author: Felix Kuehling <felix.kuehling@amd.com>
Patches: 4
Reviewed: 2026-05-16T12:38:59.764368

---

This is a single patch that widens `fpfn` and `lpfn` in `struct ttm_place` from `unsigned` (32-bit) to `unsigned long` to support physical addresses beyond 44 bits (32-bit page numbers × 4KB pages). The motivation is sound — 32-bit page frame numbers limit addressing to 16 TiB, which is increasingly insufficient.

However, **this patch is already superseded by work in drm-next**. The current drm-next tree already has these fields as `uint64_t`:

```c
struct ttm_place {
	uint64_t	fpfn;
	uint64_t	lpfn;
	uint32_t	mem_type;
	uint32_t	flags;
};
```

The `uint64_t` approach in drm-next is **strictly better** than the `unsigned long` proposed here, because `unsigned long` is only 32-bit on 32-bit platforms, providing no improvement there, while `uint64_t` is unconditionally 64-bit.

**Recommendation: NAK — this change has already landed in drm-next with a superior type choice (`uint64_t` vs `unsigned long`).**

---

---
Generated by Claude Code Patch Reviewer

Claude review: drm/ttm: Support 52-bit PAs in ttm_place

[Claude Code Review Bot]

Patch Review

**Already superseded in drm-next.** The fields have been changed to `uint64_t`, which is the correct fix.

**Type choice concern:** Even if this weren't superseded, `unsigned long` would be the wrong type here. On 32-bit kernels, `unsigned long` is 32 bits — identical to `unsigned` — so the patch would silently provide no benefit on those platforms. The `uint64_t` already in drm-next avoids this problem.

```c
-	unsigned	fpfn;
-	unsigned	lpfn;
+	unsigned long	fpfn;
+	unsigned long	lpfn;
```

**Missing downstream widening:** Note that even with the TTM-level fix (whether this patch or the drm-next version), `struct amdgpu_mem_partition_info` in `amdgpu_gmc.h` still uses `uint32_t` for its `fpfn`/`lpfn`:

```c
struct amdgpu_mem_partition_info {
	union {
		struct {
			uint32_t fpfn;
			uint32_t lpfn;
		} range;
```

These values feed directly into `places[c].fpfn` at `amdgpu_object.c:123`:

```c
places[c].fpfn = adev->gmc.mem_partitions[mem_id].range.fpfn;
...
places[c].lpfn = adev->gmc.mem_partitions[mem_id].range.lpfn + 1;
```

If the goal is truly 52-bit PA support for AMD GPUs, this downstream struct also needs widening. A follow-up patch addressing `amdgpu_mem_partition_info` would be needed to make the full path consistent.

**No callers updated:** The patch changes the struct definition but doesn't update any callers that may be using `unsigned` or `uint32_t` local variables to hold these values. A grep shows ~31 files touch `fpfn`/`lpfn` across multiple drivers (amdgpu, xe, i915, nouveau, radeon, vmwgfx, qxl, etc.). While many assign literal 0 (safe), some do arithmetic that could be affected by the type change. The patch should have audited these call sites, or at minimum mentioned them in the commit message.

**Verdict:** This patch is redundant with drm-next and uses an inferior type. If the submitter needs 52-bit PA support, they should rebase onto drm-next (which already has the `uint64_t` fix) and submit follow-up patches to widen the AMD-specific structures like `amdgpu_mem_partition_info`.

---
Generated by Claude Code Patch Reviewer