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

drm/i915: Enable display WA#1183 from its correct spot

2018-05-01T19:47:29Z

commit ac315c621f01d4b8a53dec317c7ae322fd26ff38 upstream. The DMC FW specific part of display WA#1183 is supposed to be enabled whenever enabling DC5 or DC6, so move it to the DC6 enable function from the DC6 disable function. I noticed this after Daniel's patch to remove the unused skl_disable_dc6() function. Fixes: 53421c2fe99c ("drm/i915: Apply Display WA #1183 on skl, kbl, and cfl") Cc: Lucas De Marchi Cc: Rodrigo Vivi Cc: Ville Syrjälä Cc: Daniel Vetter Cc: Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20180419155109.29451-1-imre.deak@intel.com (cherry picked from commit b49be6622f08187129561cff0409f7b06b33de57) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman

BackMerge tag 'v4.15-rc8' into drm-next

2018-01-17T23:32:15Z

Linux 4.15-rc8 Daniel requested this for so the intel CI won't fall over on drm-next so often.

drm/i915: Apply Display WA #1183 on skl, kbl, and cfl

2018-01-04T12:39:08Z

Display WA #1183 was recently added to workaround "Failures when enabling DPLL0 with eDP link rate 2.16 or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz (CDCLK_CTL CD Frequency Select 10b or 11b) used in this enabling or in previous enabling." This workaround was designed to minimize the impact only to save the bad case with that link rates. But HW engineers indicated that it should be safe to apply broadly, although they were expecting the DPLL0 link rate to be unchanged on runtime. We need to cover 2 cases: when we are in fact enabling DPLL0 and when we are just changing the frequency with small differences. This is based on previous patch by Rodrigo Vivi with suggestions from Ville Syrjälä. Cc: Arthur J Runyan Cc: Ville Syrjälä Cc: Rodrigo Vivi Cc: stable@vger.kernel.org Signed-off-by: Lucas De Marchi Reviewed-by: Ville Syrjälä Signed-off-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20171204232210.4958-1-lucas.demarchi@intel.com (cherry picked from commit 53421c2fe99ce16838639ad89d772d914a119a49) [ Lucas: Backport to 4.15 adding back variable that has been removed on commits not meant to be backported ] Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20180102201837.6812-1-lucas.demarchi@intel.com

drm/i915: Disable DC states around GMBUS on GLK

2018-01-02T11:45:06Z

Prevent the DMC from destroying GMBUS transfers on GLK. GMBUS lives in PG1 so DC off is all we need. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20171208213739.16388-1-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan (cherry picked from commit 156961ae7bdf6feb72778e8da83d321b273343fd) Signed-off-by: Jani Nikula

drm/i915: No need to power up PG2 for GMBUS on BXT

2017-12-22T12:22:48Z

GMBUS lives in PG1, so no need to power up PG2. We do want to prevent the DMC from making a mess of things though, so add GMBUS to the DC off power well. Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20171208213739.16388-2-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan

drm/i915: Disable DC states around GMBUS on GLK

2017-12-22T12:22:48Z

drm/i915: Restore GT performance in headless mode with DMC loaded

2017-12-08T10:23:07Z

It seems that the DMC likes to transition between the DC states a lot when there are no connected displays (no active power domains) during command submission. This activity on DC states has a negative impact on the performance of the chip with huge latencies observed in the interrupt handlers and elsewhere. Simple tests like igt/gem_latency -n 0 are slowed down by a factor of eight. Work around it by introducing a new power domain named, POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is held for the duration of command submission activity. CNL has the same problem which will be addressed as a follow-up. Doing that requires a fix for a DC6 context corruption problem in the CNL DMC firmware which is yet to be released. v2: * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson) * Protect macro body with braces. (Jani Nikula) v3: * Add dedicated power domain for clarity. (Chris, Imre) * Commit message and comment text updates. * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC firmware release. v4: * Power domain should be inner to device runtime pm. (Chris) * Simplify NEEDS_CSR_GT_PERF_WA macro. (Chris) * Handle async DMC loading by moving the GT_IRQ power domain logic into intel_runtime_pm. (Daniel, Chris) * Include small core GEN9 as well. (Imre) v5 * Special handling for async DMC load is not needed since on failure the power domain reference is kept permanently taken. (Imre) v6: * Drop the NEEDS_CSR_GT_PERF_WA macro since all firmwares have now been deployed. (Imre, Chris) Signed-off-by: Tvrtko Ursulin Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572 Testcase: igt/gem_exec_nop/headless Cc: Imre Deak Acked-by: Chris Wilson (v2) Cc: Chris Wilson Cc: Dmitry Rogozhkin Reviewed-by: Daniel Vetter (v5) Reviewed-by: Chris Wilson [Imre: Add note about applying the WA on CNL as a follow-up] Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20171205132854.26380-1-tvrtko.ursulin@linux.intel.com

drm/i915: Start tracking voltage level in the cdclk state

2017-10-25T10:40:00Z

For CNL we'll need to start considering the port clocks when we select the voltage level for the system agent. To that end start tracking the voltage in the cdclk state (since that already has to adjust it). v2: s/voltage/voltage_level/ (Rodrigo) Cc: Mika Kahola Cc: Manasi Navare Cc: Rodrigo Vivi Signed-off-by: Ville Syrjälä Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-3-ville.syrjala@linux.intel.com

drm/i915: Move rps.hw_lock to dev_priv and s/hw_lock/pcu_lock

2017-10-11T07:56:56Z

In order to separate GT PM related functionality into new structure we are updating rps structure. hw_lock in it is used for display related PCU communication too hence move it to dev_priv. Signed-off-by: Sagar Arun Kamble Cc: Imre Deak Cc: Chris Wilson Cc: Joonas Lahtinen Cc: Radoslaw Szwichtenberg Reviewed-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/1507360055-19948-8-git-send-email-sagar.a.kamble@intel.com Acked-by: Imre Deak Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20171010213010.7415-7-chris@chris-wilson.co.uk

drm/i915: Name i915_runtime_pm structure in dev_priv as "runtime_pm"

2017-10-11T07:56:54Z

We were using dev_priv->pm for runtime power management related state. This patch renames it to "runtime_pm" which looks more apt. v2: s/rpm/runtime_pm (Chris) Signed-off-by: Sagar Arun Kamble Cc: Imre Deak Cc: Chris Wilson Cc: Joonas Lahtinen Reviewed-by: Radoslaw Szwichtenberg #1 Reviewed-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/1507360055-19948-7-git-send-email-sagar.a.kamble@intel.com Acked-by: Imre Deak Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20171010213010.7415-6-chris@chris-wilson.co.uk