summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-04-19drm/i915: Fix error path in i915_drm_resume_earlyImre Deak
If system resume fails, this may lead to a runtime PM wake reference underflow used for runtime PM state checking. Fixes: 1f814daca43a ("drm/i915: add support for checking if we hold an RPM reference") Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460963062-13211-2-git-send-email-imre.deak@intel.com
2016-04-18drm/i915/kbl: Reset secondary power well requests left on by DMC/KVMRImre Deak
The workaround added in commit c6782b76d31a ("drm/i915/gen9: Reset secondary power well requests left on by DMC/KVMR") needs to be applied on Kabylake too as shown by the corresponding timeout errors about power well 1 and MISC IO power well disabling in the latest CI run. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460748778-4484-1-git-send-email-imre.deak@intel.com
2016-04-18drm/i915: Replace nondescript 'WARN_ON(!lret)' with a sensible error messageVille Syrjälä
When a vblank wait times out in intel_atomic_wait_for_vblanks() we just get a cryptic 'WARN_ON(!ret)' backtrace in dmesg. Repace it with something that tells you what actually happened. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460978973-24945-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2016-04-18drm/i915: Avoid stalling on pending flips for legacy cursor updatesChris Wilson
The legacy cursor ioctl expects to be asynchronous with respect to other screen updates, in particular page flips. As X updates the cursor from a signal context, if the cursor blocks then it will stall both the input and output chains causing bad stuttering and horrible UX. Reported-and-tested-by: Rafael Ristovski <rafael.ristovski@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94980 Fixes: 5008e874edd34 ("drm/i915: Make wait_for_flips interruptible.") Suggested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Link: http://patchwork.freedesktop.org/patch/msgid/1460922166-20292-1-git-send-email-chris@chris-wilson.co.uk Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2016-04-18drm/i915/dsi: fix CHV dsi encoder hardware state readout on port CJani Nikula
Due to "some hardware limitation" the DPI enable bit in port C control register does not get set on VLV. As a workaround we check the status in pipe B conf register instead. The workaround was added in commit c0beefd29fcb1ca998f0f9ba41be8539f8eeba9b Author: Gaurav K Singh <gaurav.k.singh@intel.com> Date: Tue Dec 9 10:59:20 2014 +0530 drm/i915: Software workaround for getting the HW status of DSI Port C on BYT Empirical evidence (on Surface 3 with DSI on port C per VBT) shows that this is the case also on CHV, so extend the workaround to CHV. We still have the device ready register check in place, so this should not get confused with e.g. HDMI on pipe B. This fixes a number of state checker warnings on CHV DSI port C. Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460724451-13810-1-git-send-email-jani.nikula@intel.com
2016-04-15drm/i915: Show pin mapped counts and sizes in debugfsTvrtko Ursulin
Show a total and purgeable number of pin mapped objects and their total and purgeable size. Example output (new stat prefixed with a star): # cat i915_gem_objects 19920 objects, 289243136 bytes 19920 [18466] objects, 288714752 [267911168] bytes in gtt 0 [0] active objects, 0 [0] bytes 19917 [18466] inactive objects, 288714752 [267911168] bytes 0 unbound objects, 0 bytes 0 purgeable objects, 0 bytes 1 pinned mappable objects, 3145728 bytes 0 fault mappable objects, 0 bytes * 19914 [0] pin mapped objects, 285560832 [0] bytes [purgeable] 4294967296 [268435456] gtt total 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> Link: http://patchwork.freedesktop.org/patch/msgid/1460716493-27826-1-git-send-email-tvrtko.ursulin@linux.intel.com
2016-04-15drm/i915: Show pin mapped status in describe_objTvrtko Ursulin
Reflect the status of obj->mapping as added with the i915_gem_object_pin_map API. 'M' was chosen to designate the pin mapped status. 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>
2016-04-15drm/i915: Reject 'Center' scaling mode for eDP/DSI on GMCH platformsVille Syrjälä
We don't have a LVDS_BORDER_ENABLE type of bit for either eDP or DSI, and just trying to frob the display timings to include borders results in a corrupted picture. So reject the 'Center' scaling mode on GMCH platforms for eDP and DSI. TODO: Should really filter out the unsupported modes from the prop, but that would be fairly invasive since the prop is now created and stored by drm core. So leave it for a rainy day. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460488478-18311-6-git-send-email-ville.syrjala@linux.intel.com Tested-by: Jani Nikula <jani.nikula@intel.com>
2016-04-15drm/i915: Hook up pfit for DSIVille Syrjälä
Add the scaling mode property to DSI connectors, handle changes in the property value, and compute the panel fitter state during .compute_config(). v2: Handle BXT as well Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460488478-18311-5-git-send-email-ville.syrjala@linux.intel.com Tested-by: Jani Nikula <jani.nikula@intel.com>
2016-04-15drm/i915: Eliminate {vlv,bxt}_configure_dsi_pll()Ville Syrjälä
Fold the DSI PLL configuration functions into the DSI PLL enable functions since they are small and not called from anywhere else. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460488478-18311-4-git-send-email-ville.syrjala@linux.intel.com Tested-by: Jani Nikula <jani.nikula@intel.com>
2016-04-15drm/i915: Compute DSI PLL parameters during .compute_config()Ville Syrjälä
Compute the DSI PLL parameters during .compute_config() rather than .pre_pll_enable() so that we can fail gracefully if we can't find suitable parameters. In order to do that we need to store the DSI PLL parameters in pipe_config. v2: Handle BXT too Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460488478-18311-3-git-send-email-ville.syrjala@linux.intel.com Tested-by: Jani Nikula <jani.nikula@intel.com>
2016-04-15drm/i915: Setup DPLL/DPLLMD for DSI too on VLV/CHVVille Syrjälä
Set up DPLL and DPLL_MD even when driving DSI output on VLV/CHV. While the DPLL isn't used to provide the clock we still need the refclock, and it appears that the pixel repeat factor also has an effect on DSI output. So set up eveyrhing in DPLL and DPLL_MD as we would do for DP/HDMI/VGA, but don't actually enable the DPLL or configure the dividers via DPIO. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460488478-18311-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Jani Nikula <jani.nikula@intel.com>
2016-04-15drm/i915/bxt: PORT_PLL_REF_SEL bit should be set for all BXT variationsDongwon Kim
This patch is to correct one thing in this commit: commit 25a56705332add0363e47b3a0eca001d6fbd5bec Author: Dongwon Kim <dongwon.kim@intel.com> Date: Wed Mar 16 18:06:13 2016 -0700 drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit This reversed bit polarity is actually common for all BXT and APL SoCs. Therefore, revision checking in the original commit should be removed to make the bit set regardless of revision ID of GFX block. Signed-off-by: Dongwon Kim <dongwon.kim@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460673463-14453-1-git-send-email-dongwon.kim@intel.com
2016-04-15drm/i915/bxt: Enable runtime PMImre Deak
With the preceding fixes runtime PM should be functional, I could runtime suspend/resume the device without problems. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-17-git-send-email-imre.deak@intel.com
2016-04-15Revert "drm/i915/bxt: Disable power well support"Imre Deak
With the preceding fixes power well support should be functional on Broxton, I could enter/exit DC5 without problems. This reverts commit 18024199579882265653bfe9e2b1a3dcb5697cd9. CC: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-16-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Add HW state verification for DDI PHY and CDCLKImre Deak
I caught a few errors in our current PHY/CDCLK programming by sanity checking the actual programmed state, so I thought it would be also useful for the future. In addition to verifying the state after programming it also verify it after exiting DC5, to make sure DMC restored/kept intact everything related. v2: - Inlining __phy_reg_verify_state() doesn't make sense and also incorrect, so don't do it (PW/CI gcc) v3: - Rebase on latest -nightly Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459780030-15781-1-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Don't reprogram an already enabled DDI PHYImre Deak
If BIOS has already programmed and enabled a PHY, don't reprogram it as that may interfere with the currently active outputs. A follow-up patch will add state verification, so we can catch any misconfiguration on BIOS's behalf. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-14-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Sanitize the DBUF HW state together with CDCLKImre Deak
When determining whether CDCLK is enabled by BIOS and so we should skip reprogramming it, we didn't check the related DBUF power request and state. In theory BIOS could enable one without the other so check for this case and reprogram things if something is amiss. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-13-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Don't toggle power well 1 on-demandImre Deak
Power well 1 is managed by the DMC firmware so don't toggle it on-demand from the driver. This means we need to follow the BSpec display initialization sequence during driver loading and resuming (both system and runtime) and enable power well 1 only once there. Afterwards DMC will toggle power well 1 whenever entering/exiting DC5. For this to work we also need to do away getting the PLL power domain, since that just kept runtime PM disabled for good. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-12-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Power down DDI PHYs separately during the per PHY uninitImre Deak
The power-down step logically belongs to the individual PHY uninit sequence so move it there. The only functional change is that we will power down now PHY 1 separately before PHY 0 and preserve the other bits in the register which are defined as reserved. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-11-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Pass drm_i915_private to DDI PHY, CDCLK helpersImre Deak
For internal APIs passing dev_priv is preferred to reduce indirections, so convert over a few DDI PHY, CDCLK helpers. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-10-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/skl: Unexport skl_pw1_misc_io_initImre Deak
On Broxton we need to enable/disable power well 1 during the init/unit display sequence similarly to Skylake/Kabylake. The code for this will be added in a follow-up patch, but to prepare for that unexport skl_pw1_misc_io_init(). It's a simple function called only from a single place and having it inlined in the Skylake display core init/unit functions will make it easier to compare it with its Broxton counterpart. This also flips the order of Misc IO and power well 1 disabling which matches the enabling order. The specification doesn't prescribe the disabling order, so this should be fine. v2: - Fix incorrect enable vs. disable power well call in skl_display_core_uninit() (Patrik) - Add commit comment about chaning the order of PW1 and Misc IO power well disabling (Patrik) CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459773777-10701-1-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Suspend power domains during suspend-to-idleImre Deak
On SKL/KBL suspend-to-idle (aka freeze/s0ix) is performed with DMC firmware assistance where the target display power state is DC6. On Broxton on the other hand we don't use the firmware for this, but rely instead on a manual DC9 flow. For this we have to uninitialize the display following the BSpec display uninit sequence, just as during S3/S4, so make sure we follow this sequence. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-8-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/gen9: Fix DMC/DC state assertsImre Deak
The display power well support and DC state management doesn't depend on runtime PM support, so remove the incorrect asserts about this. Also Broxton does support DC5, so the related assert in assert_can_enable_dc5() is incorrect. There is a more generic and correct assert for this already in gen9_set_dc_state(), so we can remove all the other ones. At the same time convert WARNs to WARN_ONCE for consistency with the other DC state asserts. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-7-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/gen9: Make power well disabling synchronousImre Deak
So far we only power well enabling was synchronous not disabling. Since we don't exactly know how the firmware (both DMC and PCU) synchronizes against the actual power well state during DC transitions, make the disabling also synchronous. CC: Mika Kuoppala <mika.kuoppala@linux.intel.com> CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-6-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/gen9: Reset secondary power well requests left on by DMC/KVMRImre Deak
DMC forces on power well 1 and the misc IO power well by setting the corresponding request bits both in the BIOS and the DEBUG power well request registers. This is somewhat unexpected since the firmware should really just save and restore state but not alter it. We also depend on being able to disable power well 1, and the misc IO power well before entering S3/S4 on BXT and SKL or entering DC9 on BXT. To fix this make sure these request bits are cleared whenever we want to disable the given power wells. On SKL there is another twist where the firmware also clears the power well 1 request bit in HSW_POWER_WELL_DRIVER (but not that of the misc IO power well). This happens to not cause a problem due to the forced-on request bits in the other request registers. I've filed a bug about all this, but fixing that may take a while and having this sanity check in place makes sense even for future firmware versions. At the same time also check the KVMR request bits. I haven't seen this being altered, but we don't expect any request bits in here either, so sanitize this register as well. v2: - Apply the workaround on SKL as well. I noticed the related failure from the CI report, later Patrik also reported seeing it on his machine. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459851965-6137-1-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Add a note about BXT_PORT_CL1CM_DW30 being read-onlyImre Deak
This register is read-only, so we have never actually set OCL2_LDOFUSE_PWR_DIS in it as specified by the specification. Add a code comment about this. I filed a specification update request to clarify this there. CC: Arthur J Runyan <arthur.j.runyan@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-4-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Fix GRC code register field definitionsImre Deak
This has been corrected in BSpec quite some time ago, but we missed it somehow. The wrong field definitions resulted in configuring PHY0 with an incorrect GRC value. v2: - Remove the FIXME comment, we left in the code exactly about this issue. (Ville) CC: Arthur J Runyan <arthur.j.runyan@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-3-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Reject DMC firmware versions with known bugsImre Deak
DMC version 1.06 has a known bug, where the firmware polls forever for a port PLL to lock, if the PLL was disabled when entering DC5, which locks up the machine. Version 1.07 fixes this, so make that the minimum required version on BXT. CC: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-2-git-send-email-imre.deak@intel.com
2016-04-15drm/i915: use drm_crtc_send_vblank_event()Gustavo Padovan
Replace the legacy drm_send_vblank_event() with the new helper function. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460656118-16766-4-git-send-email-gustavo@padovan.org
2016-04-14drm/i915: Use fw_domains_put_with_fifo() on HSWVille Syrjälä
HSW still has the wake FIFO, so let's check it. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Deepak S <deepak.s@linux.intel.com> Fixes: 05a2fb157e44 ("drm/i915: Consolidate forcewake code") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460633942-24013-1-git-send-email-ville.syrjala@linux.intel.com Cc: stable@vger.kernel.org Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
2016-04-14drm/i915: Split gen8_gt_irq_handler into ack+handleVille Syrjälä
As we did on VLV, split the gt irq handling to ack and handler phases on CHV. Leave the BDW+ codepath mostly intact for now. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-13-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-14drm/i915: Eliminate passing dev+dev_priv to {snb,ilk}_gt_irq_handler()Ville Syrjälä
It looks silly to pass both dev and dev_priv to the snb/ilk gt irq handlers. Just pass dev_priv. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-12-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-14drm/i915: Move gt/pm irq handling out from irq disabled section on VLVVille Syrjälä
No need to actually handle the GT/PM interrupt while we have interrupt sources disabled. Move the actual processing to happen after we've restored VLV_IER and master interrupt enable. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-11-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-14drm/i915: Split VLV/CVH PIPESTAT handling into ack+handlerVille Syrjälä
Minimize the amount of stuff we do with interrupt sources disabled by splitting the PIPESTAT irq handling into ack+handler phases. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-10-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-14drm/i915: Split PORT_HOTPLUG_STAT ack out from i9xx_hpd_irq_handler()Ville Syrjälä
Split the VLV/CHV hoplug irq handling to ack and handler phases. This way we can move the actual irq handling outside the section where we have disabled the interrupt sources. For now, we leave things as is for pre-VLV GMCH platforms, but eventually they could get the same treatment. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-9-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-14drm/i915: Move variables to narrower scope in VLV/CHV irq handlersVille Syrjälä
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-8-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-14drm/i915: Eliminate loop from VLV irq handlerVille Syrjälä
Now that we've dealt with the races in clearing IIR bits via VLV_IER and the master interrupt enable, we can go ahead aliminate the loop from the VLV interrupt handler. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-7-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-14drm/i915: Clear VLV_IER around irq processingVille Syrjälä
On VLV/CHV the master interrupt enable bit only affects GT/PM interrupts. Display interrupts are not affected by the master irq control. Also it seems that the CPU interrupt will only be generated when the combined result of all GT/PM/display interrupts has a 0->1 edge. We already use the master interrupt enable bit to make sure GT/PM interrupt can generate such an edge if we don't end up clearing all IIR bits. We must do the same for display interrupts, and for that we can simply clear out VLV_IER, and restore after we've acked all the interrupts we are about to process. So with both master interrupt enable and VLV_IER cleared out, we will guarantee that there will be a 0->1 edge if any IIR bits are still set at the end, and thus another CPU interrupt will be generated. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 579de73b048a ("drm/i915: Exit cherryview_irq_handler() after one pass") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-6-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-14drm/i915: Clear VLV_MASTER_IER around irq processingVille Syrjälä
Like on CHV, let's clear out the master irq enable bit when we ack GT/PM interrupts. This will allow GT/PM interrupts to re-raise the CPU interrupt if we fail to clear all the bits from the IIR(s). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-5-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-14drm/i915: Clear VLV_IIR after PIPESTATVille Syrjälä
On VLV/CHV VLV_IIR is not double double buffered, and it doesn't detect edges from PIPESTAT & co. like it does on gen4. Instead it just directly latches the level from PIPESTAT & co. That means we must clear VLV_IIR after PIPESTAT & co. or else we'll get a spurious bit in VLV_IIR every single time. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-14drm/i915: Set up VLV_MASTER_IER consistentlyVille Syrjälä
We're lacking VLV_MASTER_IER setup from valleyview_irq_preinstall(), so add it there. Also cargo cult in some POSTING_READ()s to match the other platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-14drm/i915: Use GEN8_MASTER_IRQ_CONTROL consistentlyVille Syrjälä
Use GEN8_MASTER_IRQ_CONTROL instead of DE_MASTER_IRQ_CONTROL or MASTER_INTERRUPT_ENABLE with the GEN8_MASTER_IRQ register. They're all bit 31 so there's no actual bug here, but let's be consistent which name we use for the bit. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-14drm/i915: Ignore GTFIFODBG FIFO free entry fields on CHVVille Syrjälä
On CHV GTFIFODBG has some read-only bits to indicate the number of free FIFO entries. Ignore these when checking to see if any of the sticky error bits are set. This gets rid of these during device resume: [drm:cherryview_enable_rps] GT fifo had a previous error 1080000 While at it, move the assignments out of the if(). Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460570970-14073-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-04-14drm/i915/mocs: Program MOCS for all engines on initPeter Antoine
Allow for the MOCS to be programmed for all engines. Currently we program the MOCS when the first render batch goes through. This works on most platforms but fails on platforms that do not run a render batch early, i.e. headless servers. The patch now programs all initialised engines on init and the RCS is programmed again within the initial batch. This is done for predictable consistency with regards to the hardware context. Hardware context loading sets the values of the MOCS for RCS and L3CC. Programming them from within the batch makes sure that the render context is valid, no matter what the previous state of the saved-context was. v2: posted correct version to the mailing list. v3: moved programming to within engine->init_hw() (Chris Wilson) v4: code formatting and white-space changes. (Chris Wilson) Testcase: igt/gem_mocs_settings Signed-off-by: Peter Antoine <peter.antoine@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460556205-6644-1-git-send-email-chris@chris-wilson.co.uk
2016-04-14drm/i915: Late request cancellations are harmfulChris Wilson
Conceptually, each request is a record of a hardware transaction - we build up a list of pending commands and then either commit them to hardware, or cancel them. However, whilst building up the list of pending commands, we may modify state outside of the request and make references to the pending request. If we do so and then cancel that request, external objects then point to the deleted request leading to both graphical and memory corruption. The easiest example is to consider object/VMA tracking. When we mark an object as active in a request, we store a pointer to this, the most recent request, in the object. Then we want to free that object, we wait for the most recent request to be idle before proceeding (otherwise the hardware will write to pages now owned by the system, or we will attempt to read from those pages before the hardware is finished writing). If the request was cancelled instead, that wait completes immediately. As a result, all requests must be committed and not cancelled if the external state is unknown. All that remains of i915_gem_request_cancel() users are just a couple of extremely unlikely allocation failures, so remove the API entirely. A consequence of committing all incomplete requests is that we generate excess breadcrumbs and fill the ring much more often with dummy work. We have completely undone the outstanding_last_seqno optimisation. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93907 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-16-git-send-email-chris@chris-wilson.co.uk
2016-04-14drm/i915: Reorganise legacy context switch to cope with late failureChris Wilson
After mi_set_context() succeeds, we need to update the state of the engine's last_context. This ensures that we hold a pin on the context whilst the hardware may write to it. However, since we didn't complete the post-switch setup of the context, we need to force the subsequent use of the same context to complete the setup (which means updating should_skip_switch()). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-15-git-send-email-chris@chris-wilson.co.uk
2016-04-14drm/i915: Split out !RCS legacy context switchingChris Wilson
Having the !RCS legacy context switch threaded through the RCS switching code makes it much harder to follow and understand. In the next patch, I want to fix a bug handling the incomplete switch, this is made much simpler if we segregate the two paths now. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-14-git-send-email-chris@chris-wilson.co.uk
2016-04-14drm/i915: Move the mb() following release-mmap into release-mmapChris Wilson
As paranoia, we want to ensure that the CPU's PTEs have been revoked for the object before we return from i915_gem_release_mmap(). This allows us to rely on there being no outstanding memory accesses from userspace and guarantees serialisation of the code against concurrent access just by calling i915_gem_release_mmap(). v2: Reduce the mb() into a wmb() following the revoke. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: "Goel, Akash" <akash.goel@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-13-git-send-email-chris@chris-wilson.co.uk
2016-04-14drm/i915: Force ringbuffers to not be at offset 0Chris Wilson
For reasons unknown Sandybridge GT1 (at least) will eventually hang when it encounters a ring wraparound at offset 0. The test case that reproduces the bug reliably forces a large number of interrupted context switches, thereby causing very frequent ring wraparounds, but there are similar bug reports in the wild with the same symptoms, seqno writes stop just before the wrap and the ringbuffer at address 0. It is also timing crucial, but adding various delays hasn't helped pinpoint where the window lies. Whether the fault is restricted to the ringbuffer itself or the GTT addressing is unclear, but moving the ringbuffer fixes all the hangs I have been able to reproduce. References: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=93262 Testcase: igt/gem_exec_whisper/render-contexts-interruptible #snb-gt1 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-12-git-send-email-chris@chris-wilson.co.uk
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 05:47:32 +0000