Re: [Intel-gfx] [PATCH 2/3] drm/vma_manage: Drop has_offset

Hi Daniel, [auto build test WARNING on drm/drm-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Update-GEM-refcounting-docs/20151023-011317 config: x86_64-randconfig-s1-10230205

Re: [Intel-gfx] [PATCH 2/3] drm/vma_manage: Drop has_offset

On Fri, Oct 23, 2015 at 02:47:49AM +0800, kbuild test robot wrote: > Hi Daniel, > > [auto build test WARNING on drm/drm-next -- if it's inappropriate base, > please suggest rules for selecting the more suitable base] > > url: >

Re: [Intel-gfx] [PATCH] drm/915: Pad GTT views of exec objects up to user specified size

On 21/10/15 16:24, Chris Wilson wrote: Our GPUs impose certain requirements upon buffers that depend upon how exactly they are used. Typically this is expressed as that they require a larger surface than would be naively computed by pitch * height. Normally such requirements are hidden away in

Re: [Intel-gfx] [PATCH v7 11/25] drm/i915: Register color correction capabilities

On Wed, Oct 21, 2015 at 11:19:10PM +, Bish, Jim wrote: > On Tue, 2015-10-20 at 18:04 +0530, Shashank Sharma wrote: > > From DRM color management: > > > > DRM color manager supports these color properties: > > 1. "ctm": Color transformation matrix property, where a

Re: [Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree

On Wed, Oct 21, 2015 at 5:14 PM, David Herrmann wrote: > On Wed, Oct 21, 2015 at 5:11 PM, Daniel Vetter wrote: >> On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote: >>> In addition to the last-in/first-out stack for accessing drm_mm nodes, >>>

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

Hi Dave, Bunch of -fixes for 4.4. Well not just, I've left the mmio/register work from Ville in here since it's low-risk but lots of churn all over. With this Jani will take over 4.4 from me. Cheers, Daniel The following changes since commit 80bea1897d7bc35e2b201847e12029a9d677cf12:

Re: [Intel-gfx] [PATCH] drm/915: Pad GTT views of exec objects up to user specified size

On Wed, Oct 21, 2015 at 04:24:58PM +0100, Chris Wilson wrote: > Our GPUs impose certain requirements upon buffers that depend upon how > exactly they are used. Typically this is expressed as that they require > a larger surface than would be naively computed by pitch * height. > Normally such

Re: [Intel-gfx] [PATCH 15/18] drm/i915: alloc/free the FBC CFB during enable/disable

On Wed, Oct 21, 2015 at 06:30:09PM +, Zanoni, Paulo R wrote: > Em Qua, 2015-10-21 às 09:24 +0200, Daniel Vetter escreveu: > > On Wed, Oct 21, 2015 at 10:20:55AM +0300, Ville Syrjälä wrote: > > > On Wed, Oct 21, 2015 at 09:11:08AM +0200, Daniel Vetter wrote: > > > > On Tue, Oct 20, 2015 at

Re: [Intel-gfx] [PATCH 04/18] drm/i915: extract crtc_is_valid() on the FBC code

On Thu, Oct 22, 2015 at 07:26:36PM +, Zanoni, Paulo R wrote: > Em Qui, 2015-10-22 às 09:52 +0200, Maarten Lankhorst escreveu: > > Op 20-10-15 om 15:49 schreef Paulo Zanoni: > > > We're going to kill intel_fbc_find_crtc(), that's why a big part of > > > the logic moved from

[Intel-gfx] [PATCH] drm/i915: don't track relative-constants-mode

'relative_constants_mode' has always been tracked per-device, but this has actually been wrong ever since hardware contexts were introduced, as the INSTPM register is saved (and automatically restored) as part of the render ring context. The software per-device value could therefore get out of

Re: [Intel-gfx] [PATCH 2/3] drm/vma_manage: Drop has_offset

Hi Daniel, [auto build test ERROR on drm/drm-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Update-GEM-refcounting-docs/20151023-011317 config: i386-randconfig-s1-201542 (attached

Re: [Intel-gfx] [PATCH 1/3] drm: Update GEM refcounting docs

On Thu, Oct 22, 2015 at 1:11 PM, Daniel Vetter wrote: > I just realized that I've forgotten to update all the gem refcounting > docs. For pennance also add pretty docs for the overall drm_gem_object > structure, with a few links thrown in fore good. > > As usually we need

Re: [Intel-gfx] [PATCH] drm/i915: Always program CSR if CSR is uninitialized

On Thu, Oct 22, 2015 at 6:07 PM, Rodrigo Vivi wrote: > regarding your offline question: yes, I had your patch applied here, so > > Tested-by: Rodrigo Vivi > > On Wed, Oct 21, 2015 at 7:57 AM, Patrik Jakobsson >

Re: [Intel-gfx] [PATCH 13/18] drm/i915: remove too-frequent FBC debug message

On Wed, Oct 21, 2015 at 06:19:23PM +, Zanoni, Paulo R wrote: > Em Qua, 2015-10-21 às 14:01 +0100, Chris Wilson escreveu: > > On Tue, Oct 20, 2015 at 11:49:59AM -0200, Paulo Zanoni wrote: > > > If we run igt/kms_frontbuffer_tracking, this message will appear > > > thousands of times, eating a

[Intel-gfx] [PULL] topic/drm-misc

Hi Dave, Few more drm-misc stragglers for 4.4. Big thing is the generic probe for imx/rockchip/armada (but the variant for msm/rpi/exynos is still missing). Also the hdmi clocking fixes from Ville which was a lot of confusion about which tree it should be applied to ;-) Cheers, Daniel The

Re: [Intel-gfx] [PATCH 04/18] drm/i915: extract crtc_is_valid() on the FBC code

Em Qui, 2015-10-22 às 09:52 +0200, Maarten Lankhorst escreveu: > Op 20-10-15 om 15:49 schreef Paulo Zanoni: > > We're going to kill intel_fbc_find_crtc(), that's why a big part of > > the logic moved from intel_fbc_find_crtc() to crtc_is_valid(). > > > > Signed-off-by: Paulo Zanoni

Re: [Intel-gfx] [PATCH 1/3] drm: Update GEM refcounting docs

On Thu, Oct 22, 2015 at 01:54:17PM -0400, Alex Deucher wrote: > On Thu, Oct 22, 2015 at 1:11 PM, Daniel Vetter wrote: > > I just realized that I've forgotten to update all the gem refcounting > > docs. For pennance also add pretty docs for the overall drm_gem_object > >

Re: [Intel-gfx] [PATCH v2 7/8] drm/i915: Grab execlist spinlock to avoid post-reset concurrency issues.

On Thu, Oct 22, 2015 at 05:49:56PM +0100, Dave Gordon wrote: > On 19/10/15 16:32, Tomas Elf wrote: > >Grab execlist lock when cleaning up execlist queues after GPU reset to avoid > >concurrency problems between the context event interrupt handler and the > >reset > >path immediately following a

Re: [Intel-gfx] [PATCH] drm/i915: add hotplug activation period to hotplug update mask

On Thu, Oct 22, 2015 at 10:46:58AM +0300, Jani Nikula wrote: > On Wed, 21 Oct 2015, Ville Syrjälä wrote: > > On Wed, Oct 21, 2015 at 05:22:43PM +0300, Jani Nikula wrote: > >> commit 0706f17c307b056ff6f1848320ba82d76945a6ff > >> Author: Egbert Eich >

Re: [Intel-gfx] [PATCH] drm/915: Pad GTT views of exec objects up to user specified size

On Thu, Oct 22, 2015 at 10:04:55AM +0200, Daniel Vetter wrote: > On Wed, Oct 21, 2015 at 04:24:58PM +0100, Chris Wilson wrote: > > Our GPUs impose certain requirements upon buffers that depend upon how > > exactly they are used. Typically this is expressed as that they require > > a larger surface

[Intel-gfx] [maintainer-tools PATCH] dim: print branches containing commit-ish if no tag contains it

dim tc is useful for checking when and where a commit has landed, so one can decide where, for example, a fix to that commit should be queued. If the commit is not in a tagged upstream Linux release, fall back to printing the i915 upstream development branches that contain it. v2: check for

[Intel-gfx] [PATCH 01/11] drm/i915: Use passed plane state for sprite planes.

Don't use plane->state directly, use the pointer from commit_plane. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_drv.h| 8 ++--- drivers/gpu/drm/i915/intel_sprite.c | 67 +++-- 2 files changed, 45

[Intel-gfx] [PATCH 00/11] Kill off intel_crtc->atomic!

While converting page flip to atomic I've noticed it was easier to kill off intel_crtc->atomic first. This can be done by adding fb_bits, visible_changed, wm_changed to the crtc_state and deriving some primary state during pre/post_plane_update. This will probably conflict with the atomic wm

[Intel-gfx] [PATCH 03/11] drm/i915: Kill off intel_crtc->atomic.wait_vblank.

By handling this after the atomic helper waits for vblanks there will be one less wait for vblank in the atomic path. Also get rid of the double wait_for_vblank on broadwell, looks like it's a bug doing the vblank wait twice. Signed-off-by: Maarten Lankhorst

[Intel-gfx] [PATCH 02/11] drm/i915: Do not acquire crtc state to check clock during modeset.

Parallel modesets are still not allowed, but this will allow updating a different crtc during a modeset if the clock is not changed. Additionally when all pipes are DPMS off the cdclk will be lowered to the minimum allowed. Signed-off-by: Maarten Lankhorst ---

[Intel-gfx] [PATCH 04/11] drm/i915: Update watermark related members in the crtc_state.

This removes another couple of hacks from intel_crtc->atomic, and creates proper atomic state for it. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_atomic.c | 2 ++ drivers/gpu/drm/i915/intel_display.c | 49

[Intel-gfx] [PATCH 11/11] drm/i915/skl: Do not allow scaling when crtc is disabled.

This fixes a warning when the crtc is turned off. In that case fb will be NULL, and crtc_clock will be 0. Because the crtc is no longer active this is not a bug, and shouldn't trigger the WARN_ON. Also remove handling a null crtc_state, with all transitional helpers gone this can no longer

[Intel-gfx] [PATCH 06/11] drm/i915: Remove atomic.pre_disable_primary.

This can be derived from the atomic state in pre_plane_update, which makes it more clear when it's supposed to be called. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 28

[Intel-gfx] [PATCH 05/11] drm/i915: Remove intel_crtc->atomic.disable_ips.

This is already handled in pre_disable_primary, disabling it twice is useless. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 16 +--- drivers/gpu/drm/i915/intel_drv.h | 1 - 2 files changed, 1 insertion(+), 16

Re: [Intel-gfx] [PATCH] drm/i915: add hotplug activation period to hotplug update mask

On Thu, Oct 22, 2015 at 10:46:58AM +0300, Jani Nikula wrote: > On Wed, 21 Oct 2015, Ville Syrjälä wrote: > > On Wed, Oct 21, 2015 at 05:22:43PM +0300, Jani Nikula wrote: > >> commit 0706f17c307b056ff6f1848320ba82d76945a6ff > >> Author: Egbert Eich >

Re: [Intel-gfx] [PATCH v7 11/25] drm/i915: Register color correction capabilities

> > diff --git a/drivers/gpu/drm/i915/i915_drv.h > > b/drivers/gpu/drm/i915/i915_drv.h > > index 8afda45..613bee2 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.h > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > @@ -789,6 +789,8 @@ struct intel_device_info { > > u8

Re: [Intel-gfx] [PATCH] drm/i915: add hotplug activation period to hotplug update mask

On Thu, 22 Oct 2015, Daniel Vetter wrote: > On Thu, Oct 22, 2015 at 10:46:58AM +0300, Jani Nikula wrote: >> On Wed, 21 Oct 2015, Ville Syrjälä wrote: >> > On Wed, Oct 21, 2015 at 05:22:43PM +0300, Jani Nikula wrote: >> >> commit

[Intel-gfx] [PATCH 07/11] drm/i915: Remove some post-commit members from intel_crtc->atomic.

fb_bits is useful to have in the crtc_state for cs flips later on, so keep it alive there. The other stuff can be calculated in post_plane_update, and aren't useful elsewhere. Currently there's a loop in post_plane_update, this should disappear with the changes to atomic wm's. At that point only

[Intel-gfx] [PATCH 10/11] drm/i915/skl: Update watermarks before the crtc is disabled.

On skylake some of the registers are only writable when the correct power wells are enabled. Because of this watermarks have to be updated before the crtc turns off, or you get unclaimed register read and write warnings. This patch needs to be modified slightly to apply to -fixes. Bugzilla:

[Intel-gfx] [PATCH 09/11] drm/i915/skl: Prevent unclaimed register writes on skylake.

I'm getting unclaimed register writes when checking the WM registers after the crtc is disabled. So I would imagine those are guarded by the crtc power well. Fix this by not reading out wm state when the power well is off. Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH v3 7/8] drm/i915: Cope with request list state change during error state capture

On Mon, Oct 19, 2015 at 05:51:57PM +0100, Tomas Elf wrote: > Since we're not synchronizing the ring request list during error state capture > the request list state might change between the time the corresponding error > request list was allocated and dimensioned to the time when the ring request

Re: [Intel-gfx] [PATCH 07/18] drm/i915: fix the __intel_fbc_update() comments

Em Qua, 2015-10-21 às 18:38 +0100, ch...@chris-wilson.co.uk escreveu: > On Wed, Oct 21, 2015 at 05:32:16PM +, Zanoni, Paulo R wrote: > > Em Qua, 2015-10-21 às 13:37 +0100, Chris Wilson escreveu: > > > On Tue, Oct 20, 2015 at 11:49:53AM -0200, Paulo Zanoni wrote: > > > > Don't try to list in

[Intel-gfx] [PATCH i-g-t 3/4] tests/kms_flip: Improve the accuracy of out frame time calculation

From: Ville Syrjälä Don't use the rounded vrefresh info to predict the frame duration. Instead calculate if from the clock. Signed-off-by: Ville Syrjälä --- tests/kms_flip.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[Intel-gfx] [PATCH i-g-t 4/4] tests/kms_flip: Dump the timestamps, counters, etc. with higher debug levels

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- tests/kms_flip.c | 24 1 file changed, 24 insertions(+) diff --git a/tests/kms_flip.c b/tests/kms_flip.c index 48e9062..e1b5856 100644 ---

[Intel-gfx] [PATCH i-g-t 2/4] lib: Skip suspend/hibernate tests if the system doesn't support them

From: Ville Syrjälä Do a dry run with rtcwake first to determine if the system even supports the intended suspend state. If not, skip the test. Fixes a bunch of stuff on my BYT FFRD8 that doesn't support S3. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH i-g-t 1/4] tests/kms_pipe_crc_basic: Skip invalid pipe/port combos

From: Ville Syrjälä Don't try to test invaliud pipe/port combos. Fixes the test on VLV w/ DSI since the pipe<->DSI port mapping is fixed. Should also fix other platforms with similar restrictions. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 0/2] CRTC background color support for i915

Recent Intel platforms (SKL+) support a background canvas color below the hardware planes. This background color can be seen on areas not covered by a plane, or if we program the hardware with various plane blending modes. Chandra Konduru previously took a stab at writing i915 patches to support

[Intel-gfx] [PATCH 1/2] drm: Add infrastructure for CRTC background color property

To support CRTC background color, we need a way of communicating RGB color values to the DRM. However there is often a mismatch between how userspace wants to represent the color value vs how it must be programmed into the hardware; this mismatch can easily lead to non-obvious bugs. Let's create

[Intel-gfx] [PATCH 2/2] drm/i915/skl: Add support for pipe background color

SKL and BXT allow CRTC's to be programmed with a background/canvas color below the programmable planes. Let's expose this as a property to allow userspace to program a desired value. This patch is based on earlier work by Chandra Konduru; unfortunately the driver has evolved so much since his

Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Add support for pipe background color

Hi Matt, [auto build test WARNING on drm/drm-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Matt-Roper/CRTC-background-color-support-for-i915/20151023-082852 config: x86_64-rhel (attached as

[Intel-gfx] [PATCH 01/20] drm/i915: Make i915_gem_reset_ring_status() public

Makes i915_gem_reset_ring_status() public for use from engine reset path in order to replicate the same behavior as in full GPU reset but for a single engine. Signed-off-by: Tomas Elf Cc: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] [PATCH 02/20] drm/i915: Generalise common GPU engine reset request/unrequest code

GPU engine reset handshaking is something that is applicable to both full GPU reset and engine reset, which is something that is part of the upcoming TDR per-engine hang recovery patches. Break out the common engine reset request/unrequest code (originally written by Mika Kuoppala) for reuse later

[Intel-gfx] [PATCH 06/20] drm/i915: Reinstate hang recovery work queue.

There used to be a work queue separating the error handler from the hang recovery path, which was removed a while back in this commit: commit b8d24a06568368076ebd5a858a011699a97bfa42 Author: Mika Kuoppala Date: Wed Jan 28 17:03:14 2015

[Intel-gfx] [PATCH 03/20] drm/i915: TDR / per-engine hang recovery support for gen8.

TDR = Timeout Detection and Recovery. This change introduces support for TDR-style per-engine reset as an initial, less intrusive hang recovery option to be attempted before falling back to the legacy full GPU reset recovery mode if necessary. Initially we're only supporting gen8 but adding

[Intel-gfx] [PATCH 16/20] drm/i915: Fix __i915_wait_request() behaviour during hang detection.

Use is_locked parameter in __i915_wait_request() to determine if a thread should be forced to back off and retry or if it can continue sleeping. Don't return -EIO from __i915_wait_request since that is bad for the upper layers, only -EAGAIN to signify reset in progress. (unless the driver is

[Intel-gfx] [PATCH 14/20] drm/i915: TDR/watchdog trace points.

Defined trace points and sprinkled the usage of these throughout the TDR/watchdog implementation. The following trace points are supported: 1. trace_i915_tdr_gpu_recovery: Called at the onset of the full GPU reset recovery path. 2. trace_i915_tdr_engine_recovery:

[Intel-gfx] [PATCH 17/20] drm/i915: Extended error state with TDR count, watchdog count and engine reset count

These new TDR-specific metrics have previously been added to i915_hangcheck_info() in debugfs. During design review Chris Wilson asked for these metrics to be added to the error state as well. Signed-off-by: Tomas Elf Cc: Chris Wilson Cc: Mika

[Intel-gfx] [PATCH 09/20] drm/i915: Watchdog timeout: Ringbuffer command emission for gen8

*** General *** Watchdog timeout (or "media engine reset") is a feature that allows userland applications to enable hang detection on individual batch buffers. The detection mechanism itself is mostly bound to the hardware and the only thing that the driver needs to do to support this form of

[Intel-gfx] [PATCH 08/20] drm/i915: Watchdog timeout: IRQ handler for gen8

*** General *** Watchdog timeout (or "media engine reset") is a feature that allows userland applications to enable hang detection on individual batch buffers. The detection mechanism itself is mostly bound to the hardware and the only thing that the driver needs to do to support this form of

[Intel-gfx] [PATCH 04/20] drm/i915: TDR / per-engine hang detection

With the per-engine hang recovery path already in place this patch adds per-engine hang detection by letting the periodic hang checker detect hangs on individual engines and communicate this to the error handler. During hang checking every engine is checked and the hang detection status for each

[Intel-gfx] [PATCH 00/20] TDR/watchdog support for gen8

This patch series introduces the following features: * Feature 1: TDR (Timeout Detection and Recovery) for gen8 execlist mode. TDR is an umbrella term for anything that goes into detecting and recovering from GPU hangs and is a term more widely used outside of the i915 driver. This feature

[Intel-gfx] [PATCH 07/20] drm/i915: Watchdog timeout: Hang detection integration into error handler

This patch enables watchdog timeout hang detection as an entrypoint into the driver error handler. This form of hang detection overrides the promotion logic normally used by the periodic hang checker and instead allows for direct access to the per-engine hang recovery path. NOTE: I don't know if

[Intel-gfx] [PATCH 05/20] drm/i915: Extending i915_gem_check_wedge to check engine reset in progress

i915_gem_wedge now returns a non-zero result in three different cases: 1. Legacy: A hang has been detected and full GPU reset is in progress. 2. Per-engine recovery: a. A single engine reference can be passed to the function, in which case only that engine will be checked. If

Re: [Intel-gfx] [PATCH i-g-t 2/4] lib: Skip suspend/hibernate tests if the system doesn't support them

On Thu, Oct 22, 2015 at 10:35 PM, wrote: > diff --git a/lib/igt_aux.c b/lib/igt_aux.c > index 04ca25b..f3c76ae 100644 > --- a/lib/igt_aux.c > +++ b/lib/igt_aux.c > @@ -357,6 +357,9 @@ void igt_system_suspend_autoresume(void) > * seems to fare better. We

Re: [Intel-gfx] [PATCH 1/2] drm: Add infrastructure for CRTC background color property

Hi Matt, [auto build test WARNING on drm/drm-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Matt-Roper/CRTC-background-color-support-for-i915/20151023-082852 reproduce: make htmldocs All warnings

[Intel-gfx] [PATCH] igt/kms_rotation_crc: Add a subtest to validate Y-tiled obj + Y fb modifier (v3)

The main goal of this subtest is to trigger the following warning in the function i915_gem_object_get_fence(): if (WARN_ON(!obj->map_and_fenceable)) To trigger this warning, the subtest first creates a Y-tiled object and an associated framebuffer with the Y-fb modifier. Furthermore, to

Re: [Intel-gfx] [PATCH] drm/i915: Deny wrapping an userptr into a framebuffer

On Tue, Oct 13, 2015 at 6:22 AM, Chris Wilson wrote: > Pinning a userptr onto the hardware raises interesting questions about > the lifetime of such a surface as the framebuffer extends that life > beyond the client's address space. That is the hardware will need to >

[Intel-gfx] [PATCH i-g-t 1/2] igt_kms: Set atomic capability bit

Tell the kernel that we understand atomic and want to have access to atomic-only properties. If the kernel doesn't support atomic for i915 yet (and i915.nuclear_pageflip=1 isn't passed on the kernel command line) this will silently fail, but won't cause any problems. We wrap this in an #ifdef to

[Intel-gfx] [PATCH i-g-t 2/2] kms_crtc_background_color: Update to match kernel interface

Update the existing test to use the current kernel interface, but leave the test logic untouched. As the test is written at the moment it's only really useful for manual testing...it will happily return success even if we fail to set the background color (or misprogram the HW with the wrong

[Intel-gfx] [PATCH libdrm] xf86drmMode: Add RGBA property helpers

Now that we've added an RGBA property type to the kernel that handles RGBA values with a specific bit layout, let's add a userspace helper to allow userspace to easily build values in the proper format. Cc: dri-de...@lists.freedesktop.org Signed-off-by: Matt Roper ---

Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Add support for pipe background color

Hi Matt, [auto build test WARNING on drm/drm-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Matt-Roper/CRTC-background-color-support-for-i915/20151023-082852 config: x86_64-randconfig-x005-10211812

[Intel-gfx] [PATCH 15/20] drm/i915: Port of Added scheduler support to __wait_request() calls

This is a partial port of the following patch from John Harrison's GPU scheduler patch series: (patch sent to Intel-GFX with the subject line "[Intel-gfx] [RFC 19/39] drm/i915: Added scheduler support to __wait_request() calls" on Fri 17 July 2015) Author: John Harrison

[Intel-gfx] [PATCH 11/20] drm/i915: Fake lost context event interrupts through forced CSB checking.

*** General *** A recurring issue during long-duration operations testing of concurrent rendering tasks with intermittent hangs is that context completion interrupts following engine resets are sometimes lost. This becomes a real problem since the hardware might have completed a previously hung

[Intel-gfx] [PATCH 19/20] drm/i915: drm/i915 changes to simulated hangs

From: Tim Gore Simulated hangs, as used by drv_hangman and some other IGT tests, are not handled correctly with the new per-engine hang recovery mode. This patch fixes several issues needed to get them working in the execlist case. 1) The "simulated" hang is effected by not

[Intel-gfx] [PATCH 12/20] drm/i915: Debugfs interface for per-engine hang recovery.

1. The i915_wedged_set() function now allows for both legacy full GPU reset and per-engine reset of one or more engines at a time: a) Legacy hang recovery by passing 0. b) Multiple engine hang recovery by passing in an engine flag mask where bit 0 corresponds to engine

[Intel-gfx] [PATCH 10/20] drm/i915: Watchdog timeout: DRM kernel interface enablement

Final enablement patch for GPU hang recovery using watchdog timeout. Added execbuf flag for watchdog timeout in DRM kernel interface. Signed-off-by: Tomas Elf --- drivers/gpu/drm/i915/intel_lrc.c | 6 ++ include/uapi/drm/i915_drm.h | 5 - 2 files changed, 6

[Intel-gfx] [PATCH 13/20] drm/i915: Test infrastructure for context state inconsistency simulation

Added debugfs functions and embedded test infrastructure in the context event interrupt handler for simulating the loss of context event interrupts so that a context submission state inconsistency can be induced. This is useful for testing the consistency checker pre-stage to the engine hang

[Intel-gfx] [PATCH 18/20] drm/i915: TDR / per-engine hang recovery kernel docs

Signed-off-by: Tomas Elf --- Documentation/DocBook/gpu.tmpl | 476 drivers/gpu/drm/i915/i915_irq.c | 8 +- 2 files changed, 483 insertions(+), 1 deletion(-) diff --git a/Documentation/DocBook/gpu.tmpl

[Intel-gfx] [PATCH 20/20] drm/i915: Enable TDR / per-engine hang recovery

This is the final enablement patch for per-engine hang recovery. It sets up per-engine hang recovery to be used per default in favour of full GPU reset. Legacy full GPU reset will no longer be the preferred mode of hang recovery and will only be used as a fall-back in case of frequent hangs on

Re: [Intel-gfx] [PATCH] igt/kms_rotation_crc: Add a subtest to validate Y-tiled obj + Y fb modifier (v2)

Hi, On 22/10/15 02:24, Vivek Kasireddy wrote: The main goal of this subtest is to verify whether flipping a Need to change to commit message since there is no flipping involved. framebuffer with a Y fb modifier (90/270 degree rotation) and with an associated Y-tiled object works or not.

Re: [Intel-gfx] [PATCH] drm/915: Pad GTT views of exec objects up to user specified size

On Thu, Oct 22, 2015 at 10:00:54AM +0100, Tvrtko Ursulin wrote: > > On 21/10/15 16:24, Chris Wilson wrote: > >Our GPUs impose certain requirements upon buffers that depend upon how > >exactly they are used. Typically this is expressed as that they require > >a larger surface than would be naively

[Intel-gfx] [maintainer-tools PATCH] dim: print branches containing commit-ish if no tag contains it

dim tc is useful for checking when and where a commit has landed, so one can decide where, for example, a fix to that commit should be queued. If the commit is not in a tagged upstream Linux release, fall back to printing the i915 upstream development branches that contain it. Signed-off-by:

Re: [Intel-gfx] [maintainer-tools PATCH] dim: print branches containing commit-ish if no tag contains it

On Thu, Oct 22, 2015 at 12:36:57PM +0300, Jani Nikula wrote: > dim tc is useful for checking when and where a commit has landed, so one > can decide where, for example, a fix to that commit should be queued. > > If the commit is not in a tagged upstream Linux release, fall back to > printing the

Re: [Intel-gfx] [PATCH 03/11] drm/i915: Kill off intel_crtc->atomic.wait_vblank.

Op 22-10-15 om 15:30 schreef Ville Syrjälä: > On Thu, Oct 22, 2015 at 01:56:28PM +0200, Maarten Lankhorst wrote: >> By handling this after the atomic helper waits for vblanks there will >> be one less wait for vblank in the atomic path. >> >> Also get rid of the double wait_for_vblank on

Re: [Intel-gfx] [PATCH] drm/915: Pad GTT views of exec objects up to user specified size

Hi, On 21/10/15 16:24, Chris Wilson wrote: Our GPUs impose certain requirements upon buffers that depend upon how exactly they are used. Typically this is expressed as that they require a larger surface than would be naively computed by pitch * height. Normally such requirements are hidden

[Intel-gfx] [PATCH 4/5] drm/i915: Respin vlv/chv reagister access to look more like SKL

From: Ville Syrjälä Change the fw domain handling in the vlv/chv register read/write functions to look more like the SKL code, ie. have a single __force_wake_get() get call instead of multiple ones. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 5/5] drm/i915: Add NEEDS_FORCEWAKE() checks for vlv/chv

From: Ville Syrjälä Include an early NEEDS_FORCEWAKE() check for vlv and chv. Hopefully that will avoid doing so many range checks in for many register accesses (at least for all display registers). Note that vlv already had the check in the write path since it

[Intel-gfx] [PATCH 0/5] drm/i915: Expose __raw_i915_read() & co. to the outside, and a few forcewake things

From: Ville Syrjälä These patches fell off from my type safe register access series. I figured I'd post them separately since they're a fairly separate piece of work. Ville Syrjälä (5): drm/i915: Turn __raw_i915_read8() & co. in to inline functions drm/i915:

Re: [Intel-gfx] [PATCH 03/11] drm/i915: Kill off intel_crtc->atomic.wait_vblank.

On Thu, Oct 22, 2015 at 01:56:28PM +0200, Maarten Lankhorst wrote: > By handling this after the atomic helper waits for vblanks there will > be one less wait for vblank in the atomic path. > > Also get rid of the double wait_for_vblank on broadwell, looks like > it's a bug doing the vblank wait

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Read FORCEWAKE registers with I915_READ_FW()

On Thu, Oct 22, 2015 at 03:34:57PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Change FORCEWAKE & co. reads for the error state to use I915_READ_FW(). > Reading a FORCEWAKE register using a function that can frob forcewake > just seems

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Minor style nits in intel_uncore.c

On Thu, Oct 22, 2015 at 03:34:58PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Signed-off-by: Ville Syrjälä I even bothered to check whether you still have spaces in here ;-) Reviewed-by: Daniel Vetter

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Add NEEDS_FORCEWAKE() checks for vlv/chv

On Thu, Oct 22, 2015 at 03:35:00PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Include an early NEEDS_FORCEWAKE() check for vlv and chv. > Hopefully that will avoid doing so many range checks in for many > register accesses (at least for

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Read FORCEWAKE registers with I915_READ_FW()

On Thu, Oct 22, 2015 at 03:37:33PM +0200, Daniel Vetter wrote: > On Thu, Oct 22, 2015 at 03:34:57PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Change FORCEWAKE & co. reads for the error state to use I915_READ_FW(). > > Reading a

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Turn __raw_i915_read8() & co. in to inline functions

On Thu, Oct 22, 2015 at 03:32:11PM +0200, Daniel Vetter wrote: > On Thu, Oct 22, 2015 at 03:34:56PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > There's no need for __raw_i915_read8() & co. bot be macros, so make them > > s/bot/be

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Add soft-pinning API for execbuffer

> -Original Message- > From: Daniel, Thomas > Sent: Wednesday, October 21, 2015 23:11 > To: Daniel Vetter > Cc: Chris Wilson; intel-gfx@lists.freedesktop.org; Belgaumkar, Vinay; Yang, > Rong R > Subject: RE: [Intel-gfx] [PATCH 3/3] drm/i915: Add soft-pinning API for > execbuffer > > >

[Intel-gfx] [PATCH] drm/i915/skl: Add SKL GT4 PCI IDs

Add Skylake Intel Graphics GT4 PCI IDs Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.c | 1 + include/drm/i915_pciids.h | 13 ++--- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c

Re: [Intel-gfx] [PATCH 02/11] drm/i915: Do not acquire crtc state to check clock during modeset.

On Thu, Oct 22, 2015 at 01:56:27PM +0200, Maarten Lankhorst wrote: > Parallel modesets are still not allowed, but this will allow updating > a different crtc during a modeset if the clock is not changed. > > Additionally when all pipes are DPMS off the cdclk will be lowered > to the minimum

Re: [Intel-gfx] [PATCH 0/5] drm/i915: Expose __raw_i915_read() & co. to the outside, and a few forcewake things

On Thu, Oct 22, 2015 at 03:34:55PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > These patches fell off from my type safe register access series. I > figured I'd post them separately since they're a fairly separate > piece of work. > >

Re: [Intel-gfx] [PATCH 3/7] drm/i915/skl: Refuse to load outdated dmc firmware

On Thu, Oct 22, 2015 at 04:31:01PM +0300, Mika Kuoppala wrote: > There is known issue on GT interrupt delivery with DC6 and > firmwares <1.21. There is a suspicion that this causes > spurious gpu hangs on driver init and with some workloads, > as upgrading the firmware to 1.21 makes these problems

Re: [Intel-gfx] [PATCH 10/11] drm/i915/skl: Update watermarks before the crtc is disabled.

On Thu, Oct 22, 2015 at 01:56:35PM +0200, Maarten Lankhorst wrote: > On skylake some of the registers are only writable when the correct > power wells are enabled. Because of this watermarks have to be updated > before the crtc turns off, or you get unclaimed register read and write > warnings. >

Re: [Intel-gfx] [PATCH] drm/i915: add hotplug activation period to hotplug update mask

On Thu, 22 Oct 2015, Ville Syrjälä wrote: > On Thu, Oct 22, 2015 at 10:46:58AM +0300, Jani Nikula wrote: >> On Wed, 21 Oct 2015, Ville Syrjälä wrote: >> > On Wed, Oct 21, 2015 at 05:22:43PM +0300, Jani Nikula wrote: >> >> commit

Re: [Intel-gfx] [PATCH 01/11] drm/i915: Use passed plane state for sprite planes.

On Thu, Oct 22, 2015 at 01:56:26PM +0200, Maarten Lankhorst wrote: > Don't use plane->state directly, use the pointer from commit_plane. > > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/i915/intel_drv.h| 8 ++--- >

Re: [Intel-gfx] [PATCH 02/11] drm/i915: Do not acquire crtc state to check clock during modeset.

On Thu, Oct 22, 2015 at 01:56:27PM +0200, Maarten Lankhorst wrote: > Parallel modesets are still not allowed, but this will allow updating > a different crtc during a modeset if the clock is not changed. > > Additionally when all pipes are DPMS off the cdclk will be lowered > to the minimum

Re: [Intel-gfx] [PATCH 01/11] drm/i915: Use passed plane state for sprite planes.

Op 22-10-15 om 14:58 schreef Daniel Vetter: > On Thu, Oct 22, 2015 at 01:56:26PM +0200, Maarten Lankhorst wrote: >> Don't use plane->state directly, use the pointer from commit_plane. >> >> Signed-off-by: Maarten Lankhorst >> --- >>

Re: [Intel-gfx] [PATCH 09/11] drm/i915/skl: Prevent unclaimed register writes on skylake.

On Thu, Oct 22, 2015 at 01:56:34PM +0200, Maarten Lankhorst wrote: > I'm getting unclaimed register writes when checking the WM registers > after the crtc is disabled. So I would imagine those are guarded by > the crtc power well. Fix this by not reading out wm state when the > power well is off.

  1   2   >