[RFC,0/6] drm/msm: DSC Electric Boogaloo for sm8[12]50

  This preliminary Display Stream Compression support package for
(initially tested on) sm8[12]50 is based on comparing DSC behaviour
between downstream and mainline.  Some new callbacks are added (for
binding blocks on active CTLs), logic bugs are corrected, zeroed struct
members are now assigned proper values, and RM allocation and hw block
retrieval now hand out (or not) DSC blocks without causing null-pointer
dereferences.

Unfortunately it is not yet enough to get rid of completely corrupted
display output on the boards I tested here:
- Sony Xperia 1 (sm8150), 1644x3840 or 1096x2560 pixels;
- Sony Xperia 5II (sm8250), 1080x2520, at 60 or 120Hz;
- (can include more Xperia boards if desired)

Both devices use the DUALPIPE_DSCMERGE topology downstream: dual LM, PP
and DSC, but only a single INTF/encoder/DSI-link.

Hopefully this spawns some community/upstream interest to help rootcause
our corruption issues (after we open a drm/msm report on GitLab for more
appropriate tracking).

The Sony Xperia XZ3 (sdm845) was fully tested and validated with this
series to not cause any regressions (an one of the math fixes now allows
us to change slice_count in the panel driver, which would corrupt
previously).

Marijn Suijten (6):
  drm/msm/dpu1: Implement DSC binding to PP block for CTL V1
  drm/msm/dpu1: Add DSC config for sm8150 and sm8250
  drm/msm/dpu1: Wire up DSC mask for active CTL configuration
  drm/msm/dsi: Use DSC slice(s) packet size to compute word count
  drm/msm/dsi: Flip greater-than check for slice_count and
    slice_per_intf
  drm/msm/dpu: Disallow unallocated (DSC) resources to be returned

 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   |  3 +++
 .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c  |  1 +
 .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c  |  1 +
 .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c   |  2 ++
 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c    | 23 +++++++++++-----
 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h    |  9 +++++++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c    | 27 +++++++++++++++++++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h    |  4 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c        | 10 +++++++
 drivers/gpu/drm/msm/dsi/dsi_host.c            |  6 ++---
 10 files changed, 77 insertions(+), 9 deletions(-)

--
2.38.1
  

On 14/12/2022 01:22, Marijn Suijten wrote:
> This preliminary Display Stream Compression support package for
> (initially tested on) sm8[12]50 is based on comparing DSC behaviour
> between downstream and mainline.  Some new callbacks are added (for
> binding blocks on active CTLs), logic bugs are corrected, zeroed struct
> members are now assigned proper values, and RM allocation and hw block
> retrieval now hand out (or not) DSC blocks without causing null-pointer
> dereferences.
> 
> Unfortunately it is not yet enough to get rid of completely corrupted
> display output on the boards I tested here:
> - Sony Xperia 1 (sm8150), 1644x3840 or 1096x2560 pixels;
> - Sony Xperia 5II (sm8250), 1080x2520, at 60 or 120Hz;
> - (can include more Xperia boards if desired)
> 
> Both devices use the DUALPIPE_DSCMERGE topology downstream: dual LM, PP
> and DSC, but only a single INTF/encoder/DSI-link.
> 
> Hopefully this spawns some community/upstream interest to help rootcause
> our corruption issues (after we open a drm/msm report on GitLab for more
> appropriate tracking).
> 
> The Sony Xperia XZ3 (sdm845) was fully tested and validated with this
> series to not cause any regressions (an one of the math fixes now allows
> us to change slice_count in the panel driver, which would corrupt
> previously).
> 
> Marijn Suijten (6):
>    drm/msm/dpu1: Implement DSC binding to PP block for CTL V1
>    drm/msm/dpu1: Add DSC config for sm8150 and sm8250
>    drm/msm/dpu1: Wire up DSC mask for active CTL configuration
>    drm/msm/dsi: Use DSC slice(s) packet size to compute word count
>    drm/msm/dsi: Flip greater-than check for slice_count and
>      slice_per_intf
>    drm/msm/dpu: Disallow unallocated (DSC) resources to be returned

General comment: patches with Fixes ideally should come first. Usually 
they are picked into -fixes and/or stable kernels. If the Fixes patches 
are in the middle of the series, one can not be sure that they do not 
have dependencies on previous patches. If there is one, it should 
probably be stated clearly to ease work on backporting them.

> 
>   drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   |  3 +++
>   .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c  |  1 +
>   .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c  |  1 +
>   .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c   |  2 ++
>   .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c    | 23 +++++++++++-----
>   .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h    |  9 +++++++
>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c    | 27 +++++++++++++++++++
>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h    |  4 +++
>   drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c        | 10 +++++++
>   drivers/gpu/drm/msm/dsi/dsi_host.c            |  6 ++---
>   10 files changed, 77 insertions(+), 9 deletions(-)
> 
> --
> 2.38.1
>
  

On 2022-12-14 20:40:06, Dmitry Baryshkov wrote:
> On 14/12/2022 01:22, Marijn Suijten wrote:
> > This preliminary Display Stream Compression support package for
> > (initially tested on) sm8[12]50 is based on comparing DSC behaviour
> > between downstream and mainline.  Some new callbacks are added (for
> > binding blocks on active CTLs), logic bugs are corrected, zeroed struct
> > members are now assigned proper values, and RM allocation and hw block
> > retrieval now hand out (or not) DSC blocks without causing null-pointer
> > dereferences.
> > 
> > Unfortunately it is not yet enough to get rid of completely corrupted
> > display output on the boards I tested here:
> > - Sony Xperia 1 (sm8150), 1644x3840 or 1096x2560 pixels;
> > - Sony Xperia 5II (sm8250), 1080x2520, at 60 or 120Hz;
> > - (can include more Xperia boards if desired)
> > 
> > Both devices use the DUALPIPE_DSCMERGE topology downstream: dual LM, PP
> > and DSC, but only a single INTF/encoder/DSI-link.
> > 
> > Hopefully this spawns some community/upstream interest to help rootcause
> > our corruption issues (after we open a drm/msm report on GitLab for more
> > appropriate tracking).
> > 
> > The Sony Xperia XZ3 (sdm845) was fully tested and validated with this
> > series to not cause any regressions (an one of the math fixes now allows
> > us to change slice_count in the panel driver, which would corrupt
> > previously).
> > 
> > Marijn Suijten (6):
> >    drm/msm/dpu1: Implement DSC binding to PP block for CTL V1
> >    drm/msm/dpu1: Add DSC config for sm8150 and sm8250
> >    drm/msm/dpu1: Wire up DSC mask for active CTL configuration
> >    drm/msm/dsi: Use DSC slice(s) packet size to compute word count
> >    drm/msm/dsi: Flip greater-than check for slice_count and
> >      slice_per_intf
> >    drm/msm/dpu: Disallow unallocated (DSC) resources to be returned
> 
> General comment: patches with Fixes ideally should come first. Usually 
> they are picked into -fixes and/or stable kernels. If the Fixes patches 
> are in the middle of the series, one can not be sure that they do not 
> have dependencies on previous patches. If there is one, it should 
> probably be stated clearly to ease work on backporting them.

Ack, I may have rushed these RFC patches straight off my branches onto
the lists in hopes of sparking some suggestions on what may still be
broken or missing to get DSC working on sm[12]50, but will keep this in
mind for v2 after receiving some more review.

That said, any suggestions?

- Marijn
  

On 14/12/2022 21:23, Marijn Suijten wrote:
> On 2022-12-14 20:40:06, Dmitry Baryshkov wrote:
>> On 14/12/2022 01:22, Marijn Suijten wrote:
>>> This preliminary Display Stream Compression support package for
>>> (initially tested on) sm8[12]50 is based on comparing DSC behaviour
>>> between downstream and mainline.  Some new callbacks are added (for
>>> binding blocks on active CTLs), logic bugs are corrected, zeroed struct
>>> members are now assigned proper values, and RM allocation and hw block
>>> retrieval now hand out (or not) DSC blocks without causing null-pointer
>>> dereferences.
>>>
>>> Unfortunately it is not yet enough to get rid of completely corrupted
>>> display output on the boards I tested here:
>>> - Sony Xperia 1 (sm8150), 1644x3840 or 1096x2560 pixels;
>>> - Sony Xperia 5II (sm8250), 1080x2520, at 60 or 120Hz;
>>> - (can include more Xperia boards if desired)
>>>
>>> Both devices use the DUALPIPE_DSCMERGE topology downstream: dual LM, PP
>>> and DSC, but only a single INTF/encoder/DSI-link.
>>>
>>> Hopefully this spawns some community/upstream interest to help rootcause
>>> our corruption issues (after we open a drm/msm report on GitLab for more
>>> appropriate tracking).
>>>
>>> The Sony Xperia XZ3 (sdm845) was fully tested and validated with this
>>> series to not cause any regressions (an one of the math fixes now allows
>>> us to change slice_count in the panel driver, which would corrupt
>>> previously).
>>>
>>> Marijn Suijten (6):
>>>     drm/msm/dpu1: Implement DSC binding to PP block for CTL V1
>>>     drm/msm/dpu1: Add DSC config for sm8150 and sm8250
>>>     drm/msm/dpu1: Wire up DSC mask for active CTL configuration
>>>     drm/msm/dsi: Use DSC slice(s) packet size to compute word count
>>>     drm/msm/dsi: Flip greater-than check for slice_count and
>>>       slice_per_intf
>>>     drm/msm/dpu: Disallow unallocated (DSC) resources to be returned
>>
>> General comment: patches with Fixes ideally should come first. Usually
>> they are picked into -fixes and/or stable kernels. If the Fixes patches
>> are in the middle of the series, one can not be sure that they do not
>> have dependencies on previous patches. If there is one, it should
>> probably be stated clearly to ease work on backporting them.
> 
> Ack, I may have rushed these RFC patches straight off my branches onto
> the lists in hopes of sparking some suggestions on what may still be
> broken or missing to get DSC working on sm[12]50, but will keep this in
> mind for v2 after receiving some more review.
> 
> That said, any suggestions?


 From what I've noticed lately:

- set dsc_version_major/dsc_version_minor
- try using dsc params from 1.2 rater than 1.1 version spec (there is 
small difference there)
  

On 2022-12-15 02:52:01, Dmitry Baryshkov wrote:
> On 14/12/2022 21:23, Marijn Suijten wrote:
> > On 2022-12-14 20:40:06, Dmitry Baryshkov wrote:
> >> On 14/12/2022 01:22, Marijn Suijten wrote:
> >>> This preliminary Display Stream Compression support package for
> >>> (initially tested on) sm8[12]50 is based on comparing DSC behaviour
> >>> between downstream and mainline.  Some new callbacks are added (for
> >>> binding blocks on active CTLs), logic bugs are corrected, zeroed struct
> >>> members are now assigned proper values, and RM allocation and hw block
> >>> retrieval now hand out (or not) DSC blocks without causing null-pointer
> >>> dereferences.
> >>>
> >>> Unfortunately it is not yet enough to get rid of completely corrupted
> >>> display output on the boards I tested here:
> >>> - Sony Xperia 1 (sm8150), 1644x3840 or 1096x2560 pixels;
> >>> - Sony Xperia 5II (sm8250), 1080x2520, at 60 or 120Hz;
> >>> - (can include more Xperia boards if desired)
> >>>
> >>> Both devices use the DUALPIPE_DSCMERGE topology downstream: dual LM, PP
> >>> and DSC, but only a single INTF/encoder/DSI-link.
> >>>
> >>> Hopefully this spawns some community/upstream interest to help rootcause
> >>> our corruption issues (after we open a drm/msm report on GitLab for more
> >>> appropriate tracking).
> >>>
> >>> The Sony Xperia XZ3 (sdm845) was fully tested and validated with this
> >>> series to not cause any regressions (an one of the math fixes now allows
> >>> us to change slice_count in the panel driver, which would corrupt
> >>> previously).
> >>>
> >>> Marijn Suijten (6):
> >>>     drm/msm/dpu1: Implement DSC binding to PP block for CTL V1
> >>>     drm/msm/dpu1: Add DSC config for sm8150 and sm8250
> >>>     drm/msm/dpu1: Wire up DSC mask for active CTL configuration
> >>>     drm/msm/dsi: Use DSC slice(s) packet size to compute word count
> >>>     drm/msm/dsi: Flip greater-than check for slice_count and
> >>>       slice_per_intf
> >>>     drm/msm/dpu: Disallow unallocated (DSC) resources to be returned
> >>
> >> General comment: patches with Fixes ideally should come first. Usually
> >> they are picked into -fixes and/or stable kernels. If the Fixes patches
> >> are in the middle of the series, one can not be sure that they do not
> >> have dependencies on previous patches. If there is one, it should
> >> probably be stated clearly to ease work on backporting them.
> > 
> > Ack, I may have rushed these RFC patches straight off my branches onto
> > the lists in hopes of sparking some suggestions on what may still be
> > broken or missing to get DSC working on sm[12]50, but will keep this in
> > mind for v2 after receiving some more review.
> > 
> > That said, any suggestions?
> 
> 
>  From what I've noticed lately:

Apologies for the late reply, I wanted to double-check this but now
ended up basing my

> - set dsc_version_major/dsc_version_minor

We always set these in our panel drivers (all the way from back when our
initial panel driver changes were based on what Vinod did for Pixel 3),
both to 1.  As expected this results in 0x11 in the first byte of the
Pixel Parameter Set sent to the DrIC over DSI.

> - try using dsc params from 1.2 rater than 1.1 version spec (there is 
> small difference there)

Didn't have any effect and this is not what downstream sets/sends
regardless, all our panels (on these sm8[12]50 SoCs) are hardcoded to
DSC 1.1 downstream.

Should I test this again, but also setting the version in the
compression_mode command?

- Marijn