On Sat, Dec 5, 2015 at 3:40 PM, Rob Herring <robh@xxxxxxxxxx> wrote: > On Fri, Dec 4, 2015 at 5:48 PM, Greg Hackmann <ghackmann@xxxxxxxxxx> wrote: >> 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. > > Yes, I realize dumb BO are not the long term nor production solution. > ATM, I'm just looking for getting things working on new platforms > without the need for lots of userspace changes. Perhaps I could just > use fb emulation, but having DRM code paths tested is valuable IMO. > >> 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. > > Laura is working on that. I'm still a bit skeptical about what should > go in DT though. > >> 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. > > I've not seen that. Where does that live? https://android.googlesource.com/platform/bootable/recovery/+/1a92c4458dcc983f624a60fb75f9679c213e6814 Stéphane > > Rob > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
