| Message ID | 20230310005704.1332368-30-dmitry.baryshkov@linaro.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | drm/msm/dpu: wide planes support | expand |
On 3/9/2023 4:57 PM, Dmitry Baryshkov wrote: > Enable SmartDMA features for the rest of the platforms where it is > supposed to work. > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> I am so glad we split this. Without visual validation check we wouldnt have caught the issues and would have ended up with a blank half screen on our sc7280 CBs on DP. For sc7280, I validated the foll cases: 1) Basic Chrome UI comes up 2) Validated some browser use-cases and played some youtube videos 3) Validated multiple plug-in/plug-out cases with DP connected 4) IGT test cases with DP connected: - kms_atomic - kms_atomic_transition - kms_pipe_basic_crc Some notes: 1) I wanted to test 4k with this too but my monitor only supports 4k@60 which is not possible with 24bpp with 2 lanes and due to the HBR3 black screen issue I could not test that so far. But since I have that issue even with 1080P and without these changes, it should have no effect due to this series. 2) I wanted to test some YUV overlay cases but I still cannot find one on chrome. Its always using RGB. Will check with others. With these two noted, this change and this series has my Tested-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Only for sc7280 device. I still cannot give my R-b on this change till others validate visually and ensure things arent broken for them. If we don't get enough validation and if only sc7280 remains in this change, please re-post it with only that and I will give my R-b too. > --- > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 54 ++++++++----------- > 1 file changed, 23 insertions(+), 31 deletions(-) > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c > index 1fc0dfbebb7e..fc818b0273e7 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c > @@ -21,19 +21,16 @@ > (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED3)) > > #define VIG_SDM845_MASK \ > - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3)) > - > -#define VIG_SDM845_MASK_SDMA \ > - (VIG_SDM845_MASK | BIT(DPU_SSPP_SMART_DMA_V2)) > + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3) |\ > + BIT(DPU_SSPP_SMART_DMA_V2)) > > #define VIG_SC7180_MASK \ > - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4)) > + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4) |\ > + BIT(DPU_SSPP_SMART_DMA_V2)) > > #define VIG_SM8250_MASK \ > - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE)) > - > -#define VIG_SM8250_MASK_SDMA \ > - (VIG_SM8250_MASK | BIT(DPU_SSPP_SMART_DMA_V2)) > + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE) |\ > + BIT(DPU_SSPP_SMART_DMA_V2)) > > #define VIG_QCM2290_MASK (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL)) > > @@ -48,17 +45,12 @@ > #define DMA_SDM845_MASK \ > (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\ > BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\ > + BIT(DPU_SSPP_SMART_DMA_V2) |\ > BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT)) > > #define DMA_CURSOR_SDM845_MASK \ > (DMA_SDM845_MASK | BIT(DPU_SSPP_CURSOR)) > > -#define DMA_SDM845_MASK_SDMA \ > - (DMA_SDM845_MASK | BIT(DPU_SSPP_SMART_DMA_V2)) > - > -#define DMA_CURSOR_SDM845_MASK_SDMA \ > - (DMA_CURSOR_SDM845_MASK | BIT(DPU_SSPP_SMART_DMA_V2)) > - > #define DMA_CURSOR_MSM8998_MASK \ > (DMA_MSM8998_MASK | BIT(DPU_SSPP_CURSOR)) > > @@ -1208,21 +1200,21 @@ static const struct dpu_sspp_cfg msm8998_sspp[] = { > }; > > static const struct dpu_sspp_cfg sdm845_sspp[] = { > - SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_SDM845_MASK_SDMA, > + SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_SDM845_MASK, > sdm845_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0), > - SSPP_BLK("sspp_1", SSPP_VIG1, 0x6000, VIG_SDM845_MASK_SDMA, > + SSPP_BLK("sspp_1", SSPP_VIG1, 0x6000, VIG_SDM845_MASK, > sdm845_vig_sblk_1, 4, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG1), > - SSPP_BLK("sspp_2", SSPP_VIG2, 0x8000, VIG_SDM845_MASK_SDMA, > + SSPP_BLK("sspp_2", SSPP_VIG2, 0x8000, VIG_SDM845_MASK, > sdm845_vig_sblk_2, 8, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG2), > - SSPP_BLK("sspp_3", SSPP_VIG3, 0xa000, VIG_SDM845_MASK_SDMA, > + SSPP_BLK("sspp_3", SSPP_VIG3, 0xa000, VIG_SDM845_MASK, > sdm845_vig_sblk_3, 12, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG3), > - SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, DMA_SDM845_MASK_SDMA, > + SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, DMA_SDM845_MASK, > sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0), > - SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, DMA_SDM845_MASK_SDMA, > + SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, DMA_SDM845_MASK, > sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA1), > - SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, DMA_CURSOR_SDM845_MASK_SDMA, > + SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, DMA_CURSOR_SDM845_MASK, > sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR0), > - SSPP_BLK("sspp_11", SSPP_DMA3, 0x2a000, DMA_CURSOR_SDM845_MASK_SDMA, > + SSPP_BLK("sspp_11", SSPP_DMA3, 0x2a000, DMA_CURSOR_SDM845_MASK, > sdm845_dma_sblk_3, 13, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1), > }; > > @@ -1263,21 +1255,21 @@ static const struct dpu_sspp_sub_blks sm8250_vig_sblk_3 = > _VIG_SBLK("3", 8, DPU_SSPP_SCALER_QSEED3LITE); > > static const struct dpu_sspp_cfg sm8250_sspp[] = { > - SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_SM8250_MASK_SDMA, > + SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_SM8250_MASK, > sm8250_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0), > - SSPP_BLK("sspp_1", SSPP_VIG1, 0x6000, VIG_SM8250_MASK_SDMA, > + SSPP_BLK("sspp_1", SSPP_VIG1, 0x6000, VIG_SM8250_MASK, > sm8250_vig_sblk_1, 4, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG1), > - SSPP_BLK("sspp_2", SSPP_VIG2, 0x8000, VIG_SM8250_MASK_SDMA, > + SSPP_BLK("sspp_2", SSPP_VIG2, 0x8000, VIG_SM8250_MASK, > sm8250_vig_sblk_2, 8, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG2), > - SSPP_BLK("sspp_3", SSPP_VIG3, 0xa000, VIG_SM8250_MASK_SDMA, > + SSPP_BLK("sspp_3", SSPP_VIG3, 0xa000, VIG_SM8250_MASK, > sm8250_vig_sblk_3, 12, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG3), > - SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, DMA_SDM845_MASK_SDMA, > + SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, DMA_SDM845_MASK, > sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0), > - SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, DMA_SDM845_MASK_SDMA, > + SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, DMA_SDM845_MASK, > sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA1), > - SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, DMA_CURSOR_SDM845_MASK_SDMA, > + SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, DMA_CURSOR_SDM845_MASK, > sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR0), > - SSPP_BLK("sspp_11", SSPP_DMA3, 0x2a000, DMA_CURSOR_SDM845_MASK_SDMA, > + SSPP_BLK("sspp_11", SSPP_DMA3, 0x2a000, DMA_CURSOR_SDM845_MASK, > sdm845_dma_sblk_3, 13, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1), > }; >
On 14/03/2023 07:08, Abhinav Kumar wrote: > > > On 3/9/2023 4:57 PM, Dmitry Baryshkov wrote: >> Enable SmartDMA features for the rest of the platforms where it is >> supposed to work. >> >> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > I am so glad we split this. Without visual validation check we wouldnt > have caught the issues and would have ended up with a blank half screen > on our sc7280 CBs on DP. yes, the r_pipe was indeed mea culpa, when I didn't fully validate the results of a rebase. However this doesn't seem to be an sc7280-specific question. Are there any platform-specific issues with SmartDMA/multirect/planes revealed during testing? In other words, were there any issues which warrant this split? > > For sc7280, I validated the foll cases: Thanks a lot! > > 1) Basic Chrome UI comes up > 2) Validated some browser use-cases and played some youtube videos > 3) Validated multiple plug-in/plug-out cases with DP connected > 4) IGT test cases with DP connected: > - kms_atomic > - kms_atomic_transition > - kms_pipe_basic_crc > > Some notes: > > 1) I wanted to test 4k with this too but my monitor only supports 4k@60 > which is not possible with 24bpp with 2 lanes and due to the HBR3 black > screen issue I could not test that so far. But since I have that issue > even with 1080P and without these changes, it should have no effect due > to this series. > > 2) I wanted to test some YUV overlay cases but I still cannot find one > on chrome. Its always using RGB. Will check with others. Testing YUV would definitely be a must, especially for the SSPP allocation. Can you possibly check whether contemporaty Xv implementation employs YUV planes? You can try that using `mpv -xo xv` or `mplayer -vo xv` > > With these two noted, this change and this series has my > > Tested-by: Abhinav Kumar <quic_abhinavk@quicinc.com> > > Only for sc7280 device. > > I still cannot give my R-b on this change till others validate visually > and ensure things arent broken for them. > > If we don't get enough validation and if only sc7280 remains in this > change, please re-post it with only that and I will give my R-b too.
On 3/14/2023 3:58 AM, Dmitry Baryshkov wrote: > On 14/03/2023 07:08, Abhinav Kumar wrote: >> >> >> On 3/9/2023 4:57 PM, Dmitry Baryshkov wrote: >>> Enable SmartDMA features for the rest of the platforms where it is >>> supposed to work. >>> >>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> >> >> I am so glad we split this. Without visual validation check we wouldnt >> have caught the issues and would have ended up with a blank half >> screen on our sc7280 CBs on DP. > > yes, the r_pipe was indeed mea culpa, when I didn't fully validate the > results of a rebase. However this doesn't seem to be an sc7280-specific > question. Are there any platform-specific issues with > SmartDMA/multirect/planes revealed during testing? In other words, were > there any issues which warrant this split? > >> >> For sc7280, I validated the foll cases: > > Thanks a lot! > >> >> 1) Basic Chrome UI comes up >> 2) Validated some browser use-cases and played some youtube videos >> 3) Validated multiple plug-in/plug-out cases with DP connected >> 4) IGT test cases with DP connected: >> - kms_atomic >> - kms_atomic_transition >> - kms_pipe_basic_crc >> >> Some notes: >> >> 1) I wanted to test 4k with this too but my monitor only supports >> 4k@60 which is not possible with 24bpp with 2 lanes and due to the >> HBR3 black screen issue I could not test that so far. But since I have >> that issue even with 1080P and without these changes, it should have >> no effect due to this series. >> >> 2) I wanted to test some YUV overlay cases but I still cannot find one >> on chrome. Its always using RGB. Will check with others. > > Testing YUV would definitely be a must, especially for the SSPP > allocation. Can you possibly check whether contemporaty Xv > implementation employs YUV planes? You can try that using `mpv -xo xv` > or `mplayer -vo xv` > Let me get some feedback from CrOS folks here instead of just trial and error to find out. >> >> With these two noted, this change and this series has my >> >> Tested-by: Abhinav Kumar <quic_abhinavk@quicinc.com> >> There is no guarantee we will end up finding the YUV case, you could have retained the Tested-by for the efforts which were already put in instead of just blatantly removing it. >> Only for sc7280 device. >> >> I still cannot give my R-b on this change till others validate >> visually and ensure things arent broken for them. >> >> If we don't get enough validation and if only sc7280 remains in this >> change, please re-post it with only that and I will give my R-b too. >
On 14/03/2023 18:35, Abhinav Kumar wrote: > > > On 3/14/2023 3:58 AM, Dmitry Baryshkov wrote: >> On 14/03/2023 07:08, Abhinav Kumar wrote: >>> >>> >>> On 3/9/2023 4:57 PM, Dmitry Baryshkov wrote: >>>> Enable SmartDMA features for the rest of the platforms where it is >>>> supposed to work. >>>> >>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> >>> >>> I am so glad we split this. Without visual validation check we >>> wouldnt have caught the issues and would have ended up with a blank >>> half screen on our sc7280 CBs on DP. >> >> yes, the r_pipe was indeed mea culpa, when I didn't fully validate the >> results of a rebase. However this doesn't seem to be an >> sc7280-specific question. Are there any platform-specific issues with >> SmartDMA/multirect/planes revealed during testing? In other words, >> were there any issues which warrant this split? >> >>> >>> For sc7280, I validated the foll cases: >> >> Thanks a lot! >> >>> >>> 1) Basic Chrome UI comes up >>> 2) Validated some browser use-cases and played some youtube videos >>> 3) Validated multiple plug-in/plug-out cases with DP connected >>> 4) IGT test cases with DP connected: >>> - kms_atomic >>> - kms_atomic_transition >>> - kms_pipe_basic_crc >>> >>> Some notes: >>> >>> 1) I wanted to test 4k with this too but my monitor only supports >>> 4k@60 which is not possible with 24bpp with 2 lanes and due to the >>> HBR3 black screen issue I could not test that so far. But since I >>> have that issue even with 1080P and without these changes, it should >>> have no effect due to this series. >>> >>> 2) I wanted to test some YUV overlay cases but I still cannot find >>> one on chrome. Its always using RGB. Will check with others. >> >> Testing YUV would definitely be a must, especially for the SSPP >> allocation. Can you possibly check whether contemporaty Xv >> implementation employs YUV planes? You can try that using `mpv -xo xv` >> or `mplayer -vo xv` >> > > Let me get some feedback from CrOS folks here instead of just trial and > error to find out. > >>> >>> With these two noted, this change and this series has my >>> >>> Tested-by: Abhinav Kumar <quic_abhinavk@quicinc.com> >>> > > There is no guarantee we will end up finding the YUV case, you could > have retained the Tested-by for the efforts which were already put in > instead of just blatantly removing it. I can add it back for v6 (or move sc7280 to the previous patch if you'd prefer that). Also I think the Tested-by should have included the #sc7280 comment. If you don't mind I'll add it. >>> Only for sc7280 device. >>> >>> I still cannot give my R-b on this change till others validate >>> visually and ensure things arent broken for them. >>> >>> If we don't get enough validation and if only sc7280 remains in this >>> change, please re-post it with only that and I will give my R-b too. >>
On 3/14/2023 9:43 AM, Dmitry Baryshkov wrote: > On 14/03/2023 18:35, Abhinav Kumar wrote: >> >> >> On 3/14/2023 3:58 AM, Dmitry Baryshkov wrote: >>> On 14/03/2023 07:08, Abhinav Kumar wrote: >>>> >>>> >>>> On 3/9/2023 4:57 PM, Dmitry Baryshkov wrote: >>>>> Enable SmartDMA features for the rest of the platforms where it is >>>>> supposed to work. >>>>> >>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> >>>> >>>> I am so glad we split this. Without visual validation check we >>>> wouldnt have caught the issues and would have ended up with a blank >>>> half screen on our sc7280 CBs on DP. >>> >>> yes, the r_pipe was indeed mea culpa, when I didn't fully validate >>> the results of a rebase. However this doesn't seem to be an >>> sc7280-specific question. Are there any platform-specific issues with >>> SmartDMA/multirect/planes revealed during testing? In other words, >>> were there any issues which warrant this split? >>> Missed this question. Well the sc7280 issue was itself coming from a platform specific maxlinewidth. So like I wrote there, my monitor supported 2560x1600 and the maxlinewidth for sc7280 is 2400. Thats why I could catch this. With RB5 or other platforms in the previous patch, this would not have been caught without forcing some conditions. >>>> >>>> For sc7280, I validated the foll cases: >>> >>> Thanks a lot! >>> >>>> >>>> 1) Basic Chrome UI comes up >>>> 2) Validated some browser use-cases and played some youtube videos >>>> 3) Validated multiple plug-in/plug-out cases with DP connected >>>> 4) IGT test cases with DP connected: >>>> - kms_atomic >>>> - kms_atomic_transition >>>> - kms_pipe_basic_crc >>>> >>>> Some notes: >>>> >>>> 1) I wanted to test 4k with this too but my monitor only supports >>>> 4k@60 which is not possible with 24bpp with 2 lanes and due to the >>>> HBR3 black screen issue I could not test that so far. But since I >>>> have that issue even with 1080P and without these changes, it should >>>> have no effect due to this series. >>>> >>>> 2) I wanted to test some YUV overlay cases but I still cannot find >>>> one on chrome. Its always using RGB. Will check with others. >>> >>> Testing YUV would definitely be a must, especially for the SSPP >>> allocation. Can you possibly check whether contemporaty Xv >>> implementation employs YUV planes? You can try that using `mpv -xo >>> xv` or `mplayer -vo xv` >>> >> >> Let me get some feedback from CrOS folks here instead of just trial >> and error to find out. >> >>>> >>>> With these two noted, this change and this series has my >>>> >>>> Tested-by: Abhinav Kumar <quic_abhinavk@quicinc.com> >>>> >> >> There is no guarantee we will end up finding the YUV case, you could >> have retained the Tested-by for the efforts which were already put in >> instead of just blatantly removing it. > > I can add it back for v6 (or move sc7280 to the previous patch if you'd > prefer that). Also I think the Tested-by should have included the > #sc7280 comment. If you don't mind I'll add it. > My tag had all the comments of what I tested and what I didnt. >>>> Only for sc7280 device. >>>> >>>> I still cannot give my R-b on this change till others validate >>>> visually and ensure things arent broken for them. >>>> >>>> If we don't get enough validation and if only sc7280 remains in this >>>> change, please re-post it with only that and I will give my R-b too. >>> >
On Tue, 14 Mar 2023 at 18:48, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > > > On 3/14/2023 9:43 AM, Dmitry Baryshkov wrote: > > On 14/03/2023 18:35, Abhinav Kumar wrote: > >> > >> > >> On 3/14/2023 3:58 AM, Dmitry Baryshkov wrote: > >>> On 14/03/2023 07:08, Abhinav Kumar wrote: > >>>> > >>>> > >>>> On 3/9/2023 4:57 PM, Dmitry Baryshkov wrote: > >>>>> Enable SmartDMA features for the rest of the platforms where it is > >>>>> supposed to work. > >>>>> > >>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > >>>> > >>>> I am so glad we split this. Without visual validation check we > >>>> wouldnt have caught the issues and would have ended up with a blank > >>>> half screen on our sc7280 CBs on DP. > >>> > >>> yes, the r_pipe was indeed mea culpa, when I didn't fully validate > >>> the results of a rebase. However this doesn't seem to be an > >>> sc7280-specific question. Are there any platform-specific issues with > >>> SmartDMA/multirect/planes revealed during testing? In other words, > >>> were there any issues which warrant this split? > >>> > > Missed this question. > > Well the sc7280 issue was itself coming from a platform specific > maxlinewidth. So like I wrote there, my monitor supported 2560x1600 and > the maxlinewidth for sc7280 is 2400. Thats why I could catch this. > > With RB5 or other platforms in the previous patch, this would not have > been caught without forcing some conditions. > > >>>> > >>>> For sc7280, I validated the foll cases: > >>> > >>> Thanks a lot! > >>> > >>>> > >>>> 1) Basic Chrome UI comes up > >>>> 2) Validated some browser use-cases and played some youtube videos > >>>> 3) Validated multiple plug-in/plug-out cases with DP connected > >>>> 4) IGT test cases with DP connected: > >>>> - kms_atomic > >>>> - kms_atomic_transition > >>>> - kms_pipe_basic_crc > >>>> > >>>> Some notes: > >>>> > >>>> 1) I wanted to test 4k with this too but my monitor only supports > >>>> 4k@60 which is not possible with 24bpp with 2 lanes and due to the > >>>> HBR3 black screen issue I could not test that so far. But since I > >>>> have that issue even with 1080P and without these changes, it should > >>>> have no effect due to this series. > >>>> > >>>> 2) I wanted to test some YUV overlay cases but I still cannot find > >>>> one on chrome. Its always using RGB. Will check with others. > >>> > >>> Testing YUV would definitely be a must, especially for the SSPP > >>> allocation. Can you possibly check whether contemporaty Xv > >>> implementation employs YUV planes? You can try that using `mpv -xo > >>> xv` or `mplayer -vo xv` > >>> > >> > >> Let me get some feedback from CrOS folks here instead of just trial > >> and error to find out. > >> > >>>> > >>>> With these two noted, this change and this series has my > >>>> > >>>> Tested-by: Abhinav Kumar <quic_abhinavk@quicinc.com> > >>>> > >> > >> There is no guarantee we will end up finding the YUV case, you could > >> have retained the Tested-by for the efforts which were already put in > >> instead of just blatantly removing it. > > > > I can add it back for v6 (or move sc7280 to the previous patch if you'd > > prefer that). Also I think the Tested-by should have included the > > #sc7280 comment. If you don't mind I'll add it. > > > > My tag had all the comments of what I tested and what I didnt. Not inline. Thus once patchwork picked your tag, all context (testing on sc7280) was lost. > >>>> Only for sc7280 device. > >>>> > >>>> I still cannot give my R-b on this change till others validate > >>>> visually and ensure things arent broken for them. > >>>> > >>>> If we don't get enough validation and if only sc7280 remains in this > >>>> change, please re-post it with only that and I will give my R-b too. > >>> > >
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c index 1fc0dfbebb7e..fc818b0273e7 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c @@ -21,19 +21,16 @@ (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED3)) #define VIG_SDM845_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3)) - -#define VIG_SDM845_MASK_SDMA \ - (VIG_SDM845_MASK | BIT(DPU_SSPP_SMART_DMA_V2)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_SC7180_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_SM8250_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE)) - -#define VIG_SM8250_MASK_SDMA \ - (VIG_SM8250_MASK | BIT(DPU_SSPP_SMART_DMA_V2)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_QCM2290_MASK (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL)) @@ -48,17 +45,12 @@ #define DMA_SDM845_MASK \ (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\ BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\ + BIT(DPU_SSPP_SMART_DMA_V2) |\ BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT)) #define DMA_CURSOR_SDM845_MASK \ (DMA_SDM845_MASK | BIT(DPU_SSPP_CURSOR)) -#define DMA_SDM845_MASK_SDMA \ - (DMA_SDM845_MASK | BIT(DPU_SSPP_SMART_DMA_V2)) - -#define DMA_CURSOR_SDM845_MASK_SDMA \ - (DMA_CURSOR_SDM845_MASK | BIT(DPU_SSPP_SMART_DMA_V2)) - #define DMA_CURSOR_MSM8998_MASK \ (DMA_MSM8998_MASK | BIT(DPU_SSPP_CURSOR)) @@ -1208,21 +1200,21 @@ static const struct dpu_sspp_cfg msm8998_sspp[] = { }; static const struct dpu_sspp_cfg sdm845_sspp[] = { - SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_SDM845_MASK_SDMA, + SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_SDM845_MASK, sdm845_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0), - SSPP_BLK("sspp_1", SSPP_VIG1, 0x6000, VIG_SDM845_MASK_SDMA, + SSPP_BLK("sspp_1", SSPP_VIG1, 0x6000, VIG_SDM845_MASK, sdm845_vig_sblk_1, 4, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG1), - SSPP_BLK("sspp_2", SSPP_VIG2, 0x8000, VIG_SDM845_MASK_SDMA, + SSPP_BLK("sspp_2", SSPP_VIG2, 0x8000, VIG_SDM845_MASK, sdm845_vig_sblk_2, 8, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG2), - SSPP_BLK("sspp_3", SSPP_VIG3, 0xa000, VIG_SDM845_MASK_SDMA, + SSPP_BLK("sspp_3", SSPP_VIG3, 0xa000, VIG_SDM845_MASK, sdm845_vig_sblk_3, 12, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG3), - SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, DMA_SDM845_MASK_SDMA, + SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, DMA_SDM845_MASK, sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0), - SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, DMA_SDM845_MASK_SDMA, + SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, DMA_SDM845_MASK, sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA1), - SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, DMA_CURSOR_SDM845_MASK_SDMA, + SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, DMA_CURSOR_SDM845_MASK, sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR0), - SSPP_BLK("sspp_11", SSPP_DMA3, 0x2a000, DMA_CURSOR_SDM845_MASK_SDMA, + SSPP_BLK("sspp_11", SSPP_DMA3, 0x2a000, DMA_CURSOR_SDM845_MASK, sdm845_dma_sblk_3, 13, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1), }; @@ -1263,21 +1255,21 @@ static const struct dpu_sspp_sub_blks sm8250_vig_sblk_3 = _VIG_SBLK("3", 8, DPU_SSPP_SCALER_QSEED3LITE); static const struct dpu_sspp_cfg sm8250_sspp[] = { - SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_SM8250_MASK_SDMA, + SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_SM8250_MASK, sm8250_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0), - SSPP_BLK("sspp_1", SSPP_VIG1, 0x6000, VIG_SM8250_MASK_SDMA, + SSPP_BLK("sspp_1", SSPP_VIG1, 0x6000, VIG_SM8250_MASK, sm8250_vig_sblk_1, 4, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG1), - SSPP_BLK("sspp_2", SSPP_VIG2, 0x8000, VIG_SM8250_MASK_SDMA, + SSPP_BLK("sspp_2", SSPP_VIG2, 0x8000, VIG_SM8250_MASK, sm8250_vig_sblk_2, 8, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG2), - SSPP_BLK("sspp_3", SSPP_VIG3, 0xa000, VIG_SM8250_MASK_SDMA, + SSPP_BLK("sspp_3", SSPP_VIG3, 0xa000, VIG_SM8250_MASK, sm8250_vig_sblk_3, 12, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG3), - SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, DMA_SDM845_MASK_SDMA, + SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, DMA_SDM845_MASK, sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0), - SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, DMA_SDM845_MASK_SDMA, + SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, DMA_SDM845_MASK, sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA1), - SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, DMA_CURSOR_SDM845_MASK_SDMA, + SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, DMA_CURSOR_SDM845_MASK, sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR0), - SSPP_BLK("sspp_11", SSPP_DMA3, 0x2a000, DMA_CURSOR_SDM845_MASK_SDMA, + SSPP_BLK("sspp_11", SSPP_DMA3, 0x2a000, DMA_CURSOR_SDM845_MASK, sdm845_dma_sblk_3, 13, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1), };
Enable SmartDMA features for the rest of the platforms where it is supposed to work. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 54 ++++++++----------- 1 file changed, 23 insertions(+), 31 deletions(-)