linux-kernel - Re: [PATCH 0/2] DPU1 GC1.8 wiring-up

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]

Date:   Thu, 20 Apr 2023 12:53:43 -0700
From:   Abhinav Kumar <quic_abhinavk@...cinc.com>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Clark <robdclark@...il.com>, Sean Paul <sean@...rly.run>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>
CC:     Marijn Suijten <marijn.suijten@...ainline.org>,
        <linux-arm-msm@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
        <freedreno@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] DPU1 GC1.8 wiring-up



On 4/20/2023 12:51 PM, Dmitry Baryshkov wrote:
> On 20/04/2023 22:47, Abhinav Kumar wrote:
>>
>>
>> On 4/20/2023 11:01 AM, Dmitry Baryshkov wrote:
>>> On 20/04/2023 04:36, Konrad Dybcio wrote:
>>>>
>>>>
>>>> On 20.04.2023 03:28, Abhinav Kumar wrote:
>>>>>
>>>>>
>>>>> On 4/19/2023 6:26 PM, Konrad Dybcio wrote:
>>>>>>
>>>>>>
>>>>>> On 20.04.2023 03:25, Dmitry Baryshkov wrote:
>>>>>>> On 20/04/2023 04:14, Konrad Dybcio wrote:
>>>>>>>> Almost all SoCs from SDM845 to SM8550 inclusive feature a GC1.8
>>>>>>>> dspp sub-block in addition to PCCv4. The other block differ a bit
>>>>>>>> more, but none of them are supported upstream.
>>>>>>>>
>>>>>>>> This series adds configures the GCv1.8 on all the relevant SoCs.
>>>>>>>
>>>>>>> Does this mean that we will see gamma_lut support soon?
>>>>>> No promises, my plate is not even full, it's beyond overflowing! :P
>>>>>>
>>>>>> Konrad
>>>>>
>>>>> So I think I wrote about this before during the catalog 
>>>>> rework/fixes that the gc registers are not written to / programmed.
>>>>>
>>>>> If thats not done, is there any benefit to this series?
>>>> Completeness and preparation for the code itself, if nothing else?
>>>
>>> The usual problem is that if something is not put to use, it quickly 
>>> rots or becomes misused for newer platforms. We have seen this with 
>>> the some of DPU features.
>>>
>>> In case of GC (and the freshly defined DPU_DSPP_IGC, but not used) we 
>>> have three options:
>>> - drop the unused GC from msm8998_sblk.
>>> - keep things as is, single unused GC entry
>>> - fill all the sblk with the correct information in hope that it 
>>> stays correct
>>>
>>> Each of these options has its own drawbacks. I have slight bias 
>>> towards the last option, to have the information in place (as long as 
>>> it is accurate).
>>>
>>
>> My vote is for (1) . Today, GC is unused and from the discussion here, 
>> there is no concrete plan to add it. If we keep extending an unused 
>> bitmask for all the chipsets including the ones which will get added 
>> in the future in the hope that someday the feature comes, it doesnt 
>> sound like a good idea.
>>
>> I would rather do (1), if someone has time.
> 
> Agree, this was the second item on my preference list. Could you please 
> send this oneliner?
> 

Sure, i will send this by tomorrow, but its not a oneliner. Need to get 
rid of below too:

470 struct dpu_dspp_sub_blks {
471 	struct dpu_pp_blk gc;

>> OR lets stay at (2) till someone does (1).
>>
>> When someone implements GC, we can re-use this patch and that time 
>> keep konrad's author rights or co-developed by.
>>
>>
>