Linux-Rockchip Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org
Cc: Sandy Huang <hjc@rock-chips.com>,
	linux-rockchip@lists.infradead.org,
	Michael Riesch <michael.riesch@wolfvision.net>,
	kernel@pengutronix.de, Robin Murphy <robin.murphy@arm.com>,
	Dan Johansen <strit@manjaro.org>, FUKAUMI Naoki <naoki@radxa.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Sascha Hauer <s.hauer@pengutronix.de>
Subject: Re: [PATCH v6 1/4] drm/rockchip: vop: limit maximium resolution to hardware capabilities
Date: Tue, 07 Mar 2023 23:21:16 +0100	[thread overview]
Message-ID: <839117967.0ifERbkFSE@diego> (raw)
In-Reply-To: <20230216102447.582905-2-s.hauer@pengutronix.de>

Hi Sascha,

Am Donnerstag, 16. Februar 2023, 11:24:44 CET schrieb Sascha Hauer:
> 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 v5:
>     - fix wrong check height vs. width
>     
>     Changes since v4:
>     - Use struct vop_rect for storing resolution
>     
>     Changes since v3:
>     - new patch
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c  | 15 +++++++++++++++
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h  |  6 ++++++
>  drivers/gpu/drm/rockchip/rockchip_drm_vop2.h |  5 -----
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c  | 18 ++++++++++++++++++
>  4 files changed, 39 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index fa1f4ee6d1950..40c688529d44e 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_output.width && mode->hdisplay > vop->data->max_output.width)
> +		return MODE_BAD_HVALUE;
> +
> +	if (vop->data->max_output.height && mode->vdisplay > vop->data->max_output.height)
> +		return MODE_BAD_VVALUE;
> +
> +	return MODE_OK;
> +}

I'm very much in favor of codifying the possible resolutions. Hopefully
this will also enable better vop-selection down the road.

But ...

The above does break the px30-minievb display.
While the px30 TRM does say it supports a 1920x1080 resolution only, the
px30-minievb comes with a 720x1280 DSI display and normally runs just
fine with it.

Looking at the vendor-code [0], it seems they only seem to check for the
hvalue. Looking deeper, the height-check was present in the beginning [1],
but then was removed later on.

Looking a bit more, I find [2] which says that
	"Actually vop hardware has no output height limit"

I re-checked this on both px30+dsi and rock64+1080p-hdmi and with
> +	if (vop->data->max_output.height && mode->vdisplay > vop->data->max_output.height)
> +		return MODE_BAD_VVALUE;
line gone, rock64 is still happy and the px30 works correctly again.

So, do you see an issue with removing the output-height check?


Heiko


[0] https://github.com/rockchip-linux/kernel/blob/develop-4.4/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#L2446
[1] https://github.com/rockchip-linux/kernel/commit/7e3e0c5e2eb16901ab5dce1cb981e1ac58fe42c6
[2] https://github.com/rockchip-linux/kernel/commit/28c41da2693fe448aeda7c03070c376290b93805



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

  reply	other threads:[~2023-03-07 22:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-16 10:24 [PATCH v6 0/4] drm/rockchip: dw_hdmi: Add 4k@30 support Sascha Hauer
2023-02-16 10:24 ` [PATCH v6 1/4] drm/rockchip: vop: limit maximium resolution to hardware capabilities Sascha Hauer
2023-03-07 22:21   ` Heiko Stübner [this message]
2023-03-08 10:06     ` Sascha Hauer
2023-02-16 10:24 ` [PATCH v6 2/4] drm/rockchip: dw_hdmi: relax mode_valid hook Sascha Hauer
2023-02-16 10:24 ` [PATCH v6 3/4] drm/rockchip: dw_hdmi: Add support for 4k@30 resolution Sascha Hauer
2023-02-16 10:24 ` [PATCH v6 4/4] drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks Sascha Hauer
2023-03-06 13:31 ` [PATCH v6 0/4] drm/rockchip: dw_hdmi: Add 4k@30 support Sascha Hauer
2023-03-09  1:07 ` Heiko Stuebner

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=839117967.0ifERbkFSE@diego \
    --to=heiko@sntech.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hjc@rock-chips.com \
    --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=s.hauer@pengutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox