rproc_da_to_va(9)

💖 rproc_da_to_va(9) — the kernel API manual, but make it make sense 💖

okay bestie, welcome to the rproc_da_to_va(9) page from the Kernel API Manual 🎀 this is the little helper that turns remoteproc device addresses into kernel virtual addresses. it's giving translator energy and honestly? iconic. ✨

---

🌸 NAME 🌸

rproc_da_to_va — lookup the kernel virtual address for a remoteproc address

---

🦋 SYNOPSIS 🦋

void * rproc_da_to_va (struct rproc *rproc , u64 da , size_t len , bool
*is_iomem );

like, copy that exactly, no cap 👑

---

✨ ARGUMENTS ✨

• rproc — the handle of a remote processor. your main character, basically 🫶
• da — the remoteproc device address you want translated. the whole point of the function ngl
• len — length of the memory region that da is pointing to 📏
• is_iomem — an optional pointer that gets filled in to indicate whether da is iomapped memory. it's optional, so don't stress 💅

---

💜 DESCRIPTION 💜

so here's the lore: some remote processors will ask us to allocate them physically contiguous memory regions — we call those "carveouts" — and then map them to specific device addresses, which are hardcoded in the firmware. hardcoded, bestie. the firmware said what it said. 😭

they may also have dedicated memory regions internal to the processors, and they use those either exclusively or alongside carveouts. both can be true, it's not a contradiction 🧚

then they may ask us to copy objects into specific device addresses (e.g. code/data sections), or expose us certain symbols in other device addresses (e.g. their trace buffer). very much "here's where my stuff lives, please respect it" energy 🌈

this function is a helper function with which we can go over the allocated carveouts and translate specific device addresses to kernel virtual addresses so we can access the referenced memory. fr fr. and it also allows performing translations on the internal remoteproc memory regions through a platform implementation specific da_to_va ops, if present. if present!! conditional bestie 🦋

---

⭐ NOTE ⭐

phys_to_virt(iommu_iova_to_phys(rproc->domain, da)) will work too, but only on kernel direct mapped RAM memory. only. that's the catch. 🙈

instead, we're just using here the output of the DMA API for the carveouts, which should be more correct. and we love correct 💖

lowkey this is the paragraph where the manpage flexes on you, so read it twice before you go poking at address translation yourself 💀

---

👑 RETURN 👑

a valid kernel address on success, or NULL on failure. no in-between, no participation trophy 🌸

---

🎀 SEE ALSO 🎀

Kernel file ./drivers/remoteproc/remoteproc_core.c

and the whole group chat of related functions, all of them, in order, no skips:

rproc_find_carveout_by_name(9), rproc_check_carveout_da(9), rproc_handle_vdev(9), rproc_handle_trace(9), rproc_handle_devmem(9), rproc_alloc_carveout(9), rproc_release_carveout(9), rproc_handle_carveout(9), rproc_add_carveout(9), rproc_mem_entry_init(9), rproc_of_resm_mem_entry_init(9), rproc_of_parse_firmware(9), rproc_alloc_registered_carveouts(9), rproc_resource_cleanup(9), rproc_trigger_recovery(9), rproc_crash_handler_work(9), rproc_boot(9), rproc_shutdown(9), rproc_detach(9), rproc_get_by_phandle(9), rproc_set_firmware(9), rproc_add(9), devm_rproc_add(9), rproc_type_release(9), rproc_alloc(9), rproc_free(9), rproc_put(9), rproc_del(9), devm_rproc_alloc(9), rproc_add_subdev(9), rproc_remove_subdev(9), rproc_get_by_child(9), rproc_report_crash(9)

---

and that's the page!! this one lives in ./drivers/remoteproc, dated October 2026, and it's part of the Kernel API Manual — mwah, go translate some addresses, ily, bye bestie 💅💖✨