#
c1be6162 |
|
17-Jul-2023 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Add helpers for managing rps thresholds In preparation for exposing via sysfs add helpers for managing rps thresholds. v2: * Force sw and hw re-programming on threshold change. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@kernel.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230717164013.826614-3-tvrtko.ursulin@linux.intel.com
|
#
44df42e6 |
|
15-Mar-2023 |
Ashutosh Dixit <ashutosh.dixit@intel.com> |
drm/i915/pmu: Use functions common with sysfs to read actual freq Expose intel_rps_read_actual_frequency_fw to read the actual freq without taking forcewake for use by PMU. The code is refactored to use a common set of functions across sysfs and PMU. Using common functions with sysfs in PMU solves the issues of missing support for MTL and missing support for older generations (prior to Gen6). It also future proofs the PMU where sometimes code has been updated for sysfs and PMU has been missed. v2: Remove runtime_pm_if_in_use from read_actual_frequency_fw (Tvrtko) v3: (Tvrtko) - Remove goto in __read_cagf - Unexport intel_rps_get_cagf and intel_rps_read_punit_req Fixes: 22009b6dad66 ("drm/i915/mtl: Modify CAGF functions for MTL") Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8280 Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316004800.2539753-1-ashutosh.dixit@intel.com
|
#
12d4eb20 |
|
15-Mar-2023 |
Ashutosh Dixit <ashutosh.dixit@intel.com> |
drm/i915/pmu: Use functions common with sysfs to read actual freq Expose intel_rps_read_actual_frequency_fw to read the actual freq without taking forcewake for use by PMU. The code is refactored to use a common set of functions across sysfs and PMU. Using common functions with sysfs in PMU solves the issues of missing support for MTL and missing support for older generations (prior to Gen6). It also future proofs the PMU where sometimes code has been updated for sysfs and PMU has been missed. v2: Remove runtime_pm_if_in_use from read_actual_frequency_fw (Tvrtko) v3: (Tvrtko) - Remove goto in __read_cagf - Unexport intel_rps_get_cagf and intel_rps_read_punit_req Fixes: 22009b6dad66 ("drm/i915/mtl: Modify CAGF functions for MTL") Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8280 Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316004800.2539753-1-ashutosh.dixit@intel.com (cherry picked from commit 44df42e66139b5fac8db49ee354be279210f9816) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
72b9da73 |
|
18-Jan-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move GT_FREQUENCY_MULTIPLIER and GEN9_FREQ_SCALER to intel_rps.h Declutter i915_drv.h. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230118131538.3558599-7-jani.nikula@intel.com
|
#
01b8c2e6 |
|
14-Nov-2022 |
Don Hiatt <don.hiatt@intel.com> |
drm/i915: Use GEN12_RPSTAT register for GT freq On GEN12+ use GEN12_RPSTAT register to get actual resolved GT freq. GEN12_RPSTAT does not require a forcewake and will return 0 freq if GT is in RC6. v2: - Fixed review comments(Ashutosh) - Added function intel_rps_read_rpstat_fw to read RPSTAT without forcewake, required especially for GEN6_RPSTAT1 (Ashutosh, Tvrtko) v3: - Updated commit title and message for more clarity (Ashutosh) - Replaced intel_rps_read_rpstat with direct read to GEN12_RPSTAT1 in read_cagf (Ashutosh) v4: Remove GEN12_CAGF_SHIFT and use REG_FIELD_GET (Rodrigo) Cc: Don Hiatt <donhiatt@gmail.com> Cc: Andi Shyti <andi.shyti@intel.com> Signed-off-by: Don Hiatt <don.hiatt@intel.com> Signed-off-by: Badal Nilawar <badal.nilawar@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.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/20221114123348.3474216-3-badal.nilawar@intel.com
|
#
cf51cc7b |
|
05-Oct-2022 |
Vinay Belgaumkar <vinay.belgaumkar@intel.com> |
drm/i915: Add a wrapper for frequency debugfs Move it to the RPS source file. v2: Separate out code movement and functional changes (Jani) Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221005155943.34747-2-vinay.belgaumkar@intel.com
|
#
018a7bdb |
|
31-Aug-2022 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915/slpc: Let's fix the PCODE min freq table setup for SLPC We need to inform PCODE of a desired ring frequencies so PCODE update the memory frequencies to us. rps->min_freq and rps->max_freq are the frequencies used in that request. However they were unset when SLPC was enabled and PCODE never updated the memory freq. v2 (as Suggested by Ashutosh): if SLPC is in use, let's pick the right frequencies from the get_ia_constants instead of the fake init of rps' min and max. v3: don't forget the max <= min return v4: Move all the freq conversion to intel_rps.c. And the max <= min check to where it belongs. v5: (Ashutosh) Fix old comment s/50 HZ/50 MHz and add a doc explaining the "raw format" Fixes: 7ba79a671568 ("drm/i915/guc/slpc: Gate Host RPS when SLPC is enabled") Cc: <stable@vger.kernel.org> # v5.15+ Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Tested-by: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220831214538.143950-1-rodrigo.vivi@intel.com
|
#
e1cab970 |
|
31-Aug-2022 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915/slpc: Let's fix the PCODE min freq table setup for SLPC We need to inform PCODE of a desired ring frequencies so PCODE update the memory frequencies to us. rps->min_freq and rps->max_freq are the frequencies used in that request. However they were unset when SLPC was enabled and PCODE never updated the memory freq. v2 (as Suggested by Ashutosh): if SLPC is in use, let's pick the right frequencies from the get_ia_constants instead of the fake init of rps' min and max. v3: don't forget the max <= min return v4: Move all the freq conversion to intel_rps.c. And the max <= min check to where it belongs. v5: (Ashutosh) Fix old comment s/50 HZ/50 MHz and add a doc explaining the "raw format" Fixes: 7ba79a671568 ("drm/i915/guc/slpc: Gate Host RPS when SLPC is enabled") Cc: <stable@vger.kernel.org> # v5.15+ Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Tested-by: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220831214538.143950-1-rodrigo.vivi@intel.com (cherry picked from commit 018a7bdbb090b9155a6509a0d1a684db4afaa5b1) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
56758cc4 |
|
06-Apr-2022 |
Ashutosh Dixit <ashutosh.dixit@intel.com> |
drm/i915/rps: Centralize computation of freq caps Freq caps (i.e. RP0, RP1 and RPn frequencies) are read from HW. However the formats (bit positions, widths, registers and units) of these vary for different generations with even more variations arriving in the future. In order not to have to do identical computation for these caps in multiple places, here we centralize the computation of these caps. This makes the code cleaner and also more extensible for the future. v2: Clarify that caps are in "hw units" in comments (Lucas De Marchi) v3: Minor checkpatch fix v4: s/intel_rps_get_freq_caps/gen6_rps_get_freq_caps/ (Badal Nilawar) v5: Changes comments to kernel doc (Anshuman Gupta) Cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Acked-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220406191848.20895-1-ashutosh.dixit@intel.com
|
#
fa68bff7 |
|
18-Mar-2022 |
Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> |
drm/i915/gt: Add sysfs throttle frequency interfaces Throttling here refers to the GT frequency being clipped. Each of the throttle reason attributes will have a 0 or 1 value depending upon whether there is throttling and also the specific reason for it. The following is a brief description of the sysfs throttle frequency attributes added: - throttle_reason_status: when set indicates that there is GT frequency clipping. - throttle_reason_pl1: when set indicates that PBM PL1 (platform or package PL1) has caused GT frequency clipping. - throttle_reason_pl2: when set indicates that PBM PL2 or PL3 (platform or package PL2 or PL3) has caused GT frequency clipping. - throttle_reason_pl4: when set indicates that PL4 or IccMax has caused GT frequency clipping. - throttle_reason_thermal: when set indicates that Thermal event has caused GT frequency clipping. - throttle_reason_prochot: when set indicates that PROCHOT# has caused GT frequency clipping. - throttle_reason_ratl: when set indicates that Running Average Thermal Limit has caused GT frequency clipping. - throttle_reason_vr_thermalert: when set indicates that Hot VR (any processor VR) has caused GT frequency clipping. - throttle_reason_vr_tdc: when set indicates that VR TDC (Thermal Design Current) has caused GT frequency clipping. Signed-off-by: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Dale B Stimson <dale.b.stimson@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220318233938.149744-8-andi.shyti@linux.intel.com
|
#
1c40d40f |
|
16-Dec-2021 |
Vinay Belgaumkar <vinay.belgaumkar@intel.com> |
drm/i915/guc: Request RP0 before loading firmware By default, GT (and GuC) run at RPn. Requesting for RP0 before firmware load can speed up DMA and HuC auth as well. In addition to writing to 0xA008, we also need to enable swreq in 0xA024 so that Punit will pay heed to our request. SLPC will restore the frequency back to RPn after initialization, but we need to manually do that for the non-SLPC path. We don't need a manual override in the SLPC disabled case, just use the intel_rps_set function to ensure consistent RPS state. Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211216233022.21351-1-vinay.belgaumkar@intel.com
|
#
1448d5c4 |
|
01-Nov-2021 |
Vinay Belgaumkar <vinay.belgaumkar@intel.com> |
drm/i915/guc/slpc: Update boost sysfs hooks for SLPC Add a helper to sort through the SLPC/RPS paths of get/set methods. Boost frequency will be modified as long as it is within the constraints of RP0 and if it is different from the existing one. We will set min freq to boost only if there is at least one active waiter. v2: Add num_boosts to guc_slpc_info and changes for worker function v3: Review comments (Ashutosh) Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211102012608.8609-4-vinay.belgaumkar@intel.com
|
#
493043fe |
|
01-Nov-2021 |
Vinay Belgaumkar <vinay.belgaumkar@intel.com> |
drm/i915/guc/slpc: Add waitboost functionality for SLPC Add helper in RPS code for handling SLPC and non-SLPC paths. When boost is requested in the SLPC path, we can ask GuC to ramp up the frequency req by setting the minimum frequency to boost freq. Reset freq back to the min softlimit when there are no more waiters. v2: Schedule a worker thread which can boost freq from within an interrupt context as well. v3: No need to check against requested freq before scheduling boost work (Ashutosh) Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211102012608.8609-3-vinay.belgaumkar@intel.com
|
#
efd330b9 |
|
05-Aug-2021 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/xehpsdv: factor out function to read RP_STATE_CAP Instead of maintaining the same if ladder in 3 different places, add a function to read RP_STATE_CAP. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210805163647.801064-6-matthew.d.roper@intel.com
|
#
41e5c17e |
|
30-Jul-2021 |
Vinay Belgaumkar <vinay.belgaumkar@intel.com> |
drm/i915/guc/slpc: Sysfs hooks for SLPC Update the get/set min/max freq hooks to work for SLPC case as well. Consolidate helpers for requested/min/max frequency get/set to intel_rps where the proper action can be taken depending on whether SLPC is enabled. v2: Add wrappers for getting rp0/1/n frequencies, update softlimits in set min/max SLPC functions. Also check for boundary conditions before setting them. v3: Address review comments (Michal W) v4: Add helper for host part of intel_rps_set_freq helpers (Michal W) v5: checkpatch() Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Acked-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210730202119.23810-13-vinay.belgaumkar@intel.com
|
#
24f90d66 |
|
22-Jan-2021 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: SPDX cleanup Clean up the SPDX licence declarations to comply with checkpatch. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210122192913.4518-1-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
389b7f00 |
|
02-May-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Sanitize RPS interrupts upon resume Currently we clear and disable the RPS pm interrupts on module load, and presume that they remain disabled forevermore. However, the mask is cleared on suspend and so after resume they may start showing up again unexepectedly. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1811 Fixes: 8e99299a04bc ("drm/i915/gt: Track use of RPS interrupts in flags") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi@etezian.org> Reviewed-by: Andi Shyti <andi@etezian.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200502173512.32353-1-chris@chris-wilson.co.uk
|
#
36d516be |
|
29-Apr-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Switch to manual evaluation of RPS As with the realisation for soft-rc6, we respond to idling the engines within microseconds, far faster than the response times for HW RC6 and RPS. Furthermore, our fast parking upon idle, prevents HW RPS from running for many desktop workloads, as the RPS evaluation intervals are on the order of tens of milliseconds, but the typical workload is just a couple of milliseconds, but yet we still need to determine the best frequency for user latency versus power. Recognising that the HW evaluation intervals are a poor fit, and that they were deprecated [in bspec at least] from gen10, start to wean ourselves off them and replace the EI with a timer and our accurate busy-stats. The principle benefit of manually evaluating RPS intervals is that we can be more responsive for better performance and powersaving for both spiky workloads and steady-state. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1698 Fixes: 98479ada421a ("drm/i915/gt: Treat idling as a RPS downclock event") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429205446.3259-4-chris@chris-wilson.co.uk
|
#
8e99299a |
|
29-Apr-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Track use of RPS interrupts in flags Use the new intel_rps.flags field to store whether or not interrupts are being used with RPS. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Andi Shyti <andi@etezian.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200429205446.3259-3-chris@chris-wilson.co.uk
|
#
9bad2adb |
|
29-Apr-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Move rps.enabled/active to flags Pull the boolean intel_rps.enabled and intel_rps.active into a single flags field, in preparation for more. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429205446.3259-2-chris@chris-wilson.co.uk
|
#
e03512ed |
|
13-Dec-2019 |
Andi Shyti <andi.shyti@intel.com> |
drm/i915/rps: Add frequency translation helpers Add two helpers that for reading the actual GT's frequency. The two helpers are: - intel_rps_read_cagf: reads the frequency and returns it not normalized - intel_rps_read_actual_frequency: provides the frequency in Hz. Use the above helpers in sysfs and debugfs. Signed-off-by: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191213183736.31992-2-andi@etezian.org
|
#
a06375a9 |
|
30-Oct-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Always track callers to intel_rps_mark_interactive() During startup, we may find ourselves in an interesting position where we haven't fully enabled RPS before the display starts trying to use it. This may lead to an imbalance in our "interactive" counter: <3>[ 4.813326] intel_rps_mark_interactive:652 GEM_BUG_ON(!rps->power.interactive) <4>[ 4.813396] ------------[ cut here ]------------ <2>[ 4.813398] kernel BUG at drivers/gpu/drm/i915/gt/intel_rps.c:652! <4>[ 4.813430] invalid opcode: 0000 [#1] PREEMPT SMP PTI <4>[ 4.813438] CPU: 1 PID: 18 Comm: kworker/1:0H Not tainted 5.4.0-rc5-CI-CI_DRM_7209+ #1 <4>[ 4.813447] Hardware name: /NUC7i5BNB, BIOS BNKBL357.86A.0054.2017.1025.1822 10/25/2017 <4>[ 4.813525] Workqueue: events_highpri intel_atomic_cleanup_work [i915] <4>[ 4.813589] RIP: 0010:intel_rps_mark_interactive+0xb3/0xc0 [i915] <4>[ 4.813597] Code: bc 3f de e0 48 8b 35 84 2e 24 00 49 c7 c0 f3 d4 4e a0 b9 8c 02 00 00 48 c7 c2 80 9c 48 a0 48 c7 c7 3e 73 34 a0 e8 8d 3b e5 e0 <0f> 0b 90 66 2e 0f 1f 84 00 00 00 00 00 80 bf c0 00 00 00 00 74 32 <4>[ 4.813616] RSP: 0018:ffffc900000efe00 EFLAGS: 00010286 <4>[ 4.813623] RAX: 000000000000000e RBX: ffff8882583cc7f0 RCX: 0000000000000000 <4>[ 4.813631] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888275969c00 <4>[ 4.813639] RBP: 0000000000000000 R08: 0000000000000008 R09: ffff888275ace000 <4>[ 4.813646] R10: ffffc900000efe00 R11: ffff888275969c00 R12: ffff8882583cc8d8 <4>[ 4.813654] R13: ffff888276abce00 R14: 0000000000000000 R15: ffff88825e878860 <4>[ 4.813662] FS: 0000000000000000(0000) GS:ffff888276a80000(0000) knlGS:0000000000000000 <4>[ 4.813672] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 4.813678] CR2: 00007f051d5ca0a8 CR3: 0000000262f48001 CR4: 00000000003606e0 <4>[ 4.813686] Call Trace: <4>[ 4.813755] intel_cleanup_plane_fb+0x4e/0x60 [i915] <4>[ 4.813764] drm_atomic_helper_cleanup_planes+0x4d/0x70 <4>[ 4.813833] intel_atomic_cleanup_work+0x15/0x80 [i915] <4>[ 4.813842] process_one_work+0x26a/0x620 <4>[ 4.813850] worker_thread+0x37/0x380 <4>[ 4.813857] ? process_one_work+0x620/0x620 <4>[ 4.813864] kthread+0x119/0x130 <4>[ 4.813870] ? kthread_park+0x80/0x80 <4>[ 4.813878] ret_from_fork+0x3a/0x50 <4>[ 4.813887] Modules linked in: i915(+) mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul btusb btrtl btbcm btintel snd_hda_intel snd_intel_nhlt snd_hda_codec bluetooth snd_hwdep snd_hda_core ghash_clmulni_intel snd_pcm e1000e ecdh_generic ecc ptp pps_core mei_me mei prime_numbers <4>[ 4.813934] ---[ end trace c13289af88174ffc ]--- The solution employed is to not worry about RPS state and keep the tally of the interactive counter separate. When we do enable RPS, we will then take the display activity into account. Fixes: 3e7abf814193 ("drm/i915: Extract GT render power state management") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Acked-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191030103827.2413-1-chris@chris-wilson.co.uk
|
#
3e7abf81 |
|
24-Oct-2019 |
Andi Shyti <andi@etezian.org> |
drm/i915: Extract GT render power state management i915_irq.c is large. One reason for this is that has a large chunk of the GT render power management stashed away in it. Extract that logic out of i915_irq.c and intel_pm.c and put it under one roof. Based on a patch by Chris Wilson. Signed-off-by: Andi Shyti <andi.shyti@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191024211642.7688-1-chris@chris-wilson.co.uk
|