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 (
On Mon, 02 Jul 2012 17:02:59 -0300
Eugeni Dodonov wrote:
> On 07/02/2012 02:49 PM, Ben Widawsky wrote:
> > On Mon, 2 Jul 2012 11:51:05 -0300
> > Eugeni Dodonov wrote:
> >
> >> Most of the RPS and RC6 enabling functionality is similar to what we had
> >> on Gen6/Gen7, so we preserve most of the
On 07/02/2012 02:49 PM, Ben Widawsky wrote:
> On Mon, 2 Jul 2012 11:51:05 -0300
> Eugeni Dodonov 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 a
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
Intel-gfx@lis
On Mon, 2 Jul 2012 11:51:11 -0300
Eugeni Dodonov wrote:
> 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
I seem to recall Chris not liking this idea. Did I make that up
On Mon, 2 Jul 2012 11:51:10 -0300
Eugeni Dodonov wrote:
> 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 sugge
On Mon, 2 Jul 2012 11:51:09 -0300
Eugeni Dodonov wrote:
> This is based on Ivy Bridge clock gating for now, but is subject to
> changes in the future.
I am a fan of not including this until it's actually needed. I only took
a peek, but I didn't see a need in the remaining patches.
>
> Signed-
On Mon, 2 Jul 2012 11:51:08 -0300
Eugeni Dodonov wrote:
> We weren't disabling RC6 bits when bringing down RPS.
>
> Signed-off-by: Eugeni Dodonov
Reviewed-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/intel_pm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i
On Mon, 2 Jul 2012 11:51:07 -0300
Eugeni Dodonov wrote:
> It should be working so let's turn it on by default and catch any possible
> issues faster.
>
> Signed-off-by: Eugeni Dodonov
Reviewed-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/intel_pm.c | 6 --
> 1 file changed, 4 insertions
At Mon, 2 Jul 2012 19:55:17 +0200,
Daniel Vetter wrote:
>
> On Mon, Jul 2, 2012 at 7:51 PM, Takashi Iwai wrote:
> > It's just for avoiding the possible regressions by this change.
> > We definitely need a fix for HD+ panels ASAP, while other panels work
> > in the current code. Introducing the e
On Mon, Jul 2, 2012 at 7:51 PM, Takashi Iwai wrote:
> It's just for avoiding the possible regressions by this change.
> We definitely need a fix for HD+ panels ASAP, while other panels work
> in the current code. Introducing the extra disable code affecting all
> laptops sounds too risky for 3.5
At Mon, 2 Jul 2012 18:53:29 +0200,
Daniel Vetter wrote:
>
> 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 wh
On Mon, 2 Jul 2012 11:51:06 -0300
Eugeni Dodonov wrote:
> Just a cosmetic change to simplify the if statement.
>
> Signed-off-by: Eugeni Dodonov
Reviewed-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/intel_pm.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/d
On Mon, 2 Jul 2012 11:51:05 -0300
Eugeni Dodonov 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 Vetter, to reduce th
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 b
On Mon, Jul 02, 2012 at 08:44:00AM -0700, Ben Widawsky wrote:
> On Sun, 1 Jul 2012 12:48:59 +0200
> Daniel Vetter wrote:
> > Hm, I don't see the comment you're talking about ... Neither
> > ironlake_disable_rc6 nor ironlake_teardown_rc6 nor any of the callers
> > have one. Or am I totally missing
On Mon, 2 Jul 2012 11:51:04 -0300
Eugeni Dodonov 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 registers in get/put, why not
On Mon, Jul 02, 2012 at 09:04:48AM -0700, Ben Widawsky wrote:
> On Sun, 1 Jul 2012 12:41:19 +0200
> Daniel Vetter wrote:
>
> > On Sun, Jul 1, 2012 at 5:09 AM, Ben Widawsky wrote:
> > > On Tue, 26 Jun 2012 23:08:50 +0200
> > > Daniel Vetter wrote:
> > >
> > >> Having this early check in intel_ri
On Mon, 2 Jul 2012 11:51:03 -0300
Eugeni Dodonov wrote:
> From: Chris Wilson
>
> 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_
On Mon, 2 Jul 2012 11:51:02 -0300
Eugeni Dodonov wrote:
> From: Chris Wilson
>
> 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* u
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 disabling LVDS off while changing the
mode.
Since this doesn't give
On Sun, 1 Jul 2012 12:41:19 +0200
Daniel Vetter wrote:
> On Sun, Jul 1, 2012 at 5:09 AM, Ben Widawsky wrote:
> > On Tue, 26 Jun 2012 23:08:50 +0200
> > Daniel Vetter wrote:
> >
> >> Having this early check in intel_ring_begin doesn't buy us anything,
> >> since we'll be calling into wait_reques
On Sun, 1 Jul 2012 12:48:59 +0200
Daniel Vetter wrote:
> On Sun, Jul 1, 2012 at 5:04 AM, Ben Widawsky wrote:
> > On Fri, 29 Jun 2012 23:32:16 +0200
> > Daniel Vetter wrote:
> >
> >> While creating the new enable/disable_gt_powersave functions in
> >>
> >> commit 8090c6b9daa04dda649ac0a220960104
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 latit
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
---
drivers/gpu/drm/i915/i915_drv.c | 191 ---
drivers/gpu/drm/i915/intel_drv.h | 1 +
driv
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
---
drivers/gpu
This is based on Ivy Bridge clock gating for now, but is subject to
changes in the future.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_pm.c | 54 -
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm
We weren't disabling RC6 bits when bringing down RPS.
Signed-off-by: Eugeni Dodonov
---
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
--- a/drivers/gpu/drm/i915/i
It should be working so let's turn it on by default and catch any possible
issues faster.
Signed-off-by: Eugeni Dodonov
---
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 b/drivers/gpu/drm/i915/intel_pm.c
Just a cosmetic change to simplify the if statement.
Signed-off-by: Eugeni Dodonov
---
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 a3ee1b1..64cd97e 100644
--- a/d
From: Chris Wilson
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* use wait_for_atomic for
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 thres
There is a different ACK register for force wake on Haswell, so account
for that.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_drv.c | 22 ++
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm
From: Chris Wilson
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: Chris Wilson
Signed-off-by:
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 t
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 readi
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.
What comes to my mind reading your message - why should dual channel
on HD+ be treated differently than on panels wit
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
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 resoluti
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
40 matches
Mail list logo
