[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/4] drm-print (rev2)

== Series Details == Series: series starting with [v3,1/4] drm-print (rev2) URL : https://patchwork.freedesktop.org/series/33566/ State : failure == Summary == Series 33566v2 series starting with [v3,1/4] drm-print https://patchwork.freedesktop.org/api/1.0/series/33566/revisions/2/mbox/ Test

[Intel-gfx] [PATCH] drm/i915/selftests: Reduce the volume of the timeout message

Originally it was anticipated that timeouts would be a rare event, and so merit a warning that the test was incomplete. However, for igt we keep the timeout low, and hitting the timeout is intentional. It no longer necessitates a warning, but to be expected. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH v2] drm/printer: Add drm_vprintf()

On Fri, Nov 10, 2017 at 09:52:26AM +, Chris Wilson wrote: > Simple va_args equivalent to the existing drm_printf() for use with the > drm_printer. > > Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter I guess you want an ack from Dave

[Intel-gfx] [PATCH v3 04/11] drm/i915: Handle adjust better in intel_pipe_config_compare

Some parameters use CHECK_BOOLL, but should really use CHECK_BOOL_INCOMPLETE. We cannot currently check whether the inherited infoframes and audio are set up correctly. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 19

[Intel-gfx] [PATCH v3 08/11] drm/i915: Pass crtc_state to ips toggle functions, v2

Changes since v1: - Only pass crtc_state, not crtc. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_color.c | 4 ++-- drivers/gpu/drm/i915/intel_display.c | 25 ++--- drivers/gpu/drm/i915/intel_dp.c | 6 +++---

[Intel-gfx] [PATCH v3 11/11] drm/i915: Re-enable fastboot by default

This fix was originally reverted because it left a chromebook pixel black, and no immediate fix was available. This has been fixed in the meantime. Rather than trying to remove the parameter, set it to default to true for now, so we can always back out if required. Signed-off-by: Maarten

[Intel-gfx] [PATCH v3 10/11] drm/i915: Enable FIFO underrun reporting after initial fastset, v3.

The firmware may have set up the pipe correctly, but the FIFO underrun and CRC interrupts are likely not enabled. This resulted in debugfs_test.read_all_entries failing on haswell, because of a timeout when reading the crc debugfs entry. Solve this by enabling FIFO underrun reporting after the

[Intel-gfx] [PATCH v3 01/11] drm/i915: Update watermark state correctly in sanitize_watermarks

We no longer use intel_crtc->wm.active for watermarks any more, which was incorrect. But this uncovered a bug in sanitize_watermarks(), which meant that we wrote the correct watermarks, but the next update would still use the wrong hw watermarks for calculating. This caused all further updates to

[Intel-gfx] [PATCH v3 07/11] drm/i915: Pass idle crtc_state to intel_dp_sink_crc

IPS can only be enabled if the primary plane is visible, so first make sure sw state matches hw state by waiting for hw_done. After this pass crtc_state to intel_dp_sink_crc() so that can be used, instead of using legacy pointers. Signed-off-by: Maarten Lankhorst

[Intel-gfx] [PATCH v3 02/11] drm/i915: Remove bogus ips_enabled check.

The flag just tells us IPS can be enabled, if the primary plane is not enabled it means IPS might not be. This never triggered in CI because we don't have a haswell ULT there, but can be reproduced easily with kms_atomic_transitions.plane-all-modeset-transition Signed-off-by: Maarten Lankhorst

[Intel-gfx] [PATCH v3 09/11] drm/i915: Handle ips_enabled in fastset, v2.

pre_plane_disable and post_plane_enable handle set ips correctly, but if there is no modeset and the ips_enabled value changes because of force disabling for crc, or hw state readout, then we don't toggle ips correctly. Handle this special case, which prevents us from having to do a full modeset

[Intel-gfx] [PATCH v3 06/11] drm/i915: Handle locking better in i915_sink_crc.

Lock the bare minimum, instead of the entire world, and use interruptible locking because we can. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_debugfs.c | 40 + 1 file changed, 32 insertions(+), 8

[Intel-gfx] [PATCH v3 03/11] drm/i915: Check boolean options in intel_pipe_config_compare with its own macro

Add PIPE_CONF_CHECK_BOOL for boolean options, which are printed with yesno. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 30 -- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git

[Intel-gfx] [PATCH v3 05/11] drm/i915: Only enable IPS when primary plane is visible

This prevents us from having to open code those checks in intel_dp_sink_crc. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Reduce the volume of the timeout message

Quoting Patchwork (2017-11-10 11:36:36) > == Series Details == > > Series: drm/i915/selftests: Reduce the volume of the timeout message > URL : https://patchwork.freedesktop.org/series/33589/ > State : success > > == Summary == > > Test perf: > Subgroup polling: > pass

Re: [Intel-gfx] [PATCH] drm/i915: Return early when pipes are not available

On Thu, 2017-11-09 at 15:15 +0200, Ville Syrjälä wrote: > On Thu, Nov 09, 2017 at 01:11:05PM +0200, Mika Kahola wrote: > > > > On Thu, 2017-11-09 at 11:01 +, Chris Wilson wrote: > > > > > > Quoting Mika Kahola (2017-11-09 10:49:52) > > > > > > > > > > > > At least in Coffee Lake it happens

Re: [Intel-gfx] [PATCH RFC] drm/i915: Print dmesg warn on unintended hangs

Chris Wilson writes: > Quoting Mika Kuoppala (2017-11-10 12:20:55) >> Chris Wilson writes: >> >> > Quoting Mika Kuoppala (2017-11-10 11:53:47) >> >> We have a problem of distinguishing intended hangs >> >> submitted by igt during CI/bat and

Re: [Intel-gfx] [PATCH 0/7] Add Plane Color Properties

>-Original Message- >From: Daniel Stone [mailto:dan...@fooishbar.org] >Sent: Tuesday, November 7, 2017 9:44 PM >To: Shankar, Uma >Cc: intel-gfx ; dri-devel de...@lists.freedesktop.org>; Syrjala, Ville ;

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v2] drm/printer: Add drm_vprintf() (rev3)

== Series Details == Series: series starting with [v2] drm/printer: Add drm_vprintf() (rev3) URL : https://patchwork.freedesktop.org/series/33566/ State : warning == Summary == Series 33566v3 series starting with [v2] drm/printer: Add drm_vprintf()

Re: [Intel-gfx] [RFC 0/3] GuC functions name/prototype update

On Fri, 2017-11-10 at 10:04 +, Chris Wilson wrote: > Quoting Sagar Arun Kamble (2017-11-10 09:59:44) > > We want to have consistent function/structure/file naming and > > function parameter semantics. Suggestion from Michal Wajdeczko about > > using "genx_" prefix (or better _genx" suffix for

Re: [Intel-gfx] [PATCH] drm/i915: Restore the wait for idle engine after flushing interrupts

Quoting Mika Kuoppala (2017-11-10 12:00:38) > Chris Wilson writes: > > > So it appears that commit 5427f207852d ("drm/i915: Bump wait-times for > > the final CS interrupt before parking") was a little over optimistic in > > its belief that it had successfully waited for

Re: [Intel-gfx] [PATCH RFC] drm/i915: Print dmesg warn on unintended hangs

Quoting Mika Kuoppala (2017-11-10 11:53:47) > We have a problem of distinguishing intended hangs > submitted by igt during CI/bat and hangs that are nonintended > happening in close proximity. Do we? I haven't had that problem in distinguishing them. -Chris

Re: [Intel-gfx] [PATCH RFC] drm/i915: Print dmesg warn on unintended hangs

Quoting Chris Wilson (2017-11-10 12:30:21) > Quoting Mika Kuoppala (2017-11-10 12:20:55) > > Chris Wilson writes: > > > > > Quoting Mika Kuoppala (2017-11-10 11:53:47) > > >> We have a problem of distinguishing intended hangs > > >> submitted by igt during CI/bat and

[Intel-gfx] ✗ Fi.CI.BAT: warning for GuC functions name/prototype update

== Series Details == Series: GuC functions name/prototype update URL : https://patchwork.freedesktop.org/series/33587/ State : warning == Summary == Series 33587v1 GuC functions name/prototype update https://patchwork.freedesktop.org/api/1.0/series/33587/revisions/1/mbox/ Test chamelium:

Re: [Intel-gfx] [PATCH v2 3/9] drm/i915/perf: refactor perf setup

On 2 November 2017 at 16:29, Lionel Landwerlin wrote: > Gen8/9 aren't very different and we can merge some of this code. > > Signed-off-by: Lionel Landwerlin Reviewed-by: Matthew Auld

[Intel-gfx] [PATCH] drm/i915: Restore the wait for idle engine after flushing interrupts

So it appears that commit 5427f207852d ("drm/i915: Bump wait-times for the final CS interrupt before parking") was a little over optimistic in its belief that it had successfully waited for all residual activity on the engines before parking. Numerous sightings in CI since then of <7>[

Re: [Intel-gfx] Pushing commits to drm-intel-next-queued and questions about CI

Hi, On 07-11-17 17:50, Jani Nikula wrote: On Tue, 07 Nov 2017, Hans de Goede wrote: Hi, On 03-11-17 20:11, Hans de Goede wrote: Hi, On 03-11-17 19:51, Hans de Goede wrote: Hi, On 03-11-17 18:40, Rodrigo Vivi wrote: Hi Hans, On Fri, Nov 03, 2017 at 10:41:55AM +,

Re: [Intel-gfx] [PATCH RFC] drm/i915: Print dmesg warn on unintended hangs

Chris Wilson writes: > Quoting Mika Kuoppala (2017-11-10 11:53:47) >> We have a problem of distinguishing intended hangs >> submitted by igt during CI/bat and hangs that are nonintended >> happening in close proximity. > > Do we? I haven't had that problem in

Re: [Intel-gfx] [PATCH v3 02/11] drm/i915: Remove bogus ips_enabled check.

On Fri, Nov 10, 2017 at 12:34:54PM +0100, Maarten Lankhorst wrote: > The flag just tells us IPS can be enabled, if the primary plane > is not enabled it means IPS might not be. This never triggered > in CI because we don't have a haswell ULT there, but can be > reproduced easily with

Re: [Intel-gfx] [PATCH] Skylake DMC v1.27

HI, > -Original Message- > From: Saarinen, Jani > Sent: perjantai 10. marraskuuta 2017 9.14 > To: 'Anusha Srivatsa' ; intel- > g...@lists.freedesktop.org > Subject: RE: [Intel-gfx] [PATCH] Skylake DMC v1.27 > > Hi, > > -Original Message- > > From:

[Intel-gfx] [PATCH v4] drm/i915: Include engine state on detecting a missed breadcrumb/seqno

Now that we have a common engine state pretty printer, we can use that instead of the adhoc information printed when we miss a breadcrumb. v2: Rearrange intel_engine_disarm_breadcrumbs() to avoid calling intel_engine_dump() under the rb spinlock (Mika) and to pretty-print the error state early so

[Intel-gfx] [PATCH v2] drm/printer: Add drm_vprintf()

Simple va_args equivalent to the existing drm_printf() for use with the drm_printer. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_print.c | 5 + include/drm/drm_print.h | 14 ++ 2 files changed, 15 insertions(+), 4 deletions(-) diff --git

Re: [Intel-gfx] [RFC 0/3] GuC functions name/prototype update

Quoting Sagar Arun Kamble (2017-11-10 09:59:44) > We want to have consistent function/structure/file naming and > function parameter semantics. Suggestion from Michal Wajdeczko about > using "genx_" prefix (or better _genx" suffix for all hw related > structures types, offsets), "i915_" prefix for

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/atomic-helper: always track connector commits, too

== Series Details == Series: series starting with [1/2] drm/atomic-helper: always track connector commits, too URL : https://patchwork.freedesktop.org/series/33591/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK

Re: [Intel-gfx] [PATCH] drm/i915: Restore the wait for idle engine after flushing interrupts

Chris Wilson writes: > So it appears that commit 5427f207852d ("drm/i915: Bump wait-times for > the final CS interrupt before parking") was a little over optimistic in > its belief that it had successfully waited for all residual activity on > the engines before

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: Make engine state pretty-printer header configurable

Chris Wilson writes: > Pass in a format string (and args) to specify the header to be emitted > along with the engine state when pretty-printing. This allows the header > to be emitted inside the drm_printer stream, so sharing the same prefix > and output

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/skl: DMC firmware for skylake v1.27

== Series Details == Series: drm/i915/skl: DMC firmware for skylake v1.27 URL : https://patchwork.freedesktop.org/series/33568/ State : warning == Summary == Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 Test kms_vblank:

[Intel-gfx] [RFC 0/3] GuC functions name/prototype update

We want to have consistent function/structure/file naming and function parameter semantics. Suggestion from Michal Wajdeczko about using "genx_" prefix (or better _genx" suffix for all hw related structures types, offsets), "i915_" prefix for driver entry calls and "intel_" in all other seems to

[Intel-gfx] [RFC 2/3] drm/i915/guc: Rename i915_guc_client struct to intel_guc_client

GuC submission clients are currently being used in kernel only hence update the structure name to intel_guc_client. Signed-off-by: Sagar Arun Kamble Cc: Michal Wajdeczko Cc: Michal Winiarski Cc: Oscar Mateo

[Intel-gfx] [RFC 1/3] drm/i915/guc: Update name and prototype of GuC submission related functions

i915 GuC submission is hardware interface and GuC APIs that are not user facing should be intel_guc* hence we change GuC submission related functions name prefix to intel_guc. Also changed the parameter to these functions to intel_guc struct. Suggested-by: Chris Wilson

[Intel-gfx] [RFC 3/3] drm/i915/guc: Rename i915_guc_submission.c|h to intel_guc_submission.c|h

With all component structures and functions named as intel_guc*, change the names of GuC submission source files. Signed-off-by: Sagar Arun Kamble Cc: Michal Wajdeczko Cc: Michal Winiarski Cc: Oscar Mateo

[Intel-gfx] [PATCH 1/2] drm/atomic-helper: always track connector commits, too

It's useful for syncing async connector work like link retraining. v2: Make it work (Manasi) Cc: Manasi Navare Cc: Maarten Lankhorst Cc: Ville Syrjälä Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH 2/2] drm/i915: sync dp link status checks against atomic commmits

Two bits: - check actual atomic state, the legacy stuff can only be looked at from within the atomic_commit_tail function, since it's only protected by ordering and not by any locks. - Make sure we don't wreak the work an ongoing nonblocking commit is doing. v2: We need the crtc lock too,

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Reduce the volume of the timeout message

== Series Details == Series: drm/i915/selftests: Reduce the volume of the timeout message URL : https://patchwork.freedesktop.org/series/33589/ State : success == Summary == Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 Test kms_busy:

Re: [Intel-gfx] [PATCH RFC] drm/i915: Print dmesg warn on unintended hangs

Quoting Mika Kuoppala (2017-11-10 12:20:55) > Chris Wilson writes: > > > Quoting Mika Kuoppala (2017-11-10 11:53:47) > >> We have a problem of distinguishing intended hangs > >> submitted by igt during CI/bat and hangs that are nonintended > >> happening in close

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,01/11] drm/i915: Update watermark state correctly in sanitize_watermarks

== Series Details == Series: series starting with [v3,01/11] drm/i915: Update watermark state correctly in sanitize_watermarks URL : https://patchwork.freedesktop.org/series/33595/ State : success == Summary == Series 33595v1 series starting with [v3,01/11] drm/i915: Update watermark state

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/skl: DMC firmware for skylake v1.27

== Series Details == Series: drm/i915/skl: DMC firmware for skylake v1.27 URL : https://patchwork.freedesktop.org/series/33568/ State : success == Summary == Series 33568v1 drm/i915/skl: DMC firmware for skylake v1.27 https://patchwork.freedesktop.org/api/1.0/series/33568/revisions/1/mbox/

Re: [Intel-gfx] [PATCH] Skylake DMC v1.27

On 10/11/17 11:29, Saarinen, Jani wrote: From: Saarinen, Jani From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Anusha Srivatsa Adding the pull request as part of the cover letter. Sending from personal account since getting the shared repo is WIP. Lets run this

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Reduce the volume of the timeout message

On Fri, 2017-11-10 at 10:11 +, Chris Wilson wrote: > Originally it was anticipated that timeouts would be a rare event, and > so merit a warning that the test was incomplete. However, for igt we > keep the timeout low, and hitting the timeout is intentional. It no > longer necessitates a

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Restore the wait for idle engine after flushing interrupts

== Series Details == Series: drm/i915: Restore the wait for idle engine after flushing interrupts URL : https://patchwork.freedesktop.org/series/33593/ State : success == Summary == Series 33593v1 drm/i915: Restore the wait for idle engine after flushing interrupts

[Intel-gfx] [PATCH RFC] drm/i915: Print dmesg warn on unintended hangs

We have a problem of distinguishing intended hangs submitted by igt during CI/bat and hangs that are nonintended happening in close proximity. As we know how igt constructs a batch intended to hang the gpu, we can use this in our advantage when error state is constructed. The signature of a

Re: [Intel-gfx] [PATCH v2 5/9] drm/i915/perf: enable perf support on CNL

On 2 November 2017 at 16:29, Lionel Landwerlin wrote: > This adds new registers to the whitelist to configs emitted from userspace. > > Signed-off-by: Lionel Landwerlin > --- > drivers/gpu/drm/i915/Makefile | 3 +- >

[Intel-gfx] QtQuick/Qt5 application produces high CPU load with Intel i915

Hello, I'm running a QtQuick application using shaders on an older Intel(R) Atom(TM) CPU N270   @ 1.60GHz with Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller. My setup is   * Ubuntu 16.04 (32-bit)   * Qt 5.9.2   * Mesa: 17.4.0   * Intel i8xx, i9xx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Reduce the volume of the timeout message

== Series Details == Series: drm/i915/selftests: Reduce the volume of the timeout message URL : https://patchwork.freedesktop.org/series/33589/ State : success == Summary == Series 33589v1 drm/i915/selftests: Reduce the volume of the timeout message

Re: [Intel-gfx] [PATCH] drm/i915: Restore the wait for idle engine after flushing interrupts

Quoting Chris Wilson (2017-11-10 12:06:59) > Quoting Mika Kuoppala (2017-11-10 12:00:38) > > Just pondering here what was the key nonidleness key that > > lead to this. What raced? > > Still pondering myself. This is basically to shut CI up so the random > fails stop inflicting the confusion of

Re: [Intel-gfx] [PATCH v2] drm/i915: Move irqs enabled assertion deeper for mock breadcrumbs

Quoting Chris Wilson (2017-11-10 11:54:23) > In order to allow the mock breadcrumbs tests to run without device irqs > being enabled, move the intel_irqs_enabled() assert deeper to just > before we commit to enabling the HW irq. > > v2: Add a FIXME explaining that placing the assertion so deep is

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Restore the wait for idle engine after flushing interrupts

== Series Details == Series: drm/i915: Restore the wait for idle engine after flushing interrupts URL : https://patchwork.freedesktop.org/series/33593/ State : success == Summary == Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 Test

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915: Enable FIFO underrun reporting after initial fastset, v2.

On Fri, Nov 10, 2017 at 09:02:18AM +0100, Maarten Lankhorst wrote: > Op 09-11-17 om 18:15 schreef Ville Syrjälä: > > On Thu, Nov 09, 2017 at 05:24:57PM +0100, Maarten Lankhorst wrote: > >> The firmware may have set up the pipe correctly, but the FIFO > >> underrun and CRC interrupts are likely not

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Reduce the volume of the timeout message

On 10 November 2017 at 10:11, Chris Wilson wrote: > Originally it was anticipated that timeouts would be a rare event, and > so merit a warning that the test was incomplete. However, for igt we > keep the timeout low, and hitting the timeout is intentional. It no >

Re: [Intel-gfx] [PATCH v2 4/9] drm/i915: fix register naming

On 2 November 2017 at 16:29, Lionel Landwerlin wrote: > This name was added with the whitelisting of registers for building up OA > configs. It is contained in a range gen8 whitelist : > >addr >= RPM_CONFIG0.reg && addr <= NOA_CONFIG(8).reg > > Hence why the

[Intel-gfx] [PATCH v2] drm/i915: Move irqs enabled assertion deeper for mock breadcrumbs

In order to allow the mock breadcrumbs tests to run without device irqs being enabled, move the intel_irqs_enabled() assert deeper to just before we commit to enabling the HW irq. v2: Add a FIXME explaining that placing the assertion so deep is not ideal, but a compromise for mock breadcrumbs.

Re: [Intel-gfx] [PATCH] drm/i915: Restore the wait for idle engine after flushing interrupts

Chris Wilson writes: > So it appears that commit 5427f207852d ("drm/i915: Bump wait-times for > the final CS interrupt before parking") was a little over optimistic in > its belief that it had successfully waited for all residual activity on > the engines before

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Print dmesg warn on unintended hangs

== Series Details == Series: drm/i915: Print dmesg warn on unintended hangs URL : https://patchwork.freedesktop.org/series/33597/ State : success == Summary == Series 33597v1 drm/i915: Print dmesg warn on unintended hangs

Re: [Intel-gfx] [PATCH] drm/i915: Return early when pipes are not available

On Fri, 2017-11-10 at 15:22 +0200, Jani Nikula wrote: > On Fri, 10 Nov 2017, Mika Kahola wrote: > > > > On Thu, 2017-11-09 at 15:15 +0200, Ville Syrjälä wrote: > > > > > > On Thu, Nov 09, 2017 at 01:11:05PM +0200, Mika Kahola wrote: > > > > > > > > > > > > On Thu,

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v3,01/11] drm/i915: Update watermark state correctly in sanitize_watermarks

== Series Details == Series: series starting with [v3,01/11] drm/i915: Update watermark state correctly in sanitize_watermarks URL : https://patchwork.freedesktop.org/series/33595/ State : success == Summary == Test kms_busy: Subgroup extended-modeset-hang-oldfb-with-reset-render-c:

[Intel-gfx] [CI 7/8] drm/i915: Record the default hw state after reset upon load

Take a copy of the HW state after a reset upon module loading by executing a context switch from a blank context to the kernel context, thus saving the default hw state over the blank context image. We can then use the default hw state to initialise any future context, ensuring that each starts

[Intel-gfx] [CI 2/8] drm/i915: Force the switch to the i915->kernel_context

In the next few patches, we will have a hard requirement that we emit a context-switch to the perma-pinned i915->kernel_context (so that we can save the HW state using that context-switch). As the first context itself may be classed as a kernel context, we want to be explicit in our comparison.

[Intel-gfx] [CI 4/8] drm/i915: Move intel_init_clock_gating() to i915_gem_init()

Despite its name intel_init_clock_gating applies both display clock gating workarounds; GT mmio workarounds and the occasional GT power context workaround. Worse, sometimes it includes a context register workaround which we need to apply before we record the default HW state for all contexts.

[Intel-gfx] [CI 3/8] drm/i915: Move GT powersaving init to i915_gem_init()

GT powersaving is tightly coupled to the request infrastructure. To avoid complications with the order of initialisation in the next patch (where we want to send requests to hw during GEM init) move the powersaving initialisation into the purview of i915_gem_init(). Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH v2 1/9] drm/i915/perf: complete whitelisting for OA programming on HSW

On 2 November 2017 at 16:29, Lionel Landwerlin wrote: > We were missing some registers and also can name one for which we only had > the offset. > > Signed-off-by: Lionel Landwerlin Reviewed-by: Matthew Auld

Re: [Intel-gfx] [PATCH RFC] drm/i915: Print dmesg warn on unintended hangs

On Fri, Nov 10, 2017 at 02:49:25PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > Quoting Mika Kuoppala (2017-11-10 12:20:55) > >> Chris Wilson writes: > >> > >> > Quoting Mika Kuoppala (2017-11-10 11:53:47) > >> >> We have a

Re: [Intel-gfx] [PATCH] drm/i915: Return early when pipes are not available

On Fri, 10 Nov 2017, Mika Kahola wrote: > On Thu, 2017-11-09 at 15:15 +0200, Ville Syrjälä wrote: >> On Thu, Nov 09, 2017 at 01:11:05PM +0200, Mika Kahola wrote: >> > >> > On Thu, 2017-11-09 at 11:01 +, Chris Wilson wrote: >> > > >> > > Quoting Mika Kahola (2017-11-09

[Intel-gfx] [PATCH] drm/i915: Initialize audio only when display is present

At least in Coffee Lake it happens that we start initiliazing audio when no display is connected. This was discovered by CI when running IGT test case drv_module_reload --r basic-no-display The issue here is that the 'intel_device_info_runtime_init()' sets num_pipes to 0 but before this happens

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Initialize audio only when display is present

== Series Details == Series: drm/i915: Initialize audio only when display is present URL : https://patchwork.freedesktop.org/series/33601/ State : success == Summary == Series 33601v1 drm/i915: Initialize audio only when display is present

[Intel-gfx] [CI 1/8] drm/i915: Define an engine class enum for the uABI

From: Tvrtko Ursulin We want to be able to report back to userspace details about an engine's class, and in return for userspace to be able to request actions regarding certain classes of engines. To isolate the uABI from any variations between hw generations, we define

[Intel-gfx] [CI 5/8] drm/i915: Inline intel_modeset_gem_init()

intel_modeset_gem_init() now only sets up the legacy overlay, so let's remove the function and call the setup directly during driver load. This should help us find a better point in the initialisation sequence for it later. Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [CI 8/8] drm/i915: Stop caching the "golden" renderstate

As we now record the default HW state and so only emit the "golden" renderstate once to prepare the HW, there is no advantage in keeping the renderstate batch around as it will never be used again. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [CI 6/8] drm/i915: Mark the context state as dirty/written

In the next few patches, we will want to both copy out of the context image and write a valid image into a new context. To be completely safe, we should then couple in our domain tracking to ensure that we don't have any issues with stale data remaining in unwanted cachelines. Historically, we

Re: [Intel-gfx] [PATCH 1/2] lib/rbtree, drm/mm: Add rbtree_replace_node_cached()

On 2017-11-09 13:24, Chris Wilson wrote: Add a variant of rbtree_replace_node() that maintains the leftmost cached of struct rbtree_root_cached when replacing nodes within the rbtree. As drm_mm is the only rb_replace_node() being used on an interval tree, the mistake looks fairly

Re: [Intel-gfx] [PATCH] i915: pm: Be less agressive with clockfreq changes on Bay Trail

Hi, On 10-11-17 15:56, Chris Wilson wrote: Quoting Hans de Goede (2017-11-09 18:51:01) Bay Trail devices are known to hang when changing the frequency often, this is discussed in great length in: https://bugzilla.kernel.org/show_bug.cgi?id=109051 Commit 6067a27d1f01 ("drm/i915: Avoid tweaking

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Move irqs enabled assertion deeper for mock breadcrumbs (rev2)

== Series Details == Series: drm/i915: Move irqs enabled assertion deeper for mock breadcrumbs (rev2) URL : https://patchwork.freedesktop.org/series/33328/ State : success == Summary == Test kms_busy: Subgroup extended-modeset-hang-oldfb-with-reset-render-c: dmesg-warn

[Intel-gfx] [PATCH] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2

assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier even though it gets unregistered on (runtime) suspend, this is caused by a race happening under the following circumstances: intel_runtime_pm_put does: atomic_dec(_priv->pm.wakeref_count);

[Intel-gfx] [PATCH 0/1] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2

Hi, This is a resend of the first patch of my 3 patch "drm/i915: Misc. PMIC bus access notifier fixes" series for some reason I'm not having any luck with the CI with this series (I believe I'm just hitting glitches) so I'm splitting it up and see if I can see which patch (if any) makes the CI

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't use GEN6_RC_VIDEO_FREQ on gen10+

== Series Details == Series: drm/i915: Don't use GEN6_RC_VIDEO_FREQ on gen10+ URL : https://patchwork.freedesktop.org/series/33608/ State : success == Summary == Series 33608v1 drm/i915: Don't use GEN6_RC_VIDEO_FREQ on gen10+

[Intel-gfx] [PATCH] drm/i915/selftests: Initialise mock_i915->mm.obj_lock

lockdep spotted that the mock tests were using the i915->mm.obj_lock without first initialiasing it: >[ 1303.217043] [IGT] drv_selftest: starting subtest mock_objects <4>[ 1303.240898] Setting dangerous option mock_selftests - tainting kernel <6>[ 1303.253665] i915: Performing mock selftests with

[Intel-gfx] [PATCH v3] drm/i915: Define an engine class enum for the uABI

From: Tvrtko Ursulin We want to be able to report back to userspace details about an engine's class, and in return for userspace to be able to request actions regarding certain classes of engines. To isolate the uABI from any variations between hw generations, we define

Re: [Intel-gfx] [PATCH v3 01/11] drm/i915: Update watermark state correctly in sanitize_watermarks

On Fri, Nov 10, 2017 at 12:34:53PM +0100, Maarten Lankhorst wrote: > We no longer use intel_crtc->wm.active for watermarks any more, > which was incorrect. But this uncovered a bug in sanitize_watermarks(), > which meant that we wrote the correct watermarks, but the next > update would still use

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Initialise mock_i915->mm.obj_lock

On 10/11/2017 15:19, Chris Wilson wrote: lockdep spotted that the mock tests were using the i915->mm.obj_lock without first initialiasing it: [ 1303.217043] [IGT] drv_selftest: starting subtest mock_objects <4>[ 1303.240898] Setting dangerous option mock_selftests - tainting kernel <6>[

Re: [Intel-gfx] [PATCH v3 03/11] drm/i915: Check boolean options in intel_pipe_config_compare with its own macro

On Fri, Nov 10, 2017 at 12:34:55PM +0100, Maarten Lankhorst wrote: > Add PIPE_CONF_CHECK_BOOL for boolean options, which are printed with yesno. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Daniel Vetter > --- >

Re: [Intel-gfx] [PATCH v3 09/11] drm/i915: Handle ips_enabled in fastset, v2.

On Fri, Nov 10, 2017 at 12:35:01PM +0100, Maarten Lankhorst wrote: > pre_plane_disable and post_plane_enable handle set ips correctly, > but if there is no modeset and the ips_enabled value changes > because of force disabling for crc, or hw state readout, then we > don't toggle ips correctly.

Re: [Intel-gfx] [PATCH v3 06/11] drm/i915: Handle locking better in i915_sink_crc.

On Fri, Nov 10, 2017 at 02:13:39PM +0100, Daniel Vetter wrote: > On Fri, Nov 10, 2017 at 12:34:58PM +0100, Maarten Lankhorst wrote: > > Lock the bare minimum, instead of the entire world, and > > use interruptible locking because we can. > > > > Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH] drm/i915: Kerneldoc typo s/rps/rps_client/

On 9 November 2017 at 14:06, Chris Wilson wrote: > Update the kerneldoc parameter name to match the real parameter name. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld

Re: [Intel-gfx] [PATCH v3 10/11] drm/i915: Enable FIFO underrun reporting after initial fastset, v3.

On Fri, Nov 10, 2017 at 12:35:02PM +0100, Maarten Lankhorst wrote: > The firmware may have set up the pipe correctly, but the FIFO > underrun and CRC interrupts are likely not enabled. > > This resulted in debugfs_test.read_all_entries failing on haswell, > because of a timeout when reading the

Re: [Intel-gfx] [PATCH] i915: pm: Be less agressive with clockfreq changes on Bay Trail

Quoting Hans de Goede (2017-11-09 18:51:01) > Bay Trail devices are known to hang when changing the frequency often, > this is discussed in great length in: > https://bugzilla.kernel.org/show_bug.cgi?id=109051 > > Commit 6067a27d1f01 ("drm/i915: Avoid tweaking evaluation thresholds > on Baytrail

Re: [Intel-gfx] [PATCH] drm/i915: Initialize audio only when display is present

Quoting Mika Kahola (2017-11-10 14:06:38) > On Fri, 2017-11-10 at 13:37 +, Chris Wilson wrote: > > Quoting Mika Kahola (2017-11-10 13:31:54) > > > > > > At least in Coffee Lake it happens that we start initiliazing audio > > > when > > > no display is connected. This was discovered by CI when

[Intel-gfx] [PATCH v3] drm/i915: Define an engine class enum for the uABI

From: Tvrtko Ursulin We want to be able to report back to userspace details about an engine's class, and in return for userspace to be able to request actions regarding certain classes of engines. To isolate the uABI from any variations between hw generations, we define

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

Hi Dave, the first batch of i915 fixes for drm-next/v4.15. BR, Jani. The following changes since commit 8a6fb5b5823d863b07f670dc9e791d4622d5b7e9: Merge branch 'drm-next-4.15' of git://people.freedesktop.org/~agd5f/linux into drm-next (2017-11-06 16:18:59 +1000) are available in the git

Re: [Intel-gfx] [PATCH] drm/i915: Initialize audio only when display is present

Quoting Mika Kahola (2017-11-10 13:31:54) > At least in Coffee Lake it happens that we start initiliazing audio when > no display is connected. This was discovered by CI when running IGT test > case > > drv_module_reload --r basic-no-display > > The issue here is that the

Re: [Intel-gfx] [PATCH] drm/i915: Return early when pipes are not available

HI, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Mika Kahola > Sent: perjantai 10. marraskuuta 2017 15.35 > To: Jani Nikula ; Ville Syrjälä > > Cc:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2

== Series Details == Series: drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2 URL : https://patchwork.freedesktop.org/series/33609/ State : success == Summary == Series 33609v1 drm/i915: Fix false-positive assert_rpm_wakelock_held in

  1   2   3   >