drm/i915: fix typos in drm/i915 files

Fix all typos in files under drm/i915 reported by codespell tool.

v2: Fix commenting style. <Andi>

v3: "in case" should be capitalized and fix
comment sty

drm/i915: fix typos in drm/i915 files

Fix all typos in files under drm/i915 reported by codespell tool.

v2: Fix commenting style. <Andi>

v3: "in case" should be capitalized and fix
comment style. <Krzysztof Niemiec>

Signed-off-by: Nitin Gote <[email protected]>
Reviewed-by: Krzysztof Niemiec <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>

show more ...

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

As of commit 2edc6a75f26c ("drm/i915: switch intel_wakeref_t underlying
type to struct ref_tracker *") we gained quite a few sparse w

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

As of commit 2edc6a75f26c ("drm/i915: switch intel_wakeref_t underlying
type to struct ref_tracker *") we gained quite a few sparse warnings
about "Using plain integer as NULL pointer" for using 0 to initialize
wakeref_t. Switch to NULL everywhere.

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Chaitanya Kumar Borah <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

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

A number of places rely on the magic -1 to denote
INTEL_WAKEREF_DEF. Switch to the macro. Define it for xe as well.

Reviewed-

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

A number of places rely on the magic -1 to denote
INTEL_WAKEREF_DEF. Switch to the macro. Define it for xe as well.

Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/57e5f1989113be4d63386478d9438cfc35a2a1f7.1726680898.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <[email protected]>

show more ...

drm/i915: Convert intel_runtime_pm_get_noresume towards raw wakeref

In the past, the noresume function was used by the GEM code to ensure
wakelocks were held and bump its usage. This is no longer th

drm/i915: Convert intel_runtime_pm_get_noresume towards raw wakeref

In the past, the noresume function was used by the GEM code to ensure
wakelocks were held and bump its usage. This is no longer the case
and this function was totally unused until it started to be used again
by display with commit 77e619a82fc3 ("drm/i915/display: convert inner
wakeref get towards get_if_in_use")

However, on the display code, most of the callers are using the
raw wakeref, rather then the wakelock version. What caused a
major regression caught by CI.

Another option to this patch is to go with the original plan and
use the get_if_in_use variant in the display code, what is enough
to 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 <[email protected]>
Cc: Francois Dugast <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Fixes: 77e619a82fc3 ("drm/i915/display: convert inner wakeref get towards get_if_in_use")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10875
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Imre Deak <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

PM: runtime: Simplify pm_runtime_get_if_active() usage

There are two ways to opportunistically increment a device's runtime PM
usage count, calling either pm_runtime_get_if_active() or
pm_runtime_ge

PM: runtime: Simplify pm_runtime_get_if_active() usage

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 <[email protected]>
Reviewed-by: Alex Elder <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Acked-by: Takashi Iwai <[email protected]> # sound/
Reviewed-by: Jacek Lawrynowicz <[email protected]> # drivers/accel/ivpu/
Acked-by: Rodrigo Vivi <[email protected]> # drivers/gpu/drm/i915/
Reviewed-by: Rodrigo Vivi <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]> # drivers/pci/
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

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

Reduce the duplication.

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: http

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

Reduce the duplication.

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

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

Beside reusing existing code, the main advantage of ref_tracker is
tracking per instance of wakeref. It allows also to catc

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

Beside reusing existing code, the main advantage of ref_tracker is
tracking per instance of wakeref. It allows also to catch double
put.
On the other side we lose information about the first acquire and
the last release, but the advantages outweigh it.

Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/i915: Remove runtime suspended boolean from intel_runtime_pm struct

It's not necessary to carry separate suspended status information in
intel_runtime_pm struct as this information is already in

drm/i915: Remove runtime suspended boolean from intel_runtime_pm struct

It's not necessary to carry separate suspended status information in
intel_runtime_pm struct as this information is already in underlying device
structure. Remove it and use pm_runtime_suspended() to obtain suspended
status information when needed.

Cc: Jani Nikula <[email protected]>
Cc: Imre Deak <[email protected]>

Signed-off-by: Jouni Högander <[email protected]>
Acked-by: Jani Nikula <[email protected]>
Reviewed-by: Imre Deak <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

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

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
s

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

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 <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/ec0eb5149120d04f3d9870d7671ef10103e6fc29.1686231190.git.jani.nikula@intel.com

show more ...

drm/i915/pm: drop intel_pm_setup()

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 <ja

drm/i915/pm: drop intel_pm_setup()

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 <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/b01f9bf0afa9abaece5d0f76aecde69e2679f662.1677678803.git.jani.nikula@intel.com

show more ...

drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual

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

drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual

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 <[email protected]>
Signed-off-by: Anshuman Gupta <[email protected]>
Reviewed-by: Matthew Auld <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/i915: Encapsulate lmem rpm stuff in intel_runtime_pm

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

drm/i915: Encapsulate lmem rpm stuff in intel_runtime_pm

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 <[email protected]>
Reviewed-by: Matthew Auld <[email protected]>
Acked-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

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

DGFX platforms has lmem and cpu can access the lmem objects
via mmap and i915 internal i915_gem_object_pin_map() for
i915 own

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

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 <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Anshuman Gupta <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 66eb93e71a7a6695b7c5eb682e3ca1c980cf9d58)
Signed-off-by: Tvrtko Ursulin <[email protected]>

show more ...

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

DGFX platforms has lmem and cpu can access the lmem objects
via mmap and i915 internal i915_gem_object_pin_map() for
i915 own

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

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 <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Anshuman Gupta <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

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

commit c50df701d49e ("drm/i915: Enable rpm wakeref tracking
whether runtime pm is enabled or not") enabled wakeref trackin

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

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 <[email protected]>
Acked-by: Tomi Sarvela <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/i915: Fix oops due to missing stack depot

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.

drm/i915: Fix oops due to missing stack depot

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 <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Cc: Marco Elver <[email protected]> # stackdepot
Cc: Chris Wilson <[email protected]>
Cc: Imre Deak <[email protected]>
Fixes: 2dba5eb1c73b ("lib/stackdepot: allow optional init and stack_table allocation by kvmalloc()")
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Acked-by: Vlastimil Babka <[email protected]>
Reviewed-by: Imre Deak <[email protected]>
(cherry picked from commit 751a9d69b19702af35b0fedfb8ff362027c1cf0c)
Signed-off-by: Tvrtko Ursulin <[email protected]>

show more ...

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

Don't see why we should skip the wakeref tracking when the
platform doesn't support runtime pm. We still want all the
code

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

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 <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Cc: Marco Elver <[email protected]> # stackdepot
Cc: Chris Wilson <[email protected]>
Cc: Imre Deak <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Imre Deak <[email protected]>

show more ...

drm/i915: Fix oops due to missing stack depot

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.

drm/i915: Fix oops due to missing stack depot

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 <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Cc: Marco Elver <[email protected]> # stackdepot
Cc: Chris Wilson <[email protected]>
Cc: Imre Deak <[email protected]>
Fixes: 2dba5eb1c73b ("lib/stackdepot: allow optional init and stack_table allocation by kvmalloc()")
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Acked-by: Vlastimil Babka <[email protected]>
Reviewed-by: Imre Deak <[email protected]>

show more ...

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

Currently, enabling CONFIG_STACKDEPOT means its stack_table will be
allocated from memblock, even if stack depot ends up

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

Currently, enabling CONFIG_STACKDEPOT means its stack_table will be
allocated 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 option
and has overhead on its own. But it's an issue for functionality that
has to be actually enabled on boot (page_owner) or depends on hardware
(GPU drivers) and thus the memory might be wasted. This was raised as
an issue [1] when attempting to add stackdepot support for SLUB's debug
object tracking functionality. It's common to build kernels with
CONFIG_SLUB_DEBUG and enable slub_debug on boot only when needed, or
create only specific kmem caches with debugging for testing purposes.

It would thus be more efficient if stackdepot's table was allocated only
when 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/[email protected]
Signed-off-by: Vlastimil Babka <[email protected]>
Acked-by: Dmitry Vyukov <[email protected]>
Reviewed-by: Marco Elver <[email protected]> # stackdepot
Cc: Marco Elver <[email protected]>
Cc: Vijayanand Jitta <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Cc: Andrey Konovalov <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Oliver Glitta <[email protected]>
Cc: Imran Khan <[email protected]>
From: Colin Ian King <[email protected]>
Subject: lib/stackdepot: fix spelling mistake and grammar in pr_err message

There is a spelling mistake of the work allocation so fix this and
re-phrase the message to make it easier to read.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Colin Ian King <[email protected]>
Cc: Vlastimil Babka <[email protected]>
From: Vlastimil Babka <[email protected]>
Subject: lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() - fixup

On FLATMEM, we call page_ext_init_flatmem_late() just before
kmem_cache_init() which means stack_depot_init() (called by page owner
init) will not recognize properly it should use kvmalloc() and not
memblock_alloc(). memblock_alloc() will also not issue a warning and
return a block memory that can be invalid and cause kernel page fault when
saving stacks, as reported by the kernel test robot [1].

Fix this by moving page_ext_init_flatmem_late() below kmem_cache_init() so
that slab_is_available() is true during stack_depot_init(). SPARSEMEM
doesn'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/[email protected]
Signed-off-by: Vlastimil Babka <[email protected]>
Reported-by: kernel test robot <[email protected]>
Cc: Mike Rapoport <[email protected]>
Cc: Stephen Rothwell <[email protected]>
From: Vlastimil Babka <[email protected]>
Subject: lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() - fixup3

Due to cd06ab2fd48f ("drm/locking: add backtrace for locking contended
locks without backoff") landing recently to -next adding a new stack depot
user in drivers/gpu/drm/drm_modeset_lock.c we need to add an appropriate
call to stack_depot_init() there as well.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Vlastimil Babka <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Naresh Kamboju <[email protected]>
Cc: Marco Elver <[email protected]>
Cc: Vijayanand Jitta <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Cc: Andrey Konovalov <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Oliver Glitta <[email protected]>
Cc: Imran Khan <[email protected]>
Cc: Stephen Rothwell <[email protected]>
From: Vlastimil Babka <[email protected]>
Subject: lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() - fixup4

Due to 4e66934eaadc ("lib: add reference counting tracking
infrastructure") landing recently to net-next adding a new stack depot
user in lib/ref_tracker.c we need to add an appropriate call to
stack_depot_init() there as well.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Vlastimil Babka <[email protected]>
Reviewed-by: Eric Dumazet <[email protected]>
Cc: Jiri Slab <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

drm/i915/rpm: Enable runtime pm autosuspend by default

Let's enable runtime pm autosuspend by default everywhere.
So, we can allow D3hot and bigger power savings on idle scenarios.

But at this time

drm/i915/rpm: Enable runtime pm autosuspend by default

Let'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 by
commit 1a52faed3131 ("drm/i915/guc: Take GT PM ref when deregistering
context")

v1: Enable runtime pm autosuspend by default for Gen12
and later versions.

v2: Enable runtime pm autosuspend by default for all
platforms(Syrjala Ville)

v3: Change commit message(Nikula Jani)

Signed-off-by: Tilak Tangudu <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

lib, stackdepot: add helper to print stack entries into buffer

To print stack entries into a buffer, users of stackdepot, first get a
list of stack entries using stack_depot_fetch and then print thi

lib, stackdepot: add helper to print stack entries into buffer

To print stack entries into a buffer, users of stackdepot, first get a
list of stack entries using stack_depot_fetch and then print this list
into a buffer using stack_trace_snprint. Provide a helper in stackdepot
for this purpose. Also change above mentioned users to use this helper.

[[email protected]: fix build error]
Link: https://lkml.kernel.org/r/[email protected]
[[email protected]: export stack_depot_snprint() to modules]
Link: https://lkml.kernel.org/r/[email protected]

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Imran Khan <[email protected]>
Suggested-by: Vlastimil Babka <[email protected]>
Acked-by: Vlastimil Babka <[email protected]>
Acked-by: Jani Nikula <[email protected]> [i915]
Cc: Alexander Potapenko <[email protected]>
Cc: Andrey Konovalov <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

drm/i915: Fix docbook header for __intel_runtime_pm_get_if_active()

Fix the

Documentation/gpu/i915:22: /drivers/gpu/drm/i915/intel_runtime_pm.c:423: WARNING: Inline strong start-string without end-

drm/i915: Fix docbook header for __intel_runtime_pm_get_if_active()

Fix the

Documentation/gpu/i915:22: /drivers/gpu/drm/i915/intel_runtime_pm.c:423: WARNING: Inline strong start-string without end-string.

warning from the htmldocs build.

Fixes: 9d58aa46291d ("drm/i915: Fix the GT fence revocation runtime PM logic")
Reported-by: Stephen Rothwell <[email protected]>
Cc: Chris Wilson <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Acked-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/i915: Fix the GT fence revocation runtime PM logic

To optimize some task deferring it until runtime resume unless someone
holds a runtime PM reference (because in this case the task can be done

drm/i915: Fix the GT fence revocation runtime PM logic

To optimize some task deferring it until runtime resume unless someone
holds a runtime PM reference (because in this case the task can be done
w/o the overhead of runtime resume), we have to use the runtime PM
get-if-active logic: If the runtime PM usage count is 0 (and so
get-if-in-use would return false) the runtime suspend handler is not
necessarily called yet (it could be just pending), so the device is not
necessarily powered down, and so the runtime resume handler is not
guaranteed to be called.

The fence revocation depends on the above deferral, so add a
get-if-active helper and use it during fence revocation.

v2:
- Add code comment explaining the fence reg programming deferral logic
to i915_vma_revoke_fence(). (Chris)
- Add Cc: stable and Fixes: tags. (Chris)
- Fix the function docbook comment.

Cc: Chris Wilson <[email protected]>
Cc: <[email protected]> # v4.12+
Fixes: 181df2d458f3 ("drm/i915: Take rpm wakelock for releasing the fence on unbind")
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 9d58aa46291d4d696bb1eac3436d3118f7bf2573)
Signed-off-by: Rodrigo Vivi <[email protected]>

show more ...

drm/i915: Fix the GT fence revocation runtime PM logic

To optimize some task deferring it until runtime resume unless someone
holds a runtime PM reference (because in this case the task can be done

drm/i915: Fix the GT fence revocation runtime PM logic

To optimize some task deferring it until runtime resume unless someone
holds a runtime PM reference (because in this case the task can be done
w/o the overhead of runtime resume), we have to use the runtime PM
get-if-active logic: If the runtime PM usage count is 0 (and so
get-if-in-use would return false) the runtime suspend handler is not
necessarily called yet (it could be just pending), so the device is not
necessarily powered down, and so the runtime resume handler is not
guaranteed to be called.

The fence revocation depends on the above deferral, so add a
get-if-active helper and use it during fence revocation.

v2:
- Add code comment explaining the fence reg programming deferral logic
to i915_vma_revoke_fence(). (Chris)
- Add Cc: stable and Fixes: tags. (Chris)
- Fix the function docbook comment.

Cc: Chris Wilson <[email protected]>
Cc: <[email protected]> # v4.12+
Fixes: 181df2d458f3 ("drm/i915: Take rpm wakelock for releasing the fence on unbind")
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/i915: Remove references to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.

v6:
* also remove assignment in self

drm/i915: Remove references to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.

v6:
* also remove assignment in selftests/ in a later patch (Chris)
v5:
* remove assignment in later patch (Chris)
v3:
* rebased
v2:
* move gt/ and gvt/ changes into separate patches

Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...