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

[Abhinav Kumar]

On 4/20/2023 12:51 PM, 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?

Sure, i will send this by tomorrow, but its not a oneliner. Need to get 
rid of below too:

470 struct dpu_dspp_sub_blks {
471 	struct dpu_pp_blk gc;

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