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
