On Mon, Feb 23, 2015 at 09:22:56AM +0100, Volker Vogelhuber wrote: > > On 22.02.2015 12:52, Daniel Vetter wrote: > >On Mon, Feb 16, 2015 at 01:43:07PM +0100, Volker Vogelhuber wrote: > >>I'm currently trying to setup a rendering pipe on an Intel Baytrail E3845 > >>cpu. > >>In our product we want to have an FPGA streaming video images to a > >>predefined memory area using bus master dma and render those images using > >>OpenGL. So far this works in a preliminary state. > >>We now have the security requirement that in case the CPU (software/kernel > >>driver) crashes for what ever reason, the GPU display signal should still > >>output at least the video images (obviously any additional render stuff will > >>not be available anymore). My question is now, would it be possible to get > >>the physical address of the DRM front buffer, so that I can provide this > >>address to the FPGA (connected via PCIe) and is it possible to have the GPU > >>still reading the last front buffer for the display output while the FPGA > >>writes to that area. So I would think that the GPU has some kind of DMA > >>engine running, that continuously reading the last front buffer until > >>switched to another buffer by the CPU. So even if the CPU does not control > >>the GPU anymore, it might be possible to have the front buffer updated by > >>the FPGA directly. Of course there will be tearing artefacts as no VSYNC > >>will be available but that wouldn't be an issue so far. > >Just share buffers between your fpga driver and the i915 driver using > >prime/dma-buf and before each pageflip tell your fpga driver to render > >into the new buffer. We don't have any interfaces to tell userspace > >physical addresses of anything, and that's fairly intentional - the kernel > >is and must be in control of memory management. > >-Daniel > Thanks for the reply. I already stumbled across the PRIME way to get access > to the buffer within the source code but it wasn't totally clear to me, how > one would access this API. > I guess one have to call drmPrimeHandleToFD with the /dev/dri/card0 file > descriptor, a gem handle (probably retrieved using gbm_bo_get_handle), > DRM_CLOEXEC and some output variable. > The Prime file descriptor returned, should be usable with the dma-buf API, > right? So I can call dma_buf_get(prime_fd) within the FPGA driver and pass > the sg_table I get from dma_buf_map_attachment to the DMA engine within the > FPGA. > Does this concept work in theory? Or did I miss something? It should work even in practice ;-) And yeah description of the dance looks complete. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
