From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Abhinav Kumar <quic_abhinavk@quicinc.com>
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 4/9] drm/msm/dpu: make fix_core_ab_vote consistent with fix_core_ib_vote
Date: Sat, 11 Jan 2025 15:08:58 +0200 [thread overview]
Message-ID: <0B5D10CF-35CE-4CF5-9105-5ACCC04EB94B@linaro.org> (raw)
In-Reply-To: <a17204c1-6eb5-4ce4-a302-c5f582055037@quicinc.com>
On 11 January 2025 01:49:23 EET, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote:
>
>
>On 1/9/2025 6:02 PM, Dmitry Baryshkov wrote:
>> On Thu, Jan 09, 2025 at 05:40:23PM -0800, Abhinav Kumar wrote:
>>>
>>>
>>> On 1/5/2025 7:07 PM, Dmitry Baryshkov wrote:
>>>> The fix_core_ab_vote is an average bandwidth value, used for bandwidth
>>>> overrides in several cases. However there is an internal inconsistency:
>>>> fix_core_ib_vote is defined in KBps, while fix_core_ab_vote is defined
>>>> in Bps.
>>>>
>>>> Fix that by changing the type of the variable to u32 and using * 1000ULL
>>>> multiplier when setting up the dpu_core_perf_params::bw_ctl value.
>>>>
>>>
>>> Actually after looking at this, I have another question.
>>>
>>> How did you conclude that fix_core_ib_vote is in KBps?
>>>
>>> min_dram_ib is in KBps in the catalog but how is fix_core_ib_vote?
>>>
>>> It depends on the interpretation perhaps. If the debugfs was supposed to
>>> operate under the expectation that the provided value will be pre-multiplied
>>> by 1000 and given then that explains why it was not multiplied again.
>>>
>>> And I cross-checked some of the internal usages of the debugfs, the values
>>> provided to it were in Bps and not KBps.
>>
>> Well... As you wrote min_dram_ib is in KBps. So, by comparing the next
>> two lines, fix_core_ib_vote should also be in kBps, as there is no
>> premultiplier:
>>
>> perf->max_per_pipe_ib = core_perf->fix_core_ib_vote;
>> [...]
>> perf->max_per_pipe_ib = perf_cfg->min_dram_ib;
>>
>> And then, as a proof, perf->max_per_pipe_ib is passed to icc_set_bw()
>> without any modifications:
>>
>> icc_set_bw(kms->path[i], avg_bw, perf.max_per_pipe_ib);
>>
>
>Understood max_per_pipe_ib. But then by the same logic, fix_core_ab_vote is always in Bps and not in KBps because bw_ctl is in Bps.
>
>Is it really a discrepancy that fix_core_ib_vote is defined in KBps, while fix_core_ab_vote is defined in Bps because they are just following the units in which bw_ctl and max_per_pipe_ib were defined in resp.
Yes. They come in pair, as a part of the user interface. If one is in Bps and another one in KBps, it is very easy to forget that and misinterpret them or to make a mistake while programming them. Not to mention that the threshold files, which are related to AB, are in KBps.
>
>>
>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>>> ---
>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 4 ++--
>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 2 +-
>>>> 2 files changed, 3 insertions(+), 3 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 7263ab63a692554cd51a7fd91bd6250330179240..7cabc8f26908cfd2dbbffebd7c70fc37d9159733 100644
>>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
>>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
>>>> @@ -125,7 +125,7 @@ static void _dpu_core_perf_calc_crtc(const struct dpu_core_perf *core_perf,
>>>> 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;
>>>> + 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 {
>>>> @@ -479,7 +479,7 @@ int dpu_core_perf_debugfs_init(struct dpu_kms *dpu_kms, struct dentry *parent)
>>>> &perf->fix_core_clk_rate);
>>>> debugfs_create_u32("fix_core_ib_vote", 0600, entry,
>>>> &perf->fix_core_ib_vote);
>>>> - debugfs_create_u64("fix_core_ab_vote", 0600, entry,
>>>> + debugfs_create_u32("fix_core_ab_vote", 0600, entry,
>>>> &perf->fix_core_ab_vote);
>>>> return 0;
>>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
>>>> index ca4595b4ec217697849af02446b23ed0857a0295..5e07119c14c6a9ed3413d0eaddbd93df5cc3f79d 100644
>>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
>>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
>>>> @@ -51,7 +51,7 @@ struct dpu_core_perf {
>>>> u32 enable_bw_release;
>>>> u64 fix_core_clk_rate;
>>>> u32 fix_core_ib_vote;
>>>> - u64 fix_core_ab_vote;
>>>> + u32 fix_core_ab_vote;
>>>> };
>>>> int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
>>>>
>>
next prev parent reply other threads:[~2025-01-11 13:09 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 [this message]
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
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=0B5D10CF-35CE-4CF5-9105-5ACCC04EB94B@linaro.org \
--to=dmitry.baryshkov@linaro.org \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=quic_abhinavk@quicinc.com \
--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