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
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
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
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
Reviewed-by: Rodrigo Vivi
---
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: Daniele Ceraolo Spurio
---
Rather passing around an intel_engine_cs in the scheduling code, pass
around a i915_sched_engine.
v3:
(Jason Ekstrand)
Add READ_ONCE around rq->engine in lock_sched_engine
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
.../drm/i915/gt/intel_execlists_submission.c | 11 +++--
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 layering. Currently the execlists
backend uses 1 of
Add wrapper function around RB tree to determine if i915_sched_engine is
empty.
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 6 +++---
Not all back-ends require a kick after a scheduling update, so make the
kick a call-back function that the back-end can opt-in to. Also move
the current kick function from the scheduler to the execlists file as it
is specific to that back-end.
Signed-off-by: Matthew Brost
Reviewed-by: Daniele
As discussed in [1] we are breaking that large series into a several
smaller ones. This series is stand alone patch part of step #4 which has
no other dependencies or patches relevant to it.
v2:
(Daniel Vetter):
- Split into several smaller patches
- Add kernel doc for i915_sched_engine
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
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 ---
Rather than touching schedule state in the generic PM code, reset the
priolist allocation when empty in the submission code. Add a wrapper
function to do this and update the backends to call it in the correct
place.
v3:
(Jason Ekstrand)
Update patch commit message with a better description
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
v4:
(Daniele)
Update private_data comment
Set queue_priority_hint in kick_execlists
v5:
(CI)
== Series Details ==
Series: Introduce i915_sched_engine object (rev5)
URL : https://patchwork.freedesktop.org/series/90630/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10226 -> Patchwork_20378
Summary
---
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 49 ++--
1 file changed, 24 insertions(+), 25
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 7
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/swiotlb.c
Always have the pointer to the swiotlb pool used in struct device. This
could help simplify the code for other pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/base/core.c| 4
include/linux/device.h | 4
kernel/dma/swiotlb.c | 8
3 files
On Wed, Jun 16, 2021 at 12:04:16PM +0800, Claire Chang wrote:
> Just noticed that after propagating swiotlb_force setting into
> io_tlb_default_mem->force, the memory allocation behavior for
> swiotlb_force will change (i.e. always skipping arch_dma_alloc and
> dma_direct_alloc_from_pool).
Yes, I
== Series Details ==
Series: Introduce i915_sched_engine object (rev5)
URL : https://patchwork.freedesktop.org/series/90630/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10226_full -> Patchwork_20378_full
Summary
---
On Wed, Jun 16, 2021 at 12:59 PM Christoph Hellwig wrote:
>
> On Wed, Jun 16, 2021 at 12:04:16PM +0800, Claire Chang wrote:
> > Just noticed that after propagating swiotlb_force setting into
> > io_tlb_default_mem->force, the memory allocation behavior for
> > swiotlb_force will change (i.e.
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
Propagate the swiotlb_force setting into io_tlb_default_mem->force and
use it to determine whether to bounce the data or not. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
include/linux/swiotlb.h | 11 +++
Add a new function, swiotlb_release_slots, to make the code reusable for
supporting different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
Add the functions, swiotlb_{alloc,free} to support the memory allocation
from restricted DMA pool.
The restricted DMA pool is preferred if available.
Note that since coherent allocation needs remapping, one must set up
another device coherent pool by shared-dma-pool and use
Rename find_slots to swiotlb_find_slots and move the maintenance of
alloc_size to it for better code reusability later.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
On Wed, Jun 16, 2021 at 11:54 AM Claire Chang wrote:
>
> Add the functions, swiotlb_{alloc,free} to support the memory allocation
> from restricted DMA pool.
>
> The restricted DMA pool is preferred if available.
>
> Note that since coherent allocation needs remapping, one must set up
> another
On Wed, Jun 16, 2021 at 01:10:02PM +0800, Claire Chang wrote:
> On Wed, Jun 16, 2021 at 12:59 PM Christoph Hellwig wrote:
> >
> > On Wed, Jun 16, 2021 at 12:04:16PM +0800, Claire Chang wrote:
> > > Just noticed that after propagating swiotlb_force setting into
> > > io_tlb_default_mem->force, the
v11 https://lore.kernel.org/patchwork/cover/1447216/
On Tue, Jun 15, 2021 at 9:27 PM Claire Chang wrote:
>
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or
On Tue, Jun 15, 2021 at 05:35:15PM -0300, Jason Gunthorpe wrote:
> Yes, the rest of the drivers will get converted eventually too. There
> is no reason to hold things back. Depending on timelines we might be
> able to get AP into this cycle too...
And I have a WIP tree to get rid of the weird
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 33 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 6
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 36
== Series Details ==
Series: drm/i915/ttm: Fix memory leaks
URL : https://patchwork.freedesktop.org/series/91512/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225_full -> Patchwork_20370_full
Summary
---
== Series Details ==
Series: i915 TTM sync accelerated migration and clear (rev3)
URL : https://patchwork.freedesktop.org/series/91463/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10225_full -> Patchwork_20371_full
== Series Details ==
Series: Update firmware to v62.0.0 (rev4)
URL : https://patchwork.freedesktop.org/series/91106/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10226 -> Patchwork_20379
Summary
---
**SUCCESS**
== Series Details ==
Series: Explicity steer l3bank multicast reads when necessary (rev3)
URL : https://patchwork.freedesktop.org/series/91485/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10226 -> Patchwork_20380
Summary
On Tue, Jun 15, 2021 at 08:30:23AM -0700, Matt Roper wrote:
> On Tue, Jun 15, 2021 at 05:11:04AM -0400, Rodrigo Vivi wrote:
> > On Tue, Jun 15, 2021 at 05:08:20AM -0400, Rodrigo Vivi wrote:
> > > On Mon, Jun 14, 2021 at 08:34:32PM -0700, Matt Roper wrote:
> > > > Although most of our multicast
On Wed, 2021-06-09 at 00:09 +, Patchwork wrote:
Patch Details
Series: drm/i915/adl_p: Add initial ADL_P Workarounds (rev2)
URL:https://patchwork.freedesktop.org/series/91127/
State: success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20314/index.html
CI Bug Log -
== Series Details ==
Series: series starting with [01/10] driver core: Pull required checks into
driver_probe_device()
URL : https://patchwork.freedesktop.org/series/91520/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225_full -> Patchwork_20373_full
On 6/15/2021 1:59 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
v4:
(Daniele)
Update private_data comment
Set
== Series Details ==
Series: Update firmware to v62.0.0 (rev4)
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.
-
== Series Details ==
Series: Introduce i915_sched_engine object (rev4)
URL : https://patchwork.freedesktop.org/series/90630/
State : failure
== Summary ==
Applying: drm/i915: Move priolist to new i915_sched_engine object
Applying: drm/i915: Add i915_sched_engine_is_empty function
Applying:
== Series Details ==
Series: Explicity steer l3bank multicast reads when necessary (rev2)
URL : https://patchwork.freedesktop.org/series/91485/
State : failure
== Summary ==
Applying: drm/i915: extract steered reg access to common function
Applying: drm/i915: Add GT support for multiple types
== Series Details ==
Series: Update firmware to v62.0.0 (rev4)
URL : https://patchwork.freedesktop.org/series/91106/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
20bd5d817f52 drm/i915/guc: Introduce unified HXG messages
899d9ce395b2 drm/i915/guc: Update firmware to v62.0.0
== Series Details ==
Series: Explicity steer l3bank multicast reads when necessary (rev3)
URL : https://patchwork.freedesktop.org/series/91485/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7ba06b9980dc drm/i915: extract steered reg access to common function
-:90:
On Tue, Jun 15, 2021 at 03:48:32PM -0400, Rodrigo Vivi wrote:
> On Tue, Jun 15, 2021 at 08:30:23AM -0700, Matt Roper wrote:
> > On Tue, Jun 15, 2021 at 05:11:04AM -0400, Rodrigo Vivi wrote:
> > > On Tue, Jun 15, 2021 at 05:08:20AM -0400, Rodrigo Vivi wrote:
> > > > On Mon, Jun 14, 2021 at
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
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.
v2:
(Michal)
Add values back to kernel DOC for actions
(Docs)
Add 'CT buffer' back in to fix warning
Signed-off-by: John Harrison
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
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:
On Tue, Jun 15, 2021 at 09:27:02PM +0800, Claire Chang wrote:
> Always have the pointer to the swiotlb pool used in struct device. This
> could help simplify the code for other pools.
Applying: swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used
error: patch failed: kernel/dma/swiotlb.c:339
== Series Details ==
Series: New uAPI drm properties for color management
URL : https://patchwork.freedesktop.org/series/91523/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10225_full -> Patchwork_20374_full
Summary
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
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
Reviewed-by: Rodrigo Vivi
---
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
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
On Tue, 15 Jun 2021 15:35:09 +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 probing
On Tue, 15 Jun 2021 15:35:13 +0200
Christoph Hellwig wrote:
> @@ -547,10 +538,9 @@ static int call_driver_probe(struct device *dev, struct
> device_driver *drv)
>
> static int really_probe(struct device *dev, struct device_driver *drv)
> {
> - int local_trigger_count =
== Series Details ==
Series: drm/i915: Perform execbuffer object locking as a separate step
URL : https://patchwork.freedesktop.org/series/91506/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225_full -> Patchwork_20369_full
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
v4:
(Daniele)
Update private_data comment
Set queue_priority_hint in kick_execlists
Signed-off-by:
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 layering. Currently the execlists
backend uses 1 of
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
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 ---
Rather passing around an intel_engine_cs in the scheduling code, pass
around a i915_sched_engine.
v3:
(Jason Ekstrand)
Add READ_ONCE around rq->engine in lock_sched_engine
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
.../drm/i915/gt/intel_execlists_submission.c | 11 +++--
Rather than touching schedule state in the generic PM code, reset the
priolist allocation when empty in the submission code. Add a wrapper
function to do this and update the backends to call it in the correct
place.
v3:
(Jason Ekstrand)
Update patch commit message with a better description
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: Daniele Ceraolo Spurio
---
Not all back-ends require a kick after a scheduling update, so make the
kick a call-back function that the back-end can opt-in to. Also move
the current kick function from the scheduler to the execlists file as it
is specific to that back-end.
Signed-off-by: Matthew Brost
Reviewed-by: Daniele
Add wrapper function around RB tree to determine if i915_sched_engine is
empty.
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 6 +++---
As discussed in [1] we are breaking that large series into a several
smaller ones. This series is stand alone patch part of step #4 which has
no other dependencies or patches relevant to it.
v2:
(Daniel Vetter):
- Split into several smaller patches
- Add kernel doc for i915_sched_engine
On Fri, Jun 04, 2021 at 09:48:39PM +0200, Hans de Goede wrote:
> Make dp_altmode_notify() handle the dp->data.conf == 0 case too,
> rather then having separate code-paths for this in various places
> which call it.
>
> Reviewed-by: Heikki Krogerus
> Tested-by: Heikki Krogerus
> Signed-off-by:
On Fri, Jun 04, 2021 at 09:48:40PM +0200, Hans de Goede wrote:
> Use the new drm_connector_oob_hotplug_event() functions to let drm/kms
> drivers know about DisplayPort over Type-C hotplug events.
>
> Reviewed-by: Heikki Krogerus
> Tested-by: Heikki Krogerus
> Signed-off-by: Hans de Goede
On Fri, Jun 04, 2021 at 09:48:32PM +0200, Hans de Goede wrote:
> Here is v3 of my patchset making DP over Type-C work on devices where the
> Type-C controller does not drive the HPD pin on the GPU, but instead
> we need to forward HPD events from the Type-C controller to the DRM driver.
>
>
On Fri, Jun 4, 2021 at 11:57 PM Kai-Heng Feng
wrote:
>
> On Thu, May 20, 2021 at 2:58 PM Kai-Heng Feng
> wrote:
> >
> > On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
> > to discrete GFX after S3. This is not desirable, because userspace will
> > treat connected display
On Thu, 10 Jun 2021 16:14:42 -0500
Jason Ekstrand wrote:
> This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds
> documentation for DMA_BUF_IOCTL_SYNC.
>
> v2 (Daniel Vetter):
> - Fix a couple typos
> - Add commentary about synchronization with other devices
> - Use item
Fix two memory leaks introduced with the ttm backend.
Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
== Series Details ==
Series: drm/i915: Perform execbuffer object locking as a separate step
URL : https://patchwork.freedesktop.org/series/91506/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225 -> Patchwork_20369
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
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
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
Reviewed-by: Thomas Hellström
---
v2:
- subfunction for accel_move (Thomas)
- engine_pm_get/put around context_move/clear (Thomas)
-
It's not used anywhere.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v4:
- Add back the igt_client_tiled_blits selftest (Suggested by Matthew Auld)
---
drivers/gpu/drm/i915/Makefile | 2 +-
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 355
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
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 1 -
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
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)
---
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
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
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
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 +
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
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:
-
== Series Details ==
Series: drm/i915/ttm: Fix memory leaks
URL : https://patchwork.freedesktop.org/series/91512/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225 -> Patchwork_20370
Summary
---
**SUCCESS**
No
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,
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
v10 here: https://lore.kernel.org/patchwork/cover/1446882/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Jun 15, 2021 at 09:27:05PM +0800, Claire Chang wrote:
> Propagate the swiotlb_force setting into io_tlb_default_mem->force and
> use it to determine whether to bounce the data or not. This will be
> useful later to allow for different pools.
>
> Signed-off-by: Claire Chang
Looks good,
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
On Tue, Jun 15, 2021 at 09:27:04PM +0800, Claire Chang wrote:
> Update is_swiotlb_active to add a struct device argument. This will be
> useful later to allow for different pools.
>
> Signed-off-by: Claire Chang
Looks good,
Reviewed-by: Christoph Hellwig
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:
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:
== Series Details ==
Series: drm/i915/jsl: Add W/A 1409054076 for JSL (rev6)
URL : https://patchwork.freedesktop.org/series/90129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225 -> Patchwork_20368
Summary
---
1 - 100 of 203 matches
Mail list logo
