[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <825ac03b692043d48563620ad9542a4ee43211e7.camel@mediatek.com>
Date: Thu, 28 Sep 2023 02:52:23 +0000
From: Moudy Ho (何宗原) <Moudy.Ho@...iatek.com>
To: "conor.dooley@...rochip.com" <conor.dooley@...rochip.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mediatek@...ts.infradead.org"
<linux-mediatek@...ts.infradead.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"conor@...nel.org" <conor@...nel.org>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
"chunkuang.hu@...nel.org" <chunkuang.hu@...nel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"mchehab@...nel.org" <mchehab@...nel.org>,
"daniel@...ll.ch" <daniel@...ll.ch>,
"p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
"conor+dt@...nel.org" <conor+dt@...nel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"hverkuil-cisco@...all.nl" <hverkuil-cisco@...all.nl>,
"airlied@...il.com" <airlied@...il.com>,
"krzysztof.kozlowski+dt@...aro.org"
<krzysztof.kozlowski+dt@...aro.org>,
"matthias.bgg@...il.com" <matthias.bgg@...il.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"angelogioacchino.delregno@...labora.com"
<angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH v6 12/16] dt-bindings: display: mediatek: color: add
compatible for MT8195
On Wed, 2023-09-27 at 10:47 +0100, Conor Dooley wrote:
> On Wed, Sep 27, 2023 at 07:19:28AM +0000, Moudy Ho (何宗原) wrote:
> > On Fri, 2023-09-22 at 16:51 +0100, Conor Dooley wrote:
> > > On Fri, Sep 22, 2023 at 04:49:14PM +0100, Conor Dooley wrote:
> > > > On Fri, Sep 22, 2023 at 03:21:12PM +0800, Moudy Ho wrote:
> > > > > Add a compatible string for the COLOR block in MediaTek
> > > > > MT8195
> > > > > that
> > > > > is controlled by MDP3.
> > > > >
> > > > > Signed-off-by: Moudy Ho <moudy.ho@...iatek.com>
> > > > > ---
> > > > > .../devicetree/bindings/display/mediatek/mediatek,color.yaml
> > > > >
> > > > > | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/display/mediatek/mediatek
> > > > > ,col
> > > > > or.yaml
> > > > > b/Documentation/devicetree/bindings/display/mediatek/mediatek
> > > > > ,col
> > > > > or.yaml
> > > > > index f21e44092043..b886ca0d89ea 100644
> > > > > ---
> > > > > a/Documentation/devicetree/bindings/display/mediatek/mediatek
> > > > > ,col
> > > > > or.yaml
> > > > > +++
> > > > > b/Documentation/devicetree/bindings/display/mediatek/mediatek
> > > > > ,col
> > > > > or.yaml
> > > > > @@ -26,6 +26,7 @@ properties:
> > > > > - mediatek,mt2701-disp-color
> > > > > - mediatek,mt8167-disp-color
> > > > > - mediatek,mt8173-disp-color
> > > > > + - mediatek,mt8195-mdp3-color
> > > >
> > > > How come this one is a "mdp3" not a "disp"?
> > >
> > > I don't know what mdp3 means & googling gives me no answers.
> > > What's
> > > the
> > > "disp" one controlled by, since it isn't controlled by mdp3?
> > >
> >
> > Hi Conor,
> >
> > Mediatek's Media Data Path ver.3 (MDP3) is associated with MMSYS
> > and
> > acts as an independent driver that operates between VDEC and DISP.
> > By controlling multiple components, it carries out tasks like
> > converting color formats, resizing, and applying specific Picture
> > Quality (PQ) effects.
> > The driver can be found at "driver/media/platform/mediatek/mdp3".
> > Since the same hardware components are configured in both MDP3 and
> > DISP, considering previous discussions, I attemped to integrate
> > into a
> > single binding, named after the controlling user.
>
> I'm still kinda struggling to understand this. Do you mean that the
> hardware can be controlled by either of the disp and mdp3 drivers,
> and
> a compatible containing "disp" would use one driver, and one
> containing
> "mdp3" would use another?
>
Hi Conor,
Sorry for any confusion caused by the software information. In the
video pipeline, after decoding, the data flows sequentially through two
subsystems: MDP and DISP. Each subsystems has multiple IPs, with some
serving the same functionality as COLOR mentioned here. However, these
IPs cannot be controlled by different subsystems. Therefore, I included
the name of the subsystem after SoC to identify the configuration's
location. Is this approach feasible?
Sincerely,
Moudy
Powered by blists - more mailing lists