From: Boris Brezillon <boris.brezillon@collabora.com>
To: Ketil Johnsen <ketil.johnsen@arm.com>
Cc: Steven Price <steven.price@arm.com>,
Liviu Dudau <liviu.dudau@arm.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Daniel Almeida <daniel.almeida@collabora.com>,
Alice Ryhl <aliceryhl@google.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 6/6] drm/panthor: Expose protected rendering features
Date: Fri, 11 Sep 2026 16:42:29 +0200 [thread overview]
Message-ID: <20260911164229.6858768c@fedora-21.home> (raw)
In-Reply-To: <20260911114014.79139-7-ketil.johnsen@arm.com>
On Fri, 11 Sep 2026 13:40:14 +0200
Ketil Johnsen <ketil.johnsen@arm.com> wrote:
> From: Boris Brezillon <boris.brezillon@collabora.com>
>
> Extensions to Panthor uAPI:
> - New IOCTL for user space to provide protected FW memory.
> - New query for checking protected rendering availability/status
> and requirements.
> - Extends group creation to allow user space to provide a protected
> suspend buffer.
>
> The Mali GPU FW needs some protected memory when executing in protected
> mode. This FW memory section is assigned a VA during device init.
> A user space process with the needed privileges (CAP_SYS_MODULE) must
> provide a suitable memory buffer before the Mali GPU is capable of
> executing in protected mode.
>
> Processes who want to execute in protected mode must also ensure they
> pass a protected suspend buffer during group creation.
>
> Added panthor_kernel_bo_import() to allow user provided buffers.
> Refactor panthor_kernel_bo_create() to allow shared code with the
> new import variant.
There's just two many things happening here, so I'd suggest splitting
this patch into:
- Add the section_vm_map_flags() helper
- Add size/VA to panthor_fw_section
- s/panthor_gem_debugfs_set_usage_flags/panthor_gem_debugfs_add_usage_flags/
- support creating kernel BOs from a pre-existing GEM object
- add support for FW PROTM init (with the new ioctl)
- add support for PROTM group init
- bump the driver version to expose the new ioctls
> /**
> - * panthor_kernel_bo_create() - Create and map a GEM object to a VM
> + * panthor_kernel_bo_import() - Create a kernel BO from an existing GEM object
> * @ptdev: Device.
> * @vm: VM to map the GEM to.
> - * @size: Size of the buffer object.
> - * @bo_flags: Combination of drm_panthor_bo_flags flags.
> + * @bo: BO to use for our kernel BO.
> * @vm_map_flags: Combination of drm_panthor_vm_bind_op_flags (only those
> * that are related to map operations).
> * @gpu_va: GPU address assigned when mapping to the VM.
> * If gpu_va == PANTHOR_VM_KERNEL_AUTO_VA, the virtual address will be
> * automatically allocated.
> - * @name: Descriptive label of the BO's contents
> + * @vm_map_size: Size of the BO to map to the VM.
> *
> * Return: A valid pointer in case of success, an ERR_PTR() otherwise.
> */
> struct panthor_kernel_bo *
> -panthor_kernel_bo_create(struct panthor_device *ptdev, struct panthor_vm *vm,
> - size_t size, u32 bo_flags, u32 vm_map_flags,
> - u64 gpu_va, const char *name)
> +panthor_kernel_bo_import(struct panthor_device *ptdev, struct panthor_vm *vm,
Not sure I like the name, because the BO we pass is not necessarily
imported. I think I prefer panthor_kernel_bo_create_{with,from}_bo() or
_{with,from}_gem().
> + struct panthor_gem_object *bo, u32 vm_map_flags,
> + u64 gpu_va, u32 vm_map_size)
> {
[..]
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
> index 1fe77e5c41995..d73fc2f6633a6 100644
> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@ -1429,10 +1429,15 @@ cs_slot_process_protm_pending_event_locked(struct panthor_device *ptdev,
> if (!group)
> return;
>
> - /* Do not allow user space work to switch into protected mode, as we
> - * do not fully support this quite yet.
> + /* Do not allow user space work to switch into protected mode if we
> + * do not support protected mode on this device.
> + * User space should query (and init) this support before attempting
> + * to use such GPU instructions.
> */
> - atomic_or(BIT(cs_id), &group->fatal_queues);
> + if (!(ptdev->protm.info.state & DRM_PANTHOR_PROTM_INITIALIZED))
Should we instead check that the group is initialized for PROTM
support, and then have a check in group init to reject group PROTM init
if the device itself is not PROTM-initialized.
> + atomic_or(BIT(cs_id), &group->fatal_queues);
> + else
> + atomic_or(BIT(cs_id), &group->protm_pending_queues);
>
> sched_queue_delayed_work(sched, tick, 0);
> }
prev parent reply other threads:[~2026-09-11 14:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 11:40 [PATCH v3 0/6] drm/panthor: Protected mode support for Mali CSF GPUs Ketil Johnsen
2026-09-11 11:40 ` [PATCH v3 1/6] drm/panthor: De-duplicate FW memory section sync Ketil Johnsen
2026-09-11 11:40 ` [PATCH v3 2/6] drm/panthor: Minor scheduler refactoring Ketil Johnsen
2026-09-11 14:23 ` Boris Brezillon
2026-09-18 12:05 ` Boris Brezillon
2026-09-11 11:40 ` [PATCH v3 3/6] drm/panthor: Pass drm_file instead of panthor_file Ketil Johnsen
2026-09-11 11:40 ` [PATCH v3 4/6] drm/panthor: Don't allocate protm_suspend_buf Ketil Johnsen
2026-09-11 11:40 ` [PATCH v3 5/6] drm/panthor: Add support for entering and exiting protected mode Ketil Johnsen
2026-09-14 13:03 ` Boris Brezillon
2026-09-11 11:40 ` [PATCH v3 6/6] drm/panthor: Expose protected rendering features Ketil Johnsen
2026-09-11 14:42 ` Boris Brezillon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260911164229.6858768c@fedora-21.home \
--to=boris.brezillon@collabora.com \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ketil.johnsen@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®