Re: [Intel-gfx] Allow mdev drivers to directly create the vfio_device (v2 / alternative)

2021-06-14 Thread Christoph Hellwig
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

Re: [Intel-gfx] [PATCH 02/10] driver core: Better distinguish probe errors in really_probe

2021-06-14 Thread Christoph Hellwig
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..

Re: [Intel-gfx] Allow mdev drivers to directly create the vfio_device (v2 / alternative)

2021-06-14 Thread Greg Kroah-Hartman
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

Re: [Intel-gfx] [PATCH 05/10] driver core: Export device_driver_attach()

2021-06-14 Thread Greg Kroah-Hartman
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

Re: [Intel-gfx] [PATCH 03/10] driver core: Flow the return code from ->probe() through to sysfs bind

2021-06-14 Thread Greg Kroah-Hartman
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

Re: [Intel-gfx] [PATCH 02/10] driver core: Better distinguish probe errors in really_probe

2021-06-14 Thread Greg Kroah-Hartman
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

Re: [Intel-gfx] [PATCH 01/10] driver core: Pull required checks into driver_probe_device()

2021-06-14 Thread Greg Kroah-Hartman
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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Explicity steer l3bank multicast reads when necessary

2021-06-14 Thread Patchwork
== 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

Re: [Intel-gfx] [PATCH v9 01/14] swiotlb: Refactor swiotlb init functions

2021-06-14 Thread Claire Chang
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(>lock); > > + for (i = 0; i < mem->nslabs; i++) { > > + mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i); > > +

Re: [Intel-gfx] [PATCH] drm/i915: Force a TypeC PHY disconnect during suspend/shutdown

2021-06-14 Thread Chris Chiu
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.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Explicity steer l3bank multicast reads when necessary

2021-06-14 Thread Patchwork
== 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:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/jsl: Add W/A 1409054076 for JSL (rev5)

2021-06-14 Thread Patchwork
== 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

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Move submission tasklet to i915_sched_engine

2021-06-14 Thread Matthew Brost
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

[Intel-gfx] [PATCH 3/3] drm/i915: Add support for explicit L3BANK steering

2021-06-14 Thread Matt Roper
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

[Intel-gfx] [PATCH 2/3] drm/i915: Add GT support for multiple types of multicast steering

2021-06-14 Thread Matt Roper
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

[Intel-gfx] [PATCH 1/3] drm/i915: extract steered reg access to common function

2021-06-14 Thread Matt Roper
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

[Intel-gfx] [PATCH 0/3] Explicity steer l3bank multicast reads when necessary

2021-06-14 Thread Matt Roper
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

[Intel-gfx] ✓ Fi.CI.BAT: success for Update firmware to v62.0.0 (rev3)

2021-06-14 Thread Patchwork
== 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**

[Intel-gfx] ✗ Fi.CI.DOCS: warning for Update firmware to v62.0.0 (rev3)

2021-06-14 Thread Patchwork
== 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:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Update firmware to v62.0.0 (rev3)

2021-06-14 Thread Patchwork
== 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. -

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Update firmware to v62.0.0 (rev3)

2021-06-14 Thread Patchwork
== 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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move system memory to TTM for discrete (rev5)

2021-06-14 Thread Patchwork
== 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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Move system memory to TTM for discrete (rev5)

2021-06-14 Thread Patchwork
== 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.

[Intel-gfx] ✓ Fi.CI.BAT: success for i915 TTM sync accelerated migration and clear

2021-06-14 Thread Patchwork
== 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 ---

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Move submission tasklet to i915_sched_engine

2021-06-14 Thread Daniele Ceraolo Spurio
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 ---

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915 TTM sync accelerated migration and clear

2021-06-14 Thread Patchwork
== 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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/10] driver core: Pull required checks into driver_probe_device()

2021-06-14 Thread Patchwork
== 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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/10] driver core: Pull required checks into driver_probe_device()

2021-06-14 Thread Patchwork
== 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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/10] driver core: Pull required checks into driver_probe_device()

2021-06-14 Thread Patchwork
== 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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ehl: Update MOCS table for EHL (rev3)

2021-06-14 Thread Patchwork
== 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 ---

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/ehl: Update MOCS table for EHL (rev3)

2021-06-14 Thread Patchwork
== 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

Re: [Intel-gfx] [PATCH 6/8] drm/i915: Add kick_backend function to i915_sched_engine

2021-06-14 Thread Daniele Ceraolo Spurio
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

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: __GFP_RETRY_MAYFAIL allocations in stable kernels

2021-06-14 Thread Patchwork
== 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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Be more gentle with exiting non-persistent context (rev3)

2021-06-14 Thread Patchwork
== 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

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Move engine->schedule to i915_sched_engine

2021-06-14 Thread Daniele Ceraolo Spurio
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 ++--

Re: [Intel-gfx] [PATCH 4/8] drm/i915: Move active tracking to i915_sched_engine

2021-06-14 Thread Daniele Ceraolo Spurio
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:

Re: [Intel-gfx] [PATCH 1/8] drm/i915: Move priolist to new i915_sched_engine object

2021-06-14 Thread Daniele Ceraolo Spurio
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

Re: [Intel-gfx] [PATCH i-g-t 1/2] tests/i915/query: Query, parse and validate the hwconfig table

2021-06-14 Thread Matthew Brost
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.

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Move system memory to TTM for discrete (rev4)

2021-06-14 Thread Patchwork
== 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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/xelpd: break feature inheritance

2021-06-14 Thread Lucas De Marchi
+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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/jsl: Add W/A 1409054076 for JSL (rev5)

2021-06-14 Thread Patchwork
== 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 ---

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: allow DG1 autoprobe for CONFIG_BROKEN

2021-06-14 Thread Patchwork
== 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

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/i915/query: Add test for L3 bank count

2021-06-14 Thread Matthew Brost
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 + >

[Intel-gfx] [PATCH 3/3] drm/i915/doc: Include GuC ABI documentation

2021-06-14 Thread Matthew Brost
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

[Intel-gfx] [PATCH 0/3] Update firmware to v62.0.0

2021-06-14 Thread Matthew Brost
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:

[Intel-gfx] [PATCH 2/3] drm/i915/guc: Update firmware to v62.0.0

2021-06-14 Thread Matthew Brost
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

[Intel-gfx] [PATCH 1/3] drm/i915/guc: Introduce unified HXG messages

2021-06-14 Thread Matthew Brost
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

Re: [Intel-gfx] [PATCH 02/10] driver core: Better distinguish probe errors in really_probe

2021-06-14 Thread Kirti Wankhede
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

Re: [Intel-gfx] [PATCH 08/13] drm/i915/guc: New CTB based communication

2021-06-14 Thread Daniele Ceraolo Spurio
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:

Re: [Intel-gfx] [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action

2021-06-14 Thread Daniele Ceraolo Spurio
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

Re: [Intel-gfx] [PATCH 06/13] drm/i915/guc: New definition of the CTB descriptor

2021-06-14 Thread Daniele Ceraolo Spurio
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) -

Re: [Intel-gfx] [PATCH 02/13] drm/i915/guc: Update MMIO based communication

2021-06-14 Thread Daniele Ceraolo Spurio
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.

Re: [Intel-gfx] [PATCH v3 10/12] drm/i915/ttm: accelerated move implementation

2021-06-14 Thread Thomas Hellström
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

[Intel-gfx] [PATCH v5 2/4] drm/i915/ttm: Adjust gem flags and caching settings after a move

2021-06-14 Thread Thomas Hellström
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

[Intel-gfx] [PATCH v5 1/4] drm/i915: Update object placement flags to be mutable

2021-06-14 Thread Thomas Hellström
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.

[Intel-gfx] [PATCH v5 3/4] drm/i915/ttm: Calculate the object placement at get_pages time

2021-06-14 Thread Thomas Hellström
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: -

[Intel-gfx] [PATCH v5 4/4] drm/i915/ttm: Use TTM for system memory

2021-06-14 Thread Thomas Hellström
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

[Intel-gfx] [PATCH v5 0/4] drm/i915: Move system memory to TTM for discrete

2021-06-14 Thread Thomas Hellström
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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Document the Virtual Engine uAPI (rev2)

2021-06-14 Thread Patchwork
== 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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move system memory to TTM for discrete (rev4)

2021-06-14 Thread Patchwork
== 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

Re: [Intel-gfx] [PATCH 01/13] drm/i915/guc: Introduce unified HXG messages

2021-06-14 Thread Daniele Ceraolo Spurio
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:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Move system memory to TTM for discrete (rev4)

2021-06-14 Thread Patchwork
== 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.

Re: [Intel-gfx] [PATCH v3 12/12] drm/i915/gem: Zap the i915_gem_object_blt code

2021-06-14 Thread Matthew Auld
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

Re: [Intel-gfx] [PATCH v3 11/12] drm/i915/gem: Zap the client blt code

2021-06-14 Thread Thomas Hellström
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

Re: [Intel-gfx] [PATCH] drm/i915/gen11: use ffs for minconfig slice/subslice

2021-06-14 Thread Matt Roper
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]

Re: [Intel-gfx] [PATCH v3 11/12] drm/i915/gem: Zap the client blt code

2021-06-14 Thread Matthew Auld
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,

Re: [Intel-gfx] [PATCH] drm/i915: Add relocation exceptions for two other platforms

2021-06-14 Thread Rodrigo Vivi
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

[Intel-gfx] [PATCH v3 07/12] drm/i915/gt: Pipelined page migration

2021-06-14 Thread Thomas Hellström
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

[Intel-gfx] [PATCH v3 09/12] drm/i915/gt: Setup a default migration context on the GT

2021-06-14 Thread Thomas Hellström
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: -

[Intel-gfx] [PATCH v3 12/12] drm/i915/gem: Zap the i915_gem_object_blt code

2021-06-14 Thread Thomas Hellström
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

[Intel-gfx] [PATCH v3 08/12] drm/i915/gt: Pipelined clear

2021-06-14 Thread Thomas Hellström
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

[Intel-gfx] [PATCH v3 10/12] drm/i915/ttm: accelerated move implementation

2021-06-14 Thread Thomas Hellström
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

[Intel-gfx] [PATCH v3 11/12] drm/i915/gem: Zap the client blt code

2021-06-14 Thread Thomas Hellström
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

[Intel-gfx] [PATCH v3 06/12] drm/i915/gt: Export the pinned context constructor and destructor

2021-06-14 Thread Thomas Hellström
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 +

[Intel-gfx] [PATCH v3 05/12] drm/i915/gt: Add a routine to iterate over the pagetables of a GTT

2021-06-14 Thread Thomas Hellström
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

[Intel-gfx] [PATCH v3 04/12] drm/i915/gt: Add an insert_entry for gen8_ppgtt

2021-06-14 Thread Thomas Hellström
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

[Intel-gfx] [PATCH v3 01/12] drm/i915: Reference objects on the ww object list

2021-06-14 Thread Thomas Hellström
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

[Intel-gfx] [PATCH v3 03/12] drm/i915: Introduce a ww transaction helper

2021-06-14 Thread Thomas Hellström
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

[Intel-gfx] [PATCH v3 02/12] drm/i915: Break out dma_resv ww locking utilities to separate files

2021-06-14 Thread Thomas Hellström
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) ---

[Intel-gfx] [PATCH v3 00/12] i915 TTM sync accelerated migration and clear

2021-06-14 Thread Thomas Hellström
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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: allow DG1 autoprobe for CONFIG_BROKEN

2021-06-14 Thread Patchwork
== 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 ---

Re: [Intel-gfx] [PATCH v2 2/7] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

2021-06-14 Thread Mario Kleiner
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

[Intel-gfx] [PATCH 10/10] vfio/mbochs: Convert to use vfio_register_group_dev()

2021-06-14 Thread 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:

[Intel-gfx] [PATCH 09/10] vfio/mdpy: Convert to use vfio_register_group_dev()

2021-06-14 Thread 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:

[Intel-gfx] [PATCH 08/10] vfio/mtty: Convert to use vfio_register_group_dev()

2021-06-14 Thread 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:

[Intel-gfx] [PATCH 06/10] vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE

2021-06-14 Thread Christoph Hellwig
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

[Intel-gfx] [PATCH 07/10] vfio/mdev: Allow the mdev_parent_ops to specify the device driver to bind

2021-06-14 Thread Christoph Hellwig
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

[Intel-gfx] [PATCH 05/10] driver core: Export device_driver_attach()

2021-06-14 Thread Christoph Hellwig
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

[Intel-gfx] [PATCH 04/10] driver core: Don't return EPROBE_DEFER to userspace during sysfs bind

2021-06-14 Thread Christoph Hellwig
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

[Intel-gfx] [PATCH 02/10] driver core: Better distinguish probe errors in really_probe

2021-06-14 Thread Christoph Hellwig
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:

[Intel-gfx] [PATCH 03/10] driver core: Flow the return code from ->probe() through to sysfs bind

2021-06-14 Thread Christoph Hellwig
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

[Intel-gfx] [PATCH 01/10] driver core: Pull required checks into driver_probe_device()

2021-06-14 Thread Christoph Hellwig
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

[Intel-gfx] Allow mdev drivers to directly create the vfio_device (v2 / alternative)

2021-06-14 Thread Christoph Hellwig
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,

Re: [Intel-gfx] [PATCH v4 2/4] drm/i915/ttm: Adjust gem flags and caching settings after a move

2021-06-14 Thread Thomas Hellström
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,

Re: [Intel-gfx] [PATCH 00/10] Allow mdev drivers to directly create the vfio_device

2021-06-14 Thread Kirti Wankhede
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

[Intel-gfx] [PATCH] drm/i915/ehl: Update MOCS table for EHL

2021-06-14 Thread Tejas Upadhyay
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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Document the Virtual Engine uAPI (rev2)

2021-06-14 Thread Patchwork
== 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 ---

Re: [Intel-gfx] [PATCH v4 2/4] drm/i915/ttm: Adjust gem flags and caching settings after a move

2021-06-14 Thread Matthew Auld
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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Document the Virtual Engine uAPI (rev2)

2021-06-14 Thread Patchwork
== 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

Re: [Intel-gfx] [PATCH 06/10] vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE

2021-06-14 Thread Jason Gunthorpe
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   2   >