summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)Author
2014-11-04drm/i915: Warn if stealing non pipe A/B power sequencerVille Syrjälä
There's no power sequencer on pipe C on VLV/CHV so scream a bit if we try to steal one from pipes other than A and B. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Clear PPS port select when giving up the power sequencerVille Syrjälä
VLV gets confused if two power sequencers have the same port selected. It would seem the port doesn't start up properly in the is case and vlv_wait_port_ready() will fail as will the link training. Clearing the port select in the PP_ON_DELAYS register fixes this problem. CHV doesn't seem to need this, but it doesn't seem to hurt either so let's just do it for both to keep the code between the platforms as uniform as possible. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Don't kick the power seqeuncer just to check if we have vdd/panel ↵Ville Syrjälä
power If there's no power sequencer assigned to the port currently we can't very well have vdd or panel power enabled either. If we would try to check that from the pps registers we'd need to pick a power seqeuncer and kick it. So let's skip the register read and the kick. Note that there's still a bit an issue about correctly recovering pps state from resume if the bios is nasty: With this check we'll always assume that the pps is off. But that's better done in a follow-up patch and it shouldn't be too harmful - at most we waste time enabling the pps if it's on already. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Add note about resume issues Imre spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Kick the power sequencer before AUX transactionsVille Syrjälä
When we pick a new power sequencer for the port but we're not doing a full modeset, the power sequencer may have locked on to another port (or no port). So kick it a bit to make sure it controls the port we want. Again just like when we attempt to actually enable the DP port, we must first write the port register with the approriate value except the enable bit, and then we must enable the port to make the power sequencer happy. In this case since we don't want the port actually enabled we just toggle it on and immediately back off. Going forward the power sequencer will keep working on that specific port until again moved to another port. v2: Refine the kick procedure Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Fix eDP link training when switching pipes on VLV/CHVVille Syrjälä
When switching from one pipe to another, the power sequencer of the new pipe seems to need a bit of kicking to lock into the port. Even the vdd force bit doesn't work before the power sequencer has been sufficiently kicked, so this must be done before any AUX transactions are attempted. After extensive experimentation I've determined that it's sufficient to first write the port register with the correct values except the port must remain disabled, then we can do a second write to enable the port, after which the power sequencer is operational and allows the port to start up properly. Contrary to my earlier theories we don't need to enable the port with the idle pattern, so let's just use training pattern 1 as that's what other platforms use here. v2: Refine the kick procedure Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Wait for PHY port ready before link training on VLV/CHVVille Syrjälä
There's no point in checking if the data lanes came out of reset after link training. If the data lanes aren't ready link training will fail anyway. Suggested-by: Todd Previte <tprevite@gmail.com> Cc: Todd Previte <tprevite@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Acked-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Hold the pps mutex across the whole panel power enable sequenceVille Syrjälä
Just grab the pps_mutex once and do all the pps panel startup operations while holding the mutex instead of grabbing the mutex separately for each individual step. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Split power sequencer panel on/off functions to locked and ↵Ville Syrjälä
unlocked variants We'll be needing to the call the power seqeuencer functions while already holding pps_mutex, so split the locking out to small wrapper functions. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Don't initialize power seqeuencer delays more than onceVille Syrjälä
Since we read the current power seqeuncer delays from the registers (as well as looking at the vbt and spec values) we may end up corrupting delays we already initialized when we switch to another pipe and the power seqeuncer there has different values currently in the registers. So make sure we only initialize the delays once even if intel_dp_init_panel_power_sequencer() gets called multiple times. There was some discussion in the review about when exactly we need to unlock the pps. Quoting Bspec: "If this bit is not a zero, it activates the register write protect and writes to those registers will be ignored unless the write protect key value is set in the panel sequencing control register." Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Add Bspec quote per review discussion between Imre and Ville.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Store power sequencer delays in intel_dpVille Syrjälä
The power seqeuncer delays are fixed for a given panel, so we can keep them around once computed. Not that on VLV/CHV we still re-compute them every time we initialize the power seqeuncer registers, but that will change soon enough. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Remove high level intel_edp_vdd_{on, off}() from hpd/detectVille Syrjälä
want_panel_vdd is a bool so it can't cope with interleaving on/off calls from multiple threads. If we want to make that possible we'd need to convert want_panel_vdd into a proper ref count. But an easier fix is to remove the high level vdd on/off calls from detect/hpd code paths and just rely on the delayed vdd off to avoid needless vdd on<->off ping pong. After this change only the encoder enable/disable paths use the high level functions, which is fine since both the on and off low level edp vdd calls from intel_dp_aux_ch() happen without dropping pps_mutex in between and so want_panel_vdd can't change in between. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Warn if trying to register eDP on port != B/C on vlv/chvVille Syrjälä
Only ports B and C have the power sequencer and backlight controls, so complain if we ever try to register an eDP connector on some other port. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: transform INTEL_OUTPUT_* into an enumPaulo Zanoni
Because I got annoyed that I had to document what values "int ddi_personality" is supposed to hold. A good side-effect of this change is that now the compilers can do some additional checks on our code, which may prevent some bugs in the future. A bad side-effect of this change is that now the compilers do some additional checks on our code and complain when a switch statement doesn't check for all possible values, so we need to add "default" cases to all those switches. Hopefully, this may help preventing confusions against DRM_MODE_CONNECTOR_* and DRM_MODE_ENCODER_*. I guess that just by looking at the patch, some people will think this change is not worth its benefits. In this case, I don't really mind dropping the patch. Also, there's probably still a few more places where we can s/int/enum intel_output_type/, but we can change that later, when we spot the places. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Resolve conflict due to reordered patches.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915/audio: pass intel_encoder on to platform specific ELD functionsJani Nikula
This will simplify things later on. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: pass intel_encoder to intel_write_eldJani Nikula
Everything else can be derived from that. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915/audio: beat some sense into the variable types and namesJani Nikula
Most importantly, "i" need not be the universal variable used for everything. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915/audio: constify hdmi audio clock structJani Nikula
Const is good. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: add new intel audio file to group DP/HDMI audioJani Nikula
In preparation for some additional cleanup. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: remove unneeded visible checkGustavo Padovan
The fb check introduced to drm_plane_helper_check_update() just make this check impossible to branch in. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Remove unnecessary test on the gen in intel_do_mmio_flip()Damien Lespiau
use_mmio_flip() makes sure we only enable MMIO flips on gen5+. So we don't need to take into account older devices. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: only flip frontbuffer if crtc is activeGustavo Padovan
There is no point in flipping a buffer for a disabled crtc. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915 Add golden context support for Gen9Armin Reese
This patch includes the Gen9 batch buffer to generate a 'golden context' for that product family. Signed-off-by: Armin Reese <armin.c.reese@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915 Update Gen8 golden context batch bufferArmin Reese
The file drivers/gpu/drm/i915/intel_renderstate_gen8.c is updated to the version created by IGT null_state_gen Signed-off-by: Armin Reese <armin.c.reese@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Abort command parsing for chained batchesBrad Volkin
libva uses chained batch buffers in a way that the command parser can't generally handle. Fortunately, libva doesn't need to write registers from batch buffers in the way that mesa does, so this patch causes the driver to fall back to non-secure dispatch if the parser detects a chained batch buffer. Note: The 2nd hunk to munge the error code of the parser looks a bit superflous. At least until we have the batch copy code ready and can run the cmd parser in granting mode. But it isn't since we still need to let existing libva buffers pass (though not with elevated privs ofc!). Testcase: igt/gem_exec_parse/chained-batch Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> [danvet: Add note - this confused me in review and Brad clarified things (after a few mails ...).] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Update plane parameters for cursor plane (v2)Sonika Jindal
This allows the cursor plane to be updated the same way as primary and sprites, and same set_property handler is used for all of these planes. v2 (by Matt Roper): Rework to apply to latest di-nightly codebase. The switch to split check/commit plane programming changed the code flow enough that the original patch could no longer be applied. Signed-off-by: Sonika Jindal <sonika.jindal@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Tested-by (IVB): Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Move flags describing VMA mappings into the VMATvrtko Ursulin
If these flags are on the object level it will be more difficult to allow for multiple VMAs per object. v2: Simplification and cleanup after code review comments (Chris Wilson). Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04Merge tag 'drm-intel-next-2014-10-24' of ↵Dave Airlie
git://anongit.freedesktop.org/drm-intel into drm-next - suspend/resume/freeze/thaw unification from Imre - wa list improvements from Mika&Arun - display pll precomputation from Ander Conselvan, this removed the last ->mode_set callbacks, a big step towards implementing atomic modesets - more kerneldoc for the interrupt code - 180 rotation for cursors (Ville&Sonika) - ULT/ULX feature check macros cleaned up thanks to Damien - piles and piles of fixes all over, bug team seems to work! * tag 'drm-intel-next-2014-10-24' of git://anongit.freedesktop.org/drm-intel: (61 commits) drm/i915: Update DRIVER_DATE to 20141024 drm/i915: add comments on what stage a given PM handler is called drm/i915: unify switcheroo and legacy suspend/resume handlers drm/i915: add poweroff_late handler drm/i915: sanitize suspend/resume helper function names drm/i915: unify S3 and S4 suspend/resume handlers drm/i915: disable/re-enable PCI device around S4 freeze/thaw drm/i915: enable output polling during S4 thaw drm/i915: check for GT faults in all resume handlers and driver load time drm/i915: remove unused restore_gtt_mappings optimization during suspend drm/i915: fix S4 suspend while switcheroo state is off drm/i915: vlv: fix switcheroo/legacy suspend/resume drm/i915: propagate error from legacy resume handler drm/i915: unify legacy S3 suspend and S4 freeze handlers drm/i915: factor out i915_drm_suspend_late drm/i915: Emit even number of dwords when emitting LRIs drm/i915: Add rotation support for cursor plane (v5) drm/i915: Correctly reject invalid flags for wait_ioctl drm/i915: use macros to assign mmio access functions drm/i915: only run hsw_power_well_post_enable when really needed ...
2014-10-31drm/i915: Don't destroy DRM properties in the driverDamien Lespiau
When drm properties are created, they are added to mode_config.property_list, which is then used in drm_mode_config_cleanup() to destroy every single property created by the driver. Cc: Chandra Konduru <chandra.konduru@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-10-30drm/i915/dp: only use training pattern 3 on platforms that support itJani Nikula
Ivybridge + 30" monitor prints a drm error on every modeset, since IVB doesn't support DP3 we should even bother trying to use it. This regression has been introduced in commit 06ea66b6bb445043dc25a9626254d5c130093199 Author: Todd Previte <tprevite@gmail.com> Date: Mon Jan 20 10:19:39 2014 -0700 drm/i915: Enable 5.4Ghz (HBR2) link rate for Displayport 1.2-capable devices Reported-by: Dave Airlie <airlied@redhat.com> Reference: http://mid.gmane.org/1414566170-9868-1-git-send-email-airlied@gmail.com Cc: Todd Previte <tprevite@gmail.com> Cc: stable@vger.kernel.org (3.15+) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-10-29drm/i915: Ignore VBT backlight check on Macbook 2, 1jens stein
commit c675949ec58ca50d5a3ae3c757892f1560f6e896 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Apr 9 11:31:37 2014 +0300 drm/i915: do not setup backlight if not available according to VBT prevents backlight setup on Macbook 2,1. Apply quirk to ignore the VBT check so backlight is set up properly. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81438 Signed-off-by: Jens Stein Jørgensen <jens.s.stein@gmail.com> Cc: stable@vger.kernel.org (3.15+) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-10-28Merge tag 'drm-intel-next-2014-10-03-no-ppgtt' of ↵Dave Airlie
git://anongit.freedesktop.org/drm-intel into drm-next Ok, new attempt, this time around with full ppgtt disabled again. drm-intel-next-2014-10-03: - first batch of skl stage 1 enabling - fixes from Rodrigo to the PSR, fbc and sink crc code - kerneldoc for the frontbuffer tracking code, runtime pm code and the basic interrupt enable/disable functions - smaller stuff all over drm-intel-next-2014-09-19: - bunch more i830M fixes from Ville - full ppgtt now again enabled by default - more ppgtt fixes from Michel Thierry and Chris Wilson - plane config work from Gustavo Padovan - spinlock clarifications - piles of smaller improvements all over, as usual * tag 'drm-intel-next-2014-10-03-no-ppgtt' of git://anongit.freedesktop.org/drm-intel: (114 commits) Revert "drm/i915: Enable full PPGTT on gen7" drm/i915: Update DRIVER_DATE to 20141003 drm/i915: Remove the duplicated logic between the two shrink phases drm/i915: kerneldoc for interrupt enable/disable functions drm/i915: Use dev_priv instead of dev in irq setup functions drm/i915: s/pm._irqs_disabled/pm.irqs_enabled/ drm/i915: Clear TX FIFO reset master override bits on chv drm/i915: Make sure hardware uses the correct swing margin/deemph bits on chv drm/i915: make sink_crc return -EIO on aux read/write failure drm/i915: Constify send buffer for intel_dp_aux_ch drm/i915: De-magic the PSR AUX message drm/i915: Reinstate error level message for non-simulated gpu hangs drm/i915: Kerneldoc for intel_runtime_pm.c drm/i915: Call runtime_pm_disable directly drm/i915: Move intel_display_set_init_power to intel_runtime_pm.c drm/i915: Bikeshed rpm functions name a bit. drm/i915: Extract intel_runtime_pm.c drm/i915: Remove intel_modeset_suspend_hw drm/i915: spelling fixes for frontbuffer tracking kerneldoc drm/i915: Tighting frontbuffer tracking around flips ...
2014-10-27drm/i915: Fix GMBUSFREQ on vlv/chvVille Syrjälä
vlv_cdclk_freq is in kHz but we need MHz for the GMBUSFREQ divider. This is a regression from: commit f8bf63fdcb1f82459dae7a3f22ee5ce92f3ea727 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Jun 13 13:37:54 2014 +0300 drm/i915: Kill duplicated cdclk readout code from i2c Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-10-27drm/i915: Ignore long hpds on eDP portsVille Syrjälä
Turning vdd on/off can generate a long hpd pulse on eDP ports. In order to handle hpd we would need to turn on vdd to perform aux transfers. This would lead to an endless cycle of "vdd off -> long hpd -> vdd on -> detect -> vdd off -> ..." So ignore long hpd pulses on eDP ports. eDP panels should be physically tied to the machine anyway so they should not actually disappear and thus don't need long hpd handling. Short hpds are still needed for link re-train and whatnot so we can't just turn off the hpd interrupt entirely for eDP ports. Perhaps we could turn it off whenever the panel is disabled, but just ignoring the long hpd seems sufficient. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-10-27drm/i915: Do a dummy DPCD read before the actual readVille Syrjälä
Sometimes we seem to get utter garbage from DPCD reads. The resulting buffer is filled with the same byte, and the operation completed without errors. My HP ZR24w monitor seems particularly susceptible to this problem once it's gone into a sleep mode. The issue seems to happen only for the first AUX message that wakes the sink up. But as the first AUX read we often do is the DPCD receiver cap it does wreak a bit of havoc with subsequent link training etc. when the receiver cap bw/lane/etc. information is garbage. A sufficient workaround seems to be to perform a single byte dummy read before reading the actual data. I suppose that just wakes up the sink sufficiently and we can just throw away the returned data in case it's crap. DP_DPCD_REV seems like a sufficiently safe location to read here. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Todd Previte <tprevite@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-10-24drm/i915: Update DRIVER_DATE to 20141024Daniel Vetter
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-10-24drm/i915: add comments on what stage a given PM handler is calledImre Deak
This will hopefully make it easier to navigate the code without the need to consult the full PM documentation. v2: - add a comment that the freeze handler is also called after rebooting - add a comment that the thaw handler is also called to recover from errors (Ville) - add the PM event names (PMSG_THAW etc.) for reference (Ville) - add comments that s0ix can be handled both via system and runtime suspend (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-10-24drm/i915: unify switcheroo and legacy suspend/resume handlersImre Deak
By now we handle switcheroo and legacy suspend/resume the same way, so no need to keep separate functions for them. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-10-24drm/i915: add poweroff_late handlerImre Deak
The suspend_late handler saves some registers and powers off the device, so it doesn't have a big overhead. Calling it at S4 poweroff_late time makes the power off handling identical to the S3 suspend and S4 freeze handling, so do this for consistency. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-10-24drm/i915: sanitize suspend/resume helper function namesImre Deak
By now the S4 freeze/thaw and S3 suspend/resume events are handled the same way, so we can rename the freeze/thaw internal helpers to suspend/resume accordingly to make clearer what the helpers do. Also rename i915_resume_early to i915_drm_resume_early aligning it with the rest of the helper names. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-10-24drm/i915: unify S3 and S4 suspend/resume handlersImre Deak
The S3 and S4 events are now handled the same way internally, there is no need to keep separate wrapper functions around them. Simply reuse the suspend/resume versions everywhere. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-10-24drm/i915: disable/re-enable PCI device around S4 freeze/thawImre Deak
We already disable everything during S4 freeze, except the PCI device itself. There is no reason why we couldn't disable that too and doing so allows us to unify these handlers in the next patch with the corresponding S3 suspend/resume handlers. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-10-24drm/i915: enable output polling during S4 thawImre Deak
To avoid processing hotplug events we disable connector polling for the duration of S3 suspend. We also disable it for S4 freeze, and keep it disabled after S4 thaw. This won't prevent though hotplug processing, since we re-enable interrupts anyway. There is also no need to prevent it at that time, since we reinitialize everything during thaw, so the device is in a consistent state. So to simplify things enable polling during thaw, which will allow us to handle S4 thaw the same way as S3 resume in an upcoming patch. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-10-24drm/i915: check for GT faults in all resume handlers and driver load timeImre Deak
Checking for GT faults is not specific in any way to S4 thaw, so do it also during S3 resume, S4 restore and driver load time. This allows us to unify the Sx handlers in an upcoming patch. v2: - move the check to intel_uncore_early_sanitize(), so we check at driver load time too (Chris) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-10-24drm/i915: remove unused restore_gtt_mappings optimization during suspendImre Deak
The logic to skip restoring GTT mappings was added to speed up suspend/resume, but not on old GENs where not restoring them caused problems. The check for old GENs is based on the existence of OpRegion, but this doesn't work since opregion is initialized only after the check. So we end up always restoring the mappings. On my BYT - which has OpRegion - skipping restoring the mappings during suspend doesn't work, I get a GPU hang after resume. Also the logic of when to allow the optimization during S4 is reversed: we should allow it during S4 thaw but not during S4 restore, but atm we have it the other way around in the code. Since correctness wins over optimal code and since the optimization wasn't used anyway I decided not to try to fix it at this point, but just remove it. This allows us to unify the S3 and S4 handlers in the following patches. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-10-24drm/i915: fix S4 suspend while switcheroo state is offImre Deak
If the device is suspended already through the switcheroo interface we shouldn't suspend it again or resume it after suspend. We have the corresponding check for S3 suspend already, add it for all the other S3 and S4 handlers. Also move the check from i915_resume_early() to i915_resume_legacy(), so that it's done in the high level handler for all PM events. v2: - fix the resume path too, we don't need to special case there DRM_SWITCH_POWER_OFF with the device being enabled (in which case we'd have to disable the device), since that never happens (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-10-24drm/i915: vlv: fix switcheroo/legacy suspend/resumeImre Deak
During switcheroo/legacy suspend we don't call the suspend_late handler but when resuming afterwards we call resume_early. This happened to work so far, since suspend_late only disabled the PCI device. This changed in commit 016970beb05da6285c2f3ed2bee1c676cb75972e Author: Sagar Kamble <sagar.a.kamble@intel.com> Date: Wed Aug 13 23:07:06 2014 +0530 drm/i915: Sharing platform specific sequence between runtime and system susp after which we also saved/restored the VLV Gunit HW state in suspend_late/resume_early. So now since we don't save the state during suspend a following resume will restore a corrupted state. Fix this by calling the suspend_late handler during both switcheroo and legacy suspend. CC: Sagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Sagar Kamble <sagar.a.kamble@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-10-24drm/i915: propagate error from legacy resume handlerImre Deak
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-10-24drm/i915: unify legacy S3 suspend and S4 freeze handlersImre Deak
i915_suspend() is called from the DRM legacy S3 suspend/S4 freeze paths and the switcheroo suspend path. For switcheroo we only ever need to perform a full suspend (PM_EVENT_SUSPEND) and for the DRM legacy path we can handle the S4 freeze (PM_EVENT_FREEZE) the same way as S3 suspend. The only difference atm between suspend and freeze is that during freeze we don't disable the PCI device, but there is no reason why we can't do so. So unify the two cases to reduce complexity. Note that for the DRM legacy case the thaw event is not handled, so we disable the display before creating the hibernation image and it won't get re-enabled until reboot. We could fix this leaving the display enabled for the image creation/writing (if we care enough about UMS), but this can be done as a follow-up. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-10-24drm/i915: factor out i915_drm_suspend_lateImre Deak
This is needed by an upcoming patch fixing the switcheroo/legacy suspend paths. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-10-24drm/i915: Emit even number of dwords when emitting LRIsArun Siluvery
The number of DWords should be even when doing ring emits as command sequences require QWord alignment. There was some discussion about the maximum length of the MI_LRI command. Quoting Mika "I did some test with bdw: "The maximum is 128 writes, resulting the 8 bit length field of the command being 0xff, thus following the spec. The 128'th write went through. "Perhaps the max command length is then less in older gens? "Perhaps WARN_ON(x > 128) in MI_LOAD_REGISTER_IMM would be in place but one needs minor tweak to command parser a bit also then. #define I915_MAX_WA_REGS 16 keeps us safe for now atleast." Ville commented that on pre-gen6 the length field seems to be restricted to 0x3f though. So for all cases we should be ok. v2: user LRI variant that can write multiple regs in one go (Damien). We can simply insert one NOP at the end instead of one per register write. Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Add a summary of the MI_LRI length discussion.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>