LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "yunfei.dong@mediatek.com" <yunfei.dong@mediatek.com>
To: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Cc: Daniel Vetter <daniel@ffwll.ch>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	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: Fri, 20 Aug 2021 15:59:38 +0800	[thread overview]
Message-ID: <1629446378.18871.27.camel@mhfsdcap03> (raw)
In-Reply-To: <CAAEAJfCTrKj9AFExN-L-TKww4E=us1VVh8LHtZ8Q0j_eaCD4Eg@mail.gmail.com>

Hi Ezequiel,

Thanks for your detail feedback. 

On Thu, 2021-08-19 at 11:10 -0300, Ezequiel Garcia wrote:
> On Thu, 19 Aug 2021 at 04:13, yunfei.dong@mediatek.com
> <yunfei.dong@mediatek.com> wrote:
> >
> > Hi Ezequiel,
> >
> > Thanks for your suggestion.
> >
> > On Wed, 2021-08-18 at 11:11 -0300, Ezequiel Garcia 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.
> > >
> > > It would be really important to avoid it. Is it really needed in the
> > > first place?
> > >
> > > Thanks,
> > > Ezequiel
> >
> > For there are many hardware need to use, mt8192 is three and mt8195 is
> > five. Maybe need more to be used in the feature.
> >
> > Each hardware has independent clk/power/iommu port/irq.
> > Use component interface in prob to get each component's information.
> > Just enable the hardware when need to use it, very convenient and
> > simple.
> >
> > I found that there are many modules use component to manage hardware
> > information, such as iommu and drm etc.
> >
> 
> Many drivers support multiple hardware variants, where each variant
> has a different number of clocks or interrupts, see for instance
> struct hantro_variant which allows to expose different codec cores,
> some having both decoder/encoder, and some having just a decoder.
> 
> The component API is mostly used by DRM to aggregate independent
> subdevices (called components) into an aggregated driver.
> 
> For instance, a DRM driver needs to glue together the HDMI, MIPI,
> and plany controller, or any other hardware arrangement where
> devices can be described independently.
> 
The usage scenario is very similar with drm and iommu, So decide to use
component framework.
Decode has three/five or more hardwares, these hardware are independent.
For mt8183 just need core hardware to decode, but mt8192 has lat,soc and
core hardware to decode. When lat need to use, just enable lat hardware,
core is the same.And mt8195 will has two cores, each core can work well
independent.

For each component device just used to open their power/clk/iommu
port/irq when master need to enable it. The main logic is in master
device.

> The component API may look simple but has some issues, it's not easy
> to debug, and can cause troubles if not used as expected [1].
> It's worth making sure you actually need a framework
> to glue different devices together.
> 
Each hardware has its index, master can get hardware information
according these index, looks not complex. What do you mean about not
easy to debug?

> > Do you have any other suggestion for this architecture?
> >
> 
> Looking at the different patchsets that are posted, it's not clear
> to me what exactly are the different architectures that you intend
> to support, can you some documentation which clarifies that?
> 
Have five hardwares lat,soc,core0,core1 and main. Lat thread can use lat
soc and main, core thread can use soc,lat, core0 and core1. Core thread
can be used or not for different project. Also Need to use these
hardware dynamic at the same time. So I use component framework, just
need to know the used  hardware index according to different
project.Need not to do complex logic to manage these hardwares.


> Thanks,
> Ezequiel
> 
> [1] https://patchwork.kernel.org/project/linux-rockchip/cover/20200120170602.3832-1-ezequiel@collabora.com/


Thanks,
Yunfei Dong





  reply	other threads:[~2021-08-20  7:59 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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-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 ` [PATCH v5, 03/15] media: mtk-vcodec: Refactor vcodec pm interface 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 ` [PATCH v5, 05/15] dt-bindings: media: mtk-vcodec: Separate video encoder and decoder dt-bindings Yunfei Dong
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 ` [PATCH v5, 07/15] media: mtk-vcodec: Add irq interface for multi hardware 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 ` [PATCH v5, 09/15] media: mtk-vcodec: Generalize power and clock on/off interfaces 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 ` [PATCH v5, 11/15] media: mtk-vcodec: Add core thread 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 ` [PATCH v5, 13/15] dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8192 Yunfei Dong
2021-08-11 17:24   ` Rob Herring
2021-08-17  3:38     ` yunfei.dong
2021-08-11 17:41   ` Rob Herring
2021-08-11 17:59   ` Laurent Pinchart
2021-08-17  3:50     ` yunfei.dong
2021-08-29 20:54       ` Ezequiel Garcia
2021-09-01  3:49         ` yunfei.dong
2021-09-01 11:50           ` Ezequiel Garcia
2021-09-02  6:09             ` yunfei.dong
2021-09-03  4:02               ` Chen-Yu Tsai
2021-08-29 20:50     ` Ezequiel Garcia
2021-08-30  6:07       ` yunfei.dong
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 ` [PATCH v5, 15/15] media: mtk-vcodec: Use codec type to separate different hardware Yunfei Dong
2021-08-18 14:11 ` [PATCH v5, 00/15] Using component framework to support multi hardware decode Ezequiel Garcia
2021-08-19  7:13   ` yunfei.dong
2021-08-19 14:10     ` Ezequiel Garcia
2021-08-20  7:59       ` yunfei.dong [this message]
2021-08-22 14:32         ` Ezequiel Garcia
2021-08-24 10:21           ` yunfei.dong
2021-08-25  5:48             ` yunfei.dong
2021-08-22 16:50   ` Daniel Vetter
2021-08-22 17:57     ` Ezequiel Garcia
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=1629446378.18871.27.camel@mhfsdcap03 \
    --to=yunfei.dong@mediatek.com \
    --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=ezequiel@vanguardiasur.com.ar \
    --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 \
    --subject='Re: [PATCH v5, 00/15] Using component framework to support multi hardware decode' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).