amdgpu_ttm_...ap_alloc_sgt(9)

📦 version 7.3.1, in nixpkgs unstable

🌸 amdgpu_ttm_...ap_alloc_sgt(9) — from the Kernel API Manual 💅

okay so bestie, welcome to the manual page for amdgpu_ttm_...ap_alloc_sgt(9) — yes the title is truncated like that, that's just how it is, no cap. Anyway, put your hair up and let's get into it 🎀

✨ NAME ✨

amdgpu_ttm_mmio_remap_alloc_sgt — builds an sg_table for the MMIO_REMAP I/O aperture 🦋

So basically: you've got this weird little I/O window, and this function makes a scatter-gather table for it. Iconic behavior, honestly.

✨ SYNOPSIS ✨

int amdgpu_ttm_mmio_remap_alloc_sgt (struct amdgpu_device *adev , struct
ttm_resource *res , struct device *dev , enum dma_data_direction dir ,
struct sg_table **sgt );

✨ ARGUMENTS ✨

  • adev — the amdgpu device that provides the remap BAR base, aka adev->rmmio_remap.bus_addr. She's the source of truth for where this window lives 💖
  • res — the TTM resource of the BO you're exporting. It's expected to live in AMDGPU_PL_MMIO_REMAP, like, that's its whole address. Respect it.
  • dev — the importing device you're mapping for (typically attach->dev in dma-buf paths). Say hi to it for me 🫶
  • dir — the DMA data direction for the importer, passed straight to dma_map_resource. Just hand it over, don't overthink it.
  • sgt — the output! On success it's set to a newly allocated sg_table describing the I/O span ✨

✨ DESCRIPTION ✨

Okay so the lore: the HDP flush page (AMDGPU_PL_MMIO_REMAP) is a fixed hardware I/O window inside a PCI BAR — and there are literally no struct pages backing it. None. Zero. It's giving ghost town 👻

But importers still need a DMA address list, right? So instead of pages, we synthesize a minimal sg_table and populate it from dma_map_resource. That's the whole trick. And using the common amdgpu_res_cursor walker keeps the offset/size math consistent with the other TTM/manager users — consistency is the look, periodt 💅

  • res is assumed to be a small, contiguous I/O region (typically a single 4 KiB page) in AMDGPU_PL_MMIO_REMAP. Callers should validate placement before calling — like, do your homework first, bestie 🙈
  • The sg entry is created with sg_set_page(sg, NULL, …) to reflect I/O space. Yes, NULL on purpose. Not a bug. Slay.
  • The mapping uses DMA_ATTR_SKIP_CPU_SYNC because this is MMIO, not cacheable RAM — so that CPU sync would be pointless and we skip it, as one does.
  • Peer reachability / p2pdma policy checks must be done by the caller. Not us. That's your main character moment, not ours 🔥

✨ RETURN ✨

  • 0 on success, with *sgt set to a valid table that must be freed via amdgpu_ttm_mmio_remap_free_sgt. Don't forget the cleanup, it's the responsible thing to do 💜
  • -ENOMEM if allocation of the sg_table fails 😭
  • -EIO if dma_map_resource fails 💀

✨ SEE ALSO ✨

The kernel file herself: ./drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c — go read the source, iykyk 📖

And the whole friend group:

and that's the page!! 🎀 this one's out of ./drivers/gpu/drm/amd/amdgpu and dated October 2026 — so like, future vibes, butterfly effect, whatever 🌈💖 bye bestie, go free that sg_table 🧚

📦 where this page comes from