All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
To: Yunfei Dong <yunfei.dong@mediatek.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	dri-devel <dri-devel@lists.freedesktop.org>
Cc: Alexandre Courbot <acourbot@chromium.org>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Tzung-Bi Shih <tzungbi@chromium.org>,
	Tiffany Lin <tiffany.lin@mediatek.com>,
	Andrew-CT Chen <andrew-ct.chen@mediatek.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Tomasz Figa <tfiga@google.com>,
	Hsin-Yi Wang <hsinyi@chromium.org>,
	Fritz Koenig <frkoenig@chromium.org>,
	Irui Wang <irui.wang@mediatek.com>,
	linux-media <linux-media@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	srv_heupstream <srv_heupstream@mediatek.com>,
	"moderated list:ARM/Mediatek SoC support" 
	<linux-mediatek@lists.infradead.org>,
	Project_Global_Chrome_Upstream_Group@mediatek.com,
	George Sun <george.sun@mediatek.com>
Subject: Re: [PATCH v5, 00/15] Using component framework to support multi hardware decode
Date: Wed, 18 Aug 2021 11:11:57 -0300	[thread overview]
Message-ID: <CAAEAJfDWOzCJxZFNtxeT7Cvr2pWbYrfz-YnA81sVNs-rM=8n4Q@mail.gmail.com> (raw)
In-Reply-To: <20210811025801.21597-1-yunfei.dong@mediatek.com>

+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.

It would be really important to avoid it. Is it really needed in the
first place?

Thanks,
Ezequiel

WARNING: multiple messages have this Message-ID (diff)
From: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
To: Yunfei Dong <yunfei.dong@mediatek.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	 dri-devel <dri-devel@lists.freedesktop.org>
Cc: Alexandre Courbot <acourbot@chromium.org>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	 Tzung-Bi Shih <tzungbi@chromium.org>,
	Tiffany Lin <tiffany.lin@mediatek.com>,
	 Andrew-CT Chen <andrew-ct.chen@mediatek.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	 Rob Herring <robh+dt@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	 Tomasz Figa <tfiga@google.com>,
	Hsin-Yi Wang <hsinyi@chromium.org>,
	 Fritz Koenig <frkoenig@chromium.org>,
	Irui Wang <irui.wang@mediatek.com>,
	 linux-media <linux-media@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	 linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	 srv_heupstream <srv_heupstream@mediatek.com>,
	 "moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	Project_Global_Chrome_Upstream_Group@mediatek.com,
	 George Sun <george.sun@mediatek.com>
Subject: Re: [PATCH v5, 00/15] Using component framework to support multi hardware decode
Date: Wed, 18 Aug 2021 11:11:57 -0300	[thread overview]
Message-ID: <CAAEAJfDWOzCJxZFNtxeT7Cvr2pWbYrfz-YnA81sVNs-rM=8n4Q@mail.gmail.com> (raw)
In-Reply-To: <20210811025801.21597-1-yunfei.dong@mediatek.com>

+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.

It would be really important to avoid it. Is it really needed in the
first place?

Thanks,
Ezequiel

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
To: Yunfei Dong <yunfei.dong@mediatek.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	 dri-devel <dri-devel@lists.freedesktop.org>
Cc: Alexandre Courbot <acourbot@chromium.org>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	 Tzung-Bi Shih <tzungbi@chromium.org>,
	Tiffany Lin <tiffany.lin@mediatek.com>,
	 Andrew-CT Chen <andrew-ct.chen@mediatek.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	 Rob Herring <robh+dt@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	 Tomasz Figa <tfiga@google.com>,
	Hsin-Yi Wang <hsinyi@chromium.org>,
	 Fritz Koenig <frkoenig@chromium.org>,
	Irui Wang <irui.wang@mediatek.com>,
	 linux-media <linux-media@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	 linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	 srv_heupstream <srv_heupstream@mediatek.com>,
	 "moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	Project_Global_Chrome_Upstream_Group@mediatek.com,
	 George Sun <george.sun@mediatek.com>
Subject: Re: [PATCH v5, 00/15] Using component framework to support multi hardware decode
Date: Wed, 18 Aug 2021 11:11:57 -0300	[thread overview]
Message-ID: <CAAEAJfDWOzCJxZFNtxeT7Cvr2pWbYrfz-YnA81sVNs-rM=8n4Q@mail.gmail.com> (raw)
In-Reply-To: <20210811025801.21597-1-yunfei.dong@mediatek.com>

+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.

It would be really important to avoid it. Is it really needed in the
first place?

Thanks,
Ezequiel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-08-18 14:13 UTC|newest]

Thread overview: 133+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-11  2:57 [PATCH v5, 00/15] Using component framework to support multi hardware decode Yunfei Dong
2021-08-11  2:57 ` Yunfei Dong
2021-08-11  2:57 ` Yunfei Dong
2021-08-11  2:57 ` [PATCH v5, 01/15] media: mtk-vcodec: Get numbers of register bases from DT Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-20  3:29   ` Tzung-Bi Shih
2021-08-20  3:29     ` Tzung-Bi Shih
2021-08-20  3:29     ` Tzung-Bi Shih
2021-08-11  2:57 ` [PATCH v5, 02/15] media: mtk-vcodec: Align vcodec wake up interrupt interface Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57 ` [PATCH v5, 03/15] media: mtk-vcodec: Refactor vcodec pm interface Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57 ` [PATCH v5, 04/15] media: mtk-vcodec: Use component framework to manage each hardware information Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57 ` [PATCH v5, 05/15] dt-bindings: media: mtk-vcodec: Separate video encoder and decoder dt-bindings Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-17 20:33   ` Rob Herring
2021-08-17 20:33     ` Rob Herring
2021-08-17 20:33     ` Rob Herring
2021-08-11  2:57 ` [PATCH v5, 06/15] media: mtk-vcodec: Use pure single core for MT8183 Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57 ` [PATCH v5, 07/15] media: mtk-vcodec: Add irq interface for multi hardware Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57 ` [PATCH v5, 08/15] media: mtk-vcodec: Add msg queue feature for lat and core architecture Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57 ` [PATCH v5, 09/15] media: mtk-vcodec: Generalize power and clock on/off interfaces Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57 ` [PATCH v5, 10/15] media: mtk-vcodec: Add new interface to lock different hardware Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57 ` [PATCH v5, 11/15] media: mtk-vcodec: Add core thread Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57 ` [PATCH v5, 12/15] media: mtk-vcodec: Support 34bits dma address for vdec Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57 ` [PATCH v5, 13/15] dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8192 Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11  2:57   ` Yunfei Dong
2021-08-11 17:24   ` Rob Herring
2021-08-11 17:24     ` Rob Herring
2021-08-11 17:24     ` Rob Herring
2021-08-17  3:38     ` yunfei.dong
2021-08-17  3:38       ` yunfei.dong
2021-08-17  3:38       ` yunfei.dong
2021-08-11 17:41   ` Rob Herring
2021-08-11 17:41     ` Rob Herring
2021-08-11 17:41     ` Rob Herring
2021-08-11 17:59   ` Laurent Pinchart
2021-08-11 17:59     ` Laurent Pinchart
2021-08-11 17:59     ` Laurent Pinchart
2021-08-17  3:50     ` yunfei.dong
2021-08-17  3:50       ` yunfei.dong
2021-08-17  3:50       ` yunfei.dong
2021-08-29 20:54       ` Ezequiel Garcia
2021-08-29 20:54         ` Ezequiel Garcia
2021-08-29 20:54         ` Ezequiel Garcia
2021-09-01  3:49         ` yunfei.dong
2021-09-01  3:49           ` yunfei.dong
2021-09-01  3:49           ` yunfei.dong
2021-09-01 11:50           ` Ezequiel Garcia
2021-09-01 11:50             ` Ezequiel Garcia
2021-09-01 11:50             ` Ezequiel Garcia
2021-09-02  6:09             ` yunfei.dong
2021-09-02  6:09               ` yunfei.dong
2021-09-02  6:09               ` yunfei.dong
2021-09-03  4:02               ` Chen-Yu Tsai
2021-09-03  4:02                 ` Chen-Yu Tsai
2021-09-03  4:02                 ` Chen-Yu Tsai
2021-08-29 20:50     ` Ezequiel Garcia
2021-08-29 20:50       ` Ezequiel Garcia
2021-08-29 20:50       ` Ezequiel Garcia
2021-08-30  6:07       ` yunfei.dong
2021-08-30  6:07         ` yunfei.dong
2021-08-30  6:07         ` yunfei.dong
2021-08-30  9:00         ` Laurent Pinchart
2021-08-30  9:00           ` Laurent Pinchart
2021-08-30  9:00           ` Laurent Pinchart
2021-08-11  2:58 ` [PATCH v5, 14/15] media: mtk-vcodec: Add core dec and dec end ipi msg Yunfei Dong
2021-08-11  2:58   ` Yunfei Dong
2021-08-11  2:58   ` Yunfei Dong
2021-08-11  2:58 ` [PATCH v5, 15/15] media: mtk-vcodec: Use codec type to separate different hardware Yunfei Dong
2021-08-11  2:58   ` Yunfei Dong
2021-08-11  2:58   ` Yunfei Dong
2021-08-18 14:11 ` Ezequiel Garcia [this message]
2021-08-18 14:11   ` [PATCH v5, 00/15] Using component framework to support multi hardware decode Ezequiel Garcia
2021-08-18 14:11   ` Ezequiel Garcia
2021-08-18 14:11   ` Ezequiel Garcia
2021-08-19  7:13   ` yunfei.dong
2021-08-19  7:13     ` yunfei.dong
2021-08-19  7:13     ` yunfei.dong
2021-08-19  7:13     ` yunfei.dong
2021-08-19 14:10     ` Ezequiel Garcia
2021-08-19 14:10       ` Ezequiel Garcia
2021-08-19 14:10       ` Ezequiel Garcia
2021-08-19 14:10       ` Ezequiel Garcia
2021-08-20  7:59       ` yunfei.dong
2021-08-20  7:59         ` yunfei.dong
2021-08-20  7:59         ` yunfei.dong
2021-08-20  7:59         ` yunfei.dong
2021-08-22 14:32         ` Ezequiel Garcia
2021-08-22 14:32           ` Ezequiel Garcia
2021-08-22 14:32           ` Ezequiel Garcia
2021-08-22 14:32           ` Ezequiel Garcia
2021-08-24 10:21           ` yunfei.dong
2021-08-24 10:21             ` yunfei.dong
2021-08-24 10:21             ` yunfei.dong
2021-08-24 10:21             ` yunfei.dong
2021-08-25  5:48             ` yunfei.dong
2021-08-25  5:48               ` yunfei.dong
2021-08-25  5:48               ` yunfei.dong
2021-08-25  5:48               ` yunfei.dong
2021-08-22 16:50   ` Daniel Vetter
2021-08-22 16:50     ` Daniel Vetter
2021-08-22 16:50     ` Daniel Vetter
2021-08-22 16:50     ` Daniel Vetter
2021-08-22 17:57     ` Ezequiel Garcia
2021-08-22 17:57       ` Ezequiel Garcia
2021-08-22 17:57       ` Ezequiel Garcia
2021-08-22 17:57       ` Ezequiel Garcia
2021-08-26  9:14       ` Daniel Vetter
2021-08-26  9:14         ` Daniel Vetter
2021-08-26  9:14         ` Daniel Vetter
2021-08-26  9:14         ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAEAJfDWOzCJxZFNtxeT7Cvr2pWbYrfz-YnA81sVNs-rM=8n4Q@mail.gmail.com' \
    --to=ezequiel@vanguardiasur.com.ar \
    --cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
    --cc=acourbot@chromium.org \
    --cc=andrew-ct.chen@mediatek.com \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=frkoenig@chromium.org \
    --cc=george.sun@mediatek.com \
    --cc=hsinyi@chromium.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=irui.wang@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mchehab@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=srv_heupstream@mediatek.com \
    --cc=tfiga@google.com \
    --cc=tiffany.lin@mediatek.com \
    --cc=tzungbi@chromium.org \
    --cc=yunfei.dong@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.