[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1219b46d-2aea-4377-a8ca-024039ee1499@quicinc.com>
Date: Wed, 11 Dec 2024 08:38:15 +0530
From: Akhil P Oommen <quic_akhilpo@...cinc.com>
To: Bjorn Andersson <andersson@...nel.org>
CC: Rob Clark <robdclark@...il.com>,
Pavan Kondeti
<quic_pkondeti@...cinc.com>,
Sean Paul <sean@...rly.run>, Konrad Dybcio
<konradybcio@...nel.org>,
Abhinav Kumar <quic_abhinavk@...cinc.com>,
"Dmitry
Baryshkov" <dmitry.baryshkov@...aro.org>,
Marijn Suijten
<marijn.suijten@...ainline.org>,
David Airlie <airlied@...il.com>, "Simona
Vetter" <simona@...ll.ch>,
Elliot Berman <quic_eberman@...cinc.com>,
<linux-arm-msm@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
<freedreno@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] drm/msm/a6xx: Skip gpu secure fw load in EL2 mode
On 12/11/2024 6:43 AM, Bjorn Andersson wrote:
> On Tue, Dec 10, 2024 at 02:22:27AM +0530, Akhil P Oommen wrote:
>> On 12/10/2024 1:24 AM, Rob Clark wrote:
>>> On Mon, Dec 9, 2024 at 12:20 AM Akhil P Oommen <quic_akhilpo@...cinc.com> wrote:
>>>>
>>>> When kernel is booted in EL2, SECVID registers are accessible to the
>>>> KMD. So we can use that to switch GPU's secure mode to avoid dependency
>>>> on Zap firmware. Also, we can't load a secure firmware without a
>>>> hypervisor that supports it.
>>>
>>> Shouldn't we do this based on whether zap node is in dtb (and not disabled)?
>>
>> This is better, isn't it? Otherwise, multiple overlays should be
>> maintained for each soc/board since EL2 can be toggled from bootloader.
>> And this feature is likely going to be more widely available.
>>
>
> The DeviceTree passed to the OS needs to describe the world that said OS
> is going to operate in. If you change the world you need to change the
> description.
> There are several other examples where this would be necessary
> (remoteproc and watchdog to name two examples from the Qualcomm upstream
> world).
But basic things work without those changes, right? For eg: Desktop UI
>
> So, if we can cover this by zap-shader being enabled or disabled, that
> sounds like a clean and scaleable solution.
I think we are focusing too much on zap shader. If the driver can
determine itself about access to its register, shouldn't it be allowed
to use that?
-Akhil
>
> Regards,
> Bjorn
Powered by blists - more mailing lists