Message-ID: <c4a49218-0e1f-415c-a72e-8518e9b4e818@quicinc.com>
Date:   Fri, 28 Oct 2022 15:06:26 -0700
From:   Abhinav Kumar <quic_abhinavk@...cinc.com>
To:     Marijn Suijten <marijn.suijten@...ainline.org>,
        <phone-devel@...r.kernel.org>, Rob Clark <robdclark@...il.com>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Vinod Koul <vkoul@...nel.org>,
        <~postmarketos/upstreaming@...ts.sr.ht>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Martin Botka <martin.botka@...ainline.org>,
        Jami Kettunen <jami.kettunen@...ainline.org>,
        Sean Paul <sean@...rly.run>, David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Douglas Anderson <dianders@...omium.org>,
        Vladimir Lypak <vladimir.lypak@...il.com>,
        <linux-arm-msm@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
        <freedreno@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 00/10] drm/msm: Fix math issues in MSM DSC
 implementation



On 10/28/2022 1:09 PM, Marijn Suijten wrote:
> Hi Abhinav,
> 
> On 2022-10-28 11:33:21, Abhinav Kumar wrote:
>> Hi Marijn
>>
>> On 10/26/2022 11:28 AM, Marijn Suijten wrote:
>>> Various removals of complex yet unnecessary math, fixing all uses of
>>> drm_dsc_config::bits_per_pixel to deal with the fact that this field
>>> includes four fractional bits, and finally making sure that
>>> range_bpg_offset contains values 6-bits wide to prevent overflows in
>>> drm_dsc_pps_payload_pack().
>>>
>>> Altogether this series is responsible for solving _all_ Display Stream
>>> Compression issues and artifacts on the Sony Tama (sdm845) Akatsuki
>>> smartphone (2880x1440p).
>>>
>>> Changes since v3:
>>> - Swap patch 7 and 8 to make sure msm_host is available inside
>>>     dsi_populate_dsc_params();
>>> - Reword patch 6 (Migrate to drm_dsc_compute_rc_parameters()) to more
>>>     clearly explain why the FIXME wasn't solved initially, but why it can
>>>     (and should!) be resolved now.
>>>
>>> v3: https://lore.kernel.org/linux-arm-msm/20221009184824.457416-1-marijn.suijten@somainline.org/T/#u
>>>
>>> Changes since v2:
>>> - Generalize mux_word_size setting depending on bits_per_component;
>>> - Migrate DSI's DSC calculations to drm_dsc_compute_rc_parameters(),
>>>     implicitly addressing existing math issues;
>>> - Disallow any bits_per_component other than 8, until hardcoded values
>>>     are updated and tested to support such cases.
>>>
>>> v2: https://lore.kernel.org/linux-arm-msm/20221005181657.784375-1-marijn.suijten@somainline.org/T/#u
>>>
>>> Changes since v1:
>>>
>>> - Propagate r-b's, except (obviously) in patches that were (heavily)
>>>     modified;
>>> - Remove accidental debug code in dsi_cmd_dma_add;
>>> - Move Range BPG Offset masking out of DCS PPS packing, back into the
>>>     DSI driver when it is assigned to drm_dsc_config (this series is now
>>>     strictly focusing on drm/msm again);
>>> - Replace modulo-check resulting in conditional increment with
>>>     DIV_ROUND_UP;
>>> - Remove repeated calculation of slice_chunk_size;
>>> - Use u16 instead of int when handling bits_per_pixel;
>>> - Use DRM_DEV_ERROR instead of pr_err in DSI code;
>>> - Also remove redundant target_bpp_x16 variable.
>>>
>>> v1: https://lore.kernel.org/linux-arm-msm/20221001190807.358691-1-marijn.suijten@somainline.org/T/#u
>>>
>>> Marijn Suijten (10):
>>>     drm/msm/dsi: Remove useless math in DSC calculations
>>>     drm/msm/dsi: Remove repeated calculation of slice_per_intf
>>>     drm/msm/dsi: Use DIV_ROUND_UP instead of conditional increment on
>>>       modulo
>>>     drm/msm/dsi: Reuse earlier computed dsc->slice_chunk_size
>>>     drm/msm/dsi: Appropriately set dsc->mux_word_size based on bpc
>>>     drm/msm/dsi: Migrate to drm_dsc_compute_rc_parameters()
>>>     drm/msm/dsi: Account for DSC's bits_per_pixel having 4 fractional bits
>>>     drm/msm/dsi: Disallow 8 BPC DSC configuration for alternative BPC
>>>       values
>>>     drm/msm/dpu1: Account for DSC's bits_per_pixel having 4 fractional
>>>       bits
>>>     drm/msm/dsi: Prevent signed BPG offsets from bleeding into adjacent
>>>       bits
>>>
>>>    drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c |  11 +-
>>>    drivers/gpu/drm/msm/dsi/dsi_host.c         | 121 ++++++---------------
>>>    2 files changed, 37 insertions(+), 95 deletions(-)
>>>
>>> --
>>> 2.38.1
>>>
>>
>> To keep the -fixes cycle to have only critical fixes (others are
>> important too but are cleanups), I was thinking of absorbing patches
>> 7,8,9 and 10 alone in the -fixes cycle and for patches 1-6, will go
>> through the 6.2 push.
>>
>> Let me know if there are any concerns if we just take patches 7,8,9 and
>> 10 separately.
> 
> Unfortunately that isn't going to cut it.  For starters patch 8 is only
> introducing additional validation but as long as no panel drivers set
> bpc != 8, this doesn't change anything: it is not a critical fix.
> 
> Then, more importantly, as discussed in v2 reviews it was preferred to
> _not_ fix the broken code in dsi_populate_dsc_params() but migrate to
> drm_dsc_compute_rc_parameters() directly [1].  As such patch 6 (which
> performs the migration) is definitely a requirement for the fixes to be
> complete.  Then again this patch looks weird when 5 is not applied,
> since both refactor how dsc->mux_word_size is assigned.  At the same
> time it cannot be cleanly applied without patch 1 (Remove useless math
> in DSC calculations) nor patch 3 (Use DIV_ROUND_UP instead of
> conditional increment on modulo), but I just realized that patch 3 is
> now also useless as the code is being removed altogether while migrating
> to drm_dsc_compute_rc_parameters().
> 
> Same for patch 4 (Reuse earlier computed dsc->slice_chunk_size): while
> it may not seem obvious at first, the original code uses bits_per_pixel
> without considering the fractional bits, again resulting invalid values.
> Perhaps this should have been mentioned in the patch description, but I
> did not want to create an even larger chain of references pointing back
> and forth to future patches fixing the exact same bug.  Unfortunately
> this patch doesn't apply cleanly without patch 2 (Remove repeated
> calculation of slice_per_intf) either.
> 
> All in all, applying this series piecemeal requires careful
> consideration which of the patches are actually fixing issues, and is
> terribly tricky considering code cleanups touching the same code and
> sitting right before the fixes (done intentionally to not distract diffs
> in bugfixes being surrounded by odd looking code).
> 
> [1]: https://lore.kernel.org/linux-arm-msm/CAA8EJpr=0w0KReqNW2jP8DzvXLgo_o6bKmwMOed2sXb6d8HKhg@mail.gmail.com/
> 
> - Marijn

Alright, in that case we will take the whole series for -next and not in 
-fixes.

Powered by blists - more mailing lists