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