[Intel-gfx] [PATCH v2] drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource

The code was making a copy of a struct ttm_resource. However, recently the struct ttm_resources were allowed to be subclassed and also were allowed to be malloced, hence the driver could end up assuming the copy we handed it was subclassed and worse, the original could have been freed at this point

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource (rev2)

== Series Details == Series: drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource (rev2) URL : https://patchwork.freedesktop.org/series/94154/ State : failure == Summary == Applying: drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource Using index info to recon

[Intel-gfx] [PATCH v10 0/4] drm: update locking for modesetting

Sorry for the noise, rebasing on top of drm-misc-next. Please ignore the v9 series. Hi, I updated the patch set with some suggestions by Daniel Vetter, and dropped the patches after patch 4 so that we can stick the landing for avoiding races with modesetting rights before dealing with the tricky

[Intel-gfx] [PATCH v10 1/4] drm: fix null ptr dereference in drm_master_release

drm_master_release can be called on a drm_file without a master, which results in a null ptr dereference of file_priv->master->magic_map. The three cases are: 1. Error path in drm_open_helper drm_open(): drm_open_helper(): drm_master_open(): drm_new_set_master(); <--- returns -

[Intel-gfx] [PATCH v10 2/4] drm: convert drm_device.master_mutex into a rwsem

drm_device.master_mutex currently protects the following: - drm_device.master - drm_file.master - drm_file.was_master - drm_file.is_master - drm_master.unique - drm_master.unique_len - drm_master.magic_map There is a clear separation between functions that read or change these attributes. Hence, c

[Intel-gfx] [PATCH v10 3/4] drm: lock drm_global_mutex earlier in the ioctl handler

In a future patch, a read lock on drm_device.master_rwsem is held in the ioctl handler before the check for ioctl permissions. However, this inverts the lock hierarchy of drm_global_mutex --> master_rwsem. To avoid this, we do some prep work to grab the drm_global_mutex before checking for ioctl p

[Intel-gfx] [PATCH v10 4/4] drm: avoid races with modesetting rights

In drm_client_modeset.c and drm_fb_helper.c, drm_master_internal_{acquire,release} are used to avoid races with DRM userspace. These functions hold onto drm_device.master_rwsem while committing, and bail if there's already a master. However, there are other places where modesetting rights can race

Re: [Intel-gfx] [PATCH 3/5] drm/edid: parse the DisplayID v2.0 VESA vendor block for MSO

On Mon, 30 Aug 2021, Ville Syrjälä wrote: > On Mon, Aug 30, 2021 at 01:29:01PM +0300, Jani Nikula wrote: >> The VESA Organization Vendor-Specific Data Block, defined in VESA >> DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO) >> stream count and segment pixel overlap. >> >> Di

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: update locking for modesetting (rev7)

== Series Details == Series: drm: update locking for modesetting (rev7) URL : https://patchwork.freedesktop.org/series/93864/ State : success == Summary == CI Bug Log - changes from CI_DRM_10538 -> Patchwork_20925 Summary --- **SUCCE

Re: [Intel-gfx] [PATCH v2] drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup

On 30/08/2021 09:26, Daniel Vetter wrote: On Fri, Aug 27, 2021 at 03:44:42PM +0100, Tvrtko Ursulin wrote: On 27/08/2021 15:39, Tvrtko Ursulin wrote: From: Tvrtko Ursulin In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa) when rendering is done on Intel dgfx and scanout

Re: [Intel-gfx] [PATCH 07/19] drm/i915: vma is always backed by an object.

On 30/08/2021 13:09, Maarten Lankhorst wrote: vma->obj and vma->resv are now never NULL, and some checks can be removed. Is the direction here compatible with SVM / VM_BIND? Regards, Tvrtko Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/intel_context.c | 2 +- ...

Re: [Intel-gfx] [PATCH 10/11] drm/i915: use xa_lock/unlock for fpriv->vm_xa lookups

Op 13-08-2021 om 22:30 schreef Daniel Vetter: > We don't need the absolute speed of rcu for this. And > i915_address_space in general dont need rcu protection anywhere else, > after we've made gem contexts and engines a lot more immutable. > > Note that this semantically reverts > > commit aabbe344

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/opregion: add support for mailbox #5 EDID

On Tue, 17 Aug 2021, Anisse Astier wrote: > The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be > used for the embedded display. Add support for using it via by adding > the EDID to the list of available modes on the connector, and use it for > eDP when available. > > If a panel'

Re: [Intel-gfx] [PATCH v3 0/2] GPD Win Max display fixes

On Tue, 17 Aug 2021, Anisse Astier wrote: > This patch series is for making the GPD Win Max display usable with > Linux. > > The GPD Win Max is a small laptop, and its eDP panel does not send an > EDID over DPCD; the EDID is instead available in the intel opregion, in > mailbox #5 [1] > > The firs

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: update locking for modesetting (rev7)

== Series Details == Series: drm: update locking for modesetting (rev7) URL : https://patchwork.freedesktop.org/series/93864/ State : success == Summary == CI Bug Log - changes from CI_DRM_10538_full -> Patchwork_20925_full Summary ---

Re: [Intel-gfx] [PATCH 07/19] drm/i915: vma is always backed by an object.

Op 31-08-2021 om 11:18 schreef Tvrtko Ursulin: > > On 30/08/2021 13:09, Maarten Lankhorst wrote: >> vma->obj and vma->resv are now never NULL, and some checks can be removed. > > Is the direction here compatible with SVM / VM_BIND? Yeah, it should be. The changes here make the obj->resv->lock th

Re: [Intel-gfx] [PATCH] drm/i915: Release i915_gem_context from a worker

Op 14-08-2021 om 12:43 schreef Daniel Vetter: > The only reason for this really is the i915_gem_engines->fence > callback engines_notify(), which exists purely as a fairly funky > reference counting scheme for that. Otherwise all other callers are > from process context, and generally fairly benign

Re: [Intel-gfx] [PATCH] drm/i915/gem: Fix the mman selftest

Op 26-08-2021 om 09:24 schreef Thomas Hellström: > Using the I915_MMAP_TYPE_FIXED mmap type requires the TTM backend, so > for that mmap type, use __i915_gem_object_create_user() instead of > i915_gem_object_create_internal(), as we really want to tests objects > mmap-able by user-space. > > This a

Re: [Intel-gfx] [PATCH v3 0/2] GPD Win Max display fixes

On Tue, Aug 31, 2021 at 11:33 AM Jani Nikula wrote: > > On Tue, 17 Aug 2021, Anisse Astier wrote: > > This patch series is for making the GPD Win Max display usable with > > Linux. > > > > The GPD Win Max is a small laptop, and its eDP panel does not send an > > EDID over DPCD; the EDID is instea

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with drm/i915: Release i915_gem_context from a worker (rev3)

== Series Details == Series: series starting with drm/i915: Release i915_gem_context from a worker (rev3) URL : https://patchwork.freedesktop.org/series/93693/ State : failure == Summary == Applying: drm/i915: Release i915_gem_context from a worker Applying: drm/i915: Release ctx->syncobj on

Re: [Intel-gfx] [PATCH 07/19] drm/i915: vma is always backed by an object.

On 31/08/2021 10:34, Maarten Lankhorst wrote: Op 31-08-2021 om 11:18 schreef Tvrtko Ursulin: On 30/08/2021 13:09, Maarten Lankhorst wrote: vma->obj and vma->resv are now never NULL, and some checks can be removed. Is the direction here compatible with SVM / VM_BIND? Yeah, it should be.

Re: [Intel-gfx] [PATCH] drm/i915/gem: Fix the mman selftest

On 8/31/21 11:45 AM, Maarten Lankhorst wrote: Op 26-08-2021 om 09:24 schreef Thomas Hellström: Using the I915_MMAP_TYPE_FIXED mmap type requires the TTM backend, so for that mmap type, use __i915_gem_object_create_user() instead of i915_gem_object_create_internal(), as we really want to tests

[Intel-gfx] [PATCH] drm/i915: use xa_lock/unlock for fpriv->vm_xa lookups

We don't need the absolute speed of rcu for this. And i915_address_space in general dont need rcu protection anywhere else, after we've made gem contexts and engines a lot more immutable. Note that this semantically reverts commit aabbe344dc3ca5f7d8263a02608ba6179e8a4499 Author: Chris Wilson Dat

Re: [Intel-gfx] [PATCH] drm/i915: Release i915_gem_context from a worker

On Tue, Aug 31, 2021 at 11:38:27AM +0200, Maarten Lankhorst wrote: > Op 14-08-2021 om 12:43 schreef Daniel Vetter: > > The only reason for this really is the i915_gem_engines->fence > > callback engines_notify(), which exists purely as a fairly funky > > reference counting scheme for that. Otherwis

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with drm/i915: Release i915_gem_context from a worker (rev4)

== Series Details == Series: series starting with drm/i915: Release i915_gem_context from a worker (rev4) URL : https://patchwork.freedesktop.org/series/93693/ State : failure == Summary == Applying: drm/i915: Release i915_gem_context from a worker Applying: drm/i915: Release ctx->syncobj on

Re: [Intel-gfx] [PATCH v8 7/7] drm: remove drm_file.master_lookup_lock

On Tue, Aug 31, 2021 at 02:02:39PM +0800, Desmond Cheong Zhi Xi wrote: > On 26/8/21 9:21 pm, Daniel Vetter wrote: > > On Thu, Aug 26, 2021 at 10:01:22AM +0800, Desmond Cheong Zhi Xi wrote: > > > Previously, master_lookup_lock was introduced in > > > commit 0b0860a3cf5e ("drm: serialize drm_file.mas

[Intel-gfx] [PATCH v2] drm/i915/gem: Fix the mman selftest

Using the I915_MMAP_TYPE_FIXED mmap type requires the TTM backend, so for that mmap type, use __i915_gem_object_create_user() instead of i915_gem_object_create_internal(), as we really want to tests objects mmap-able by user-space. This also means that the out-of-space error happens at object crea

Re: [Intel-gfx] [PATCH v2] drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup

On Tue, Aug 31, 2021 at 10:15:03AM +0100, Tvrtko Ursulin wrote: > > On 30/08/2021 09:26, Daniel Vetter wrote: > > On Fri, Aug 27, 2021 at 03:44:42PM +0100, Tvrtko Ursulin wrote: > > > > > > On 27/08/2021 15:39, Tvrtko Ursulin wrote: > > > > From: Tvrtko Ursulin > > > > > > > > In short this mak

Re: [Intel-gfx] [PATCH 8/8] drm/i915/perf: Map OA buffer to user space for gen12 performance query

On Mon, Aug 30, 2021 at 12:38:51PM -0700, Umesh Nerlige Ramappa wrote: > i915 used to support time based sampling mode which is good for overall > system monitoring, but is not enough for query mode used to measure a > single draw call or dispatch. Gen9-Gen11 are using current i915 perf > implement

Re: [Intel-gfx] [PATCH v2] drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup

On 31/08/2021 13:43, Daniel Vetter wrote: On Tue, Aug 31, 2021 at 10:15:03AM +0100, Tvrtko Ursulin wrote: On 30/08/2021 09:26, Daniel Vetter wrote: On Fri, Aug 27, 2021 at 03:44:42PM +0100, Tvrtko Ursulin wrote: On 27/08/2021 15:39, Tvrtko Ursulin wrote: From: Tvrtko Ursulin In short th

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: Fix the mman selftest (rev2)

== Series Details == Series: drm/i915/gem: Fix the mman selftest (rev2) URL : https://patchwork.freedesktop.org/series/94062/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10539 -> Patchwork_20928 Summary --- **FAILU

[Intel-gfx] [PATCH 1/2] drm/i915/debugfs: Do not report currently active engine when describing objects

From: Tvrtko Ursulin It is not very useful to have code which tries to report a rapidly transient state which will not report anything majority of the time, especially since it is currently only used from /i915_gem_framebuffers. Signed-off-by: Tvrtko Ursulin Cc: Daniel Vetter --- drivers/gpu/

[Intel-gfx] [PATCH 2/2] drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup

From: Tvrtko Ursulin In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa) when rendering is done on Intel dgfx and scanout/composition on Intel igfx. Before this patch the driver was not quite ready for that setup, mainly because it was able to emit a semaphore wait between th

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: Fix the mman selftest (rev2)

On 8/31/21 3:19 PM, Patchwork wrote: Project List - Patchwork *Patch Details* *Series:* drm/i915/gem: Fix the mman selftest (rev2) *URL:* https://patchwork.freedesktop.org/series/94062/ *State:*failure *Details:* https://intel-g

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/debugfs: Do not report currently active engine when describing objects

== Series Details == Series: series starting with [1/2] drm/i915/debugfs: Do not report currently active engine when describing objects URL : https://patchwork.freedesktop.org/series/94202/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used,

[Intel-gfx] [PATCH v2 0/6] drm/displayid: VESA vendor block and drm/i915 MSO use of it

v2 of https://patchwork.freedesktop.org/series/94161/ with the VESA OUI check and an OUI helper patch added. Jani Nikula (6): drm/displayid: re-align data block macros drm/displayid: add DisplayID v2.0 data blocks and primary use cases drm/edid: abstract OUI conversion to 24-bit int drm/ed

[Intel-gfx] [PATCH v2 1/6] drm/displayid: re-align data block macros

Make the values easier to read. Also add DisplayID Structure version and revision information (this is different from the spec version). Signed-off-by: Jani Nikula --- include/drm/drm_displayid.h | 57 +++-- 1 file changed, 29 insertions(+), 28 deletions(-) diff

[Intel-gfx] [PATCH v2 2/6] drm/displayid: add DisplayID v2.0 data blocks and primary use cases

DisplayID v2.0 changes the data block identifiers and product types (now called primary use cases). Signed-off-by: Jani Nikula --- include/drm/drm_displayid.h | 29 + 1 file changed, 29 insertions(+) diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayi

[Intel-gfx] [PATCH v2 3/6] drm/edid: abstract OUI conversion to 24-bit int

Replace the open coded OUI conversion from three bytes to a 24-bit int, as we'll be adding one more user shortly. No functional changes. Side note: CTA-861 format has the OUI bytes in reverse order. Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_edid.c | 17 +++-- 1 file changed

[Intel-gfx] [PATCH v2 4/6] drm/edid: parse the DisplayID v2.0 VESA vendor block for MSO

The VESA Organization Vendor-Specific Data Block, defined in VESA DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO) stream count and segment pixel overlap. DisplayID v1.3 has Appendix B: DisplayID as an EDID Extension, describing how DisplayID sections may be embedded in EDID ex

[Intel-gfx] [PATCH v2 5/6] drm/i915/edp: postpone MSO init until after EDID read

MSO will require segment pixel overlap information from the EDID. Postpone MSO init until after we've read and cached the EDID. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_dp.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/dis

[Intel-gfx] [PATCH v2 6/6] drm/i915/edp: use MSO pixel overlap from DisplayID data

Now that we have MSO pixel overlap in display info, use it. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_dp.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index

Re: [Intel-gfx] [PATCH 3/5] drm/edid: parse the DisplayID v2.0 VESA vendor block for MSO

On Tue, 31 Aug 2021, Jani Nikula wrote: > On Mon, 30 Aug 2021, Ville Syrjälä wrote: >> Don't we need to check the OUI to make sure the block is the right >> type? I don't have the v2 spec at hand atm, but I presume a vendor >> specific block could contain all kinds of different things? > > You're

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/debugfs: Do not report currently active engine when describing objects

== Series Details == Series: series starting with [1/2] drm/i915/debugfs: Do not report currently active engine when describing objects URL : https://patchwork.freedesktop.org/series/94202/ State : success == Summary == CI Bug Log - changes from CI_DRM_10539 -> Patchwork_20929 ===

Re: [Intel-gfx] [PATCH] drm/i915: Release i915_gem_context from a worker

On Tue, Aug 31, 2021 at 02:16:56PM +0200, Daniel Vetter wrote: > On Tue, Aug 31, 2021 at 11:38:27AM +0200, Maarten Lankhorst wrote: > > Op 14-08-2021 om 12:43 schreef Daniel Vetter: > > > The only reason for this really is the i915_gem_engines->fence > > > callback engines_notify(), which exists pu

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/displayid: VESA vendor block and drm/i915 MSO use of it (rev2)

== Series Details == Series: drm/displayid: VESA vendor block and drm/i915 MSO use of it (rev2) URL : https://patchwork.freedesktop.org/series/94161/ 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 drm/i915/gem: Fix the mman selftest (rev2)

== Series Details == Series: drm/i915/gem: Fix the mman selftest (rev2) URL : https://patchwork.freedesktop.org/series/94062/ State : success == Summary == CI Bug Log - changes from CI_DRM_10539 -> Patchwork_20928 Summary --- **SUCCE

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/debugfs: Do not report currently active engine when describing objects

== Series Details == Series: series starting with [1/2] drm/i915/debugfs: Do not report currently active engine when describing objects URL : https://patchwork.freedesktop.org/series/94202/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10539_full -> Patchwork_20929_full =

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/displayid: VESA vendor block and drm/i915 MSO use of it (rev2)

== Series Details == Series: drm/displayid: VESA vendor block and drm/i915 MSO use of it (rev2) URL : https://patchwork.freedesktop.org/series/94161/ State : success == Summary == CI Bug Log - changes from CI_DRM_10540 -> Patchwork_20930 Su

Re: [Intel-gfx] [PATCH 5/5] drm/i915/debugfs: pass intel_connector to intel_connector_debugfs_add()

Hi Jani, I love your patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on drm-tip/drm-tip next-20210831] [cannot apply to v5.14] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: Fix the mman selftest (rev2)

Re-reported. From: Thomas Hellström Sent: Tuesday, August 31, 2021 6:29 AM To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana Subject: Re: ✗ Fi.CI.BAT: failure for drm/i915/gem: Fix the mman selftest (rev2) On 8/31/21 3:19 PM, Patchwork wrote: Patch Details Series: drm/i915/gem: Fi

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/debugfs: Do not report currently active engine when describing objects

On 31/08/2021 16:43, Patchwork wrote: *Patch Details* *Series:* series starting with [1/2] drm/i915/debugfs: Do not report currently active engine when describing objects *URL:* https://patchwork.freedesktop.org/series/94202/ *State:*

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: Fix the mman selftest (rev2)

== Series Details == Series: drm/i915/gem: Fix the mman selftest (rev2) URL : https://patchwork.freedesktop.org/series/94062/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10539_full -> Patchwork_20928_full Summary ---

Re: [Intel-gfx] [PATCH 26/27] drm/i915/guc: Add GuC kernel doc

On 8/25/2021 20:23, Matthew Brost wrote: Add GuC kernel doc for all structures added thus far for GuC submission and update the main GuC submission section with the new interface details. v2: - Drop guc_active.lock DOC v3: (Daniele) - Fixup a few kernel doc comments Signed-off-by: Matthew

Re: [Intel-gfx] [PATCH 27/27] drm/i915/guc: Drop static inline functions intel_guc_submission.c

Subject should be 'drop .. functions *from* intel...'. On 8/25/2021 20:23, Matthew Brost wrote: s/static inline/static/g + fix function argument alignment to make checkpatch happy. Why? Signed-off-by: Matthew Brost --- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 116 +

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/displayid: VESA vendor block and drm/i915 MSO use of it (rev2)

== Series Details == Series: drm/displayid: VESA vendor block and drm/i915 MSO use of it (rev2) URL : https://patchwork.freedesktop.org/series/94161/ State : success == Summary == CI Bug Log - changes from CI_DRM_10540_full -> Patchwork_20930_full ==

[Intel-gfx] [PATCH v7 0/8] use DYNAMIC_DEBUG to implement DRM.debug

Hi Jason, DRM folks, In DRM-debug currently, drm_debug_enabled() is called a lot to decide whether or not to write debug messages. Each test is cheap, but costs continue with uptime. DYNAMIC_DEBUG "dyndbg", when built with JUMP_LABEL, replaces each of those tests with a patchable NOOP, for "zero

[Intel-gfx] [PATCH v7 1/8] dyndbg: add DEFINE_DYNAMIC_DEBUG_CATEGORIES and callbacks

DEFINE_DYNAMIC_DEBUG_CATEGORIES(name, var, bitmap_desc, @bit_descs) allows users to define a drm.debug style (bitmap) sysfs interface, and to specify the desired mapping from bits[0-N] to the format-prefix'd pr_debug()s to be controlled. DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,

[Intel-gfx] [PATCH v7 2/8] dyndbg: remove spaces in pr_debug "gvt: core:" etc prefixes

Taking embedded spaces out of existing prefixes makes them better class-prefixes; simplifying the extra quoting needed otherwise: $> echo format "^gvt: core:" +p >control Dropping the internal spaces means any trailing space in a query will more clearly terminate the prefix being searched for.

[Intel-gfx] [PATCH v7 3/8] i915/gvt: use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create "gvt:core:" etc categories

The gvt component of this driver has ~120 pr_debugs, in 9 categories quite similar to those in DRM. Following the interface model of drm.debug, add a parameter to map bits to these categorizations. DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug, "dyndbg bitmap desc", { "gv

[Intel-gfx] [PATCH v7 4/8] amdgpu: use DEFINE_DYNAMIC_DEBUG_CATEGORIES

logger_types.h defines many DC_LOG_*() categorized debug wrappers. Most of these use DRM debug API, so are controllable using drm.debug, but others use bare pr_debug("$prefix: .."), each with a different class-prefix matching "^\[\w+\]:" Use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create a /sys debug_d

[Intel-gfx] [PATCH v7 5/8] drm_print: add choice to use dynamic debug in drm-debug

drm's debug system writes 10 distinct categories of messages to syslog using a small API[1]: drm_dbg*(10 names), DRM_DEV_DEBUG*(3 names), DRM_DEBUG*(8 names). There are thousands of these callsites, each categorized in this systematized way. These callsites can be enabled at runtime by their cate

[Intel-gfx] [PATCH v7 6/8] drm_print: instrument drm_debug_enabled

Duplicate drm_debug_enabled() code into both "basic" and "dyndbg" ifdef branches. Then add a pr_debug("todo: ...") into the "dyndbg" branch. Then convert the "dyndbg" branch's code to a macro, so that its pr_debug() get its callsite info from the invoking function, instead of from drm_debug_enabl

[Intel-gfx] [PATCH v7 8/8] nouveau: fold multiple DRM_DEBUG_DRIVERs together

With DRM_USE_DYNAMIC_DEBUG, each callsite record requires 56 bytes. We can combine 12 into one here and save ~620 bytes. Signed-off-by: Jim Cromie --- drivers/gpu/drm/nouveau/nouveau_drm.c | 36 +-- 1 file changed, 23 insertions(+), 13 deletions(-) diff --git a/drivers/g

[Intel-gfx] [PATCH v7 7/8] amdgpu_ucode: reduce number of pr_debug calls

There are blocks of DRM_DEBUG calls, consolidate their args into single calls. With dynamic-debug in use, each callsite consumes 56 bytes of callsite data, and this patch removes about 65 calls, so it saves ~3.5kb. no functional changes. RFC: this creates multi-line log messages, does that break

Re: [Intel-gfx] [PATCH 8/8] drm/i915/perf: Map OA buffer to user space for gen12 performance query

On Tue, Aug 31, 2021 at 02:55:37PM +0200, Daniel Vetter wrote: On Mon, Aug 30, 2021 at 12:38:51PM -0700, Umesh Nerlige Ramappa wrote: i915 used to support time based sampling mode which is good for overall system monitoring, but is not enough for query mode used to measure a single draw call or

Re: [Intel-gfx] [PATCH v7 05/17] drm/i915/pxp: Implement funcs to create the TEE channel

On Fri, Aug 27, 2021 at 06:27:26PM -0700, Daniele Ceraolo Spurio wrote: > From: "Huang, Sean Z" > > Implement the funcs to create the TEE channel, so kernel can > send the TEE commands directly to TEE for creating the arbitrary > (default) session. > > v2: fix locking, don't pollute dev_priv (Ch

Re: [Intel-gfx] [PATCH v7 05/17] drm/i915/pxp: Implement funcs to create the TEE channel

On 8/31/2021 2:08 PM, Rodrigo Vivi wrote: On Fri, Aug 27, 2021 at 06:27:26PM -0700, Daniele Ceraolo Spurio wrote: From: "Huang, Sean Z" Implement the funcs to create the TEE channel, so kernel can send the TEE commands directly to TEE for creating the arbitrary (default) session. v2: fix l

Re: [Intel-gfx] [PATCH v7 10/17] drm/i915/pxp: interfaces for using protected objects

On Fri, Aug 27, 2021 at 06:27:31PM -0700, Daniele Ceraolo Spurio wrote: > This api allow user mode to create protected buffers and to mark > contexts as making use of such objects. Only when using contexts > marked in such a way is the execution guaranteed to work as expected. > > Contexts can onl

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for use DYNAMIC_DEBUG to implement DRM.debug (rev2)

== Series Details == Series: use DYNAMIC_DEBUG to implement DRM.debug (rev2) URL : https://patchwork.freedesktop.org/series/93914/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7bd3d881384d dyndbg: add DEFINE_DYNAMIC_DEBUG_CATEGORIES and callbacks -:210: CHECK:MACRO_ARG_REUSE:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for use DYNAMIC_DEBUG to implement DRM.debug (rev2)

== Series Details == Series: use DYNAMIC_DEBUG to implement DRM.debug (rev2) URL : https://patchwork.freedesktop.org/series/93914/ 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/d

[Intel-gfx] ✓ Fi.CI.BAT: success for use DYNAMIC_DEBUG to implement DRM.debug (rev2)

== Series Details == Series: use DYNAMIC_DEBUG to implement DRM.debug (rev2) URL : https://patchwork.freedesktop.org/series/93914/ State : success == Summary == CI Bug Log - changes from CI_DRM_10541 -> Patchwork_20931 Summary --- **

Re: [Intel-gfx] [PATCH v7 10/17] drm/i915/pxp: interfaces for using protected objects

+} + +void intel_pxp_invalidate(struct intel_pxp *pxp) +{ + struct drm_i915_private *i915 = pxp_to_gt(pxp)->i915; + struct i915_gem_context *ctx, *cn; + + /* ban all contexts marked as protected */ + spin_lock_irq(&i915->gem.contexts.lock); + list_for_each_entry_sa

[Intel-gfx] ✗ Fi.CI.IGT: failure for use DYNAMIC_DEBUG to implement DRM.debug (rev2)

== Series Details == Series: use DYNAMIC_DEBUG to implement DRM.debug (rev2) URL : https://patchwork.freedesktop.org/series/93914/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10541_full -> Patchwork_20931_full Summary ---

[Intel-gfx] [PATCH 6/7] Me: Workaround LMEM blow up

From: Matthew Brost --- drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index b9f66dbd46bb..a61e23deeb00 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++

[Intel-gfx] [PATCH 7/7] Me: Dump GuC log to dmesg on SLPC load failure

From: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 3 + drivers/gpu/drm/i915/i915_gpu_error.c | 97 + drivers/gpu/drm/i915/i915_gpu_error.h | 3 + 3 files changed, 103 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c b/

[Intel-gfx] [PATCH 1/7] drm/i915: Do not define vma on stack

From: Venkata Sandeep Dhanalakota Defining vma on stack can cause stack overflow, if vma gets populated with new fields. Cc: Daniele Ceraolo Spurio Cc: Tvrtko Ursulin Signed-off-by: Venkata Sandeep Dhanalakota Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 18 ++

[Intel-gfx] [PATCH 2/7] drm/i915/guc: put all guc objects in lmem when available

From: Daniele Ceraolo Spurio The firmware binary has to be loaded from lmem and the recommendation is to put all other objects in there as well. Note that we don't fall back to system memory if the allocation in lmem fails because all objects are allocated during driver load and if we have issues

[Intel-gfx] [PATCH 5/7] Me: Allow relocs on DG1 for CI

From: Matthew Brost --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 8290bdadd167..a530a65e6f2a 100644 --- a/drivers/gpu/dr

[Intel-gfx] [PATCH 3/7] drm/i915/guc: Add DG1 GuC / HuC firmware defs

From: Matthew Brost Add DG1 GuC / HuC firmware defs Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index f8cb00ffb506..a685d563df7

[Intel-gfx] [PATCH 0/7] [CI] Enable GuC submission by default on DG1

From: John Harrison Minimum set of patches to enable GuC submission on DG1 and enable it by default. A little difficult to test as IGTs do not work with DG1 due to a bunch of uAPI features being disabled (e.g. relocations, caching memory options, etc...). Hence extra patches at the end to enable

[Intel-gfx] [PATCH 4/7] drm/i915/guc: Enable GuC submission by default on DG1

From: Matthew Brost Enable GuC submission by default on DG1 Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c b/drivers/gpu/drm/i915/gt/uc/intel_uc.c index b104fb7607

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable GuC submission by default on DG1 (rev2)

== Series Details == Series: Enable GuC submission by default on DG1 (rev2) URL : https://patchwork.freedesktop.org/series/93325/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6980dea021fa drm/i915: Do not define vma on stack 8e2a5b71ad3f drm/i915/guc: put all guc objects in lm

[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable GuC submission by default on DG1 (rev2)

== Series Details == Series: Enable GuC submission by default on DG1 (rev2) URL : https://patchwork.freedesktop.org/series/93325/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10541 -> Patchwork_20932 Summary --- **F