On Thu, May 20, 2021 at 5:50 AM Christian König
wrote:
>
> Am 20.05.21 um 09:55 schrieb Daniel Vetter:
> > On Wed, May 19, 2021 at 5:48 PM Michel Dänzer wrote:
> >> On 2021-05-19 5:21 p.m., Jason Ekstrand wrote:
> >>> On Wed, May 19, 2021 at 5:52 AM Michel Dänze
From: Christian König
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand)
- Return NULL from dma_fence_array_first if head == NULL. This matches
the iterator behavior of dma_fence_chain_for_each in that it iterates
zero times if head == NULL
owever, this is a
case of userspace racing with itself. As long as we ensure userspace
can't back the kernel into a corner, it should be fine.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- L
Cc: Bas Nieuwenhuizen
Cc: Daniel Stone
Christian König (1):
dma-buf: add dma_fence_array_for_each (v2)
Jason Ekstrand (3):
dma-buf: add dma_resv_get_singleton_rcu (v4)
dma-buf: Add an API for exporting sync files (v9)
RFC: dma-buf: Add an API for importing sync files (v6)
drivers/dma-buf
e export from the
dma-buf before we re-introduce it for rendering, it will only contain
fences from the compositor or display. This allows to accurately turn
it into a VkFence or VkSemaphore without any over- synchronization.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences i
Add a helper function to get a single fence representing
all fences in a dma_resv object.
This fence is either the only one in the object or all not
signaled fences of the object in a flatted out dma_fence_array.
v2 (Jason Ekstrand):
- Take reference of fences both for creating the
On Thu, May 20, 2021 at 12:23 PM Jason Ekstrand wrote:
>
> On Thu, May 20, 2021 at 5:50 AM Christian König
> wrote:
> >
> > Am 20.05.21 um 09:55 schrieb Daniel Vetter:
> > > On Wed, May 19, 2021 at 5:48 PM Michel Dänzer wrote:
> > >> On 2021-05-19 5:21
mitives every time some GL call
requires them to sync between fragment and vertex pipes.
So, to sum up, I think there's likely some good collaboration to be
had here for everyone. :-)
--Jason
> > > Sure, I've done a quick PoC internally and have been able to hook this
> &
ret;
> + enum ibv_access_flags access = (enum ibv_access_flags)acc;
Why?
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
four to the rdma tree, thanks
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
t; + struct ibv_mr * (*reg_dmabuf_mr)(struct ibv_pd *pd, uint64_t
> offset,
> + size_t length, uint64_t iova,
> + int fd, int access);
> uint64_t _ABI_placeholder3;
> size_t sz;/* Must be immediately before struct
> ibv_context */
> struct ibv_context context; /* Must be last field in the struct */
No, delete this whole hunk, it is not needed
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
B, args);
> +a, b, self.map_offset = unpack('=iiq', args);
Wow, OK
Is it worth using ctypes here instead? Can you at least add a comment
before each pack specifying the 'struct XXX' this is following?
Does this work with normal Intel GPUs, like in a L
ussed this already, but for actual p2p the intel
> patches aren't in upstream yet. We have some internally, but with very
> broken locking (in the process of getting fixed up, but it's taking time).
Someone needs to say this test works on a real system with an
unpatched ups
On Tue, Nov 24, 2020 at 03:34:11PM +0100, Daniel Vetter wrote:
> On Fri, Nov 20, 2020 at 02:07:19PM -0400, Jason Gunthorpe wrote:
> > On Fri, Nov 20, 2020 at 10:54:43AM +0100, Daniel Vetter wrote:
> > > diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> &
On Tue, Nov 24, 2020 at 06:24:43PM +, Xiong, Jianxin wrote:
> > From: Christoph Hellwig
> > Sent: Tuesday, November 24, 2020 1:34 AM
> > To: Xiong, Jianxin
> > Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug
> > Ledford ; Jason Gunthorpe
On Tue, Nov 24, 2020 at 03:28:14PM +0100, Daniel Vetter wrote:
> On Fri, Nov 20, 2020 at 02:30:29PM -0400, Jason Gunthorpe wrote:
> > On Thu, Nov 19, 2020 at 03:41:46PM +0100, Daniel Vetter wrote:
> > > @@ -4805,21 +4824,15 @@ EXPORT_SYMBOL(follow_pte_pmd);
> > > *
tion through cython to
the python test script
If you struggle here I can probably work out the build system bits,
but it should not be too terrible
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Nov 25, 2020 at 06:11:29PM +, Christoph Hellwig wrote:
> On Wed, Nov 25, 2020 at 02:06:06PM -0400, Jason Gunthorpe wrote:
> > It uses a empty 'cover-letter' commit and automatically transforms it
> > into exactly the right stuff. Keeps track of everything you s
t access);
Please include the iova in addition to the offset for this API
Similar to ibv_reg_mr_iova
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Nov 25, 2020 at 07:27:07PM +, Xiong, Jianxin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, November 25, 2020 4:15 AM
> > To: Daniel Vetter
> > Cc: Xiong, Jianxin ; Leon Romanovsky
> > ; linux-r...@vger.kernel.org; dri-
> > de...@lists.fr
ver-letter' commit and automatically transforms it
into exactly the right stuff. Keeps track of everything you send in
git, and there is a little tool to auto-run git range-diff to help
build change logs..
https://github.com/jgunthorpe/Kernel-Maintainer-Tools/bl
evmem
This sequence seems fairly stand alone, and in good shape as well
My advice is to put the done things on a branch and get Stephen to put
them in linux-next. You can send a PR to Lins. There is very little mm
stuff in here, and cross subsystem stuff works better in git land,
IMHO.
Jason
___
function -Wno-redundant-decls -Wno-shadow -Wno-cast-function-type
> -Wno-implicit-fallthrough -Wno-unknown-warning -Wno-unknown-warning-option
> -Wno-deprecated-declarations ${NO_VAR_TRACKING_FLAGS}"
Ugh, you copy and pasted this, but it shouldn't have existed in the
first place. Compiler arguments like this should not be specified
manually. I should fix it..
Also you should cc edward on all this pyverbs stuff, he knows it all
very well
It all looks reasonable to me
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
+}
> > +
> > +static int radeon_alloc(struct dri *dri, size_t size, uint32_t *handle)
>
> Tbh radeon chips are old enough I wouldn't care. Also doesn't support p2p
> dma-buf, so always going to be in system memory when you share. Plus you
> al
On Mon, Nov 30, 2020 at 05:04:43PM +0100, Daniel Vetter wrote:
> On Mon, Nov 30, 2020 at 11:55:44AM -0400, Jason Gunthorpe wrote:
> > On Mon, Nov 30, 2020 at 03:57:41PM +0100, Daniel Vetter wrote:
> > > > + err = ioctl(dri->fd, DRM_IOCTL_AMDGPU_GEM_CREATE, &gem
On Mon, Nov 30, 2020 at 05:53:39PM +, Xiong, Jianxin wrote:
> > From: Jason Gunthorpe
> > Sent: Monday, November 30, 2020 8:08 AM
> > To: Xiong, Jianxin
> > Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug
> > Ledford ; Leon Romanovsky
ng, IMHO. I
skeptical that TPM interrupts were ever valuable enough to deserve
this in the first place.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
e EOPNOTSUPP and not EINVAL.
>
> EINVAL is used here to be consistent with existing definitions in the same
> file.
They may be wrong, EOPNOTSUPP is right for this situation
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
f_get()
> * Return -EOPNOTSUPP instead of -EINVAL for unimplemented functions
> * Remove an unnecessary use of unlikely()
> * Remove left-over commit message resulted from rebase
You should probably slow down a bit, v13 needed rebasing too.
Jason
___
On Wed, Dec 09, 2020 at 05:36:16PM +0100, Thomas Hellström (Intel) wrote:
> Jason, Christian
>
> In most implementations of the callback mentioned in the subject there's a
> fence wait.
> What exactly is it needed for?
Invalidate must stop DMA before returning, so presumably
l_dmabuf->npages, sizeof(*hl_dmabuf->pages),
> + GFP_KERNEL);
> + if (!hl_dmabuf->pages) {
> + rc = -ENOMEM;
> + goto err_free_dmabuf_wrapper;
> + }
Why not just create the SGL directly? Is there a reason it needs to
make a page list?
Jason
ystem
it has benefited greatly, I think.
However, in another sense no: RDMA hasn't been blocking, say Intel,
just because they have built proprietary stuff on top of our open
stack.
Honestly, I think GPU is approaching this backwards. Wayland should
have been designed to prevent proprietary userspace stacks.
Jason
checking this value (and using it) when
> creating the SGL when exporting dmabuf. (e.g.
> amdgpu_vram_mgr_alloc_sgt)
For dmabuf the only importer is RDMA and it doesn't care, but you
certainly should not introduce a hardwired constant instead of using
the correct function.
Jason
like say NVMe, can really be
properly community oriented. Otherwise we have to work in a community
partnership with the vendor.
Jason
.
> So I'm not clear what you're suggesting here we should do different.
Not enabling proprietary stacks as above would be a good start.
Jason
On Tue, Jul 06, 2021 at 04:39:19PM +0200, Daniel Vetter wrote:
> On Tue, Jul 6, 2021 at 4:23 PM Jason Gunthorpe wrote:
> >
> > On Tue, Jul 06, 2021 at 12:36:51PM +0200, Daniel Vetter wrote:
> >
> > > If that means AI companies don't want to open our their hw s
tegra socs,
> which are fully supported in upstream afaik.
I understand nvgpu is the tegra driver that people actualy
use. nouveau may have good tegra support but is it used in any actual
commercial product?
Jason
kernels, no add on kernel
modules, with full commercial support.
If you can say that kind of arrangment is also common place in the GPU
world then I will happily be wrong.
Jason
On Tue, Jul 06, 2021 at 07:31:37PM +0200, Christoph Hellwig wrote:
> On Tue, Jul 06, 2021 at 02:28:28PM -0300, Jason Gunthorpe wrote:
> > > Also on your claim that drivers/gpu is a non-upstream disaster: I've
> > > also learned that that for drivers/rdma there's the
demands.
IHMO upstream success is found by motivating the customer to demand
and make it "easy" for the vendor to supply it.
Jason
On Tue, Jul 6, 2021 at 5:12 AM Daniel Vetter wrote:
>
> Specifically document the new/clarified rules around how the shared
> fences do not have any ordering requirements against the exclusive
> fence.
>
> But also document all the things a bit better, given how central
> struct dma_resv to dynami
xt.
3. Get rid of the separation between context close and context destroy
4. Get rid of the RCU on i915_gem_context
However, these should probably be done as a separate patch series as this
one is already starting to get longish, especially if you consider the 89
IGT patches that go along w
really care
about solving this problem, they can do it properly.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/gem/i915_gem_context.c | 85 +--
drivers/gpu/drm/i915/gt/intel_conte
patch adds a new ring_size field and makes everything use
that.
v2 (Daniel Vetter):
- Replace 512 * SZ_4K with SZ_2M
v2 (Jason Ekstrand):
- Rebase on top of page migration code
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3
ml
[2]: https://lists.freedesktop.org/archives/intel-gfx/2015-May/067031.html
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 16 ++--
.../gpu/drm/i915/gem/i915_gem_context_types.h| 1 -
drivers/gpu/drm/i91
e races setting request_timeout_ms and context creation, they
can theoretically end up with different timeouts. However, since both
of these are fairly harmless and require changing kernel params, we
don't care.
v2 (Tvrtko Ursulin):
- Add a comment about races with request_timeout_ms
None of the callbacks we use with it return an error code anymore; they
all return 0 unconditionally.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++--
1 file changed, 8 insertions(+), 18 deletions(-)
diff
imeline, they can
use a syncobj and set it as an in and out fence on every submit.
v2 (Jason Ekstrand):
- More detailed commit message
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 199 +-
.../drm/i915/gt/
text::syncobj to mention that it's
an emulation and the possible race if userspace calls execbuffer2
twice on the same context concurrently.
v2 (Jason Ekstrand):
- Wrap the checks for eb.gem_context->syncobj in unlikely()
- Drop the dma_fence reference
- Improved commit message
v3
This was only ever used for FENCE_SUBMIT automatic engine selection
which was removed in the previous commit.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_request.c | 42
Vetter):
- Mention the exact IGT test this breaks
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h| 7 ---
.../drm/i915/gt/intel_execlists_submission.c| 17
There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/dr
hey can use set CONTEXT_PARAM_RECOVERABLE to false and look for -EIO
coming from execbuf to check for hangs instead.
v2 (Daniel Vetter):
- Add a comment in the commit message about recoverable contexts
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem
he bonding information.
v2 (Jason Ekstrand):
- Don't delete quite as much code.
v3 (Tvrtko Ursulin):
- Add some history to the commit message
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 18 +-
.../drm/i915/gt/intel_execlists_subm
With the proto-context stuff added later in this series, we end up
having to duplicate set_priority. This lets us avoid duplicating the
validation logic.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 +
1 file
data so it's not useful for discovering what engines
are in the context. It's also not a replacement for the recently
removed I915_CONTEXT_CLONE_ENGINES because it doesn't return any of the
balancing or bonding information.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
-
In order to prevent kernel doc warnings, also fill out docs for any
missing fields and fix those that forgot the "@".
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
Documentation/gpu/i915.rst| 2 +
.../gpu/drm/i915/gem/i915_gem_context_ty
Since free_engines works for partially constructed engine sets, we can
use the usual goto pattern.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers
For now this is a no-op because everyone passes in a null SSEU but it
lets us get some of the error handling and selftest refactoring plumbed
through.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 41 +++
.../gpu
anual bitops and BIT() instead of __set_bit
v4 (Daniel Vetter):
- Add a changelog to the commit message
- Better hyperlinking in docs
- Create the default PPGTT in i915_gem_create_context
v5 (Daniel Vetter):
- Hand-roll the initialization of UCONTEXT_PERSISTENCE
Signed-off-by: Jason Ekstrand
This is the VM equivalent of i915_gem_context_lookup. It's only used
once in this patch but future patches will need to duplicate this lookup
code so it's better to have it in a helper.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem
UG_ON might be trying to implicitly check is
that offsetof(user->engines) == sizeof(*user) and we don't have any
weird padding throwing us off. However, that's not the check it's doing
and it's not even a reliable way to do that check.
Signed-off-by: Jason Ekstrand
Reviewed-b
't allow more resetting user engines
- Rework initialization of UCONTEXT_PERSISTENCE
v4 (Jason Ekstrand):
- Move hand-rolled initialization of UCONTEXT_PERSISTENCE to an
earlier patch
v5 (Jason Ekstrand):
- Move proto_context_set_persistence to this patch
Signed-off-by: Jason Ekstrand
R
We're about to start doing lazy context creation which means contexts
get created in i915_gem_context_lookup and we may start having more
errors than -ENOENT.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++--
dr
per-client
stats from debugfs/i915_gem_objects")
v2 (Daniel Vetter):
- Delete a struct drm_i915_file_private pre-declaration
- Add a comment to the commit message about history
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 9
create_context_locked static
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 203 ++
drivers/gpu/drm/i915/gem/i915_gem_context.h | 3 +
.../gpu/drm/i915/gem/i915_gem_context_types.h | 54 +
.../gpu/drm
client can hurt itself or try to get
around kernel context banning.
v2 (Jason Ekstrand):
- Expand the commit mesage
v3 (Jason Ekstrand):
- Make it more obvious that I915_CONTEXT_PARAM_ENGINES returns -EINVAL
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/g
e.
By removing support for CONTEXT_PARAM_VM from ctx_setparam, we make it
impossible to change out the VM after the context has been fully
created. This lets us delete a bunch of deferred task code as well as a
duplicated (and slightly different) copy of the code which programs the
PPGTT registers.
v2 (
We want to delete __assign_ppgtt and, generally, stop setting the VM
after context creation. This is the one place I could find in the
selftests where we set a VM after the fact.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
Now that we have the whole engine set and VM at context creation time,
we can just assign those fields instead of creating first and handling
the VM and engines later. This lets us avoid creating useless VMs and
engine sets and lets us get rid of the complex VM setting code.
Signed-off-by: Jason
.
Signed-off-by: Jason Ekstrand
Cc: Jon Bloomfield
Cc: Carl Zhang
Cc: Michal Mrozek
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 39 -
1 file changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem
This better models where we want to go with contexts in general where
things like the VM and engine set are create parameters instead of being
set after the fact.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
.../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
.../gpu/drm
As per Daniel's request, this better documents the VM and engine set APIs
including some discussion of the deprecation plan.
Test-with: 20210710211923.784638-1-ja...@jlekstrand.net
Cc: Daniel Vetter
Jason Ekstrand (2):
drm/i915: Don't allow setting I915_CONTEXT_PARAM_VM twice
drm
Allowing setting it multiple times brings no real utility to the API, no
userspace relies on it, and it does make i915 a tiny bit more
complicated. Let's disallow it for now unless someone comes up with a
compelling reason to support it.
Signed-off-by: Jason Ekstrand
Cc: Daniel V
Signed-off-by: Jason Ekstrand
Cc: Daniel Vetter
---
include/uapi/drm/i915_drm.h | 39 ++---
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index e334a8b14ef2d..b6bfbda1258c8 100644
--- a
r):
- Rebase on drm-tip
Test-with: 20210711035204.802908-1-ja...@jlekstrand.net
Cc: Daniel Vetter
Cc: Jon Bloomfield
Jason Ekstrand (5):
drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser"
Revert "drm/i915: Propagate errors on awaiting already signaled
fences"
d
ned-off-by: Jason Ekstrand
Cc: Maarten Lankhorst
Reviewed-by: Jon Bloomfield
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 20
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
drivers/gpu/d
. Now that everything is synchronous, we
don't need it.
v2 (Daniel Vetter):
- Add stabel Cc and Fixes tag
Signed-off-by: Jason Ekstrand
Cc: # v5.6+
Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled
fences")
Cc: Maarten Lankhorst
Reviewed-by:
ri-devel/20210602164149.391653-2-ja...@jlekstrand.net/
for otherwise backporting just this patch opens up a security bug.
v2: Augment commit message. Also restore Jason's sob that I
accidentally lost.
v3: Add a note for backporters
Signed-off-by: Jason Ekstrand
Reported-by: Marcin Slusarz
Cc: # v5.6
Asynchronous command parsing was the only thing which ever returned a
non-zero error. With that gone, we can drop the error handling from
dma_fence_work.
Signed-off-by: Jason Ekstrand
Reviewed-by: Jon Bloomfield
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 4
that's not a case we should optimize for in the kernel. We should
optimize for code clarity instead.
Signed-off-by: Jason Ekstrand
Reviewed-by: Jon Bloomfield
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 67 +-
1 file changed, 34 insertions(+
No worries. Thanks for pushing!
On Mon, Jul 12, 2021 at 6:37 AM Christian König
wrote:
>
> Sorry for the vacation and sick leave induced delay.
>
> I've just pushed this to drm-misc-fixes.
>
> Thanks,
> Christian.
>
> Am 24.06.21 um 21:43 schrieb Jason Ekstrand:
ry, WB otherwise.
> */
> __u64 flags;
> -#define I915_MMAP_OFFSET_GTT 0
> -#define I915_MMAP_OFFSET_WC 1
> -#define I915_MMAP_OFFSET_WB 2
> -#define I915_MMAP_OFFSET_UC 3
>
> - /*
> -* Zero-terminated chain of extension
On Mon, Jul 12, 2021 at 9:12 AM Daniel Vetter wrote:
>
> On Mon, Jul 12, 2021 at 08:47:24AM -0500, Jason Ekstrand wrote:
> > On Fri, Jul 9, 2021 at 6:41 AM Maarten Lankhorst
> > wrote:
> > >
> > > This is only used for ttm, and tells userspace that the
On Mon, Jul 12, 2021 at 9:38 AM Daniel Vetter wrote:
>
> On Mon, Jul 12, 2021 at 09:31:13AM -0500, Jason Ekstrand wrote:
> > On Mon, Jul 12, 2021 at 9:12 AM Daniel Vetter wrote:
> > >
> > > On Mon, Jul 12, 2021 at 08:47:24AM -0500, Jason Ekstrand wrote:
> >
support and move the pinning into the
attach/detach path.
v4: (ruhl)
- Put pages does not need to assert on the dma-resv
v5: (jason)
- Lock around dma_buf_unmap_attachment() when emulating a dynamic
importer in the subtests.
- Use pin_pages_unlocked
Reported-by: Michael J. Ruhl
Signed-off-by
() callback.
v4:
- Migrate in attach
v5: (jason)
- Lock around the migration
Signed-off-by: Thomas Hellström
Signed-off-by: Michael J. Ruhl
Reported-by: kernel test robot
Signed-off-by: Jason Ekstrand
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 25
On Tue, Jul 13, 2021 at 9:40 AM Daniel Vetter wrote:
>
> On Mon, Jul 12, 2021 at 06:12:33PM -0500, Jason Ekstrand wrote:
> > From: Thomas Hellström
> >
> > If our exported dma-bufs are imported by another instance of our driver,
> > that instance will typically hav
#x27;m not 100% sure where the Linux release cuts land. In any
case, I'm happy to make a version of this series per-release if needed for
Greg to back-port.
v2 (Daniel Vetter):
- Re-order to put the reverts first
- Add ACKs from Daniel
- Add better CC and Fixes tags
v3 (Jason Ekstran
. Now that everything is synchronous, we
don't need it.
v2 (Daniel Vetter):
- Add stabel Cc and Fixes tag
Signed-off-by: Jason Ekstrand
Cc: # v5.6+
Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled
fences")
Cc: Maarten Lankhorst
Reviewed-by:
ri-devel/20210602164149.391653-2-ja...@jlekstrand.net/
for otherwise backporting just this patch opens up a security bug.
v2: Augment commit message. Also restore Jason's sob that I
accidentally lost.
v3: Add a note for backporters
Signed-off-by: Jason Ekstrand
Reported-by: Marcin Slusarz
Cc: # v5.6
Asynchronous command parsing was the only thing which ever returned a
non-zero error. With that gone, we can drop the error handling from
dma_fence_work.
Signed-off-by: Jason Ekstrand
Reviewed-by: Jon Bloomfield
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 4
ned-off-by: Jason Ekstrand
Cc: Maarten Lankhorst
Reviewed-by: Jon Bloomfield
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 20
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
drivers/gpu/d
that's not a case we should optimize for in the kernel. We should
optimize for code clarity instead.
Signed-off-by: Jason Ekstrand
Reviewed-by: Jon Bloomfield
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 67 +-
1 file changed, 34 insertions(+
ff-by: Jason Ekstrand
Cc: Daniel Vetter
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 8 +++-
drivers/gpu/drm/i915/gem/i915_gem_object.c| 13 ++---
.../gpu/drm/i915/gem/selftests/i915_gem_migrate.c | 15 ---
3 files changed, 5 inser
On Tue, Jul 13, 2021 at 10:23 AM Daniel Vetter wrote:
>
> On Tue, Jul 13, 2021 at 04:06:13PM +0100, Matthew Auld wrote:
> > On Tue, 13 Jul 2021 at 15:44, Daniel Vetter wrote:
> > >
> > > On Mon, Jul 12, 2021 at 06:12:34PM -0500, Jason Ekstrand wrote:
-by: Max Gurtovoy
Signed-off-by: Jason Gunthorpe
---
Documentation/driver-api/vfio.rst| 4 ++-
drivers/vfio/fsl-mc/vfio_fsl_mc.c| 6 +++--
drivers/vfio/mdev/vfio_mdev.c| 13 +++---
drivers/vfio/pci/vfio_pci.c | 6 +++--
drivers/vfio
kwards from the struct
pci_device.
Overall a few minor bugs are squashed and quite a bit of code is removed
through consolidation.
Jason Gunthorpe (11):
vfio/samples: Remove module get/put
vfio: Provide better generic support for open/release vfio_device_ops
vfio/samples: Delete usel
The core code no longer requires these ops to be defined, so delete these
empty functions and leave the op as NULL. mtty's functions only log a
pointless message, delete that entirely.
Signed-off-by: Yishai Hadas
Signed-off-by: Jason Gunthorpe
---
samples/vfio-mdev/mbochs.c
Platform simply wants to run some code when the device is first
opened/last closed. Use the core framework and locking for this. Aside
from removing a bit of code this narrows the locking scope from a global
lock.
Signed-off-by: Yishai Hadas
Signed-off-by: Jason Gunthorpe
---
drivers/vfio
501 - 600 of 3569 matches
Mail list logo
