[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest

== Series Details == Series: drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest URL : https://patchwork.freedesktop.org/series/40851/ State : success == Summary == Series 40851v1 drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/breadcrumbs: Keep the fake irq armed across reset (rev2)

== Series Details == Series: drm/i915/breadcrumbs: Keep the fake irq armed across reset (rev2) URL : https://patchwork.freedesktop.org/series/40825/ State : failure == Summary == Possible new issues: Test kms_cursor_crc: Subgroup cursor-128x128-dpms: fail

[Intel-gfx] [PATCH] drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest

Four drm_mm_node are used to reserve guest ggtt space, but some of them may aren't initialized and used in intel_vgt_balloon(), so these unused drm_mm_node couldn't be removed through drm_mm_remove_node(). Fixes: ff8f797557c7("drm/i915: return the correct usable aperture size under gvt

Re: [Intel-gfx] [igt-dev] [RFC i-g-t] intel-gpu-top: Rewrite the tool to be safe to use

>Среда, 28 марта 2018, 21:30 +03:00 от Tvrtko Ursulin : > >+static struct engines *discover_engines(void) > { >-uint32_t devid = pci_dev->device_id; >-uint16_t gcfgc; >+const char *sysfs_root = "/sys/devices/i915/events"; Just a question. I think, I have Linux 4.15.11

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Only warn for might_sleep() before a slow wait_for_register

== Series Details == Series: drm/i915: Only warn for might_sleep() before a slow wait_for_register URL : https://patchwork.freedesktop.org/series/40823/ State : failure == Summary == Possible new issues: Test kms_cursor_crc: Subgroup cursor-128x128-dpms: fail

Re: [Intel-gfx] [PATCH 9/9] drm/i915/execlists: Report GPU rendering as IO activity to cpufreq.

Quoting Chris Wilson (2018-03-29 02:01:37) > Quoting Francisco Jerez (2018-03-29 01:32:07) > > Chris Wilson writes: > > > + else > > > + execlists_end(execlists); > > > } else { >

Re: [Intel-gfx] [PATCH 9/9] drm/i915/execlists: Report GPU rendering as IO activity to cpufreq.

Quoting Francisco Jerez (2018-03-29 01:32:07) > Chris Wilson writes: > > > Quoting Chris Wilson (2018-03-28 20:20:19) > >> Quoting Francisco Jerez (2018-03-28 19:55:12) > >> > Hi Chris, > >> > > >> [snip] > >> > That said, it wouldn't hurt to call each of them once per

Re: [Intel-gfx] [PATCH 9/9] drm/i915/execlists: Report GPU rendering as IO activity to cpufreq.

Chris Wilson writes: > Quoting Chris Wilson (2018-03-28 20:20:19) >> Quoting Francisco Jerez (2018-03-28 19:55:12) >> > Hi Chris, >> > >> [snip] >> > That said, it wouldn't hurt to call each of them once per sequence of >> > overlapping requests. Do you want me to

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/execlists: Consistent seqno reporting in GEM_TRACE

== Series Details == Series: drm/i915/execlists: Consistent seqno reporting in GEM_TRACE URL : https://patchwork.freedesktop.org/series/40821/ State : failure == Summary == Possible new issues: Test drv_selftest: Subgroup live_hangcheck: pass -> DMESG-FAIL

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v3,01/10] drm: Add DP PSR2 sink enable bit

== Series Details == Series: series starting with [v3,01/10] drm: Add DP PSR2 sink enable bit URL : https://patchwork.freedesktop.org/series/40839/ State : warning == Summary == Series 40839v1 series starting with [v3,01/10] drm: Add DP PSR2 sink enable bit

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,01/10] drm: Add DP PSR2 sink enable bit

== Series Details == Series: series starting with [v3,01/10] drm: Add DP PSR2 sink enable bit URL : https://patchwork.freedesktop.org/series/40839/ State : warning == Summary == $ dim checkpatch origin/drm-tip 83dbb7136992 drm: Add DP PSR2 sink enable bit 36672bef768d drm: Add DP last

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Avoid sleeping inside per-engine reset

== Series Details == Series: drm/i915: Avoid sleeping inside per-engine reset URL : https://patchwork.freedesktop.org/series/40838/ State : success == Summary == Series 40838v1 drm/i915: Avoid sleeping inside per-engine reset

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/psr: Control PSR interrupts via debugfs

On Wed, 2018-03-28 at 17:37 +, Pandiyan, Dhinakaran wrote: > > > On Wed, 2018-03-28 at 13:28 +0300, Ville Syrjälä wrote: > > On Tue, Mar 27, 2018 at 06:33:11PM +, Pandiyan, Dhinakaran wrote: > > > On Tue, 2018-03-27 at 13:24 +0300, Ville Syrjälä wrote: > > > > On Mon, Mar 26, 2018 at

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/15] drm/i915/execlists: Refactor out complete_preempt_context()

Quoting Patchwork (2018-03-29 00:01:23) > == Series Details == > > Series: series starting with [01/15] drm/i915/execlists: Refactor out > complete_preempt_context() > URL : https://patchwork.freedesktop.org/series/40834/ > State : failure > > == Summary == > > Series 40834v1 series starting

[Intel-gfx] ✓ Fi.CI.BAT: success for ICL PLLs, DP/HDMI and misc display (rev5)

== Series Details == Series: ICL PLLs, DP/HDMI and misc display (rev5) URL : https://patchwork.freedesktop.org/series/38737/ State : success == Summary == Series 38737v5 ICL PLLs, DP/HDMI and misc display https://patchwork.freedesktop.org/api/1.0/series/38737/revisions/5/mbox/ Possible

Re: [Intel-gfx] [PATCH 9/9] drm/i915/execlists: Report GPU rendering as IO activity to cpufreq.

Quoting Chris Wilson (2018-03-28 20:20:19) > Quoting Francisco Jerez (2018-03-28 19:55:12) > > Hi Chris, > > > [snip] > > That said, it wouldn't hurt to call each of them once per sequence of > > overlapping requests. Do you want me to call them from > > execlists_set/clear_active() themselves

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for ICL PLLs, DP/HDMI and misc display (rev5)

== Series Details == Series: ICL PLLs, DP/HDMI and misc display (rev5) URL : https://patchwork.freedesktop.org/series/38737/ State : warning == Summary == $ dim checkpatch origin/drm-tip faa292edccbc drm/i915/icl: Don't set pipe CSC/Gamma in PLANE_COLOR_CTL 890b377784c4 drm/i915/icl: add

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/15] drm/i915/execlists: Refactor out complete_preempt_context()

== Series Details == Series: series starting with [01/15] drm/i915/execlists: Refactor out complete_preempt_context() URL : https://patchwork.freedesktop.org/series/40834/ State : failure == Summary == Series 40834v1 series starting with [01/15] drm/i915/execlists: Refactor out

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/15] drm/i915/execlists: Refactor out complete_preempt_context()

== Series Details == Series: series starting with [01/15] drm/i915/execlists: Refactor out complete_preempt_context() URL : https://patchwork.freedesktop.org/series/40834/ State : warning == Summary == $ dim checkpatch origin/drm-tip a016c0c4e8a6 drm/i915/execlists: Refactor out

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: warn only once about ddi translation table missing

== Series Details == Series: drm/i915: warn only once about ddi translation table missing URL : https://patchwork.freedesktop.org/series/40833/ State : success == Summary == Series 40833v1 drm/i915: warn only once about ddi translation table missing

[Intel-gfx] [PATCH v3 04/10] drm/i915/psr: Tie PSR2 support to Y coordinate requirement

Although i915 don't implement aux sync frame through tests was findout that pannels can do selective update when the y-coordinate is also included in SDP, that is why it is required to run PSR2 in i915. So moving to only one place the sink requirements that the actual driver needs to enable PSR2.

[Intel-gfx] [PATCH v3 09/10] drm/i915/psr: Set DPCD PSR2 enable bit when needed

In the 2 eDP1.4a pannels tested set or not set bit have no effect but is better set it and comply with specification. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan Reviewed-by: Rodrigo Vivi --- v3:

[Intel-gfx] [PATCH v3 10/10] drm/i915/debugfs: Print sink PSR status

IGT tests could be improved with sink status, knowing for sure that hardware have activate or exit PSR. Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi Signed-off-by: José Roberto de Souza --- v3: rebased

[Intel-gfx] [PATCH v3 08/10] drm/i915/psr: Cache sink synchronization latency

This value do not change overtime so better cache it than fetch it every PSR enable. Cc: Dhinakaran Pandiyan Reviewed-by: Rodrigo Vivi Signed-off-by: José Roberto de Souza --- v3: rebased

[Intel-gfx] [PATCH v3 06/10] drm/i915/psr: Do not override PSR2 sink support

Sink can support our PSR2 requirements but userspace can request a resolution that PSR2 hardware do not support, in this case it was overwritten the PSR2 sink support. Adding another flag here, this way if requested resolution changed to a value that PSR2 hardware can handle, PSR2 can be enabled.

[Intel-gfx] [PATCH v3 01/10] drm: Add DP PSR2 sink enable bit

To comply with eDP1.4a this bit should be set when enabling PSR2. Signed-off-by: José Roberto de Souza Reviewed-by: Rodrigo Vivi --- v3: rebased include/drm/drm_dp_helper.h | 1 + 1 file changed, 1 insertion(+) diff --git

[Intel-gfx] [PATCH v3 07/10] drm/i915/psr: Use PSR2 macro for PSR2

Cosmetic change. Reviewed-by: Rodrigo Vivi Signed-off-by: José Roberto de Souza --- v3: rebased drivers/gpu/drm/i915/i915_reg.h | 3 ++- drivers/gpu/drm/i915/intel_psr.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH v3 03/10] drm/i915/psr: Nuke aux frame sync

eDP spec states that aux frame is required to do PSR2 selective update but i915 don't fully implement it. It sends the aux frame sync messages but the value is always zero as the GTC is not enabled in driver. Through tests was findout that pannels can do selective update when the y-coordinate is

[Intel-gfx] [PATCH v3 05/10] drm/i915/psr/cnl: Enable Y-coordinate support in source

For Geminilake and Cannonlake+ the Y-coordinate support must be enabled in PSR2_CTL too. Spec: 7713 and 7720 Cc: Dhinakaran Pandiyan Reviewed-by: Rodrigo Vivi Signed-off-by: José Roberto de Souza --- v3: rebased

[Intel-gfx] [PATCH v3 02/10] drm: Add DP last received PSR SDP VSC register and bits

This is a register to help debug what is in the last SDP VSC packet revived by sink. Signed-off-by: José Roberto de Souza Reviewed-by: Rodrigo Vivi --- v3: rebased include/drm/drm_dp_helper.h | 9 + 1 file changed, 9 insertions(+) diff

Re: [Intel-gfx] [CI] drm/i915: Avoid sleeping inside per-engine reset

Quoting Chris Wilson (2018-03-28 23:30:56) > Only sleep and repeat when asked for a full device reset (ALL_ENGINES) > and avoid using sleeping waits when asked for a per-engine reset. The > goal is to be able to use a per-engine reset from hardirq/softirq/timer > context. A consequence is that our

[Intel-gfx] [CI] drm/i915: Avoid sleeping inside per-engine reset

Only sleep and repeat when asked for a full device reset (ALL_ENGINES) and avoid using sleeping waits when asked for a per-engine reset. The goal is to be able to use a per-engine reset from hardirq/softirq/timer context. A consequence is that our individual wait timeouts are a thousand times

Re: [Intel-gfx] [PATCH v1] drm/i915/gen11: Preempt-to-idle support in execlists.

Quoting Lis, Tomasz (2018-03-28 17:06:58) > > > On 2018-03-28 01:27, Chris Wilson wrote: > > Quoting Tomasz Lis (2018-03-27 16:17:59) > >> The patch adds support of preempt-to-idle requesting by setting a proper > >> bit within Execlist Control Register, and receiving preemption result from > >>

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/guc: enable guc interrupts unconditionally in uc_resume

== Series Details == Series: series starting with [CI,1/2] drm/i915/guc: enable guc interrupts unconditionally in uc_resume URL : https://patchwork.freedesktop.org/series/40832/ State : success == Summary == Series 40832v1 series starting with [CI,1/2] drm/i915/guc: enable guc interrupts

[Intel-gfx] [PATCH 8/8] drm/i915/icl: Fix the DP Max Voltage for ICL

From: Manasi Navare On clock recovery this function is called to find out the max voltage swing level that we could go. However gen 9 functions use the old buffer translation tables to figure that out. ICL uses different set of tables for eDP and DP for both Combo and

[Intel-gfx] [PATCH 5/8] drm/i915/icl: compute the combo PHY (DPLL) DP registers

Just use the hardcoded tables provided by our spec. v2: Rebase. v3: Clarify that 38.4 uses the 19.2 table (James). Reviewed-by: James Ausmus Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_dpll_mgr.c | 87

[Intel-gfx] [PATCH 1/8] drm/i915/icl: Don't set pipe CSC/Gamma in PLANE_COLOR_CTL

From: James Ausmus These fields have been deprecated and moved in ICL+. Stop setting the bits. They have moved to GAMMA_MODE and CSC_MODE, respectively. This patch is just to stop incorrectly setting bits in PLANE_COLOR_CTL while we're waiting for the new replacement

[Intel-gfx] [PATCH 7/8] drm/i915/icl: Implement voltage swing programming sequence for Combo PHY DDI

From: Manasi Navare This is an important part of the DDI initalization as well as for changing the voltage during DisplayPort link training. The Voltage swing seqeuence is similar to Cannonlake. However it has different register definitions and hence it makes sense to

[Intel-gfx] [PATCH 3/8] drm/i915/icl: add basic support for the ICL clocks

This commit introduces the definitions for the ICL clocks and adds the basic functions to the shared DPLL framework. It adds code for the Enable and Disable sequences for some PLLs, but it does not have the code to compute the actual PLL values, which are marked as TODO comments and should be

[Intel-gfx] [PATCH 4/8] drm/i915/icl: compute the combo PHY (DPLL) HDMI registers

HDMI mode DPLL programming on ICL is the same as CNL, so just reuse the CNL code. v2: - Properly detect HDMI crtcs. - Rebase after changes to the cnl function (clock * 1000). v3: - Add a comment to clarify why we treat 38.4 as 19.2 (James). Reviewed-by: James Ausmus

[Intel-gfx] [PATCH 6/8] drm/i915/icl: compute the MG PLL registers

This implements the "MG PLL Programming" sequence from our spec. The biggest problem was that the spec assumes real numbers, so we had to adjust some numbers and alculations due to the fact that the Kernel prefers to deal with integers. I recommend grabbing some coffee, a pen and paper before

[Intel-gfx] [PATCH 2/8] drm/i915/icl: add definitions for the ICL PLL registers

There's a lot of code for the PLL enabling, so let's first only introduce the register definitions in order to make patch reviewing a little easier. v2: Coding style (Jani). v3: Preparation for upstreaming. v4: Fix MG_CLKTOP2_CORECLKCTL1 address and random typos (James). Cc: James Ausmus

[Intel-gfx] [PATCH 0/8] ICL PLLs, DP/HDMI and misc display, v2

We already merged some patches from this series, so this new version is smaller. Some of the patches here already have R-B tags but they depend on non-reviewed patches. Only patches 2, 3 and 7 need reviews. I don't think I can qualify as a reviewer for patch 7 anymore due to how much I changed

Re: [Intel-gfx] [PATCH 10/15] drm/i915: Avoid sleeping inside per-engine reset

On 28/03/18 14:52, Chris Wilson wrote: Quoting Michel Thierry (2018-03-28 22:47:55) On 28/03/18 14:18, Chris Wilson wrote: @@ -2094,7 +2095,7 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv, unsigned engine_mask) int retry; int ret; - might_sleep(); +

Re: [Intel-gfx] [PATCH 10/15] drm/i915: Avoid sleeping inside per-engine reset

Quoting Michel Thierry (2018-03-28 22:47:55) > On 28/03/18 14:18, Chris Wilson wrote: > > @@ -2094,7 +2095,7 @@ int intel_gpu_reset(struct drm_i915_private > > *dev_priv, unsigned engine_mask) > > int retry; > > int ret; > > > > - might_sleep(); > > +

Re: [Intel-gfx] [PATCH v5 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

On 3/28/2018 2:39 AM, Tvrtko Ursulin wrote: On 27/03/2018 23:14, Yunwei Zhang wrote: L3Bank could be fused off in hardware for debug purpose, and it is possible that subslice is enabled while its corresponding L3Bank pairs are disabled. In such case, if MCR packet control register(0xFDC)

Re: [Intel-gfx] [PATCH 10/15] drm/i915: Avoid sleeping inside per-engine reset

On 28/03/18 14:18, Chris Wilson wrote: Only sleep and repeat when asked for a full device reset (ALL_ENGINES) and avoid using sleeping waits when asked for a per-engine reset. The goal is to be able to use a per-engine reset from hardirq/softirq/timer context. A consequence is that our

Re: [Intel-gfx] [PATCH 11/15] drm/i915/execlists: Force preemption via reset on timeout

Quoting Chris Wilson (2018-03-28 22:18:53) > @@ -1221,7 +1287,7 @@ static void execlists_schedule(struct i915_request > *request, int prio) > > if (prio > engine->execlists.queue_priority && > i915_sw_fence_done(_to_request(pt)->submit)) > -

[Intel-gfx] [PATCH 07/15] drm/i915/breadcrumbs: Keep the fake irq armed across reset

Instead of synchronously cancelling the timer and re-enabling it inside the reset callbacks, keep the timer enabled and let it die on its next wakeup if no longer required. This allows intel_engine_reset_breadcrumbs() to be used from an atomic (timer/softirq) context such as required for resetting

[Intel-gfx] [PATCH 10/15] drm/i915: Avoid sleeping inside per-engine reset

Only sleep and repeat when asked for a full device reset (ALL_ENGINES) and avoid using sleeping waits when asked for a per-engine reset. The goal is to be able to use a per-engine reset from hardirq/softirq/timer context. A consequence is that our individual wait timeouts are a thousand times

[Intel-gfx] [PATCH 11/15] drm/i915/execlists: Force preemption via reset on timeout

Install a timer when trying to preempt on behalf of an important context such that if the active context does not honour the preemption request within the desired timeout, then we reset the GPU to allow the important context to run. v2: Install the timer on scheduling the preempt request; long

[Intel-gfx] [PATCH 09/15] drm/i915: Stop parking the signaler around reset

We cannot call kthread_park() from softirq context, so let's avoid it entirely during the reset. We wanted to suspend the signaler so that it would not mark a request as complete at the same time as we marked it as being in error. Instead of parking the signaling, stop the engine from advancing so

[Intel-gfx] [PATCH 04/15] drm/i915/execlists: Flush pending preemption events during reset

Catch up with the inflight CSB events, after disabling the tasklet before deciding which request was truly guilty of hanging the GPU. v2: Restore checking of use_csb_mmio on every loop, don't forget old vgpu. Signed-off-by: Chris Wilson Cc: Michał Winiarski

[Intel-gfx] [PATCH 05/15] drm/i915/selftests: Add basic sanitychecks for execlists

Before adding a new feature to execlists submission, we should endeavour to cover the baseline behaviour with selftests. So start the ball rolling. Signed-off-by: Chris Wilson Cc: Michał Winiarski CC: Michel Thierry

[Intel-gfx] [PATCH 03/15] drm/i915: Split execlists/guc reset prepartions

In the next patch, we will make the execlists reset prepare callback take into account preemption by flushing the context-switch handler. This is not applicable to the GuC submission backend, so split the two into their own backend callbacks. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 15/15] drm/i915: Allow user control over preempt timeout on the important context

EGL_NV_realtime_priority? Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c| 22 drivers/gpu/drm/i915/i915_gem_context.h| 13 + drivers/gpu/drm/i915/i915_request.c| 8 ++- drivers/gpu/drm/i915/intel_lrc.c |

[Intel-gfx] [PATCH 14/15] drm/i915: Use a preemption timeout to enforce interactivity

Use a liberal timeout of 20ms to ensure that the rendering for an interactive pageflip is started in a timely fashion, and that user interaction is not blocked by GPU, or CPU, hogs. This is at the cost of resetting whoever was blocking the preemption, likely leading to that context/process being

[Intel-gfx] [PATCH 06/15] drm/i915: Only warn for might_sleep() before a slow wait_for_register

As intel_wait_for_register_fw() may use, and if successful only use, a busy-wait loop, the might_sleep() warning is a little over-zealous. Restrict it to a might_sleep_if() a slow timeout is specified (and so the caller authorises use of a usleep). Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 13/15] drm/i915/preemption: Select timeout when scheduling

The choice of preemption timeout is determined by the context from which we trigger the preemption, as such allow the caller to specify the desired timeout. Effectively the other choice would be to use the shortest timeout along the dependency chain. However, given that we would have already

[Intel-gfx] [PATCH 12/15] drm/i915/execlists: Try preempt-reset from softirq context

When circumstances allow, trying resetting the engine directly from the preemption timeout handler. As this is softirq context, we have to be careful both not to sleep and not to spin on anything we may be interrupting (e.g. the submission tasklet). Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 08/15] drm/i915: Combine tasklet_kill and tasklet_disable

Ideally, we want to atomically flush and disable the tasklet before resetting the GPU. At present, we rely on being the only part to touch our tasklet and serialisation of the reset process to ensure that we can suspend the tasklet from the mix of reset/wedge pathways. In this patch, we move the

[Intel-gfx] [PATCH 01/15] drm/i915/execlists: Refactor out complete_preempt_context()

As a complement to inject_preempt_context(), follow up with the function to handle its completion. This will be useful should we wish to extend the duties of the preempt-context for execlists. Signed-off-by: Chris Wilson Cc: Jeff McGee Cc: Michał

[Intel-gfx] [PATCH 02/15] drm/i915: Move engine reset prepare/finish to backends

In preparation to more carefully handling incomplete preemption during reset by execlists, we move the existing code wholesale to the backends under a couple of new reset vfuncs. Signed-off-by: Chris Wilson Cc: Michał Winiarski CC: Michel

[Intel-gfx] Sleepless per-engine resests

The original goal for per-engine reset was to allow them from irq context for the purpose of implementing a fast watchdog. However, since we haven't been using them from even softirq context, we have accumulated a number of sleeps and synchronous waits. With the desire for a fast reset to unblock

Re: [Intel-gfx] [PATCH] drm/i915: warn only once about ddi translation table missing

Quoting Michel Thierry (2018-03-28 22:03:04) > It's not like it will magically appear or disappear ;) You know the quote, "With an infinite amount of spam, we get Shakespeare." -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH] drm/i915: warn only once about ddi translation table missing

It's not like it will magically appear or disappear ;) Signed-off-by: Michel Thierry Cc: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ddi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Intel-gfx] [CI 1/2] drm/i915/guc: enable guc interrupts unconditionally in uc_resume

Probably lost while rebasing commit eacd8391f977 ("drm/i915/guc: Keep GuC interrupts enabled when using GuC"). Not really needed since i915_gem_init_hw is called before uc_resume, but it brings symmetry to uc_suspend. Signed-off-by: Michel Thierry Cc: Michał Winiarski

[Intel-gfx] [CI 2/2] HAX enable GuC submission for CI

From: Michal Wajdeczko Stolen from... Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Add basic sanitychecks for execlists

== Series Details == Series: drm/i915/selftests: Add basic sanitychecks for execlists URL : https://patchwork.freedesktop.org/series/40805/ State : success == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-onoff:

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Support for Guc responses and requests (rev5)

Quoting Patchwork (2018-03-28 09:22:48) > == Series Details == > > Series: drm/i915/guc: Support for Guc responses and requests (rev5) > URL : https://patchwork.freedesktop.org/series/28393/ > State : failure > > == Summary == > > Possible new issues: > > Test debugfs_test: >

Re: [Intel-gfx] [PATCH] drm/i915: Only warn for might_sleep() before a slow wait_for_register

On Wed, 2018-03-28 at 20:13 +0100, Chris Wilson wrote: > Quoting Pandiyan, Dhinakaran (2018-03-28 20:01:40) > > > > On Wed, 2018-03-28 at 18:53 +0100, Chris Wilson wrote: > > > As intel_wait_for_register_fw() may use, and if successful only use, a > > > busy-wait loop, the might_sleep()

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/execlists: Reset ring registers on rebinding contexts

Quoting Patchwork (2018-03-28 08:07:45) > == Series Details == > > Series: drm/i915/execlists: Reset ring registers on rebinding contexts > URL : https://patchwork.freedesktop.org/series/40763/ > State : failure > > == Summary == > > Possible new issues: > > Test kms_flip: >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/breadcrumbs: Keep the fake irq armed across reset (rev2)

== Series Details == Series: drm/i915/breadcrumbs: Keep the fake irq armed across reset (rev2) URL : https://patchwork.freedesktop.org/series/40825/ State : success == Summary == Series 40825v2 drm/i915/breadcrumbs: Keep the fake irq armed across reset

Re: [Intel-gfx] [PATCH 9/9] drm/i915/execlists: Report GPU rendering as IO activity to cpufreq.

Quoting Francisco Jerez (2018-03-28 19:55:12) > Hi Chris, > [snip] > That said, it wouldn't hurt to call each of them once per sequence of > overlapping requests. Do you want me to call them from > execlists_set/clear_active() themselves when bit == EXECLISTS_ACTIVE_USER, > or at each callsite

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

Hi Dave, Here's a lonely fix for -next, please pull at your convenience. drm-misc-next-fixes-2018-03-28: UABI: - Mask mode type garbage from userspace (Ville) Cc: Ville Syrjälä Cheers, Sean The following changes since commit

Re: [Intel-gfx] [PATCH] drm/i915: Only warn for might_sleep() before a slow wait_for_register

Quoting Pandiyan, Dhinakaran (2018-03-28 20:01:40) > > On Wed, 2018-03-28 at 18:53 +0100, Chris Wilson wrote: > > As intel_wait_for_register_fw() may use, and if successful only use, a > > busy-wait loop, the might_sleep() warning is a little over-zealous. > > Restrict it to a might_sleep_if() a

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only warn for might_sleep() before a slow wait_for_register

== Series Details == Series: drm/i915: Only warn for might_sleep() before a slow wait_for_register URL : https://patchwork.freedesktop.org/series/40823/ State : success == Summary == Series 40823v1 drm/i915: Only warn for might_sleep() before a slow wait_for_register

Re: [Intel-gfx] [PATCH 9/9] drm/i915/execlists: Report GPU rendering as IO activity to cpufreq.

Hi Chris, Chris Wilson writes: > Quoting Francisco Jerez (2018-03-28 07:38:45) >> This allows cpufreq governors to realize when the system becomes >> non-CPU-bound due to GPU rendering activity, which will cause the >> intel_pstate LP controller to behave more

Re: [Intel-gfx] [PATCH] drm/i915: Only warn for might_sleep() before a slow wait_for_register

On Wed, 2018-03-28 at 18:53 +0100, Chris Wilson wrote: > As intel_wait_for_register_fw() may use, and if successful only use, a > busy-wait loop, the might_sleep() warning is a little over-zealous. > Restrict it to a might_sleep_if() a slow timeout is specified (and so > the caller authorises use

Re: [Intel-gfx] [RFC i-g-t] intel-gpu-top: Rewrite the tool to be safe to use

On 28/03/18 19:29, Tvrtko Ursulin wrote: From: Tvrtko Ursulin intel-gpu-top is a dangerous tool which can hang machines due unsafe mmio register access. This patch rewrites it to use only PMU. Only overall command streamer busyness and GPU global data such as power

Re: [Intel-gfx] [RFC i-g-t] intel-gpu-top: Rewrite the tool to be safe to use

Quoting Tvrtko Ursulin (2018-03-28 19:29:48) > From: Tvrtko Ursulin > > intel-gpu-top is a dangerous tool which can hang machines due unsafe mmio > register access. This patch rewrites it to use only PMU. > > Only overall command streamer busyness and GPU global data

[Intel-gfx] [RFC i-g-t] intel-gpu-top: Rewrite the tool to be safe to use

From: Tvrtko Ursulin intel-gpu-top is a dangerous tool which can hang machines due unsafe mmio register access. This patch rewrites it to use only PMU. Only overall command streamer busyness and GPU global data such as power and frequencies are included in this new

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Consistent seqno reporting in GEM_TRACE

== Series Details == Series: drm/i915/execlists: Consistent seqno reporting in GEM_TRACE URL : https://patchwork.freedesktop.org/series/40821/ State : success == Summary == Series 40821v1 drm/i915/execlists: Consistent seqno reporting in GEM_TRACE

[Intel-gfx] [PATCH v2] drm/i915/breadcrumbs: Keep the fake irq armed across reset

Instead of synchronously cancelling the timer and re-enabling it inside the reset callbacks, keep the timer enabled and let it die on its next wakeup if no longer required. This allows intel_engine_reset_breadcrumbs() to be used from an atomic (timer/softirq) context such as required for resetting

[Intel-gfx] [PATCH] drm/i915/breadcrumbs: Keep the fake irq armed across reset

Instead of synchronously cancelling the timer and re-enabling it inside the reset callbacks, keep the timer enabled and let it die on its next wakeup if no longer required. This allows intel_engine_reset_breadcrumbs() to be used from an atomic (timer/softirq) context such as required for resetting

[Intel-gfx] [PATCH] drm/i915: Only warn for might_sleep() before a slow wait_for_register

As intel_wait_for_register_fw() may use, and if successful only use, a busy-wait loop, the might_sleep() warning is a little over-zealous. Restrict it to a might_sleep_if() a slow timeout is specified (and so the caller authorises use of a usleep). Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Consistent seqno reporting in GEM_TRACE

Quoting Tvrtko Ursulin (2018-03-28 18:39:59) > From: Tvrtko Ursulin > > Some messages are using %d and some %x which creates confusion while > reading the traces. > > I also added: > > 1. Fence context/seqno to elsp traces - so it is easier to correlate > events.

[Intel-gfx] [PATCH] drm/i915/execlists: Consistent seqno reporting in GEM_TRACE

From: Tvrtko Ursulin Some messages are using %d and some %x which creates confusion while reading the traces. I also added: 1. Fence context/seqno to elsp traces - so it is easier to correlate events. 2. New GEM_TRACE logging to port and request cancellation

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/psr: Control PSR interrupts via debugfs

On Wed, 2018-03-28 at 13:28 +0300, Ville Syrjälä wrote: > On Tue, Mar 27, 2018 at 06:33:11PM +, Pandiyan, Dhinakaran wrote: > > On Tue, 2018-03-27 at 13:24 +0300, Ville Syrjälä wrote: > > > On Mon, Mar 26, 2018 at 06:16:22PM -0700, Dhinakaran Pandiyan wrote: > > > > Interrupts other than

Re: [Intel-gfx] [PATCH i-g-t v3] tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases

The rework looks good to me. Thanks Mika for testing this. >-Original Message- >From: Kahola, Mika >Sent: Wednesday, March 28, 2018 1:26 AM >To: Sripada, Radhakrishna ; igt- >d...@lists.freedesktop.org >Cc: intel-gfx@lists.freedesktop.org; Srivatsa, Anusha

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Use _FW variants for mmio access in GuC irq handler

On Wed, Mar 28, 2018 at 04:51:55PM +0300, Joonas Lahtinen wrote: > Quoting Daniele Ceraolo Spurio (2018-03-23 19:17:49) > > > > > > On 23/03/18 05:34, Michał Winiarski wrote: > > > We're seeing "RPM wakelock ref not held during HW access" warning > > > otherwise. And since IRQ are synced for

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Reset ring registers on rebinding contexts

Quoting Tvrtko Ursulin (2018-03-28 17:26:37) > > On 27/03/2018 22:01, Chris Wilson wrote: > > Tvrtko uncovered a fun issue with recovering from a wedge device. In his > > tests, he wedged the driver by injecting an unrecoverable hang whilst a > > batch was spinning. As we reset the gpu in the

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Reset ring registers on rebinding contexts

On 27/03/2018 22:01, Chris Wilson wrote: Tvrtko uncovered a fun issue with recovering from a wedge device. In his tests, he wedged the driver by injecting an unrecoverable hang whilst a batch was spinning. As we reset the gpu in the middle of the spinner, when resumed it would continue on from

Re: [Intel-gfx] [PATCH v2 2/2] drm/tinydrm: Make fb_dirty into a lower level hook

On Fri, Mar 23, 2018 at 05:28:03PM +0100, Noralf Trønnes wrote: > > Den 23.03.2018 16.35, skrev Ville Syrjala: > > From: Ville Syrjälä > > > > mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the > > bowels of the .atomic_enable() hook. That prevents

Re: [Intel-gfx] [PATCH] drm/i915: Add debugfs file to clear FIFO underruns.

Op 28-03-18 om 12:21 schreef Jani Nikula: > On Wed, 28 Mar 2018, Maarten Lankhorst > wrote: >> Adding a i915_fifo_underrun_reset debugfs file will make it possible >> for IGT tests to clear FIFO underrun fallout at the start of each >> subtest, and make

Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

On 3/28/2018 9:03 AM, Chris Wilson wrote: Quoting Zhang, Yunwei (2018-03-28 16:54:26) On 3/27/2018 4:13 PM, Chris Wilson wrote: Quoting Zhang, Yunwei (2018-03-27 23:49:27) On 3/27/2018 3:27 PM, Chris Wilson wrote: Quoting Yunwei Zhang (2018-03-27 23:14:16)

Re: [Intel-gfx] [PATCH v1] drm/i915/gen11: Preempt-to-idle support in execlists.

On 2018-03-28 01:27, Chris Wilson wrote: Quoting Tomasz Lis (2018-03-27 16:17:59) The patch adds support of preempt-to-idle requesting by setting a proper bit within Execlist Control Register, and receiving preemption result from Context Status Buffer. Preemption in previous gens required a

Re: [Intel-gfx] [PATCH v7 10/12] drm/i915/guc: Handle default action received over CT

On 3/27/2018 3:49 PM, Michel Thierry wrote: On 3/27/2018 2:41 PM, Michal Wajdeczko wrote: When running on platform with CTB based GuC communication enabled, GuC to Host event data will be delivered as CT request message. However, content of the data[1] of this CT message follows format of the

Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

Quoting Zhang, Yunwei (2018-03-28 16:54:26) > > > On 3/27/2018 4:13 PM, Chris Wilson wrote: > > Quoting Zhang, Yunwei (2018-03-27 23:49:27) > >> > >> On 3/27/2018 3:27 PM, Chris Wilson wrote: > >>> Quoting Yunwei Zhang (2018-03-27 23:14:16) > WaProgramMgsrForCorrectSliceSpecificMmioReads

Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

On 3/27/2018 4:13 PM, Chris Wilson wrote: Quoting Zhang, Yunwei (2018-03-27 23:49:27) On 3/27/2018 3:27 PM, Chris Wilson wrote: Quoting Yunwei Zhang (2018-03-27 23:14:16) WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO read into Slice/Subslice specific registers,

  1   2   >