All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Jonas Karlman <jonas@kwiboo.se>
Cc: Dan Johansen <strit@manjaro.org>,
	Sandy Huang <hjc@rock-chips.com>,
	dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org,
	FUKAUMI Naoki <naoki@radxa.com>,
	Michael Riesch <michael.riesch@wolfvision.net>,
	kernel@pengutronix.de, Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v4 1/4] drm/rockchip: vop: limit maximium resolution to hardware capabilities
Date: Tue, 7 Feb 2023 13:34:18 +0100	[thread overview]
Message-ID: <20230207123418.GF10447@pengutronix.de> (raw)
In-Reply-To: <547c8e94-f2eb-2125-24fe-0dc035f9d6d2@kwiboo.se>

On Tue, Feb 07, 2023 at 10:46:49AM +0000, Jonas Karlman wrote:
> Hi Sascha,
> On 2023-02-07 09:44, Sascha Hauer wrote:
> > The different VOP variants support different maximum resolutions. Reject
> > resolutions that are not supported by a specific variant.
> > 
> > This hasn't been a problem in the upstream driver so far as 1920x1080
> > has been the maximum resolution supported by the HDMI driver and that
> > resolution is supported by all VOP variants. Now with higher resolutions
> > supported in the HDMI driver we have to limit the resolutions to the
> > ones supported by the VOP.
> > 
> > The actual maximum resolutions are taken from the Rockchip downstream
> > Kernel.
> > 
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
> > 
> > Notes:
> >     Changes since v3:
> >     - new patch
> > 
> >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 ++++++++++
> >  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  2 ++
> >  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 31 +++++++++++++++++++++
> >  3 files changed, 48 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > index fa1f4ee6d1950..96b6bd8d17803 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -1174,6 +1174,20 @@ static void vop_crtc_disable_vblank(struct drm_crtc *crtc)
> >  	spin_unlock_irqrestore(&vop->irq_lock, flags);
> >  }
> >  
> > +static enum drm_mode_status vop_crtc_mode_valid(struct drm_crtc *crtc,
> > +						const struct drm_display_mode *mode)
> > +{
> > +	struct vop *vop = to_vop(crtc);
> > +
> > +	if (vop->data->max_xres && mode->hdisplay > vop->data->max_xres)
> > +		return MODE_BAD_HVALUE;
> > +
> > +	if (vop->data->max_yres && mode->vdisplay > vop->data->max_yres)
> > +		return MODE_BAD_VVALUE;
> > +
> > +	return MODE_OK;
> > +}
> > +
> >  static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
> >  				const struct drm_display_mode *mode,
> >  				struct drm_display_mode *adjusted_mode)
> > @@ -1585,6 +1599,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
> >  }
> >  
> >  static const struct drm_crtc_helper_funcs vop_crtc_helper_funcs = {
> > +	.mode_valid = vop_crtc_mode_valid,
> >  	.mode_fixup = vop_crtc_mode_fixup,
> >  	.atomic_check = vop_crtc_atomic_check,
> >  	.atomic_begin = vop_crtc_atomic_begin,
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> > index 8502849833d93..5c4875ca3f270 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> > @@ -225,6 +225,8 @@ struct vop_data {
> >  	const struct vop_win_data *win;
> >  	unsigned int win_size;
> >  	unsigned int lut_size;
> > +	unsigned int max_xres;
> > +	unsigned int max_yres;
> 
> I would suggest using the same struct vop_rect max_input/output as the
> vop2 driver instead of handling this differently between the two.

As it was me who introduced struct vop_rect in the vop2 driver I
probably have to agree ;)

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

WARNING: multiple messages have this Message-ID (diff)
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Jonas Karlman <jonas@kwiboo.se>
Cc: dri-devel@lists.freedesktop.org, Dan Johansen <strit@manjaro.org>,
	Sandy Huang <hjc@rock-chips.com>,
	linux-rockchip@lists.infradead.org,
	FUKAUMI Naoki <naoki@radxa.com>,
	Michael Riesch <michael.riesch@wolfvision.net>,
	kernel@pengutronix.de, Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v4 1/4] drm/rockchip: vop: limit maximium resolution to hardware capabilities
Date: Tue, 7 Feb 2023 13:34:18 +0100	[thread overview]
Message-ID: <20230207123418.GF10447@pengutronix.de> (raw)
In-Reply-To: <547c8e94-f2eb-2125-24fe-0dc035f9d6d2@kwiboo.se>

On Tue, Feb 07, 2023 at 10:46:49AM +0000, Jonas Karlman wrote:
> Hi Sascha,
> On 2023-02-07 09:44, Sascha Hauer wrote:
> > The different VOP variants support different maximum resolutions. Reject
> > resolutions that are not supported by a specific variant.
> > 
> > This hasn't been a problem in the upstream driver so far as 1920x1080
> > has been the maximum resolution supported by the HDMI driver and that
> > resolution is supported by all VOP variants. Now with higher resolutions
> > supported in the HDMI driver we have to limit the resolutions to the
> > ones supported by the VOP.
> > 
> > The actual maximum resolutions are taken from the Rockchip downstream
> > Kernel.
> > 
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
> > 
> > Notes:
> >     Changes since v3:
> >     - new patch
> > 
> >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 ++++++++++
> >  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  2 ++
> >  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 31 +++++++++++++++++++++
> >  3 files changed, 48 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > index fa1f4ee6d1950..96b6bd8d17803 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -1174,6 +1174,20 @@ static void vop_crtc_disable_vblank(struct drm_crtc *crtc)
> >  	spin_unlock_irqrestore(&vop->irq_lock, flags);
> >  }
> >  
> > +static enum drm_mode_status vop_crtc_mode_valid(struct drm_crtc *crtc,
> > +						const struct drm_display_mode *mode)
> > +{
> > +	struct vop *vop = to_vop(crtc);
> > +
> > +	if (vop->data->max_xres && mode->hdisplay > vop->data->max_xres)
> > +		return MODE_BAD_HVALUE;
> > +
> > +	if (vop->data->max_yres && mode->vdisplay > vop->data->max_yres)
> > +		return MODE_BAD_VVALUE;
> > +
> > +	return MODE_OK;
> > +}
> > +
> >  static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
> >  				const struct drm_display_mode *mode,
> >  				struct drm_display_mode *adjusted_mode)
> > @@ -1585,6 +1599,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
> >  }
> >  
> >  static const struct drm_crtc_helper_funcs vop_crtc_helper_funcs = {
> > +	.mode_valid = vop_crtc_mode_valid,
> >  	.mode_fixup = vop_crtc_mode_fixup,
> >  	.atomic_check = vop_crtc_atomic_check,
> >  	.atomic_begin = vop_crtc_atomic_begin,
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> > index 8502849833d93..5c4875ca3f270 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> > @@ -225,6 +225,8 @@ struct vop_data {
> >  	const struct vop_win_data *win;
> >  	unsigned int win_size;
> >  	unsigned int lut_size;
> > +	unsigned int max_xres;
> > +	unsigned int max_yres;
> 
> I would suggest using the same struct vop_rect max_input/output as the
> vop2 driver instead of handling this differently between the two.

As it was me who introduced struct vop_rect in the vop2 driver I
probably have to agree ;)

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2023-02-07 12:34 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-07  8:44 [PATCH v4 0/4] drm/rockchip: dw_hdmi: Add 4k@30 support Sascha Hauer
2023-02-07  8:44 ` Sascha Hauer
2023-02-07  8:44 ` [PATCH v4 1/4] drm/rockchip: vop: limit maximium resolution to hardware capabilities Sascha Hauer
2023-02-07  8:44   ` Sascha Hauer
2023-02-07  9:16   ` Dan Johansen
2023-02-07  9:16     ` Dan Johansen
2023-02-07  9:40     ` Sascha Hauer
2023-02-07  9:40       ` Sascha Hauer
2023-02-07 10:46   ` Jonas Karlman
2023-02-07 10:46     ` Jonas Karlman
2023-02-07 12:34     ` Sascha Hauer [this message]
2023-02-07 12:34       ` Sascha Hauer
2023-02-07  8:44 ` [PATCH v4 2/4] drm/rockchip: dw_hdmi: relax mode_valid hook Sascha Hauer
2023-02-07  8:44   ` Sascha Hauer
2023-02-07  8:44 ` [PATCH v4 3/4] drm/rockchip: dw_hdmi: Add support for 4k@30 resolution Sascha Hauer
2023-02-07  8:44   ` Sascha Hauer
2023-02-07  8:44 ` [PATCH v4 4/4] drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks Sascha Hauer
2023-02-07  8:44   ` Sascha Hauer
2023-02-07 11:01   ` Jonas Karlman
2023-02-07 11:01     ` Jonas Karlman
2023-02-07 12:51     ` Sascha Hauer
2023-02-07 12:51       ` Sascha Hauer
2023-02-07 16:29       ` Jonas Karlman
2023-02-07 16:29         ` Jonas Karlman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230207123418.GF10447@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hjc@rock-chips.com \
    --cc=jonas@kwiboo.se \
    --cc=kernel@pengutronix.de \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=michael.riesch@wolfvision.net \
    --cc=naoki@radxa.com \
    --cc=robin.murphy@arm.com \
    --cc=strit@manjaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.