linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>,
	Laura Abbott <labbott@redhat.com>,
	devel@driverdev.osuosl.org, romlem@google.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	arve@android.com, linux-kernel@vger.kernel.org,
	linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org,
	Riley Andrews <riandrews@android.com>,
	Mark Brown <broonie@kernel.org>,
	Daniel Vetter <daniel.vetter@intel.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
Date: Mon, 6 Mar 2017 11:38:20 +0100	[thread overview]
Message-ID: <20170306103820.ixuvs7fd6s4tvfzy@phenom.ffwll.local> (raw)
In-Reply-To: <10344634.XsotFaGzfj@avalon>

On Fri, Mar 03, 2017 at 06:45:40PM +0200, Laurent Pinchart wrote:
> - I haven't seen any proposal how a heap-based solution could be used in a 
> generic distribution. This needs to be figured out before committing to any 
> API/ABI.

Two replies from my side:

- Just because a patch doesn't solve world hunger isn't really a good
  reason to reject it.

- Heap doesn't mean its not resizeable (but I'm not sure that's really
  your concern).

- Imo ION is very much part of the picture here to solve this for real. We
  need to bits:

  * Be able to allocate memory from specific pools, not going through a
    specific driver. ION gives us that interface. This is e.g. also needed
    for "special" memory, like SMA tries to expose.

  * Some way to figure out how&where to allocate the buffer object. This
    is purely a userspace problem, and this is the part the unix memory
    allocator tries to solve. There's no plans in there for big kernel
    changes, instead userspace does a dance to reconcile all the
    constraints, and one of the constraints might be "you have to allocate
    this from this special ION heap". The only thing the kernel needs to
    expose is which devices use which ION heaps (we kinda do that
    already), and maybe some hints of how they can be generalized (but I
    guess stuff like "minimal pagesize of x KB" is also fulfilled by any
    CMA heap is knowledge userspace needs).

Again I think waiting for this to be fully implemented before we merge any
part is going to just kill any upstreaming efforts. ION in itself, without
the full buffer negotiation dance seems clearly useful (also for stuff
like SMA), and having it merged will help with moving the buffer
allocation dance forward.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  parent reply	other threads:[~2017-03-06 10:40 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-02 21:44 [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott
2017-03-02 21:44 ` [RFC PATCH 01/12] staging: android: ion: Remove dmap_cnt Laura Abbott
2017-03-02 21:44 ` [RFC PATCH 02/12] staging: android: ion: Remove alignment from allocation field Laura Abbott
2017-03-02 21:44 ` [RFC PATCH 03/12] staging: android: ion: Duplicate sg_table Laura Abbott
2017-03-03  8:18   ` Hillf Danton
2017-03-03 18:41     ` Laura Abbott
2017-03-02 21:44 ` [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping Laura Abbott
2017-03-03 11:04   ` Dan Carpenter
2017-03-03 11:58     ` Eric Engestrom
2017-03-03 16:37   ` Laurent Pinchart
2017-03-03 18:40     ` Laura Abbott
2017-03-02 21:44 ` [RFC PATCH 05/12] staging: android: ion: Remove page faulting support Laura Abbott
2017-03-02 21:44 ` [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support Laura Abbott
2017-03-03  9:56   ` Daniel Vetter
2017-03-03 16:39     ` Laurent Pinchart
2017-03-03 18:46       ` Laura Abbott
2017-03-06 10:29         ` Daniel Vetter
2017-03-06 17:00           ` Emil Velikov
2017-03-06 19:20             ` Laura Abbott
2017-03-02 21:44 ` [RFC PATCH 07/12] staging: android: ion: Remove old platform support Laura Abbott
2017-03-03 10:31   ` Daniel Vetter
2017-03-02 21:44 ` [RFC PATCH 08/12] cma: Store a name in the cma structure Laura Abbott
2017-03-10  8:53   ` Sumit Semwal
2017-03-17 18:02     ` Laura Abbott
2017-03-02 21:44 ` [RFC PATCH 09/12] cma: Introduce cma_for_each_area Laura Abbott
2017-03-02 21:44 ` [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Laura Abbott
2017-03-03 16:41   ` Laurent Pinchart
2017-03-03 18:50     ` Laura Abbott
2017-03-06 10:32       ` Daniel Vetter
2017-03-06 13:43         ` Laurent Pinchart
2017-03-06 15:52           ` Daniel Vetter
2017-03-06 19:14             ` Laura Abbott
2017-03-02 21:44 ` [RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable Laura Abbott
2017-03-03 10:33   ` Daniel Vetter
2017-03-03 19:10     ` Laura Abbott
2017-03-02 21:44 ` [RFC PATCH 12/12] staging; android: ion: Enumerate all available heaps Laura Abbott
2017-03-03 10:39   ` Daniel Vetter
2017-03-03 10:04 ` [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter
2017-03-03 10:27   ` Daniel Vetter
2017-03-03 12:54     ` Benjamin Gaignard
2017-03-03 16:45   ` Laurent Pinchart
2017-03-03 19:16     ` Laura Abbott
2017-03-06 10:38     ` Daniel Vetter [this message]
2017-03-06 15:02       ` Laurent Pinchart
2017-03-06 16:01         ` Daniel Vetter
2017-03-03 13:29 ` Michal Hocko
2017-03-03 17:37   ` Laura Abbott
2017-03-06  7:42     ` Michal Hocko
2017-03-06 10:40       ` Daniel Vetter
2017-03-06 10:58         ` Mark Brown
2017-03-06 16:04           ` Daniel Vetter
2017-03-09 10:00             ` Benjamin Gaignard
2017-03-09 17:38               ` Laura Abbott
2017-03-10 10:31                 ` Brian Starkey
2017-03-10 11:46                   ` Robin Murphy
2017-03-10 14:27                     ` Brian Starkey
2017-03-10 16:46                       ` Laura Abbott
2017-03-10 12:40                   ` Daniel Vetter
2017-03-10 13:56                     ` Rob Clark
2017-03-12 13:34                 ` Benjamin Gaignard
2017-03-12 19:05                   ` Daniel Vetter
2017-03-13 21:09                     ` Laura Abbott
2017-03-13 21:29                       ` Rob Clark
2017-03-13 21:59                         ` Laura Abbott
2017-03-14 14:47                       ` Benjamin Gaignard
2017-03-14 19:45                         ` Laura Abbott
2017-03-14 20:28                         ` Nicolas Dufresne
2017-03-13 10:54                   ` Brian Starkey
2017-03-13 13:21                     ` Mark Brown
2017-03-13 21:45                       ` Laura Abbott
2017-03-13 21:29                     ` Laura Abbott
2017-03-06 13:34         ` Michal Hocko
2017-03-03 16:25 ` Laurent Pinchart
2017-03-03 19:14   ` Laura Abbott

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=20170306103820.ixuvs7fd6s4tvfzy@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=arve@android.com \
    --cc=broonie@kernel.org \
    --cc=daniel.vetter@intel.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=labbott@redhat.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riandrews@android.com \
    --cc=romlem@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).