<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm, branch v4.12.9</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.12.9</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.12.9'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2017-08-25T00:15:01+00:00</updated>
<entry>
<title>drm/amdgpu: save list length when fence is signaled</title>
<updated>2017-08-25T00:15:01+00:00</updated>
<author>
<name>Chunming Zhou</name>
<email>David1.Zhou@amd.com</email>
</author>
<published>2017-08-11T01:34:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b5e042f90f1f9b33f9788c4e18981c2b1ccddafa'/>
<id>urn:sha1:b5e042f90f1f9b33f9788c4e18981c2b1ccddafa</id>
<content type='text'>
commit 7a7c286d07f9c704e8fd11dd960bf421cc67b66b upstream.

update the list first to avoid redundant checks.

Signed-off-by: Chunming Zhou &lt;David1.Zhou@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&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: Perform an invalidate prior to executing golden renderstate</title>
<updated>2017-08-25T00:15:01+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2017-08-08T13:19:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2149506faff17258aef239703b97f908291e8c13'/>
<id>urn:sha1:2149506faff17258aef239703b97f908291e8c13</id>
<content type='text'>
commit a0125a932e917cb507b682cb66645efdca1f8cab upstream.

As we may have just bound the renderstate into the GGTT for execution, we
need to ensure that the GTT TLB are also flushed.

On snb-gt2, this would cause a random GPU hang at the start of a new
context (e.g. boot) and on snb-gt1, it was causing the renderstate batch
to take ~10s. It was the GPU hang that revealed the truth, as the CS
gleefully executed beyond the end of the golden renderstate batch, a good
indicator for a GTT TLB miss.

Fixes: 20fe17aa52dc ("drm/i915: Remove redundant TLB invalidate on switching contexts")
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20170808131904.1385-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Cc: &lt;drm-intel-fixes@lists.freedesktop.org&gt; # v4.12-rc1+
(cherry picked from commit 802673d66f8a6ded5d2689d597853c7bb3a70163)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lut</title>
<updated>2017-08-16T20:46:53+00:00</updated>
<author>
<name>Maarten Lankhorst</name>
<email>maarten.lankhorst@linux.intel.com</email>
</author>
<published>2017-07-24T09:14:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=59f1322cc1e5fc9a4aa186c1862a027df97132fc'/>
<id>urn:sha1:59f1322cc1e5fc9a4aa186c1862a027df97132fc</id>
<content type='text'>
commit 5279fc7724ae3a82c9cfe5b09c1fb07ff0e41056 upstream.

bdw_load_gamma_lut is writing beyond the array to the maximum value.
The intend of the function is to clamp values &gt; 1 to 1, so write
the intended color to the max register.

This fixes the following KASAN warning:

[  197.020857] [IGT] kms_pipe_color: executing
[  197.063434] [IGT] kms_pipe_color: starting subtest ctm-0-25-pipe0
[  197.078989] ==================================================================
[  197.079127] BUG: KASAN: slab-out-of-bounds in bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
[  197.079188] Read of size 2 at addr ffff8800d38db150 by task kms_pipe_color/1839
[  197.079208] CPU: 2 PID: 1839 Comm: kms_pipe_color Tainted: G     U 4.13.0-rc1-patser+ #5211
[  197.079215] Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015
[  197.079220] Call Trace:
[  197.079230]  dump_stack+0x68/0x9e
[  197.079239]  print_address_description+0x6f/0x250
[  197.079251]  kasan_report+0x216/0x370
[  197.079374]  ? bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
[  197.079451]  ? gen8_write16+0x4e0/0x4e0 [i915]
[  197.079460]  __asan_report_load2_noabort+0x14/0x20
[  197.079535]  bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
[  197.079612]  broadwell_load_luts+0x1df/0x550 [i915]
[  197.079690]  intel_color_load_luts+0x7b/0x80 [i915]
[  197.079764]  intel_begin_crtc_commit+0x138/0x760 [i915]
[  197.079783]  drm_atomic_helper_commit_planes_on_crtc+0x1a3/0x820 [drm_kms_helper]
[  197.079859]  ? intel_pre_plane_update+0x571/0x580 [i915]
[  197.079937]  intel_update_crtc+0x238/0x330 [i915]
[  197.080016]  intel_update_crtcs+0x10f/0x210 [i915]
[  197.080092]  intel_atomic_commit_tail+0x1552/0x3340 [i915]
[  197.080101]  ? _raw_spin_unlock+0x3c/0x40
[  197.080110]  ? __queue_work+0xb40/0xbf0
[  197.080188]  ? skl_update_crtcs+0xc00/0xc00 [i915]
[  197.080195]  ? trace_hardirqs_on+0xd/0x10
[  197.080269]  ? intel_atomic_commit_ready+0x128/0x13c [i915]
[  197.080329]  ? __i915_sw_fence_complete+0x5b8/0x6d0 [i915]
[  197.080336]  ? debug_object_activate+0x39e/0x580
[  197.080397]  ? i915_sw_fence_await+0x30/0x30 [i915]
[  197.080409]  ? __might_sleep+0x15b/0x180
[  197.080483]  intel_atomic_commit+0x944/0xa70 [i915]
[  197.080490]  ? refcount_dec_and_test+0x11/0x20
[  197.080567]  ? intel_atomic_commit_tail+0x3340/0x3340 [i915]
[  197.080597]  ? drm_atomic_crtc_set_property+0x303/0x580 [drm]
[  197.080674]  ? intel_atomic_commit_tail+0x3340/0x3340 [i915]
[  197.080704]  drm_atomic_commit+0xd7/0xe0 [drm]
[  197.080722]  drm_atomic_helper_crtc_set_property+0xec/0x130 [drm_kms_helper]
[  197.080749]  drm_mode_crtc_set_obj_prop+0x7d/0xb0 [drm]
[  197.080775]  drm_mode_obj_set_property_ioctl+0x50b/0x5d0 [drm]
[  197.080783]  ? __might_fault+0x104/0x180
[  197.080809]  ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
[  197.080838]  ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
[  197.080861]  drm_ioctl_kernel+0x154/0x1a0 [drm]
[  197.080885]  drm_ioctl+0x624/0x8f0 [drm]
[  197.080910]  ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
[  197.080934]  ? drm_getunique+0x210/0x210 [drm]
[  197.080943]  ? __handle_mm_fault+0x1bd0/0x1ce0
[  197.080949]  ? lock_downgrade+0x610/0x610
[  197.080957]  ? __lru_cache_add+0x15a/0x180
[  197.080967]  do_vfs_ioctl+0xd92/0xe40
[  197.080975]  ? ioctl_preallocate+0x1b0/0x1b0
[  197.080982]  ? selinux_capable+0x20/0x20
[  197.080991]  ? __do_page_fault+0x7b7/0x9a0
[  197.080997]  ? lock_downgrade+0x5bb/0x610
[  197.081007]  ? security_file_ioctl+0x57/0x90
[  197.081016]  SyS_ioctl+0x4e/0x80
[  197.081024]  entry_SYSCALL_64_fastpath+0x18/0xad
[  197.081030] RIP: 0033:0x7f61f287a987
[  197.081035] RSP: 002b:00007fff7d44d188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[  197.081043] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f61f287a987
[  197.081048] RDX: 00007fff7d44d1c0 RSI: 00000000c01864ba RDI: 0000000000000003
[  197.081053] RBP: 00007f61f2b3eb00 R08: 0000000000000059 R09: 0000000000000000
[  197.081058] R10: 0000002ea5c4a290 R11: 0000000000000246 R12: 00007f61f2b3eb58
[  197.081063] R13: 0000000000001010 R14: 00007f61f2b3eb58 R15: 0000000000002702

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101659
Signed-off-by: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Reported-by: Martin Peres &lt;martin.peres@linux.intel.com&gt;
Cc: Martin Peres &lt;martin.peres@linux.intel.com&gt;
Fixes: 82cf435b3134 ("drm/i915: Implement color management on bdw/skl/bxt/kbl")
Cc: Shashank Sharma &lt;shashank.sharma@intel.com&gt;
Cc: Kiran S Kumar &lt;kiran.s.kumar@intel.com&gt;
Cc: Kausal Malladi &lt;kausalmalladi@gmail.com&gt;
Cc: Lionel Landwerlin &lt;lionel.g.landwerlin@intel.com&gt;
Cc: Matt Roper &lt;matthew.d.roper@intel.com&gt;
Cc: Daniel Vetter &lt;daniel.vetter@intel.com&gt;
Cc: Jani Nikula &lt;jani.nikula@linux.intel.com&gt;
Cc: intel-gfx@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20170724091431.24251-1-maarten.lankhorst@linux.intel.com
Reviewed-by: Lionel Landwerlin &lt;lionel.g.landwerlin@intel.com&gt;
(cherry picked from commit 09a92bc8773b4314e02b478e003fe5936ce85adb)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/etnaviv: Fix off-by-one error in reloc checking</title>
<updated>2017-08-16T20:46:53+00:00</updated>
<author>
<name>Wladimir J. van der Laan</name>
<email>laanwj@gmail.com</email>
</author>
<published>2017-07-25T12:33:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4eedc8a7f03b15a9daad69b4d54e43f79fa0e16e'/>
<id>urn:sha1:4eedc8a7f03b15a9daad69b4d54e43f79fa0e16e</id>
<content type='text'>
commit d6f756e09f01ea7a0efbbcef269a1e384a35d824 upstream.

A relocation pointing to the last four bytes of a buffer can
legitimately happen in the case of small vertex buffers.

Signed-off-by: Wladimir J. van der Laan &lt;laanwj@gmail.com&gt;
Reviewed-by: Philipp Zabel &lt;p.zabel@pengutronix.de&gt;
Reviewed-by: Christian Gmeiner &lt;christian.gmeiner@gmail.com&gt;
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/bridge: tc358767: fix probe without attached output node</title>
<updated>2017-08-16T20:46:52+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2017-07-10T12:41:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8f0f15cc167d550cb50adbdf14472968b619d244'/>
<id>urn:sha1:8f0f15cc167d550cb50adbdf14472968b619d244</id>
<content type='text'>
commit d630213f2a47933e1037909273a20023ba3e598d upstream.

The output node of the TC358767 is only used if another bridge is chained
behind it. Panels attached to the TC358767 can be detected using the usual
DP AUX probing. This restores the old behavior of ignoring the output if
no endpoint is found.

Fixes: ebc944613567 (drm: convert drivers to use drm_of_find_panel_or_bridge)
Acked-by: Andrey Gusakov &lt;andrey.gusakov@cogentembedded.com&gt;
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Archit Taneja &lt;architt@codeaurora.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20170710124125.9019-1-l.stach@pengutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/vmwgfx: Fix cursor hotspot issue with Wayland on Fedora</title>
<updated>2017-08-11T15:34:00+00:00</updated>
<author>
<name>Sinclair Yeh</name>
<email>syeh@vmware.com</email>
</author>
<published>2017-07-18T06:26:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e7672072192edc045b1abb7a61594834e6ce0032'/>
<id>urn:sha1:e7672072192edc045b1abb7a61594834e6ce0032</id>
<content type='text'>
commit 14979adb0294f04cf6fbbb81555acff9ec1e7c9c upstream.

Parts of commit &lt;8fbf9d92a7bc&gt; (“drm/vmwgfx: Implement the
cursor_set2 callback v2”) were not moved over when we started
atomic mode set development because at that time the DRM did
not support cursor hotspots in the fb struct.

This patch fixes what was not moved over.

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Brian Paul &lt;brianp@vmware.com&gt;
Tested-by: Brian Paul &lt;brianp@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/amdgpu: Fix undue fallthroughs in golden registers initialization</title>
<updated>2017-08-11T15:33:52+00:00</updated>
<author>
<name>Jean Delvare</name>
<email>jdelvare@suse.de</email>
</author>
<published>2017-07-30T08:18:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=aff854f4e125b7db9c0583ebc1bbd02ec132669b'/>
<id>urn:sha1:aff854f4e125b7db9c0583ebc1bbd02ec132669b</id>
<content type='text'>
commit 5694785cf09bf0e7bd8e5f62361ea34fa162a4a0 upstream.

As I was staring at the si_init_golden_registers code, I noticed that
the Pitcairn initialization silently falls through the Cape Verde
initialization, and the Oland initialization falls through the Hainan
initialization. However there is no comment stating that this is
intentional, and the radeon driver doesn't have any such fallthrough,
so I suspect this is not supposed to happen.

Signed-off-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10")
Cc: Ken Wang &lt;Qingqing.Wang@amd.com&gt;
Cc: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: "Marek Olšák" &lt;maraeo@gmail.com&gt;
Cc: "Christian König" &lt;christian.koenig@amd.com&gt;
Cc: Flora Cui &lt;Flora.Cui@amd.com&gt;
Reviewed-by: Marek Olšák &lt;marek.olsak@amd.com&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/amdgpu: fix header on gfx9 clear state</title>
<updated>2017-08-11T15:33:51+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2017-07-27T02:10:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bf8afa46d7014f1a0c0afa9ad49bd37bbfff948c'/>
<id>urn:sha1:bf8afa46d7014f1a0c0afa9ad49bd37bbfff948c</id>
<content type='text'>
commit c471e70b187e62efc77bcdf6f58795907f8f4851 upstream.

This got missed when we open sourced this.

Reviewed-by: Christian König &lt;christian.koenig@amd.com&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 scaler init during CRTC HW state readout</title>
<updated>2017-08-06T16:21:10+00:00</updated>
<author>
<name>Imre Deak</name>
<email>imre.deak@intel.com</email>
</author>
<published>2017-07-20T11:28:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9ec2ee3a972d58f808dfadad92ba1b3617740a9f'/>
<id>urn:sha1:9ec2ee3a972d58f808dfadad92ba1b3617740a9f</id>
<content type='text'>
commit 283d6860d64f5091565bf729b0a6d6af14ae6c27 upstream.

The scaler allocation code depends on a non-zero default value for the
crtc scaler_id, so make sure we initialize the scaler state accordingly
even if the crtc is off. This fixes at least an initial YUV420 modeset
(added in a follow-up patchset by Shashank) when booting with the screen
off: after the initial HW readout and modeset which enables the scaler a
subsequent modeset will disable the scaler which isn't properly
allocated. This results in a funky HW state where the pipe scaler HW
registers can't be modified and the normally black screen is grey and
shifted to the right or jitters.

The problem was revealed by Shashank's YUV420 patchset and first
reported by Ville.

v2:
- In the stable tag also include versions which need backporting (Jani)

Cc: Jani Nikula &lt;jani.nikula@intel.com&gt;
Cc: Shashank Sharma &lt;shashank.sharma@intel.com&gt;
Cc: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Cc: Chandra Konduru &lt;chandra.konduru@intel.com&gt;
Cc: Matt Roper &lt;matthew.d.roper@intel.com&gt;
Reported-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Fixes: a1b2278e4dfc ("drm/i915: skylake panel fitting using shared scalers")
Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Reviewed-by: Mahesh Kumar &lt;mahesh1.kumar@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20170720112820.26816-1-imre.deak@intel.com
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
(cherry picked from commit 5fb9dadf336f3590c799e8cbde348215dccc2aa2)
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/nouveau/bar/gf100: fix access to upper half of BAR2</title>
<updated>2017-08-06T16:21:10+00:00</updated>
<author>
<name>Ben Skeggs</name>
<email>bskeggs@redhat.com</email>
</author>
<published>2017-07-25T01:06:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7a4337a68743a77bc60d7828bd5ed4cd0b416ba6'/>
<id>urn:sha1:7a4337a68743a77bc60d7828bd5ed4cd0b416ba6</id>
<content type='text'>
commit 38bcb208f60924a031b9f809f7cd252ea4a94e5f upstream.

Bit 30 being set causes the upper half of BAR2 to stay in physical mode,
mapped over the end of VRAM, even when the rest of the BAR has been set
to virtual mode.

We inherited our initial value from RM, but I'm not aware of any reason
we need to keep it that way.

This fixes severe GPU hang/lockup issues revealed by Wayland on F26.

Shout-out to NVIDIA for the quick response with the potential cause!

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

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