From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: [PATCH] drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats Date: Wed, 8 Feb 2017 13:49:44 +0200 Message-ID: <664df7bf-03e9-1554-d697-3a546538a90c@ti.com> References: <1486478480-1966-1-git-send-email-jsarha@ti.com> <3081631.2jIF2WKCqd@avalon> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1160744139==" Return-path: Received: from fllnx209.ext.ti.com (fllnx209.ext.ti.com [198.47.19.16]) by gabe.freedesktop.org (Postfix) with ESMTPS id A50EF89C83 for ; Wed, 8 Feb 2017 11:50:30 +0000 (UTC) In-Reply-To: <3081631.2jIF2WKCqd@avalon> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Laurent Pinchart , Jyri Sarha Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1160744139== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mav3M4ebnE0tQt9jhhxOM3d5eDFoKank9" --mav3M4ebnE0tQt9jhhxOM3d5eDFoKank9 Content-Type: multipart/mixed; boundary="xNv1OECueg8xk1b0QvmnQOGhmHLdesH71"; protected-headers="v1" From: Tomi Valkeinen To: Laurent Pinchart , Jyri Sarha Cc: dri-devel@lists.freedesktop.org, airlied@linux.ie, daniel@ffwll.ch Message-ID: <664df7bf-03e9-1554-d697-3a546538a90c@ti.com> Subject: Re: [PATCH] drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats References: <1486478480-1966-1-git-send-email-jsarha@ti.com> <3081631.2jIF2WKCqd@avalon> In-Reply-To: <3081631.2jIF2WKCqd@avalon> --xNv1OECueg8xk1b0QvmnQOGhmHLdesH71 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/02/17 13:25, Laurent Pinchart wrote: > Hi Jyri, >=20 > Thank you for the patch. >=20 > On Tuesday 07 Feb 2017 16:41:20 Jyri Sarha wrote: >> Let's disable all scaling that requires horizontal decimation with >> higher factor than 4, until we have better estimates of what we can >> and can not do. However, 1 byte per pixel color format appear to work >> Ok with all decimation factors. >> >> When decimating horizontally by more that 4 the dss is not able to >> fetch the data in burst mode. When this happens it is hard to tell if >> there enough bandwidth. Despite what theory says this appears to be >> true also for 16-bit color formats. >> >> Signed-off-by: Jyri Sarha >> --- >> drivers/gpu/drm/omapdrm/dss/dispc.c | 19 +++++++++++++++++++ >> 1 file changed, 19 insertions(+) >> >> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c >> b/drivers/gpu/drm/omapdrm/dss/dispc.c index 5554b72..61daef6 100644 >> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c >> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c >> @@ -2506,6 +2506,25 @@ static int dispc_ovl_calc_scaling_44xx(unsigned= long >> pclk, unsigned long lclk, return -EINVAL; >> } >> >> + if (*decim_x > 4 && color_mode_to_bpp(color_mode) > 8) { >> + /* >> + Let's disable all scaling that requires horizontal >> + decimation with higher factor than 4, until we have >> + better estimates of what we can and can not >> + do. However, 1 byte per pixel color format appear to >> + work Ok with all decimation factors. >> + >> + When decimating horizontally by more that 4 the dss >> + is not able to fetch the data in burst mode. When >> + this happens it is hard to tell if there enough >> + bandwidth. Despite what theory says this appears to >> + be true also for 16-bit color formats. >> + */ >> + DSSERR("Not enough bandwidth (x-decimation factor %d > 4)", >> + *decim_x); >> + return -EINVAL; >=20 > This needs to be validated during the atomic check phase to avoid failu= res at=20 > commit time that are much harder to handle properly. I agree, but that requires rewriting half of the dispc driver... This and the few earlier ones from Jyri are quick fixes to major issues we've found. Tomi --xNv1OECueg8xk1b0QvmnQOGhmHLdesH71-- --mav3M4ebnE0tQt9jhhxOM3d5eDFoKank9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYmwXYAAoJEPo9qoy8lh71/qYP/A8fRwpdE4SG1jk6DLsBUMde rP7UrN1pEoXnHtugg5yqs5kmmqv4lzrL72+HM6v1cgFMrlWTBY4ndK7b/wbGI7AK Ij8t3VvtbENxk6K75/puxUyCqochHLlivSDdDsUndrUoOw5usngO/qEbIR98vbgI auOJuXJK+nunNAmanANkJwMg3b3rv5B6telDhcwf0SXA7nYxsKmFhZT/DSSXqEld u5D4MaEbDMT+MJlw0Aws/IXdoNxNb4CjgXcvYKcIVPx9/luOhgZ9Qfuo7f+/HET2 vQkqUVgWlQCmEEJZxSNAuwyxvBcKps7zhAvfJkeJBgwPMc8ANPqW10mKMwpECO6q aBflXoDlg7SVGBJWtEilCMUBvful49IBp9ilaoibp+lUSWuK0aOvpzpw8+Hm4uos TBVIy9Wk5crt307Espr7AhYYO1vxokDolc0OfDuBdolY6v2nsEdFVMlLrEhG+oJJ kPHf8MbwThO73TTw1ciyQaTZH6blG1R1KIZqolBJjknR0uGPaKhxaftF7TX88mXf R7rnw/SqwQ3RqcOd4UIc8/BlfMpg9+r18/c+TTq48rFr1dxcvazSrlDcXWbrfizv 4vwV2exbCKwrmXutOzOLnu/qkGS0GV0CtdGYmkZVtBGe2f4BMecJawAiGBAWlHDu XC443WyI4hdU6qbuhkAp =ol5i -----END PGP SIGNATURE----- --mav3M4ebnE0tQt9jhhxOM3d5eDFoKank9-- --===============1160744139== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1160744139==--