From: Jessica Zhang <quic_jesszhan@quicinc.com>
To: Abhinav Kumar <quic_abhinavk@quicinc.com>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Ryan McCann <quic_rmccann@quicinc.com>,
"Rob Clark" <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
Marijn Suijten <marijn.suijten@somainline.org>,
David Airlie <airlied@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>
Cc: Rob Clark <robdclark@chromium.org>,
<linux-arm-msm@vger.kernel.org>,
<dri-devel@lists.freedesktop.org>,
<freedreno@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 6/6] drm/msm/dpu: Update dev core dump to dump registers of sub blocks
Date: Fri, 23 Jun 2023 18:23:56 -0700 [thread overview]
Message-ID: <55d783d5-ef47-8c2e-d3ac-598e686e53fe@quicinc.com> (raw)
In-Reply-To: <1e41b909-4886-8392-edbc-78684e52bbf9@quicinc.com>
On 6/23/2023 5:09 PM, Abhinav Kumar wrote:
>
>
> On 6/22/2023 5:13 PM, Dmitry Baryshkov wrote:
>> On 23/06/2023 02:48, Ryan McCann wrote:
>>> Currently, the device core dump mechanism does not dump registers of sub
>>> blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Add wrapper
>>> function to dump hardware blocks that contain sub blocks.
>>>
>>> Signed-off-by: Ryan McCann <quic_rmccann@quicinc.com>
>>> ---
>>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 194
>>> +++++++++++++++++++++++++++-----
>>> 1 file changed, 168 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
>>> index aa8499de1b9f..9b1b1c382269 100644
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
>>> @@ -885,6 +885,154 @@ static int dpu_irq_postinstall(struct msm_kms
>>> *kms)
>>> return 0;
>>> }
>>> +static void dpu_kms_mdp_snapshot_add_block(struct msm_disp_state
>>> *disp_state,
>>> + void __iomem *mmio, void *blk,
>>> + enum dpu_hw_blk_type blk_type)
>>
>> No. Such multiplexers add no value to the code. Please inline it.
>>
>> Not to mention that this patch is hard to review. You both move
>> existing code and add new features. If it were to go, it should have
>> been split into two patches: one introducing the multiplexer and
>> another one adding subblocks.
>>
>
> Ok. we can split this into:
>
> 1) adding the multiplexer
> 2) adding sub-blk parsing support inside the multiplexer
>
>>> +{
>>> + u32 base;
>>> +
>>> + switch (blk_type) {
>>> + case DPU_HW_BLK_TOP:
>>> + {
>>> + struct dpu_mdp_cfg *top = (struct dpu_mdp_cfg *)blk;
>>> +
>>> + if (top->features & BIT(DPU_MDP_PERIPH_0_REMOVED)) {
>>> + msm_disp_snapshot_add_block(disp_state, MDP_PERIPH_TOP0,
>>> + mmio + top->base, "top");
>>> + msm_disp_snapshot_add_block(disp_state, top->len -
>>> MDP_PERIPH_TOP0_END,
>>> + mmio + top->base + MDP_PERIPH_TOP0_END,
>>> + "top_2");
>>> + } else {
>>> + msm_disp_snapshot_add_block(disp_state, top->len, mmio +
>>> top->base, "top");
>>> + }
>>> + break;
>>> + }
>>> + case DPU_HW_BLK_LM:
>>> + {
>>> + struct dpu_lm_cfg *mixer = (struct dpu_lm_cfg *)blk;
>>> +
>>> + msm_disp_snapshot_add_block(disp_state, mixer->len, mmio +
>>> mixer->base, "%s",
>>> + mixer->name);
>>> + break;
>>> + }
>>> + case DPU_HW_BLK_CTL:
>>> + {
>>> + struct dpu_ctl_cfg *ctl = (struct dpu_ctl_cfg *)blk;
>>> +
>>> + msm_disp_snapshot_add_block(disp_state, ctl->len, mmio +
>>> ctl->base, "%s",
>>> + ctl->name);
>>> + break;
>>> + }
>>> + case DPU_HW_BLK_INTF:
>>> + {
>>> + struct dpu_intf_cfg *intf = (struct dpu_intf_cfg *)blk;
>>> +
>>> + msm_disp_snapshot_add_block(disp_state, intf->len, mmio +
>>> intf->base, "%s",
>>> + intf->name);
>>> + break;
>>> + }
>>> + case DPU_HW_BLK_WB:
>>> + {
>>> + struct dpu_wb_cfg *wb = (struct dpu_wb_cfg *)blk;
>>> +
>>> + msm_disp_snapshot_add_block(disp_state, wb->len, mmio +
>>> wb->base, "%s",
>>> + wb->name);
>>> + break;
>>> + }
>>> + case DPU_HW_BLK_SSPP:
>>> + {
>>> + struct dpu_sspp_cfg *sspp_block = (struct dpu_sspp_cfg *)blk;
>>> + const struct dpu_sspp_sub_blks *sblk = sspp_block->sblk;
>>> +
>>> + base = sspp_block->base;
>>> +
>>> + msm_disp_snapshot_add_block(disp_state, sspp_block->len,
>>> mmio + base, "%s",
>>> + sspp_block->name);
>>> +
>>> + if (sspp_block->features & BIT(DPU_SSPP_SCALER_QSEED3) ||
>>> + sspp_block->features & BIT(DPU_SSPP_SCALER_QSEED3LITE) ||
>>> + sspp_block->features & BIT(DPU_SSPP_SCALER_QSEED4))
>>> + msm_disp_snapshot_add_block(disp_state,
>>> sblk->scaler_blk.len,
>>> + mmio + base + sblk->scaler_blk.base,
>>> "%s_%s",
>>> + sspp_block->name, sblk->scaler_blk.name);
>>
>> Actually, it would be better to:
>> - drop name from all sblk instances (and use known string instead of
>> the sblk name here)
Hey Dmitry,
FWIW, I second Abhinav's points about the sblk names. For example, if in
the future we want to add a "_rot" suffix specifically to the
VIG_SBLK_ROT.scaler name, it would be easier to just make that change in
the HW catalog.
>> - Use sblk->foo_blk.len to check if it should be printed or not.
From my understanding, your suggestion is to replace the feature flag
checks with a sblk.len > 0 check.
I don't think that would be good because it wouldn't be correct to
assume that the sblk will always be present. For example, for
DPU_HW_BLK_DSC, the sblks will only be present for DSC_BLK_1_2.
In addition, it is possible for sblks, like pp_sblk_te.te2, to have a
len of 0. While the register space of that specific sblk will not be
printed, I'd prefer the devcore dump to reflect what is present within
the HW catalog so that the user knows which pingpong blks have the TE2 sblk.
Thanks,
Jessica Zhang
>>
>
> No, I dont agree. If we drop the names from the sub_blk in the catalog,
> we will end up using "sub_blk_name" string here in the code to indicate
> which blk that is in the dump.
>
> If we add more sub_blks in the catalog in the future we need to keep
> changing the code over here. Thats not how it should be.
>
> Leaving the names in the catalog ensures that this code wont change and
> only catalog changes when we add a new sub_blk either for an existing or
> new chipset.
>
> catalog is indicating the new blk, and dumping code just prints it.
>
> with your approach, dumping code will or can keep changing with chipsets
> or sub_blks. Thats not how it should be.
>
>>> +
>>> + if (sspp_block->features & BIT(DPU_SSPP_CSC) ||
>>> sspp_block->features
>>> + & BIT(DPU_SSPP_CSC_10BIT))
>>
>> A very bad use of indentation. In future please split logically rather
>> than just filling the line up to the line width.
>>
>>> + msm_disp_snapshot_add_block(disp_state, sblk->csc_blk.len,
>>> + mmio + base + sblk->csc_blk.base, "%s_%s",
>>> + sspp_block->name, sblk->csc_blk.name);
>>> + break;
>>> + }
>>> + case DPU_HW_BLK_DSPP:
>>> + {
>>> + struct dpu_dspp_cfg *dspp_block = (struct dpu_dspp_cfg *)blk;
>>> +
>>> + base = dspp_block->base;
>>> +
>>> + msm_disp_snapshot_add_block(disp_state, dspp_block->len,
>>> mmio + base, "%s",
>>> + dspp_block->name);
>>> +
>>> + if (dspp_block->features & BIT(DPU_DSPP_PCC))
>>> + msm_disp_snapshot_add_block(disp_state,
>>> dspp_block->sblk->pcc.len,
>>> + mmio + base + dspp_block->sblk->pcc.base,
>>> + "%s_%s", dspp_block->name,
>>> + dspp_block->sblk->pcc.name);
>>> + break;
>>> + }
>>> + case DPU_HW_BLK_PINGPONG:
>>> + {
>>> + struct dpu_pingpong_cfg *pingpong_block = (struct
>>> dpu_pingpong_cfg *)blk;
>>> + const struct dpu_pingpong_sub_blks *sblk =
>>> pingpong_block->sblk;
>>> +
>>> + base = pingpong_block->base;
>>> +
>>> + msm_disp_snapshot_add_block(disp_state, pingpong_block->len,
>>> mmio + base, "%s",
>>> + pingpong_block->name);
>>> +
>>> + if (pingpong_block->features & BIT(DPU_PINGPONG_TE2))
>>> + msm_disp_snapshot_add_block(disp_state, sblk->te2.len,
>>> + mmio + base + sblk->te2.base, "%s_%s",
>>> + pingpong_block->name, sblk->te2.name);
>>> +
>>> + if (pingpong_block->features & BIT(DPU_PINGPONG_DITHER))
>>> + msm_disp_snapshot_add_block(disp_state, sblk->dither.len,
>>> + mmio + base + sblk->dither.base, "%s_%s",
>>> + pingpong_block->name, sblk->dither.name);
>>> + break;
>>> + }
>>> + case DPU_HW_BLK_DSC:
>>> + {
>>> + struct dpu_dsc_cfg *dsc_block = (struct dpu_dsc_cfg *)blk;
>>> +
>>> + base = dsc_block->base;
>>> +
>>> + if (dsc_block->features & BIT(DPU_DSC_HW_REV_1_2)) {
>>> + struct dpu_dsc_blk enc = dsc_block->sblk->enc;
>>> + struct dpu_dsc_blk ctl = dsc_block->sblk->ctl;
>>> +
>>> + /* For now, pass in a length of 0 because the DSC_BLK
>>> register space
>>> + * overlaps with the sblks' register space.
>>> + *
>>> + * TODO: Pass in a length of 0 t0 DSC_BLK_1_2 in the HW
>>> catalog where
>>> + * applicable.
>>
>> Nice catch, thank you. We should fix that.
>>
>
> Yes and we would have fixed that ourself if you wanted that with this
> series as another patch.
>
next prev parent reply other threads:[~2023-06-24 1:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-22 23:48 [PATCH 0/6] Add support to print sub block registers in dpu hw catalog Ryan McCann
2023-06-22 23:48 ` [PATCH 1/6] drm/msm: Update dev core dump to not print backwards Ryan McCann
2023-06-22 23:59 ` Dmitry Baryshkov
2023-06-22 23:48 ` [PATCH 2/6] drm/msm/dpu: Drop unused num argument from relevant macros Ryan McCann
2023-06-22 23:57 ` Dmitry Baryshkov
2023-06-23 0:15 ` Dmitry Baryshkov
2023-06-22 23:48 ` [PATCH 3/6] drm/msm/dpu: Define names for unnamed sblks Ryan McCann
2023-06-22 23:48 ` [PATCH 4/6] drm/msm/dpu: Remove redundant suffix in name of sub blocks Ryan McCann
2023-06-22 23:48 ` [PATCH 5/6] drm/msm/disp: Remove redundant prefix " Ryan McCann
2023-06-22 23:48 ` [PATCH 6/6] drm/msm/dpu: Update dev core dump to dump registers " Ryan McCann
2023-06-23 0:13 ` Dmitry Baryshkov
2023-06-24 0:09 ` Abhinav Kumar
2023-06-24 1:23 ` Jessica Zhang [this message]
2023-06-24 12:14 ` Dmitry Baryshkov
2023-06-24 12:07 ` Dmitry Baryshkov
2023-06-24 14:17 ` Abhinav Kumar
2023-06-24 15:03 ` Dmitry Baryshkov
2023-06-25 2:44 ` Abhinav Kumar
2023-06-29 23:29 ` Abhinav Kumar
2023-06-30 0:10 ` Dmitry Baryshkov
2023-06-24 12:18 ` Dmitry Baryshkov
2023-06-23 7:10 ` [PATCH 0/6] Add support to print sub block registers in dpu hw catalog Marijn Suijten
2023-06-30 23:15 ` 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=55d783d5-ef47-8c2e-d3ac-598e686e53fe@quicinc.com \
--to=quic_jesszhan@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=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=quic_abhinavk@quicinc.com \
--cc=quic_rmccann@quicinc.com \
--cc=robdclark@chromium.org \
--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