summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_runtime_pm.c
AgeCommit message (Collapse)Author
2018-02-27drm/i915/psr: New power domain for AUX IO.Dhinakaran Pandiyan
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: Imre Deak <imre.deak@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180223221520.18464-1-dhinakaran.pandiyan@intel.com
2018-02-19drm/i915: Remove WARN_ONCE for failing to pm_runtime_if_in_useChris Wilson
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180219125046.19363-1-chris@chris-wilson.co.uk
2018-02-13drm/i915/icl: initialize MBus during display initMahesh Kumar
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: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: James Ausmus <james.ausmus@intel.com> Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-6-paulo.r.zanoni@intel.com
2018-02-13drm/i915/icl: Enable both DBuf slices during initMahesh Kumar
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: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-5-paulo.r.zanoni@intel.com
2018-02-13drm/i915/icl: implement the display init/uninit sequencesPaulo Zanoni
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: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-4-paulo.r.zanoni@intel.com
2018-02-13drm/i915/icl: add ICL support to cnl_set_procmon_ref_valuesPaulo Zanoni
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: James Ausmus <james.ausmus@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-2-paulo.r.zanoni@intel.com
2018-01-30drm/i915/cnl: Enable DDI-F on Cannonlake.Rodrigo Vivi
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-9-rodrigo.vivi@intel.com
2018-01-30drm/i915/cnl: Extend Wa 1178 to Aux F.Rodrigo Vivi
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-3-rodrigo.vivi@intel.com
2018-01-30drm/i915/cnl: Add AUX-F supportRodrigo Vivi
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-2-rodrigo.vivi@intel.com
2018-01-18drm/i915/cnl: apply Display WA #1178 to fix type C donglesLucas De Marchi
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: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171128220553.22435-1-lucas.demarchi@intel.com
2018-01-11drm/i915: Apply headless DMC workaround for CNLTvrtko Ursulin
With firmware 1.07 having fixed the state corruption issue, we can enable the headless GT performance workaround for CNL as well. (Equivalent to b68763741aa2 ("drm/i915: Restore GT performance in headless mode with DMC loaded") on other affected platforms.) Signed-off-by: Tvrtko 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: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180111082417.795-1-tvrtko.ursulin@linux.intel.com
2017-12-22drm/i915: Apply Display WA #1183 on skl, kbl, and cflLucas De Marchi
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: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171204232210.4958-1-lucas.demarchi@intel.com
2017-12-22drm/i915: No need to power up PG2 for GMBUS on BXTVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171208213739.16388-2-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2017-12-22drm/i915: Disable DC states around GMBUS on GLKVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171208213739.16388-1-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2017-12-08drm/i915: Restore GT performance in headless mode with DMC loadedTvrtko Ursulin
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 <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: Chris Wilson <chris@chris-wilson.co.uk> [Imre: Add note about applying the WA on CNL as a follow-up] Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171205132854.26380-1-tvrtko.ursulin@linux.intel.com
2017-10-25drm/i915: Start tracking voltage level in the cdclk stateVille Syrjälä
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-3-ville.syrjala@linux.intel.com
2017-10-11drm/i915: Move rps.hw_lock to dev_priv and s/hw_lock/pcu_lockSagar Arun Kamble
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 <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: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1507360055-19948-8-git-send-email-sagar.a.kamble@intel.com Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171010213010.7415-7-chris@chris-wilson.co.uk
2017-10-11drm/i915: Name i915_runtime_pm structure in dev_priv as "runtime_pm"Sagar Arun Kamble
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 <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> #1 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1507360055-19948-7-git-send-email-sagar.a.kamble@intel.com Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171010213010.7415-6-chris@chris-wilson.co.uk
2017-10-06drm/i915: Silence compiler warning for hsw_power_well_enable()Chris Wilson
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: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: b2891eb2531e ("drm/i915/hsw+: Add has_fuses power well attribute") Signed-off-by: Chris 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.uk Reviewed-by: Imre Deak <imre.deak@intel.com>
2017-10-04drm/i915/cnl: Reprogram DMC firmware after S3/S4 resumeImre Deak
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: cebfcead63de ("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: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171003095159.711-1-imre.deak@intel.com
2017-09-22drm/i915: Rename global i915 to i915_modparamsMichal Wajdeczko
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: Michal 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: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170919193846.38060-1-michal.wajdeczko@intel.com
2017-08-22drm/i915/cnl: extract cnl_set_procmon_ref_valuesPaulo Zanoni
Move the part that reads the table and sets registers based on the table to its own function. v2: Rebase. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170822000356.17330-2-rodrigo.vivi@intel.com
2017-08-22drm/i915/cnl: simplify cnl_procmon_values handlingPaulo Zanoni
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: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170822000356.17330-1-rodrigo.vivi@intel.com
2017-08-15drm/i915/hsw+: Add support for multiple power well regsImre Deak
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: Imre Deak <imre.deak@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Rakshmi Bhatia <rakshmi.bhatia@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170814151530.24154-2-imre.deak@intel.com
2017-08-15drm/i915: Work around GCC anonymous union initialization bugImre Deak
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: b5565a2efc12 ("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=10676 Reported-by: Fengguang Wu <fengguang.wu@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170814151530.24154-1-imre.deak@intel.com
2017-08-08drm/i915/cnl: Removing missing DDI_E bits from CNL.Rodrigo Vivi
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: 8bcd3dd41766 ("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: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170808193237.17410-1-rodrigo.vivi@intel.com
2017-07-27drm/i915: cleanup the CHICKEN_MISC_2 (re)definitionsPaulo Zanoni
* 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: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170714175228.27019-1-paulo.r.zanoni@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Gather all the power well->domain mappings to one placeImre Deak
Shuffle the power well->domain mapping macros around so they are at one place in old->new GEN order. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-19-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Move hsw_power_well_enable() next to the rest of HSW helpersImre Deak
Move the helper next to the rest of HSW specific code. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-18-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/gen9+: Unify the HSW/BDW and GEN9+ power well helpersImre Deak
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: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-7-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/hsw+: Add has_fuses power well attributeImre Deak
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: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-6-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/hsw, bdw: Wait for the power well disabled stateImre Deak
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: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-15-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/hsw, bdw: Add irq_pipe_mask, has_vga power well attributesImre Deak
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: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170712155413.29839-1-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/hsw+: Unify the hsw/bdw and gen9+ power well req/state macrosImre Deak
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: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-13-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/hsw, bdw: Split power well set to enable/disable helpersImre Deak
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: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-12-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/hsw, bdw: Remove redundant state check during power well togglingImre Deak
Similarly to the GEN9 power well toggling, saving an occasional extra MMIO write is not worth the code complexity, let's simplify things. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-11-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/gen9+: Remove redundant state check during power well togglingImre Deak
Atm we enable/disable a power well only if it wasn't already enabled/disabled respectively. The only reason for this I can think of is to save the extra MMIO writes. Since the HW state matches the power well's usage counter most of the time the overhead due to these MMIOs is insignificant. Let's simplify the code by making the writes unconditional. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-10-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/gen9+: Remove redundant power well state assert during enablingImre Deak
We check already for power wells that are unexpectedly on (or forced on) during power well disabling. Those checks also account for other power well requesters like KVMR or DEBUG. As such this check is redundant, let's remove it to simplify things. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-9-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/bxt, glk: Give a proper name to the power well struct phy fieldImre Deak
Follow-up patches will add new fields to the i915_power_well struct that are specific to the hsw_power_well_ops helpers. Prepare for this by changing the generic 'data' field to a union of platform specific structs. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-8-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Check for duplicated power well IDsImre Deak
Check that all the power well IDs are unique on the given platform. v2: - Fix using BIT_ULL() instead of BIT() for 64 bit mask. v3: - Move the check to a separate function. (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-4-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/hsw, bdw: Add an ID for the global display power wellImre Deak
Add an ID for the HSW/BDW global display power well for consistency. The ID is selected so that it can be used to get at the HW request and status flags with the corresponding GEN9+ macros. Unifying the HSW/BDW and GEN9+ versions of these macros and the power well ops using them will be done in follow-up patches. v2: - Rebased on v2 of patch 2. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-3-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/gen2: Add an ID for the display pipes power wellImre Deak
Make the I830 power well ID assignment explicit for consistency. v2: - s/GEN2/I830/ in the comment, since other GEN2s don't have the power well. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-2-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Assign everywhere the always-on power well IDImre Deak
Power well IDs are used for lookup so they must be unique. To ensure this assign the always-on power well ID everywhere where it's missing. This didn't cause a problem so far, since we didn't need to look up power wells that happened to share their IDs. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-4-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Unify power well ID enumsImre Deak
Atm, the power well IDs are defined in separate platform specific enums, which isn't ideal for the following reasons: - the IDs are used by helpers like lookup_power_well() in a platform independent way - the always-on power well is used by multiple platforms and so needs now separate IDs, although these IDs refer to the same thing To make things more consistent use a single enum instead of the two separate ones, listing the IDs per platform (or set of very similar platforms like all GEN9/10). Replace the separate always-on power well IDs with a single ID. While at it also add a note clarifying the distinction between regular power wells that follow a common programming pattern and custom ones that are programmed in some other way. The IDs for regular power wells need to stay fixed, since they also define the request and state HW flag positions in their corresponding power well control register(s). v2: - Add comment about id to req,status bit mapping to the enum. (Rodrigo) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-1-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/chv: Add unique power well ID for the pipe A power wellImre Deak
The power well IDs are used for lookup, so they must be unique on a given platform; ensure this on CHV. This didn't cause an actual problem since we didn't need to look up power wells which happened to share an ID. Mark this new power well as custom, since its programming pattern doesn't follow that of the rest of VLV/CHV power wells. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-2-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-10drm/i915/cnl: Add max allowed Cannonlake DC.Rodrigo Vivi
This is a follow-up after enabling DC states with commit: "drm/i915/DMC/CNL: Load DMC on CNL". Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499373908-26761-1-git-send-email-rodrigo.vivi@intel.com
2017-07-06drm/i915/cnl: Fix comment about AUX IO power well enable/disableImre Deak
The comments match an earlier version of the patch, fix them to match the current state. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-6-git-send-email-imre.deak@intel.com
2017-07-06drm/i915/gen9+: Don't remove secondary power well requestsImre Deak
So far in an attempt to make sure all power wells get disabled during display uninitialization the driver removed any secondary request bits (BIOS, KVMR, DEBUG) that were set for a given power well. The known source for these requests was DMC's request on power well 1 and the misc IO power well. Since DMC is inactive (DC states are disabled) at the point we disable these power wells, there shouldn't be any reason to leave them on. However there are two problems with the above assumption: Bspec requires that the misc IO power well stays enabled (without providing a reason) and there can be KVMR requests that we can't remove anyway (the KVMR request register is R/O). Atm, a KVMR request can trigger a timeout WARN when trying to disable power wells. To make the code aligned to Bspec and to get rid of the KVMR WARN, don't try to remove the secondary requests, only detect them and stop polling for the power well disabled state when any one is set. Also add a comment about the timeout values required by Bspec when enabling power wells and the fact that waiting for them to get disabled is not required by Bspec. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98564 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-5-git-send-email-imre.deak@intel.com
2017-07-06drm/i915/bxt, glk: Fix assert on conditions for DC9 enablingImre Deak
What we want to assert based on the conditions required by Bspec is that power well 2 is disabled, so no need to check for other power wells. In addition we can only check if the driver's request is removed, the actual state depends on whether the other request bits are set or not (BIOS, KVMR, DEBUG). So check only the driver's request bit. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-4-git-send-email-imre.deak@intel.com
2017-07-06drm/i915/skl: Don't disable misc IO power well during display uninitImre Deak
Bspec requires leaving the misc IO power well enabled during display uninit, so align the code accordingly. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-3-git-send-email-imre.deak@intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-16 18:52:56 +0000