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.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 27378C432BE for ; Sun, 22 Aug 2021 17:57:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0779F611AF for ; Sun, 22 Aug 2021 17:57:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231788AbhHVR6I (ORCPT ); Sun, 22 Aug 2021 13:58:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35284 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231698AbhHVR6I (ORCPT ); Sun, 22 Aug 2021 13:58:08 -0400 Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4CDAFC061757 for ; Sun, 22 Aug 2021 10:57:27 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id s16so14857363ilo.9 for ; Sun, 22 Aug 2021 10:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vanguardiasur-com-ar.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tO3FpggPumUudO2O7Ir/fs1af6Qf8hcFO9g7I6cp01Q=; b=NDkEoB50cJIffh8DEmD3xfV5OH8ema/PjNX2L8kixdAdzju1+1Q+RfI4dvsWmf6ckV cbsUqLyLFzaRWyrxKHgk9HO+WkFNp66FjMC0xCvO73mpe2AOuKEOT9losiWcUW3PDPNm I0Juj2PjGLAqKt2+Iz9cmX6gBy5MzrvAzxAH8s1TYKJbJaqQKfMgWI5aiYeXRCwwh3kd CJI4TEZHABSCNMA2IhdFQIizIVfW37pxWIzkxkAqqzqK5tmPuWInXDStw52NSqp8XXny pVSXtZOL/inFPT0NN6u8kmBCcSiariw/dIe5ePYIn0HTiy7GwQL7GtGEqlmgztShSjIB r2/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tO3FpggPumUudO2O7Ir/fs1af6Qf8hcFO9g7I6cp01Q=; b=MueOJn4Ngr8btyyz3d+JLCTAU4mxbsaxk4m9nH1y/cp395NlxYy19vt5SOrN/34UOK UVmHnTtc+RBVylZYchSmsKDkauc0HF3uV8XInSpZi/TEqt4rRfZrU/EdAxYeBI6jBfw5 SQvHjWKe4jRspWFf4q7FKcZzdfrVoFUhAB7ejjAOgxvMVzVcFs28OE75cLROoxV2KDjU 6y0NxNl6PWOTVYUVS3CB+kzfEIb1DJIhuqJ1ZiDoL/oYP/WCcwXR9P0V865Xa5DVuIsH X5sbPBs+InxMF/uYGMNufEDX+Vem2R69uQt67vBp7ZagrrP8DJ3MGjZQCsW0OB57TlkV kveQ== X-Gm-Message-State: AOAM533D46e5wrl0uyRNVScPB8jD9HeCy8QNMIIir7K0V6Dd790hIDCX XpazSqov3bIBqihBAGJV+ChDp8Su9pVfe4vEdVwLVA== X-Google-Smtp-Source: ABdhPJxAy4F4JBrNf2BEXyC2jHsLYTKqTZpEvWl47iBJSnZyLzmCveu6cLApJEwjHW6shDTLnoCxAWArc0HfBTHBbuc= X-Received: by 2002:a92:ca89:: with SMTP id t9mr21038515ilo.178.1629655046630; Sun, 22 Aug 2021 10:57:26 -0700 (PDT) MIME-Version: 1.0 References: <20210811025801.21597-1-yunfei.dong@mediatek.com> In-Reply-To: From: Ezequiel Garcia Date: Sun, 22 Aug 2021 14:57:15 -0300 Message-ID: Subject: Re: [PATCH v5, 00/15] Using component framework to support multi hardware decode To: Daniel Vetter Cc: Yunfei Dong , dri-devel , Alexandre Courbot , Hans Verkuil , Tzung-Bi Shih , Tiffany Lin , Andrew-CT Chen , Mauro Carvalho Chehab , Rob Herring , Matthias Brugger , Tomasz Figa , 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@mediatek.com, George Sun Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Sun, 22 Aug 2021 at 13:50, Daniel Vetter wrote: > > On Wed, Aug 18, 2021 at 4:12 PM Ezequiel Garcia > wrote: > > > > +danvet > > > > Hi, > > > > On Tue, 10 Aug 2021 at 23:58, Yunfei Dong wrote: > > > > > > This series adds support for multi hardware decode into mtk-vcodec, by first > > > adding component framework to manage each hardware information: interrupt, > > > clock, register bases and power. Secondly add core thread to deal with core > > > hardware message, at the same time, add msg queue for different hardware > > > share messages. Lastly, the architecture of different specs are not the same, > > > using specs type to separate them. > > > > > > > I don't think it's a good idea to introduce the component API in the > > media subsystem. It doesn't seem to be maintained, IRC there's not even > > a maintainer for it, and it has some issues that were never addressed. > > Defacto dri-devel folks are maintainer component.c, but also I'm not > aware of anything missing there? > A while ago, I tried to fix a crash in the Rockchip DRM driver (I was then told there can be similar issues on the IMX driver too, but I forgot the details of that). I sent a patchset trying to address it and got total silence back. Although you could argue the issue is in how drivers use the component API, AFAICR the abuse is spreaded across a few drivers, so it felt more reasonable to improve the component API itself, instead of changing all the drivers. See below: https://patchwork.kernel.org/project/linux-rockchip/cover/20200120170602.3832-1-ezequiel@collabora.com/ > There has been discussions that in various drm subsystems like > drm_bridge or drm_panel a few things are missing, which prevent > drivers from moving _away_ from component.c to the more specific > solutions for panel/bridges. But nothing that's preventing them from > using component.c itself. > > I'm happy to merge a MAINTAINERS patch to clarify the situation if > that's needed. Indeed, that would be good. Thanks, Ezequiel