linux/drivers, branch v3.10.15

drm/i915: fix gen4 digital port hotplug definitions

2013-10-05T14:13:12Z

commit 0ce99f749b3834edeb500e17d6ad17e86b60ff83 upstream. Apparently Bspec is wrong in this case here even for gm45. Note that Bspec is horribly misguided on i965g/gm, so we don't have any other data points besides that it seems to make machines work better. With this changes all the bits in PORT_HOTPLUG_STAT for the digital ports are ordered the same way. This seems to agree with what register dumps from the hpd storm handling code shows, where the LIVE bit and the short/long pulse STATUS bits light up at the same time with this enumeration (but no with the one from Bspec). Also tested on my gm45 which has two DP+ ports, and everything seems to still work as expected. References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg23054.html Cc: Egbert Eich Cc: Jan Niggemann Tested-by: Jan Niggemann [danvet: Add a big warning that Bspec seems to be wrong for these bits, suggested by Jani.] Acked-by: Jani Nikula Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

hwmon: (applesmc) Check key count before proceeding

2013-10-05T14:13:12Z

commit 5f4513864304672e6ea9eac60583eeac32e679f2 upstream. After reports from Chris and Josh Boyer of a rare crash in applesmc, Guenter pointed at the initialization problem fixed below. The patch has not been verified to fix the crash, but should be applied regardless. Reported-by: Suggested-by: Guenter Roeck Signed-off-by: Henrik Rydberg Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix hdmi audio on DCE3.0/3.1 asics

2013-10-05T14:13:12Z

commit 58d327da9721f7a0f6e46c8dfa5cc5546fd7078a upstream. These asics seem to use a mix of the DCE2.x and DCE3.2 audio interfaces despite what the register spec says. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=69729 https://bugs.freedesktop.org/show_bug.cgi?id=69671 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/radeon: add missing hdmi callbacks for rv6xx

2013-10-05T14:13:12Z

commit 99d79aa2f3b7729e7290e8bda5d0dd8b0240ec62 upstream. When dpm was merged, I added a new asic struct for rv6xx, but it never got properly updated when the hdmi callbacks were added due to the two patch sets being developed in parallel. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=69729 Signed-off-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Greg Kroah-Hartman

drm/radeon: disable tests/benchmarks if accel is disabled

2013-10-05T14:13:12Z

commit 4a1132a023eb48cf10522d84c5908d43b612c041 upstream. The tests are only usable if the acceleration engines have been successfully initialized. Based on an initial patch from: Alex Ivanov Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/radeon: Make r100_cp_ring_info() and radeon_ring_gfx() safe (v2)

2013-10-05T14:13:12Z

commit 0eb3448aa6b31fbf24c31756aba7940cac5ad6b8 upstream. Prevent NULL pointer dereference in case when radeon_ring_fini() did it's job. Reading of r100_cp_ring_info and radeon_ring_gfx debugfs entries will lead to a KP if ring buffer was deallocated, e.g. on failed ring test. Seen on PA-RISC machine having "radeon: ring test failed (scratch(0x8504)=0xCAFEDEAD)" issue. v2: agd5f: add some parens around ring->ready check Signed-off-by: Alex Ivanov Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/radeon: avoid UVD corruption on AGP cards using GPU gart

2013-10-05T14:13:12Z

commit 4ca5a6cba53e13b8fd153b0762b4128fab6a3cfb upstream. If the user has forced the driver to use the internal GPU gart rather than AGP on an AGP card, force the buffers to vram as well. Signed-off-by: Alex Deucher Reviewed-by: Christian König Tested-by: Dieter Nützel Signed-off-by: Greg Kroah-Hartman

drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER

2013-10-05T14:13:11Z

commit 8d16f258217f2f583af1fd57c5144aa4bbe73e48 upstream. There is no clear cut rules or specs for the retry interval, as there are many factors that affect overall response time. Increase the interval, and even more so on branch devices which may have limited i2c bit rates. Signed-off-by: Jani Nikula Reference: https://bugs.freedesktop.org/show_bug.cgi?id=60263 Tested-by: Nicolas Suzor Reviewed-by: Todd Previte Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: preserve pipe A quirk in i9xx_set_pipeconf

2013-10-05T14:13:11Z

commit 67c72a12254101d4e8d9b9f3a02646ba0be84a2d upstream. This regression has been introduced in commit 9f11a9e4e50006b615ba94722dfc33ced89664cf Author: Daniel Vetter Date: Thu Jun 13 00:54:58 2013 +0200 drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms Ville brough up the idea that this is just the pipe A quirk gone wrong. Note that after resume the bios might or might not have enabled pipe A already. We have a bit of magic to make sure that on resume we set up a decent mode for pipe A, but I fear if I just smash pipe A to always on we'd enable it in a bogus state and hang the hw. Hence the readback. v2: Clarify the logic a bit as suggested by Chris. Also amend the commit message to clarify why we don't unconditionally enable the pipe. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66462 References: https://lkml.org/lkml/2013/8/26/238 Cc: Meelis Roos Cc: Chris Wilson Cc: Ville Syrjälä Reviewed-by: Chris Wilson [danvet: Use |= instead of = as suggested by Chris.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

dm-raid: silence compiler warning on rebuilds_per_group.

2013-10-05T14:13:11Z

commit 3f6bbd3ffd7b733dd705e494663e5761aa2cb9c1 upstream. This doesn't really need to be initialised, but it doesn't hurt, silences the compiler, and as it is a counter it makes sense for it to start at zero. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman