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;
>>>>> }
>>>>>
>>>
>
next prev parent 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