[PATCHv6 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Fri Aug 25 09:32:37 UTC 2017
Hello Hean Loon,
On Friday, 25 August 2017 04:21:17 EEST Ong, Hean Loong wrote:
> 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 ?
Regardless of whether the display port encoder is a soft IP or a hard IP, it
should be described in DT as it is there. Obviously it should not be
controlled by the VIP Frame Buffer II driver, but I expect at least some of
the encoders to have registers exposed to the ARM processor running Linux, so
you will need a device driver for them at some point.
--
Regards,
Laurent Pinchart
More information about the dri-devel
mailing list