From: "Ong, Hean Loong" <hean.loong.ong@intel.com>
To: "laurent.pinchart@ideasonboard.com" <laurent.pinchart@ideasonboard.com>
Cc: "dinguyen@kernel.org" <dinguyen@kernel.org>,
"rdunlap@infradead.org" <rdunlap@infradead.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"Vetter, Daniel" <daniel.vetter@intel.com>
Subject: Re: [PATCHv6 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite
Date: Thu, 24 Aug 2017 05:41:50 +0000 [thread overview]
Message-ID: <1503553309.2102.9.camel@intel.com> (raw)
In-Reply-To: <2093746.zMPb9cMisI@avalon>
Hi Laurent,
I removed the examples for the HDMI in the draft below. The connections
between the VIP and Display Port IP or any display connector are
determined by HW logic. There are currently no SW defined encoders or
connectors that is connected to the AVALON-ST other than the Intel VIP
Frame Buffer II. Therefore there are no examples for the Display Port
encoder and connector.
On Mon, 2017-08-21 at 08:09 +0300, Laurent Pinchart wrote:
> Hi Hean Loong,
>
> On Monday, 21 August 2017 04:40:09 EEST Ong, Hean Loong wrote:
> >
> > On Fri, 2017-08-18 at 16:11 +0300, Laurent Pinchart wrote:
> > >
> > > On Friday 18 Aug 2017 08:34:44 Ong, Hean Loong wrote:
> > > >
> > > >
> > > > Hi Laurent,
> > > > Thanks for the comments, I drafted a copy of the DT bindings
> > > > based
> > > > on your recommendations and inputs. I inserted the changes
> > > > below the
> > > > previous comments.
> > > [snip]
> > >
> > > >
> > > >
> > > > Intel Video and Image Processing(VIP) Frame Buffer II bindings
> > > >
> > > > Supported hardware: Intel FPGA SoC Arria10 and above with
> > > > display
> > > > portIP
> > > >
> > > > The Video Frame Buffer II in Video Image Processing (VIP) suite
> > > > is
> > > > an IP core that interfaces between system memory and Avalon-ST
> > > > video
> > > > ports. The IP core can be configured to support the memory
> > > > reader (from
> > > > memory to Avalon-ST) and/or memory writer (from Avalon-ST to
> > > > memory)
> > > > interfaces.
> > > >
> > > > Connections between the Frame Buffer II and other video IP
> > > > cores in
> > > > the system are modelled using the OF graph DT bindings. The
> > > > Frame
> > > > Buffer II node has up to two OF graph ports. When the memory
> > > > writer
> > > > interface is enabled, port 0 maps to the Avalon-ST Input (din)
> > > > port.
> > > > When the memory reader interface is enabled, port 1 maps to the
> > > > Avalon-
> > > > ST Output (dout) port.
> > > >
> > > > More information the FPGA video IP component can be acquired
> > > > from
> > > > https://www.altera.com/content/dam/altera-www/global/en_US/pdfs
> > > > \
> > > > /literature/ug/ug_vip.pdf
> > > >
> > > > New bindings:
> > > > =============
> > > How are the bindings "new" ? You can omit that title.
> > Noted.
> >
> > >
> > > >
> > > >
> > > > Required properties:
> > > > ----------------------------
> > > > - compatible: "altr,vip-frame-buffer-2.0"
> > > > - reg: Physical base address and length of the framebuffer
> > > > controller's registers.
> > > > - altr,max-width: The maximum width of the framebuffer in
> > > > pixels.
> > > > - altr,max-height: The maximum height of the framebuffer in
> > > > pixels.
> > > > - altr,mem-port-width = the bus width of the avalon master
> > > > port
> > > > on the frame reader
> > > You need to mention the ports here as they are mandatory. I would
> > > move the second paragraph from the introduction to here. You
> > > should also
> > > refer to the file defining the OF graph DT bindings. You can find
> > > examples
> > > in other DT bindings.
> > Noted
> >
> > >
> > > >
> > > >
> > > > Example:
> > > > ----------------------------
> > > > +-----+ +-----------+ +------------+ +---------
> > > > --+
> > > > | D | | Frame | | DP/HDMI TX | |
> > > > DP/HDMI |
> > > > | D |----->| Buffer II |----->| Controller |----->|
> > > > Connector |
> > > > | R | | | | | |
> > > > |
> > > > +-----+ +-----------+ +------------+ +---------
> > > > --+
> > > >
> > > > framebuffer@100000280 {
> > > > compatible = "altr,vip-frame-buffer-2.0";
> > > > reg = <0x00000001 0x00000280 0x00000040>;
> > > > altr,max-width = <1280>;
> > > > altr,max-height = <720>;
> > > > altr,mem-port-width = <128>;
> > > >
> > > > ports {
> > > > #address-cells = <1>;
> > > > #size-cells = <0>;
> > > >
> > > > port@1 {
> > > > reg = <1>;
> > > > fb_output: endpoint {
> > > > remote-endpoint =
> > > > <&dp_encoder_input>;
> > > > };
> > > > };
> > > > };
> > > > };
> > > >
> > > > If there is a need to scale the Frame Buffer II IP cores in
> > > > the pipeline, each node would have its own node, connected
> > > > through ports and endpoints.
> > > >
> > > > hdmi-encoder@......... {
> > > > compatible = "altr,hdmi-tx-16.0";
> > > This was just an example, please use the real compatible string
> > > of
> > > the HDMI controller (and please submit DT bindings for the HDMI
> > > controller
> > > :-)). Please also fill the reg property with values from a real
> > > example.
> > I was trying to get overall picture to be correct before I proceed
> > further. We currently do not have support for HDMI therefore I
> > would
> > omit this until a HDMI IP is available. The only values are
> > available
> > for the Display Port.
> No problem. In that case the best option is to replace the HDMI
> encoder with a
> DisplayPort encoder in the example.
>
> >
> > >
> > > >
> > > > reg = <.....>;
> > > > /* Other IP-specific properties here */
> > > >
> > > > ports {
> > > > #address-cells = <1>;
> > > > #size-cells = <0>;
> > > >
> > > > port@0 {
> > > > reg = <0>;
> > > > hdmi_tx_input: endpoint {
> > > > remote-endpoint = <&fb_output>;
> > > > };
> > > > };
> > > >
> > > > port@1 {
> > > > reg = <1>;
> > > > hdmi_tx_output: endpoint {
> > > > remote-endpoint =
> > > > <&hdmi_conn_input>;
> > > > };
> > > > };
> > > > };
> > > > };
> > > >
> > > > hdmi-connector@0 {
> > > > compatible = "hdmi-connector";
> > > > type = "a";
> > > >
> > > > port {
> > > > hdmi_conn_input: endpoint {
> > > > remote-endpoint = <&hdmi_tx_output>;
> > > > };
> > > > };
> > > > };
>
Intel Video and Image Processing(VIP) Frame Buffer II bindings
Supported hardware: Intel FPGA SoC Arria10 and above with display port
IP
The Video Frame Buffer II in Video Image Processing (VIP) suite is an
IP core
that interfaces between system memory and Avalon-ST video ports. The IP
core
can be configured to support the memory reader (from memory to Avalon-
ST)
and/or memory writer (from Avalon-ST to memory) interfaces.
More information the FPGA video IP component can be acquired from
https://www.altera.com/content/dam/altera-www/global/en_US/pdfs\
/literature/ug/ug_vip.pdf
DT-Bindings:
=============
Required properties:
----------------------------
- compatible: "altr,vip-frame-buffer-2.0"
- reg: Physical base address and length of the framebuffer controller's
registers.
- altr,max-width: The maximum width of the framebuffer in pixels.
- altr,max-height: The maximum height of the framebuffer in pixels.
- altr,mem-port-width = the bus width of the avalon master port
on the frame reader
Connections between the Frame Buffer II and other video IP cores in the
system
are modelled using the OF graph DT bindings. The Frame Buffer II node
has up
to two OF graph ports. When the memory writer interface is enabled,
port 0
maps to the Avalon-ST Input (din) port. When the memory reader
interface is
enabled, port 1 maps to the Avalon-ST Output (dout) port.
If there is a need to scale the Frame Buffer II IP cores in
the pipeline, each node would have its own node, connected
through ports and endpoints.
Currently only a Display Port IP input endpoint is supported.
Port 0 Port1
---------------------------------------------------------
ARRIA10 AVALON_ST (DIN) AVALON_ST (DOUT)
Example:
----------------------------
+-----+ +-----------+ +------------+ +-----------+
| D | | Frame | | DP/HDMI TX | | DP/HDMI |
| D |----->| Buffer II |----->| Controller |----->| Connector |
| R | | | | | | |
+-----+ +-----------+ +------------+ +-----------+
framebuffer@100000280 {
compatible = "altr,vip-frame-buffer-2.0";
reg = <0x00000001 0x00000280 0x00000040>;
altr,max-width = <1280>;
altr,max-height = <720>;
altr,mem-port-width = <128>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@1 {
reg = <1>;
fb_output: endpoint {
remote-endpoint = <&dp_encoder_input>;
};
};
};
};
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-08-24 5:41 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-11 6:49 [PATCHv6 0/3] Hean-Loong, Ong
2017-08-11 6:49 ` Hean-Loong, Ong
2017-08-11 6:49 ` Hean-Loong, Ong
2017-08-11 6:49 ` [PATCHv6 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite Hean-Loong, Ong
2017-08-11 6:49 ` Hean-Loong, Ong
2017-08-17 15:22 ` Rob Herring
2017-08-17 15:22 ` Rob Herring
2017-08-17 15:22 ` Rob Herring
2017-08-18 0:56 ` Ong, Hean Loong
2017-08-18 0:56 ` Ong, Hean Loong
2017-08-18 0:56 ` Ong, Hean Loong
2017-08-11 6:49 ` [PATCHv6 2/3] ARM:socfpga-defconfig " Hean-Loong, Ong
2017-08-11 6:49 ` Hean-Loong, Ong
2017-08-11 6:49 ` [PATCHv6 3/3] ARM:drm ivip " Hean-Loong, Ong
2017-08-11 6:49 ` Hean-Loong, Ong
2017-08-11 6:49 ` Hean-Loong, Ong
2017-08-11 15:21 ` Randy Dunlap
2017-08-11 15:21 ` Randy Dunlap
2017-08-14 2:27 ` Ong, Hean Loong
2017-08-14 2:27 ` Ong, Hean Loong
2017-08-14 2:27 ` Ong, Hean Loong
[not found] ` <2740499.pDDaZTb32r@avalon>
[not found] ` <1503045283.2075.8.camel@intel.com>
2017-08-18 13:11 ` [PATCHv6 1/3] ARM:dt-bindings " Laurent Pinchart
2017-08-21 1:40 ` Ong, Hean Loong
2017-08-21 5:09 ` Laurent Pinchart
2017-08-24 5:41 ` Ong, Hean Loong [this message]
2017-08-24 9:39 ` Laurent Pinchart
2017-08-25 1:21 ` Ong, Hean Loong
2017-08-25 9:32 ` Laurent Pinchart
2017-08-28 5:06 ` Ong, Hean Loong
2017-09-04 6:09 ` Ong, Hean Loong
2017-09-12 22:47 ` Laurent Pinchart
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=1503553309.2102.9.camel@intel.com \
--to=hean.loong.ong@intel.com \
--cc=daniel.vetter@intel.com \
--cc=dinguyen@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=rdunlap@infradead.org \
--cc=robh+dt@kernel.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.