Re: [Intel-gfx] [PATCH 1/3] PM: make VT switching to the suspend console optional v3
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 potentially restore the display configuration without userspace help. Such drivers can can call a new funciton, pm_vt_switch_required(false) if they support this feature. In that case, the PM layer won't VT switch to the suspend console at suspend time and then back to the original VT on resume, but rather leave things alone for a nicer looking suspend and resume sequence. v2: make a function so we can handle multiple drivers (Alan) v3: use a list to track device requests (Rafael) Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com for all [1-3/3]. Any chance for an r-b on the PM one at least? Then Daniel could probably push this through drm-intel-next. Done. Thanks, I've merged the first two patches to drm-intel-next, the i915 one still needs a bit of care imo. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Discard the unbound list when suspending
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 resume, just move them out of the unbound
tracking list on suspend and lazily reload them from the CPU domain as
and when they are used afterwards.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f6ef53f..db14c73 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3912,6 +3912,17 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
i915_gem_object_free(obj);
}
+static void
+i915_gem_discard_unbound(struct drm_i915_private *dev_priv)
+{
+ struct drm_i915_gem_object *obj, *next;
+
+ list_for_each_entry_safe(obj, next,
+dev_priv-mm.unbound_list,
+gtt_list)
+ (void)i915_gem_object_put_pages(obj);
+}
+
int
i915_gem_idle(struct drm_device *dev)
{
@@ -3936,6 +3947,19 @@ i915_gem_idle(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
i915_gem_evict_everything(dev);
+ /* For KMS we just want to discard the unbound list as it will
+* change domains when thawing - and restoring its domain upon
+* resume seems like a false optimisation. Also note that discarding
+* the unbound list will have the useful side-effect of dropping
+* purgeable objects which it seems pointless to restore as they are
+* merely a userspace cache.
+* However, we may still have some pinned objects (like dma-buf)
+* that cannot simply be discarded and will require domain
+* restoration upon resume.
+*/
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ i915_gem_discard_unbound(dev_priv);
+
i915_gem_reset_fences(dev);
/* Hack! Don't let anybody do execbuf while we don't control the chip.
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Restore GTT domain tracking of unbound objects upon resume
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 --- drivers/gpu/drm/i915/i915_gem_gtt.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index bdaca3f..368c821 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -404,6 +404,9 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev) i915_gem_gtt_bind_object(obj, obj-cache_level); } + list_for_each_entry(obj, dev_priv-mm.unbound_list, gtt_list) + i915_gem_clflush_object(obj); + i915_gem_chipset_flush(dev); } -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Restore GTT domain tracking of unbound objects upon resume
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: sta...@vger.kernel.org Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk I think this change will freak out Jesse, since it'll kill resume time when we clflush a few GB of memory. So could you throw another patch on top of this series (maybe after the unbound dropping) which calls restore_gtt only when thawing from hibernate, but not when resuming? --- drivers/gpu/drm/i915/i915_gem_gtt.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index bdaca3f..368c821 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -404,6 +404,9 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev) i915_gem_gtt_bind_object(obj, obj-cache_level); } + list_for_each_entry(obj, dev_priv-mm.unbound_list, gtt_list) + i915_gem_clflush_object(obj); + i915_gem_chipset_flush(dev); } -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Discard the unbound list when suspending
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. Rather than perform those clflushes for all
objects immediately upon resume, just move them out of the unbound
tracking list on suspend and lazily reload them from the CPU domain as
and when they are used afterwards.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Similar comment about fast resume performance: I think we should only do
these when freezing for hibernation. Otherwise browser performance with
cool new stuff like the fast S1x suspend (or whatever it's called again)
will be a horrible experience. Every time you just read for a few
seconds and the system suspend in the background we'll drop all gem bo's
on the floor ...
-Daniel
---
drivers/gpu/drm/i915/i915_gem.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f6ef53f..db14c73 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3912,6 +3912,17 @@ void i915_gem_free_object(struct drm_gem_object
*gem_obj)
i915_gem_object_free(obj);
}
+static void
+i915_gem_discard_unbound(struct drm_i915_private *dev_priv)
+{
+ struct drm_i915_gem_object *obj, *next;
+
+ list_for_each_entry_safe(obj, next,
+ dev_priv-mm.unbound_list,
+ gtt_list)
+ (void)i915_gem_object_put_pages(obj);
+}
+
int
i915_gem_idle(struct drm_device *dev)
{
@@ -3936,6 +3947,19 @@ i915_gem_idle(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
i915_gem_evict_everything(dev);
+ /* For KMS we just want to discard the unbound list as it will
+ * change domains when thawing - and restoring its domain upon
+ * resume seems like a false optimisation. Also note that discarding
+ * the unbound list will have the useful side-effect of dropping
+ * purgeable objects which it seems pointless to restore as they are
+ * merely a userspace cache.
+ * However, we may still have some pinned objects (like dma-buf)
+ * that cannot simply be discarded and will require domain
+ * restoration upon resume.
+ */
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ i915_gem_discard_unbound(dev_priv);
+
i915_gem_reset_fences(dev);
/* Hack! Don't let anybody do execbuf while we don't control the chip.
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] configure.ac: Split out XCB libraries from `XVMCLIB` into `XCB`
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
[…]
make[1]: Entering directory `/src/xserver-xorg-video-intel'
dh_shlibdeps -- --warnings=6
dpkg-shlibdeps: Warnung:
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen
libX11-xcb.so.1 gelinkt werden (es verwendet keines der Bibliotheks-Symbole)
dpkg-shlibdeps: Warnung:
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen
libxcb-dri2.so.0 gelinkt werden (es verwendet keines der Bibliotheks-Symbole)
dpkg-shlibdeps: Warnung:
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen
libxcb-util.so.0 gelinkt werden (es verwendet keines der Bibliotheks-Symbole)
dpkg-shlibdeps: Warnung:
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen
libxcb.so.1 gelinkt werden (es verwendet keines der Bibliotheks-Symbole)
make[1]: Leaving directory `/src/xserver-xorg-video-intel'
[…]
Moving `x11-xcb`, `xcb-dri2` and `xcb-aux` from `XVMCLIBS` into `XCB`
and adding `XCB_LIBS` only to the `LIBADD` variables of `libIntelXvMC`
makes the warnings go away and the libraries are still built without any
issues.
make[1]: Entering directory `/src/xserver-xorg-video-intel'
dh_shlibdeps -- --warnings=6
make[1]: Leaving directory `/src/xserver-xorg-video-intel'
dh_installdeb -O--builddirectory=build/
dh_xsf_substvars -O--builddirectory=build/
dh_gencontrol -O--builddirectory=build/
dpkg-gencontrol: Warnung: Feld Depends von Paket
xserver-xorg-video-intel-dbg: unbekannte Substitutionsvariable ${shlibs:Depends}
dh_md5sums -O--builddirectory=build/
dh_builddeb -O--builddirectory=build/
dpkg-deb: Paket »xserver-xorg-video-intel« wird in
»../xserver-xorg-video-intel_2.19.0-6.1_i386.deb« gebaut.
dpkg-deb: Paket »xserver-xorg-video-intel-dbg« wird in
»../xserver-xorg-video-intel-dbg_2.19.0-6.1_i386.deb« gebaut.
dpkg-genchanges -b ../xserver-xorg-video-intel_2.19.0-6.1_i386.changes
dpkg-genchanges: rein binärer Upload - es ist kein Quellcode hinzugefügt
dpkg-source --after-build xserver-xorg-video-intel
dpkg-buildpackage: Binärpaket(e) hochzuladen (keine Quellen enthalten)
Now running lintian...
W: xserver-xorg-video-intel: hardening-no-relro
usr/lib/libI810XvMC.so.1.0.0
W: xserver-xorg-video-intel: hardening-no-fortify-functions
usr/lib/libI810XvMC.so.1.0.0
W: xserver-xorg-video-intel: hardening-no-relro
usr/lib/libIntelXvMC.so.1.0.0
W: xserver-xorg-video-intel: hardening-no-fortify-functions
usr/lib/libIntelXvMC.so.1.0.0
W: xserver-xorg-video-intel: hardening-no-relro
usr/lib/xorg/modules/drivers/intel_drv.so
W: xserver-xorg-video-intel: hardening-no-fortify-functions
usr/lib/xorg/modules/drivers/intel_drv.so
N: 1 tag overridden (1 warning)
Finished running lintian.
The modules were originally added with the following commit present
since tag 2.10.0.
commit 3e8f2eae3a586aa29be4858698e666e0ec778cea
Author: Eric Anholt e...@anholt.net
Date: Thu Oct 15 13:48:56 2009 -0700
XVMC: Use XCB DRI2 instead of cargo-culting our own copy of Xlib
stuff. (v2)
[1]
https://buildd.debian.org/status/fetch.php?pkg=xserver-xorg-video-intelarch=i386ver=2%3A2.19.0-6stamp=1347825458
Signed-off-by: Paul Menzel paulepan...@users.sourceforge.net
---
configure.ac |3 ++-
src/xvmc/Makefile.am |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index e6ab9d0..5ae4208 100644
--- a/configure.ac
+++ b/configure.ac
@@ -404,8 +404,9 @@ AC_MSG_RESULT([$DRI2])
if test $XVMC = yes; then
PKG_CHECK_MODULES(XVMCLIB,
- [xvmc dri2proto x11-xcb xcb-dri2 xcb-aux],
+ [xvmc dri2proto],
[XVMC=yes], [XVMC=no])
+ PKG_CHECK_MODULES(XCB, [x11-xcb xcb-dri2 xcb-aux])
fi
AC_MSG_CHECKING([whether to include XvMC support])
AC_MSG_RESULT([$XVMC])
diff --git a/src/xvmc/Makefile.am b/src/xvmc/Makefile.am
index 36a939b..85e6a89 100644
--- a/src/xvmc/Makefile.am
+++ b/src/xvmc/Makefile.am
@@ -20,4 +20,4 @@ AM_CFLAGS = @XORG_CFLAGS@ @DRM_CFLAGS@ @DRI_CFLAGS@ \
@XVMCLIB_CFLAGS@ -I$(top_srcdir)/src -DTRUE=1 -DFALSE=0
libIntelXvMC_la_LDFLAGS = -version-number 1:0:0
-libIntelXvMC_la_LIBADD = @DRI_LIBS@ @DRM_LIBS@ @XVMCLIB_LIBS@ @DRMINTEL_LIBS@
-lpthread
+libIntelXvMC_la_LIBADD = @DRI_LIBS@ @DRM_LIBS@ @XVMCLIB_LIBS@ @XCB_LIBS@
@DRMINTEL_LIBS@ -lpthread
--
1.7.10.4
signature.asc
Description: This is a digitally signed
[Intel-gfx] [PATCH] NEWS: Fix a typo: a*n* inadvertent
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 (2013-01-20) A quick release as the last broke USB DisplayLink slave outputs badly. The -performance of those displays was unusable due to a inadvertent change that +performance of those displays was unusable due to an inadvertent change that caused us to flush the entire scanout over the USB for every drawing operation. -- 1.7.10.4 signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] configure.ac: Split out XCB libraries from `XVMCLIB` into `XCB`
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 `libxcb.so.1` [1]. [snip] Thanks for the patch, 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
Re: [Intel-gfx] [PATCH] NEWS: Fix a typo: a*n* inadvertent
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
[Intel-gfx] [PATCH] drm/i915: write backlight harder
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 backlight, which
helped prevent non-working backlights on some machines. Turns out that
the original sequence was the right thing to do for a different set of
machines. Worse, setting the backlight level _after_ enabling it seems
to reset it somehow. So we need to make that one conditional upon the
backlight having been reset to zero, and add the old one back.
Cargo-culting at it's best, but it seems to work.
Cc: sta...@vger.kernel.org
Cc: Takashi Iwai ti...@suse.de
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_panel.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index bee8cb6..a3730e0 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -321,6 +321,9 @@ void intel_panel_enable_backlight(struct drm_device *dev,
if (dev_priv-backlight_level == 0)
dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
+ dev_priv-backlight_enabled = true;
+ intel_panel_actually_set_backlight(dev, dev_priv-backlight_level);
+
if (INTEL_INFO(dev)-gen = 4) {
uint32_t reg, tmp;
@@ -356,12 +359,12 @@ void intel_panel_enable_backlight(struct drm_device *dev,
}
set_level:
- /* Call below after setting BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1.
-* BLC_PWM_CPU_CTL may be cleared to zero automatically when these
-* registers are set.
+ /* Check the current backlight level and try to set again if it's zero.
+* On some machines, BLC_PWM_CPU_CTL is cleared to zero automatically
+* when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 are written.
*/
- dev_priv-backlight_enabled = true;
- intel_panel_actually_set_backlight(dev, dev_priv-backlight_level);
+ if (!intel_panel_get_backlight(dev))
+ intel_panel_actually_set_backlight(dev,
dev_priv-backlight_level);
}
static void intel_panel_init_backlight(struct drm_device *dev)
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915: Skip modifying PCH DREF if not changing clock sources
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
---
drivers/gpu/drm/i915/intel_display.c | 83 +-
1 file changed, 61 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d75c6a0..f1dbd01 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4749,7 +4749,7 @@ static void ironlake_init_pch_refclk(struct drm_device
*dev)
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_mode_config *mode_config = dev-mode_config;
struct intel_encoder *encoder;
- u32 temp;
+ u32 val, final;
bool has_lvds = false;
bool has_cpu_edp = false;
bool has_pch_edp = false;
@@ -4792,70 +4792,109 @@ static void ironlake_init_pch_refclk(struct drm_device
*dev)
* PCH B stepping, previous chipset stepping should be
* ignoring this setting.
*/
- temp = I915_READ(PCH_DREF_CONTROL);
+ val = I915_READ(PCH_DREF_CONTROL);
+
+ /* As we must carefully and slowly disable/enable each source in turn,
+* compute the final state we want first and check if we need to
+* make any changes at all.
+*/
+ final = val;
+ final = ~DREF_NONSPREAD_SOURCE_MASK;
+ if (has_ck505)
+ final |= DREF_NONSPREAD_CK505_ENABLE;
+ else
+ final |= DREF_NONSPREAD_SOURCE_ENABLE;
+
+ final = ~DREF_SSC_SOURCE_MASK;
+ final = ~DREF_CPU_SOURCE_OUTPUT_MASK;
+ final = ~DREF_SSC1_ENABLE;
+
+ if (has_panel) {
+ final |= DREF_SSC_SOURCE_ENABLE;
+
+ if (intel_panel_use_ssc(dev_priv) can_ssc)
+ final |= DREF_SSC1_ENABLE;
+
+ if (has_cpu_edp) {
+ if (intel_panel_use_ssc(dev_priv) can_ssc)
+ final |= DREF_CPU_SOURCE_OUTPUT_DOWNSPREAD;
+ else
+ final |= DREF_CPU_SOURCE_OUTPUT_NONSPREAD;
+ } else
+ final |= DREF_CPU_SOURCE_OUTPUT_DISABLE;
+ } else {
+ final |= DREF_SSC_SOURCE_DISABLE;
+ final |= DREF_CPU_SOURCE_OUTPUT_DISABLE;
+ }
+
+ if (final == val)
+ return;
+
/* Always enable nonspread source */
- temp = ~DREF_NONSPREAD_SOURCE_MASK;
+ val = ~DREF_NONSPREAD_SOURCE_MASK;
if (has_ck505)
- temp |= DREF_NONSPREAD_CK505_ENABLE;
+ val |= DREF_NONSPREAD_CK505_ENABLE;
else
- temp |= DREF_NONSPREAD_SOURCE_ENABLE;
+ val |= DREF_NONSPREAD_SOURCE_ENABLE;
if (has_panel) {
- temp = ~DREF_SSC_SOURCE_MASK;
- temp |= DREF_SSC_SOURCE_ENABLE;
+ val = ~DREF_SSC_SOURCE_MASK;
+ val |= DREF_SSC_SOURCE_ENABLE;
/* SSC must be turned on before enabling the CPU output */
if (intel_panel_use_ssc(dev_priv) can_ssc) {
DRM_DEBUG_KMS(Using SSC on panel\n);
- temp |= DREF_SSC1_ENABLE;
+ val |= DREF_SSC1_ENABLE;
} else
- temp = ~DREF_SSC1_ENABLE;
+ val = ~DREF_SSC1_ENABLE;
/* Get SSC going before enabling the outputs */
- I915_WRITE(PCH_DREF_CONTROL, temp);
+ I915_WRITE(PCH_DREF_CONTROL, val);
POSTING_READ(PCH_DREF_CONTROL);
udelay(200);
- temp = ~DREF_CPU_SOURCE_OUTPUT_MASK;
+ val = ~DREF_CPU_SOURCE_OUTPUT_MASK;
/* Enable CPU source on CPU attached eDP */
if (has_cpu_edp) {
if (intel_panel_use_ssc(dev_priv) can_ssc) {
DRM_DEBUG_KMS(Using SSC on eDP\n);
- temp |= DREF_CPU_SOURCE_OUTPUT_DOWNSPREAD;
+ val |= DREF_CPU_SOURCE_OUTPUT_DOWNSPREAD;
}
else
- temp |= DREF_CPU_SOURCE_OUTPUT_NONSPREAD;
+ val |= DREF_CPU_SOURCE_OUTPUT_NONSPREAD;
} else
- temp |= DREF_CPU_SOURCE_OUTPUT_DISABLE;
+ val |= DREF_CPU_SOURCE_OUTPUT_DISABLE;
- I915_WRITE(PCH_DREF_CONTROL, temp);
+ I915_WRITE(PCH_DREF_CONTROL, val);
POSTING_READ(PCH_DREF_CONTROL);
udelay(200);
} else {
DRM_DEBUG_KMS(Disabling SSC entirely\n);
- temp = ~DREF_CPU_SOURCE_OUTPUT_MASK;
+
[Intel-gfx] [PATCH 2/8] drm/i915: Introduce i915_gem_object_create_stolen_for_preallocated
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
2 files changed, 70 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 08c5def..fd8a495 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1720,6 +1720,11 @@ void i915_gem_stolen_cleanup_compression(struct
drm_device *dev);
void i915_gem_cleanup_stolen(struct drm_device *dev);
struct drm_i915_gem_object *
i915_gem_object_create_stolen(struct drm_device *dev, u32 size);
+struct drm_i915_gem_object *
+i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
+ u32 stolen_offset,
+ u32 gtt_offset,
+ u32 size);
void i915_gem_object_release_stolen(struct drm_i915_gem_object *obj);
/* i915_gem_tiling.c */
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 69d97cb..130d1db 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -312,6 +312,71 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32
size)
return NULL;
}
+struct drm_i915_gem_object *
+i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
+ u32 stolen_offset,
+ u32 gtt_offset,
+ u32 size)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_i915_gem_object *obj;
+ struct drm_mm_node *stolen;
+
+ if (dev_priv-mm.stolen_base == 0)
+ return NULL;
+
+ DRM_DEBUG_KMS(creating preallocated stolen object: stolen_offset=%x,
gtt_offset=%x, size=%x\n,
+ stolen_offset, gtt_offset, size);
+
+ /* KISS and expect everything to be page-aligned */
+ BUG_ON(stolen_offset 4095);
+ BUG_ON(gtt_offset 4095);
+ BUG_ON(size 4095);
+
+ if (WARN_ON(size == 0))
+ return NULL;
+
+ stolen = drm_mm_create_block(dev_priv-mm.stolen,
+stolen_offset, size,
+false);
+ if (stolen == NULL) {
+ DRM_DEBUG_KMS(failed to allocate stolen space\n);
+ return NULL;
+ }
+
+ obj = _i915_gem_object_create_stolen(dev, stolen);
+ if (obj == NULL) {
+ DRM_DEBUG_KMS(failed to allocate stolen object\n);
+ drm_mm_put_block(stolen);
+ return NULL;
+ }
+
+ /* To simplify the initialisation sequence between KMS and GTT,
+* we allow construction of the stolen object prior to
+* setting up the GTT space. The actual reservation will occur
+* later.
+*/
+ if (drm_mm_initialized(dev_priv-mm.gtt_space)) {
+ obj-gtt_space = drm_mm_create_block(dev_priv-mm.gtt_space,
+gtt_offset, size,
+false);
+ if (obj-gtt_space == NULL) {
+ DRM_DEBUG_KMS(failed to allocate stolen GTT space\n);
+ drm_gem_object_unreference(obj-base);
+ return NULL;
+ }
+ } else
+ obj-gtt_space = I915_GTT_RESERVED;
+
+ obj-gtt_offset = gtt_offset;
+ obj-has_global_gtt_mapping = 1;
+
+ list_add_tail(obj-gtt_list, dev_priv-mm.bound_list);
+ list_add_tail(obj-mm_list, dev_priv-mm.inactive_list);
+
+ return obj;
+}
+
void
i915_gem_object_release_stolen(struct drm_i915_gem_object *obj)
{
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/8] drm/i915: Split the framebuffer_info creation into a separate routine
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 --
drivers/gpu/drm/i915/intel_drv.h |7 ++
drivers/gpu/drm/i915/intel_fb.c | 154 ++
3 files changed, 91 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f1dbd01..8f9cdd7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6413,13 +6413,6 @@ intel_framebuffer_create(struct drm_device *dev,
}
static u32
-intel_framebuffer_pitch_for_width(int width, int bpp)
-{
- u32 pitch = DIV_ROUND_UP(width * bpp, 8);
- return ALIGN(pitch, 64);
-}
-
-static u32
intel_framebuffer_size_for_mode(struct drm_display_mode *mode, int bpp)
{
u32 pitch = intel_framebuffer_pitch_for_width(mode-hdisplay, bpp);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 13afb37..07d95a1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -134,6 +134,13 @@ struct intel_framebuffer {
struct drm_i915_gem_object *obj;
};
+inline static u32
+intel_framebuffer_pitch_for_width(int width, int bpp)
+{
+ u32 pitch = DIV_ROUND_UP(width * bpp, 8);
+ return ALIGN(pitch, 64);
+}
+
struct intel_fbdev {
struct drm_fb_helper helper;
struct intel_framebuffer ifb;
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 6591029..de0ac4c 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -57,29 +57,96 @@ static struct fb_ops intelfb_ops = {
.fb_debug_leave = drm_fb_helper_debug_leave,
};
+static struct fb_info *intelfb_create_info(struct intel_fbdev *ifbdev)
+{
+ struct drm_framebuffer *fb = ifbdev-ifb.base;
+ struct drm_device *dev = fb-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct fb_info *info;
+ u32 gtt_offset, size;
+ int ret;
+
+ info = framebuffer_alloc(0, dev-pdev-dev);
+ if (!info)
+ return NULL;
+
+ info-par = ifbdev;
+ ifbdev-helper.fb = fb;
+ ifbdev-helper.fbdev = info;
+
+ strcpy(info-fix.id, inteldrmfb);
+
+ info-flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
+ info-fbops = intelfb_ops;
+
+ ret = fb_alloc_cmap(info-cmap, 256, 0);
+ if (ret)
+ goto err_info;
+
+ /* setup aperture base/size for vesafb takeover */
+ info-apertures = alloc_apertures(1);
+ if (!info-apertures)
+ goto err_cmap;
+
+ info-apertures-ranges[0].base = dev-mode_config.fb_base;
+ info-apertures-ranges[0].size = dev_priv-gtt.mappable_end;
+
+ gtt_offset = ifbdev-ifb.obj-gtt_offset;
+ size = ifbdev-ifb.obj-base.size;
+
+ info-fix.smem_start = dev-mode_config.fb_base + gtt_offset;
+ info-fix.smem_len = size;
+
+ info-screen_size = size;
+ info-screen_base = ioremap_wc(dev_priv-gtt.mappable_base + gtt_offset,
+ size);
+ if (!info-screen_base)
+ goto err_cmap;
+
+ /* If the object is shmemfs backed, it will have given us zeroed pages.
+* If the object is stolen however, it will be full of whatever
+* garbage was left in there.
+*/
+ if (ifbdev-ifb.obj-stolen)
+ memset_io(info-screen_base, 0, info-screen_size);
+
+ /* Use default scratch pixmap (info-pixmap.flags = FB_PIXMAP_SYSTEM) */
+
+ drm_fb_helper_fill_fix(info, fb-pitches[0], fb-depth);
+ drm_fb_helper_fill_var(info, ifbdev-helper, fb-width, fb-height);
+
+ return info;
+
+err_cmap:
+ if (info-cmap.len)
+ fb_dealloc_cmap(info-cmap);
+err_info:
+ framebuffer_release(info);
+ return NULL;
+}
+
static int intelfb_create(struct intel_fbdev *ifbdev,
struct drm_fb_helper_surface_size *sizes)
{
struct drm_device *dev = ifbdev-helper.dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct fb_info *info;
- struct drm_framebuffer *fb;
- struct drm_mode_fb_cmd2 mode_cmd = {};
+ struct drm_mode_fb_cmd2 mode_cmd = { 0 };
struct drm_i915_gem_object *obj;
- struct device *device = dev-pdev-dev;
+ struct fb_info *info;
int size, ret;
/* we don't do packed 24bpp */
if (sizes-surface_bpp == 24)
sizes-surface_bpp = 32;
- mode_cmd.width = sizes-surface_width;
+ mode_cmd.width = sizes-surface_width;
mode_cmd.height = sizes-surface_height;
- mode_cmd.pitches[0] = ALIGN(mode_cmd.width * ((sizes-surface_bpp + 7) /
-
[Intel-gfx] [PATCH 4/8] drm: add initial_config function to fb helper
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 BIOS lit up at boot time. If that
fails, the driver can still fall back the same way as the core.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_fb_helper.c | 23 +++
include/drm/drm_fb_helper.h |4
2 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 954d175..924901d 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1247,7 +1247,7 @@ static void drm_setup_crtcs(struct drm_fb_helper
*fb_helper)
struct drm_mode_set *modeset;
bool *enabled;
int width, height;
- int i, ret;
+ int i;
DRM_DEBUG_KMS(\n);
@@ -1268,16 +1268,23 @@ static void drm_setup_crtcs(struct drm_fb_helper
*fb_helper)
drm_enable_connectors(fb_helper, enabled);
- ret = drm_target_cloned(fb_helper, modes, enabled, width, height);
- if (!ret) {
- ret = drm_target_preferred(fb_helper, modes, enabled, width,
height);
- if (!ret)
+ if (!(fb_helper-funcs-initial_config
+ fb_helper-funcs-initial_config(fb_helper, crtcs, modes,
+ enabled, width, height))) {
+ memset(modes, 0,
dev-mode_config.num_connector*sizeof(modes[0]));
+ memset(crtcs, 0,
dev-mode_config.num_connector*sizeof(crtcs[0]));
+
+ if (!drm_target_cloned(fb_helper,
+ modes, enabled, width, height)
+ !drm_target_preferred(fb_helper,
+ modes, enabled, width, height))
DRM_ERROR(Unable to find initial modes\n);
- }
- DRM_DEBUG_KMS(picking CRTCs for %dx%d config\n, width, height);
+ DRM_DEBUG_KMS(picking CRTCs for %dx%d config\n,
+ width, height);
- drm_pick_crtcs(fb_helper, crtcs, modes, 0, width, height);
+ drm_pick_crtcs(fb_helper, crtcs, modes, 0, width, height);
+ }
/* need to set the modesets up here for use later */
/* fill out the connector-crtc mappings into the modesets */
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 5120b01..40b0c5c 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -56,6 +56,10 @@ struct drm_fb_helper_funcs {
int (*fb_probe)(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes);
+ bool (*initial_config)(struct drm_fb_helper *fb_helper,
+ struct drm_fb_helper_crtc **crtcs,
+ struct drm_display_mode **modes,
+ bool *enabled, int width, int height);
};
struct drm_fb_helper_connector {
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon
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 +
drivers/gpu/drm/i915/intel_fb.c | 305 +++---
5 files changed, 306 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4fa6beb..f2b7db7 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1273,6 +1273,7 @@ static const struct vga_switcheroo_client_ops
i915_switcheroo_ops = {
static int i915_load_modeset_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ bool was_vga_enabled;
int ret;
ret = intel_parse_bios(dev);
@@ -1309,7 +1310,11 @@ static int i915_load_modeset_init(struct drm_device *dev)
/* Important: The output setup functions called by modeset_init need
* working irqs for e.g. gmbus and dp aux transfers. */
- intel_modeset_init(dev);
+ intel_modeset_init(dev, was_vga_enabled);
+
+ /* Wrap existing BIOS mode configuration prior to GEM takeover */
+ if (!was_vga_enabled)
+ intel_fbdev_init_bios(dev);
ret = i915_gem_init(dev);
if (ret)
@@ -1323,6 +1328,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
/* FIXME: do pre/post-mode set stuff in core KMS code */
dev-vblank_disable_allowed = 1;
+ /* Install a default KMS/GEM fbcon if we failed to wrap the BIOS fb */
ret = intel_fbdev_init(dev);
if (ret)
goto cleanup_gem;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fd8a495..6f4afbf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1814,7 +1814,7 @@ static inline void intel_unregister_dsm_handler(void) {
return; }
/* modesetting */
extern void intel_modeset_init_hw(struct drm_device *dev);
-extern void intel_modeset_init(struct drm_device *dev);
+extern void intel_modeset_init(struct drm_device *dev, bool *was_vga_enabled);
extern void intel_modeset_gem_init(struct drm_device *dev);
extern void intel_modeset_cleanup(struct drm_device *dev);
extern int intel_modeset_vga_set_state(struct drm_device *dev, bool state);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8f9cdd7..7c4c7d5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8698,12 +8698,17 @@ static void intel_init_quirks(struct drm_device *dev)
}
/* Disable the VGA plane that we never use */
-static void i915_disable_vga(struct drm_device *dev)
+static bool i915_disable_vga(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ bool was_enabled;
u8 sr1;
u32 vga_reg = i915_vgacntrl_reg(dev);
+ was_enabled = !(I915_READ(vga_reg) VGA_DISP_DISABLE);
+ DRM_DEBUG_KMS(VGA output is currently %s\n,
+ was_enabled ? enabled : disabled);
+
vga_get_uninterruptible(dev-pdev, VGA_RSRC_LEGACY_IO);
outb(SR01, VGA_SR_INDEX);
sr1 = inb(VGA_SR_DATA);
@@ -8713,6 +8718,8 @@ static void i915_disable_vga(struct drm_device *dev)
I915_WRITE(vga_reg, VGA_DISP_DISABLE);
POSTING_READ(vga_reg);
+
+ return was_enabled;
}
void intel_modeset_init_hw(struct drm_device *dev)
@@ -8728,7 +8735,8 @@ void intel_modeset_init_hw(struct drm_device *dev)
mutex_unlock(dev-struct_mutex);
}
-void intel_modeset_init(struct drm_device *dev)
+void intel_modeset_init(struct drm_device *dev,
+ bool *was_vga_enabled)
{
struct drm_i915_private *dev_priv = dev-dev_private;
int i, ret;
@@ -8775,7 +8783,7 @@ void intel_modeset_init(struct drm_device *dev)
intel_pch_pll_init(dev);
/* Just disable it once at startup */
- i915_disable_vga(dev);
+ *was_vga_enabled = i915_disable_vga(dev);
intel_setup_outputs(dev);
/* Just in case the BIOS is doing something questionable. */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 07d95a1..985e9dd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -146,6 +146,8 @@ struct intel_fbdev {
struct intel_framebuffer ifb;
struct list_head fbdev_list;
struct drm_display_mode *our_mode;
+ bool stolen;
+ int preferred_bpp;
};
struct intel_encoder {
@@ -212,6 +214,7 @@ struct intel_crtc {
enum plane plane;
enum transcoder cpu_transcoder;
u8 lut_r[256], lut_g[256], lut_b[256];
+ bool mode_valid;
/*
* Whether the crtc and the connected output pipeline is active. Implies
[Intel-gfx] [PATCH 6/8] drm/i915: Retrieve the current mode upon KMS takeover
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 +++-
drivers/gpu/drm/i915/intel_display.c | 119 ++
drivers/gpu/drm/i915/intel_dp.c | 22 +++
drivers/gpu/drm/i915/intel_drv.h |7 +-
drivers/gpu/drm/i915/intel_dvo.c | 36 ++
drivers/gpu/drm/i915/intel_hdmi.c| 22 +++
drivers/gpu/drm/i915/intel_lvds.c| 27 +++-
drivers/gpu/drm/i915/intel_sdvo.c| 23 +++
9 files changed, 242 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6f4afbf..aff1436 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -280,6 +280,8 @@ struct drm_i915_display_funcs {
void (*update_linetime_wm)(struct drm_device *dev, int pipe,
struct drm_display_mode *mode);
void (*modeset_global_resources)(struct drm_device *dev);
+ bool (*crtc_get_mode)(struct drm_crtc *crtc,
+struct drm_display_mode *mode);
int (*crtc_mode_set)(struct drm_crtc *crtc,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode,
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 68e79f3..aa3001a 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -81,6 +81,27 @@ static bool intel_crt_get_hw_state(struct intel_encoder
*encoder,
return true;
}
+static unsigned intel_crt_get_mode_flags(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
+ struct intel_crt *crt = intel_encoder_to_crt(encoder);
+ u32 tmp, flags = 0;
+
+ tmp = I915_READ(crt-adpa_reg);
+
+ if (tmp ADPA_HSYNC_ACTIVE_HIGH)
+ flags |= DRM_MODE_FLAG_PHSYNC;
+ else
+ flags |= DRM_MODE_FLAG_NHSYNC;
+
+ if (tmp ADPA_VSYNC_ACTIVE_HIGH)
+ flags |= DRM_MODE_FLAG_PVSYNC;
+ else
+ flags |= DRM_MODE_FLAG_NVSYNC;
+
+ return flags;
+}
+
static void intel_disable_crt(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
@@ -777,10 +798,12 @@ void intel_crt_init(struct drm_device *dev)
crt-base.disable = intel_disable_crt;
crt-base.enable = intel_enable_crt;
- if (HAS_DDI(dev))
+ if (HAS_DDI(dev)) {
crt-base.get_hw_state = intel_ddi_get_hw_state;
- else
+ } else {
crt-base.get_hw_state = intel_crt_get_hw_state;
+ crt-base.get_mode_flags = intel_crt_get_mode_flags;
+ }
intel_connector-get_hw_state = intel_connector_get_hw_state;
drm_encoder_helper_add(crt-base.base, crt_encoder_funcs);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7c4c7d5..43e226d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6600,11 +6600,12 @@ void intel_release_load_detect_pipe(struct
drm_connector *connector,
}
/* Returns the clock of the currently programmed mode of the given pipe. */
-static int intel_crtc_clock_get(struct drm_device *dev, struct drm_crtc *crtc)
+static int i9xx_crtc_clock_get(struct drm_crtc *crtc)
{
+ struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- int pipe = intel_crtc-pipe;
+ enum pipe pipe = intel_crtc-pipe;
u32 dpll = I915_READ(DPLL(pipe));
u32 fp;
intel_clock_t clock;
@@ -6687,35 +6688,84 @@ static int intel_crtc_clock_get(struct drm_device *dev,
struct drm_crtc *crtc)
}
/** Returns the currently programmed mode of the given pipe. */
-struct drm_display_mode *intel_crtc_mode_get(struct drm_device *dev,
-struct drm_crtc *crtc)
+static bool i9xx_crtc_get_mode(struct drm_crtc *crtc,
+ struct drm_display_mode *mode)
{
- struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_i915_private *dev_priv = crtc-dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum transcoder cpu_transcoder = intel_crtc-cpu_transcoder;
- struct drm_display_mode *mode;
- int htot = I915_READ(HTOTAL(cpu_transcoder));
- int hsync = I915_READ(HSYNC(cpu_transcoder));
- int vtot = I915_READ(VTOTAL(cpu_transcoder));
- int vsync = I915_READ(VSYNC(cpu_transcoder));
+ u32 tmp;
- mode = kzalloc(sizeof(*mode), GFP_KERNEL);
- if (!mode)
-
[Intel-gfx] [PATCH 7/8] drm/i915: Only preserve the BIOS modes if they are the preferred ones
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 +
drivers/gpu/drm/i915/intel_lvds.c|1 +
drivers/gpu/drm/i915/intel_panel.c | 10 ++
6 files changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 43e226d..c1d8200 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9233,6 +9233,15 @@ void intel_connector_attach_encoder(struct
intel_connector *connector,
encoder-base);
}
+bool intel_connector_get_preferred_mode(struct intel_connector *connector,
+ struct drm_display_mode *mode)
+{
+ if (!connector-get_preferred_mode)
+ return false;
+
+ return connector-get_preferred_mode(connector, mode);
+}
+
/*
* set vga decode state - true == enable VGA decode
*/
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c82aed3..c8597d9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2922,6 +2922,7 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
}
if (is_edp(intel_dp)) {
+ intel_connector-get_preferred_mode =
intel_connector_get_panel_fixed_mode;
intel_panel_init(intel_connector-panel, fixed_mode);
intel_panel_setup_backlight(connector);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a6c0b25..8bd9bf0 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -204,6 +204,9 @@ struct intel_connector {
* and active (i.e. dpms ON state). */
bool (*get_hw_state)(struct intel_connector *);
+ bool (*get_preferred_mode)(struct intel_connector *,
+ struct drm_display_mode *);
+
/* Panel info for eDP and LVDS */
struct intel_panel panel;
@@ -505,6 +508,9 @@ extern int intel_panel_init(struct intel_panel *panel,
struct drm_display_mode *fixed_mode);
extern void intel_panel_fini(struct intel_panel *panel);
+extern bool intel_connector_get_panel_fixed_mode(struct intel_connector
*connector,
+struct drm_display_mode *mode);
+
extern void intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode);
extern void intel_pch_panel_fitting(struct drm_device *dev,
@@ -576,6 +582,8 @@ hdmi_to_dig_port(struct intel_hdmi *intel_hdmi)
bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
struct intel_digital_port *port);
+extern bool intel_connector_get_preferred_mode(struct intel_connector
*connector,
+ struct drm_display_mode *mode);
extern void intel_connector_attach_encoder(struct intel_connector *connector,
struct intel_encoder *encoder);
extern struct drm_encoder *intel_best_encoder(struct drm_connector *connector);
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index ca6c8e6..32bc904 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -237,6 +237,7 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
for (i = 0; i fb_helper-connector_count; i++) {
struct drm_connector *connector;
struct drm_encoder *encoder;
+ struct drm_display_mode mode;
connector = fb_helper-connector_info[i]-connector;
if (!enabled[i]) {
@@ -266,6 +267,14 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
return false;
}
+ if
(intel_connector_get_preferred_mode(to_intel_connector(connector), mode)
+ !drm_mode_equal(mode, encoder-crtc-mode)) {
+ DRM_DEBUG_KMS(connector %s on crtc %d has an
non-native mode, aborting\n,
+ drm_get_connector_name(connector),
+ encoder-crtc-base.id);
+ return false;
+ }
+
modes[i] = encoder-crtc-mode;
crtcs[i] = intel_fb_helper_crtc(fb_helper, encoder-crtc);
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 3da1b2a..9f4381e 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -1134,6 +1134,7 @@ bool intel_lvds_init(struct drm_device *dev)
intel_encoder-get_hw_state =
[Intel-gfx] [PATCH 8/8] drm/i915: Validate that the framebuffer accommodates the current mode
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 own.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 38 +-
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c1d8200..f5d4d88 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6441,27 +6441,40 @@ intel_framebuffer_create_for_mode(struct drm_device
*dev,
return intel_framebuffer_create(dev, mode_cmd, obj);
}
+static bool
+mode_fits_in_fb(struct drm_display_mode *mode,
+ struct drm_framebuffer *fb)
+{
+ struct drm_i915_gem_object *obj;
+ int min_pitch;
+
+ min_pitch = intel_framebuffer_pitch_for_width(mode-hdisplay,
+ fb-bits_per_pixel);
+ if (fb-pitches[0] min_pitch)
+ return false;
+
+ obj = to_intel_framebuffer(fb)-obj;
+ if (obj == NULL)
+ return false;
+
+ if (obj-base.size mode-vdisplay * fb-pitches[0])
+ return false;
+
+ return true;
+}
+
static struct drm_framebuffer *
mode_fits_in_fbdev(struct drm_device *dev,
struct drm_display_mode *mode)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- struct drm_i915_gem_object *obj;
struct drm_framebuffer *fb;
if (dev_priv-fbdev == NULL)
return NULL;
- obj = dev_priv-fbdev-ifb.obj;
- if (obj == NULL)
- return NULL;
-
fb = dev_priv-fbdev-ifb.base;
- if (fb-pitches[0] intel_framebuffer_pitch_for_width(mode-hdisplay,
-
fb-bits_per_pixel))
- return NULL;
-
- if (obj-base.size mode-vdisplay * fb-pitches[0])
+ if (!mode_fits_in_fb(mode, fb))
return NULL;
return fb;
@@ -9090,6 +9103,11 @@ void intel_modeset_setup_hw_state(struct drm_device *dev,
if (crtc-base.enabled)
crtc-mode_valid = intel_crtc_get_mode(crtc-base,
crtc-base.mode);
+
+ if (crtc-base.fb
+ !mode_fits_in_fb(crtc-base.mode, crtc-base.fb))
+ crtc-mode_valid = false;
+
if (crtc-mode_valid) {
DRM_DEBUG_KMS(found active mode: );
drm_mode_debug_printmodeline(crtc-base.mode);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: write backlight harder
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 lid
changed the register write sequence for restoring the backlight, which
helped prevent non-working backlights on some machines. Turns out that
the original sequence was the right thing to do for a different set of
machines. Worse, setting the backlight level _after_ enabling it seems
to reset it somehow. So we need to make that one conditional upon the
backlight having been reset to zero, and add the old one back.
Cargo-culting at it's best, but it seems to work.
Cc: sta...@vger.kernel.org
Cc: Takashi Iwai ti...@suse.de
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Feel free to take:
Acked-by: Takashi Iwai ti...@suse.de
thanks,
Takashi
---
drivers/gpu/drm/i915/intel_panel.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index bee8cb6..a3730e0 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -321,6 +321,9 @@ void intel_panel_enable_backlight(struct drm_device *dev,
if (dev_priv-backlight_level == 0)
dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
+ dev_priv-backlight_enabled = true;
+ intel_panel_actually_set_backlight(dev, dev_priv-backlight_level);
+
if (INTEL_INFO(dev)-gen = 4) {
uint32_t reg, tmp;
@@ -356,12 +359,12 @@ void intel_panel_enable_backlight(struct drm_device
*dev,
}
set_level:
- /* Call below after setting BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1.
- * BLC_PWM_CPU_CTL may be cleared to zero automatically when these
- * registers are set.
+ /* Check the current backlight level and try to set again if it's zero.
+ * On some machines, BLC_PWM_CPU_CTL is cleared to zero automatically
+ * when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 are written.
*/
- dev_priv-backlight_enabled = true;
- intel_panel_actually_set_backlight(dev, dev_priv-backlight_level);
+ if (!intel_panel_get_backlight(dev))
+ intel_panel_actually_set_backlight(dev,
dev_priv-backlight_level);
}
static void intel_panel_init_backlight(struct drm_device *dev)
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Build: Add --disable-tests configure flag to avoid tests build - v2
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 more tests.
v2: wait for Ben's spacin fixes and adjusted for new space rules.
/spacin/spacing/ ?
Reviewed-by: Takashi Iwai ti...@suse.de
Thanks! We can drop one more patch from SLE package now ;)
Takashi
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
Conflicts:
configure.ac
---
Makefile.am | 6 +-
configure.ac | 11 ++-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 5ea0fd8..0dd615b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -21,12 +21,16 @@
ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS}
-SUBDIRS = lib man tools scripts tests benchmarks demos
+SUBDIRS = lib man tools scripts benchmarks demos
if BUILD_SHADER_DEBUGGER
SUBDIRS += debugger
endif
+if BUILD_TESTS
+SUBDIRS += tests
+endif
+
test:
${MAKE} -C tests test
diff --git a/configure.ac b/configure.ac
index 1c56fa4..e66876c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -122,6 +122,16 @@ AM_CONDITIONAL(BUILD_SHADER_DEBUGGER, [test
x$BUILD_SHADER_DEBUGGER != xno])
XORG_TESTSET_CFLAG([THREAD_CFLAGS], [-pthread], [-mt])
AC_SUBST([THREAD_CFLAGS])
+AC_ARG_ENABLE(tests,
+ AS_HELP_STRING([--disable-tests],
+ [Disable tests build (default: enabled)]),
+ [BUILD_TESTS=$enableval], [BUILD_TESTS=yes])
+if test x$BUILD_TESTS = xyes; then
+ AC_DEFINE(BUILD_TESTS, 1, [Build tests])
+ AC_CONFIG_FILES([tests/Makefile])
+fi
+AM_CONDITIONAL(BUILD_TESTS, [test x$BUILD_TESTS = xyes])
+
AC_CONFIG_FILES([
Makefile
benchmarks/Makefile
@@ -129,7 +139,6 @@ AC_CONFIG_FILES([
lib/Makefile
man/Makefile
scripts/Makefile
- tests/Makefile
tools/Makefile
debugger/Makefile
debugger/system_routine/Makefile
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/22] drm/i915: enable force wake, disable LLC on VLV
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 right, though.
BR,
Jani.
On Sat, 02 Feb 2013, Jesse Barnes jbar...@virtuousgeek.org wrote:
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 13b9b4f..b35b479 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -276,6 +276,8 @@ static const struct intel_device_info
intel_valleyview_m_info = {
.has_bsd_ring = 1,
.has_blt_ring = 1,
.is_valleyview = 1,
+ .has_force_wake = 1,
+ .has_llc = 0,
};
static const struct intel_device_info intel_valleyview_d_info = {
@@ -285,6 +287,8 @@ static const struct intel_device_info
intel_valleyview_d_info = {
.has_bsd_ring = 1,
.has_blt_ring = 1,
.is_valleyview = 1,
+ .has_force_wake = 1,
+ .has_llc = 0,
};
static const struct intel_device_info intel_haswell_d_info = {
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: write backlight harder
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 reopening lid
changed the register write sequence for restoring the backlight, which
helped prevent non-working backlights on some machines. Turns out that
the original sequence was the right thing to do for a different set of
machines. Worse, setting the backlight level _after_ enabling it seems
to reset it somehow. So we need to make that one conditional upon the
backlight having been reset to zero, and add the old one back.
Cargo-culting at it's best, but it seems to work.
Cc: sta...@vger.kernel.org
Cc: Takashi Iwai ti...@suse.de
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_panel.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index bee8cb6..a3730e0 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -321,6 +321,9 @@ void intel_panel_enable_backlight(struct drm_device *dev,
if (dev_priv-backlight_level == 0)
dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
+ dev_priv-backlight_enabled = true;
+ intel_panel_actually_set_backlight(dev, dev_priv-backlight_level);
+
if (INTEL_INFO(dev)-gen = 4) {
uint32_t reg, tmp;
@@ -356,12 +359,12 @@ void intel_panel_enable_backlight(struct drm_device
*dev,
}
set_level:
- /* Call below after setting BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1.
- * BLC_PWM_CPU_CTL may be cleared to zero automatically when these
- * registers are set.
+ /* Check the current backlight level and try to set again if it's zero.
+ * On some machines, BLC_PWM_CPU_CTL is cleared to zero automatically
+ * when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 are written.
*/
- dev_priv-backlight_enabled = true;
- intel_panel_actually_set_backlight(dev, dev_priv-backlight_level);
+ if (!intel_panel_get_backlight(dev))
+ intel_panel_actually_set_backlight(dev,
dev_priv-backlight_level);
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 jani.nik...@intel.com
}
static void intel_panel_init_backlight(struct drm_device *dev)
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: write backlight harder
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 jani.nik...@intel.com Merged to dinq, thanks for the review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Skip modifying PCH DREF if not changing clock sources
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.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
One idea I've been pondering for the refclock stuff is to simply shovel
this into the -modeset_global_resources callback. That way no clever
tricks are required, and we'd avoid this for all cases where fastboot
works complety. Presumably ofc that the bios didn't set up a config which
does not work.
As a bonus, we could only set up the refclocks the new configuration
actually needs, i.e. filter for encoder-crtc != NULL ... A bit a risky
patch, but might uncover some subtle bugs if we do the refclock adjusting
more often.
Too insane?
-Daniel
---
drivers/gpu/drm/i915/intel_display.c | 83
+-
1 file changed, 61 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d75c6a0..f1dbd01 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4749,7 +4749,7 @@ static void ironlake_init_pch_refclk(struct drm_device
*dev)
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_mode_config *mode_config = dev-mode_config;
struct intel_encoder *encoder;
- u32 temp;
+ u32 val, final;
bool has_lvds = false;
bool has_cpu_edp = false;
bool has_pch_edp = false;
@@ -4792,70 +4792,109 @@ static void ironlake_init_pch_refclk(struct
drm_device *dev)
* PCH B stepping, previous chipset stepping should be
* ignoring this setting.
*/
- temp = I915_READ(PCH_DREF_CONTROL);
+ val = I915_READ(PCH_DREF_CONTROL);
+
+ /* As we must carefully and slowly disable/enable each source in turn,
+ * compute the final state we want first and check if we need to
+ * make any changes at all.
+ */
+ final = val;
+ final = ~DREF_NONSPREAD_SOURCE_MASK;
+ if (has_ck505)
+ final |= DREF_NONSPREAD_CK505_ENABLE;
+ else
+ final |= DREF_NONSPREAD_SOURCE_ENABLE;
+
+ final = ~DREF_SSC_SOURCE_MASK;
+ final = ~DREF_CPU_SOURCE_OUTPUT_MASK;
+ final = ~DREF_SSC1_ENABLE;
+
+ if (has_panel) {
+ final |= DREF_SSC_SOURCE_ENABLE;
+
+ if (intel_panel_use_ssc(dev_priv) can_ssc)
+ final |= DREF_SSC1_ENABLE;
+
+ if (has_cpu_edp) {
+ if (intel_panel_use_ssc(dev_priv) can_ssc)
+ final |= DREF_CPU_SOURCE_OUTPUT_DOWNSPREAD;
+ else
+ final |= DREF_CPU_SOURCE_OUTPUT_NONSPREAD;
+ } else
+ final |= DREF_CPU_SOURCE_OUTPUT_DISABLE;
+ } else {
+ final |= DREF_SSC_SOURCE_DISABLE;
+ final |= DREF_CPU_SOURCE_OUTPUT_DISABLE;
+ }
+
+ if (final == val)
+ return;
+
/* Always enable nonspread source */
- temp = ~DREF_NONSPREAD_SOURCE_MASK;
+ val = ~DREF_NONSPREAD_SOURCE_MASK;
if (has_ck505)
- temp |= DREF_NONSPREAD_CK505_ENABLE;
+ val |= DREF_NONSPREAD_CK505_ENABLE;
else
- temp |= DREF_NONSPREAD_SOURCE_ENABLE;
+ val |= DREF_NONSPREAD_SOURCE_ENABLE;
if (has_panel) {
- temp = ~DREF_SSC_SOURCE_MASK;
- temp |= DREF_SSC_SOURCE_ENABLE;
+ val = ~DREF_SSC_SOURCE_MASK;
+ val |= DREF_SSC_SOURCE_ENABLE;
/* SSC must be turned on before enabling the CPU output */
if (intel_panel_use_ssc(dev_priv) can_ssc) {
DRM_DEBUG_KMS(Using SSC on panel\n);
- temp |= DREF_SSC1_ENABLE;
+ val |= DREF_SSC1_ENABLE;
} else
- temp = ~DREF_SSC1_ENABLE;
+ val = ~DREF_SSC1_ENABLE;
/* Get SSC going before enabling the outputs */
- I915_WRITE(PCH_DREF_CONTROL, temp);
+ I915_WRITE(PCH_DREF_CONTROL, val);
POSTING_READ(PCH_DREF_CONTROL);
udelay(200);
- temp = ~DREF_CPU_SOURCE_OUTPUT_MASK;
+ val = ~DREF_CPU_SOURCE_OUTPUT_MASK;
/* Enable CPU source on CPU attached eDP */
if (has_cpu_edp) {
if (intel_panel_use_ssc(dev_priv) can_ssc) {
DRM_DEBUG_KMS(Using SSC on eDP\n);
- temp |= DREF_CPU_SOURCE_OUTPUT_DOWNSPREAD;
+ val |= DREF_CPU_SOURCE_OUTPUT_DOWNSPREAD;
}
else
- temp |=
Re: [Intel-gfx] [PATCH 03/22] drm/i915: add UCGCTL4 to display reg check on VLV
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 Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/i915_drv.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 69d0637..13b9b4f 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1208,6 +1208,7 @@ static bool IS_DISPLAYREG(u32 reg) case GEN7_HALF_SLICE_CHICKEN1: case GEN6_MBCTL: case GEN6_UCGCTL2: + case GEN7_UCGCTL4: return false; default: break; -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/22] drm/i915: add power context allocation and setup on VLV
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 ++
drivers/gpu/drm/i915/i915_gem_stolen.c | 41
drivers/gpu/drm/i915/i915_reg.h|1 +
3 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f4ae73d..34f01a9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -928,6 +928,8 @@ typedef struct drm_i915_private {
struct drm_mm_node *compressed_fb;
struct drm_mm_node *compressed_llb;
+ struct drm_mm_node *vlv_pctx;
+
unsigned long last_gpu_reset;
/* list of fbdev register on this device */
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index f21ae17..ac11a41 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -171,11 +171,49 @@ void i915_gem_stolen_cleanup_compression(struct
drm_device *dev)
dev_priv-cfb_size = 0;
}
+static void i915_setup_pctx(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_mm_node *pctx;
+ unsigned long pctx_paddr;
+ int pctx_size = 24*1024;
+
+ pctx = drm_mm_search_free(dev_priv-mm.stolen, pctx_size, 4096, 0);
+ if (pctx)
+ pctx = drm_mm_get_block(pctx, pctx_size, 4096);
+ if (!pctx)
+ goto err;
+
+ pctx_paddr = dev_priv-mm.stolen_base + pctx-start;
+ if (!pctx_paddr)
+ goto err_free_pctx;
+
+ dev_priv-vlv_pctx = pctx;
+ I915_WRITE(VLV_PCBR, pctx_paddr);
+
+ return;
+
+err_free_pctx:
+ drm_mm_put_block(pctx);
+err:
+ DRM_DEBUG(not enough stolen space for PCTX, disabling\n);
+}
+
+static void i915_cleanup_pctx(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ I915_WRITE(VLV_PCBR, 0);
+ drm_mm_put_block(dev_priv-vlv_pctx);
+}
+
void i915_gem_cleanup_stolen(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
i915_gem_stolen_cleanup_compression(dev);
+ if (IS_VALLEYVIEW(dev) i915_powersave)
+ i915_cleanup_pctx(dev);
At least in theory dev_priv-vlv_pctx could be NULL here. Maybe make
dev_priv-vlv_pctx != NULL the condition here?
BR,
Jani.
drm_mm_takedown(dev_priv-mm.stolen);
}
@@ -193,6 +231,9 @@ int i915_gem_init_stolen(struct drm_device *dev)
/* Basic memrange allocator for stolen space */
drm_mm_init(dev_priv-mm.stolen, 0, dev_priv-mm.gtt-stolen_size);
+ if (IS_VALLEYVIEW(dev) i915_powersave)
+ i915_setup_pctx(dev);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 286bab3..c785750 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -561,6 +561,7 @@
#define ISR 0x020ac
#define VLV_GUNIT_CLOCK_GATE 0x182060
#define GCFG_DIS (18)
+#define VLV_PCBR 0x182120
#define VLV_IIR_RW 0x182084
#define VLV_IER 0x1820a0
#define VLV_IIR 0x1820a4
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/22] drm/i915: add UCGCTL4 to display reg check on VLV
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 in i915_reg.h after IS_DISPLAYREG removal. Strike that. The whole patch can be dropped since it's not a display reg. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/i915_drv.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 69d0637..13b9b4f 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1208,6 +1208,7 @@ static bool IS_DISPLAYREG(u32 reg) case GEN7_HALF_SLICE_CHICKEN1: case GEN6_MBCTL: case GEN6_UCGCTL2: +case GEN7_UCGCTL4: return false; default: break; -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/22] drm/i915: new register for IS_DISPLAYREG
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 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index b35b479..28d5992 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1193,10 +1193,6 @@ static bool IS_DISPLAYREG(u32 reg) reg = VLV_ISR) return false; - if (reg == FORCEWAKE_VLV || - reg == FORCEWAKE_ACK_VLV) - return false; - if (reg == GEN6_GDRST) return false; @@ -1213,6 +1209,9 @@ static bool IS_DISPLAYREG(u32 reg) case GEN6_MBCTL: case GEN6_UCGCTL2: case GEN7_UCGCTL4: + case FORCEWAKE_VLV: + case FORCEWAKE_ACK_VLV: + case VLV_GTLC_WAKE_CTRL: Obviously the IS_DISPLAYREG bits can be dropped now. BR, Jani. return false; default: break; diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index c785750..7e13f34 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4212,6 +4212,7 @@ #define FORCEWAKE_ACK_VLV 0x1300b4 #define FORCEWAKE_ACK_HSW 0x130044 #define FORCEWAKE_ACK 0x130090 +#define VLV_GTLC_WAKE_CTRL 0x130090 #define FORCEWAKE_MT0xa188 /* multi-threaded */ #define FORCEWAKE_KERNEL 0x1 #define FORCEWAKE_USER 0x2 -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/22] drm/i915: don't init LVDS on VLV
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 a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index 8c61876..feef18c 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -1024,6 +1024,9 @@ static bool intel_lvds_supported(struct drm_device *dev) if (HAS_PCH_SPLIT(dev)) return true; + if (IS_VALLEYVIEW(dev)) + return false; + /* Otherwise LVDS was only attached to mobile products, * except for the inglorious 830gm */ return IS_MOBILE(dev) !IS_I830(dev); -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/22] drm/i915: don't init LVDS on VLV
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 selection has happened in, I'm not sure whether we should sprinkle this out like that. In any case, we seem to miss the check for Haswell, too. It probably works out since the lvds present pin doesn't work, either. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ZaphodHeads with intel X driver
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 screens. I also came across this commit. http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=265d94e0aa46b30a3198893544dd3619cc9145de So Looks like the config with ZaphodHeads should work. Is there anything wrong in this config? How can I get it to work? Thanks, Nitin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes
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 noticed that: a) switching between 1080p30 and 1080p50 or 1080p60 is enough to make the sound go away (higher frame rates) or work (1080p30). So, it has nothing to do with interlacing. The only difference between the output of all the intel*dump tools when running 1080p30 and 1080p60 is included below. It's interesting to note that all the modes that don't work have fdi_lanes = 2 while the working ones have fdi_lanes = 1 (port width in intel_reg_dumper-speak). I'm CC:ing the intel-gfx list as well as the ALSA list since I'm not su sure where the problem lies anymore...suggestions? //David difference between intel reg dump: diff -Nur 1080p60/intel_reg_dumper.log 1080p30/intel_reg_dumper.log --- 1080p60/intel_reg_dumper.log2013-02-06 21:50:35.307560443 +0100 +++ 1080p30/intel_reg_dumper.log2013-02-06 21:52:46.579566050 +0100 @@ -20,11 +20,11 @@ VSYNC_A: 0x0440043b (1084 start, 1089 end) VSYNCSHIFT_A: 0x PIPEASRC: 0x077f0437 (1920, 1080) - PIPEA_DATA_M1: 0x7e3661e0 (TU 64, val 0x3661e0 3564000) - PIPEA_DATA_N1: 0x0041eb00 (val 0x41eb00 432) + PIPEA_DATA_M1: 0x7e1b30f0 (TU 64, val 0x1b30f0 1782000) + PIPEA_DATA_N1: 0x0020f580 (val 0x20f580 216) PIPEA_DATA_M2: 0x (TU 1, val 0x0 0) PIPEA_DATA_N2: 0x (val 0x0 0) - PIPEA_LINK_M1: 0x00024414 (val 0x24414 148500) + PIPEA_LINK_M1: 0x0001220a (val 0x1220a 74250) PIPEA_LINK_N1: 0x00041eb0 (val 0x41eb0 27) PIPEA_LINK_M2: 0x (val 0x0 0) PIPEA_LINK_N2: 0x (val 0x0 0) @@ -102,7 +102,7 @@ PCH_SSC4_AUX_PARMS: 0x29c5 PCH_DPLL_SEL: 0x0008 (TransA DPLL enable (DPLL A), TransB DPLL disable (DPLL (null))) PCH_DPLL_ANALOG_CTL: 0x8000 -PCH_DPLL_A: 0xc4020002 (enable, sdvo high speed yes, mode (null), p2 (null), FPA0 P1 2, FPA1 P1 2, refclk default 120Mhz, sdvo/hdmi mul 1) +PCH_DPLL_A: 0xc4080008 (enable, sdvo high speed yes, mode (null), p2 (null), FPA0 P1 4, FPA1 P1 4, refclk default 120Mhz, sdvo/hdmi mul 1) PCH_DPLL_B: 0x04800080 (disable, sdvo high speed no, mode (null), p2 (null), FPA0 P1 8, FPA1 P1 8, refclk default 120Mhz, sdvo/hdmi mul 1) PCH_FPA0: 0x00021007 (n = 2, m1 = 16, m2 = 7) PCH_FPA1: 0x00021007 (n = 2, m1 = 16, m2 = 7) @@ -156,10 +156,10 @@ TRANSACONF: 0xc000 (enable, active, progressive) TRANSBCONF: 0x (disable, inactive, progressive) TRANSCCONF: 0x (disable, inactive, progressive) - FDI_TXA_CTL: 0x800c4b00 (enable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X2, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable) + FDI_TXA_CTL: 0x80044b00 (enable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable) FDI_TXB_CTL: 0x0004 (disable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL disable, scrambing enable, master mode disable) FDI_TXC_CTL: 0x0004 (disable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL disable, scrambing enable, master mode disable) - FDI_RXA_CTL: 0x8c082b50 (enable, train pattern not train, port width X2, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc enable, FE ecc disable, FS err report enable, FE err report enable,scrambing enable, enhanced framing enable, PCDClk) + FDI_RXA_CTL: 0x8c002b50 (enable, train pattern not train, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc enable, FE ecc disable, FS err report enable, FE err report enable,scrambing enable, enhanced framing enable, PCDClk) FDI_RXB_CTL: 0x0040 (disable, train pattern pattern_1, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL disable,FS ecc disable, FE ecc disable, FS err report disable, FE err report disable,scrambing enable, enhanced framing enable, RawClk) FDI_RXC_CTL: 0x0040 (disable, train pattern pattern_1, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL disable,FS ecc disable, FE ecc
Re: [Intel-gfx] ZaphodHeads with intel X driver
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/ Dual_Monitors#Single_graphics_card.2C_Multiple_X_screens_with_ZaphodHeads And X is failing to start complaining about no usable screens. I also came across this commit. http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/ ?id=265d94e0aa46b30a3198893544dd3619cc9145de So Looks like the config with ZaphodHeads should work. Is there anything wrong in this config? How can I get it to work? That's quite difficult to tell since you did not attach the xorg.conf you experimented with, or the resultant Xorg.log. Quite probably you simply missed the Option AccelMethod SNA, but since you got an error message about no screens detected, the error is actually likely to be something else. -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
Re: [Intel-gfx] ZaphodHeads with intel X driver
-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, 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/ Dual_Monitors#Single_graphics_card.2C_Multiple_X_screens_with_Zaphod He ads And X is failing to start complaining about no usable screens. I also came across this commit. http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/ ?id=265d94e0aa46b30a3198893544dd3619cc9145de So Looks like the config with ZaphodHeads should work. Is there anything wrong in this config? How can I get it to work? That's quite difficult to tell since you did not attach the xorg.conf you experimented with, or the resultant Xorg.log. Quite probably you simply missed the Option AccelMethod SNA, but since you got an error message about no screens detected, the error is actually likely to be something else. -Chris -- Chris Wilson, Intel Open Source Technology Centre Thanks Chris for the reply. Attached are all the relevant log files. Nitin lspci Description: lspci sys Description: sys Xorg.0.log Description: Xorg.0.log xorg.conf Description: xorg.conf ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ZaphodHeads with intel X driver
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 Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ZaphodHeads with intel X driver
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 OptionDPMS true OptionPrefferedMode 1920x1080 EndSection Section Screen IdentifierScreen0 DeviceIntel0 Monitor HDMI1 DefaultDepth 24 EndSection Section ServerLayout Identifier Default Layout Screen Screen0 0 0 EndSection Section ServerFlags OptionDontZap 0 OptionAutoAddDevices False EndSection The x log is: [3054115.081] (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43, B43, Clarkdale, Arrandale, Sandybridge Desktop (GT1), Sandybridge Desktop (GT2), Sandybridge Desktop (GT2+), Sandybridge Mobile (GT1), Sandybridge Mobile (GT2), Sandybridge Mobile (GT2+), Sandybridge Server, Ivybridge Mobile (GT1), Ivybridge Mobile (GT2), Ivybridge Desktop (GT1), Ivybridge Desktop (GT2), Ivybridge Server, Ivybridge Server (GT2), Haswell Desktop (GT1), Haswell Desktop (GT2), Haswell Desktop (GT2+), Haswell Mobile (GT1), Haswell Mobile (GT2), Haswell Mobile (GT2+), Haswell Server (GT1), Haswell Server (GT2), Haswell Server (GT2+), Haswell SDV Desktop (GT1), Haswell SDV Desktop (GT2), Haswell SDV Desktop (GT2+), Haswell SDV Mobile (GT1), Haswell SDV Mobile (GT2), Haswell SDV Mobile (GT2+), Haswell SDV Server (GT1), Haswell SDV Server (GT2), Haswell SDV Server (GT2+), Haswell ULT Desktop (GT1), Haswell ULT Desktop (GT2), Haswell ULT Desktop (GT2+), Haswell ULT Mobile (GT1), Haswell ULT Mobile (GT2), Haswell ULT Mobile (GT2+), Haswell ULT Server (GT1), Haswell ULT Server (GT2), Haswell ULT Server (GT2+), Haswell CRW Desktop (GT1), Haswell CRW Desktop (GT2), Haswell CRW Desktop (GT2+), Haswell CRW Mobile (GT1), Haswell CRW Mobile (GT2), Haswell CRW Mobile (GT2+), Haswell CRW Server (GT1), Haswell CRW Server (GT2), Haswell CRW Server (GT2+), ValleyView PO board [3054115.081] (--) using VT number 3 [3054115.088] (EE) Screen 0 deleted because of no matching config section. [3054115.088] (II) UnloadModule: intel [3054115.088] (II) UnloadModule: intel [3054115.088] (EE) Screen(s) found, but none have a usable configuration. [3054115.088] Fatal server error: [3054115.088] no screens found [3054115.088] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [3054115.088] (EE) Please also check the log file at /var/log/Xorg.0.log for additional information. [3054115.088] (EE) [3054115.111] Server terminated with error (1). Closing log file. Let me know if you need any more information. Thanks, Nitin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ZaphodHeads with intel X driver
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 match the name given by xrandr, which would appear to be HDMI1. Getting closer... -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
Re: [Intel-gfx] ZaphodHeads with intel X driver
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 config. But now the issue is I am seeing the screen getting duplicated on the 2 monitors. The following config should create 2 separate screens. Section ServerLayout Identifier Default Layout Screen Screen0 0 0 Screen Screen1 LeftOf Screen0 EndSection Thanks, Nitin Xorg.0.log Description: Xorg.0.log xorg.conf Description: xorg.conf ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ZaphodHeads with intel X driver
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 already in use! [3056612.622] (EE) Screen 1 deleted because of no matching config section. [3056612.622] (EE) [3056612.622] (EE) Backtrace: [3056612.623] (EE) 0: /usr/bin/Xorg (xorg_backtrace+0x36) [0x5726f6] [3056612.623] (EE) 1: /usr/bin/Xorg (0x40+0x1761c9) [0x5761c9] [3056612.623] (EE) 2: /lib/libpthread.so.0 (0x7f893e206000+0xfb20) [0x7f893e215b20] [3056612.623] (EE) 3: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f893bcf4000+0xed20) [0x7f893bd02d20] [3056612.623] (EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f893bcf4000+0xff85) [0x7f893bd03f85] [3056612.623] (EE) 5: /usr/bin/Xorg (xf86DeleteScreen+0x84) [0x47dd04] [3056612.623] (EE) 6: /usr/bin/Xorg (xf86BusConfig+0x216) [0x469336] [3056612.623] (EE) 7: /usr/bin/Xorg (InitOutput+0x956) [0x476e96] [3056612.623] (EE) 8: /usr/bin/Xorg (0x40+0x25b26) [0x425b26] [3056612.623] (EE) 9: /lib/libc.so.6 (__libc_start_main+0xf5) [0x7f893d09a755] [3056612.623] (EE) 10: /usr/bin/Xorg (0x40+0x26001) [0x426001] [3056612.624] (EE) [3056612.624] (EE) Segmentation fault at address 0x0 [3056612.624] Fatal server error: [3056612.624] Caught signal 11 (Segmentation fault). Server aborting [3056612.624] [3056612.624] (EE) Thanks, Nitin -Original Message- From: Kamble, Nitin A Sent: Wednesday, February 06, 2013 4:07 PM To: 'ch...@chris-wilson.co.uk' Cc: intel-gfx@lists.freedesktop.org Subject: RE: ZaphodHeads with intel X driver 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 config. But now the issue is I am seeing the screen getting duplicated on the 2 monitors. The following config should create 2 separate screens. Section ServerLayout Identifier Default Layout Screen Screen0 0 0 Screen Screen1 LeftOf Screen0 EndSection Thanks, Nitin xorg.conf.working Description: xorg.conf.working ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] drm/i915: Introduce i915_gem_object_create_stolen_for_preallocated
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 +++
drivers/gpu/drm/i915/i915_gem_stolen.c | 65
2 files changed, 70 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 08c5def..fd8a495 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1720,6 +1720,11 @@ void i915_gem_stolen_cleanup_compression(struct
drm_device *dev);
void i915_gem_cleanup_stolen(struct drm_device *dev);
struct drm_i915_gem_object *
i915_gem_object_create_stolen(struct drm_device *dev, u32 size);
+struct drm_i915_gem_object *
+i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
+u32 stolen_offset,
+u32 gtt_offset,
+u32 size);
Can we default to u64 for things from now on. Not that I know anything,
or anything. At least gtt_offset.
void i915_gem_object_release_stolen(struct drm_i915_gem_object *obj);
/* i915_gem_tiling.c */
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 69d97cb..130d1db 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -312,6 +312,71 @@ i915_gem_object_create_stolen(struct drm_device *dev,
u32 size)
return NULL;
}
+struct drm_i915_gem_object *
+i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
+u32 stolen_offset,
+u32 gtt_offset,
+u32 size)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_i915_gem_object *obj;
+ struct drm_mm_node *stolen;
+
+ if (dev_priv-mm.stolen_base == 0)
+ return NULL;
+
+ DRM_DEBUG_KMS(creating preallocated stolen object: stolen_offset=%x,
gtt_offset=%x, size=%x\n,
+ stolen_offset, gtt_offset, size);
+
+ /* KISS and expect everything to be page-aligned */
+ BUG_ON(stolen_offset 4095);
+ BUG_ON(gtt_offset 4095);
+ BUG_ON(size 4095);
+
+ if (WARN_ON(size == 0))
+ return NULL;
+
+ stolen = drm_mm_create_block(dev_priv-mm.stolen,
+ stolen_offset, size,
+ false);
+ if (stolen == NULL) {
+ DRM_DEBUG_KMS(failed to allocate stolen space\n);
+ return NULL;
+ }
+
+ obj = _i915_gem_object_create_stolen(dev, stolen);
+ if (obj == NULL) {
+ DRM_DEBUG_KMS(failed to allocate stolen object\n);
+ drm_mm_put_block(stolen);
+ return NULL;
+ }
+
+ /* To simplify the initialisation sequence between KMS and GTT,
+ * we allow construction of the stolen object prior to
+ * setting up the GTT space. The actual reservation will occur
+ * later.
+ */
+ if (drm_mm_initialized(dev_priv-mm.gtt_space)) {
+ obj-gtt_space = drm_mm_create_block(dev_priv-mm.gtt_space,
+ gtt_offset, size,
+ false);
+ if (obj-gtt_space == NULL) {
+ DRM_DEBUG_KMS(failed to allocate stolen GTT space\n);
+ drm_gem_object_unreference(obj-base);
+ return NULL;
+ }
+ } else
+ obj-gtt_space = I915_GTT_RESERVED;
Could you explain how/why we'd do this before the mm is initialized.
+
+ obj-gtt_offset = gtt_offset;
+ obj-has_global_gtt_mapping = 1;
+
+ list_add_tail(obj-gtt_list, dev_priv-mm.bound_list);
+ list_add_tail(obj-mm_list, dev_priv-mm.inactive_list);
+
+ return obj;
+}
+
void
i915_gem_object_release_stolen(struct drm_i915_gem_object *obj)
{
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
