On Thu, May 11, 2017 at 02:50:41AM +0000, Ong, Hean Loong wrote: > On Tue, 2017-05-09 at 09:40 -0700, Eric Anholt wrote: > > "Ong, Hean Loong" <hean.loong.ong@xxxxxxxxx> writes: > > > > > > > > On Mon, 2017-05-08 at 09:03 -0700, Eric Anholt wrote: > > > > > > > > "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". > > > > > > > While running my own test (since the intel-gpu-tools doesn't seems > > > applicable.) The drm_simple_display_pipe_init seems to be simple > > > enough > > > for displaying a matchbox console. The use case for this driver is > > > only > > > part of the enablemennt of the reference design board so that users > > > of > > > the Arria10 devkit can use this as base for their own designs. > > > > > > > > > > > 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. > > > The FPGA FrameBuffer 2 soft IP reads the information provided to it > > > from the Linux Kernel via the platform device register provided in > > > the > > > DT. The Linux driver here allocates a chunk of coherent memory that > > > directly maps to the SDRAM. The FPGA soft IP would stream the > > > display > > > out to the Display Port based on the information that was written > > > to > > > the SDRAM. > > Your "FPGA soft IP" that's reading pixels from an area of memory (a > > DRM > > plane does this) and outputting that to a display port (a DRM CRTC > > and > > encoder does this) would make a lot of sense as a DRM driver. > > > > However, this piece of hardware that takes in pixels in a stream from > > elsewhere and stores it to memory doesn't make sense to me as a DRM > > driver. > > > > I can't really offer more advice until I understand what's generating > > the pixels that the FrameBuffer IP is storing. > > My previous explanation might have been confusing here. I apologize for > that. > To put it in simpler terms the FPGA FrameBuffer Soft IP could be seen > as the GPU and the DRM driver patch here is allocating memory for > information to be streamed from the ARM/Linux to the display port. > Basically the driver just wraps the information such as the pixels to > be drawn by the FPGA FrameBuffer 2. > > The piece of hardware in discussion is the SoC FPGA where Linux runs on > the ARM chip and the FGPA is driven by its NIOS soft core with its own > proprietary firmware. > > For example the application from the ARM Linux would have to write > information on the /dev/fb0 with the information stored in the SDRAM to > be fetched by the FPGA framebuffer IP and displayed on the Display Port > Monitor. Ah ok, this sounds like it's indeed suitable for drm. Thanks for clearing up the confusion ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
