radeon_vram_location(9)

💖 radeon_vram_location(9) 💖

okay so this is a page from the Kernel API Manual, and bestie, it's all about radeon_vram_location — the little function that could, whose whole personality is "try to find VRAM location." Yes that's literally the NAME section, we're doing this properly ✨

---

🎀 SYNOPSIS 🎀

void radeon_vram_location (struct radeon_device *rdev , struct radeon_mc
*mc , u64 base );

like, it returns void, it takes three things, and it never fails. main character energy fr 🫶

---

🌸 ARGUMENTS 🌸

• rdev — the radeon device structure, and it's holding all the necessary informations. everything. the whole vibe check of the card lives here 💅
• mc — the memory controller structure, and this one's holding the memory informations (yes, plural, that's the manpage's grammar not mine, we respect it 🙈)
• base — the base address where VRAM is supposed to go. that's the spot. that's the assignment 📍

---

🦋 DESCRIPTION 🦋

so the function is gonna try to place VRAM at whatever base address you handed it — and just so you know, that base is so far either the PCI aperture address, or for IGP it's the TOM base address 👑

and here's where it gets real: if there's not enough space to fit the unvisible VRAM inside the 32bits address space, then we limit the VRAM size down to the aperture. not ideal but we're coping 💀

if we're using AGP, and the AGP aperture doesn't give us room for all the VRAM, then we restrict the VRAM to the PCI aperture size and print a warning. yes, it will publicly announce it. it's giving accountability ✨

and the iconic part: this function will never fail. worst case scenario? it just limits VRAM. that's it. that's the whole tragedy. it literally cannot flop 🔥

---

⭐ NOTE ⭐

GTT start, end, and size should be initialized before calling this function on an AGP platform. do not skip this step bestie, it's not optional 💀

Note 1: We don't explicitly enforce VRAM start to be aligned on VRAM size. this shouldn't be a problem because we're using the PCI aperture as a reference. otherwise this would be needed for rv280, all r3xx, and all r4xx — but not IGP 🧚

Note 2: we use mc_vram_size because on some board we need to program the mc to cover the whole aperture even if the VRAM size is inferior to the aperture size — that's Novell bug 204882 plus a whole pile of ubuntu ones 🍓

Note 3: when limiting vram it's safe to overwrite real_vram_size because we're not in the case where real_vram_size is inferior to mc_vram_size (i.e. not affected by the bogus hw of Novell bug 204882 plus all those ubuntu ones) 💜

Note 4: IGP TOM addr should be the same as the aperture addr — we don't explicitly check for that though. we simply trust. 🙈

FIXME: when reducing VRAM size, align the new size on power of 2. somebody bookmark this, it's on the list 😭

---

🌈 SEE ALSO 🌈

kernel file ./drivers/gpu/drm/radeon/radeon_device.c

and the whole friend group, no cap, every single one:

radeon_program_register_sequence(9), radeon_surface_init(9), radeon_scratch_init(9), radeon_scratch_get(9), radeon_scratch_free(9), radeon_doorbell_init(9), radeon_doorbell_fini(9), radeon_doorbell_get(9), radeon_doorbell_free(9), radeon_wb_disable(9), radeon_wb_fini(9), radeon_wb_init(9), radeon_gtt_location(9), radeon_card_posted(9), radeon_update_bandwidth_info(9), radeon_boot_test_post_card(9), radeon_dummy_page_init(9), radeon_dummy_page_fini(9), cail_pll_read(9), cail_pll_write(9), cail_mc_read(9), cail_mc_write(9), cail_reg_write(9), cail_reg_read(9), cail_ioreg_write(9), cail_ioreg_read(9), radeon_atombios_init(9), radeon_atombios_fini(9), radeon_combios_init(9), radeon_combios_fini(9), radeon_vga_set_decode(9), radeon_gart_size_auto(9), radeon_check_arguments(9), radeon_switcheroo_set_state(9), radeon_switcheroo_can_switch(9), radeon_device_init(9), radeon_device_fini(9), radeon_gpu_reset(9)

---

and that's the page!! 🫶 it lives in ./drivers/gpu/drm/radeon, the manpage is dated October 2026, and it's brought to you by the Kernel API Manual — stay slay, stay aligned, and remember to initialize your GTT first 💅✨🎀