This keeps the memory manager from complaining when we take it down.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_dma.c | 14 ++
drivers/gpu/drm/i915/i915_drv.h |3 +++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers
Was better safe than sorry, but it appears these bits aren't necessary.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_gem.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915
,
What about the indirect bug? Did that also go away when you fixed the
perms issue? If not, that sounds like a serious issue, in indirect
mode the swap interval should still be honored I think...
--
Jesse Barnes, Intel Open Source Technology Center
On Tue, 11 May 2010 07:59:19 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 10 May 2010 22:00:46 -0400
Andrew Morton a...@linux-foundation.org wrote:
+#define thm_readb(off) readb(ips-regmap + (off))
+#define thm_readw(off) readw(ips-regmap + (off))
+#define thm_readl(off
.
--
Jesse Barnes, Intel Open Source Technology Center
From dd91007d2c98ef43ead29347dec344c6ae596ad4 Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Mon, 10 May 2010 14:22:06 -0700
Subject: [PATCH 2/2] x86 platform driver: intelligent power sharing driver
Intel Core i3/5
/intel_lvds.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
Looks good, we should get it upstream early in this cycle to get it
some test coverage. If it doesn't work out it's easy to revert.
Acked-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel
Be sure to enable GPU turbo by default at load time and check GPU busy
and MCP exceeded status correctly. Also fix up CPU power comparison and
work around buggy MCH temp reporting.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/platform/x86/intel_ips.c | 30
-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_debugfs.c | 56 -
drivers/gpu/drm/i915/i915_dma.c | 529 +-
drivers/gpu/drm/i915/i915_drv.h | 20 ++-
drivers/gpu/drm/i915/i915_irq.c | 28 +--
drivers/gpu/drm/i915
FBC disable on 965 can take long enough to trigger latency checks in the
kernel so be sure to timeout after a reasonable period.
Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15015.
Tested-by: James Ettle theholyet...@googlemail.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff
-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Kristian Høgsberg k...@bitplanet.net
---
drivers/gpu/drm/i915/intel_display.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915
On Thu, 27 May 2010 13:18:15 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_gem.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff
drm_os_linux, but it
should have been fine.
We should still kill the drm_os_linux bits where possible...
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman
, I'll refresh them and post new ones tomorrow.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
to lid handling...
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fri, 18 Jun 2010 13:04:50 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Thu, 17 Jun 2010 19:44:10 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 18 Jun 2010 02:20:23 +0200
Marc Deop i Argemí damnsh...@gmail.com wrote:
On Friday June 18 2010 02:17:53 Andrew
On Mon, 21 Jun 2010 16:32:48 -0400
Andrew Lutomirski l...@mit.edu wrote:
On Sun, Jun 20, 2010 at 11:29 AM, Andrew Lutomirski l...@mit.edu wrote:
On Fri, Jun 18, 2010 at 4:04 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Thu, 17 Jun 2010 19:44:10 -0700
Jesse Barnes jbar
Allows us to track each process that requests and completes events.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_irq.c |8 ++
drivers/gpu/drm/drm_trace.h | 57 --
include/drm/drmP.h |2 +
3 files
is required. (So long as we do not start performing asynchronous flips.)
Note the impact of this should be slight as on i965 we should be using a
tiled frontbuffer for anything up to a 4096x4096 display.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar
memory back into the general pool using the
memory hotplug code is left as an exercise for the reader.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index f97122a..54ed0e1 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b
On Thu, 8 Jul 2010 10:58:21 +0100
Simon Farnsworth simon.farnswo...@onelan.com wrote:
On Wednesday 7 July 2010, Jesse Barnes jbar...@virtuousgeek.org wrote:
Some BIOSes will claim a large chunk of stolen space. Unless we
reclaim it, our aperture for remapping buffer objects
On Thu, 8 Jul 2010 09:01:44 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Thu, 8 Jul 2010 10:58:21 +0100
Simon Farnsworth simon.farnswo...@onelan.com wrote:
On Wednesday 7 July 2010, Jesse Barnes jbar...@virtuousgeek.org wrote:
Some BIOSes will claim a large chunk of stolen space
This function and its description were confusing at best. Clean them up to
reflect the current state of things.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 0eab8df..6bc313a 100644
--- a/drivers
On Fri, 9 Jul 2010 08:30:11 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 08 Mar 2010 21:59:29 +0100
Brice Goglin brice.gog...@gmail.com wrote:
Eric Anholt wrote:
On Thu, 18 Feb 2010 14:51:54 -0800, Jesse Barnes
jbar...@virtuousgeek.org wrote:
When we get a CRTC
configuration into something they couldn't change. :)
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman
) with 'Full Aspect' scaling
https://bugs.freedesktop.org/show_bug.cgi?id=29057
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git
, active
divisible by 2 in ganged mode, etc). If you're feeling adventurous
anyway. :)
Other than that:
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx
We should only free the compressed llb if we allocated it in the first
place otherwise we'll panic at unload time.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_dma.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm
In some cases, unlocking the panel regs is safe and can help us avoid a
flickery, full mode set sequence. So define the unlock key and use it.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c |6
in the PCH panel
sequencing logic, apparently this is one possible workaround.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=28739.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c | 53 +-
1 files changed, 51
On Wed, 14 Jul 2010 15:40:56 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=28739. We need to
enable power to the panel with the AUX VDD bit in order to properly
detect the eDP attached panel, and we also need to turn the panel
-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8359c50..cf5a91d 100644
--- a/drivers/gpu/drm
On Fri, 23 Jul 2010 12:13:07 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 23 Jul 2010 12:03:37 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
If a framebuffer is shared across CRTCs, the x,y position of one of them
is likely to be something other than the origin (e.g
On Thu, 22 Jul 2010 13:18:19 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
When enabling the eDP port, we need to make sure the panel is turned on
after training the link. If we don't, it likely won't come back after
suspend or may not come up at all.
For unknown reasons, unlocking
haven't tried building against a 1.6 server for a long time, if
we need changes to support that I can make them as well.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
On Tue, 27 Jul 2010 17:00:28 +0100
Daniel Stone dan...@fooishbar.org wrote:
Hi,
On Tue, Jul 27, 2010 at 05:44:39PM +0200, Julien Cristau wrote:
On Tue, Jul 27, 2010 at 08:25:13 -0700, Jesse Barnes wrote:
Apparently MeeGo does automatic packaging based on configure.ac, so
Arjan
On Tue, 27 Jul 2010 17:39:11 +0100
Daniel Stone dan...@fooishbar.org wrote:
On Tue, Jul 27, 2010 at 09:34:01AM -0700, Jesse Barnes wrote:
On Tue, 27 Jul 2010 17:00:28 +0100
Daniel Stone dan...@fooishbar.org wrote:
On Tue, Jul 27, 2010 at 05:44:39PM +0200, Julien Cristau wrote:
On Tue
similar, for some reason VGA seems
to commonly fail on Ironlake. I'll try to reproduce on a couple of
systems I have here...
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
, looks fine.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
);
+ OUT_RING(0);
+ ADVANCE_LP_RING();
+ }
BEGIN_LP_RING(4);
if (IS_I965G(dev)) {
This looks nicer than what was there before. Hope it still works on
9xx...
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
tree by sending a
note to sta...@kernel.org with the commit id(s). They have to meet the
stable criteria though; I think the kernel has a doc on what makes
something eligible for stable inclusion.
--
Jesse Barnes, Intel Open Source Technology Center
inverted right x axis y axis)
Can you file a bug for this at bugs.freedesktop.org so it doesn't get
lost?
Adam's commit looks ok in general, but maybe your VBIOS is lying to us
in this case?
--
Jesse Barnes, Intel Open Source Technology Center
.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, 09 Aug 2010 19:20:34 +0200
Alexey Fisher bug-tr...@fisher-privat.net wrote:
On Mo, 2010-08-09 at 09:36 -0700, Jesse Barnes wrote:
On Sat, 07 Aug 2010 11:46:19 +0200
Alexey Fisher bug-tr...@fisher-privat.net wrote:
Hallo all,
i have some times on my primer desktop
On Mon, 09 Aug 2010 14:08:59 -0400
Adam Jackson a...@redhat.com wrote:
On Mon, 2010-08-09 at 09:39 -0700, Jesse Barnes wrote:
On Sat, 7 Aug 2010 20:09:32 +0200 Paul Neumann paul1...@yahoo.de wrote:
i915 :00:02.0: BAR 6: can't assign [??? 0x flags 0x0] (bogus
alignment
);
}
ADVANCE_LP_RING();
These bits look good.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
issue sounds like a desktop problem possibly? The kernel is
emitting a hotplug event as it should when the config changes, but the
desktop software listening for it apparently does the wrong thing.
Maybe it's a gnome-display-properties bug?
--
Jesse Barnes, Intel Open Source Technology Center
/gpu/drm/i915/i915_drv.h | 27 -
2 files changed, 34 insertions(+), 54 deletions(-)
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
My only complaint about this patch is that our hardware isn't more
uniform; for any given feature we may need to check the generation,
something
and many others.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_display.c | 31 +--
2 files changed, 31 insertions(+), 2 deletions(-)
Have
not just code motion though, the IS_IRONLAKE -
HAS_PCH_SPLIT change looks like a real bug fix.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
Ironlake requires that we clear the reset panel bit during power
sequences and restore it afterwards. Uncondtionally add code to do that
since it should be harmless on SNB+.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c | 17 -
1
We should disable the panel first when shutting down an eDP link. And
when turning one on, the panel needs to be enabled before link training
or eDP I/O won't be enabled.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c | 15 ---
1 files
event.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 52 +++--
1 files changed, 24 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5e21b31
We need to make sure the eDP PLL is enabled before the pipes or planes,
so do it as part of the DP prepare mode set function.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 39 +
drivers/gpu/drm/i915/intel_dp.c | 63
This set replaces the last one, and includes an additional patch to fix
our vblank wait code, which is apparently important especially when
dealing with link training.
It also contains a patch to address Adam's comment about the new VGA
disable code. I was missing a vga get/put pair around my
Ironlake requires that we clear the reset panel bit during power
sequences and restore it afterwards. Uncondtionally add code to do that
since it should be harmless on SNB+.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c | 17 -
1
here now? Can you
check and see if we're timing out in the wait_for_vblank function?
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, 24 Aug 2010 09:43:00 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
We were failing when trying to allocate the resource for MMIO of the
MCHBAR because we forgot to specify what type of resource we wanted.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes
Here's the set of eDP changes I've been running with locally. With
these fixes applied, my Dell E6510 test machine is solid from boot
through suspend/resume, though it appears other users haven't been so
fortunate, so there's still more work to do.
Thanks,
Jesse
Fix the test so we don't try to use the 450MHz refclk on PCH attached
eDP.
References:
https://bugs.freedesktop.org/show_bug.cgi?id=29141
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c |5 -
1 files changed, 4 insertions(+), 1 deletions
Mode setting sequence specifies that we use VDD AUX for configuration
and detection, and early in the mode set sequence. Only later (after
DP_A has started training) should we actually enable panel power.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c
args from the various DP
handling functions and use the intel_dp fields everywhere we can.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c | 115 +--
1 files changed, 62 insertions(+), 53 deletions(-)
diff --git a/drivers
When turning on or off the VDD AUX bit, we need to give the panel time
to start or stop or AUX transactions may fail.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm
nice smooth animations, but if I used the
HPET things were really slow.
Does the same work for you?
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman
On Tue, 14 Sep 2010 00:10:08 +0300
Vasily Khoruzhick anars...@gmail.com wrote:
В сообщении от 13 of September 2010 23:44:41 автор Jesse Barnes написал:
I remember seeing a similar problem on an Eee PC I had; it seemed to be
timer/interrupt related somehow. If I booted with clocksource=tsc
On Tue, 14 Sep 2010 00:41:18 +0300
Vasily Khoruzhick anars...@gmail.com wrote:
В сообщении от 14 of September 2010 00:19:55 автор Jesse Barnes написал:
On Tue, 14 Sep 2010 00:10:08 +0300
Vasily Khoruzhick anars...@gmail.com wrote:
В сообщении от 13 of September 2010 23:44:41 автор
On Tue, 14 Sep 2010 00:52:31 +0300
Vasily Khoruzhick anars...@gmail.com wrote:
В сообщении от 14 of September 2010 00:46:32 автор Jesse Barnes написал:
Yes, you can set vblank_mode=0 in your environment or drirc. At least
I think 0 is no vsync. :)
That doesn't help, glxgears shows
don't care about power saving at runtime on
my kit).
If it's happening on other kit, perhaps the i915 driver should make a suitable
pm_qos request itself. Jesse, can you comment?
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
--
Jesse Barnes, Intel Open Source
sequencing is pretty ugly with eDP, so it's likely other panels
will need the additional delays here as well. So:
Acked-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx
?
FDO bug for this is https://bugs.freedesktop.org/show_bug.cgi?id=30364.
I still don't have a root cause, but at least we have a workaround.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx
On Fri, 24 Sep 2010 22:48:36 +0300
Vasily Khoruzhick anars...@gmail.com wrote:
On 24 of September 2010 22:39:01 Jesse Barnes wrote:
On Thu, 16 Sep 2010 23:06:46 +0300
Vasily Khoruzhick anars...@gmail.com wrote:
В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner
, these functions do not modify the first argument and use it
for the result).
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 9d67b48..c74e4e8 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm
we program the
transcoder regs at all).
Even with those fixed though (among other things), I haven't been able
to get my Vaio with switchable graphics working. Which platforms did
you have working, and what changeset is most likely to work?
Thanks,
--
Jesse Barnes, Intel Open Source Technology
shouldn't change behavior since we ought to
time out on waiting on vblank in that case, and the timeout is the same
as the msleep we used to use.
The second one looks like a good change, but really the pipe off change
is separate from the plane disable bug fix.
--
Jesse Barnes, Intel Open Source
), but Eric changed to to div_u64 to fix a
build error of some kind, but forgot to fix things up due to the
changed semantics.
At any rate, it's a good fix and gives the IPS driver good GMCH power
values again.
--
Jesse Barnes, Intel Open Source Technology Center
Keith Packard kei...@keithp.com wrote:
On Sun, 3 Oct 2010 08:10:48 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Do these fixes help with the DP issues you've been seeing, Keith?
Seems like the first one shouldn't change behavior since we ought to
time out on waiting on vblank
On Mon, 4 Oct 2010 15:13:17 +0200
Jan-Hendrik Zab j...@jhz.name wrote:
On 03/10/10 08:04 -0700, Jesse Barnes wrote:
On Thu, 2 Sep 2010 23:37:26 +0800
Zhenyu Wang zhen...@linux.intel.com wrote:
[snip]
Adam, I believe this one causes regression on PCH eDP port as
for bug 27220
Here's the set of PCH eDP fixes I came up with once I received my Sony
Vaio. I found a few, non-PCH issues in the process, and took the
opportunity to enhance our eDP support to avoid most of the DP training
if the VBIOS gives us good data.
This patchset is against ickle's drm-intel-next branch
With the old check we'd never set lane_count or bpp to different values
on PCH attached eDP panels.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915
The display code needs to distinguish between CPU and PCH attached eDP
panels, so add some helpers to handle that.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c | 19 +++
drivers/gpu/drm/i915/intel_drv.h |1 +
2 files changed, 20
Since we set the output type of PCH attached eDP panels to
INTEL_OUTPUT_eDP this function would never return true when it should.
It's been replaced by working functions.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |5 ++---
drivers/gpu/drm
FDI training needs to done and idle for PCH eDP and before we turn the
pipes on, and various eDP checks need to account for PCH attached eDP.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 67 --
1 files changed
sequencing logic and register lock is to avoid such
damage.
That said, I've abused my panels (both LVDS and eDP) pretty hard and
have yet to damage one in any visible way, so stealing some
conservative (i.e. long) delays from an existing VBT will probably work
ok.
--
Jesse Barnes, Intel Open
We do this later (and more properly) when we enable FDI, so we don't
need to do it here.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 21 -
1 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm
As with other PCH DP connections.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5fee124
CPU eDP needs a different reference clock than PCH eDP, which uses the
standard PCH refclk of 120MHz.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915
Wait for vblank after enabling a pipe, make the error messages more
informative, and wait for the pipe to turn off when we disable it.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |8
1 files changed, 4 insertions(+), 4 deletions
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c |8
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index
Needed on Ibex Peak and Cougar Point or the panel won't always come on.
Cc: sta...@kernel.org
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |3 +++
drivers/gpu/drm/i915/intel_display.c |7 +++
2 files changed, 10 insertions(+), 0
We don't use the CPU DP PLL with PCH attached eDP panels, so don't
bother to enable it.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 19e0d65..8e019c8 100644
--- a/drivers/gpu/drm/i915
Cache the first 4 bytes of DPCD data in the eDP case. It's unlikely to
change and can save us some trouble at link training time.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_dp.c | 20
2
We can skip most of the link training step if we use the VBT provided
values.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c | 146 ---
1 files changed, 89 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm
PP_ON_DELAYS is valid upon
device init (module load and resume) and fixup in case the BIOS does not.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
On Fri, 08 Oct 2010 11:00:11 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, 7 Oct 2010 16:01:05 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Here's the set of PCH eDP fixes I came up with once I received my Sony
Vaio. I found a few, non-PCH issues in the process
Since the PLL may still be on, and the training pattern may not be
correct. Fixes suspend/resume on my PCH eDP test system.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8e019c8..2449192 100644
is the right thing to do; we want to
make sure the fb passed in isn't used again until its flip is complete.
But maybe we're decrementing it incorrectly in the buffer exec path or
allowing rendering to continue too soon?
--
Jesse Barnes, Intel Open Source Technology Center
On Thu, 21 Oct 2010 17:32:30 +0800
Chia-I Wu olva...@gmail.com wrote:
Block execbuffer for the fb to be flipped away, not the one that is to
be flipped in.
I think we want to block rendering on both? Otherwise we could display
partial drawing in the new buffer.
--
Jesse Barnes, Intel Open
On Fri, 22 Oct 2010 01:49:17 +0800
Chia-I Wu olva...@gmail.com wrote:
On Fri, Oct 22, 2010 at 12:18 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Thu, 21 Oct 2010 17:55:13 +0800
Chia-I Wu olva...@gmail.com wrote:
Hi list,
According to the doc for page_flip
all to 0. That will disable several memory related power saving
features while the CPU is in a deep sleep state.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org
On Tue, 26 Oct 2010 01:14:04 +0100
Peter Clifton pc...@cam.ac.uk wrote:
On Mon, 2010-10-25 at 13:20 -0700, Jesse Barnes wrote:
On Mon, 25 Oct 2010 13:11:24 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
There are some bits in the GMCH to control memory behavior during CPU
C
1 - 100 of 2916 matches
Mail list logo
