kernel/linux.git/drivers/gpu/drm, branch v3.14.43

drm/radeon: more strictly validate the UVD codec

2015-05-17T16:53:50+00:00

commit d52cdfa4a0c6406bbfb33206341eaf1fb1555994 upstream. MPEG 2/4 are only supported since UVD3. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/radeon: make UVD handle checking more strict

2015-05-17T16:53:50+00:00

commit a1b403da70e038ca6c6c6fe434d1d873546873a3 upstream. Invalid messages can crash the hw otherwise. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/radeon: disable semaphores for UVD V1 (v2)

2015-05-17T16:53:50+00:00

commit 013ead48a843442e63b9426e3bd5df18ca5d054a upstream. Hardware doesn't seem to work correctly, just block userspace in this case. v2: add missing defines Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=85320 Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/i915: Add missing MacBook Pro models with dual channel LVDS

2015-05-17T16:53:50+00:00

commit 3916e3fd81021fb795bfbdb17f375b6b3685bced upstream. Single channel LVDS maxes out at 112 MHz. The 15" pre-retina models shipped with 1440x900 (106 MHz) by default or 1680x1050 (119 MHz) as a BTO option, both versions used dual channel LVDS even though the smaller one would have fit into a single channel. Notes: Bug report showing that the MacBookPro8,2 with 1440x900 uses dual channel LVDS (this lead to it being hardcoded in intel_lvds.c by Daniel Vetter with commit 618563e3945b9d0864154bab3c607865b557cecc): https://bugzilla.kernel.org/show_bug.cgi?id=42842 If i915.lvds_channel_mode=2 is missing even though the machine needs it, every other vertical line is white and consequently, only the left half of the screen is visible (verified by myself on a MacBookPro9,1). Forum posting concerning a MacBookPro6,2 with 1440x900, author is using i915.lvds_channel_mode=2 on the kernel command line, proving that the machine uses dual channels: https://bbs.archlinux.org/viewtopic.php?id=185770 Chi Mei N154C6-L04 with 1440x900 is a replacement panel for all MacBook Pro "A1286" models, and that model number encompasses the MacBookPro6,2 / 8,2 / 9,1. Page 17 of the panel's datasheet shows it's driven with dual channel LVDS: http://www.ebay.com/itm/-/400690878560 http://www.everymac.com/ultimate-mac-lookup/?search_keywords=A1286 http://www.taopanel.com/chimei/datasheet/N154C6-L04.pdf Those three 15" models, MacBookPro6,2 / 8,2 / 9,1, are the only ones with i915 graphics and dual channel LVDS, so that list should be complete. And the 8,2 is already in intel_lvds.c. Possible motivation to use dual channel LVDS even on the 1440x900 models: Reduce the number of different parts, i.e. use identical logic boards and display cabling on both versions and the only differing component is the panel. Signed-off-by: Lukas Wunner Acked-by: Jani Nikula [Jani: included notes in the commit message for posterity] Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5

2015-05-13T12:16:58+00:00

commit cd17e02ff4db58ec32d35cf331c705d295779930 upstream. Seems to have problems with high mclks. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/i915: cope with large i2c transfers

2015-05-06T19:59:19+00:00

commit 9535c4757b881e06fae72a857485ad57c422b8d2 upstream. The hardware, according to the specs, is limited to 256 byte transfers, and current driver has no protections in case users attempt to do larger transfers. The code will just stomp over status register and mayhem ensues. Let's split larger transfers into digestable chunks. Doing this allows Atmel MXT driver on Pixel 1 function properly (it hasn't since commit 9d8dc3e529a19e427fd379118acd132520935c5d "Input: atmel_mxt_ts - implement T44 message handling" which tries to consume multiple touchscreen/touchpad reports in a single transaction). Reviewed-by: Chris Wilson Signed-off-by: Dmitry Torokhov Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix doublescan modes (v2)

2015-05-06T19:59:19+00:00

commit fd99a0943ffaa0320ea4f69d09ed188f950c0432 upstream. Use the correct flags for atom. v2: handle DRM_MODE_FLAG_DBLCLK Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/msm: use componentised device support

2015-05-06T19:59:15+00:00

commit 060530f1ea6740eb767085008d183f89ccdd289c upstream. Signed-off-by: Rob Clark [Guenter Roeck: backported to 3.14] Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

radeon: Do not directly dereference pointers to BIOS area.

2015-04-19T08:11:07+00:00

commit f2c9e560b406f2f6b14b345c7da33467dee9cdf2 upstream. Use readb() and memcpy_fromio() accessors instead. Reviewed-by: Christian König Signed-off-by: David S. Miller Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Reorder device takedown somewhat

2015-03-26T14:06:56+00:00

commit 3458390b9f0ba784481d23134798faee27b5f16f upstream. To take down the MOB and GMR memory types, the driver may have to issue fence objects and thus make sure that the fence manager is taken down after those memory types. Reorder device init accordingly. Signed-off-by: Thomas Hellstrom Reviewed-by: Sinclair Yeh Signed-off-by: Greg Kroah-Hartman