<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu, branch v4.4.87</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.4.87</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.4.87'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2017-09-07T06:34:09+00:00</updated>
<entry>
<title>drm/ttm: Fix accounting error when fail to get pages for pool</title>
<updated>2017-09-07T06:34:09+00:00</updated>
<author>
<name>Xiangliang.Yu</name>
<email>Xiangliang.Yu@amd.com</email>
</author>
<published>2017-08-16T06:25:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=94183009ac0e58972c2b4bf1bf13b61b1a23971b'/>
<id>urn:sha1:94183009ac0e58972c2b4bf1bf13b61b1a23971b</id>
<content type='text'>
commit 9afae2719273fa1d406829bf3498f82dbdba71c7 upstream.

When fail to get needed page for pool, need to put allocated pages
into pool. But current code has a miscalculation of allocated pages,
correct it.

Signed-off-by: Xiangliang.Yu &lt;Xiangliang.Yu@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Reviewed-by: Monk Liu &lt;monk.liu@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 compiler warning in drivers/gpu/drm/i915/intel_uncore.c</title>
<updated>2017-09-02T05:06:53+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2017-08-31T06:30:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c81c4d453edf242af644f7e71f673fc7632f337c'/>
<id>urn:sha1:c81c4d453edf242af644f7e71f673fc7632f337c</id>
<content type='text'>
When building with gcc-7, the following warning happens:

drivers/gpu/drm/i915/intel_uncore.c: In function ‘hsw_unclaimed_reg_detect’:
drivers/gpu/drm/i915/intel_uncore.c:638:36: warning: decrement of a boolean expression [-Wbool-operation]
   i915.mmio_debug = mmio_debug_once--;
                                    ^~

As it's really not wise to -- on a boolean value.

Commit 7571494004d8 ("drm/i915: Do one shot unclaimed mmio detection
less frequently") which showed up in 4.6-rc1 does solve this issue, by
rewriting the mmio detection logic, but that isn't really good to
backport to 4.4-stable, so just fix up the obvious logic here to do the
right thing.

Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Paulo Zanoni &lt;przanoni@gmail.com&gt;
Cc: Mika Kuoppala &lt;mika.kuoppala@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm: rcar-du: Fix H/V sync signal polarity configuration</title>
<updated>2017-08-30T08:19:24+00:00</updated>
<author>
<name>Koji Matsuoka</name>
<email>koji.matsuoka.xm@renesas.com</email>
</author>
<published>2016-05-16T02:28:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0d2b7767611fc1762140614452e21d558aa5e462'/>
<id>urn:sha1:0d2b7767611fc1762140614452e21d558aa5e462</id>
<content type='text'>
commit fd1adef3bff0663c5ac31b45bc4a05fafd43d19b upstream.

The VSL and HSL bits in the DSMR register set the corresponding
horizontal and vertical sync signal polarity to active high. The code
got it the wrong way around, fix it.

Signed-off-by: Koji Matsuoka &lt;koji.matsuoka.xm@renesas.com&gt;
Signed-off-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Thong Ho &lt;thong.ho.px@rvc.renesas.com&gt;
Signed-off-by: Nhan Nguyen &lt;nhan.nguyen.yb@renesas.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm: rcar-du: Fix display timing controller parameter</title>
<updated>2017-08-30T08:19:24+00:00</updated>
<author>
<name>Koji Matsuoka</name>
<email>koji.matsuoka.xm@renesas.com</email>
</author>
<published>2016-04-18T07:31:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=64f3c534e7acab041e39cb2429b54d8c5141e89a'/>
<id>urn:sha1:64f3c534e7acab041e39cb2429b54d8c5141e89a</id>
<content type='text'>
commit 9cdced8a39c04cf798ddb2a27cb5952f7d39f633 upstream.

There is a bug in the setting of the DES (Display Enable Signal)
register. This current setting occurs 1 dot left shift. The DES
register should be set minus one value about the specifying value
with H/W specification. This patch corrects it.

Signed-off-by: Koji Matsuoka &lt;koji.matsuoka.xm@renesas.com&gt;
Signed-off-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Thong Ho &lt;thong.ho.px@rvc.renesas.com&gt;
Signed-off-by: Nhan Nguyen &lt;nhan.nguyen.yb@renesas.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm: rcar-du: Fix crash in encoder failure error path</title>
<updated>2017-08-30T08:19:24+00:00</updated>
<author>
<name>Laurent Pinchart</name>
<email>laurent.pinchart+renesas@ideasonboard.com</email>
</author>
<published>2016-10-03T17:03:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fbf583912145e9096815a14f1554f44cfaab7059'/>
<id>urn:sha1:fbf583912145e9096815a14f1554f44cfaab7059</id>
<content type='text'>
commit 05ee29e94acf0d4b3998c3f93374952de8f90176 upstream.

When an encoder fails to initialize the driver prints an error message
to the kernel log. The message contains the name of the encoder's DT
node, which is NULL for internal encoders. Use the of_node_full_name()
macro to avoid dereferencing a NULL pointer, print the output number to
add more context to the error, and make sure we still own a reference to
the encoder's DT node by delaying the of_node_put() call.

Signed-off-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Reviewed-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
Signed-off-by: Thong Ho &lt;thong.ho.px@rvc.renesas.com&gt;
Signed-off-by: Nhan Nguyen &lt;nhan.nguyen.yb@renesas.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm: rcar-du: lvds: Rename PLLEN bit to PLLON</title>
<updated>2017-08-30T08:19:24+00:00</updated>
<author>
<name>Laurent Pinchart</name>
<email>laurent.pinchart+renesas@ideasonboard.com</email>
</author>
<published>2015-09-07T12:28:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=766a097cbfea9a2527d881b67b835bf223d5f79d'/>
<id>urn:sha1:766a097cbfea9a2527d881b67b835bf223d5f79d</id>
<content type='text'>
commit 82e7c5e4964545352accff4b44bbcaa2c38e7fc1 upstream.

The bit is named PLLON in the datasheet, rename it.

Signed-off-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Thong Ho &lt;thong.ho.px@rvc.renesas.com&gt;
Signed-off-by: Nhan Nguyen &lt;nhan.nguyen.yb@renesas.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm: rcar-du: lvds: Fix PLL frequency-related configuration</title>
<updated>2017-08-30T08:19:23+00:00</updated>
<author>
<name>Laurent Pinchart</name>
<email>laurent.pinchart+renesas@ideasonboard.com</email>
</author>
<published>2015-09-07T13:03:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2b60c153ff3d922e0be3fa9dbe3d53fbc8c78cdb'/>
<id>urn:sha1:2b60c153ff3d922e0be3fa9dbe3d53fbc8c78cdb</id>
<content type='text'>
commit 5e1ac3bdc6bbb4f378251b87625b8acfbfc4ae82 upstream.

The frequency checks don't match the datasheet, fix them.

Signed-off-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Thong Ho &lt;thong.ho.px@rvc.renesas.com&gt;
Signed-off-by: Nhan Nguyen &lt;nhan.nguyen.yb@renesas.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/atomic: If the atomic check fails, return its value first</title>
<updated>2017-08-30T08:19:23+00:00</updated>
<author>
<name>Maarten Lankhorst</name>
<email>maarten.lankhorst@linux.intel.com</email>
</author>
<published>2017-08-15T09:57:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3416ee45a8cbeb5bc4b13a754873fbb26a27dccb'/>
<id>urn:sha1:3416ee45a8cbeb5bc4b13a754873fbb26a27dccb</id>
<content type='text'>
commit a0ffc51e20e90e0c1c2491de2b4b03f48b6caaba upstream.

The last part of drm_atomic_check_only is testing whether we need to
fail with -EINVAL when modeset is not allowed, but forgets to return
the value when atomic_check() fails first.

This results in -EDEADLK being replaced by -EINVAL, and the sanity
check in drm_modeset_drop_locks kicks in:

[  308.531734] ------------[ cut here ]------------
[  308.531791] WARNING: CPU: 0 PID: 1886 at drivers/gpu/drm/drm_modeset_lock.c:217 drm_modeset_drop_locks+0x33/0xc0 [drm]
[  308.531828] Modules linked in:
[  308.532050] CPU: 0 PID: 1886 Comm: kms_atomic Tainted: G     U  W 4.13.0-rc5-patser+ #5225
[  308.532082] Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015
[  308.532124] task: ffff8800cd9dae00 task.stack: ffff8800ca3b8000
[  308.532168] RIP: 0010:drm_modeset_drop_locks+0x33/0xc0 [drm]
[  308.532189] RSP: 0018:ffff8800ca3bf980 EFLAGS: 00010282
[  308.532211] RAX: dffffc0000000000 RBX: ffff8800ca3bfaf8 RCX: 0000000013a171e6
[  308.532235] RDX: 1ffff10019477f69 RSI: ffffffffa8ba4fa0 RDI: ffff8800ca3bfb48
[  308.532258] RBP: ffff8800ca3bf998 R08: 0000000000000000 R09: 0000000000000003
[  308.532281] R10: 0000000079dbe066 R11: 00000000f760b34b R12: 0000000000000001
[  308.532304] R13: dffffc0000000000 R14: 00000000ffffffea R15: ffff880096889680
[  308.532328] FS:  00007ff00959cec0(0000) GS:ffff8800d4e00000(0000) knlGS:0000000000000000
[  308.532359] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  308.532380] CR2: 0000000000000008 CR3: 00000000ca2e3000 CR4: 00000000003406f0
[  308.532402] Call Trace:
[  308.532440]  drm_mode_atomic_ioctl+0x19fa/0x1c00 [drm]
[  308.532488]  ? drm_atomic_set_property+0x1220/0x1220 [drm]
[  308.532565]  ? avc_has_extended_perms+0xc39/0xff0
[  308.532593]  ? lock_downgrade+0x610/0x610
[  308.532640]  ? drm_atomic_set_property+0x1220/0x1220 [drm]
[  308.532680]  drm_ioctl_kernel+0x154/0x1a0 [drm]
[  308.532755]  drm_ioctl+0x624/0x8f0 [drm]
[  308.532858]  ? drm_atomic_set_property+0x1220/0x1220 [drm]
[  308.532976]  ? drm_getunique+0x210/0x210 [drm]
[  308.533061]  do_vfs_ioctl+0xd92/0xe40
[  308.533121]  ? ioctl_preallocate+0x1b0/0x1b0
[  308.533160]  ? selinux_capable+0x20/0x20
[  308.533191]  ? do_fcntl+0x1b1/0xbf0
[  308.533219]  ? kasan_slab_free+0xa2/0xb0
[  308.533249]  ? f_getown+0x4b/0xa0
[  308.533278]  ? putname+0xcf/0xe0
[  308.533309]  ? security_file_ioctl+0x57/0x90
[  308.533342]  SyS_ioctl+0x4e/0x80
[  308.533374]  entry_SYSCALL_64_fastpath+0x18/0xad
[  308.533405] RIP: 0033:0x7ff00779e4d7
[  308.533431] RSP: 002b:00007fff66a043d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[  308.533481] RAX: ffffffffffffffda RBX: 000000e7c7ca5910 RCX: 00007ff00779e4d7
[  308.533560] RDX: 00007fff66a04430 RSI: 00000000c03864bc RDI: 0000000000000003
[  308.533608] RBP: 00007ff007a5fb00 R08: 000000e7c7ca4620 R09: 000000e7c7ca5e60
[  308.533647] R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000070
[  308.533685] R13: 0000000000000000 R14: 0000000000000000 R15: 000000e7c7ca5930
[  308.533770] Code: ff df 55 48 89 e5 41 55 41 54 53 48 89 fb 48 83 c7
50 48 89 fa 48 c1 ea 03 80 3c 02 00 74 05 e8 94 d4 16 e7 48 83 7b 50 00
74 02 &lt;0f&gt; ff 4c 8d 6b 58 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1
[  308.534086] ---[ end trace 77f11e53b1df44ad ]---

Solve this by adding the missing return.

This is also a bugfix because we could end up rejecting updates with
-EINVAL because of a early -EDEADLK, while if atomic_check ran to
completion it might have downgraded the modeset to a fastset.

Signed-off-by: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Testcase: kms_atomic
Link: https://patchwork.freedesktop.org/patch/msgid/20170815095706.23624-1-maarten.lankhorst@linux.intel.com
Fixes: d34f20d6e2f2 ("drm: Atomic modeset ioctl")
Reviewed-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: Release driver tracking before making the object available again</title>
<updated>2017-08-30T08:19:23+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2017-08-19T12:05:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2a9d7664ffb2c223c488058ee6bee61512db9396'/>
<id>urn:sha1:2a9d7664ffb2c223c488058ee6bee61512db9396</id>
<content type='text'>
commit fe4600a548f2763dec91b3b27a1245c370ceee2a upstream.

This is the same bug as we fixed in commit f6cd7daecff5 ("drm: Release
driver references to handle before making it available again"), but now
the exposure is via the PRIME lookup tables. If we remove the
object/handle from the PRIME lut, then a new request for the same
object/fd will generate a new handle, thus for a short window that
object is known to userspace by two different handles. Fix this by
releasing the driver tracking before PRIME.

Fixes: 0ff926c7d4f0 ("drm/prime: add exported buffers to current fprivs
imported buffer list (v2)")
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: David Airlie &lt;airlied@linux.ie&gt;
Cc: Daniel Vetter &lt;daniel.vetter@intel.com&gt;
Cc: Rob Clark &lt;robdclark@gmail.com&gt;
Cc: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Cc: Thierry Reding &lt;treding@nvidia.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20170819120558.6465-1-chris@chris-wilson.co.uk
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/virtio: fix framebuffer sparse warning</title>
<updated>2017-08-11T16:08:58+00:00</updated>
<author>
<name>Gerd Hoffmann</name>
<email>kraxel@redhat.com</email>
</author>
<published>2016-11-28T07:52:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c9e4ee445752ecd97c839ffa7e08146a614576dd'/>
<id>urn:sha1:c9e4ee445752ecd97c839ffa7e08146a614576dd</id>
<content type='text'>
[ Upstream commit 71d3f6ef7f5af38dea2975ec5715c88bae92e92d ]

virtio uses normal ram as backing storage for the framebuffer, so we
should assign the address to new screen_buffer (added by commit
17a7b0b4d9749f80d365d7baff5dec2f54b0e992) instead of screen_base.

Reported-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
