"Ong, Hean Loong" <hean.loong.ong@xxxxxxxxx> writes: > On Thu, 2017-05-04 at 10:11 -0700, Eric Anholt wrote: >> "Ong, Hean Loong" <hean.loong.ong@xxxxxxxxx> writes: >> >> > >> > On Wed, 2017-05-03 at 13:28 -0700, Eric Anholt wrote: >> > > >> > > hean.loong.ong@xxxxxxxxx writes: >> > > >> > > > >> > > > >> > > > From: Ong Hean Loong <hean.loong.ong@xxxxxxxxx> >> > > > >> > > > Hi, >> > > > >> > > > The new Intel Arria10 SOC FPGA devkit has a Display Port IP >> > > > component >> > > > which requires a new driver. This is a virtual driver in which >> > > > the >> > > > FGPA hardware would enable the Display Port based on the >> > > > information >> > > > and data provided from the DRM frame buffer from the OS. >> > > > Basically >> > > > all >> > > > all information with reagrds to resolution and bits per pixel >> > > > are >> > > > pre-configured on the FPGA design and these information are fed >> > > > to >> > > > the driver via the device tree information as part of the >> > > > hardware >> > > > information. >> > > I started reviewing the code, but I want to make sure I >> > > understand >> > > what's going on: >> > > >> > > This IP core isn't displaying contents from system memory on some >> > > sort >> > > of actual physical display, right? It's a core that takes some >> > > input >> > > video stream (not described in the DT or in this driver) and >> > > stores >> > > it >> > > to memory? >> > If the IP Core you are referring to is some form of GPU then in >> > this >> > case we are using the Intel FPGA Display Port Framebuffer IP. It >> > does >> > display contents streamed from the ARM/Linux system to the Display >> > Port >> > of the physical Monitor. >> > >> > Below a simple illustration of the system: >> > >> > ARM/Linux --DMA-->Intel FPGA Display Port Framebuffer IP >> > | >> > | >> > Physical Connection >> > Display Port >> The "DMA" in this diagram is the frame reader IP, right? The frame >> reader, as described in the spec, sounds approximately like a DRM >> plane, >> so if you have that in your system then that needs to be part of this >> DRM driver (otherwise you won't be putting the right things on the >> screen!). > > Would the drm_simple_display_pipe_init be able to handle this ? It > seems to be displaying the proper images on screen, based on my current > changes. There were recommendations to use the > drm_simple_display_pipe_init instead of creating the CRTC and planes > myself The docs I've read for the Frame Buffer IP don't fit into any current DRM component, since it's what we're currently calling a "writeback connector". I don't understand your system enough to answer. You didn't answer if the "DMA" block you diagrammed was the frame reader IP (or maybe the frame reader IP comes after). I also don't see how the frame buffer IP could possibly be connected directly to a physical display connector.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
