- 07 Nov, 2014 31 commits
-
-
Paulo Zanoni authored
With this patch, the RPS sequence for runtime suspend/resume is exactly like the sequence for S3 suspend/resume: - flush_delayed_work(&dev_priv->rps.delayed_resume_work) - intel_runtime_pm_disable_interrupts() - intel_suspend_gt_powersave() (suspended) - intel_runtime_pm_enable_interrupts() - intel_enable_gt_powersave() With this, we get rid of WARNs that are currently intermittently triggered by the system-suspend-execbuf subtest of runtime PM. Notice that these WARNs could also be triggered in other ways that involved doing lots of RPM suspend/resume cycles just after a system S3 resume. Testcase: igt/pm_rpm/system-suspend-execbuf Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Fix the message, not the fault :) This is what I see: [ 282.108597] [drm:i915_check_and_clear_faults] Unexpected fault [ 282.108597] Addr: 0x00000000\n Address space: PPGTT [ 282.108597] Source ID: 24 [ 282.108597] Type: 0 Signed-off-by:
-
Ville Syrjälä authored
There are two leftover GTIIR writes in valleyview_irq_preinstall(). Looks like the were originally left behind by: commit d18ea1b5 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jul 12 22:43:25 2013 +0200 drm/i915: unify PM interrupt preinstall sequence and then the GTIIR reset was added back here: commit f86f3fb0 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Tue Apr 1 15:37:14 2014 -0300 drm/i915: properly clear IIR at irq_uninstall on Gen5+ so we can kill the leftovers from the vlv code. Cc: Paulo Zanoni <przanoni@gmail.com> Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
The extra VLV_IIR writes at the end of vlv_display_irq_postinstall() serve no purpose. Remove them. The VLV_IMR/IER/IIR setup at the start of the function also seems a bit pointless since it doesn't unmask/enable anything. But leave it be for now. Signed-off-by:
-
Ville Syrjälä authored
Split the vlv display irq postinstall code to a separate function so that we can share it with chv. Signed-off-by:
-
Ville Syrjälä authored
Pull the vlv display irq reset code to a new functions. The aim is to share the code with chv. Signed-off-by:
-
Ville Syrjälä authored
Genralize valleyview_display_irqs_install() and valleyview_display_irqs_uninstall() enough so that they work on chv. The only difference to vlv here being the third pipe that chv brings. Signed-off-by:
-
Ville Syrjälä authored
Looks like we forgot to call gen5_gt_irq_reset() for vlv in the uninstall phase. Do so. Signed-off-by:
-
Ville Syrjälä authored
Replace the hand rolled IIR,IER,IMR disable sequences with GEN5_IRQ_RESET(). Signed-off-by:
-
Ville Syrjälä authored
Follow the same ordering rules for the IIR,IER,IMR writes on vlv/chv that we do on other gen5+ platforms. Signed-off-by:
-
Ville Syrjälä authored
Looks like a leftover POSTING_READ(GEN8_PCU_IIR) in cherryview_irq_preinstall() from some earlier age. GEN5_IRQ_RESET() already does the posting read so this changes nothing, so kill it. Signed-off-by:
-
Ville Syrjälä authored
Replace the hand rolled macros with gen8_gt_irq_reset() and GEN5_IRQ_RESET() in cherryview_irq_uninstall(). Signed-off-by:
-
Ville Syrjälä authored
Some has given a name for the DPINVGTT status bitmask, so let's use it instead of the magic number. Looks more like the chv code now. Signed-off-by:
-
Ville Syrjälä authored
When disabling interrupts we do the writes in this order: IMR,IER,IIR,IIR. But when enabling interrupts we don't do use the mirrored order, and instead do IIR,IIR,IMR,IER. I like consistency unless there's a good reason against it, which I can't think of here, so change the enable order to IIR,IIR,IER,IMR. Signed-off-by:
-
Tvrtko Ursulin authored
It will help future code if this function knows something about of the context of the display setup object is being pinned for. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Thomas Daniel authored
Write HWS_PGA address even in execlists mode as the global hardware status page is still required. This address was previously uninitialized and HWSP writes would clobber whatever buffer happened to reside at GGTT address 0. v2: Break out hardware status page setup into a separate function. Issue: VIZ-2020 Signed-off-by:
Thomas Daniel <thomas.daniel@intel.com> Signed-off-by:
-
Damien Lespiau authored
The function was removed in: commit 037bde19 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Mar 27 08:24:19 2014 +0000 Revert "drm/i915: Disable/Enable PM Intrrupts based on the current freq." Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Damien Lespiau authored
The function was removed in: commit 0e32b39c Author: Dave Airlie <airlied@redhat.com> Date: Fri May 2 14:02:48 2014 +1000 drm/i915: add DP 1.2 MST support (v0.7) Signed-off-by:
-
Daniel Vetter authored
On pre-ddi platforms we don't shut down the link when changing link training parameters. Except when clock recovery fails too hard and we restart with channel eq training. Which doesn't make a lot of sense really, since just stopping/restarting the DP port at this point violates the modeset sequence documented in the Bspec. So let's tempt fate and try this. This patch is motivated by a WARN_ON triggered by commit bc76e320 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue May 20 22:46:50 2014 +0200 drm/i915: Drop now misleading DDI comment from dp_link_down References: https://bugs.freedesktop.org/show_bug.cgi?id=85670Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Acked-by:
Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Damien Lespiau authored
Chris removed the code using it in: commit be2d599b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Sep 10 19:52:18 2014 +0100 drm/i915: Remove dead code, i915_gem_verify_gtt Signed-off-by:
-
Damien Lespiau authored
As Paulo said when introducing the enum, having more types is really good to document what should go where (int foo(int, int, bool, bool). Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Daniel Vetter authored
It's really part of the "push all new_* state into current state pointers" done in that function. So let's move it there to make this clear. Also, with the conversion done the num_shared_dpll check the function does in it's loop is enough, so we can drop the check for the dpll compute callback, too. Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: -
Ander Conselvan de Oliveira authored
Now that shared DPLLs configuration is staged, there's no need to track the current ones in the new pipe_config since those are released before making the new pipe_config effective. Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by:
-
Ander Conselvan de Oliveira authored
There's no users left after the conversion to calculate clocks before disabling crtcs during mode set. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Use the infrastructure added in a previous patch to choose shared DPLLs and calculate clocks before touching the hardware. v2: Don't set mode_set hooks since dev_priv is kzalloc()'d (Ville) Signed-off-by:
-
Ander Conselvan de Oliveira authored
Use the infrastructure added in a previous patch to choose shared DPLLs and calculate clocks before touching the hardware. v2: Don't set mode_set hooks since dev_priv is kzalloc()'d (Ville) Signed-off-by:
-
Ander Conselvan de Oliveira authored
Use the infrastructure added in a previous patch to choose shared DPLLs and calculate clocks before touching the hardware. v2: Don't set mode_set hooks since dev_priv is kzalloc()'d (Ville) Signed-off-by:
-
Ander Conselvan de Oliveira authored
It is possible for a mode set to fail if there aren't shared DPLLS that match the new configuration requirement or other errors in clock computation. If that step is executed after disabling crtcs, in the failure case the hardware configuration is changed and needs to be restored. Doing those things early will allow the mode set to fail before actually touching the hardware. Follow up patches will convert different platforms to use the new infrastructure. v2: Keep pll->new_config valid only during mode set (Ville) Use kmemdup() in i915_shared_dpll_start_config() (Ville) Restore old pll config if something fails before commit (Ville) Don't set compute_clock hooks since dev_priv is kzalloc()'d (Ville) Signed-off-by: -
Ander Conselvan de Oliveira authored
The new struct will be used in a follow up patch to allow a current and a staged config to exist for the same shared DPLL. v2: Rebase on by mask_to_refcount()->hweight32() change. (Damien) Signed-off-by:
-
Ander Conselvan de Oliveira authored
This will be used in a follow up patch to properly release shared DPLLs without relying on the shared_dpll field in pipe_config. v2: Fix white space error (Ville) Use hweight32() (Ville) Signed-off-by: -
Daniel Vetter authored
More concise. Noticed while reviewing Ander's patch which touched a lot of the pipe_has_type checks. v2: Use new_config in one place Ander spotted. Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
-
- 04 Nov, 2014 9 commits
-
-
Ander Conselvan de Oliveira authored
This shouldn't change the behavior of those functions, since they are called after the new_config is made effective and that points to the current config. In a follow up patch, the mode set sequence will be changed so this is called before disabling crtcs, and in that case those functions should work on the staged config. Signed-off-by:
-
Dave Gordon authored
execlists_submit_context() always returns 0, which is redundant. And its name is inaccurate, since it actually submits (up to) TWO contextS. So we rename it, change it to "void", and remove the WARN_ON() testing its return value. Change-Id: Ie225b0eca7754c6093c8b8bd15550b251b6feb82 Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
-
John Harrison authored
If a ring failed to initialise for any reason then the error path would try to clean up all rings including those that had not yet been allocated. The ring clean up code did a check that the ring was valid before starting its work. Unfortunately, that was after it had already dereferenced the ring to obtain a dev_private pointer. Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
-
Mika Kuoppala authored
When looking at the bug report logs with triggered WARN_ON, the person doing bug triaging will have to find exact kernel source and match file/line. Attach the condition that triggered the WARN_ON to kernel log. In most cases the context is self evident and this way we can save developer time. The drawback is ~16kbytes bigger i915.ko Signed-off-by:
Mika Kuoppala <miku@iki.fi> Signed-off-by:
-
Ville Syrjälä authored
When we suspend we turn everything off so the pps should be idle, and we also (or at least should) disable all power wells which will reset the power sequencer port assignment. So when we resume all power sequencers should be in their reset state. However it's at least theoretically possible that the BIOS would touch the power seuqencer(s), so to be safe we ought to read out the current port assignment like we do at driver init time. To do that we can simply call vlv_initial_power_sequencer_setup() from the encoder ->reset() hook before calling intel_edp_panel_vdd_sanitize(). There's no danger or clobbering the pps delays since we now have those stored within intel_dp and we don't change them once initialized. This will make sure that the vdd state gets correctly tracked post-resume in case the BIOS enabled it. We need to shuffle things around a bit to get the locking right, and while at it, make intel_edp_panel_vdd_sanitize() static and move it around a bit to avoid a forward declaration. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
The pps timestamp initialization was accidentally lost on vlv/chv in commit a4a5d2f8 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Sep 4 14:54:20 2014 +0300 drm/i915: Track which port is using which pipe's power sequencer Restore it so that we avoid introducing random delays into the pps operations during/after driver init time. Cc: Imre Deak <imre.deak@intel.com> Reported-by:
-
Jani Nikula authored
We'll never end up in the hooks with eld[0] unset, as that's checked by drm_select_eld(). Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Jani Nikula authored
Introduce functions to enable/disable the audio codec, incorporating the ELD setup within enable. The disable is initially limited to HSW, covering exactly what was done previously. The only functional difference is that ELD valid is no longer set if there is no connector with ELD, which should be the right thing to do anyway. Otherwise the sequence remains the same, with warts and all, in preparation for applying more sanity. v2: add kernel doc. Signed-off-by:
-
Jani Nikula authored
The audio programming sequence states that the ELD must be written and enabled after the pipe is ready. Indeed, this should clarify the situation with commit c7905792 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Apr 16 16:56:09 2014 +0200 drm/i915: Remove vblank wait from haswell_write_eld and Ville's review of it [1]. Moreover, we should not touch the relevant registers before we get the audio power domain. [1] http://mid.gmane.org/20140416155309.GK18465@intel.comSigned-off-by:
-
