pvr_fw_obje...d_map_offset(9)

📦 version 7.3.1, in nixpkgs unstable

💖 pvr_fw_object_create_and_map_offset 💖

Okay so bestie, gather round, because this is the pvr_fw_object_create_and_map_offset(9) page from the Kernel API Manual, section 9, and it is literally the "make a firmware object and then map it to firmware at the exact offset you asked for, and also to the CPU" function. Multi-tasking icon behaviour. 🎀

✨ NAME ✨

pvr_fw_object_create_and_map_offset — create a FW object and map it to the firmware at the provided offset and to the CPU. Both. At once. Obsessed. 🦋

🌸 SYNOPSIS 🌸

void * pvr_fw_object_create_and_map_offset (struct pvr_device *pvr_dev ,
u32 dev_offset , size_t size , u64 flags , void (*init)(void *cpu_ptr,
void *priv) , void *init_priv , struct pvr_fw_object **fw_obj_out );

🧚 ARGUMENTS 🧚

Seven args, no cap. Let's go one by one:

  • pvr_dev — the PowerVR device pointer. Your device. Your main character. 💜
  • dev_offset — the base address of the FW mapping you want, expressed as an offset from the start of the FW heap. So like, you're picking the seat, not the whole row. 🎀
  • size — how big the object is, in bytes. Standard. 💅
  • flags — the options that affect both this operation and any future mapping operations performed on the returned object. Heads up: this has to be a combo of DRM_PVR_BO_* and/or PVR_BO_* flags. It's giving "your choices echo into the future" ngl. ✨
  • init — the initialisation callback. Signature is void (*init)(void *cpu_ptr, void *priv), so it takes your CPU pointer and your private pointer. Slay. 🫶
  • init_priv — the private pointer you hand off to that initialisation callback. 🍓
  • fw_obj_out — pointer to the location where the newly created object pointer gets stored. The little drop-off box. 📦

💀 DESCRIPTION 💀

Big vibe note first: DRM_PVR_BO_DEVICE_PM_FW_PROTECT is implied for all FW objects. Like, you don't even have to say it, it's just the house rules. 🏠

Because of that implication, this function will fail if flags has DRM_PVR_BO_CPU_ALLOWUSERSPACE_ACCESS set. Not "might", not "could" — it will. So don't do that, bestie. 🙈

Also, and this is the part everybody forgets: the caller is responsible for calling pvr_fw_object_vunmap to release the CPU mapping. That's your job. Nobody's gonna do it for you. Lease the mapping, return the mapping. Periodt. 🔥

⭐ RETURN ⭐

Three possible outcomes, and it's one of these:

  • Pointer to the CPU mapping of the newly created object, or
  • any error returned by pvr_fw_object_create, or
  • any error returned by pvr_fw_object_vmap.

Three-way tie, basically. 💫

🌈 SEE ALSO 🌈

Kernel file ./drivers/gpu/drm/imagination/pvr_fw.c — and the whole friend group:

Every single one of them, linked and accounted for. Go read them, iykyk. 📚✨

That's the whole page, bestie 🫶 — courtesy of ./drivers/gpu/drm/imagination, October 2026, Kernel API Manual, section 9. Stay mapped, stay validated, and please remember the vunmap. 😭💖

📦 where this page comes from