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 32C86C4332F for ; Mon, 20 Dec 2021 03:13:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237322AbhLTDNx (ORCPT ); Sun, 19 Dec 2021 22:13:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237313AbhLTDNv (ORCPT ); Sun, 19 Dec 2021 22:13:51 -0500 Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2700DC06173F for ; Sun, 19 Dec 2021 19:13:51 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id k2so13671537lji.4 for ; Sun, 19 Dec 2021 19:13:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mF5wYxPSqdxf3ndDaiNpjYh7EExZO+92B2rlWd4Hn/w=; b=H/hN9JtCLykDVNHSsTlSCCQbC1jeDpVXuzoQfGiqcOKtC70LixZK3hc4x9DnBgZyYy 1lLhpZ4uboMNb8eVCBGXv+DAuWFNdo9AJq8iZMJAPl7xxsDE0dNGDqyySE0w4YJ1yLgU QaK+fHHXI5tJEgGPBjGRAbFYXb32mQxTV2jCQ= 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:content-transfer-encoding; bh=mF5wYxPSqdxf3ndDaiNpjYh7EExZO+92B2rlWd4Hn/w=; b=XrQoi1LJaRkP9Udvzl78m1YkBnuC3Q8PZp7xvvszLWCKB0c+l1MpAHMBflKQCQY8UL WGj41M70l06SJeSY7QaQ+mp46LBV+vBN7nQ2kN9BhKNWvbKFb1HN5Ku+0ZLRDyPCjnbi is3GY8tgNsXlOey77EupqSFKGeqBEnQD8RuuNyQu6LBJkhQHXQtR4MGkevLvMzqQSOB7 S/vn0Dcwor2ZLaCIAkDl6baD3o6/+GYw7jNVsOxSHkQ0P6UnTwapB1r5P23orUnBnbIC YkEwtW+pzNQevWB/yIUJrpoWgXaeTL3qVHLWCLH9jsxpoOAEeDp5sve9xNbLMn4UGpu5 07iw== X-Gm-Message-State: AOAM533Ra0Jayv1kqAt+8GCMsq8zG5/3PIga4Ygz35X9C6FyfOWbnewp aglLr3jW5cnVDZ0oxjDC2q1xkY/TqY8HOR9tRD8UwA== X-Google-Smtp-Source: ABdhPJxunl6swmvnYR15PB/3dHuBiP42NrBlmSpRdVW8fHz4URsaEzdHg45SD9YGC11Q7qsqGbLcNVjoVI+7j1Re0fg= X-Received: by 2002:a2e:a54c:: with SMTP id e12mr13210214ljn.457.1639970029235; Sun, 19 Dec 2021 19:13:49 -0800 (PST) MIME-Version: 1.0 References: <20211106183802.893285-1-aford173@gmail.com> <718f7f6d6cd564d031c1963f1590c62d549ae725.camel@ndufresne.ca> <8db00a4b6faa99c940d9bc86e17161eb0db5efe3.camel@ndufresne.ca> <7f94eaacfddb8c5434c17f1e069ea87a17657ce9.camel@ndufresne.ca> <8438070708d16c34c0f79aba19e67fa343adb169.camel@ndufresne.ca> <41f0e00cf5e57668b643b096e6bb69c67635c540.camel@ndufresne.ca> In-Reply-To: <41f0e00cf5e57668b643b096e6bb69c67635c540.camel@ndufresne.ca> From: Chen-Yu Tsai Date: Mon, 20 Dec 2021 11:13:37 +0800 Message-ID: Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs To: Nicolas Dufresne Cc: Tim Harvey , Adam Ford , Ezequiel Garcia , linux-media , Schrempf Frieder , Marek Vasut , Jagan Teki , Adam Ford-BE , cstevens@beaconembedded.com, Philipp Zabel , Mauro Carvalho Chehab , Rob Herring , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Greg Kroah-Hartman , Heiko Stuebner , Lucas Stach , Joakim Zhang , Alice Guo , Peng Fan , "open list:HANTRO VPU CODEC DRIVER" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , open list , "open list:STAGING SUBSYSTEM" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 18, 2021 at 1:52 AM Nicolas Dufresne wro= te: > Le vendredi 17 d=C3=A9cembre 2021 =C3=A0 09:26 -0800, Tim Harvey a =C3=A9= crit : > > I'm not clear if anyone is working on IMX8MM VPU H1 support. You had > > mentioned that some support [1] and [2] can be derived from the RK3288 > > using the Google ChromeOS method (a v4l2 plugin that simulates in > > userspace a stateful encoder). I'm not sure if this is worth pursuing > > if others are working on stateless encode support in kernel and > > gstreamer. > > My colleagues started last week the project of crafting mainline stateles= s > encoder uAPI. This is too early. In older project, we have had good succe= ss with > the emulated stateful encoder. It is of course quite limited, but works i= n > gstreamer, ffmpeg and chromium. It is also likely safer compared to the v= endor > provided driver. If people still want to play with the old emulated stateful encoder, there is a forward-ported version in the ChromeOS v5.10 kernel now. Note that RK3288 (H1) support is untested. Also, RK3288 and RK3399 require different versions of the userspace plugin. And the RK3288 version might require some updates to add SELECTION API support. ChenYu