devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Stultz <jstultz@google.com>
To: Maxime Ripard <mripard@kernel.org>
Cc: "Rob Herring" <robh@kernel.org>,
	"Saravana Kannan" <saravanak@google.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
	"Brian Starkey" <Brian.Starkey@arm.com>,
	"T.J. Mercier" <tjmercier@google.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Mattijs Korpershoek" <mkorpershoek@baylibre.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH 0/8] dma-buf: heaps: Support carved-out heaps and ECC related-flags
Date: Thu, 16 May 2024 10:09:13 -0700	[thread overview]
Message-ID: <CANDhNCqyh2ZKsOyb9rLBpUZZ+VTU8M70XBQC3aC2=G_v8LqciA@mail.gmail.com> (raw)
In-Reply-To: <20240516-truthful-fair-kudu-adb6df@penduick>

On Thu, May 16, 2024 at 5:22 AM Maxime Ripard <mripard@kernel.org> wrote:
> On Wed, May 15, 2024 at 11:42:58AM -0700, John Stultz wrote:
> > I apologize as my worry is mostly born out of seeing vendors really
> > push opaque feature flags in their old ion heaps, so in providing a
> > flags argument, it was mostly intended as an escape hatch for
> > obviously common attributes. So having the first be something that
> > seems reasonable, but isn't actually that common makes me fret some.
> >
> > So again, not an objection, just something for folks to stew on to
> > make sure this is really the right approach.
>
> I understand your hesitation and concern :) Is there anything we could
> provide that would help moving the discussion forward?
>

Mostly I just want to make sure it's discussed, which is why I raise
it as a concern.

Getting APIs right is hard, and I know I've made my share of mistakes
(for instance, a situation that very much echoes this current
question: the *_ALARM clockids probably should have used a flag). So
I've found highlighting the trade-offs and getting other folk's
perspectives useful to avoid such issues.  But I also don't intend to
needlessly delay things.

> > Another thing to discuss, that I didn't see in your mail: Do we have
> > an open-source user of this new flag?
>
> Not at the moment. I guess it would be one of the things that would
> reduce your concerns, but is it a requirement?

So I'd defer to Sima on this. There have been a number of heap
releated changes that have had to be held out of tree on this
requirement, but I'm hoping recent efforts on upstream device support
will eventually unblock those.

thanks
-john

      reply	other threads:[~2024-05-16 17:09 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-15 13:56 [PATCH 0/8] dma-buf: heaps: Support carved-out heaps and ECC related-flags Maxime Ripard
2024-05-15 13:56 ` [PATCH 1/8] dma-buf: heaps: Introduce a new heap for reserved memory Maxime Ripard
2024-05-15 13:56 ` [PATCH 2/8] of: Add helper to retrieve ECC memory bits Maxime Ripard
2024-05-15 13:56 ` [PATCH 3/8] dma-buf: heaps: Import uAPI header Maxime Ripard
2024-05-16  8:14   ` Christian König
2024-05-15 13:56 ` [PATCH 4/8] dma-buf: heaps: Add ECC protection flags Maxime Ripard
2024-05-15 13:57 ` [PATCH 5/8] dma-buf: heaps: system: Remove global variable Maxime Ripard
2024-05-15 13:57 ` [PATCH 6/8] dma-buf: heaps: system: Handle ECC flags Maxime Ripard
2024-05-15 13:57 ` [PATCH 7/8] dma-buf: heaps: cma: " Maxime Ripard
2024-05-16  5:55   ` kernel test robot
2024-05-16 12:48   ` kernel test robot
2024-05-15 13:57 ` [PATCH 8/8] dma-buf: heaps: carveout: " Maxime Ripard
2024-05-15 18:42 ` [PATCH 0/8] dma-buf: heaps: Support carved-out heaps and ECC related-flags John Stultz
2024-05-16 10:56   ` Daniel Vetter
2024-05-16 12:41     ` Maxime Ripard
2024-05-16 16:51     ` John Stultz
2024-05-21 12:06       ` Daniel Vetter
2024-05-22 13:18         ` Maxime Ripard
2024-05-23  9:45           ` Daniel Vetter
2024-06-28 11:29         ` Thierry Reding
2024-06-28 13:08           ` Maxime Ripard
2024-06-28 14:42             ` Thierry Reding
2024-07-04 12:24               ` Maxime Ripard
2024-07-05 14:31                 ` Thierry Reding
2024-07-05 15:35                   ` Daniel Vetter
2024-07-08  7:14                     ` [Linaro-mm-sig] " Christian König
2024-07-11 12:44                       ` Thierry Reding
2024-07-10 12:10                   ` Maxime Ripard
2024-07-11 12:43                     ` Thierry Reding
2024-07-12 10:37                     ` Thierry Reding
2024-05-16 12:21   ` Maxime Ripard
2024-05-16 17:09     ` John Stultz [this message]

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='CANDhNCqyh2ZKsOyb9rLBpUZZ+VTU8M70XBQC3aC2=G_v8LqciA@mail.gmail.com' \
    --to=jstultz@google.com \
    --cc=Brian.Starkey@arm.com \
    --cc=benjamin.gaignard@collabora.com \
    --cc=christian.koenig@amd.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mkorpershoek@baylibre.com \
    --cc=mripard@kernel.org \
    --cc=robh@kernel.org \
    --cc=saravanak@google.com \
    --cc=sumit.semwal@linaro.org \
    --cc=tjmercier@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).