Message ID | 20250514-max-mixer-width-v1-4-c8ba0d9bb858@oss.qualcomm.com |
---|---|
State | New |
Headers | show |
Series | drm/msm/dpu: Drop max_mixer_width and MAX_HDISPLAY_SPLIT | expand |
On Thu, 15 May 2025 at 02:52, Jessica Zhang <jessica.zhang@oss.qualcomm.com> wrote: > > Since the max mixer width is not a strict hardware limit, use the actual Is it? What is the actual max width that the mixer can support? > hardware limit (the writeback maxlinewidth) to filter modes. > > Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 9 +-------- > 1 file changed, 1 insertion(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c > index 8ff496082902..0a198896f656 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c > @@ -14,14 +14,7 @@ static int dpu_wb_conn_get_modes(struct drm_connector *connector) > struct msm_drm_private *priv = dev->dev_private; > struct dpu_kms *dpu_kms = to_dpu_kms(priv->kms); > > - /* > - * We should ideally be limiting the modes only to the maxlinewidth but > - * on some chipsets this will allow even 4k modes to be added which will > - * fail the per SSPP bandwidth checks. So, till we have dual-SSPP support > - * and source split support added lets limit the modes based on max_mixer_width > - * as 4K modes can then be supported. > - */ > - return drm_add_modes_noedid(connector, dpu_kms->catalog->caps->max_mixer_width, > + return drm_add_modes_noedid(connector, dpu_kms->catalog->wb->maxlinewidth, > dev->mode_config.max_height); > } > > > -- > 2.49.0 >
On 5/14/2025 5:17 PM, Dmitry Baryshkov wrote: > On Thu, 15 May 2025 at 02:52, Jessica Zhang > <jessica.zhang@oss.qualcomm.com> wrote: >> >> Since the max mixer width is not a strict hardware limit, use the actual > > Is it? What is the actual max width that the mixer can support? Hi Dmitry, By hardware limit, I mean restrictions based on the size of buffers within the hardware block itself. PINGPONG, DSC encoder, and WB blocks all have buffers, so they do have a max supported width based on the size of their hardware buffers. On the other hand, LM doesn't so it isn't necessarily restricted by a max width. I can clarify this in the commit message and cover letter. Thanks, Jessica Zhang > >> hardware limit (the writeback maxlinewidth) to filter modes. >> >> Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> >> --- >> drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 9 +-------- >> 1 file changed, 1 insertion(+), 8 deletions(-) >> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c >> index 8ff496082902..0a198896f656 100644 >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c >> @@ -14,14 +14,7 @@ static int dpu_wb_conn_get_modes(struct drm_connector *connector) >> struct msm_drm_private *priv = dev->dev_private; >> struct dpu_kms *dpu_kms = to_dpu_kms(priv->kms); >> >> - /* >> - * We should ideally be limiting the modes only to the maxlinewidth but >> - * on some chipsets this will allow even 4k modes to be added which will >> - * fail the per SSPP bandwidth checks. So, till we have dual-SSPP support >> - * and source split support added lets limit the modes based on max_mixer_width >> - * as 4K modes can then be supported. >> - */ >> - return drm_add_modes_noedid(connector, dpu_kms->catalog->caps->max_mixer_width, >> + return drm_add_modes_noedid(connector, dpu_kms->catalog->wb->maxlinewidth, >> dev->mode_config.max_height); >> } >> >> >> -- >> 2.49.0 >>
On Thu, May 15, 2025 at 05:48:09PM -0700, Jessica Zhang wrote: > > > On 5/14/2025 5:17 PM, Dmitry Baryshkov wrote: > > On Thu, 15 May 2025 at 02:52, Jessica Zhang > > <jessica.zhang@oss.qualcomm.com> wrote: > > > > > > Since the max mixer width is not a strict hardware limit, use the actual > > > > Is it? What is the actual max width that the mixer can support? > > Hi Dmitry, > > By hardware limit, I mean restrictions based on the size of buffers within > the hardware block itself. > > PINGPONG, DSC encoder, and WB blocks all have buffers, so they do have a max > supported width based on the size of their hardware buffers. On the other > hand, LM doesn't so it isn't necessarily restricted by a max width. > > I can clarify this in the commit message and cover letter. Yes, please. The text above is perfect for the commit message. > > Thanks, > > Jessica Zhang > > > > > > hardware limit (the writeback maxlinewidth) to filter modes. > > > > > > Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> > > > --- > > > drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 9 +-------- > > > 1 file changed, 1 insertion(+), 8 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c > > > index 8ff496082902..0a198896f656 100644 > > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c > > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c > > > @@ -14,14 +14,7 @@ static int dpu_wb_conn_get_modes(struct drm_connector *connector) > > > struct msm_drm_private *priv = dev->dev_private; > > > struct dpu_kms *dpu_kms = to_dpu_kms(priv->kms); > > > > > > - /* > > > - * We should ideally be limiting the modes only to the maxlinewidth but > > > - * on some chipsets this will allow even 4k modes to be added which will > > > - * fail the per SSPP bandwidth checks. So, till we have dual-SSPP support > > > - * and source split support added lets limit the modes based on max_mixer_width > > > - * as 4K modes can then be supported. > > > - */ > > > - return drm_add_modes_noedid(connector, dpu_kms->catalog->caps->max_mixer_width, > > > + return drm_add_modes_noedid(connector, dpu_kms->catalog->wb->maxlinewidth, > > > dev->mode_config.max_height); > > > } > > > > > > > > > -- > > > 2.49.0 > > > >
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c index 8ff496082902..0a198896f656 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c @@ -14,14 +14,7 @@ static int dpu_wb_conn_get_modes(struct drm_connector *connector) struct msm_drm_private *priv = dev->dev_private; struct dpu_kms *dpu_kms = to_dpu_kms(priv->kms); - /* - * We should ideally be limiting the modes only to the maxlinewidth but - * on some chipsets this will allow even 4k modes to be added which will - * fail the per SSPP bandwidth checks. So, till we have dual-SSPP support - * and source split support added lets limit the modes based on max_mixer_width - * as 4K modes can then be supported. - */ - return drm_add_modes_noedid(connector, dpu_kms->catalog->caps->max_mixer_width, + return drm_add_modes_noedid(connector, dpu_kms->catalog->wb->maxlinewidth, dev->mode_config.max_height); }
Since the max mixer width is not a strict hardware limit, use the actual hardware limit (the writeback maxlinewidth) to filter modes. Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> --- drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-)