On Wed, Aug 18, 2021 at 4:12 PM Ezequiel Garcia ezequiel@vanguardiasur.com.ar wrote:
+danvet
Hi,
On Tue, 10 Aug 2021 at 23:58, Yunfei Dong yunfei.dong@mediatek.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.
Defacto dri-devel folks are maintainer component.c, but also I'm not aware of anything missing there?
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. -Daniel
It would be really important to avoid it. Is it really needed in the first place?
Thanks, Ezequiel