linux-kernel - Re: [PATCH 05/10] drm/msm/dpu: Allow variable SSPP/INTF

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 13 Feb 2023 17:05:14 +0200
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Marijn Suijten <marijn.suijten@...ainline.org>
Cc:     Konrad Dybcio <konrad.dybcio@...aro.org>,
        linux-arm-msm@...r.kernel.org, andersson@...nel.org,
        agross@...nel.org, krzysztof.kozlowski@...aro.org,
        Rob Clark <robdclark@...il.com>,
        Abhinav Kumar <quic_abhinavk@...cinc.com>,
        Sean Paul <sean@...rly.run>, David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Robert Foss <rfoss@...nel.org>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>,
        dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 05/10] drm/msm/dpu: Allow variable SSPP/INTF_BLK size

On 13/02/2023 17:02, Marijn Suijten wrote:
> On 2023-02-13 16:40:56, Dmitry Baryshkov wrote:
>> On 13/02/2023 16:31, Marijn Suijten wrote:
>>> On 2023-02-13 13:38:33, Dmitry Baryshkov wrote:
>>>> On 13/02/2023 13:12, Marijn Suijten wrote:
>>>>> On 2023-02-11 13:26:51, Konrad Dybcio wrote:
>>>>>> These blocks are of variable length on different SoCs. Set the
>>>>>> correct values where I was able to retrieve it from downstream
>>>>>> DTs and leave the old defaults (0x1c8 for sspp and 0x280 for
>>>>>> intf) otherwise.
>>>>>>
>>>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@...aro.org>
>>>>>> ---
>>>>>>     .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c    | 242 +++++++++---------
>>>>>>     1 file changed, 121 insertions(+), 121 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>>>>> index 802050118345..d9ef1e133c1e 100644
>>>>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>>>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>>>> [..]
>>>>>> @@ -1848,10 +1848,10 @@ static struct dpu_dsc_cfg sm8150_dsc[] = {
>>>>>>     /*************************************************************
>>>>>>      * INTF sub blocks config
>>>>>>      *************************************************************/
>>>>>> -#define INTF_BLK(_name, _id, _base, _type, _ctrl_id, _progfetch, _features, _reg, _underrun_bit, _vsync_bit) \
>>>>>> +#define INTF_BLK(_name, _id, _base, _len, _type, _ctrl_id, _progfetch, _features, _reg, _underrun_bit, _vsync_bit) \
>>>>>
>>>>> Dmitry and I discussed in #freedreno to instead add the INTF_BLK_DSI_TE
>>>>> macro that accounts for the INTF TE registers using this higher register
>>>>> area, as well as an extended signature to configure extra interrupts.
>>>>
>>>> Yes, that's still the plan. It's slightly painful that we are touching
>>>> this are simultaneously.
>>>
>>> Should we (Konrad) then drop this patch as there's no need to add these
>>> (mostly RAZ/WI) registers to the dump until my INTF TE series starts
>>> using them?  That'll make rebasing easier on everyone too.
>>
>> RAZ/WI is for not present registers (read-as-zero/write-ignore). I think
>> that the growing register space is getting populated with registers
>> (which we have been ignoring up to now).
> 
> They are, but not until my INTF TE series lands; hence again the request
> to drop this patch until that happens?

I see nothing wrong with including them into the snapshots.

Dropping this single patch will still result in the huge amount of 
rejects. So, let's get your INTF TE done, I'll rebase my work on top of it.

-- 
With best wishes
Dmitry