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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63DAFC433EF for ; Tue, 5 Oct 2021 06:13:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3CFB861139 for ; Tue, 5 Oct 2021 06:13:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232492AbhJEGPf (ORCPT ); Tue, 5 Oct 2021 02:15:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41474 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232346AbhJEGPf (ORCPT ); Tue, 5 Oct 2021 02:15:35 -0400 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 27F3BC061749 for ; Mon, 4 Oct 2021 23:13:45 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id j10-20020a1c230a000000b0030d523b6693so1923646wmj.2 for ; Mon, 04 Oct 2021 23:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j0gdpa7QFj6JEtxCL0CAkQhhWBN7lylbx+e4M1Vsb7o=; b=VSMlRsoRvLnUs/myw52hG6menRckaTpfD/sc8jEUT0jyW5v3NKcZHtBWqWykMD5xpQ mFu4QMfCZ9RQ9gHcJ9QFLXWCDQioaZGzCLDj2r3q5cK6Bu/YSHR3txAyRLJylC+4AKLR g55PRWGvVR45Df7AB215vAr2ryBVF9UVBNPf2zz3lLIf+C6rBUlNftwFmbW96vlrWdTq hCwjH6VQ0tr1DWzEEMjTxsoihIPbk377R7bOZfQPdhVWl10LaMlIoj6UaOF+EZtODQyV LwPycfL7e8vNKveuzSRdCDYLP9xDWVdJMnpBwUvvLfFs+gIqIOclKdHk3GCXIwYTLdoB y/FQ== 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=j0gdpa7QFj6JEtxCL0CAkQhhWBN7lylbx+e4M1Vsb7o=; b=QuXx5LRumWG/TDcmYXc+eVp/WDqnqxsk2dM/xU/TZbjRt7pYNBREb/+gAUM1K6vwJo JtYErrxoosLnZJiGBAhOqHL4cv5pCfT5DXRBeFUn9gxSsp8gYQQb24ELfVJkdtuoPV6p RsMlmufPrxBPuLcx0WG2Vba/tuqLUFF4qb1KJOkHTQU60vw2izc6sJ5aq5QWueuiAhA5 VwNU6BDMSkobCwMV+a4JSITRphnh+OkWwpNNJTb4N5mW5V6o5C+8cEYaB5s6+mMVL1xG r7ONxuzTu6Ljz9fyKxsj3Pwt8tO8UgQrr2cv+ZJnwhJkU3tJGlnC+kf5tsXDt+Hgf39x iaMw== X-Gm-Message-State: AOAM531aWxwKDdtBrIaUIpqn2RtB8pGh7WNPNLHMsFOLdNrR7NVgImRN WqxxKzU2arpYY9D4vn8q/8D+bm308l3GDC5+YD3UzA== X-Google-Smtp-Source: ABdhPJwvzH04gXiNcjIVGCd6bQFa+g35hTdKUKGTFBM4UFTMR14Ybiy5zm5HBrSroG102mfVLu4iLioSc6A1uZAaB2I= X-Received: by 2002:a05:600c:1c9a:: with SMTP id k26mr1406845wms.169.1633414423545; Mon, 04 Oct 2021 23:13:43 -0700 (PDT) MIME-Version: 1.0 References: <20210901083215.25984-1-yunfei.dong@mediatek.com> <3b9463e88d88ce85205da08f8263252da7726ade.camel@mediatek.com> In-Reply-To: From: Tomasz Figa Date: Tue, 5 Oct 2021 15:13:32 +0900 Message-ID: Subject: Re: [PATCH v6, 00/15] Using component framework to support multi hardware decode To: Steve Cho Cc: Ezequiel Garcia , "yunfei.dong@mediatek.com" , Alexandre Courbot , Hans Verkuil , Tzung-Bi Shih , Tiffany Lin , Andrew-CT Chen , Mauro Carvalho Chehab , Rob Herring , Matthias Brugger , Laurent Pinchart , Daniel Vetter , dri-devel , Hsin-Yi Wang , Fritz Koenig , Irui Wang , linux-media , devicetree , Linux Kernel Mailing List , linux-arm-kernel , srv_heupstream , "moderated list:ARM/Mediatek SoC support" , Project_Global_Chrome_Upstream_Group Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, Sep 28, 2021 at 2:02 AM Steve Cho wrote: > > Hi Ezequiel, > > Thank you for reviewing these series from Yunfei! > This series is one of the main obstacles for us at the moment for MTK > so please continue to help & support reviewing this series. > > > > According to google's suggestion, it's better not to use v4l2 async > > > also. > > > > Hum? I haven't seen such objection on the mailing list. > Maybe coming from Tzung-Bi? > Yunfei, please let us know. I do object to using V4L2 async. It's designed for independent components of media pipelines, handled by multiple different drivers and also modelled as V4L2 subdevices. We don't have anything like that here. How about just open coding something trivial that only fits the needs of this specific driver? I think it would be as simple as a linked list and registering the V4L2 devices only after all the nodes probe. Best regards, Tomasz