On 20/04/2023 22:53, Abhinav Kumar wrote:
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;
Agree.
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.
--
With best wishes
Dmitry