[PATCH v5] drm/msm/dpu: add current resource allocation to dumped state

Dmitry Baryshkov dmitry.baryshkov at linaro.org
Thu Feb 22 21:57:38 UTC 2024


On Thu, 22 Feb 2024 at 23:53, Abhinav Kumar <quic_abhinavk at quicinc.com> wrote:
>
>
>
> On 2/22/2024 1:47 PM, Dmitry Baryshkov wrote:
> > Provide atomic_print_state callback to the DPU's private object. This
> > way the debugfs/dri/0/state will also include RM's internal state.
> >
> > Example output (RB5 board, HDMI and writeback encoder enabled)
> >
> > resource mapping:
> >       pingpong=31 36 # # # # - - - - -
> >       mixer=31 36 # # # # -
> >       ctl=# # 31 36 # #
> >       dspp=# # # #
> >       dsc=# # # # - -
> >       cdm=#
> >
>
> Thanks, this LGTM now, one nit below.
>
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> > ---
> > Changes in v5:
> > - Extracted the common helper for printing RM state
> > - Changed the code to print '#' for unused/unmapped blocks (Abhinav)
> > - Link to v4: https://lore.kernel.org/r/20240219-fd-rm-state-v4-1-b47f14ef27c2@linaro.org
> >
> > Changes in v4:
> > - Split the patch from the virual wide planes series
> > - Reworked the output format
> > - Added the CDM block into the dump
> > ---
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 12 +++++++
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |  2 ++
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c  | 56 +++++++++++++++++++++++++++++++++
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h  |  8 +++++
> >   4 files changed, 78 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > index 723cc1d82143..9f3697e1eacb 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > @@ -353,9 +353,18 @@ static void dpu_kms_global_destroy_state(struct drm_private_obj *obj,
> >       kfree(dpu_state);
> >   }
> >
> > +static void dpu_kms_global_print_state(struct drm_printer *p,
> > +                                    const struct drm_private_state *state)
> > +{
> > +     const struct dpu_global_state *global_state = to_dpu_global_state(state);
> > +
> > +     dpu_rm_print_state(p, global_state);
> > +}
> > +
> >   static const struct drm_private_state_funcs dpu_kms_global_state_funcs = {
> >       .atomic_duplicate_state = dpu_kms_global_duplicate_state,
> >       .atomic_destroy_state = dpu_kms_global_destroy_state,
> > +     .atomic_print_state = dpu_kms_global_print_state,
> >   };
> >
> >   static int dpu_kms_global_obj_init(struct dpu_kms *dpu_kms)
> > @@ -371,6 +380,9 @@ static int dpu_kms_global_obj_init(struct dpu_kms *dpu_kms)
> >       drm_atomic_private_obj_init(dpu_kms->dev, &dpu_kms->global_state,
> >                                   &state->base,
> >                                   &dpu_kms_global_state_funcs);
> > +
> > +     state->rm = &dpu_kms->rm;
> > +
> >       return 0;
> >   }
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> > index d1207f4ec3ae..2512c9bd08df 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> > @@ -131,6 +131,8 @@ struct vsync_info {
> >   struct dpu_global_state {
> >       struct drm_private_state base;
> >
> > +     struct dpu_rm *rm;
> > +
> >       uint32_t pingpong_to_enc_id[PINGPONG_MAX - PINGPONG_0];
> >       uint32_t mixer_to_enc_id[LM_MAX - LM_0];
> >       uint32_t ctl_to_enc_id[CTL_MAX - CTL_0];
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> > index 724537ab776d..1a56ddca536d 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> > @@ -634,3 +634,59 @@ int dpu_rm_get_assigned_resources(struct dpu_rm *rm,
> >
> >       return num_blks;
> >   }
> > +
> > +static void dpu_rm_print_state_helper(struct drm_printer *p,
> > +                                         struct dpu_hw_blk *blk,
> > +                                         uint32_t mapping)
>
> Not sure if its the mail client, but is this aligned with the opening brace?

No, it is shifted to the right. Will fix while applying.

>
> Please double check once. Rest LGTM.
>
> Reviewed-by: Abhinav Kumar <quic_abhinavk at quicinc.com>



-- 
With best wishes
Dmitry


More information about the dri-devel mailing list