From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 358BB2745C for ; Fri, 16 Jan 2026 16:49:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.11.138.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768582194; cv=none; b=VCEUuup6oEvu1ekwTCB2xojwYkAG5nfM6/CkpmlgReBF5peuS1ED0HMSyhw8xjotxdZPdbVuiDU17jGw3cYAHW/tzcCS3u9rz2hpLWS4T2xRYrF8A5RJL1bjarmcjMKJh1kJXB//7DMb+rYmlZII3t6C1X47e/8XEyA/3nuKjb8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768582194; c=relaxed/simple; bh=GkDKjDlxFtXb0NUjFiF2mLsnPMUeYSRT3wIGGP7h7fw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nTV9yGHDpS5BtgsR45CnIfdJtX8Um0etgVVTPsdGKf8Ecq45laD56lxq0FnVYC8YrDSC9XHk8Mbklc3ckJiMsaZt5BPQ3hMXGAxd87H9LzfL1njCLJrLY3tcSaFN7UNu7tOl+V/ax5d08lHQXDqkX9eO1VaXh6aqoqS5AXcAVZQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sntech.de; spf=pass smtp.mailfrom=sntech.de; dkim=pass (2048-bit key) header.d=sntech.de header.i=@sntech.de header.b=ChRtAKmF; arc=none smtp.client-ip=185.11.138.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sntech.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sntech.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sntech.de header.i=@sntech.de header.b="ChRtAKmF" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sntech.de; s=gloria202408; h=Content-Type:Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Reply-To; bh=yI2XYSwTvVhb9DCV7BJIh+Gsz4vYaSmf6hvMKZExTCo=; b=ChRtAKmFPFgjEj2MJUr5lwxoqR 6KHtYVPzSVyn9bFz7rHB0lcpr2sYi5ewutGrLY8qE1juhIvHX/67F94QnlB3wraAH2jbNuNpFg5au IUqv1YSIaYrLzsoah74DeYeyC1CmUwzF7yH9YPP5HtAeBisxSpCTqBnPNmEgNIBOKicSlpmLu1O1y FY2kEU9Bf++OXlUxM8zRYYOKoDsWM6GO0ZOI2Lb3Vm1/at800F8Mj1DJpFupJQn7TYh6twB4eg4a4 vkvQRrNNTtUj5LtTcg3HNgxs/XmdZeQ5E6rbcPfIDuWwnTjBPBXkMzka6qXaS9py9cT8jz2tJ3N08 kyeM9y5w==; Received: from i53875a97.versanet.de ([83.135.90.151] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vgn0l-002eXq-JT; Fri, 16 Jan 2026 17:49:24 +0100 From: Heiko =?UTF-8?B?U3TDvGJuZXI=?= To: Andy Yan Cc: hjc@rock-chips.com, mripard@kernel.org, maarten.lankhorst@linux.intel.com, tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, Andy Yan Subject: Re: [PATCH] drm/rockchip: vop2: Add mode valid callback for crtc Date: Fri, 16 Jan 2026 17:49:23 +0100 Message-ID: <6509513.iIbC2pHGDl@diego> In-Reply-To: <20260116005953.286225-1-andyshrk@163.com> References: <20260116005953.286225-1-andyshrk@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Andy, Am Freitag, 16. Januar 2026, 01:59:49 Mitteleurop=C3=A4ische Normalzeit sch= rieb Andy Yan: > From: Andy Yan when resending an unmodified patch, please mark the subject as [PATCH RESEND] .... > Filter the mode that can't output by the crtc. In commit 8e140cb60270 ("drm/rockchip: vop: limit maximum resolution to hardware capabilities") which introduced the similar check on VOP(1), we had additional information, in that the VOP1 hardware does not have an output height limit. Is the same true for VOP2 ? Because then I'd like to extend the commit description to something like: =3D=3D=3D=3D=3D=3D=3D 8< =3D=3D=3D=3D=3D=3D=3D The different VOP variants support different maximum resolutions. Reject resolutions that are not supported by a specific variant. Only the output width is checked because the hardware itself does not have a hard output height limit. =3D=3D=3D=3D=3D=3D=3D 8< =3D=3D=3D=3D=3D=3D=3D Because when someone sees the code later they might ask why the height is not checked, so having that in the commit description allows us all to remember why the check is this specific way :-) Thanks Heiko > Signed-off-by: Andy Yan > --- > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) >=20 > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/d= rm/rockchip/rockchip_drm_vop2.c > index 498df0ce4680..74fba29bfff3 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > @@ -1439,6 +1439,17 @@ static void vop2_crtc_disable_vblank(struct drm_cr= tc *crtc) > vop2_crtc_disable_irq(vp, VP_INT_FS_FIELD); > } > =20 > +static enum drm_mode_status vop2_crtc_mode_valid(struct drm_crtc *crtc, > + const struct drm_display_mode *mode) > +{ > + struct vop2_video_port *vp =3D to_vop2_video_port(crtc); > + > + if (mode->hdisplay > vp->data->max_output.width) > + return MODE_BAD_HVALUE; > + > + return MODE_OK; > +} > + > static bool vop2_crtc_mode_fixup(struct drm_crtc *crtc, > const struct drm_display_mode *mode, > struct drm_display_mode *adj_mode) > @@ -1884,6 +1895,7 @@ static void vop2_crtc_atomic_flush(struct drm_crtc = *crtc, > =20 > static const struct drm_crtc_helper_funcs vop2_crtc_helper_funcs =3D { > .mode_fixup =3D vop2_crtc_mode_fixup, > + .mode_valid =3D vop2_crtc_mode_valid, > .atomic_check =3D vop2_crtc_atomic_check, > .atomic_begin =3D vop2_crtc_atomic_begin, > .atomic_flush =3D vop2_crtc_atomic_flush, >=20