dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* [RFC][PATCH 0/3] dmabuf heaps: system uncached and cma uncached heaps
@ 2021-01-20 21:09 John Stultz
  2021-01-20 21:09 ` [PATCH 1/3] dma-buf: dma-heap: Keep track of the heap device struct John Stultz
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: John Stultz @ 2021-01-20 21:09 UTC (permalink / raw)
  To: lkml
  Cc: dri-devel, Bing Song, Sandeep Patil, Chris Goldsworthy,
	Ezequiel Garcia, Robin Murphy, James Jones, Liam Mark,
	Laura Abbott, Hridya Valsaraju, Ørjan Eide, linux-media,
	Suren Baghdasaryan, Daniel Mentz

After the last round submitting the system-uncached heap, I got
some feedback that Daniel would like to see it demonstrated with
a mesa based system. I'm still working on such a gralloc
implementation (using the db845c), but along with other work, so
I don't yet have something to share there. 

However, Bing Song reached out and was interested in having a
uncached variant for the CMA heap as well, and he shared this
patch providing an initial implementation.

This gave me some hesitation with regards to the earlier
discussion around what sort of attributes would be useful for
the flags field of the allocation IOCTL.

In earlier discussions, folks seemed happy to provide the
uncached system heap functionality as its own heap chardev, as
it seemed uncertain that the uncached attribute would truely be
generic across all heaps. 

But with Bing's patch, it seems like it may be generically useful,
and utilizing a flag might be a bit cleaner then adding lots of
duplicative heap names postfixed with "-uncached".

So I wanted to re-submit both of these together to reopen that
discussion on the question of if a BUF_FLAG_UNCACHED flag would
make sense, or if folks still think separate heap chardevs is
the way to go.

thanks
-john

Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Liam Mark <lmark@codeaurora.org>
Cc: Laura Abbott <labbott@kernel.org>
Cc: Brian Starkey <Brian.Starkey@arm.com>
Cc: Hridya Valsaraju <hridya@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Sandeep Patil <sspatil@google.com>
Cc: Daniel Mentz <danielmentz@google.com>
Cc: Chris Goldsworthy <cgoldswo@codeaurora.org>
Cc: Ørjan Eide <orjan.eide@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Ezequiel Garcia <ezequiel@collabora.com>
Cc: Simon Ser <contact@emersion.fr>
Cc: James Jones <jajones@nvidia.com>
Cc: Bing Song <bing.song@nxp.com>
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org

Bing Song (1):
  dma-buf: cma_heap: Add a cma-uncached heap re-using the cma heap

John Stultz (2):
  dma-buf: dma-heap: Keep track of the heap device struct
  dma-buf: system_heap: Add a system-uncached heap re-using the system
    heap

 drivers/dma-buf/dma-heap.c          |  33 ++++++--
 drivers/dma-buf/heaps/cma_heap.c    | 119 +++++++++++++++++++++++++---
 drivers/dma-buf/heaps/system_heap.c | 111 ++++++++++++++++++++++----
 include/linux/dma-heap.h            |   9 +++
 4 files changed, 236 insertions(+), 36 deletions(-)

-- 
2.17.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-01-20 21:09 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-20 21:09 [RFC][PATCH 0/3] dmabuf heaps: system uncached and cma uncached heaps John Stultz
2021-01-20 21:09 ` [PATCH 1/3] dma-buf: dma-heap: Keep track of the heap device struct John Stultz
2021-01-20 21:09 ` [PATCH 2/3] dma-buf: system_heap: Add a system-uncached heap re-using the system heap John Stultz
2021-01-20 21:09 ` [PATCH 3/3] dma-buf: cma_heap: Add a cma-uncached heap re-using the cma heap John Stultz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).