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: 53421c2f ("drm/i915: Apply Display WA #1183 on skl, kbl, and cfl")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180419155109.29451-1-imre.deak@intel.com
(cherry picked from commit b49be662)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

PSR on CNL requires AUX IO wells to be kept on and the existing AUX domain
for AUX-A enables DC_OFF well too. This is not required, so add a new
AUX_IO_A domain for AUX-A to allow DC states to remain enabled. Other AUX
channels re-use the existing AUX domains.

v4: Reword comment (Rodrigo and Ville)
    Rename _get and _put functions to include aux_io substring(Rodrigo)
    Remove unnecessary diff that got included.
v3: Extract aux domain selection into a function (Ville)
v2: Add AUX IO domain only for AUX-A
    Rebased on top of Ville's AUX series.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180223221520.18464-1-dhinakaran.pandiyan@intel.com

As the driver is called to handle circumstances beyond it's control, we
cannot assume that the pm_runtime core is happy to see us. For example,
if we are called from shrink_slab to free up our pages during suspend,
rpm may be disabled and pm_runtime_if_in_use() decides to fail with
-EINVAL rather than simply say no. This is expected to happen, so don't
warn.  For example,

[  217.429228] Suspending console(s) (use no_console_suspend to debug)
[  217.557179] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  217.559399] sd 0:0:0:0: [sda] Stopping disk
[  218.661567] i915 0000:00:02.0: Resetting chip after gpu hang
[  219.523879] ------------[ cut here ]------------
[  219.524474] pm_runtime_get_if_in_use() failed: -22
[  219.524817] WARNING: CPU: 1 PID: 14 at drivers/gpu/drm/i915/intel_runtime_pm.c:3351 intel_runtime_pm_get_if_in_use+0xe3/0x150 [i915]
[  219.524836] Modules linked in: vgem i915 snd_hda_codec_realtek snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec r8169 lpc_ich snd_hwdep mii snd_hda_core snd_pcm prime_numbers
[  219.525054] CPU: 1 PID: 14 Comm: cpuhp/1 Tainted: G     U           4.16.0-rc1-g740f57c54ecf-kasan_6+ #1
[  219.525070] Hardware name:  /D510MO, BIOS MOPNV10J.86A.0311.2010.0802.2346 08/02/2010
[  219.525294] RIP: 0010:intel_runtime_pm_get_if_in_use+0xe3/0x150 [i915]
[  219.525313] RSP: 0018:ffff880018f5edf8 EFLAGS: 00010286
[  219.525344] RAX: dffffc0000000008 RBX: ffff880007fc0000 RCX: 0000000000000000
[  219.525361] RDX: 0000000000000001 RSI: ffffffff850609c0 RDI: ffffffff872992a0
[  219.525377] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
[  219.525394] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880007fc0000
[  219.525411] R13: ffff880018f5f0f8 R14: ffff880007fc8de8 R15: ffff880018f5f0f0
[  219.525429] FS:  0000000000000000(0000) GS:ffff880019c80000(0000) knlGS:0000000000000000
[  219.525446] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  219.525463] CR2: 0000564df7897e86 CR3: 0000000000d7c000 CR4: 00000000000006e0
[  219.525478] Call Trace:
[  219.525734]  i915_gem_shrink+0x841/0xb50 [i915]
[  219.525802]  ? debug_check_no_locks_freed+0x2a0/0x2a0
[  219.525842]  ? trace_hardirqs_on_thunk+0x1a/0x1c
[  219.526083]  ? i915_gem_shrinker_count+0x2f0/0x2f0 [i915]
[  219.526131]  ? lock_acquire+0x138/0x3c0
[  219.526157]  ? lock_acquire+0x138/0x3c0
[  219.526391]  ? shrinker_lock+0x49/0x210 [i915]
[  219.526465]  ? mutex_trylock+0x15c/0x1a0
[  219.526694]  ? shrinker_lock+0x49/0x210 [i915]
[  219.526969]  ? i915_gem_shrinker_scan+0xc4/0x320 [i915]
[  219.527200]  i915_gem_shrinker_scan+0xc4/0x320 [i915]
[  219.527448]  ? i915_gem_shrinker_vmap+0x3a0/0x3a0 [i915]
[  219.527533]  shrink_slab.part.18+0x2d0/0x8d0
[  219.527613]  ? unregister_shrinker+0x1f0/0x1f0
[  219.527668]  ? mem_cgroup_iter+0x37d/0xc50
[  219.527728]  shrink_node+0x882/0xbe0
[  219.527847]  ? shrink_node_memcg+0x11c0/0x11c0
[  219.527882]  ? mark_held_locks+0xa8/0xf0
[  219.527931]  ? trace_hardirqs_on_caller+0x33f/0x590
[  219.527961]  ? ktime_get+0xad/0x140
[  219.528015]  do_try_to_free_pages+0x2d3/0xd70
[  219.528099]  ? allow_direct_reclaim.part.23+0x1d0/0x1d0
[  219.528132]  ? shrink_node+0xbe0/0xbe0
[  219.528213]  try_to_free_pages+0x1cd/0x570
[  219.528257]  ? do_try_to_free_pages+0xd70/0xd70
[  219.528355]  __alloc_pages_nodemask+0xadf/0x2110
[  219.528423]  ? unwind_next_frame+0x870/0x1970
[  219.528465]  ? deref_stack_reg+0x97/0xc0
[  219.528503]  ? gfp_pfmemalloc_allowed+0x150/0x150
[  219.528539]  ? register_sched_domain_sysctl+0x23a/0x1b90
[  219.528588]  ? unwind_next_frame+0x138/0x1970
[  219.528619]  ? kthread+0x30a/0x3d0
[  219.528677]  ? __read_once_size_nocheck.constprop.4+0x10/0x10
[  219.528698]  ? deref_stack_reg+0xc0/0xc0
[  219.528762]  ? __save_stack_trace+0x6e/0xd0
[  219.528822]  depot_save_stack+0x3bc/0x430
[  219.528870]  kasan_kmalloc+0x142/0x170
[  219.528912]  ? __kmalloc+0xf7/0x340
[  219.528935]  ? register_sched_domain_sysctl+0x23a/0x1b90
[  219.528957]  ? partition_sched_domains+0x4d4/0x840
[  219.528978]  ? sched_cpu_deactivate+0x11b/0x150
[  219.529001]  ? cpuhp_invoke_callback+0x160/0x15f0
[  219.529023]  ? cpuhp_thread_fun+0x35e/0x710
[  219.529044]  ? smpboot_thread_fn+0x50a/0x7f0
[  219.529065]  ? kthread+0x30a/0x3d0
[  219.529086]  ? ret_from_fork+0x24/0x50
[  219.529141]  ? register_sched_domain_sysctl+0x23a/0x1b90
[  219.529169]  ? register_sched_domain_sysctl+0x23a/0x1b90
[  219.529198]  ? set_track+0x87/0x100
[  219.529225]  ? init_object+0x6e/0x80
[  219.529275]  ? ___slab_alloc.constprop.36+0x232/0x3e0
[  219.529303]  ? ___slab_alloc.constprop.36+0x232/0x3e0
[  219.529325]  ? register_sched_domain_sysctl+0x23a/0x1b90
[  219.529410]  ? mark_held_locks+0xa8/0xf0
[  219.529453]  ? register_sched_domain_sysctl+0x23a/0x1b90
[  219.529479]  ? trace_hardirqs_on_caller+0x33f/0x590
[  219.529532]  __kmalloc+0xf7/0x340
[  219.529557]  ? register_sched_domain_sysctl+0x23a/0x1b90
[  219.529604]  register_sched_domain_sysctl+0x23a/0x1b90
[  219.529684]  ? sched_debug_show+0x20/0x20
[  219.529713]  ? debug_object_activate+0x530/0x530
[  219.529771]  ? rcu_lockdep_current_cpu_online+0xdc/0x130
[  219.529802]  ? partition_sched_domains+0x4ae/0x840
[  219.529825]  ? rcu_read_lock_sched_held+0x10f/0x130
[  219.529875]  partition_sched_domains+0x4d4/0x840
[  219.529955]  ? sched_init_domains+0x110/0x110
[  219.529981]  ? __wait_rcu_gp+0x24f/0x390
[  219.530054]  sched_cpu_deactivate+0x11b/0x150
[  219.530086]  ? sched_cpu_activate+0x1e0/0x1e0
[  219.530112]  ? __call_rcu.constprop.53+0x680/0x680
[  219.530132]  ? call_rcu_bh+0x10/0x10
[  219.530166]  ? debug_check_no_locks_freed+0x2a0/0x2a0
[  219.530201]  ? trace_raw_output_rcu_utilization+0xa0/0xa0
[  219.530267]  ? trace_raw_output_rcu_utilization+0xa0/0xa0
[  219.530337]  ? rcu_lockdep_current_cpu_online+0xdc/0x130
[  219.530370]  ? sched_cpu_activate+0x1e0/0x1e0
[  219.530397]  cpuhp_invoke_callback+0x160/0x15f0
[  219.530424]  ? lock_acquire+0x138/0x3c0
[  219.530445]  ? lock_acquire+0x138/0x3c0
[  219.530471]  ? cpuhp_thread_fun+0xaf/0x710
[  219.530507]  ? pci_mmcfg_check_reserved+0x100/0x100
[  219.530565]  cpuhp_thread_fun+0x35e/0x710
[  219.530618]  ? cpuhp_complete_idle_dead+0x10/0x10
[  219.530639]  smpboot_thread_fn+0x50a/0x7f0
[  219.530678]  ? sort_range+0x20/0x20
[  219.530709]  ? __kthread_parkme+0xba/0x1f0
[  219.530739]  ? schedule+0x84/0x1a0
[  219.530768]  ? __kthread_parkme+0xbf/0x1f0
[  219.530805]  ? sort_range+0x20/0x20
[  219.530831]  kthread+0x30a/0x3d0
[  219.530859]  ? _kthread_create_on_node+0xb0/0xb0
[  219.530900]  ret_from_fork+0x24/0x50
[  219.530999] Code: 01 00 00 00 85 c0 74 4a 89 e8 5b 5d c3 80 3d 48 37 4e 00 00 75 f2 89 c6 48 c7 c7 40 f0 61 c0 c6 05 36 37 4e 00 01 e8 ed 2a e1 c2 <0f> ff eb d9 80 3d 3f 37 4e 00 00 75 94 48 c7 c7 60 e8 61 c0 c6
[  219.531880] ---[ end trace 18ec0139488ea0c8 ]---
[  219.607967] IRQ 16: no longer affine to CPU1
[  219.670291] IRQ 24: no longer affine to CPU2
[  219.701489] IRQ 8: no longer affine to CPU3
[  219.701529] IRQ 9: no longer affine to CPU3
[  219.701582] IRQ 18: no longer affine to CPU3
[  219.701640] IRQ 25: no longer affine to CPU3
[  219.743857]  cache: parent cpu1 should not be sleeping
[  219.784549]  cache: parent cpu2 should not be sleeping
[  219.816041]  cache: parent cpu3 should not be sleeping

v2: Add Returns: information to intel_runtime_pm_get_if_in_use() kerneldoc.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219125046.19363-1-chris@chris-wilson.co.uk

This patch initializes MBus during display initialization.

Changes since V2 (from Paulo):
 - Don't forget to remove the WARN_ON(1) call.
Changes since V1:
 - Rebase to use function like Macros
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJames Ausmus <james.ausmus@intel.com>
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-6-paulo.r.zanoni@intel.com

ICL has 2 slices of DBuf, enable both the slices during display init.

Ideally we should only enable the second slice when needed in order to
save power, but while we're not there yet, adopt the simpler solution
to keep us bug-free.

v2 (from Paulo):
  - Add the TODO comment.
  - Reorganize where things are defined.
  - Fix indentation.
  - Remove unnecessary POSTING_READ() calls.
  - Improve the commit message.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-5-paulo.r.zanoni@intel.com

This code is similar enough to the CNL code that I considered just
adding ICL support to the CNL function, but I think it's still
different enough, and having a function specific to ICL allows us to
more easily adapt code in case the spec changes more later.

We're still missing the power wells and the mbus code, so leave those
pieces with a FIXME comment while they're not here yet.

v2: Don't use _PICK, don't WARN_ON(1), don't forget the chicken bits.
v3: Use _MMIO_PORT() (Ville).

Reviewed-by: James Ausmus <james.ausmus@intel.com> (v2)
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-4-paulo.r.zanoni@intel.com

On ICL we have two sets of registers: one for port A and another for
port B. The set of port A registers is the same as the CNL registers.

Since the procmon table on ICL is the same we want to reuse the CNL
function. To do that we add a port argument and make CNL always call
the function passing port A. This way, we'll be able to easily reuse
the function on ICL when we add icl_display_core_init().

v2: Don't use _PICK() when you can use a ternary operator.
v3: Don't use a ternary operation when you can use _MMIO_PORT (Ville).
    Add an extra comment about why we're passing PORT_A (James).
Reviewed-by: NJames Ausmus <james.ausmus@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-2-paulo.r.zanoni@intel.com

Now let's finish the Port-F support by adding the
proper port F detection, irq and power well support.

v2: Rebase
v3: Use BIT_ULL
v4: Cover missed case on ddi init.
v5: Update commit message.
v6: Rebase on top of display headers rework.
v7: Squash power-well handling related to DDI F to this
    patch to avoid warns as pointed out by DK.
v8: Introduce DDI_F_LANES to PG2. (DK)
v9: Squash in the PORT_F case for enabling DP MST encoder. (DK)

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-9-rodrigo.vivi@intel.com

We also need to extend this WA to Aux F.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-3-rodrigo.vivi@intel.com

On some Cannonlake SKUs we have a dedicated Aux for port F,
that is only the full split between port A and port E.

There is still no Aux E for Port E, as in previous platforms,
because port_E still means shared lanes with port A.

v2: Rebase.
v3: Add couple missed PORT_F cases on intel_dp.
v4: Rebase and fix commit message.
v5: Squash Imre's "drm/i915: Add missing AUX_F power well string"
v6: Rebase on top of display headers rework.
v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK)
v8: Fix Aux bits for Port F (DK)
v9: Fix VBT definition of Port F (DK).
v10: Squash power well addition to this patch to avoid
     warns as pointed by DK.
v11: Clean up squashed commit message. (David)
v12: Remove unnecessary handling for older platforms (DK)
     Adding AUX_F to PG2 following other existent ones. (DK)

Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-2-rodrigo.vivi@intel.com

Display WA #1178 is meant to fix Aux channel voltage swing too low with
some type C dongles. Although it is for type C, HW engineers reported
that it can be applied to all external ports even if they are not going
to type C.

For CNL we apply the workaround every time Aux B, C and D are powering
up since they will lose the configuration when powered down.

v2: Use common tag for WA

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Arthur J Runyan <arthur.j.runyan@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171128220553.22435-1-lucas.demarchi@intel.com

With firmware 1.07 having fixed the state corruption issue, we can enable
the headless GT performance workaround for CNL as well. (Equivalent to
b6876374 ("drm/i915: Restore GT performance in headless mode with DMC
loaded") on other affected platforms.)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
Testcase: igt/gem_exec_nop/headless
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180111082417.795-1-tvrtko.ursulin@linux.intel.com

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 <arthur.j.runyan@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171204232210.4958-1-lucas.demarchi@intel.com
(cherry picked from commit 53421c2f)
[ Lucas: Backport to 4.15 adding back variable that has been removed on
  commits not meant to be backported ]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180102201837.6812-1-lucas.demarchi@intel.com

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171208213739.16388-1-ville.syrjala@linux.intel.comReviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
(cherry picked from commit 156961ae)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

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 <arthur.j.runyan@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171204232210.4958-1-lucas.demarchi@intel.com

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171208213739.16388-2-ville.syrjala@linux.intel.comReviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171208213739.16388-1-ville.syrjala@linux.intel.comReviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>

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: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
Testcase: igt/gem_exec_nop/headless
Cc: Imre Deak <imre.deak@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v5)
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[Imre: Add note about applying the WA on CNL as a follow-up]
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171205132854.26380-1-tvrtko.ursulin@linux.intel.com

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 <mika.kahola@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-3-ville.syrjala@linux.intel.com

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: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1507360055-19948-8-git-send-email-sagar.a.kamble@intel.comAcked-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010213010.7415-7-chris@chris-wilson.co.uk

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: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> #1Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1507360055-19948-7-git-send-email-sagar.a.kamble@intel.comAcked-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010213010.7415-6-chris@chris-wilson.co.uk

Not all compilers are able to determine that pg is guarded by wait_fuses
and so may think that pg is used uninitialized.
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Fixes: b2891eb2 ("drm/i915/hsw+: Add has_fuses power well attribute")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171002100416.25865-1-chris@chris-wilson.co.ukReviewed-by: NImre Deak <imre.deak@intel.com>
(cherry picked from commit 320671f9)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Not all compilers are able to determine that pg is guarded by wait_fuses
and so may think that pg is used uninitialized.
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Fixes: b2891eb2 ("drm/i915/hsw+: Add has_fuses power well attribute")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171002100416.25865-1-chris@chris-wilson.co.ukReviewed-by: NImre Deak <imre.deak@intel.com>

The DMC firmware program memory is lost after S3/S4 system suspend, so
we need to reprogram it during resume.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103070
Fixes: cebfcead ("drm/i915/DMC/CNL: Load DMC on CNL")
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171003095159.711-1-imre.deak@intel.com
(cherry picked from commit 57522c4c)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The DMC firmware program memory is lost after S3/S4 system suspend, so
we need to reprogram it during resume.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103070
Fixes: cebfcead ("drm/i915/DMC/CNL: Load DMC on CNL")
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171003095159.711-1-imre.deak@intel.com

Our global struct with params is named exactly the same way
as new preferred name for the drm_i915_private function parameter.
To avoid such name reuse lets use different name for the global.

v5: pure rename
v6: fix

Credits-to: Coccinelle

@@
identifier n;
@@
(
-	i915.n
+	i915_modparams.n
)
Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Ville Syrjala <ville.syrjala@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170919193846.38060-1-michal.wajdeczko@intel.com

Move the part that reads the table and sets registers based on the
table to its own function.

v2: Rebase.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170822000356.17330-2-rodrigo.vivi@intel.com

Make it a little less magical and a little simpler and more hardcoded
so we don't end up with an array that's composed mostly of empty
entries.

v2: Add an enum for the voltage+register values (Ville).
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170822000356.17330-1-rodrigo.vivi@intel.com

Future platforms increase the number of power wells which require
additional control registers. A convenient way to select the correct
register is to use the high bits of the power well ID as index. This
patch only prepares for this, while upcoming platform enabling patches
will add the actual new power well IDs and corresponding power well
control registers.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Rakshmi Bhatia <rakshmi.bhatia@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NAnimesh Manna <animesh.manna@intel.com>
Reviewed-by: NRakshmi Bhatia <rakshmi.bhatia@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170814151530.24154-2-imre.deak@intel.com

GCC 4.4 can't cope with anonymous union initializers which seems to be a
bug in that version (see the Reference) and is fixed since GCC version
4.6. A workaround which is also used elsewhere in the kernel for the
same purpose is to wrap the initialization in curly braces, so do the
same here.

Fixes: b5565a2e ("drm/i915/bxt, glk: Give a proper name to the power well struct phy field")
Reference: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20170814151530.24154-1-imre.deak@intel.com

DDI_E is not supported on CNL-U and CNL-Y

When adding the initial support we noticed DDI_E wasn't supported
and removed it on v4 and v5 of that patch.
However for some reason I missed or put back these 2 chunks.

Time to clean it up to avoid later confusion.

Fixes: 8bcd3dd4 ("drm/i915/cnl: Add power wells for CNL")
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170808193237.17410-1-rodrigo.vivi@intel.com

* Don't define it twice.
* Define MSBs first, like the rest of i915_reg.h.
* Add CNL_ prefix to the bit that arrived in CNL.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170714175228.27019-1-paulo.r.zanoni@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Shuffle the power well->domain mapping macros around so they are at one
place in old->new GEN order.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NArkadiusz Hiler <arkadiusz.hiler@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-19-git-send-email-imre.deak@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move the helper next to the rest of HSW specific code.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NArkadiusz Hiler <arkadiusz.hiler@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-18-git-send-email-imre.deak@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

After the previous refactorings the HSW/BDW and GEN9+ power well helpers
are practically identical, so use the HSW power well helpers for GEN9+
too. This means using the HSW power well ops instead of the SKL one and
setting the irq_pipe_mask, has_vga and has_fuses attributes as needed.

v2:
- Rebased on v2 of patch 15.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NArkadiusz Hiler <arkadiusz.hiler@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-7-imre.deak@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The pattern of a power well backing a set of fuses whose initialization
we need to wait for during power well enabling is common to all GEN9+
platforms. Adding support for this to the HSW power well enable helper
allows us to use the HSW/BDW power well code for GEN9+ as well in a
follow-up patch.

v2:
- Use an enum for power gates instead of raw numbers. (Ville)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NArkadiusz Hiler <arkadiusz.hiler@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-6-imre.deak@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Similarly to GEN9+ waiting for the power well disabled state is a safer
option and also provides diagnostic info if the disabling didn't succeed
or the power well was forced on by an external requester. While at it
also use the existing GEN9+ helper to wait for the enabled state.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NArkadiusz Hiler <arkadiusz.hiler@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-15-git-send-email-imre.deak@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The pattern of a power well backing a set of pipe IRQ or VGA
functionality applies to all HSW+ platforms. Using power well attributes
instead of platform checks to decide whether to init/reset pipe IRQs and
VGA correspondingly is cleaner and it allows us to unify the HSW/BDW and
GEN9+ power well code in follow-up patches.

Also use u8 for pipe_mask in related helpers to match the type in the
power well struct.

v2:
- Use u8 instead of u32 for irq_pipe_mask. (Ville)

v3:
- Use u8 for pipe_mask in related helpers too for clarity.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NArkadiusz Hiler <arkadiusz.hiler@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170712155413.29839-1-imre.deak@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Although on HSW/BDW there is only a single display global power well,
it's programmed the same way as other GEN9+ power wells. This also
means we can get at the HSW/BDW request and status flags the same way
it's done on GEN9+ by assigning the corresponding HSW/BDW power well ID.
This ID was assigned in a recent patch, so we can now switch to using
the same macros everywhere on HSW+.

Updating the HSW power well control register with RMW is not strictly
necessary, but this will allow us to use the same code for GEN9+.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NArkadiusz Hiler <arkadiusz.hiler@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-13-git-send-email-imre.deak@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We can reduce the code indentation by splitting the set helper to
separate enable/disable helpers. This also allows us to unify the
HSW/BDW and GEN9+ power well ops in follow-up patches, which introduces
some differences between the enable and disable helpers.

While at it also remove the redundant enable/disable debug messages,
the same info is printed already elsewhere.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NArkadiusz Hiler <arkadiusz.hiler@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-12-git-send-email-imre.deak@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>