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
> ---
> driv
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
> ---
> dr
From: Ville Syrjälä
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ä
---
drivers/gpu/drm/i915/i915_drv.h | 6 +++---
drivers/gpu/drm/i915/i915_gem.c | 4 +++-
drivers/gpu/drm/i915/i915_irq.c | 2
From: Ville Syrjälä
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ä
---
drivers/gpu/drm/i915/i915_gem_tiling.c | 9 ++---
drivers/gpu/drm/i915/i915_reg.h|
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
> ---
> drivers/gpu/drm/i915/i915_dma.c | 48
> -
> 1 file changed, 24 insertions(+), 24 deletions(-)
>
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ä
Cc: Ben Widawsky
Signed-off-by: Chris Wilson
---
drivers/g
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 th
On Mon, Apr 08, 2013 at 06:43:56PM -0700, Ben Widawsky wrote:
> From: Ben Widawsky
>
> 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: Resolve conflicts due t
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ä
Cc: Ben Widawsky
Signed-off-by: Chris W
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 HPD
From: Egbert Eich
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 seems to be bad
From: Egbert Eich
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 storm
detection
From: Egbert Eich
To disable previously enabled HPD IRQs we need to reset them and
set the enabled ones individually.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/i915/i915_irq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915
From: Egbert Eich
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
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i
From: Egbert Eich
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
---
drivers/gpu/drm/i915/i915_irq.c | 37 +++--
1
From: Egbert Eich
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
the system). T
From: Egbert Eich
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 hotplug inte
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 sa
From: Ville Syrjälä
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 for FBC. Since then
BSpec has be
On Tue, Apr 09, 2013 at 11:45:05AM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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ä
> ---
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ä
> >
> > BSpec contains several scattered notes which state that the maximum
> > fence stride was increased to 256KB on IVB.
> >
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 t
Some fence stuff related to the 32 fence registers/256KB max fence stride
kernel changes.
I'm not sure gem_tiling_max_stride does any good since you can only use
it to verify that the tested fence stride <= max fence stride. Also I
ran it only on ILK,SNB and IVB, so at least the Gen2-3 code is
tot
From: Ville Syrjälä
IVB+ supports 32 fence registers, bump the maximum in the test.
Signed-off-by: Ville Syrjälä
---
tests/gem_fenced_exec_thrash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/gem_fenced_exec_thrash.c b/tests/gem_fenced_exec_thrash.c
index 8281449.
From: Ville Syrjälä
lib/drmtest.c provides gem_available_fences(). Use it where
appropriate.
Signed-off-by: Ville Syrjälä
---
tests/gem_fence_thrash.c | 8 ++--
tests/gem_fenced_exec_thrash.c | 8 ++--
tests/gem_stress.c | 8 ++--
3 files changed, 6 insertions(+),
From: Ville Syrjälä
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ä
---
tests/Makefile.am | 1 +
tests/gem_
On Tue, Apr 09, 2013 at 03:25:37PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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 GPU surface tiling being resu
On Tue, Apr 09, 2013 at 03:25:39PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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 w
From: Ville Syrjälä
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 are rejected
properly.
v2: Che
Ben Widawsky 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 frequency to be in
Ben Widawsky writes:
> Requested-by: Daniel Vetter
> Signed-off-by: Ben Widawsky
> ---
> 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 b/drivers/gpu/drm/i915/intel_pm.c
> index 2edb743..c81921b 100644
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 clea
On Tue, Apr 09, 2013 at 04:41:42PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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 w
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 m
From: Ville Syrjälä
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 are rejected
properly.
v2: Che
From: Ville Syrjälä
Our checks for an invalid fence stride forgot to guard against
zero stride on gen4+. Fix it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem_tiling.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
b/drivers/gpu/d
Hi
2013/4/9 Jani Nikula :
> 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
>
> ---
>
> Untested.
> ---
> drivers/gpu/drm/i915/intel_dp.c |8 ++--
> 1 file changed, 6 insertio
On Tue, Apr 09, 2013 at 11:49:45AM -0300, Paulo Zanoni wrote:
> Hi
>
> 2013/4/9 Jani Nikula :
> > 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
> >
> > ---
> >
> > Untested.
On Tue, Apr 09, 2013 at 05:46:45PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Our checks for an invalid fence stride forgot to guard against
> zero stride on gen4+. Fix it.
>
> Signed-off-by: Ville Syrjälä
This duplicates the tiny stride check a bit with the gen2/3 c
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ä
> >
> > Our checks for an invalid fence stride forgot to guard against
> > zero stride on gen4+. Fix it.
> >
> > Signed-off-by:
On Thu, 2013-04-04 at 15:13 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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ä
On the series:
Reviewed-by: Imre Deak
> ---
> drivers/gpu
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
@@ -47
On Tue, Apr 09, 2013 at 04:44:28PM +0300, Mika Kuoppala wrote:
> Ben Widawsky writes:
>
> > Requested-by: Daniel Vetter
> > Signed-off-by: Ben Widawsky
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i
On Tue, Apr 09, 2013 at 07:23:18PM +0300, Imre Deak wrote:
> On Thu, 2013-04-04 at 15:13 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > 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: Vil
From: Ville Syrjälä
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ä
---
drivers/gpu/drm/i915/i915_gem_tiling.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a
On Tue, Apr 09, 2013 at 08:09:13PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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ä
Queued for -next, than
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 100644
On Tue, Apr 9, 2013 at 7:51 PM, Hans de Bruin 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 - 1) << 16)
On Tue, Apr 9, 2013 at 5:37 AM, Ville Syrjälä 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 after FBC is disabled to avo
On Tue, Apr 09, 2013 at 05:45:37PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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 w
On Tue, Apr 9, 2013 at 5:35 AM, Ville Syrjälä 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
> > ironlake_enable_fbc messed with many IS_
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ä
> > >
> > > BSpec contains several scattered notes whic
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ä
> >
> > gem_tiling_max_stride writes a data pattern to an X-tiled buffer using
> > the maximum supported stride, reads the data ba
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 en
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 pat
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
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --gi
According to SNB GT PM Programming Guide page 9,
Write Min Frequency Table is 09h
Signed-off-by: Rodrigo Vivi
---
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 b/drivers/gpu/drm/i915/i915_reg.h
index fc4f542f..
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
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed,
> 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 p
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
From: Mika Kuoppala
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: track i915_hw_context pointers in
Looks like a some remnant from a rebase.
Signed-off-by: Ben Widawsky
---
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
--- a/drivers/gpu/drm/i915/i
64 matches
Mail list logo
