dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: lkml <linux-kernel@vger.kernel.org>
Cc: dri-devel@lists.freedesktop.org, "Bing Song" <bing.song@nxp.com>,
	"Sandeep Patil" <sspatil@google.com>,
	"Chris Goldsworthy" <cgoldswo@codeaurora.org>,
	"Ezequiel Garcia" <ezequiel@collabora.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"James Jones" <jajones@nvidia.com>,
	"Liam Mark" <lmark@codeaurora.org>,
	"Laura Abbott" <labbott@kernel.org>,
	"Hridya Valsaraju" <hridya@google.com>,
	"Ørjan Eide" <orjan.eide@arm.com>,
	linux-media@vger.kernel.org,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Daniel Mentz" <danielmentz@google.com>
Subject: [RFC][PATCH 0/3] dmabuf heaps: system uncached and cma uncached heaps
Date: Wed, 20 Jan 2021 21:09:34 +0000	[thread overview]
Message-ID: <20210120210937.15069-1-john.stultz@linaro.org> (raw)

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

             reply	other threads:[~2021-01-20 21:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20 21:09 John Stultz [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210120210937.15069-1-john.stultz@linaro.org \
    --to=john.stultz@linaro.org \
    --cc=bing.song@nxp.com \
    --cc=cgoldswo@codeaurora.org \
    --cc=danielmentz@google.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ezequiel@collabora.com \
    --cc=hridya@google.com \
    --cc=jajones@nvidia.com \
    --cc=labbott@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=lmark@codeaurora.org \
    --cc=orjan.eide@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=sspatil@google.com \
    --cc=surenb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).