Pull drm fixes from Dave Airlie: "This is just a regular fixes pull apart from the qxl one, it has radeon and intel bits in it, The intel fixes are for a regression with the RC6 fix and a 3.10 hdmi regression, whereas radeon is more DPM fixes, a few lockup fixes and some rn50/r100 DAC fixes" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/radeon/dpm: fix r600_enable_sclk_control() drm/radeon/dpm: implement force performance levels for rv6xx drm/radeon/dpm: fix displaygap programming on rv6xx drm/radeon/dpm: fix a typo in the rv6xx mclk setup drm/i915: initialize gt_lock early with other spin locks drm/i915: fix hdmi portclock limits drm/radeon: fix combios tables on older cards drm/radeon: improve dac adjust heuristics for legacy pdac drm/radeon: Another card with wrong primary dac adj drm/radeon: fix endian issues with DP handling (v3) drm/radeon/vm: only align the pt base to 32k drm/radeon: wait for 3D idle before using CP DMA
Pull qxl drm fixes from Dave Airlie: "Okay as I warned, the qxl driver was running a bit free and loose with its ttm object reservations and the new lockdep enabled reservation tracking shone a bright light into it, it also with the new reservations mutexes hits a possible deadlock during boot. The first patch is a real fix to render the console correctly as the driver used to just drop irq renderering as too hard, this also fixes a sleeping while atomic warning. The other two patches are the big ugly ones that redo how the driver allocates objects and reserves them and makes things all work properly, I've tested this in a VM, and compared to the current code which hits a lockdep warning and the sleep while atomic warning before failing. So sorry this is coming in late, I should have tested qxl before merging the mutex code, but I'd rather just fix qxl with this than revert the reservations code at this point" * 'qxl-fixes' of git://people.freedesktop.org/~airlied/linux: qxl: convert qxl driver to proper use for reservations qxl: allow creation of pre-pinned objects and use for releases. drm/qxl: add delayed fb operations
Pull ACPI and power management fixes from Rafael Wysocki:
"These are just two fixes, a revert of the would-be backlight fix that
didn't work and an intel_pstate fix for two problems related to
maximum P-state selection.
Specifics:
- Revert of the ACPI video commit that I hoped would help fix
backlight problems related to Windows 8 compatibility on some
systems. Unfortunately, it turned out to cause problems to happen
too.
- Fix for two problems in intel_pstate, a possible failure to respond
to a load change on a quiet system and a possible failure to select
the highest available P-state on some systems. From Dirk
Brandewie"
* tag 'pm+acpi-3.11-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
Revert "ACPI / video / i915: No ACPI backlight if firmware expects Windows 8"
cpufreq / intel_pstate: Change to scale off of max P-state
We attempted to address a regression introduced by commit a57f7f9 (ACPICA: Add Windows8/Server2012 string for _OSI method.) after which ACPI video backlight support doesn't work on a number of systems, because the relevant AML methods in the ACPI tables in their BIOSes become useless after the BIOS has been told that the OS is compatible with Windows 8. That problem is tracked by the bug entry at: https://bugzilla.kernel.org/show_bug.cgi?id=51231 Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware expects Windows 8) introduced for this purpose essentially prevented the ACPI backlight support from being used if the BIOS had been told that the OS was compatible with Windows 8 and the i915 driver was loaded, in which case the backlight would always be handled by i915. Unfortunately, however, that turned out to cause problems with backlight to appear on multiple systems with symptoms indicating that i915 was unable to control the backlight on those systems as expected. For this reason, revert commit 8c5bd7a, but leave the function acpi_video_backlight_quirks() introduced by it, because another commit on top of it uses that function. References: https://lkml.org/lkml/2013/7/21/119 References: https://lkml.org/lkml/2013/7/22/261 References: https://lkml.org/lkml/2013/7/23/429 References: https://lkml.org/lkml/2013/7/23/459 References: https://lkml.org/lkml/2013/7/23/81 References: https://lkml.org/lkml/2013/7/24/27 Reported-and-tested-by: James Hogan <james@albanarts.com> Reported-and-tested-by: Kamal Mostafa <kamal@canonical.com> Reported-and-tested-by: Jörg Otte <jrg.otte@gmail.com> Reported-and-tested-by: Steven Newbury <steve@snewbury.org.uk> Reported-by: Martin Steigerwald <Martin@lichtvoll.de> Reported-by: Kalle Valo <kvalo@adurom.com> Tested-by: Joerg Platte <jplatte@naasa.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Brown-paper-bag pull request here. The snb rc6 fix from the last pull broke forcewake BIOS dirt cleanup, which with fixed. But that fix broke the spinlock init sequence, which results in an ugly BUG when spinlock debugging is enabled :( So I get to throw another patch at cc: stable to fix up the mess ... * tag 'drm-intel-fixes-2013-07-25' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: initialize gt_lock early with other spin locks drm/i915: fix hdmi portclock limits
Actually program the correct register to enable engine clock scaling control. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Allows you to limit the selected power levels via sysfs. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Need to use the driver state rather than the register state since the displays may not be enabled when the power state is programmed. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Need to set high for the last two entries. Looks like a copy and paste typo. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
commit 181d1b9e31c668259d3798c521672afb8edd355c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Jul 21 13:16:24 2013 +0200
drm/i915: fix up gt init sequence fallout
moved dev_priv->gt_lock initialization after use. Do the initialization
much earlier with other spin lock initializations.
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Cc: stable@vger.kernel.org (since the regressing patch is also cc: stable)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>