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@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.
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;
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
