kernel/linux.git/drivers/gpu/drm/i915/intel_runtime_pm.c, branch v6.6.149

PM: runtime: Simplify pm_runtime_get_if_active() usage

2025-08-28T14:28:42+00:00

[ Upstream commit c0ef3df8dbaef51ee4cfd58a471adf2eaee6f6b3 ] There are two ways to opportunistically increment a device's runtime PM usage count, calling either pm_runtime_get_if_active() or pm_runtime_get_if_in_use(). The former has an argument to tell whether to ignore the usage count or not, and the latter simply calls the former with ign_usage_count set to false. The other users that want to ignore the usage_count will have to explicitly set that argument to true which is a bit cumbersome. To make this function more practical to use, remove the ign_usage_count argument from the function. The main implementation is in a static function called pm_runtime_get_conditional() and implementations of pm_runtime_get_if_active() and pm_runtime_get_if_in_use() are moved to runtime.c. Signed-off-by: Sakari Ailus Reviewed-by: Alex Elder Reviewed-by: Laurent Pinchart Acked-by: Takashi Iwai # sound/ Reviewed-by: Jacek Lawrynowicz # drivers/accel/ivpu/ Acked-by: Rodrigo Vivi # drivers/gpu/drm/i915/ Reviewed-by: Rodrigo Vivi Acked-by: Bjorn Helgaas # drivers/pci/ Signed-off-by: Rafael J. Wysocki [ Removed changes to code that didn't exist in older trees ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/i915: use pointer to i915 instead of rpm in wakeref

2023-06-10T03:32:58+00:00

Currently a pointer to an intel_runtime_pm structure is stored in the wake reference structures so the runtime data can be accessed. We can save the entire device information (drm_i915_private) instead, since we'll need to reference the new workqueue we'll add in subsequent patches. Reviewed-by: Tvrtko Ursulin Signed-off-by: Luca Coelho Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/ec0eb5149120d04f3d9870d7671ef10103e6fc29.1686231190.git.jani.nikula@intel.com

drm/i915/pm: drop intel_pm_setup()

2023-03-06T16:25:58+00:00

All the init in intel_pm_setup() is related to runtime pm. Move them to intel_runtime_pm_init_early(), and remove intel_pm_setup(). Signed-off-by: Jani Nikula Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/b01f9bf0afa9abaece5d0f76aecde69e2679f662.1677678803.git.jani.nikula@intel.com

Merge tag 'drm-intel-gt-next-2022-11-03' of git://anongit.freedesktop.org/drm/drm-intel into drm-next

2022-11-04T07:33:34+00:00

Driver Changes: - Fix for #7306: [Arc A380] white flickering when using arc as a secondary gpu (Matt A) - Add Wa_18017747507 for DG2 (Wayne) - Avoid spurious WARN on DG1 due to incorrect cache_dirty flag (Niranjana, Matt A) - Corrections to CS timestamp support for Gen5 and earlier (Ville) - Fix a build error used with clang compiler on hwmon (GG) - Improvements to LMEM handling with RPM (Anshuman, Matt A) - Cleanups in dmabuf code (Mike) - Selftest improvements (Matt A) Signed-off-by: Dave Airlie From: Joonas Lahtinen Link: https://patchwork.freedesktop.org/patch/msgid/Y2N11wu175p6qeEN@jlahtine-mobl.ger.corp.intel.com

drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual

2022-10-31T13:01:09+00:00

We had already grabbed the rpm wakeref at obj destruction path, but it also required to grab the wakeref when object moves. When i915_gem_object_release_mmap_offset() gets called by i915_ttm_move_notify(), it will release the mmap offset without grabbing the wakeref. We want to avoid that therefore, grab the wakeref at i915_ttm_unmap_virtual() accordingly. While doing that also changed the lmem_userfault_lock from mutex to spinlock, as spinlock widely used for list. Also changed if (obj->userfault_count) to GEM_BUG_ON(!obj->userfault_count). v2: - Removed lmem_userfault_{list,lock} from intel_gt. [Matt Auld] Fixes: ad74457a6b5a ("drm/i915/dgfx: Release mmap on rpm suspend") Suggested-by: Matthew Auld Signed-off-by: Anshuman Gupta Reviewed-by: Matthew Auld Link: https://patchwork.freedesktop.org/patch/msgid/20221027092242.1476080-3-anshuman.gupta@intel.com

drm/i915: Encapsulate lmem rpm stuff in intel_runtime_pm

2022-10-31T12:59:17+00:00

Runtime pm is not really per GT, therefore it make sense to move lmem_userfault_list, lmem_userfault_lock and userfault_wakeref from intel_gt to intel_runtime_pm structure, which is embedded to i915. No functional change. v2: - Fixes the code comment nit. [Matt Auld] Signed-off-by: Anshuman Gupta Reviewed-by: Matthew Auld Acked-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20221027092242.1476080-2-anshuman.gupta@intel.com

drm/i915/dgfx: Keep PCI autosuspend control 'on' by default on all dGPU

2022-10-18T13:14:45+00:00

DGFX platforms has lmem and cpu can access the lmem objects via mmap and i915 internal i915_gem_object_pin_map() for i915 own usages. Both of these methods has pre-requisite requirement to keep GFX PCI endpoint in D0 for a supported iomem transaction over PCI link. (Refer PCIe specs 5.3.1.4.1) Both DG1/DG2 have a known hardware bug that violates the PCIe specs and support the iomem read write transaction over PCIe bus despite endpoint is D3 state. Due to above H/W bug, we had never observed any issue with i915 runtime PM versus lmem access. But this issue becomes visible when PCIe gfx endpoint's upstream bridge enters to D3, at this point any lmem read/write access will be returned as unsupported request. But again this issue is not observed on every platform because it has been observed on few host machines DG1/DG2 endpoint's upstream bridge does not bind with pcieport driver. which really disables the PCIe power savings and leaves the bridge at D0 state. We need a unique interface to read/write from lmem with runtime PM wakeref protection something similar to intel_uncore_{read, write}, keep autosuspend control to 'on' on all discrete platforms, until we have a unique interface to read/write from lmem. This just change the default autosuspend setting of i915 on dGPU, user can still change it to 'auto'. v2: - Modified the commit message and subject with more information. - Changed the Fixes tag to LMEM support commit. [Joonas] - Changed !HAS_LMEM() Cond to !IS_DGFX(). [Rodrigo] Fixes: b908be543e44 ("drm/i915: support creating LMEM objects") Suggested-by: Rodrigo Vivi Reviewed-by: Rodrigo Vivi Signed-off-by: Anshuman Gupta Link: https://patchwork.freedesktop.org/patch/msgid/20221014113258.1284226-1-anshuman.gupta@intel.com

drm/i915/selftests: Disable runtime pm wakeref tracking for the mock device

2022-02-11T11:22:10+00:00

commit c50df701d49e ("drm/i915: Enable rpm wakeref tracking whether runtime pm is enabled or not") enabled wakeref tracking even for the mock device. Turns out that has somewhat significant overhead, and on the glacial Core m3's we have in CI the vma selftests are now exceeding the allotted time budget. So let's disable the wakeref tracking once again for the mock device in order to avoid blowing up the selftest runtime. Cc: Thomas Hellström Acked-by: Tomi Sarvela Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220204171053.18409-1-ville.syrjala@linux.intel.com

drm/i915: Enable rpm wakeref tracking whether runtime pm is enabled or not

2022-02-01T09:12:28+00:00

Don't see why we should skip the wakeref tracking when the platform doesn't support runtime pm. We still want all the code to be 100% leak free so let's track this unconditionally. Cc: Vlastimil Babka Cc: Dmitry Vyukov Cc: Marco Elver # stackdepot Cc: Chris Wilson Cc: Imre Deak Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220126081539.23227-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak

drm/i915: Fix oops due to missing stack depot

2022-02-01T09:12:18+00:00

We call __save_depot_stack() unconditionally so the stack depot must always be initialized or else we'll oops on platforms without runtime pm support. Presumably we've not seen this in CI due to stack_depot_init() already getting called via drm_mm_init()+CONFIG_DRM_DEBUG_MM. Cc: Vlastimil Babka Cc: Dmitry Vyukov Cc: Marco Elver # stackdepot Cc: Chris Wilson Cc: Imre Deak Fixes: 2dba5eb1c73b ("lib/stackdepot: allow optional init and stack_table allocation by kvmalloc()") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220126081539.23227-1-ville.syrjala@linux.intel.com Acked-by: Vlastimil Babka Reviewed-by: Imre Deak