From: Abhinav Kumar <quic_abhinavk@quicinc.com>
To: Jessica Zhang <quic_jesszhan@quicinc.com>,
Marijn Suijten <marijn.suijten@somainline.org>
Cc: <freedreno@lists.freedesktop.org>, Sean Paul <sean@poorly.run>,
<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
"Konrad Dybcio" <konrad.dybcio@linaro.org>,
Rob Clark <robdclark@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
<linux-arm-msm@vger.kernel.org>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
David Airlie <airlied@gmail.com>
Subject: Re: [Freedreno] [PATCH v5 2/5] drm/msm/dsi: Adjust pclk rate for compression
Date: Thu, 8 Jun 2023 18:09:57 -0700 [thread overview]
Message-ID: <f11fc3c1-4b19-3186-9c56-b1bac221cf83@quicinc.com> (raw)
In-Reply-To: <f63435ca-933a-52be-d879-1d9cc9441107@quicinc.com>
On 6/8/2023 5:56 PM, Jessica Zhang wrote:
>
>
> On 6/8/2023 1:36 PM, Marijn Suijten wrote:
>> Same title suggestion as earlier: s/adjust/reduce
>
> Hi Marijn,
>
> Acked.
>
>>
>> On 2023-05-22 18:08:56, Jessica Zhang wrote:
>>> Adjust the pclk rate to divide hdisplay by the compression ratio when
>>> DSC
>>> is enabled.
>>>
>>> Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com>
>>> ---
>>> drivers/gpu/drm/msm/dsi/dsi_host.c | 21 ++++++++++++++++++---
>>> 1 file changed, 18 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
>>> b/drivers/gpu/drm/msm/dsi/dsi_host.c
>>> index a448931af804..88f370dd2ea1 100644
>>> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
>>> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
>>> @@ -561,7 +561,18 @@ void dsi_link_clk_disable_v2(struct msm_dsi_host
>>> *msm_host)
>>> clk_disable_unprepare(msm_host->byte_clk);
>>> }
>>> -static unsigned long dsi_get_pclk_rate(const struct drm_display_mode
>>> *mode, bool is_bonded_dsi)
>>> +static unsigned long dsi_adjust_compressed_pclk(const struct
>>> drm_display_mode *mode,
>>
>> Nit: adjust_pclk_for_compression
>
> Acked.
>
>>
>> As discussed before we realized that this change is more-or-less a hack,
>> since downstream calculates pclk quite differently - at least for
>> command-mode panels. Do you still intend to land this patch this way,
>> or go the proper route by introducing the right math from the get-go?
>> Or is the math at least correct for video-mode panels?
>
> Sorry but can you please clarify what exactly is incorrect or different
> about this math when compared to downstream? And, if you think that this
> math is incorrect, what exactly has to be changed to make it the "right
> math"?
>
Agree with Jessica, just calling the math a hack without explaining why
you think it is so is not justified especially when a great detail of
explanation was given on the bug. Sorry but its a bit harsh on the
developers.
> We've already shown step-by-step [1] not only how the resulting pclk
> from the downstream code matches out upstream calculations, but also how
> the inclusion of porches in the upstream math would make up for the fact
> that upstream has no concept of transfer time [2].
>
> If the lack of transfer time in the upstream math is the issue, I
> believe that that's not within the scope of this series, as transfer
> time is not something specific to DSC.
>
> Moreover, as stated in an earlier revision [3], there is no way to
> validate DSC over DSI for video mode. As far as I know, we do not have a
> way to validate video mode datapath for DSI in general.
>
> [1] https://gitlab.freedesktop.org/drm/msm/-/issues/24#note_1936144
> [2] https://gitlab.freedesktop.org/drm/msm/-/issues/24#note_1945792
> [3]
> https://patchwork.freedesktop.org/patch/535117/?series=117219&rev=1#comment_970492
>
>>
>> This function requires a documentation comment to explain that all.
>>
>>> + const struct drm_dsc_config *dsc)
>>> +{
>>> + int new_hdisplay = DIV_ROUND_UP(mode->hdisplay *
>>> drm_dsc_get_bpp_int(dsc),
>>
>> This sounds like a prime candidate for msm_dsc_get_bytes_per_line(), if
>> bits_per_component==8 is assumed. In fact, it then becomes identical
>> to the following line in dsi_host.c which you added previously:
>>
>> hdisplay = DIV_ROUND_UP(msm_dsc_get_bytes_per_line(msm_host->dsc),
>> 3);
>>
>> If not, what is the difference between these two calculations? Maybe
>> they both need to be in a properly-named helper.
>
> While the math technically matches up (assuming, also, that
> mode->hdisplay == slice_width * slice_count for all cases), there are
> conceptual differences between the pclk and hdisplay calculations.
>
> Just to reiterate what was already said on IRC:
>
> In the pclk calculation, we're multiplying pclk by the compression ratio
> (which would be target_bpp / src_bpp) -- please note that here, we
> calculate src_bpp by doing bpc * 3.
>
> In the hdisplay calculation, we calculate the bytes per line and divide
> by 3 (bytes) to account for the fact that we can only process 3 bytes
> per pclk cycle.
>
> So while I understand why you would want to put this behind a shared
> helper, I think abstracting the pclk and hdisplay math away would
> obfuscate the conceptual difference between the 2 calculations.
>
>>
>>> + dsc->bits_per_component * 3);
>>
>> As we established in the drm/msm issue [2] there is currently a
>> confusion whether this /3 (and the /3 in dsi_timing_setup) come from the
>> ratio between dsi_get_bpp() and dsc->bpp or something else. Can you
>> clarify that with constants and comments?
>
> Sure, we are planning to add a patch to the end of this series
> documenting the math.
>
>>
>> [2]: https://gitlab.freedesktop.org/drm/msm/-/issues/24
>>
>>> +
>>> + return (new_hdisplay + (mode->htotal - mode->hdisplay))
>>> + * mode->vtotal * drm_mode_vrefresh(mode);
>>
>> As clarified in [1] I was not necessarily suggesting to move this math
>> to a separate helper, but to also use a few more properly-named
>> intermediate variables to not have multi-line math and self-documenting
>> code. These lines could be split to be much more clear.
>
> Acked.
>
>>
>> [1]:
>> https://lore.kernel.org/linux-arm-msm/u4x2vldkzsokfcpbkz3dtwcllbdk4ljcz6kzuaxt5frx6g76o5@uku6abewvye7/
>>
>>> +}
>>> +
>>> +static unsigned long dsi_get_pclk_rate(const struct drm_display_mode
>>> *mode,
>>> + const struct drm_dsc_config *dsc, bool is_bonded_dsi)
>>> {
>>> unsigned long pclk_rate;
>>> @@ -576,6 +587,10 @@ static unsigned long dsi_get_pclk_rate(const
>>> struct drm_display_mode *mode, bool
>>> if (is_bonded_dsi)
>>> pclk_rate /= 2;
>>> + /* If DSC is enabled, divide hdisplay by compression ratio */
>>> + if (dsc)
>>> + pclk_rate = dsi_adjust_compressed_pclk(mode, dsc);
>>
>> The confusion with this comment (and the reason the aforementioned
>> discussion [2] carried on so long) stems from the fact a division makes
>> sense for a bit/byte clock, but not for a pixel clock: we still intend
>> to send the same number of pixels, just spending less bytes on them. So
>> as you clarify the /3 above, can you also clarify that here or drop this
>> comment completely when the function is correctly documented instead?
>
> Acked.
>
> Thanks,
>
> Jessica Zhang
>
>>
>> - Marijn
>>
>>> +
>>> return pclk_rate;
>>> }
>>> @@ -585,7 +600,7 @@ unsigned long dsi_byte_clk_get_rate(struct
>>> mipi_dsi_host *host, bool is_bonded_d
>>> struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
>>> u8 lanes = msm_host->lanes;
>>> u32 bpp = dsi_get_bpp(msm_host->format);
>>> - unsigned long pclk_rate = dsi_get_pclk_rate(mode, is_bonded_dsi);
>>> + unsigned long pclk_rate = dsi_get_pclk_rate(mode, msm_host->dsc,
>>> is_bonded_dsi);
>>> unsigned long pclk_bpp;
>>> if (lanes == 0) {
>>> @@ -604,7 +619,7 @@ unsigned long dsi_byte_clk_get_rate(struct
>>> mipi_dsi_host *host, bool is_bonded_d
>>> static void dsi_calc_pclk(struct msm_dsi_host *msm_host, bool
>>> is_bonded_dsi)
>>> {
>>> - msm_host->pixel_clk_rate = dsi_get_pclk_rate(msm_host->mode,
>>> is_bonded_dsi);
>>> + msm_host->pixel_clk_rate = dsi_get_pclk_rate(msm_host->mode,
>>> msm_host->dsc, is_bonded_dsi);
>>> msm_host->byte_clk_rate =
>>> dsi_byte_clk_get_rate(&msm_host->base, is_bonded_dsi,
>>> msm_host->mode);
>>>
>>> --
>>> 2.40.1
>>>
next prev parent reply other threads:[~2023-06-09 1:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-23 1:08 [PATCH v5 0/5] Add DSC v1.2 Support for DSI Jessica Zhang
2023-05-23 1:08 ` [PATCH v5 1/5] msm/drm/dsi: Round up DSC hdisplay calculation Jessica Zhang
2023-05-23 1:08 ` [PATCH v5 2/5] drm/msm/dsi: Adjust pclk rate for compression Jessica Zhang
2023-06-08 20:36 ` Marijn Suijten
2023-06-09 0:56 ` [Freedreno] " Jessica Zhang
2023-06-09 1:09 ` Abhinav Kumar [this message]
2023-06-11 21:19 ` Marijn Suijten
2023-06-11 21:59 ` Marijn Suijten
2023-06-09 16:58 ` Dmitry Baryshkov
2023-06-09 17:24 ` Jessica Zhang
2023-06-11 21:42 ` Marijn Suijten
2023-05-23 1:08 ` [PATCH v5 3/5] drm/msm/dpu: Add DPU_INTF_DATA_COMPRESS feature flag for DPU >= 7.0 Jessica Zhang
2023-05-23 1:08 ` [PATCH v5 4/5] drm/msm/dpu: Set DATA_COMPRESS on command mode for DCE/DSC 1.2 Jessica Zhang
2023-05-23 1:08 ` [PATCH v5 5/5] drm/msm/dsi: Remove incorrect references to slice_count Jessica Zhang
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=f11fc3c1-4b19-3186-9c56-b1bac221cf83@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=quic_jesszhan@quicinc.com \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).