<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu, branch v4.10.2</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.10.2</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.10.2'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2017-02-17T01:13:17+00:00</updated>
<entry>
<title>Merge branch 'drm-fixes-4.10' of git://people.freedesktop.org/~agd5f/linux into drm-fixes</title>
<updated>2017-02-17T01:13:17+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2017-02-17T01:13:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=18a0de8816766a0da7537ef82156b5418ba5cd6e'/>
<id>urn:sha1:18a0de8816766a0da7537ef82156b5418ba5cd6e</id>
<content type='text'>
One regression fix for interlaced modes on radeon

* 'drm-fixes-4.10' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: Use mode h/vdisplay fields to hide out of bounds HW cursor
</content>
</entry>
<entry>
<title>drm/radeon: Use mode h/vdisplay fields to hide out of bounds HW cursor</title>
<updated>2017-02-16T16:03:03+00:00</updated>
<author>
<name>Michel Dänzer</name>
<email>michel.daenzer@amd.com</email>
</author>
<published>2017-02-15T02:28:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d74c67dd7800fc7aae381f272875c337f268806c'/>
<id>urn:sha1:d74c67dd7800fc7aae381f272875c337f268806c</id>
<content type='text'>
The crtc_h/vdisplay fields may not match the CRTC viewport dimensions
with special modes such as interlaced ones.

Fixes the HW cursor disappearing in the bottom half of the screen with
interlaced modes.

Fixes: 6b16cf7785a4 ("drm/radeon: Hide the HW cursor while it's out of bounds")
Cc: stable@vger.kernel.org
Reported-by: Ashutosh Kumar &lt;ashutosh.kumar@amd.com&gt;
Tested-by: Sonny Jiang &lt;sonny.jiang@amd.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Michel Dänzer &lt;michel.daenzer@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/dp/mst: fix kernel oops when turning off secondary monitor</title>
<updated>2017-02-15T09:41:19+00:00</updated>
<author>
<name>Pierre-Louis Bossart</name>
<email>pierre-louis.bossart@linux.intel.com</email>
</author>
<published>2017-02-14T12:49:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bb08c04dc867b5f392caec635c097d5d5fcd8c9f'/>
<id>urn:sha1:bb08c04dc867b5f392caec635c097d5d5fcd8c9f</id>
<content type='text'>
100% reproducible issue found on SKL SkullCanyon NUC with two external
DP daisy-chained monitors in DP/MST mode. When turning off or changing
the input of the second monitor the machine stops with a kernel
oops. This issue happened with 4.8.8 as well as drm/drm-intel-nightly.

This issue is traced to an inconsistent control flow in
drm_dp_update_payload_part1(): the 'port' pointer is set to NULL at the
same time as 'req_payload.num_slots' is set to zero, but the pointer is
dereferenced even when req_payload.num_slot is zero.

The problematic dereference was introduced in commit dfda0df34
("drm/mst: rework payload table allocation to conform better") and may
impact all versions since v3.18

The fix suggested by Chris Wilson removes the kernel oops and was found to
work well after 10mn of monkey-testing with the second monitor power and
input buttons

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98990
Fixes: dfda0df34264 ("drm/mst: rework payload table allocation to conform better.")
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Nathan D Ciobanu &lt;nathan.d.ciobanu@linux.intel.com&gt;
Cc: Dhinakaran Pandiyan &lt;dhinakaran.pandiyan@intel.com&gt;
Cc: Sean Paul &lt;seanpaul@chromium.org&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v3.18+
Tested-by: Nathan D Ciobanu &lt;nathan.d.ciobanu@linux.intel.com&gt;
Reviewed-by: Dhinakaran Pandiyan &lt;dhinakaran.pandiyan@intel.com&gt;
Signed-off-by: Pierre-Louis Bossart &lt;pierre-louis.bossart@linux.intel.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/1487076561-2169-1-git-send-email-jani.nikula@intel.com
</content>
</entry>
<entry>
<title>Merge tag 'drm-intel-fixes-2017-02-09' of git://anongit.freedesktop.org/git/drm-intel into drm-fixes</title>
<updated>2017-02-10T00:14:24+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2017-02-10T00:14:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=697d3a21615672b2bf7724a65755799260325dda'/>
<id>urn:sha1:697d3a21615672b2bf7724a65755799260325dda</id>
<content type='text'>
Hopefully final fixes for v4.10, about half of them stable material.

* tag 'drm-intel-fixes-2017-02-09' of git://anongit.freedesktop.org/git/drm-intel:
  drm/i915: Always convert incoming exec offsets to non-canonical
  drm/i915: Remove overzealous fence warn on runtime suspend
  drm/i915/bxt: Add MST support when do DPLL calculation
  drm/i915: don't warn about Skylake CPU - KabyPoint PCH combo
  drm/i915: fix i915 running as dom0 under Xen
  drm/i915: Flush untouched framebuffers before display on !llc
  drm/i915: fix use-after-free in page_flip_completed()
</content>
</entry>
<entry>
<title>Merge tag 'drm-misc-fixes-2017-02-09' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes</title>
<updated>2017-02-10T00:14:01+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2017-02-10T00:14:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=811b40c83db047ba22a0c5b638186ed2b8c9810c'/>
<id>urn:sha1:811b40c83db047ba22a0c5b638186ed2b8c9810c</id>
<content type='text'>
Last-minute vc4 fix for 4.10.

* tag 'drm-misc-fixes-2017-02-09' of git://anongit.freedesktop.org/git/drm-misc:
  drm: vc4: adapt to new behaviour of drm_crtc.c
</content>
</entry>
<entry>
<title>drm: vc4: adapt to new behaviour of drm_crtc.c</title>
<updated>2017-02-08T22:19:23+00:00</updated>
<author>
<name>Andrzej Pietrasiewicz</name>
<email>andrzej.p@samsung.com</email>
</author>
<published>2017-02-01T09:35:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=49d29a077af8d2ee3b291ccd8d053541bebe09d7'/>
<id>urn:sha1:49d29a077af8d2ee3b291ccd8d053541bebe09d7</id>
<content type='text'>
When drm_crtc_init_with_planes() was orignally added
(in drm_crtc.c, e13161af80c185ecd8dc4641d0f5df58f9e3e0af
drm: Add drm_crtc_init_with_planes() (v2)), it only checked for "primary"
being non-null. If that was the case, it modified primary-&gt;possible_crtcs.

Then, when support for cursor planes was added
(fc1d3e44ef7c1db93384150fdbf8948dcf949f15 drm: Allow drivers to register
cursor planes with crtc), the same behaviour was implemented for cursor
planes.

vc4_plane_init() since its inception has passed 0xff as "possible_crtcs"
parameter to drm_universal_plane_init(). With a change in drm_crtc.c
(7abc7d47510c75dd984380ebf819616e574c9604 drm: don't override
possible_crtcs for primary/cursor planes) passing 0xff results in primary's
possible_crtcs set to 0xff (cursor was updated manually by vc4_crtc.c).
Consequently, it would be allowed to use the primary plane from CRTC 1 (for
example) on CRTC 0, which would result in the overlay and cursors being
buried.

Signed-off-by: Andrzej Pietrasiewicz &lt;andrzej.p@samsung.com&gt;
Reviewed-by: Eric Anholt &lt;eric@anholt.net&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/1485941708-27892-1-git-send-email-andrzej.p@samsung.com
Fixes: 7abc7d47510c ("drm: don't override possible_crtcs for primary/cursor planes")
</content>
</entry>
<entry>
<title>drm/i915: Always convert incoming exec offsets to non-canonical</title>
<updated>2017-02-08T11:27:28+00:00</updated>
<author>
<name>Michał Winiarski</name>
<email>michal.winiarski@intel.com</email>
</author>
<published>2017-02-07T19:55:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6e7eb1783be7f19eb071c96ddda0bbf22279ff46'/>
<id>urn:sha1:6e7eb1783be7f19eb071c96ddda0bbf22279ff46</id>
<content type='text'>
We're using non-canonical addresses in drm_mm, and we're making sure that
userspace is using canonical addressing - both in case of softpin
(verifying incoming offset) and when relocating (converting to canonical
when updating offset returned to userspace).
Unfortunately when considering the need for relocations, we're comparing
offset from userspace (in canonical form) with drm_mm node (in
non-canonical form), and as a result, we end up always relocating if our
offsets are in the "problematic" range.
Let's always convert the offsets to avoid the performance impact of
relocations.

Fixes: a5f0edf63bdf ("drm/i915: Avoid writing relocs with addresses in non-canonical form")
Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Michel Thierry &lt;michel.thierry@intel.com&gt;
Reported-by: Michał Pyrzowski &lt;michal.pyrzowski@intel.com&gt;
Signed-off-by: Michał Winiarski &lt;michal.winiarski@intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20170207195559.18798-1-michal.winiarski@intel.com
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
(cherry picked from commit 038c95a313e4ca954ee5ab8a0c7559a646b0f462)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915: Remove overzealous fence warn on runtime suspend</title>
<updated>2017-02-08T11:27:27+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2017-02-03T12:57:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=83bf6d55c132d5c4f773e5a04149c05f4aa0c2ad'/>
<id>urn:sha1:83bf6d55c132d5c4f773e5a04149c05f4aa0c2ad</id>
<content type='text'>
The goal of the WARN was to catch when we are still actively using the
fence as we go into the runtime suspend. However, the reg-&gt;pin_count is
too coarse as it does not distinguish between exclusive ownership of the
fence register from activity.

I've not improved on the WARN, nor have we captured this WARN in an
exact igt, but it is showing up regularly in the wild:

[ 1915.935332] WARNING: CPU: 1 PID: 10861 at drivers/gpu/drm/i915/i915_gem.c:2022 i915_gem_runtime_suspend+0x116/0x130 [i915]
[ 1915.935383] WARN_ON(reg-&gt;pin_count)[ 1915.935399] Modules linked in:
 snd_hda_intel i915 drm_kms_helper vgem netconsole scsi_transport_iscsi fuse vfat fat x86_pkg_temp_thermal coretemp intel_cstate intel_uncore snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd mei_me mei serio_raw intel_rapl_perf intel_pch_thermal soundcore wmi acpi_pad i2c_algo_bit syscopyarea sysfillrect sysimgblt fb_sys_fops drm r8169 mii video [last unloaded: drm_kms_helper]
[ 1915.935785] CPU: 1 PID: 10861 Comm: kworker/1:0 Tainted: G     U  W       4.9.0-rc5+ #170
[ 1915.935799] Hardware name: LENOVO 80MX/Lenovo E31-80, BIOS DCCN34WW(V2.03) 12/01/2015
[ 1915.935822] Workqueue: pm pm_runtime_work
[ 1915.935845]  ffffc900044fbbf0 ffffffffac3220bc ffffc900044fbc40 0000000000000000
[ 1915.935890]  ffffc900044fbc30 ffffffffac059bcb 000007e6044fbc60 ffff8801626e3198
[ 1915.935937]  ffff8801626e0000 0000000000000002 ffffffffc05e5d4e 0000000000000000
[ 1915.935985] Call Trace:
[ 1915.936013]  [&lt;ffffffffac3220bc&gt;] dump_stack+0x4f/0x73
[ 1915.936038]  [&lt;ffffffffac059bcb&gt;] __warn+0xcb/0xf0
[ 1915.936060]  [&lt;ffffffffac059c4f&gt;] warn_slowpath_fmt+0x5f/0x80
[ 1915.936158]  [&lt;ffffffffc052d916&gt;] i915_gem_runtime_suspend+0x116/0x130 [i915]
[ 1915.936251]  [&lt;ffffffffc04f1c74&gt;] intel_runtime_suspend+0x64/0x280 [i915]
[ 1915.936277]  [&lt;ffffffffac0926f1&gt;] ? dequeue_entity+0x241/0xbc0
[ 1915.936298]  [&lt;ffffffffac36bb85&gt;] pci_pm_runtime_suspend+0x55/0x180
[ 1915.936317]  [&lt;ffffffffac36bb30&gt;] ? pci_pm_runtime_resume+0xa0/0xa0
[ 1915.936339]  [&lt;ffffffffac4514e2&gt;] __rpm_callback+0x32/0x70
[ 1915.936356]  [&lt;ffffffffac451544&gt;] rpm_callback+0x24/0x80
[ 1915.936375]  [&lt;ffffffffac36bb30&gt;] ? pci_pm_runtime_resume+0xa0/0xa0
[ 1915.936392]  [&lt;ffffffffac45222d&gt;] rpm_suspend+0x12d/0x680
[ 1915.936415]  [&lt;ffffffffac69f6d7&gt;] ? _raw_spin_unlock_irq+0x17/0x30
[ 1915.936435]  [&lt;ffffffffac0810b8&gt;] ? finish_task_switch+0x88/0x220
[ 1915.936455]  [&lt;ffffffffac4534bf&gt;] pm_runtime_work+0x6f/0xb0
[ 1915.936477]  [&lt;ffffffffac074353&gt;] process_one_work+0x1f3/0x4d0
[ 1915.936501]  [&lt;ffffffffac074678&gt;] worker_thread+0x48/0x4e0
[ 1915.936523]  [&lt;ffffffffac074630&gt;] ? process_one_work+0x4d0/0x4d0
[ 1915.936542]  [&lt;ffffffffac074630&gt;] ? process_one_work+0x4d0/0x4d0
[ 1915.936559]  [&lt;ffffffffac07a2c9&gt;] kthread+0xd9/0xf0
[ 1915.936580]  [&lt;ffffffffac07a1f0&gt;] ? kthread_park+0x60/0x60
[ 1915.936600]  [&lt;ffffffffac69fe62&gt;] ret_from_fork+0x22/0x30

In the case the register is pinned, it should be present and we will
need to invalidate them to be restored upon resume as we cannot expect
the owner of the pin to call get_fence prior to use after resume.

Fixes: 7c108fd8feac ("drm/i915: Move fence cancellation to runtime suspend")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98804
Reported-by: Lionel Landwerlin &lt;lionel.g.landwerlin@linux.intel.com&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: Imre Deak &lt;imre.deak@linux.intel.com&gt;
Cc: Jani Nikula &lt;jani.nikula@linux.intel.com&gt;
Cc: &lt;drm-intel-fixes@lists.freedesktop.org&gt; # v4.10-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/20170203125717.8431-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
(cherry picked from commit e0ec3ec698851a6c97a12d696407b3ff77700c23)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/bxt: Add MST support when do DPLL calculation</title>
<updated>2017-02-08T11:27:27+00:00</updated>
<author>
<name>Lee, Shawn C</name>
<email>shawn.c.lee@intel.com</email>
</author>
<published>2017-02-03T04:32:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=789ea12500e5ce3911d0a6a822277c3133451927'/>
<id>urn:sha1:789ea12500e5ce3911d0a6a822277c3133451927</id>
<content type='text'>
Add the missing INTEL_OUTPUT_DP_MST case in bxt_get_dpll()
to correctly initialize the crtc_state and port plls when
link training a DP MST monitor on BXT/APL devices.

Fixes: a277ca7dc01d ("drm/i915: Split bxt_ddi_pll_select()")
Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99572
Reviewed-by: Cooper Chiou &lt;cooper.chiou@intel.com&gt;
Reviewed-by: Gary C Wang &lt;gary.c.wang@intel.com&gt;
Reviewed-by: Ciobanu, Nathan D &lt;nathan.d.ciobanu@intel.com&gt;
Reviewed-by: Herbert, Marc &lt;marc.herbert@intel.com&gt;
Reviewed-by: Bride, Jim &lt;jim.bride@intel.com&gt;
Reviewed-by: Navare, Manasi D &lt;manasi.d.navare@intel.com&gt;
Cc: Jani Nikula &lt;jani.nikula@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.9+
Signed-off-by: Lee, Shawn C &lt;shawn.c.lee@intel.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/1486096329-6255-1-git-send-email-shawn.c.lee@intel.com
(cherry picked from commit 0aab2c721d81590012a5021a516f00666646741f)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915: don't warn about Skylake CPU - KabyPoint PCH combo</title>
<updated>2017-02-08T11:10:36+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2017-02-01T13:46:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=853277481178fdf14d1a4e9e6ac7174d6046176f'/>
<id>urn:sha1:853277481178fdf14d1a4e9e6ac7174d6046176f</id>
<content type='text'>
Apparently there are machines out there with Skylake CPU and KabyPoint
PCH. Judging from our driver code, there doesn't seem to be any code
paths that would do anything different between SunrisePoint and
KabyPoint PCHs, so it would seem okay to accept the combo without
warnings.

Fixes: 22dea0be50b2 ("drm/i915: Introduce Kabypoint PCH for Kabylake H/DT.")
References: https://lists.freedesktop.org/archives/intel-gfx/2017-February/118611.html
Reported-by: Rainer Koenig &lt;Rainer.Koenig@ts.fujitsu.com&gt;
Cc: Rainer Koenig &lt;Rainer.Koenig@ts.fujitsu.com&gt;
Cc: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.8+
Reviewed-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/1485956769-26015-1-git-send-email-jani.nikula@intel.com
(cherry picked from commit 3aac4acb89710fe782c9e78e7b1febf76e112c6c)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
</content>
</entry>
</feed>
