From: Tomasz Figa <tfiga@google.com>
To: Steve Cho <stevecho@chromium.org>
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
"yunfei.dong@mediatek.com" <Yunfei.Dong@mediatek.com>,
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>,
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: Tue, 5 Oct 2021 15:13:32 +0900 [thread overview]
Message-ID: <CAAFQd5DzLMFarc2fFkrcE4t+T3mk5XJtCoWa8WpHNuOS5++SbA@mail.gmail.com> (raw)
In-Reply-To: <CAC-pXoMR=mOwnKqP5SFAfF3Ka5UrG0F8Mj=sJuEziU=uOKftoA@mail.gmail.com>
On Tue, Sep 28, 2021 at 2:02 AM Steve Cho <stevecho@chromium.org> wrote:
>
> Hi Ezequiel,
>
> Thank you for reviewing these series from Yunfei!
> This series is one of the main obstacles for us at the moment for MTK
> so please continue to help & support reviewing this series.
>
> > > According to google's suggestion, it's better not to use v4l2 async
> > > also.
> >
> > Hum? I haven't seen such objection on the mailing list.
> Maybe coming from Tzung-Bi?
> Yunfei, please let us know.
I do object to using V4L2 async. It's designed for independent
components of media pipelines, handled by multiple different drivers
and also modelled as V4L2 subdevices. We don't have anything like that
here.
How about just open coding something trivial that only fits the needs
of this specific driver? I think it would be as simple as a linked
list and registering the V4L2 devices only after all the nodes probe.
Best regards,
Tomasz
WARNING: multiple messages have this Message-ID (diff)
From: Tomasz Figa <tfiga@google.com>
To: Steve Cho <stevecho@chromium.org>
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
"yunfei.dong@mediatek.com" <Yunfei.Dong@mediatek.com>,
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>,
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: Tue, 5 Oct 2021 15:13:32 +0900 [thread overview]
Message-ID: <CAAFQd5DzLMFarc2fFkrcE4t+T3mk5XJtCoWa8WpHNuOS5++SbA@mail.gmail.com> (raw)
In-Reply-To: <CAC-pXoMR=mOwnKqP5SFAfF3Ka5UrG0F8Mj=sJuEziU=uOKftoA@mail.gmail.com>
On Tue, Sep 28, 2021 at 2:02 AM Steve Cho <stevecho@chromium.org> wrote:
>
> Hi Ezequiel,
>
> Thank you for reviewing these series from Yunfei!
> This series is one of the main obstacles for us at the moment for MTK
> so please continue to help & support reviewing this series.
>
> > > According to google's suggestion, it's better not to use v4l2 async
> > > also.
> >
> > Hum? I haven't seen such objection on the mailing list.
> Maybe coming from Tzung-Bi?
> Yunfei, please let us know.
I do object to using V4L2 async. It's designed for independent
components of media pipelines, handled by multiple different drivers
and also modelled as V4L2 subdevices. We don't have anything like that
here.
How about just open coding something trivial that only fits the needs
of this specific driver? I think it would be as simple as a linked
list and registering the V4L2 devices only after all the nodes probe.
Best regards,
Tomasz
_______________________________________________
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: Tomasz Figa <tfiga@google.com>
To: Steve Cho <stevecho@chromium.org>
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
"yunfei.dong@mediatek.com" <Yunfei.Dong@mediatek.com>,
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>,
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: Tue, 5 Oct 2021 15:13:32 +0900 [thread overview]
Message-ID: <CAAFQd5DzLMFarc2fFkrcE4t+T3mk5XJtCoWa8WpHNuOS5++SbA@mail.gmail.com> (raw)
In-Reply-To: <CAC-pXoMR=mOwnKqP5SFAfF3Ka5UrG0F8Mj=sJuEziU=uOKftoA@mail.gmail.com>
On Tue, Sep 28, 2021 at 2:02 AM Steve Cho <stevecho@chromium.org> wrote:
>
> Hi Ezequiel,
>
> Thank you for reviewing these series from Yunfei!
> This series is one of the main obstacles for us at the moment for MTK
> so please continue to help & support reviewing this series.
>
> > > According to google's suggestion, it's better not to use v4l2 async
> > > also.
> >
> > Hum? I haven't seen such objection on the mailing list.
> Maybe coming from Tzung-Bi?
> Yunfei, please let us know.
I do object to using V4L2 async. It's designed for independent
components of media pipelines, handled by multiple different drivers
and also modelled as V4L2 subdevices. We don't have anything like that
here.
How about just open coding something trivial that only fits the needs
of this specific driver? I think it would be as simple as a linked
list and registering the V4L2 devices only after all the nodes probe.
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-10-05 6:13 UTC|newest]
Thread overview: 115+ 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 ` Yunfei Dong
2021-09-01 8:32 ` 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 ` Yunfei Dong
2021-09-01 8:32 ` 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 ` Yunfei Dong
2021-09-01 8:32 ` 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 ` Yunfei Dong
2021-09-01 8:32 ` 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 ` Yunfei Dong
2021-09-01 8:32 ` 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 ` Yunfei Dong
2021-09-01 8:32 ` 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 ` Yunfei Dong
2021-09-01 8:32 ` 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 ` Yunfei Dong
2021-09-01 8:32 ` 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 ` Yunfei Dong
2021-09-01 8:32 ` 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 ` Yunfei Dong
2021-09-01 8:32 ` 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 ` Yunfei Dong
2021-09-01 8:32 ` Yunfei Dong
2021-09-01 8:32 ` [PATCH v6, 11/15] media: mtk-vcodec: Add core thread Yunfei Dong
2021-09-01 8:32 ` Yunfei Dong
2021-09-01 8:32 ` Yunfei Dong
2021-09-01 8:32 ` [PATCH v6, 12/15] media: mtk-vcodec: Support 34bits dma address for vdec Yunfei Dong
2021-09-01 8:32 ` Yunfei Dong
2021-09-01 8:32 ` Yunfei Dong
2021-10-07 11:37 ` Benjamin Gaignard
2021-10-07 11:37 ` Benjamin Gaignard
2021-10-07 11:37 ` Benjamin Gaignard
2021-10-11 5:42 ` yunfei.dong
2021-10-11 5:42 ` yunfei.dong
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-01 8:32 ` Yunfei Dong
2021-09-01 8:32 ` Yunfei Dong
2021-09-02 12:03 ` Rob Herring
2021-09-02 12:03 ` Rob Herring
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 ` Yunfei Dong
2021-09-01 8:32 ` 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 8:32 ` Yunfei Dong
2021-09-01 8:32 ` Yunfei Dong
2021-09-01 12:17 ` Dafna Hirschfeld
2021-09-01 12:17 ` Dafna Hirschfeld
2021-09-01 12:17 ` Dafna Hirschfeld
2021-09-02 6:05 ` yunfei.dong
2021-09-02 6:05 ` yunfei.dong
2021-09-02 6:05 ` yunfei.dong
2021-09-03 12:42 ` Dafna Hirschfeld
2021-09-03 12:42 ` Dafna Hirschfeld
2021-09-03 12:42 ` Dafna Hirschfeld
2021-09-04 3:00 ` yunfei.dong
2021-09-04 3:00 ` yunfei.dong
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-02 16:30 ` Ezequiel Garcia
2021-09-02 16:30 ` Ezequiel Garcia
2021-09-02 16:30 ` Ezequiel Garcia
2021-09-03 3:08 ` yunfei.dong
2021-09-03 3:08 ` yunfei.dong
2021-09-03 3:08 ` yunfei.dong
2021-09-03 3:08 ` yunfei.dong
2021-09-14 12:16 ` yunfei.dong
2021-09-14 12:16 ` yunfei.dong
2021-09-14 12:16 ` yunfei.dong
2021-09-14 12:16 ` yunfei.dong
2021-09-26 8:27 ` yunfei.dong
2021-09-26 8:27 ` yunfei.dong
2021-09-26 8:27 ` yunfei.dong
2021-09-26 8:27 ` yunfei.dong
2021-09-26 14:51 ` Ezequiel Garcia
2021-09-26 14:51 ` Ezequiel Garcia
2021-09-26 14:51 ` Ezequiel Garcia
2021-09-26 14:51 ` Ezequiel Garcia
2021-09-27 17:02 ` Steve Cho
2021-09-27 17:02 ` Steve Cho
2021-09-27 17:02 ` Steve Cho
2021-09-27 17:02 ` Steve Cho
2021-10-05 6:13 ` Tomasz Figa [this message]
2021-10-05 6:13 ` Tomasz Figa
2021-10-05 6:13 ` Tomasz Figa
2021-10-13 1:17 ` yunfei.dong
2021-10-13 1:17 ` yunfei.dong
2021-10-13 1:17 ` yunfei.dong
2021-10-14 12:38 ` Ezequiel Garcia
2021-10-14 12:38 ` Ezequiel Garcia
2021-10-14 12:38 ` Ezequiel Garcia
2021-10-29 3:21 ` yunfei.dong
2021-09-03 4:09 ` Chen-Yu Tsai
2021-09-03 4:09 ` Chen-Yu Tsai
2021-09-03 4:09 ` Chen-Yu Tsai
2021-09-03 4:09 ` Chen-Yu Tsai
2021-09-27 16:56 ` Steve Cho
2021-09-27 16:56 ` Steve Cho
2021-09-27 16:56 ` Steve Cho
2021-09-27 16:56 ` Steve Cho
2021-09-27 17:31 ` Steve Cho
2021-09-27 17:31 ` Steve Cho
2021-09-27 17:31 ` 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=CAAFQd5DzLMFarc2fFkrcE4t+T3mk5XJtCoWa8WpHNuOS5++SbA@mail.gmail.com \
--to=tfiga@google.com \
--cc=Andrew-CT.Chen@mediatek.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=Yunfei.Dong@mediatek.com \
--cc=acourbot@chromium.org \
--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=stevecho@chromium.org \
--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 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.