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

[Dmitry Baryshkov <dmitry.baryshkov@linaro.org>]

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.

> 
> 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
>>>>
>>

-- 
With best wishes
Dmitry