<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu, branch v3.6.6</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.6.6</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.6.6'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2012-11-05T08:56:52+00:00</updated>
<entry>
<title>drm/nouveau: headless mode by default if pci class != vga display</title>
<updated>2012-11-05T08:56:52+00:00</updated>
<author>
<name>Ben Skeggs</name>
<email>bskeggs@redhat.com</email>
</author>
<published>2012-11-01T06:16:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8c1118a286324e4c16352b317f4531e82ede021a'/>
<id>urn:sha1:8c1118a286324e4c16352b317f4531e82ede021a</id>
<content type='text'>
This is to prevent nouveau from taking over the console on headless boards
such as Tesla.

Backport of upstream commit: e412e95a268fa8544858ebfe066826b290430d51

Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/nouveau: fix suspend/resume when in headless mode</title>
<updated>2012-11-05T08:56:52+00:00</updated>
<author>
<name>Ben Skeggs</name>
<email>bskeggs@redhat.com</email>
</author>
<published>2012-11-01T06:16:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=83dc21544384ae8db01cc1c1a159ae6594444534'/>
<id>urn:sha1:83dc21544384ae8db01cc1c1a159ae6594444534</id>
<content type='text'>
Backport of fixes from upstream commit:
9430738d80223a1cd791a2baa74fa170d3df1262

Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/nouveau: silence modesetting spam on pre-gf8 chipsets</title>
<updated>2012-11-05T08:56:52+00:00</updated>
<author>
<name>Ben Skeggs</name>
<email>bskeggs@redhat.com</email>
</author>
<published>2012-10-28T23:03:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=783250d700a2ab8d12040dec188b291328e13225'/>
<id>urn:sha1:783250d700a2ab8d12040dec188b291328e13225</id>
<content type='text'>
commit cee59f15a60cc6269a25e3f6fbf1a577d6ab8115 upstream.

Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/radeon: add error output if VM CS fails on cayman</title>
<updated>2012-10-31T17:09:37+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2012-10-19T17:27:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7eff2fdcdb9c78d8d2c9e27b223d67b4a9da3a5a'/>
<id>urn:sha1:7eff2fdcdb9c78d8d2c9e27b223d67b4a9da3a5a</id>
<content type='text'>
commit c71721324c612f7f040657ce9917d87f530f9784 upstream.

So we know why the CS was rejected.

Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: Use cpu relocations if the object is in the GTT but not mappable</title>
<updated>2012-10-28T17:56:16+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2012-08-23T12:12:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2c609a2f31e7961301c3b7ecbc8b47b29c1ea790'/>
<id>urn:sha1:2c609a2f31e7961301c3b7ecbc8b47b29c1ea790</id>
<content type='text'>
commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846 upstream.

This prevents the case of unbinding the object in order to process the
relocations through the GTT and then rebinding it only to then proceed
to use cpu relocations as the object is now in the CPU write domain. By
choosing to use cpu relocations up front, we can therefore avoid the
rebind penalty.

Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag</title>
<updated>2012-10-21T16:32:42+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2012-09-26T15:43:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6c34ed3be47036c173f7f43df112f93fbd89026f'/>
<id>urn:sha1:6c34ed3be47036c173f7f43df112f93fbd89026f</id>
<content type='text'>
commit 0c96c65b48fba3ffe9822a554cbc0cd610765cd5 upstream.

The dithering introduced in

commit 3b5c78a35cf7511c15e09a9b0ffab290a42d9bcf
Author: Adam Jackson &lt;ajax@redhat.com&gt;
Date:   Tue Dec 13 15:41:00 2011 -0800

    drm/i915/dp: Dither down to 6bpc if it makes the mode fit

stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the
adjusted mode, while i9xx_crtc_mode_set() and ironlake_crtc_mode_set() use
the original mode, without the flag, so it would never have any
effect. However, the BPC was clamped by VBT settings, making things work by
coincidence, until that part was removed in

commit 4344b813f105a19f793f1fd93ad775b784648b95
Author: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Date:   Fri Aug 10 11:10:20 2012 +0200

Use adjusted_mode instead of mode when checking for
INTEL_MODE_DP_FORCE_6BPC to make the flag have effect.

v2: Don't forget to fix this in i9xx_crtc_mode_set() also, pointed out by
Daniel both before and after sending the first patch.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47621
CC: Adam Jackson &lt;ajax@redhat.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Reviewed-by: Adam Jackson &lt;ajax@redhat.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>drm/i915: Set guardband clipping workaround bit in the right register.</title>
<updated>2012-10-21T16:32:42+00:00</updated>
<author>
<name>Kenneth Graunke</name>
<email>kenneth@whitecape.org</email>
</author>
<published>2012-10-07T15:51:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=248f303079cbc3161e88e8ebbcc4dd25983e82b0'/>
<id>urn:sha1:248f303079cbc3161e88e8ebbcc4dd25983e82b0</id>
<content type='text'>
commit 26b6e44afb58432a5e998da0343757404f9de9ee upstream.

A previous patch, namely:

commit bf97b276ca04cee9ab65ffd378fa8e6aedd71ff6
Author: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Date:   Wed Apr 11 20:42:41 2012 +0200

    drm/i915: implement w/a for incorrect guarband clipping

accidentally set bit 5 in 3D_CHICKEN, which has nothing to do with
clipping.  This patch changes it to be set in 3D_CHICKEN3, where it
belongs.

The game "Dante" demonstrates random clipping issues when guardband
clipping is enabled and bit 5 of 3D_CHICKEN3 isn't set.  So the
workaround is actually necessary.

Acked-by: Paul Menzel &lt;paulepanter@users.sourceforge.net&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: Oliver McFadden &lt;oliver.mcfadden@linux.intel.com&gt;
Signed-off-by: Kenneth Graunke &lt;kenneth@whitecape.org&gt;
Reviewed-by: Mika Kuoppala &lt;mika.kuoppala@intel.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: remove useless BUG_ON which caused a regression in 3.5.</title>
<updated>2012-10-21T16:32:42+00:00</updated>
<author>
<name>Willy Tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2012-10-06T08:20:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=673c45ace878af19df61f240bddc44938c47d11d'/>
<id>urn:sha1:673c45ace878af19df61f240bddc44938c47d11d</id>
<content type='text'>
commit c77d7162a7ae451c2e895d7ef7fbeb0906107472 upstream.

starting an old X server causes a kernel BUG since commit 1b50247a8d:

------------[ cut here ]------------
kernel BUG at drivers/gpu/drm/i915/i915_gem.c:3661!
invalid opcode: 0000 [#1] SMP
Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss uvcvideo
+videobuf2_core videodev videobuf2_vmalloc videobuf2_memops uhci_hcd ath9k mac80211 snd_hda_codec_realtek ath9k_common microcode
+ath9k_hw psmouse serio_raw sg ath cfg80211 atl1c lpc_ich mfd_core ehci_hcd snd_hda_intel snd_hda_codec snd_hwdep snd_pcm rtc_cmos
+snd_timer snd evdev eeepc_laptop snd_page_alloc sparse_keymap

Pid: 2866, comm: X Not tainted 3.5.6-rc1-eeepc #1 ASUSTeK Computer INC. 1005HA/1005HA
EIP: 0060:[&lt;c12dc291&gt;] EFLAGS: 00013297 CPU: 0
EIP is at i915_gem_entervt_ioctl+0xf1/0x110
EAX: f5941df4 EBX: f5940000 ECX: 00000000 EDX: 00020000
ESI: f5835400 EDI: 00000000 EBP: f51d7e38 ESP: f51d7e20
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
CR0: 8005003b CR2: b760e0a0 CR3: 351b6000 CR4: 000007d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process X (pid: 2866, ti=f51d6000 task=f61af8d0 task.ti=f51d6000)
Stack:
 00000001 00000000 f5835414 f51d7e84 f5835400 f54f85c0 f51d7f10 c12b530b
 00000001 c151b139 c14751b6 c152e030 00000b32 00006459 00000059 0000e200
 00000001 00000000 00006459 c159ddd0 c12dc1a0 ffffffea 00000000 00000000
Call Trace:
 [&lt;c12b530b&gt;] drm_ioctl+0x2eb/0x440
 [&lt;c12dc1a0&gt;] ? i915_gem_init+0xe0/0xe0
 [&lt;c1052b2b&gt;] ? enqueue_hrtimer+0x1b/0x50
 [&lt;c1053321&gt;] ? __hrtimer_start_range_ns+0x161/0x330
 [&lt;c10530b3&gt;] ? lock_hrtimer_base+0x23/0x50
 [&lt;c1053163&gt;] ? hrtimer_try_to_cancel+0x33/0x70
 [&lt;c12b5020&gt;] ? drm_version+0x90/0x90
 [&lt;c10ca171&gt;] vfs_ioctl+0x31/0x50
 [&lt;c10ca2e4&gt;] do_vfs_ioctl+0x64/0x510
 [&lt;c10535de&gt;] ? hrtimer_nanosleep+0x8e/0x100
 [&lt;c1052c20&gt;] ? update_rmtp+0x80/0x80
 [&lt;c10ca7c9&gt;] sys_ioctl+0x39/0x60
 [&lt;c1433949&gt;] syscall_call+0x7/0xb
Code: 83 c4 0c 5b 5e 5f 5d c3 c7 44 24 04 2c 05 53 c1 c7 04 24 6f ef 47 c1 e8 6e e0 fd ff c7 83 38 1e 00 00 00 00 00 00 e9 3f ff ff
+ff &lt;0f&gt; 0b eb fe 0f 0b eb fe 8d b4 26 00 00 00 00 0f 0b eb fe 8d b6
EIP: [&lt;c12dc291&gt;] i915_gem_entervt_ioctl+0xf1/0x110 SS:ESP 0068:f51d7e20
---[ end trace dd332ec083cbd513 ]---

The crash happens here in i915_gem_entervt_ioctl() :

    3659          BUG_ON(!list_empty(&amp;dev_priv-&gt;mm.active_list));
    3660          BUG_ON(!list_empty(&amp;dev_priv-&gt;mm.flushing_list));
 -&gt; 3661          BUG_ON(!list_empty(&amp;dev_priv-&gt;mm.inactive_list));
    3662          mutex_unlock(&amp;dev-&gt;struct_mutex);

Quoting Chris :
  "That BUG_ON there is silly and can simply be removed. The check is to
   verify that no batches were submitted to the kernel whilst the UMS/GEM
   client was suspended - to which the BUG_ONs are a crude approximation.
   Furthermore, the checks are too late, since it means we attempted to
   program the hardware whilst it was in an invalid state, the BUG_ONs are
   the least of your concerns at that point."

Note that this regression has been introduced in

commit 1b50247a8ddde4af5aaa0e6bc125615372ce6c16
Author: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Date:   Tue Apr 24 15:47:30 2012 +0100

    drm/i915: Remove the list of pinned inactive objects

Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
[danvet: Added note about the regressing commit and cc: stable.]
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/radeon: Don't destroy I2C Bus Rec in radeon_ext_tmds_enc_destroy().</title>
<updated>2012-10-21T16:32:42+00:00</updated>
<author>
<name>Egbert Eich</name>
<email>eich@suse.de</email>
</author>
<published>2012-10-15T06:21:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b567aa019fe3d2b9d341650b95c7afcc04a3c812'/>
<id>urn:sha1:b567aa019fe3d2b9d341650b95c7afcc04a3c812</id>
<content type='text'>
commit 082918471139b07964967cfe5f70230909c82ae1 upstream.

radeon_i2c_fini() walks thru the list of I2C bus recs rdev-&gt;i2c_bus[]
to destroy each of them.
radeon_ext_tmds_enc_destroy() however also has code to destroy it's
associated I2C bus rec which has been obtained by radeon_i2c_lookup()
and is therefore also in the i2c_bus[] list.
This causes a double free resulting in a kernel panic when unloading
the radeon driver.
Removing destroy code from radeon_ext_tmds_enc_destroy() fixes this
problem.

agd5f: fix compiler warning

Signed-off-by: Egbert Eich &lt;eich@suse.de&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: Fix GT_MODE default value</title>
<updated>2012-10-12T20:50:29+00:00</updated>
<author>
<name>Ben Widawsky</name>
<email>ben@bwidawsk.net</email>
</author>
<published>2012-10-04T02:34:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2a853d7062c3598e2fa68a6614cd953164dcaf3e'/>
<id>urn:sha1:2a853d7062c3598e2fa68a6614cd953164dcaf3e</id>
<content type='text'>
commit f8f2ac9a76b0f80a6763ca316116a7bab8486997 upstream.

I can't even find how I figured this might be needed anymore. But sure
enough, the value I'm reading back on platforms doesn't match what the
docs recommends.

It seemed to fix Chris' GT1 in limited testing as well.

Tested-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Ben Widawsky &lt;ben@bwidawsk.net&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
