linux-kernel - Re: [PATCH v2 2/2] drm/msm/adreno: Setup SMMU aparture for per-process page table

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <750739e8-62ad-4808-9d05-327d64355886@quicinc.com>
Date: Thu, 14 Nov 2024 23:32:55 +0530
From: Akhil P Oommen <quic_akhilpo@...cinc.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Rob Clark
	<robdclark@...il.com>,
        Bjorn Andersson <bjorn.andersson@....qualcomm.com>
CC: Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio
	<konradybcio@...nel.org>, Sean Paul <sean@...rly.run>,
        Abhinav Kumar
	<quic_abhinavk@...cinc.com>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        David Airlie
	<airlied@...il.com>,
        Jessica Zhang <quic_jesszhan@...cinc.com>,
        Simona Vetter
	<simona@...ll.ch>, <linux-arm-msm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
        <freedreno@...ts.freedesktop.org>
Subject: Re: [PATCH v2 2/2] drm/msm/adreno: Setup SMMU aparture for
 per-process page table

On 11/14/2024 8:57 PM, Konrad Dybcio wrote:
> On 12.11.2024 10:15 PM, Akhil P Oommen wrote:
>> On 11/11/2024 8:38 PM, Rob Clark wrote:
>>> On Sun, Nov 10, 2024 at 9:31 AM Bjorn Andersson
>>> <bjorn.andersson@....qualcomm.com> wrote:
>>>>
>>>> Support for per-process page tables requires the SMMU aparture to be
>>>> setup such that the GPU can make updates with the SMMU. On some targets
>>>> this is done statically in firmware, on others it's expected to be
>>>> requested in runtime by the driver, through a SCM call.
>>>>
>>>> One place where configuration is expected to be done dynamically is the
>>>> QCS6490 rb3gen2.
>>>>
>>>> The downstream driver does this unconditioanlly on any A6xx and newer,
>>>
>>> nit, s/unconditioanlly/unconditionally/
>>>
>>>> so follow suite and make the call.
>>>>
>>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@....qualcomm.com>
>>>
>>> Reviewed-by: Rob Clark <robdclark@...il.com>
>>>
>>>
>>>> ---
>>>>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +++++++++++
>>>>  1 file changed, 11 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
>>>> index 076be0473eb5..75f5367e73ca 100644
>>>> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
>>>> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
>>>> @@ -572,8 +572,19 @@ struct drm_gem_object *adreno_fw_create_bo(struct msm_gpu *gpu,
>>>>
>>>>  int adreno_hw_init(struct msm_gpu *gpu)
>>>>  {
>>
>> SCM calls into TZ can block for a very long time (seconds). It depends
>> on concurrent activities from other drivers like crypto for eg:. So we
>> should not do this in the gpu wake up path.
>>
>> Practically, gpu probe is the better place to do this.
> 
> Do we only have to do this once?
> 
> Do we have to redo it after CXPC?

Only once. Those registers have retention.

-Akhil.

> 
> Konrad