From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92CE0C433DB for ; Mon, 15 Feb 2021 10:16:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 46F8C64E05 for ; Mon, 15 Feb 2021 10:16:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230098AbhBOKQM (ORCPT ); Mon, 15 Feb 2021 05:16:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229989AbhBOKQG (ORCPT ); Mon, 15 Feb 2021 05:16:06 -0500 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35301C061756 for ; Mon, 15 Feb 2021 02:15:26 -0800 (PST) Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lBauX-00027Q-0k; Mon, 15 Feb 2021 11:15:21 +0100 Message-ID: <10bfc6f5aaa02ad5858186ccee1894424fc0dd39.camel@pengutronix.de> Subject: Re: [BUG REPORT] media: coda: mpeg4 decode corruption on i.MX6qp only From: Lucas Stach To: Sven Van Asbroeck , Philipp Zabel Cc: Nicolas Dufresne , Mauro Carvalho Chehab , Adrian Ratiu , Fabio Estevam , linux-media , Linux Kernel Mailing List Date: Mon, 15 Feb 2021 11:15:19 +0100 In-Reply-To: References: <20210203163348.30686-1-TheSven73@gmail.com> <804285cff81878a2c188d1b823182114f891ca38.camel@ndufresne.ca> <20210211143233.GA1360@pengutronix.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3 (3.38.3-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sven, Am Freitag, dem 12.02.2021 um 18:52 -0500 schrieb Sven Van Asbroeck: > Philipp, Fabio, > > I was able to verify that the PREs do indeed overrun their allocated ocram area. > > Section 38.5.1 of the iMX6QuadPlus manual indicates the ocram size > required: width(pixels) x 8 lines x 4 bytes. For 2048 pixels max, this > comes to 64K. This is what the PRE driver allocates. So far, so good. > > The trouble starts when we're displaying a section of a much wider > bitmap. This happens in X when using two displays. e.g.: > HDMI 1920x1088 > LVDS 1280x800 > X bitmap 3200x1088, left side displayed on HDMI, right side on LVDS. > > In such a case, the stride will be much larger than the width of a > display scanline. Urgh, bad tested corner case. > This is where things start to go very wrong. > > I found that the ocram area used by the PREs increases with the > stride. I experimentally found a formula: > ocam_used = display_widthx8x4 + (bitmap_width-display_width)x7x4 > > As the stride increases, the PRE eventually overruns the ocram and... > ends up in the "ocram aliased" area, where it overwrites the ocram in > use by the vpu/coda ! > > I could not find any PRE register setting that changes the used ocram area. There is no such setting. The PRE always prefetches a doublebuffer of 2x4 scanlines and the scanline size is defined by the store engine pitch. The straight forward way to fix this would be to just disable the PRE when the stride is getting too large, which might not work well with all userspace requirements, as it effectively disables the ability to scan GPU tiled surfaces when the stride is getting too large. I'm not sure if this works in practice, as the PRG address rewriting might make this harder than it seems, but on could probably try to rewrite the prefetch start address, input pitch, input width/height and store pitch of the PRE settings to cover only the area used by the the CRTC to reduce OCRAM requirements. Regards, Lucas