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
next prev parent 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