On 2023-05-04 20:53:33, Dmitry Baryshkov wrote:
> On Thu, 4 May 2023 at 20:49, Marijn Suijten
> <marijn.suijten@xxxxxxxxxxxxxx> wrote:
> >
> > PP_BLK_TE is no longer there.
> >
> > marcos -> macros.
> >
> > On 2023-05-04 09:46:41, Kuogee Hsieh wrote:
> > > At legacy chipsets, it required DPU_PINGPONG_DSC bit be set to indicate
> >
> > I may have not made this clear, but the comments on patch 2/7
> > (introducing the DPU_PINGPONG_DSC bit) also apply to this patch: clarify
> > DPU 7.0.0 exactly in favour of "legacy", which has no definition at all
> > and changes over time.
> >
> > > pingpong ops functions are required to complete DSC data path setup if
> > > this chipset has DSC hardware block presented. This patch add
> > > DPU_PINGPONG_DSC bit to both PP_BLK and PP_BLK_TE marcos if it has DSC
> > > hardware block presented.
> >
> > Strictly speaking this patch together with 2/7 is not bisectable, as 2/7
> > first disables the callbacks for _all_ hardware and then this patch adds
> > it back by adding the flag to all DPU < 7.0.0 catalog descriptions.
>
> I asked to split these into two patches, but I see your point and
> partially agree with it. However if we mix the catalog changes with
> functional changes, it is too easy to overlook or misjudge the
> functional changes.
I did the same in the INTF TE series for patches that have very little
and/or very obvious functional changes: exactly this combination of
guarding a few callbacks behind a feature bit, and setting that feature
bit on a few specific catalog entries.
> As you are correct about bisectability, I'd probably suggest either
> having three patches (define flag, update catalog, handle flag in the
> driver) or squashing first two patches to have two patches (add flag +
> catalog, separate functional changes).
Sure, if you really prefer a split I'd go for two patches:
1. Add the flag to the enum and catalog;
2. Add the ops guard (functional change).
Then don't forget to reword the commit message, following the guidelines
below and the suggestion for 2/7.
- Marijn
> > To solve that, as we do in other DPU patch-series, just squash this
> > patch into 2/7. That way you also don't have to spend extra time
> > rewording this commit message either to match the improvements we made
> > in 2/7 (for example, you mention that "ops functions are required to
> > complete DSC data path setup", but those were already available before
> > 2/7, despite sounding as if this is a new thing that was previously
> > missing entirely).
> >
> > But please wait at least a couple days before sending v6. I only have a
> > few hours every day/week but would appreciate to review and test all the
> > other patches.
> >
> > > Signed-off-by: Kuogee Hsieh <quic_khsieh@xxxxxxxxxxx>
> > > ---
> > > .../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 16 +++++++--------
> > > .../gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 16 +++++++--------
> > > .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 24 +++++++++++-----------
> > > .../drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 24 +++++++++++-----------
> > > .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 24 +++++++++++-----------
> > > 5 files changed, 52 insertions(+), 52 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> > > index 521cfd5..ef92545 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> > > @@ -112,17 +112,17 @@ static const struct dpu_lm_cfg msm8998_lm[] = {
> > > };
> > >
> > > static const struct dpu_pingpong_cfg msm8998_pp[] = {
> > > - PP_BLK("pingpong_0", PINGPONG_0, 0x70000, PINGPONG_SDM845_TE2_MASK, 0, sdm845_pp_sblk_te,
> > > - DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
> > > + PP_BLK("pingpong_0", PINGPONG_0, 0x70000, PINGPONG_SDM845_TE2_MASK|BIT(DPU_PINGPONG_DSC),
> >
> > This should be added to the MASK (add new #define's where necessary).
> >
> > - Marijn
<snip>
