[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0f469b3c-5f0f-e027-8a9f-d1233169c04a@linaro.org>
Date: Thu, 20 Apr 2023 22:51:22 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Abhinav Kumar <quic_abhinavk@...cinc.com>,
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 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?
> 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.
>
>
--
With best wishes
Dmitry
Powered by blists - more mailing lists