- 29 Sep, 2014 3 commits
-
-
Rodrigo Vivi authored
Reference: Predator r73977 / HSD 4394389 Cc: Arthur Runyan <arthur.j.runyan@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Arthur Runyan <arthur.j.runyan@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
Let's make sure PSR is propperly disabled before to re-enabled it. According to Spec, after disabled PSR CTL, the Idle state might occur up to 24ms, that is one full frame time (1/refresh rate), plus SRD exit training time (max of 6ms), plus SRD aux channel handshake (max of 1.5ms). So if something went wrong PSR will be disabled until next full enable/disable setup. v2: The 24ms above takes in account 16ms for refresh rate on 60Hz mode. However on low frequency modes this can take longer. So let's use 50ms for safeness. v3: Move wait out of psr.lock critical area. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
The sw cache clean on BDW is a tempoorary workaround because we cannot set cache clean on blt ring with risk of hungs. So we are doing the cache clean on sw. However we are doing much more than needed. Not only when using blt ring. So, with this extra w/a we minimize the ammount of cache cleans and call it only on same cases that it was being called on gen7. The traditional FBC Cache clean happens over LRI on BLT ring when there is a frontbuffer touch happening. frontbuffer tracking set fbc_dirty variable to let BLT flush that it must clean FBC cache. fbc.need_sw_cache_clean works in the opposite information direction of ring->fbc_dirty telling software on frontbuffer tracking to perform the cache clean on sw side. v2: Clean it a little bit and fully check for Broadwell instead of gen8. v3: Rebase after frontbuffer organization. v4: Wiggle confused me. So fixing v3! Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
- 24 Sep, 2014 3 commits
-
-
Rodrigo Vivi authored
The panel has to be reconfigured only when it really loose the power. The traditional enable/disable sequence already take care of this so we can minimize the time spend on every re-enable. Signed-off-by:
-
Rodrigo Vivi authored
We don't need to setup everything else if it doesn't match all conditions. Signed-off-by:
-
Rodrigo Vivi authored
psr_enabled is already by itself a setup once so let's put the W/As there and rename old setup once to setup_vsc. Signed-off-by:
-
- 23 Sep, 2014 2 commits
-
-
Paulo Zanoni authored
Currently, calling intel_fbc_enabled() will trigger a register read. And we call it a lot of times, even when FBC is disabled, so saving a few cycles would be a good thing. Another reason for this patch is because we currently call intel_fbc_enabled() while the HW is runtime suspended, so the read makes no sense and triggers a WARN. This happens even if FBC is disabled by default. Of course one could argue that we just shouldn't be calling intel_fbc_enabled() while the driver is runtime suspended, and I agree that's a good argument, but I still think that the reason explained in the first paragraph already justifies the patch. This problem can easily be reproduced with many subtests of igt/pm_rpm, and it is a regression introduced by: commit c5ad011d Author: Rodrigo Vivi <rodrigo.vivi@intel.com> Date: Mon Aug 4 03:51:38 2014 -0700 drm/i915: FBC flush nuke for BDW Testcase: igt/pm_rpm/cursor (and others) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: -
Paulo Zanoni authored
Because I plan to expand it a little bit. Signed-off-by:
-
- 19 Sep, 2014 32 commits
-
-
Daniel Vetter authored
I shouldn't ask everyone to do this and fail myself ... This extracts all the frontbuffer tracking functions into intel_frontbuffer.c, adds a DOC overview section and also adds the missing kerneldoc for i915_gem_track_fb and also pulls it into the same section for convenience. v2: Don't forget about the header files. v3: Oops, might check compilation next time around. To make my life easier drop the increase_pllclock from set_base_atomic since really, it doesn't matter if you see your Oops or kgdb with a tiny bit of lag. v4: Try to better explain how to actually use this, requested by Paulo on irc. v5: Explain invalidate/flush a bit clearer. v6: s/business/busyness/ Acked-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Chris Wilson authored
Rather than splitting and hiding away critical parts of sanitize_enable_ppgtt() into single use macros in the headers, inline them into the function for clarity. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Brad Volkin authored
The other paths in the command parser that reject a batch all log a message indicating the reason. We simply missed this one. Signed-off-by:
Brad Volkin <bradley.d.volkin@intel.com> Signed-off-by:
-
Brad Volkin authored
In commit commit 896ab1a5 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Aug 6 15:04:51 2014 +0200 drm/i915: Fix up checks for aliasing ppgtt it looks like we accidentally inverted the check that the command parser should only run when the driver enables some form of PPGTT. Testcase: igt/gem_exec_parse Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
Signed-off-by: -
Deepak S authored
Based on the HW team inputs. We can should not wait for the old ack, Waiting for old ack might fail, when other forcewake came before the present one is desserted. for example, if forcewake bit 0 was set and before it could get cleared forcewake bit 1 got set, HW eventually clear bit 0, when the bit 1 is cleared. i.e, bit 1 is still sent then forcewake bit 0 will still be set. Signed-off-by:
Deepak S <deepak.s@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Add comment Ville requested.] Signed-off-by:
-
Rodrigo Vivi authored
If it wasn't never enabled by kernel parameter or platform default we can avoid reading registers so many times in vain Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
Avoid touching fbc register when fbc is disabled. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Daniel Vetter authored
The ->queue_flip callback is always called from process context, so plain _irq spinlock variants are enough. Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Daniel Vetter authored
Only one place looked in need of a bit of polish: hsw_restore_lcpll. It's used by the runtime pm code and hence is always called from process context. No irq flag saving required. Another thing I've stumbled over is that we might need to add a raw forcewake_get/put helpers which don't grab a runtime pm reference but just check that the device isn't suspended - we have this duplicated in the execlist code, too. Reviewed-by:
-
Daniel Vetter authored
Grab bag for all the special cases: - i9xx_check_fifo_underruns is only called from crtc_enable hooks, i.e. process context. - i915_enable_asle_pipestat is only called from interrupt postinstall hooks. So again process context. - gen8_irq_power_well_post_enable is called from the runtime pm code, which again means process context. - The open-coded hpd_irq_setup loop in _thaw is also running in process context. So for all of them the plain _irq variant is sufficient. Reviewed-by:
-
Daniel Vetter authored
irq handlers always run with interrupts locally disabled, so plain spinlocks is all we need. I've also reviewed again that they all follow the _irq_handler postfix convention. Reviewed-by:
-
Daniel Vetter authored
All the interrupt setup/teardown hooks are always run from plain process context. So again just the _irq variant is good enough. Reviewed-by:
-
Daniel Vetter authored
Work functions are in process context, so plain _irq spinlock variants is all we need. The hpd reenable work didn't follow the _work/_work_func postfix naming scheme, so adjust that while at it. Reviewed-by:
-
Daniel Vetter authored
->detect callbacks are only ever called from process context, and there's no fancy nesting going on here. So plain _irq spinlock variants is what we want. Reviewed-by:
-
Daniel Vetter authored
i915_capture_error_state can be called from all kinds of contexts, so needs the full irqsave dance. But the other two places to grab and release the error state are only called from process context. So simplify them to the plaine _irq spinlock versions to clarify the locking semantics. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com Reviewed-by:
-
Daniel Vetter authored
Now we tackle the functions also called from interrupt handlers. - intel_check_page_flip is exclusively called from irq handlers, so a plain spin_lock is all we need. In i915_irq.c we have the convention to give all such functions an _irq_handler postfix, but that would look strange and als be a bit a misleading name. I've opted for a WARN_ON(!in_irq()) instead. - The other two places left are called both from interrupt handlers and from our reset work, so need the full irqsave dance. Annotate them with a short comment. Reviewed-by:
-
Daniel Vetter authored
It's good practice to use the more specific versions for irq save spinlocks both as executable documentation and to enforce saner design. The _irqsave version really should only be used if the calling context is unknown and there's a good reason to call a function from all kinds of places. This is the first step whice replaces all occurances of _irqsave in process context with the simpler irq disable/enable variants. We don't have any funky spinlock nesting going on, especially since the event_lock is the outermost of the irq/vblank related spinlocks. Reviewed-by:
-
Ville Syrjälä authored
We changed to an interrupt based vblank wait (as opposed to polling) in: commit 44bd93a3d367913d883be6abba9a6e51a53c4e90 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jul 25 23:36:44 2014 +0200 drm/i915: Use generic vblank wait However we already had vblank waits on the wrong side of drm_vblank_{on,off}() calls due to various workarounds, so now we get a warning more or less every time we do a modeset, and we fail to wait for the vblank like we should. Move the drm_vblank_{on,off}() calls back out from intel_crtc_{enable,disable}_planes() so that all of these vblank waits return to proper operation. Also move the cxsr wait a bit earlier so that we can keep the encoder disable after we've turned off vblanks. Moving stuff out from the plane enable/disable functions seems preferrable to moving the workaround stuff in since the workarounds are required only on specific platforms. While at it switch over to the drm_crtc_ variants of the vblank on/off functions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82525 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82490 Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: -
Daniel Vetter authored
Requested by Chris, and also requested to keep it since it's a more accurate name in his opinion. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniel Vetter authored
This has the upside that it will no longer steal interrupts from the interrupt handler on pre-g4x. Furthermore this will now scream properly on all platforms if we don't have hw counters enabled. v2: Adjust to the new names. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Daniel Vetter authored
Originally the irq safe spinlock was required because of asle interrupts. But since commit 91a60f20 Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Oct 31 18:55:48 2013 +0200 drm/i915: move opregion asle request handling to a work queue there's no need for this any more. So switch to the simpler mutex. v2: Cite the right commit, spotted by Jani. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Jani Nikula authored
This does not seem to make a difference for the structs in question, but document the intent. v2: also pack union child_device_config (Daniel) Signed-off-by:
-
Daniel Vetter authored
Yet another place that wasn't properly transformed when implementing SOix. While at it convert the checks to WARN_ON on gen5+ (since we don't have UMS potentially doing stupid things on those platforms). And also add the corresponding checks to the put functions (again with a WARN_ON) for gen5+. v2: Drop the WARNINGS in the irq_put functions (including the existing one for vebox), Chris convinced me that they're not that terribly useful. v3: Don't forget about execlist code. Cc: Imre Deak <imre.deak@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: "Volkin, Bradley D" <bradley.d.volkin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Imre Deak authored
We want to enable/disable display IRQs only if global i915 IRQs are enabled. To check the latter it's not enough to consult the DRM dev->irq_enabled flag, since runtime PM can disable/enable IRQs and it won't adjust this flag only the i915 specific dev_priv->pm._irqs_disabled flag. Fix this by using the proper intel_irqs_enabled() helper instead. Fortunately this didn't cause an actual problem since even if we enabled display IRQs too early (before enabling global i915 IRQs) the VLV_MASTER_IER would still be clear masking all IRQs. This issue was caught by commit 920dd15a2b2fc60d054646a8a1ffd6aeb6090e05 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Aug 27 10:43:37 2014 +0200 drm/i915: WARN if interrupts aren't on in en/disable_pipestat Signed-off-by:Imre Deak <imre.deak@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Ville Syrjälä authored
It seems cleaner if we keep CURCNTR at 0 when the cursor is disabled, so don't set the CURSOR_PIPE_CSC_ENABLE bit unless the cursor is enabled. Signed-off-by:
-
Ville Syrjälä authored
To make the code a bit more undestandable move the intel_crtc->cursor_base assignment into the low level update cursor routines. That's were we compare the current value with the new one so immediately seeing that it gets assigned only afterwards helps one to understand that it gets assigned only after the comparison. Signed-off-by:
-
Daniel Vetter authored
If a page isn't allocated as __GFP_MOVEABLE it won't move around, so no need to grab a reference to lock it into place. Discovered while reviewing page allocation handling in i915 gem. Acked-by:
-
Daniel Vetter authored
While discussing/reviewing __GFP_MOVEABLE behaviour and interactions with our various page allocations on irc Chris brought up that the scratch page isn't allocated as moveable, but we still grab/put a reference to lock it in place. Which is unecessary. So drop that. Acked-by:
-
Gustavo Padovan authored
7e4bf45dbd99a965c7b5d5944c6dc4246f171eb5 introduced the regression. We fix it by doing the right assignment of crtc_y Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83747Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by:
-
Chris Wilson authored
The data structure it was supposed to be sanity checking has long gone. Signed-off-by:
-
Gustavo Padovan authored
Factor out a piece of code from intel_pipe_set_base() that updates the pipe size and adjust fitter. This will help refactor the update primary plane path. v2: use struct intel_crtc as argument to intel_update_pipe_size() v3: use 'crtc' as argument name Signed-off-by:
-
