[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAEAJfDWOzCJxZFNtxeT7Cvr2pWbYrfz-YnA81sVNs-rM=8n4Q@mail.gmail.com>
Date: Wed, 18 Aug 2021 11:11:57 -0300
From: Ezequiel Garcia <ezequiel@...guardiasur.com.ar>
To: Yunfei Dong <yunfei.dong@...iatek.com>,
Daniel Vetter <daniel@...ll.ch>,
dri-devel <dri-devel@...ts.freedesktop.org>
Cc: Alexandre Courbot <acourbot@...omium.org>,
Hans Verkuil <hverkuil-cisco@...all.nl>,
Tzung-Bi Shih <tzungbi@...omium.org>,
Tiffany Lin <tiffany.lin@...iatek.com>,
Andrew-CT Chen <andrew-ct.chen@...iatek.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Matthias Brugger <matthias.bgg@...il.com>,
Tomasz Figa <tfiga@...gle.com>,
Hsin-Yi Wang <hsinyi@...omium.org>,
Fritz Koenig <frkoenig@...omium.org>,
Irui Wang <irui.wang@...iatek.com>,
linux-media <linux-media@...r.kernel.org>,
devicetree <devicetree@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
srv_heupstream <srv_heupstream@...iatek.com>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@...ts.infradead.org>,
Project_Global_Chrome_Upstream_Group@...iatek.com,
George Sun <george.sun@...iatek.com>
Subject: Re: [PATCH v5, 00/15] Using component framework to support multi
hardware decode
+danvet
Hi,
On Tue, 10 Aug 2021 at 23:58, Yunfei Dong <yunfei.dong@...iatek.com> 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.
It would be really important to avoid it. Is it really needed in the
first place?
Thanks,
Ezequiel
Powered by blists - more mailing lists