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