On Tue, Feb 05, 2013 at 11:02:17PM +0100, Rafael J. Wysocki wrote:
On Tuesday, February 05, 2013 01:55:44 PM Jesse Barnes wrote:
On Mon, 04 Feb 2013 21:26:26 +0100
Rafael J. Wysocki r...@sisk.pl wrote:
On Monday, February 04, 2013 01:37:20 PM Jesse Barnes wrote:
KMS drivers can
The unbound tracking of objects is an optimisation to avoid costly
domain transfers whilst the system is rendering. Across suspend, the
objects will be involuntarily moved out of the GTT domain and will
require fixup upon resume. Rather than perform those clflushes for all
objects immediately upon
In order for the objects to be coherent in uncached memory (as they are
presumed to be on the unbound list) we need to clflush them because
experience dictates that the CPU caches will be dirtied across
hibernation.
Cc: sta...@vger.kernel.org
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
On Wed, Feb 06, 2013 at 09:31:20AM +, Chris Wilson wrote:
In order for the objects to be coherent in uncached memory (as they are
presumed to be on the unbound list) we need to clflush them because
experience dictates that the CPU caches will be dirtied across
hibernation.
Cc:
On Wed, Feb 06, 2013 at 09:31:21AM +, Chris Wilson wrote:
The unbound tracking of objects is an optimisation to avoid costly
domain transfers whilst the system is rendering. Across suspend, the
objects will be involuntarily moved out of the GTT domain and will
require fixup upon resume.
Date: Sun, 3 Feb 2013 13:33:08 +0100
Building the package under Debian Sid/unstable, `dh_shlibdeps` informs
that `libI810XvMC.so.1.0.0` does not need to be linked against
`libX11-xcb.so.1`, `libxcb-dri2.so.0`, `libxcb-util.so.0` or
`libxcb.so.1` [1].
$ debuild -b -us -uc
[…]
Date: Tue, 22 Jan 2013 10:47:22 +0100
---
NEWS |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index a1fcf66..bc384e7 100644
--- a/NEWS
+++ b/NEWS
@@ -47,7 +47,7 @@ As usual we have a large number of bug fixes since the last
release:
Release 2.20.19
On Wed, Feb 06, 2013 at 10:59:53AM +0100, Paul Menzel wrote:
Date: Sun, 3 Feb 2013 13:33:08 +0100
Building the package under Debian Sid/unstable, `dh_shlibdeps` informs
that `libI810XvMC.so.1.0.0` does not need to be linked against
`libX11-xcb.so.1`, `libxcb-dri2.so.0`, `libxcb-util.so.0` or
I'm a terrible proof-reader. Thanks for the correction, applied.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
770c12312ad617172b1a65b911d3e6564fc5aca8 is the first bad commit
commit 770c12312ad617172b1a65b911d3e6564fc5aca8
Author: Takashi Iwai ti...@suse.de
Date: Sat Aug 11 08:56:42 2012 +0200
drm/i915: Fix blank panel at reopening lid
changed the register write sequence for restoring the
Modifying the clock sources (via the DREF control on the PCH) is a slow
multi-stage process as we need to let the clocks stabilise between each
stage. If we are not actually changing the clock sources, then we can
return early.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
Wrap a preallocated region of stolen memory within an ordinary GEM
object, for example the BIOS framebuffer.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h|5 +++
drivers/gpu/drm/i915/i915_gem_stolen.c | 65
This will be shared with wrapping the BIOS framebuffer into the fbdev
later. In the meantime, we can tidy the code slightly and improve the
error path handling.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c |7 --
From: Jesse Barnes jbar...@virtuousgeek.org
Rather than building a config which may or may not work, let the driver
build an initial fb config. This allows the driver to use the BIOS boot
configuration for example, displaying kernel messages and the initial fb
console on the same outputs the
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_dma.c |8 +-
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/intel_display.c | 14 +-
drivers/gpu/drm/i915/intel_drv.h |4
Read the current hardware state to retrieve the active mode and populate
our CRTC config if that mode matches our presumptions.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/intel_crt.c | 27 +++-
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c |9 +
drivers/gpu/drm/i915/intel_dp.c |1 +
drivers/gpu/drm/i915/intel_drv.h |8
drivers/gpu/drm/i915/intel_fb.c |9 +
As we retrieve the mode from the BIOS it may be constructed using
different assumptions for its configuration, such as utilizing the panel
fitter in a conflicting manner. As such the associated framebuffer may be
insufficient for our setup, and so we need to reject the current mode
and install our
At Wed, 6 Feb 2013 11:24:41 +0100,
Daniel Vetter wrote:
770c12312ad617172b1a65b911d3e6564fc5aca8 is the first bad commit
commit 770c12312ad617172b1a65b911d3e6564fc5aca8
Author: Takashi Iwai ti...@suse.de
Date: Sat Aug 11 08:56:42 2012 +0200
drm/i915: Fix blank panel at reopening
At Tue, 5 Feb 2013 16:17:54 -0200,
Rodrigo Vivi wrote:
Tests are still being built by default. However this request
came from OSVs in order to allow them to include i-g-t in their
distributions by default avoiding adding more and more dependencies
since we are improving and adding more and
This has been discussed elsewhere, but I summarize here for
transparency:
This makes some of the display registers take the NEEDS_FORCE_WAKE path
in reg reads and writes, breaking things. Rebased on top of recent
drm-intel-next-queued with Ville's IS_DISPLAYREG nuking commits this
works all
On Wed, 06 Feb 2013, Daniel Vetter daniel.vet...@ffwll.ch wrote:
770c12312ad617172b1a65b911d3e6564fc5aca8 is the first bad commit
commit 770c12312ad617172b1a65b911d3e6564fc5aca8
Author: Takashi Iwai ti...@suse.de
Date: Sat Aug 11 08:56:42 2012 +0200
drm/i915: Fix blank panel at
On Wed, Feb 6, 2013 at 1:29 PM, Jani Nikula jani.nik...@linux.intel.com wrote:
Given how much pain the backlight keeps giving us, do you think we would
benefit from sticking a DRM_DEBUG_DRIVER in the if block there?
Either way, with a heavy *sigh*,
Reviewed-by: Jani Nikula
On Wed, Feb 06, 2013 at 11:10:21AM +, Chris Wilson wrote:
Modifying the clock sources (via the DREF control on the PCH) is a slow
multi-stage process as we need to let the clocks stabilise between each
stage. If we are not actually changing the clock sources, then we can
return early.
On Sat, 02 Feb 2013, Jesse Barnes jbar...@virtuousgeek.org wrote:
Add a few regs needed for various clock gating init purposes and make
sure they don't fall into the display offset range on VLV.
GEN7_UCGCTL4 needs to be fixed in i915_reg.h after IS_DISPLAYREG
removal.
Signed-off-by: Jesse
On Sat, 02 Feb 2013, Jesse Barnes jbar...@virtuousgeek.org wrote:
The Gunit has a separate reg for this, so allocate some stolen space for
the power context and initialize the reg.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h|2 ++
On Wed, 06 Feb 2013, Jani Nikula jani.nik...@linux.intel.com wrote:
On Sat, 02 Feb 2013, Jesse Barnes jbar...@virtuousgeek.org wrote:
Add a few regs needed for various clock gating init purposes and make
sure they don't fall into the display offset range on VLV.
GEN7_UCGCTL4 needs to be fixed
On Sat, 02 Feb 2013, Jesse Barnes jbar...@virtuousgeek.org wrote:
From: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.c |7 +++
drivers/gpu/drm/i915/i915_reg.h |1 +
2 files changed, 4 insertions(+), 4
On Sat, 02 Feb 2013, Jesse Barnes jbar...@virtuousgeek.org wrote:
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Reviewed-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_lvds.c |3 +++
1 file changed, 3 insertions(+)
diff --git
On Wed, Feb 6, 2013 at 2:19 PM, Jani Nikula jani.nik...@linux.intel.com wrote:
On Sat, 02 Feb 2013, Jesse Barnes jbar...@virtuousgeek.org wrote:
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Reviewed-by: Jani Nikula jani.nik...@intel.com
Up to now all the platform output setup
On a Intel core i3 (ivybridge) system (NUC) with 2 HDMI ports, I am trying to
get two independent screens by following this method.
http://en.gentoo-wiki.com/wiki/X.Org/Dual_Monitors#Single_graphics_card.2C_Multiple_X_screens_with_ZaphodHeads
And X is failing to start complaining about no usable
I'll break etiquette here and include the entire original message below
(and top-post!) since I'm sending this to intel-gfx as well.
Since the previous mail I've tested a more recent kernel (3.8-rc6),
swapping HDMI cables and a firmware update on the receiver, none of it
helped.
I've also
On Wed, Feb 06, 2013 at 06:43:53PM +, Kamble, Nitin A wrote:
On a Intel core i3 (ivybridge) system (NUC) with 2 HDMI ports, I am trying to
get two independent screens by following this method.
http://en.gentoo-wiki.com/wiki/X.Org/
-Original Message-
From: ch...@chris-wilson.co.uk [mailto:ch...@chris-wilson.co.uk]
Sent: Wednesday, February 06, 2013 2:12 PM
To: Kamble, Nitin A
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: ZaphodHeads with intel X driver
On Wed, Feb 06, 2013 at 06:43:53PM +, Kamble,
On Wed, Feb 06, 2013 at 11:00:49PM +, Kamble, Nitin A wrote:
Thanks Chris for the reply. Attached are all the relevant log files.
Both screen stanzas are pointing to the same device.
It should be:
Screen0 - Device0,
Screen1 - Device1
-Chris
--
Chris Wilson, Intel Open Source Technology
Chris,
X is failing even with this reduced 1 screen config.
Section Device
Identifier Intel0
Driver intel
BusID PCI:00:02:0
Option ZaphodHeads HDMI-A-1
Option AccelMethod SNA
Screen 0
EndSection
Section Monitor
IdentifierHDMI1
On Wed, Feb 06, 2013 at 11:43:51PM +, Kamble, Nitin A wrote:
Chris,
X is failing even with this reduced 1 screen config.
Section Device
Identifier Intel0
Driver intel
BusID PCI:00:02:0
Option ZaphodHeads HDMI-A-1
The ZaphodHead connector name should
The ZaphodHead connector name should match the name given by xrandr,
which would appear to be HDMI1. Getting closer...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Thanks Chris, Yes, it got me closer. The X is not failing now as seen in the
attached log with the attached
Sorry Chris, I spoke too soon.
The working config was single screen/monitor config, as attached here.
Commenting of SNA line made it work.
The dual screen configuration is still failing as before. And if I comment out
the SNA lines I get this in the X log.
[3056612.622] Requested Entity
On Wed, Feb 06, 2013 at 11:10:22AM +, Chris Wilson wrote:
Wrap a preallocated region of stolen memory within an ordinary GEM
object, for example the BIOS framebuffer.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h|5 +++
40 matches
Mail list logo
