On 12/04/2015 11:23 AM, Rob Herring wrote:
On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard
<benjamin.gaignard@xxxxxxxxxx> wrote:
Hi Rob,
I got the same problem today with sti drm/kms driver and dumb Bo.
The issue comes become hwcomposer because is the master and authenticated on
/dev/dri/cardX
Dumb allocation is done by gralloc which does a new open (so it is not
authenticated) on drm node the consequence is that we can't use prime
functions...
If you use render node you won't be able to call dumb functions.
To get out of this I think I will implement additional helpers in gem_cma to
have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP
and call them instead of dumb so be able to use render node.
Of course it is only for drivers which already use gem_cma helpers (like
sti)
That's only marginally better than per driver BO calls which is the
whole thing I'm trying to avoid. There should be some way to pass the
auth token to gralloc?
Rob
Frankly, you probably want to approach this by allocating dma-bufs using
something external to DRM (probably ion) and then have your hwcomposer
import them into DRM when they're passed to the display.
Backing gralloc allocations with dumb BOs doesn't really fit the way
gralloc is designed: like dma-buf, it's built around passing buffers
between different hardware blocks, and some of those buffers may never
even touch the display hardware. You'll also run up against other
(deliberate) limitations of dumb BOs like not being able to allocate YUV
buffers.
Unfortunately this currently means adding some shim driver code to
create the ion device. (Device-Tree bindings for ion are on my long,
long backlog of things to do.) It's not a lot of code, especially if all
you need is a CMA heap, but it's still non-zero.
Note that supporting dumb BOs in your KMS driver is still useful, since
the recovery console in AOSP has KMS support now. In that case it's a
single privileged process software-rendering everything, so it bypasses
gralloc/hwcomposer and calls directly into libdrm.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
