[v3,06/21] drm/msm/dpu: Use V2 DITHER PINGPONG sub-block in SM8[34]50/SC8280XP

  According to downstream sources this DITHER sub-block sits at an offset
of 0xe0 with version 0x20000.  The PP_BLK_DITHER macro is _not_ used as
downstream still says the size of the PINGPONG block is 0xd4 and not 0.

Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280XP")
Fixes: 0e91bcbb0016 ("drm/msm/dpu: Add SM8350 to hw catalog")
Fixes: 100d7ef6995d ("drm/msm/dpu: add support for SM8450")
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
---
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h   | 12 ++++++------
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 12 ++++++------
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h   | 16 ++++++++--------
 3 files changed, 20 insertions(+), 20 deletions(-)
  

On 4/25/2023 4:05 PM, Marijn Suijten wrote:
> According to downstream sources this DITHER sub-block sits at an offset
> of 0xe0 with version 0x20000.  The PP_BLK_DITHER macro is _not_ used as
> downstream still says the size of the PINGPONG block is 0xd4 and not 0.
> 

the PINGPONG block size is 0x0 on sm8350, sm8450 and sc8280xp.

and length of dither is 0x20 and they all start at 0xe0.

So now does anything prevent us from using PP_BLK_DITHER macro for these?

> Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280XP")
> Fixes: 0e91bcbb0016 ("drm/msm/dpu: Add SM8350 to hw catalog")
> Fixes: 100d7ef6995d ("drm/msm/dpu: add support for SM8450")
> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
> ---
>   drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h   | 12 ++++++------
>   drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 12 ++++++------
>   drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h   | 16 ++++++++--------
>   3 files changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> index 41ef0c8fc993f..4c1bb88029cd3 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> @@ -127,22 +127,22 @@ static const struct dpu_dspp_cfg sm8350_dspp[] = {
>   };
>   
>   static const struct dpu_pingpong_cfg sm8350_pp[] = {
> -	PP_BLK("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, sdm845_pp_sblk,
> +	PP_BLK("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, sc7280_pp_sblk,
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),
> -	PP_BLK("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, sdm845_pp_sblk,
> +	PP_BLK("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, sc7280_pp_sblk,
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 13)),
> -	PP_BLK("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, sdm845_pp_sblk,
> +	PP_BLK("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, sc7280_pp_sblk,
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 14)),
> -	PP_BLK("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1, sdm845_pp_sblk,
> +	PP_BLK("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1, sc7280_pp_sblk,
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
> -	PP_BLK("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2, sdm845_pp_sblk,
> +	PP_BLK("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2, sc7280_pp_sblk,
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 30),
>   			-1),
> -	PP_BLK("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2, sdm845_pp_sblk,
> +	PP_BLK("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2, sc7280_pp_sblk,
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31),
>   			-1),
>   };
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
> index 12c14d15e3863..bab9b0715f8c2 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
> @@ -121,17 +121,17 @@ static const struct dpu_dspp_cfg sc8280xp_dspp[] = {
>   };
>   
>   static const struct dpu_pingpong_cfg sc8280xp_pp[] = {
> -	PP_BLK("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, sdm845_pp_sblk,
> +	PP_BLK("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, sc7280_pp_sblk,
>   		  DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8), -1),
> -	PP_BLK("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, sdm845_pp_sblk,
> +	PP_BLK("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, sc7280_pp_sblk,
>   		  DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9), -1),
> -	PP_BLK("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, sdm845_pp_sblk,
> +	PP_BLK("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, sc7280_pp_sblk,
>   		  DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10), -1),
> -	PP_BLK("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1, sdm845_pp_sblk,
> +	PP_BLK("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1, sc7280_pp_sblk,
>   		  DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11), -1),
> -	PP_BLK("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2, sdm845_pp_sblk,
> +	PP_BLK("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2, sc7280_pp_sblk,
>   		  DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 30), -1),
> -	PP_BLK("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2, sdm845_pp_sblk,
> +	PP_BLK("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2, sc7280_pp_sblk,
>   		  DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31), -1),
>   };
>   
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
> index e409c119b0a2a..ec296a52076ce 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
> @@ -128,28 +128,28 @@ static const struct dpu_dspp_cfg sm8450_dspp[] = {
>   };
>   /* FIXME: interrupts */
>   static const struct dpu_pingpong_cfg sm8450_pp[] = {
> -	PP_BLK("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, sdm845_pp_sblk,
> +	PP_BLK("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, sc7280_pp_sblk,
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),
> -	PP_BLK("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, sdm845_pp_sblk,
> +	PP_BLK("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, sc7280_pp_sblk,
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 13)),
> -	PP_BLK("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, sdm845_pp_sblk,
> +	PP_BLK("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, sc7280_pp_sblk,
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 14)),
> -	PP_BLK("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1, sdm845_pp_sblk,
> +	PP_BLK("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1, sc7280_pp_sblk,
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
> -	PP_BLK("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2, sdm845_pp_sblk,
> +	PP_BLK("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2, sc7280_pp_sblk,
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 30),
>   			-1),
> -	PP_BLK("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2, sdm845_pp_sblk,
> +	PP_BLK("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2, sc7280_pp_sblk,
>   			DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31),
>   			-1),
> -	PP_BLK("pingpong_6", PINGPONG_6, 0x65800, MERGE_3D_3, sdm845_pp_sblk,
> +	PP_BLK("pingpong_6", PINGPONG_6, 0x65800, MERGE_3D_3, sc7280_pp_sblk,
>   			-1,
>   			-1),
> -	PP_BLK("pingpong_7", PINGPONG_7, 0x65c00, MERGE_3D_3, sdm845_pp_sblk,
> +	PP_BLK("pingpong_7", PINGPONG_7, 0x65c00, MERGE_3D_3, sc7280_pp_sblk,
>   			-1,
>   			-1),
>   };
>
  

On 2023-04-26 09:24:19, Abhinav Kumar wrote:
> 
> 
> On 4/25/2023 4:05 PM, Marijn Suijten wrote:
> > According to downstream sources this DITHER sub-block sits at an offset
> > of 0xe0 with version 0x20000.  The PP_BLK_DITHER macro is _not_ used as
> > downstream still says the size of the PINGPONG block is 0xd4 and not 0.
> > 
> 
> the PINGPONG block size is 0x0 on sm8350, sm8450 and sc8280xp.
> 
> and length of dither is 0x20 and they all start at 0xe0.
> 
> So now does anything prevent us from using PP_BLK_DITHER macro for these?

Nothing prevents it from being used (if you are referring to our
previous conversations) besides this information not being available in
public DTS (I simply did not know) and the fact that all these many
fixes - however necessary they are - distract from the main topic of
this series: bringing INTF TE support to DPU1.

I'll fit in that patch though, as I have to send v4 anyway.

- Marijn
  

On 4/26/2023 12:08 PM, Marijn Suijten wrote:
> On 2023-04-26 09:24:19, Abhinav Kumar wrote:
>>
>>
>> On 4/25/2023 4:05 PM, Marijn Suijten wrote:
>>> According to downstream sources this DITHER sub-block sits at an offset
>>> of 0xe0 with version 0x20000.  The PP_BLK_DITHER macro is _not_ used as
>>> downstream still says the size of the PINGPONG block is 0xd4 and not 0.
>>>
>>
>> the PINGPONG block size is 0x0 on sm8350, sm8450 and sc8280xp.
>>
>> and length of dither is 0x20 and they all start at 0xe0.
>>
>> So now does anything prevent us from using PP_BLK_DITHER macro for these?
> 
> Nothing prevents it from being used (if you are referring to our
> previous conversations) besides this information not being available in
> public DTS (I simply did not know) and the fact that all these many
> fixes - however necessary they are - distract from the main topic of
> this series: bringing INTF TE support to DPU1.
> 

Yeah, you could have sent these as a separate series if you wanted to 
stick to this one being only intf te.

> I'll fit in that patch though, as I have to send v4 anyway.

Thanks.

> 
> - Marijn
  

On 2023-04-26 12:11:39, Abhinav Kumar wrote:
> 
> 
> On 4/26/2023 12:08 PM, Marijn Suijten wrote:
> > On 2023-04-26 09:24:19, Abhinav Kumar wrote:
> >>
> >>
> >> On 4/25/2023 4:05 PM, Marijn Suijten wrote:
> >>> According to downstream sources this DITHER sub-block sits at an offset
> >>> of 0xe0 with version 0x20000.  The PP_BLK_DITHER macro is _not_ used as
> >>> downstream still says the size of the PINGPONG block is 0xd4 and not 0.
> >>>
> >>
> >> the PINGPONG block size is 0x0 on sm8350, sm8450 and sc8280xp.
> >>
> >> and length of dither is 0x20 and they all start at 0xe0.
> >>
> >> So now does anything prevent us from using PP_BLK_DITHER macro for these?
> > 
> > Nothing prevents it from being used (if you are referring to our
> > previous conversations) besides this information not being available in
> > public DTS (I simply did not know) and the fact that all these many
> > fixes - however necessary they are - distract from the main topic of
> > this series: bringing INTF TE support to DPU1.
> > 
> 
> Yeah, you could have sent these as a separate series if you wanted to 
> stick to this one being only intf te.

As already explained in IRC, and repeating here for posterity:

Maintaining two heavily-dependent series that constantly touch the exact
same lines in the catalog for many SoCs at once is pretty much
impossible.  Doing it that way relies on one of the two series to be
easily pick-able so that the other can proceed through a few review
rounds and revisions without constantly conflicting or having to be
rebased on the other.  And that doesn't apply here: both INTF TE and the
fixes have required extra revisions.  And then, some of the fixes are
even preliminary to INTF TE support.

- Marijn