summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_runtime_pm.c
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915/bxt: Fix PPS lost state after suspend breaking eDP link trainingImre Deak2016-06-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | The PPS registers are backed by power well #0 and as such may be reset after system or runtime suspend (both implying a possible DC9 transition). Fix this by reusing the VLV/CHV PPS pipe-reassignment logic. The difference on BXT is that the PPS instances are not pipe but port (or more accurately pin) specific, so we only need to care about the lost HW state. As opposed to VLV/CHV the SW state is fixed and initialized during connector init. This also paves the way towards using the actual port->PPS instance mapping based on VBT. This fixes eDP link training errors on BXT after suspend, where we started the link training too early due to an incorrect T3 (panel power on) register value. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96436 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/1466084243-5388-2-git-send-email-imre.deak@intel.com
* drm/i915/bxt: Rename broxton to bxt in PHY/CDCLK function prefixesImre Deak2016-06-131-2/+2
| | | | | | | | | | Rename these remaining function prefixes to better align with the corresponding SKL functions. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
* drm/i915/bxt: Move DDI PHY enabling/disabling to the power well codeImre Deak2016-06-131-7/+99
| | | | | | | | | | | | | | | | | | | | | So far we depended on the HW to dynamically power down unused PHYs and so we enabled them manually once during driver loading/resuming. There are indications however that we can achieve better power savings by manual powering toggling. So make the PHY enabling/disabling to happen on-demand whenever we need either the corresponding AUX or port functionality. CHV does this already by enabling the PHY along the corresponding PHY common lane power wells there, do the same on BXT by adding virtual power wells for the same purpose. Also sanity check the common lane power down ack signal from the PHY. Do this only when the PHY is enabled, since it's not clear at what point the HW power/clock gates things. While at it rename broxton_ prefix to bxt_ in related function names to better align with the SKL code. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
* drm/i915: Factor out intel_power_well_get/putImre Deak2016-06-131-12/+21
| | | | | | | | | | | | | These helpers will be needed by the next patch, so factor them out. No functional change. v2: - Move the refcount==0 WARN to the new put helper. (Ville) CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
* drm/i915: Fix a buch of kerneldoc warningsTvrtko Ursulin2016-06-061-0/+1
| | | | | | | | | | | | | Just a bunch of stale kerneldocs generating warnings when building the docs. Mostly function parameters so not very useful but still. v2: Tidy. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464958937-23344-1-git-send-email-tvrtko.ursulin@linux.intel.com
* drm/i915: Assert the dbuf is enabled when disabling DC5/6Ville Syrjälä2016-05-231-0/+11
| | | | | | | | | | | | | | Like with cdclk, the DMC is supposed to manage dbuf enabling/disabling. Let's make sure it has correctly restored the dbuf state to enabled when we disable the DC states. v2: s/skl/gen9/ in function name (Imre) Cc: Imre Deak <imre.deak@intel.com> Suggested-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463407180-28993-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Replace bxt_verify_cdclk_state() with a more generic cdclk checkVille Syrjälä2016-05-231-4/+4
| | | | | | | | | | | | | Rather than having a BXT specific function to make sure the DE PLL is enabled after disabling DC6, let's just make sure the current cdclk is the same as what we last programmed. Having another check in bxt_display_core_init() almost immediately after the cdclk init seems redundant, so let's just kill that one. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-21-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Move SKL+ DBUF enable/disable to display core init/uninitVille Syrjälä2016-05-231-0/+32
| | | | | | | | | | | | | | | | | | | | SKL and BXT have the same snippets of code for enabling disabling the DBUF. Extract those into helpers and move the calls from init/unit_cdclk() to the display core init/init since this stuff isn't really about cdclk. Also doing the enable twice shouldn't hurt since you're just setting the request bit again when it was already set. We can also toss in a few WARNs about the register values into skl_get_dpll0_vco() now that we know that things should always be sane there. Flatten skl_init_cdclk() while at it. v2: s/skl/gen9/ in function names (Imre) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-12-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Unify SKL cdclk init pathsVille Syrjälä2016-05-231-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | Currently we initialize cdclk on SKL from two different places, depending on whether it's during driver init or resume. Let's unify it to happen from the same place always, and that place will be the display core init function. To do this we first run through the cdclk sanitation code, which will first verify that the PLL is programmed correctly, after which we can read out the current cdclk frequency, and once the cdclk is known we verify that the cdclk "decimal" frequency is programmed correctly. If any of these fail we will force a cdclk change, and to be safe we also force the PLL to be turned off and on again. If the sanitation step didn't notice anything amiss, we'll skip the cdclk programming which will prevent cdclk reprogramming when the displays might be active. We can also toss in a few WARNs about the register values into skl_update_dpll0() since we now know that the PLL state should always be sane when that function is called. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-11-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Update RAWCLK_FREQ register on VLV/CHVVille Syrjälä2016-04-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | I just noticed that VLV/CHV have a RAWCLK_FREQ register just like PCH platforms. It lives in the display power well, so we should update it when enabling the power well. Interestingly the BIOS seems to leave it at the reset value (125) which doesn't match the rawclk frequency on VLV/CHV (200 MHz). As always with these register, the spec is extremely vague what the register does. All it says is: "This is used to generate a divided down clock for miscellaneous timers in display." Based on a quick test, at least AUX and PWM appear to be unaffected by this. But since the register is there, let's configure it in accordance with the spec. Note that we have to move intel_update_rawclk() to occur before we touch the power wells, so that the dev_priv->rawclk_freq is already populated when the disp2 enable hook gets called for the first time. I think this should be safe to do on other platforms as well. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461768202-17544-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
* drm/i915/bxt: Enable DC5 during runtime resumeImre Deak2016-04-221-1/+1
| | | | | | | | | | Right after runtime resume we know that we can re-enable DC5, since we just disabled DC9 and power well 2 is disabled. So enable DC5 explicitly instead of delaying this until the next time we disable power well 2. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461173277-16090-5-git-send-email-imre.deak@intel.com
* drm/i915/bxt: Sanitize DC state tracking during system resumeImre Deak2016-04-221-3/+22
| | | | | | | | | | | | | | | After suspend-to-ram or -disk we don't know what power state the display HW will be, DC0 or DC9 are both possible states, so reset the software DC state tracking in these cases. This gets rid of 'DC state mismatch' error messages during resuming from ram or disk where we expected to be in DC9 (as set by the suspend handler) but we are in DC0. v2: - Remove extra WS in gen9_sanitize_dc_state() (Bob) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461173277-16090-4-git-send-email-imre.deak@intel.com
* drm/i915/kbl: Don't WARN for expected secondary MISC IO power well requestImre Deak2016-04-211-1/+2
| | | | | | | | | | | | | In commit 5f304c873634 ("drm/i915/kbl: Reset secondary power well requests left on by DMC/KVMR") I forgot about the fact that SKL==KBL most of the time and that a secondary MISC IO power well request left on by the DMC is "expected". Tune down the corresponding WARN to be a debug message. This was caught by CI suspend tests. 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/1461060036-19043-1-git-send-email-imre.deak@intel.com
* drm/i915: Define HSW/BDW display power domains the right way upVille Syrjälä2016-04-191-19/+26
| | | | | | | | | | | | | | | | | | | Currently we're trying to define HSW/BDW power wells by what's not included. Let's do it the other way around, so that you can actually tell when the power well would get enabled. This will also allow us to add new power domains without accidentally adding it to the HSW/BDW display power domains. The current set of domains looks rather buggy even: - POWER_DOMAIN_MODESET is included in the display power well needlessly - DDI-B to DDI-E were not part of the display power well when they should be So let's fix that up while at it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460977348-32260-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Define VLV/CHV display power well domains properlyVille Syrjälä2016-04-191-2/+40
| | | | | | | | | | | Currently we're using POWER_DOMAIN_MASK as the power domains for the display power well on VLV/CHV. That includes all power domains even though the disp2d/pipe-a power well is not needed for a lot of things. Let's reduce these to what we actually need. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460977348-32260-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Set .domains=POWER_DOMAIN_MASK for the always-on wellVille Syrjälä2016-04-191-16/+6
| | | | | | | | | | The always-on well is the same as runtime PM, so we should just "enable" it for any power domain. Throw out the usless FOO_ALWAYS_ON_DOMAINS defines and just use POWER_DOMAIN_MASK. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460977348-32260-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915/gen9: Fix runtime PM refcounting in case DMC firmware isn't loadedImre Deak2016-04-191-0/+3
| | | | | | | | | | | | | | | | | | | While we disable runtime PM and with that display power well support if the DMC firmware isn't loaded, we still want to disable power wells during system suspend and driver unload. So drop/reacquire the corresponding power refcount during suspend/resume and driver unloading. This also means we have to check if DMC is not loaded and skip enabling DC states in the power well code. v2: - Reuse intel_csr_ucode_suspend() in intel_csr_ucode_fini() instead of opencoding the former. (Chris) - Add docbook comment to the public resume and suspend functions. CC: Chris Wilson <chris@chris-wilson.co.uk> 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/1460980101-14713-1-git-send-email-imre.deak@intel.com
* drm/i915/kbl: Reset secondary power well requests left on by DMC/KVMRImre Deak2016-04-181-1/+1
| | | | | | | | | | | | | | 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
* Revert "drm/i915/bxt: Disable power well support"Imre Deak2016-04-151-5/+0
| | | | | | | | | | | | 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
* drm/i915/bxt: Add HW state verification for DDI PHY and CDCLKImre Deak2016-04-151-0/+8
| | | | | | | | | | | | | | | | | | 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
* drm/i915/bxt: Don't toggle power well 1 on-demandImre Deak2016-04-151-14/+61
| | | | | | | | | | | | | | | 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
* drm/i915/skl: Unexport skl_pw1_misc_io_initImre Deak2016-04-151-31/+18
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* drm/i915/gen9: Fix DMC/DC state assertsImre Deak2016-04-151-21/+11
| | | | | | | | | | | | | | | | | | 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
* drm/i915/gen9: Make power well disabling synchronousImre Deak2016-04-151-4/+5
| | | | | | | | | | | | | 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
* drm/i915/gen9: Reset secondary power well requests left on by DMC/KVMRImre Deak2016-04-151-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* drm/i915: Move vlv_init_display_clock_gating() to the display power wellVille Syrjälä2016-04-121-0/+13
| | | | | | | | | | | | | | | | | | | | The registers frobbed by vlv_init_display_clock_gating() libve inside the disp2d power well, so frobbing them while the power well is down results in unclaimed register access warning (and of course the values won't stick). Let's do this setup after we know the power well is enabled. It's also worth noting that DSPCLK_GATE_D and CBR1_VLV lose their state when the power well goes down, but fortunately the values we've been writing are actually the reset defaults. MI_ARB_VLV actually retains its value even if the power well was turned off, we just can't access it while the power well is down. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94164 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-9-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Do not use {HAS_*, IS_*, INTEL_INFO}(dev_priv->dev)Joonas Lahtinen2016-04-071-6/+6
| | | | | | | | | | | | | | | | | | | | | dev_priv is what the macro works hard to extract, pass it directly. > sed 's/\([A-Z].*(dev_priv\)->dev)/\1)/g' v2: - Include all wrapper macros too (Chris) v3: - Include sed cmdline (Chris) v4: - Break long line - Rebase Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460016485-8089-1-git-send-email-joonas.lahtinen@linux.intel.com
* drm/i915/bxt: add dsi transcodersJani Nikula2016-03-211-0/+6
| | | | | | | | | | | | | | | | | | | | | | The BXT display connections have DSI transcoders A and C that can be muxed to any pipe, not unlike the eDP transcoder. Add the notion of DSI transcoders. The "normal" transcoders A, B and C are not used with BXT DSI, so care must be taken to avoid accessing those registers with DSI transcoders in the hardware state readout, modeset, and generally everywhere. v2: addressing comments by Ville: - rename the dsi get config function to hsw_get_dsi_transcoder_state - rebase onto the higher level split of pipe/transcoder functions - use more has_dsi_encoder as we can now because of the above, with no need to look at the transcoder so much - rename IS_DSI_TRANSCODER to transcoder_is_dsi - use the above a bit more instead of comparing to < TRANSCODER_EDP 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/299740536b7941e31b2744f3ce34f7afe936a771.1458313400.git.jani.nikula@intel.com
* drm/i915/bxt: add missing DSI power domain to power well 1Jani Nikula2016-03-091-0/+1
| | | | | | | | | | | | | | | | | The DSI power domain was missing from BXT power well 1 definitions, failing to get the power well for DSI transcoders. As pipe A is in the same power well as DSI transcoders, the problem should only occur with pipes B and C. According to Ville, this is basically a nop since pw1 is under dmc control. But given that we still have this stuff defined here, it's clearly correct to include DSI here. Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Deepak M <m.deepak@intel.com> 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/1457463656-29357-1-git-send-email-jani.nikula@intel.com
* drm/i915/gen9: Fix DMC firmware initializationImre Deak2016-03-071-20/+2
| | | | | | | | | | | | | | | | | | | | | | In commit 1e657ad7 we moved the last step of firmware initialization to skl_display_core_init(), where it will be run only during system resume, but not during driver loading. Since this init step needs to be done whenever we program the firmware fix this by moving the initialization to the end of intel_csr_load_program(). While at it simplify a bit csr_load_work_fn(). This issue prevented DC5/6 transitions, this change will re-enable those. v2: - remove debugging left-over and redundant comment in csr_load_work_fn() Fixes: 1e657ad7a48f ("drm/i915/gen9: Write dc state debugmask bits only once") CC: Mika Kuoppala <mika.kuoppala@intel.com> CC: Patrik Jakobsson <patrik.jakobsson@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/1457121461-16729-1-git-send-email-imre.deak@intel.com
* drm/i915/gen9: Remove state asserts when disabling DC statesImre Deak2016-03-011-40/+1
| | | | | | | | | | | | Disabling the DC states when it's already disabled is a valid scenario, for example during HW state sanitization during driver loading and resuming or when DC states are disabled via the i915.enable_dc or disable_power_well option. 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/1456778945-5411-4-git-send-email-imre.deak@intel.com
* drm/i915/gen9: Disable DC states if power well support is disabledImre Deak2016-03-011-0/+3
| | | | | | | | | | | | If power well support is disabled via the i915.disable_power_well module option we should never enable DC states. Currently we would enable DC states even in this case during system suspend, where we need to disable all power wells regardless of the disable_power_well option. 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/1456778945-5411-3-git-send-email-imre.deak@intel.com
* drm/i915/gen9: Sanitize handling of allowed DC statesImre Deak2016-03-011-21/+57
| | | | | | | | | | | | | | | | We can simplify the conditions selecting the target DC state during runtime by calculating the allowed DC states in advance during driver loading. This also makes it easier to disable DC states depending on the i915.disable_power_well module option, added in the next patch. v2: - Print a debug message if the requested max DC value was adjusted due to a platform limit. Also debug print the calculated mask value. (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/1456778945-5411-2-git-send-email-imre.deak@intel.com
* drm/i915/skl: Fix power domain suspend sequenceImre Deak2016-03-011-3/+3
| | | | | | | | | | | | | During system suspend we need to first disable power wells then unitialize the display core. In case power well support is disabled we did this in the wrong order, so fix this up. Fixes: d314cd43 ("drm/i915: fix handling of the disable_power_well module option") CC: stable@vger.kernel.org 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/1456778945-5411-1-git-send-email-imre.deak@intel.com
* drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM)Chris Wilson2016-02-261-14/+12
| | | | | | | | | | | | | | | | | | | | commit 09731280028ce03e6a27e1998137f1775a2839f3 Author: Imre Deak <imre.deak@intel.com> Date: Wed Feb 17 14:17:42 2016 +0200 drm/i915: Add helper to get a display power ref if it was already enabled left the rpm wakelock assertions unbalanced if CONFIG_PM was disabled as intel_runtime_pm_get_if_in_use() would return true without incrementing the local bookkeeping required for the assertions. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> CC: Mika Kuoppala <mika.kuoppala@intel.com> CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456434628-22574-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Make sure pipe interrupts are processed before turning off power ↵Ville Syrjälä2016-02-221-0/+19
| | | | | | | | | | | | | | | | well on BDW+ Starting from BDW the DE_PIPE interrupts for pipe B and C belong to the relevant display power well. So we should make sure we've finished processing them before turning off the power well. The pipe interrupts shouldn't really happen at this point anymore since we've already shut down the planes/pipes/whatnot, but being a bit paranoid shouldn't hurt. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455907651-16397-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915: synchronize_irq() before turning off disp2d power well on VLV/CHVVille Syrjälä2016-02-221-0/+3
| | | | | | | | | | | | | | | | | | After we've told the irq code we don't want to handle display irqs anymore, we must make sure any display irq handling already kicked off has finished before we actually turn off the power well. I wouldn't expect PIPESTAT based interrupts to occur anymore since vblanks/page flips/gmbus/etc should all be quiescent at this point. But at least hotplug interrupts could still occur. Hotplug interrupts may also kick off the workqueue based hotplug processing, but that code should take the required power domain references itself, so there shouldn't be any need to synchronize with the hotplug processing from the power well code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455900112-15387-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915/gen9: Write dc state debugmask bits only onceMika Kuoppala2016-02-221-5/+2
| | | | | | | | | | | | DMC debugmask bits should stick so no need to write them everytime dc state is changed. v2: Write after firmware has been successfully loaded (Ville) Signed-off-by: Mika Kuoppala <mika.kuoppala@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/1455808874-22089-5-git-send-email-mika.kuoppala@intel.com
* drm/i915/gen9: Extend dmc debug mask to include coresMika Kuoppala2016-02-221-6/+10
| | | | | | | | | | | | | | Cores need to be included into the debug mask. We don't exactly know what it does but the spec says it must be enabled. So obey. v2: Cores should be only set for BXT (Imre, Art) Cc: Imre Deak <imre.deak@intel.com> Cc: Runyan, Arthur J <arthur.j.runyan@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@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/1455877564-5128-1-git-send-email-mika.kuoppala@intel.com
* drm/i915/gen9: Verify and enforce dc6 state writesMika Kuoppala2016-02-221-2/+39
| | | | | | | | | | | | | | | | | | | | | | | It has been observed that sometimes disabling the dc6 fails and dc6 state pops back up, brief moment after disabling. This has to be dmc save/restore timing issue or other bug in the way dc states are handled. Try to work around this issue as we don't have firmware fix yet available. Verify that the value we wrote for the dmc sticks, and also enforce it by rewriting it, if it didn't. v2: Zero rereads on rewrite for extra paranoia (Imre) Testcase: kms_flip/basic-flip-vs-dpms References: https://bugs.freedesktop.org/show_bug.cgi?id=93768 Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@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/1455811089-27884-1-git-send-email-mika.kuoppala@intel.com
* drm/i915/gen9: Check for DC state mismatchPatrik Jakobsson2016-02-221-0/+8
| | | | | | | | | | | The DMC can incorrectly run off and allow DC states on it's own. We don't know the root-cause for this yet but this patch makes it more visible. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455808874-22089-2-git-send-email-mika.kuoppala@intel.com
* drm/i915: Add helper to get a display power ref if it was already enabledImre Deak2016-02-171-9/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | We have many places in the code where we check if a given display power domain is enabled and if so access registers backed by this power domain. We assumed that some modeset lock will prevent the power reference from vanishing in the middle of the HW access, but this assumption doesn't always hold. In such cases we get either the wakeref not held, or an unclaimed register access error message. To fix this in a future-proof way that's independent of other locks wrap any such access with a get_ref_if_enabled()/put_ref() pair. Kudos to Ville and Joonas for the ideas of this new interface. v2: - init the power_domains ptr when declaring it everywhere (Joonas) v3: - don't report the device to be powered if runtime PM is disabled CC: Mika Kuoppala <mika.kuoppala@intel.com> CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455711462-7442-1-git-send-email-imre.deak@intel.com
* drm/i915: Kill intel_prepare_ddi()Ville Syrjälä2016-01-121-12/+0
| | | | | | | | | | | | | Move the ddi buffer translation programming to occur from the encoder .pre_enable() hook, for just the ddi port we are enabling. Previously we used to reprogram the translations for all ddi ports during init and during power well enabling. v2: s/intel_prepare_ddi_buffers/intel_prepare_ddi_buffer/ (Daniel) Resolve conflicts due to dev_priv->atomic_cdclk_freq Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/kbl: Adding missing IS_KABYLAKE checks.Rodrigo Vivi2016-01-081-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When adding IS_KABYLAKE definition I didn't included the DC states related because I was planing to include them with the patch that fixes DMC firmware loading, but I forgot them. Meanwhile this runtime pm code changed a lot for Skylake. Well, I didn't expect that this would crash the machine and I just noticed now that Sarah warned me our driver wasn't working. Thanks Sarah. Michel had found the main error first and his fix had better details on the history and got merged already: commit 16fbc291cb87c7defcd13ad715d3e4af0d523e43 Author: Michel Thierry <michel.thierry@intel.com> Date: Wed Jan 6 12:08:36 2016 +0000 drm/i915/kbl: Enable PW1 and Misc I/O power wells This one is a follow-up adding the other remaining missing pieces. v2: Rebased on top of Michel's patch as explained above. Cc: Sarah Sharp <sarah.a.sharp@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452214179-22361-1-git-send-email-rodrigo.vivi@intel.com
* drm/i915/kbl: Enable PW1 and Misc I/O power wellsMichel Thierry2016-01-071-2/+2
| | | | | | | | | | | | | | | | | | | | My kbl stopped working because of this. Fixes regression from commit 2f693e28b8df69f67beced5e18bb2b91c2bfcec2 Author: Damien Lespiau <damien.lespiau@intel.com> Date: Wed Nov 4 19:24:12 2015 +0200 drm/i915: Make turning on/off PW1 and Misc I/O part of the init/fini sequences Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452082116-16770-1-git-send-email-michel.thierry@intel.com Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: don't enable autosuspend on platforms without RPM supportImre Deak2015-12-181-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | pm_runtime_{use,dont_use}_autosuspend() controls whether the device's sysfs power/autosuspend_delay_ms file is writeable or returns -EIO on access to user space. Since commit 25b181b46e4340f69793a886f2cd46608487783b Author: Imre Deak <imre.deak@intel.com> Date: Thu Dec 17 13:44:56 2015 +0200 drm/i915: get a permanent RPM reference on platforms w/o RPM support this sysfs file is writeable also on platforms without RPM support, but userspace (at least IGT) depends on this file being unchangable to determine whether the device supports runtime PM at all. So restore the old behavior. This gets rid of igt/pm_rpm failures on old platforms without RPM support, where the test should be skipped. Testcase: igt/pm_rpm/basic-rte Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450371873-878-1-git-send-email-imre.deak@intel.com
* drm/i915: add support for checking RPM atomic sectionsImre Deak2015-12-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | In some cases we want to check whether we hold an RPM wakelock reference for the whole duration of a sequence. To achieve this add a new RPM atomic sequence counter that we increment any time the wakelock refcount drops to zero. Check whether the sequence number stays the same during the atomic section and that we hold the wakelock at the beginning of the section. Motivated by Chris. v2-v3: - unchanged v4: - swap the order of atomic_read() and assert_rpm_wakelock_held() in assert_rpm_atomic_begin() to avoid race Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-10-git-send-email-imre.deak@intel.com
* drm/i915: check that we hold an RPM wakelock ref before we put itImre Deak2015-12-171-0/+1
| | | | | | | | | | | | | | | | | With this change we have the corresponding wake lock checks in both the rpm get and put functions. v2-v3: - unchanged v4: - keep the corresponding check in the get helper (Chris) v5: - add a note to the commit message that with this change we have the checks both in the rpm get and put functions (Joonas) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-9-git-send-email-imre.deak@intel.com
* drm/i915: add support for checking if we hold an RPM referenceImre Deak2015-12-171-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Atm, we assert that the device is not suspended until the point when the device is truly put to a suspended state. This is fine, but we can catch more problems if we check that RPM refcount is non-zero. After that one drops to zero we shouldn't access the device any more, even if the actual device suspend may be delayed. Change assert_rpm_wakelock_held() accordingly to check for a non-zero RPM refcount in addition to the current device-not-suspended check. For the new asserts to work we need to annotate every place explicitly in the code where we expect that the device is powered. The places where we only assume this, but may not hold an RPM reference: - driver load We assume the device to be powered until we enable RPM. Make this explicit by taking an RPM reference around the load function. - system and runtime sudpend/resume handlers These handlers are called when the RPM reference becomes 0 and know the exact point after which the device can get powered off. Disable the RPM-reference-held check for their duration. - the IRQ, hangcheck and RPS work handlers These handlers are flushed in the system/runtime suspend handler before the device is powered off, so it's guaranteed that they won't run while the device is powered off even though they don't hold any RPM reference. Disable the RPM-reference-held check for their duration. In all these cases we still check that the device is not suspended. These explicit annotations also have the positive side effect of documenting our assumptions better. This caught additional WARNs from the atomic modeset path, those should be fixed separately. v2: - remove the redundant HAS_RUNTIME_PM check (moved to patch 1) (Ville) v3: - use a new dedicated RPM wakelock refcount to also catch cases where our own RPM get/put functions were not called (Chris) - assert also that the new RPM wakelock refcount is 0 in the RPM suspend handler (Chris) - change the assert error message to be more meaningful (Chris) - prevent false assert errors and check that the RPM wakelock is 0 in the RPM resume handler too - prevent false assert errors in the hangcheck work too - add a device not suspended assert check to the hangcheck work v4: - rename disable/enable_rpm_asserts to disable/enable_rpm_wakeref_asserts and wakelock_count to wakeref_count - disable the wakeref asserts in the IRQ handlers and RPS work too - update/clarify commit message v5: - mark places we plan to change to use proper RPM refcounting with separate DISABLE/ENABLE_RPM_WAKEREF_ASSERTS aliases (Chris) 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/1450227139-13471-1-git-send-email-imre.deak@intel.com
* drm/i915: use assert_rpm_wakelock_held instead of opencoding itImre Deak2015-12-171-6/+4
| | | | | | 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/1450203038-5150-7-git-send-email-imre.deak@intel.com
OpenPOWER on IntegriCloud