Hi Dave -
Black screen, screen corruption, hardware state corruption fixes.
BR,
Jani.
The following changes since commit 0df1f2487d2f0d04703f142813d53615d62a1da4:
Linux 3.18-rc3 (2014-11-02 15:01:51 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
print a warning if we ever hit this
From: Ville Syrjälä ville.syrj...@linux.intel.com
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() which
would obviously end accessing
From: Ville Syrjälä ville.syrj...@linux.intel.com
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 means we don't yet know the current
From: Ville Syrjälä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_panel.c | 12
From: Ville Syrjälä ville.syrj...@linux.intel.com
This series tries to fix the initial backlight setup on VLV/CHV so that
we read out the hardware state from the correct pipe's BLC registers.
Makes for a better experience on BSW where the BIOS always uses pipe B
for the eDP port.
I also noticed
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
information down from the eDP init code into
From: Ville Syrjälä ville.syrj...@linux.intel.com
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.
If we still manage to get here with INVALID_PIPE we will now get a WARN
from the lower
Hi,
Am 06.11.2014 um 13:53 schrieb Jani Nikula:
root@kallisto:~# cat /sys/class/backlight/intel_backlight/bl_power
1
you echo 0 there?
:-) Works my display comes back, when I echo 0 there.
Is user-space doing something wrong here?
If the userspace wishes to switch off backlight, then
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 rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 23 +--
1
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 PM,
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 got an
Cc: Brad Volkin bradley.d.vol...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
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
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.
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
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 got an
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
On Wed, Nov 05, 2014 at 05:31:34PM -0800, Tom.O'rou...@intel.com wrote:
From: Tom O'Rourke Tom.O'rou...@intel.com
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
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
improved
This fixes the following warning due to a typo:
configure: WARNING: unrecognized options: --enable-wc-map
Signed-off-by: Sedat Dilek sedat.di...@gmail.com
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index e5877c8..328b4e9
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 easiest
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 sedat.di...@gmail.com
Thank you, pushed.
-Chris
--
Chris Wilson, Intel Open Source Technology
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
[
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
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 need to
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);
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 support:
On Fri, Nov 7, 2014 at 11:29 AM, Chris Wilson ch...@chris-wilson.co.uk 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'
On Wed, Nov 05, 2014 at 05:31:34PM -0800, Tom.O'rou...@intel.com wrote:
From: Tom O'Rourke Tom.O'rou...@intel.com
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
On Fri, Nov 07, 2014 at 11:35:01AM +0100, Sedat Dilek wrote:
On Fri, Nov 7, 2014 at 11:29 AM, Chris Wilson ch...@chris-wilson.co.uk
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
On Fri, Nov 7, 2014 at 11:43 AM, Chris Wilson ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk
wrote:
On Fri, Nov 07, 2014 at 11:08:41AM +0100, Sedat Dilek wrote:
Hi,
I am
On Fri, Nov 07, 2014 at 11:59:26AM +0100, Sedat Dilek wrote:
On Fri, Nov 7, 2014 at 11:43 AM, Chris Wilson ch...@chris-wilson.co.uk
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 ch...@chris-wilson.co.uk
wrote:
On Fri,
On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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ä
On Fri, Nov 7, 2014 at 12:14 PM, Chris Wilson ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk
wrote:
On Fri, Nov 07, 2014 at 11:35:01AM +0100, Sedat Dilek wrote:
On Fri, Nov
On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
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_domain =
The cleanup path would reset pll-new_config to NULL but wouldn't free
the allocated memory.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git
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
+++
On Fri, Nov 7, 2014 at 1:10 PM, Chris Wilson ch...@chris-wilson.co.uk 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
---
On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
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 patch can
On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
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
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ä ville.syrj...@linux.intel.com
Now that the backlight device no longer gets registered too early we
should be able to drop most of the INVALID_PIPE
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 not
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
On Fri, 07 Nov 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
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 into
2014-11-07 10:07 GMT-02:00 Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com:
The cleanup path would reset pll-new_config to NULL but wouldn't free
the allocated memory.
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Ander Conselvan de Oliveira
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 domain
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
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 rebased on the
Chris Wilson ch...@chris-wilson.co.uk 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
On Fri, Nov 07, 2014 at 04:28:33PM +0200, Mika Kuoppala wrote:
Chris Wilson ch...@chris-wilson.co.uk 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
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
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.
Bugzilla:
Chris Wilson ch...@chris-wilson.co.uk writes:
On Fri, Nov 07, 2014 at 04:28:33PM +0200, Mika Kuoppala wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
With multiple rings, we may continue to render on the blitter whilst
executing an infinite shader on the render ring. As we currently,
to see if one can fool hangcheck by keeping non hanging
ring busy
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
tests/gem_reset_stats.c | 43 +++
1 file changed, 43 insertions(+)
diff --git
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
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 +++--
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 can
On Fri, 07 Nov 2014 11:41:48 +0200
Ander Conselvan de Oliveira conselv...@gmail.com 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
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 black
From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com
- 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
On Fri, 07 Nov 2014, Chris Wilson ch...@chris-wilson.co.uk 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
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
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
On Wed, Oct 29, 2014 at 2:12 PM, Kenneth Graunke kenn...@whitecape.org 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
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 +++---
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
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 can
From: Ville Syrjälä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
---
From: Ville Syrjälä ville.syrj...@linux.intel.com
Remove the magic number for the GPLLENABLE bit by adding a name for it.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
2 files changed, 3
From: Ville Syrjälä ville.syrj...@linux.intel.com
Even with the rps debug messages signficantly recuced by
commit 67956867aa07c59d6d83628bbc9ee4bd9799a1e1
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date: Tue Sep 2 15:12:17 2014 +0300
drm/i915: Don't spam dmesg with rps
From: Ville Syrjälä ville.syrj...@linux.intel.com
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 deepa...@linux.intel.com
Date:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 8 ++--
1 file
Hi
With this and the other patches you resent, you can add Reviewed-by:
Paulo Zanoni paulo.r.zan...@intel.com 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
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 min...@mina86.com
To: airl...@redhat.com
Cc: intel-gfx@lists.freedesktop.org
Sent: Saturday, 8 November, 2014 5:55:00 AM
Subject:
2014-11-05 16:48 GMT-02:00 Imre Deak imre.d...@intel.com:
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
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
v2: Use VBT + 1 as suggested by Arthur. So this patch depends on
PSR VBT block parsing.
Reference: hsdhsw/4394433
Cc: Arthur Runyan arthur.j.run...@intel.com
Cc: Jani Nikula jani.nik...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 7 ++-
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 rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 16 ++
drivers/gpu/drm/i915/intel_bios.c
From: Brad Volkin bradley.d.vol...@intel.com
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 bradley.d.vol...@intel.com
---
From: Brad Volkin bradley.d.vol...@intel.com
To better account for the potentially large memory consumption
of the batch pool.
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 45 +
1 file changed, 36
From: Brad Volkin bradley.d.vol...@intel.com
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 bradley.d.vol...@intel.com
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 ++-
1 file changed,
From: Brad Volkin bradley.d.vol...@intel.com
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
From: Brad Volkin bradley.d.vol...@intel.com
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: Brad Volkin bradley.d.vol...@intel.com
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
From: Brad Volkin bradley.d.vol...@intel.com
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
From: Brad Volkin bradley.d.vol...@intel.com
Move it to a separate function since the main do_execbuffer function
already has so much going on.
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 136 +
1 file
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 Tom.O'rou...@intel.com
Updated gen6|8_enable_rps() for Haswell and Broadwell
to use the efficient frequency read from pcode.
1 - 100 of 109 matches
Mail list logo
