[Intel-gfx] [PATCH] drm/i915: enable semaphores on gen6 if dmar is not active

[Daniel Vetter]

On Mon, Apr 02, 2012 at 01:45:39PM -0700, Andrew Lutomirski wrote:
> On Mon, Apr 2, 2012 at 11:48 AM, Daniel Vetter  
> wrote:
> > Inspired by the recent ppgtt regression report, where switching of
> > dmar only for the gpu seems to fix things completely, I've looked
> > again at the semaphores+vt-d situation.
> >
> > Contrary to my earlier testing a few months back my system is now
> > stable with dmar disabled for the igd, and not only when disabling
> > dmar completely.
> >
> > So I'm rather hopeful that all our recent fixes for snb have changed
> > things for code and it's time to try enabling semaphores again. We've
> > also had issues with enabling semaphores which are not vt-d related,
> > but I guess these are all fixed by the autoreport-disabling and lazy
> > request fix. And there's only one way to find out whether there are
> > still other issues ...
> >
> > Signed-Off-by: Daniel Vetter 
> >
> > ---
> >
> > If no further vt-d regressions show up in the 3.4 cycle I plan to
> > merge this into -next for 3.5 (in a month or so). Comments about how
> > unfeasibly you deem this highly welcome.
> > -Daniel
> > ---
> > ?drivers/gpu/drm/i915/i915_gem_execbuffer.c | ? ?8 +---
> > ?1 files changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 8e0b686..ac52433 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -849,9 +849,11 @@ intel_enable_semaphores(struct drm_device *dev)
> > ? ? ? ?if (i915_semaphores >= 0)
> > ? ? ? ? ? ? ? ?return i915_semaphores;
> >
> > - ? ? ? /* Disable semaphores on SNB */
> > - ? ? ? if (INTEL_INFO(dev)->gen == 6)
> > - ? ? ? ? ? ? ? return 0;
> > +#ifdef CONFIG_INTEL_IOMMU
> > + ? ? ? /* Disable semaphores on SNB if VT-d is on. */
> > + ? ? ? if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped)
> > + ? ? ? ? ? ? ? return false;
> 
> It might be nice to have a printk here giving instructions for how to work
> around this.  For example:
> 
> i915: Disabling semaphores to work around a DMAR issue.  As an
> alternative, boot with intel_iommu=igfx_off [or on, igfx_off, or
> whatever it's supposed to be].
> 
> The documentation in kernel-parameters.txt is at best unclear to the
> uninitiated.

If this really does work, I'll look into this. Atm it's still unclear
where to exactly put the plain, we need to annoy internal hardware people
to analyze this. Once we have enough evidence that the combination of gpu
with various features enable plus VT-d just doesn't seem to work reliably.

So can you check whether things do indeed work with this patch, atop
kernel 3.4-rc1? Iirc you've been the one with the most trouble when
semaphores are enabled ...

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 48131] Very large 2D texture is sometimes corrupted

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48131

Alex Deucher  changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Drivers/Gallium/r600

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 48131] Very large 2D texture is sometimes corrupted

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48131

Sven Arvidsson  changed:

   What|Removed |Added

 CC||sa at whiz.se

--- Comment #5 from Sven Arvidsson  2012-04-02 15:32:53 PDT ---
FWIW, for me the test segfaults with 8.0 but works (without artefacts AFAICT)
with 8.0.2. This is on a HD 5670.

(I suppose the component of the bug should be moved to Drivers/Gallium/r600 ?)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH RFC] drm: support for rotated scanout

[Ville Syrjälä]

On Mon, Apr 02, 2012 at 08:26:14PM +0300, Ville Syrj?l? wrote:
> On Mon, Apr 02, 2012 at 10:31:47AM -0500, Rob Clark wrote:
> > On Sat, Mar 31, 2012 at 4:09 PM, Ville Syrj?l?  wrote:
> > > On Fri, Mar 30, 2012 at 05:59:32PM -0500, Rob Clark wrote:
> > >> From: Rob Clark 
> > >>
> > >> For drivers that can support rotated scanout, the extra parameter
> > >> checking in drm-core, while nice, tends to get confused. ?To solve
> > >> this drivers can set the crtc or plane invert_dimensions field so
> > >> that the dimension checking takes into account the rotation that
> > >> the driver is performing.
> > >> ---
> > >> Note: RFC still mainly because I've only tested the CRTC rotation so
> > >> far.. still need to write some test code for plane rotation.
> > >>
> > >> ?drivers/gpu/drm/drm_crtc.c | ? 50 
> > >> +--
> > >> ?include/drm/drm_crtc.h ? ? | ? ?9 
> > >> ?2 files changed, 43 insertions(+), 16 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > >> index 0dff444..261c9bd 100644
> > >> --- a/drivers/gpu/drm/drm_crtc.c
> > >> +++ b/drivers/gpu/drm/drm_crtc.c
> > >> @@ -375,6 +375,7 @@ int drm_crtc_init(struct drm_device *dev, struct 
> > >> drm_crtc *crtc,
> > >>
> > >> ? ? ? crtc->dev = dev;
> > >> ? ? ? crtc->funcs = funcs;
> > >> + ? ? crtc->invert_dimensions = false;
> > >>
> > >> ? ? ? mutex_lock(>mode_config.mutex);
> > >>
> > >> @@ -609,6 +610,7 @@ int drm_plane_init(struct drm_device *dev, struct 
> > >> drm_plane *plane,
> > >> ? ? ? plane->base.properties = >properties;
> > >> ? ? ? plane->dev = dev;
> > >> ? ? ? plane->funcs = funcs;
> > >> + ? ? plane->invert_dimensions = false;
> > >> ? ? ? plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
> > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? GFP_KERNEL);
> > >> ? ? ? if (!plane->format_types) {
> > >> @@ -1758,6 +1760,9 @@ int drm_mode_setplane(struct drm_device *dev, void 
> > >> *data,
> > >> ? ? ? fb_width = fb->width << 16;
> > >> ? ? ? fb_height = fb->height << 16;
> > >>
> > >> + ? ? if (plane->invert_dimensions)
> > >> + ? ? ? ? ? ? swap(fb_width, fb_height);
> > >> +
> > >
> > > In my opinion the only sane way to specify this stuff is that
> > > the source coordinates are not transformed in any way.
> > 
> > fwiw, it might be a bit odd that in one case I swapped fb dimensions,
> > and in the other crtc dimensions..  although it was just laziness
> > (there were fewer param's to swap that way ;-))
> 
> Not sure if you got my point, which was that w/ plane rotation the
> src coordinate check should be correct as is. Instead you should
> apply the rotation when you clip/process the plane's crtc coordinates.
> 
> Since we don't clip the crtc coordinates in the common code (to allow
> partially/fully offscreen planes), all the work ends up happening in
> driver specific code.

What I write doesn't actually match what I meant to write. I didn't
mean that you'd rotate the crtc coordinates prior to clipping.
What I meant is that you (probably) rotate the src coordinates in
the driver in order to do clipping and scaling factor calculations.

But in any case the bounds checking in the core code is OK, as the
src coordinates are specified in the orienation of the fb memory
layout.

-- 
Ville Syrj?l?
Intel OTC

[Bug 48215] New: [NV11] Display constantly switches on and off roughly every 10 seconds.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48215

 Bug #: 48215
   Summary: [NV11] Display constantly switches on and off roughly
every 10 seconds.
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: x86 (IA32)
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/other
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: alex.buell at munted.org.uk


Display constantly switches on and off roughly every 10 seconds on my NV11
machine. This started happening with 3.2.0. 

Checking backwards, 3.1.0 works just fine. I am currently trying a bisect to
find the problem.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 48131] Very large 2D texture is sometimes corrupted

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48131

--- Comment #4 from Robert Hooker (Sarvatt)  2012-04-02 
14:35:38 PDT ---
The safest way would be to just try a 12.04 beta 2 or newer livecd out, it has
8.0.2

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

2.6.35-rc4 Graphics performance issue and freeing invalid memtype messages on boot.

[Andreas Mohr]

Hi,

how's that for a hijacked thread?
- timing completely bollocks... (2010)
- author completely... err, something else :)
- versioning now in a completely different league

For the dazed and confused among you, rescue is to be found... here:
https://lkml.org/lkml/2010/7/6/108 (original parent)

OP said in the last reply that a PAT rb tree patch fixed it,
but - for me it persists.

> hrmpf, one of those wonderful messages where neither it nor its source
> code give you any clue regarding what caused it nor how to fix it.
> 
> please, apply this:
> 
> --- a/arch/x86/mm/pat.c~a
> +++ a/arch/x86/mm/pat.c
> @@ -359,7 +359,7 @@ int free_memtype(u64 start, u64 end)
>   entry = rbt_memtype_erase(start, end);
>   spin_unlock(_lock);
>  
> - if (!entry) {
> + if (WARN_ON(!entry)) {
>   printk(KERN_INFO "%s:%d freeing invalid memtype %Lx-%Lx\n",
>   current->comm, current->pid, start, end);
>   return -EINVAL;
> 
> and let's at least see where it's coming from.

Applied that patch since I (_still_) keep having it
on 3.3.0something, on my Athlon XP something Debian testing,
Radeon RV250 something (does that trigger a bell!?).

Happens on kdm stop (i.e., xorg shutdown).


pat_memtype_list_w_xorg.log:

PAT memtype list:
write-back @ 0x1fff-0x1fff1000
write-back @ 0x1fff3000-0x1fff8000
uncached-minus @ 0xc000-0xc0101000
uncached-minus @ 0xc000-0xc0101000
uncached-minus @ 0xc0101000-0xc0102000
uncached-minus @ 0xc0101000-0xc0102000
uncached-minus @ 0xc0101000-0xc0102000
uncached-minus @ 0xc0102000-0xc0302000
uncached-minus @ 0xc0102000-0xc0302000
uncached-minus @ 0xc0102000-0xc0302000
uncached-minus @ 0xc0102000-0xc0302000
uncached-minus @ 0xc0302000-0xc07e2000
uncached-minus @ 0xc0302000-0xc07e2000
write-combining @ 0xd000-0xd400
write-combining @ 0xd000-0xd400
uncached-minus @ 0xd900-0xd901
uncached-minus @ 0xd900-0xd901
uncached-minus @ 0xd900-0xd901
uncached-minus @ 0xd900-0xd901


pat_memtype_list_wo_xorg.log:

PAT memtype list:
write-back @ 0x1fff-0x1fff1000
write-back @ 0x1fff3000-0x1fff8000
uncached-minus @ 0xc0102000-0xc0302000
uncached-minus @ 0xc0102000-0xc0302000
uncached-minus @ 0xd900-0xd901


mtrr_w_xorg.log:

reg00: base=0x0 (0MB), size=  512MB, count=1: write-back
reg01: base=0x0c000 ( 3072MB), size=  256MB, count=2: write-combining
reg02: base=0x0c000 ( 3072MB), size=  256MB, count=1: write-combining
reg03: base=0x0d000 ( 3328MB), size=   64MB, count=1: write-combining


mtrr_wo_xorg.log:

reg00: base=0x0 (0MB), size=  512MB, count=1: write-back
reg01: base=0x0c000 ( 3072MB), size=  256MB, count=2: write-combining
reg02: base=0x0c000 ( 3072MB), size=  256MB, count=1: write-combining



dmesg:


[ cut here ]
WARNING: at arch/x86/mm/pat.c:362 free_memtype+0x166/0x1b0()
Hardware name: VT8367-8235
Modules linked in:
Pid: 2088, comm: Xorg Not tainted 3.3.0-08839-gb5174fa-dirty #58
Call Trace:
 [] ? printk+0x18/0x1a
 [] warn_slowpath_common+0x6d/0xa0
 [] ? free_memtype+0x166/0x1b0
 [] ? free_memtype+0x166/0x1b0
 [] warn_slowpath_null+0x1d/0x20
 [] free_memtype+0x166/0x1b0
 [] ? page_is_ram+0x19/0x40
 [] ? release_resource+0x80/0x80
 [] ? pat_pagerange_is_ram+0x42/0x70
 [] untrack_pfn_vma+0x56/0x60
 [] unmap_single_vma+0x322/0x390
 [] ? prio_tree_insert+0xf9/0x1e0
 [] unmap_vmas+0x4d/0x60
 [] unmap_region+0x6c/0xd0
 [] ? __split_vma+0xd1/0x170
 [] do_munmap+0x20c/0x290
 [] sys_munmap+0x3a/0x60
 [] sysenter_do_call+0x12/0x26
---[ end trace 6b5ec98d9867b183 ]---
Xorg:2088 freeing invalid memtype c0102000-c0112000
[ cut here ]
WARNING: at arch/x86/mm/pat.c:362 free_memtype+0x166/0x1b0()
Hardware name: VT8367-8235
Modules linked in:
Pid: 2088, comm: Xorg Tainted: GW3.3.0-08839-gb5174fa-dirty #58
Call Trace:
 [] ? printk+0x18/0x1a
 [] warn_slowpath_common+0x6d/0xa0
 [] ? free_memtype+0x166/0x1b0
 [] ? free_memtype+0x166/0x1b0
 [] warn_slowpath_null+0x1d/0x20
 [] free_memtype+0x166/0x1b0
 [] ? page_is_ram+0x19/0x40
 [] ? release_resource+0x80/0x80
 [] ? pat_pagerange_is_ram+0x42/0x70
 [] untrack_pfn_vma+0x56/0x60
 [] unmap_single_vma+0x322/0x390
 [] ? prio_tree_insert+0xf9/0x1e0
 [] unmap_vmas+0x4d/0x60
 [] unmap_region+0x6c/0xd0
 [] ? __split_vma+0xd1/0x170
 [] do_munmap+0x20c/0x290
 [] sys_munmap+0x3a/0x60
 [] sysenter_do_call+0x12/0x26
---[ end trace 6b5ec98d9867b184 ]---
Xorg:2088 freeing invalid memtype c0112000-c0122000
[ cut here ]
WARNING: at arch/x86/mm/pat.c:362 free_memtype+0x166/0x1b0()
Hardware name: VT8367-8235
Modules linked in:
Pid: 2088, comm: Xorg Tainted: GW3.3.0-08839-gb5174fa-dirty #58
Call Trace:
 [] ? printk+0x18/0x1a
 [] warn_slowpath_common+0x6d/0xa0
 [] ? free_memtype+0x166/0x1b0
 [] ? free_memtype+0x166/0x1b0
 [] warn_slowpath_null+0x1d/0x20
 [] free_memtype+0x166/0x1b0
 [] ? page_is_ram+0x19/0x40
 [] ? 

[PATCH libdrm] exynos: add exynos drm support

[Inki Dae]

this patch adds libdrm_exynos helper layer that inclues some intefaces
for exynos specific gem and virtual display driver and also adds exynos
module name to modtest and vbltest.

this patch is based on a link below:
git://anongit.freedesktop.org/mesa/drm
commit id: e057a56448e2e785f74bc13dbd6ead8572ebed91

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 Makefile.am|6 +-
 configure.ac   |   13 ++
 exynos/Makefile.am |   22 +++
 exynos/exynos_drm.c|  324 
 exynos/exynos_drm.h|  127 +
 exynos/exynos_drmif.h  |   60 
 exynos/libdrm_exynos.pc.in |   11 ++
 tests/modetest/modetest.c  |2 +-
 tests/vbltest/vbltest.c|2 +-
 9 files changed, 564 insertions(+), 3 deletions(-)
 create mode 100644 exynos/Makefile.am
 create mode 100644 exynos/exynos_drm.c
 create mode 100644 exynos/exynos_drm.h
 create mode 100644 exynos/exynos_drmif.h
 create mode 100644 exynos/libdrm_exynos.pc.in

diff --git a/Makefile.am b/Makefile.am
index 4f625a1..256a8cc 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -45,7 +45,11 @@ if HAVE_OMAP
 OMAP_SUBDIR = omap
 endif

-SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) tests include
+if HAVE_EXYNOS
+EXYNOS_SUBDIR = exynos
+endif
+
+SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) tests include

 libdrm_la_LTLIBRARIES = libdrm.la
 libdrm_ladir = $(libdir)
diff --git a/configure.ac b/configure.ac
index 1ba7eba..ae84817 100644
--- a/configure.ac
+++ b/configure.ac
@@ -88,6 +88,11 @@ AC_ARG_ENABLE(omap-experimental-api,
  [Enable support for OMAP's experimental API (default: disabled)]),
  [OMAP=$enableval], [OMAP=no])

+AC_ARG_ENABLE(exynos-experimental-api,
+ AS_HELP_STRING([--enable-exynos-experimental-api],
+ [Enable support for EXYNOS's experimental API (default: 
disabled)]),
+ [EXYNOS=$enableval], [EXYNOS=no])
+
 dnl ===
 dnl check compiler flags
 AC_DEFUN([LIBDRM_CC_TRY_FLAG], [
@@ -191,6 +196,11 @@ if test "x$OMAP" = xyes; then
AC_DEFINE(HAVE_OMAP, 1, [Have OMAP support])
 fi

+AM_CONDITIONAL(HAVE_EXYNOS, [test "x$EXYNOS" = xyes])
+if test "x$EXYNOS" = xyes; then
+   AC_DEFINE(HAVE_EXYNOS, 1, [Have EXYNOS support])
+fi
+
 PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
 if test "x$HAVE_CAIRO" = xyes; then
AC_DEFINE(HAVE_CAIRO, 1, [Have cairo support])
@@ -302,6 +312,8 @@ AC_CONFIG_FILES([
nouveau/libdrm_nouveau.pc
omap/Makefile
omap/libdrm_omap.pc
+   exynos/Makefile
+   exynos/libdrm_exynos.pc
tests/Makefile
tests/modeprint/Makefile
tests/modetest/Makefile
@@ -322,4 +334,5 @@ echo "  vmwgfx API $VMWGFX"
 echo "  Radeon API $RADEON"
 echo "  Nouveau API$NOUVEAU"
 echo "  OMAP API   $OMAP"
+echo "  EXYNOS API $EXYNOS"
 echo ""
diff --git a/exynos/Makefile.am b/exynos/Makefile.am
new file mode 100644
index 000..e782d34
--- /dev/null
+++ b/exynos/Makefile.am
@@ -0,0 +1,22 @@
+AM_CFLAGS = \
+   $(WARN_CFLAGS) \
+   -I$(top_srcdir) \
+   -I$(top_srcdir)/exynos \
+   $(PTHREADSTUBS_CFLAGS) \
+   -I$(top_srcdir)/include/drm
+
+libdrm_exynos_la_LTLIBRARIES = libdrm_exynos.la
+libdrm_exynos_ladir = $(libdir)
+libdrm_exynos_la_LDFLAGS = -version-number 1:0:0 -no-undefined
+libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
+
+libdrm_exynos_la_SOURCES = exynos_drm.c
+
+libdrm_exynoscommonincludedir = ${includedir}/exynos
+libdrm_exynoscommoninclude_HEADERS = exynos_drm.h
+
+libdrm_exynosincludedir = ${includedir}/libdrm
+libdrm_exynosinclude_HEADERS = exynos_drmif.h
+
+pkgconfigdir = @pkgconfigdir@
+pkgconfig_DATA = libdrm_exynos.pc
diff --git a/exynos/exynos_drm.c b/exynos/exynos_drm.c
new file mode 100644
index 000..778321a
--- /dev/null
+++ b/exynos/exynos_drm.c
@@ -0,0 +1,324 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co., Ltd.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR 

[3.4-rc1][Regression][intel] Resume from suspend to disk hangs on restoring backlight state

[Daniel Vetter]

On Mon, Apr 02, 2012 at 09:00:11PM +0200, Maciej Rutecki wrote:
> On poniedzia?ek, 2 kwietnia 2012 o 19:54:02 Daniel Vetter wrote:
> > On Mon, Apr 02, 2012 at 07:39:39PM +0200, Maciej Rutecki wrote:
> > > Last known good: 3.3
> > > Bad kernel: 3.4-rc1
> > > Subsystem: power management/suspend/dri(intel)
> > > 
> > > When I resume from suspend to disk then system hangs on this screen:
> > > http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/DSC_5479.jpg
> > > 
> > > It does not help SysRq keys. Only I can force power off by hold power
> > > button.
> > > 
> > > Dmesg:
> > > http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/dmesg-3.4-rc1.t
> > > xt
> > > 
> > > Config:
> > > http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/config-3.4.0-rc
> > > 1
> > 
> > Likely a known regression, ppgtt support broke hibernate because my code
> > doesn't restore the ppgtt page directory correctly in the thaw function.
> > 
> > Patch:
> > http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes=
> > 55a254ac63a3ac1867d1501030e7fba69c7d4aeb
> > 
> > Please test whether this fixes your issue. You can also try adding
> > i915.i915_enable_ppgtt=0 to your kernel cmdline.
> > 
> > Thanks, Daniel
> 
> Patch solves problem.
> 
> Now resume hangs later on another subsystem: wireless :D

Woot, I'm off the hook ;-) Thanks for reporting this issue and testing the
patch.

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[3.4-rc1][Regression][intel] Resume from suspend to disk hangs on restoring backlight state

[Maciej Rutecki]

On poniedzia?ek, 2 kwietnia 2012 o 19:54:02 Daniel Vetter wrote:
> On Mon, Apr 02, 2012 at 07:39:39PM +0200, Maciej Rutecki wrote:
> > Last known good: 3.3
> > Bad kernel: 3.4-rc1
> > Subsystem: power management/suspend/dri(intel)
> > 
> > When I resume from suspend to disk then system hangs on this screen:
> > http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/DSC_5479.jpg
> > 
> > It does not help SysRq keys. Only I can force power off by hold power
> > button.
> > 
> > Dmesg:
> > http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/dmesg-3.4-rc1.t
> > xt
> > 
> > Config:
> > http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/config-3.4.0-rc
> > 1
> 
> Likely a known regression, ppgtt support broke hibernate because my code
> doesn't restore the ppgtt page directory correctly in the thaw function.
> 
> Patch:
> http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes=
> 55a254ac63a3ac1867d1501030e7fba69c7d4aeb
> 
> Please test whether this fixes your issue. You can also try adding
> i915.i915_enable_ppgtt=0 to your kernel cmdline.
> 
> Thanks, Daniel

Patch solves problem.

Now resume hangs later on another subsystem: wireless :D

Regards
-- 
Maciej Rutecki
http://www.mrutecki.pl

[PATCH] drm/i915: enable semaphores on gen6 if dmar is not active

[Daniel Vetter]

Inspired by the recent ppgtt regression report, where switching of
dmar only for the gpu seems to fix things completely, I've looked
again at the semaphores+vt-d situation.

Contrary to my earlier testing a few months back my system is now
stable with dmar disabled for the igd, and not only when disabling
dmar completely.

So I'm rather hopeful that all our recent fixes for snb have changed
things for code and it's time to try enabling semaphores again. We've
also had issues with enabling semaphores which are not vt-d related,
but I guess these are all fixed by the autoreport-disabling and lazy
request fix. And there's only one way to find out whether there are
still other issues ...

Signed-Off-by: Daniel Vetter 

---

If no further vt-d regressions show up in the 3.4 cycle I plan to
merge this into -next for 3.5 (in a month or so). Comments about how
unfeasibly you deem this highly welcome.
-Daniel
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8e0b686..ac52433 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -849,9 +849,11 @@ intel_enable_semaphores(struct drm_device *dev)
if (i915_semaphores >= 0)
return i915_semaphores;

-   /* Disable semaphores on SNB */
-   if (INTEL_INFO(dev)->gen == 6)
-   return 0;
+#ifdef CONFIG_INTEL_IOMMU
+   /* Disable semaphores on SNB if VT-d is on. */
+   if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped)
+   return false;
+#endif

return 1;
 }
-- 
1.7.7.6

[Bug 48131] Very large 2D texture is sometimes corrupted

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48131

--- Comment #3 from Benoit Jacob  2012-04-02 13:40:51 
PDT ---
Maybe, if there is a package for Ubuntu 11.10 that is safe and easy to install?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH RFC] drm: support for rotated scanout

[Ville Syrjälä]

On Mon, Apr 02, 2012 at 10:31:47AM -0500, Rob Clark wrote:
> On Sat, Mar 31, 2012 at 4:09 PM, Ville Syrj?l?  wrote:
> > On Fri, Mar 30, 2012 at 05:59:32PM -0500, Rob Clark wrote:
> >> From: Rob Clark 
> >>
> >> For drivers that can support rotated scanout, the extra parameter
> >> checking in drm-core, while nice, tends to get confused. ?To solve
> >> this drivers can set the crtc or plane invert_dimensions field so
> >> that the dimension checking takes into account the rotation that
> >> the driver is performing.
> >> ---
> >> Note: RFC still mainly because I've only tested the CRTC rotation so
> >> far.. still need to write some test code for plane rotation.
> >>
> >> ?drivers/gpu/drm/drm_crtc.c | ? 50 
> >> +--
> >> ?include/drm/drm_crtc.h ? ? | ? ?9 
> >> ?2 files changed, 43 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >> index 0dff444..261c9bd 100644
> >> --- a/drivers/gpu/drm/drm_crtc.c
> >> +++ b/drivers/gpu/drm/drm_crtc.c
> >> @@ -375,6 +375,7 @@ int drm_crtc_init(struct drm_device *dev, struct 
> >> drm_crtc *crtc,
> >>
> >> ? ? ? crtc->dev = dev;
> >> ? ? ? crtc->funcs = funcs;
> >> + ? ? crtc->invert_dimensions = false;
> >>
> >> ? ? ? mutex_lock(>mode_config.mutex);
> >>
> >> @@ -609,6 +610,7 @@ int drm_plane_init(struct drm_device *dev, struct 
> >> drm_plane *plane,
> >> ? ? ? plane->base.properties = >properties;
> >> ? ? ? plane->dev = dev;
> >> ? ? ? plane->funcs = funcs;
> >> + ? ? plane->invert_dimensions = false;
> >> ? ? ? plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? GFP_KERNEL);
> >> ? ? ? if (!plane->format_types) {
> >> @@ -1758,6 +1760,9 @@ int drm_mode_setplane(struct drm_device *dev, void 
> >> *data,
> >> ? ? ? fb_width = fb->width << 16;
> >> ? ? ? fb_height = fb->height << 16;
> >>
> >> + ? ? if (plane->invert_dimensions)
> >> + ? ? ? ? ? ? swap(fb_width, fb_height);
> >> +
> >
> > In my opinion the only sane way to specify this stuff is that
> > the source coordinates are not transformed in any way.
> 
> fwiw, it might be a bit odd that in one case I swapped fb dimensions,
> and in the other crtc dimensions..  although it was just laziness
> (there were fewer param's to swap that way ;-))

Not sure if you got my point, which was that w/ plane rotation the
src coordinate check should be correct as is. Instead you should
apply the rotation when you clip/process the plane's crtc coordinates.

Since we don't clip the crtc coordinates in the common code (to allow
partially/fully offscreen planes), all the work ends up happening in
driver specific code.

> > So you fetch the data from the fb based on the source coordinates, then
> > apply all plane transformations (if any), and then apply all CRTC
> > transformations (if any).
> 
> fwiw, in my case planes and CRTCs are rotated independently.. ie.
> rotating the CRTC doesn't automatically rotate the planes.  But I
> include invert_dimensions flag in both drm_crtc and drm_plane so
> drivers for hw that works differently can do whatever is appropriate

I think you should rotate the planes according to the crtc rotation as
well. Otherwise the pipeline fb->plane->crtc->... doesn't make much
sense. If we would just deprecate the crtc='scanout engine' concept
this wouldn't be an issue, as you'd just have plane rotation all the
way.

I suppose another option would be to name your crtc rotation property to
something like "crtc fb rotation" to make it clear that it only applies
to the crtc scanout, and not any attached planes. Then we can still add a
"real" crtc rotation later. You could perhaps expose the rotation
capabilities of the actual display as "crtc rotation". OTOH maybe that'd
be equally illogical as rotation that doesn't rotate.

> >> ? ? ? /* Make sure source coordinates are inside the fb. */
> >> ? ? ? if (plane_req->src_w > fb_width ||
> >> ? ? ? ? ? plane_req->src_x > fb_width - plane_req->src_w ||
> >> @@ -1856,6 +1861,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void 
> >> *data,
> >> ? ? ? DRM_DEBUG_KMS("[CRTC:%d]\n", crtc->base.id);
> >>
> >> ? ? ? if (crtc_req->mode_valid) {
> >> + ? ? ? ? ? ? int hdisplay, vdisplay;
> >> ? ? ? ? ? ? ? /* If we have a mode we need a framebuffer. */
> >> ? ? ? ? ? ? ? /* If we pass -1, set the mode with the currently bound fb */
> >> ? ? ? ? ? ? ? if (crtc_req->fb_id == -1) {
> >> @@ -1891,14 +1897,20 @@ int drm_mode_setcrtc(struct drm_device *dev, void 
> >> *data,
> >>
> >> ? ? ? ? ? ? ? drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
> >>
> >> - ? ? ? ? ? ? if (mode->hdisplay > fb->width ||
> >> - ? ? ? ? ? ? ? ? mode->vdisplay > fb->height ||
> >> - ? ? ? ? ? ? ? ? crtc_req->x > fb->width - mode->hdisplay ||
> >> - ? ? ? ? ? ? ? ? crtc_req->y > fb->height - mode->vdisplay) {
> >> - ? ? ? ? ? ? ? ? ? ? DRM_DEBUG_KMS("Invalid CRTC viewport %ux%u+%u+%u for 
> >> fb size %ux%u.\n",
> >> - ? ? ? ? ? ? ? ? ? 

[3.4-rc1][Regression][intel] Resume from suspend to disk hangs on restoring backlight state

[Daniel Vetter]

On Mon, Apr 02, 2012 at 07:39:39PM +0200, Maciej Rutecki wrote:
> Last known good: 3.3
> Bad kernel: 3.4-rc1
> Subsystem: power management/suspend/dri(intel)
> 
> When I resume from suspend to disk then system hangs on this screen:
> http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/DSC_5479.jpg
> 
> It does not help SysRq keys. Only I can force power off by hold power button.
> 
> Dmesg:
> http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/dmesg-3.4-rc1.txt
> 
> Config:
> http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/config-3.4.0-rc1

Likely a known regression, ppgtt support broke hibernate because my code
doesn't restore the ppgtt page directory correctly in the thaw function.

Patch:
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes=55a254ac63a3ac1867d1501030e7fba69c7d4aeb

Please test whether this fixes your issue. You can also try adding
i915.i915_enable_ppgtt=0 to your kernel cmdline.

Thanks, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

broken nouveau dependency on power supply

[Benjamin Herrenschmidt]

On Mon, 2012-04-02 at 05:00 -0400, David Airlie wrote:
> >  - Better: Just make the bloody thing a bool :-) The power supply
> > framework itself is small enough, just make it a boolean option and
> > avoid the problem entirely. The actual power supply sub drivers can
> > remain modular of course.
> 
> We can just do select POWER_SUPPLY.

Well, select'ing otherwise user configurable options was still frowned
on last we discussed that... and it makes the whole inline stubs in
power_supply.h totally pointless :-)

> Yes it reduces the option range for some stupid corner case but really
> I don't care, removing features from the kernel that a driver depends
> on is just leading to insane state combination and QA problems.

Well, the power supply stuff only works if you have a backend for it,
which not all platforms are, and it's fairly safe to assume AC whenever
it's not actually supported.

(Talking of which, we should be able to do a PowerBook backend
reasonably easily).

I don't care which solution you guys end up choosing though, just fix
it :-)

Cheers,
Ben.

[3.4-rc1][Regression][intel] Resume from suspend to disk hangs on restoring backlight state

[Maciej Rutecki]

Last known good: 3.3
Bad kernel: 3.4-rc1
Subsystem: power management/suspend/dri(intel)

When I resume from suspend to disk then system hangs on this screen:
http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/DSC_5479.jpg

It does not help SysRq keys. Only I can force power off by hold power button.

Dmesg:
http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/dmesg-3.4-rc1.txt

Config:
http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/config-3.4.0-rc1
-- 
Maciej Rutecki
http://www.mrutecki.pl

[Bug 46724] radeon_drm_winsys compile fail with libdrm in non standard directory

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=46724

vand2 at gmx.de changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #3 from vand2 at gmx.de 2012-04-02 10:07:21 PDT ---
This seems fixed now. 
git version 42bc0b9b9dc31a15c08d409d14d25ccf19501255
compiles without any errors.

Thanks!

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 48203] New: texture problem with KMS

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48203

 Bug #: 48203
   Summary: texture problem with KMS
Classification: Unclassified
   Product: Mesa
   Version: 7.11
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: bottleman at icf.org.ru


there is a game - oolite, after switching to KMS there is texture problesm
started like
http://gallery.icf.org.ru/icfteam/GHhost/GHhost_screens/screenshot_027.png.html
and
http://gallery.icf.org.ru/icfteam/GHhost/GHhost_screens/screenshot0.png.html,
all othere works fine and game is playable,

hw 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250
[Mobility FireGL 9000] (rev 02)

xorg log:
[484367.551] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
[484367.551] (II) [KMS] Kernel modesetting enabled.
[484367.551] (**) RADEON(0): Depth 24, (--) framebuffer bpp 32
[484367.551] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp
pixmaps)
[484367.551] (==) RADEON(0): Default visual is TrueColor
[484367.551] (**) RADEON(0): Option "EnablePageFlip" "on"
[484367.551] (**) RADEON(0): Option "AccelDFS" "on"
[484367.551] (**) RADEON(0): Option "ColorTiling" "on"
[484367.551] (**) RADEON(0): Option "SubPixelOrder" "NONE"
[484367.551] (**) RADEON(0): Option "EXAVSync" "off"
[484367.551] (**) RADEON(0): Option "EXAPixmaps" "on"
[484367.551] (**) RADEON(0): Option "SwapbuffersWait" "on"
[484367.551] (==) RADEON(0): RGB weight 888
[484367.551] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
[484367.551] (--) RADEON(0): Chipset: "ATI Radeon Mobility 9000 (M9) Lf (AGP)"
(ChipID = 0x4c66)
[484367.551] (II) RADEON(0): AGP card detected
[484367.551] drmOpenDevice: node name is /dev/dri/card0
[484367.551] drmOpenDevice: open result is 9, (OK)
[484367.551] drmOpenByBusid: Searching for BusID pci::01:00.0
[484367.551] drmOpenDevice: node name is /dev/dri/card0
[484367.551] drmOpenDevice: open result is 9, (OK)
[484367.551] drmOpenByBusid: drmOpenMinor returns 9
[484367.551] drmOpenByBusid: Interface 1.4 failed, trying 1.1
[484367.551] drmOpenByBusid: drmGetBusid reports pci::01:00.0
[484367.552] (II) Loading sub module "exa"
[484367.552] (II) LoadModule: "exa"
[484367.552] (II) Loading /usr/lib/xorg/modules/libexa.so
[484367.552] (II) Module exa: vendor="X.Org Foundation"
[484367.552]compiled for 1.10.4, module version = 2.5.0
[484367.552]ABI class: X.Org Video Driver, version 10.0
[484367.552] (II) RADEON(0): KMS Color Tiling: enabled
[484367.552] (II) RADEON(0): SwapBuffers wait for vsync: enabled
[484367.560] (II) RADEON(0): Output VGA-0 using monitor section LCD_monitor
[484367.560] (II) RADEON(0): Output LVDS has no monitor section
[484367.566] (II) RADEON(0): Output S-video has no monitor section
[484367.574] (II) RADEON(0): EDID for output VGA-0
[484367.574] (II) RADEON(0): EDID for output LVDS
[484367.574] (II) RADEON(0): Printing probed modes for output LVDS
[484367.574] (II) RADEON(0): Modeline "1024x768"x60.4   65.00  1024 1040 1176
1336  768 769 775 805 (48.7 kHz)
[484367.574] (II) RADEON(0): Modeline "800x600"x59.9   38.25  800 832 912 1024 
600 603 607 624 -hsync +vsync (37.4 kHz)
[484367.574] (II) RADEON(0): Modeline "848x480"x59.7   31.50  848 872 952 1056 
480 483 493 500 -hsync +vsync (29.8 kHz)
[484367.574] (II) RADEON(0): Modeline "720x480"x59.7   26.75  720 744 808 896 
480 483 493 500 -hsync +vsync (29.9 kHz)
[484367.574] (II) RADEON(0): Modeline "640x480"x59.4   23.75  640 664 720 800 
480 483 487 500 -hsync +vsync (29.7 kHz)
[484367.580] (II) RADEON(0): EDID for output S-video
[484367.580] (II) RADEON(0): Output VGA-0 disconnected
[484367.580] (II) RADEON(0): Output LVDS connected
[484367.580] (II) RADEON(0): Output S-video disconnected
[484367.580] (II) RADEON(0): Using user preference for initial modes
[484367.580] (II) RADEON(0): Output LVDS using initial mode 1024x768
[484367.580] (II) RADEON(0): Using default gamma of (1.0, 1.0, 1.0) unless
otherwise stated.
[484367.580] (II) RADEON(0): mem size init: gart size :fdff000 vram size:
s:400 visible:3cc
[484367.580] (II) RADEON(0): EXA: Driver will allow EXA pixmaps in VRAM
[484367.580] (++) RADEON(0): DPI set to (106, 106)
[484367.580] (II) Loading sub module "fb"
[484367.580] (II) LoadModule: "fb"
[484367.580] (II) Loading /usr/lib/xorg/modules/libfb.so
[484367.580] (II) Module fb: vendor="X.Org Foundation"
[484367.580]compiled for 1.10.4, module version = 1.0.0
[484367.581]ABI class: X.Org ANSI C Emulation, version 0.4
[484367.581] (II) Loading sub module "ramdac"
[484367.581] (II) LoadModule: "ramdac"
[484367.581] (II) Module "ramdac" already built-in
[484367.581] (--) Depth 24 pixmap format is 32 bpp
[484367.581] (WW) RADEON(0): You need a newer kernel for sync extension
[484367.581] (II) RADEON(0): 

Process to merge Openchrome work

[James Simmons]

Hello!!

This last year the Openchrome support for the VIA chipsets has 
come along way from being in a state of decay. The plan is to release
a Xorg driver June 1 that will have support for the KMS as well as UMS.
The goal is to have this xorg driver out in the wild before the kernel
side is ready so that the migration to the new kernel drivers will be
as painless as possible. My hope is to merge the kernel tree for public 
use for Christmas.
This brings up the question I had with the other project leader.
How does one go about merging the tree? What makes this more complex is
that a old via drm kernel driver already exist. Do we just drop in the 
code into the staging area? Does it have to be piece meal? Does a rename 
of the driver need to happen? What would you recommend ?

[Bug 48197] DVI monitor connected to an Ati x1550 on standard resolution blinks.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48197

--- Comment #5 from ter4py at gmail.com 2012-04-02 08:25:14 PDT ---
Only in the 1680x1050 mode that way.
But it might happen very rarely on 1480x900. 
I'm not sure about this though, it didn't happen recently.
(In reply to comment #4)
> Does it only blink on the 1680x1050 mode or all modes on the DVI monitor?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 48197] DVI monitor connected to an Ati x1550 on standard resolution blinks.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48197

--- Comment #4 from Alex Deucher  2012-04-02 08:11:53 PDT 
---
Does it only blink on the 1680x1050 mode or all modes on the DVI monitor?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 48197] DVI monitor connected to an Ati x1550 on standard resolution blinks.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48197

--- Comment #3 from ter4py at gmail.com 2012-04-02 07:57:35 PDT ---
It doesn't help at all.

(In reply to comment #2)
> Does booting with radeon.disp_priority=2 on the kernel command line in grub
> help?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 48197] DVI monitor connected to an Ati x1550 on standard resolution blinks.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48197

--- Comment #2 from Alex Deucher  2012-04-02 07:46:28 PDT 
---
Does booting with radeon.disp_priority=2 on the kernel command line in grub
help?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Intel-gfx] [PATCH] drm/i915: enable semaphores on gen6 if dmar is not active

[Andrew Lutomirski]

On Mon, Apr 2, 2012 at 1:52 PM, Daniel Vetter  wrote:
> On Mon, Apr 02, 2012 at 01:45:39PM -0700, Andrew Lutomirski wrote:
>> On Mon, Apr 2, 2012 at 11:48 AM, Daniel Vetter  
>> wrote:
>> > Inspired by the recent ppgtt regression report, where switching of
>> > dmar only for the gpu seems to fix things completely, I've looked
>> > again at the semaphores+vt-d situation.
>> >
>> > Contrary to my earlier testing a few months back my system is now
>> > stable with dmar disabled for the igd, and not only when disabling
>> > dmar completely.
>> >
>> > So I'm rather hopeful that all our recent fixes for snb have changed
>> > things for code and it's time to try enabling semaphores again. We've
>> > also had issues with enabling semaphores which are not vt-d related,
>> > but I guess these are all fixed by the autoreport-disabling and lazy
>> > request fix. And there's only one way to find out whether there are
>> > still other issues ...
>> >
>> > Signed-Off-by: Daniel Vetter 
>> >
>> > ---
>> >
>> > If no further vt-d regressions show up in the 3.4 cycle I plan to
>> > merge this into -next for 3.5 (in a month or so). Comments about how
>> > unfeasibly you deem this highly welcome.
>> > -Daniel
>> > ---
>> > ?drivers/gpu/drm/i915/i915_gem_execbuffer.c | ? ?8 +---
>> > ?1 files changed, 5 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
>> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>> > index 8e0b686..ac52433 100644
>> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>> > @@ -849,9 +849,11 @@ intel_enable_semaphores(struct drm_device *dev)
>> > ? ? ? ?if (i915_semaphores >= 0)
>> > ? ? ? ? ? ? ? ?return i915_semaphores;
>> >
>> > - ? ? ? /* Disable semaphores on SNB */
>> > - ? ? ? if (INTEL_INFO(dev)->gen == 6)
>> > - ? ? ? ? ? ? ? return 0;
>> > +#ifdef CONFIG_INTEL_IOMMU
>> > + ? ? ? /* Disable semaphores on SNB if VT-d is on. */
>> > + ? ? ? if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped)
>> > + ? ? ? ? ? ? ? return false;
>>
>> It might be nice to have a printk here giving instructions for how to work
>> around this. ?For example:
>>
>> i915: Disabling semaphores to work around a DMAR issue. ?As an
>> alternative, boot with intel_iommu=igfx_off [or on, igfx_off, or
>> whatever it's supposed to be].
>>
>> The documentation in kernel-parameters.txt is at best unclear to the
>> uninitiated.
>
> If this really does work, I'll look into this. Atm it's still unclear
> where to exactly put the plain, we need to annoy internal hardware people
> to analyze this. Once we have enough evidence that the combination of gpu
> with various features enable plus VT-d just doesn't seem to work reliably.
>
> So can you check whether things do indeed work with this patch, atop
> kernel 3.4-rc1? Iirc you've been the one with the most trouble when
> semaphores are enabled ...

I've had a hard time reproducing the problems lately.  The
unconditional instant hard hang went away a few months ago, I think.
I'll give it another shot when I get home to that machine.

--Andy

[Bug 48197] DVI monitor connected to an Ati x1550 on standard resolution blinks.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48197

--- Comment #1 from ter4py at gmail.com 2012-04-02 07:40:17 PDT ---
Created attachment 59381
  --> https://bugs.freedesktop.org/attachment.cgi?id=59381
Xorg log

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 48197] New: DVI monitor connected to an Ati x1550 on standard resolution blinks.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48197

 Bug #: 48197
   Summary: DVI monitor connected to an Ati x1550 on standard
resolution blinks.
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: ter4py at gmail.com


Created attachment 59380
  --> https://bugs.freedesktop.org/attachment.cgi?id=59380
dmesg from fedora 16

I have an Ati radeon x1550, and connected to that a DVI monitor (and another to
the VGA, but this bug is present also when only the DVI monitor is connected)
This bug appears in every distribution and kernel I tried, the last one is
fedora 16, but I tried debian 6 too and Archlinux with the latest kernel.
Description of problem:
DVI screen, if on standard resolution (1680x1050) blinks from the tty to the
Gnome dekstop, and especially when something like Firefox is made fullscreen:
I recorded a video to explain this better:
https://www.youtube.com/watch?v=8Tcjb6p0Yi4

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 42920] Radeon with KMS and UMA works only up to 128MB

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=42920


j.fikar at gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WILL_NOT_FIX




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH] drm/prime: expose capability flags for userspace.

[Dave Airlie]

From: Dave Airlie 

This lets the kernel tell userspace if the device supports prime
import/export.

This is useful for -modesetting at least, but would be nice for other
drivers.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_ioctl.c |4 
 include/drm/drm.h   |4 
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index cf85155..64a62c6 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -283,6 +283,10 @@ int drm_getcap(struct drm_device *dev, void *data, struct 
drm_file *file_priv)
case DRM_CAP_DUMB_PREFER_SHADOW:
req->value = dev->mode_config.prefer_shadow;
break;
+   case DRM_CAP_PRIME:
+   req->value |= dev->driver->prime_fd_to_handle ? 
DRM_PRIME_CAP_IMPORT : 0;
+   req->value |= dev->driver->prime_handle_to_fd ? 
DRM_PRIME_CAP_EXPORT : 0;
+   break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 64ff02d..34d6335 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -775,6 +775,10 @@ struct drm_event_vblank {
 #define DRM_CAP_VBLANK_HIGH_CRTC 0x2
 #define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
 #define DRM_CAP_DUMB_PREFER_SHADOW 0x4
+#define DRM_CAP_PRIME 0x5
+
+#define DRM_PRIME_CAP_IMPORT 0x1
+#define DRM_PRIME_CAP_EXPORT 0x2

 /* typedef area */
 #ifndef __KERNEL__
-- 
1.7.7.6

[Bug 42920] Radeon with KMS and UMA works only up to 128MB

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=42920





--- Comment #8 from j.fikar at gmail.com  2012-04-02 13:58:16 ---
The problem is solved! I forgot I have a custom dsdt.hex, created with small
amount of UMA memory. Removing the custom dsdt.hex solves the problem:

[6.976583] [drm] Initialized drm 1.1.0 20060810
[7.127923] [drm] radeon defaulting to kernel modesetting.
[7.127925] [drm] radeon kernel modesetting enabled.
[7.127974] radeon :01:05.0: setting latency timer to 64
[7.128093] [drm] initializing kernel modesetting (RS880 0x1002:0x9715
0x1043:0x843E).
[7.128108] [drm] register mmio base: 0xFEBE
[7.128109] [drm] register mmio size: 65536
[7.128705] [drm] CONFIG_MEMSIZE: 0x4000
[7.128708] radeon :01:05.0: VRAM: 1024M 0xC000 -
0x (1024M used)
[7.128710] radeon :01:05.0: GTT: 512M 0xA000 -
0xBFFF
[7.132802] [drm] Detected VRAM RAM=1024M, BAR=256M
[7.132805] [drm] RAM width 32bits DDR
[7.132896] [drm] radeon: 1024M of VRAM memory ready
[7.132897] [drm] radeon: 512M of GTT memory ready.
[7.132910] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[7.132911] [drm] Driver supports precise vblank timestamp query.
[7.132932] [drm] radeon: irq initialized.
[7.132935] [drm] GART: num cpu pages 131072, num gpu pages 131072
[7.133487] [drm] radeon: ib pool ready.
[7.133551] [drm] Loading RS780 Microcode
[7.245054] [drm] PCIE GART of 512M enabled (table at 0xC004).
[7.245117] radeon :01:05.0: WB enabled
[7.245119] [drm] fence driver on ring 0 use gpu addr 0xac00 and cpu
addr 0x8804156aec00
[7.277226] [drm] ring test on 0 succeeded in 1 usecs
[7.277296] [drm] ib test on ring 0 succeeded in 0 usecs
[7.582928] [drm] radeon: blit 1024 bo moves of 1024 kB from 2 to 4 in 305
ms, throughput: 27496 Mb/s or 3437 MB/s
[7.888011] [drm] radeon: blit 1024 bo moves of 1024 kB from 4 to 2 in 305
ms, throughput: 27496 Mb/s or 3437 MB/s
[7.888368] [drm] Radeon Display Connectors
[7.888370] [drm] Connector 0:
[7.888371] [drm]   VGA
[7.888372] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c
0x7e4c
[7.888373] [drm]   Encoders:
[7.888374] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[7.888375] [drm] Connector 1:
[7.888376] [drm]   HDMI-A
[7.888377] [drm]   HPD3
[7.888378] [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c
0x7e5c
[7.888380] [drm]   Encoders:
[7.888381] [drm] DFP3: INTERNAL_KLDSCP_LVTMA
[7.888404] [drm] radeon: power management initialized
[7.961690] [drm] fb mappable at 0xD0142000
[7.961692] [drm] vram apper at 0xD000
[7.961693] [drm] size 3932160
[7.961694] [drm] fb depth is 24
[7.961695] [drm]pitch is 5120
[7.961753] fbcon: radeondrmfb (fb0) is primary device
[7.984815] fb0: radeondrmfb frame buffer device
[7.984816] drm: registered panic notifier
[7.984820] [drm] Initialized radeon 2.13.0 20080528 for :01:05.0 on
minor 0

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

broken nouveau dependency on power supply

[Benjamin Herrenschmidt]

On Mon, 2012-04-02 at 11:06 +1000, Benjamin Herrenschmidt wrote:
> Hi folks !
> 
> With CONFIG_POWER_SUPPLY=m & nouveau built-in we get a build failure:
> 
> drivers/built-in.o: In function `.nouveau_pm_trigger':
> (.text+0xa56e8): undefined reference to `.power_supply_is_system_supplied'
> 
> nouveau probably needs to depends on CONFIG_POWER_SUPPLY to force a module
> build with the latter is =m

Ok, not that trivial...

The problem is more like POWER_SUPPLY should be a bool, not a tristate.

If you think about it: you don't want things like nouveau to depend on a
random subsystem like that, people will never get it. In fact,
POWER_SUPPLY provides empty inline stubs when not enabled, so that's
really designed to not have depends...

However that -cannot- work if POWER_SUPPLY is modular and the drivers
who use it are not. The only fixes here that make sense I can think of
that don't also involve Kconfig horrors are:

 - Ugly: in power_supply.h, use the extern variant if

defined(CONFIG_POWER_SUPPLY) ||
 (defined(CONFIG_POWER_SUPPLY_MODULE) && defined(MODULE))

IE. use the stub if power supply is a module and what is being built is
built-in. Of course that's not only ugly, it somewhat sucks from a user
perspective as the subsystem now exists but can't be used by some
drivers...

 - Better: Just make the bloody thing a bool :-) The power supply
framework itself is small enough, just make it a boolean option and
avoid the problem entirely. The actual power supply sub drivers can
remain modular of course.

Cheers,
Ben.

[Intel-gfx] [PATCH] drm/i915: enable semaphores on gen6 if dmar is not active

[Andrew Lutomirski]

On Mon, Apr 2, 2012 at 11:48 AM, Daniel Vetter  
wrote:
> Inspired by the recent ppgtt regression report, where switching of
> dmar only for the gpu seems to fix things completely, I've looked
> again at the semaphores+vt-d situation.
>
> Contrary to my earlier testing a few months back my system is now
> stable with dmar disabled for the igd, and not only when disabling
> dmar completely.
>
> So I'm rather hopeful that all our recent fixes for snb have changed
> things for code and it's time to try enabling semaphores again. We've
> also had issues with enabling semaphores which are not vt-d related,
> but I guess these are all fixed by the autoreport-disabling and lazy
> request fix. And there's only one way to find out whether there are
> still other issues ...
>
> Signed-Off-by: Daniel Vetter 
>
> ---
>
> If no further vt-d regressions show up in the 3.4 cycle I plan to
> merge this into -next for 3.5 (in a month or so). Comments about how
> unfeasibly you deem this highly welcome.
> -Daniel
> ---
> ?drivers/gpu/drm/i915/i915_gem_execbuffer.c | ? ?8 +---
> ?1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 8e0b686..ac52433 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -849,9 +849,11 @@ intel_enable_semaphores(struct drm_device *dev)
> ? ? ? ?if (i915_semaphores >= 0)
> ? ? ? ? ? ? ? ?return i915_semaphores;
>
> - ? ? ? /* Disable semaphores on SNB */
> - ? ? ? if (INTEL_INFO(dev)->gen == 6)
> - ? ? ? ? ? ? ? return 0;
> +#ifdef CONFIG_INTEL_IOMMU
> + ? ? ? /* Disable semaphores on SNB if VT-d is on. */
> + ? ? ? if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped)
> + ? ? ? ? ? ? ? return false;

It might be nice to have a printk here giving instructions for how to work
around this.  For example:

i915: Disabling semaphores to work around a DMAR issue.  As an
alternative, boot with intel_iommu=igfx_off [or on, igfx_off, or
whatever it's supposed to be].

The documentation in kernel-parameters.txt is at best unclear to the
uninitiated.

--Andy

[PATCH] nouveau/bios: Fix tracking of BIOS image data

[Benjamin Herrenschmidt]

The code tries various methods for retreiving the BIOS data. However
it doesn't clear the bios->data pointer between the iterations.

In some cases, the shadow() method will fail and not update bios->data
at all, which will cause us to "score" the old data and incorrectly
attribute that score to the new method. This can cause double frees
later when disposing of the unused data.

Additionally, we were not freeing the data for methods that fail the
score test (we only freed when a "best" is superseeded, not when the
new method has a lower score than the exising "best"). Fix that as well.

Signed-off-by: Benjamin Herrenschmidt 
---

This was found by code inspection while chasing a different bug,
I do not hit the problem path on my machine.

 drivers/gpu/drm/nouveau/nouveau_bios.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c 
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index 80963d0..1947d61 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -273,6 +273,7 @@ bios_shadow(struct drm_device *dev)
mthd->score = score_vbios(bios, mthd->rw);
mthd->size = bios->length;
mthd->data = bios->data;
+   bios->data = NULL;
} while (mthd->score != 3 && (++mthd)->shadow);

mthd = shadow_methods;
@@ -281,7 +282,8 @@ bios_shadow(struct drm_device *dev)
if (mthd->score > best->score) {
kfree(best->data);
best = mthd;
-   }
+   } else
+   kfree(mthd->data);
} while ((++mthd)->shadow);

if (best->score) {
-- 
1.7.9.5

[PATCH] nouveau: Fix crash when pci_ram_rom() returns a size of 0

[Benjamin Herrenschmidt]

No subject

[Benjamin Herrenschmidt]

Under some circumstances, pci_map_rom() can return a valid mapping
but a size of 0 (if it cannot find an image in the header).

This causes nouveau to try to kmalloc() a 0 sized pointer and
dereference it, which crashes.

Signed-off-by: Benjamin Herrenschmidt 
---

Please send to Linus asap, without this, it crashes on the G5

 drivers/gpu/drm/nouveau/nouveau_bios.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c 
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index 637afe7..80963d0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -177,14 +177,15 @@ bios_shadow_pci(struct nvbios *bios)

if (!pci_enable_rom(pdev)) {
void __iomem *rom = pci_map_rom(pdev, );
-   if (rom) {
+   if (rom && length) {
bios->data = kmalloc(length, GFP_KERNEL);
if (bios->data) {
memcpy_fromio(bios->data, rom, length);
bios->length = length;
}
-   pci_unmap_rom(pdev, rom);
}
+   if (rom)
+   pci_unmap_rom(pdev, rom);

pci_disable_rom(pdev);
}
-- 
1.7.9.5

Linux 3.4-rc1

[Kyungmin Park]

On Mon, Apr 2, 2012 at 12:34 AM, Rob Clark  wrote:
> On Sat, Mar 31, 2012 at 6:58 PM, Linus Torvalds
>  wrote:
>> ?- drm dma-buf prime support. Dave Airlie sent me the pull request but
>> didn't push very hard for it, it's in my "ok, I can still pull it for
>> 3.4 if individual DRM driver people tell me that it will make their
>> lives easier." So this is in limbo - I have nothing against it, but I
>> won't pull unless I get a few people say "yes, please".
>
> yes, please :-)
>
> Note that the core drm dma-buf/prime support has already been reviewed
> by a lot of folks, and tested with a few different drivers (exynos,
> omapdrm, i915, nouveau, udl) with some driver support that could be
> pushed for 3.5 cycle if the core support makes it in for 3.4 cycle.
Yes, Please.

It's used for exynos display and multimedia.

Thank you,
Kyungmin Park
>
> BR,
> -R
>
> ___
> linaro-dev mailing list
> linaro-dev at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev

broken nouveau dependency on power supply

[Benjamin Herrenschmidt]

Hi folks !

With CONFIG_POWER_SUPPLY=m & nouveau built-in we get a build failure:

drivers/built-in.o: In function `.nouveau_pm_trigger':
(.text+0xa56e8): undefined reference to `.power_supply_is_system_supplied'

nouveau probably needs to depends on CONFIG_POWER_SUPPLY to force a module
build with the latter is =m

Cheers,
Ben.

Linux 3.4-rc1

[Daniel Vetter]

On Mon, Apr 02, 2012 at 12:40:39PM +0900, Kyungmin Park wrote:
> On Mon, Apr 2, 2012 at 12:34 AM, Rob Clark  wrote:
> > On Sat, Mar 31, 2012 at 6:58 PM, Linus Torvalds
> >  wrote:
> >> ?- drm dma-buf prime support. Dave Airlie sent me the pull request but
> >> didn't push very hard for it, it's in my "ok, I can still pull it for
> >> 3.4 if individual DRM driver people tell me that it will make their
> >> lives easier." So this is in limbo - I have nothing against it, but I
> >> won't pull unless I get a few people say "yes, please".
> >
> > yes, please :-)
> >
> > Note that the core drm dma-buf/prime support has already been reviewed
> > by a lot of folks, and tested with a few different drivers (exynos,
> > omapdrm, i915, nouveau, udl) with some driver support that could be
> > pushed for 3.5 cycle if the core support makes it in for 3.4 cycle.
> Yes, Please.
> 
> It's used for exynos display and multimedia.

Thirded.

There are a lot of loose pieces to juggle until we have everything in
place for buffer sharing (and quite a few of this involve contentious
topics). But this core piece for integrating dma-buf with drm here has
been acked/reviewd by all the relevant people and merging it would imo
greatly help in wiring up all the other loose ends.

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] drm/i915: disable ppgtt on snb when dmar is enabled

[Chris Wilson]

On Mon,  2 Apr 2012 10:08:35 +0200, Daniel Vetter  
wrote:
> Totally unexpected that this regressed. Luckily it sounds like we just
> need to have dmar disable on the igfx, not the entire system. At least
> that's what a few days of testing between Tony Vroon and me indicates.
> 
> Reported-by: Tony Vroon 
> Cc: Tony Vroon 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43024
> Signed-Off-by: Daniel Vetter 

Patch itself looks sane,

Acked-by: Chris Wilson 

-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH RFC] drm: support for rotated scanout

[Rob Clark]

On Sat, Mar 31, 2012 at 4:09 PM, Ville Syrj?l?  wrote:
> On Fri, Mar 30, 2012 at 05:59:32PM -0500, Rob Clark wrote:
>> From: Rob Clark 
>>
>> For drivers that can support rotated scanout, the extra parameter
>> checking in drm-core, while nice, tends to get confused. ?To solve
>> this drivers can set the crtc or plane invert_dimensions field so
>> that the dimension checking takes into account the rotation that
>> the driver is performing.
>> ---
>> Note: RFC still mainly because I've only tested the CRTC rotation so
>> far.. still need to write some test code for plane rotation.
>>
>> ?drivers/gpu/drm/drm_crtc.c | ? 50 
>> +--
>> ?include/drm/drm_crtc.h ? ? | ? ?9 
>> ?2 files changed, 43 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index 0dff444..261c9bd 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -375,6 +375,7 @@ int drm_crtc_init(struct drm_device *dev, struct 
>> drm_crtc *crtc,
>>
>> ? ? ? crtc->dev = dev;
>> ? ? ? crtc->funcs = funcs;
>> + ? ? crtc->invert_dimensions = false;
>>
>> ? ? ? mutex_lock(>mode_config.mutex);
>>
>> @@ -609,6 +610,7 @@ int drm_plane_init(struct drm_device *dev, struct 
>> drm_plane *plane,
>> ? ? ? plane->base.properties = >properties;
>> ? ? ? plane->dev = dev;
>> ? ? ? plane->funcs = funcs;
>> + ? ? plane->invert_dimensions = false;
>> ? ? ? plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? GFP_KERNEL);
>> ? ? ? if (!plane->format_types) {
>> @@ -1758,6 +1760,9 @@ int drm_mode_setplane(struct drm_device *dev, void 
>> *data,
>> ? ? ? fb_width = fb->width << 16;
>> ? ? ? fb_height = fb->height << 16;
>>
>> + ? ? if (plane->invert_dimensions)
>> + ? ? ? ? ? ? swap(fb_width, fb_height);
>> +
>
> In my opinion the only sane way to specify this stuff is that
> the source coordinates are not transformed in any way.

fwiw, it might be a bit odd that in one case I swapped fb dimensions,
and in the other crtc dimensions..  although it was just laziness
(there were fewer param's to swap that way ;-))

> So you fetch the data from the fb based on the source coordinates, then
> apply all plane transformations (if any), and then apply all CRTC
> transformations (if any).

fwiw, in my case planes and CRTCs are rotated independently.. ie.
rotating the CRTC doesn't automatically rotate the planes.  But I
include invert_dimensions flag in both drm_crtc and drm_plane so
drivers for hw that works differently can do whatever is appropriate

>
>> ? ? ? /* Make sure source coordinates are inside the fb. */
>> ? ? ? if (plane_req->src_w > fb_width ||
>> ? ? ? ? ? plane_req->src_x > fb_width - plane_req->src_w ||
>> @@ -1856,6 +1861,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void 
>> *data,
>> ? ? ? DRM_DEBUG_KMS("[CRTC:%d]\n", crtc->base.id);
>>
>> ? ? ? if (crtc_req->mode_valid) {
>> + ? ? ? ? ? ? int hdisplay, vdisplay;
>> ? ? ? ? ? ? ? /* If we have a mode we need a framebuffer. */
>> ? ? ? ? ? ? ? /* If we pass -1, set the mode with the currently bound fb */
>> ? ? ? ? ? ? ? if (crtc_req->fb_id == -1) {
>> @@ -1891,14 +1897,20 @@ int drm_mode_setcrtc(struct drm_device *dev, void 
>> *data,
>>
>> ? ? ? ? ? ? ? drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
>>
>> - ? ? ? ? ? ? if (mode->hdisplay > fb->width ||
>> - ? ? ? ? ? ? ? ? mode->vdisplay > fb->height ||
>> - ? ? ? ? ? ? ? ? crtc_req->x > fb->width - mode->hdisplay ||
>> - ? ? ? ? ? ? ? ? crtc_req->y > fb->height - mode->vdisplay) {
>> - ? ? ? ? ? ? ? ? ? ? DRM_DEBUG_KMS("Invalid CRTC viewport %ux%u+%u+%u for 
>> fb size %ux%u.\n",
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? mode->hdisplay, mode->vdisplay,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? crtc_req->x, crtc_req->y,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? fb->width, fb->height);
>> + ? ? ? ? ? ? hdisplay = mode->hdisplay;
>> + ? ? ? ? ? ? vdisplay = mode->vdisplay;
>> +
>> + ? ? ? ? ? ? if (crtc->invert_dimensions)
>> + ? ? ? ? ? ? ? ? ? ? swap(hdisplay, vdisplay);
>> +
>> + ? ? ? ? ? ? if (hdisplay > fb->width ||
>> + ? ? ? ? ? ? ? ? vdisplay > fb->height ||
>> + ? ? ? ? ? ? ? ? crtc_req->x > fb->width - hdisplay ||
>> + ? ? ? ? ? ? ? ? crtc_req->y > fb->height - vdisplay) {
>> + ? ? ? ? ? ? ? ? ? ? DRM_DEBUG_KMS("Invalid fb size %ux%u for CRTC viewport 
>> %ux%u+%d+%d%s.\n",
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? fb->width, fb->height,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? hdisplay, vdisplay, crtc_req->x, 
>> crtc_req->y,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? crtc->invert_dimensions ? " (inverted)" 
>> : "");
>
> I would perhaps just stick more details about the transformations into
> drm_crtc, but we will anyway require a better mode setting API. So
> perhaps this is an OK intermediate solution.
>

I was trying to avoid putting full matrix transformation in the kernel ;-)

but at least the hw I'm familiar with is only doing simple isometric
transformations in scanout 

[PATCH] drm/i915: disable ppgtt on snb when dmar is enabled

[Daniel Vetter]

Totally unexpected that this regressed. Luckily it sounds like we just
need to have dmar disable on the igfx, not the entire system. At least
that's what a few days of testing between Tony Vroon and me indicates.

Reported-by: Tony Vroon 
Cc: Tony Vroon 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43024
Signed-Off-by: Daniel Vetter 
---
 drivers/char/agp/intel-gtt.c|1 -
 drivers/gpu/drm/i915/i915_dma.c |   17 -
 drivers/gpu/drm/i915/i915_drv.c |4 ++--
 drivers/gpu/drm/i915/i915_drv.h |2 +-
 include/drm/intel-gtt.h |4 
 5 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 7e223a2..e086fa5 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1204,7 +1204,6 @@ static inline int needs_idle_maps(void)
 {
 #ifdef CONFIG_INTEL_IOMMU
const unsigned short gpu_devid = intel_private.pcidev->device;
-   extern int intel_iommu_gfx_mapped;

/* Query intel_iommu to see if we need the workaround. Presumably that
 * was loaded first.
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4636391..ee06241 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1189,6 +1189,21 @@ static bool i915_switcheroo_can_switch(struct pci_dev 
*pdev)
return can_switch;
 }

+static bool
+intel_enable_ppgtt(struct drm_device *dev)
+{
+   if (i915_enable_ppgtt >= 0)
+   return i915_enable_ppgtt;
+
+#ifdef CONFIG_INTEL_IOMMU
+   /* Disable ppgtt on SNB if VT-d is on. */
+   if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped)
+   return false;
+#endif
+
+   return true;
+}
+
 static int i915_load_gem_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1203,7 +1218,7 @@ static int i915_load_gem_init(struct drm_device *dev)
drm_mm_init(_priv->mm.stolen, 0, prealloc_size);

mutex_lock(>struct_mutex);
-   if (i915_enable_ppgtt && HAS_ALIASING_PPGTT(dev)) {
+   if (intel_enable_ppgtt(dev) && HAS_ALIASING_PPGTT(dev)) {
/* PPGTT pdes are stolen from global gtt ptes, so shrink the
 * aperture accordingly when using aliasing ppgtt. */
gtt_size -= I915_PPGTT_PD_ENTRIES*PAGE_SIZE;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0efc02e..c65907e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -109,8 +109,8 @@ MODULE_PARM_DESC(enable_hangcheck,
"WARNING: Disabling this can cause system wide hangs. "
"(default: true)");

-bool i915_enable_ppgtt __read_mostly = 1;
-module_param_named(i915_enable_ppgtt, i915_enable_ppgtt, bool, 0600);
+int i915_enable_ppgtt __read_mostly = -1;
+module_param_named(i915_enable_ppgtt, i915_enable_ppgtt, int, 0600);
 MODULE_PARM_DESC(i915_enable_ppgtt,
"Enable PPGTT (default: true)");

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b617cd5..1c8c440 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1088,7 +1088,7 @@ extern int i915_vbt_sdvo_panel_type __read_mostly;
 extern int i915_enable_rc6 __read_mostly;
 extern int i915_enable_fbc __read_mostly;
 extern bool i915_enable_hangcheck __read_mostly;
-extern bool i915_enable_ppgtt __read_mostly;
+extern int i915_enable_ppgtt __read_mostly;

 extern int i915_suspend(struct drm_device *dev, pm_message_t state);
 extern int i915_resume(struct drm_device *dev);
diff --git a/include/drm/intel-gtt.h b/include/drm/intel-gtt.h
index 0a0001b..923afb5 100644
--- a/include/drm/intel-gtt.h
+++ b/include/drm/intel-gtt.h
@@ -44,4 +44,8 @@ void intel_gtt_insert_pages(unsigned int first_entry, 
unsigned int num_entries,
 /* flag for GFDT type */
 #define AGP_USER_CACHED_MEMORY_GFDT (1 << 3)

+#ifdef CONFIG_INTEL_IOMMU
+extern int intel_iommu_gfx_mapped;
+#endif
+
 #endif
-- 
1.7.7.6

Linux 3.4-rc1

[Alex Deucher]

On Sun, Apr 1, 2012 at 11:34 AM, Rob Clark  wrote:
> On Sat, Mar 31, 2012 at 6:58 PM, Linus Torvalds
>  wrote:
>> ?- drm dma-buf prime support. Dave Airlie sent me the pull request but
>> didn't push very hard for it, it's in my "ok, I can still pull it for
>> 3.4 if individual DRM driver people tell me that it will make their
>> lives easier." So this is in limbo - I have nothing against it, but I
>> won't pull unless I get a few people say "yes, please".
>
> yes, please :-)
>
> Note that the core drm dma-buf/prime support has already been reviewed
> by a lot of folks, and tested with a few different drivers (exynos,
> omapdrm, i915, nouveau, udl) with some driver support that could be
> pushed for 3.5 cycle if the core support makes it in for 3.4 cycle.

Please.  It's the first step in making hybrid laptops work properly in Linux.

Alex

broken nouveau dependency on power supply

[David Airlie]

> 
> Ok, not that trivial...
> 
> The problem is more like POWER_SUPPLY should be a bool, not a
> tristate.
> 
> If you think about it: you don't want things like nouveau to depend
> on a
> random subsystem like that, people will never get it. In fact,
> POWER_SUPPLY provides empty inline stubs when not enabled, so that's
> really designed to not have depends...
> 
> However that -cannot- work if POWER_SUPPLY is modular and the drivers
> who use it are not. The only fixes here that make sense I can think
> of
> that don't also involve Kconfig horrors are:
> 
>  - Ugly: in power_supply.h, use the extern variant if
> 
>   defined(CONFIG_POWER_SUPPLY) ||
>(defined(CONFIG_POWER_SUPPLY_MODULE) && defined(MODULE))
> 
> IE. use the stub if power supply is a module and what is being built
> is
> built-in. Of course that's not only ugly, it somewhat sucks from a
> user
> perspective as the subsystem now exists but can't be used by some
> drivers...
> 
>  - Better: Just make the bloody thing a bool :-) The power supply
> framework itself is small enough, just make it a boolean option and
> avoid the problem entirely. The actual power supply sub drivers can
> remain modular of course.

We can just do select POWER_SUPPLY.

Yes it reduces the option range for some stupid corner case but really I don't 
care, removing features from the kernel that a driver depends on is just 
leading to insane state combination and QA problems.

Dave.

Re: Linux 3.4-rc1

[Rob Clark]

On Sat, Mar 31, 2012 at 6:58 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
  - drm dma-buf prime support. Dave Airlie sent me the pull request but
 didn't push very hard for it, it's in my ok, I can still pull it for
 3.4 if individual DRM driver people tell me that it will make their
 lives easier. So this is in limbo - I have nothing against it, but I
 won't pull unless I get a few people say yes, please.

yes, please :-)

Note that the core drm dma-buf/prime support has already been reviewed
by a lot of folks, and tested with a few different drivers (exynos,
omapdrm, i915, nouveau, udl) with some driver support that could be
pushed for 3.5 cycle if the core support makes it in for 3.4 cycle.

BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.4-rc1

[Daniel Vetter]

On Mon, Apr 02, 2012 at 12:40:39PM +0900, Kyungmin Park wrote:
 On Mon, Apr 2, 2012 at 12:34 AM, Rob Clark rob.cl...@linaro.org wrote:
  On Sat, Mar 31, 2012 at 6:58 PM, Linus Torvalds
  torva...@linux-foundation.org wrote:
   - drm dma-buf prime support. Dave Airlie sent me the pull request but
  didn't push very hard for it, it's in my ok, I can still pull it for
  3.4 if individual DRM driver people tell me that it will make their
  lives easier. So this is in limbo - I have nothing against it, but I
  won't pull unless I get a few people say yes, please.
 
  yes, please :-)
 
  Note that the core drm dma-buf/prime support has already been reviewed
  by a lot of folks, and tested with a few different drivers (exynos,
  omapdrm, i915, nouveau, udl) with some driver support that could be
  pushed for 3.5 cycle if the core support makes it in for 3.4 cycle.
 Yes, Please.
 
 It's used for exynos display and multimedia.

Thirded.

There are a lot of loose pieces to juggle until we have everything in
place for buffer sharing (and quite a few of this involve contentious
topics). But this core piece for integrating dma-buf with drm here has
been acked/reviewd by all the relevant people and merging it would imo
greatly help in wiring up all the other loose ends.

Cheers, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: broken nouveau dependency on power supply

[David Airlie]

 
 Ok, not that trivial...
 
 The problem is more like POWER_SUPPLY should be a bool, not a
 tristate.
 
 If you think about it: you don't want things like nouveau to depend
 on a
 random subsystem like that, people will never get it. In fact,
 POWER_SUPPLY provides empty inline stubs when not enabled, so that's
 really designed to not have depends...
 
 However that -cannot- work if POWER_SUPPLY is modular and the drivers
 who use it are not. The only fixes here that make sense I can think
 of
 that don't also involve Kconfig horrors are:
 
  - Ugly: in power_supply.h, use the extern variant if
 
   defined(CONFIG_POWER_SUPPLY) ||
(defined(CONFIG_POWER_SUPPLY_MODULE)  defined(MODULE))
 
 IE. use the stub if power supply is a module and what is being built
 is
 built-in. Of course that's not only ugly, it somewhat sucks from a
 user
 perspective as the subsystem now exists but can't be used by some
 drivers...
 
  - Better: Just make the bloody thing a bool :-) The power supply
 framework itself is small enough, just make it a boolean option and
 avoid the problem entirely. The actual power supply sub drivers can
 remain modular of course.

We can just do select POWER_SUPPLY.

Yes it reduces the option range for some stupid corner case but really I don't 
care, removing features from the kernel that a driver depends on is just 
leading to insane state combination and QA problems.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: disable ppgtt on snb when dmar is enabled

[Daniel Vetter]

Totally unexpected that this regressed. Luckily it sounds like we just
need to have dmar disable on the igfx, not the entire system. At least
that's what a few days of testing between Tony Vroon and me indicates.

Reported-by: Tony Vroon t...@linx.net
Cc: Tony Vroon t...@linx.net
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43024
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/char/agp/intel-gtt.c|1 -
 drivers/gpu/drm/i915/i915_dma.c |   17 -
 drivers/gpu/drm/i915/i915_drv.c |4 ++--
 drivers/gpu/drm/i915/i915_drv.h |2 +-
 include/drm/intel-gtt.h |4 
 5 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 7e223a2..e086fa5 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1204,7 +1204,6 @@ static inline int needs_idle_maps(void)
 {
 #ifdef CONFIG_INTEL_IOMMU
const unsigned short gpu_devid = intel_private.pcidev-device;
-   extern int intel_iommu_gfx_mapped;
 
/* Query intel_iommu to see if we need the workaround. Presumably that
 * was loaded first.
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4636391..ee06241 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1189,6 +1189,21 @@ static bool i915_switcheroo_can_switch(struct pci_dev 
*pdev)
return can_switch;
 }
 
+static bool
+intel_enable_ppgtt(struct drm_device *dev)
+{
+   if (i915_enable_ppgtt = 0)
+   return i915_enable_ppgtt;
+
+#ifdef CONFIG_INTEL_IOMMU
+   /* Disable ppgtt on SNB if VT-d is on. */
+   if (INTEL_INFO(dev)-gen == 6  intel_iommu_gfx_mapped)
+   return false;
+#endif
+
+   return true;
+}
+
 static int i915_load_gem_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -1203,7 +1218,7 @@ static int i915_load_gem_init(struct drm_device *dev)
drm_mm_init(dev_priv-mm.stolen, 0, prealloc_size);
 
mutex_lock(dev-struct_mutex);
-   if (i915_enable_ppgtt  HAS_ALIASING_PPGTT(dev)) {
+   if (intel_enable_ppgtt(dev)  HAS_ALIASING_PPGTT(dev)) {
/* PPGTT pdes are stolen from global gtt ptes, so shrink the
 * aperture accordingly when using aliasing ppgtt. */
gtt_size -= I915_PPGTT_PD_ENTRIES*PAGE_SIZE;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0efc02e..c65907e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -109,8 +109,8 @@ MODULE_PARM_DESC(enable_hangcheck,
WARNING: Disabling this can cause system wide hangs. 
(default: true));
 
-bool i915_enable_ppgtt __read_mostly = 1;
-module_param_named(i915_enable_ppgtt, i915_enable_ppgtt, bool, 0600);
+int i915_enable_ppgtt __read_mostly = -1;
+module_param_named(i915_enable_ppgtt, i915_enable_ppgtt, int, 0600);
 MODULE_PARM_DESC(i915_enable_ppgtt,
Enable PPGTT (default: true));
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b617cd5..1c8c440 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1088,7 +1088,7 @@ extern int i915_vbt_sdvo_panel_type __read_mostly;
 extern int i915_enable_rc6 __read_mostly;
 extern int i915_enable_fbc __read_mostly;
 extern bool i915_enable_hangcheck __read_mostly;
-extern bool i915_enable_ppgtt __read_mostly;
+extern int i915_enable_ppgtt __read_mostly;
 
 extern int i915_suspend(struct drm_device *dev, pm_message_t state);
 extern int i915_resume(struct drm_device *dev);
diff --git a/include/drm/intel-gtt.h b/include/drm/intel-gtt.h
index 0a0001b..923afb5 100644
--- a/include/drm/intel-gtt.h
+++ b/include/drm/intel-gtt.h
@@ -44,4 +44,8 @@ void intel_gtt_insert_pages(unsigned int first_entry, 
unsigned int num_entries,
 /* flag for GFDT type */
 #define AGP_USER_CACHED_MEMORY_GFDT (1  3)
 
+#ifdef CONFIG_INTEL_IOMMU
+extern int intel_iommu_gfx_mapped;
+#endif
+
 #endif
-- 
1.7.7.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: disable ppgtt on snb when dmar is enabled

[Chris Wilson]

On Mon,  2 Apr 2012 10:08:35 +0200, Daniel Vetter daniel.vet...@ffwll.ch 
wrote:
 Totally unexpected that this regressed. Luckily it sounds like we just
 need to have dmar disable on the igfx, not the entire system. At least
 that's what a few days of testing between Tony Vroon and me indicates.
 
 Reported-by: Tony Vroon t...@linx.net
 Cc: Tony Vroon t...@linx.net
 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43024
 Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch

Patch itself looks sane,

Acked-by: Chris Wilson ch...@chris-wilson.co.uk

-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: broken nouveau dependency on power supply

[Benjamin Herrenschmidt]

On Mon, 2012-04-02 at 05:00 -0400, David Airlie wrote:
   - Better: Just make the bloody thing a bool :-) The power supply
  framework itself is small enough, just make it a boolean option and
  avoid the problem entirely. The actual power supply sub drivers can
  remain modular of course.
 
 We can just do select POWER_SUPPLY.

Well, select'ing otherwise user configurable options was still frowned
on last we discussed that... and it makes the whole inline stubs in
power_supply.h totally pointless :-)

 Yes it reduces the option range for some stupid corner case but really
 I don't care, removing features from the kernel that a driver depends
 on is just leading to insane state combination and QA problems.

Well, the power supply stuff only works if you have a backend for it,
which not all platforms are, and it's fairly safe to assume AC whenever
it's not actually supported.

(Talking of which, we should be able to do a PowerBook backend
reasonably easily).

I don't care which solution you guys end up choosing though, just fix
it :-)

Cheers,
Ben.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] exynos: add exynos drm support

[Inki Dae]

this patch adds libdrm_exynos helper layer that inclues some intefaces
for exynos specific gem and virtual display driver and also adds exynos
module name to modtest and vbltest.

this patch is based on a link below:
git://anongit.freedesktop.org/mesa/drm
commit id: e057a56448e2e785f74bc13dbd6ead8572ebed91

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 Makefile.am|6 +-
 configure.ac   |   13 ++
 exynos/Makefile.am |   22 +++
 exynos/exynos_drm.c|  324 
 exynos/exynos_drm.h|  127 +
 exynos/exynos_drmif.h  |   60 
 exynos/libdrm_exynos.pc.in |   11 ++
 tests/modetest/modetest.c  |2 +-
 tests/vbltest/vbltest.c|2 +-
 9 files changed, 564 insertions(+), 3 deletions(-)
 create mode 100644 exynos/Makefile.am
 create mode 100644 exynos/exynos_drm.c
 create mode 100644 exynos/exynos_drm.h
 create mode 100644 exynos/exynos_drmif.h
 create mode 100644 exynos/libdrm_exynos.pc.in

diff --git a/Makefile.am b/Makefile.am
index 4f625a1..256a8cc 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -45,7 +45,11 @@ if HAVE_OMAP
 OMAP_SUBDIR = omap
 endif
 
-SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) tests include
+if HAVE_EXYNOS
+EXYNOS_SUBDIR = exynos
+endif
+
+SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) tests include
 
 libdrm_la_LTLIBRARIES = libdrm.la
 libdrm_ladir = $(libdir)
diff --git a/configure.ac b/configure.ac
index 1ba7eba..ae84817 100644
--- a/configure.ac
+++ b/configure.ac
@@ -88,6 +88,11 @@ AC_ARG_ENABLE(omap-experimental-api,
  [Enable support for OMAP's experimental API (default: disabled)]),
  [OMAP=$enableval], [OMAP=no])
 
+AC_ARG_ENABLE(exynos-experimental-api,
+ AS_HELP_STRING([--enable-exynos-experimental-api],
+ [Enable support for EXYNOS's experimental API (default: 
disabled)]),
+ [EXYNOS=$enableval], [EXYNOS=no])
+
 dnl ===
 dnl check compiler flags
 AC_DEFUN([LIBDRM_CC_TRY_FLAG], [
@@ -191,6 +196,11 @@ if test x$OMAP = xyes; then
AC_DEFINE(HAVE_OMAP, 1, [Have OMAP support])
 fi
 
+AM_CONDITIONAL(HAVE_EXYNOS, [test x$EXYNOS = xyes])
+if test x$EXYNOS = xyes; then
+   AC_DEFINE(HAVE_EXYNOS, 1, [Have EXYNOS support])
+fi
+
 PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
 if test x$HAVE_CAIRO = xyes; then
AC_DEFINE(HAVE_CAIRO, 1, [Have cairo support])
@@ -302,6 +312,8 @@ AC_CONFIG_FILES([
nouveau/libdrm_nouveau.pc
omap/Makefile
omap/libdrm_omap.pc
+   exynos/Makefile
+   exynos/libdrm_exynos.pc
tests/Makefile
tests/modeprint/Makefile
tests/modetest/Makefile
@@ -322,4 +334,5 @@ echo   vmwgfx API $VMWGFX
 echo   Radeon API $RADEON
 echo   Nouveau API$NOUVEAU
 echo   OMAP API   $OMAP
+echo   EXYNOS API $EXYNOS
 echo 
diff --git a/exynos/Makefile.am b/exynos/Makefile.am
new file mode 100644
index 000..e782d34
--- /dev/null
+++ b/exynos/Makefile.am
@@ -0,0 +1,22 @@
+AM_CFLAGS = \
+   $(WARN_CFLAGS) \
+   -I$(top_srcdir) \
+   -I$(top_srcdir)/exynos \
+   $(PTHREADSTUBS_CFLAGS) \
+   -I$(top_srcdir)/include/drm
+
+libdrm_exynos_la_LTLIBRARIES = libdrm_exynos.la
+libdrm_exynos_ladir = $(libdir)
+libdrm_exynos_la_LDFLAGS = -version-number 1:0:0 -no-undefined
+libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
+
+libdrm_exynos_la_SOURCES = exynos_drm.c
+
+libdrm_exynoscommonincludedir = ${includedir}/exynos
+libdrm_exynoscommoninclude_HEADERS = exynos_drm.h
+
+libdrm_exynosincludedir = ${includedir}/libdrm
+libdrm_exynosinclude_HEADERS = exynos_drmif.h
+
+pkgconfigdir = @pkgconfigdir@
+pkgconfig_DATA = libdrm_exynos.pc
diff --git a/exynos/exynos_drm.c b/exynos/exynos_drm.c
new file mode 100644
index 000..778321a
--- /dev/null
+++ b/exynos/exynos_drm.c
@@ -0,0 +1,324 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co., Ltd.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * 

Re: Linux 3.4-rc1

[Alex Deucher]

On Sun, Apr 1, 2012 at 11:34 AM, Rob Clark rob.cl...@linaro.org wrote:
 On Sat, Mar 31, 2012 at 6:58 PM, Linus Torvalds
 torva...@linux-foundation.org wrote:
  - drm dma-buf prime support. Dave Airlie sent me the pull request but
 didn't push very hard for it, it's in my ok, I can still pull it for
 3.4 if individual DRM driver people tell me that it will make their
 lives easier. So this is in limbo - I have nothing against it, but I
 won't pull unless I get a few people say yes, please.

 yes, please :-)

 Note that the core drm dma-buf/prime support has already been reviewed
 by a lot of folks, and tested with a few different drivers (exynos,
 omapdrm, i915, nouveau, udl) with some driver support that could be
 pushed for 3.5 cycle if the core support makes it in for 3.4 cycle.

Please.  It's the first step in making hybrid laptops work properly in Linux.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/prime: expose capability flags for userspace.

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

This lets the kernel tell userspace if the device supports prime
import/export.

This is useful for -modesetting at least, but would be nice for other
drivers.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/drm_ioctl.c |4 
 include/drm/drm.h   |4 
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index cf85155..64a62c6 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -283,6 +283,10 @@ int drm_getcap(struct drm_device *dev, void *data, struct 
drm_file *file_priv)
case DRM_CAP_DUMB_PREFER_SHADOW:
req-value = dev-mode_config.prefer_shadow;
break;
+   case DRM_CAP_PRIME:
+   req-value |= dev-driver-prime_fd_to_handle ? 
DRM_PRIME_CAP_IMPORT : 0;
+   req-value |= dev-driver-prime_handle_to_fd ? 
DRM_PRIME_CAP_EXPORT : 0;
+   break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 64ff02d..34d6335 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -775,6 +775,10 @@ struct drm_event_vblank {
 #define DRM_CAP_VBLANK_HIGH_CRTC 0x2
 #define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
 #define DRM_CAP_DUMB_PREFER_SHADOW 0x4
+#define DRM_CAP_PRIME 0x5
+
+#define DRM_PRIME_CAP_IMPORT 0x1
+#define DRM_PRIME_CAP_EXPORT 0x2
 
 /* typedef area */
 #ifndef __KERNEL__
-- 
1.7.7.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42920] Radeon with KMS and UMA works only up to 128MB

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=42920





--- Comment #8 from j.fi...@gmail.com  2012-04-02 13:58:16 ---
The problem is solved! I forgot I have a custom dsdt.hex, created with small
amount of UMA memory. Removing the custom dsdt.hex solves the problem:

[6.976583] [drm] Initialized drm 1.1.0 20060810
[7.127923] [drm] radeon defaulting to kernel modesetting.
[7.127925] [drm] radeon kernel modesetting enabled.
[7.127974] radeon :01:05.0: setting latency timer to 64
[7.128093] [drm] initializing kernel modesetting (RS880 0x1002:0x9715
0x1043:0x843E).
[7.128108] [drm] register mmio base: 0xFEBE
[7.128109] [drm] register mmio size: 65536
[7.128705] [drm] CONFIG_MEMSIZE: 0x4000
[7.128708] radeon :01:05.0: VRAM: 1024M 0xC000 -
0x (1024M used)
[7.128710] radeon :01:05.0: GTT: 512M 0xA000 -
0xBFFF
[7.132802] [drm] Detected VRAM RAM=1024M, BAR=256M
[7.132805] [drm] RAM width 32bits DDR
[7.132896] [drm] radeon: 1024M of VRAM memory ready
[7.132897] [drm] radeon: 512M of GTT memory ready.
[7.132910] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[7.132911] [drm] Driver supports precise vblank timestamp query.
[7.132932] [drm] radeon: irq initialized.
[7.132935] [drm] GART: num cpu pages 131072, num gpu pages 131072
[7.133487] [drm] radeon: ib pool ready.
[7.133551] [drm] Loading RS780 Microcode
[7.245054] [drm] PCIE GART of 512M enabled (table at 0xC004).
[7.245117] radeon :01:05.0: WB enabled
[7.245119] [drm] fence driver on ring 0 use gpu addr 0xac00 and cpu
addr 0x8804156aec00
[7.277226] [drm] ring test on 0 succeeded in 1 usecs
[7.277296] [drm] ib test on ring 0 succeeded in 0 usecs
[7.582928] [drm] radeon: blit 1024 bo moves of 1024 kB from 2 to 4 in 305
ms, throughput: 27496 Mb/s or 3437 MB/s
[7.888011] [drm] radeon: blit 1024 bo moves of 1024 kB from 4 to 2 in 305
ms, throughput: 27496 Mb/s or 3437 MB/s
[7.888368] [drm] Radeon Display Connectors
[7.888370] [drm] Connector 0:
[7.888371] [drm]   VGA
[7.888372] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c
0x7e4c
[7.888373] [drm]   Encoders:
[7.888374] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[7.888375] [drm] Connector 1:
[7.888376] [drm]   HDMI-A
[7.888377] [drm]   HPD3
[7.888378] [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c
0x7e5c
[7.888380] [drm]   Encoders:
[7.888381] [drm] DFP3: INTERNAL_KLDSCP_LVTMA
[7.888404] [drm] radeon: power management initialized
[7.961690] [drm] fb mappable at 0xD0142000
[7.961692] [drm] vram apper at 0xD000
[7.961693] [drm] size 3932160
[7.961694] [drm] fb depth is 24
[7.961695] [drm]pitch is 5120
[7.961753] fbcon: radeondrmfb (fb0) is primary device
[7.984815] fb0: radeondrmfb frame buffer device
[7.984816] drm: registered panic notifier
[7.984820] [drm] Initialized radeon 2.13.0 20080528 for :01:05.0 on
minor 0

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42920] Radeon with KMS and UMA works only up to 128MB

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=42920


j.fi...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WILL_NOT_FIX




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48197] New: DVI monitor connected to an Ati x1550 on standard resolution blinks.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48197

 Bug #: 48197
   Summary: DVI monitor connected to an Ati x1550 on standard
resolution blinks.
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: ter...@gmail.com


Created attachment 59380
  -- https://bugs.freedesktop.org/attachment.cgi?id=59380
dmesg from fedora 16

I have an Ati radeon x1550, and connected to that a DVI monitor (and another to
the VGA, but this bug is present also when only the DVI monitor is connected)
This bug appears in every distribution and kernel I tried, the last one is
fedora 16, but I tried debian 6 too and Archlinux with the latest kernel.
Description of problem:
DVI screen, if on standard resolution (1680x1050) blinks from the tty to the
Gnome dekstop, and especially when something like Firefox is made fullscreen:
I recorded a video to explain this better:
https://www.youtube.com/watch?v=8Tcjb6p0Yi4

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48197] DVI monitor connected to an Ati x1550 on standard resolution blinks.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48197

--- Comment #1 from ter...@gmail.com 2012-04-02 07:40:17 PDT ---
Created attachment 59381
  -- https://bugs.freedesktop.org/attachment.cgi?id=59381
Xorg log

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48197] DVI monitor connected to an Ati x1550 on standard resolution blinks.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48197

--- Comment #2 from Alex Deucher ag...@yahoo.com 2012-04-02 07:46:28 PDT ---
Does booting with radeon.disp_priority=2 on the kernel command line in grub
help?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48197] DVI monitor connected to an Ati x1550 on standard resolution blinks.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48197

--- Comment #3 from ter...@gmail.com 2012-04-02 07:57:35 PDT ---
It doesn't help at all.

(In reply to comment #2)
 Does booting with radeon.disp_priority=2 on the kernel command line in grub
 help?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48197] DVI monitor connected to an Ati x1550 on standard resolution blinks.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48197

--- Comment #4 from Alex Deucher ag...@yahoo.com 2012-04-02 08:11:53 PDT ---
Does it only blink on the 1680x1050 mode or all modes on the DVI monitor?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Process to merge Openchrome work

[James Simmons]

Hello!!

This last year the Openchrome support for the VIA chipsets has 
come along way from being in a state of decay. The plan is to release
a Xorg driver June 1 that will have support for the KMS as well as UMS.
The goal is to have this xorg driver out in the wild before the kernel
side is ready so that the migration to the new kernel drivers will be
as painless as possible. My hope is to merge the kernel tree for public 
use for Christmas.
This brings up the question I had with the other project leader.
How does one go about merging the tree? What makes this more complex is
that a old via drm kernel driver already exist. Do we just drop in the 
code into the staging area? Does it have to be piece meal? Does a rename 
of the driver need to happen? What would you recommend ?

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48197] DVI monitor connected to an Ati x1550 on standard resolution blinks.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48197

--- Comment #5 from ter...@gmail.com 2012-04-02 08:25:14 PDT ---
Only in the 1680x1050 mode that way.
But it might happen very rarely on 1480x900. 
I'm not sure about this though, it didn't happen recently.
(In reply to comment #4)
 Does it only blink on the 1680x1050 mode or all modes on the DVI monitor?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC] drm: support for rotated scanout

[Rob Clark]

On Sat, Mar 31, 2012 at 4:09 PM, Ville Syrjälä syrj...@sci.fi wrote:
 On Fri, Mar 30, 2012 at 05:59:32PM -0500, Rob Clark wrote:
 From: Rob Clark r...@ti.com

 For drivers that can support rotated scanout, the extra parameter
 checking in drm-core, while nice, tends to get confused.  To solve
 this drivers can set the crtc or plane invert_dimensions field so
 that the dimension checking takes into account the rotation that
 the driver is performing.
 ---
 Note: RFC still mainly because I've only tested the CRTC rotation so
 far.. still need to write some test code for plane rotation.

  drivers/gpu/drm/drm_crtc.c |   50 
 +--
  include/drm/drm_crtc.h     |    9 
  2 files changed, 43 insertions(+), 16 deletions(-)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index 0dff444..261c9bd 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -375,6 +375,7 @@ int drm_crtc_init(struct drm_device *dev, struct 
 drm_crtc *crtc,

       crtc-dev = dev;
       crtc-funcs = funcs;
 +     crtc-invert_dimensions = false;

       mutex_lock(dev-mode_config.mutex);

 @@ -609,6 +610,7 @@ int drm_plane_init(struct drm_device *dev, struct 
 drm_plane *plane,
       plane-base.properties = plane-properties;
       plane-dev = dev;
       plane-funcs = funcs;
 +     plane-invert_dimensions = false;
       plane-format_types = kmalloc(sizeof(uint32_t) * format_count,
                                     GFP_KERNEL);
       if (!plane-format_types) {
 @@ -1758,6 +1760,9 @@ int drm_mode_setplane(struct drm_device *dev, void 
 *data,
       fb_width = fb-width  16;
       fb_height = fb-height  16;

 +     if (plane-invert_dimensions)
 +             swap(fb_width, fb_height);
 +

 In my opinion the only sane way to specify this stuff is that
 the source coordinates are not transformed in any way.

fwiw, it might be a bit odd that in one case I swapped fb dimensions,
and in the other crtc dimensions..  although it was just laziness
(there were fewer param's to swap that way ;-))

 So you fetch the data from the fb based on the source coordinates, then
 apply all plane transformations (if any), and then apply all CRTC
 transformations (if any).

fwiw, in my case planes and CRTCs are rotated independently.. ie.
rotating the CRTC doesn't automatically rotate the planes.  But I
include invert_dimensions flag in both drm_crtc and drm_plane so
drivers for hw that works differently can do whatever is appropriate


       /* Make sure source coordinates are inside the fb. */
       if (plane_req-src_w  fb_width ||
           plane_req-src_x  fb_width - plane_req-src_w ||
 @@ -1856,6 +1861,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void 
 *data,
       DRM_DEBUG_KMS([CRTC:%d]\n, crtc-base.id);

       if (crtc_req-mode_valid) {
 +             int hdisplay, vdisplay;
               /* If we have a mode we need a framebuffer. */
               /* If we pass -1, set the mode with the currently bound fb */
               if (crtc_req-fb_id == -1) {
 @@ -1891,14 +1897,20 @@ int drm_mode_setcrtc(struct drm_device *dev, void 
 *data,

               drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);

 -             if (mode-hdisplay  fb-width ||
 -                 mode-vdisplay  fb-height ||
 -                 crtc_req-x  fb-width - mode-hdisplay ||
 -                 crtc_req-y  fb-height - mode-vdisplay) {
 -                     DRM_DEBUG_KMS(Invalid CRTC viewport %ux%u+%u+%u for 
 fb size %ux%u.\n,
 -                                   mode-hdisplay, mode-vdisplay,
 -                                   crtc_req-x, crtc_req-y,
 -                                   fb-width, fb-height);
 +             hdisplay = mode-hdisplay;
 +             vdisplay = mode-vdisplay;
 +
 +             if (crtc-invert_dimensions)
 +                     swap(hdisplay, vdisplay);
 +
 +             if (hdisplay  fb-width ||
 +                 vdisplay  fb-height ||
 +                 crtc_req-x  fb-width - hdisplay ||
 +                 crtc_req-y  fb-height - vdisplay) {
 +                     DRM_DEBUG_KMS(Invalid fb size %ux%u for CRTC viewport 
 %ux%u+%d+%d%s.\n,
 +                                   fb-width, fb-height,
 +                                   hdisplay, vdisplay, crtc_req-x, 
 crtc_req-y,
 +                                   crtc-invert_dimensions ?  (inverted) 
 : );

 I would perhaps just stick more details about the transformations into
 drm_crtc, but we will anyway require a better mode setting API. So
 perhaps this is an OK intermediate solution.


I was trying to avoid putting full matrix transformation in the kernel ;-)

but at least the hw I'm familiar with is only doing simple isometric
transformations in scanout (ie. multiples of 90 degress and/or
horiz/vert mirroring).  Anything more complex would require a shadow
buffer and gpu, which is (I think) better to do in userspace.  But I
don't know if this is sufficient for other drivers or 

[Bug 48203] New: texture problem with KMS

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48203

 Bug #: 48203
   Summary: texture problem with KMS
Classification: Unclassified
   Product: Mesa
   Version: 7.11
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: bottle...@icf.org.ru


there is a game - oolite, after switching to KMS there is texture problesm
started like
http://gallery.icf.org.ru/icfteam/GHhost/GHhost_screens/screenshot_027.png.html
and
http://gallery.icf.org.ru/icfteam/GHhost/GHhost_screens/screenshot0.png.html,
all othere works fine and game is playable,

hw 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250
[Mobility FireGL 9000] (rev 02)

xorg log:
[484367.551] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
[484367.551] (II) [KMS] Kernel modesetting enabled.
[484367.551] (**) RADEON(0): Depth 24, (--) framebuffer bpp 32
[484367.551] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp
pixmaps)
[484367.551] (==) RADEON(0): Default visual is TrueColor
[484367.551] (**) RADEON(0): Option EnablePageFlip on
[484367.551] (**) RADEON(0): Option AccelDFS on
[484367.551] (**) RADEON(0): Option ColorTiling on
[484367.551] (**) RADEON(0): Option SubPixelOrder NONE
[484367.551] (**) RADEON(0): Option EXAVSync off
[484367.551] (**) RADEON(0): Option EXAPixmaps on
[484367.551] (**) RADEON(0): Option SwapbuffersWait on
[484367.551] (==) RADEON(0): RGB weight 888
[484367.551] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
[484367.551] (--) RADEON(0): Chipset: ATI Radeon Mobility 9000 (M9) Lf (AGP)
(ChipID = 0x4c66)
[484367.551] (II) RADEON(0): AGP card detected
[484367.551] drmOpenDevice: node name is /dev/dri/card0
[484367.551] drmOpenDevice: open result is 9, (OK)
[484367.551] drmOpenByBusid: Searching for BusID pci::01:00.0
[484367.551] drmOpenDevice: node name is /dev/dri/card0
[484367.551] drmOpenDevice: open result is 9, (OK)
[484367.551] drmOpenByBusid: drmOpenMinor returns 9
[484367.551] drmOpenByBusid: Interface 1.4 failed, trying 1.1
[484367.551] drmOpenByBusid: drmGetBusid reports pci::01:00.0
[484367.552] (II) Loading sub module exa
[484367.552] (II) LoadModule: exa
[484367.552] (II) Loading /usr/lib/xorg/modules/libexa.so
[484367.552] (II) Module exa: vendor=X.Org Foundation
[484367.552]compiled for 1.10.4, module version = 2.5.0
[484367.552]ABI class: X.Org Video Driver, version 10.0
[484367.552] (II) RADEON(0): KMS Color Tiling: enabled
[484367.552] (II) RADEON(0): SwapBuffers wait for vsync: enabled
[484367.560] (II) RADEON(0): Output VGA-0 using monitor section LCD_monitor
[484367.560] (II) RADEON(0): Output LVDS has no monitor section
[484367.566] (II) RADEON(0): Output S-video has no monitor section
[484367.574] (II) RADEON(0): EDID for output VGA-0
[484367.574] (II) RADEON(0): EDID for output LVDS
[484367.574] (II) RADEON(0): Printing probed modes for output LVDS
[484367.574] (II) RADEON(0): Modeline 1024x768x60.4   65.00  1024 1040 1176
1336  768 769 775 805 (48.7 kHz)
[484367.574] (II) RADEON(0): Modeline 800x600x59.9   38.25  800 832 912 1024 
600 603 607 624 -hsync +vsync (37.4 kHz)
[484367.574] (II) RADEON(0): Modeline 848x480x59.7   31.50  848 872 952 1056 
480 483 493 500 -hsync +vsync (29.8 kHz)
[484367.574] (II) RADEON(0): Modeline 720x480x59.7   26.75  720 744 808 896 
480 483 493 500 -hsync +vsync (29.9 kHz)
[484367.574] (II) RADEON(0): Modeline 640x480x59.4   23.75  640 664 720 800 
480 483 487 500 -hsync +vsync (29.7 kHz)
[484367.580] (II) RADEON(0): EDID for output S-video
[484367.580] (II) RADEON(0): Output VGA-0 disconnected
[484367.580] (II) RADEON(0): Output LVDS connected
[484367.580] (II) RADEON(0): Output S-video disconnected
[484367.580] (II) RADEON(0): Using user preference for initial modes
[484367.580] (II) RADEON(0): Output LVDS using initial mode 1024x768
[484367.580] (II) RADEON(0): Using default gamma of (1.0, 1.0, 1.0) unless
otherwise stated.
[484367.580] (II) RADEON(0): mem size init: gart size :fdff000 vram size:
s:400 visible:3cc
[484367.580] (II) RADEON(0): EXA: Driver will allow EXA pixmaps in VRAM
[484367.580] (++) RADEON(0): DPI set to (106, 106)
[484367.580] (II) Loading sub module fb
[484367.580] (II) LoadModule: fb
[484367.580] (II) Loading /usr/lib/xorg/modules/libfb.so
[484367.580] (II) Module fb: vendor=X.Org Foundation
[484367.580]compiled for 1.10.4, module version = 1.0.0
[484367.581]ABI class: X.Org ANSI C Emulation, version 0.4
[484367.581] (II) Loading sub module ramdac
[484367.581] (II) LoadModule: ramdac
[484367.581] (II) Module ramdac already built-in
[484367.581] (--) Depth 24 pixmap format is 32 bpp
[484367.581] (WW) RADEON(0): You need a newer kernel for sync extension
[484367.581] (II) RADEON(0): [DRI2] Setup complete
[484367.581] (II) RADEON(0): [DRI2]   DRI 

[Bug 46724] radeon_drm_winsys compile fail with libdrm in non standard directory

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=46724

va...@gmx.de changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #3 from va...@gmx.de 2012-04-02 10:07:21 PDT ---
This seems fixed now. 
git version 42bc0b9b9dc31a15c08d409d14d25ccf19501255
compiles without any errors.

Thanks!

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC] drm: support for rotated scanout

[Ville Syrjälä]

On Mon, Apr 02, 2012 at 10:31:47AM -0500, Rob Clark wrote:
 On Sat, Mar 31, 2012 at 4:09 PM, Ville Syrjälä syrj...@sci.fi wrote:
  On Fri, Mar 30, 2012 at 05:59:32PM -0500, Rob Clark wrote:
  From: Rob Clark r...@ti.com
 
  For drivers that can support rotated scanout, the extra parameter
  checking in drm-core, while nice, tends to get confused.  To solve
  this drivers can set the crtc or plane invert_dimensions field so
  that the dimension checking takes into account the rotation that
  the driver is performing.
  ---
  Note: RFC still mainly because I've only tested the CRTC rotation so
  far.. still need to write some test code for plane rotation.
 
   drivers/gpu/drm/drm_crtc.c |   50 
  +--
   include/drm/drm_crtc.h     |    9 
   2 files changed, 43 insertions(+), 16 deletions(-)
 
  diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
  index 0dff444..261c9bd 100644
  --- a/drivers/gpu/drm/drm_crtc.c
  +++ b/drivers/gpu/drm/drm_crtc.c
  @@ -375,6 +375,7 @@ int drm_crtc_init(struct drm_device *dev, struct 
  drm_crtc *crtc,
 
        crtc-dev = dev;
        crtc-funcs = funcs;
  +     crtc-invert_dimensions = false;
 
        mutex_lock(dev-mode_config.mutex);
 
  @@ -609,6 +610,7 @@ int drm_plane_init(struct drm_device *dev, struct 
  drm_plane *plane,
        plane-base.properties = plane-properties;
        plane-dev = dev;
        plane-funcs = funcs;
  +     plane-invert_dimensions = false;
        plane-format_types = kmalloc(sizeof(uint32_t) * format_count,
                                      GFP_KERNEL);
        if (!plane-format_types) {
  @@ -1758,6 +1760,9 @@ int drm_mode_setplane(struct drm_device *dev, void 
  *data,
        fb_width = fb-width  16;
        fb_height = fb-height  16;
 
  +     if (plane-invert_dimensions)
  +             swap(fb_width, fb_height);
  +
 
  In my opinion the only sane way to specify this stuff is that
  the source coordinates are not transformed in any way.
 
 fwiw, it might be a bit odd that in one case I swapped fb dimensions,
 and in the other crtc dimensions..  although it was just laziness
 (there were fewer param's to swap that way ;-))

Not sure if you got my point, which was that w/ plane rotation the
src coordinate check should be correct as is. Instead you should
apply the rotation when you clip/process the plane's crtc coordinates.

Since we don't clip the crtc coordinates in the common code (to allow
partially/fully offscreen planes), all the work ends up happening in
driver specific code.

  So you fetch the data from the fb based on the source coordinates, then
  apply all plane transformations (if any), and then apply all CRTC
  transformations (if any).
 
 fwiw, in my case planes and CRTCs are rotated independently.. ie.
 rotating the CRTC doesn't automatically rotate the planes.  But I
 include invert_dimensions flag in both drm_crtc and drm_plane so
 drivers for hw that works differently can do whatever is appropriate

I think you should rotate the planes according to the crtc rotation as
well. Otherwise the pipeline fb-plane-crtc-... doesn't make much
sense. If we would just deprecate the crtc='scanout engine' concept
this wouldn't be an issue, as you'd just have plane rotation all the
way.

I suppose another option would be to name your crtc rotation property to
something like crtc fb rotation to make it clear that it only applies
to the crtc scanout, and not any attached planes. Then we can still add a
real crtc rotation later. You could perhaps expose the rotation
capabilities of the actual display as crtc rotation. OTOH maybe that'd
be equally illogical as rotation that doesn't rotate.

        /* Make sure source coordinates are inside the fb. */
        if (plane_req-src_w  fb_width ||
            plane_req-src_x  fb_width - plane_req-src_w ||
  @@ -1856,6 +1861,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void 
  *data,
        DRM_DEBUG_KMS([CRTC:%d]\n, crtc-base.id);
 
        if (crtc_req-mode_valid) {
  +             int hdisplay, vdisplay;
                /* If we have a mode we need a framebuffer. */
                /* If we pass -1, set the mode with the currently bound fb */
                if (crtc_req-fb_id == -1) {
  @@ -1891,14 +1897,20 @@ int drm_mode_setcrtc(struct drm_device *dev, void 
  *data,
 
                drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
 
  -             if (mode-hdisplay  fb-width ||
  -                 mode-vdisplay  fb-height ||
  -                 crtc_req-x  fb-width - mode-hdisplay ||
  -                 crtc_req-y  fb-height - mode-vdisplay) {
  -                     DRM_DEBUG_KMS(Invalid CRTC viewport %ux%u+%u+%u for 
  fb size %ux%u.\n,
  -                                   mode-hdisplay, mode-vdisplay,
  -                                   crtc_req-x, crtc_req-y,
  -                                   fb-width, fb-height);
  +             hdisplay = mode-hdisplay;
  +             vdisplay = mode-vdisplay;

[3.4-rc1][Regression][intel] Resume from suspend to disk hangs on restoring backlight state

[Maciej Rutecki]

Last known good: 3.3
Bad kernel: 3.4-rc1
Subsystem: power management/suspend/dri(intel)

When I resume from suspend to disk then system hangs on this screen:
http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/DSC_5479.jpg

It does not help SysRq keys. Only I can force power off by hold power button.

Dmesg:
http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/dmesg-3.4-rc1.txt

Config:
http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/config-3.4.0-rc1
-- 
Maciej Rutecki
http://www.mrutecki.pl
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [3.4-rc1][Regression][intel] Resume from suspend to disk hangs on restoring backlight state

[Daniel Vetter]

On Mon, Apr 02, 2012 at 07:39:39PM +0200, Maciej Rutecki wrote:
 Last known good: 3.3
 Bad kernel: 3.4-rc1
 Subsystem: power management/suspend/dri(intel)
 
 When I resume from suspend to disk then system hangs on this screen:
 http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/DSC_5479.jpg
 
 It does not help SysRq keys. Only I can force power off by hold power button.
 
 Dmesg:
 http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/dmesg-3.4-rc1.txt
 
 Config:
 http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/config-3.4.0-rc1

Likely a known regression, ppgtt support broke hibernate because my code
doesn't restore the ppgtt page directory correctly in the thaw function.

Patch:
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixesid=55a254ac63a3ac1867d1501030e7fba69c7d4aeb

Please test whether this fixes your issue. You can also try adding
i915.i915_enable_ppgtt=0 to your kernel cmdline.

Thanks, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC] drm: support for rotated scanout

[Ville Syrjälä]

On Mon, Apr 02, 2012 at 08:26:14PM +0300, Ville Syrjälä wrote:
 On Mon, Apr 02, 2012 at 10:31:47AM -0500, Rob Clark wrote:
  On Sat, Mar 31, 2012 at 4:09 PM, Ville Syrjälä syrj...@sci.fi wrote:
   On Fri, Mar 30, 2012 at 05:59:32PM -0500, Rob Clark wrote:
   From: Rob Clark r...@ti.com
  
   For drivers that can support rotated scanout, the extra parameter
   checking in drm-core, while nice, tends to get confused.  To solve
   this drivers can set the crtc or plane invert_dimensions field so
   that the dimension checking takes into account the rotation that
   the driver is performing.
   ---
   Note: RFC still mainly because I've only tested the CRTC rotation so
   far.. still need to write some test code for plane rotation.
  
    drivers/gpu/drm/drm_crtc.c |   50 
   +--
    include/drm/drm_crtc.h     |    9 
    2 files changed, 43 insertions(+), 16 deletions(-)
  
   diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
   index 0dff444..261c9bd 100644
   --- a/drivers/gpu/drm/drm_crtc.c
   +++ b/drivers/gpu/drm/drm_crtc.c
   @@ -375,6 +375,7 @@ int drm_crtc_init(struct drm_device *dev, struct 
   drm_crtc *crtc,
  
         crtc-dev = dev;
         crtc-funcs = funcs;
   +     crtc-invert_dimensions = false;
  
         mutex_lock(dev-mode_config.mutex);
  
   @@ -609,6 +610,7 @@ int drm_plane_init(struct drm_device *dev, struct 
   drm_plane *plane,
         plane-base.properties = plane-properties;
         plane-dev = dev;
         plane-funcs = funcs;
   +     plane-invert_dimensions = false;
         plane-format_types = kmalloc(sizeof(uint32_t) * format_count,
                                       GFP_KERNEL);
         if (!plane-format_types) {
   @@ -1758,6 +1760,9 @@ int drm_mode_setplane(struct drm_device *dev, void 
   *data,
         fb_width = fb-width  16;
         fb_height = fb-height  16;
  
   +     if (plane-invert_dimensions)
   +             swap(fb_width, fb_height);
   +
  
   In my opinion the only sane way to specify this stuff is that
   the source coordinates are not transformed in any way.
  
  fwiw, it might be a bit odd that in one case I swapped fb dimensions,
  and in the other crtc dimensions..  although it was just laziness
  (there were fewer param's to swap that way ;-))
 
 Not sure if you got my point, which was that w/ plane rotation the
 src coordinate check should be correct as is. Instead you should
 apply the rotation when you clip/process the plane's crtc coordinates.
 
 Since we don't clip the crtc coordinates in the common code (to allow
 partially/fully offscreen planes), all the work ends up happening in
 driver specific code.

What I write doesn't actually match what I meant to write. I didn't
mean that you'd rotate the crtc coordinates prior to clipping.
What I meant is that you (probably) rotate the src coordinates in
the driver in order to do clipping and scaling factor calculations.

But in any case the bounds checking in the core code is OK, as the
src coordinates are specified in the orienation of the fb memory
layout.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [3.4-rc1][Regression][intel] Resume from suspend to disk hangs on restoring backlight state

[Maciej Rutecki]

On poniedziałek, 2 kwietnia 2012 o 19:54:02 Daniel Vetter wrote:
 On Mon, Apr 02, 2012 at 07:39:39PM +0200, Maciej Rutecki wrote:
  Last known good: 3.3
  Bad kernel: 3.4-rc1
  Subsystem: power management/suspend/dri(intel)
  
  When I resume from suspend to disk then system hangs on this screen:
  http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/DSC_5479.jpg
  
  It does not help SysRq keys. Only I can force power off by hold power
  button.
  
  Dmesg:
  http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/dmesg-3.4-rc1.t
  xt
  
  Config:
  http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/config-3.4.0-rc
  1
 
 Likely a known regression, ppgtt support broke hibernate because my code
 doesn't restore the ppgtt page directory correctly in the thaw function.
 
 Patch:
 http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixesid=
 55a254ac63a3ac1867d1501030e7fba69c7d4aeb
 
 Please test whether this fixes your issue. You can also try adding
 i915.i915_enable_ppgtt=0 to your kernel cmdline.
 
 Thanks, Daniel

Patch solves problem.

Now resume hangs later on another subsystem: wireless :D

Regards
-- 
Maciej Rutecki
http://www.mrutecki.pl
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [3.4-rc1][Regression][intel] Resume from suspend to disk hangs on restoring backlight state

[Daniel Vetter]

On Mon, Apr 02, 2012 at 09:00:11PM +0200, Maciej Rutecki wrote:
 On poniedziałek, 2 kwietnia 2012 o 19:54:02 Daniel Vetter wrote:
  On Mon, Apr 02, 2012 at 07:39:39PM +0200, Maciej Rutecki wrote:
   Last known good: 3.3
   Bad kernel: 3.4-rc1
   Subsystem: power management/suspend/dri(intel)
   
   When I resume from suspend to disk then system hangs on this screen:
   http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/DSC_5479.jpg
   
   It does not help SysRq keys. Only I can force power off by hold power
   button.
   
   Dmesg:
   http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/dmesg-3.4-rc1.t
   xt
   
   Config:
   http://mrutecki.pl/download/kernel/3.4-rc1/suspend_resume/config-3.4.0-rc
   1
  
  Likely a known regression, ppgtt support broke hibernate because my code
  doesn't restore the ppgtt page directory correctly in the thaw function.
  
  Patch:
  http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixesid=
  55a254ac63a3ac1867d1501030e7fba69c7d4aeb
  
  Please test whether this fixes your issue. You can also try adding
  i915.i915_enable_ppgtt=0 to your kernel cmdline.
  
  Thanks, Daniel
 
 Patch solves problem.
 
 Now resume hangs later on another subsystem: wireless :D

Woot, I'm off the hook ;-) Thanks for reporting this issue and testing the
patch.

Yours, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: enable semaphores on gen6 if dmar is not active

[Daniel Vetter]

Inspired by the recent ppgtt regression report, where switching of
dmar only for the gpu seems to fix things completely, I've looked
again at the semaphores+vt-d situation.

Contrary to my earlier testing a few months back my system is now
stable with dmar disabled for the igd, and not only when disabling
dmar completely.

So I'm rather hopeful that all our recent fixes for snb have changed
things for code and it's time to try enabling semaphores again. We've
also had issues with enabling semaphores which are not vt-d related,
but I guess these are all fixed by the autoreport-disabling and lazy
request fix. And there's only one way to find out whether there are
still other issues ...

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch

---

If no further vt-d regressions show up in the 3.4 cycle I plan to
merge this into -next for 3.5 (in a month or so). Comments about how
unfeasibly you deem this highly welcome.
-Daniel
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8e0b686..ac52433 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -849,9 +849,11 @@ intel_enable_semaphores(struct drm_device *dev)
if (i915_semaphores = 0)
return i915_semaphores;
 
-   /* Disable semaphores on SNB */
-   if (INTEL_INFO(dev)-gen == 6)
-   return 0;
+#ifdef CONFIG_INTEL_IOMMU
+   /* Disable semaphores on SNB if VT-d is on. */
+   if (INTEL_INFO(dev)-gen == 6  intel_iommu_gfx_mapped)
+   return false;
+#endif
 
return 1;
 }
-- 
1.7.7.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48131] Very large 2D texture is sometimes corrupted

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48131

--- Comment #3 from Benoit Jacob bja...@mozilla.com 2012-04-02 13:40:51 PDT 
---
Maybe, if there is a package for Ubuntu 11.10 that is safe and easy to install?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915: enable semaphores on gen6 if dmar is not active

[Andrew Lutomirski]

On Mon, Apr 2, 2012 at 11:48 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 Inspired by the recent ppgtt regression report, where switching of
 dmar only for the gpu seems to fix things completely, I've looked
 again at the semaphores+vt-d situation.

 Contrary to my earlier testing a few months back my system is now
 stable with dmar disabled for the igd, and not only when disabling
 dmar completely.

 So I'm rather hopeful that all our recent fixes for snb have changed
 things for code and it's time to try enabling semaphores again. We've
 also had issues with enabling semaphores which are not vt-d related,
 but I guess these are all fixed by the autoreport-disabling and lazy
 request fix. And there's only one way to find out whether there are
 still other issues ...

 Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch

 ---

 If no further vt-d regressions show up in the 3.4 cycle I plan to
 merge this into -next for 3.5 (in a month or so). Comments about how
 unfeasibly you deem this highly welcome.
 -Daniel
 ---
  drivers/gpu/drm/i915/i915_gem_execbuffer.c |    8 +---
  1 files changed, 5 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
 b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 index 8e0b686..ac52433 100644
 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 @@ -849,9 +849,11 @@ intel_enable_semaphores(struct drm_device *dev)
        if (i915_semaphores = 0)
                return i915_semaphores;

 -       /* Disable semaphores on SNB */
 -       if (INTEL_INFO(dev)-gen == 6)
 -               return 0;
 +#ifdef CONFIG_INTEL_IOMMU
 +       /* Disable semaphores on SNB if VT-d is on. */
 +       if (INTEL_INFO(dev)-gen == 6  intel_iommu_gfx_mapped)
 +               return false;

It might be nice to have a printk here giving instructions for how to work
around this.  For example:

i915: Disabling semaphores to work around a DMAR issue.  As an
alternative, boot with intel_iommu=igfx_off [or on, igfx_off, or
whatever it's supposed to be].

The documentation in kernel-parameters.txt is at best unclear to the
uninitiated.

--Andy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915: enable semaphores on gen6 if dmar is not active

[Daniel Vetter]

On Mon, Apr 02, 2012 at 01:45:39PM -0700, Andrew Lutomirski wrote:
 On Mon, Apr 2, 2012 at 11:48 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
  Inspired by the recent ppgtt regression report, where switching of
  dmar only for the gpu seems to fix things completely, I've looked
  again at the semaphores+vt-d situation.
 
  Contrary to my earlier testing a few months back my system is now
  stable with dmar disabled for the igd, and not only when disabling
  dmar completely.
 
  So I'm rather hopeful that all our recent fixes for snb have changed
  things for code and it's time to try enabling semaphores again. We've
  also had issues with enabling semaphores which are not vt-d related,
  but I guess these are all fixed by the autoreport-disabling and lazy
  request fix. And there's only one way to find out whether there are
  still other issues ...
 
  Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
 
  ---
 
  If no further vt-d regressions show up in the 3.4 cycle I plan to
  merge this into -next for 3.5 (in a month or so). Comments about how
  unfeasibly you deem this highly welcome.
  -Daniel
  ---
   drivers/gpu/drm/i915/i915_gem_execbuffer.c |    8 +---
   1 files changed, 5 insertions(+), 3 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
  b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
  index 8e0b686..ac52433 100644
  --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
  +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
  @@ -849,9 +849,11 @@ intel_enable_semaphores(struct drm_device *dev)
         if (i915_semaphores = 0)
                 return i915_semaphores;
 
  -       /* Disable semaphores on SNB */
  -       if (INTEL_INFO(dev)-gen == 6)
  -               return 0;
  +#ifdef CONFIG_INTEL_IOMMU
  +       /* Disable semaphores on SNB if VT-d is on. */
  +       if (INTEL_INFO(dev)-gen == 6  intel_iommu_gfx_mapped)
  +               return false;
 
 It might be nice to have a printk here giving instructions for how to work
 around this.  For example:
 
 i915: Disabling semaphores to work around a DMAR issue.  As an
 alternative, boot with intel_iommu=igfx_off [or on, igfx_off, or
 whatever it's supposed to be].
 
 The documentation in kernel-parameters.txt is at best unclear to the
 uninitiated.

If this really does work, I'll look into this. Atm it's still unclear
where to exactly put the plain, we need to annoy internal hardware people
to analyze this. Once we have enough evidence that the combination of gpu
with various features enable plus VT-d just doesn't seem to work reliably.

So can you check whether things do indeed work with this patch, atop
kernel 3.4-rc1? Iirc you've been the one with the most trouble when
semaphores are enabled ...

Yours, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48131] Very large 2D texture is sometimes corrupted

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48131

--- Comment #4 from Robert Hooker (Sarvatt) sarv...@gmail.com 2012-04-02 
14:35:38 PDT ---
The safest way would be to just try a 12.04 beta 2 or newer livecd out, it has
8.0.2

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48215] New: [NV11] Display constantly switches on and off roughly every 10 seconds.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48215

 Bug #: 48215
   Summary: [NV11] Display constantly switches on and off roughly
every 10 seconds.
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: x86 (IA32)
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/other
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: alex.bu...@munted.org.uk


Display constantly switches on and off roughly every 10 seconds on my NV11
machine. This started happening with 3.2.0. 

Checking backwards, 3.1.0 works just fine. I am currently trying a bisect to
find the problem.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915: enable semaphores on gen6 if dmar is not active

[Andrew Lutomirski]

On Mon, Apr 2, 2012 at 1:52 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Mon, Apr 02, 2012 at 01:45:39PM -0700, Andrew Lutomirski wrote:
 On Mon, Apr 2, 2012 at 11:48 AM, Daniel Vetter daniel.vet...@ffwll.ch 
 wrote:
  Inspired by the recent ppgtt regression report, where switching of
  dmar only for the gpu seems to fix things completely, I've looked
  again at the semaphores+vt-d situation.
 
  Contrary to my earlier testing a few months back my system is now
  stable with dmar disabled for the igd, and not only when disabling
  dmar completely.
 
  So I'm rather hopeful that all our recent fixes for snb have changed
  things for code and it's time to try enabling semaphores again. We've
  also had issues with enabling semaphores which are not vt-d related,
  but I guess these are all fixed by the autoreport-disabling and lazy
  request fix. And there's only one way to find out whether there are
  still other issues ...
 
  Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
 
  ---
 
  If no further vt-d regressions show up in the 3.4 cycle I plan to
  merge this into -next for 3.5 (in a month or so). Comments about how
  unfeasibly you deem this highly welcome.
  -Daniel
  ---
   drivers/gpu/drm/i915/i915_gem_execbuffer.c |    8 +---
   1 files changed, 5 insertions(+), 3 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
  b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
  index 8e0b686..ac52433 100644
  --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
  +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
  @@ -849,9 +849,11 @@ intel_enable_semaphores(struct drm_device *dev)
         if (i915_semaphores = 0)
                 return i915_semaphores;
 
  -       /* Disable semaphores on SNB */
  -       if (INTEL_INFO(dev)-gen == 6)
  -               return 0;
  +#ifdef CONFIG_INTEL_IOMMU
  +       /* Disable semaphores on SNB if VT-d is on. */
  +       if (INTEL_INFO(dev)-gen == 6  intel_iommu_gfx_mapped)
  +               return false;

 It might be nice to have a printk here giving instructions for how to work
 around this.  For example:

 i915: Disabling semaphores to work around a DMAR issue.  As an
 alternative, boot with intel_iommu=igfx_off [or on, igfx_off, or
 whatever it's supposed to be].

 The documentation in kernel-parameters.txt is at best unclear to the
 uninitiated.

 If this really does work, I'll look into this. Atm it's still unclear
 where to exactly put the plain, we need to annoy internal hardware people
 to analyze this. Once we have enough evidence that the combination of gpu
 with various features enable plus VT-d just doesn't seem to work reliably.

 So can you check whether things do indeed work with this patch, atop
 kernel 3.4-rc1? Iirc you've been the one with the most trouble when
 semaphores are enabled ...

I've had a hard time reproducing the problems lately.  The
unconditional instant hard hang went away a few months ago, I think.
I'll give it another shot when I get home to that machine.

--Andy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915: enable semaphores on gen6 if dmar is not active

[Daniel Vetter]

On Mon, Apr 02, 2012 at 02:44:14PM -0700, Andrew Lutomirski wrote:
 On Mon, Apr 2, 2012 at 1:52 PM, Daniel Vetter dan...@ffwll.ch wrote:
  On Mon, Apr 02, 2012 at 01:45:39PM -0700, Andrew Lutomirski wrote:
  On Mon, Apr 2, 2012 at 11:48 AM, Daniel Vetter daniel.vet...@ffwll.ch 
  wrote:
   Inspired by the recent ppgtt regression report, where switching of
   dmar only for the gpu seems to fix things completely, I've looked
   again at the semaphores+vt-d situation.
  
   Contrary to my earlier testing a few months back my system is now
   stable with dmar disabled for the igd, and not only when disabling
   dmar completely.
  
   So I'm rather hopeful that all our recent fixes for snb have changed
   things for code and it's time to try enabling semaphores again. We've
   also had issues with enabling semaphores which are not vt-d related,
   but I guess these are all fixed by the autoreport-disabling and lazy
   request fix. And there's only one way to find out whether there are
   still other issues ...
  
   Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
  
   ---
  
   If no further vt-d regressions show up in the 3.4 cycle I plan to
   merge this into -next for 3.5 (in a month or so). Comments about how
   unfeasibly you deem this highly welcome.
   -Daniel
   ---
    drivers/gpu/drm/i915/i915_gem_execbuffer.c |    8 +---
    1 files changed, 5 insertions(+), 3 deletions(-)
  
   diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
   b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
   index 8e0b686..ac52433 100644
   --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
   +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
   @@ -849,9 +849,11 @@ intel_enable_semaphores(struct drm_device *dev)
          if (i915_semaphores = 0)
                  return i915_semaphores;
  
   -       /* Disable semaphores on SNB */
   -       if (INTEL_INFO(dev)-gen == 6)
   -               return 0;
   +#ifdef CONFIG_INTEL_IOMMU
   +       /* Disable semaphores on SNB if VT-d is on. */
   +       if (INTEL_INFO(dev)-gen == 6  intel_iommu_gfx_mapped)
   +               return false;
 
  It might be nice to have a printk here giving instructions for how to work
  around this.  For example:
 
  i915: Disabling semaphores to work around a DMAR issue.  As an
  alternative, boot with intel_iommu=igfx_off [or on, igfx_off, or
  whatever it's supposed to be].
 
  The documentation in kernel-parameters.txt is at best unclear to the
  uninitiated.
 
  If this really does work, I'll look into this. Atm it's still unclear
  where to exactly put the plain, we need to annoy internal hardware people
  to analyze this. Once we have enough evidence that the combination of gpu
  with various features enable plus VT-d just doesn't seem to work reliably.
 
  So can you check whether things do indeed work with this patch, atop
  kernel 3.4-rc1? Iirc you've been the one with the most trouble when
  semaphores are enabled ...
 
 I've had a hard time reproducing the problems lately.  The
 unconditional instant hard hang went away a few months ago, I think.
 I'll give it another shot when I get home to that machine.

Well, I've managed to kill my machine shortly after login with semaphores,
rc6 and dmar enabled. It hasn't died in the same configuration after a few
hours of light usage (in my case that seems to be the best killer) with
dmar disabled for just the gpu.

So if you can give your machine some serious beating with the different
options, that's really great.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48131] Very large 2D texture is sometimes corrupted

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48131

Sven Arvidsson s...@whiz.se changed:

   What|Removed |Added

 CC||s...@whiz.se

--- Comment #5 from Sven Arvidsson s...@whiz.se 2012-04-02 15:32:53 PDT ---
FWIW, for me the test segfaults with 8.0 but works (without artefacts AFAICT)
with 8.0.2. This is on a HD 5670.

(I suppose the component of the bug should be moved to Drivers/Gallium/r600 ?)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48131] Very large 2D texture is sometimes corrupted

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48131

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Drivers/Gallium/r600

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48215] [NV11] Display constantly switches on and off roughly every 10 seconds.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48215

Alex Buell alex.bu...@munted.org.uk changed:

   What|Removed |Added

 OS/Version|All |Linux (All)

--- Comment #1 from Alex Buell alex.bu...@munted.org.uk 2012-04-02 16:28:01 
PDT ---
Bug is still present in 3.4_rc1.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel