On Tue, Jun 11, 2013 at 04:01:21PM -0700, Stéphane Marchesin wrote:
>
> On Tue, Jun 11, 2013 at 3:57 PM, Chris Wilson
> wrote:
> > On Tue, Jun 11, 2013 at 03:49:27PM -0700, Stéphane Marchesin wrote:
> >> During suspend all fences are reset, including their pin_count which
> >> is reset to 0. How
On Tue, May 21, 2013 at 09:54:55PM +0200, Daniel Vetter wrote:
> So don't try to store it in the DPLL_FP register.
>
> Otherwise it looks like the limits for pineview are correct: It has
> it's own clock computation code, which doesn't use an offset for n
> divisors, and the register value based m
On Tue, 11 Jun 2013 23:06:59 +0200
Daniel Vetter wrote:
> On Tue, Jun 11, 2013 at 11:08:16PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The current PLL settings produce a rather unstable picture when
> > I hook up a VLV to my HP ZR24w display via a VGA cable. Sw
On Tue, May 21, 2013 at 09:54:54PM +0200, Daniel Vetter wrote:
> Again the same confusion that our code expects m1/m2 in register values.
> This time around with the added fun that many of the existing values
> have been all off by a bit in different directions. Hence extract a
> common #define.
>
On Tue, Jun 11, 2013 at 3:57 PM, Chris Wilson wrote:
> On Tue, Jun 11, 2013 at 03:49:27PM -0700, Stéphane Marchesin wrote:
>> During suspend all fences are reset, including their pin_count which
>> is reset to 0. However a framebuffer can be bound across
>> suspend/resume, which means that when th
On Tue, Jun 11, 2013 at 03:49:27PM -0700, Stéphane Marchesin wrote:
> During suspend all fences are reset, including their pin_count which
> is reset to 0. However a framebuffer can be bound across
> suspend/resume, which means that when the buffer is unbound after
> resume, the pin count for the b
During suspend all fences are reset, including their pin_count which
is reset to 0. However a framebuffer can be bound across
suspend/resume, which means that when the buffer is unbound after
resume, the pin count for the buffer will be negative. Since the
fence pin count is now negative when avail
It's basically the same deal as the RC6+ issues on ivy bridge
except this time with RC6 on sandy bridge. Like last time the
core of the issue is that the timings don't work 100% with our
voltage regulator. So from time to time, the kernel will print
a warning message about the GPU not getting out o
On Tue, May 21, 2013 at 09:54:53PM +0200, Daniel Vetter wrote:
> So apparently the pll limits in the docs are the real values, but the
> formula actually seems to consistenly use register values. See
>
> commit 4f7dfb6788dd022446847fbbfbe45e13bedb5be2
> Author: Patrik Jakobsson
> Date: Wed Feb
On Tue, Jun 11, 2013 at 11:08:16PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The current PLL settings produce a rather unstable picture when
> I hook up a VLV to my HP ZR24w display via a VGA cable. Switching
> the PLL to hybrid mode makes the picture a lot more stable
On Tue, Jun 11, 2013 at 04:33:24PM -0300, Paulo Zanoni wrote:
> 2013/6/7 Damien Lespiau :
> > intel_enable_rc6() is used to check if we can compute the RC6 residency
> > in the sysfs code. Disable this for platforms older than Ironlake.
> >
> > Signed-off-by: Damien Lespiau
> > ---
> > drivers/gp
From: Ville Syrjälä
The current PLL settings produce a rather unstable picture when
I hook up a VLV to my HP ZR24w display via a VGA cable. Switching
the PLL to hybrid mode makes the picture a lot more stable. No
idea if this is truly wise though...
Signed-off-by: Ville Syrjälä
---
drivers/gpu
2013/6/7 Damien Lespiau :
> intel_enable_rc6() is used to check if we can compute the RC6 residency
> in the sysfs code. Disable this for platforms older than Ironlake.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_pm.c | 4
> 1 file changed, 4 insertions(+)
>
> diff -
2013/6/7 Damien Lespiau :
> Let's disable RC6+ by default. We still leave the possibility to
> override this with the module parameter.
>
> I've also shuffled the code around so we always log if we have RC6
> enabled or disabled.
Why disable RC6+ on IVB? My docs tells me it should only be disabled
2013/6/7 Damien Lespiau :
> Signed-off-by: Damien Lespiau
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_display.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 8
2013/6/7 Damien Lespiau :
> Signed-off-by: Damien Lespiau
Reviewed-by: Paulo Zanoni
If you search for the WaFbcDisableDpfcClockGating string on that file,
you'll see that this workaround is implemented differently on IVB/HSW:
on ILK the bits are turned on at init_clock_gating and stay like that
2013/6/7 Damien Lespiau :
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_pm.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 57e99b1..eb3c2c4 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
2013/6/7 Damien Lespiau :
> We also wait for that blank on other platforms but the w/a doesn't
> apply there. Not an issue at all.
>
> Signed-off-by: Damien Lespiau
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_pm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/driv
On Tue, Jun 11, 2013 at 04:37:26PM +0200, Daniel Vetter wrote:
> On Tue, Jun 11, 2013 at 4:16 PM, Chris Wilson
> wrote:
> > On Tue, Jun 11, 2013 at 04:05:41PM +0200, Daniel Vetter wrote:
> >> On Tue, Jun 11, 2013 at 02:40:19PM +0100, Chris Wilson wrote:
> >> > Not sure what you mean here. The che
On Tue, Jun 11, 2013 at 4:16 PM, Chris Wilson wrote:
> On Tue, Jun 11, 2013 at 04:05:41PM +0200, Daniel Vetter wrote:
>> On Tue, Jun 11, 2013 at 02:40:19PM +0100, Chris Wilson wrote:
>> > Not sure what you mean here. The check is fairly easy and has gotten us
>> > out of many a hole before, and ma
On Mon, Jun 10, 2013 at 12:27 AM, Chris Wilson wrote:
> It is these machines that require the per-connector quirk to turn off
> hotplug detection anyway. And there are users that need to turn off all
> hotplug detection (hardware and polling) on certain connectors whilst
> plugged into their kvm.
On Tue, Jun 11, 2013 at 04:05:41PM +0200, Daniel Vetter wrote:
> On Tue, Jun 11, 2013 at 02:40:19PM +0100, Chris Wilson wrote:
> > Not sure what you mean here. The check is fairly easy and has gotten us
> > out of many a hole before, and makes for a good defense. So how would
> > you want to fine t
On Tue, Jun 11, 2013 at 02:40:19PM +0100, Chris Wilson wrote:
> On Tue, Jun 11, 2013 at 11:45:00AM +0200, Daniel Vetter wrote:
> > On Mon, Jun 10, 2013 at 11:20:20AM +0100, Chris Wilson wrote:
> > > + if (ring->hangcheck.seqno == seqno) {
> > > + if (ring_idle(ring, seqno))
On Tue, Jun 11, 2013 at 11:45:00AM +0200, Daniel Vetter wrote:
> On Mon, Jun 10, 2013 at 11:20:20AM +0100, Chris Wilson wrote:
> > + if (ring->hangcheck.seqno == seqno) {
> > + if (ring_idle(ring, seqno)) {
> > + if (waitqueue_active(&ring->irq_
On Sun, Jun 09, 2013 at 07:01:36PM -0400, Matthew Garrett wrote:
> Windows 8 introduced new policy for backlight control by pushing it out to
> graphics drivers. This appears to have coincided with a range of vendors
> adding Windows 8 checks to their backlight control code which trigger either
> a
On Mon, Jun 10, 2013 at 11:20:21AM +0100, Chris Wilson wrote:
> If we detect a ring is in a valid wait for another, just let it be.
> Eventually it will either begin to progress again, or the entire system
> will come grinding to a halt and then hangcheck will fire as soon as the
> deadlock is dete
On Mon, Jun 10, 2013 at 11:20:20AM +0100, Chris Wilson wrote:
> After kicking a ring, it should be free to make progress again and so
> should not be accused of being stuck until hangcheck fires once more. In
> order to catch a denial-of-service within a batch or across multiple
> batches, we still
Hi Dave,
Just tiny regression fixes here:
- Two fixes to fix sdvo hotplug which broke in the hpd storm detection
work.
- One fix to patch-up the sdvo lvds regression fixer from the last pull -
we need to prefer the vbt mode over edid modes.
IMPORTANT:
The sdvo lvds fix in this -fixes pull
c
28 matches
Mail list logo
