[PATCH] drm/radeon: allocate dummy_page without DMA32 on fail

[PATCH] drm/radeon: allocate dummy_page without DMA32 on fail

[Anirudh Srinivasan]

radeon fails to probe on platforms that have all their memory above the
32-bit range with an -ENOMEM because dummy_page_init calls
alloc_page(GFP_DMA32), which would fail.

Allow this driver to work on such platforms by falling back to
ZONE_NORMAL regions. dma_map_page called subsequently would catch any
issues with the device being unable to DMA into the mapped page.

An equivalent fix was applied to ttm in commit 0a8c1feed387 ("drm/ttm:
allocate dummy_read_page without DMA32 on fail")

Signed-off-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
---
I had issues getting a R5 430 (Oland) with the radeon driver to probe on
a spacemit K3, which has no 32-bit memory regions. With this patch, the
driver was able to probe. The K3 supports up to 40 bit DMA and also has
an IOMMU, so the card works with the board. I was able to reach a
framebuffer console with this patch.
---
 drivers/gpu/drm/radeon/radeon_device.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
index 705c012fcf9e0..e8b1fa715a648 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -783,9 +783,15 @@ int radeon_dummy_page_init(struct radeon_device *rdev)
 {
 	if (rdev->dummy_page.page)
 		return 0;
-	rdev->dummy_page.page = alloc_page(GFP_DMA32 | GFP_KERNEL | __GFP_ZERO);
-	if (rdev->dummy_page.page == NULL)
-		return -ENOMEM;
+	rdev->dummy_page.page = alloc_page(GFP_DMA32 | GFP_KERNEL | __GFP_ZERO |
+				    __GFP_NOWARN);
+	/* Retry without GFP_DMA32 for platforms where DMA32 is not available */
+	if (rdev->dummy_page.page == NULL) {
+		rdev->dummy_page.page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+		if (rdev->dummy_page.page == NULL)
+			return -ENOMEM;
+		dev_warn(&rdev->pdev->dev, "Falling back to non-DMA32 dummy page allocation\n");
+	}
 	rdev->dummy_page.addr = dma_map_page(&rdev->pdev->dev, rdev->dummy_page.page,
 					0, PAGE_SIZE, DMA_BIDIRECTIONAL);
 	if (dma_mapping_error(&rdev->pdev->dev, rdev->dummy_page.addr)) {

---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260714-radeon_32bit_fix-8b1058b6d571

Best regards,
--  
Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>

Re: [PATCH] drm/radeon: allocate dummy_page without DMA32 on fail

[Christian König]

On 7/14/26 18:03, Anirudh Srinivasan wrote:
> radeon fails to probe on platforms that have all their memory above the
> 32-bit range with an -ENOMEM because dummy_page_init calls
> alloc_page(GFP_DMA32), which would fail.

Unfortunately I clearly have to reject this.

The DMA32 allocation is mandatory for radeon to work correctly on some platforms.

> Allow this driver to work on such platforms by falling back to
> ZONE_NORMAL regions. dma_map_page called subsequently would catch any
> issues with the device being unable to DMA into the mapped page.

No, it doesn't.

It's just your special case that dma_map_page() is able to use some IOMMU to remap the page below 32bits so that the driver can access it.

The problem is that we have quite a bunch of cases where this doesn't work correctly and eventually result in all kinds of trouble, including random memory corruptions.

In those cases it's better to not load the driver at all than to later deal with corrupted data.

What could be possible is to add a special quirk for your platform to not allocate the dummy page as DMA32 in the first place.

> An equivalent fix was applied to ttm in commit 0a8c1feed387 ("drm/ttm:
> allocate dummy_read_page without DMA32 on fail")

Yeah, but only after making sure that radeon still doesn't load on such platforms.

Regards,
Christian.

> 
> Signed-off-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
> ---
> I had issues getting a R5 430 (Oland) with the radeon driver to probe on
> a spacemit K3, which has no 32-bit memory regions. With this patch, the
> driver was able to probe. The K3 supports up to 40 bit DMA and also has
> an IOMMU, so the card works with the board. I was able to reach a
> framebuffer console with this patch.
> ---
>  drivers/gpu/drm/radeon/radeon_device.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
> index 705c012fcf9e0..e8b1fa715a648 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -783,9 +783,15 @@ int radeon_dummy_page_init(struct radeon_device *rdev)
>  {
>         if (rdev->dummy_page.page)
>                 return 0;
> -       rdev->dummy_page.page = alloc_page(GFP_DMA32 | GFP_KERNEL | __GFP_ZERO);
> -       if (rdev->dummy_page.page == NULL)
> -               return -ENOMEM;
> +       rdev->dummy_page.page = alloc_page(GFP_DMA32 | GFP_KERNEL | __GFP_ZERO |
> +                                   __GFP_NOWARN);
> +       /* Retry without GFP_DMA32 for platforms where DMA32 is not available */
> +       if (rdev->dummy_page.page == NULL) {
> +               rdev->dummy_page.page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> +               if (rdev->dummy_page.page == NULL)
> +                       return -ENOMEM;
> +               dev_warn(&rdev->pdev->dev, "Falling back to non-DMA32 dummy page allocation\n");
> +       }
>         rdev->dummy_page.addr = dma_map_page(&rdev->pdev->dev, rdev->dummy_page.page,
>                                         0, PAGE_SIZE, DMA_BIDIRECTIONAL);
>         if (dma_mapping_error(&rdev->pdev->dev, rdev->dummy_page.addr)) {
> 
> ---
> base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
> change-id: 20260714-radeon_32bit_fix-8b1058b6d571
> 
> Best regards,
> --
> Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
> 

Re: [PATCH] drm/radeon: allocate dummy_page without DMA32 on fail

[Anirudh Srinivasan]

Hi Christian,

On Wed, Jul 15, 2026 at 4:15 AM Christian König
<christian.koenig@amd.com> wrote:
>
> On 7/14/26 18:03, Anirudh Srinivasan wrote:
> > radeon fails to probe on platforms that have all their memory above the
> > 32-bit range with an -ENOMEM because dummy_page_init calls
> > alloc_page(GFP_DMA32), which would fail.
>
> Unfortunately I clearly have to reject this.
>
> The DMA32 allocation is mandatory for radeon to work correctly on some platforms.
>
> > Allow this driver to work on such platforms by falling back to
> > ZONE_NORMAL regions. dma_map_page called subsequently would catch any
> > issues with the device being unable to DMA into the mapped page.
>
> No, it doesn't.
>
> It's just your special case that dma_map_page() is able to use some IOMMU to remap the page below 32bits so that the driver can access it.
>
> The problem is that we have quite a bunch of cases where this doesn't work correctly and eventually result in all kinds of trouble, including random memory corruptions.
>
> In those cases it's better to not load the driver at all than to later deal with corrupted data.

So this platform has an IOMMU, but it isn't enabled in the upstream
kernel at the moment. I am able to boot up to framebuffer console. Is
there anything that isn't expected to work in this setup? Is there
some test I can run to verify this?

I should look into whether the IOMMU on this cihp can be enabled and
then try this out too.

>
> What could be possible is to add a special quirk for your platform to not allocate the dummy page as DMA32 in the first place.

So some kind of a whitelisted set of PCIE vendor/ID combos (with
working IOMMUS?) where we fallback to non DMA32 ranges?

Regards
Anirudh Srinivasan

Re: [PATCH] drm/radeon: allocate dummy_page without DMA32 on fail

[Christian König]

Hi Anirudh,

On 7/16/26 04:08, Anirudh Srinivasan wrote:
> Hi Christian,
> 
> On Wed, Jul 15, 2026 at 4:15 AM Christian König
> <christian.koenig@amd.com> wrote:
>>
>> On 7/14/26 18:03, Anirudh Srinivasan wrote:
>>> radeon fails to probe on platforms that have all their memory above the
>>> 32-bit range with an -ENOMEM because dummy_page_init calls
>>> alloc_page(GFP_DMA32), which would fail.
>>
>> Unfortunately I clearly have to reject this.
>>
>> The DMA32 allocation is mandatory for radeon to work correctly on some platforms.
>>
>>> Allow this driver to work on such platforms by falling back to
>>> ZONE_NORMAL regions. dma_map_page called subsequently would catch any
>>> issues with the device being unable to DMA into the mapped page.
>>
>> No, it doesn't.
>>
>> It's just your special case that dma_map_page() is able to use some IOMMU to remap the page below 32bits so that the driver can access it.
>>
>> The problem is that we have quite a bunch of cases where this doesn't work correctly and eventually result in all kinds of trouble, including random memory corruptions.
>>
>> In those cases it's better to not load the driver at all than to later deal with corrupted data.
> 
> So this platform has an IOMMU, but it isn't enabled in the upstream
> kernel at the moment. I am able to boot up to framebuffer console.

That is not even remotely enough to actually test the driver.

What happens is that you allocation succeeds, but you simply doesn't exercise the functionality which would need the dummy page.

> Is there anything that isn't expected to work in this setup? Is there
> some test I can run to verify this?

For the technical background, the dummy page is there to prevent buggy applications/driver code to crash the system.

The general idea is that a reads/writes which otherwise would go into nirvana are redirected to the dummy page and so prevented from harming the system as a whole.

The problem is that while some HW generations can handle 40bit of PCI addresses the dummy page register is only 32bit wide in some cases (I would need to double check your specific HW generation, maybe that would help).

To actually make sure everything works as expected you need to enable some desktop system and run OpenGL tests. If then an error occurs and IOMMU confirms that the right address is used for the dummy write then we could be save that this actually works.

> I should look into whether the IOMMU on this cihp can be enabled and
> then try this out too.

Well enabling IOMMU could eventually help, but the code in the current form would still fail. You need to use something like dma_alloc_coherent() and I think that this won't work because of the HW restrictions.

>>
>> What could be possible is to add a special quirk for your platform to not allocate the dummy page as DMA32 in the first place.
> 
> So some kind of a whitelisted set of PCIE vendor/ID combos (with
> working IOMMUS?) where we fallback to non DMA32 ranges?

No, what you are testing here is basically that display is functional and not anything else.

Regards,
Christian.

> 
> Regards
> Anirudh Srinivasan

Re: [PATCH] drm/radeon: allocate dummy_page without DMA32 on fail

[Anirudh Srinivasan]

Hi Christian,

On Thu, Jul 16, 2026 at 2:34 AM Christian König
<christian.koenig@amd.com> wrote:
>
> Hi Anirudh,
>
> On 7/16/26 04:08, Anirudh Srinivasan wrote:
> > Hi Christian,
> >
> > On Wed, Jul 15, 2026 at 4:15 AM Christian König
> > <christian.koenig@amd.com> wrote:
> >>
> >> On 7/14/26 18:03, Anirudh Srinivasan wrote:
> >>> radeon fails to probe on platforms that have all their memory above the
> >>> 32-bit range with an -ENOMEM because dummy_page_init calls
> >>> alloc_page(GFP_DMA32), which would fail.
> >>
> >> Unfortunately I clearly have to reject this.
> >>
> >> The DMA32 allocation is mandatory for radeon to work correctly on some platforms.
> >>
> >>> Allow this driver to work on such platforms by falling back to
> >>> ZONE_NORMAL regions. dma_map_page called subsequently would catch any
> >>> issues with the device being unable to DMA into the mapped page.
> >>
> >> No, it doesn't.
> >>
> >> It's just your special case that dma_map_page() is able to use some IOMMU to remap the page below 32bits so that the driver can access it.
> >>
> >> The problem is that we have quite a bunch of cases where this doesn't work correctly and eventually result in all kinds of trouble, including random memory corruptions.
> >>
> >> In those cases it's better to not load the driver at all than to later deal with corrupted data.
> >
> > So this platform has an IOMMU, but it isn't enabled in the upstream
> > kernel at the moment. I am able to boot up to framebuffer console.
>
> That is not even remotely enough to actually test the driver.
>
> What happens is that you allocation succeeds, but you simply doesn't exercise the functionality which would need the dummy page.
>
> > Is there anything that isn't expected to work in this setup? Is there
> > some test I can run to verify this?
>
> For the technical background, the dummy page is there to prevent buggy applications/driver code to crash the system.
>
> The general idea is that a reads/writes which otherwise would go into nirvana are redirected to the dummy page and so prevented from harming the system as a whole.
>
> The problem is that while some HW generations can handle 40bit of PCI addresses the dummy page register is only 32bit wide in some cases (I would need to double check your specific HW generation, maybe that would help).
>
> To actually make sure everything works as expected you need to enable some desktop system and run OpenGL tests. If then an error occurs and IOMMU confirms that the right address is used for the dummy write then we could be save that this actually works.

Thanks for explaining what the dummy page is used for. I will try
running some OpenGL tests with/without the IOMMU and see what happens.
It'll probably be a while till I can test this since the IOMMU isn't
enabled in upstream kernels yet.

>
> > I should look into whether the IOMMU on this cihp can be enabled and
> > then try this out too.
>
> Well enabling IOMMU could eventually help, but the code in the current form would still fail. You need to use something like dma_alloc_coherent() and I think that this won't work because of the HW restrictions.
>
> >>
> >> What could be possible is to add a special quirk for your platform to not allocate the dummy page as DMA32 in the first place.
> >
> > So some kind of a whitelisted set of PCIE vendor/ID combos (with
> > working IOMMUS?) where we fallback to non DMA32 ranges?
>
> No, what you are testing here is basically that display is functional and not anything else.

I think I understand this now. You're suggesting that we skip
allocating the dummy page in this specific case.

>
> Regards,
> Christian.
>
> >
> > Regards
> > Anirudh Srinivasan
>

Re: [PATCH] drm/radeon: allocate dummy_page without DMA32 on fail

[Christian König]

On 7/16/26 16:31, Anirudh Srinivasan wrote:
...
>>>>
>>>> What could be possible is to add a special quirk for your platform to not allocate the dummy page as DMA32 in the first place.
>>>
>>> So some kind of a whitelisted set of PCIE vendor/ID combos (with
>>> working IOMMUS?) where we fallback to non DMA32 ranges?
>>
>> No, what you are testing here is basically that display is functional and not anything else.
> 
> I think I understand this now. You're suggesting that we skip
> allocating the dummy page in this specific case.

Well that won't really work.

We had some minimal fallback to enable only CRTCs in the radeon driver but that was more or less only used to print error messages and not let people end up with a completely black desktop if HW initialization fails.

As far as I can see you can't use the driver/HW combination on this platform when DMA32 isn't available.

You could give efifb or vesafb a try, that is pretty much the same functionality as radeon without acceleration.

On the other hand what HW generation do you have? Maybe it's possible that this is something newer like SI or CIK? In that case you could try the more modern amdgpu driver, it should be able to better deal with the situation.

Regards,
Christian.

> 
>>
>> Regards,
>> Christian.
>>
>>>
>>> Regards
>>> Anirudh Srinivasan
>>