[PATCHv6 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite
Ong, Hean Loong
hean.loong.ong at intel.com
Fri Aug 25 01:21:17 UTC 2017
Hi Laurent,
The encoder resides as a hardware logic as part of the FPGA fabric. The
software driver has no direct access to the encoder. The VIP is created
in such a way that the software i.e Linux Driver only streams data
through the VIP. What happens beyond the VIP Frame buffer directly
boils down to the FGPA logic design that is provided in the dev kit.
In this example the hardware A10 dev kit has a Display Port IP attached
to the VIP therefore from the drivers perspective we only know that the
endpoint is a Display Port
The system design uses the VIP FRame Buffer II as the default display
interface for various FPGA display IP (HDMI/DP). The FPGA bridge design
only provides the drivers to access the VIP.
Note there is also a soft Processor running on the FPGA that drives the
video signal transceivers for the Display Port or any other display
IP.
The encoder used for the Intel FPGA VIP are hardware based therefore
the video device that is concerned here is the VIP Frame Buffer device
which streams data to whatever FPGA display hardware.
To describe the hardware encoder do I need to create it as part of the
device tree node or a explanation of it would suffice ?
On Thu, 2017-08-24 at 12:39 +0300, Laurent Pinchart wrote:
> Hi Hean Loong,
>
> On Thursday, 24 August 2017 08:41:50 EEST Ong, Hean Loong wrote:
> >
> > 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.
> But there must be an encoder, even if its default configuration makes
> it
> usable without a softwarer driver at the moment. As the encoder is
> there in
> hardware, it should be described in DT.
>
More information about the dri-devel
mailing list