user/sven/linux.git/drivers/gpu/drm, branch v3.16.51

drm/ttm: Fix accounting error when fail to get pages for pool

2017-11-26T13:50:20Z

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 Reviewed-by: Christian König Reviewed-by: Monk Liu Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings

drm/i915: cleanup some indenting

2017-11-11T13:33:55Z

commit ba0635ffb7665d76715b43ae8144e014a90c1e63 upstream. Static checkers complain that we should probably add curly braces because, from the indenting, it looks like seq_printf() should be inside the list_for_each_entry() loop. But the code is actually correct, it's just the indenting which is off. Besides fixing the indenting on seq_printf(), I did add curly braces, because generally mult-line indents should have curly braces to make them more readable. The unintended indent was left behind and not unindented in commit d7f46fc4e7323887494db13f063a8e59861fefb0 Author: Ben Widawsky Date: Fri Dec 6 14:10:55 2013 -0800 drm/i915: Make pin count per VMA Signed-off-by: Dan Carpenter Reviewed-by: Jani Nikula Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman Signed-off-by: Arnd Bergmann Signed-off-by: Ben Hutchings

drm: Release driver tracking before making the object available again

2017-11-11T13:33:23Z

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 Cc: David Airlie Cc: Daniel Vetter Cc: Rob Clark Cc: Ville Syrjälä Cc: Thierry Reding Reviewed-by: Daniel Vetter Signed-off-by: Joonas Lahtinen Link: https://patchwork.freedesktop.org/patch/msgid/20170819120558.6465-1-chris@chris-wilson.co.uk [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings

drm/msm: fix an integer overflow test

2017-11-11T13:33:13Z

commit 65e93108891e571f177c202add9288eda9ac4100 upstream. We recently added an integer overflow check but it needs an additional tweak to work properly on 32 bit systems. The problem is that we're doing the right hand side of the assignment as type unsigned long so the max it will have an integer overflow instead of being larger than SIZE_MAX. That means the "sz > SIZE_MAX" condition is never true even on 32 bit systems. We need to first cast it to u64 and then do the math. Fixes: 4a630fadbb29 ("drm/msm: Fix potential buffer overflow issue") Signed-off-by: Dan Carpenter Acked-by: Jordan Crouse Signed-off-by: Rob Clark [bwh: Backported to 3.16: submit_create() only supports a variable number of bos] Signed-off-by: Ben Hutchings

drm/msm: Fix potential buffer overflow issue

2017-11-11T13:33:12Z

commit 4a630fadbb29d9efaedb525f1a8f7449ad107641 upstream. In function submit_create, if nr_cmds or nr_bos is assigned with negative value, the allocated buffer may be small than intended. Using this buffer will lead to buffer overflow issue. Signed-off-by: Kasin Li Signed-off-by: Jordan Crouse Signed-off-by: Rob Clark [bwh: Backported to 3.16: submit_create() only supports a variable number of bos] Signed-off-by: Ben Hutchings

drm/vmwgfx: Fix gcc-7.1.1 warning

2017-11-11T13:32:59Z

commit fcfffdd8f98ac305285dca568b5065ef86be6458 upstream. The current code does not look correct, and the reason for it is probably lost. Since this now generates a compiler warning, fix it to what makes sense. Reported-by: Arnd Bergmann Reported-by: Linus Torvalds Signed-off-by: Sinclair Yeh Reviewed-by: Brian Paul Signed-off-by: Ben Hutchings

drm/irq: BUG_ON() -> WARN_ON()

2017-10-12T14:28:15Z

commit 7f907bf284ba7bb8d271f094b226699d3fef2142 upstream. Let's make things a bit easier to debug when things go bad (potentially under console_lock). Signed-off-by: Rob Clark Reviewed-by: Michel Dänzer Signed-off-by: Dave Airlie [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings

drm/radeon: Fix eDP for single-display iMac10,1 (v2)

2017-10-12T14:28:03Z

commit 564d8a2cf3abf16575af48bdc3e86e92ee8a617d upstream. The late 2009, 27 inch Apple iMac10,1 has an internal eDP display and an external Mini- Displayport output, driven by a DCE-3.2, RV730 Radeon Mobility HD-4670. The machine worked fine in a dual-display setup with eDP panel + externally connected HDMI or DVI-D digital display sink, connected via MiniDP to DVI or HDMI adapter. However, booting the machine single-display with only eDP panel results in a completely black display - even backlight powering off, as soon as the radeon modesetting driver loads. This patch fixes the single dispay eDP case by assigning encoders based on dig->linkb, similar to DCE-4+. While this should not be generally necessary (Alex: "...atom on normal boards should be able to handle any mapping."), Apple seems to use some special routing here. One remaining problem not solved by this patch is that an external Minidisplayport->DP sink does still not work on iMac10,1, whereas external DVI and HDMI sinks continue to work. The problem affects at least all tested kernels since Linux 3.13 - didn't test earlier kernels, so backporting to stable probably makes sense. v2: With the original patch from 2016, Alex was worried it will break other DCE3.2 systems. Use dmi_match() to apply this special encoder assignment only for the Apple iMac 10,1 from late 2009. Signed-off-by: Mario Kleiner Cc: Alex Deucher Cc: Michel Dänzer Signed-off-by: Alex Deucher [bwh: Backported to 3.16: - Return the selected encoder rather than assiging it - Adjust context] Signed-off-by: Ben Hutchings

drm/i915: Disable MSI for all pre-gen5

2017-10-12T14:28:00Z

commit ce3f7163e4ce8fd583dcb36b6ee6b81fd1b419ae upstream. We have pretty clear evidence that MSIs are getting lost on g4x and somehow the interrupt logic doesn't seem to recover from that state even if we try hard to clear the IIR. Disabling IER around the normal IIR clearing in the irq handler isn't sufficient to avoid this, so the problem really seems to be further up the interrupt chain. This should guarantee that there's always an edge if any IIR bits are set after the interrupt handler is done, which should normally guarantee that the CPU interrupt is generated. That approach seems to work perfectly on VLV/CHV, but apparently not on g4x. MSI is documented to be broken on 965gm at least. The chipset spec says MSI is defeatured because interrupts can be delayed or lost, which fits well with what we're seeing on g4x. Previously we've already disabled GMBUS interrupts on g4x because somehow GMBUS manages to raise legacy interrupts even when MSI is enabled. Since there's such widespread MSI breakahge all over in the pre-gen5 land let's just give up on MSI on these platforms. Seqno reporting might be negatively affected by this since the legcy interrupts aren't guaranteed to be ordered with the seqno writes, whereas MSI interrupts may be? But an occasioanlly missed seqno seems like a small price to pay for generally working interrupts. Cc: Diego Viola Tested-by: Diego Viola Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261 Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/20170626203051.28480-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter (cherry picked from commit e38c2da01f76cca82b59ca612529b81df82a7cc7) Signed-off-by: Jani Nikula [bwh: Backported to 3.16: - Open-code INTEL_GEN() - Adjust filename, context] Signed-off-by: Ben Hutchings

drm/msm/hdmi: Use bitwise operators when building register values

2017-10-12T14:27:50Z

commit ffe8f53f9cc73fb25c8f78d4aed7ddf285503a60 upstream. Commit c0c0d9eeeb8d ("drm/msm: hdmi audio support") uses logical OR operators to build up a value to be written in the REG_HDMI_AUDIO_INFO0 and REG_HDMI_AUDIO_INFO1 registers when it should have used bitwise operators. Signed-off-by: Liviu Dudau Fixes: c0c0d9eeeb8d ("drm/msm: hdmi audio support") Signed-off-by: Rob Clark Signed-off-by: Ben Hutchings