On Mon, Apr 08, 2013 at 06:49:42PM -0300, Rodrigo Vivi wrote:
This patch introduce Frame Buffer Compression (FBC) support for HSW.
It adds a new function haswell_enable_fbc to avoid getting
ironlake_enable_fbc messed with many IS_HASWELL checks.
Signed-off-by: Rodrigo Vivi
On Mon, Apr 08, 2013 at 06:49:44PM -0300, Rodrigo Vivi wrote:
Display register 46500h bit 23 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.
So should we enable it again after FBC is disabled to avoid wasting
power?
Signed-off-by: Rodrigo Vivi
From: Ville Syrjälä ville.syrj...@linux.intel.com
Increase the number of fence registers to 32 on IVB/HSW. VLV however
only has 16 fence registers according to the docs.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 6 +++---
From: Ville Syrjälä ville.syrj...@linux.intel.com
BSpec contains several scattered notes which state that the maximum
fence stride was increased to 256KB on IVB.
Testing on real hardware agrees.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
On Mon, Apr 08, 2013 at 06:43:49PM -0700, Ben Widawsky wrote:
This will allow us to read/write registers in GTT init.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_dma.c | 48
-
1 file changed, 24 insertions(+), 24
As we only update and sanitize the return timeout value after a
successful wait, we should not assert that it is valid for any error
returns. Also, for consistency, we should only modify args-timeout_ns
upon success.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Ben Widawsky
On Tue, Apr 09, 2013 at 09:58:15AM +0100, Chris Wilson wrote:
As we only update and sanitize the return timeout value after a
successful wait, we should not assert that it is valid for any error
returns. Also, for consistency, we should only modify args-timeout_ns
upon success.
Doesn't that
On Mon, Apr 08, 2013 at 06:43:56PM -0700, Ben Widawsky wrote:
From: Ben Widawsky benjamin.widaw...@intel.com
I'm really not happy that we have to support this, but this will be the
simplest way to handle cases where PPGTT init can fail, which I promise
will be coming in the future.
v2:
As we recompute the remaining timeout after waiting, there is a
potential for that timeout to be less than zero and so need sanitizing.
The timeout is always returned to userspace and validated, so we should
always perform the sanitation.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Ben
This set of patches contains the remaining bits to add IRQ strom detection and
disabling.
Daniel has asked me to send this batch as soon as possible even though this
latest batch has not yet been retested, yet.
Egbert Eich (7):
drm/i915: Add HPD IRQ storm detection (v4)
drm/i915: (re)init
From: Egbert Eich e...@suse.de
Add a hotplug IRQ storm detection (triggered when a hotplug interrupt
fires more than 5 times / sec).
Rationale:
Despite of the many attempts to fix the problem with noisy hotplug
interrupt lines we are still seeing systems which have issues:
Once cause of noise
From: Egbert Eich e...@suse.de
When an encoder is shared on several connectors there is only
one hotplug line, thus this line needs to be shared among these
connectors.
If HPD detect only works reliably on a subset of those connectors,
we want to poll the others. Thus we need to make sure that
From: Egbert Eich e...@suse.de
To disable previously enabled HPD IRQs we need to reset them and
set the enabled ones individually.
Signed-off-by: Egbert Eich e...@suse.de
---
drivers/gpu/drm/i915/i915_irq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c
From: Egbert Eich e...@suse.de
This way it is possible to limit 're'-detect() of displays to connectors
which have received an HPD event.
v2: Reordered drm_i915_private: Move hpd_event_bits to hpd state tracking.
Signed-off-by: Egbert Eich e...@suse.de
---
drivers/gpu/drm/i915/i915_drv.h | 1
From: Egbert Eich e...@suse.de
Instead of calling into the DRM helper layer to poll all connectors for
changes in connected displays probe only those connectors which have
received a hotplug event.
Signed-off-by: Egbert Eich e...@suse.de
---
drivers/gpu/drm/i915/i915_irq.c | 37
From: Egbert Eich e...@suse.de
We disable hoptplug detection when we encounter a hotplug event
storm. Still hotplug detection is required on some outputs (like
Display Port). The interrupt storm may be only temporary (on certain
Dell Laptops for instance it happens at certain charging states of
From: Egbert Eich e...@suse.de
This patch disables hotplug interrupts if an 'interrupt storm'
has been detected.
Noise on the interrupt line renders the hotplug interrupt useless:
each hotplug event causes the devices to be rescanned which will
will only increase the system load.
Thus disable the
On Tue, Apr 09, 2013 at 10:13:23AM +0100, Chris Wilson wrote:
As we recompute the remaining timeout after waiting, there is a
potential for that timeout to be less than zero and so need sanitizing.
The timeout is always returned to userspace and validated, so we should
always perform the
From: Ville Syrjälä ville.syrj...@linux.intel.com
Increase the number of fence registers to 32 on IVB/HSW. VLV however
only has 16 fence registers according to the docs.
Increasing the number of fences was attempted before [1], but there was
some uncertainty about the maximum CPU fence number
On Tue, Apr 09, 2013 at 11:45:05AM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
BSpec contains several scattered notes which state that the maximum
fence stride was increased to 256KB on IVB.
Testing on real hardware agrees.
On Tue, Apr 09, 2013 at 01:54:01PM +0200, Daniel Vetter wrote:
On Tue, Apr 09, 2013 at 11:45:05AM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
BSpec contains several scattered notes which state that the maximum
fence stride was increased
Since atm we don't take a reference on the dma buf pointer when we add
it to the import lookup table the dma buf can vanish leaving the stale
pointer behind. This can in turn lead to returning stale GEM handles
when userspace imports a newly exported buffer.
Fix this by keeping a reference on the
In commit be8a42ae60 we inroduced a refcount problem, where on the
drm_gem_prime_fd_to_handle() error path we'll call dma_buf_put() for
self imported dma buffers.
Fix this by taking a reference on the dma buffer in the .gem_import
hook instead of assuming the caller had taken one. Besides fixing
From: Ville Syrjälä ville.syrj...@linux.intel.com
lib/drmtest.c provides gem_available_fences(). Use it where
appropriate.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
tests/gem_fence_thrash.c | 8 ++--
tests/gem_fenced_exec_thrash.c | 8 ++--
tests/gem_stress.c
From: Ville Syrjälä ville.syrj...@linux.intel.com
gem_tiling_max_stride writes a data pattern to an X-tiled buffer using
the maximum supported stride, reads the data back as linear, and
verifies that the data didn't get scrambled on the way.
Signed-off-by: Ville Syrjälä
On Tue, Apr 09, 2013 at 03:25:37PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
IVB+ supports 32 fence registers, bump the maximum in the test.
Then again the test is only relevant for gen2/3 (and 1), and I don't
forsee the use of fences for
On Tue, Apr 09, 2013 at 03:25:39PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
gem_tiling_max_stride writes a data pattern to an X-tiled buffer using
the maximum supported stride, reads the data back as linear, and
verifies that the data
From: Ville Syrjälä ville.syrj...@linux.intel.com
gem_tiling_max_stride writes a data pattern to an X-tiled buffer using
the maximum supported stride, reads the data back as linear, and
verifies that the data didn't get scrambled on the way.
The test also checks that some invalid stride values
Ben Widawsky b...@bwidawsk.net writes:
Most importantly this will allow users to set overclock frequencies in
sysfs. Previously the max was limited by the RP0 max as opposed to the
overclock max. This is useful if one wants to either limit the max
overclock frequency, or set the minimum
Ben Widawsky b...@bwidawsk.net writes:
Requested-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/intel_pm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
Backlight cleanup in the eDP connector destroy callback caused the
backlight device to be removed on some systems that first initialized LVDS
and then attempted to initialize eDP. Prevent multiple backlight
initializations, and ensure backlight cleanup is only done once by moving
it to modeset
On Tue, Apr 09, 2013 at 04:41:42PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
gem_tiling_max_stride writes a data pattern to an X-tiled buffer using
the maximum supported stride, reads the data back as linear, and
verifies that the data
Hi,
For various reasons, I'm trying to build an Intel driver to run on a QM67
system but with Ubuntu 8.04.4
Kernel 2.6.24-32-generic
Intel 2010Q4
Basically, I've got other hardware depending on Ubuntu 8.04 as the
manufacturer stopped supporting Linux at that point.
The question is am I wasting
From: Ville Syrjälä ville.syrj...@linux.intel.com
gem_tiling_max_stride writes a data pattern to an X-tiled buffer using
the maximum supported stride, reads the data back as linear, and
verifies that the data didn't get scrambled on the way.
The test also checks that some invalid stride values
From: Ville Syrjälä ville.syrj...@linux.intel.com
Our checks for an invalid fence stride forgot to guard against
zero stride on gen4+. Fix it.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_gem_tiling.c | 2 ++
1 file changed, 2 insertions(+)
diff
Hi
2013/4/9 Jani Nikula jani.nik...@intel.com:
Workaround to avoid intermittent aux channel failures, per spec change.
v2: Don't mess with cpu dp aux divider (Paulo Zanoni)
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
Untested.
---
drivers/gpu/drm/i915/intel_dp.c |8
On Tue, Apr 09, 2013 at 11:49:45AM -0300, Paulo Zanoni wrote:
Hi
2013/4/9 Jani Nikula jani.nik...@intel.com:
Workaround to avoid intermittent aux channel failures, per spec change.
v2: Don't mess with cpu dp aux divider (Paulo Zanoni)
Signed-off-by: Jani Nikula jani.nik...@intel.com
On Tue, Apr 09, 2013 at 05:46:45PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Our checks for an invalid fence stride forgot to guard against
zero stride on gen4+. Fix it.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
This
On Tue, Apr 09, 2013 at 05:01:18PM +0200, Daniel Vetter wrote:
On Tue, Apr 09, 2013 at 05:46:45PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Our checks for an invalid fence stride forgot to guard against
zero stride on gen4+. Fix it.
On Thu, 2013-04-04 at 15:13 +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
GAC_ECO_BITS has a bit similar to GAM_ECOCHK's ECOCHK_SNB_BIT. Add
the define, and enable it on SNB.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
On the
Can you please quickly test whether the below patch changes anything
in the behaviour?
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8809813..974ae32 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@
On Tue, Apr 09, 2013 at 04:44:28PM +0300, Mika Kuoppala wrote:
Ben Widawsky b...@bwidawsk.net writes:
Requested-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/intel_pm.c | 3 +--
1 file changed, 1 insertion(+), 2
From: Ville Syrjälä ville.syrj...@linux.intel.com
Our checks for an invalid fence stride forgot to guard against
zero stride on gen4+. Fix it.
v2: Avoid duplicated code (danvet)
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_gem_tiling.c | 6 +++---
1
On Tue, Apr 09, 2013 at 08:09:13PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Our checks for an invalid fence stride forgot to guard against
zero stride on gen4+. Fix it.
v2: Avoid duplicated code (danvet)
Signed-off-by: Ville Syrjälä
On 04/09/2013 06:40 PM, Daniel Vetter wrote:
Can you please quickly test whether the below patch changes anything
in the behaviour?
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8809813..974ae32 100644
--- a/drivers/gpu/drm/i915/intel_display.c
On 04/09/2013 07:42 PM, Hans de Bruin wrote:
On 04/09/2013 06:40 PM, Daniel Vetter wrote:
Can you please quickly test whether the below patch changes anything
in the behaviour?
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8809813..974ae32
On Tue, Apr 9, 2013 at 7:51 PM, Hans de Bruin jmdebr...@xmsnet.nl wrote:
/* pipesrc and dspsize control the size that is scaled from,
* which should always be the user's requested size.
*/
I915_WRITE(DSPSIZE(plane),
((mode-vdisplay -
On Tue, Apr 9, 2013 at 5:37 AM, Ville Syrjälä ville.syrj...@linux.intel.com
wrote:
On Mon, Apr 08, 2013 at 06:49:44PM -0300, Rodrigo Vivi wrote:
Display register 46500h bit 23 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.
So should we enable it again
On Tue, Apr 09, 2013 at 05:45:37PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
gem_tiling_max_stride writes a data pattern to an X-tiled buffer using
the maximum supported stride, reads the data back as linear, and
verifies that the data
On Tue, Apr 9, 2013 at 5:35 AM, Ville Syrjälä ville.syrj...@linux.intel.com
wrote:
On Mon, Apr 08, 2013 at 06:49:42PM -0300, Rodrigo Vivi wrote:
This patch introduce Frame Buffer Compression (FBC) support for HSW.
It adds a new function haswell_enable_fbc to avoid getting
On Tue, Apr 09, 2013 at 03:03:28PM +0300, Ville Syrjälä wrote:
On Tue, Apr 09, 2013 at 01:54:01PM +0200, Daniel Vetter wrote:
On Tue, Apr 09, 2013 at 11:45:05AM +0300, ville.syrj...@linux.intel.com
wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
BSpec contains several
On Tue, Apr 09, 2013 at 07:06:32PM +0100, Chris Wilson wrote:
On Tue, Apr 09, 2013 at 05:45:37PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
gem_tiling_max_stride writes a data pattern to an X-tiled buffer using
the maximum supported
It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable checking only where it doesn't make sense.
Note that intel_modeset_setup_hw_state already has a call to
intel_modeset_check_state at the
This series is an attempt to fix many hang bugs we have at SNB with RC6.
https://bugzilla.kernel.org/show_bug.cgi?id=43267
Reporter of this 43267 mentioned that one ugly patch of mine fixed his hangs.
That patch was wrong and probably regressing some other stuff already fixed
by Chris. At that
According to SNB GT PM Programming Guide Turbo, page 8, GEN6_RPNSWREQ (A008)
bit [31] must be set as 0 meaning Turbo Disable.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 2 ++
2 files changed, 3 insertions(+), 1
According to SNB GT PM Programming Guide page 9,
Write Min Frequency Table is 09h
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
According to SNB GT PM Programming Guide page 8 RP_CONTROL (A024) must be
set according this:
* bits [10:9] = 01 - Use Normal or Video Turbo frequency req.
* bits [2:0] = 010 - Down=Busy Min Average (EI)
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/intel_pm.c | 4
Since atm we don't take a reference on the dma buf pointer when we add
it to the import lookup table the dma buf can vanish leaving the stale
pointer behind. This can in turn lead to returning stale GEM handles
when userspace imports a newly exported buffer.
I sent a bunch of patches to
On Thu, Apr 04, 2013 at 06:32:35PM +0300, Mika Kuoppala wrote:
In preparation to do analysis of which context was
guilty of gpu hung, store kreffed context pointer
into request struct.
This allows us to inspect contexts when gpu is reset
even if those contexts would already be released
by
From: Mika Kuoppala mika.kuopp...@linux.intel.com
In preparation to do analysis of which context was
guilty of gpu hung, store kreffed context pointer
into request struct.
This allows us to inspect contexts when gpu is reset
even if those contexts would already be released
by userspace.
v2:
Looks like a some remnant from a rebase.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index b77e98c..50df194 100644
---
61 matches
Mail list logo
