Linux Media Controller development
 help / color / mirror / Atom feed
From: Sumit Garg <sumit.garg@oss.qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: Sumit Garg <sumit.garg@oss.qualcomm.com>,
	Vikash Garodia <vikash.garodia@oss.qualcomm.com>,
	Sumit Garg <sumit.garg@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>,
	Abhinav Kumar <abhinav.kumar@linux.dev>,
	Bryan O'Donoghue <bod@kernel.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-media@vger.kernel.org,
	Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>,
	Jorge Ramirez-Ortiz <jorge.ramirez.ortiz@gmail.com>
Subject: Re: [PATCH 2/3] media: iris: Skip SCM call for non-SCM PAS backend
Date: Thu, 15 Oct 2026 20:10:53 +0530	[thread overview]
Message-ID: <atDl9clfABlLMgkC@sumit-xelite> (raw)
In-Reply-To: <9ae0c4e2-35cd-402e-96d0-eccfe26e622b@oss.qualcomm.com>

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@oss.qualcomm.com> 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

  reply	other threads:[~2026-10-15 14:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11 12:38 [PATCH 0/3] media: qcom: Skip SCM secure memory protection with OP-TEE PAS backend Sumit Garg
2026-09-11 12:38 ` [PATCH 1/3] firmware: qcom: pas: Expose the active PAS backend name Sumit Garg
2026-09-11 12:38 ` [PATCH 2/3] media: iris: Skip SCM call for non-SCM PAS backend Sumit Garg
2026-09-11 14:24   ` Konrad Dybcio
2026-09-14  6:14     ` Sumit Garg
2026-09-17 11:41       ` Vikash Garodia
2026-09-18 11:10         ` Sumit Garg
2026-10-15  9:43           ` Konrad Dybcio
2026-10-15 14:40             ` Sumit Garg [this message]
2026-10-15 15:00             ` Sumit Garg
2026-09-11 12:38 ` [PATCH 3/3] media: venus: " Sumit Garg

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=atDl9clfABlLMgkC@sumit-xelite \
    --to=sumit.garg@oss.qualcomm.com \
    --cc=abhinav.kumar@linux.dev \
    --cc=andersson@kernel.org \
    --cc=bod@kernel.org \
    --cc=dikshita.agarwal@oss.qualcomm.com \
    --cc=jorge.ramirez.ortiz@gmail.com \
    --cc=jorge.ramirez@oss.qualcomm.com \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=konradybcio@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=sumit.garg@kernel.org \
    --cc=vikash.garodia@oss.qualcomm.com \
    /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