Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Abhinav Kumar <quic_abhinavk@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>
Cc: Marijn Suijten <marijn.suijten@somainline.org>,
	<linux-arm-msm@vger.kernel.org>,
	<dri-devel@lists.freedesktop.org>,
	<freedreno@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] DPU1 GC1.8 wiring-up
Date: Thu, 20 Apr 2023 12:47:50 -0700	[thread overview]
Message-ID: <b134d09c-55fa-7879-80ff-900e39c20c3d@quicinc.com> (raw)
In-Reply-To: <6a335df7-ff0b-098a-feec-45714159df04@linaro.org>



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



  reply	other threads:[~2023-04-20 19:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-20  1:14 [PATCH 0/2] DPU1 GC1.8 wiring-up Konrad Dybcio
2023-04-20  1:14 ` [PATCH 1/2] drm/msm/dpu1: Rename sm8150_dspp_blk to sdm845_dspp_blk Konrad Dybcio
2023-04-20 11:47   ` Dmitry Baryshkov
2023-04-20 11:48   ` Dmitry Baryshkov
2023-04-20  1:14 ` [PATCH 2/2] drm/msm/dpu1: Enable GCv1.8 on many SoCs Konrad Dybcio
2023-04-20  1:25 ` [PATCH 0/2] DPU1 GC1.8 wiring-up Dmitry Baryshkov
2023-04-20  1:26   ` Konrad Dybcio
2023-04-20  1:28     ` Abhinav Kumar
2023-04-20  1:36       ` Konrad Dybcio
2023-04-20 18:01         ` Dmitry Baryshkov
2023-04-20 19:47           ` Abhinav Kumar [this message]
2023-04-20 19:51             ` Dmitry Baryshkov
2023-04-20 19:53               ` Abhinav Kumar
2023-04-20 20:09                 ` Dmitry Baryshkov
2023-04-20 19:56               ` Marijn Suijten
2023-04-20 22:52                 ` Dmitry Baryshkov
2023-04-21 22:34                   ` Abhinav Kumar
2023-04-21 22:35                     ` Dmitry Baryshkov
2023-04-22 12:08                       ` Konrad Dybcio
2023-04-22 14:11                         ` Dmitry Baryshkov
2023-04-22 18:32                           ` Abhinav Kumar
2023-04-20 19:48           ` Marijn Suijten
2023-07-11 14:21 ` Dmitry Baryshkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b134d09c-55fa-7879-80ff-900e39c20c3d@quicinc.com \
    --to=quic_abhinavk@quicinc.com \
    --cc=airlied@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marijn.suijten@somainline.org \
    --cc=robdclark@gmail.com \
    --cc=sean@poorly.run \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox