kernel.git/drivers/gpu/drm/i915/intel_runtime_pm.c, branch linux-4.2.y

drm/i915: Throw out WIP CHV power well definitions

2015-05-28T09:13:50Z

Expecting CHV power wells to be just an extended versions of the VLV power wells, a bunch of commented out power wells were added in anticipation when Punit folks would implement it all. Turns out they never did, and instead CHV has fewer power wells than VLV. Rip out all the #if 0'ed junk that's not needed. v2: Rename the "pipe-a" well to "display" to match VLV Clarify the pipe A power well relationship to pipes B and C (Deepak) Reviewed-by: Deepak S Signed-off-by: Ville Syrjälä Signed-off-by: Daniel Vetter

drm/i915: Use the default 600ns LDO programming sequence delay

2015-05-28T09:13:50Z

Not sure which LDO programming sequence delay should be used for the CHV PHY, but the spec says that 600ns is "Used by default for initial bringup", and the BIOS seems to use that, so let's do the same. Reviewed-by: Deepak S Signed-off-by: Ville Syrjälä Signed-off-by: Daniel Vetter

drm/i915: Fix typo in intel_runtime_pm.c

2015-05-20T09:25:39Z

This patch fix spelling typo in intel_runtime_pm.c Signed-off-by: Masanari Iida Signed-off-by: Daniel Vetter

Revert "drm/i915: Hack to tie both common lanes together on chv"

2015-05-08T13:56:42Z

With recent hardware/firmware there don't appear to be any glitches on the other PHY when we toggle the cmnreset for the other PHY. So detangle the cmnlane power wells from one another and let them be controlled independently. This reverts commit 3dd7b97458e8aa2d8985b46622d226fa635071e7. Signed-off-by: Ville Syrjälä Reviewed-by: Deepak S Signed-off-by: Daniel Vetter

drm/i915: Work around DISPLAY_PHY_CONTROL register corruption on CHV

2015-05-08T13:56:30Z

Sometimes (exactly when is a bit unclear) DISPLAY_PHY_CONTROL appears to get corrupted. The values I've managed to read from it seem to have some pattern but vary quite a lot. The corruption doesn't seem to just happen when the register is accessed, but can also happen spontaneosly during modeset. When this happens during a modeset things go south and the display doesn't light up. I've managed to hit the problemn when toggling HDMI on port D on and off. When things get corrupted the display doesn't light up, but as soon as I manually write the correct value to the register the display comes up. First I was suspicious that we ourselves accidentally overwrite it with garbage, but didn't catch anything with the reg_rw tracepoint. Also I sprinkled check all over the modeset path to see exactly when the corruption happens, and eg. the read back value was fine just before intel_dp_set_m(), and corrupted immediately after it. I also made my check function repair the register value whenever it was wrong, and with this approach the corruption repeated several times during the modeset operation, always seeming to trigger in the same exact calls to the check function, while other calls to the function never caught anything. So far I've not seen this problem occurring when carefully avoiding all read accesses to DISPLAY_PHY_CONTROL. Not sure if that's just pure luck or an actual workaround, but we can hope it works. So let's avoid reading the register and instead track the desired value of the register in dev_priv. v2: Read out the power well state to determine initial register value v3: Use DPIO_CHx names instead of raw numbers Signed-off-by: Ville Syrjälä Reviewed-by: Deepak S Signed-off-by: Daniel Vetter

drm/i915/skl: Make the Misc I/O power well part of the PLLS domain

2015-05-08T11:03:35Z

The specs tell us to ungate PG1 and Misc I/O at display init. We'll use the PLLS power domain to ensure those two power wells are up. Signed-off-by: Damien Lespiau Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter

drm/i915/skl: Add the INIT power domain to the MISC I/O power well

2015-05-08T11:03:31Z

Signed-off-by: Damien Lespiau Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter

drm/i915/skl: Assert the requirements to enter or exit DC6.

2015-05-08T11:03:16Z

Warn if the conditions to enter or exit DC6 are not satisfied such as support for runtime PM, state of power well, CSR loading etc. v2: Removed camelcase in functions and variables. v3: Do some minimal check to assert if CSR program is not loaded. v4: 1] Correct the check for backlight-disabling in assert_can_enable_dc6(). 2] Check csr.loaded = false before disabling DC6 and simplify other checks. v5: 1] Remove checks for DC5 state from assert_can_enable_dc6 function as DC5 is no longer enabled before enabling DC6. 2] Correct the check for CSR-loading in assert_can_disable_dc6 function as CSR must be loaded for context restore to happen on DC6 disabling. v6: 1] It's okay to explicitly disable DC6 during driver-load/resume even though it might already be disabled and so don't warn about it. v7: Rebase to latest. v8: Sqashed the patch from Imre - [PATCH] drm/i915/skl: avoid false CSR fw not loaded WARN during driver load/resume v9: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh) v10: During initialization added a early return before disabling DC5. (Animesh) Issue: VIZ-2819 Signed-off-by: A.Sunil Kamath Signed-off-by: Suketu Shah Signed-off-by: Damien Lespiau Signed-off-by: Animesh Manna Reviewed-by: Imre Deak Signed-off-by: Daniel Vetter

Implement enable/disable for Display C6 state

2015-05-08T11:03:15Z

This patch just implements the basic enable and disable functions of DC6 state which is needed for SKL platform. Its important to load SKL CSR program before calling enable. DC6 is a deeper power saving state where hardware dynamically disables power well 0 and saves the associated registers. DC6 can be entered when software allows it, the conditions for DC5 are met, and the PCU allows DC6. DC6 cannot be used if the backlight is being driven from the display utility pin. Its better to configure display engine to have power well 2 disabled before getting into DC6 enable function. Hence rpm framework will ensure to check status of power well 2 and DC5 before calling skl_enable_dc6. v2: Replace HAS_ with IS_ check as per Daniel's review comments v3: Cleared the bits dc5/dc6 enable of DC_STATE_EN register before setting them as per Satheesh's review comments. v4: No need to call gen9_disable_dc5 inside enable sequence of DC6, as its already take care above. v5: call POSTING_READ for every write to a register to ensure that its written immediately. Call intel_prepare_ddi during DC6 exit as it's required on low-power exit. v6: Protect DC6-enabling-disabling functionality with locks to synchronize with CSR-loading code. v7: Remove grabbing CSR-related mutex in skl_enable/disable_dc6 functions as deferred DC5-enabling functionality is now removed. v8: Remove 'Disabling DC5' from the debug comment during DC6 enabling as when DC6 is allowed, DC5 is not programmed at all. v9: - Rebase to latest. - Move all DC6-related functions from intel_display.c to intel_runtime_pm.c. v10: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh) Issue: VIZ-2819 Signed-off-by: A.Sunil Kamath Signed-off-by: Damien Lespiau Signed-off-by: Animesh Manna Reviewed-by: Imre Deak Signed-off-by: Daniel Vetter

drm/i915/skl: Add DC6 Trigger sequence.

2015-05-08T11:03:14Z

Add triggers for DC6 as per details provided in skl_enable_dc6 and skl_disable_dc6 implementations. Also Call POSTING_READ for every write to a register to ensure it is written to immediately v1: Remove POSTING_READ and intel_prepare_ddi calls as they've been added in previous patches. v2: 1] Remove check for backlight disabled as it should be the case by that time. 2] Mark DC5 as disabled when enabling DC6. 3] Return from DC5-disabling function early if DC5 is already be disabled which can happen due to DC6-enabling earlier. 3] Ensure CSR firmware is loaded after resume from DC6 as corresponding memory contents won't be retained after runtime-suspend. 4] Ensure that CSR isn't identified as loaded before CSR-loading program is called during runtime-resume. v3: Rebase to latest Modified as per review comments from Imre and after discussion with Art: 1] DC6 should be preferably enabled when PG2 is disabled by SW as the check for PG1 being disabled is taken of by HW to enter DC6, and disabled when PG2 is enabled respectively. This helps save more power, especially in the case when display is disabled but GT is enabled. Accordingly, replacing DC5 trigger sequence with DC6 for SKL. 2] DC6 could be enabled from intel_runtime_suspend() function, if DC5 is already enabled. 3] Move CSR-load-status setting code from intel_runtime_suspend function to a new function. v4: 1] Enable/disable DC6 only when toggling the power-well using a newly defined macro ENABLE_DC6. v5: 1] Load CSR on system resume too as firmware may be lost on system suspend preventing enabling DC5, DC6. 2] DDI buffers shouldn't be programmed during driver-load/resume as it's already done during modeset initialization then and also that the encoder list is still uninitialized by then. Therefore, call intel_prepare_ddi function right after disabling DC6 but outside skl_disable_dc6 function and not during driver-load/resume. v6: 1] Rebase to latest. 2] Move SKL_ENABLE_DC6 macro definition from intel_display.c to intel_runtime_pm.c. v7: 1) Refactored the code for removing the warning got from checkpatch. 2) After adding dmc ver 1.0 support rebased on top of nightly. (Animesh) v8: - Reverted the changes done in v7. - Removed the condition check in skl_prepare_resune(). (Animesh) Issue: VIZ-2819 Signed-off-by: A.Sunil Kamath Signed-off-by: Suketu Shah Signed-off-by: Damien Lespiau Signed-off-by: Animesh Manna Reviewed-by: Imre Deak Signed-off-by: Daniel Vetter