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@xxxxxxxxxxx> 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.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
