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