From patchwork Wed Feb 8 14:08:06 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jyri Sarha X-Patchwork-Id: 9562609 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A1C7460434 for ; Wed, 8 Feb 2017 14:08:16 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 93A87284D1 for ; Wed, 8 Feb 2017 14:08:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 87407284F4; Wed, 8 Feb 2017 14:08:16 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 234C6284D1 for ; Wed, 8 Feb 2017 14:08:15 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E54586E8AE; Wed, 8 Feb 2017 14:08:14 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from fllnx210.ext.ti.com (fllnx210.ext.ti.com [198.47.19.17]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5472A6E8AF for ; Wed, 8 Feb 2017 14:08:14 +0000 (UTC) Received: from dflxv15.itg.ti.com ([128.247.5.124]) by fllnx210.ext.ti.com (8.15.1/8.15.1) with ESMTP id v18E8A8J029356; Wed, 8 Feb 2017 08:08:10 -0600 Received: from DFLE73.ent.ti.com (dfle73.ent.ti.com [128.247.5.110]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id v18E8AE6003811; Wed, 8 Feb 2017 08:08:10 -0600 Received: from dlep33.itg.ti.com (157.170.170.75) by DFLE73.ent.ti.com (128.247.5.110) with Microsoft SMTP Server id 14.3.294.0; Wed, 8 Feb 2017 08:08:10 -0600 Received: from jadmar.ti.com (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id v18E88Lq027803; Wed, 8 Feb 2017 08:08:08 -0600 From: Jyri Sarha To: Subject: [PATCH v2] drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats Date: Wed, 8 Feb 2017 16:08:06 +0200 Message-ID: <1486562886-15261-1-git-send-email-jsarha@ti.com> X-Mailer: git-send-email 1.9.1 MIME-Version: 1.0 Cc: tomi.valkeinen@ti.com, Jyri Sarha , laurent.pinchart@ideasonboard.com X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP 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, NV12 color format appears 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 Acked-by: Laurent Pinchart --- Chnages since first version: - "color_mode_to_bpp(color_mode) > 8" -> "color_mode != OMAP_DSS_COLOR_NV12" - commit message and comment updated too - improve error print 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..d956e626 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 != OMAP_DSS_COLOR_NV12) { + /* + * 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, NV12 color format appears 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, too much downscaling (x-decimation factor %d > 4)", *decim_x); + + return -EINVAL; + } + *core_clk = dispc.feat->calc_core_clk(pclk, in_width, in_height, out_width, out_height, mem_to_mem); return 0;