From: Daniel Vetter <daniel@ffwll.ch>
To: christian.koenig@amd.com
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
amd-gfx list <amd-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
Date: Mon, 24 Jun 2019 16:41:05 +0200 [thread overview]
Message-ID: <20190624144105.GR12905@phenom.ffwll.local> (raw)
In-Reply-To: <1d4f3779-8dc8-14ad-4d20-f7ccee7cea53@gmail.com>
On Mon, Jun 24, 2019 at 03:58:00PM +0200, Christian König wrote:
> Am 24.06.19 um 13:23 schrieb Koenig, Christian:
> > Am 21.06.19 um 18:27 schrieb Daniel Vetter:
> >
> > > So I pondered a few ideas while working out:
> > >
> > > 1) We drop this filtering. Importer needs to keep track of all its
> > > mappings and filter out invalidates that aren't for that specific importer
> > > (either because already invalidated, or not yet mapped, or whatever).
> > > Feels fragile.
> > >
> > > [SNIP]
> > [SNIP]
> >
> > I will take a moment and look into #1 as well, but I still don't see the
> > need to change anything.
>
> That turned out much cleaner than I thought it would be. Essentially it is
> only a single extra line of code in amdgpu.
>
> Going to send that out as a patch set in a minute.
Yeah I mean kinda expected that because:
- everything's protected with ww_mutex anyway
- importer needs to keep track of mappings anways
So really all it needs to do is not be stupid and add the mapping it just
created to its tracking while still holding the ww_mutex. Similar on
invalidate/unmap.
With that all we need is a huge note in the docs that importers need to
keep track of their mappings and dtrt (with all the examples here spelled
out in the appropriate kerneldoc). And then I'm happy :-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-06-24 14:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-18 11:54 [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10 Christian König
2019-06-18 11:54 ` [PATCH 2/6] drm/ttm: remove the backing store if no placement is given Christian König
2019-06-18 11:54 ` [PATCH 3/6] drm/ttm: use the parent resv for ghost objects v2 Christian König
[not found] ` <20190618115455.1253-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2019-06-18 11:54 ` [PATCH 4/6] drm/amdgpu: use allowed_domains for exported DMA-bufs Christian König
2019-06-18 11:54 ` [PATCH 5/6] drm/amdgpu: add independent DMA-buf export v6 Christian König
2019-06-18 11:54 ` [PATCH 6/6] drm/amdgpu: add independent DMA-buf import v6 Christian König
2019-06-18 12:28 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v10 Patchwork
2019-06-18 12:30 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-06-18 13:29 ` ✓ Fi.CI.BAT: success " Patchwork
2019-06-19 13:48 ` Christian König
2019-06-19 0:33 ` ✓ Fi.CI.IGT: " Patchwork
2019-06-21 9:20 ` [Intel-gfx] [PATCH 1/6] " Daniel Vetter
[not found] ` <20190621092022.GB12905-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-06-21 9:55 ` Christian König
2019-06-21 10:32 ` Daniel Vetter
2019-06-21 12:06 ` Christian König
[not found] ` <78db8951-2e62-2a9d-3d87-3b458fbba880-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-06-21 16:27 ` [Intel-gfx] " Daniel Vetter
[not found] ` <20190621162753.GI12905-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-06-24 11:23 ` Koenig, Christian
2019-06-24 13:58 ` Christian König
2019-06-24 14:41 ` Daniel Vetter [this message]
2019-06-25 7:20 ` Koenig, Christian
[not found] ` <d2933e7a-5dd1-70af-cbb6-69755fcbbc5e-5C7GfCeVMHo@public.gmane.org>
2019-06-25 7:40 ` [Intel-gfx] " Daniel Vetter
[not found] ` <4d868c4c-cc00-bfa9-b6f5-969b76497cab-5C7GfCeVMHo@public.gmane.org>
2019-06-24 14:38 ` 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=20190624144105.GR12905@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.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