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

[Noralf Trønnes]

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.