[Intel-gfx] [PATCH v4 0/4] drm: Introduce struct drm_device based WARN* and use them in i915

Device specific dev_WARN and dev_WARN_ONCE macros available in kernel include device information in the backtrace, so we know what device the warnings originate from. Similar to this, add new struct drm_device based drm_WARN* macros. These macros include device information in the backtrace, so we

[Intel-gfx] [PATCH v4 1/4] drm/i915/display: Make WARN* drm specific where drm_device ptr is available

Drm specific drm_WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_device struct pointer is readily available. The conversion was done automatica

[Intel-gfx] [PATCH v4 4/4] drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available

Drm specific drm_WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_device struct pointer is readily available. The conversion was done automatica

[Intel-gfx] [PATCH v4 2/4] drm/i915/display: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done automati

[Intel-gfx] [PATCH v4 3/4] drm/i915/gvt: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done automati

Re: [Intel-gfx] [PATCH v3 0/4] drm: Introduce struct drm_device based WARN* and use them in i915

On Sat, Jan 25, 2020 at 04:51:08PM +0200, Jani Nikula wrote: > On Thu, 23 Jan 2020, Pankaj Bharadiya > wrote: > > changes since v2: > > - rebase pending unmerged patches on drm-tip > > Alas, these conflict already... please rebase. :/ Ahh :( ... Looks like other changes are merged before you

Re: [Intel-gfx] [ [PATCH v2 00/10] drm: Introduce struct drm_device based WARN* and use them in i915

On Thu, Jan 23, 2020 at 11:39:37AM +0200, Jani Nikula wrote: > On Thu, 23 Jan 2020, "Bharadiya,Pankaj" > wrote: > > Will rebase remaining patches and submit. > > Please also add a patch to convert MISSING_CASE(), Will do. > and another to remove > the WARN_ON/WARN_ON_ONCE "overrides" that we h

[Intel-gfx] [PATCH i-g-t] i915/gem_pipe_control_store_loop: Limit runtime

Use a runtime limit, not a fixed amount of work, so that it doesn't take several hundred seconds on the slower machines. Signed-off-by: Chris Wilson --- tests/i915/gem_pipe_control_store_loop.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tests/i915/gem_pipe_contro

Re: [Intel-gfx] [PATCH v4 7/9] parisc/perf: open access for CAP_SYS_PERFMON privileged process

On 18.12.19 10:29, Alexey Budankov wrote: > > Open access to monitoring for CAP_SYS_PERFMON privileged processes. > For backward compatibility reasons access to the monitoring remains open > for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure > monitoring is discouraged with r

Re: [Intel-gfx] [ [PATCH v2 00/10] drm: Introduce struct drm_device based WARN* and use them in i915

On Mon, 27 Jan 2020, "Bharadiya,Pankaj" wrote: > On Thu, Jan 23, 2020 at 11:39:37AM +0200, Jani Nikula wrote: >> On Thu, 23 Jan 2020, "Bharadiya,Pankaj" >> wrote: >> > Will rebase remaining patches and submit. >> >> Please also add a patch to convert MISSING_CASE(), > > Will do. > >> and anoth

Re: [Intel-gfx] [PATCH 0/2] drm/i915/gem: conversion to new drm logging macros

On Sat, Jan 25, 2020 at 04:08:39PM +, Chris Wilson wrote: > Quoting Wambui Karuga (2020-01-22 12:57:48) > > This series is a part of the conversion to the new struct drm_device > > based logging macros in drm/i915. > > This series focuses on the drm/i915/gem directory and converts all > > stra

[Intel-gfx] [PATCH i-g-t 2/4] i915/gem_exec_nop: Reduce runtime

Reduce the upper timeout for stress tests from 150s to a mere 20s, and quick tests to 2s. Signed-off-by: Chris Wilson --- tests/i915/gem_exec_nop.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/tests/i915/gem_exec_nop.c b/tests/i915/gem_exec_nop.c i

[Intel-gfx] [PATCH i-g-t 1/4] i915/gem_sync: Reduce runtime

Reduce the upper timeout for stress tests from 150s to a mere 20s, and quick tests to 2s. Signed-off-by: Chris Wilson --- tests/i915/gem_sync.c | 60 +-- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/tests/i915/gem_sync.c b/tests/i915/gem

[Intel-gfx] [PATCH i-g-t 3/4] i915/gem_ctx_create: Reduce runtime

Reduce the upper timeout for stress tests from 150s to a mere 20s, and quick tests to 2s. Signed-off-by: Chris Wilson --- tests/i915/gem_ctx_create.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tests/i915/gem_ctx_create.c b/tests/i915/gem_ctx_create.c index 83d

[Intel-gfx] [PATCH i-g-t 4/4] i915/gem_ctx_switch: Reduce runtime

Reduce the upper timeout for stress tests from 150s to a mere 20s, and quick tests to 2s. Signed-off-by: Chris Wilson --- tests/i915/gem_ctx_switch.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/tests/i915/gem_ctx_switch.c b/tests/i915/gem_ctx_sw

Re: [Intel-gfx] [PATCH 0/2] drm/i915/gem: conversion to new drm logging macros

Quoting Daniel Vetter (2020-01-27 09:05:57) > On Sat, Jan 25, 2020 at 04:08:39PM +, Chris Wilson wrote: > > Quoting Wambui Karuga (2020-01-22 12:57:48) > > > This series is a part of the conversion to the new struct drm_device > > > based logging macros in drm/i915. > > > This series focuses o

Re: [Intel-gfx] [PATCH 0/2] drm/i915/gem: conversion to new drm logging macros

On Mon, Jan 27, 2020 at 09:08:01AM +, Chris Wilson wrote: > Quoting Daniel Vetter (2020-01-27 09:05:57) > > On Sat, Jan 25, 2020 at 04:08:39PM +, Chris Wilson wrote: > > > Quoting Wambui Karuga (2020-01-22 12:57:48) > > > > This series is a part of the conversion to the new struct drm_devi

Re: [Intel-gfx] [PATCH] drm: Avoid drm_global_mutex for simple inc/dec of dev->open_count

On Fri, Jan 24, 2020 at 06:39:26PM +, Chris Wilson wrote: > Quoting Thomas Hellström (VMware) (2020-01-24 13:37:47) > > On 1/24/20 2:01 PM, Chris Wilson wrote: > > > Since drm_global_mutex is a true global mutex across devices, we don't > > > want to acquire it unless absolutely necessary. For

Re: [Intel-gfx] [PATCH] drm/i915/perf: Fix OA context id overlap with idle context id

On 27/01/2020 07:30, Umesh Nerlige Ramappa wrote: On Sat, Jan 25, 2020 at 03:37:38AM +0200, Lionel Landwerlin wrote: On 24/01/2020 03:37, Umesh Nerlige Ramappa wrote: Engine context pinned in perf OA was set to same context id as the idle context. Set the context id to an unused value. Clear t

Re: [Intel-gfx] [PATCH RESEND 6/6] drm/i915/pm: use intel de functions for forcewake register access

On Thu, 23 Jan 2020, Chris Wilson wrote: > Quoting Ville Syrjälä (2020-01-23 14:16:46) >> On Thu, Jan 23, 2020 at 04:00:04PM +0200, Jani Nikula wrote: >> > Move away from I915_READ_FW() and I915_WRITE_FW() in display code, and >> > switch to using intel_de_read_fw() and intel_de_write_fw(), >> > r

Re: [Intel-gfx] [PATCH 1/2] drm: Release filp before global lock

On Fri, Jan 24, 2020 at 12:56:26PM +, Chris Wilson wrote: > The file is not part of the global drm resource and can be released > prior to take the global mutex to drop the open_count (and potentially > close) the drm device. As the global mutex is indeed global, not only > within the device bu

Re: [Intel-gfx] [PATCH 0/2] drm/i915/gem: conversion to new drm logging macros

On Sat, 25 Jan 2020, Chris Wilson wrote: > Quoting Wambui Karuga (2020-01-22 12:57:48) >> This series is a part of the conversion to the new struct drm_device >> based logging macros in drm/i915. >> This series focuses on the drm/i915/gem directory and converts all >> straightforward instances of

[Intel-gfx] [CI i-g-t 2/2] tests/i915/gem_exec_parallel:Set engine map to default context

From: Sreedhar Telukuntla Set the potential engine map of the parent client's default context to the newly created DRM client's default context. Without doing so there is a mismatch between the intended and actual engine used by the *-fds subtests. v2: Fix FDS flags check Tvrtko: v3: Use new he

[Intel-gfx] [CI i-g-t 1/2] lib/i915: Add helper for copying engine maps from one context to another

From: Tvrtko Ursulin We also need to support copying across file descriptors. v2: * Copy over even if src is unset. (Chris) Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson Cc: Sreedhar Telukuntla Reviewed-by: Chris Wilson --- lib/i915/gem_context.c | 30 ++ lib/

Re: [Intel-gfx] [PATCH i-g-t] i915_pm_rps: Be wary if RP0 == RPn

Chris Wilson writes: > If the HW min/max frequencies are the same, there is not much range to > deal with and a couple of our invalid tests become confused as they are > actually no-ops. > > Error reporting in i915_pm_rps is rudimentary and we deserve better. > > Closes: https://gitlab.freedeskto

Re: [Intel-gfx] [PATCH] drm/i915/vbt: Fix the timing parameters

On Fri, 24 Jan 2020, Jani Nikula wrote: > On Fri, 24 Jan 2020, Vandita Kulkarni wrote: >> Fix htotal and vtotal parameters derived from >> DTD block of VBT. >> >> Fixes: 33ef6d4fd8df ("drm/i915/vbt: Handle generic DTD block") >> Signed-off-by: Vandita Kulkarni > > Reviewed-by: Jani Nikula And

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_pipe_control_store_loop: Limit runtime

Chris Wilson writes: > Use a runtime limit, not a fixed amount of work, so that it doesn't take > several hundred seconds on the slower machines. > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala > --- > tests/i915/gem_pipe_control_store_loop.c | 8 > 1 file changed, 4 inse

Re: [Intel-gfx] [PATCH i-g-t] i915_pm_rps: Be wary if RP0 == RPn

Quoting Mika Kuoppala (2020-01-27 09:54:25) > Chris Wilson writes: > > > If the HW min/max frequencies are the same, there is not much range to > > deal with and a couple of our invalid tests become confused as they are > > actually no-ops. > > > > Error reporting in i915_pm_rps is rudimentary an

[Intel-gfx] [PATCH] drm/auth: Drop master_create/destroy hooks

vmwgfx stopped using them. With the drm device model that we've slowly evolved over the past few years master status essentially controls access to display resources, and nothing else. Since that's a pure access permission check drivers should have no need at all to track additional state on a per

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/4] i915/gem_sync: Reduce runtime

Chris Wilson writes: > Reduce the upper timeout for stress tests from 150s to a mere 20s, and > quick tests to 2s. > > Signed-off-by: Chris Wilson This and the rest of the series, Reviewed-by: Mika Kuoppala > --- > tests/i915/gem_sync.c | 60 +-- > 1

[Intel-gfx] [PATCH i-g-t v2] i915_pm_rps: Be wary if RP0 == RPn

If the HW min/max frequencies are the same, there is not much range to deal with and a couple of our invalid tests become confused as they are actually no-ops. Error reporting in i915_pm_rps is rudimentary and we deserve better. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1008 Signed-

Re: [Intel-gfx] [PATCH] drm/i915: Remove 'prefault_disable' modparam

On Fri, 24 Jan 2020, Chris Wilson wrote: > The 'prefault_disable' modparam was used by IGT to prevent a few > prefaulting operations to make fault handling under struct_mutex more > prominent. With the removal of struct_mutex, this is not as important > any more and we have almost completely stopp

Re: [Intel-gfx] [PATCH] drm/i915/display: Squelch kerneldoc complaints

On Sun, 26 Jan 2020, Chris Wilson wrote: > drivers/gpu/drm/i915/display/intel_atomic.c:185: warning: Function parameter > or member 'state' not described in 'intel_connector_needs_modeset' > drivers/gpu/drm/i915/display/intel_atomic.c:185: warning: Function parameter > or member 'connector' not

[Intel-gfx] [PATCH] drm/i915/gt: Lift set-wedged engine dumping out of user paths

The user (e.g. gem_eio) can manipulate the driver into wedging itself, allowing the user to trigger voluminous logging of inconsequential details. If we lift the dump to direct calls to intel_gt_set_wedged(), out of the intel_reset failure handling, we keep the detail logging for what we expect are

Re: [Intel-gfx] [PATCH] drm/i915: Stub out i915_gpu_coredump_put

Hi Chris, On Fri, Jan 24, 2020 at 07:22:55PM +, Chris Wilson wrote: > i915_gpu_coreddump_put is currently only defined if > CONFIG_DRM_I915_CAPTURE_ERROR is enabled, provide a stub otherwise. > > Reported-by: Mike Lothian > Fixes: 742379c0c400 ("drm/i915: Start chopping up the GPU error capt

[Intel-gfx] [PATCH] drm/i915: Add missing HDMI audio pixel clocks for gen12

Gen12 hardware supports HDMI audio pixel clocks of 296.7/297Mhz and 593.4/594Mhz. Add the missing rates and add logic to ignore them if running on older hardware. Bspec: 49333 Signed-off-by: Kai Vehmanen --- drivers/gpu/drm/i915/display/intel_audio.c | 16 +--- drivers/gpu/drm/i915/i

[Intel-gfx] [PATCH] drm/i915/dsi: Enable dsi as part of encoder->enable

Enable the dsi transcoder, panel and backlight as part of encoder->enable and not encoder->pre_enable. Signed-off-by: Vandita Kulkarni --- drivers/gpu/drm/i915/display/icl_dsi.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c

Re: [Intel-gfx] [PATCH] drm/auth: Drop master_create/destroy hooks

Am 27.01.20 um 11:02 schrieb Daniel Vetter: > vmwgfx stopped using them. > > With the drm device model that we've slowly evolved over the past few > years master status essentially controls access to display resources, > and nothing else. Since that's a pure access permission check drivers > sho

Re: [Intel-gfx] [PATCH] drm/i915/dsi: Enable dsi as part of encoder->enable

On Mon, 27 Jan 2020, Vandita Kulkarni wrote: > Enable the dsi transcoder, panel and backlight as part > of encoder->enable and not encoder->pre_enable. That's the *what*, and we can see that much from the patch. But we need to know *why*, and why you think it was done like this before, and why i

Re: [Intel-gfx] [PATCH] drm/auth: Drop master_create/destroy hooks

On 1/27/20 11:02 AM, Daniel Vetter wrote: vmwgfx stopped using them. With the drm device model that we've slowly evolved over the past few years master status essentially controls access to display resources, and nothing else. Since that's a pure access permission check drivers should have no ne

[Intel-gfx] [PATCH i-g-t 3/5] i915: Exercise preemption timeout controls in sysfs

We [will] expose various per-engine scheduling controls. One of which, 'preempt_timeout_ms', defines how we wait for a preemption request to be honoured by the currently executing context. If it fails to relieve the GPU within the required timeout, the engine is reset and the miscreant forcibly evi

[Intel-gfx] [PATCH i-g-t 5/5] i915: Exercise timeslice sysfs property

We [will] expose various per-engine scheduling controls. One of which, 'timeslice_duration_ms', defines the scheduling quantum. If a context exhausts its timeslice, it will be preempted in favour of running one of its compatriots. Signed-off-by: Chris Wilson --- tests/Makefile.sources

[Intel-gfx] [PATCH i-g-t 4/5] i915: Exercise sysfs heartbeat controls

We [will] expose various per-engine scheduling controls. One of which, 'heartbeat_duration_ms', defines how often we send a heartbeat down the engine to check upon the health of the engine. If a heartbeat does not complete within the interval (or two), the engine is declared hung. Signed-off-by: C

[Intel-gfx] [PATCH i-g-t 1/5] i915: Start putting the mmio_base to wider use

Several tests depend upon the implicit engine->mmio_base but have no means of determining the physical layout. Since the kernel has started providing this information, start putting it to use. Signed-off-by: Chris Wilson --- lib/i915/gem_engine_topology.c | 84 ++

[Intel-gfx] [PATCH i-g-t 2/5] i915/gem_ctx_isolation: Check engine relative registers

Some of the non-privileged registers are at the same offset on each engine. We can improve our coverage for unknown HW layout by using the reported engine->mmio_base for relative offsets. Signed-off-by: Chris Wilson --- tests/i915/gem_ctx_isolation.c | 164 - 1 fi

Re: [Intel-gfx] [PATCH] drm/i915: Restore the kernel context after verifying the w/a

Chris Wilson writes: > As a safety net, flush the engine verifications and restore the kernel > context. > > Closes: https://gitlab.freedesktop.org/drm/intel/issues/971 > Signed-off-by: Chris Wilson Acked-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/gt/intel_gt.c | 4 > 1 file changed

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Enable second DBuf slice for ICL and TGL (rev21)

On 27/01/2020 09:48, Lisovskiy, Stanislav wrote: > Good morning :) > > > Yet another gem related issue not caused by this patch.. Thanks! Lakshmi reported the bug and I made the filing a little more generic and attached it to https://gitlab.freedesktop.org/drm/intel/issues/530. Thanks for sendi

[Intel-gfx] [PATCH] drm/i915/selftests/perf: measure memcpy bw between regions

Measure the memcpy bw between our CPU accessible regions, trying all supported mapping combinations(WC, WB) across various sizes. Signed-off-by: Matthew Auld Cc: Chris Wilson --- .../drm/i915/selftests/i915_perf_selftests.h | 1 + .../drm/i915/selftests/intel_memory_region.c | 164 +

[Intel-gfx] [PATCH] drm/i915/gt: Lift set-wedged engine dumping out of user paths

The user (e.g. gem_eio) can manipulate the driver into wedging itself, allowing the user to trigger voluminous logging of inconsequential details. If we lift the dump to direct calls to intel_gt_set_wedged(), out of the intel_reset failure handling, we keep the detail logging for what we expect are

[Intel-gfx] ✓ Fi.CI.IGT: success for Enable second DBuf slice for ICL and TGL (rev21)

== Series Details == Series: Enable second DBuf slice for ICL and TGL (rev21) URL : https://patchwork.freedesktop.org/series/70059/ State : success == Summary == CI Bug Log - changes from CI_DRM_7806_full -> Patchwork_16248_full Summary ---

[Intel-gfx] ✓ Fi.CI.IGT: success for Enable second DBuf slice for ICL and TGL (rev21)

== Series Details == Series: Enable second DBuf slice for ICL and TGL (rev21) URL : https://patchwork.freedesktop.org/series/70059/ State : success == Summary == CI Bug Log - changes from CI_DRM_7806_full -> Patchwork_16248_full Summary ---

Re: [Intel-gfx] [PATCH] drm/i915/selftests/perf: measure memcpy bw between regions

Quoting Matthew Auld (2020-01-27 12:56:26) > Measure the memcpy bw between our CPU accessible regions, trying all > supported mapping combinations(WC, WB) across various sizes. > > Signed-off-by: Matthew Auld > Cc: Chris Wilson > --- > .../drm/i915/selftests/i915_perf_selftests.h | 1 + > ..

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix inconsistance between pfit.enable and scaler freeing (rev3)

== Series Details == Series: drm/i915: Fix inconsistance between pfit.enable and scaler freeing (rev3) URL : https://patchwork.freedesktop.org/series/72539/ State : success == Summary == CI Bug Log - changes from CI_DRM_7810_full -> Patchwork_16259_full ===

Re: [Intel-gfx] [PATCH v3] drm/i915: Fix inconsistance between pfit.enable and scaler freeing

Quoting Ville Syrjälä (2020-01-24 18:15:30) > On Fri, Jan 24, 2020 at 07:23:01PM +0200, Stanislav Lisovskiy wrote: > > Despite that during hw readout we seem to have scalers assigned > > to pipes, then call atomic_setup_scalers, at the commit stage in > > skl_update_scaler there is a check, that if

Re: [Intel-gfx] [PATCH] drm/i915: Add missing HDMI audio pixel clocks for gen12

On Mon, Jan 27, 2020 at 01:39:09PM +0200, Kai Vehmanen wrote: > Gen12 hardware supports HDMI audio pixel clocks of 296.7/297Mhz > and 593.4/594Mhz. Add the missing rates and add logic to ignore > them if running on older hardware. > > Bspec: 49333 > Signed-off-by: Kai Vehmanen > --- > drivers/gp

Re: [Intel-gfx] [RFC 00/33] drm/i915/display: mass conversion to intel_de_*() register accessors

Quoting Jani Nikula (2020-01-24 15:25:21) > Hey all, > > So I sent [1] to convert some forcewake register accessors... but what if we > just ripped off the bandage once and for all? It's going to hurt, a lot, but > we'd get it done. > > This completely rids us of the "dev_priv" dependency in disp

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/8] drm/edid: Check the number of detailed timing descriptors in the CEA ext block

== Series Details == Series: series starting with [1/8] drm/edid: Check the number of detailed timing descriptors in the CEA ext block URL : https://patchwork.freedesktop.org/series/72550/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7811_full -> Patchwork_16262_full ===

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Implement Wa_1606931601 (rev2)

== Series Details == Series: drm/i915/tgl: Implement Wa_1606931601 (rev2) URL : https://patchwork.freedesktop.org/series/72433/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7811_full -> Patchwork_16263_full Summary ---

Re: [Intel-gfx] [PATCH v3 00/12] drm/i915: Add support for HDCP 1.4 over MST connectors

On Fri, Jan 17, 2020 at 2:31 PM Sean Paul wrote: > > From: Sean Paul > > Hey all, > Here's v3, which addresses all review comments in v2. > Friendly ping Sean > Sean > > Sean Paul (12): > drm/i915: Fix sha_text population code > drm/i915: Clear the repeater bit on HDCP disable > drm/i91

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Check current i915_vma.pin_count status first on unbind (rev2)

== Series Details == Series: drm/i915: Check current i915_vma.pin_count status first on unbind (rev2) URL : https://patchwork.freedesktop.org/series/72529/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7811_full -> Patchwork_16264_full =

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Check current i915_vma.pin_count status first on unbind

On 26/01/2020 10:23, Chris Wilson wrote: Do an early rejection of a i915_vma_unbind() attempt if the i915_vma is currently pinned, without waiting to see if the inflight operations may unpin it. We see this problem with the shrinker trying to unbind the active vma from inside its bind worker:

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Check current i915_vma.pin_count status first on unbind

Quoting Tvrtko Ursulin (2020-01-27 14:15:57) > > On 26/01/2020 10:23, Chris Wilson wrote: > > Do an early rejection of a i915_vma_unbind() attempt if the i915_vma is > > currently pinned, without waiting to see if the inflight operations may > > unpin it. We see this problem with the shrinker tryi

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Tighten atomicity of i915_active_acquire vs i915_active_release

On 26/01/2020 10:23, Chris Wilson wrote: As we use a mutex to serialise the first acquire (as it may be a lengthy operation), but only an atomic decrement for the release, we have to be careful in case a second thread races and completes both acquire/release as the first finishes its acquire.

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Check current i915_vma.pin_count status first on unbind

Quoting Chris Wilson (2020-01-27 14:20:21) > Quoting Tvrtko Ursulin (2020-01-27 14:15:57) > > > > On 26/01/2020 10:23, Chris Wilson wrote: > > > Do an early rejection of a i915_vma_unbind() attempt if the i915_vma is > > > currently pinned, without waiting to see if the inflight operations may > >

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Suppress DC5/DC6 around DSB usage (rev2)

== Series Details == Series: drm/i915/tgl: Suppress DC5/DC6 around DSB usage (rev2) URL : https://patchwork.freedesktop.org/series/72549/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7811_full -> Patchwork_16265_full Summa

Re: [Intel-gfx] [PATCH 13/17] drm/i915: Introduce better global state handling

On Mon, Jan 20, 2020 at 07:47:24PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Our current global state handling is pretty ad-hoc. Let's try to > make it better by imitating the standard drm core private object > approach. > > The reason why we don't want to directly use the private ob

Re: [Intel-gfx] [PATCH 14/17] drm/i915: Convert bandwidth state to global state

On Mon, Jan 20, 2020 at 07:47:25PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Now that we have the more formal global state thing let's > use if for memory bandwidth tracking. No real difference > to the current private object usage since we already > tried to avoid taking the single s

Re: [Intel-gfx] [PATCH 15/17] drm/i915: Introduce intel_calc_active_pipes()

On Mon, Jan 20, 2020 at 07:47:26PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Extract a small helper to compute the active pipes bitmask > based on the old bitmask + the crtcs in the atomic state. > I want to decouple the cdclk state entirely from the current > global state so I want t

[Intel-gfx] [PATCH] drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex

Similar to commit ac0e331a628b ("drm/i915: Tighten atomicity of i915_active_acquire vs i915_active_release") we have the same race of trying to pin the context underneath a mutex while allowing the decrement to be atomic outside of that mutex. This leads to the problem where two threads may simulta

Re: [Intel-gfx] [PATCH 4/6] drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex

On 26/01/2020 10:23, Chris Wilson wrote: <0> [198.668822] gem_exec-12460 193899010us : timeline_advance: timeline_advance:387 GEM_BUG_ON(!atomic_read(&tl->pin_count)) <0> [198.668859] - <4> [198.669619] [ cut here ] <2> [198.66962

Re: [Intel-gfx] [PATCH 4/6] drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex

Quoting Tvrtko Ursulin (2020-01-27 15:33:44) > > On 26/01/2020 10:23, Chris Wilson wrote: > > <0> [198.668822] gem_exec-12460 193899010us : timeline_advance: > > timeline_advance:387 GEM_BUG_ON(!atomic_read(&tl->pin_count)) > > <0> [198.668859] - > > <4> [1

Re: [Intel-gfx] [PATCH 5/6] drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore

On 26/01/2020 10:23, Chris Wilson wrote: If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the user batch or in our own preamble, the engine raises a GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so respond to a semaphore wait by yielding the timeslice, if we

Re: [Intel-gfx] [PATCH 5/6] drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore

Quoting Tvrtko Ursulin (2020-01-27 15:52:51) > > On 26/01/2020 10:23, Chris Wilson wrote: > > If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the > > user batch or in our own preamble, the engine raises a > > GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so >

Re: [Intel-gfx] [PATCH 5/6] drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore

Quoting Chris Wilson (2020-01-27 16:03:11) > Quoting Tvrtko Ursulin (2020-01-27 15:52:51) > > > > On 26/01/2020 10:23, Chris Wilson wrote: > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c > > > b/drivers/gpu/drm/i915/gt/intel_gt_irq.c > > > index f796bdf1ed30..6ae64a224b02 100644 > > > -

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Include the AUX CH name in the debug messages

On Thu, Jan 23, 2020 at 09:19:04AM -0800, Matt Roper wrote: > On Thu, Jan 23, 2020 at 05:45:41PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > To make it easier to figure out what caused a particular debug > > message let's print out aux->name. > > > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH] drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex

On 27/01/2020 15:28, Chris Wilson wrote: Similar to commit ac0e331a628b ("drm/i915: Tighten atomicity of i915_active_acquire vs i915_active_release") we have the same race of trying to pin the context underneath a mutex while allowing the decrement to be atomic outside of that mutex. This leads

Re: [Intel-gfx] [PATCH 17/17] drm/i915: Store active_pipes bitmask in cdclk state

On Mon, Jan 20, 2020 at 07:47:28PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Let's add a copy of the active_pipes bitmask into the cdclk_state. > While this is duplicating a bit of information we may already > have elsewhere, I think it's worth it to decopule the cdclk stuff > from wh

Re: [Intel-gfx] [PATCH] drm/i915: Add missing HDMI audio pixel clocks for gen12

Hi, On Mon, 27 Jan 2020, Ville Syrjälä wrote: > On Mon, Jan 27, 2020 at 01:39:09PM +0200, Kai Vehmanen wrote: > > Gen12 hardware supports HDMI audio pixel clocks of 296.7/297Mhz > > and 593.4/594Mhz. Add the missing rates and add logic to ignore > > them if running on older hardware. [...] > >

Re: [Intel-gfx] [PATCH v2 16/17] drm/i915: Convert cdclk to global state

On Mon, Jan 27, 2020 at 07:03:01PM +0200, Imre Deak wrote: > On Tue, Jan 21, 2020 at 04:03:53PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Let's convert cdclk_state to be a proper global state. That allows > > us to use the regular atomic old vs. new state accessor, hopefully > >

Re: [Intel-gfx] [PATCH v2 16/17] drm/i915: Convert cdclk to global state

On Tue, Jan 21, 2020 at 04:03:53PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Let's convert cdclk_state to be a proper global state. That allows > us to use the regular atomic old vs. new state accessor, hopefully > making the code less confusing. > > We do have to deal with a few mor

Re: [Intel-gfx] [PATCH v2 16/17] drm/i915: Convert cdclk to global state

On Mon, Jan 27, 2020 at 07:15:06PM +0200, Ville Syrjälä wrote: > On Mon, Jan 27, 2020 at 07:03:01PM +0200, Imre Deak wrote: > > On Tue, Jan 21, 2020 at 04:03:53PM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > Let's convert cdclk_state to be a proper global state. That allows >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: Fix OA context id overlap with idle context id (rev2)

== Series Details == Series: drm/i915/perf: Fix OA context id overlap with idle context id (rev2) URL : https://patchwork.freedesktop.org/series/72505/ State : success == Summary == CI Bug Log - changes from CI_DRM_7814_full -> Patchwork_16269_full =

[Intel-gfx] [PATCH v2] drm/hdcp: optimizing the srm handling

As we are not using the sysfs infrastructure anymore, link to it is removed. And global srm data and mutex to protect it are removed, with required handling at revocation check function. v2: srm_data is dropped and few more comments are addressed. Signed-off-by: Ramalingam C Suggested-by: Sean

[Intel-gfx] [PATCH i-g-t v2 1/2] i915/gem_ctx_isolation: use the gem_engine_topology library, part 1

From: Ramalingam C Call function gem_class_can_store_dword instead of legacy function gem_can_store_dword. This requires that e->class be available in the calling function. Instead of passing "engine" (== "e->flags") to functions, pass "e". This makes e->class available where it is needed. Thi

[Intel-gfx] [PATCH i-g-t v2 0/2] i915/gem_ctx_isolation: __for_each_physical_engine + engine mapping

i915/gem_ctx_isolation: __for_each_physical_engine and gem_engine_topology V2: Use new function gem_context_clone_with_engines Use __for_each_physical_engine with gem_engine_topology. Iterates through the definitive list of all engines present. Patch 1 was originally posted by Ramalingam C . Si

[Intel-gfx] [PATCH v2 0/8] drm/i915/display: mass conversion to intel_de_*() register accessors

Rebase of the patches from [1] that failed to apply. BR, Jani. [1] https://patchwork.freedesktop.org/series/72533/ Cc: Chris Wilson Cc: Rodrigo Vivi Cc: Joonas Lahtinen Jani Nikula (8): drm/i915/icl_dsi: use intel_de_*() functions for register access drm/i915/combo_phy: use intel_de_*(

[Intel-gfx] [PATCH v2 3/8] drm/i915/ddi: use intel_de_*() functions for register access

The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(),

[Intel-gfx] [PATCH v2 4/8] drm/i915/display: use intel_de_*() functions for register access

The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(),

[Intel-gfx] [PATCH v2 8/8] drm/i915/psr: use intel_de_*() functions for register access

The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(),

[Intel-gfx] [PATCH v2 6/8] drm/i915/dp: use intel_de_*() functions for register access

The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(),

[Intel-gfx] [PATCH v2 2/8] drm/i915/combo_phy: use intel_de_*() functions for register access

The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(),

Re: [Intel-gfx] [RFC 00/33] drm/i915/display: mass conversion to intel_de_*() register accessors

On Sat, 25 Jan 2020, Jani Nikula wrote: > On Fri, 24 Jan 2020, Rodrigo Vivi wrote: >> On Fri, Jan 24, 2020 at 01:54:58PM +, Chris Wilson wrote: >>> Quoting Jani Nikula (2020-01-24 13:25:21) >>> > Hey all, >>> > >>> > So I sent [1] to convert some forcewake register accessors... but what if

Re: [Intel-gfx] [RFC 05/33] drm/i915/combo_phy: use intel_de_*() functions for register access

On Fri, 24 Jan 2020, Matt Roper wrote: > On Fri, Jan 24, 2020 at 03:25:26PM +0200, Jani Nikula wrote: >> @@ -151,20 +151,20 @@ static void cnl_combo_phys_init(struct >> drm_i915_private *dev_priv) >> { >> u32 val; >> >> -val = I915_READ(CHICKEN_MISC_2); >> +val = intel_de_read(dev

[Intel-gfx] [PATCH i-g-t v2 2/2] i915/gem_ctx_isolation: use the gem_engine_topology library, part 2

Switch from simple iteration over all potential engines to using macro __for_each_physical_engine which only returns engines that are actually present. For each context (as it is created) call gem_context_set_all_engines so that execbuf will interpret the engine specification in the new way. Sign

[Intel-gfx] [PATCH v2 7/8] drm/i915/hdcp: use intel_de_*() functions for register access

The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(),

[Intel-gfx] [PATCH v2 1/8] drm/i915/icl_dsi: use intel_de_*() functions for register access

The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(),

[Intel-gfx] [PATCH v2 5/8] drm/i915/display_power: use intel_de_*() functions for register access

The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(),

Re: [Intel-gfx] [RFC 00/33] drm/i915/display: mass conversion to intel_de_*() register accessors

On Fri, 24 Jan 2020, Matt Roper wrote: > There's a lot of display (watermark) code in intel_pm.c as well, even > though it doesn't live in the display/ directory. We should probably > pull the watermark stuff out into a separate display/intel_wm.c or > something soon, but in the meantime we'll pr

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Check current i915_vma.pin_count status first on unbind

On 26/01/2020 10:23, Chris Wilson wrote: Do an early rejection of a i915_vma_unbind() attempt if the i915_vma is currently pinned, without waiting to see if the inflight operations may unpin it. We see this problem with the shrinker trying to unbind the active vma from inside its bind worker:

[Intel-gfx] [PATCH] drm/i915: Adding YUV444 packed format support for skl+ (V13)

From: Stanislav Lisovskiy PLANE_CTL_FORMAT_AYUV is already supported, according to hardware specification. v2: Edited commit message, removed redundant whitespaces. v3: Fixed fallthrough logic for the format switch cases. v4: Yet again fixed fallthrough logic, to reuse code from other case

  1   2   >