Re: [PATCH 2/3] media: iris: Skip SCM call for non-SCM PAS backend
From: Sumit Garg
Date: Thu Oct 15 2026 - 11:00:47 EST
On Thu, 15 Oct 2026 at 11:43:19 +0200, Konrad Dybcio wrote:
On 9/18/26 1:10 PM, Sumit Garg wrote:
Hey Vikash,
On Thu, Sep 17, 2026 at 5:11 PM Vikash Garodia
<vikash.garodia@xxxxxxxxxxxxxxxx> wrote:
Hi Sumit,
On 9/14/2026 11:44 AM, Sumit Garg wrote:
Hey Konrad,
[...]
The main disadvantage is that we don't want to carry these custom SCM
ABIs per kernel subsystem with the open source TF-A/OP-TEE boot stack.
ABIs always come with maintenance burdens, especially the custom ones
we have in this case.
Since we started from scratch for the open source boot stack, the
motivation is to keep the TZ ABI minimal and that too with
discoverable OP-TEE services like the PAS service.
Okay, I can symphatize with that.
Let's think of another solution though, as a strcmp over the provider
name is 10x worse.
Okay, I can rather stub these APIs via the generic PAS layer except the
SCM backend, that can reuse the existing abstraction.
Although I find these APIs not related to PIL/PAS but however it will be
just overkill to have another abstraction layer for it.
What is the planned replacement on the open boot stack side?
In case of video subsystem, OP-TEE pseudo TA already holds platform
specific info so we can directly add this info there which is being
passed by the kernel in SCM calls.
FF-A lend?
FF-A surely is being already enabled and tested with open boot stack.
See TF-A PR for Lemans as an example here [1]. However for FF-A lend to
work in real terms when kernel running in EL2 (KVM mode), we need
capability to be able to unmap buffers from kernel linear map.
See this proposal from Google where discussions are leading towards to
make the generic CMA pool capable to unmap buffers on arm64 here [1]. It
will actually unlock FF-A lend use-cases in the kernel.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/54873
[2] https://lore.kernel.org/all/as4ATqhp0bPI03PA@sumit-xelite/
-Sumit