On 2023-06-23 12:36:06, Abhinav Kumar wrote:
>
>
> On 6/22/2023 11:57 PM, Marijn Suijten wrote:
> > On 2023-06-23 08:54:39, Marijn Suijten wrote:
> >> On 2023-06-22 22:47:04, Abhinav Kumar wrote:
> >>> On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
> >>>> All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
> >>>> This includes the common block itself, enc subblocks and some empty
> >>>> space around. Change that to pass 0x4 instead, the length of common
> >>>> register block itself.
> >>>>
> >>>> Fixes: 0d1b10c63346 ("drm/msm/dpu: add DSC 1.2 hw blocks for relevant chipsets")
> >>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
> >>>
> >>> There is no need of a fixes tag for this.
> >>>
> >>> This is not a bug but was intentional.
> >>>
> >>> Till we added sub-block parsing support we had to dump the whole block.
> >>>
> >>> And hence I would suggest this change should be merged after the
> >>> sub-block parsing change otherwise we wont have full register dumps for DSC.
> >>
> >> This was indeed intentional, we discussed it in [1].
> >>
> >> In fact I asked to make it 0xf00 + 0x10 or 0xf80 + 0x10 to also cover
> >> the CTL registers, but that change didn't make it through. 0x29c is an
> >> arbitrary number that I have no clue what it was based on.
> >
> > Ah, as expected Dmitry's second commit clarifies that the last register
> > in the enc block is at 0x98, and the base of the enc + length of the enc
> > then is 0x200 + 0x9c.
> >
> > That still excludes the ctl sblk.
>
> 0x29c is not an arbitrary number. The last encoder offset is 0x298 so we
> add 4 more to that.
That is literally what I said in this correction followup ;)
> Yes it will still exclude ctl blk as that space is not contiguous and we
> dont want to increase len all the way to 0xf00.
Sure, it's quite a lot of "dead space" to have in-between. Looking
forward to having better dumpers.
- Marijn
