On Sat, Mar 26, 2016 at 08:11:08PM +0100, Noralf Trønnes wrote:
>
> 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;
sg table is supposed to be for device dma, for kernel access either use
vmap or the kmap functions dma-buf provides. Since no one yet bothered
with kmap I'd just go with vmap ;-)
The reason for this split is that the dma-buf might wrap something that's
totally not normal memory (not struct page backed at least) and hence
kernel mmmaps need special attention.
-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
