From patchwork Tue Feb 7 14:41:20 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jyri Sarha X-Patchwork-Id: 9560289 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 D65E2602B1 for ; Tue, 7 Feb 2017 14:42:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C8B1328450 for ; Tue, 7 Feb 2017 14:42:11 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BD91928453; Tue, 7 Feb 2017 14:42:11 +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 43AB028450 for ; Tue, 7 Feb 2017 14:42:11 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4CAE46E063; Tue, 7 Feb 2017 14:42:09 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from fllnx209.ext.ti.com (fllnx209.ext.ti.com [198.47.19.16]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1484A6E063 for ; Tue, 7 Feb 2017 14:42:08 +0000 (UTC) Received: from dflxv15.itg.ti.com ([128.247.5.124]) by fllnx209.ext.ti.com (8.15.1/8.15.1) with ESMTP id v17EfT0Q012009; Tue, 7 Feb 2017 08:41:29 -0600 Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id v17EfO8i027047; Tue, 7 Feb 2017 08:41:24 -0600 Received: from dlep33.itg.ti.com (157.170.170.75) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.294.0; Tue, 7 Feb 2017 08:41:23 -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 v17EfMAE001254; Tue, 7 Feb 2017 08:41:22 -0600 From: Jyri Sarha To: Subject: [PATCH] drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats Date: Tue, 7 Feb 2017 16:41:20 +0200 Message-ID: <1486478480-1966-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, 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; + } + *core_clk = dispc.feat->calc_core_clk(pclk, in_width, in_height, out_width, out_height, mem_to_mem); return 0;