Re: [PATCH 2/3] media: iris: Skip SCM call for non-SCM PAS backend

[Vikash Garodia <vikash.garodia@oss.qualcomm.com>]

Hi Sumit,

On 9/14/2026 11:44 AM, Sumit Garg wrote:
> Hey Konrad,
> 
> On Fri, Sep 11, 2026 at 7:54 PM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>>
>> On 9/11/26 2:38 PM, Sumit Garg wrote:
>>> From: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
>>>
>>> qcom_scm_mem_protect_video_var() is only serviced by the SCM backend;
>>> with OP-TEE the TEE owns secure memory protection. Use
>>> qcom_pas_get_backend() to issue the SCM call only for the SCM backend.
>>>
>>> Assisted-by: Copilot:claude-opus-4.8
>>> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez.ortiz@gmail.com>
>>> Co-developed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>> ---
>>
>> [...]
>>
>>> +     /*
>>> +      * qcom_scm_mem_protect_video_var() only applies to the SCM backend;
>>> +      * other backends (e.g. OP-TEE) own secure memory protection and do
>>> +      * not service this call.
>>
>> Can you not just stub it out in TF-A then?
>>
> 
> Please don't, we don't want to support these random SCM calls ABI per
> subsystem with the open boot stack. All the config in this case for
> video is handled by OP-TEE itself.

Could you please help me understand the demerit in stubbing it out and 
let that be a dummy ABI in OPTEE world ? that way client driver can 
remain agnostic of the calls being routed to OPTEE or QTEE

> 
> Instead we want to mostly support any subsystem specific TZ use-cases
> as proper client drivers for the TEE subsystem.
> 
> -Sumit

Regards,
Vikash