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

[Abhinav Kumar]

On 4/22/2023 7:11 AM, Dmitry Baryshkov wrote:
> 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.

I second that, they were not useless at all. In fact, like I mentioned 
earlier, once GC support is added, we can re-use these catalog changes.

So, this is all good work.

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