[Intel-gfx] [PATCH 3/3] drm/i915/cnl: Kill _MMIO_PORT6 macro

This patch replaces use of remaining _MMIO_PORT6 macro and removes the macro. Signed-off-by: Mahesh Kumar --- drivers/gpu/drm/i915/i915_reg.h | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Reset ring space estimate after unwinding the request

Quoting Chris Wilson (2018-03-07 13:42:22) > With a series of unusual events (a sequence of interrupted request > allocations), we could gradually leak the ring->space estimate by > unwinding the ring back to the start of the request, but not return the > used space back to the ring. Eventually

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Wrap engine->schedule in RCU locks for set-wedge protection

Chris Wilson writes: > Similar to the staging around handling of engine->submit_request, we > need to stop adding to the execlists->queue prior to calling > engine->cancel_requests. cancel_requests will move requests from the > queue onto the timeline, so if we add a

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Only call tasklet_kill() on the first prepare_reset

Chris Wilson writes: > tasklet_kill() will spin waiting for the current tasklet to be executed. > However, if tasklet_disable() has been called, then the tasklet is never > executed but permanently put back onto the runlist until > tasklet_enable() is called. Ergo, we

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Only call tasklet_kill() on the first prepare_reset

Quoting Chris Wilson (2018-03-09 14:10:34) > Quoting Chris Wilson (2018-03-07 13:42:26) > > tasklet_kill() will spin waiting for the current tasklet to be executed. > > However, if tasklet_disable() has been called, then the tasklet is never > > executed but permanently put back onto the runlist

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Finish the wait-for-wedge by retiring all the inflight requests

Chris Wilson writes: > Before we reset the GPU after marking the device as wedged, we wait for > all the remaining requests to be completed (and marked as EIO). > Afterwards, we should flush the request lists so the next batch start > with the driver in an idle start.

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Reset ring space estimate after unwinding the request

Chris Wilson writes: > With a series of unusual events (a sequence of interrupted request > allocations), we could gradually leak the ring->space estimate by > unwinding the ring back to the start of the request, but not return the > used space back to the ring.

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Reset ring space estimate after unwinding the request

Quoting Mika Kuoppala (2018-03-09 13:17:09) > Chris Wilson writes: > > > With a series of unusual events (a sequence of interrupted request > > allocations), we could gradually leak the ring->space estimate by > > unwinding the ring back to the start of the request, but

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Include ring->emit in debugging

Chris Wilson writes: > Include ring->emit and ring->space alongside ring->(head,tail) when > printing debug information. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > --- >

Re: [Intel-gfx] [PATCH] drm/i915/perf: enable perf support on ICL

On 9 March 2018 at 11:58, Lionel Landwerlin wrote: > No significant changes from either context offsets, nor report > formats, nor register whitelist. > > Signed-off-by: Lionel Landwerlin > --- The usual spiel about disabling

Re: [Intel-gfx] [PATCH] drm/i915/perf: enable perf support on ICL

On 09/03/18 13:49, Matthew Auld wrote: On 9 March 2018 at 11:58, Lionel Landwerlin wrote: No significant changes from either context offsets, nor report formats, nor register whitelist. Signed-off-by: Lionel Landwerlin --- The

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Update ring position from request on retiring

Chris Wilson writes: > When wedged, we do not update the ring->tail as we submit the requests > causing us to leak the ring->space upon cleaning up the wedged driver. > We can just use the value stored in rq->tail, and keep the submission > backend details away from

[Intel-gfx] ✓ Fi.CI.BAT: success for CNL port refactoring (rev2)

== Series Details == Series: CNL port refactoring (rev2) URL : https://patchwork.freedesktop.org/series/38334/ State : success == Summary == Series 38334v2 CNL port refactoring https://patchwork.freedesktop.org/api/1.0/series/38334/revisions/2/mbox/ Known issues: Test

[Intel-gfx] [PATCH v3 1/4] drm: Add drm_any_plane_has_format()

From: Ville Syrjälä Add a function to check whether there is at least one plane that supports a specific format and modifier combination. Drivers can use this to reject unsupported formats/modifiers in .fb_create(). v2: Accept anyformat if the driver doesn't do

[Intel-gfx] [PATCH 4/4] drm/vc4: Validate framebuffer pixel format/modifier

From: Ville Syrjälä Only create framebuffers with supported format/modifier combinations by checking that at least one plane supports the requested combination. Using drm_any_plane_has_format() is somewhat suboptimal for vc4 since the planes have (mostly) uniform

[Intel-gfx] [PATCH 3/4] drm: Fix some coding style issues

From: Ville Syrjälä Put an empty line between the variable declarations and the code, and use tabs for alignment. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_framebuffer.c | 5 +++-- 1 file changed, 3 insertions(+), 2

[Intel-gfx] [PATCH v3 2/4] drm/i915: Eliminate the horrendous format check code

From: Ville Syrjälä Replace the messy framebuffer format/modifier validation code with a single call to drm_any_plane_has_format(). The code was extremely annoying to maintain as you had to have a lot of platform checks for different formats. The new code requires

Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_mocs_settings: Wait for RC6 EI before polling

On Fri, Mar 09, 2018 at 10:42:40AM +, Chris Wilson wrote: > On bxt, we see that the rc6 subtest flip-flops as RC6 does not restart > within our desired interval. Improve the likelihood of the inspection > passing by idling the GPU and waiting for 2 Evaluation Intervals before > we start

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/4] drm: Add drm_any_plane_has_format()

== Series Details == Series: series starting with [v3,1/4] drm: Add drm_any_plane_has_format() URL : https://patchwork.freedesktop.org/series/39700/ State : success == Summary == Series 39700v1 series starting with [v3,1/4] drm: Add drm_any_plane_has_format()

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: enable perf support on ICL

== Series Details == Series: drm/i915/perf: enable perf support on ICL URL : https://patchwork.freedesktop.org/series/39689/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight: incomplete -> PASS (shard-apl) fdo#105341 Test

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: misc fixes in headers (RESEND)

== Series Details == Series: drm/i915: misc fixes in headers (RESEND) URL : https://patchwork.freedesktop.org/series/39589/ State : success == Summary == Series 39589v1 drm/i915: misc fixes in headers (RESEND) https://patchwork.freedesktop.org/api/1.0/series/39589/revisions/1/mbox/

Re: [Intel-gfx] [PATCH] drm/i915: Remove the impedance mismatch around intel_engine_enable_signaling

Quoting Tvrtko Ursulin (2018-03-09 17:24:33) > > On 08/03/2018 14:07, Chris Wilson wrote: > > There is some redundancy between dma_fence->ops->enable_signaling (via > > i915_fence_enable_signaling) and our backend, > > intel_engine_enable_signaling() in that both levels recheck the fence > >

[Intel-gfx] ✓ Fi.CI.BAT: success for Add NV12 support

== Series Details == Series: Add NV12 support URL : https://patchwork.freedesktop.org/series/39670/ State : success == Summary == Series 39670v1 Add NV12 support https://patchwork.freedesktop.org/api/1.0/series/39670/revisions/1/mbox/ Known issues: Test debugfs_test: Subgroup

Re: [Intel-gfx] [PATCH] drm/i915: Remove the impedance mismatch around intel_engine_enable_signaling

On 08/03/2018 14:07, Chris Wilson wrote: There is some redundancy between dma_fence->ops->enable_signaling (via i915_fence_enable_signaling) and our backend, intel_engine_enable_signaling() in that both levels recheck the fence status multiple times. If we convert

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

Quoting Tvrtko Ursulin (2018-03-09 17:06:45) > > On 09/03/2018 13:46, Chris Wilson wrote: > > Exercise some new API that allows applications to request that > > individual contexts are executed within a desired frequency range. > > > > v2: Split single/continuous set_freq subtests > > v3: Do an

[Intel-gfx] ✓ Fi.CI.IGT: success for CNL port refactoring (rev2)

== Series Details == Series: CNL port refactoring (rev2) URL : https://patchwork.freedesktop.org/series/38334/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-external: pass -> INCOMPLETE (shard-apl) fdo#105341 Test

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915/guc: Tidy guc_log_control

== Series Details == Series: series starting with [CI,1/4] drm/i915/guc: Tidy guc_log_control URL : https://patchwork.freedesktop.org/series/39710/ State : success == Summary == Series 39710v1 series starting with [CI,1/4] drm/i915/guc: Tidy guc_log_control

Re: [Intel-gfx] [PATCH v2 0/4] drm/i915: misc fixes in headers (RESEND)

On Thu, Mar 08, 2018 at 04:22:55PM +0100, Michal Wajdeczko wrote: > On Thu, 08 Mar 2018 13:58:48 +0100, Petri Latvala > wrote: > > > On Thu, Mar 08, 2018 at 02:20:41PM +0200, Jani Nikula wrote: > > > On Thu, 08 Mar 2018, Chris Wilson wrote: > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: i915: Fix audio issue on BXT (rev2)

== Series Details == Series: drm: i915: Fix audio issue on BXT (rev2) URL : https://patchwork.freedesktop.org/series/35955/ State : failure == Summary == Series 35955v2 drm: i915: Fix audio issue on BXT https://patchwork.freedesktop.org/api/1.0/series/35955/revisions/2/mbox/ Possible

Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/guc: Split relay control and GuC log level

On Fri, Mar 09, 2018 at 12:00:06PM +0100, Michal Wajdeczko wrote: > On Thu, 08 Mar 2018 16:47:00 +0100, Michał Winiarski > wrote: > > > Those two concepts are really separate. Since GuC is writing data into > > its own buffer and we even provide a way for userspace to

[Intel-gfx] [CI 4/4] HAX: Enable GuC for CI

From: Michal Wajdeczko v2: except running with HYPERVISOR --- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h

[Intel-gfx] [CI 1/4] drm/i915/guc: Tidy guc_log_control

From: Michał Winiarski We plan to decouple log runtime (mapping + relay) from verbosity control. Let's tidy the code now to reduce the churn in the following patches. v2: Tidy macros, keep debug messages, use helper var for enable, correct typo (Michał) Fix

[Intel-gfx] [CI 2/4] drm/i915/guc: Create common entry points for log register/unregister

From: Michał Winiarski We have many functions responsible for allocating different parts of GuC log runtime called from multiple places. Let's stick with keeping everything in guc_log_register instead. v2: Use more generic intel_uc_register name, keep using "misc"

[Intel-gfx] [CI 3/4] drm/i915/guc: Move GuC notification handling to separate function

From: Michal Wajdeczko To allow future code reuse. While here, fix comment style. v2: Notifications are a separate thing - rename the handler (Sagar) Suggested-by: Oscar Mateo Signed-off-by: Michal Wajdeczko

[Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT

On Apollolake, with stress test warm reboot, audio card was not getting enumerated after reboot. This was a spurious issue happening on Apollolake. HW codec and HD audio controller link was going out of sync for which there was a fix in i915 driver but was not getting invoked for BXT. Extending

[Intel-gfx] [PATCH v2 0/3] drm/i915/uc: Sanitize uC

Attempt to sanitize uC for better alignment with rest of GEM driver. v2: cover reset path and sanitize uc before gem Michal Wajdeczko (3): drm/i915/uc: Sanitize uC options early drm/i915/uc: Sanitize uC together with GEM HAX: Enable GuC for CI drivers/gpu/drm/i915/i915_drv.c| 2 --

[Intel-gfx] [PATCH v2 1/3] drm/i915/uc: Sanitize uC options early

We are sanitizing uC related modparams together with other driver modparams in intel_sanitize_options called from i915_driver_init_hw, but this is too late for us as we will want to use USES_GUC/USES_HUC macros at earlier stage. Since our sanitizing does not require any MMIO access, we can do it

[Intel-gfx] [PATCH v2 2/3] drm/i915/uc: Sanitize uC together with GEM

Instead of dancing around uC on reset/suspend/resume scenarios, explicitly sanitize uC when we sanitize GEM to force uC reload and start from known beginning. v2: don't forget about reset path (Daniele) sanitize uc before gem initiated full reset (Daniele) Signed-off-by: Michal Wajdeczko

[Intel-gfx] [PATCH v2 3/3] HAX: Enable GuC for CI

v2: except running with HYPERVISOR Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uc: Sanitize uC (rev2)

== Series Details == Series: drm/i915/uc: Sanitize uC (rev2) URL : https://patchwork.freedesktop.org/series/39634/ State : success == Summary == Series 39634v2 drm/i915/uc: Sanitize uC https://patchwork.freedesktop.org/api/1.0/series/39634/revisions/2/mbox/ Known issues: Test

Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/guc: Split relay control and GuC log level

Quoting Michał Winiarski (2018-03-09 16:30:42) > On Fri, Mar 09, 2018 at 12:00:06PM +0100, Michal Wajdeczko wrote: > > On Thu, 08 Mar 2018 16:47:00 +0100, Michał Winiarski > > wrote: > > > > > Those two concepts are really separate. Since GuC is writing data into > >

<    1   2