linux-mediatek.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "yunfei.dong@mediatek.com" <yunfei.dong@mediatek.com>
To: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
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>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	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
	<Project_Global_Chrome_Upstream_Group@mediatek.com>
Subject: Re: [PATCH v6, 00/15] Using component framework to support multi hardware decode
Date: Fri, 3 Sep 2021 11:08:13 +0800	[thread overview]
Message-ID: <3b9463e88d88ce85205da08f8263252da7726ade.camel@mediatek.com> (raw)
In-Reply-To: <CAAEAJfDOt_GyDPojcj5P6Wou9HC2GC8YzRt2wYyqdrCOjfeOog@mail.gmail.com>

Hi Ezequiel,

Thanks for your suggestion.
On Thu, 2021-09-02 at 13:30 -0300, Ezequiel Garcia wrote:
> On Wed, 1 Sept 2021 at 05:32, 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.
> > 
> > This series has been tested with both MT8183 and MT8173. Decoding
> > was working
> > for both chips.
> > 
> > Patches 1~3 rewrite get register bases and power on/off interface.
> > 
> > Patch 4 add component framework to support multi hardware.
> > 
> > Patch 5 separate video encoder and decoder document
> > 
> > Patches 6-15 add interfaces to support core hardware.
> > ----
> > This patch dependents on : "media: mtk-vcodec: support for MT8183
> > decoder"[1] and
> > "Mediatek MT8192 clock support"[2].
> > 
> > 1: Multi hardware decode is based on stateless decoder, MT8183 is
> > the first time
> > to add stateless decoder. Otherwise it will cause conflict. This
> > patch will be
> > accepted in 5.15[1].
> > 
> > 2: The definition of decoder clocks are in mt8192-clk.h, this patch
> > already in clk tree[2].
> > 
> > [1]
> > https://patchwork.linuxtv.org/project/linux-media/list/?series=5826
> > [2]
> > https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/commit/?h=clk-next&id=f35f1a23e0e12e3173e9e9dedbc150d139027189
> > ----
> > Changes compared with v5:
> > -Add decoder hardware block diagram for patch 13/15
> > 
> 
> 
> The discussion on v5 was still on-going, so sending this v6
> is not helpful. The context for v5's discussion is now harder to
> find.
> 

> Please avoid sending a new version without properly
> discussing all the feedback, and without reaching consensus.
> This is very important, please keep it in mind.
> 
Thanks for your remind, I will keep this patch until get the solution.

> Specifically, the feedback on v5 was NAK, with the request to avoid
> using any async framework, and instead try to find a simpler
> solution.
> 
> For instance, you can model things with a bus-like pattern,
> which ties all the devices together, under a parent node.
> This pattern is common in the kernel, the parent
> node can use of_platform_populate or similar
> (git grep of_platform_populate, you will see plenty of examples).
> 
> You will still have to do some work to have the proper
> regs resources, but this is doable. Each child is a device,
> so it can have its own resources (clocks, interrupts, iommus).
> 
> You don't need any async framework.
> 
If put the lat and core node in the parent node, need to check the
below things after discussed with iommu owner.

If putting the iommus property in the child node, then is the child
device a standard platform device?

The iommu registe like this:  
ret = bus_set_iommu(&platform_bus_type, &mtk_iommu_ops); 
It expect the consumer is a standard platform device. otherwise it
could not enter to the iommu of_xlate.)

Thanks
Yunfei Dong
>     vcodec_dec: vcodec_dec@16000000 {
>         compatible = "mediatek,mt8192-vcodec-dec";
>         reg = <something>;
>         mediatek,scp = <&scp>;
>         iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>;
>         dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>;
> 
>         vcodec_lat@0x10000 {
>             compatible = "mediatek,mtk-vcodec-lat";
>             reg = <0x10000 0x800>;      /* VDEC_MISC */
>             interrupts = <GIC_SPI 426 IRQ_TYPE_LEVEL_HIGH 0>;
>             // etc
>         };
> 
>         vcodec_core@0x25000 {
>            compatible = "mediatek,mtk-vcodec-core";
>            reg = <0x25000 0x1000>;      /* VDEC_CORE_MISC */
>            interrupts = <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH 0>;
>            // etc
>         };
>     };
> 
> Thanks,
> Ezequiel
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

  reply	other threads:[~2021-09-03  3:09 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01  8:32 [PATCH v6, 00/15] Using component framework to support multi hardware decode Yunfei Dong
2021-09-01  8:32 ` [PATCH v6, 01/15] media: mtk-vcodec: Get numbers of register bases from DT Yunfei Dong
2021-09-01  8:32 ` [PATCH v6, 02/15] media: mtk-vcodec: Align vcodec wake up interrupt interface Yunfei Dong
2021-09-01  8:32 ` [PATCH v6, 03/15] media: mtk-vcodec: Refactor vcodec pm interface Yunfei Dong
2021-09-01  8:32 ` [PATCH v6, 04/15] media: mtk-vcodec: Use component framework to manage each hardware information Yunfei Dong
2021-09-01  8:32 ` [PATCH v6, 05/15] dt-bindings: media: mtk-vcodec: Separate video encoder and decoder dt-bindings Yunfei Dong
2021-09-01  8:32 ` [PATCH v6, 06/15] media: mtk-vcodec: Use pure single core for MT8183 Yunfei Dong
2021-09-01  8:32 ` [PATCH v6, 07/15] media: mtk-vcodec: Add irq interface for multi hardware Yunfei Dong
2021-09-01  8:32 ` [PATCH v6, 08/15] media: mtk-vcodec: Add msg queue feature for lat and core architecture Yunfei Dong
2021-09-01  8:32 ` [PATCH v6, 09/15] media: mtk-vcodec: Generalize power and clock on/off interfaces Yunfei Dong
2021-09-01  8:32 ` [PATCH v6, 10/15] media: mtk-vcodec: Add new interface to lock different hardware Yunfei Dong
2021-09-01  8:32 ` [PATCH v6, 11/15] media: mtk-vcodec: Add core thread Yunfei Dong
2021-09-01  8:32 ` [PATCH v6, 12/15] media: mtk-vcodec: Support 34bits dma address for vdec Yunfei Dong
2021-10-07 11:37   ` Benjamin Gaignard
2021-10-11  5:42     ` yunfei.dong
2021-09-01  8:32 ` [PATCH v6, 13/15] dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8192 Yunfei Dong
2021-09-02 12:03   ` Rob Herring
2021-09-01  8:32 ` [PATCH v6, 14/15] media: mtk-vcodec: Add core dec and dec end ipi msg Yunfei Dong
2021-09-01  8:32 ` [PATCH v6, 15/15] media: mtk-vcodec: Use codec type to separate different hardware Yunfei Dong
2021-09-01 12:17   ` Dafna Hirschfeld
2021-09-02  6:05     ` yunfei.dong
2021-09-03 12:42       ` Dafna Hirschfeld
2021-09-04  3:00         ` yunfei.dong
2021-09-02 16:30 ` [PATCH v6, 00/15] Using component framework to support multi hardware decode Ezequiel Garcia
2021-09-03  3:08   ` yunfei.dong [this message]
2021-09-14 12:16     ` yunfei.dong
2021-09-26  8:27       ` yunfei.dong
2021-09-26 14:51         ` Ezequiel Garcia
2021-09-27 17:02           ` Steve Cho
2021-10-05  6:13             ` Tomasz Figa
2021-10-13  1:17           ` yunfei.dong
2021-10-14 12:38             ` Ezequiel Garcia
2021-09-03  4:09   ` Chen-Yu Tsai
2021-09-27 16:56 ` Steve Cho
2021-09-27 17:31   ` Steve Cho

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=3b9463e88d88ce85205da08f8263252da7726ade.camel@mediatek.com \
    --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=hsinyi@chromium.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=irui.wang@mediatek.com \
    --cc=laurent.pinchart@ideasonboard.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 \
    /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 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).