Hi Christian, On Wed, Jul 15, 2026 at 4:15 AM Christian König <[email protected]> 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
