Linux Media Controller development
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Gustavo Padovan <gustavo@padovan.org>,
	linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH 04/15] dma-fence: Make ->wait callback optional
Date: Fri, 4 May 2018 10:17:22 +0200	[thread overview]
Message-ID: <20180504081722.GQ12521@phenom.ffwll.local> (raw)
In-Reply-To: <152542135089.4767.3315686184618150713@mail.alporthouse.com>

On Fri, May 04, 2018 at 09:09:10AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2018-05-03 15:25:52)
> > Almost everyone uses dma_fence_default_wait.
> > 
> > v2: Also remove the BUG_ON(!ops->wait) (Chris).
> 
> I just don't get the rationale for implicit over explicit.

Closer approximation of dwim semantics. There's been tons of patch series
all over drm and related places to get there, once we have a big pile of
implementations and know what the dwim semantics should be. Individually
they're all not much, in aggregate they substantially simplify simple
drivers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2018-05-04  8:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180503142603.28513-1-daniel.vetter@ffwll.ch>
2018-05-03 14:25 ` [PATCH 02/15] dma-fence: Make ->enable_signaling optional Daniel Vetter
2018-05-03 15:51   ` Chris Wilson
2018-05-04 14:10   ` [PATCH] " Daniel Vetter
2018-05-07  9:35     ` Maarten Lankhorst
2018-05-03 14:25 ` [PATCH 03/15] dma-fence: Allow wait_any_timeout for all fences Daniel Vetter
2018-05-03 14:25 ` [PATCH 04/15] dma-fence: Make ->wait callback optional Daniel Vetter
2018-05-04  8:09   ` Chris Wilson
2018-05-04  8:17     ` Daniel Vetter [this message]
2018-05-04  8:23       ` Daniel Vetter
     [not found]         ` <152542269311.4767.4254637128660397977@mail.alporthouse.com>
2018-05-04  8:57           ` Daniel Vetter
     [not found]             ` <152542538170.4767.9925437389288286145@mail.alporthouse.com>
2018-05-04  9:25               ` Daniel Vetter
2018-05-04 13:17                 ` Christian König
2018-05-04 13:47                   ` Daniel Vetter
2018-07-02  8:23                     ` Daniel Vetter
2018-07-02  8:49                       ` Christian König
2018-05-03 14:26 ` [PATCH 15/15] dma-fence: Polish kernel-doc for dma-fence.c Daniel Vetter
2018-05-04 14:06   ` [PATCH] " Daniel Vetter

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=20180504081722.GQ12521@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo@padovan.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.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