On Tue, Jun 15, 2021 at 07:21:57AM +0200, Greg Kroah-Hartman wrote:
> This looks much better as far as the driver core changes go, thank you
> for doing this.
>
> I'm guessing there will be at least one more revision of this.
Yes.
> Do you
> want this to go through my driver core tree or is ther
On Tue, Jun 15, 2021 at 07:17:43AM +0200, Greg Kroah-Hartman wrote:
> Like Kirti said, 0 needs to be handled here. Did this not spew a lot of
> warnings in the logs?
Trying again it did. But I didn't even notice given all the crap
printed during a typical boot these days..
__
On Mon, Jun 14, 2021 at 05:08:36PM +0200, Christoph Hellwig wrote:
> This is my alternative take on this series from Jason:
>
> https://lore.kernel.org/dri-devel/87czsszi9i@redhat.com/T/
>
> The mdev/vfio parts are exactly the same, but this solves the driver core
> changes for the direct pro
On Mon, Jun 14, 2021 at 05:08:41PM +0200, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> This is intended as a replacement API for device_bind_driver(). It has at
> least the following benefits:
>
> - Internal locking. Few of the users of device_bind_driver() follow the
> locking rules
>
On Mon, Jun 14, 2021 at 05:08:39PM +0200, Christoph Hellwig wrote:
> Currently really_probe() returns 1 on success and 0 if the probe() call
> fails. This return code arrangement is designed to be useful for
> __device_attach_driver() which is walking the device list and trying every
> driver. 0 me
On Mon, Jun 14, 2021 at 05:08:38PM +0200, Christoph Hellwig wrote:
> really_probe tries to special case errors from ->probe, but due to all
> other initialization added to the function over time now a lot of
> internal errors hit that code path as well. Untangle that by adding
> a new probe_err lo
On Mon, Jun 14, 2021 at 05:08:37PM +0200, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> Checking if the dev is dead or if the dev is already bound is a required
> precondition to invoking driver_probe_device(). All the call chains
> leading here duplicate these checks.
>
> Add it directly
== Series Details ==
Series: Explicity steer l3bank multicast reads when necessary
URL : https://patchwork.freedesktop.org/series/91485/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10222 -> Patchwork_20365
Summary
---
On Mon, Jun 14, 2021 at 2:16 PM Christoph Hellwig wrote:
>
> On Fri, Jun 11, 2021 at 11:26:46PM +0800, Claire Chang wrote:
> > + spin_lock_init(&mem->lock);
> > + for (i = 0; i < mem->nslabs; i++) {
> > + mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
> > +
On Fri, Jun 11, 2021 at 1:42 AM Imre Deak wrote:
>
> Disconnect TypeC PHYs during system suspend and shutdown, even with the
> corresponding TypeC sink still plugged to its connector, since leaving
> the PHY connected causes havoc at least during system resume in the
> presence of an Nvidia card.
== Series Details ==
Series: Explicity steer l3bank multicast reads when necessary
URL : https://patchwork.freedesktop.org/series/91485/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
16715f8678e5 drm/i915: extract steered reg access to common function
-:89: CHECK:MULTIPLE_ASSIG
== Series Details ==
Series: drm/i915/jsl: Add W/A 1409054076 for JSL (rev5)
URL : https://patchwork.freedesktop.org/series/90129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10220_full -> Patchwork_20357_full
Summary
---
On Mon, Jun 14, 2021 at 06:05:19PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 6/8/2021 12:17 PM, Matthew Brost wrote:
> > The submission tasklet operates on i915_sched_engine, thus it is the
> > correct place for it.
> >
> > v3:
> > (Jason Ekstrand)
> >Change sched_engine->engine to a v
Because Render Power Gating restricts us to just a single subslice as a
valid steering target for reads of multicast registers in a SUBSLICE
range, the default steering we setup at init may not lead to a suitable
target for L3BANK multicast register. In cases where it does not, use
explicit runtim
Although most of our multicast registers are replicated per-subslice, we
also have a small number of multicast registers that are replicated
per-l3 bank instead. For both types of multicast registers we need to
make sure we steer reads of these registers to a valid instance.
Ideally we'd like to f
From: Daniele Ceraolo Spurio
New steering cases will be added in the follow-up patches, so prepare a
common helper to avoid code duplication.
Cc: Tvrtko Ursulin
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 41 +---
We've recently learned that when steering reads of multicast registers
that use 'subslice' replication, it's not only important to steer to a
subslice that isn't fused off, but also to steer to the lowest-numbered
subslice. This is because when Render Power Gating is enabled, grabbing
forcewake wi
== Series Details ==
Series: Update firmware to v62.0.0 (rev3)
URL : https://patchwork.freedesktop.org/series/91106/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10222 -> Patchwork_20364
Summary
---
**SUCCESS**
N
== Series Details ==
Series: Update firmware to v62.0.0 (rev3)
URL : https://patchwork.freedesktop.org/series/91106/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
/home/cidrm/kernel/Documentation/gpu/i915:526:
./drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb
== Series Details ==
Series: Update firmware to v62.0.0 (rev3)
URL : https://patchwork.freedesktop.org/series/91106/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/
== Series Details ==
Series: Update firmware to v62.0.0 (rev3)
URL : https://patchwork.freedesktop.org/series/91106/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9deadb9a2e73 drm/i915/guc: Introduce unified HXG messages
79a6d8e1bf6a drm/i915/guc: Update firmware to v62.0.0
-:7
== Series Details ==
Series: drm/i915: Move system memory to TTM for discrete (rev5)
URL : https://patchwork.freedesktop.org/series/90898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10222 -> Patchwork_20363
Summary
-
== Series Details ==
Series: drm/i915: Move system memory to TTM for discrete (rev5)
URL : https://patchwork.freedesktop.org/series/90898/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/g
== Series Details ==
Series: i915 TTM sync accelerated migration and clear
URL : https://patchwork.freedesktop.org/series/91463/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10222 -> Patchwork_20362
Summary
---
**SU
On 6/8/2021 12:17 PM, Matthew Brost wrote:
The submission tasklet operates on i915_sched_engine, thus it is the
correct place for it.
v3:
(Jason Ekstrand)
Change sched_engine->engine to a void* private data pointer
Add kernel doc
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i9
== Series Details ==
Series: i915 TTM sync accelerated migration and clear
URL : https://patchwork.freedesktop.org/series/91463/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a9a395f920ef drm/i915: Reference objects on the ww object list
161d138ac072 drm/i915: Break out dma_res
== Series Details ==
Series: series starting with [01/10] driver core: Pull required checks into
driver_probe_device()
URL : https://patchwork.freedesktop.org/series/91461/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10222 -> Patchwork_20361
== Series Details ==
Series: series starting with [01/10] driver core: Pull required checks into
driver_probe_device()
URL : https://patchwork.freedesktop.org/series/91461/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won'
== Series Details ==
Series: series starting with [01/10] driver core: Pull required checks into
driver_probe_device()
URL : https://patchwork.freedesktop.org/series/91461/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
852f63054431 driver core: Pull required checks into driver
== Series Details ==
Series: drm/i915/ehl: Update MOCS table for EHL (rev3)
URL : https://patchwork.freedesktop.org/series/61409/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10222 -> Patchwork_20360
Summary
---
**S
== Series Details ==
Series: drm/i915/ehl: Update MOCS table for EHL (rev3)
URL : https://patchwork.freedesktop.org/series/61409/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8aa2ff58ba7d drm/i915/ehl: Update MOCS table for EHL
-:8: WARNING:COMMIT_LOG_LONG_LINE: Possible unwra
On 6/8/2021 12:17 PM, Matthew Brost wrote:
Rather than touching execlist specific structures in the generic
scheduling code, add a callback function in the backend.
I think this could do with a better wording to explain the reasoning
more, something like: "Not all back-ends require a kick a
== Series Details ==
Series: drm/i915: __GFP_RETRY_MAYFAIL allocations in stable kernels
URL : https://patchwork.freedesktop.org/series/91456/
State : failure
== Summary ==
Applying: drm/i915: __GFP_RETRY_MAYFAIL allocations in stable kernels
error: sha1 information is lacking or useless
(dri
== Series Details ==
Series: drm/i915: Be more gentle with exiting non-persistent context (rev3)
URL : https://patchwork.freedesktop.org/series/89644/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10222 -> Patchwork_20358
S
On 6/8/2021 12:17 PM, Matthew Brost wrote:
The schedule function should be in the schedule object.
v3:
(Jason Ekstrand)
Add kernel doc
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 ++--
drive
On 6/8/2021 12:17 PM, Matthew Brost wrote:
Move active request tracking and its lock to i915_sched_engine. This
lock is also the submission lock so having it in the i915_sched_engine
is the correct place.
v3:
(Jason Ekstrand)
Add kernel doc
Signed-off-by: Matthew Brost
Reviewed-by: D
On 6/8/2021 12:17 PM, Matthew Brost wrote:
Introduce i915_sched_engine object which is lower level data structure
that i915_scheduler / generic code can operate on without touching
execlist specific structures. This allows additional submission backends
to be added without breaking the layerin
On Thu, Jun 10, 2021 at 02:52:46PM -0700, john.c.harri...@intel.com wrote:
> From: Rodrigo Vivi
>
> All the static platform configuration per SKU is moving to
> this KVL table. User Space components can query and parse
> it to find the proper hw configuration instead of having
> to hardcode it.
>
== Series Details ==
Series: drm/i915: Move system memory to TTM for discrete (rev4)
URL : https://patchwork.freedesktop.org/series/90898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10219_full -> Patchwork_20356_full
Sum
+Lakshmi
On Sat, Jun 12, 2021 at 07:35:35AM +, Patchwork wrote:
== Series Details ==
Series: drm/i915/xelpd: break feature inheritance
URL : https://patchwork.freedesktop.org/series/91422/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10214_full -> Patchwork_20352_full
== Series Details ==
Series: drm/i915/jsl: Add W/A 1409054076 for JSL (rev5)
URL : https://patchwork.freedesktop.org/series/90129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10220 -> Patchwork_20357
Summary
---
**
== Series Details ==
Series: drm/i915: allow DG1 autoprobe for CONFIG_BROKEN
URL : https://patchwork.freedesktop.org/series/91440/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10219_full -> Patchwork_20355_full
Summary
---
On Thu, Jun 10, 2021 at 02:52:47PM -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Various UMDs need to know the L3 bank count. So a query API has been
> added for it. Test that query.
>
> Signed-off-by: John Harrison
> ---
> include/drm-uapi/i915_drm.h | 1 +
> tests/i915/i
From: Michal Wajdeczko
GuC ABI documentation is now ready to be included in i915.rst
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Cc: Piotr Piórkowski
Reviewed-by: Matthew Brost
---
Documentation/gpu/i915.rst | 8
1 file changed, 8 insertions(+)
diff --git a/Docume
As part of enabling GuC submission [1] we need to update to the latest
and greatest firmware. This series does that. All backwards
compatibility breaking changes squashed into a single patch #2. Same
series sent to trybot [2] forcing GuC to be enabled to ensure we haven't
broke something.
v2: Addr
From: Michal Wajdeczko
Most of the changes to the 62.0.0 firmware revolved around CTB
communication channel. Conform to the new (stable) CTB protocol.
Signed-off-by: John Harrison
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h |
From: Michal Wajdeczko
New GuC firmware will unify format of MMIO and CTB H2G messages.
Introduce their definitions now to allow gradual transition of
our code to match new changes.
Signed-off-by: Matthew Brost
Signed-off-by: Michal Wajdeczko
Cc: Michał Winiarski
Reviewed-by: Daniele Ceraolo
On 6/14/2021 8:38 PM, Christoph Hellwig wrote:
really_probe tries to special case errors from ->probe, but due to all
other initialization added to the function over time now a lot of
internal errors hit that code path as well. Untangle that by adding
a new probe_err local variable and apply
On 6/9/2021 9:36 PM, Matthew Brost wrote:
From: Michal Wajdeczko
Format of the CTB messages has changed:
- support for multiple formats
- message fence is now part of the header
- reuse of unified HXG message formats
v2:
(Daniele)
- Better comment in ct_write()
Signed-off-by: Mic
On 6/9/2021 9:36 PM, Matthew Brost wrote:
From: Michal Wajdeczko
Definition of the CTB registration action has changed.
Add some ABI documentation and implement required changes.
v2:
(Checkpoint)
- Fix warnings
(Daniele)
- Drop FIXME
(John H)
- Drop value in kernel doc, just u
On 6/9/2021 9:36 PM, Matthew Brost wrote:
From: Michal Wajdeczko
Definition of the CTB descriptor has changed, leaving only
minimal shared fields like HEAD/TAIL/STATUS.
Both HEAD and TAIL are now in dwords.
Add some ABI documentation and implement required changes.
v2:
(Daniele)
- Dr
On 6/9/2021 9:36 PM, Matthew Brost wrote:
From: Michal Wajdeczko
The MMIO based Host-to-GuC communication protocol has been
updated to use unified HXG messages.
Update our intel_guc_send_mmio() function by correctly handle
BUSY, RETRY and FAILURE replies. Also update our documentation.
Sinc
On 6/14/21 6:26 PM, Thomas Hellström wrote:
From: Ramalingam C
Invokes the pipelined page migration through blt, for
i915_ttm_move requests of eviction and also obj clear.
Signed-off-by: Ramalingam C
---
v2:
- subfunction for accel_move (Thomas)
- engine_pm_get/put around context_move/cl
After a TTM move or object init we need to update the i915 gem flags and
caching settings to reflect the new placement. Currently caching settings
are not changed during the lifetime of an object, although that might
change moving forward if we run into performance issues or issues with
WC system p
The object ops i915_GEM_OBJECT_HAS_IOMEM and the object
I915_BO_ALLOC_STRUCT_PAGE flags are considered immutable by
much of our code. Introduce a new mem_flags member to hold these
and make sure checks for these flags being set are either done
under the object lock or with pages properly pinned. Th
Instead of relying on a static placement, calculate at get_pages() time.
This should work for LMEM regions and system for now. For stolen we need
to take preallocated range into account. That will if needed be added
later.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2:
- Fixed
For discrete, use TTM for both cached and WC system memory. That means
we currently rely on the TTM memory accounting / shrinker. For cached
system memory we should consider remaining shmem-backed, which can be
implemented from our ttm_tt_populate callback. We can then also reuse our
own very elabo
Early implementation of moving system memory for discrete cards over to
TTM. We first add the notion of objects being migratable under the object
lock to i915 gem, and add some asserts to verify that objects are either
locked or pinned when the placement is checked by the gem code.
Patch 2 and 3 d
== Series Details ==
Series: drm/i915: Document the Virtual Engine uAPI (rev2)
URL : https://patchwork.freedesktop.org/series/91406/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10218_full -> Patchwork_20354_full
Summary
-
== Series Details ==
Series: drm/i915: Move system memory to TTM for discrete (rev4)
URL : https://patchwork.freedesktop.org/series/90898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10219 -> Patchwork_20356
Summary
-
On 6/9/2021 9:36 PM, Matthew Brost wrote:
From: Michal Wajdeczko
New GuC firmware will unify format of MMIO and CTB H2G messages.
Introduce their definitions now to allow gradual transition of
our code to match new changes.
Signed-off-by: Matthew Brost
Signed-off-by: Michal Wajdeczko
Cc: M
== Series Details ==
Series: drm/i915: Move system memory to TTM for discrete (rev4)
URL : https://patchwork.freedesktop.org/series/90898/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/g
On 14/06/2021 17:26, Thomas Hellström wrote:
It's unused with the exception of selftest. Replace a call in the
memory_region live selftest with a call into a corresponding
function in the new migrate code.
I guess we do lose some coverage around blitting massively sized GEM
objects using the h
On 6/14/21 6:33 PM, Matthew Auld wrote:
On 14/06/2021 17:26, Thomas Hellström wrote:
It's not used anywhere.
Signed-off-by: Thomas Hellström
We do have to keep igt_client_tiled_blits subtest, it's not related to
the client blitting code and was added afterwards. Not completely sure
why it
On Sat, Jun 12, 2021 at 09:55:02AM +, Surendrakumar Upadhyay, TejaskumarX
wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: 11 June 2021 23:36
> > To: Surendrakumar Upadhyay, TejaskumarX
> >
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PAT
On 14/06/2021 17:26, Thomas Hellström wrote:
It's not used anywhere.
Signed-off-by: Thomas Hellström
We do have to keep igt_client_tiled_blits subtest, it's not related to
the client blitting code and was added afterwards. Not completely sure
why it's in this file.
With that added back,
R
On Mon, Jun 14, 2021 at 10:35:30AM +0200, Zbigniew Kempczyński wrote:
> On Fri, Jun 11, 2021 at 04:54:32AM -0400, Rodrigo Vivi wrote:
> > On Fri, Jun 11, 2021 at 08:09:00AM +0200, Zbigniew Kempczyński wrote:
> > > On Thu, Jun 10, 2021 at 10:36:12AM -0400, Rodrigo Vivi wrote:
> > > > On Thu, Jun 10,
From: Chris Wilson
If we pipeline the PTE updates and then do the copy of those pages
within a single unpreemptible command packet, we can submit the copies
and leave them to be scheduled without having to synchronously wait
under a global lock. In order to manage migration, we need to
preallocat
From: Chris Wilson
Set up a default migration context on the GT and use it from the
selftests.
Add a perf selftest and make sure we exercise LMEM if available.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v3:
- Sk
It's unused with the exception of selftest. Replace a call in the
memory_region live selftest with a call into a corresponding
function in the new migrate code.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 -
.../gpu/drm/i915/gem/i915_gem_object_blt.c
From: Chris Wilson
Update the PTE and emit a clear within a single unpreemptible packet
such that we can schedule and pipeline clears.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
---
v3:
- Handle engine instances correctly (Reported by Matthew
From: Ramalingam C
Invokes the pipelined page migration through blt, for
i915_ttm_move requests of eviction and also obj clear.
Signed-off-by: Ramalingam C
---
v2:
- subfunction for accel_move (Thomas)
- engine_pm_get/put around context_move/clear (Thomas)
- Invalidation at accel_clear (Thom
It's not used anywhere.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 -
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 355 -
.../gpu/drm/i915/gem/i915_gem_client_blt.h| 21 -
.../i915/gem/selftests/i915_gem_client_blt.c | 704 ---
From: Chris Wilson
Allow internal clients to create and destroy a pinned context.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
v2:
- (Thomas) Export also the pinned context destructor
---
drivers/gpu/drm/i915/gt/intel_engine.h| 11 +
drivers/gpu/drm/i915/gt/intel_engi
From: Chris Wilson
In the next patch, we will want to look at the dma addresses of
individual page tables, so add a routine to iterate over them.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 49
drivers/gpu/drm/i
From: Chris Wilson
In the next patch, we will want to write a PTE for an explicit
dma address, outside of the usual vma.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/driv
Since the ww transaction endpoint easily end up far out-of-scope of
the objects on the ww object list, particularly for contending lock
objects, make sure we reference objects on the list so they don't
disappear under us.
This comes with a performance penalty so it's been debated whether this
is r
Introduce a for_i915_gem_ww(){} utility to help make the code
around a ww transaction more readable.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_ww.h | 31 +-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git
As we're about to add more ww-related functionality,
break out the dma_resv ww locking utilities to their own files
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2:
- Make sure filenames are sorted in include file lists and Makefile
(Reported by Matthew Auld)
---
drivers/gpu/
This patchset implements synchronous accelerated migration and clearing
for i915 on TTM. We plan to follow up with these operations made
asynchronous to the extent of TTM support for that:
A couple of patches from Chris which implement pipelined migration and
clears by atomically writing the PTEs
== Series Details ==
Series: drm/i915: allow DG1 autoprobe for CONFIG_BROKEN
URL : https://patchwork.freedesktop.org/series/91440/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10219 -> Patchwork_20355
Summary
---
**
On Thu, Jun 10, 2021 at 9:55 AM Pekka Paalanen wrote:
>
> On Tue, 8 Jun 2021 19:43:15 +0200
> Werner Sembach wrote:
>
> > Add a new general drm property "active bpc" which can be used by graphic
> > drivers
> > to report the applied bit depth per pixel back to userspace.
> >
Maybe "bit depth p
From: Jason Gunthorpe
This is straightforward conversion, the mdev_state is actually serving as
the vfio_device and we can replace all the mdev_get_drvdata()'s and the
wonky dead code with a simple container_of().
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
Signed-off-by: Chr
From: Jason Gunthorpe
This is straightforward conversion, the mdev_state is actually serving as
the vfio_device and we can replace all the mdev_get_drvdata()'s and the
wonky dead code with a simple container_of().
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
Signed-off-by: Chr
From: Jason Gunthorpe
This is straightforward conversion, the mdev_state is actually serving as
the vfio_device and we can replace all the mdev_get_drvdata()'s and the
wonky dead code with a simple container_of()
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
Signed-off-by: Chri
From: Jason Gunthorpe
For some reason the vfio_mdev shim mdev_driver has its own module and
kconfig. As the next patch requires access to it from mdev.ko merge the
two modules together and remove VFIO_MDEV_DEVICE.
A later patch deletes this driver entirely.
Signed-off-by: Jason Gunthorpe
Signe
From: Jason Gunthorpe
This allows a mdev driver to opt out of using vfio_mdev.c, instead the
driver will provide a 'struct mdev_driver' and register directly with the
driver core.
Much of mdev_parent_ops becomes unused in this mode:
- create()/remove() are done via the mdev_driver probe()/remove
From: Jason Gunthorpe
This is intended as a replacement API for device_bind_driver(). It has at
least the following benefits:
- Internal locking. Few of the users of device_bind_driver() follow the
locking rules
- Calls device driver probe() internally. Notably this means that devm
support
EPROBE_DEFER is an internal kernel error code and it should not be leaked
to userspace via the bind_store() sysfs. Userspace doesn't have this
constant and cannot understand it.
Further, it doesn't really make sense to have userspace trigger a deferred
probe via bind_store(), which could eventuall
really_probe tries to special case errors from ->probe, but due to all
other initialization added to the function over time now a lot of
internal errors hit that code path as well. Untangle that by adding
a new probe_err local variable and apply the special casing only to
that.
Signed-off-by: Chr
Currently really_probe() returns 1 on success and 0 if the probe() call
fails. This return code arrangement is designed to be useful for
__device_attach_driver() which is walking the device list and trying every
driver. 0 means to keep trying.
However, it is not useful for the other places that ca
From: Jason Gunthorpe
Checking if the dev is dead or if the dev is already bound is a required
precondition to invoking driver_probe_device(). All the call chains
leading here duplicate these checks.
Add it directly to driver_probe_device() so the precondition is clear and
remove the checks from
This is my alternative take on this series from Jason:
https://lore.kernel.org/dri-devel/87czsszi9i@redhat.com/T/
The mdev/vfio parts are exactly the same, but this solves the driver core
changes for the direct probing without the in/out flag that Greg hated,
which cause a little more work, b
On 6/14/21 3:48 PM, Matthew Auld wrote:
On Mon, 14 Jun 2021 at 12:54, Thomas Hellström
wrote:
After a TTM move or object init we need to update the i915 gem flags and
caching settings to reflect the new placement. Currently caching settings
are not changed during the lifetime of an object, alt
Jason,
I couldn't find patch 1,2,4 and 5 of these series. Can you please keep
k...@vger.kernel.org cc for all patches?
Also it will be helpful if you can add version prefix, eg. 'v3' for this
series, in subject line.
Thanks,
Kirti
On 6/8/2021 6:25 AM, Jason Gunthorpe wrote:
This is a "v3"
From: Matt Roper
These extra EHL entries were not behaving as expected without proper
flushing implemented in kernel.
https://cgit.freedesktop.org/drm-tip/commit/?id=a679f58d051025db6fa86226c4d35650b75e990f
patch introduces proper flushing to make it work as expected.
Hence adding those EHL entr
== Series Details ==
Series: drm/i915: Document the Virtual Engine uAPI (rev2)
URL : https://patchwork.freedesktop.org/series/91406/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10218 -> Patchwork_20354
Summary
---
On Mon, 14 Jun 2021 at 12:54, Thomas Hellström
wrote:
>
> After a TTM move or object init we need to update the i915 gem flags and
> caching settings to reflect the new placement. Currently caching settings
> are not changed during the lifetime of an object, although that might
> change moving for
== Series Details ==
Series: drm/i915: Document the Virtual Engine uAPI (rev2)
URL : https://patchwork.freedesktop.org/series/91406/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
af02f5aa318e drm/i915: Document the Virtual Engine uAPI
-:76: WARNING:SPACE_BEFORE_TAB: please, no
On Fri, Jun 11, 2021 at 02:40:41PM +0200, Cornelia Huck wrote:
> On Mon, Jun 07 2021, Jason Gunthorpe wrote:
>
> > For some reason the vfio_mdev shim mdev_driver has its own module and
> > kconfig. As the next patch requires access to it from mdev.ko merge the
> > two modules together and remove
1 - 100 of 126 matches
Mail list logo
