Re: [PATCHv6 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel