[Intel-gfx] [PATCH] drm/i915: Don't initialize pipe config after choosing DPLLs.

The pipe config needs to be initialized before calling crtc_compute_clock since this will update the new_config structure DPLL values. Initializing the new_config structure after calling crtc_compute_clock can result in incorrect timing values. This regression was introduced in commit 0dbdf89f27b

Re: [Intel-gfx] [PATCH] drm/i915: HSW/BDW PSR Set idle_frames=2 since sometimes it can be off by 1.

On Mon, Nov 3, 2014 at 9:25 AM, Runyan, Arthur J wrote: >>From: Daniel Vetter >> >>On Thu, Oct 30, 2014 at 05:35:55AM -0700, Rodrigo Vivi wrote: >>> It was identified that in some cases when moving cursor Hardware can do >>> mistake with idle_frame count. So Spec is being updated to use >>> 2 as m

[Intel-gfx] [PATCH 3/4] drm/i915: Introduce intel_psr.c

No functional changes. Just cleaning and reorganizing it. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/Makefile| 1 + drivers/gpu/drm/i915/intel_ddi.c | 4 +- drivers/gpu/drm/i915/intel_display.c | 2 +- drivers/gpu/drm/i915/intel_dp.c | 386 +--

[Intel-gfx] [PATCH 2/4] 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 4/4] drm/i915: Add PSR docbook

Let's document PSR a bit. No functional changes. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_psr.c | 58 1 file changed, 58 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 793f491..5f350

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

Let's use VBT + 1 now we parse it. v2: fix subject and consider that idle_frame = 2 is another fix. Cc: Arthur Runyan Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_dp.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/driv

Re: [Intel-gfx] [PATCH 2/2] It was identified that in some cases when moving cursor Hardware can do mistake with idle_frame count. So Spec is being updated to use 2 as minimum idle_frames.

oh! ugly! I forgot commit subject. Please ignore these 2 patches On Fri, Nov 7, 2014 at 2:15 PM, Rodrigo Vivi wrote: > v2: Use VBT + 1 as suggested by Arthur. So this patch depends on > PSR VBT block parsing. > > Reference: hsdhsw/4394433 > Cc: Arthur Runyan > Cc: Jani Nikula > Signed-off-by:

Re: [Intel-gfx] [PATCH v4 7/7] drm/i915: Tidy up execbuffer command

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=348/348->348/348 PNV: pass/total=325/328->324

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use efficient frequency for HSW/BDW

On Fri, Nov 07, 2014 at 10:41:26AM +, Chris Wilson wrote: > On Wed, Nov 05, 2014 at 05:31:34PM -0800, Tom.O'rou...@intel.com wrote: > > From: Tom O'Rourke > > > > Updated gen6|8_enable_rps() for Haswell and Broadwell > > to use the efficient frequency read from pcode. > > > > Added hsw_use_e

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use efficient frequency for HSW/BDW

On Fri, Nov 07, 2014 at 10:50:02AM +0100, Daniel Vetter wrote: > On Wed, Nov 05, 2014 at 05:31:34PM -0800, Tom.O'rou...@intel.com wrote: > > From: Tom O'Rourke > > > > Updated gen6|8_enable_rps() for Haswell and Broadwell > > to use the efficient frequency read from pcode. > > > > Added hsw_use_

[Intel-gfx] [PATCH v4 1/7] drm/i915: Implement a framework for batch buffer pools

From: Brad Volkin This adds a small module for managing a pool of batch buffers. The only current use case is for the command parser, as described in the kerneldoc in the patch. The code is simple, but separating it out makes it easier to change the underlying algorithms and to extend to future u

[Intel-gfx] [PATCH v4 5/7] drm/i915: Use batch length instead of object size in command parser

From: Brad Volkin Previously we couldn't trust the user-supplied batch length because it came directly from userspace (i.e. untrusted code). It would have affected what commands software parsed without regard to what hardware would actually execute, leaving a potential hole. With the parser now

[Intel-gfx] [PATCH v4 7/7] drm/i915: Tidy up execbuffer command parsing code

From: Brad Volkin Move it to a separate function since the main do_execbuffer function already has so much going on. Signed-off-by: Brad Volkin --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 136 + 1 file changed, 79 insertions(+), 57 deletions(-) diff --git a/dr

[Intel-gfx] [PATCH v4 6/7] drm/i915: Mark shadow batch buffers as purgeable

From: Brad Volkin By adding a new exec_entry flag, we cleanly mark the shadow objects as purgeable after they are on the active list. Signed-off-by: Brad Volkin --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/driver

[Intel-gfx] [PATCH v4 0/7] Command parser batch buffer copy

From: Brad Volkin This is v4 of the series I sent here: http://lists.freedesktop.org/archives/intel-gfx/2014-November/054733.html This version incorporates most of the feedback from v3. The couple of things that I missed (mostly for timing reasons) are: * Move 'pending_read_domains |= I915_GEM_D

[Intel-gfx] [PATCH v4 2/7] drm/i915: Use batch pools with the command parser

From: Brad Volkin This patch sets up all of the tracking and copying necessary to use batch pools with the command parser and dispatches the copied (shadow) batch to the hardware. After this patch, the parser is in 'enabling' mode. Note that performance takes a hit from the copy in some cases a

[Intel-gfx] [PATCH v4 4/7] drm/i915: Add batch pool details to i915_gem_objects debugfs

From: Brad Volkin To better account for the potentially large memory consumption of the batch pool. Signed-off-by: Brad Volkin --- drivers/gpu/drm/i915/i915_debugfs.c | 45 + 1 file changed, 36 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915

[Intel-gfx] [PATCH v4 3/7] drm/i915: Add a batch pool debugfs file

From: Brad Volkin It provides some useful information about the buffers in the global command parser batch pool. v2: rebase on global pool instead of per-ring pools v3: rebase Signed-off-by: Brad Volkin --- drivers/gpu/drm/i915/i915_debugfs.c | 41 + 1 fil

[Intel-gfx] [PATCH 2/2] It was identified that in some cases when moving cursor Hardware can do mistake with idle_frame count. So Spec is being updated to use 2 as minimum idle_frames.

v2: Use VBT + 1 as suggested by Arthur. So this patch depends on PSR VBT block parsing. Reference: hsdhsw/4394433 Cc: Arthur Runyan Cc: Jani Nikula Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_dp.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/

[Intel-gfx] [PATCH 1/2] 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] drm/i915: use compute_config in set_config v4

This will allow us to consult more info before deciding whether to flip or do a full mode set. v2: - don't use uninitialized or incorrect pipe masks in set_config failure path (Ander) v3: - fixup for pipe_config changes in compute_config (Jesse) v4: - drop spurious hunk in force restore

Re: [Intel-gfx] [PATCH 0/8] sanitize RPS interrupt enabling/disabling

2014-11-05 16:48 GMT-02:00 Imre Deak : > While fixing [1] I noticed that we can simplify a couple of things in > the RPS enabling/disabling code. So I did that and also fixed one WARN > that we can hit with some of the pm_rpm subtests. Hopefully these > changes also makes it clearer how we avoid th

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

Just try a 3.17 based kernel if you can. and make sure you have a new enough intel userspace driver. Dave. - Original Message - > From: "Michal Nazarewicz" > To: airl...@redhat.com > Cc: intel-gfx@lists.freedesktop.org > Sent: Saturday, 8 November, 2014 5:55:00 AM > Subject: drm-i915-m

Re: [Intel-gfx] [PATCH 66/89 v9] drm/i915/skl: Implementation of SKL DPLL programming

Hi With this and the other patches you resent, you can add "Reviewed-by: Paulo Zanoni " to patches 58, 59, 60, 61, 62 and 66. And I guess this makes the "clocks" part of the series complete and ready to merge. That said, this patch has some weird comment syntax on the comment that contains "Inter

[Intel-gfx] [PATCH 5/5] drm/i915: Improve PCBR debug information

From: Ville Syrjälä Always print the final PCBR register value on both vlv and chv, and also tell us whether the BIOS was a good citizen or not. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/

[Intel-gfx] [PATCH 2/5] drm/i915: Read the CCK fuse register from CCK

From: Ville Syrjälä When reading a CCK register we should obviously read it from CCK not Punit. This problem has been present ever since this of code was introduced in commit 67c3bf6f55a97a0915a0f9ea07278a3073cc9601 Author: Deepak S Date: Thu Jul 10 13:16:24 2014 +0530 drm/i915: popul

[Intel-gfx] [PATCH 0/5] drm/i915: Some VLV/CHV rc6/rps fixes/cleanups

From: Ville Syrjälä Here's a random collection of patches touching the vlv/chv rc6/rps code. The CCK fuse thing is the only fix here, the rest is mostly just me getting annoyed at stuff. Ville Syrjälä (5): drm/i915: Silence valleyview_set_rps() drm/i915: Read the CCK fuse register from CCK

[Intel-gfx] [PATCH 3/5] drm/i915: Add a name for the Punit GPLLENABLE bit

From: Ville Syrjälä Remove the magic number for the GPLLENABLE bit by adding a name for it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915

[Intel-gfx] [PATCH 1/5] drm/i915: Silence valleyview_set_rps()

From: Ville Syrjälä Even with the rps debug messages signficantly recuced by commit 67956867aa07c59d6d83628bbc9ee4bd9799a1e1 Author: Ville Syrjälä Date: Tue Sep 2 15:12:17 2014 +0300 drm/i915: Don't spam dmesg with rps messages on vlv/chv we still get an inordinate amount of spam fro

[Intel-gfx] [PATCH 4/5] drm/i915: Warn if GPLL isn't used on vlv/chv

From: Ville Syrjälä Our freq<->opcode conversions assume that GPLL is always used. Apparently that should be the case always, but let's scream if we ever encounter something different. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 6 ++ 1 file changed, 6 insertions(+)

Re: [Intel-gfx] [PATCH] drm/i915: Add the predicate source registers to the register whitelist

On Friday, November 07, 2014 03:34:31 PM Neil Roberts wrote: > The predicate source registers are needed to implement conditional > rendering without stalling. The two source registers are used to load > the previous values of the PS_DEPTH_COUNT register saved from > PIPE_CONTROL commands. These ca

[Intel-gfx] [PATCH v2] drm/i915: Add the predicate source registers to the register whitelist

The predicate source registers are needed to implement conditional rendering without stalling. The two source registers are used to load the previous values of the PS_DEPTH_COUNT register saved from PIPE_CONTROL commands. These can then be compared and used to set the predicate enable bit via the M

Re: [Intel-gfx] [PATCH] drm/i915: Reduce duplicated forcewake logic

On 07/11/14 15:46, Ville Syrjälä wrote: > On Wed, Sep 10, 2014 at 07:34:54PM +0100, Chris Wilson wrote: >> Introduce a structure to track the individual forcewake domains and use >> that to eliminated duplicate logic. >> --- >> drivers/gpu/drm/i915/i915_debugfs.c | 41 +++--- >> drivers/gpu/drm/i

Re: [Intel-gfx] [PATCH] drm/i915: Make sample_c messages go faster on Haswell.

On Wed, Oct 29, 2014 at 2:12 PM, Kenneth Graunke wrote: > Haswell significantly improved the performance of sampler_c messages, > but the optimization appears to be off by default. Later platforms > remove this bit, and apparently always enable the optimization. > > Improves performance in "Count

[Intel-gfx] [PATCH] drm/i915: Refactor gen6_gt_force_wake_{get, put}

This is largely for the benefit of TDR, which needs to be able to call the forcewake functions from a context where it must not sleep. Hence we split the forcewake {get,put} operations into inner core versions that don't include pm {get,put} calls, and outer wrappers that do. Callers of the existin

[Intel-gfx] Updated drm-intel-testing

Hi all, New -testing cycle with cool stuff: - 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 (

[Intel-gfx] [PATCH v6] drm/i915: Add tracepoints to track a vm during its lifetime

From: Daniele Ceraolo Spurio - ppgtt init/release: these tracepoints are useful for observing the creation and destruction of Full PPGTTs. - ctx create/free: we can use the ctx_free trace in combination with the ppgtt_release one to be sure that the ppgtt doesn't stay alive for too long af

Re: [Intel-gfx] [PATCH] drm/i915: Fix obj->map_and_fenceable across tiling changes

On Fri, 07 Nov 2014, Chris Wilson wrote: > On Fri, Nov 07, 2014 at 11:05:05AM +0100, Daniel Vetter wrote: >> On Thu, Nov 06, 2014 at 08:40:35AM +, Chris Wilson wrote: >> > As obj->map_and_fenceable computation has changed to only be set when >> > the object is bound inside the global GTT (and

Re: [Intel-gfx] [PATCH] drm/i915: Mark fastboot as unsafe

On Tue, Nov 04, 2014 at 03:29:57PM +0100, Daniel Vetter wrote: > Fastboot in its current incarnation assumes that the pfit isn't > relevatn for the state and that it can be disabled without restarting > the crtc. Unfortunately that's not the case on gen2/3 - it upsets the > hw and results in a blac

Re: [Intel-gfx] [PATCH 2/6] drm/i915: use compute_config in set_config v3

On Fri, 07 Nov 2014 11:41:48 +0200 Ander Conselvan de Oliveira wrote: > On 11/06/2014 12:26 AM, Jesse Barnes wrote: > > This will allow us to consult more info before deciding whether to flip > > or do a full mode set. > > > > v2: > >- don't use uninitialized or incorrect pipe masks in set_co

Re: [Intel-gfx] [PATCH] drm/i915: Add the predicate source registers to the register whitelist

On Fri, Nov 07, 2014 at 07:34:31AM -0800, Neil Roberts wrote: > The predicate source registers are needed to implement conditional > rendering without stalling. The two source registers are used to load > the previous values of the PS_DEPTH_COUNT register saved from > PIPE_CONTROL commands. These c

Re: [Intel-gfx] [PATCH] drm/i915: Reduce duplicated forcewake logic

On Wed, Sep 10, 2014 at 07:34:54PM +0100, Chris Wilson wrote: > Introduce a structure to track the individual forcewake domains and use > that to eliminated duplicate logic. > --- > drivers/gpu/drm/i915/i915_debugfs.c | 41 +++--- > drivers/gpu/drm/i915/i915_drv.h | 32 +++-- > drivers/gpu/d

[Intel-gfx] [PATCH] drm/i915: Add the predicate source registers to the register whitelist

The predicate source registers are needed to implement conditional rendering without stalling. The two source registers are used to load the previous values of the PS_DEPTH_COUNT register saved from PIPE_CONTROL commands. These can then be compared and used to set the predicate enable bit via the M

[Intel-gfx] [PATCH] tests/gem_reset_stats: add defer-hangcheck test

to see if one can fool hangcheck by keeping non hanging ring busy Cc: Chris Wilson Signed-off-by: Mika Kuoppala --- tests/gem_reset_stats.c | 43 +++ 1 file changed, 43 insertions(+) diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c index 3f

Re: [Intel-gfx] [PATCH] drm/i915: Don't continually defer the hangcheck

Chris Wilson writes: > On Fri, Nov 07, 2014 at 04:28:33PM +0200, Mika Kuoppala wrote: >> Chris Wilson writes: >> >> > With multiple rings, we may continue to render on the blitter whilst >> > executing an infinite shader on the render ring. As we currently, rearm >> > the timer with each execbu

Re: [Intel-gfx] [PATCH] Revert "drm/i915/vlv: Remove check for Old Ack during forcewake"

On 06/11/14 14:09, Daniel Vetter wrote: > On Wed, Nov 05, 2014 at 05:30:52PM +0200, Mika Kuoppala wrote: >> This reverts commit 5cb13c07dae73380d8b3ddc792740487b8742938. >> >> While the relevance for WaRsDontPollForAckOnClearingFWBits is under >> investigation, revert this as regression. >> >> Bugz

[Intel-gfx] [PATCH v4 1/4] drm/i915/bdw: Clean up execlist queue items in retire_work

No longer create a work item to clean each execlist queue item. Instead, move retired execlist requests to a queue and clean up the items during retire_requests. v2: Fix legacy ring path broken during overzealous cleanup v3: Update idle detection to take execlists queue into account v4: Grab exe

Re: [Intel-gfx] [PATCH] drm/i915: Don't continually defer the hangcheck

On Fri, Nov 07, 2014 at 04:28:33PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > With multiple rings, we may continue to render on the blitter whilst > > executing an infinite shader on the render ring. As we currently, rearm > > the timer with each execbuf, in this scenario the hangch

Re: [Intel-gfx] [PATCH] drm/i915: Don't continually defer the hangcheck

Chris Wilson writes: > With multiple rings, we may continue to render on the blitter whilst > executing an infinite shader on the render ring. As we currently, rearm > the timer with each execbuf, in this scenario the hangcheck will never > fire and we will never detect the lockup on the render r

Re: [Intel-gfx] [PATCH 72/89] drm/i915/skl: Enable/disable power well for aux transaction

On Fri, Nov 07, 2014 at 01:49:43PM +, Damien Lespiau wrote: > On Fri, Nov 07, 2014 at 03:31:20PM +0200, Ville Syrjälä wrote: > > On Fri, Nov 07, 2014 at 01:11:13PM +, Damien Lespiau wrote: > > > On Tue, Sep 16, 2014 at 04:19:07PM +0300, Imre Deak wrote: > > > > This patch needs to be rebase

Re: [Intel-gfx] [PATCH] drm: Per-plane locking

On Mon, Nov 03, 2014 at 12:07:02AM +0100, Daniel Vetter wrote: [...] > diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h > index 28931a23d96c..70595ff565ba 100644 > --- a/include/drm/drm_modeset_lock.h > +++ b/include/drm/drm_modeset_lock.h > @@ -127,11 +127,13 @@ void dr

Re: [Intel-gfx] [PATCH 72/89] drm/i915/skl: Enable/disable power well for aux transaction

On Fri, Nov 07, 2014 at 03:31:20PM +0200, Ville Syrjälä wrote: > On Fri, Nov 07, 2014 at 01:11:13PM +, Damien Lespiau wrote: > > On Tue, Sep 16, 2014 at 04:19:07PM +0300, Imre Deak wrote: > > > This patch needs to be rebased on the recent PPS changes at least > > > getting/putting the AUX power

Re: [Intel-gfx] [PATCH] drm/i915: Plug memory leak in intel_shared_dpll_start_config()

2014-11-07 10:07 GMT-02:00 Ander Conselvan de Oliveira : > The cleanup path would reset pll->new_config to NULL but wouldn't free > the allocated memory. Reviewed-by: Paulo Zanoni > > Signed-off-by: Ander Conselvan de Oliveira > > --- > drivers/gpu/drm/i915/intel_display.c | 1 + > 1 file cha

Re: [Intel-gfx] [PATCH 72/89] drm/i915/skl: Enable/disable power well for aux transaction

On Fri, Nov 07, 2014 at 01:11:13PM +, Damien Lespiau wrote: > On Tue, Sep 16, 2014 at 04:19:07PM +0300, Imre Deak wrote: > > This patch needs to be rebased on the recent PPS changes at least > > getting/putting the AUX power domain in pps_lock()/pps_unlock() too. > > Also it should be squashed

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Remove most INVALID_PIPE checks from the backlight code

On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Now that the backlight device no longer gets registered too early we > should be able to drop most of the INVALID_PIPE checks from the backlight > code. > > The only exceptio is the opregion stuff where we may (in

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915: Register the backlight device after the modeset init

On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Currently we register the backlight device as soon as we register the > connector. That means we can get backlight requests from userspace > already before reading out the current modeset hardware state. > > That m

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915: Skip .get_backlight() when backlight isn't enabled

On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > On VLV/CHV when the display is off, we can't read out the current > backlight level from the hardware since we have no pipe to do so. > Currently we end up reading a bigus register due to passing > INVALID_PIPE to

[Intel-gfx] [PATCH v2 6/6] drm/i915: Remove most INVALID_PIPE checks from the backlight code

From: Ville Syrjälä Now that the backlight device no longer gets registered too early we should be able to drop most of the INVALID_PIPE checks from the backlight code. The only exceptio is the opregion stuff where we may (in theory at least) get a request from the BIOS already during driver ini

[Intel-gfx] [PATCH v2 2/6] drm/i915: Skip .get_backlight() when backlight isn't enabled

From: Ville Syrjälä On VLV/CHV when the display is off, we can't read out the current backlight level from the hardware since we have no pipe to do so. Currently we end up reading a bigus register due to passing INVALID_PIPE to VLV_BLC_PWM_CTL(). Skip the entire .get_backlight() call if the back

[Intel-gfx] [PATCH v2 5/6] drm/i915: Register the backlight device after the modeset init

From: Ville Syrjälä Currently we register the backlight device as soon as we register the connector. That means we can get backlight requests from userspace already before reading out the current modeset hardware state. That means we don't yet know the current crtc->encoder->connector mapping, w

Re: [Intel-gfx] [PATCH 72/89] drm/i915/skl: Enable/disable power well for aux transaction

On Tue, Sep 16, 2014 at 04:19:07PM +0300, Imre Deak wrote: > This patch needs to be rebased on the recent PPS changes at least > getting/putting the AUX power domain in pps_lock()/pps_unlock() too. > Also it should be squashed into 69/89. Some more comments below. Hum, do we really need to hold a

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

On Fri, 2014-11-07 at 12:44 +, Chris Wilson wrote: > 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 no

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Remove most INVALID_PIPE checks from VLV backlight code

On Fri, Nov 07, 2014 at 02:24:46PM +0200, Jani Nikula wrote: > On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Now that the backlight device no longer gets registered too early we > > should be able to drop most of the INVALID_PIPE checks form the VLV/CHV

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

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 to be bound into the

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Register the backlight device after the modeset init

On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä Also, s/requestes/requests/g below. J. > Currently we register the backlight device as soon as we register the > connector. That means we can get backlight requestes from userspace > already before reading out the c

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Remove most INVALID_PIPE checks from VLV backlight code

On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Now that the backlight device no longer gets registered too early we > should be able to drop most of the INVALID_PIPE checks form the VLV/CHV > backlight code. The subject and this paragraph refer to VLV/CHV but

Re: [Intel-gfx] [PATCH 0/3] drm/i915/chv: Add new WA and remove pre-production ones

On Tue, Oct 28, 2014 at 06:33:11PM +, Arun Siluvery wrote: > The patches in this series adds two new workarounds for CHV and > removes pre-production ones. > > Based on review comments from Ville, add/remove patches are split-up > which helps in reverting them if required. > > The initial pat

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Register the backlight device after the modeset init

On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Currently we register the backlight device as soon as we register the > connector. That means we can get backlight requestes from userspace > already before reading out the current modeset hardware state. > > That

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

On Fri, Nov 7, 2014 at 1:10 PM, Chris Wilson wrote: > On Fri, Nov 07, 2014 at 01:00:32PM +0100, Sedat Dilek wrote: >> Here some numbers... >> >> $ diff -uprN benchmarks/x11perf-aa10text_no-wcmmap.txt >> benchmarks/x11perf-aa10text_wcmmap.txt >> --- benchmarks/x11perf-aa10text_no-wcmmap.txt 2014-

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

On Fri, Nov 07, 2014 at 01:00:32PM +0100, Sedat Dilek wrote: > Here some numbers... > > $ diff -uprN benchmarks/x11perf-aa10text_no-wcmmap.txt > benchmarks/x11perf-aa10text_wcmmap.txt > --- benchmarks/x11perf-aa10text_no-wcmmap.txt 2014-11-07 > 12:57:49.932264840 +0100 > +++ benchmarks/x11perf-a

[Intel-gfx] [PATCH] drm/i915: Plug memory leak in intel_shared_dpll_start_config()

The cleanup path would reset pll->new_config to NULL but wouldn't free the allocated memory. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_display.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel

Re: [Intel-gfx] [PATCH 72/89] drm/i915/skl: Enable/disable power well for aux transaction

On Tue, Sep 16, 2014 at 04:19:07PM +0300, Imre Deak wrote: > > @@ -1233,6 +1233,9 @@ static bool edp_panel_vdd_on(struct intel_dp > > *intel_dp) > > power_domain = intel_display_port_power_domain(intel_encoder); > > intel_display_power_get(dev_priv, power_domain); > > > > + power_domai

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Pass the current pipe from eDP init to backlight setup

On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > On VLV/CHV both pipes A and B have their own backlight control > registers. In order to correctly read out the current hardware state at > init we need to know which pipe is driving the eDP port. Pass that > inform

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

On Fri, Nov 7, 2014 at 12:14 PM, Chris Wilson wrote: > On Fri, Nov 07, 2014 at 11:59:26AM +0100, Sedat Dilek wrote: >> On Fri, Nov 7, 2014 at 11:43 AM, Chris Wilson >> wrote: >> > On Fri, Nov 07, 2014 at 11:35:01AM +0100, Sedat Dilek wrote: >> >> On Fri, Nov 7, 2014 at 11:29 AM, Chris Wilson >

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Don't deref NULL crtc in intel_get_pipe_from_connector()

On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > If the connector would have an encoder but the encoder didn't have a > crtc we might dereference a NULL crtc here. I suppose that should never > happen due to intel_sanitize_encoder(), but let's be a bit paranoid >

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Warn if trying to poke a VLV backlight on invalid pipe

On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > VLV/CHV have backlight controls only on pipes A and B. Bail out > without touching registers that don't exist, and print a warning. > > Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula > --- > drivers/gpu

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Catch INVALID_PIPE in vlv_get_backlight()

On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > When the display is off, we can't read out the current backlight level > from the hardware since we have no pipe to do so. Catch the INVALID_PIPE > in vlv_get_backlight() rather than pass it to VLV_BLC_PWM_CTL() wh

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

On Fri, Nov 07, 2014 at 11:59:26AM +0100, Sedat Dilek wrote: > On Fri, Nov 7, 2014 at 11:43 AM, Chris Wilson > wrote: > > On Fri, Nov 07, 2014 at 11:35:01AM +0100, Sedat Dilek wrote: > >> On Fri, Nov 7, 2014 at 11:29 AM, Chris Wilson > >> wrote: > >> > On Fri, Nov 07, 2014 at 11:08:41AM +0100,

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

On Fri, Nov 7, 2014 at 11:43 AM, Chris Wilson wrote: > On Fri, Nov 07, 2014 at 11:35:01AM +0100, Sedat Dilek wrote: >> On Fri, Nov 7, 2014 at 11:29 AM, Chris Wilson >> wrote: >> > On Fri, Nov 07, 2014 at 11:08:41AM +0100, Sedat Dilek wrote: >> >> Hi, >> >> >> >> I am playing with wc-mmap [1]...

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

On Fri, Nov 07, 2014 at 11:35:01AM +0100, Sedat Dilek wrote: > On Fri, Nov 7, 2014 at 11:29 AM, Chris Wilson > wrote: > > On Fri, Nov 07, 2014 at 11:08:41AM +0100, Sedat Dilek wrote: > >> Hi, > >> > >> I am playing with wc-mmap [1]... (and sent a trivial patch [0]). > >> > >> Inspecting my logs..

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use efficient frequency for HSW/BDW

On Wed, Nov 05, 2014 at 05:31:34PM -0800, Tom.O'rou...@intel.com wrote: > From: Tom O'Rourke > > Updated gen6|8_enable_rps() for Haswell and Broadwell > to use the efficient frequency read from pcode. > > Added hsw_use_efficient_freq() to read efficient > frequency (aka RPe) from pcode. The eff

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

On Fri, Nov 7, 2014 at 11:29 AM, Chris Wilson wrote: > On Fri, Nov 07, 2014 at 11:08:41AM +0100, Sedat Dilek wrote: >> Hi, >> >> I am playing with wc-mmap [1]... (and sent a trivial patch [0]). >> >> Inspecting my logs... >> >> $ egrep 'wc|mmap' >> logs/build-and-install-log_XF86-Video-Intel-v2-99

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

On Fri, Nov 07, 2014 at 11:08:41AM +0100, Sedat Dilek wrote: > Hi, > > I am playing with wc-mmap [1]... (and sent a trivial patch [0]). > > Inspecting my logs... > > $ egrep 'wc|mmap' > logs/build-and-install-log_XF86-Video-Intel-v2-99-916-137-g0aa2edb_WCMMAP_llvm-3-4-2.txt > Experimental supp

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Capture module params on hang

On Thu, Nov 06, 2014 at 11:13:33AM +, Chris Wilson wrote: > On Thu, Nov 06, 2014 at 01:03:47PM +0200, Mika Kuoppala wrote: > > @@ -1303,7 +1332,10 @@ void i915_capture_error_state(struct drm_device > > *dev, bool wedged, > > error->display = intel_display_capture_error_state(dev); > > >

Re: [Intel-gfx] [PATCH] drm/i915: Fix obj->map_and_fenceable across tiling changes

On Fri, Nov 07, 2014 at 11:05:05AM +0100, Daniel Vetter wrote: > On Thu, Nov 06, 2014 at 08:40:35AM +, Chris Wilson wrote: > > As obj->map_and_fenceable computation has changed to only be set when > > the object is bound inside the global GTT (and is suitable aligned to a > > fence region) we n

Re: [Intel-gfx] [PATCH 12/17] drm/atomic: Integrate fence support

On Sun, Nov 02, 2014 at 02:19:25PM +0100, Daniel Vetter wrote: > This patch is for enabling async commits. It replaces an earlier > approach which added an async boolean paramter to the ->prepare_fb > callbacks. The idea is that prepare_fb picks up the right fence to > synchronize against, which is

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

Hi, I am playing with wc-mmap [1]... (and sent a trivial patch [0]). Inspecting my logs... $ egrep 'wc|mmap' logs/build-and-install-log_XF86-Video-Intel-v2-99-916-137-g0aa2edb_WCMMAP_llvm-3-4-2.txt Experimental support: TearFree mmap(wc) $ egrep -i 'wc|mmap|write|comb' /var/log/Xorg.0.log [ E

Re: [Intel-gfx] [PATCH] sna: wc-mmap: Fix warning in configure

On Fri, Nov 07, 2014 at 10:54:18AM +0100, Sedat Dilek wrote: > This fixes the following warning due to a typo: > > configure: WARNING: unrecognized options: --enable-wc-map > Signed-off-by: Sedat Dilek Thank you, pushed. -Chris -- Chris Wilson, Intel Open Source Technology Centre _

Re: [Intel-gfx] [PATCH] drm/i915: Fix obj->map_and_fenceable across tiling changes

On Thu, Nov 06, 2014 at 08:40:35AM +, Chris Wilson wrote: > As obj->map_and_fenceable computation has changed to only be set when > the object is bound inside the global GTT (and is suitable aligned to a > fence region) we need to accommodate those changes when the tiling is > adjusted. The eas

[Intel-gfx] [PATCH] sna: wc-mmap: Fix warning in configure

This fixes the following warning due to a typo: configure: WARNING: unrecognized options: --enable-wc-map Signed-off-by: Sedat Dilek --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index e5877c8..328b4e9 100644 --- a/configure.ac +

Re: [Intel-gfx] [PATCH] drm/i915: Disable caches for Global GTT.

On Fri, Nov 07, 2014 at 10:33:10AM +0100, Daniel Vetter wrote: > tbh I'm not sure any more whether we still need this on vlv/chv - they did > change the snooping logic a lot. Iirc pre-gen5 only could snoop with the > blitter, vlv/chv can also snoop with the render engine. So maybe this has > improv

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use efficient frequency for HSW/BDW

On Wed, Nov 05, 2014 at 05:31:34PM -0800, Tom.O'rou...@intel.com wrote: > From: Tom O'Rourke > > Updated gen6|8_enable_rps() for Haswell and Broadwell > to use the efficient frequency read from pcode. > > Added hsw_use_efficient_freq() to read efficient > frequency (aka RPe) from pcode. The eff

[Intel-gfx] [PATCH] drm/i915: Don't continually defer the hangcheck

With multiple rings, we may continue to render on the blitter whilst executing an infinite shader on the render ring. As we currently, rearm the timer with each execbuf, in this scenario the hangcheck will never fire and we will never detect the lockup on the render ring. Instead, only arm the time

Re: [Intel-gfx] [PATCH v3 2/5] drm/i915: Use batch pools with the command parser

On Thu, Nov 06, 2014 at 09:38:00AM -0800, Volkin, Bradley D wrote: > On Thu, Nov 06, 2014 at 05:56:36AM -0800, Daniel Vetter wrote: > > On Thu, Nov 06, 2014 at 07:36:55AM +, Chris Wilson wrote: > > > On Wed, Nov 05, 2014 at 02:42:00PM -0800, Volkin, Bradley D wrote: > > > > For this part, I've

Re: [Intel-gfx] [PATCH 2/6] drm/i915: use compute_config in set_config v3

On 11/06/2014 12:26 AM, Jesse Barnes wrote: This will allow us to consult more info before deciding whether to flip or do a full mode set. v2: - don't use uninitialized or incorrect pipe masks in set_config failure path (Ander) v3: - fixup for pipe_config changes in compute_config (Je

Re: [Intel-gfx] [PATCH 1/2] tests/gem_exec_parse: fix batch_len setting for cmd-crossing-page

On Thu, Nov 06, 2014 at 02:39:53PM -0800, Volkin, Bradley D wrote: > Ping on this series. They're related to the batch copy series, but > the changes are valid and tests should still pass even without the > kernel changes being merged. Merged - I kinda forgotten that you don't have commit access.

[Intel-gfx] [PATCH i-g-t] tests/gem_exec_parse: Go OCD about C-style comments

Cc: Brad Volkin Signed-off-by: Daniel Vetter --- tests/gem_exec_parse.c | 34 ++ 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c index e48b83a611b3..fff166a4954a 100644 --- a/tests/gem_exec_parse.c ++

Re: [Intel-gfx] [PATCH v3 2/5] drm/i915: Use batch pools with the command parser

On Thu, Nov 06, 2014 at 09:38:00AM -0800, Volkin, Bradley D wrote: > On Thu, Nov 06, 2014 at 05:56:36AM -0800, Daniel Vetter wrote: > > On Thu, Nov 06, 2014 at 07:36:55AM +, Chris Wilson wrote: > > > On Wed, Nov 05, 2014 at 02:42:00PM -0800, Volkin, Bradley D wrote: > > > > For this part, I've

Re: [Intel-gfx] [PATCH] drm/i915: Disable caches for Global GTT.

On Thu, Nov 06, 2014 at 10:53:00PM +0200, Ville Syrjälä wrote: > On Thu, Nov 06, 2014 at 09:09:52PM +0200, Ville Syrjälä wrote: > > On Thu, Nov 06, 2014 at 10:55:12AM +, Chris Wilson wrote: > > > On Wed, Nov 05, 2014 at 12:11:41PM +0100, Daniel Vetter wrote: > > > > On Thu, Oct 30, 2014 at 5:18

Re: [Intel-gfx] [PATCH 02/10] drm/i915: VLV PSR: Status/enabled function.

On Tue, Oct 28, 2014 at 11:45:35AM -0700, Rodrigo Vivi wrote: > VLV PSR support PSR per pipe, including the status. So we have to check > if it is enabled per pipe on status. > > Signed-off-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_dp.c | 23 +-- > 1 file changed, 2

  1   2   >