mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Philipp Stanner <phasta@mailbox.org>
To: "Christian König" <christian.koenig@amd.com>,
	phasta@kernel.org, "Sumit Semwal" <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dma-buf/dma-fence: Mark two callbacks as deprecated
Date: Fri, 25 Sep 2026 10:42:01 +0200	[thread overview]
Message-ID: <7b8942e29f6c714979415a59b42af450afa101e4.camel@mailbox.org> (raw)
In-Reply-To: <c7d9c659-d903-456f-87f2-d75aafb8de3b@amd.com>

On Fri, 2026-09-25 at 10:21 +0200, Christian König wrote:
> Some problems like the locking design are still WIP, but we are
> slowly moving towards that.

The question will be whether we can reach common ground with that one.

> 
> But some problems like parts of the dma_fence uAPI are unfixable
> without time travel.

I would be especially interested in learning about who the party is
that apparently is spinning on dma_fence_is_signaled(), supposedly
preventing us from getting the memory ordering right.

Also learning more about the users that definitely *need* ops-
>signaled() and ops->enable_signaling() would be interesting. drm_sched
users cannot make use of these, since the sched-fence does not pass the
request through to the hardware fence.

So who are the users? Parties like Nouveau implement these callbacks,
but it's not clear whether they actually need them.

(btw, funnily enough, with the Rust-fence design we finally have the
ability to fully support all callbacks with or without a scheduler,
since the need for an intermediate fence disappeared)


P.

      reply	other threads:[~2026-09-25  8:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-23 15:03 Philipp Stanner
2026-09-23 15:13 ` Christian König
2026-09-23 15:27   ` Philipp Stanner
2026-09-23 15:35     ` Christian König
2026-09-24  8:14       ` Philipp Stanner
2026-09-25  8:21         ` Christian König
2026-09-25  8:42           ` Philipp Stanner [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=7b8942e29f6c714979415a59b42af450afa101e4.camel@mailbox.org \
    --to=phasta@mailbox.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=phasta@kernel.org \
    --cc=sumit.semwal@linaro.org \
    /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

all inboxes | Powered by JetHome®