[PATCH] drm: enable render nodes wherever buffer sharing is supported

[Daniel Vetter]

On Thu, Apr 30, 2020 at 12:30 PM Brian Starkey <brian.starkey at arm.com> wrote:
>
> On Wed, Apr 29, 2020 at 06:31:01PM +0100, Liviu Dudau wrote:
> > On Wed, Apr 29, 2020 at 09:51:19AM -0700, Peter Collingbourne wrote:
> > > On Wed, Apr 29, 2020 at 9:17 AM Brian Starkey <brian.starkey at arm.com> wrote:
> > > >
> > > > Hi Peter,
> > > >
> > > > On Mon, Apr 27, 2020 at 01:05:13PM -0700, Peter Collingbourne wrote:
> > > > > Render nodes are not just useful for devices supporting GPU hardware
> > > > > acceleration. Even on devices that only support dumb frame buffers,
> > > > > they are useful in situations where composition (using software
> > > > > rasterization) and KMS are done in different processes with buffer
> > > > > sharing being used to send frame buffers between them. This is the
> > > > > situation on Android, where surfaceflinger is the compositor and the
> > > > > composer HAL uses KMS to display the buffers. Thus it is beneficial
> > > > > to expose render nodes on all devices that support buffer sharing.
> > > >
> > > > If I understand your problem right, the issue is that you're getting
> > > > your buffers in minigbm via pl111, which means you want a render node
> > > > just for buffer allocation? Then HWComposer will import those on the
> > > > primary node for displaying.
> > >
> > > Correct.
> > >
> > > > I'm not at all familiar with how minigbm sits in Android, but on our
> > > > platforms where the Display and GPU devices are different, we allocate
> > > > via ion in Gralloc, and import those into both the GPU and Display.
> > > > I think that should work on pl111 too - if you can allocate contiguous
> > > > memory from ion (or dma-buf heaps) in minigbm, then you don't need the
> > > > render node.
> > >
> > > Those contiguous memory regions would not necessarily be compatible
> > > with the pl111 device as far as I know -- according to [1], on some
> > > devices, a designated memory region must be used for the framebuffer
> > > and therefore the memory region allocated in CMA would not be
> > > compatible. That being said, FVP doesn't appear to be one of those
> > > devices, so in principle that might work for FVP (provided that the
> > > user provides a sufficiently large cma=X kernel command line
> > > argument), but not for those other devices.
>
> Yeah I'd be surprised if FVP cares about anything other than it being
> contiguous.
>
> My understanding of how "most" Android devices implement this is to
> have ion heaps representing whatever dedicated memory regions there
> are. Gralloc can then pick the appropriate one based on the gralloc
> usage flags. So allocations wouldn't go via the DRM driver.
>
> It looks like the checks in pl111 can't support that usage model if
> use_device_memory is set (though that wouldn't matter on FVP).
>
> >
> > We have been doing that with mali-dp drivers for years. Because most of
> > our dev environments are on FPGAs, we needed to use the local RAM on
> > those boards so we've had to assign a memory region to the driver that
> > in turn was using CMA. We've made heavy use of 'reserved-memory' and
> > 'memory-region' nodes in the DT to link the two together, but things
> > worked out quite well. Because the 'reserved-memory' sub-node was marked
> > as 'compatible="shared-dma-pool"', gralloc and ION could be used to
> > allocate memory from it.
>
> This is a little imperfect because ion doesn't have a way to access
> the `dev` pointer needed to allocate from device-attached CMA regions,
> so some hackery is required.
>
> I think dma-heaps would let you expose device-specific CMA regions.

The plan was that each device in sysfs which needs special dma memory
would have a pointer to the corresponding dma-heap. That way userspace
knows where to allocate. Just need some userspace to use these, and
kernel patch to expose those links. I think it's defacto already there
through the dma pointers of struct device.
-Daniel

>
> Even if you did that and allocated from the right place, the check
> in pl111 would reject any attempt to import it if it's set to
> use_device_memory.
>
> I don't know if there's a better way to tell if the memory is
> compatible, but that check seems like a bit of a sledgehammer. It
> looks like it not only forces the memory to be from the right place,
> it also forces it to have been allocated via pl111.
>
> On FVP though, I reckon any old CMA memory should be fine.
>
> Cheers,
> -Brian
>
> >
> > Best regards,
> > Liviu
> >
> > >
> > > Peter
> > >
> > > [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/display/arm%2Cpl11x.txt
> >
> > --
> > ====================
> > | I would like to |
> > | fix the world,  |
> > | but they're not |
> > | giving me the   |
> >  \ source code!  /
> >   ---------------
> >     ¯\_(ツ)_/¯
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch