At Thu, 28 Jun 2012 14:23:04 -0400,
Giacomo Comes wrote:
On Thu, Jun 28, 2012 at 07:52:18AM +0200, Takashi Iwai wrote:
At Tue, 26 Jun 2012 15:08:32 -0400,
Giacomo Comes wrote:
I have a dell latitude E6420 with Sandybridge Mobile (GT2).
Since I got it (about one year ago), it has
I've had this problem with the e6420 on 1600x900. Applying your work
around fixed it for me. Though, kernel 3.5-rc4 fixes the problem for
real (it even fixes the default resolutions set when X comes up,
which did not work properly before).
I'm not aware of what this could cause to other
At Mon, 2 Jul 2012 10:54:43 +0200,
Georg Grabler wrote:
I've had this problem with the e6420 on 1600x900. Applying your work
around fixed it for me. Though, kernel 3.5-rc4 fixes the problem for
real (it even fixes the default resolutions set when X comes up,
which did not work properly
At Mon, 2 Jul 2012 11:51:46 +0200,
Georg Grabler wrote:
Hello,
Not sure if it's of any help, but Thiago Macieira has the same model
as mine, but with a different panel (lower resolution, 1366x768), and
he never suffered of this problem.
So far, so good.
What comes to my mind reading
Hi,
Addressing bike color suggestions in the previous series:
- simplify RPS function to reduce the number of changes. With this, we still
write the RC6p/RC6pp bits, but those should be ignored on Haswell and
experimental results have demonstrated no issues with it so far.
- *really* use
From: Chris Wilson ch...@chris-wilson.co.uk
Tidy up the routines for interacting with the GT (in particular the
forcewake dance) which are scattered throughout the code in a single
structure.
v2: use wait_for_atomic for polling.
v3: *really* use wait_for_atomic for polling.
Signed-off-by:
There is a different ACK register for force wake on Haswell, so account
for that.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 22 ++
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 19 insertions(+), 4 deletions(-)
Most of the RPS and RC6 enabling functionality is similar to what we had
on Gen6/Gen7, so we preserve most of the registers.
Note that Haswell only has RC6, so account for that as well. As suggested
by Daniel Vetter, to reduce the amount of changes in the patch, we still
write the RC6p/RC6pp
From: Chris Wilson ch...@chris-wilson.co.uk
As a w/a to prevent reads sporadically returning 0, we need to wait for
the GT thread to return to TC0 before proceeding to read the registers.
v2: adapt for Haswell changes (Eugeni).
v3: use wait_for_atomic_us for thread status polling.
v3: *really*
Just a cosmetic change to simplify the if statement.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index
It should be working so let's turn it on by default and catch any possible
issues faster.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
We weren't disabling RC6 bits when bringing down RPS.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b00df1f..5ea8319 100644
---
This is based on Ivy Bridge clock gating for now, but is subject to
changes in the future.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 54 -
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git
For Haswell, on some of the early hardware revisions, it is possible to
run into issues when RC6 state is enabled and when pipes change state.
v2: add comment saying that this is for early revisions only.
v3: beautify as suggested by Daniel Vetter.
Signed-off-by: Eugeni Dodonov
This commit moves force wake support routines into intel_pm modules, and
exports the gen6_gt_check_fifodbg routine (used in I915_READ).
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 191 ---
On Mon, Jul 02, 2012 at 10:18:43AM +0200, Takashi Iwai wrote:
At Thu, 28 Jun 2012 14:23:04 -0400,
Giacomo Comes wrote:
On Thu, Jun 28, 2012 at 07:52:18AM +0200, Takashi Iwai wrote:
At Tue, 26 Jun 2012 15:08:32 -0400,
Giacomo Comes wrote:
I have a dell latitude E6420 with
On Sun, 1 Jul 2012 12:48:59 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Sun, Jul 1, 2012 at 5:04 AM, Ben Widawsky b...@bwidawsk.net wrote:
On Fri, 29 Jun 2012 23:32:16 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
While creating the new enable/disable_gt_powersave functions
On Sun, 1 Jul 2012 12:41:19 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Sun, Jul 1, 2012 at 5:09 AM, Ben Widawsky b...@bwidawsk.net wrote:
On Tue, 26 Jun 2012 23:08:50 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Having this early check in intel_ring_begin doesn't buy us anything,
On Mon, 2 Jul 2012 11:51:02 -0300
Eugeni Dodonov eugeni.dodo...@intel.com wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
Tidy up the routines for interacting with the GT (in particular the
forcewake dance) which are scattered throughout the code in a single
structure.
v2: use
On Mon, 2 Jul 2012 11:51:03 -0300
Eugeni Dodonov eugeni.dodo...@intel.com wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
As a w/a to prevent reads sporadically returning 0, we need to wait for
the GT thread to return to TC0 before proceeding to read the registers.
v2: adapt for
On Mon, 2 Jul 2012 11:51:04 -0300
Eugeni Dodonov eugeni.dodo...@intel.com wrote:
There is a different ACK register for force wake on Haswell, so account
for that.
Well I guess that HSW bit in patch 2 that I just acked didn't belong
there yet ;-)
Also, since you've now put conditional
On Mon, Jul 02, 2012 at 06:14:54PM +0200, Takashi Iwai wrote:
Some SNB/IVY Laptops with 1600x900 HD+ panel (e.g. Dell Latitude E6420
and HP ProBook 65xx) are known to show the whole black/white garbage
or flickering screens while starting up or changing the mode.
This can be worked around by
On Mon, 2 Jul 2012 11:51:05 -0300
Eugeni Dodonov eugeni.dodo...@intel.com wrote:
Most of the RPS and RC6 enabling functionality is similar to what we had
on Gen6/Gen7, so we preserve most of the registers.
Note that Haswell only has RC6, so account for that as well. As suggested
by Daniel
Hi,
Is there any update on this issue or has a bug been reported?
I seem to have a similar issue ([drm:i915_hangcheck_hung] *ERROR* Hangcheck
timer) when using vaapi with gstreamer.
Best regards,
Christophe
___
Intel-gfx mailing list
On 07/02/2012 02:49 PM, Ben Widawsky wrote:
On Mon, 2 Jul 2012 11:51:05 -0300
Eugeni Dodonov eugeni.dodo...@intel.com wrote:
Most of the RPS and RC6 enabling functionality is similar to what we had
on Gen6/Gen7, so we preserve most of the registers.
Note that Haswell only has RC6, so
On Mon, 02 Jul 2012 17:02:59 -0300
Eugeni Dodonov eugeni.dodo...@linux.intel.com wrote:
On 07/02/2012 02:49 PM, Ben Widawsky wrote:
On Mon, 2 Jul 2012 11:51:05 -0300
Eugeni Dodonov eugeni.dodo...@intel.com wrote:
Most of the RPS and RC6 enabling functionality is similar to what we had
Hello folks,
I am seeing corruption when running spectex from mesa demos which looks like
vertex being randomly clipped on Valleyview, however spectex works fine on Ivy
Bridge.
After tracing down the codes I realize that the current Mesa driver would
program the maximum number or URB entries
27 matches
Mail list logo
