[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev4)

== Series Details == Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev4) URL : https://patchwork.freedesktop.org/series/80542/ State : success == Summary == CI Bug Log - changes from CI_DRM_8910_full -> Patchwork_18385_full =

[Intel-gfx] ✗ Fi.CI.IGT: failure for Allow privileged user to map the OA buffer

== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80868/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8910_full -> Patchwork_18384_full Summary ---

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Compute has_drrs after compute has_psr

== Series Details == Series: series starting with [1/2] drm/i915: Compute has_drrs after compute has_psr URL : https://patchwork.freedesktop.org/series/80866/ State : success == Summary == CI Bug Log - changes from CI_DRM_8910_full -> Patchwork_18383_full =

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Break up error capture compression loops with cond_resched()

== Series Details == Series: drm/i915: Break up error capture compression loops with cond_resched() URL : https://patchwork.freedesktop.org/series/80861/ State : success == Summary == CI Bug Log - changes from CI_DRM_8910_full -> Patchwork_18382_full ===

Re: [Intel-gfx] [RFC 13/20] drm/i915/dp: Extract drm_dp_downstream_read_info()

On Wed, Aug 19, 2020 at 05:34:15PM -0400, Lyude Paul wrote: > (adding Ville and Imre to the cc here, they might be interested to know about > this, comments down below) > > On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote: > > On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote: > > > We'

Re: [Intel-gfx] [PATCH i-g-t 1/4] i915/perf: 32bit printf cleanup

On 20/08/2020 20:26, Chris Wilson wrote: Use PRI[du]64 as necessary for 32bit builds. Signed-off-by: Chris Wilson Reviewed-by: Lionel Landwerlin Thanks! -Lionel --- tests/i915/perf.c| 8 tools/i915-perf/i915_perf_recorder.c | 2 +- 2 files changed, 5 ins

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Update to GuC v45.0.0

On 8/19/2020 2:14 PM, Michal Wajdeczko wrote: On 11.08.2020 03:04, Daniele Ceraolo Spurio wrote: On 8/7/2020 10:46 AM, john.c.harri...@intel.com wrote: From: John Harrison Update to the latest GuC firmware. This includes some significant changes to the interface. A high level overview of

Re: [Intel-gfx] [PATCH v6] drm/kmb: Add support for KeemBay Display

Hi Anitha. Feedback on kmb_dsi. The main feedback can be found after the kmb_dsi_init function. The highligt of the feedback is that, in my opinion, the best would be to use the drm_bridge abstraction for the kmb_dsi. Maybe because I am biased - and this is just overhead. But it just looks simple

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev4)

== Series Details == Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev4) URL : https://patchwork.freedesktop.org/series/80542/ State : success == Summary == CI Bug Log - changes from CI_DRM_8910 -> Patchwork_18385 ===

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev4)

== Series Details == Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev4) URL : https://patchwork.freedesktop.org/series/80542/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be check

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev4)

== Series Details == Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev4) URL : https://patchwork.freedesktop.org/series/80542/ State : warning == Summary == $ dim checkpatch origin/drm-tip a9e819463691 drm/nouveau/kms: Fix some indenting in nouveau_dp_detec

[Intel-gfx] [RFC v2 02/20] drm/nouveau/kms/nv50-: Remove open-coded drm_dp_read_desc()

Noticed this while going through our DP code - we use an open-coded version of drm_dp_read_desc() instead of just using the helper, so change that. This will also let us use quirks in the future if we end up needing them. Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nou

[Intel-gfx] [RFC v2 16/20] drm/i915/dp: Extract drm_dp_get_sink_count()

And of course, we'll also need to read the sink count from other drivers as well if we're checking whether or not it's supported. So, let's extract the code for this into another helper. v2: * Fix drm_dp_dpcd_readb() ret check * Add back comment and move back sink_count assignment in intel_dp_get_

[Intel-gfx] [RFC v2 17/20] drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT

This is another bit that we never implemented for nouveau: dongle detection. When a "dongle", e.g. an active display adaptor, is hooked up to the system and causes an HPD to be fired, we don't actually know whether or not there's anything plugged into the dongle without checking the sink count. As

[Intel-gfx] [RFC v2 19/20] drm/i915/dp: Extract drm_dp_read_dpcd_caps()

Since DP 1.3, it's been possible for DP receivers to specify an additional set of DPCD capabilities, which can take precedence over the capabilities reported at DP_DPCD_REV. Basically any device supporting DP is going to need to read these in an identical manner, in particular nouveau, so let's go

[Intel-gfx] [RFC v2 08/20] drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling

First some backstory here: Currently, we keep track of whether or not we've enabled MST or not by trying to piggy-back off the MST helpers. This means that in order to check whether MST is enabled or not, we actually need to grab drm_dp_mst_topology_mgr.lock. Back when I originally wrote this, I d

[Intel-gfx] [RFC v2 11/20] drm/nouveau/kms: Move drm_dp_cec_unset_edid() into nouveau_connector_detect()

For whatever reason we currently unset the EDID for DP CEC support when responding to the connector being unplugged, instead of just doing it in nouveau_connector_detect() where we set the CEC EDID. This isn't really needed and could even potentially cause us to forget to unset the EDID if the conn

[Intel-gfx] [RFC v2 15/20] drm/i915/dp: Extract drm_dp_has_sink_count()

Since other drivers are also going to need to be aware of the sink count in order to do proper dongle detection, we might as well steal i915's DP_SINK_COUNT helpers and move them into DRM helpers so that other dirvers can use them as well. Note that this also starts using intel_dp_has_sink_count()

[Intel-gfx] [RFC v2 09/20] drm/i915/dp: Extract drm_dp_has_mst()

Just a tiny drive-by cleanup, we can consolidate i915's code for checking for MST support into a helper to be shared across drivers. Signed-off-by: Lyude Paul Reviewed-by: Sean Paul --- drivers/gpu/drm/i915/display/intel_dp.c | 18 ++ include/drm/drm_dp_mst_helper.h | 22

[Intel-gfx] [RFC v2 18/20] drm/nouveau/kms: Don't change EDID when it hasn't actually changed

Currently in nouveau_connector_ddc_detect() and nouveau_connector_detect_lvds(), we start the connector probing process by releasing the previous EDID and informing DRM of the change. However, since commit 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector") drm_connector_update_edid_prop

[Intel-gfx] [RFC v2 20/20] drm/nouveau/kms: Start using drm_dp_read_dpcd_caps()

Now that we've extracted i915's code for reading both the normal DPCD caps and extended DPCD caps into a shared helper, let's start using this in nouveau to enable us to start checking extended DPCD caps for free. Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nou

[Intel-gfx] [RFC v2 04/20] drm/nouveau/kms/nv50-: Use macros for DP registers in nouveau_dp.c

No functional changes. Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nouveau_dp.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index 8db9216d52c69..4030806

[Intel-gfx] [RFC v2 12/20] drm/nouveau/kms: Only use hpd_work for reprobing in HPD paths

Currently we perform both short IRQ handling for DP, and connector reprobing in the HPD IRQ handler. However since we need to grab connection_mutex in order to reprobe a connector, in theory we could accidentally block ourselves from handling any short IRQs until after a modeset completes if a conn

[Intel-gfx] [RFC v2 06/20] drm/nouveau/kms: Search for encoders' connectors properly

While the way we find the associated connector for an encoder is just fine for legacy modesetting, it's not correct for nv50+ since that uses atomic modesetting. For reference, see the drm_encoder kdocs. Fix this by removing nouveau_encoder_connector_get(), and replacing it with nv04_encoder_get_c

[Intel-gfx] [RFC v2 01/20] drm/nouveau/kms: Fix some indenting in nouveau_dp_detect()

Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nouveau_dp.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index 8a0f7994e1aeb..ee778ddc95fae 100644 --- a/driv

[Intel-gfx] [RFC v2 00/20] drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's

[Intel-gfx] [RFC v2 07/20] drm/nouveau/kms/nv50-: Use drm_dp_dpcd_(readb|writeb)() in nv50_sor_disable()

Just use drm_dp_dpcd_(readb|writeb)() so we get automatic DPCD logging Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers

[Intel-gfx] [RFC v2 13/20] drm/i915/dp: Extract drm_dp_downstream_read_info()

We're going to be doing the same probing process in nouveau for determining downstream DP port capabilities, so let's deduplicate the work by moving i915's code for handling this into a shared helper: drm_dp_downstream_read_info(). Note that when we do this, we also do make some functional changes

[Intel-gfx] [RFC v2 03/20] drm/nouveau/kms/nv50-: Just use drm_dp_dpcd_read() in nouveau_dp.c

Since this actually logs accesses, we should probably always be using this imho… Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nouveau_dp.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/dr

[Intel-gfx] [RFC v2 14/20] drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation

This adds support for querying the maximum clock rate of a downstream port on a DisplayPort connection. Generally, downstream ports refer to active dongles which can have their own pixel clock limits. Note as well, we also start marking the connector as disconnected if we can't read the DPCD, sinc

[Intel-gfx] [RFC v2 10/20] drm/nouveau/kms: Use new drm_dp_has_mst() helper for checking MST caps

Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++- 1 file changed, 3 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index 032afc73e2a33..201c0b4335563 100644

[Intel-gfx] [RFC v2 05/20] drm/nouveau/kms: Don't clear DP_MST_CTRL DPCD in nv50_mstm_new()

Since fa3cdf8d0b09 ("drm/nouveau: Reset MST branching unit before enabling") we've been clearing DP_MST_CTRL before we start enabling MST. Since then clearing DP_MST_CTRL in nv50_mstm_new() has been unnecessary and redundant, so let's remove it. Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs

[Intel-gfx] [PATCH i-g-t 3/4] i915/bb: Cleanup 32bit printfs

Use PRIx64 for 64b addresses on a 32b build. Signed-off-by: Chris Wilson --- tests/i915/api_intel_bb.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/tests/i915/api_intel_bb.c b/tests/i915/api_intel_bb.c index 6967fc5d0..cf7f6e91b 100644 --- a/tests/i915/a

[Intel-gfx] ✓ Fi.CI.BAT: success for Allow privileged user to map the OA buffer

== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80868/ State : success == Summary == CI Bug Log - changes from CI_DRM_8910 -> Patchwork_18384 Summary --- **SUCCES

[Intel-gfx] [PATCH i-g-t 4/4] i915/gem_exec_alignment: 32b printf cleanups

PRIu64 to the rescue! Signed-off-by: Chris Wilson --- tests/i915/gem_exec_alignment.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/i915/gem_exec_alignment.c b/tests/i915/gem_exec_alignment.c index 17a14bef4..7bbd2a8fc 100644 --- a/tests/i915/gem_exec_alignment.c +++

[Intel-gfx] [PATCH i-g-t 2/4] i915/gem_exec_fence: Cleanup 32bit printfs

Use PRI[ux]64 for printing 64bit values in a 32bit build. Signed-off-by: Chris Wilson --- tests/i915/gem_exec_fence.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c index b240c30bf..0b8ab1400 100644 --- a/t

[Intel-gfx] [PATCH i-g-t 1/4] i915/perf: 32bit printf cleanup

Use PRI[du]64 as necessary for 32bit builds. Signed-off-by: Chris Wilson --- tests/i915/perf.c| 8 tools/i915-perf/i915_perf_recorder.c | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/tests/i915/perf.c b/tests/i915/perf.c index 92edc9f1f..a894f

[Intel-gfx] [PATCH 0/4] Allow privileged user to map the OA buffer

Allow user to map the OA buffer and also trigger reports into it. CI fixes: v1: Fixes a memory corruption due to addition of OA whitelist on demand. v2: Spinlock when applying whitelist v3: Use uncore->lock. Do not check for wal->count when applying whitelist. v4: Refresh and rerun with newly add

[Intel-gfx] [PATCH 3/4] drm/i915/perf: Whitelist OA counter and buffer registers

It is useful to have markers in the OA reports to identify triggered reports. Whitelist some OA counters that can be used as markers. A triggered report can be found faster if we can sample the HW tail and head registers when the report was triggered. Whitelist OA buffer specific registers. v2: -

[Intel-gfx] [PATCH 1/4] drm/i915/perf: Ensure observation logic is not clock gated

From: Piotr Maciejewski A clock gating switch can control if the performance monitoring and observation logic is enaled or not. Ensure that we enable the clocks. v2: Separate code from other patches (Lionel) v3: Reset PMON enable when disabling perf to save power (Lionel) v4: Use intel_uncore_rm

[Intel-gfx] [PATCH 2/4] drm/i915/perf: Whitelist OA report trigger registers

OA reports can be triggered into the OA buffer by writing into the OAREPORTTRIG registers. Whitelist the registers to allow non-privileged user to trigger reports. Whitelist registers only if perf_stream_paranoid is set to 0. In i915_perf_open_ioctl, this setting is checked and the whitelist is en

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

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 implementation for query, but Gen12+ requires a new approach for query based on triggere

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Compute has_drrs after compute has_psr

== Series Details == Series: series starting with [1/2] drm/i915: Compute has_drrs after compute has_psr URL : https://patchwork.freedesktop.org/series/80866/ State : success == Summary == CI Bug Log - changes from CI_DRM_8910 -> Patchwork_18383 ===

Re: [Intel-gfx] [PATCH v6] drm/kmb: Add support for KeemBay Display

Hi Anitha. On Mon, Aug 10, 2020 at 02:53:38PM -0700, Anitha Chrisanthus wrote: > This is a basic KMS atomic modesetting display driver for KeemBay family of > SOCs. Driver has no 2D or 3D graphics.It calls into the ADV bridge > driver at the connector level. > > Single CRTC with LCD controller->m

[Intel-gfx] [PATCH 1/2] drm/i915: Compute has_drrs after compute has_psr

DRRS and PSR can't be enable together, so giving preference to PSR as it allows more power-savings by complete shutting down display, so to guarantee this, it should compute DRRS state after compute PSR. Cc: Srinivas K Cc: Hariom Pandey Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/

[Intel-gfx] [PATCH 2/2] drm/i915/drrs: Disable DRRS when needed in fastsets

Changes in the configuration could cause PSR to be compatible and enabled so driver must also be able to disable DRRS when doing fastsets. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/209 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/173 Closes: https://gitlab.freedesktop.

Re: [Intel-gfx] [PATCH 2/2] drm/virtio: Remove open-coded commit-tail function

On 19. 08. 20, 15:24, Gerd Hoffmann wrote: > On Wed, Aug 19, 2020 at 02:43:28PM +0200, Jiri Slaby wrote: >> On 09. 07. 20, 14:33, Daniel Vetter wrote: >>> Exactly matches the one in the helpers. >> >> It's not that exact. The order of modeset_enables and planes is >> different. And this causes a re

Re: [Intel-gfx] [RFC 19/20] drm/i915/dp: Extract drm_dp_read_dpcd_caps()

On Wed, 2020-08-19 at 11:29 -0400, Sean Paul wrote: > On Tue, Aug 11, 2020 at 04:04:56PM -0400, Lyude Paul wrote: > > Since DP 1.3, it's been possible for DP receivers to specify an > > additional set of DPCD capabilities, which can take precedence over the > > capabilities reported at DP_DPCD_REV.

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

On Thu, Aug 20, 2020 at 2:23 AM Pavel Machek wrote: > > Yes, it seems they make things work. (Chris asked for new patch to be > tested, so I am switching to his kernel, but it survived longer than > it usually does.) Ok, so at worst we know how to solve it, at best the reverts won't be needed bec

Re: [Intel-gfx] [RFC 19/20] drm/i915/dp: Extract drm_dp_read_dpcd_caps()

On Wed, 2020-08-19 at 11:29 -0400, Sean Paul wrote: > On Tue, Aug 11, 2020 at 04:04:56PM -0400, Lyude Paul wrote: > > Since DP 1.3, it's been possible for DP receivers to specify an > > additional set of DPCD capabilities, which can take precedence over the > > capabilities reported at DP_DPCD_REV.

[Intel-gfx] [PATCH i-g-t v3 19/19] tests/core_hotunplug: Un-blocklist *bind* subtests

Subtests which don't remove the device, only unbind the driver from it, seem relatively safe and harmless for CI. Remove them from the CI blocklist. Signed-off-by: Janusz Krzysztofik --- tests/intel-ci/blacklist.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/intel

[Intel-gfx] [PATCH i-g-t v3 12/19] tests/core_hotunplug: Fail subtests on device close errors

Since health checks are now run from follow-up fixture sections, it is safe to fail subtests without the need to abort the test execution. Do that on device close errors instead of just emitting warnings. v3: Refresh. Signed-off-by: Janusz Krzysztofik Reviewed-by: Michał Winiarski --- tests/c

[Intel-gfx] [PATCH i-g-t v3 13/19] tests/core_hotunplug: Let the driver time out essential sysfs operations

The test now arms a timer before performing each driver unbind / rebind or device unplug / bus rescan sysfs operation. Then in case of issues we may prevent the driver from showing us if and how it can handle them. Don't arm the timer before sysfs operations which are essential for a subtest. Si

[Intel-gfx] [PATCH i-g-t v3 14/19] tests/core_hotunplug: Process return values of sysfs operations

Return values of driver bind/unbind / device remove/recover sysfs operations are now ignored. Assert their correctness. v2: Add trailing newlines missing from igt_assert messages. Signed-off-by: Janusz Krzysztofik Reviewed-by: Michał Winiarski --- tests/core_hotunplug.c | 14 ++ 1

[Intel-gfx] [PATCH i-g-t v3 16/19] tests/core_hotunplug: Explicitly ignore unused return values

Some return values are not useful and can be ignored. Wrap those cases inside igt_ignore_warn(), not only to make sure compilers are happy but also to clearly document our decisions. Signed-off-by: Janusz Krzysztofik Reviewed-by: Michał Winiarski --- tests/core_hotunplug.c | 6 +++--- 1 file c

[Intel-gfx] [PATCH i-g-t v3 07/19] tests/core_hotunplug: Pass errors via a data structure field

A pointer to fatal error messages can be passed around via hotunplug structure, no need to declare it as global. v3: Refresh. Signed-off-by: Janusz Krzysztofik Reviewed-by: Michał Winiarski --- tests/core_hotunplug.c | 96 +- 1 file changed, 47 insertion

[Intel-gfx] [PATCH i-g-t v3 17/19] tests/core_hotunplug: More thorough i915 healthcheck and recovery

The test now assumes the i915 driver is able to identify potential hardware or driver issues while rebinding to a device and indicate them by marking the GPU wedged. Should that assumption occur wrong, the health check phase of the test would happily succeed while potentially leaving the device in

[Intel-gfx] [PATCH i-g-t v3 15/19] tests/core_hotunplug: Assert expected device presence/absence

Don't rely on successful write to sysfs control files, assert existence / non-existence of a respective device sysfs node as well. Signed-off-by: Janusz Krzysztofik Reviewed-by: Michał Winiarski --- tests/core_hotunplug.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/tests

[Intel-gfx] [PATCH i-g-t v3 18/19] tests/core_hotunplug: Add 'lateclose before restore' variants

If a GPU gets wedged during driver rebind or device re-plug for some reason, current hotunbind/hotunplug test variants may time out before lateclose phase, resulting in incomplete CI reports. Rename those variants to more adequate hotrebind/hotreplug-lateclose and add new variants under the old na

[Intel-gfx] [PATCH i-g-t v3 09/19] tests/core_hotunplug: Prepare invariant data once per test run

Each subtest now calls a prepare() helper which opens a couple of files required by that subtest. Those files are then closed after use, either directly from the subtest body, or indirectly from inside one of helper functions called during the subtest execution. That approach not only makes lifec

[Intel-gfx] [PATCH i-g-t v3 04/19] tests/core_hotunplug: Consolidate duplicated debug messages

Some debug messages which designate specific test operations, or their greater parts at least, sound always the same, no matter which subtest they are called from. Emit them, possibly updated with subtest specified modifiers, from inside respective helpers instead of duplicating them in subtest bo

[Intel-gfx] [PATCH i-g-t v3 08/19] tests/core_hotunplug: Handle device close errors

The test now ignores device close errors. Those errors are believed to have no influence on device health so there is no need to process them the same way as we mostly do on errors, i.e., notify CI about a problem via igt_abort. However, those errors may indicate issues with the test itself. Mor

[Intel-gfx] [PATCH i-g-t v3 02/19] tests/core_hotunplug: Constify dev_bus_addr string

Device bus address structure field is always initialized with a pointer to a substring of the device sysfs path and never used for its modification. Declare it as a constant string. Signed-off-by: Janusz Krzysztofik Reviewed-by: Michał Winiarski --- tests/core_hotunplug.c | 2 +- 1 file change

[Intel-gfx] [PATCH i-g-t v3 11/19] tests/core_hotunplug: Recover from subtest failures

Subtests now forcibly call or request igt_abort on failures in order to avoid silently leaving an exercised device in an unusable state. However, a failure inside a subtest doesn't always mean the device is no longer working correctly and reboot is needed. On the other hand, if a subtest just fail

[Intel-gfx] [PATCH i-g-t v3 05/19] tests/core_hotunplug: Assert successful device filter application

Return value of igt_device_filter_add() representing a number of successfully installed device filters is now ignored. Fail if not 1. Signed-off-by: Janusz Krzysztofik Reviewed-by: Michał Winiarski --- tests/core_hotunplug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t

[Intel-gfx] [PATCH i-g-t v3 06/19] tests/core_hotunplug: Maintain a single data structure instance

The following changes to the test are planned: - avoid global variables, - skip subtest after device close errors, - prepare invariant data only once per test run, - move device health checks to igt_fixture sections, - try to recover from subtest failures instead of aborting. For that to be possibl

[Intel-gfx] [PATCH i-g-t v3 10/19] tests/core_hotunplug: Skip selectively on sysfs close errors

Since we no longer open a device DRM sysfs node, only a PCI one, driver unbind operations are no longer affected by missed or unsuccessful sysfs file close attempts. Skip only affected subtests if that happens. v3: Refresh. Signed-off-by: Janusz Krzysztofik Reviewed-by: Michał Winiarski --- t

[Intel-gfx] [PATCH i-g-t v3 01/19] tests/core_hotunplug: Use igt_assert_fd()

There is a new library helper that asserts validity of open file descriptors. Use it instead of open coding. Signed-off-by: Janusz Krzysztofik Reviewed-by: Michał Winiarski --- tests/core_hotunplug.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tests/core_hotu

[Intel-gfx] [PATCH i-g-t v3 03/19] tests/core_hotunplug: Clean up device open error handling

We don't use drm_driver_open() since in case of an i915 device it keeps an extra file descriptor of the exercised device open for exit handler use, while we would like to be able to close the device completely before running certain test operations. Instead, we call __drm_driver_open() and handle

[Intel-gfx] [PATCH i-g-t v3 00/19] tests/core_hotunplug: Fixes and enhancements

Clean up the test code, add some new basic subtests, then unblock unbind test variants. One patch has been renamed, three new patches added to the series, and one more patch form a formerly submitted series with new subtests included. @Michał: Since most v2/v3 updates are trivial, I've preserved

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Break up error capture compression loops with cond_resched()

== Series Details == Series: drm/i915: Break up error capture compression loops with cond_resched() URL : https://patchwork.freedesktop.org/series/80861/ State : success == Summary == CI Bug Log - changes from CI_DRM_8910 -> Patchwork_18382

[Intel-gfx] [PATCH] drm/i915: Break up error capture compression loops with cond_resched()

As the error capture will compress user buffers as directed to by the user, it can take an arbitrary amount of time and space. Break up the compression loops with a call to cond_resched(), that will allow other processes to schedule (avoiding the soft lockups) and also serve as a warning should we

[Intel-gfx] [PATCH i-g-t] i915/gem_exec_capture: Check the capture runs in isolation

Capturing the error state for one context should not impede progress of other contexts across the system. That is we reset the engine, remove the context from the execution queue, then capture it. Once the hanging request has been removed, we can execute any other context instead. Signed-off-by: C

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported

== Series Details == Series: drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported URL : https://patchwork.freedesktop.org/series/80821/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8908_full -> Patchwork_18380_full ===

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Fix stepping WA matching

== Series Details == Series: drm/i915/tgl: Fix stepping WA matching URL : https://patchwork.freedesktop.org/series/80820/ State : success == Summary == CI Bug Log - changes from CI_DRM_8908_full -> Patchwork_18379_full Summary --- **

Re: [Intel-gfx] [PATCH v2 24/24] drm/i915: Do not share hwsp across contexts any more

On 8/19/20 4:09 PM, Maarten Lankhorst wrote: Instead of sharing pages with breadcrumbs, give each timeline a single page. This allows unrelated timelines not to share locks any more during command submission. As an additional benefit, seqno wraparound no longer requires i915_vma_pin, which mean

Re: [Intel-gfx] [PATCH v2 23/24] drm/i915: Add ww locking to pin_to_display_plane, v2.

On 8/19/20 4:09 PM, Maarten Lankhorst wrote: Use ww locking for pin_to_display_plane for all the pinning and locking. With the locking removed from set_cache_level, we need to fix i915_gem_set_caching_ioctl to take the object reservation lock. As this is a single lock, we don't need to use the

Re: [Intel-gfx] [PATCH v2 22/24] drm/i915: Add ww locking to vm_fault_gtt

On 8/19/20 4:09 PM, Maarten Lankhorst wrote: We want to start requiring the reservation_lock instead of obj->mm.lock for pinning objects, take the ww lock inside vm_fault_gtt as a first step towards the legacy lock removal. Signed-off-by: Maarten Lankhorst Reviewed-by: Thomas Hellström __

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/display/tgl: Use TGL DP tables for eDP ports without low power support

== Series Details == Series: series starting with [1/3] drm/i915/display/tgl: Use TGL DP tables for eDP ports without low power support URL : https://patchwork.freedesktop.org/series/80819/ State : success == Summary == CI Bug Log - changes from CI_DRM_8908_full -> Patchwork_18377_full ==

Re: [Intel-gfx] [PATCH v2 14/24] drm/i915: Make sure execbuffer always passes ww state to i915_vma_pin.

On 8/19/20 4:08 PM, Maarten Lankhorst wrote: As a preparation step for full object locking and wait/wound handling during pin and object mapping, ensure that we always pass the ww context in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this happens. This also requires changing t

Re: [Intel-gfx] [PATCH] drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported

On Wed, 19 Aug 2020 at 21:32, Chris Wilson wrote: > > Let's not try and use PAT attributes for I915_MAP_WC is the CPU doesn't > support PAT. > > Fixes: 6056e50033d9 ("drm/i915/gem: Support discontiguous lmem object maps") > Signed-off-by: Chris Wilson > Cc: # v5.6+ Reviewed-by: Matthew Auld ___

[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave & Daniel - This is a fairly ordinary looking set of i915 fixes for v5.9-rc2. Of course, the out of the ordinary is what's *not* here. This replaces the earlier pull request [1]. The dinq branch has since been split and rebased, with a new topic/drm-intel-gem-next. The fixes in this pull

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

Hi! > > I think there's been some discussion about reverting that change for > > other reasons, but it's quite likely the culprit. > > Hmm. It reverts cleanly, but the end result doesn't work, because of > other changes. > > Reverting all of > >763fedd6a216 ("drm/i915: Remove i915_gem_objec

[Intel-gfx] [PATCH v4 2/3] kernel/trace: Add TRACING_ALLOW_PRINTK config option

trace_printk is meant as a debugging tool, and should not be compiled into production code without specific debug Kconfig options enabled, or source code changes, as indicated by the warning that shows up on boot if any trace_printk is called: ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] drm/i915/gem: Replace reloc chain with terminator on error unwind (rev2)

== Series Details == Series: series starting with [1/2] drm/i915/gem: Replace reloc chain with terminator on error unwind (rev2) URL : https://patchwork.freedesktop.org/series/80795/ State : failure == Summary == Applying: drm/i915/gem: Replace reloc chain with terminator on error unwind erro

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: Replace reloc chain with terminator on error unwind

Quoting Pavel Machek (2020-08-19 20:33:26) > Hi! > > > > > If we hit an error during construction of the reloc chain, we need to > > > > replace the chain into the next batch with the terminator so that upon > > > > flushing the relocations so far, we do not execute a hanging batch. > > > > > > T

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add support for HDCP 1.4 over MST (rev3)

== Series Details == Series: drm/i915: Add support for HDCP 1.4 over MST (rev3) URL : https://patchwork.freedesktop.org/series/78749/ State : success == Summary == CI Bug Log - changes from CI_DRM_8908_full -> Patchwork_18375_full Summary -