- 13 Jun, 2014 1 commit
-
-
Tom O'Rourke authored
Correct a merge mishap in commit e4443e45 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Apr 9 13:28:41 2014 +0300 drm/i915/chv: Add a bunch of pre production workarounds Remove the the chv specific workarounds from bdw code, specifically gen8_enable_rps(). Signed-off-by:
Tom O'Rourke <Tom.O'Rourke@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> [Jani: extract hunk #1 for 3.16 from Tom's patch, clarify commit message] Signed-off-by:
Jani Nikula <jani.nikula@intel.com> --- All, I intend to push this to drm-intel-fixes, any objections? Jani.
-
- 11 Jun, 2014 39 commits
-
-
Jani Nikula authored
vt/vgacon fixes to avoid hangs, unclaimed register errors on module load, reload: vt: Fix replacement console check when unbinding vt: Fix up unregistration of vt drivers vt: Don't ignore unbind errors in vt_unbind drm/i915: Fixup global gtt cleanup drm/i915: Kick out vga console Link: http://lkml.kernel.org/r/1401980308-5116-1-git-send-email-daniel.vetter@ffwll.chSigned-off-by:
-
Imre Deak authored
If the timer putting the last forcewake refcount was pending and we canceled it, we'll leak the corresponding forcewake and RPM references. v2: - do the ptr casting at the caller instead of adding a separate helper for this (Chris) Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
If a semaphore is waiting on another ring, which in turn happens to be waiting on the first ring, but that second semaphore has been signalled, we will be able to kick the second ring and so can treat the first ring as a valid WAIT and not as HUNG. v2: Be paranoid and cap the potential recursion depth whilst visiting the semaphore signallers. (Mika) References: https://bugs.freedesktop.org/show_bug.cgi?id=54226 References: https://bugs.freedesktop.org/show_bug.cgi?id=75502Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Chris Wilson authored
Otherwise we print out spurious processes on unused rings in the error state. Signed-off-by:
-
Jani Nikula authored
For reasons I can't claim to fully understand gen4 seems to require backlight duty cycle setting after the backlight has been enabled, or else black screen follows. I don't have documentation for the correct sequence on gen4 either. Confirmed on Dell Latitude D630 and MacBook4,1. This fixes a regression introduced by commit b35684b8 Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Nov 14 12:13:41 2013 +0200 drm/i915: do full backlight setup at enable time Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=75791 Reported-and-tested-by: mcy@lm7.fr Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79423Reported-and-tested-by:
Marc Milgram <mmilgram@redhat.com> Cc: Stable <stable@vger.kernel.org> # 3.14+ Acked-by:
-
Ville Syrjälä authored
On certain platforms pixel_multiplier is read out in .get_pipe_config(), but it also gets used to calculate the pixel clock in intel_sdvo_get_config(). If the pipe is disable but some SDVO outputs are active, we may end up dividing by zero in intel_sdvo_get_config(). To avoid the problem simply check for zero pixel_multiplier and skip the division. Another attempt at fixing this involved populating pixel_multiplier to 1 even for disabled pipes, but that triggered a WARN because SDVO_CMD_GET_CLOCK_RATE_MULT command failed and thus encoder_pixel_multiplier was left at zero and didn't match pipe_config->pixel_multiplier. The "divide by pixel_multiplier" operation got introduced here: commit 18442d08 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Sep 13 16:00:08 2013 +0300 drm/i915: Fix port_clock and adjusted_mode.clock readout all over and it has caused a regression on certain machines since they would hit the div-by-zero during resume. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76520 Cc: <stable@vger.kernel.org> # 3.13+ Tested-by:
Tim Richardson <tim@tim-richardson.net> Reviewed-by:
-
Chris Wilson authored
It causes black screen on bootup and is approximately 100x slower than running with FBC disabled, so the GPU runs at a high frequency for much longer - completely contrary to the power saving claims. It also still has mutex deadlocks in multi-head scenarios, which can lead to a system/X lockup. These bugs were known before FBC was enabled by default on Haswell and still have not been fixed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79716Reported-and-tested-by:
Jon Kristensen <info@jonkri.com> Signed-off-by:
-
Dave Airlie authored
Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next display rework fixes lots of displayport issues. * 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (43 commits) drm/nouveau/disp/dp: fix tmds passthrough on dp connector drm/nouveau/dp: probe dpcd to determine connectedness drm/nv50-: trigger update after all connectors disabled drm/nv50-: prepare for attaching a SOR to multiple heads drm/gf119-/disp: fix debug output on update failure drm/nouveau/disp/dp: make use of postcursor when its available drm/g94-/disp/dp: take max pullup value across all lanes drm/nouveau/bios/dp: parse lane postcursor data drm/nouveau/dp: fix support for dpms drm/nouveau: register a drm_dp_aux channel for each dp connector drm/g94-/disp: add method to power-off dp lanes drm/nouveau/disp/dp: maintain link in response to hpd signal drm/g94-/disp: bash and wait for something after changing lane power regs drm/nouveau/disp/dp: split link config/power into two steps drm/nv50/disp: train PIOR-attached DP from second supervisor drm/nouveau/disp/dp: make use of existing output data for link training drm/gf119/disp: start removing direct vbios parsing from supervisor drm/nv50/disp: start removing direct vbios parsing from supervisor drm/nouveau/disp/dp: maintain receiver caps in response to hpd signal drm/nouveau/disp/dp: create subclass for dp outputs ...
-
Ben Skeggs authored
Signed-off-by:Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
We were sending the necessary state changes to unset the mode, but never actually hit the big GO button unless another modeset happens afterwards. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
And at the same time, obey the spec better wrt out-of-range requests. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
SOR_PWR has no effect to power-off DP links, unlike other SOR protocols. Instead, on the source side, we cut power to the lanes after having put the sink into D3. Link training takes care of everything required to bring it back again. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
This previously worked for the most part due to userspace doing a modeset in response to HPD interrupts. This will allow us to properly handle cases where sync is lost for other reasons, or if userspace isn't caring. Signed-off-by: -
Ben Skeggs authored
Some kind of update? Needed to make the power-down take effect at least. Signed-off-by: -
Ben Skeggs authored
We want to be able to power down the lanes for DPMS off. Signed-off-by: -
Ben Skeggs authored
Same place as for SOR, between detach and attach phases. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
This will, at some point, be used to replace various bits and pieces of code doing direct bios parsing. For now, it'll just be used for some DP improvements. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
There's also provisions to allow a pad to be locked with a specific routing, for an indefinite period of time. This will be used in future patches. The G94+ pad driver will now also power-down pads when not required. Signed-off-by: -
Ben Skeggs authored
This was a half-finished hack before, just enough to handle the shared aux/i2c pad thing on G94 and up. We got lucky with locking etc up until now, as this was (generally) all protected by the DRM mode_config lock. It's about to become a lot more likely to hit the races. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by:
-
