Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Abhinav Kumar <quic_abhinavk@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
	Marijn Suijten <marijn.suijten@somainline.org>,
	David Airlie <airlied@gmail.com>,
	Stephen Boyd <swboyd@chromium.org>,
	Simona Vetter <simona.vetter@ffwll.ch>,
	<linux-arm-msm@vger.kernel.org>,
	<dri-devel@lists.freedesktop.org>,
	<freedreno@lists.freedesktop.org>
Subject: Re: [PATCH v4 7/9] drm/msm/dpu: handle perf mode in _dpu_core_perf_crtc_update_bus()
Date: Wed, 15 Jan 2025 11:41:27 -0800	[thread overview]
Message-ID: <72c50442-5624-44ca-a954-64f7ddfa16f9@quicinc.com> (raw)
In-Reply-To: <4quxgv6n35np7fm7iqx5bw5xnkz7gxabh3ix5rexcq5nir5k7i@xi33w2wyj7om>



On 1/15/2025 12:27 AM, Dmitry Baryshkov wrote:
> On Tue, Jan 14, 2025 at 01:18:26PM -0800, Abhinav Kumar wrote:
>>
>>
>> On 1/14/2025 3:10 AM, Dmitry Baryshkov wrote:
>>> On Mon, Jan 13, 2025 at 07:38:16PM -0800, Abhinav Kumar wrote:
>>>>
>>>>
>>>> On 1/5/2025 7:07 PM, Dmitry Baryshkov wrote:
>>>>> Move perf mode handling for the bandwidth to
>>>>> _dpu_core_perf_crtc_update_bus() rather than overriding per-CRTC data
>>>>> and then aggregating known values.
>>>>>
>>>>> Note, this changes the fix_core_ab_vote. Previously it would be
>>>>> multiplied per the CRTC number, now it will be used directly for
>>>>> interconnect voting. This better reflects user requirements in the case
>>>>> of different resolutions being set on different CRTCs: instead of using
>>>>> the same bandwidth for each CRTC (which is incorrect) user can now
>>>>> calculate overall bandwidth required by all outputs and use that value.
>>>>>
>>>>
>>>> There are two things this change is doing:
>>>>
>>>> 1) Dropping the core_clk_rate setting because its already handled inside
>>>> _dpu_core_perf_get_core_clk_rate() and hence dpu_core_perf_crtc_update()
>>>> will still work.
>>>>
>>>> and
>>>>
>>>> 2) Then this part of moving the ab/ib setting to
>>>> _dpu_core_perf_crtc_update_bus().
>>>>
>>>> Can we split this into two changes so that its clear that dropping
>>>> core_clk_rate setting in this change will not cause an issue.
>>>
>>> Ack
>>>
>>
>> Actually I think this is incorrect.
>>
>> If the user puts in an incorrect value beyond the bounds, earlier the code
>> will reject that by failing the in _dpu_core_perf_calc_crtc().
> 
> This function doesn't perform any validation nor returns an error code.
> Probably you've meant some other function.
> 

Sorry, let me explain a little more to complete the flow I am seeing.

_dpu_core_perf_calc_crtc() gets called by dpu_core_perf_crtc_check().

That one checks against erroneous values.

                 if (!threshold) {
                         DPU_ERROR("no bandwidth limits specified\n");
                         return -E2BIG;
                 } else if (bw > threshold) {
                         DPU_ERROR("exceeds bandwidth: %ukb > %ukb\n", bw,
                                         threshold);
                         return -E2BIG;
                 }

>>
>> Now, if we move it to _dpu_core_perf_crtc_update_bus(), this is beyond the
>> check phase so incorrect values cannot be rejected.
>>
>> So we will still need to preserve overriding the values in
>> _dpu_core_perf_calc_crtc().
>>
>>>>
>>>>
>>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>>>> ---
>>>>>     drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 40 +++++++++++++--------------
>>>>>     1 file changed, 19 insertions(+), 21 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
>>>>> index 70f43e8359caee2082f2ca9944a17a6a20aa3d49..7ff3405c6867556a8dc776783b91f1da6c86ef3f 100644
>>>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
>>>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
>>>>> @@ -118,22 +118,9 @@ static void _dpu_core_perf_calc_crtc(const struct dpu_core_perf *core_perf,
>>>>>     		return;
>>>>>     	}
>>>>> -	memset(perf, 0, sizeof(struct dpu_core_perf_params));
>>>>> -
>>>>> -	if (core_perf->perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
>>>>> -		perf->bw_ctl = 0;
>>>>> -		perf->max_per_pipe_ib = 0;
>>>>> -		perf->core_clk_rate = 0;
>>>>> -	} else if (core_perf->perf_tune.mode == DPU_PERF_MODE_FIXED) {
>>>>> -		perf->bw_ctl = core_perf->fix_core_ab_vote * 1000ULL;
>>>>> -		perf->max_per_pipe_ib = core_perf->fix_core_ib_vote;
>>>>> -		perf->core_clk_rate = core_perf->fix_core_clk_rate;
>>>>> -	} else {
>>>>> -		perf->bw_ctl = _dpu_core_perf_calc_bw(perf_cfg, crtc);
>>>>> -		perf->max_per_pipe_ib = perf_cfg->min_dram_ib;
>>>>> -		perf->core_clk_rate = _dpu_core_perf_calc_clk(perf_cfg, crtc, state);
>>>>> -	}
>>>>> -
>>>>> +	perf->bw_ctl = _dpu_core_perf_calc_bw(perf_cfg, crtc);
>>>>> +	perf->max_per_pipe_ib = perf_cfg->min_dram_ib;
>>>>> +	perf->core_clk_rate = _dpu_core_perf_calc_clk(perf_cfg, crtc, state);
>>>>>     	DRM_DEBUG_ATOMIC(
>>>>>     		"crtc=%d clk_rate=%llu core_ib=%u core_ab=%u\n",
>>>>>     			crtc->base.id, perf->core_clk_rate,
>>>>> @@ -222,18 +209,29 @@ static int _dpu_core_perf_crtc_update_bus(struct dpu_kms *kms,
>>>>>     {
>>>>>     	struct dpu_core_perf_params perf = { 0 };
>>>>>     	int i, ret = 0;
>>>>> -	u64 avg_bw;
>>>>> +	u32 avg_bw;
>>>>> +	u32 peak_bw;
>>>>>     	if (!kms->num_paths)
>>>>>     		return 0;
>>>>> -	dpu_core_perf_aggregate(crtc->dev, dpu_crtc_get_client_type(crtc), &perf);
>>>>> +	if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
>>>>> +		avg_bw = 0;
>>>>> +		peak_bw = 0;
>>>>> +	} else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED) {
>>>>> +		avg_bw = kms->perf.fix_core_ab_vote;
>>>>> +		peak_bw = kms->perf.fix_core_ib_vote;
>>>>> +	} else {
>>>>> +		dpu_core_perf_aggregate(crtc->dev, dpu_crtc_get_client_type(crtc), &perf);
>>>>> +
>>>>> +		avg_bw = div_u64(perf.bw_ctl, 1000); /*Bps_to_icc*/
>>>>> +		peak_bw = perf.max_per_pipe_ib;
>>>>> +	}
>>>>> -	avg_bw = perf.bw_ctl;
>>>>> -	do_div(avg_bw, (kms->num_paths * 1000)); /*Bps_to_icc*/
>>>>> +	avg_bw /= kms->num_paths;
>>>>>     	for (i = 0; i < kms->num_paths; i++)
>>>>> -		icc_set_bw(kms->path[i], avg_bw, perf.max_per_pipe_ib);
>>>>> +		icc_set_bw(kms->path[i], avg_bw, peak_bw);
>>>>>     	return ret;
>>>>>     }
>>>>>
>>>
> 

  reply	other threads:[~2025-01-15 19:41 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-06  3:07 [PATCH v4 0/9] drm/msm/dpu: rework debugfs interface of dpu_core_perf Dmitry Baryshkov
2025-01-06  3:07 ` [PATCH v4 1/9] drm/msm/dpu: extract bandwidth aggregation function Dmitry Baryshkov
2025-01-06  3:07 ` [PATCH v4 2/9] drm/msm/dpu: remove duplicate code calculating sum of bandwidths Dmitry Baryshkov
2025-01-10  1:14   ` Abhinav Kumar
2025-01-06  3:07 ` [PATCH v4 3/9] drm/msm/dpu: change ib values to u32 Dmitry Baryshkov
2025-01-10  1:25   ` Abhinav Kumar
2025-01-06  3:07 ` [PATCH v4 4/9] drm/msm/dpu: make fix_core_ab_vote consistent with fix_core_ib_vote Dmitry Baryshkov
2025-01-10  1:40   ` Abhinav Kumar
2025-01-10  2:02     ` Dmitry Baryshkov
2025-01-10 23:49       ` Abhinav Kumar
2025-01-11 13:08         ` Dmitry Baryshkov
2025-01-14  1:31           ` Abhinav Kumar
2025-01-14  1:43             ` Dmitry Baryshkov
2025-01-06  3:07 ` [PATCH v4 5/9] drm/msm/dpu: also use KBps for bw_ctl output Dmitry Baryshkov
2025-01-14  1:33   ` Abhinav Kumar
2025-01-06  3:07 ` [PATCH v4 6/9] drm/msm/dpu: rename average bandwidth-related debugfs files Dmitry Baryshkov
2025-01-10 23:52   ` Abhinav Kumar
2025-01-06  3:07 ` [PATCH v4 7/9] drm/msm/dpu: handle perf mode in _dpu_core_perf_crtc_update_bus() Dmitry Baryshkov
2025-01-14  3:38   ` Abhinav Kumar
2025-01-14 11:10     ` Dmitry Baryshkov
2025-01-14 21:18       ` Abhinav Kumar
2025-01-15  8:27         ` Dmitry Baryshkov
2025-01-15 19:41           ` Abhinav Kumar [this message]
2025-01-16  0:32             ` Dmitry Baryshkov
2025-01-16  0:40               ` Abhinav Kumar
2025-01-16  1:14                 ` Dmitry Baryshkov
2025-01-17 20:28                   ` Abhinav Kumar
2025-01-06  3:07 ` [PATCH v4 8/9] drm/msm/dpu: rework core_perf debugfs overrides Dmitry Baryshkov
2025-01-14 22:02   ` Abhinav Kumar
2025-01-15  8:41     ` Dmitry Baryshkov
2025-01-15 19:51       ` Abhinav Kumar
2025-01-16  0:35         ` Dmitry Baryshkov
2025-01-16  0:47           ` Abhinav Kumar
2025-01-16  1:15             ` Dmitry Baryshkov
2025-01-16  1:19               ` Abhinav Kumar
2025-01-06  3:07 ` [PATCH v4 9/9] drm/msm/dpu: drop dpu_core_perf_params::max_per_pipe_ib Dmitry Baryshkov
2025-01-15  0:53   ` Abhinav Kumar
2025-01-15  8:42     ` 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=72c50442-5624-44ca-a954-64f7ddfa16f9@quicinc.com \
    --to=quic_abhinavk@quicinc.com \
    --cc=airlied@gmail.com \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=marijn.suijten@somainline.org \
    --cc=robdclark@gmail.com \
    --cc=sean@poorly.run \
    --cc=simona.vetter@ffwll.ch \
    --cc=swboyd@chromium.org \
    /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