On Wed, Apr 28, 2021 at 10:49 AM Tvrtko Ursulin
wrote:
>
>
> On 23/04/2021 23:31, Jason Ekstrand wrote:
> > This API is entirely unnecessary and I'd love to get rid of it. If
> > userspace wants a single timeline across multiple contexts, they can
> > either u
On Tue, Apr 27, 2021 at 4:49 AM Daniel Vetter wrote:
>
> On Fri, Apr 23, 2021 at 05:31:15PM -0500, Jason Ekstrand wrote:
> > This API allows one context to grab bits out of another context upon
> > creation. It can be used as a short-cut for setparam(getparam()) f
On Wed, Apr 28, 2021 at 12:26 PM Matthew Brost wrote:
>
> On Wed, Apr 28, 2021 at 12:18:29PM -0500, Jason Ekstrand wrote:
> > On Wed, Apr 28, 2021 at 5:13 AM Daniel Vetter wrote:
> > >
> > > On Tue, Apr 27, 2021 at 08:51:08AM -0500, Jason Ekstrand wrote:
> >
On Wed, Apr 28, 2021 at 1:02 PM Matthew Brost wrote:
>
> On Wed, Apr 28, 2021 at 12:46:07PM -0500, Jason Ekstrand wrote:
> > On Wed, Apr 28, 2021 at 12:26 PM Matthew Brost
> > wrote:
> > >
> > > On Wed, Apr 28, 2021 at 12:18:29PM -0500, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 5:27 AM Daniel Vetter wrote:
>
> On Fri, Apr 23, 2021 at 05:31:21PM -0500, Jason Ekstrand wrote:
> > As far as I can tell, the only real reason for this is to avoid taking a
> > reference to the i915_gem_context. The cost of those two atomics
>
On Wed, Apr 28, 2021 at 12:18 PM Jason Ekstrand wrote:
>
> On Wed, Apr 28, 2021 at 5:13 AM Daniel Vetter wrote:
> >
> > On Tue, Apr 27, 2021 at 08:51:08AM -0500, Jason Ekstrand wrote:
> > > I sent a v2 of this patch because it turns out I deleted a bit too
> &g
mestamps separately and the calculated delta between these
> > timestamps lack enough accuracy.
> >
> > To improve the accuracy of these time measurements to within a few us,
> > add a query that returns the engine and cpu timestamps captured as
> > close to each other as
On Wed, Apr 28, 2021 at 2:50 PM Lionel Landwerlin
wrote:
>
> On 28/04/2021 22:24, Jason Ekstrand wrote:
>
> On Wed, Apr 28, 2021 at 3:43 AM Jani Nikula
> wrote:
>
> On Tue, 27 Apr 2021, Umesh Nerlige Ramappa
> wrote:
>
> Perf measurements rely on CPU and
On Wed, Apr 28, 2021 at 3:14 PM Lionel Landwerlin
wrote:
>
> On 28/04/2021 22:54, Jason Ekstrand wrote:
> > On Wed, Apr 28, 2021 at 2:50 PM Lionel Landwerlin
> > wrote:
> >> On 28/04/2021 22:24, Jason Ekstrand wrote:
> >>
> >> On Wed, Apr
On Thu, Apr 29, 2021 at 7:08 AM Daniel Vetter wrote:
>
> On Thu, Apr 29, 2021 at 09:06:47AM +0100, Tvrtko Ursulin wrote:
> >
> > On 28/04/2021 18:26, Jason Ekstrand wrote:
> > > On Wed, Apr 28, 2021 at 10:49 AM Tvrtko Ursulin
> > > wrote:
> > >
On Thu, Apr 29, 2021 at 3:04 AM Tvrtko Ursulin
wrote:
>
>
> On 28/04/2021 18:24, Jason Ekstrand wrote:
> > On Wed, Apr 28, 2021 at 10:55 AM Tvrtko Ursulin
> > wrote:
> >> On 23/04/2021 23:31, Jason Ekstrand wrote:
> >>> Instead of handling it like a
On Thu, Apr 29, 2021 at 7:37 AM Daniel Vetter wrote:
>
> On Fri, Apr 23, 2021 at 05:31:25PM -0500, Jason Ekstrand wrote:
> > There's a big comment saying how useful it is but no one is using this
> > for anything.
> >
> > Signed-off-by: Jason Ekstrand
>
>
On Thu, Apr 29, 2021 at 8:27 AM Daniel Vetter wrote:
>
> On Fri, Apr 23, 2021 at 05:31:24PM -0500, Jason Ekstrand wrote:
> > 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
On Thu, Apr 29, 2021 at 7:54 AM Tvrtko Ursulin
wrote:
>
>
> On 29/04/2021 13:24, Daniel Vetter wrote:
> > On Wed, Apr 28, 2021 at 04:51:19PM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 23/04/2021 23:31, Jason Ekstrand wrote:
> >>> This adds a bunch o
On Thu, Apr 29, 2021 at 7:16 AM Daniel Vetter wrote:
>
> On Wed, Apr 28, 2021 at 01:58:17PM -0500, Jason Ekstrand wrote:
> > On Wed, Apr 28, 2021 at 12:18 PM Jason Ekstrand
> > wrote:
> > >
> > > On Wed, Apr 28, 2021 at 5:13 AM Daniel Vetter wrote:
> >
tely we butchered the uapi with setparam and sharing
> setparams between create_ext and setparam
>
> - and how exactly proto ctx fixes this (with stuff like locking design
> used)
>
> Maybe also dupe the kerneldoc into here for completeness.
> On Fri, Apr 23, 2021 at 05:31:23
On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter wrote:
>
> Yeah this needs some text to explain what/why you're doing this, and maybe
> some rough sketch of the locking design.
Yup. Will add.
>
> On Fri, Apr 23, 2021 at 05:31:26PM -0500, Jason Ekstrand wrote:
> > Sig
On Thu, Apr 29, 2021 at 12:13 PM Daniel Vetter wrote:
>
> On Thu, Apr 29, 2021 at 07:12:05PM +0200, Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 09:54:15AM -0500, Jason Ekstrand wrote:
> > > On Thu, Apr 29, 2021 at 3:04 AM Tvrtko Ursulin
> > > wrote:
> >
On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter wrote:
>
> On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:
> > On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter wrote:
> > > > + ret = set_proto_ctx_param(file_priv, pc, args);
> > >
> > >
ml
[2]: https://lists.freedesktop.org/archives/intel-gfx/2015-May/067031.html
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 16 ++--
.../gpu/drm/i915/gem/i915_gem_context_types.h| 1 -
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
really care
about solving this problem, they can do it properly.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/gem/i915_gem_context.c | 85 +--
drivers/gpu/drm/i915/gt/intel_context_param.c | 63 ---
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
-
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
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 +--
drivers/gpu/drm/i915/gt/intel_context.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_context.h | 5 -
drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c
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
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
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 18 +-
.../drm/i915/gt/intel_execlists_submission.c | 69 --
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
This was only ever used for FENCE_SUBMIT automatic engine selection
which was removed in the previous commit.
Signed-off-by: Jason Ekstrand
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_request.c | 42 ---
drivers/gpu/drm/i915
such that they can run in parallel.
However, this functionality has never been used in the real world. The
media driver (the only user of FENCE_SUBMIT) always picks exactly two
physical engines to bond and never asks us to pick which to use.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915
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
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
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
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
imeline, they can
use a syncobj and set it as an in and out fence on every submit.
Signed-off-by: Jason Ekstrand
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 199 +-
.../drm/i915/gt/intel_execlists_submission.c | 28 ---
.../drm/i915/gt/intel_execlists_
round this wart, this
commit adds a proto-context struct which contains all the context create
parameters.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 143 ++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 22 +++
.../gpu/drm/i915/gem
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
---
Documentation/gpu/i915.rst| 2 +
.../gpu/drm/i915/gem/i915_gem_context_types.h | 43 ---
2 fil
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
This means that the proto-context needs to grow support for engine
configuration information as well as setparam logic. Fortunately, we'll
be deleting a lot of setparam logic on the primary context shortly so it
will hopefully balance out.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm
ork properly, everything which ever touches
a proto-context is guarded by drm_i915_file_private::proto_context_lock,
including context creation. Yes, this means context creation now takes
a giant global lock but it can't really be helped and that should never
be on any driver's fast-pat
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 302
1 file changed, 302 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index a80d36c2a2663..dd066b5009fe7 100644
--- a
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 git rid of the complex VM setting code.
Signed-off-by: Jason
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 267 --
.../gpu/drm/i915/gem/i915_gem_context_types.h | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 119
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
4 files changed
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
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
---
.../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
.../gpu/drm/i915/gem/selftests
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
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +-
1 file changed
gt; v9: (Lionel)
> - Return 2 cpu timestamps in the query - captured before and after the
> register read
>
> v10: (Chris)
> - Use local_clock() to measure time taken to read lower dword of
> register and return it to user.
>
> v11: (Jani)
> - IS_GEN deprecated. User
On Thu, Apr 29, 2021 at 3:01 AM Tvrtko Ursulin
wrote:
>
>
> On 28/04/2021 18:09, Jason Ekstrand wrote:
> > On Wed, Apr 28, 2021 at 9:26 AM Tvrtko Ursulin
> > wrote:
> >> On 28/04/2021 15:02, Daniel Vetter wrote:
> >>> On Wed, Apr 28, 2021
On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
>
> On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
> > On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter wrote:
> > > On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:
> > > > On Thu
On Fri, Apr 30, 2021 at 6:18 AM Tvrtko Ursulin
wrote:
>
>
> On 29/04/2021 15:54, Jason Ekstrand wrote:
> > On Thu, Apr 29, 2021 at 3:04 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 28/04/2021 18:24, Jason Ekstrand wrote:
> >>>
On Fri, Apr 30, 2021 at 6:40 AM Tvrtko Ursulin
wrote:
>
>
> On 29/04/2021 20:16, Jason Ekstrand wrote:
> > On Thu, Apr 29, 2021 at 3:01 AM Tvrtko Ursulin
> > wrote:
> >> On 28/04/2021 18:09, Jason Ekstrand wrote:
> >>> On Wed, Apr 28, 2021 at 9:26 AM Tv
On Fri, Apr 30, 2021 at 1:53 AM Daniel Vetter wrote:
>
> On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand wrote:
> >
> > On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
> > >
> > > On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
> >
On Fri, Apr 30, 2021 at 11:33 AM Daniel Vetter wrote:
>
> On Fri, Apr 30, 2021 at 6:27 PM Jason Ekstrand wrote:
> >
> > On Fri, Apr 30, 2021 at 1:53 AM Daniel Vetter wrote:
> > >
> > > On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand
> > > wrote:
&g
you can query the 64-bit timestamp value
from the GPU. The way this is handled in Vulkan is that the number of
timestamp bits is reported to the application as a queue property.
--Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
On April 30, 2021 23:01:44 "Dixit, Ashutosh" wrote:
On Fri, 30 Apr 2021 19:19:59 -0700, Umesh Nerlige Ramappa wrote:
On Fri, Apr 30, 2021 at 07:35:41PM -0500, Jason Ekstrand wrote:
On April 30, 2021 18:00:58 "Dixit, Ashutosh"
wrote:
On Fri, 30 Apr 2021 15:26:09 -0700, U
ff-by: Jason Ekstrand
Cc: Daniel Vetter
Cc: Dave Airlie
---
Documentation/gpu/drm-uapi.rst | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 199afb503ab1..82f780bc3fce 100644
--- a/Documentation/gpu/drm-uapi.rst
On Wed, Aug 4, 2021 at 1:48 PM Jason Ekstrand wrote:
>
> While tracking down various bits of i915 uAPI, it's been difficult to
> find the userspace much of the time because no one bothers to mention it
> in commit messages. Require the kernel patch to be a one-stop shop for
>
aniel Vetter):
- Minor wording tweaks
Signed-off-by: Jason Ekstrand
Acked-by: Daniel Vetter
Cc: Dave Airlie
---
Documentation/gpu/drm-uapi.rst | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 199afb503ab1..7b398c6fadc6 1
o allow them.
My gut says we actually want to back-port
https://lore.kernel.org/dri-devel/YPk3OCMrhg7UlU6T@phenom.ffwll.local/
instead. Daniel, thoughts?
--Jason
>
> Fixes: 1354d830cb8f ("drm/i915: Call i915_globals_exit() if
> pci_register_device() fails")
> Signed-off-b
On Tue, Aug 03, 2021 at 10:52:25AM -0600, Alex Williamson wrote:
> On Tue, 3 Aug 2021 13:41:52 -0300
> Jason Gunthorpe wrote:
> > On Tue, Aug 03, 2021 at 10:34:06AM -0600, Alex Williamson wrote:
> > > I think the vfio_pci_find_reset_target() function needs to be re-worked
Thanks,
What I did is add a new function vfio_pci_dev_set_resettable() which
pulls in three parts of logic that can be be shared with the
VFIO_DEVICE_PCI_HOT_RESET change in the next patch. That leaves this
function as purely needs_reset.
In turn the VFIO_DEVICE_PCI_HOT_RESET patch gets the same treatment
where it becomes a dev_set centric API just like this.
I'll send it as a v4.
Thanks,
Jason
mbochs
- Return 0 from mdev open_device if there is no op
- Fix style for else {}
- Spelling fix for singleton
- Acquire cur_mem under lock
- Always use error unwind flow for vfio_pci_check_all_devices_bound()
v1: https://lore.kernel.org/r/0-v1-eaf3ccbba33c+1add0-vfio_reflck_...@nvidia.com
Jason G
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
samples/vfio-mdev/mbochs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index 7b2e12fe70827c..c313ab4d1f4e4e 100644
--- a/samples/vfio-mdev/mbochs.c
ing it inside vfio_pci_dev_set_try_reset().
This restructuring corrects a call to pci_dev_driver() without holding the
device_lock() and removes a hard wiring to &vfio_pci_driver.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/pci/vfio_pci.c | 182 +---
1 file chang
ot;)
Reported-by: Cornelia Huck
Co-developed-by: Alex Williamson
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
samples/vfio-mdev/mbochs.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-
o group
vfio_devices into sets.
This implementation uses xarray instead of searching through the driver
core structures, which simplifies the somewhat tricky locking in this
area.
Following patches convert all the drivers.
Signed-off-by: Yishai Hadas
Reviewed-by: Cornelia Huck
Reviewed-by: Christoph
ed by what devices
pci_reset_bus() touches, which is either the entire bus or only the slot.
Rely on the core code to do everything reflck was doing and delete reflck
entirely.
Signed-off-by: Yishai Hadas
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/pci/
i_dev_driver().
Reviewed-off-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/pci/vfio_pci.c | 213 +++-
1 file changed, 89 insertions(+), 124 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 0147f04c91b2
-by: Max Gurtovoy
Reviewed-by: Cornelia Huck
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
Documentation/driver-api/vfio.rst| 4 ++-
drivers/vfio/fsl-mc/vfio_fsl_mc.c| 7 ++---
drivers/vfio/mdev/vfio_mdev.c| 13 +++---
drivers/vfio
Nothing uses this anymore, delete it.
Signed-off-by: Yishai Hadas
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/mdev/vfio_mdev.c | 22 --
drivers/vfio/vfio.c | 14 +-
include/linux/mdev.h | 7 ---
include
ned-off-by: Jason Gunthorpe
---
drivers/vfio/fsl-mc/vfio_fsl_mc.c | 156 --
drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c| 6 +-
drivers/vfio/fsl-mc/vfio_fsl_mc_private.h | 7 -
3 files changed, 29 insertions(+), 140 deletions(-)
diff --git a/drivers/vfio/fsl-mc/vfio_f
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
Reviewed-by: Cornelia Huck
Reviewed-by: Christoph Hellwig
Signed-off-by:
Hellwig
Signed-off-by: Jason Gunthorpe
Signed-off-by: Yishai Hadas
---
drivers/vfio/platform/vfio_platform_common.c | 95 ---
drivers/vfio/platform/vfio_platform_private.h | 1 -
2 files changed, 40 insertions(+), 56 deletions(-)
diff --git a/drivers/vfio/platform
ot;)
Fixes: 681c1615f891 ("vfio/mbochs: Convert to use vfio_register_group_dev()")
Reviewed-by: Cornelia Huck
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
samples/vfio-mdev/mbochs.c | 4
samples/vfio-mdev/mdpy.c | 4
2 files changed, 8 deletions(-)
diff --git
these really want the new open/close_device() semantics just change
the function over.
Reviewed-by: Zhenyu Wang
Reviewed-by: Cornelia Huck
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 8
1 file changed, 4 insertions(+), 4 deletions
.
Since these really want the new open/close_device() semantics just change
the functions over.
Reviewed-by: Cornelia Huck
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_ops.c | 8
drivers/s390/crypto/vfio_ap_ops.c | 8
2 files changed, 8 insertions(+), 8
reference.
This tripped up Jason when reimplementing the single timeline feature
in
commit 00dae4d3d35d4f526929633b76e00b0ab4d3970d
Author: Jason Ekstrand
Date: Thu Jul 8 10:48:12 2021 -0500
drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)
We could fix the bug by holding ctx->mutex,
Acked-by: Jason Ekstrand
On Tue, Aug 10, 2021 at 7:34 AM Daniel Vetter wrote:
>
> We still have quite a bit more work to do with overall reworking of
> the ttm-based dg1 code, but the uapi stuff is now finalized with the
> latest pull. So remove that.
>
> This also fix
at does) faster with
> a proper design fix.
>
> Also since there's only one caller of context_apply_all left and it's
> really just a loop, inline it and then inline the lopp body too. This
> is how all other callers that take the engine lock loop over engines,
> it&#
These names were changed in
commit 8af8a109b34fa88b8b91f25d11485b37d37549c3
Author: Christian König
Date: Thu Oct 1 14:51:40 2020 +0200
drm/ttm: device naming cleanup
But he missed a couple of them.
Signed-off-by: Jason Ekstrand
Cc: Christian König
Fixes: 8af8a109b34f ("dr
It's needed for pgprot_t which is used in the header.
Signed-off-by: Jason Ekstrand
Cc: Christian König
---
drivers/gpu/drm/ttm/ttm_tt.c | 1 -
include/drm/ttm/ttm_tt.h | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/dr
definitely just enable the uapi parts by default.
> >
> > Signed-off-by: Maarten Lankhorst
> > References: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11584
> > Cc: Jordan Justen jordan.l.jus...@intel.com
> > Cc: Jason Ekstrand ja...@jlekstrand.ne
Makes sense
Reviewed-by: Jason Ekstrand
On Mon, Aug 16, 2021 at 2:40 AM Christian König
wrote:
>
> Am 10.08.21 um 21:59 schrieb Dan Moulding:
> > In 69de4421bb4c ("drm/ttm: Initialize debugfs from
> > ttm_global_init()"), ttm_global_init was changed so that if
I'd really like this for Mesa so we can pull drm_fourcc.h into common
WSI code. Why has it stalled?
--Jason
On Tue, Dec 8, 2020 at 2:33 AM James Park wrote:
>
> I updated the patch earlier today incorporating the suggestions. I also had
> to bring back "#include "
_mr that should be
> initialized to zero.
>
> Cc: Leon Romanovsky
> Cc: Doug Ledford
> Cc: Jason Gunthorpe
> Cc: linux-r...@vger.kernel.org
> Signed-off-by: Kees Cook
> ---
> drivers/infiniband/hw/mlx5/mlx5_ib.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 del
On Thu, Aug 19, 2021 at 09:19:08AM -0700, Kees Cook wrote:
> On Thu, Aug 19, 2021 at 09:27:16AM -0300, Jason Gunthorpe wrote:
> > On Tue, Aug 17, 2021 at 11:05:26PM -0700, Kees Cook wrote:
> > > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > >
or certain sophisticated scenarios
with RDMA, the intree drivers just haven't quite got there yet.
So, I think it is worthwhile to start thinking about this regardless
of habana labs.
Jason
On Fri, Aug 20, 2021 at 09:25:30AM +0200, Daniel Vetter wrote:
> On Fri, Aug 20, 2021 at 1:06 AM Jason Gunthorpe wrote:
> > On Wed, Aug 18, 2021 at 11:34:51AM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 18, 2021 at 9:45 AM Gal Pressman wrote:
> > > >
> > &g
> "clear to the end" pattern was so common it made sense to add the helpers,
> as they're a bit less disruptive. It's totally up to you! :)
Well, of the patches you cc'd to me only this one used the struct
group..
Jason
importer.
That is fine if there is no revoke - once revoke exists we must have
driver and HW support.
Jason
one caller of
__sg_free_table() in sg_pool.c, so may as well just export
sg_free_table_entries have have it use that directly.
Jason
On Fri, Aug 20, 2021 at 12:54:25PM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 29, 2021 at 12:39:12PM +0300, Leon Romanovsky wrote:
>
> > +/**
> > + * __sg_free_table - Free a previously mapped sg table
> > + * @table: The sg table header to use
> > + * @max_en
umem
I'm going to send this into linux-next, last time that triggered some
bug reports.
But overall it looks okay, though some of the sg_append_table is bit
odd. Certainly using the sg_table throughout the RDMA code is big
improvement.
Lets see a v4, reviews/etc and I'll update it.
Jason
agation but missed the case
added in 8e9f84cf5cac ("drm/i915/gt: Propagate change in error status
to children on unhold"). Revert that one too. This error was found
by an up-and-coming selftest which .
Otherwise, looks good to me.
--Jason
>
> This reverts commit 8e9f84cf5cac248a1
On Mon, Aug 23, 2021 at 02:09:37PM +0300, Maor Gottlieb wrote:
>
> On 8/20/2021 6:54 PM, Jason Gunthorpe wrote:
> > On Thu, Jul 29, 2021 at 12:39:12PM +0300, Leon Romanovsky wrote:
> >
> > > +/**
> > > + * __sg_free_table - Free a previously mapped sg table
On Mon, Aug 23, 2021 at 04:45:45PM +0300, Maor Gottlieb wrote:
>
> On 8/23/2021 3:45 PM, Jason Gunthorpe wrote:
> > On Mon, Aug 23, 2021 at 02:09:37PM +0300, Maor Gottlieb wrote:
> > > On 8/20/2021 6:54 PM, Jason Gunthorpe wrote:
> > > > On Thu, Jul 29, 2021 at
i915_sg_segment_size(), GFP_KERNEL);
> + if (ret) {
> kfree(st);
> - return ERR_CAST(sg);
> + return ERR_PTR(ret);
> }
Looks right, thanks
Jason
On Tue, Aug 24, 2021 at 10:27:23AM -0700, John Hubbard wrote:
> On 8/24/21 2:32 AM, Christian König wrote:
> > Am 24.08.21 um 11:06 schrieb Gal Pressman:
> > > On 23/08/2021 13:43, Christian König wrote:
> > > > Am 21.08.21 um 11:16 schrieb Gal Pressman:
> &
sgt_append->sgt.nents += added_nents;
> + sgt_append->sgt.orig_nents = sgt_append->sgt.nents;
> + sgt_append->prv = s;
Why is nents being touched here?
Shouldn't it just be
sgt_append->sgt.orig_nents += added_nents;
sgt_append->prv = s;
?
Let me know I can fix it
Jason
On Wed, Aug 25, 2021 at 05:15:52AM +1000, Dave Airlie wrote:
> On Wed, 25 Aug 2021 at 03:36, John Hubbard wrote:
> >
> > On 8/24/21 10:32 AM, Jason Gunthorpe wrote:
> > ...
> > >>> And yes at least for the amdgpu driver we migrate the memory to host
> >
On Wed, Aug 25, 2021 at 02:27:08PM +0200, Christian König wrote:
> Am 25.08.21 um 14:18 schrieb Jason Gunthorpe:
> > On Wed, Aug 25, 2021 at 08:17:51AM +0200, Christian König wrote:
> >
> > > The only real option where you could do P2P with buffer pinning are those
>
201 - 300 of 3569 matches
Mail list logo
