Noralf Trønnes <noralf@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?

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.