Re: [Intel-gfx] [PATCH 9/9] drm/i915: Make all plane disables use

2014-11-24 Thread shuang . he
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform Delta drm-intel-nightly Series Applied PNV -1 367/367 3

[Intel-gfx] [PATCH] drm/i915/skl: Update in Gen9 multi-engine forcewake range

2014-11-24 Thread akash . goel
From: Akash Goel Updates in forcewake range for Render/Media/Common power wells for Gen9. Signed-off-by: Akash Goel Signed-off-by: Zhe Wang --- drivers/gpu/drm/i915/intel_uncore.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uncor

Re: [Intel-gfx] [PATCH] drm/atomic-helper: Skip vblank waits for

2014-11-24 Thread shuang . he
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform Delta drm-intel-nightly Series Applied PNV 367/367

Re: [Intel-gfx] [PATCH] drm/i915: More cautious with pch fifo underruns

2014-11-24 Thread shuang . he
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform Delta drm-intel-nightly Series Applied PNV 367/367

Re: [Intel-gfx] [PATCH] drm/i915: Drop vblank wait from

2014-11-24 Thread shuang . he
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform Delta drm-intel-nightly Series Applied PNV 367/367

Re: [Intel-gfx] [PATCH] drm/i915: Handle runtime pm in the CRC setup

2014-11-24 Thread shuang . he
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform Delta drm-intel-nightly Series Applied PNV 367/367

[Intel-gfx] [PATCH 4/7] drm/i915: Add ioctl to set per-context parameters

2014-11-24 Thread Rodrigo Vivi
From: Chris Wilson Sometimes we wish to tweak how an individual context behaves. Since we always create a context for every filp, this means that individual processes can fine tune their behaviour even if they do not explicitly create a context. The first example parameter here is to enable mult

[Intel-gfx] [PATCH 2/7] drm/i915: add I915_PARAM_HAS_BSD2 to i915_getparam

2014-11-24 Thread Rodrigo Vivi
From: Zhipeng Gong This will let userland only try to use the new ring when the appropriate kernel is present Signed-off-by: Zhipeng Gong Signed-off-by: Rodrigo Vivi Reviewed--by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_dma.c | 3 +++ include/uapi/drm/i915_drm.h | 1 + 2 files changed

[Intel-gfx] [PATCH 7/7] drm/i915: Broaden application of set-domain(GTT)

2014-11-24 Thread Rodrigo Vivi
From: Chris Wilson Previously, this was restricted to only operate on bound objects - to make pointer access through the GTT to the object coherent with writes to and from the GPU. A second usecase is drm_intel_bo_wait_rendering() which at present does not function unless the object also happens

[Intel-gfx] [PATCH 6/7] drm/i915: Add WaCsStallBeforeStateCacheInvalidate:bdw, chv to logical ring

2014-11-24 Thread Rodrigo Vivi
Similar to: commit 02c9f7e3cfe76a7f54ef03438c36aade86cc1c8b Author: Kenneth Graunke Date: Mon Jan 27 14:20:16 2014 -0800 drm/i915: Add the WaCsStallBeforeStateCacheInvalidate:bdw workaround. On Broadwell, any PIPE_CONTROL with the "State Cache Invalidate" bit set must be preceded

[Intel-gfx] [PATCH 3/7] drm/i915: Move the ban period onto the context

2014-11-24 Thread Rodrigo Vivi
From: Chris Wilson This will allow us to set per-file, or even per-context, periods in the future. Signed-off-by: Chris Wilson Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_gem.c | 3 ++- drivers/gpu/drm/i915/i915_gem_cont

[Intel-gfx] [PATCH 5/7] drm/i915: Put logical pipe_control emission into a helper.

2014-11-24 Thread Rodrigo Vivi
To be used for a Workaroud. Similar to: commit 884ceacee308f0e4616d0c933518af2639f7b1d8 Author: Kenneth Graunke Date: Sat Jun 28 02:04:20 2014 +0300 drm/i915: Refactor Broadwell PIPE_CONTROL emission into a helper. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_lrc.c | 35 ++

[Intel-gfx] [PATCH 0/7] drm-intel-collector - update

2014-11-24 Thread Rodrigo Vivi
This is another drm-intel-collector updated notice: http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector Here goes the update list in order for better reviewers assignment: Patch drm/i915: Specify bsd rings through exec flag - Reviewed Patch drm/i915: add I915_PARAM_H

[Intel-gfx] [PATCH 1/7] drm/i915: Specify bsd rings through exec flag

2014-11-24 Thread Rodrigo Vivi
From: Zhipeng Gong On Broadwell GT3 we have 2 Video Command Streamers (VCS), but userspace has no control when using VCS1 or VCS2. This patch introduces a mechanism to avoid the default ping-pong mode and use one specific ring through execution flag. v2: fix whitespace (Rodrigo) v3: remove incor

Re: [Intel-gfx] [PATCH] intel_error_decode: Inflate compressed error state

2014-11-24 Thread Rodrigo Vivi
both deflate and inflate was listed to -collector but got a hard conflict. If it is still needed please rebase it over -nightly On Fri, Oct 31, 2014 at 4:33 AM, Chris Wilson wrote: > Recent kernels compress the active objects using zlib + ascii85 > encoding. This adapts the tool to decompress tho

Re: [Intel-gfx] [PATCH] drm/i915: Stop gathering error states for CS error interrupts

2014-11-24 Thread Chris Wilson
On Mon, Nov 24, 2014 at 09:57:32PM +0100, Daniel Vetter wrote: > I looked at this and it gets ugly fast. Given that we seem to have a quite > substantial false-positive (found one more by just reading recent bug > spam) rate and haven't enabled this on gen5+ I've decided to just merge > this one he

Re: [Intel-gfx] [PATCH] drm/locking: Allow NULL crtc in drm_modeset_legacy_acquire_ctx

2014-11-24 Thread Jasper St. Pierre
This still crashes for me: kernel: [ cut here ] kernel: WARNING: at drivers/gpu/drm/drm_modeset_lock.c:219 drm_modeset_legacy_acquire_ctx+0x38/0x40() kernel: Modules linked in: kernel: CPU: 0 PID: 586 Comm: Xorg Not tainted 3.10.33-02454-g1c4eeb3-dirty #196 kernel: [] (unwi

Re: [Intel-gfx] [PATCH] drm/atomic-helper: Skip vblank waits for unchanged fbs

2014-11-24 Thread Jasper St. Pierre
With the oops fix: Reviewed-by: Jasper St. Pierre Tested-by: Jasper St. Pierre On Mon, Nov 24, 2014 at 12:42 PM, Daniel Vetter wrote: > Especially with legacy cursor ioctls existing userspace assumes that > you can pile up lots of updates in one go. The super-proper way to > support this woul

Re: [Intel-gfx] [PATCH] drm/i915: Stop gathering error states for CS error interrupts

2014-11-24 Thread Daniel Vetter
On Wed, Nov 05, 2014 at 10:56:06AM +0100, Daniel Vetter wrote: > On Wed, Nov 05, 2014 at 08:35:01AM +, Chris Wilson wrote: > > On Tue, Nov 04, 2014 at 03:52:22PM +0100, Daniel Vetter wrote: > > > There's quite a few bug reports with error states where the error > > > reasons makes just about no

[Intel-gfx] [PATCH] drm/i915: Handle runtime pm in the CRC setup code

2014-11-24 Thread Daniel Vetter
The crc code doesn't handle anything really that could drop the register state (by design so that we have less complexity). Which means userspace may only start crc capture once the pipe is fully set up. With an i-g-t patch this will be the case, but there's still the problem that this results in

[Intel-gfx] [PATCH] drm/atomic-helper: Skip vblank waits for unchanged fbs

2014-11-24 Thread Daniel Vetter
Especially with legacy cursor ioctls existing userspace assumes that you can pile up lots of updates in one go. The super-proper way to support this would be a special commit mode which overwrites the last update. But getting there will be quite a bit of work. Meanwhile do what pretty much all the

Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context backing objects to GGTT on-demand

2014-11-24 Thread Daniel Vetter
On Mon, Nov 24, 2014 at 6:14 PM, Daniel, Thomas wrote: >> This patch here scored a regression (leak in the module unload path), please >> address it asap. Deadline for regressions should be 1 week, then I'll just >> drop >> the patch or apply the revert. That includes review and everything. >> >>

Re: [Intel-gfx] [PATCH] drm/i915: Handle runtime pm in the CRC setup code

2014-11-24 Thread Daniel Vetter
On Mon, Nov 24, 2014 at 4:36 PM, Damien Lespiau wrote: > On Mon, Nov 24, 2014 at 04:23:36PM +0100, Daniel Vetter wrote: >> The crc code doesn't handle anything really that could drop the >> register state (by design so that we have less complexity). Which >> means userspace may only start crc capt

[Intel-gfx] [PATCH 1/9] drm: add helper to get crtc timings (v4)

2014-11-24 Thread Matt Roper
From: Gustavo Padovan We need to get hdisplay and vdisplay in a few places so create a helper to make our job easier. v2 (by Matt): Use new stereo doubling function (suggested by Ville) v3 (by Matt): - Add missing kerneldoc (Daniel) - Use drm_mode_copy() (Jani) v4 (by Matt): - Drop stereo d

[Intel-gfx] [PATCH 2/9] drm/i915: remove intel_crtc_cursor_set_obj() (v5)

2014-11-24 Thread Matt Roper
From: Gustavo Padovan Merge it into the plane update_plane() callback and make other users use the update_plane() functions instead. The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj() so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane() and merge both

[Intel-gfx] [PATCH 6/9] drm/i915: Consolidate plane 'prepare' functions

2014-11-24 Thread Matt Roper
The 'prepare' step for all types of planes are pretty similar; consolidate the three 'prepare' functions into a single function. This paves the way for future integration with the atomic plane handlers. Note that we pull the 'wait for pending flips' functionality out of the primary plane's prepar

[Intel-gfx] [PATCH 8/9] drm/i915: Consolidate top-level .update_plane() handlers

2014-11-24 Thread Matt Roper
Our .update_plane() handlers do the same check/prepare/commit/cleanup steps regardless of plane type. Consolidate them all into a single function that calls check/commit through a vtable. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_display.c | 113 ++

[Intel-gfx] [PATCH 4/9] drm/i915: Introduce intel_prepare_cursor_plane()

2014-11-24 Thread Matt Roper
Primary and sprite planes have already been refactored to include a 'prepare' step which handles all the commit-time operations that could fail (i.e., pinning buffers and such). Refactor the cursor commit in a similar manner. For simplicity and consistency with other plane types, we also switch t

[Intel-gfx] [PATCH 0/9] i915 display refactoring (v3)

2014-11-24 Thread Matt Roper
Another iteration of the i915 display refactoring work, with a few additional patches added to the end which should help simplify the transition to the atomic plane helpers. The previous version of this patch series was posted here: http://lists.freedesktop.org/archives/intel-gfx/2014-November/0

[Intel-gfx] [PATCH 3/9] drm/i915: remove intel_pipe_set_base() (v4)

2014-11-24 Thread Matt Roper
From: Gustavo Padovan After some refactor intel_primary_plane_setplane() does the same as intel_pipe_set_base() so we can get rid of it and replace the calls with intel_primary_plane_setplane(). v2: take Ville's comments: - get the right arguments for update_plane() - use drm_crt

[Intel-gfx] [PATCH 9/9] drm/i915: Make all plane disables use 'update_plane'

2014-11-24 Thread Matt Roper
If we extend the commit_plane handlers for each plane type to be able to handle fb=0, then we can easily implement plane disable via the update_plane handler. The cursor plane already works this way, and this is the direction we need to go to integrate with the atomic plane handler. We can now ki

[Intel-gfx] [PATCH 5/9] drm/i915: Make intel_plane_state subclass drm_plane_state

2014-11-24 Thread Matt Roper
Reviewed-by: Bob Paauwe Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_display.c | 34 +- drivers/gpu/drm/i915/intel_drv.h | 3 +-- drivers/gpu/drm/i915/intel_sprite.c | 16 3 files changed, 26 insertions(+), 27 deletions(-) diff

[Intel-gfx] [PATCH 7/9] drm/i915: Consolidate plane 'cleanup' operations

2014-11-24 Thread Matt Roper
All plane update functions need to unpin the old framebuffer when flipping to a new one. Pull this logic into a separate function to ease the integration with atomic plane helpers. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_display.c | 57 ++-- driv

Re: [Intel-gfx] [PATCH] drm/i915/eDP: When enabling panel VDD cancel pending disable worker

2014-11-24 Thread Daniel Vetter
On Mon, Nov 24, 2014 at 5:56 PM, Egbert Eich wrote: > Before testing if the panel VDD is enabled on eDP cancel any pending > disable worker. This makes sure the worker doesn't fire when we expect > VDD to be enabled. > > https://bugs.freedesktop.org/show_bug.cgi?id=86201 > > Signed-off-by: Egbert

[Intel-gfx] [PATCH] drm/atomic-helper: Skip vblank waits for unchanged fbs

2014-11-24 Thread Daniel Vetter
Especially with legacy cursor ioctls existing userspace assumes that you can pile up lots of updates in one go. The super-proper way to support this would be a special commit mode which overwrites the last update. But getting there will be quite a bit of work. Meanwhile do what pretty much all the

[Intel-gfx] [PATCH v3 01/28] drm/i915: Ensure OLS & PLR are always in sync

2014-11-24 Thread John . C . Harrison
From: John Harrison The aim is to replace seqno values with request structures. A step along the way is to switch to using the PLR in preference to the OLS. That requires the PLR to only be valid when and only when the OLS is also valid. I.e., the two must be kept in lock step. Then, code which w

Re: [Intel-gfx] [PATCH] drm/i915/eDP: When enabling panel VDD cancel pending disable worker

2014-11-24 Thread Egbert Eich
Ville Syrjälä writes: > On Mon, Nov 24, 2014 at 07:32:49PM +0200, Ville Syrjälä wrote: > > On Mon, Nov 24, 2014 at 05:56:20PM +0100, Egbert Eich wrote: > > > Before testing if the panel VDD is enabled on eDP cancel any pending > > > disable worker. This makes sure the worker doesn't fire when w

[Intel-gfx] [PATCH v3 05/28] drm/i915: Convert i915_gem_ring_throttle to use requests

2014-11-24 Thread John . C . Harrison
From: John Harrison Convert the throttle code to use the request structure rather than extracting a ring/seqno pair from it and using those. This is in preparation for __wait_seqno() becoming __wait_request(). For: VIZ-4377 Signed-off-by: John Harrison Reviewed-by: Thomas Daniel --- drivers/

[Intel-gfx] [PATCH v3 07/28] drm/i915: Remove 'outstanding_lazy_seqno'

2014-11-24 Thread John . C . Harrison
From: John Harrison The OLS value is now obsolete. Exactly the same value is guarateed to be always available as PLR->seqno. Thus it is safe to remove the OLS completely. And also to rename the PLR to OLR to keep the 'outstanding lazy ...' naming convention valid. For: VIZ-4377 Signed-off-by: Jo

[Intel-gfx] [PATCH v3 25/28] drm/i915: Interrupt driven request completion

2014-11-24 Thread John . C . Harrison
From: John Harrison Added a hook to the ring noftification code to process request completion. This means that there is no longer a need to explicitly process request completions every time a request object is tested. Instead, the test code simply becomes 'return req->completed'. Obviously, this

[Intel-gfx] [PATCH v3 17/28] drm/i915: Convert 'trace_irq' to use requests rather than seqnos

2014-11-24 Thread John . C . Harrison
From: John Harrison Updated the trace_irq code to use requests instead of seqnos. This includes reference counting the request object to ensure it sticks around when required. Note that getting access to the reference counting functions means moving the inline i915_trace_irq_get() function from i

[Intel-gfx] [PATCH v3 27/28] drm/i915: Add unique id to the request structure for debugging

2014-11-24 Thread John . C . Harrison
From: John Harrison For debugging purposes, it is useful to be able to uniquely identify a given request structure as it works its way through the system. This becomes especially tricky once the seqno value is lazily allocated as then the request has nothing but its pointer to identify it for muc

[Intel-gfx] [PATCH v3 08/28] drm/i915: Make 'i915_gem_check_olr' actually check by request not seqno

2014-11-24 Thread John . C . Harrison
From: John Harrison Updated the _check_olr() function to actually take a request object and compare it to the OLR rather than extracting seqnos and comparing those. Note that there is one use case where the request object being processed is no longer available at that point in the call stack. He

[Intel-gfx] [PATCH v3 21/28] drm/i915: Remove the now redundant 'obj->ring'

2014-11-24 Thread John . C . Harrison
From: John Harrison The ring member of the object structure was always updated with the last_read_seqno member. Thus with the conversion to last_read_req, obj->ring is now a direct copy of obj->last_read_req->ring. This makes it somewhat redundant and potentially misleading (especially as there w

[Intel-gfx] [PATCH v3 06/28] drm/i915: Ensure requests stick around during waits

2014-11-24 Thread John . C . Harrison
From: John Harrison Added reference counting of the request structure around __wait_seqno() calls. This is a precursor to updating the wait code itself to take the request rather than a seqno. At that point, it would be a Bad Idea for a request object to be retired and freed while the wait code i

[Intel-gfx] [PATCH v3 16/28] drm/i915: Convert trace functions from seqno to request

2014-11-24 Thread John . C . Harrison
From: John Harrison All the code above is now using requests not seqnos so it is possible to convert the trace functions across. Note that rather than get into problematic reference counting issues, the trace code only saves the seqno and ring values from the request structure not the structure p

[Intel-gfx] [PATCH v3 11/28] drm/i915: Add IRQ friendly request deference facility

2014-11-24 Thread John . C . Harrison
From: John Harrison The next patches in the series convert some display related seqno usage to request structure usage. However, the request dereference introduced must be done from interrupt context. As the dereference potentially involves freeing the request structure and thus calling lots of n

[Intel-gfx] [PATCH v3 19/28] drm/i915: Connect requests to rings at creation not submission

2014-11-24 Thread John . C . Harrison
From: John Harrison It makes a lot more sense (and makes future seqno -> request conversion patches simpler) to fill in the 'ring' field of the request structure at the point of creation rather than submission. Given that the request structure is assigned by ring specific code and thus is locked

[Intel-gfx] [PATCH v3 02/28] drm/i915: Add reference count to request structure

2014-11-24 Thread John . C . Harrison
From: John Harrison The plan is to use request structures everywhere that seqno values were previously used. This means saving pointers to structures in places that used to be simple integers. In turn, that means that the target structure now needs much more stringent lifetime tracking. That is,

[Intel-gfx] [PATCH v3 18/28] drm/i915: Convert 'ring_idle()' to use requests not seqnos

2014-11-24 Thread John . C . Harrison
From: John Harrison More seqno value to request structure conversions. Note, this change temporarily moves the 'get_seqno()' call inside ring_idle() but this will disappear again in a later patch when i915_seqno_passed() itself is converted. For: VIZ-4377 Signed-off-by: John Harrison Reviewed-b

[Intel-gfx] [PATCH v3 14/28] drm/i915: Remove obsolete seqno parameter from 'i915_add_request'

2014-11-24 Thread John . C . Harrison
From: John Harrison There is no longer any need to retrieve a seqno value from an i915_add_request() call. The calling code already knows which request structure is being processed (it can only be ring->OLR). And as the request itself is now used in preference to the basic seqno value, the latter

[Intel-gfx] [PATCH v3 13/28] drm/i915: Convert __wait_seqno() to __wait_request()

2014-11-24 Thread John . C . Harrison
From: John Harrison Now that all code above is using request structures instead of seqno values, it is possible to convert __wait_seqno() itself. Internally, it is still calling i915_seqno_passed(), this will be updated later in the series. This step is just changing the parameter list and funct

[Intel-gfx] [PATCH v3 26/28] drm/i915: Remove obsolete parameter to i915_gem_request_completed()

2014-11-24 Thread John . C . Harrison
From: John Harrison The request completion test no longer chains on to the request completion processing code. Thus it no longer needs to pass a 'lazy coherency' flag through to the seqno query call. Hence that parameter can be removed. For: VIZ-4377 Signed-off-by: John Harrison Reviewed-by: Th

[Intel-gfx] [PATCH v3 20/28] drm/i915: Convert 'i915_seqno_passed' calls into 'i915_gem_request_completed'

2014-11-24 Thread John . C . Harrison
From: John Harrison Almost everywhere that caled i915_seqno_passed() was really asking 'has the given seqno popped out of the hardware yet?'. Thus it had to query the current hardware seqno and then do a signed delta comparison (which copes with wrapping around zero but not with seqno values more

[Intel-gfx] [PATCH v3 09/28] drm/i915: Convert 'last_flip_req' to be a request not a seqno

2014-11-24 Thread John . C . Harrison
From: John Harrison Converted 'last_flip_req' to be an actual request rather than a seqno value as part of the on going seqno to request changes. This includes reference counting the request being saved away to ensure it can not be retired and freed while the overlay code is still waiting on it.

[Intel-gfx] [PATCH v3 22/28] drm/i915: Cache request completion status

2014-11-24 Thread John . C . Harrison
From: John Harrison Continuing the removal of seqno based operations - updated the request completion query to not simply chain on to i915_seqno_passed(). Instead, it now returns a pre-cached completion flag in the fast case. In the slow case it reads the hardware seqno and, only if it has moved

[Intel-gfx] [PATCH v3 15/28] drm/i915: Convert 'flip_queued_seqno' into 'flip_queued_request'

2014-11-24 Thread John . C . Harrison
From: John Harrison Converted the flip_queued_seqno value to be a request structure as part of the on going seqno to request changes. This includes reference counting the request being saved away to ensure it can not be retired and freed while the flip code is still waiting on it. For: VIZ-4377

[Intel-gfx] [PATCH v3 12/28] drm/i915: Convert mmio_flip::seqno to struct request

2014-11-24 Thread John . C . Harrison
From: John Harrison Converted the mmio_flip 'seqno' value to be a request structure as part of the on going seqno to request changes. This includes reference counting the request being saved away to ensure it can not be retired and freed while the flip code is still waiting on it. v2: Used the I

[Intel-gfx] [PATCH v3 23/28] drm/i915: Zero fill the request structure

2014-11-24 Thread John . C . Harrison
From: John Harrison There is a general theory that kzmalloc is better/safer than kmalloc, especially for interesting data structures. This change updates the request structure allocation to be zero filled. That also means it is no longer necessary to explicitly clear the 'complete' field. For: V

[Intel-gfx] [PATCH v3 10/28] drm/i915: Convert i915_wait_seqno to i915_wait_request

2014-11-24 Thread John . C . Harrison
From: John Harrison Updated i915_wait_seqno() to take a request structure instead of a seqno value and renamed it accordingly. Internally, it just pulls the seqno out of the request and calls on to __wait_seqno() as before. However, all the code further up the stack is now simplified as it can ju

[Intel-gfx] [PATCH v3 24/28] drm/i915: Spinlock protection for request list

2014-11-24 Thread John . C . Harrison
From: John Harrison The completion status for all entries in the request list is updated on demand. This occurs whenever the code queries the completion status of a given request and a new seqno value has popped out of the hardware. Unfortuntately, not all such queries are done with the driver mu

[Intel-gfx] [PATCH v3 28/28] drm/i915: Additional request structure tracing

2014-11-24 Thread John . C . Harrison
From: John Harrison Added the request structure's 'uniq' identifier to the trace information. Also renamed the '_complete' trace event to '_notify' as it actually happens in the IRQ 'notify_ring()' function. Additionally there is now a new '_complete' trace event which occurs when a request struc

[Intel-gfx] [PATCH v3 04/28] drm/i915: Replace last_[rwf]_seqno with last_[rwf]_req

2014-11-24 Thread John . C . Harrison
From: John Harrison The object structure contains the last read, write and fenced seqno values for use in syncrhonisation operations. These have now been replaced with their request structure counterparts. Note that to ensure that objects do not end up with dangling pointers, the assignments of

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Remove user pinning code

2014-11-24 Thread shuang . he
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform Delta drm-intel-nightly Series Applied PNV -2 367/367 3

[Intel-gfx] [PATCH v3 00/28] Replace seqno values with request structures

2014-11-24 Thread John . C . Harrison
From: John Harrison There is a general feeling that it is better to move away from using a simple integer 'seqno' value to track batch buffer completion. Instead, the request structure should be used. That provides for much more flexibility going forwards. Especially which things like a GPU sched

[Intel-gfx] [PATCH v3 03/28] drm/i915: Add helper functions to aid seqno -> request transition

2014-11-24 Thread John . C . Harrison
From: John Harrison Added helper functions for retrieving the ring and seqno entries from a request structure. This allows the internal workings of the request structure to be hidden from code that is using these. It also allows for useful workarounds/debug code to be added as or when necessary.

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Try to avoid pps_{lock, unlock}() on DP ports

2014-11-24 Thread Jani Nikula
On Mon, 24 Nov 2014, Egbert Eich wrote: > From: Ville Syrjälä > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_dp.c | 48 > - > 1 file changed, 28 insertions(+), 20 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/driver

Re: [Intel-gfx] [PATCH] drm/i915/eDP: When enabling panel VDD cancel pending disable worker

2014-11-24 Thread Ville Syrjälä
On Mon, Nov 24, 2014 at 07:32:49PM +0200, Ville Syrjälä wrote: > On Mon, Nov 24, 2014 at 05:56:20PM +0100, Egbert Eich wrote: > > Before testing if the panel VDD is enabled on eDP cancel any pending > > disable worker. This makes sure the worker doesn't fire when we expect > > VDD to be enabled. >

Re: [Intel-gfx] [PATCH] drm/i915/eDP: When enabling panel VDD cancel pending disable worker

2014-11-24 Thread Ville Syrjälä
On Mon, Nov 24, 2014 at 05:56:20PM +0100, Egbert Eich wrote: > Before testing if the panel VDD is enabled on eDP cancel any pending > disable worker. This makes sure the worker doesn't fire when we expect > VDD to be enabled. > > https://bugs.freedesktop.org/show_bug.cgi?id=86201 > > Signed-off-b

[Intel-gfx] [PATCH 0/5] drm/i915 Avoid long delays when reading EDID on eDP

2014-11-24 Thread Egbert Eich
For eDP in the Intel driver pps_lock()/unlock() need to be called before initiating an I2C/AUX channel transfer. These operations can be quite expensive - especially on values for HZ lower than 1000. It is therefore better to perfrom this locking/unlocking only

[Intel-gfx] [PATCH 5/5] drm/i915/eDP: Move pps_lock() and edp_panel_vdd_on() to top

2014-11-24 Thread Egbert Eich
On eDP each low level transfer is wrapped by pps_lock()/unlock() and edp_panel_vdd_on()/off(). Since PPS locking can be quite expensive and each call to master_xfer() or dpcd_access() may call these low level transfer functions many times it may introduce a considerable delay. Move locking/VDD enab

[Intel-gfx] [PATCH 1/5] drm/i915: Try to avoid pps_{lock, unlock}() on DP ports

2014-11-24 Thread Egbert Eich
From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dp.c | 48 - 1 file changed, 28 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 81f959d..a24c8cc7 100644 -

[Intel-gfx] [PATCH 4/5] drm/DP: Export drm_dp_dpcd_access() DP helper function

2014-11-24 Thread Egbert Eich
It may be required to wrap the generic DP DPCD transfer function to perfrom certain operations before of after this function is called. Signed-off-by: Egbert Eich --- drivers/gpu/drm/drm_dp_helper.c | 3 ++- include/drm/drm_dp_helper.h | 4 2 files changed, 6 insertions(+), 1 deletion(-

[Intel-gfx] [PATCH 2/5] drm/DP: Create pointer to generic DPCD access function

2014-11-24 Thread Egbert Eich
This way a driver can replace this function with its own version. Signed-off-by: Egbert Eich --- drivers/gpu/drm/drm_dp_helper.c | 5 +++-- include/drm/drm_dp_helper.h | 8 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/

[Intel-gfx] [PATCH 3/5] drm/DP: Export drm_dp_i2c_xfer() DP helper function

2014-11-24 Thread Egbert Eich
It may be required to wrap the generic DP I2C transfer function to perfrom certain operations before of after this function is called. Make this function available to the driver. Signed-off-by: Egbert Eich --- drivers/gpu/drm/drm_dp_helper.c | 3 ++- include/drm/drm_dp_helper.h | 2 ++ 2 fil

Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context backing objects to GGTT on-demand

2014-11-24 Thread Daniel, Thomas
> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Monday, November 24, 2014 2:25 PM > To: Daniel, Thomas > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context > backing obje

[Intel-gfx] [PATCH] drm/i915/eDP: When enabling panel VDD cancel pending disable worker

2014-11-24 Thread Egbert Eich
Before testing if the panel VDD is enabled on eDP cancel any pending disable worker. This makes sure the worker doesn't fire when we expect VDD to be enabled. https://bugs.freedesktop.org/show_bug.cgi?id=86201 Signed-off-by: Egbert Eich --- drivers/gpu/drm/i915/intel_dp.c | 1 + 1 file changed,

Re: [Intel-gfx] [PATCH] drm/i915: Disable the mmio.debug WARN after it

2014-11-24 Thread shuang . he
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform Delta drm-intel-nightly Series Applied PNV 367/367

[Intel-gfx] [PATCH v2 5/6] drm/i915: Grab modeset locks for GPU rest on pre-ctg

2014-11-24 Thread ville . syrjala
From: Ville Syrjälä On gen4 and earlier the GPU reset also resets the display, so we should protect against concurrent modeset operations. Grab all the modeset locks around the entire GPU reset dance, remebering first ti dislogde any pending page flip to make sure we don't deadlock. Any pageflip

[Intel-gfx] [PATCH 7/6] drm/i915: Deal with video overlay on GPU reset

2014-11-24 Thread ville . syrjala
From: Ville Syrjälä Clear the video overlay state on GPU reset. Any pending overlay request in the ring has been nuked, and the display itself gets reset. So we pretty much lose all state here. Adjust the software state to match so that the next "putimage" will restore things to working order. S

Re: [Intel-gfx] [PATCH] drm/i915: Disable the mmio.debug WARN after it fires

2014-11-24 Thread Paulo Zanoni
2014-11-24 9:07 GMT-02:00 Chris Wilson : > On Mon, Nov 24, 2014 at 12:52:23PM +0200, Jani Nikula wrote: >> On Mon, 24 Nov 2014, Chris Wilson wrote: >> > If we have a single unclaimed register, we will have lots. A WARN for >> > each one makes the machine unusable and does not aid debugging. Conver

[Intel-gfx] [PATCH] drm/i915: More cautious with pch fifo underruns

2014-11-24 Thread Daniel Vetter
Apparently PCH fifo underruns are tricky, we have plenty reports that we see the occasional underrun (especially at boot-up). So for a change let's see what happens when we don't re-enable pch fifo underrun reporting when the pipe is disabled. This means that the kernel can't catch pch fifo underr

[Intel-gfx] [PATCH] drm/i915: Drop vblank wait from intel_dp_link_down

2014-11-24 Thread Daniel Vetter
Nothing in Bspec seems to indicate that we actually needs this, and it looks like can't work since by this point the pipe is off and so vblanks won't really happen any more. Note that Bspec mentions that it takes a vblank for this bit to change, but _only_ when enabling. Dropping this code quench

Re: [Intel-gfx] [PATCH] drm/i915: Handle runtime pm in the CRC setup code

2014-11-24 Thread Damien Lespiau
On Mon, Nov 24, 2014 at 04:23:36PM +0100, Daniel Vetter wrote: > The crc code doesn't handle anything really that could drop the > register state (by design so that we have less complexity). Which > means userspace may only start crc capture once the pipe is fully set > up. > > With an i-g-t patch

[Intel-gfx] [PATCH] drm/i915: Handle runtime pm in the CRC setup code

2014-11-24 Thread Daniel Vetter
The crc code doesn't handle anything really that could drop the register state (by design so that we have less complexity). Which means userspace may only start crc capture once the pipe is fully set up. With an i-g-t patch this will be the case, but there's still the problem that this results in

[Intel-gfx] [PATCH i-g-t] lib/igt_debugfs: Don't setup crc in _new

2014-11-24 Thread Daniel Vetter
The problem is that this causes writes to registers, and if the pipe is off they might go nowhere (e.g. when runtime pm is enabled). Furthermore we can only really check once the modeset setup is done, but again most tests set up the CRC structure before calling igt_commit and friends. We could add

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Consolidate ring freespace calculations

2014-11-24 Thread Dave Gordon
On 24/11/14 10:04, Daniel Vetter wrote: > On Tue, Nov 18, 2014 at 08:07:22PM +, Dave Gordon wrote: >> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c >> b/drivers/gpu/drm/i915/intel_ringbuffer.c >> index ae09258..a08ae65 100644 >> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c >> +++ b/dri

Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context backing objects to GGTT on-demand

2014-11-24 Thread Daniel Vetter
On Thu, Nov 13, 2014 at 10:28:10AM +, Thomas Daniel wrote: > From: Oscar Mateo > > Up until now, we have pinned every logical ring context backing object > during creation, and left it pinned until destruction. This made my life > easier, but it's a harmful thing to do, because we cause fragm

Re: [Intel-gfx] [PATCH] drm/i915: Only warn the first time we attempt to mmio whilst suspended

2014-11-24 Thread Chris Wilson
On Mon, Nov 24, 2014 at 12:11:45PM -0200, Paulo Zanoni wrote: > 2014-11-24 6:03 GMT-02:00 Chris Wilson : > > In all likelihood we will do a few hundred errnoneous register > > operations if we do a single invalid register access whilst the device > > is suspended. As each instance causes a WARN, th

[Intel-gfx] [PATCH i-g-t] lib: fix igt_reset_connectors

2014-11-24 Thread Thomas Wood
Use igt_debugfs_open to open the connector file, since the forced_connectors array now only stores the connector path relative to the debugfs path. Also add some extra error checking to ensure a test failure if the reset fails. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85829 Signed-of

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Disallow pin ioctl completely for kms drivers

2014-11-24 Thread Chris Wilson
On Mon, Nov 24, 2014 at 03:10:05PM +0100, Daniel Vetter wrote: > On Mon, Nov 24, 2014 at 10:35:29AM +, Chris Wilson wrote: > > On Mon, Nov 24, 2014 at 11:30:24AM +0100, Daniel Vetter wrote: > > > The problem here is that SNA pins batchbuffers to etch out a bit more > > > performance. Iirc it st

Re: [Intel-gfx] [PATCH] drm/i915: Only warn the first time we attempt to mmio whilst suspended

2014-11-24 Thread Paulo Zanoni
2014-11-24 6:03 GMT-02:00 Chris Wilson : > In all likelihood we will do a few hundred errnoneous register > operations if we do a single invalid register access whilst the device > is suspended. As each instance causes a WARN, this floods the system > logs and can make the system unresponsive. > >

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Disallow pin ioctl completely for kms drivers

2014-11-24 Thread Daniel Vetter
On Mon, Nov 24, 2014 at 10:35:29AM +, Chris Wilson wrote: > On Mon, Nov 24, 2014 at 11:30:24AM +0100, Daniel Vetter wrote: > > The problem here is that SNA pins batchbuffers to etch out a bit more > > performance. Iirc it started out as a w/a for i830M (which we've > > implemented in the kernel

Re: [Intel-gfx] [RFC] drm/i915: Infrastructure for supporting different GGTT views per object

2014-11-24 Thread Daniel Vetter
On Mon, Nov 24, 2014 at 12:32:12PM +, Tvrtko Ursulin wrote: > > On 11/12/2014 05:02 PM, Daniel Vetter wrote: > >On Thu, Nov 06, 2014 at 02:39:25PM +, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>Things like reliable GGTT mmaps and mirrored 2d-on-3d display will need > >>to map

Re: [Intel-gfx] [PATCH] drm/i915: Only warn the first time we attempt

2014-11-24 Thread shuang . he
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform Delta drm-intel-nightly Series Applied PNV 367/367

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Grab modeset locks for GPU rest on pre-ctg

2014-11-24 Thread Ville Syrjälä
On Mon, Nov 24, 2014 at 10:34:42AM +0100, Daniel Vetter wrote: > On Fri, Nov 21, 2014 at 11:10:31PM +0200, Ville Syrjälä wrote: > > On Fri, Nov 21, 2014 at 09:49:21PM +0100, Daniel Vetter wrote: > > > On Fri, Nov 21, 2014 at 09:54:29PM +0200, ville.syrj...@linux.intel.com > > > wrote: > > > > + >

Re: [Intel-gfx] [RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support

2014-11-24 Thread Daniel Vetter
On Mon, Nov 24, 2014 at 10:55:46AM +0100, Thierry Reding wrote: > On Fri, Nov 21, 2014 at 09:36:33PM +0100, Daniel Vetter wrote: > > On Fri, Nov 21, 2014 at 09:27:04PM +0100, Thierry Reding wrote: > > > On Sat, Nov 22, 2014 at 03:10:01AM +0800, Yao Cheng wrote: > > > > on vlv, if ipvr is installed,

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Fix gen4 GPU reset

2014-11-24 Thread Ville Syrjälä
On Sat, Nov 22, 2014 at 11:05:15AM +, Chris Wilson wrote: > On Fri, Nov 21, 2014 at 09:54:25PM +0200, ville.syrj...@linux.intel.com wrote: > > + /* assert reset for at least 20 usec */ > > + pci_write_config_byte(dev->pdev, I965_GDRST, GRDOM_RESET_ENABLE); > > Is this an UC write or do we

Re: [Intel-gfx] [RFC] drm/i915: Infrastructure for supporting different GGTT views per object

2014-11-24 Thread Chris Wilson
On Mon, Nov 24, 2014 at 12:32:12PM +, Tvrtko Ursulin wrote: > > On 11/12/2014 05:02 PM, Daniel Vetter wrote: > >The change around finish_gtt is actually a leak since if the last view > >around is the rotate one (which can happen if userspace drops the buffer > >but leaves it displayed) we won'

Re: [Intel-gfx] [RFC] drm/i915: Infrastructure for supporting different GGTT views per object

2014-11-24 Thread Tvrtko Ursulin
On 11/12/2014 05:02 PM, Daniel Vetter wrote: On Thu, Nov 06, 2014 at 02:39:25PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Things like reliable GGTT mmaps and mirrored 2d-on-3d display will need to map objects into the same address space multiple times. This also means that objects no

  1   2   >