summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/i915_drv.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge remote-tracking branch 'airlied/drm-next' into drm-intel-nextDaniel Vetter2014-07-291-8/+17
|\ | | | | | | | | | | | | | | | | | | | | | | Pull in drm-next with Dave's DP MST support so that I can merge some conflicting patches which also touch the driver load sequencing around interrupt handling. Conflicts: drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_dp.c Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: don't suspend gt until after we disable irqs and display (v2)Dave Airlie2014-07-241-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | When I moved the irq disable down to after display disable, I didn't realise the gt suspend also required irqs off, so move it down as well. Fixes WARNs seen at suspend/resume time. v2: moved the rps flush down as well. Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/i915: add DP 1.2 MST support (v0.7)Dave Airlie2014-07-221-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds DP 1.2 MST support on Haswell systems. Notes: a) this reworks irq handling for DP MST ports, so that we can avoid the mode config locking in the current hpd handlers, as we need to process up/down msgs at a better time. Changes since v0.1: use PORT_PCH_HOTPLUG to detect short vs long pulses add a workqueue to deal with digital events as they can get blocked on the main workqueue beyong mode_config mutex fix a bunch of modeset checker warnings acks irqs in the driver cleanup the MST encoders Changes since v0.2: check irq status again in work handler move around bring up and tear down to fix DPMS on/off use path properties. Changes since v0.3: updates for mst apis more state checker fixes irq handling improvements fbcon handling support improved reference counting of link - fixes redocking. Changes since v0.4: handle gpu reset hpd reinit without oopsing check link status on HPD irqs fix suspend/resume Changes since v0.5: use proper functions to get max link/lane counts fix another checker backtrace - due to connectors disappearing. set output type in more places fro, unknown->displayport don't talk to devices if no HPD asserted check mst on short irqs only check link status properly rebase onto prepping irq changes. drop unsued force_act Changes since v0.6: cleanup unused struct entry. [airlied: fix some sparse warnings]. Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * Merge tag 'drm-intel-next-2014-07-11' of ↵Dave Airlie2014-07-191-7/+6
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next - fbc improvements when stolen memory is tight (Ben) - cdclk handling improvements for vlv/chv (Ville) - proper fix for stuck primary planes on gmch platforms with cxsr (Imre&Ebgert Eich) - gen8 hw semaphore support (Ben) - more execlist prep work from Oscar Mateo - locking fixes for primary planes (Matt Roper) - code rework to support runtime pm for dpms on hsw/bdw (Paulo, Imre & me), but not yet enabled because some fixes from Paulo haven't made the cut - more gpu boost tuning from Chris - as usual piles of little things all over * tag 'drm-intel-next-2014-07-11' of git://anongit.freedesktop.org/drm-intel: (93 commits) drm/i915: Make the RPS interrupt generation mask handle the vlv wa drm/i915: Move RPS evaluation interval counters to i915->rps drm/i915: Don't cast a pointer to void* unnecessarily drm/i915: don't read LVDS regs at compute_config time drm/i915: check the power domains in intel_lvds_get_hw_state() drm/i915: check the power domains in ironlake_get_pipe_config() drm/i915: don't skip shared DPLL assertion on LPT drm/i915: Only touch WRPLL hw state in enable/disable hooks drm/i915: Switch to common shared dpll framework for WRPLLs drm/i915: ->enable hook for WRPLLs drm/i915: ->disable hook for WRPLLs drm/i915: State readout support for WRPLLs drm/i915: add POWER_DOMAIN_PLLS drm/i915: Document that the pll->mode_set hook is optional drm/i915: Basic shared dpll support for WRPLLs drm/i915: Precompute static ddi_pll_sel values in encoders drm/i915: BDW also has special-purpose DP DDI clocks drm/i915: State readout and cross-checking for ddi_pll_sel drm/i915: Move ddi_pll_sel into the pipe config drm/i915: Add a debugfs file for the shared dpll state ...
| * \ Merge tag 'drm-intel-next-2014-06-20' of ↵Dave Airlie2014-07-091-15/+24
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next - Accurate frontbuffer tracking and frontbuffer rendering invalidate, flush and flip events. This is prep work for proper PSR support and should also be useful for DRRS&fbc. - Runtime suspend hardware on system suspend to support the new SOix sleep states, from Jesse. - PSR updates for broadwell (Rodrigo) - Universal plane support for cursors (Matt Roper), including core drm patches. - Prefault gtt mappings (Chris) - baytrail write-enable pte bit support (Akash Goel) - mmio based flips (Sourab Gupta) instead of blitter ring flips - interrupt handling race fixes (Oscar Mateo) And old, not yet merged features from the previous round: - rps/turbo support for chv (Deepak) - some other straggling chv patches (Ville) - proper universal plane conversion for the primary plane (Matt Roper) - ppgtt on vlv from Jesse - pile of cleanups, little fixes for insane corner cases and improved debug support all over * tag 'drm-intel-next-2014-06-20' of git://anongit.freedesktop.org/drm-intel: (99 commits) drm/i915: Update DRIVER_DATE to 20140620 drivers/i915: Fix unnoticed failure of init_ring_common() drm/i915: Track frontbuffer invalidation/flushing drm/i915: Use new frontbuffer bits to increase pll clock drm/i915: don't take runtime PM reference around freeze/thaw drm/i915: use runtime irq suspend/resume in freeze/thaw drm/i915: Properly track domain of the fbcon fb drm/i915: Print obj->frontbuffer_bits in debugfs output drm/i915: Introduce accurate frontbuffer tracking drm/i915: Drop schedule_back from psr_exit drm/i915: Ditch intel_edp_psr_update drm/i915: Drop unecessary complexity from psr_inactivate drm/i915: Remove ctx->last_ring drm/i915/chv: Ack interrupts before handling them (CHV) drm/i915/bdw: Ack interrupts before handling them (GEN8) drm/i915/vlv: Ack interrupts before handling them (VLV) drm/i915: Ack interrupts before handling them (GEN5 - GEN7) drm/i915: Don't BUG_ON in i915_gem_obj_offset drm/i915: Grab dev->struct_mutex in i915_gem_pageflip_info drm/i915: Add some L3 registers to the parser whitelist ... Conflicts: drivers/gpu/drm/i915/i915_drv.c
| * | | drm/fb-helper: Fix hpd vs. initial config racesDaniel Vetter2014-07-081-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some drivers need to be able to have a perfect race-free fbcon setup. Current drivers only enable hotplug processing after the call to drm_fb_helper_initial_config which leaves a tiny but important race. This race is especially noticable on embedded platforms where the driver itself enables the voltage for the hdmi output, since only then will monitors (after a bit of delay, as usual) respond by asserting the hpd pin. Most of the infrastructure is already there with the split-out drm_fb_helper_init. And drm_fb_helper_initial_config already has all the required locking to handle concurrent hpd events since commit 53f1904bced78d7c00f5d874c662ec3ac85d0f9f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Mar 20 14:26:35 2014 +0100 drm/fb-helper: improve drm_fb_helper_initial_config locking The only missing bit is making drm_fb_helper_hotplug_event save against concurrent calls of drm_fb_helper_initial_config. The only unprotected bit is the check for fb_helper->fb. With that drivers can first initialize the fb helper, then enabel hotplug processing and then set up the initial config all in a completely race-free manner. Update kerneldoc and convert i915 as a proof of concept. Feature requested by Thierry since his tegra driver atm reliably boots slowly enough to misses the hotplug event for an external hdmi screen, but also reliably boots to quickly for the hpd pin to be asserted when the fb helper calls into the hdmi ->detect function. Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | | drm/i915: BDW can also detect unclaimed registersPaulo Zanoni2014-07-231-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By the time I wrote this patch, it allowed me to catch some problems. But due to patch reordering - in order to prevent fake "regression" reports - this patch may be merged after the fixes of the problems identified by this patch. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | | drm/i915: Power gating display wells during i915_pm_suspendBorun Fu2014-07-231-4/+3
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On VLV, after i915_pm_suspend display power wells are staying power ungated. So, after initiating mem sleep "echo mem > /sys/power/state" Display is staing D0 State. There might be better way/place to power gate these wells. Also, we need to make sure that if wells are power gated due to DPMS OFF sequence, they need not be turned off by i915_pm_suspend again. v2: Extracted helper for intel_crtc_disable and power gating CRTC power wells. [Daniel] Cc: Imre Deak <imre.deak@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Change-Id: I34c80da66aa24c423a5576c68aa1f3a8d0f43848 Signed-off-by: Borun Fu <borun.fu@intel.com> Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: make system freeze support depend on CONFIG_ACPI_SLEEPImre Deak2014-07-081-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To achieve further power savings during system freeze (aka connected standby, or s0ix) we have to send a PCI_D1 opregion notification. As the information about the state we're entering (system freeze, suspend to ram or suspend to disk) is only available through the ACPI subsystem, make this support depend on the relevant kconfig option. Things will still work if this option isn't set, albeit with less than optimial power saving. This also fixes a compile breakage when the option is not set introduced in commit e5747e3adcd67ae27105003ec99fb58cba180105 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Jun 12 08:35:47 2014 -0700 drm/i915: send proper opregion notifications on suspend/resume Reported-by: Randy Dunlap <rdunlap@infradead.org> 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>
* | | drm/i915: Enable semaphores on BDWRodrigo Vivi2014-07-071-4/+0
| | | | | | | | | | | | | | | Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: flush delayed_resume_work when suspendingPaulo Zanoni2014-07-011-0/+2
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is possible that, by the time we run i915_drm_freeze(), delayed_resume_work was already queued but did not run yet. If it still didn't run after intel_runtime_pm_disable_interrupts(), by the time it runs it will try to change the interrupt registers with the interrupts already disabled, which will trigger a WARN. We can reliably reproduce this with the pm_rpm system-suspend test case. In order to avoid the problem, we have to flush the work before disabling the interrupts. We could also cancel the work instead of flushing it, but that would require us to put a runtime PM reference - and any other resource we may need in the future - in case the work was already queued, so I believe flushing the work is more future-proof, although less efficient. But I can also change this part if someone requests. Another thing I tried was to move the intel_suspend_gt_powersave() call to before intel_runtime_pm_disable_interrupts(), but since that function needs to be called after the interrupts are already disabled, due to dev_priv->rps.work, this strategy didn't work. Testcase: igt/pm_rpm/system-suspend Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80517 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: don't take runtime PM reference around freeze/thawJesse Barnes2014-06-191-3/+0
| | | | | | | | | | | | | | | | | | | | | | We should be taking the right power well refs these days, so this shouldn't be necessary. It also gets in the way of re-using these routines for S0iX states, as those need all the power saving features enabled. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: use runtime irq suspend/resume in freeze/thawJesse Barnes2014-06-191-3/+2
| | | | | | | | | | | | | | | | | | We don't need to uninstall the full handler, simply disabling interrupts ought to be enough. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge branch 'topic/soix' into drm-intel-next-queuedDaniel Vetter2014-06-181-2/+21
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jesse's SOix work required some patches from acpi-next, so pull it in through a topic barnch. Conflicts: drivers/gpu/drm/i915/i915_drv.c drivers/gpu/drm/i915/intel_pm.c Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: make sure PC8 is enabled on suspend and disabled on resume v4Kristen Carlson Accardi2014-06-121-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This matches the runtime suspend paths and allows the system to enter the lowest power mode at freeze time. v2: move disable_pc8 call to thaw_early (Imre) move enable_pc8 to freeze_late (Imre/Jesse) v3: drop spurious hunk from _freeze now that we have freeze_late (Jesse) v4: move back to suspend_late (Imre was right) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: send proper opregion notifications on suspend/resumeJesse Barnes2014-06-121-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This indicates to the firmware that it can power down various other components or bring them back up, depending on the target system state. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: leave rc6 enabled at suspend time v4Jesse Barnes2014-06-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows the system to enter the lowest power mode during system freeze. v2: delete force wake timer at suspend (Imre) v3: add GT work suspend function (Imre) v4: use uncore forcewake reset (Daniel) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: disable power wells on suspendKristen Carlson Accardi2014-06-121-0/+2
| |/ | | | | | | | | | | | | | | | | | | We want to make sure everything is disabled and at its lowest power when freezing. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: preserve user forcewake over system suspend/resumeImre Deak2014-06-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Atm, the forcewake refcount will be incorrectly set to zero during system suspend if there is any reference held via the i915_forcewake_user debugfs entry. Fix this by simply not zeroing the sw counters during suspend and restoring the original state using them. Note that the only other places where we zeroed the counters were driver load and unload time, where it was redundant anyway. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78059 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>
* | drm/i915: Don't use pipe_offset stuff for DPLL registersVille Syrjälä2014-06-111-6/+0
|/ | | | | | | | | | | | | These are just single registers so wasting space for the pipe offsets seems a bit pointless. So just use the _PIPE3() macro instead. Also rewrite the _PIPE3() macro to be more obvious, and protect the arguments properly. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Frob conflict.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: BDW: Adding missing cursor offsets.Rodrigo Vivi2014-06-051-0/+2
| | | | | | | | | | | | | | | BDW uses IVB cursor offsets. Whithout this patch it is not possible to use multiple outputs with cursor on BDW. The cursor gets completely crazy because update position uses the wrong cursor register for the second pipe. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Cc: stable@vger.kernel.org Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79621 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: tell the user if both KMS and UMS are disabledJani Nikula2014-06-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | If both KMS is disabled (by i915.modeset=0 or nomodeset parameters) and UMS is disabled (by CONFIG_DRM_I915_UMS=n, the default), the user might not be aware his setup is not supported. Inform the users (and, by extension, the poor i915 developers having to read their dmesgs in bug reports) why their graphics experience might be lacking. A similar message was added on the UMS path in commit e147accbd19f55489dabdcc4dc3551cc3e3f2553 Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Oct 10 15:25:37 2013 +0300 drm/i915: tell the user KMS is required for gen6+ but it won't be reached if CONFIG_DRM_I915_UMS=n since commit b30324adaf8d2e5950a602bde63030d15a61826f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Nov 13 22:11:25 2013 +0100 drm/i915: Deprecated UMS support v2: Use DRM_DEBUG_DRIVER. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Improve irq handling after gpu resetsDaniel Vetter2014-06-051-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we do a full re-init of all interrupts after a gpu hang. Which is pretty bad since we don't restore the interrupts we've enabled at runtime correctly. Even with that addressed it's rather horribly race. But on g4x and later we only reset the gt and not the entire gpu. Which means we only need to reset the GT interrupt bits. Which has the nice benefit that vblank waits, pipe CRC interrupts and everything else display related just keeps on working. The downside is that gt interrupt handling (i.e. ring->get/put_irq) is still racy. But as long as the gpu hang reliably wakes all waters and we have a short time where the refcount drops to 0 we'll recover. So not that bad really. v2: Ville noticed that GTIMR and PMIMR don't get cleared, only the subordinate per-ring registers. So let's rip out all the interrupt dancing. The FIXME comment is still required though since the ring irq handling happens at the per-ring interrupt mask registers, too. Testcase: igt/kms_flip/vblank-vs-hang Testcase: igt/kms_pipe_crc_basic/hang-* Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm: Split connection_mutex out of mode_config.mutex (v3)Daniel Vetter2014-06-041-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After the split-out of crtc locks from the big mode_config.mutex there's still two major areas it protects: - Various connector probe states, like connector->status, EDID properties, probed mode lists and similar information. - The links from connector->encoder and encoder->crtc and other modeset-relevant connector state (e.g. properties which control the panel fitter). The later is used by modeset operations. But they don't really care about the former since it's allowed to e.g. enable a disconnected VGA output or with a mode not in the probed list. Thus far this hasn't been a problem, but for the atomic modeset conversion Rob Clark needs to convert all modeset relevant locks into w/w locks. This is required because the order of acquisition is determined by how userspace supplies the atomic modeset data. This has run into troubles in the detect path since the i915 load detect code needs _both_ protections offered by the mode_config.mutex: It updates probe state and it needs to change the modeset configuration to enable the temporary load detect pipe. The big deal here is that for the probe/detect users of this lock a plain mutex fits best, but for atomic modesets we really want a w/w mutex. To fix this lets split out a new connection_mutex lock for the modeset relevant parts. For simplicity I've decided to only add one additional lock for all connector/encoder links and modeset configuration states. We have piles of different modeset objects in addition to those (like bridges or panels), so adding per-object locks would be much more effort. Also, we're guaranteed (at least for now) to do a full modeset if we need to acquire this lock. Which means that fine-grained locking is fairly irrelevant compared to the amount of time the full modeset will take. I've done a full audit, and there's just a few things that justify special focus: - Locking in drm_sysfs.c is almost completely absent. We should sprinkle mode_config.connection_mutex over this file a bit, but since it already lacks mode_config.mutex this patch wont make the situation any worse. This is material for a follow-up patch. - omap has a omap_framebuffer_flush function which walks the connector->encoder->crtc links and is called from many contexts. Some look like they don't acquire mode_config.mutex, so this is already racy. Again fixing this is material for a separate patch. - The radeon hot_plug function to retrain DP links looks at connector->dpms. Currently this happens without any locking, so is already racy. I think radeon_hotplug_work_func should gain mutex_lock/unlock calls for the mode_config.connection_mutex. - Same applies to i915's intel_dp_hot_plug. But again, this is already racy. - i915 load_detect code needs to acquire this lock. Which means the w/w dance due to Rob's work will be nicely contained to _just_ this function. I've added fixme comments everywhere where it looks suspicious but in the sysfs code. After a quick irc discussion with Dave Airlie it sounds like the lack of locking in there is due to sysfs cleanup fun at module unload. v1: original (only compile tested) v2: missing mutex_init(), etc (from Rob Clark) v3: i915 needs more care in the conversion: - Protect the edp pp logic with the connection_mutex. - Use connection_mutex in the backlight code due to get_pipe_from_connector. - Use drm_modeset_lock_all in suspend/resume paths. - Update lock checks in the overlay code. Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Rob Clark <robdclark@gmail.com>
* drm/i915: disable GT power saving early during system suspendImre Deak2014-05-221-2/+3
| | | | | | | | | | | | | | | | | Atm, we disable GT power saving during the end of the suspend sequence in i915_save_state(). Doing the disabling at that point seems arbitrary. One reason to disable it early though is to have a quiescent HW state before we do anything else (for example save registers). So move the disabling earlier, which also takes care canceling of the deferred RPS enabling work done by intel_disable_gt_powersave(). Note that after the move we'll call intel_disable_gt_powersave() only in case modeset is enabled, but that's anyway the only case where we have it enabled in the first place. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Robert Beckett <robert.beckett@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: remove user GTT mappings early during runtime suspendImre Deak2014-05-221-2/+25
| | | | | | | | | | | | | | | | | | | | Currently user space can access GEM buffers mapped to GTT through existing mappings concurrently while the platform specific suspend handlers are running. Since these handlers may change the HW state in a way that would break such accesses, remove the mappings before calling the handlers. Spotted by Ville. Also Chris pointed out that the lists that i915_gem_release_all_mmaps() walks through need dev->struct_mutex, so take this lock. There is a potential deadlock against a concurrent RPM resume, resolve this by aborting and rescheduling the suspend (Daniel). v2: - take struct_mutex around i915_gem_release_all_mmaps() (Chris, Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Robert Beckett <robert.beckett@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Hold CRTC lock whilst freezing the planesChris Wilson2014-05-221-1/+4
| | | | | | | | | | | | | | | | | | | | | Daniel keeps on ramping up the warning level of the DRM and our display core to make it complain whenever the locking rules are not followed. This caught commit 24576d23976746cb52e7700c4cadbf4bc1bc3472 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Mar 26 09:25:45 2013 -0700 drm/i915: enable VT switchless resume v3 introducing an unlocked access to the CRTC whilst disabling it for suspend. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78114 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: drop encoder hot_plug calls at resumeJesse Barnes2014-05-211-19/+1
| | | | | | | | | We really just want to go detect displays again and fire off a hotplug event if things have changed, not go through full hotplug processing. Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/chv: Bump num_pipes to 3Ville Syrjälä2014-05-201-1/+1
| | | | | | | | CHV has three pipes so let's expose them all. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/chv: Add cursor pipe offsetsVille Syrjälä2014-05-201-0/+34
| | | | | | | | | | | | | Unsurprisingly the cursor C regiters are also at a weird offset on CHV. Add more pipe offsets to handle them. This also gets rid of most of the differences between the i9xx vs. ivb cursor code. We can unify the remaining code as well, but I'll leave that for another patch. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/chv: Add CHV display supportRafael Barbalho2014-05-201-0/+12
| | | | | | | | | | | | | Add support for the third pipe in cherrview v2: Don't use spaces for indentation (Jani) Wrap long lines Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com> [vsyrjala: slightly massaged the patch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use for_each_crtc() when iterating through the CRTCsDamien Lespiau2014-05-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Patch done using the following semantic patch (thanks Daniel for the help!) @@ iterator name list_for_each_entry; iterator name for_each_crtc; struct drm_crtc * crtc; struct drm_device * dev; @@ -list_for_each_entry(crtc,&dev->mode_config.crtc_list, head) { +for_each_crtc(dev,crtc) { ... } Followed by a couple of fixups by hand (that spatch doesn't match the cases where list_for_each_entry() is not followed by a set of '{', '}', but I couldn't figure out a way to leave the '{' out of the iterator match). Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* srm/i915/chv: Add Cherryview PCI IDsVille Syrjälä2014-05-121-1/+11
| | | | | | | | | | | | | | | v2: Update to also fill in the new num_pipes field. v3: Rebase on top of the pciid extraction. v4: Switch from info->has*ring to info->ring mask. Also add VEBOX support whiel at it. v5: s/CHV_PCI_IDS/CHV_IDS/, and drop the trailing '\' Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: vlv: add runtime PM supportImre Deak2014-05-071-0/+327
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add runtime PM support for VLV, but leave it disabled. The next patch enables it. The suspend/resume sequence used is based on [1] and [2]. In practice we depend on the GT RC6 mechanism to save the HW context depending on the render and media power wells. By the time we run the runtime suspend callback the display side is also off and the HW context for that is managed by the display power domain framework. Besides the above there are Gunit registers that depend on a system-wide power well. This power well goes off once the device enters any of the S0i[R123] states. To handle this scenario, save/restore these Gunit registers. Note that this is not the complete register set dictated by [2], to remove some overhead, registers that are known not to be used are ignored. Also some registers are fully setup by initialization functions called during resume, these are not saved either. The list of registers can be further reduced, see the TODO note in the code. [1] VLV_gfx_clocking_PM_reset_y12w21d3 / "Driver D3 entry/exit" [2] VLV2_S0IXRegs v2: - unchanged v3: - fix s/GEN6_PMIIR/GEN6_PMIMR/ typo when saving/restoring registers (Ville) v4: - rebased on the previous patch fixing GEN register prefixes Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [ rebased (according to v4) ] Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: propagate the error code from runtime PM callbacksImre Deak2014-05-071-15/+42
| | | | | | | | | | | | | | | | | | | Atm, none of the RPM callbacks can fail, but the next patch adding RPM support for VLV changes this, so prepare for it. In case one of these callbacks return error RPM will get permanently disabled until the error is explicitly cleared. In the future we could add support for re-enabling it, for example after resetting the HW, but for now - hopefully - we can live with the simpler solution. v2: - propagate the error from the resume callbacks too (Paulo) v3: - fix rebase fail typo around IS_GEN6() check in intel_runtime_suspend() 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>
* drm/i915: vlv: increase timeout when forcing on the GFX clockImre Deak2014-05-051-2/+2
| | | | | | | | I've seen latencies up to 15msec, so increase the timeout to 20msec. 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>
* drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-offImre Deak2014-05-051-0/+37
| | | | | | | | | | | | | | | | | This will be needed by the VLV runtime PM helpers too, so factor it out. Also add a safety check for the case where the previous force-off is still pending, since I'm not sure if Punit can handle a new setting while the previous one hasn't settled yet. v2: - unchanged v3: - add a note to the commit message about the safety check (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>
* drm/i915: reinit GT power save during resumeImre Deak2014-05-051-0/+7
| | | | | | | | | | | | | | | | | | | | During runtime suspend there can be a last pending rps.work, so make sure it's canceled. Note that in the runtime suspend callback we can't get any RPS interrupts since it's called only after the GPU goes idle and we set the minimum RPS frequency. The next possibility for an RPS interrupt is only after getting an RPM ref (for example because of a new GPU command) and calling the RPM resume callback. v2: - patch introduced in v2 of the patchset v3: - Change the order of canceling the rps.work and disabling interrupts to avoid the race between interrupt disabling and the the rps.work. Race spotted by 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>
* drm/i915: make runtime PM swizzling/ring_freq init platform independentImre Deak2014-05-051-2/+3
| | | | | | | | | | | | We need to re-init sizzling on all platforms so move it to the platform independent runtime resume callback. The ring frequency reinit is also needed everywhere except on VLV, but gen6_update_ring_freq() will be a noop on VLV, so we can move this function too to platform independent code. 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>
* drm/i915: factor out gen6_update_ring_freqImre Deak2014-05-051-2/+0
| | | | | | | | | | | | | | | | This is needed by the next patch moving the call out from platform specific RPM callbacks to platform independent code. No functional change. v2: - patch introduce in v2 of the patchset v3: - simplify platform check condition (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>
* drm/i915: make runtime PM interrupt enable/disable platform independentImre Deak2014-05-051-9/+5
| | | | | | | | | | | | | | | We need to disable the interrupts for all platforms, so make the helpers for this platform independent and call them from them platform independent runtime suspend/resume callbacks. On HSW/BDW this will move interrupt disabling/re-enabling at the beginning/end of runtime suspend/resume respectively, but I don't see any reason why this would cause a problem there. In any case this seems to be the correct thing to do even on those platforms. 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>
* drm/i915: disable runtime PM if RC6 is disabledImre Deak2014-05-051-1/+1
| | | | | | | | | | | | | | | | | | On VLV we depend on RC6 to save the GT render and media HW context before going to the D3 state via RPM, so as a preparation for the VLV RPM support (added in an upcoming patch) disable RPM if RC6 is disabled. There is probably a similar dependency on other platforms too, so for safety require RC6 for those too. For these platforms (SNB, HSW, BDW) this is then a possible fix. v2: - require RC6 for all RPM platforms, not just for VLV (Paulo, Daniel) 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>
* drm/i915: get a runtime PM ref for the deferred GT powersave enablingImre Deak2014-05-051-1/+4
| | | | | | | | | | | | | | | At least on VLV but probably on other platforms too we depend on RC6 being enabled for RPM, so disable RPM until the delayed RC6 enabling completes. v2: - explain the reason for the _noresume version of RPM get (Daniel) - use the simpler 'if (schedule_work()) rpm_get();' instead of 'if (!cancel_work_sync()) rpm_get(); schedule_work();' 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>
* drm/i915: move getting struct_mutex lower in the callstack during GPU resetImre Deak2014-05-051-4/+1
| | | | | | | | | | | | | | Getting struct_mutex around the whole intel_enable_gt_powersave() function is not necessary, since it's only needed for the ILK path therein. This will make intel_enable_gt_powersave() useable on the RPM resume path for >=GEN6 (added in an upcoming patch to reset the RPS state during RPM resume), where we can't (and need not) get this mutex. 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>
* drm/i915:Initialize the second BSD ring on BDW GT3 machineZhao Yakui2014-05-051-2/+2
| | | | | | | | | | | | | | Based on the hardware spec, the BDW GT3 machine has two independent BSD ring that can be used to dispatch the video commands. So just initialize it. V3->V4: Follow Imre's comment to do some minor updates. For example: more comments are added to describe the semaphore between ring. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> [danvet: Fix up checkpatch error.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Split the BDW device definition to prepare for dual BSD rings on ↵Zhao Yakui2014-05-051-2/+24
| | | | | | | | | | | | | | | BDW GT3 Based on the hardware spec, the BDW GT3 has the different configuration with the BDW GT1/GT2. So split the BDW device info definition. This is to do the preparation for adding the Dual BSD rings on BDW GT3 machine. V1->V2: Follow Daniel's comment to pay attention to the stolen check for BDW in kernel/early-quirks.c Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Mark device as wedged if we fail to resumeChris Wilson2014-05-051-4/+5
| | | | | | | | | | | | | | | | | | | During module load, if we fail to initialise the rings, we abort the load reporting EIO. However during resume, even though we report EIO as we fail to reinitialize the ringbuffers, the resume continues and the device is restored - albeit in a non-functional state. As we cannot execute any commands on the GPU, it is effectively wedged, mark it so. As we now preserve the ringbuffers across resume, this should prevent UXA from falling into the trap of repeatedly sending invalid batchbuffers and dropping all further rendering into /dev/null. Reported-and-tested-by: Jiri Kosina <jkosina@suse.cz> References: https://bugs.freedesktop.org/show_bug.cgi?id=76554 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Oscar Mateo <oscar.mateo@intel.com> [danvet: Drop unused error, spotted by Oscar.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge branch 'drm-init-cleanup' of git://people.freedesktop.org/~danvet/drm ↵Dave Airlie2014-05-011-2/+7
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-next Next pull request, this time more of the drm de-midlayering work. The big thing is that his patch series here removes everything from drm_bus except the set_busid callback. Thierry has a few more patches on top of this to make that one optional to. With that we can ditch all the non-pci drm_bus implementations, which Thierry has already done for the fake tegra host1x drm_bus. Reviewed by Thierry, Laurent and David and now also survived some testing on my intel boxes to make sure the irq fumble is fixed correctly ;-) The last minute rebase was just to add the r-b tags from Thierry for the 2 patches I've redone. * 'drm-init-cleanup' of git://people.freedesktop.org/~danvet/drm: drm/<drivers>: don't set driver->dev_priv_size to 0 drm: Remove dev->kdriver drm: remove drm_bus->get_name drm: rip out dev->devname drm: inline drm_pci_set_unique drm: remove bus->get_irq implementations drm: pass the irq explicitly to drm_irq_install drm/irq: Look up the pci irq directly in the drm_control ioctl drm/irq: track the irq installed in drm_irq_install in dev->irq drm: rename dev->count_lock to dev->buf_lock drm: Rip out totally bogus vga_switcheroo->can_switch locking drm: kill drm_bus->bus_type drm: remove drm_dev_to_irq from drivers drm/irq: remove cargo-culted locking from irq_install/uninstall drm/irq: drm_control is a legacy ioctl, so pci devices only drm/pci: fold in irq_by_busid support drm/irq: simplify irq checks in drm_wait_vblank
| * drm: pass the irq explicitly to drm_irq_installDaniel Vetter2014-04-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately this requires a drm-wide change, and I didn't see a sane way around that. Luckily it's fairly simple, we just need to inline the respective get_irq implementation from either drm_pci.c or drm_platform.c. With that we can now also remove drm_dev_to_irq from drm_irq.c. Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/irq: remove cargo-culted locking from irq_install/uninstallDaniel Vetter2014-04-221-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The dev->struct_mutex locking in drm_irq.c only protects dev->irq_enabled. Which isn't really much at all and only prevents especially nasty ums userspace from concurrently installing the interrupt handling a few times. Or at least trying. There are tons of unlocked readers of dev->irqs_enabled in the vblank wait code (and by extension also in the pageflip code since that uses the same vblank timestamp engine). Real modesetting drivers should ensure that nothing can go haywire with a sane setup teardown sequence. So we only really need this for the drm_control ioctl, everywhere else this will just paper over nastiness. Note that drm/i915 is a bit specially due to the gem+ums combination. So there we also need to properly protect the entervt and leavevt ioctls. But it's definitely saner to do everything in one go than to drop the lock in-between. Finally there's the gpu reset code in drm/i915. That one's just race (concurrent userspace calls to for vblank waits of pageflips could spuriously fail). So wrap it up in with a nice comment since fixing this is more involved. v2: Rebase and fix commit message (Thierry) Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
OpenPOWER on IntegriCloud