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:   Sat, 22 Apr 2023 11:32:27 -0700
From:   Abhinav Kumar <quic_abhinavk@...cinc.com>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Marijn Suijten <marijn.suijten@...ainline.org>
CC:     <freedreno@...ts.freedesktop.org>, Sean Paul <sean@...rly.run>,
        <linux-kernel@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
        <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH 0/2] DPU1 GC1.8 wiring-up



On 4/22/2023 7:11 AM, Dmitry Baryshkov wrote:
> On 22/04/2023 15:08, Konrad Dybcio wrote:
>>
>>
>> On 22.04.2023 00:35, Dmitry Baryshkov wrote:
>>> On 22/04/2023 01:34, Abhinav Kumar wrote:
>>>>
>>>>
>>>> On 4/20/2023 3:52 PM, Dmitry Baryshkov wrote:
>>>>> On 20/04/2023 22:56, Marijn Suijten wrote:
>>>>>> On 2023-04-20 22:51:22, 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?
>>>>>>
>>>>>> Nit (to make sure we're on the same thought here): I think it's a
>>>>>> 3-liner: remove it from DSPP_MSM8998_MASK as well as 
>>>>>> msm8998_dspp_sblk.
>>>>>>
>>>>>>>> OR lets stay at (2) till
>>>>>>>> someone does (1).
>>>>>>
>>>>>> I'm personally okay leaving it in place too, with an eye on 
>>>>>> implementing
>>>>>> this, IGC, and other blocks at some point if there's a use for it via
>>>>>> standard DRM properties.
>>>>>
>>>>> I took a quick glance. I think it is possible, but not 
>>>>> straightforward. But I must admit here, I don't have a full picture 
>>>>> regarding different color encodings, ranges and the rest of 
>>>>> gamma/degamma API and usage.
>>>>>
>>>>
>>>> I think its easier to remove this now and then add it when we add 
>>>> the support. As discussed, will post this shortly.
>>>>
>>>> Otherwise, whenever any new chipset gets added, we will run into the 
>>>> same question of whether to add GC or not.
>>>
>>> Yes, I absolutely agree here.
>> Sorry for the useless patches, though I guess they were a good
>> discussion starter..
> 
> If they started the discussion, they were not useless.
> 

I second that, they were not useless at all. In fact, like I mentioned 
earlier, once GC support is added, we can re-use these catalog changes.

So, this is all good work.

>>
>> Konrad
>>>
>>>>
>>>>>>
>>>>>>>> When someone implements GC, we can re-use this patch and that 
>>>>>>>> time keep
>>>>>>>> konrad's author rights or co-developed by.
>>>>>>
>>>>>> Good to at least know all these SoCs have the same offset and 
>>>>>> revision.
>>>>>>
>>>>>> - Marijn
>>>>>
>>>
>