Changes in intel_runtime_pm.c

381ab12d - drm/i915: fix typos in drm/i915 files

Mon, 20 Jan 2025 08:15:17 +0000

drm/i915: fix typos in drm/i915 filesFix all typos in files under drm/i915 reported by codespell tool.v2: Fix commenting style. v3: "in case" should be capitalized and fix comment style. Signed-off-by: Nitin Gote Reviewed-by: Krzysztof Niemiec Link: https://patchwork.freedesktop.org/patch/msgid/20250120081517.3237326-9-nitin.r.gote@intel.comSigned-off-by: Rodrigo Vivi List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

8231ac7e - drm/i915: use NULL for zero wakeref_t instead of plain integer 0

Wed, 02 Oct 2024 18:16:55 +0000

drm/i915: use NULL for zero wakeref_t instead of plain integer 0As of commit 2edc6a75f26c ("drm/i915: switch intel_wakeref_t underlyingtype to struct ref_tracker *") we gained quite a few sparse warningsabout "Using plain integer as NULL pointer" for using 0 to initializewakeref_t. Switch to NULL everywhere.Signed-off-by: Jani Nikula Reviewed-by: Chaitanya Kumar Borah Link: https://patchwork.freedesktop.org/patch/msgid/20241002181655.582597-1-jani.nikula@intel.com List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

3b856748 - drm/i915: use INTEL_WAKEREF_DEF instead of magic -1 for intel_wakeref_t

Wed, 18 Sep 2024 17:35:44 +0000

drm/i915: use INTEL_WAKEREF_DEF instead of magic -1 for intel_wakeref_tA number of places rely on the magic -1 to denoteINTEL_WAKEREF_DEF. Switch to the macro. Define it for xe as well.Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/57e5f1989113be4d63386478d9438cfc35a2a1f7.1726680898.git.jani.nikula@intel.comSigned-off-by: Jani Nikula List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

7af6b116 - drm/i915: Convert intel_runtime_pm_get_noresume towards raw wakeref

Thu, 18 Apr 2024 22:37:56 +0000

drm/i915: Convert intel_runtime_pm_get_noresume towards raw wakerefIn the past, the noresume function was used by the GEM code to ensurewakelocks were held and bump its usage. This is no longer the caseand this function was totally unused until it started to be used againby display with commit 77e619a82fc3 ("drm/i915/display: convert innerwakeref get towards get_if_in_use")However, on the display code, most of the callers are using theraw wakeref, rather then the wakelock version. What caused amajor regression caught by CI.Another option to this patch is to go with the original plan anduse the get_if_in_use variant in the display code, what is enoughto fulfil our needs. Then, an extra patch to delete the unused_noresume variant.v2: Keep grabbing wakelock but only assert for wakeref. (Imre)Cc: Imre Deak Cc: Francois Dugast Cc: Ville Syrjälä Fixes: 77e619a82fc3 ("drm/i915/display: convert inner wakeref get towards get_if_in_use")Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10875Signed-off-by: Rodrigo Vivi Reviewed-by: Imre Deak Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20240418223756.68427-1-rodrigo.vivi@intel.com List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

c0ef3df8 - PM: runtime: Simplify pm_runtime_get_if_active() usage

Tue, 30 Jan 2024 11:28:05 +0000

PM: runtime: Simplify pm_runtime_get_if_active() usageThere are two ways to opportunistically increment a device's runtime PMusage count, calling either pm_runtime_get_if_active() orpm_runtime_get_if_in_use(). The former has an argument to tell whether toignore the usage count or not, and the latter simply calls the former withign_usage_count set to false. The other users that want to ignore theusage_count will have to explicitly set that argument to true which is abit cumbersome.To make this function more practical to use, remove the ign_usage_countargument from the function. The main implementation is in a staticfunction called pm_runtime_get_conditional() and implementations ofpm_runtime_get_if_active() and pm_runtime_get_if_in_use() are moved toruntime.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 List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

261200eb - drm/i915/rpm: add rpm_to_i915() helper around container_of()

Tue, 05 Dec 2023 12:15:45 +0000

drm/i915/rpm: add rpm_to_i915() helper around container_of()Reduce the duplication.Signed-off-by: Jani Nikula Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20231205121545.2338665-1-jani.nikula@intel.com List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

b49e894c - drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library

Mon, 30 Oct 2023 17:40:12 +0000

drm/i915: Replace custom intel runtime_pm tracker with ref_tracker libraryBeside reusing existing code, the main advantage of ref_tracker istracking per instance of wakeref. It allows also to catch doubleput.On the other side we lose information about the first acquire andthe last release, but the advantages outweigh it.Signed-off-by: Andrzej Hajda Reviewed-by: Andi Shyti Link: https://patchwork.freedesktop.org/patch/msgid/20231030-ref_tracker_i915-v1-1-006fe6b96421@intel.com List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

8874288c - drm/i915: Remove runtime suspended boolean from intel_runtime_pm struct

Wed, 13 Sep 2023 10:04:30 +0000

drm/i915: Remove runtime suspended boolean from intel_runtime_pm structIt's not necessary to carry separate suspended status information inintel_runtime_pm struct as this information is already in underlying devicestructure. Remove it and use pm_runtime_suspended() to obtain suspendedstatus information when needed.Cc: Jani Nikula Cc: Imre Deak Signed-off-by: Jouni Högander Acked-by: Jani Nikula Reviewed-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20230913100430.3433969-1-jouni.hogander@intel.com List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

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

Thu, 08 Jun 2023 13:35:44 +0000

drm/i915: use pointer to i915 instead of rpm in wakerefCurrently a pointer to an intel_runtime_pm structure is stored in thewake reference structures so the runtime data can be accessed. We cansave the entire device information (drm_i915_private) instead, sincewe'll need to reference the new workqueue we'll add in subsequentpatches.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 List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

d3708182 - drm/i915/pm: drop intel_pm_setup()

Wed, 01 Mar 2023 13:54:16 +0000

drm/i915/pm: drop intel_pm_setup()All the init in intel_pm_setup() is related to runtime pm. Move them tointel_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 List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

1cacd689 - drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual

Thu, 27 Oct 2022 09:22:42 +0000

drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtualWe 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 byi915_ttm_move_notify(), it will release the mmap offset withoutgrabbing 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 frommutex to spinlock, as spinlock widely used for list.Also changed if (obj->userfault_count) toGEM_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 List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

e66c8dcf - drm/i915: Encapsulate lmem rpm stuff in intel_runtime_pm

Thu, 27 Oct 2022 09:22:41 +0000

drm/i915: Encapsulate lmem rpm stuff in intel_runtime_pmRuntime pm is not really per GT, therefore it make sense tomove lmem_userfault_list, lmem_userfault_lock anduserfault_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 List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

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

Fri, 14 Oct 2022 11:32:58 +0000

drm/i915/dgfx: Keep PCI autosuspend control 'on' by default on all dGPUDGFX platforms has lmem and cpu can access the lmem objectsvia mmap and i915 internal i915_gem_object_pin_map() fori915 own usages. Both of these methods has pre-requisiterequirement to keep GFX PCI endpoint in D0 for a supportediomem transaction over PCI link. (Refer PCIe specs 5.3.1.4.1)Both DG1/DG2 have a known hardware bug that violates the PCIe specsand support the iomem read write transaction over PCIe bus despiteendpoint is D3 state.Due to above H/W bug, we had never observed any issue with i915 runtimePM versus lmem access.But this issue becomes visible when PCIe gfx endpoint's upstreambridge enters to D3, at this point any lmem read/write access will bereturned as unsupported request. But again this issue is not observedon every platform because it has been observed on few host machinesDG1/DG2 endpoint's upstream bridge does not bind with pcieport driver.which really disables the PCIe power savings and leaves the bridgeat D0 state.We need a unique interface to read/write from lmem with runtime PMwakeref 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(cherry picked from commit 66eb93e71a7a6695b7c5eb682e3ca1c980cf9d58)Signed-off-by: Tvrtko Ursulin List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

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

Fri, 14 Oct 2022 11:32:58 +0000

drm/i915/dgfx: Keep PCI autosuspend control 'on' by default on all dGPUDGFX platforms has lmem and cpu can access the lmem objectsvia mmap and i915 internal i915_gem_object_pin_map() fori915 own usages. Both of these methods has pre-requisiterequirement to keep GFX PCI endpoint in D0 for a supportediomem transaction over PCI link. (Refer PCIe specs 5.3.1.4.1)Both DG1/DG2 have a known hardware bug that violates the PCIe specsand support the iomem read write transaction over PCIe bus despiteendpoint is D3 state.Due to above H/W bug, we had never observed any issue with i915 runtimePM versus lmem access.But this issue becomes visible when PCIe gfx endpoint's upstreambridge enters to D3, at this point any lmem read/write access will bereturned as unsupported request. But again this issue is not observedon every platform because it has been observed on few host machinesDG1/DG2 endpoint's upstream bridge does not bind with pcieport driver.which really disables the PCIe power savings and leaves the bridgeat D0 state.We need a unique interface to read/write from lmem with runtime PMwakeref 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 List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

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

Fri, 04 Feb 2022 17:10:53 +0000

drm/i915/selftests: Disable runtime pm wakeref tracking for the mock devicecommit c50df701d49e ("drm/i915: Enable rpm wakeref trackingwhether runtime pm is enabled or not") enabled wakeref trackingeven for the mock device. Turns out that has somewhat significantoverhead, and on the glacial Core m3's we have in CI the vmaselftests are now exceeding the allotted time budget.So let's disable the wakeref tracking once again for the mockdevice 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 List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

eb48d421 - drm/i915: Fix oops due to missing stack depot

Wed, 26 Jan 2022 08:15:38 +0000

drm/i915: Fix oops due to missing stack depotWe call __save_depot_stack() unconditionally so the stack depotmust always be initialized or else we'll oops on platforms withoutruntime 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 # stackdepotCc: 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.comAcked-by: Vlastimil Babka Reviewed-by: Imre Deak (cherry picked from commit 751a9d69b19702af35b0fedfb8ff362027c1cf0c)Signed-off-by: Tvrtko Ursulin List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

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

Wed, 26 Jan 2022 08:15:39 +0000

drm/i915: Enable rpm wakeref tracking whether runtime pm is enabled or notDon't see why we should skip the wakeref tracking when theplatform doesn't support runtime pm. We still want all thecode to be 100% leak free so let's track this unconditionally.Cc: Vlastimil Babka Cc: Dmitry Vyukov Cc: Marco Elver # stackdepotCc: 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.comReviewed-by: Imre Deak List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

751a9d69 - drm/i915: Fix oops due to missing stack depot

Wed, 26 Jan 2022 08:15:38 +0000

drm/i915: Fix oops due to missing stack depotWe call __save_depot_stack() unconditionally so the stack depotmust always be initialized or else we'll oops on platforms withoutruntime 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 # stackdepotCc: 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.comAcked-by: Vlastimil Babka Reviewed-by: Imre Deak List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

2dba5eb1 - lib/stackdepot: allow optional init and stack_table allocation by kvmalloc()

Sat, 22 Jan 2022 06:14:27 +0000

lib/stackdepot: allow optional init and stack_table allocation by kvmalloc()Currently, enabling CONFIG_STACKDEPOT means its stack_table will beallocated from memblock, even if stack depot ends up not actually used.The default size of stack_table is 4MB on 32-bit, 8MB on 64-bit.This is fine for use-cases such as KASAN which is also a config optionand has overhead on its own. But it's an issue for functionality thathas to be actually enabled on boot (page_owner) or depends on hardware(GPU drivers) and thus the memory might be wasted. This was raised asan issue [1] when attempting to add stackdepot support for SLUB's debugobject tracking functionality. It's common to build kernels withCONFIG_SLUB_DEBUG and enable slub_debug on boot only when needed, orcreate only specific kmem caches with debugging for testing purposes.It would thus be more efficient if stackdepot's table was allocated onlywhen actually going to be used. This patch thus makes the allocation(and whole stack_depot_init() call) optional: - Add a CONFIG_STACKDEPOT_ALWAYS_INIT flag to keep using the current well-defined point of allocation as part of mem_init(). Make CONFIG_KASAN select this flag. - Other users have to call stack_depot_init() as part of their own init when it's determined that stack depot will actually be used. This may depend on both config and runtime conditions. Convert current users which are page_owner and several in the DRM subsystem. Same will be done for SLUB later. - Because the init might now be called after the boot-time memblock allocation has given all memory to the buddy allocator, change stack_depot_init() to allocate stack_table with kvmalloc() when memblock is no longer available. Also handle allocation failure by disabling stackdepot (could have theoretically happened even with memblock allocation previously), and don't unnecessarily align the memblock allocation to its own size anymore.[1] https://lore.kernel.org/all/CAMuHMdW=eoVzM1Re5FVoEN87nKfiLmM2+Ah7eNu2KXEhCvbZyA@mail.gmail.com/Link: https://lkml.kernel.org/r/20211013073005.11351-1-vbabka@suse.czSigned-off-by: Vlastimil Babka Acked-by: Dmitry Vyukov Reviewed-by: Marco Elver # stackdepotCc: Marco Elver Cc: Vijayanand Jitta Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Dmitry Vyukov Cc: Geert Uytterhoeven Cc: Oliver Glitta Cc: Imran Khan From: Colin Ian King Subject: lib/stackdepot: fix spelling mistake and grammar in pr_err messageThere is a spelling mistake of the work allocation so fix this andre-phrase the message to make it easier to read.Link: https://lkml.kernel.org/r/20211015104159.11282-1-colin.king@canonical.comSigned-off-by: Colin Ian King Cc: Vlastimil Babka From: Vlastimil Babka Subject: lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() - fixupOn FLATMEM, we call page_ext_init_flatmem_late() just beforekmem_cache_init() which means stack_depot_init() (called by page ownerinit) will not recognize properly it should use kvmalloc() and notmemblock_alloc(). memblock_alloc() will also not issue a warning andreturn a block memory that can be invalid and cause kernel page fault whensaving stacks, as reported by the kernel test robot [1].Fix this by moving page_ext_init_flatmem_late() below kmem_cache_init() sothat slab_is_available() is true during stack_depot_init(). SPARSEMEMdoesn't have this issue, as it doesn't do page_ext_init_flatmem_late(),but a different page_ext_init() even later in the boot process.Thanks to Mike Rapoport for pointing out the FLATMEM init ordering issue.While at it, also actually resolve a checkpatch warning in stack_depot_init()from DRM CI, which was supposed to be in the original patch already.[1] https://lore.kernel.org/all/20211014085450.GC18719@xsang-OptiPlex-9020/Link: https://lkml.kernel.org/r/6abd9213-19a9-6d58-cedc-2414386d2d81@suse.czSigned-off-by: Vlastimil Babka Reported-by: kernel test robot Cc: Mike Rapoport Cc: Stephen Rothwell From: Vlastimil Babka Subject: lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() - fixup3Due to cd06ab2fd48f ("drm/locking: add backtrace for locking contendedlocks without backoff") landing recently to -next adding a new stack depotuser in drivers/gpu/drm/drm_modeset_lock.c we need to add an appropriatecall to stack_depot_init() there as well.Link: https://lkml.kernel.org/r/2a692365-cfa1-64f2-34e0-8aa5674dce5e@suse.czSigned-off-by: Vlastimil Babka Cc: Jani Nikula Cc: Naresh Kamboju Cc: Marco Elver Cc: Vijayanand Jitta Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Dmitry Vyukov Cc: Geert Uytterhoeven Cc: Oliver Glitta Cc: Imran Khan Cc: Stephen Rothwell From: Vlastimil Babka Subject: lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() - fixup4Due to 4e66934eaadc ("lib: add reference counting trackinginfrastructure") landing recently to net-next adding a new stack depotuser in lib/ref_tracker.c we need to add an appropriate call tostack_depot_init() there as well.Link: https://lkml.kernel.org/r/45c1b738-1a2f-5b5f-2f6d-86fab206d01c@suse.czSigned-off-by: Vlastimil Babka Reviewed-by: Eric Dumazet Cc: Jiri Slab Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c

527bab04 - drm/i915/rpm: Enable runtime pm autosuspend by default

Tue, 16 Nov 2021 15:52:38 +0000

drm/i915/rpm: Enable runtime pm autosuspend by defaultLet's enable runtime pm autosuspend by default everywhere.So, we can allow D3hot and bigger power savings on idle scenarios.But at this time let's not touch the autosuspend_delay time,what caused some regression on our previous attempt.Also, the latest identified issue on GuC PM has been fixed bycommit 1a52faed3131 ("drm/i915/guc: Take GT PM ref when deregisteringcontext")v1: Enable runtime pm autosuspend by default for Gen12and later versions.v2: Enable runtime pm autosuspend by default for allplatforms(Syrjala Ville)v3: Change commit message(Nikula Jani)Signed-off-by: Tilak Tangudu Reviewed-by: Rodrigo Vivi Signed-off-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20211116155238.3226516-1-tilak.tangudu@intel.com List of files: /linux-6.15/drivers/gpu/drm/i915/intel_runtime_pm.c