Den 18.03.2016 18:48, skrev Daniel Vetter: > On Thu, Mar 17, 2016 at 11:00:00PM +0100, Noralf Trønnes wrote: >> Den 16.03.2016 19:26, skrev Eric Anholt: >>> Noralf Trønnes <noralf at tronnes.org> writes: >>> >>>> This is an attempt at providing a DRM version of drivers/staging/fbtft. >>>> I'm sending this early before cleaning up the code hoping to get some >>>> feedback in case there are better ways to structure this. >>>> >>>> The tinydrm module provides a very simplified view of DRM for displays that >>>> has onboard video memory and is connected through a slow bus like SPI/I2C. >>>> A driver using tinydrm has to provide a function that will be called from >>>> the dirtyfb ioctl and optionally drm_panel functions which can be used to >>>> set up the display controller and control backlight. >>>> >>>> tinydrm also has fbdev support using fb_deferred_io which is tied in >>>> through >>>> the dirtyfb function call. A driver can use the provided deferred work code >>>> to collect dirtyfb calls and schedule display memory updates if it whishes. >>>> The various display controllers can have library modules that handles >>>> display updates. >>>> Display controllers that have a similar register interface as the MIPI >>>> DBI/DCS >>>> controllers can use the lcdreg module for register access. >>>> >>>> struct tinydrm_device { >>>> struct drm_device *base; >>>> u32 width, height; >>>> struct drm_panel panel; >>>> [...] >>>> int (*dirtyfb)(struct drm_framebuffer *fb, void *vmem, unsigned flags, >>>> unsigned color, struct drm_clip_rect *clips, >>>> unsigned num_clips); >>>> }; >>> This is awesome! >>> >>> I was wondering, have you considered what it would take to DMA >>> framebuffer contents from somewhere in memory to these displays? Does >>> that look doable to you? >> The vast majory of these displays are connected through SPI and the SPI >> subsystem maps the buffers using the DMA streaming API including support >> for vmalloc buffers. I have some more details in my reply to Daniel. >> >>> I'd love to be able to do something PRIME-like where vc4's doing the >>> rendering and we're periodically updating the TFT with the result. >> I think I read somewhere that one drm device could do the rendering and >> another could scan out the buffer. It would be great if this could be done. >> Some use these displays on handhold game emulators and the emulator only >> supports OpenGL or some library needing hw rendering. Currently on the >> Raspberry Pi this is solved by having a program take snapshots of the gpu >> framebuffer and copy this into the fbtft fbdev framebuffer. > Yeah, this is definitely perfect use-case for prime buffer sharing. > CMA/dma buffer support for tinydrm would be great to make this work > seamlessly.
I have looked at cma prime and it looks like vaddr is not set. How do I get the virtual address? drm_prime_fd_to_handle_ioctl -> drm_gem_prime_fd_to_handle -> drm_gem_prime_import -> drm_gem_cma_prime_import_sg_table: cma_obj = __drm_gem_cma_create(dev, attach->dmabuf->size); cma_obj->paddr = sg_dma_address(sgt->sgl); cma_obj->sgt = sgt;