Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0306BC433FE for ; Wed, 1 Dec 2021 18:16:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352187AbhLASUH (ORCPT ); Wed, 1 Dec 2021 13:20:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42262 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244383AbhLASTv (ORCPT ); Wed, 1 Dec 2021 13:19:51 -0500 Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4CA9EC061574 for ; Wed, 1 Dec 2021 10:16:30 -0800 (PST) Received: by mail-pj1-x102e.google.com with SMTP id np6-20020a17090b4c4600b001a90b011e06so2345548pjb.5 for ; Wed, 01 Dec 2021 10:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gateworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Fjo/oLhM/GI33DECaidoRno6lOPTrQDXq4YeW1u3XI=; b=Gy/mI/syDjgmJ/Dy5HSB0lekRFIu1fZjXrSHJRAyRpEjIvsMYeuD7jd9Gl+/dViRyQ bX7H/U8ylCShghMTxCO2moMoFwVRephY825eJHoHYIsCBrCSTGr5lkGv0EVJCxBJCTjC XKWTHHeI4L0kX6Cm8I0VJGnBecIMJN05ZjnxWJF4pIjeSiGX31iD106ZbDpbwRBH3ncL GQspUzeaq+6ISOEZHY9XlWQRXZMBJvMLiLqaYwPf9HtglHgZUBhMgSXHJZwlcKZdu2JF kvW6WGURB6KwscUjDn/Y5mtcbI6S1JQUSwK+OOMpZYnpnAwCy3Qgvhf8sAIwj+oy1ks2 C3Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Fjo/oLhM/GI33DECaidoRno6lOPTrQDXq4YeW1u3XI=; b=gswiNoa9yPO2wNz+zMuL5C7EDUf15DgUUPt+l4kj9srR+hwxEY3H/Iemc0vecP2kwL 0yQJNHB9fcHLi/jhT3OKOdagdm7ipPF0w2cIsKsaOH7cIZrianKTNwMqaVs8pHZVGOPe JSfH6qVkW50F2Gbye4sjbPt+ZmVev3ojJOuCBEkEdAMleOn/qhOGUfC0gYTtCVSDxj5s 0BSxxjNs10WMc5EWYVpFJ1Vat40tpC8r0+reeC6bSn8lzMS0OpvJY59x043esXiSnVP9 Y08XLCgYyR95/gEB+aXFVJo8ww1ky8u0qhcwH0S0Fm7wa5bo/dhaUgABOIfUcYdeN+IC I1dA== X-Gm-Message-State: AOAM5313UrTmBFxiApYm7TulI/d8mAAzpkYgFO0JmWJ+il8/bIfdym2f lvAuGdS474qfIO871VYvjpGOaoAYDv+y2R+N3Ldjbw== X-Google-Smtp-Source: ABdhPJwttCSPFnI/f0Y+73jbxauzbId1+8+EbhmZWwrFdssLOLUTnHuIDjdXa+sBopTO83KHL5/G+HdxFmuxHV6QOCE= X-Received: by 2002:a17:90b:33d0:: with SMTP id lk16mr9513215pjb.66.1638382589692; Wed, 01 Dec 2021 10:16:29 -0800 (PST) MIME-Version: 1.0 References: <20211201013329.15875-1-aford173@gmail.com> <7216bc863d89faa9fdc5cd8d44c319f7a6d88159.camel@pengutronix.de> In-Reply-To: <7216bc863d89faa9fdc5cd8d44c319f7a6d88159.camel@pengutronix.de> From: Tim Harvey Date: Wed, 1 Dec 2021 10:16:18 -0800 Message-ID: Subject: Re: [RFC V2 0/2] arm64: imx8mm: Enable Hantro VPUs To: Lucas Stach Cc: Adam Ford , linux-media , Ezequiel Garcia , Hans Verkuil , Nicolas Dufresne , Adam Ford-BE , Rob Herring , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Philipp Zabel , Mauro Carvalho Chehab , Greg Kroah-Hartman , Device Tree Mailing List , Linux ARM Mailing List , open list , "open list:HANTRO VPU CODEC DRIVER" , "open list:STAGING SUBSYSTEM" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 1, 2021 at 9:32 AM Lucas Stach wrote: > > Hi Tim, > > Am Mittwoch, dem 01.12.2021 um 09:23 -0800 schrieb Tim Harvey: > > On Tue, Nov 30, 2021 at 5:33 PM Adam Ford wrote: > > > > > > The i.MX8M has two Hantro video decoders, called G1 and G2 which appear > > > to be related to the video decoders used on the i.MX8MQ, but because of > > > how the Mini handles the power domains, the VPU driver does not need to > > > handle all the functions, nor does it support the post-processor, > > > so a new compatible flag is required. > > > > > > With the suggestion from Hans Verkuil, I was able to get the G2 splat to go away > > > with changes to FORCE_MAX_ZONEORDER, but I found I could also set cma=512M, however > > > it's unclear to me if that's an acceptable alternative. > > > > > > At the suggestion of Ezequiel Garcia and Nicolas Dufresne I have some > > > results from Fluster. However, the G2 VPU appears to fail most tests. > > > > > > ./fluster.py run -dGStreamer-H.264-V4L2SL-Gst1.0 > > > Ran 90/135 tests successfully in 76.431 secs > > > > > > ./fluster.py run -d GStreamer-VP8-V4L2SL-Gst1.0 > > > Ran 55/61 tests successfully in 21.454 secs > > > > > > ./fluster.py run -d GStreamer-VP9-V4L2SL-Gst1.0 > > > Ran 0/303 tests successfully in 20.016 secs > > > > > > Each day seems to show more and more G2 submissions, and gstreamer seems to be > > > still working on the VP9, so I am not sure if I should drop G2 as well. > > > > > > > > > Adam Ford (2): > > > media: hantro: Add support for i.MX8M Mini > > > arm64: dts: imx8mm: Enable VPU-G1 and VPU-G2 > > > > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 41 +++++++++++++++ > > > drivers/staging/media/hantro/hantro_drv.c | 2 + > > > drivers/staging/media/hantro/hantro_hw.h | 2 + > > > drivers/staging/media/hantro/imx8m_vpu_hw.c | 57 +++++++++++++++++++++ > > > 4 files changed, 102 insertions(+) > > > > > > > Adam, > > > > That's for the patches! > > > > I tested just this series on top of v5.16-rc3 on an > > imx8mm-venice-gw73xx-0x and found that if I loop fluster I can end up > > getting a hang within 10 to 15 mins or so when imx8m_blk_ctrl_power_on > > is called for VPUMIX pd : > > while [ 1 ]; do uptime; ./fluster.py run -d GStreamer-VP8-V4L2SL-Gst1.0; done > > ... > > [ 618.838436] imx-pgc imx-pgc-domain.6: failed to command PGC > > [ 618.844407] imx8m-blk-ctrl 38330000.blk-ctrl: failed to power up bus domain > > > > I added prints in imx_pgc_power_{up,down} and > > imx8m_blk_ctrl_power_{on,off} to get some more context > > ... > > Ran 55/61 tests successfully in 8.685 secs > > 17:16:34 up 17 min, 0 users, load average: 3.97, 2.11, 0.93 > > ******************************************************************************** > > ******************** > > Running test suite VP8-TEST-VECTORS with decoder GStreamer-VP8-V4L2SL-Gst1.0 > > Using 4 parallel job(s) > > ******************************************************************************** > > ******************** > > > > [TEST SUITE ] (DECODER ) TEST VECTOR ... R > > ESULT > > ---------------------------------------------------------------------- > > [ 1023.114806] imx8m_blk_ctrl_power_on vpublk-g1 > > [ 1023.119669] imx_pgc_power_up vpumix > > [ 1023.124307] imx-pgc imx-pgc-domain.6: failed to command PGC > > [ 1023.130006] imx8m-blk-ctrl 38330000.blk-ctrl: failed to power up bus domain > > > > While this wouldn't be an issue with this series it does indicate we > > still have something racy in blk-ctrl. Can you reproduce this (and if > > not what kernel are you based on)? Perhaps you or Lucas have some > > ideas? > > > Did you have "[PATCH] soc: imx: gpcv2: Synchronously suspend MIX > domains" applied when running those tests? It has only recently been > picked up by Shawn and may have an influence on the bus domain > behavior. > Lucas, Good point. I did have that originally before I started pruning down to the bare minimum to reproduce the issue. I added it back and now I have the following: arm64: dts: imx8mm: Enable VPU-G1 and VPU-G2 media: hantro: Add support for i.MX8M Mini soc: imx: gpcv2: keep i.MX8MM VPU-H1 bus clock active soc: imx: gpcv2: Synchronously suspend MIX domains Linux 5.16-rc3 Here's the latest with that patch: ... [VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0) vp80-00-comprehensive-007 ... Success [ 316.632373] imx8m_blk_ctrl_power_off vpublk-g1 [ 316.636908] imx_pgc_power_down vpu-g1 [ 316.640983] imx_pgc_power_down vpumix [ 316.756869] imx8m_blk_ctrl_power_on vpublk-g1 [ 316.761360] imx_pgc_power_up vpumix [ 316.765985] imx-pgc imx-pgc-domain.6: failed to command PGC [ 316.772743] imx8m-blk-ctrl 38330000.blk-ctrl: failed to power up bus domain ^^^ hang I believe there is some sort of simple test I can do to power the gpu up/down to test as well but not clear what that is. Tim