[Intel-gfx] [PATCH] drm/i915: WaSetupGtModeTdRowDispatch:snb

This reverts commit 8d85d27281095e4df6eb97ae84326b5814337337 Author: Ville Syrjälä Date: Tue Feb 4 21:59:15 2014 +0200 drm/i915: Fix SNB GT_MODE register setup Reported-by: Leo Wolf Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79996 Cc: sta...@vger.kernel.org Signed-off-by: Dan

[Intel-gfx] [PATCH] drm/i915: Kick fbdev before vgacon

It's magic, but it seems to work. This fixes a regression introduced in commit 1bb9e632a0aeee1121e652ee4dc80e5e6f14bcd2 Author: Daniel Vetter Date: Tue Jul 8 10:02:43 2014 +0200 drm/i915: Only unbind vgacon, not other console drivers My best guess is that the vga fbdev driver falls over

Re: [Intel-gfx] [PATCH 1/4] drm/i915: preserve SSC if previously set v3

On Thu, Nov 13, 2014 at 10:42:20AM +0200, Jani Nikula wrote: > On Thu, 09 Oct 2014, Jesse Barnes wrote: > > Some machines may have a broken VBT or no VBT at all, but we still want > > to use SSC there. So check for it and keep it enabled if we see it > > already on. Based on an earlier fix from

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Switch plane handling to atomic helpers

On Thu, Nov 13, 2014 at 10:43:25AM -0800, Matt Roper wrote: > Now that we have hooks to enable the atomic plane helpers, we can use > the plane helpers for our .update_plane() and .disable_plane() > entrypoints. > > Even though we'd already refactored our plane handling code into > check/commit, w

Re: [Intel-gfx] [PATCH] drm/i915: Kick fbdev before vgacon

On Fri, Nov 14, 2014 at 10:09:49AM +0100, Daniel Vetter wrote: > It's magic, but it seems to work. > > This fixes a regression introduced in > > commit 1bb9e632a0aeee1121e652ee4dc80e5e6f14bcd2 > Author: Daniel Vetter > Date: Tue Jul 8 10:02:43 2014 +0200 > > drm/i915: Only unbind vgacon,

Re: [Intel-gfx] [PATCH 04/10] drm/i915: PSR VLV/CHV: Introduce setup, enable and disable functions

On Thu, Nov 13, 2014 at 07:33:21PM -0500, Rodrigo Vivi wrote: > On Thu, Nov 6, 2014 at 1:32 PM, R, Durgadoss wrote: > > I see we are keeping the source active during PSR. > > Making this '0' may provide better power savings, > > but we need to manage a lot of hassle during PSR exit.. > > (like Lin

Re: [Intel-gfx] sna: Experimental support for write-combining mmaps (wc-mmap)

On Thu, Nov 13, 2014 at 04:28:46PM +0100, Sedat Dilek wrote: > Hi, > > what is the status of drm-intel-wc-mmap patchset (#2 + #3)? > I have refreshed them on top of drm-intel-coherent-phys-gtt patch (#1). > Playing with that againt Linux v3.18-rc4. Waiting for the misssing testcases and remainig

Re: [Intel-gfx] [PATCH] drm/i915: remove the unnecessary block around

On Wed, Nov 12, 2014 at 12:03:26PM -0800, shuang...@intel.com wrote: > Tested-By: PRC QA PRTS (Patch Regression Test System Contact: > shuang...@intel.com) > -Summary- > Platform: baseline_drm_intel_nightly_pass_rate->patch_ap

Re: [Intel-gfx] [PATCH v3 2/8] drm/i915: Adds graphic address space ballooning logic

On Thu, Nov 13, 2014 at 08:02:43PM +0800, Yu Zhang wrote: > + if (low_gm_base < ggtt_vm->start > + || low_gm_end > dev_priv->gtt.mappable_end > + || high_gm_base < dev_priv->gtt.mappable_end > + || high_gm_end > ggtt_vm_end) { Nit: Logical operators like || or && should

Re: [Intel-gfx] sna: Experimental support for write-combining mmaps (wc-mmap)

On Fri, Nov 14, 2014 at 11:04 AM, Daniel Vetter wrote: > On Thu, Nov 13, 2014 at 04:28:46PM +0100, Sedat Dilek wrote: >> Hi, >> >> what is the status of drm-intel-wc-mmap patchset (#2 + #3)? >> I have refreshed them on top of drm-intel-coherent-phys-gtt patch (#1). >> Playing with that againt Linu

Re: [Intel-gfx] [PATCH v3 0/8] Add enlightenments for vGPU

On Thu, Nov 13, 2014 at 08:02:41PM +0800, Yu Zhang wrote: > Intel GVT-g (previously known as XenGT), is a complete GPU > virtualization solution with mediated pass-through for 4th > generation Intel Core processors - Haswell platform. This > technology presents a virtual full-fledged GPU to each Vi

Re: [Intel-gfx] [PATCH 00/10] SKL stage 1 part 3

On Thu, Nov 13, 2014 at 02:55:12PM +, Damien Lespiau wrote: > Another series of reviewed patches. This time SKL clocks minus DPLL0 (eDP) and > a extra small patch to not apply the HSW/BDW eDP link training W/A. Pulled them all in. Tbh I haven't fully cross-checked whether this will conflict wi

Re: [Intel-gfx] [PATCH 0/7] SKL stage 1 part 4 - loose ends

On Thu, Nov 13, 2014 at 05:51:45PM +, Damien Lespiau wrote: > A few misc patches for SKL. Two caveats: > > - drm/i915/skl: Use correct use counters for force wakes > > This patch fixes a problem, is reviewed, but there's a better solution being > proposed. The better solution doesn't seem t

Re: [Intel-gfx] [PATCH] drm/i915: Kick fbdev before vgacon

On Fri, Nov 14, 2014 at 09:47:57AM +, Chris Wilson wrote: > On Fri, Nov 14, 2014 at 10:09:49AM +0100, Daniel Vetter wrote: > > It's magic, but it seems to work. > > > > This fixes a regression introduced in > > > > commit 1bb9e632a0aeee1121e652ee4dc80e5e6f14bcd2 > > Author: Daniel Vetter > >

Re: [Intel-gfx] [PATCH] drm/i915: WaSetupGtModeTdRowDispatch:snb

On Fri, Nov 14, 2014 at 09:25:29AM +0100, Daniel Vetter wrote: > This reverts > > commit 8d85d27281095e4df6eb97ae84326b5814337337 > Author: Ville Syrjälä > Date: Tue Feb 4 21:59:15 2014 +0200 > > drm/i915: Fix SNB GT_MODE register setup I think you mean commit 6547fbdbfff62c99e4f7b4f985f

Re: [Intel-gfx] [PATCH] drm/i915: WaSetupGtModeTdRowDispatch:snb

On Fri, Nov 14, 2014 at 01:13:16PM +0200, Ville Syrjälä wrote: > On Fri, Nov 14, 2014 at 09:25:29AM +0100, Daniel Vetter wrote: > > This reverts > > > > commit 8d85d27281095e4df6eb97ae84326b5814337337 > > Author: Ville Syrjälä > > Date: Tue Feb 4 21:59:15 2014 +0200 > > > > drm/i915: Fix S

Re: [Intel-gfx] [PATCH] drm/i915: Kick fbdev before vgacon

On Fri, 14 Nov 2014, Daniel Vetter wrote: > It's magic, but it seems to work. > > This fixes a regression introduced in > > commit 1bb9e632a0aeee1121e652ee4dc80e5e6f14bcd2 > Author: Daniel Vetter > Date: Tue Jul 8 10:02:43 2014 +0200 > > drm/i915: Only unbind vgacon, not other console drive

Re: [Intel-gfx] [PATCH] drm/i915: WaSetupGtModeTdRowDispatch:snb

On Fri, 14 Nov 2014, Ville Syrjälä wrote: > On Fri, Nov 14, 2014 at 09:25:29AM +0100, Daniel Vetter wrote: >> This reverts >> >> commit 8d85d27281095e4df6eb97ae84326b5814337337 >> Author: Ville Syrjälä >> Date: Tue Feb 4 21:59:15 2014 +0200 >> >> drm/i915: Fix SNB GT_MODE register setup >

Re: [Intel-gfx] [PATCH 00/10] SKL stage 1 part 3

On Fri, Nov 14, 2014 at 11:20:36AM +0100, Daniel Vetter wrote: > On Thu, Nov 13, 2014 at 02:55:12PM +, Damien Lespiau wrote: > > Another series of reviewed patches. This time SKL clocks minus DPLL0 (eDP) > > and > > a extra small patch to not apply the HSW/BDW eDP link training W/A. > > Pulle

Re: [Intel-gfx] [PATCH] drm: Simplify return value handling in drm_crtc.c

On Wed, Nov 12, 2014 at 11:59:47AM +0100, Daniel Vetter wrote: > While looking through drm_crtc.c to double-check make locking changes > I've noticed that there's a few other places that would now benefit > from simplified return value handling. > > So let's flatten the control flow and replace an

Re: [Intel-gfx] [PATCH v3 0/8] Add enlightenments for vGPU

On 11/14/2014 6:17 PM, Daniel Vetter wrote: On Thu, Nov 13, 2014 at 08:02:41PM +0800, Yu Zhang wrote: Intel GVT-g (previously known as XenGT), is a complete GPU virtualization solution with mediated pass-through for 4th generation Intel Core processors - Haswell platform. This technology prese

Re: [Intel-gfx] [PATCH v3 2/8] drm/i915: Adds graphic address space ballooning logic

On 11/14/2014 6:16 PM, Daniel Vetter wrote: On Thu, Nov 13, 2014 at 08:02:43PM +0800, Yu Zhang wrote: + if (low_gm_base < ggtt_vm->start + || low_gm_end > dev_priv->gtt.mappable_end + || high_gm_base < dev_priv->gtt.mappable_end + || high_gm_end > ggtt_vm_en

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

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.

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

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 v2 06/28] drm/i915: Ensure requests stick around during waits

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 v2 11/28] drm/i915: Add IRQ friendly request deference facility

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 v2 05/28] drm/i915: Convert i915_gem_ring_throttle to use requests

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 --- drivers/gpu/drm/i915/i915_gem.c |

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

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

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

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 v2 17/28] drm/i915: Convert 'trace_irq' to use requests rather than seqnos

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 v2 02/28] drm/i915: Add reference count to request structure

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 v2 19/28] drm/i915: Connect requests to rings at creation not submission

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 v2 07/28] drm/i915: Remove 'outstanding_lazy_seqno'

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 v2 08/28] drm/i915: Make 'i915_gem_check_olr' actually check by request not seqno

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 v2 13/28] drm/i915: Convert __wait_seqno() to __wait_request()

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 v2 01/28] drm/i915: Ensure OLS & PLR are always in sync

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

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

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 v2 26/28] drm/i915: Remove obsolete parameter to i915_gem_request_completed()

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 --- drivers/gp

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

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 v2 22/28] drm/i915: Cache request completion status

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 v2 14/28] drm/i915: Remove obsolete seqno parameter from 'i915_add_request'

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 v2 18/28] drm/i915: Convert 'ring_idle()' to use requests not seqnos

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 --- drive

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

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 v2 15/28] drm/i915: Convert 'flip_queued_seqno' into 'flip_queued_request'

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 v2 12/28] drm/i915: Convert mmio_flip::seqno to struct request

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 v2 28/28] drm/i915: Additional request structure tracing

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 v2 24/28] drm/i915: Spinlock protection for request list

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 v2 20/28] drm/i915: Convert 'i915_seqno_passed' calls into 'i915_gem_request_completed'

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 v2 27/28] drm/i915: Add unique id to the request structure for debugging

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 v2 09/28] drm/i915: Convert 'last_flip_req' to be a request not a seqno

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 v2 25/28] drm/i915: Interrupt driven request completion

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] [QA 11/14 ww45] Testing report for `drm-intel-testing` (was: Updated -next)

Summary We covered the platform: Baswell, Broadwell, Baytrail, Haswell, Ivybridge, SandyBridge In this circle, 4 new bugs are filed: Bug 86270 - [BSW Regression] DP/HDMI call trace when pulgin Bug 86268

[Intel-gfx] [PATCH] drm/i915/skl: Fix big integer constant sparse warning

intel_ddi.c:955:41: sparse: constant 84 is so big it is long intel_ddi.c:955:53: sparse: constant 90 is so big it is long intel_ddi.c:955:65: sparse: constant 96 is so big it is long intel_ddi.c:1028:23: sparse: constant 96 is so big it is long intel_ddi.c:1031:23: s

Re: [Intel-gfx] [PATCH] drm/i915: WaSetupGtModeTdRowDispatch:snb

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate BYT: pass/total=290/291->290/291 PNV: pass/total=351/356->351

[Intel-gfx] [PATCH 2/3] drm/i915/dsi: add ports to intel_dsi to describe the ports being driven

Later on this can include multiple ports (e.g. (1 << PORT_A) | (1 << PORT_C)) to describe dual link DSI. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi.c | 7 +-- drivers/gpu/drm/i915/intel_dsi.h | 3 +++ 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/g

[Intel-gfx] [PATCH 0/3] BYT DSI Dual Link Support

Hi Shobhit and Gaurav - I've been pondering this whole MIPI DSI pipes vs. ports thing and discussing with Ville and others. Rather than try and fail in explaining the ideas, here are some concrete patches to describe what I'd like to be done first. The most important thing is that we don't confus

[Intel-gfx] [PATCH 3/3] drm/i915/dsi: an example how to handle dual link for each port

The same paradigm can be used all around. Certain places will need to special case "if (port == PORT_A)" in the loop, some other places will need to have some other special cases. However the idea should be future compatible. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi_cmd.c |

[Intel-gfx] [PATCH 1/3] drm/i915/dsi: clean up MIPI DSI pipe vs. port usage

MIPI DSI works on ports A and C, which map to pipes A and B, respectively. Things are going to get more complicated with the introduction of dual link DSI support, so clean up the register defines and code to match reality. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_reg.h | 30

[Intel-gfx] [PATCH] drm/i915/skl: Don't allow disabling ppgtt and execlists on gen9+

Running the driver without execlists and hence PPGTT (either aliasing or full) isn't a supported configuration on gen9+. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/i915_gem_gtt.c | 7 ++- drivers/gpu/drm/i915/intel_lrc.c| 3 +++ 2 files changed, 9 insertions(+), 1 deletion(-)

Re: [Intel-gfx] [PATCH] drm/i915: Kick fbdev before vgacon

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate BYT: pass/total=290/291->290/291 PNV: pass/total=351/356->356

Re: [Intel-gfx] drm-i915-mst + Ubuntu 14.04 + HP 840

> On Fri, Nov 07 2014, David Airlie wrote: >> Just try a 3.17 based kernel if you can. On Mon, Nov 10 2014, Michal Nazarewicz wrote: > I've tried with 3.17.2 and have similar results. …come to think of it, this is actually a regression. -- Best regards,

[Intel-gfx] [PATCH] drm/i915: s/MI_STORE_DWORD_IMM_GEN8/MI_STORE_DWORD_IMM_GEN4/

From: Ville Syrjälä MI_STORE_DWORD_IMM length has been the same ever since gen4. Rename the define to avoid potential confusion if someone tries to use this on pre-gen8. Also correct the comment on MI_MEM_VIRTUAL bit. It's present on 945,g33 and 965 only. Cc: Oscar Mateo Signed-off-by: Ville S

Re: [Intel-gfx] [PATCH] drm/i915/skl: Fix big integer constant sparse warning

On Fri, Nov 14, 2014 at 02:20:27PM +, Damien Lespiau wrote: > intel_ddi.c:955:41: sparse: constant 84 is so big it is long > intel_ddi.c:955:53: sparse: constant 90 is so big it is long > intel_ddi.c:955:65: sparse: constant 96 is so big it is long > intel_ddi.c:1028:23:

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

Hi Dave, drm-intel-next-2014-11-07: - skl watermarks code (Damien, Vandana, Pradeep) - reworked audio codec /eld handling code (Jani) - rework the mmio_flip code to use the vblank evade logic and wait for rendering using the standard wait_seqno interface (Ander) - skl forcewake support (Zhe Wang

Re: [Intel-gfx] [PATCH v3] drm/i915: Move to CPU domain in pwrite/pread

On Wed, Nov 12, 2014 at 11:47:14PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Currently it's possible to get visible cache dirt on scanout on LLC > machines when using pwrite on the future scanout bo if its cache_level > is already NONE. > > pwrite's "does this need cl

Re: [Intel-gfx] [PATCH] drm/i915/skl: Don't allow disabling ppgtt and execlists on gen9+

On Fri, Nov 14, 2014 at 03:05:59PM +, Damien Lespiau wrote: > Running the driver without execlists and hence PPGTT (either aliasing or > full) isn't a supported configuration on gen9+. > > Signed-off-by: Damien Lespiau Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Softwar

Re: [Intel-gfx] [Regression] 83f45fc turns machine's screen off

Hi Daniel, Thanks for your reply and very sorry for the belated reply, some gmail filtering issues... On Mon, Nov 10, 2014 at 10:19 PM, Daniel Vetter wrote: > Adding relevant mailing lists. > > > On Sat, Nov 8, 2014 at 7:34 PM, Emmanuel Benisty wrote: >> Hi, >> >> The following commit permanent

[Intel-gfx] [PATCH 1/4] drm/i915/skl: Remove spurious warn in get_ddi_pll()

When reading out a DDI config that uses a PLL that is not part of the shared_dpll scheme (DPLL0), it's totally normal to end up in the default: case of that switch. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/intel_display.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers

[Intel-gfx] [PATCH 3/4] drm/i915/skl: Use the pipe config DPLL tracking to query the link clock

Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/intel_ddi.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 596bdc1..b5a279a 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/dr

[Intel-gfx] [PATCH 2/4] drm/i915/skl: Set the eDP link rate on DPLL0

On SKL DPLL0 is used to derive CDCLK but can also be used to drive an eDP port (as long as we don't want SSC). DPLL0 is special enough to not be handled by the shared DPLL framework (drives CDCLK, not supposed to enable the HDMI mode), So we need to compute the configuration separately from the oth

[Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for eDP/DPLL0

Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/intel_ddi.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index b5a279a..924f1ec 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_

[Intel-gfx] [PATCH 0/4] SKL eDP clocks

The previous clock series didn't include the eDP side of it. This should address most of it, for now. Note that I have some issues with HBR2 and link training here and I'm trying to find more information about this. So depending on the configuration (number of lanes wired, panel bw) this series ma

Re: [Intel-gfx] [PATCH 13/14] drm/i915: Use vlv display irq setup code for chv

2014-10-31 8:04 GMT-02:00 Ville Syrjälä : > On Thu, Oct 30, 2014 at 06:41:11PM -0200, Paulo Zanoni wrote: >> 2014-10-30 15:43 GMT-02:00 : >> > From: Ville Syrjälä >> > >> > Throw away the hand rolled display irq setup code on chv, and instead >> > just call vlv_display_irq_postinstall() and vlv_d

Re: [Intel-gfx] [PATCH 14/14] drm/i915: Reinit display irqs and hpd from chv pipe-a power well

2014-10-30 15:43 GMT-02:00 : > From: Ville Syrjälä > > On chv the pipe-a power well is the new disp2d well, and it kills pretty > much everything in the display block. So we need to do the the same > dance that vlv does wrt. display irqs and hpd when the power well goes > up or down. I don't hav

Re: [Intel-gfx] [PATCH v3] drm/i915: Move to CPU domain in pwrite/pread

On Fri, Nov 14, 2014 at 05:00:59PM +, Chris Wilson wrote: > On Wed, Nov 12, 2014 at 11:47:14PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Currently it's possible to get visible cache dirt on scanout on LLC > > machines when using pwrite on the future scanout b

Re: [Intel-gfx] [PATCH 14/14] drm/i915: Reinit display irqs and hpd from chv pipe-a power well

On Fri, Nov 14, 2014 at 03:49:25PM -0200, Paulo Zanoni wrote: > 2014-10-30 15:43 GMT-02:00 : > > From: Ville Syrjälä > > > > On chv the pipe-a power well is the new disp2d well, and it kills pretty > > much everything in the display block. So we need to do the the same > > dance that vlv does wrt

[Intel-gfx] [PATCH] drm/i915: Fix comments about CHV snoop behaviour

From: Ville Syrjälä Replace the misinformed notes about CHV snoop behaviour with something that's hopefully closer to reality. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/dr

Re: [Intel-gfx] [PATCH] drm/i915: Fix comments about CHV snoop behaviour

On Fri, Nov 14, 2014 at 09:02:44PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Replace the misinformed notes about CHV snoop behaviour with something > that's hopefully closer to reality. > > Signed-off-by: Ville Syrjälä Queued for -next, thanks for the patch. -Daniel

Re: [Intel-gfx] [PATCH v2 28/28] drm/i915: Additional request structure

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate BYT: pass/total=290/291->290/291 PNV: pass/total=351/356->356

[Intel-gfx] [PATCH 13/15] drm/i915: VLV/CHV PSR: Increase wait delay time before active PSR.

Since active function on VLV immediately activate PSR let's give more time for idleness. v2: Rebase over intel_psr.c and fix typo. Cc: Durgadoss R Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_psr.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/

[Intel-gfx] [PATCH 06/15] drm/i915: PSR get full link off x standby from VBT

OEMs can specify if full_link might be always enabled, i.e. only_standby over VBT. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_psr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 576568

[Intel-gfx] [PATCH 01/15] drm/i915: Make dp aux pack/unpack public outside intel_dp.c

No functional change. Just making it public for use outside intel_dp.c Allowing split psr functions. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_dp.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/d

[Intel-gfx] [PATCH 11/15] drm/i915: PSR VLV/CHV: Introduce setup, enable and disable functions

The biggest difference from HSW/BDW PSR here is that VLV enable_source function enables PSR but let it in Inactive state. So it might be called on early stage along with setup and enable_sink ones. v2: Rebase over intel_psr.c; Remove docs from static functions; Merge vlv_psr_active_on_pipe

[Intel-gfx] [PATCH 04/15] drm/i915: Parse VBT PSR block.

PSR (aka SRD) block is defined at VBT and currently being used. Mainly/At-least to configure the amount of idle_frames require to get back to PSR Entry. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_drv.h | 16 ++ drivers/gpu/drm/i915/intel_bios.c | 45 +

[Intel-gfx] [PATCH 10/15] drm/i915: Add PSR registers for PSR VLV/CHV.

Baytrail (Valleyview) and Braswell (Cherryview) uses a complete different implementation of PSR that we currently have supported for Haswell and Broadwell. So let's start by adding registers definitions. I usually don't like commit that adds just registers without using, but after I put all in one

[Intel-gfx] [PATCH 15/15] drm/i915: Enable PSR for Baytrail and Braswell.

This patch is the last in series of VLV/CHV PSR, that finnaly enable psr by adding it to HAS_PSR and calling the proper enable and disable functions on the right places. Although it is still disabled by default. v2: Rebase over intel_psr and merge Durgadoss's fixes. Cc: Durgadoss R Signed-off-b

[Intel-gfx] [PATCH 02/15] drm/i915: Introduce intel_psr.c

No functional changes. Just cleaning and reorganizing it. v2: Rebase it puting it to begin of psr rework. This helps to blame easily at least latest changes. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/Makefile| 1 + drivers/gpu/drm/i915/intel_ddi.c | 4 +- driv

[Intel-gfx] [PATCH 08/15] drm/i915: remove PSR BDW single frame update.

Single frame update is a feature available on BDW for PSR that allows Source to send Sink only one frame and get it updated. Usually useful when page fliping. However with our frontbuffer tracking where we force psr exit on flips we don't need this feature. Also after it got added here many workar

[Intel-gfx] [PATCH 07/15] drm/i915: PSR skip aux on wake up as defined by VBT.

Let's always skip aux on exit unless specified at VBT we need it. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_psr.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index e706c9d..4cfe7a4 100

[Intel-gfx] [PATCH 05/15] drm/i915: HSW/BDW PSR Set idle_frames = VBT + 1

Let's use VBT + 1 now we parse it. v2: fix subject v3: rebase over intel_psr and without counting on previous fix Cc: Arthur Runyan Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_psr.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i

[Intel-gfx] [PATCH 03/15] drm/i915: Add PSR docbook

Let's document PSR a bit. No functional changes. v2: Add actual DocBook entry and accept Daniel's improvements. Cc: Daniel Vetter Signed-off-by: Rodrigo Vivi --- Documentation/DocBook/drm.tmpl | 5 +++ drivers/gpu/drm/i915/intel_psr.c | 73 2 files c

[Intel-gfx] [PATCH 14/15] drm/i915: VLV/CHV PSR debugfs.

Add debugfs support for Valleyview and Cherryview considering that we have PSR per pipe and we don't have any kind of performance counter as we have on other platforms that support PSR. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_debugfs.c | 34 +-

[Intel-gfx] [PATCH 12/15] drm/i915: VLV/CHV PSR Software timer mode

This patch introduces exit/activate functions for PSR on VLV+. Since on VLV+ HW cannot track frame updates and force PSR exit let's use fully SW tracking available. v2: Rebase over intel_psr.c; Remove Single Frame update transitioning from state 3 to 5 directly; Fake a software invalidatio

[Intel-gfx] [PATCH 09/15] drm/i915: Fix intel_psr_is_enabled function and document it.

This function can be used to check if psr feature got enabled. However on HSW and BDW we currently force psr exit by disabling EDP_PSR_ENABLE bit at EDP_PSR_CTL(dev). So this function was actually returning the active/inactive state that is different from the enable/disable meaning and had the risk

Re: [Intel-gfx] [PATCH] drm/i915/skl: Fix big integer constant sparse

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate BYT: pass/total=290/291->290/291 PNV: pass/total=351/356->356

Re: [Intel-gfx] [PATCH 3/3] drm/i915/dsi: an example how to handle dual

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate BYT: pass/total=290/291->290/291 PNV: pass/total=351/356->355

Re: [Intel-gfx] [PATCH] drm/i915:

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate BYT: pass/total=290/291->290/291 PNV: pass/total=352/356->356

Re: [Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for eDP/DPLL0

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate BYT: pass/total=290/291->290/291 PNV: pass/total=352/356->356