public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: daniel@ffwll.ch, dri-devel@lists.freedesktop.org,
	sumit.semwal@linaro.org, linaro-mm-sig@lists.linaro.org,
	linux-media@vger.kernel.org, intel-gfx@lists.freedesktop.org
Subject: Dynamic DMA-buf locking changes
Date: Thu, 29 Aug 2019 16:29:13 +0200	[thread overview]
Message-ID: <20190829142917.13058-1-christian.koenig@amd.com> (raw)

Hi everyone,

since upstreaming the full dynamic DMA-buf changes turned out more problematic than previously thought I've reverted back to individual patches and separated out only the locking changes.

So this patch does NOT contain any new callbacks for pinning/unpinning and move notification, but only the locking changes necessary.

As previously discussed when the framework detects that the locking semantics between exporter and importer are different it just falls back to using a cached sgt created during attach time.

While separating the patch set I've most likely stumbled over the problem why this previously raised some lockdep warning with i915, it turned out to be just a might_lock() at the wrong place.

Please review and/or comment,
Christian.



             reply	other threads:[~2019-08-29 14:29 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-29 14:29 Christian König [this message]
2019-08-29 14:29 ` [PATCH 1/4] dma-buf: change DMA-buf locking convention Christian König
2019-09-03  8:05   ` Daniel Vetter
2019-09-11 10:53     ` Christian König
2019-09-16 12:23       ` Christian König
2019-09-17 12:31         ` Daniel Vetter
2019-09-17 12:40           ` Koenig, Christian
2019-09-17 13:13             ` Daniel Vetter
2019-09-17 13:24               ` Koenig, Christian
2019-09-17 13:45                 ` Daniel Vetter
2019-09-17 14:47                   ` Koenig, Christian
2019-09-17 14:56                     ` Daniel Vetter
2019-09-24  9:51                       ` Koenig, Christian
2019-10-02  8:37                         ` Koenig, Christian
2019-10-08  8:55                           ` Daniel Vetter
2019-10-16 13:46                             ` Koenig, Christian
2019-10-16 14:23                               ` Daniel Vetter
2019-10-17  9:04                                 ` Koenig, Christian
2019-10-08  8:55   ` Daniel Vetter
2019-08-29 14:29 ` [PATCH 2/4] drm/ttm: use the parent resv for ghost objects v2 Christian König
2019-10-08  9:25   ` Daniel Vetter
2019-10-09 13:10     ` Christian König
2019-10-09 14:09       ` Daniel Vetter
2019-08-29 14:29 ` [PATCH 3/4] drm/amdgpu: add independent DMA-buf export v7 Christian König
2019-08-29 14:29 ` [PATCH 4/4] drm/amdgpu: add independent DMA-buf import v8 Christian König

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=20190829142917.13058-1-christian.koenig@amd.com \
    --to=ckoenig.leichtzumerken@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.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