From mboxrd@z Thu Jan 1 00:00:00 1970 From: maxime.ripard@free-electrons.com (Maxime Ripard) Date: Wed, 12 Oct 2016 23:09:28 +0200 Subject: [PATCH] drm/sun4i: Check that the plane coordinates are not negative In-Reply-To: <20161003181840.0cb369d8@bbrezillon> References: <20160930143320.26241-1-maxime.ripard@free-electrons.com> <20160930180826.169e3daf@bbrezillon> <20161003125811.GH5228@lukather> <20161003181840.0cb369d8@bbrezillon> Message-ID: <20161012210928.GB9245@lukather> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Oct 03, 2016 at 06:18:40PM +0200, Boris Brezillon wrote: > On Mon, 3 Oct 2016 14:58:11 +0200 > Maxime Ripard wrote: > > > Hi Boris, > > > > On Fri, Sep 30, 2016 at 06:08:26PM +0200, Boris Brezillon wrote: > > > On Fri, 30 Sep 2016 16:33:20 +0200 > > > Maxime Ripard wrote: > > > > > > > Our planes cannot be set at negative coordinates. Make sure we reject such > > > > configuration. > > > > > > > > Reported-by: Boris Brezillon > > > > Signed-off-by: Maxime Ripard > > > > --- > > > > drivers/gpu/drm/sun4i/sun4i_layer.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/sun4i/sun4i_layer.c > > > > index f0035bf5efea..f5463c4c2cde 100644 > > > > --- a/drivers/gpu/drm/sun4i/sun4i_layer.c > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_layer.c > > > > @@ -29,6 +29,9 @@ struct sun4i_plane_desc { > > > > static int sun4i_backend_layer_atomic_check(struct drm_plane *plane, > > > > struct drm_plane_state *state) > > > > { > > > > + if ((state->crtc_x < 0) || (state->crtc_y < 0)) > > > > + return -EINVAL; > > > > + > > > > > > Hm, I think it's a perfectly valid use case from the DRM framework and > > > DRM user PoV: you may want to place your plane at a negative CRTC > > > offset (which means part of the plane will be hidden). > > > > > > Maybe I'm wrong, but it seems you can support that by adapting the > > > start address of your framebuffer pointer and the layer size. > > > > Indeed, that would probably work. This is even somewhat what we've > > been using to implement the VGA hack we use on the CHIP. > > > > Can you send that patch? > > Actually, Ville suggested a slightly different approach: use the > ->src and ->dst in drm_plane_state. After more tests, it turns out that it's actually simpler than that.... The hardware is able to take negative coordinates. Sorry for the noise, Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Subject: Re: [PATCH] drm/sun4i: Check that the plane coordinates are not negative Date: Wed, 12 Oct 2016 23:09:28 +0200 Message-ID: <20161012210928.GB9245@lukather> References: <20160930143320.26241-1-maxime.ripard@free-electrons.com> <20160930180826.169e3daf@bbrezillon> <20161003125811.GH5228@lukather> <20161003181840.0cb369d8@bbrezillon> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1869470094==" Return-path: Received: from mail.free-electrons.com (down.free-electrons.com [37.187.137.238]) by gabe.freedesktop.org (Postfix) with ESMTP id 938C56E928 for ; Wed, 12 Oct 2016 21:09:31 +0000 (UTC) In-Reply-To: <20161003181840.0cb369d8@bbrezillon> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Boris Brezillon Cc: Daniel Vetter , Chen-Yu Tsai , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org List-Id: dri-devel@lists.freedesktop.org --===============1869470094== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 03, 2016 at 06:18:40PM +0200, Boris Brezillon wrote: > On Mon, 3 Oct 2016 14:58:11 +0200 > Maxime Ripard wrote: >=20 > > Hi Boris, > >=20 > > On Fri, Sep 30, 2016 at 06:08:26PM +0200, Boris Brezillon wrote: > > > On Fri, 30 Sep 2016 16:33:20 +0200 > > > Maxime Ripard wrote: > > > =20 > > > > Our planes cannot be set at negative coordinates. Make sure we reje= ct such > > > > configuration. > > > >=20 > > > > Reported-by: Boris Brezillon > > > > Signed-off-by: Maxime Ripard > > > > --- > > > > drivers/gpu/drm/sun4i/sun4i_layer.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > >=20 > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/= sun4i/sun4i_layer.c > > > > index f0035bf5efea..f5463c4c2cde 100644 > > > > --- a/drivers/gpu/drm/sun4i/sun4i_layer.c > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_layer.c > > > > @@ -29,6 +29,9 @@ struct sun4i_plane_desc { > > > > static int sun4i_backend_layer_atomic_check(struct drm_plane *plan= e, > > > > struct drm_plane_state *state) > > > > { > > > > + if ((state->crtc_x < 0) || (state->crtc_y < 0)) > > > > + return -EINVAL; > > > > + =20 > > >=20 > > > Hm, I think it's a perfectly valid use case from the DRM framework and > > > DRM user PoV: you may want to place your plane at a negative CRTC > > > offset (which means part of the plane will be hidden). > > >=20 > > > Maybe I'm wrong, but it seems you can support that by adapting the > > > start address of your framebuffer pointer and the layer size. =20 > >=20 > > Indeed, that would probably work. This is even somewhat what we've > > been using to implement the VGA hack we use on the CHIP. > >=20 > > Can you send that patch? >=20 > Actually, Ville suggested a slightly different approach: use the > ->src and ->dst in drm_plane_state. After more tests, it turns out that it's actually simpler than that.... The hardware is able to take negative coordinates. Sorry for the noise, Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJX/qaIAAoJEBx+YmzsjxAgZRYP/15juVDIrRYrtie+8S/tCyxJ 66Ym6kPQ23QGwsIrNMpqOM9MyslqE4qLFyeQhVVfuAVtVMG3XuPEgVcvDK0XYrn1 2J/OlBBSUkiF0otza4Lx0AXb4PLf9VNKipQYWjMaeJoLOh+fQ+M8BykyQ2QuDMCe RRAqf8bgnWxrK1LMzrT8pyRtI4clMVvggAN3JtSbnY6zQESc6rbGJZaIyZLFjSps +CVqHnTjb+urrmQB+YLGondoPwz2GqnTnJi6mjR/2JBIdu6GRAw/v7mysn4Q3DRg joS4iquNZFGIJmG4CLDCkYeqjZtH3cwEhhJ1zuky1ECWxES0L4OdKs/AGZ+pDfmr h+nZl2vG1PAzSgSom144SL+FeZgsoLR5O39rQ0PuQzIX9Of8aakwW/iYaNxuTtyZ YtQcruOt+iSJcXDBPqFt+5ZT1mN5WlJ38a4yckKssLkA11Styu2qijXFIauobfiJ +e7ZCUpuwVJiqMldOmgNCQIBjoXhEmLDgwBtAhD6rGI/Awdv5fykhAT6W3bVDT1G iRgNezOghDLM0l1Yh3YcY21smWY075BtaXmr6H5TUwEjILA+bpqSkTJwdF2QLybY Frra4aFlu3f4pfUunNF85yyE7aPJsPAqv3y7fgxH1Tx/uH+7H85gkum62CdAc46Q 6ycY+hqWp90HN53U3rK/ =8NJu -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp-- --===============1869470094== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1869470094==--