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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
