aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* drm/i915: don't always do full mode sets when infoframes are enabledJesse Barnes2014-12-05
| | | | | | | | | | | | | | | Partial revert of commit 206645910b9796bff13fcdb67bdca166b724ba62 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Nov 5 14:26:09 2014 -0800 drm/i915: check for audio and infoframe changes across mode sets v2 References: https://bugs.freedesktop.org/show_bug.cgi?id=86683 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Li Xu <li.l.xu@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: Reject modeset when the same digital port is used more than onceVille Syrjälä2014-12-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On pre-HSW we have two encoders per digital port: one HDMI, one DP. However they are the same physical port in hardware and we can't enable both at the same time. Reject the modeset if the user attempts this. So far we've been saved by the fact that we never see both HDMI and DP connectors as connected. But if the user decides to force a mode anyway, all kinds of funny stuff might happen. Unfortunately we don't seem to have any way to inform userspace that such configurations are invalid except by returning an error from setcrtc. possible_clones only covers real cloning situations, and looking at the connector names doesn't work either since we don't always register both connectors for the same port. I suppose the only way to fix that would be to expose only a single encoder per digital port like we do on HSW+ but that would be a fairly large undertaking for little gain. kms_setmode hits this since it forces modes on non-connected VGA and HDMI connectors. Previosuly it just resulted in weirdness such as failed link training. With this patch it will now get an error back from the kernel and will die with an assert since it thinks that the configuration should be fine. v2: Deal with INTEL_OUTPUT_UNKNOWN (Paulo) Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: mask RPS IRQs properly when disabling RPSImre Deak2014-12-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Atm, igt/gem_reset_stats can trigger the recently added WARN on left-over PM_IIR bits in gen6_enable_rps_interrupts(). There are two reasons for this: 1. we call intel_enable_gt_powersave() without a preceeding intel_disable_gt_powersave() 2. gen6_disable_rps_interrupts() doesn't mask interrupts in PM_IMR 1. means RPS interrupts will remain enabled and can be serviced during the HW initialization after a GPU reset. 2. means even if we called gen6_disable_rps_interrupts() any new RPS interrupt during RPS initialization would still propagate to PM_IIR too early (though wouldn't be serviced). This patch solves the 2. issue by also masking interrupts in PM_IMR, the following patch fixes 1. getting rid of the WARN. This also makes intel_enable_gt_powersave() and intel_disable_gt_powersave() more symmetric. Since gen6_disable_rps_interrupts() is called during driver loading with i915 interrupts disabled add a new version of gen6_disable_pm_irq() that doesn't WARN for this. Also while at it, get the irq_lock around the whole PM_IMR/IER/IIR programming sequence and make sure that any queued PM_IIR bit is also cleared. The WARN was caught by PRTS after I sent my previous RPS sanitizing patchset and I could easily reproduce it on HSW. To actually fix it we also need the next patch. Reported-by: He, Shuang <shuang.he@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Tune down spurious CRC interrupt warningDaniel Vetter2014-12-03
| | | | | | | | | | | | | | We don't really synchronously turn them off from debugfs. We try to avoid hitting them too badly by waiting one vblank, but apparently the irq handler can still race through that gap. Since this isn't really all that important for testcases, only for debugging CRC issues let's tune it down to a debug message. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82602 Cc: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
* drm/i915: Fix context object leak for legacy contextsThomas Daniel2014-12-03
| | | | | | | | | | | | Dynamic context pinning for LRCs introduced a leak in legacy mode. Reinstate context unreference in i915_gem_free_request for legacy contexts. Leak reported by i-g-t/drv_module_reload fixed by this patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86507 Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: John Harrison<John.C.Harrison@Intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/skl: Update in Gen9 multi-engine forcewake rangeAkash Goel2014-12-03
| | | | | | | | | | Updates in forcewake range for Render/Media/Common power wells for Gen9. Signed-off-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Zhe Wang <zhe1.wang@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/eDP: When enabling panel VDD cancel pending disable workerEgbert Eich2014-12-03
| | | | | | | | | | | | | | | | | | Before testing if the panel VDD is enabled on eDP cancel any pending disable worker. This makes sure the worker will be triggered with a delay from the last time edp_panel_vdd_schedule_off() is called, not the first time. This avoids unnecessary overhead. https://bugs.freedesktop.org/show_bug.cgi?id=86201 v2: use cancel_delayed_work() instead of cancel_delayed_work_sync() as the pps_mutexes will provide the required serialization with edp_panel_vdd_work() while the sync variant may deadlock. Suggested by Ville Syrjälä <ville.syrjala@linux.intel.com>. Made commit message a bit clearer. Signed-off-by: Egbert Eich <eich@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Handle runtime pm in the CRC setup codeDaniel Vetter2014-12-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The crc code doesn't handle anything really that could drop the register state (by design so that we have less complexity). Which means userspace may only start crc capture once the pipe is fully set up. With an i-g-t patch this will be the case, but there's still the problem that this results in obscure unclaimed register write failures. Which is a pain to debug. So instead make sure we don't have the basic unclaimed register write failure by grabbing runtime pm references. And reject completely invalid requests with -EIO. This is still racy of course, but for a test library we don't really care - if userspace shuts down the pipe right afterwards the entire setup will be lost anyway. v2: Put instead of get, spotted by Damien. Also explain the runtime pm dance. v3: There's really no need for rpm get/put since power_is_enabled only checks software state (Damien). References: https://bugs.freedesktop.org/show_bug.cgi?id=86092 Cc: Damien Lespiau <damien.lespiau@intel.com> (v2) Tested-by: lu hua <huax.lu@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
* drm/i915: Disable crtcs gracefully before GPU reset on gen3/4Ville Syrjälä2014-12-03
| | | | | | | | | The GPU reset also resets the display on gen3/4. The g33 docs say we should disable all planes before flipping the reset switch. Just disable all the crtcs instead. That seems a nicer thing to do anyway. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Grab modeset locks for GPU rest on pre-ctgVille Syrjälä2014-12-03
| | | | | | | | | | | | | | | | | | | On gen4 and earlier the GPU reset also resets the display, so we should protect against concurrent modeset operations. Grab all the modeset locks around the entire GPU reset dance, remebering first ti dislogde any pending page flip to make sure we don't deadlock. Any pageflip coming in between these two steps should fail anyway due to reset_in_progress, so this should be safe. This fixes a lot of failed asserts in the modeset code when there's a modeset racing with the reset. Naturally the asserts aren't happy when the expected state has disappeared. v2: Drop UMS checks, complete pending flips after the reset (Daniel) Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Implement GPU reset for g33Ville Syrjälä2014-12-03
| | | | | | | | | g33 seems to sit somewhere between the 915/945/965 style and the g4x style. The bits look like g4x, but we still need to do a full reset including display. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Implement GPU reset for 915/945Ville Syrjälä2014-12-03
| | | | | | | 915/945 have the same reset registers as 965, so share the code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Restore the display config after a GPU reset on gen4Ville Syrjälä2014-12-03
| | | | | | | | | | | | | On pre-ctg GPU reset also resets the display hardware. Force a mode restore after the GPU reset, and also re-init clock gating. v2: Use intel_modeset_init_hw() instead of intel_init_clock_gating() in case more relevant stuff gets added there at some point Restore interrupts after the reset as well Tested-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix gen4 GPU resetVille Syrjälä2014-12-03
| | | | | | | | | | On pre-ctg the reset bit directly controls the reset signal. We must assert it for >=20usec and then deassert it. Bit 1 is a RO status bit which should also go down when the reset is no longer asserted. Tested-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Stop gathering error states for CS error interruptsDaniel Vetter2014-12-03
| | | | | | | | | | | | | | | | | | | | | | | | There's quite a few bug reports with error states where the error reasons makes just about no sense at all. Like dying on tlbs for a display plane that's not even there. Also users don't really report a lot of bad side effects generally, just the error states. Furthermore we don't even enable these interrupts any more on gen5+ (though the handling code is still there). So this mostly concerns old platforms. Given all that lets make our lives a bit easier and stop capturing error states, in the hopes that we can just ignore them. In case that's not true and the gpu indeed dies the hangcheck should eventually kick in. And I've left some debug log in to make this case noticeble. Referenced bug is just an example. v2: Fix missing \n Jani spotted. References: https://bugs.freedesktop.org/show_bug.cgi?id=82095 References: https://bugs.freedesktop.org/show_bug.cgi?id=85944 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Disallow pin ioctl completely for kms driversDaniel Vetter2014-12-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem here is that SNA pins batchbuffers to etch out a bit more performance. Iirc it started out as a w/a for i830M (which we've implemented in the kernel since a long time already). The problem is that the pin ioctl wasn't added in commit d23db88c3ab233daed18709e3a24d6c95344117f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri May 23 08:48:08 2014 +0200 drm/i915: Prevent negative relocation deltas from wrapping Fix this by simply disallowing pinning from userspace so that the kernel is in full control of batch placement again. Especially since distros are moving towards running X as non-root, so most users won't even be able to see any benefits. UMS support is dead now, but we need this minimal patch for backporting. Follow-up patch will remove the pin ioctl code completely. Note to backporters: You must have both commit b45305fce5bb1abec263fcff9d81ebecd6306ede Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Dec 17 16:21:27 2012 +0100 drm/i915: Implement workaround for broken CS tlb on i830/845 which laned in 3.8 and commit c4d69da167fa967749aeb70bc0e94a457e5d00c1 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Sep 8 14:25:41 2014 +0100 drm/i915: Evict CS TLBs between batches which is also marked cc: stable. Otherwise this could introduce a regression by disabling the userspace w/a without the kernel w/a being fully functional on i830/45. References: https://bugs.freedesktop.org/show_bug.cgi?id=76554#c116 Cc: stable@vger.kernel.org # requires c4d69da167fa967749a and v3.8 Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
* drm/i915: Only warn the first time we attempt to mmio whilst suspendedChris Wilson2014-12-03
| | | | | | | | | | | | | | | | | | | | | | In all likelihood we will do a few hundred errnoneous register operations if we do a single invalid register access whilst the device is suspended. As each instance causes a WARN, this floods the system logs and can make the system unresponsive. The warning was first introduced in commit b2ec142cb0101f298f8e091c7d75b1ec5b809b65 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Feb 21 13:52:25 2014 -0300 drm/i915: call assert_device_not_suspended at gen6_force_wake_work and despite the claims the WARN is still encountered in the wild today. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/chv: Enable AVI, SPD and HDMI infoframes for CHV.Clint Taylor2014-12-03
| | | | | | | | CHV infoframes were not being enabled. Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Don't clobber crtc->new_config when nothing changesVille Syrjälä2014-12-03
| | | | | | | | | | | | | | | | When doing a nop modeset we currently leave crtc->new_config point at the already freed temporary pipe_config. That will anger the sanity checks in intel_modeset_update_state() when the nop modeset gets followed by a GPU reset on gen3/4 where the display block gets fully reinitialized during the reset. So leave crtc->new_config alone until we know a modeset is actually required. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm: rcar-du: Fix NULL encoder pointer dereferenceLaurent Pinchart2014-12-02
| | | | | | | | | | | | | | The DRM connector's encoder pointer is managed internally by the DRM core and set to NULL when the DRM connector is disconnected from the CRTC it was attached to. This results in a NULL pointer dereference in the HDMI connector functions when trying to call the associated slave encoder's operations. Fix this by retrieving the slave encoder pointer from the R-Car connector structure instead of the DRM connector structure. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge tag 'drm-intel-next-2014-11-21-fixed' of ↵Dave Airlie2014-12-02
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next drm-intel-next-2014-11-21: - infoframe tracking (for fastboot) from Jesse - start of the dri1/ums support removal - vlv forcewake timeout fixes (Imre) - bunch of patches to polish the rps code (Imre) and improve it on bdw (Tom O'Rourke) - on-demand pinning for execlist contexts - vlv/chv backlight improvements (Ville) - gen8+ render ctx w/a work from various people - skl edp programming (Satheeshakrishna et al.) - psr docbook (Rodrigo) - piles of little fixes and improvements all over, as usual * tag 'drm-intel-next-2014-11-21-fixed' of git://anongit.freedesktop.org/drm-intel: (117 commits) drm/i915: Don't pin LRC in GGTT when dumping in debugfs drm/i915: Update DRIVER_DATE to 20141121 drm/i915/g4x: fix g4x infoframe readout drm/i915: Only call mod_timer() if not already pending drm/i915: Don't rely upon encoder->type for infoframe hw state readout drm/i915: remove the IRQs enabled WARN from intel_disable_gt_powersave drm/i915: Use ggtt error obj capture helper for gen8 semaphores drm/i915: vlv: increase timeout when setting idle GPU freq drm/i915: vlv: fix cdclk setting during modeset while suspended drm/i915: Dump hdmi pipe_config state drm/i915: Gen9 shadowed registers drm/i915/skl: Gen9 multi-engine forcewake drm/i915: Read power well status before other registers for drpc info drm/i915: Pin tiled objects for L-shaped configs drm/i915: Update ring freq for full gpu freq range drm/i915: change initial rps frequency for gen8 drm/i915: Keep min freq above floor on HSW/BDW drm/i915: Use efficient frequency for HSW/BDW drm/i915: Can i915_gem_init_ioctl drm/i915: Sanitize ->lastclose ...
| * drm/i915: Don't pin LRC in GGTT when dumping in debugfsThomas Daniel2014-12-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LRC object does not need to be mapped into the GGTT when dumping. A side-effect of this patch is that a compiler warning goes away (not checking return value of i915_gem_obj_ggtt_pin). v2: Broke out individual context dumping into a new function as the indentation was getting a bit crazy. Added notification of contexts with no gem object for debugging purposes. Removed unnecessary pin_pages and unpin_pages, replaced with explicit get_pages for the context object as there may be no backing store allocated at this time (Comment for get_pages says "Ensure that the associated pages are gathered from the backing storage and pinned into our object"). Improved error checking - get_pages and get_page are checked for failure. Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> [danvet: Align paramter continuation lines properly. Also add some braces to the nested loops again for readability.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Update DRIVER_DATE to 20141121Daniel Vetter2014-11-21
| | | | | | | | Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/g4x: fix g4x infoframe readoutJesse Barnes2014-11-20
| | | | | | | | | | | | | | | | Need to check the port too. Reported-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Only call mod_timer() if not already pendingChris Wilson2014-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The final arrangement of updating timer->expires and calling mod_timer() used in commit 672e7b7c1849c904b2c55185906b3940843c55c6 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Nov 19 09:47:19 2014 +0000 drm/i915: Don't continually defer the hangcheck turns out to be very unsafe. Try again. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Don't rely upon encoder->type for infoframe hw state readoutDaniel Vetter2014-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | encoder->type can change underneath us and doesn't need to reflect actual hw state (since we don't construct it from hw state like e.g. encoder->crtc crtc->config). And this can indeed happen: 1) Boot with plugged-in hdmi screen. Since we only set ->type in the probe functions this means we won't detect any infoframes since type is still unkown. 2) First probe sets type to HDMI. 3) If the first modeset now does _not_ happen on the HDMI pipe with infoframes encoder->get_config suddenly sees infoframes and the state checker gets angry. Fix this by only relying on actual hw state when figuring out whether the ddi port is in hdmi mode and sends infoframes. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Paulo Zanoni <przanoni@gmail.com> Reported-by: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: remove the IRQs enabled WARN from intel_disable_gt_powersaveImre Deak2014-11-20
| | | | | | | | | | | | | | | | | | | | | | This function can be called now with i915 interrupts enabled, so the corresponding WARN is incorrect, remove it. I think this was spotted by Paulo during his review, but since I already removed the same WARN from intel_suspend_gt_powersave() I missed then his point. Spotted-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Use ggtt error obj capture helper for gen8 semaphoresDaniel Vetter2014-11-20
| | | | | | | | | | | | | | | | Spotted while reading and trying to understand how our error capture code deals with full ppgtt. Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * drm/i915: vlv: increase timeout when setting idle GPU freqImre Deak2014-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | | I saw punit timeouts in vlv_set_rps_idle() while running various subtests of pm_rpm. Increasing the timeout to 100ms got rid of the issue. Testcase: igt/pm_rpm Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939 Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Guo Jinxian <jinxianx.guo@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: vlv: fix cdclk setting during modeset while suspendedImre Deak2014-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently after doing DPMS-OFF on all outputs CDCLK won't be set to its minimum value as it should. A subsequent modeset to turn off all outputs will thus run with all power domains disabled, and notice that it needs to change CDCLK to its minimum value. Since the power domains are disabled this will emit a register-access-while-suspended WARN and fail to set the minimum freq. The proper solution for this is to set the minimum frequency during DPMS-OFF. That needs a bigger rework that would take into account the user DPMS setting too during the calculation of the new modesetting configuration. Until that's done this stop-gap solution gets the PIPE-A power domain during setting the CDCLK; this domain covers the HW blocks needed for this. Idea to use PIPE-A domain from Ville. Testcase: igt/pm_rpm Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939 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: Dump hdmi pipe_config stateDaniel Vetter2014-11-20
| | | | | | | | | | | | | | | | Makes it easier to debug infoframe mismatches. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * drm/i915: Gen9 shadowed registersZhe Wang2014-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For MMIO registers which are shadowed, force wake is not needed to write to these registers. v2: Rebase on top of nightly (Damien) v3: Rebase on top of "Gen9 multiple-engine forcewake" changes v4: (Mika, Bob, done by Damien) - Reorder the shadowed registers by popularity Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Zhe Wang <zhe1.wang@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/skl: Gen9 multi-engine forcewakeZhe Wang2014-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable multi-engine forcewake for Gen9. v2: (Damien) - Rebase on top of nightly - Move the register range definitions to intel_uncore.c - Whitespace fixes v3: (Addressing Mika's comment, done by Damien) - Use REG_RANGE() (introduced after the patch was written) - Add a SKL_NEEDS_FORCE_WAKE() macro that gets rid of a useless comparison to FORCEWAKE (reg 0xa18c is not used on SKL) v4: (Damien) - Use newly introduced ASSIGN_READ/WRITE_MMIO_VFUNCS() macros Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Zhe Wang <zhe1.wang@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Read power well status before other registers for drpc infoVille Syrjälä2014-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Trying to read the status of the power wells right after taking forcewake for the other register reads makes little sense. Most of the time the power wells will still be up due to the recent forcewake. Instead do the power well status read first, and only then read the register needing forcewake. This way the reported power well status can actually reflect what's going on in the system. Cc: Deepak S <deepak.s@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Pin tiled objects for L-shaped configsDaniel Vetter2014-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let's just throw in the towel on this one and take the cheap way out. Based on a patch from Chris Wilson, but checking for a different bit. Chris' patch checked for even bank layout, this one here for a magic bit. Given the evidence we've gathered (not much) both work I think, but checking for the magic bit might be more accurate. Anyway, works on my gm45 here. For paranoi restrict to gen4 (and mobile), since we've only ever seen this on gm45 and i965gm. Also add some debugfs output so that we can skip the tiled swapping tests properly in these cases. v2: Clean up the quirk'ed pin count in free_object to avoid upsetting the WARN_ON. Spotted by Chris. Cc: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28813 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45092 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Update ring freq for full gpu freq rangeTom O'Rourke2014-11-20
| | | | | | | | | | | | | | | | | | | | | | | | In __gen6_update_ring_freq, use the full range of possible gpu frequencies from max_freq to min_freq. The actual gpu frequency could be outside the range from max_freq_softlimit to min_freq_softlimit due to power/thermal constraints. Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: change initial rps frequency for gen8Tom O'Rourke2014-11-20
| | | | | | | | | | | | | | | | | | In gen8_enable_rps, change the initial rps setting to the min_freq_softlimit (same as gen6_enable_rps). Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Keep min freq above floor on HSW/BDWTom O'Rourke2014-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Set the min_freq_softlimit to max(RPe, 450MHz). Setting a floor can ensure a minimum experience level. The 450MHz value came from a power and performance study of various types of workloads (3D, Media, GPGPU, idle, etc). v2: rebased Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Use efficient frequency for HSW/BDWTom O'Rourke2014-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added gen6_init_rps_frequencies() to initialize the rps frequency values. This function replaces parse_rp_state_cap(). In addition to reading RPn, RP0, and RP1 from RP_STATE_CAP register, the new function reads efficient frequency (aka RPe) from pcode for Haswell and Broadwell and sets the turbo softlimits. The turbo minimum frequency softlimit is set to RPe for Haswell and Broadwell and to RPn otherwise. For RPe, the efficiency is based on the frequency/power ratio (MHz/W); this is considering GT power and not package power. The efficent frequency is the highest frequency for which the frequency/power ratio is within some threshold of the highest frequency/power ratio. A fixed decrease in frequency results in smaller decrease in power at frequencies less than RPe than at frequencies above RPe. v2: Following suggestions from Chris Wilson and Daniel Vetter to extend and rename parse_rp_state_cap and to open-code a poorly named function. Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Remove unused variables.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Can i915_gem_init_ioctlDaniel Vetter2014-11-20
| | | | | | | | | | | | | | | | | | Found one more! With this we can clear up the ggtt init code a bit, yay! Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * drm/i915: Sanitize ->lastcloseDaniel Vetter2014-11-20
| | | | | | | | | | | | | | | | With this all the ums nonsense around gem setup/teardown has disappeared, yay! Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * drm/i915: Ditch dev_priv->ums.mm_suspendDaniel Vetter2014-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Again just complicates gem init functions and makes a general mess out of everything. Good riddance! v2: In my enthusiasm to start removing dri1/ums crud I went overboard a bit and killed parts of hangcheck. Resurrect it. Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * drm/i915: No-Op enter/leave vt gem ioctlDaniel Vetter2014-11-19
| | | | | | | | | | | | | | | | We've killed ums support by now, it's time to reap the benefits. This one here is getting in the way of doing some ring init cleanup. Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * drm/i915: Drop checks for initializationDaniel Vetter2014-11-19
| | | | | | | | | | | | | | | | | | | | KMS always intializes, this was only a valid check when userspace was still in control of the kernel driver. v2: Comment that we outright reject all dri1/ums params. Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Replace dri1 functions with drm_noopDaniel Vetter2014-11-19
| | | | | | | | | | | | | | Whether we'll reject them or no-op doesn't really matter ... Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Remove DRI1 ring accessors and APIChris Wilson2014-11-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | With the deprecation of UMS, and by association DRI1, we have a tough choice when updating the ring access routines. We either rewrite the DRI1 routines blindly without testing (so likely to be broken) or take the liberty of declaring them no longer supported and remove them entirely. This takes the latter approach. v2: Also remove the DRI1 sarea updates Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Fix rebase conflicts.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Pin the ringbuffer backing object to GGTT on-demandThomas Daniel2014-11-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Same as with the context, pinning to GGTT regardless is harmful (it badly fragments the GGTT and can even exhaust it). Unfortunately, this case is also more complex than the previous one because we need to map and access the ringbuffer in several places along the execbuffer path (and we cannot make do by leaving the default ringbuffer pinned, as before). Also, the context object itself contains a pointer to the ringbuffer address that we have to keep updated if we are going to allow the ringbuffer to move around. v2: Same as with the context pinning, we cannot really do it during an interrupt. Also, pin the default ringbuffers objects regardless (makes error capture a lot easier). v3: Rebased. Take a pin reference of the ringbuffer for each item in the execlist request queue because the hardware may still be using the ringbuffer after the MI_USER_INTERRUPT to notify the seqno update is executed. The ringbuffer must remain pinned until the context save is complete. No longer pin and unpin ringbuffer in populate_lr_context() - this transient address is meaningless and the pinning can cause a sleep while atomic. v4: Moved ringbuffer pin and unpin into the lr_context_pin functions. Downgraded pinning check BUG_ONs to WARN_ONs. v5: Reinstated WARN_ONs for unexpected execlist states. Removed unused variable. Issue: VIZ-4277 Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Pin the context backing objects to GGTT on-demandOscar Mateo2014-11-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Up until now, we have pinned every logical ring context backing object during creation, and left it pinned until destruction. This made my life easier, but it's a harmful thing to do, because we cause fragmentation of the GGTT (and, eventually, we would run out of space). This patch makes the pinning on-demand: the backing objects of the two contexts that are written to the ELSP are pinned right before submission and unpinned once the hardware is done with them. The only context that is still pinned regardless is the global default one, so that the HWS can still be accessed in the same way (ring->status_page). v2: In the early version of this patch, we were pinning the context as we put it into the ELSP: on the one hand, this is very efficient because only a maximum two contexts are pinned at any given time, but on the other hand, we cannot really pin in interrupt time :( v3: Use a mutex rather than atomic_t to protect pin count to avoid races. Do not unpin default context in free_request. v4: Break out pin and unpin into functions. Fix style problems reported by checkpatch v5: Remove unpin_lock as all pinning and unpinning is done with the struct mutex already locked. Add WARN_ONs to make sure this is the case in future. Issue: VIZ-4277 Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Clean up execlist queue items in retire_workThomas Daniel2014-11-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No longer create a work item to clean each execlist queue item. Instead, move retired execlist requests to a queue and clean up the items during retire_requests. v2: Fix legacy ring path broken during overzealous cleanup v3: Update idle detection to take execlists queue into account v4: Grab execlist lock when checking queue state v5: Fix leaking requests by freeing in execlists_retire_requests. Issue: VIZ-4274 Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * Merge tag 'drm-intel-fixes-2014-11-19' into drm-intel-next-queuedDaniel Vetter2014-11-19
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So with all the code movement and extraction in intel_pm.c in -next git is hopelessly confused with commit 2208d655a91f9879bd9a39ff9df05dd668b3512c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Nov 14 09:25:29 2014 +0100 drm/i915: drop WaSetupGtModeTdRowDispatch:snb from -fixes. Worse even small changes in -next move around the conflict context so rerere is equally useless. Let's just backmerge and be done with it. Conflicts: drivers/gpu/drm/i915/i915_drv.c drivers/gpu/drm/i915/intel_pm.c Except for git getting lost no tricky conflicts really. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-27 22:58:35 -0400