[RFC 0/5] drm: Add support for tiny LCD displays

[Noralf Trønnes]

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;