2005-04-16 15:20:36 -07:00
|
|
|
/* i915_drv.c -- i830,i845,i855,i865,i915 driver -*- linux-c -*-
|
|
|
|
*/
|
2006-01-02 20:14:23 +11:00
|
|
|
/*
|
2005-06-23 22:46:46 +10:00
|
|
|
*
|
2005-04-16 15:20:36 -07:00
|
|
|
* Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas.
|
|
|
|
* All Rights Reserved.
|
2005-06-23 22:46:46 +10:00
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
* copy of this software and associated documentation files (the
|
|
|
|
* "Software"), to deal in the Software without restriction, including
|
|
|
|
* without limitation the rights to use, copy, modify, merge, publish,
|
|
|
|
* distribute, sub license, and/or sell copies of the Software, and to
|
|
|
|
* permit persons to whom the Software is furnished to do so, subject to
|
|
|
|
* the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the
|
|
|
|
* next paragraph) shall be included in all copies or substantial portions
|
|
|
|
* of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
|
|
|
|
* OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
|
|
|
|
* IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR
|
|
|
|
* ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
|
|
|
|
* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
|
|
|
|
* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
|
|
|
*
|
2006-01-02 20:14:23 +11:00
|
|
|
*/
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-09-30 15:03:05 +02:00
|
|
|
#include <linux/aperture.h>
|
2014-06-12 08:35:47 -07:00
|
|
|
#include <linux/acpi.h>
|
2016-06-24 14:00:22 +01:00
|
|
|
#include <linux/device.h>
|
2011-08-30 11:04:30 -04:00
|
|
|
#include <linux/module.h>
|
2021-11-11 12:13:02 +02:00
|
|
|
#include <linux/oom.h>
|
2016-06-24 14:00:22 +01:00
|
|
|
#include <linux/pci.h>
|
|
|
|
#include <linux/pm.h>
|
2014-05-07 19:57:49 +03:00
|
|
|
#include <linux/pm_runtime.h>
|
2016-06-24 14:00:22 +01:00
|
|
|
#include <linux/slab.h>
|
2022-02-25 15:46:30 -08:00
|
|
|
#include <linux/string_helpers.h>
|
2016-01-11 20:09:20 +01:00
|
|
|
#include <linux/vga_switcheroo.h>
|
2016-06-24 14:00:22 +01:00
|
|
|
#include <linux/vt.h>
|
|
|
|
|
2016-12-15 15:29:44 +01:00
|
|
|
#include <drm/drm_atomic_helper.h>
|
2024-12-12 18:08:42 +01:00
|
|
|
#include <drm/drm_client.h>
|
|
|
|
#include <drm/drm_client_event.h>
|
2019-01-26 13:25:24 +01:00
|
|
|
#include <drm/drm_ioctl.h>
|
2020-03-23 15:49:07 +01:00
|
|
|
#include <drm/drm_managed.h>
|
2019-01-26 13:25:24 +01:00
|
|
|
#include <drm/drm_probe_helper.h>
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2024-11-13 17:50:11 -05:00
|
|
|
#include "display/i9xx_display_sr.h"
|
2019-06-13 11:44:16 +03:00
|
|
|
#include "display/intel_bw.h"
|
|
|
|
#include "display/intel_cdclk.h"
|
2024-09-13 16:54:38 +03:00
|
|
|
#include "display/intel_crtc.h"
|
2025-05-22 12:48:43 +03:00
|
|
|
#include "display/intel_display_core.h"
|
2023-04-14 12:41:54 +03:00
|
|
|
#include "display/intel_display_driver.h"
|
2021-11-11 12:13:02 +02:00
|
|
|
#include "display/intel_dmc.h"
|
2019-06-13 11:44:15 +03:00
|
|
|
#include "display/intel_dp.h"
|
2021-11-01 20:35:51 +02:00
|
|
|
#include "display/intel_dpt.h"
|
2024-06-18 15:52:53 +03:00
|
|
|
#include "display/intel_encoder.h"
|
2024-12-12 18:08:51 +01:00
|
|
|
#include "display/intel_fbdev.h"
|
2019-06-13 11:44:16 +03:00
|
|
|
#include "display/intel_hotplug.h"
|
2025-05-22 12:48:43 +03:00
|
|
|
#include "display/intel_opregion.h"
|
2019-06-13 11:44:16 +03:00
|
|
|
#include "display/intel_overlay.h"
|
2021-10-15 10:16:17 +03:00
|
|
|
#include "display/intel_pch_refclk.h"
|
2021-01-20 12:18:32 +02:00
|
|
|
#include "display/intel_pps.h"
|
2025-05-27 13:59:07 +03:00
|
|
|
#include "display/intel_sbi.h"
|
2024-09-16 19:24:07 +03:00
|
|
|
#include "display/intel_sprite_uapi.h"
|
2022-09-08 22:16:45 +03:00
|
|
|
#include "display/skl_watermark.h"
|
2019-06-13 11:44:15 +03:00
|
|
|
|
2019-05-28 10:29:49 +01:00
|
|
|
#include "gem/i915_gem_context.h"
|
2022-02-10 17:45:42 +02:00
|
|
|
#include "gem/i915_gem_create.h"
|
2022-02-10 17:45:41 +02:00
|
|
|
#include "gem/i915_gem_dmabuf.h"
|
2019-05-28 10:29:43 +01:00
|
|
|
#include "gem/i915_gem_ioctls.h"
|
2019-12-04 12:00:32 +00:00
|
|
|
#include "gem/i915_gem_mman.h"
|
2021-01-23 14:55:43 +00:00
|
|
|
#include "gem/i915_gem_pm.h"
|
2019-06-21 08:07:41 +01:00
|
|
|
#include "gt/intel_gt.h"
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-24 21:07:17 +01:00
|
|
|
#include "gt/intel_gt_pm.h"
|
2023-10-09 11:38:02 -07:00
|
|
|
#include "gt/intel_gt_print.h"
|
2019-10-17 16:38:31 +03:00
|
|
|
#include "gt/intel_rc6.h"
|
2019-04-24 18:48:39 +01:00
|
|
|
|
drm/i915/pxp: Promote pxp subsystem to top-level of i915
Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pertaining to PXP
operation (such as creating the arbitration session and session
tear-down).
PXP as a global feature is accessible via batch buffer instructions
on any engine/tile and the coherency across tiles is handled implicitly
by the HW. In fact, for the foreseeable future, we are expecting this
single-control-tile for the PXP subsystem.
In MTL, it's the standalone media tile (not the root tile) because
it contains the VDBOX and KCR engine (among the assets PXP relies on
for those events).
Looking at the current code design, each tile is represented by the
intel_gt structure while the intel_pxp structure currently hangs off the
intel_gt structure.
Keeping the intel_pxp structure within the intel_gt structure makes some
internal functionalities more straight forward but adds code complexity to
code readability and maintainibility to many external-to-pxp subsystems
which may need to pick the correct intel_gt structure. An example of this
would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
which should be viewed as a global level inquiry, not a per-gt inquiry.
That said, this series promotes the intel_pxp structure into the
drm_i915_private structure making it a top-level subsystem and the PXP
subsystem will select the control gt internally and keep a pointer to
it for internal reference.
This promotion comes with two noteworthy changes:
1. Exported pxp functions that are called by external subsystems
(such as intel_pxp_enabled/active) will have to check implicitly
if i915->pxp is valid as that structure will not be allocated
for HW that doesn't support PXP.
2. Since GT is now considered a soft-dependency of PXP we are
ensuring that GT init happens before PXP init and vice versa
for fini. This causes a minor ordering change whereby we previously
called intel_pxp_suspend after intel_uc_suspend but now is before
i915_gem_suspend_late but the change is required for correct
dependency flows. Additionally, this re-order change doesn't
have any impact because at that point in either case, the top level
entry to i915 won't observe any PXP events (since the GPU was
quiesced during suspend_prepare). Also, any PXP event doesn't
really matter when we disable the PXP HW (global GT irqs are
already off anyway, so even if there was a bug that generated
spurious events we wouldn't see it and we would just clean it
up on resume which is okay since the default fallback action
for PXP would be to keep the sessions off at this suspend stage).
Changes from prior revs:
v11: - Reformat a comment (Tvrtko).
v10: - Change the code flow for intel_pxp_init to make it more
cleaner and readible with better comments explaining the
difference between full-PXP-feature vs the partial-teelink
inits depending on the platform. Additionally, only do
the pxp allocation when we are certain the subsystem is
needed. (Tvrtko).
v9: - Cosmetic cleanups in supported/enabled/active. (Daniele).
- Add comments for intel_pxp_init and pxp_get_ctrl_gt that
explain the functional flow for when PXP is not supported
but the backend-assets are needed for HuC authentication
(Daniele and Tvrtko).
- Fix two remaining functions that are accessible outside
PXP that need to be checking pxp ptrs before using them:
intel_pxp_irq_handler and intel_pxp_huc_load_and_auth
(Tvrtko and Daniele).
- User helper macro in pxp-debugfs (Tvrtko).
v8: - Remove pxp_to_gt macro (Daniele).
- Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't
support GSC-FW on it. (Daniele).
- Leave i915->pxp as NULL if we dont support PXP and in line
with that, do additional validity check on i915->pxp for
intel_pxp_is_supported/enabled/active (Daniele).
- Remove unncessary include header from intel_gt_debugfs.c
and check drm_minor i915->drm.primary (Daniele).
- Other cosmetics / minor issues / more comments on suspend
flow order change (Daniele).
v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
through out instead of local variable newpxp. (Rodrigo)
- In the case intel_pxp_fini is called during driver unload but
after i915 loading failed without pxp being allocated, check
i915->pxp before referencing it. (Alan)
v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
because : [1] introduction of 'ctrl_gt' means we correct this
for MTL's upcoming series now. [2] Also, this has little impact
globally as its only used by PXP-internal callers at the moment.
- Change intel_pxp_init/fini to take in i915 as its input to avoid
ptr-to-ptr in init/fini calls.(Jani).
- Remove the backpointer from pxp->i915 since we can use
pxp->ctrl_gt->i915 if we need it. (Rodrigo).
v5: - Switch from series to single patch (Rodrigo).
- change function name from pxp_get_kcr_owner_gt to
pxp_get_ctrl_gt.
- Fix CI BAT failure by removing redundant call to intel_pxp_fini
from driver-remove.
- NOTE: remaining open still persists on using ptr-to-ptr
and back-ptr.
v4: - Instead of maintaining intel_pxp as an intel_gt structure member
and creating a number of convoluted helpers that takes in i915 as
input and redirects to the correct intel_gt or takes any intel_gt
and internally replaces with the correct intel_gt, promote it to
be a top-level i915 structure.
v3: - Rename gt level helper functions to "intel_pxp_is_enabled/
supported/ active_on_gt" (Daniele)
- Upgrade _gt_supports_pxp to replace what was intel_gtpxp_is
supported as the new intel_pxp_is_supported_on_gt to check for
PXP feature support vs the tee support for huc authentication.
Fix pxp-debugfs-registration to use only the former to decide
support. (Daniele)
- Couple minor optimizations.
v2: - Avoid introduction of new device info or gt variables and use
existing checks / macros to differentiate the correct GT->PXP
control ownership (Daniele Ceraolo Spurio)
- Don't reuse the updated global-checkers for per-GT callers (such
as other files within PXP) to avoid unnecessary GT-reparsing,
expose a replacement helper like the prior ones. (Daniele).
v1: - Add one more patch to the series for the intel_pxp suspend/resume
for similar refactoring
References: https://patchwork.freedesktop.org/patch/msgid/20221202011407.4068371-1-alan.previn.teres.alexis@intel.com
Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221208180542.998148-1-alan.previn.teres.alexis@intel.com
2022-12-08 10:05:42 -08:00
|
|
|
#include "pxp/intel_pxp.h"
|
|
|
|
#include "pxp/intel_pxp_debugfs.h"
|
2021-09-24 12:14:47 -07:00
|
|
|
#include "pxp/intel_pxp_pm.h"
|
|
|
|
|
2022-12-08 16:23:47 +02:00
|
|
|
#include "soc/intel_dram.h"
|
2023-01-17 14:33:07 +02:00
|
|
|
#include "soc/intel_gmch.h"
|
2022-12-08 16:23:47 +02:00
|
|
|
|
2019-05-02 18:02:43 +03:00
|
|
|
#include "i915_debugfs.h"
|
2021-11-11 12:13:02 +02:00
|
|
|
#include "i915_driver.h"
|
2022-04-01 15:21:58 +01:00
|
|
|
#include "i915_drm_client.h"
|
2016-06-24 14:00:22 +01:00
|
|
|
#include "i915_drv.h"
|
2023-04-03 15:24:27 +03:00
|
|
|
#include "i915_file_private.h"
|
2022-01-07 15:20:43 +02:00
|
|
|
#include "i915_getparam.h"
|
2022-10-13 08:45:20 -07:00
|
|
|
#include "i915_hwmon.h"
|
2020-02-27 19:00:45 +02:00
|
|
|
#include "i915_ioc32.h"
|
2022-01-20 13:33:46 +02:00
|
|
|
#include "i915_ioctl.h"
|
2019-04-29 15:29:27 +03:00
|
|
|
#include "i915_irq.h"
|
2019-08-08 16:42:47 +03:00
|
|
|
#include "i915_memcpy.h"
|
2019-08-08 16:42:44 +03:00
|
|
|
#include "i915_perf.h"
|
2018-03-06 12:28:56 +00:00
|
|
|
#include "i915_query.h"
|
2024-12-11 17:29:52 +05:30
|
|
|
#include "i915_reg.h"
|
2019-10-04 15:20:18 +03:00
|
|
|
#include "i915_switcheroo.h"
|
2019-08-08 16:42:45 +03:00
|
|
|
#include "i915_sysfs.h"
|
2022-03-29 10:02:04 +01:00
|
|
|
#include "i915_utils.h"
|
2016-06-24 14:00:22 +01:00
|
|
|
#include "i915_vgpu.h"
|
2023-04-03 15:24:27 +03:00
|
|
|
#include "intel_clock_gating.h"
|
2024-12-11 17:29:52 +05:30
|
|
|
#include "intel_cpu_info.h"
|
2020-02-27 16:44:08 +02:00
|
|
|
#include "intel_gvt.h"
|
2019-10-26 21:20:32 +01:00
|
|
|
#include "intel_memory_region.h"
|
2022-01-10 11:57:37 +02:00
|
|
|
#include "intel_pci_config.h"
|
2021-10-14 13:28:57 +03:00
|
|
|
#include "intel_pcode.h"
|
2021-06-02 10:38:08 +02:00
|
|
|
#include "intel_region_ttm.h"
|
2025-05-12 17:56:52 +03:00
|
|
|
#include "vlv_iosf_sb.h"
|
2020-02-12 16:40:57 +02:00
|
|
|
#include "vlv_suspend.h"
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-07 14:24:08 -08:00
|
|
|
|
2021-11-11 12:13:03 +02:00
|
|
|
static const struct drm_driver i915_drm_driver;
|
2009-01-04 16:55:33 -05:00
|
|
|
|
2016-06-24 14:00:22 +01:00
|
|
|
static int i915_workqueues_init(struct drm_i915_private *dev_priv)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* The i915 workqueue is primarily used for batched retirement of
|
|
|
|
* requests (and thus managing bo) once the task has been completed
|
2018-02-21 09:56:36 +00:00
|
|
|
* by the GPU. i915_retire_requests() is called directly when we
|
2016-06-24 14:00:22 +01:00
|
|
|
* need high-priority retirement, such as waiting for an explicit
|
|
|
|
* bo.
|
|
|
|
*
|
|
|
|
* It is also used for periodic low-priority events, such as
|
|
|
|
* idle-timers and recording error state.
|
|
|
|
*
|
|
|
|
* All tasks on the workqueue are expected to acquire the dev mutex
|
|
|
|
* so there is no point in running more than one instance of the
|
|
|
|
* workqueue at any time. Use an ordered one.
|
|
|
|
*/
|
|
|
|
dev_priv->wq = alloc_ordered_workqueue("i915", 0);
|
|
|
|
if (dev_priv->wq == NULL)
|
|
|
|
goto out_err;
|
|
|
|
|
2023-06-08 16:35:45 +03:00
|
|
|
/*
|
|
|
|
* The unordered i915 workqueue should be used for all work
|
|
|
|
* scheduling that do not require running in order, which used
|
|
|
|
* to be scheduled on the system_wq before moving to a driver
|
|
|
|
* instance due deprecation of flush_scheduled_work().
|
|
|
|
*/
|
|
|
|
dev_priv->unordered_wq = alloc_workqueue("i915-unordered", 0, 0);
|
|
|
|
if (dev_priv->unordered_wq == NULL)
|
2025-05-16 15:16:57 +03:00
|
|
|
goto out_free_wq;
|
2023-06-08 16:35:45 +03:00
|
|
|
|
2016-06-24 14:00:22 +01:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
out_free_wq:
|
|
|
|
destroy_workqueue(dev_priv->wq);
|
|
|
|
out_err:
|
drm/i915: conversion to drm_device logging macros when drm_i915_private is present.
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Instances of the DRM_DEBUG macro were not converted due to lack of a
consensus of an analogous struct drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
2020-01-31 12:34:12 +03:00
|
|
|
drm_err(&dev_priv->drm, "Failed to allocate workqueues.\n");
|
2016-06-24 14:00:22 +01:00
|
|
|
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void i915_workqueues_cleanup(struct drm_i915_private *dev_priv)
|
|
|
|
{
|
2023-06-08 16:35:45 +03:00
|
|
|
destroy_workqueue(dev_priv->unordered_wq);
|
2016-06-24 14:00:22 +01:00
|
|
|
destroy_workqueue(dev_priv->wq);
|
|
|
|
}
|
|
|
|
|
2016-09-26 15:07:52 +03:00
|
|
|
/*
|
|
|
|
* We don't keep the workarounds for pre-production hardware, so we expect our
|
|
|
|
* driver to fail on these machines in one way or another. A little warning on
|
|
|
|
* dmesg may help both the user and the bug triagers.
|
2017-11-17 10:26:35 +00:00
|
|
|
*
|
|
|
|
* Our policy for removing pre-production workarounds is to keep the
|
|
|
|
* current gen workarounds as a guide to the bring-up of the next gen
|
|
|
|
* (workarounds have a habit of persisting!). Anything older than that
|
|
|
|
* should be removed along with the complications they introduce.
|
2016-09-26 15:07:52 +03:00
|
|
|
*/
|
|
|
|
static void intel_detect_preproduction_hw(struct drm_i915_private *dev_priv)
|
|
|
|
{
|
2017-01-30 10:44:56 +00:00
|
|
|
bool pre = false;
|
|
|
|
|
2023-08-01 19:23:31 +05:30
|
|
|
pre |= IS_HASWELL_EARLY_SDV(dev_priv);
|
2021-07-13 12:36:25 -07:00
|
|
|
pre |= IS_SKYLAKE(dev_priv) && INTEL_REVID(dev_priv) < 0x6;
|
|
|
|
pre |= IS_BROXTON(dev_priv) && INTEL_REVID(dev_priv) < 0xA;
|
|
|
|
pre |= IS_KABYLAKE(dev_priv) && INTEL_REVID(dev_priv) < 0x1;
|
|
|
|
pre |= IS_GEMINILAKE(dev_priv) && INTEL_REVID(dev_priv) < 0x3;
|
2021-07-13 12:36:30 -07:00
|
|
|
pre |= IS_ICELAKE(dev_priv) && INTEL_REVID(dev_priv) < 0x7;
|
2023-01-27 14:43:11 -08:00
|
|
|
pre |= IS_TIGERLAKE(dev_priv) && INTEL_REVID(dev_priv) < 0x1;
|
2023-01-27 14:43:12 -08:00
|
|
|
pre |= IS_DG1(dev_priv) && INTEL_REVID(dev_priv) < 0x1;
|
2023-08-16 14:42:03 -07:00
|
|
|
pre |= IS_DG2_G10(dev_priv) && INTEL_REVID(dev_priv) < 0x8;
|
|
|
|
pre |= IS_DG2_G11(dev_priv) && INTEL_REVID(dev_priv) < 0x5;
|
|
|
|
pre |= IS_DG2_G12(dev_priv) && INTEL_REVID(dev_priv) < 0x1;
|
2017-01-30 10:44:56 +00:00
|
|
|
|
2017-01-30 10:44:57 +00:00
|
|
|
if (pre) {
|
drm/i915: conversion to drm_device logging macros when drm_i915_private is present.
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Instances of the DRM_DEBUG macro were not converted due to lack of a
consensus of an analogous struct drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
2020-01-31 12:34:12 +03:00
|
|
|
drm_err(&dev_priv->drm, "This is a pre-production stepping. "
|
2016-09-26 15:07:52 +03:00
|
|
|
"It may not be fully functional.\n");
|
2017-01-30 10:44:57 +00:00
|
|
|
add_taint(TAINT_MACHINE_CHECK, LOCKDEP_STILL_OK);
|
|
|
|
}
|
2016-09-26 15:07:52 +03:00
|
|
|
}
|
|
|
|
|
2019-12-28 11:12:55 +00:00
|
|
|
static void sanitize_gpu(struct drm_i915_private *i915)
|
|
|
|
{
|
2025-03-03 13:27:05 +02:00
|
|
|
if (!intel_gt_gpu_reset_clobbers_display(to_gt(i915))) {
|
2022-09-06 16:49:29 -07:00
|
|
|
struct intel_gt *gt;
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
for_each_gt(gt, i915, i)
|
2024-04-22 22:19:50 +02:00
|
|
|
intel_gt_reset_all_engines(gt);
|
2022-09-06 16:49:29 -07:00
|
|
|
}
|
2019-12-28 11:12:55 +00:00
|
|
|
}
|
|
|
|
|
2016-06-24 14:00:22 +01:00
|
|
|
/**
|
2019-07-12 13:24:30 +02:00
|
|
|
* i915_driver_early_probe - setup state not requiring device access
|
2016-06-24 14:00:22 +01:00
|
|
|
* @dev_priv: device private
|
|
|
|
*
|
|
|
|
* Initialize everything that is a "SW-only" state, that is state not
|
|
|
|
* requiring accessing the device or exposing the driver via kernel internal
|
|
|
|
* or userspace interfaces. Example steps belonging here: lock initialization,
|
|
|
|
* system memory allocation, setting up device specific attributes and
|
|
|
|
* function hooks not requiring accessing the device.
|
|
|
|
*/
|
2019-07-12 13:24:30 +02:00
|
|
|
static int i915_driver_early_probe(struct drm_i915_private *dev_priv)
|
2016-06-24 14:00:22 +01:00
|
|
|
{
|
2025-05-07 18:22:54 +03:00
|
|
|
struct intel_display *display = dev_priv->display;
|
2016-06-24 14:00:22 +01:00
|
|
|
int ret = 0;
|
|
|
|
|
2019-08-02 18:40:50 +00:00
|
|
|
if (i915_inject_probe_failure(dev_priv))
|
2016-06-24 14:00:22 +01:00
|
|
|
return -ENODEV;
|
|
|
|
|
2022-09-15 18:46:46 -07:00
|
|
|
intel_device_info_runtime_init_early(dev_priv);
|
|
|
|
|
2021-03-26 15:21:34 +02:00
|
|
|
intel_step_init(dev_priv);
|
2019-03-27 14:23:28 +00:00
|
|
|
|
2022-09-06 16:49:22 -07:00
|
|
|
intel_uncore_mmio_debug_init_early(dev_priv);
|
2019-04-02 13:10:31 -07:00
|
|
|
|
2016-06-24 14:00:22 +01:00
|
|
|
spin_lock_init(&dev_priv->gpu_error.lock);
|
2017-02-03 21:18:25 -05:00
|
|
|
|
2025-05-27 13:59:08 +03:00
|
|
|
intel_sbi_init(display);
|
2024-10-29 11:25:25 +02:00
|
|
|
vlv_iosf_sb_init(dev_priv);
|
2016-06-24 14:00:22 +01:00
|
|
|
mutex_init(&dev_priv->sb_lock);
|
2019-04-26 09:17:18 +01:00
|
|
|
|
2016-08-12 12:39:59 +01:00
|
|
|
i915_memcpy_init_early(dev_priv);
|
2019-06-13 16:21:53 -07:00
|
|
|
intel_runtime_pm_init_early(&dev_priv->runtime_pm);
|
2016-08-12 12:39:59 +01:00
|
|
|
|
2016-06-24 14:00:22 +01:00
|
|
|
ret = i915_workqueues_init(dev_priv);
|
|
|
|
if (ret < 0)
|
2019-07-18 08:00:10 +01:00
|
|
|
return ret;
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2020-02-12 16:40:57 +02:00
|
|
|
ret = vlv_suspend_init(dev_priv);
|
2019-08-19 19:01:46 -07:00
|
|
|
if (ret < 0)
|
|
|
|
goto err_workqueues;
|
|
|
|
|
2021-06-02 10:38:08 +02:00
|
|
|
ret = intel_region_ttm_device_init(dev_priv);
|
|
|
|
if (ret)
|
|
|
|
goto err_ttm;
|
|
|
|
|
2022-09-06 16:49:33 -07:00
|
|
|
ret = intel_root_gt_init_early(dev_priv);
|
|
|
|
if (ret < 0)
|
|
|
|
goto err_rootgt;
|
2019-06-21 08:07:41 +01:00
|
|
|
|
2019-09-27 18:33:49 +01:00
|
|
|
i915_gem_init_early(dev_priv);
|
2018-03-23 12:34:49 +00:00
|
|
|
|
2016-06-24 14:00:22 +01:00
|
|
|
intel_irq_init(dev_priv);
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_early_probe(display);
|
2023-04-03 15:24:27 +03:00
|
|
|
intel_clock_gating_hooks_init(dev_priv);
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2016-09-26 15:07:52 +03:00
|
|
|
intel_detect_preproduction_hw(dev_priv);
|
2016-06-24 14:00:22 +01:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
2022-09-06 16:49:33 -07:00
|
|
|
err_rootgt:
|
2021-06-02 10:38:08 +02:00
|
|
|
intel_region_ttm_device_fini(dev_priv);
|
|
|
|
err_ttm:
|
2020-02-12 16:40:57 +02:00
|
|
|
vlv_suspend_cleanup(dev_priv);
|
2019-08-19 19:01:46 -07:00
|
|
|
err_workqueues:
|
2016-06-24 14:00:22 +01:00
|
|
|
i915_workqueues_cleanup(dev_priv);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2019-07-12 13:24:28 +02:00
|
|
|
* i915_driver_late_release - cleanup the setup done in
|
2019-07-12 13:24:30 +02:00
|
|
|
* i915_driver_early_probe()
|
2016-06-24 14:00:22 +01:00
|
|
|
* @dev_priv: device private
|
|
|
|
*/
|
2019-07-12 13:24:28 +02:00
|
|
|
static void i915_driver_late_release(struct drm_i915_private *dev_priv)
|
2016-06-24 14:00:22 +01:00
|
|
|
{
|
2025-05-07 18:22:54 +03:00
|
|
|
struct intel_display *display = dev_priv->display;
|
2024-11-28 17:38:23 +02:00
|
|
|
|
2017-04-28 10:58:39 +03:00
|
|
|
intel_irq_fini(dev_priv);
|
2024-11-28 17:38:23 +02:00
|
|
|
intel_power_domains_cleanup(display);
|
2018-03-23 12:34:49 +00:00
|
|
|
i915_gem_cleanup_early(dev_priv);
|
2022-03-19 01:39:33 +02:00
|
|
|
intel_gt_driver_late_release_all(dev_priv);
|
2021-06-02 10:38:08 +02:00
|
|
|
intel_region_ttm_device_fini(dev_priv);
|
2020-02-12 16:40:57 +02:00
|
|
|
vlv_suspend_cleanup(dev_priv);
|
2016-06-24 14:00:22 +01:00
|
|
|
i915_workqueues_cleanup(dev_priv);
|
2019-04-26 09:17:18 +01:00
|
|
|
|
|
|
|
mutex_destroy(&dev_priv->sb_lock);
|
2024-10-29 11:25:25 +02:00
|
|
|
vlv_iosf_sb_fini(dev_priv);
|
2025-05-27 13:59:08 +03:00
|
|
|
intel_sbi_fini(display);
|
2020-06-18 18:04:02 +03:00
|
|
|
|
|
|
|
i915_params_free(&dev_priv->params);
|
2025-05-22 12:48:42 +03:00
|
|
|
|
|
|
|
intel_display_device_remove(display);
|
2016-06-24 14:00:22 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2019-07-12 13:24:30 +02:00
|
|
|
* i915_driver_mmio_probe - setup device MMIO
|
2016-06-24 14:00:22 +01:00
|
|
|
* @dev_priv: device private
|
|
|
|
*
|
|
|
|
* Setup minimal device state necessary for MMIO accesses later in the
|
|
|
|
* initialization sequence. The setup here should avoid any other device-wide
|
|
|
|
* side effects or exposing the driver via kernel internal or user space
|
|
|
|
* interfaces.
|
|
|
|
*/
|
2019-07-12 13:24:30 +02:00
|
|
|
static int i915_driver_mmio_probe(struct drm_i915_private *dev_priv)
|
2016-06-24 14:00:22 +01:00
|
|
|
{
|
2025-05-07 18:22:54 +03:00
|
|
|
struct intel_display *display = dev_priv->display;
|
2022-09-06 16:49:28 -07:00
|
|
|
struct intel_gt *gt;
|
|
|
|
int ret, i;
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2019-08-02 18:40:50 +00:00
|
|
|
if (i915_inject_probe_failure(dev_priv))
|
2016-06-24 14:00:22 +01:00
|
|
|
return -ENODEV;
|
|
|
|
|
2023-01-17 14:33:07 +02:00
|
|
|
ret = intel_gmch_bridge_setup(dev_priv);
|
2021-09-30 14:24:35 +03:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2022-09-06 16:49:28 -07:00
|
|
|
for_each_gt(gt, dev_priv, i) {
|
|
|
|
ret = intel_uncore_init_mmio(gt->uncore);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = drmm_add_action_or_reset(&dev_priv->drm,
|
|
|
|
intel_uncore_fini_mmio,
|
|
|
|
gt->uncore);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2021-10-28 20:28:09 -07:00
|
|
|
|
2019-03-19 11:35:40 -07:00
|
|
|
/* Try to make sure MCHBAR is enabled before poking at it */
|
2023-01-17 14:33:07 +02:00
|
|
|
intel_gmch_bar_setup(dev_priv);
|
2021-01-04 11:51:41 +00:00
|
|
|
intel_device_info_runtime_init(dev_priv);
|
2024-11-11 12:34:02 +02:00
|
|
|
intel_display_device_info_runtime_init(display);
|
2017-04-28 10:53:36 +03:00
|
|
|
|
2022-09-06 16:49:28 -07:00
|
|
|
for_each_gt(gt, dev_priv, i) {
|
|
|
|
ret = intel_gt_init_mmio(gt);
|
|
|
|
if (ret)
|
|
|
|
goto err_uncore;
|
|
|
|
}
|
2017-04-28 10:53:36 +03:00
|
|
|
|
2019-12-28 11:12:55 +00:00
|
|
|
/* As early as possible, scrub existing GPU state before clobbering */
|
|
|
|
sanitize_gpu(dev_priv);
|
|
|
|
|
2016-06-24 14:00:22 +01:00
|
|
|
return 0;
|
|
|
|
|
2017-04-28 10:53:36 +03:00
|
|
|
err_uncore:
|
2023-01-17 14:33:07 +02:00
|
|
|
intel_gmch_bar_teardown(dev_priv);
|
2016-06-24 14:00:22 +01:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2019-07-12 13:24:30 +02:00
|
|
|
* i915_driver_mmio_release - cleanup the setup done in i915_driver_mmio_probe()
|
2016-06-24 14:00:22 +01:00
|
|
|
* @dev_priv: device private
|
|
|
|
*/
|
2019-07-12 13:24:28 +02:00
|
|
|
static void i915_driver_mmio_release(struct drm_i915_private *dev_priv)
|
2016-06-24 14:00:22 +01:00
|
|
|
{
|
2023-01-17 14:33:07 +02:00
|
|
|
intel_gmch_bar_teardown(dev_priv);
|
2016-06-24 14:00:22 +01:00
|
|
|
}
|
|
|
|
|
2020-04-17 15:51:07 -04:00
|
|
|
/**
|
|
|
|
* i915_set_dma_info - set all relevant PCI dma info as configured for the
|
|
|
|
* platform
|
|
|
|
* @i915: valid i915 instance
|
|
|
|
*
|
|
|
|
* Set the dma max segment size, device and coherent masks. The dma mask set
|
|
|
|
* needs to occur before i915_ggtt_probe_hw.
|
|
|
|
*
|
|
|
|
* A couple of platforms have special needs. Address them as well.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
static int i915_set_dma_info(struct drm_i915_private *i915)
|
|
|
|
{
|
|
|
|
unsigned int mask_size = INTEL_INFO(i915)->dma_mask_size;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
GEM_BUG_ON(!mask_size);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't have a max segment size, so set it to the max so sg's
|
|
|
|
* debugging layer doesn't complain
|
|
|
|
*/
|
2021-01-28 14:31:23 +01:00
|
|
|
dma_set_max_seg_size(i915->drm.dev, UINT_MAX);
|
2020-04-17 15:51:07 -04:00
|
|
|
|
2021-01-28 14:31:23 +01:00
|
|
|
ret = dma_set_mask(i915->drm.dev, DMA_BIT_MASK(mask_size));
|
2020-04-17 15:51:07 -04:00
|
|
|
if (ret)
|
|
|
|
goto mask_err;
|
|
|
|
|
|
|
|
/* overlay on gen2 is broken and can't address above 1G */
|
2021-06-05 21:50:49 -07:00
|
|
|
if (GRAPHICS_VER(i915) == 2)
|
2020-04-17 15:51:07 -04:00
|
|
|
mask_size = 30;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 965GM sometimes incorrectly writes to hardware status page (HWS)
|
|
|
|
* using 32bit addressing, overwriting memory if HWS is located
|
|
|
|
* above 4GB.
|
|
|
|
*
|
|
|
|
* The documentation also mentions an issue with undefined
|
|
|
|
* behaviour if any general state is accessed within a page above 4GB,
|
|
|
|
* which also needs to be handled carefully.
|
|
|
|
*/
|
|
|
|
if (IS_I965G(i915) || IS_I965GM(i915))
|
|
|
|
mask_size = 32;
|
|
|
|
|
2021-01-28 14:31:23 +01:00
|
|
|
ret = dma_set_coherent_mask(i915->drm.dev, DMA_BIT_MASK(mask_size));
|
2020-04-17 15:51:07 -04:00
|
|
|
if (ret)
|
|
|
|
goto mask_err;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
mask_err:
|
|
|
|
drm_err(&i915->drm, "Can't set DMA mask/consistent mask (%d)\n", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2024-12-11 17:29:52 +05:30
|
|
|
/* Wa_14022698537:dg2 */
|
|
|
|
static void i915_enable_g8(struct drm_i915_private *i915)
|
|
|
|
{
|
|
|
|
if (IS_DG2(i915)) {
|
|
|
|
if (IS_DG2_D(i915) && !intel_match_g8_cpu())
|
|
|
|
return;
|
|
|
|
|
|
|
|
snb_pcode_write_p(&i915->uncore, PCODE_POWER_SETUP,
|
|
|
|
POWER_SETUP_SUBCOMMAND_G8_ENABLE, 0, 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-05-25 06:19:18 -07:00
|
|
|
static int i915_pcode_init(struct drm_i915_private *i915)
|
|
|
|
{
|
|
|
|
struct intel_gt *gt;
|
|
|
|
int id, ret;
|
|
|
|
|
|
|
|
for_each_gt(gt, i915, id) {
|
|
|
|
ret = intel_pcode_init(gt->uncore);
|
|
|
|
if (ret) {
|
2023-10-09 11:38:02 -07:00
|
|
|
gt_err(gt, "intel_pcode_init failed %d\n", ret);
|
2022-05-25 06:19:18 -07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-12-11 17:29:52 +05:30
|
|
|
i915_enable_g8(i915);
|
2022-05-25 06:19:18 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-06-24 14:00:22 +01:00
|
|
|
/**
|
2019-07-12 13:24:30 +02:00
|
|
|
* i915_driver_hw_probe - setup state requiring device access
|
2016-06-24 14:00:22 +01:00
|
|
|
* @dev_priv: device private
|
|
|
|
*
|
|
|
|
* Setup state that requires accessing the device, but doesn't require
|
|
|
|
* exposing the driver via kernel internal or userspace interfaces.
|
|
|
|
*/
|
2019-07-12 13:24:30 +02:00
|
|
|
static int i915_driver_hw_probe(struct drm_i915_private *dev_priv)
|
2016-06-24 14:00:22 +01:00
|
|
|
{
|
2025-05-07 18:22:54 +03:00
|
|
|
struct intel_display *display = dev_priv->display;
|
2021-01-28 14:31:23 +01:00
|
|
|
struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
|
2016-06-24 14:00:22 +01:00
|
|
|
int ret;
|
|
|
|
|
2019-08-02 18:40:50 +00:00
|
|
|
if (i915_inject_probe_failure(dev_priv))
|
2016-06-24 14:00:22 +01:00
|
|
|
return -ENODEV;
|
|
|
|
|
2018-09-26 21:12:22 +01:00
|
|
|
if (HAS_PPGTT(dev_priv)) {
|
|
|
|
if (intel_vgpu_active(dev_priv) &&
|
2019-03-14 22:38:35 +00:00
|
|
|
!intel_vgpu_has_full_ppgtt(dev_priv)) {
|
2024-08-06 16:38:31 +03:00
|
|
|
drm_err(&dev_priv->drm,
|
|
|
|
"incompatible vGPU found, support for isolated ppGTT required\n");
|
2018-09-26 21:12:22 +01:00
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-11-30 12:59:54 +00:00
|
|
|
if (HAS_EXECLISTS(dev_priv)) {
|
|
|
|
/*
|
|
|
|
* Older GVT emulation depends upon intercepting CSB mmio,
|
|
|
|
* which we no longer use, preferring to use the HWSP cache
|
|
|
|
* instead.
|
|
|
|
*/
|
|
|
|
if (intel_vgpu_active(dev_priv) &&
|
|
|
|
!intel_vgpu_has_hwsp_emulation(dev_priv)) {
|
2024-08-06 16:38:31 +03:00
|
|
|
drm_err(&dev_priv->drm,
|
|
|
|
"old vGPU host found, support for HWSP emulation required\n");
|
2018-11-30 12:59:54 +00:00
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-03-28 10:45:32 -07:00
|
|
|
/* needs to be done before ggtt probe */
|
2020-02-25 13:15:07 +02:00
|
|
|
intel_dram_edram_detect(dev_priv);
|
2019-03-28 10:45:32 -07:00
|
|
|
|
2020-04-17 15:51:07 -04:00
|
|
|
ret = i915_set_dma_info(dev_priv);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2023-03-23 15:58:55 -07:00
|
|
|
ret = i915_perf_init(dev_priv);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2017-10-27 15:59:31 +01:00
|
|
|
|
2016-08-04 07:52:22 +01:00
|
|
|
ret = i915_ggtt_probe_hw(dev_priv);
|
2016-06-24 14:00:22 +01:00
|
|
|
if (ret)
|
2018-04-14 10:12:33 +01:00
|
|
|
goto err_perf;
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2024-09-30 15:03:05 +02:00
|
|
|
ret = aperture_remove_conflicting_pci_devices(pdev, dev_priv->drm.driver->name);
|
2019-08-22 11:06:45 +02:00
|
|
|
if (ret)
|
2018-04-14 10:12:33 +01:00
|
|
|
goto err_ggtt;
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2016-08-04 07:52:22 +01:00
|
|
|
ret = i915_ggtt_init_hw(dev_priv);
|
2016-08-04 07:52:21 +01:00
|
|
|
if (ret)
|
2018-04-14 10:12:33 +01:00
|
|
|
goto err_ggtt;
|
2016-08-04 07:52:21 +01:00
|
|
|
|
2023-01-27 16:03:21 +00:00
|
|
|
/*
|
|
|
|
* Make sure we probe lmem before we probe stolen-lmem. The BAR size
|
|
|
|
* might be different due to bar resizing.
|
|
|
|
*/
|
|
|
|
ret = intel_gt_tiles_init(dev_priv);
|
2019-10-26 21:20:32 +01:00
|
|
|
if (ret)
|
|
|
|
goto err_ggtt;
|
|
|
|
|
2023-01-27 16:03:21 +00:00
|
|
|
ret = intel_memory_regions_hw_probe(dev_priv);
|
2021-01-27 13:14:10 +00:00
|
|
|
if (ret)
|
2023-01-27 16:03:21 +00:00
|
|
|
goto err_ggtt;
|
2021-01-27 13:14:10 +00:00
|
|
|
|
2016-08-04 07:52:22 +01:00
|
|
|
ret = i915_ggtt_enable_hw(dev_priv);
|
2016-08-04 07:52:21 +01:00
|
|
|
if (ret) {
|
drm/i915: conversion to drm_device logging macros when drm_i915_private is present.
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Instances of the DRM_DEBUG macro were not converted due to lack of a
consensus of an analogous struct drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
2020-01-31 12:34:12 +03:00
|
|
|
drm_err(&dev_priv->drm, "failed to enable GGTT\n");
|
2019-10-26 21:20:32 +01:00
|
|
|
goto err_mem_regions;
|
2016-08-04 07:52:21 +01:00
|
|
|
}
|
|
|
|
|
2016-08-22 13:32:44 +03:00
|
|
|
pci_set_master(pdev);
|
2016-06-24 14:00:22 +01:00
|
|
|
|
|
|
|
/* On the 945G/GM, the chipset reports the MSI capability on the
|
|
|
|
* integrated graphics even though the support isn't actually there
|
|
|
|
* according to the published specs. It doesn't appear to function
|
|
|
|
* correctly in testing on 945G.
|
|
|
|
* This may be a side effect of MSI having been made available for PEG
|
|
|
|
* and the registers being closely associated.
|
|
|
|
*
|
|
|
|
* According to chipset errata, on the 965GM, MSI interrupts may
|
2017-06-26 23:30:51 +03:00
|
|
|
* be lost or delayed, and was defeatured. MSI interrupts seem to
|
|
|
|
* get lost on g4x as well, and interrupt delivery seems to stay
|
|
|
|
* properly dead afterwards. So we'll just disable them for all
|
|
|
|
* pre-gen5 chipsets.
|
2018-05-23 11:04:35 -07:00
|
|
|
*
|
|
|
|
* dp aux and gmbus irq on gen4 seems to be able to generate legacy
|
|
|
|
* interrupts even when in MSI mode. This results in spurious
|
|
|
|
* interrupt warnings if the legacy irq no. is shared with another
|
|
|
|
* device. The kernel then disables that interrupt source and so
|
|
|
|
* prevents the other device from working properly.
|
2016-06-24 14:00:22 +01:00
|
|
|
*/
|
2021-06-05 21:50:49 -07:00
|
|
|
if (GRAPHICS_VER(dev_priv) >= 5) {
|
2016-08-22 13:32:44 +03:00
|
|
|
if (pci_enable_msi(pdev) < 0)
|
drm/i915: conversion to drm_device logging macros when drm_i915_private is present.
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Instances of the DRM_DEBUG macro were not converted due to lack of a
consensus of an analogous struct drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
2020-01-31 12:34:12 +03:00
|
|
|
drm_dbg(&dev_priv->drm, "can't enable MSI");
|
2016-06-24 14:00:22 +01:00
|
|
|
}
|
|
|
|
|
2017-01-13 10:46:09 +08:00
|
|
|
ret = intel_gvt_init(dev_priv);
|
|
|
|
if (ret)
|
2018-07-10 15:38:21 +01:00
|
|
|
goto err_msi;
|
|
|
|
|
2024-08-09 17:27:05 +03:00
|
|
|
intel_opregion_setup(display);
|
2021-01-28 08:43:11 -08:00
|
|
|
|
2022-05-25 06:19:18 -07:00
|
|
|
ret = i915_pcode_init(dev_priv);
|
2021-07-27 23:03:38 +05:30
|
|
|
if (ret)
|
2023-03-08 18:25:02 +02:00
|
|
|
goto err_opregion;
|
2021-01-28 08:43:11 -08:00
|
|
|
|
2018-08-24 15:02:21 +05:30
|
|
|
/*
|
2021-01-28 08:43:10 -08:00
|
|
|
* Fill the dram structure to get the system dram info. This will be
|
|
|
|
* used for memory latency calculation.
|
2018-08-24 15:02:21 +05:30
|
|
|
*/
|
2025-05-27 12:25:25 +03:00
|
|
|
ret = intel_dram_detect(dev_priv);
|
|
|
|
if (ret)
|
|
|
|
goto err_opregion;
|
2018-08-24 15:02:21 +05:30
|
|
|
|
2025-03-11 14:04:51 -03:00
|
|
|
intel_bw_init_hw(display);
|
2017-01-13 10:46:09 +08:00
|
|
|
|
2016-06-24 14:00:22 +01:00
|
|
|
return 0;
|
|
|
|
|
2023-03-08 18:25:02 +02:00
|
|
|
err_opregion:
|
2024-08-09 17:27:05 +03:00
|
|
|
intel_opregion_cleanup(display);
|
2018-07-10 15:38:21 +01:00
|
|
|
err_msi:
|
|
|
|
if (pdev->msi_enabled)
|
|
|
|
pci_disable_msi(pdev);
|
2019-10-26 21:20:32 +01:00
|
|
|
err_mem_regions:
|
|
|
|
intel_memory_regions_driver_release(dev_priv);
|
2018-04-14 10:12:33 +01:00
|
|
|
err_ggtt:
|
2019-07-12 13:24:28 +02:00
|
|
|
i915_ggtt_driver_release(dev_priv);
|
2021-06-01 09:46:41 +02:00
|
|
|
i915_gem_drain_freed_objects(dev_priv);
|
|
|
|
i915_ggtt_driver_late_release(dev_priv);
|
2018-04-14 10:12:33 +01:00
|
|
|
err_perf:
|
|
|
|
i915_perf_fini(dev_priv);
|
2016-06-24 14:00:22 +01:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2019-07-12 13:24:29 +02:00
|
|
|
* i915_driver_hw_remove - cleanup the setup done in i915_driver_hw_probe()
|
2016-06-24 14:00:22 +01:00
|
|
|
* @dev_priv: device private
|
|
|
|
*/
|
2019-07-12 13:24:29 +02:00
|
|
|
static void i915_driver_hw_remove(struct drm_i915_private *dev_priv)
|
2016-06-24 14:00:22 +01:00
|
|
|
{
|
2025-05-07 18:22:54 +03:00
|
|
|
struct intel_display *display = dev_priv->display;
|
2021-01-28 14:31:23 +01:00
|
|
|
struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2017-10-27 15:59:31 +01:00
|
|
|
i915_perf_fini(dev_priv);
|
|
|
|
|
2024-08-09 17:27:05 +03:00
|
|
|
intel_opregion_cleanup(display);
|
2023-03-08 18:25:02 +02:00
|
|
|
|
2016-08-22 13:32:44 +03:00
|
|
|
if (pdev->msi_enabled)
|
|
|
|
pci_disable_msi(pdev);
|
2016-06-24 14:00:22 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* i915_driver_register - register the driver with the rest of the system
|
|
|
|
* @dev_priv: device private
|
|
|
|
*
|
|
|
|
* Perform any steps necessary to make the driver available via kernel
|
|
|
|
* internal or userspace interfaces.
|
|
|
|
*/
|
drm/i915: Fix harmful driver register/unregister asymmetry
Starting with commit ec3e00b4ee27 ("drm/i915: stop registering if
drm_dev_register() fails"), we return from i915_driver_register()
immediately if drm_dev_register() fails, skipping remaining registration
steps, and continue only with remaining probe steps. However, the
_unregister() counterpart called at driver remove knows nothing about that
skip and executes reverts of all those steps. As a consequence, a number
of kernel warnings that taint the kernel are triggered:
<3> [525.823143] i915 0000:00:02.0: [drm] *ERROR* Failed to register driver for userspace access!
...
<4> [525.831069] ------------[ cut here ]------------
<4> [525.831071] i915 0000:00:02.0: [drm] drm_WARN_ON(power_domains->init_wakeref)
<4> [525.831095] WARNING: CPU: 6 PID: 3440 at drivers/gpu/drm/i915/display/intel_display_power.c:2074 intel_power_domains_disable+0xc2/0xd0 [i915]
...
<4> [525.831328] CPU: 6 UID: 0 PID: 3440 Comm: i915_module_loa Tainted: G U 6.14.0-rc1-CI_DRM_16076-g7a632b6798b6+ #1
...
<4> [525.831334] RIP: 0010:intel_power_domains_disable+0xc2/0xd0 [i915]
...
<4> [525.831483] Call Trace:
<4> [525.831484] <TASK>
...
<4> [525.831943] i915_driver_remove+0x4b/0x140 [i915]
<4> [525.832028] i915_pci_remove+0x1e/0x40 [i915]
<4> [525.832099] pci_device_remove+0x3e/0xb0
<4> [525.832103] device_remove+0x40/0x80
<4> [525.832107] device_release_driver_internal+0x215/0x280
...
Moreover, that unexpected PM reference is left untouched (not released)
but overwritten, then that triggers another kernel warning at driver
release phase:
<4> [526.685700] ------------[ cut here ]------------
<4> [526.685706] i915 0000:00:02.0: [drm] i915 raw-wakerefs=1 wakelocks=1 on cleanup
<4> [526.685734] WARNING: CPU: 1 PID: 3440 at drivers/gpu/drm/i915/intel_runtime_pm.c:443 intel_runtime_pm_driver_release+0x75/0x90 [i915]
...
<4> [526.686090] RIP: 0010:intel_runtime_pm_driver_release+0x75/0x90 [i915]
...
<4> [526.686294] Call Trace:
<4> [526.686296] <TASK>
...
<4> [526.687025] i915_driver_release+0x7e/0xb0 [i915]
<4> [526.687243] drm_dev_put.part.0+0x47/0x90
<4> [526.687250] devm_drm_dev_init_release+0x13/0x30
<4> [526.687255] devm_action_release+0x12/0x30
<4> [526.687261] release_nodes+0x3a/0x120
<4> [526.687268] devres_release_all+0x97/0xe0
<4> [526.687277] device_unbind_cleanup+0x12/0x80
<4> [526.687282] device_release_driver_internal+0x23a/0x280
...
A call to intel_power_domains_disable() was already there. It triggers
the drm_WARN_ON() when it finds a reference to a wakeref taken on device
probe and not released after device registration failure. That wakeref is
then left held forever once its handle gets lost overwritten with another
wakeref, hence another WARN() is called from
intel_runtime_pm_driver_release().
The WARN() triggered by kernfs_remove_by_name_ns() from
i915_teardown_sysfs()->i915_gpu_error_sysfs_teardown(), formerly
i915_teardown_error_capture(), was also there when the return was added.
A call to intel_gt_sysfs_unregister() that triggers the WARN() from
kobject_put() was added to intel_gt_driver_unregister() with commit
69d6bf5c3754ff ("drm/i915/gt: Fix memory leaks in per-gt sysfs").
Fix the asymmetry by failing the driver probe on device registration
failure and going through rewind paths.
For that to work as expected, we apparently need to start the rewind path
of i915_driver_register() with drm_dev_unregister(), even if
drm_dev_register() returned an error.
v5: Drop unsigned keyword from ret variable declaration (Krzysztof),
- keep the "Failed to register driver for userspace access" error
message (Krzysztof),
- split PXP cleanup addition to rewind path out to a separate patch.
v4: Switch to taking an error rewind path on device registration failure
(Krzysztof, Lucas).
v3: Based on Andi's commitment on introducing a flag, try to address
Jani's "must find another way" by finding a better place and name for
the flag (in hope that's what Jani had on mind),
- split into a series of patches and limit the scope of the first (this)
one to a minimum of omitting conditionally only those unregister
(sub)steps that trigger kernel warnings when not registered.
v2: Check in _unregister whether the drm_dev_register has succeeded and
skip some of the _unregister() steps. (Andi)
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10047
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10131
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10887
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12817
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250314205202.809563-8-janusz.krzysztofik@linux.intel.com
2025-03-14 21:38:35 +01:00
|
|
|
static int i915_driver_register(struct drm_i915_private *dev_priv)
|
2016-06-24 14:00:22 +01:00
|
|
|
{
|
2025-05-07 18:22:54 +03:00
|
|
|
struct intel_display *display = dev_priv->display;
|
2022-09-06 16:49:29 -07:00
|
|
|
struct intel_gt *gt;
|
|
|
|
unsigned int i;
|
drm/i915: Fix harmful driver register/unregister asymmetry
Starting with commit ec3e00b4ee27 ("drm/i915: stop registering if
drm_dev_register() fails"), we return from i915_driver_register()
immediately if drm_dev_register() fails, skipping remaining registration
steps, and continue only with remaining probe steps. However, the
_unregister() counterpart called at driver remove knows nothing about that
skip and executes reverts of all those steps. As a consequence, a number
of kernel warnings that taint the kernel are triggered:
<3> [525.823143] i915 0000:00:02.0: [drm] *ERROR* Failed to register driver for userspace access!
...
<4> [525.831069] ------------[ cut here ]------------
<4> [525.831071] i915 0000:00:02.0: [drm] drm_WARN_ON(power_domains->init_wakeref)
<4> [525.831095] WARNING: CPU: 6 PID: 3440 at drivers/gpu/drm/i915/display/intel_display_power.c:2074 intel_power_domains_disable+0xc2/0xd0 [i915]
...
<4> [525.831328] CPU: 6 UID: 0 PID: 3440 Comm: i915_module_loa Tainted: G U 6.14.0-rc1-CI_DRM_16076-g7a632b6798b6+ #1
...
<4> [525.831334] RIP: 0010:intel_power_domains_disable+0xc2/0xd0 [i915]
...
<4> [525.831483] Call Trace:
<4> [525.831484] <TASK>
...
<4> [525.831943] i915_driver_remove+0x4b/0x140 [i915]
<4> [525.832028] i915_pci_remove+0x1e/0x40 [i915]
<4> [525.832099] pci_device_remove+0x3e/0xb0
<4> [525.832103] device_remove+0x40/0x80
<4> [525.832107] device_release_driver_internal+0x215/0x280
...
Moreover, that unexpected PM reference is left untouched (not released)
but overwritten, then that triggers another kernel warning at driver
release phase:
<4> [526.685700] ------------[ cut here ]------------
<4> [526.685706] i915 0000:00:02.0: [drm] i915 raw-wakerefs=1 wakelocks=1 on cleanup
<4> [526.685734] WARNING: CPU: 1 PID: 3440 at drivers/gpu/drm/i915/intel_runtime_pm.c:443 intel_runtime_pm_driver_release+0x75/0x90 [i915]
...
<4> [526.686090] RIP: 0010:intel_runtime_pm_driver_release+0x75/0x90 [i915]
...
<4> [526.686294] Call Trace:
<4> [526.686296] <TASK>
...
<4> [526.687025] i915_driver_release+0x7e/0xb0 [i915]
<4> [526.687243] drm_dev_put.part.0+0x47/0x90
<4> [526.687250] devm_drm_dev_init_release+0x13/0x30
<4> [526.687255] devm_action_release+0x12/0x30
<4> [526.687261] release_nodes+0x3a/0x120
<4> [526.687268] devres_release_all+0x97/0xe0
<4> [526.687277] device_unbind_cleanup+0x12/0x80
<4> [526.687282] device_release_driver_internal+0x23a/0x280
...
A call to intel_power_domains_disable() was already there. It triggers
the drm_WARN_ON() when it finds a reference to a wakeref taken on device
probe and not released after device registration failure. That wakeref is
then left held forever once its handle gets lost overwritten with another
wakeref, hence another WARN() is called from
intel_runtime_pm_driver_release().
The WARN() triggered by kernfs_remove_by_name_ns() from
i915_teardown_sysfs()->i915_gpu_error_sysfs_teardown(), formerly
i915_teardown_error_capture(), was also there when the return was added.
A call to intel_gt_sysfs_unregister() that triggers the WARN() from
kobject_put() was added to intel_gt_driver_unregister() with commit
69d6bf5c3754ff ("drm/i915/gt: Fix memory leaks in per-gt sysfs").
Fix the asymmetry by failing the driver probe on device registration
failure and going through rewind paths.
For that to work as expected, we apparently need to start the rewind path
of i915_driver_register() with drm_dev_unregister(), even if
drm_dev_register() returned an error.
v5: Drop unsigned keyword from ret variable declaration (Krzysztof),
- keep the "Failed to register driver for userspace access" error
message (Krzysztof),
- split PXP cleanup addition to rewind path out to a separate patch.
v4: Switch to taking an error rewind path on device registration failure
(Krzysztof, Lucas).
v3: Based on Andi's commitment on introducing a flag, try to address
Jani's "must find another way" by finding a better place and name for
the flag (in hope that's what Jani had on mind),
- split into a series of patches and limit the scope of the first (this)
one to a minimum of omitting conditionally only those unregister
(sub)steps that trigger kernel warnings when not registered.
v2: Check in _unregister whether the drm_dev_register has succeeded and
skip some of the _unregister() steps. (Andi)
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10047
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10131
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10887
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12817
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250314205202.809563-8-janusz.krzysztofik@linux.intel.com
2025-03-14 21:38:35 +01:00
|
|
|
int ret;
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2019-08-06 13:42:59 +01:00
|
|
|
i915_gem_driver_register(dev_priv);
|
drm/i915/pmu: Expose a PMU interface for perf queries
From: Chris Wilson <chris@chris-wilson.co.uk>
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
From: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
The first goal is to be able to measure GPU (and invidual ring) busyness
without having to poll registers from userspace. (Which not only incurs
holding the forcewake lock indefinitely, perturbing the system, but also
runs the risk of hanging the machine.) As an alternative we can use the
perf event counter interface to sample the ring registers periodically
and send those results to userspace.
Functionality we are exporting to userspace is via the existing perf PMU
API and can be exercised via the existing tools. For example:
perf stat -a -e i915/rcs0-busy/ -I 1000
Will print the render engine busynnes once per second. All the performance
counters can be enumerated (perf list) and have their unit of measure
correctly reported in sysfs.
v1-v2 (Chris Wilson):
v2: Use a common timer for the ring sampling.
v3: (Tvrtko Ursulin)
* Decouple uAPI from i915 engine ids.
* Complete uAPI defines.
* Refactor some code to helpers for clarity.
* Skip sampling disabled engines.
* Expose counters in sysfs.
* Pass in fake regs to avoid null ptr deref in perf core.
* Convert to class/instance uAPI.
* Use shared driver code for rc6 residency, power and frequency.
v4: (Dmitry Rogozhkin)
* Register PMU with .task_ctx_nr=perf_invalid_context
* Expose cpumask for the PMU with the single CPU in the mask
* Properly support pmu->stop(): it should call pmu->read()
* Properly support pmu->del(): it should call stop(event, PERF_EF_UPDATE)
* Introduce refcounting of event subscriptions.
* Make pmu.busy_stats a refcounter to avoid busy stats going away
with some deleted event.
* Expose cpumask for i915 PMU to avoid multiple events creation of
the same type followed by counter aggregation by perf-stat.
* Track CPUs getting online/offline to migrate perf context. If (likely)
cpumask will initially set CPU0, CONFIG_BOOTPARAM_HOTPLUG_CPU0 will be
needed to see effect of CPU status tracking.
* End result is that only global events are supported and perf stat
works correctly.
* Deny perf driver level sampling - it is prohibited for uncore PMU.
v5: (Tvrtko Ursulin)
* Don't hardcode number of engine samplers.
* Rewrite event ref-counting for correctness and simplicity.
* Store initial counter value when starting already enabled events
to correctly report values to all listeners.
* Fix RC6 residency readout.
* Comments, GPL header.
v6:
* Add missing entry to v4 changelog.
* Fix accounting in CPU hotplug case by copying the approach from
arch/x86/events/intel/cstate.c. (Dmitry Rogozhkin)
v7:
* Log failure message only on failure.
* Remove CPU hotplug notification state on unregister.
v8:
* Fix error unwind on failed registration.
* Checkpatch cleanup.
v9:
* Drop the energy metric, it is available via intel_rapl_perf.
(Ville Syrjälä)
* Use HAS_RC6(p). (Chris Wilson)
* Handle unsupported non-engine events. (Dmitry Rogozhkin)
* Rebase for intel_rc6_residency_ns needing caller managed
runtime pm.
* Drop HAS_RC6 checks from the read callback since creating those
events will be rejected at init time already.
* Add counter units to sysfs so perf stat output is nicer.
* Cleanup the attribute tables for brevity and readability.
v10:
* Fixed queued accounting.
v11:
* Move intel_engine_lookup_user to intel_engine_cs.c
* Commit update. (Joonas Lahtinen)
v12:
* More accurate sampling. (Chris Wilson)
* Store and report frequency in MHz for better usability from
perf stat.
* Removed metrics: queued, interrupts, rc6 counters.
* Sample engine busyness based on seqno difference only
for less MMIO (and forcewake) on all platforms. (Chris Wilson)
v13:
* Comment spelling, use mul_u32_u32 to work around potential GCC
issue and somne code alignment changes. (Chris Wilson)
v14:
* Rebase.
v15:
* Rebase for RPS refactoring.
v16:
* Use the dynamic slot in the CPU hotplug state machine so that we are
free to setup our state as multi-instance. Previously we were re-using
the CPUHP_AP_PERF_X86_UNCORE_ONLINE slot which is neither used as
multi-instance, nor owned by our driver to start with.
* Register the CPU hotplug handlers after the PMU, otherwise the callback
will get called before the PMU is initialized which can end up in
perf_pmu_migrate_context with an un-initialized base.
* Added workaround for a probable bug in cpuhp core.
v17:
* Remove workaround for the cpuhp bug.
v18:
* Rebase for drm_i915_gem_engine_class getting upstream before us.
v19:
* Rebase. (trivial)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171121181852.16128-2-tvrtko.ursulin@linux.intel.com
2017-11-21 18:18:45 +00:00
|
|
|
i915_pmu_register(dev_priv);
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2020-02-27 16:44:06 +02:00
|
|
|
intel_vgpu_register(dev_priv);
|
2016-06-24 14:00:22 +01:00
|
|
|
|
|
|
|
/* Reveal our presence to userspace */
|
drm/i915: Fix harmful driver register/unregister asymmetry
Starting with commit ec3e00b4ee27 ("drm/i915: stop registering if
drm_dev_register() fails"), we return from i915_driver_register()
immediately if drm_dev_register() fails, skipping remaining registration
steps, and continue only with remaining probe steps. However, the
_unregister() counterpart called at driver remove knows nothing about that
skip and executes reverts of all those steps. As a consequence, a number
of kernel warnings that taint the kernel are triggered:
<3> [525.823143] i915 0000:00:02.0: [drm] *ERROR* Failed to register driver for userspace access!
...
<4> [525.831069] ------------[ cut here ]------------
<4> [525.831071] i915 0000:00:02.0: [drm] drm_WARN_ON(power_domains->init_wakeref)
<4> [525.831095] WARNING: CPU: 6 PID: 3440 at drivers/gpu/drm/i915/display/intel_display_power.c:2074 intel_power_domains_disable+0xc2/0xd0 [i915]
...
<4> [525.831328] CPU: 6 UID: 0 PID: 3440 Comm: i915_module_loa Tainted: G U 6.14.0-rc1-CI_DRM_16076-g7a632b6798b6+ #1
...
<4> [525.831334] RIP: 0010:intel_power_domains_disable+0xc2/0xd0 [i915]
...
<4> [525.831483] Call Trace:
<4> [525.831484] <TASK>
...
<4> [525.831943] i915_driver_remove+0x4b/0x140 [i915]
<4> [525.832028] i915_pci_remove+0x1e/0x40 [i915]
<4> [525.832099] pci_device_remove+0x3e/0xb0
<4> [525.832103] device_remove+0x40/0x80
<4> [525.832107] device_release_driver_internal+0x215/0x280
...
Moreover, that unexpected PM reference is left untouched (not released)
but overwritten, then that triggers another kernel warning at driver
release phase:
<4> [526.685700] ------------[ cut here ]------------
<4> [526.685706] i915 0000:00:02.0: [drm] i915 raw-wakerefs=1 wakelocks=1 on cleanup
<4> [526.685734] WARNING: CPU: 1 PID: 3440 at drivers/gpu/drm/i915/intel_runtime_pm.c:443 intel_runtime_pm_driver_release+0x75/0x90 [i915]
...
<4> [526.686090] RIP: 0010:intel_runtime_pm_driver_release+0x75/0x90 [i915]
...
<4> [526.686294] Call Trace:
<4> [526.686296] <TASK>
...
<4> [526.687025] i915_driver_release+0x7e/0xb0 [i915]
<4> [526.687243] drm_dev_put.part.0+0x47/0x90
<4> [526.687250] devm_drm_dev_init_release+0x13/0x30
<4> [526.687255] devm_action_release+0x12/0x30
<4> [526.687261] release_nodes+0x3a/0x120
<4> [526.687268] devres_release_all+0x97/0xe0
<4> [526.687277] device_unbind_cleanup+0x12/0x80
<4> [526.687282] device_release_driver_internal+0x23a/0x280
...
A call to intel_power_domains_disable() was already there. It triggers
the drm_WARN_ON() when it finds a reference to a wakeref taken on device
probe and not released after device registration failure. That wakeref is
then left held forever once its handle gets lost overwritten with another
wakeref, hence another WARN() is called from
intel_runtime_pm_driver_release().
The WARN() triggered by kernfs_remove_by_name_ns() from
i915_teardown_sysfs()->i915_gpu_error_sysfs_teardown(), formerly
i915_teardown_error_capture(), was also there when the return was added.
A call to intel_gt_sysfs_unregister() that triggers the WARN() from
kobject_put() was added to intel_gt_driver_unregister() with commit
69d6bf5c3754ff ("drm/i915/gt: Fix memory leaks in per-gt sysfs").
Fix the asymmetry by failing the driver probe on device registration
failure and going through rewind paths.
For that to work as expected, we apparently need to start the rewind path
of i915_driver_register() with drm_dev_unregister(), even if
drm_dev_register() returned an error.
v5: Drop unsigned keyword from ret variable declaration (Krzysztof),
- keep the "Failed to register driver for userspace access" error
message (Krzysztof),
- split PXP cleanup addition to rewind path out to a separate patch.
v4: Switch to taking an error rewind path on device registration failure
(Krzysztof, Lucas).
v3: Based on Andi's commitment on introducing a flag, try to address
Jani's "must find another way" by finding a better place and name for
the flag (in hope that's what Jani had on mind),
- split into a series of patches and limit the scope of the first (this)
one to a minimum of omitting conditionally only those unregister
(sub)steps that trigger kernel warnings when not registered.
v2: Check in _unregister whether the drm_dev_register has succeeded and
skip some of the _unregister() steps. (Andi)
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10047
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10131
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10887
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12817
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250314205202.809563-8-janusz.krzysztofik@linux.intel.com
2025-03-14 21:38:35 +01:00
|
|
|
ret = drm_dev_register(&dev_priv->drm, 0);
|
|
|
|
if (ret) {
|
2025-03-14 21:38:33 +01:00
|
|
|
i915_probe_error(dev_priv,
|
|
|
|
"Failed to register driver for userspace access!\n");
|
drm/i915: Fix harmful driver register/unregister asymmetry
Starting with commit ec3e00b4ee27 ("drm/i915: stop registering if
drm_dev_register() fails"), we return from i915_driver_register()
immediately if drm_dev_register() fails, skipping remaining registration
steps, and continue only with remaining probe steps. However, the
_unregister() counterpart called at driver remove knows nothing about that
skip and executes reverts of all those steps. As a consequence, a number
of kernel warnings that taint the kernel are triggered:
<3> [525.823143] i915 0000:00:02.0: [drm] *ERROR* Failed to register driver for userspace access!
...
<4> [525.831069] ------------[ cut here ]------------
<4> [525.831071] i915 0000:00:02.0: [drm] drm_WARN_ON(power_domains->init_wakeref)
<4> [525.831095] WARNING: CPU: 6 PID: 3440 at drivers/gpu/drm/i915/display/intel_display_power.c:2074 intel_power_domains_disable+0xc2/0xd0 [i915]
...
<4> [525.831328] CPU: 6 UID: 0 PID: 3440 Comm: i915_module_loa Tainted: G U 6.14.0-rc1-CI_DRM_16076-g7a632b6798b6+ #1
...
<4> [525.831334] RIP: 0010:intel_power_domains_disable+0xc2/0xd0 [i915]
...
<4> [525.831483] Call Trace:
<4> [525.831484] <TASK>
...
<4> [525.831943] i915_driver_remove+0x4b/0x140 [i915]
<4> [525.832028] i915_pci_remove+0x1e/0x40 [i915]
<4> [525.832099] pci_device_remove+0x3e/0xb0
<4> [525.832103] device_remove+0x40/0x80
<4> [525.832107] device_release_driver_internal+0x215/0x280
...
Moreover, that unexpected PM reference is left untouched (not released)
but overwritten, then that triggers another kernel warning at driver
release phase:
<4> [526.685700] ------------[ cut here ]------------
<4> [526.685706] i915 0000:00:02.0: [drm] i915 raw-wakerefs=1 wakelocks=1 on cleanup
<4> [526.685734] WARNING: CPU: 1 PID: 3440 at drivers/gpu/drm/i915/intel_runtime_pm.c:443 intel_runtime_pm_driver_release+0x75/0x90 [i915]
...
<4> [526.686090] RIP: 0010:intel_runtime_pm_driver_release+0x75/0x90 [i915]
...
<4> [526.686294] Call Trace:
<4> [526.686296] <TASK>
...
<4> [526.687025] i915_driver_release+0x7e/0xb0 [i915]
<4> [526.687243] drm_dev_put.part.0+0x47/0x90
<4> [526.687250] devm_drm_dev_init_release+0x13/0x30
<4> [526.687255] devm_action_release+0x12/0x30
<4> [526.687261] release_nodes+0x3a/0x120
<4> [526.687268] devres_release_all+0x97/0xe0
<4> [526.687277] device_unbind_cleanup+0x12/0x80
<4> [526.687282] device_release_driver_internal+0x23a/0x280
...
A call to intel_power_domains_disable() was already there. It triggers
the drm_WARN_ON() when it finds a reference to a wakeref taken on device
probe and not released after device registration failure. That wakeref is
then left held forever once its handle gets lost overwritten with another
wakeref, hence another WARN() is called from
intel_runtime_pm_driver_release().
The WARN() triggered by kernfs_remove_by_name_ns() from
i915_teardown_sysfs()->i915_gpu_error_sysfs_teardown(), formerly
i915_teardown_error_capture(), was also there when the return was added.
A call to intel_gt_sysfs_unregister() that triggers the WARN() from
kobject_put() was added to intel_gt_driver_unregister() with commit
69d6bf5c3754ff ("drm/i915/gt: Fix memory leaks in per-gt sysfs").
Fix the asymmetry by failing the driver probe on device registration
failure and going through rewind paths.
For that to work as expected, we apparently need to start the rewind path
of i915_driver_register() with drm_dev_unregister(), even if
drm_dev_register() returned an error.
v5: Drop unsigned keyword from ret variable declaration (Krzysztof),
- keep the "Failed to register driver for userspace access" error
message (Krzysztof),
- split PXP cleanup addition to rewind path out to a separate patch.
v4: Switch to taking an error rewind path on device registration failure
(Krzysztof, Lucas).
v3: Based on Andi's commitment on introducing a flag, try to address
Jani's "must find another way" by finding a better place and name for
the flag (in hope that's what Jani had on mind),
- split into a series of patches and limit the scope of the first (this)
one to a minimum of omitting conditionally only those unregister
(sub)steps that trigger kernel warnings when not registered.
v2: Check in _unregister whether the drm_dev_register has succeeded and
skip some of the _unregister() steps. (Andi)
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10047
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10131
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10887
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12817
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250314205202.809563-8-janusz.krzysztofik@linux.intel.com
2025-03-14 21:38:35 +01:00
|
|
|
drm_dev_unregister(&dev_priv->drm);
|
|
|
|
i915_pmu_unregister(dev_priv);
|
|
|
|
i915_gem_driver_unregister(dev_priv);
|
|
|
|
return ret;
|
2016-06-24 14:00:22 +01:00
|
|
|
}
|
|
|
|
|
2021-02-12 20:27:53 -08:00
|
|
|
i915_debugfs_register(dev_priv);
|
|
|
|
i915_setup_sysfs(dev_priv);
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2021-02-12 20:27:53 -08:00
|
|
|
/* Depends on sysfs having been initialized */
|
|
|
|
i915_perf_register(dev_priv);
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2022-09-06 16:49:29 -07:00
|
|
|
for_each_gt(gt, dev_priv, i)
|
|
|
|
intel_gt_driver_register(gt);
|
2017-11-28 11:01:47 +00:00
|
|
|
|
drm/i915/pxp: Promote pxp subsystem to top-level of i915
Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pertaining to PXP
operation (such as creating the arbitration session and session
tear-down).
PXP as a global feature is accessible via batch buffer instructions
on any engine/tile and the coherency across tiles is handled implicitly
by the HW. In fact, for the foreseeable future, we are expecting this
single-control-tile for the PXP subsystem.
In MTL, it's the standalone media tile (not the root tile) because
it contains the VDBOX and KCR engine (among the assets PXP relies on
for those events).
Looking at the current code design, each tile is represented by the
intel_gt structure while the intel_pxp structure currently hangs off the
intel_gt structure.
Keeping the intel_pxp structure within the intel_gt structure makes some
internal functionalities more straight forward but adds code complexity to
code readability and maintainibility to many external-to-pxp subsystems
which may need to pick the correct intel_gt structure. An example of this
would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
which should be viewed as a global level inquiry, not a per-gt inquiry.
That said, this series promotes the intel_pxp structure into the
drm_i915_private structure making it a top-level subsystem and the PXP
subsystem will select the control gt internally and keep a pointer to
it for internal reference.
This promotion comes with two noteworthy changes:
1. Exported pxp functions that are called by external subsystems
(such as intel_pxp_enabled/active) will have to check implicitly
if i915->pxp is valid as that structure will not be allocated
for HW that doesn't support PXP.
2. Since GT is now considered a soft-dependency of PXP we are
ensuring that GT init happens before PXP init and vice versa
for fini. This causes a minor ordering change whereby we previously
called intel_pxp_suspend after intel_uc_suspend but now is before
i915_gem_suspend_late but the change is required for correct
dependency flows. Additionally, this re-order change doesn't
have any impact because at that point in either case, the top level
entry to i915 won't observe any PXP events (since the GPU was
quiesced during suspend_prepare). Also, any PXP event doesn't
really matter when we disable the PXP HW (global GT irqs are
already off anyway, so even if there was a bug that generated
spurious events we wouldn't see it and we would just clean it
up on resume which is okay since the default fallback action
for PXP would be to keep the sessions off at this suspend stage).
Changes from prior revs:
v11: - Reformat a comment (Tvrtko).
v10: - Change the code flow for intel_pxp_init to make it more
cleaner and readible with better comments explaining the
difference between full-PXP-feature vs the partial-teelink
inits depending on the platform. Additionally, only do
the pxp allocation when we are certain the subsystem is
needed. (Tvrtko).
v9: - Cosmetic cleanups in supported/enabled/active. (Daniele).
- Add comments for intel_pxp_init and pxp_get_ctrl_gt that
explain the functional flow for when PXP is not supported
but the backend-assets are needed for HuC authentication
(Daniele and Tvrtko).
- Fix two remaining functions that are accessible outside
PXP that need to be checking pxp ptrs before using them:
intel_pxp_irq_handler and intel_pxp_huc_load_and_auth
(Tvrtko and Daniele).
- User helper macro in pxp-debugfs (Tvrtko).
v8: - Remove pxp_to_gt macro (Daniele).
- Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't
support GSC-FW on it. (Daniele).
- Leave i915->pxp as NULL if we dont support PXP and in line
with that, do additional validity check on i915->pxp for
intel_pxp_is_supported/enabled/active (Daniele).
- Remove unncessary include header from intel_gt_debugfs.c
and check drm_minor i915->drm.primary (Daniele).
- Other cosmetics / minor issues / more comments on suspend
flow order change (Daniele).
v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
through out instead of local variable newpxp. (Rodrigo)
- In the case intel_pxp_fini is called during driver unload but
after i915 loading failed without pxp being allocated, check
i915->pxp before referencing it. (Alan)
v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
because : [1] introduction of 'ctrl_gt' means we correct this
for MTL's upcoming series now. [2] Also, this has little impact
globally as its only used by PXP-internal callers at the moment.
- Change intel_pxp_init/fini to take in i915 as its input to avoid
ptr-to-ptr in init/fini calls.(Jani).
- Remove the backpointer from pxp->i915 since we can use
pxp->ctrl_gt->i915 if we need it. (Rodrigo).
v5: - Switch from series to single patch (Rodrigo).
- change function name from pxp_get_kcr_owner_gt to
pxp_get_ctrl_gt.
- Fix CI BAT failure by removing redundant call to intel_pxp_fini
from driver-remove.
- NOTE: remaining open still persists on using ptr-to-ptr
and back-ptr.
v4: - Instead of maintaining intel_pxp as an intel_gt structure member
and creating a number of convoluted helpers that takes in i915 as
input and redirects to the correct intel_gt or takes any intel_gt
and internally replaces with the correct intel_gt, promote it to
be a top-level i915 structure.
v3: - Rename gt level helper functions to "intel_pxp_is_enabled/
supported/ active_on_gt" (Daniele)
- Upgrade _gt_supports_pxp to replace what was intel_gtpxp_is
supported as the new intel_pxp_is_supported_on_gt to check for
PXP feature support vs the tee support for huc authentication.
Fix pxp-debugfs-registration to use only the former to decide
support. (Daniele)
- Couple minor optimizations.
v2: - Avoid introduction of new device info or gt variables and use
existing checks / macros to differentiate the correct GT->PXP
control ownership (Daniele Ceraolo Spurio)
- Don't reuse the updated global-checkers for per-GT callers (such
as other files within PXP) to avoid unnecessary GT-reparsing,
expose a replacement helper like the prior ones. (Daniele).
v1: - Add one more patch to the series for the intel_pxp suspend/resume
for similar refactoring
References: https://patchwork.freedesktop.org/patch/msgid/20221202011407.4068371-1-alan.previn.teres.alexis@intel.com
Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221208180542.998148-1-alan.previn.teres.alexis@intel.com
2022-12-08 10:05:42 -08:00
|
|
|
intel_pxp_debugfs_register(dev_priv->pxp);
|
|
|
|
|
2022-10-13 08:45:20 -07:00
|
|
|
i915_hwmon_register(dev_priv);
|
|
|
|
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_register(display);
|
2018-08-16 15:37:56 +03:00
|
|
|
|
2024-11-28 17:38:23 +02:00
|
|
|
intel_power_domains_enable(display);
|
2019-06-13 16:21:53 -07:00
|
|
|
intel_runtime_pm_enable(&dev_priv->runtime_pm);
|
2020-02-11 18:28:01 +02:00
|
|
|
|
|
|
|
if (i915_switcheroo_register(dev_priv))
|
|
|
|
drm_err(&dev_priv->drm, "Failed to register vga switcheroo!\n");
|
drm/i915: Fix harmful driver register/unregister asymmetry
Starting with commit ec3e00b4ee27 ("drm/i915: stop registering if
drm_dev_register() fails"), we return from i915_driver_register()
immediately if drm_dev_register() fails, skipping remaining registration
steps, and continue only with remaining probe steps. However, the
_unregister() counterpart called at driver remove knows nothing about that
skip and executes reverts of all those steps. As a consequence, a number
of kernel warnings that taint the kernel are triggered:
<3> [525.823143] i915 0000:00:02.0: [drm] *ERROR* Failed to register driver for userspace access!
...
<4> [525.831069] ------------[ cut here ]------------
<4> [525.831071] i915 0000:00:02.0: [drm] drm_WARN_ON(power_domains->init_wakeref)
<4> [525.831095] WARNING: CPU: 6 PID: 3440 at drivers/gpu/drm/i915/display/intel_display_power.c:2074 intel_power_domains_disable+0xc2/0xd0 [i915]
...
<4> [525.831328] CPU: 6 UID: 0 PID: 3440 Comm: i915_module_loa Tainted: G U 6.14.0-rc1-CI_DRM_16076-g7a632b6798b6+ #1
...
<4> [525.831334] RIP: 0010:intel_power_domains_disable+0xc2/0xd0 [i915]
...
<4> [525.831483] Call Trace:
<4> [525.831484] <TASK>
...
<4> [525.831943] i915_driver_remove+0x4b/0x140 [i915]
<4> [525.832028] i915_pci_remove+0x1e/0x40 [i915]
<4> [525.832099] pci_device_remove+0x3e/0xb0
<4> [525.832103] device_remove+0x40/0x80
<4> [525.832107] device_release_driver_internal+0x215/0x280
...
Moreover, that unexpected PM reference is left untouched (not released)
but overwritten, then that triggers another kernel warning at driver
release phase:
<4> [526.685700] ------------[ cut here ]------------
<4> [526.685706] i915 0000:00:02.0: [drm] i915 raw-wakerefs=1 wakelocks=1 on cleanup
<4> [526.685734] WARNING: CPU: 1 PID: 3440 at drivers/gpu/drm/i915/intel_runtime_pm.c:443 intel_runtime_pm_driver_release+0x75/0x90 [i915]
...
<4> [526.686090] RIP: 0010:intel_runtime_pm_driver_release+0x75/0x90 [i915]
...
<4> [526.686294] Call Trace:
<4> [526.686296] <TASK>
...
<4> [526.687025] i915_driver_release+0x7e/0xb0 [i915]
<4> [526.687243] drm_dev_put.part.0+0x47/0x90
<4> [526.687250] devm_drm_dev_init_release+0x13/0x30
<4> [526.687255] devm_action_release+0x12/0x30
<4> [526.687261] release_nodes+0x3a/0x120
<4> [526.687268] devres_release_all+0x97/0xe0
<4> [526.687277] device_unbind_cleanup+0x12/0x80
<4> [526.687282] device_release_driver_internal+0x23a/0x280
...
A call to intel_power_domains_disable() was already there. It triggers
the drm_WARN_ON() when it finds a reference to a wakeref taken on device
probe and not released after device registration failure. That wakeref is
then left held forever once its handle gets lost overwritten with another
wakeref, hence another WARN() is called from
intel_runtime_pm_driver_release().
The WARN() triggered by kernfs_remove_by_name_ns() from
i915_teardown_sysfs()->i915_gpu_error_sysfs_teardown(), formerly
i915_teardown_error_capture(), was also there when the return was added.
A call to intel_gt_sysfs_unregister() that triggers the WARN() from
kobject_put() was added to intel_gt_driver_unregister() with commit
69d6bf5c3754ff ("drm/i915/gt: Fix memory leaks in per-gt sysfs").
Fix the asymmetry by failing the driver probe on device registration
failure and going through rewind paths.
For that to work as expected, we apparently need to start the rewind path
of i915_driver_register() with drm_dev_unregister(), even if
drm_dev_register() returned an error.
v5: Drop unsigned keyword from ret variable declaration (Krzysztof),
- keep the "Failed to register driver for userspace access" error
message (Krzysztof),
- split PXP cleanup addition to rewind path out to a separate patch.
v4: Switch to taking an error rewind path on device registration failure
(Krzysztof, Lucas).
v3: Based on Andi's commitment on introducing a flag, try to address
Jani's "must find another way" by finding a better place and name for
the flag (in hope that's what Jani had on mind),
- split into a series of patches and limit the scope of the first (this)
one to a minimum of omitting conditionally only those unregister
(sub)steps that trigger kernel warnings when not registered.
v2: Check in _unregister whether the drm_dev_register has succeeded and
skip some of the _unregister() steps. (Andi)
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10047
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10131
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10887
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12817
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250314205202.809563-8-janusz.krzysztofik@linux.intel.com
2025-03-14 21:38:35 +01:00
|
|
|
|
|
|
|
return 0;
|
2016-06-24 14:00:22 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* i915_driver_unregister - cleanup the registration done in i915_driver_regiser()
|
|
|
|
* @dev_priv: device private
|
|
|
|
*/
|
|
|
|
static void i915_driver_unregister(struct drm_i915_private *dev_priv)
|
|
|
|
{
|
2025-05-07 18:22:54 +03:00
|
|
|
struct intel_display *display = dev_priv->display;
|
2022-09-06 16:49:29 -07:00
|
|
|
struct intel_gt *gt;
|
|
|
|
unsigned int i;
|
|
|
|
|
2020-02-11 18:28:01 +02:00
|
|
|
i915_switcheroo_unregister(dev_priv);
|
|
|
|
|
2019-06-13 16:21:53 -07:00
|
|
|
intel_runtime_pm_disable(&dev_priv->runtime_pm);
|
2024-11-28 17:38:23 +02:00
|
|
|
intel_power_domains_disable(display);
|
2018-08-16 15:37:56 +03:00
|
|
|
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_unregister(display);
|
2017-11-28 11:01:47 +00:00
|
|
|
|
drm/i915/pxp: Promote pxp subsystem to top-level of i915
Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pertaining to PXP
operation (such as creating the arbitration session and session
tear-down).
PXP as a global feature is accessible via batch buffer instructions
on any engine/tile and the coherency across tiles is handled implicitly
by the HW. In fact, for the foreseeable future, we are expecting this
single-control-tile for the PXP subsystem.
In MTL, it's the standalone media tile (not the root tile) because
it contains the VDBOX and KCR engine (among the assets PXP relies on
for those events).
Looking at the current code design, each tile is represented by the
intel_gt structure while the intel_pxp structure currently hangs off the
intel_gt structure.
Keeping the intel_pxp structure within the intel_gt structure makes some
internal functionalities more straight forward but adds code complexity to
code readability and maintainibility to many external-to-pxp subsystems
which may need to pick the correct intel_gt structure. An example of this
would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
which should be viewed as a global level inquiry, not a per-gt inquiry.
That said, this series promotes the intel_pxp structure into the
drm_i915_private structure making it a top-level subsystem and the PXP
subsystem will select the control gt internally and keep a pointer to
it for internal reference.
This promotion comes with two noteworthy changes:
1. Exported pxp functions that are called by external subsystems
(such as intel_pxp_enabled/active) will have to check implicitly
if i915->pxp is valid as that structure will not be allocated
for HW that doesn't support PXP.
2. Since GT is now considered a soft-dependency of PXP we are
ensuring that GT init happens before PXP init and vice versa
for fini. This causes a minor ordering change whereby we previously
called intel_pxp_suspend after intel_uc_suspend but now is before
i915_gem_suspend_late but the change is required for correct
dependency flows. Additionally, this re-order change doesn't
have any impact because at that point in either case, the top level
entry to i915 won't observe any PXP events (since the GPU was
quiesced during suspend_prepare). Also, any PXP event doesn't
really matter when we disable the PXP HW (global GT irqs are
already off anyway, so even if there was a bug that generated
spurious events we wouldn't see it and we would just clean it
up on resume which is okay since the default fallback action
for PXP would be to keep the sessions off at this suspend stage).
Changes from prior revs:
v11: - Reformat a comment (Tvrtko).
v10: - Change the code flow for intel_pxp_init to make it more
cleaner and readible with better comments explaining the
difference between full-PXP-feature vs the partial-teelink
inits depending on the platform. Additionally, only do
the pxp allocation when we are certain the subsystem is
needed. (Tvrtko).
v9: - Cosmetic cleanups in supported/enabled/active. (Daniele).
- Add comments for intel_pxp_init and pxp_get_ctrl_gt that
explain the functional flow for when PXP is not supported
but the backend-assets are needed for HuC authentication
(Daniele and Tvrtko).
- Fix two remaining functions that are accessible outside
PXP that need to be checking pxp ptrs before using them:
intel_pxp_irq_handler and intel_pxp_huc_load_and_auth
(Tvrtko and Daniele).
- User helper macro in pxp-debugfs (Tvrtko).
v8: - Remove pxp_to_gt macro (Daniele).
- Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't
support GSC-FW on it. (Daniele).
- Leave i915->pxp as NULL if we dont support PXP and in line
with that, do additional validity check on i915->pxp for
intel_pxp_is_supported/enabled/active (Daniele).
- Remove unncessary include header from intel_gt_debugfs.c
and check drm_minor i915->drm.primary (Daniele).
- Other cosmetics / minor issues / more comments on suspend
flow order change (Daniele).
v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
through out instead of local variable newpxp. (Rodrigo)
- In the case intel_pxp_fini is called during driver unload but
after i915 loading failed without pxp being allocated, check
i915->pxp before referencing it. (Alan)
v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
because : [1] introduction of 'ctrl_gt' means we correct this
for MTL's upcoming series now. [2] Also, this has little impact
globally as its only used by PXP-internal callers at the moment.
- Change intel_pxp_init/fini to take in i915 as its input to avoid
ptr-to-ptr in init/fini calls.(Jani).
- Remove the backpointer from pxp->i915 since we can use
pxp->ctrl_gt->i915 if we need it. (Rodrigo).
v5: - Switch from series to single patch (Rodrigo).
- change function name from pxp_get_kcr_owner_gt to
pxp_get_ctrl_gt.
- Fix CI BAT failure by removing redundant call to intel_pxp_fini
from driver-remove.
- NOTE: remaining open still persists on using ptr-to-ptr
and back-ptr.
v4: - Instead of maintaining intel_pxp as an intel_gt structure member
and creating a number of convoluted helpers that takes in i915 as
input and redirects to the correct intel_gt or takes any intel_gt
and internally replaces with the correct intel_gt, promote it to
be a top-level i915 structure.
v3: - Rename gt level helper functions to "intel_pxp_is_enabled/
supported/ active_on_gt" (Daniele)
- Upgrade _gt_supports_pxp to replace what was intel_gtpxp_is
supported as the new intel_pxp_is_supported_on_gt to check for
PXP feature support vs the tee support for huc authentication.
Fix pxp-debugfs-registration to use only the former to decide
support. (Daniele)
- Couple minor optimizations.
v2: - Avoid introduction of new device info or gt variables and use
existing checks / macros to differentiate the correct GT->PXP
control ownership (Daniele Ceraolo Spurio)
- Don't reuse the updated global-checkers for per-GT callers (such
as other files within PXP) to avoid unnecessary GT-reparsing,
expose a replacement helper like the prior ones. (Daniele).
v1: - Add one more patch to the series for the intel_pxp suspend/resume
for similar refactoring
References: https://patchwork.freedesktop.org/patch/msgid/20221202011407.4068371-1-alan.previn.teres.alexis@intel.com
Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221208180542.998148-1-alan.previn.teres.alexis@intel.com
2022-12-08 10:05:42 -08:00
|
|
|
intel_pxp_fini(dev_priv);
|
|
|
|
|
2022-09-06 16:49:29 -07:00
|
|
|
for_each_gt(gt, dev_priv, i)
|
|
|
|
intel_gt_driver_unregister(gt);
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2022-10-13 08:45:20 -07:00
|
|
|
i915_hwmon_unregister(dev_priv);
|
|
|
|
|
2016-11-07 19:49:53 +00:00
|
|
|
i915_perf_unregister(dev_priv);
|
drm/i915/pmu: Expose a PMU interface for perf queries
From: Chris Wilson <chris@chris-wilson.co.uk>
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
From: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
The first goal is to be able to measure GPU (and invidual ring) busyness
without having to poll registers from userspace. (Which not only incurs
holding the forcewake lock indefinitely, perturbing the system, but also
runs the risk of hanging the machine.) As an alternative we can use the
perf event counter interface to sample the ring registers periodically
and send those results to userspace.
Functionality we are exporting to userspace is via the existing perf PMU
API and can be exercised via the existing tools. For example:
perf stat -a -e i915/rcs0-busy/ -I 1000
Will print the render engine busynnes once per second. All the performance
counters can be enumerated (perf list) and have their unit of measure
correctly reported in sysfs.
v1-v2 (Chris Wilson):
v2: Use a common timer for the ring sampling.
v3: (Tvrtko Ursulin)
* Decouple uAPI from i915 engine ids.
* Complete uAPI defines.
* Refactor some code to helpers for clarity.
* Skip sampling disabled engines.
* Expose counters in sysfs.
* Pass in fake regs to avoid null ptr deref in perf core.
* Convert to class/instance uAPI.
* Use shared driver code for rc6 residency, power and frequency.
v4: (Dmitry Rogozhkin)
* Register PMU with .task_ctx_nr=perf_invalid_context
* Expose cpumask for the PMU with the single CPU in the mask
* Properly support pmu->stop(): it should call pmu->read()
* Properly support pmu->del(): it should call stop(event, PERF_EF_UPDATE)
* Introduce refcounting of event subscriptions.
* Make pmu.busy_stats a refcounter to avoid busy stats going away
with some deleted event.
* Expose cpumask for i915 PMU to avoid multiple events creation of
the same type followed by counter aggregation by perf-stat.
* Track CPUs getting online/offline to migrate perf context. If (likely)
cpumask will initially set CPU0, CONFIG_BOOTPARAM_HOTPLUG_CPU0 will be
needed to see effect of CPU status tracking.
* End result is that only global events are supported and perf stat
works correctly.
* Deny perf driver level sampling - it is prohibited for uncore PMU.
v5: (Tvrtko Ursulin)
* Don't hardcode number of engine samplers.
* Rewrite event ref-counting for correctness and simplicity.
* Store initial counter value when starting already enabled events
to correctly report values to all listeners.
* Fix RC6 residency readout.
* Comments, GPL header.
v6:
* Add missing entry to v4 changelog.
* Fix accounting in CPU hotplug case by copying the approach from
arch/x86/events/intel/cstate.c. (Dmitry Rogozhkin)
v7:
* Log failure message only on failure.
* Remove CPU hotplug notification state on unregister.
v8:
* Fix error unwind on failed registration.
* Checkpatch cleanup.
v9:
* Drop the energy metric, it is available via intel_rapl_perf.
(Ville Syrjälä)
* Use HAS_RC6(p). (Chris Wilson)
* Handle unsupported non-engine events. (Dmitry Rogozhkin)
* Rebase for intel_rc6_residency_ns needing caller managed
runtime pm.
* Drop HAS_RC6 checks from the read callback since creating those
events will be rejected at init time already.
* Add counter units to sysfs so perf stat output is nicer.
* Cleanup the attribute tables for brevity and readability.
v10:
* Fixed queued accounting.
v11:
* Move intel_engine_lookup_user to intel_engine_cs.c
* Commit update. (Joonas Lahtinen)
v12:
* More accurate sampling. (Chris Wilson)
* Store and report frequency in MHz for better usability from
perf stat.
* Removed metrics: queued, interrupts, rc6 counters.
* Sample engine busyness based on seqno difference only
for less MMIO (and forcewake) on all platforms. (Chris Wilson)
v13:
* Comment spelling, use mul_u32_u32 to work around potential GCC
issue and somne code alignment changes. (Chris Wilson)
v14:
* Rebase.
v15:
* Rebase for RPS refactoring.
v16:
* Use the dynamic slot in the CPU hotplug state machine so that we are
free to setup our state as multi-instance. Previously we were re-using
the CPUHP_AP_PERF_X86_UNCORE_ONLINE slot which is neither used as
multi-instance, nor owned by our driver to start with.
* Register the CPU hotplug handlers after the PMU, otherwise the callback
will get called before the PMU is initialized which can end up in
perf_pmu_migrate_context with an un-initialized base.
* Added workaround for a probable bug in cpuhp core.
v17:
* Remove workaround for the cpuhp bug.
v18:
* Rebase for drm_i915_gem_engine_class getting upstream before us.
v19:
* Rebase. (trivial)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171121181852.16128-2-tvrtko.ursulin@linux.intel.com
2017-11-21 18:18:45 +00:00
|
|
|
i915_pmu_unregister(dev_priv);
|
2016-11-07 19:49:53 +00:00
|
|
|
|
2016-08-22 13:32:43 +03:00
|
|
|
i915_teardown_sysfs(dev_priv);
|
2019-04-05 15:02:34 +02:00
|
|
|
drm_dev_unplug(&dev_priv->drm);
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2019-08-06 13:42:59 +01:00
|
|
|
i915_gem_driver_unregister(dev_priv);
|
2016-06-24 14:00:22 +01:00
|
|
|
}
|
|
|
|
|
2021-11-26 14:14:24 +00:00
|
|
|
void
|
|
|
|
i915_print_iommu_status(struct drm_i915_private *i915, struct drm_printer *p)
|
|
|
|
{
|
2022-02-25 15:46:30 -08:00
|
|
|
drm_printf(p, "iommu: %s\n",
|
2022-03-29 10:02:04 +01:00
|
|
|
str_enabled_disabled(i915_vtd_active(i915)));
|
2021-11-26 14:14:24 +00:00
|
|
|
}
|
|
|
|
|
2017-12-21 21:57:35 +00:00
|
|
|
static void i915_welcome_messages(struct drm_i915_private *dev_priv)
|
|
|
|
{
|
2019-10-28 12:38:15 +02:00
|
|
|
if (drm_debug_enabled(DRM_UT_DRIVER)) {
|
2024-01-16 15:07:32 +02:00
|
|
|
struct drm_printer p = drm_dbg_printer(&dev_priv->drm, DRM_UT_DRIVER,
|
|
|
|
"device info:");
|
2022-09-06 16:49:29 -07:00
|
|
|
struct intel_gt *gt;
|
|
|
|
unsigned int i;
|
2017-12-21 21:57:35 +00:00
|
|
|
|
2019-03-27 14:23:28 +00:00
|
|
|
drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s (subplatform=0x%x) gen=%i\n",
|
2018-12-31 16:56:45 +02:00
|
|
|
INTEL_DEVID(dev_priv),
|
|
|
|
INTEL_REVID(dev_priv),
|
|
|
|
intel_platform_name(INTEL_INFO(dev_priv)->platform),
|
2019-03-27 14:23:28 +00:00
|
|
|
intel_subplatform(RUNTIME_INFO(dev_priv),
|
|
|
|
INTEL_INFO(dev_priv)->platform),
|
2021-06-05 21:50:49 -07:00
|
|
|
GRAPHICS_VER(dev_priv));
|
2018-12-31 16:56:45 +02:00
|
|
|
|
2022-08-19 15:02:35 +03:00
|
|
|
intel_device_info_print(INTEL_INFO(dev_priv),
|
|
|
|
RUNTIME_INFO(dev_priv), &p);
|
2021-11-26 14:14:24 +00:00
|
|
|
i915_print_iommu_status(dev_priv, &p);
|
2022-09-06 16:49:29 -07:00
|
|
|
for_each_gt(gt, dev_priv, i)
|
|
|
|
intel_gt_info_print(>->info, &p);
|
2017-12-21 21:57:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG))
|
drm/i915: conversion to drm_device logging macros when drm_i915_private is present.
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Instances of the DRM_DEBUG macro were not converted due to lack of a
consensus of an analogous struct drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
2020-01-31 12:34:12 +03:00
|
|
|
drm_info(&dev_priv->drm, "DRM_I915_DEBUG enabled\n");
|
2017-12-21 21:57:35 +00:00
|
|
|
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
|
drm/i915: conversion to drm_device logging macros when drm_i915_private is present.
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Instances of the DRM_DEBUG macro were not converted due to lack of a
consensus of an analogous struct drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
2020-01-31 12:34:12 +03:00
|
|
|
drm_info(&dev_priv->drm, "DRM_I915_DEBUG_GEM enabled\n");
|
2018-08-16 22:34:14 +03:00
|
|
|
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM))
|
drm/i915: conversion to drm_device logging macros when drm_i915_private is present.
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Instances of the DRM_DEBUG macro were not converted due to lack of a
consensus of an analogous struct drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
2020-01-31 12:34:12 +03:00
|
|
|
drm_info(&dev_priv->drm,
|
|
|
|
"DRM_I915_DEBUG_RUNTIME_PM enabled\n");
|
2017-12-21 21:57:35 +00:00
|
|
|
}
|
|
|
|
|
2018-09-05 15:09:20 +01:00
|
|
|
static struct drm_i915_private *
|
|
|
|
i915_driver_create(struct pci_dev *pdev, const struct pci_device_id *ent)
|
|
|
|
{
|
|
|
|
const struct intel_device_info *match_info =
|
|
|
|
(struct intel_device_info *)ent->driver_data;
|
|
|
|
struct drm_i915_private *i915;
|
2025-05-22 12:48:42 +03:00
|
|
|
struct intel_display *display;
|
2018-09-05 15:09:20 +01:00
|
|
|
|
2021-11-11 12:13:03 +02:00
|
|
|
i915 = devm_drm_dev_alloc(&pdev->dev, &i915_drm_driver,
|
2020-04-15 09:40:13 +02:00
|
|
|
struct drm_i915_private, drm);
|
|
|
|
if (IS_ERR(i915))
|
|
|
|
return i915;
|
2018-09-05 15:09:20 +01:00
|
|
|
|
2024-08-29 17:47:43 +03:00
|
|
|
pci_set_drvdata(pdev, &i915->drm);
|
2018-09-05 15:09:20 +01:00
|
|
|
|
2020-06-18 18:04:02 +03:00
|
|
|
/* Device parameters start as a copy of module parameters. */
|
|
|
|
i915_params_copy(&i915->params, &i915_modparams);
|
|
|
|
|
2023-04-11 13:56:43 +03:00
|
|
|
/* Set up device info and initial runtime info. */
|
|
|
|
intel_device_info_driver_create(i915, pdev->device, match_info);
|
2018-09-05 15:09:20 +01:00
|
|
|
|
2025-05-22 12:48:42 +03:00
|
|
|
display = intel_display_device_probe(pdev);
|
|
|
|
if (IS_ERR(display))
|
|
|
|
return ERR_CAST(display);
|
2025-05-07 18:22:54 +03:00
|
|
|
|
2025-05-22 12:48:42 +03:00
|
|
|
i915->display = display;
|
2023-09-12 15:05:37 +03:00
|
|
|
|
2018-09-05 15:09:20 +01:00
|
|
|
return i915;
|
|
|
|
}
|
|
|
|
|
2016-06-24 14:00:22 +01:00
|
|
|
/**
|
2019-07-12 13:24:26 +02:00
|
|
|
* i915_driver_probe - setup chip and create an initial config
|
2016-11-10 15:36:34 +02:00
|
|
|
* @pdev: PCI device
|
|
|
|
* @ent: matching PCI ID entry
|
2016-06-24 14:00:22 +01:00
|
|
|
*
|
2019-07-12 13:24:26 +02:00
|
|
|
* The driver probe routine has to do several things:
|
2023-04-14 12:41:58 +03:00
|
|
|
* - drive output discovery via intel_display_driver_probe()
|
2016-06-24 14:00:22 +01:00
|
|
|
* - initialize the memory manager
|
|
|
|
* - allocate initial config memory
|
|
|
|
* - setup the DRM framebuffer with the allocated memory
|
|
|
|
*/
|
2019-07-12 13:24:26 +02:00
|
|
|
int i915_driver_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
|
2016-06-24 14:00:22 +01:00
|
|
|
{
|
2020-02-11 18:28:02 +02:00
|
|
|
struct drm_i915_private *i915;
|
2024-12-04 12:21:50 +02:00
|
|
|
struct intel_display *display;
|
2016-06-24 14:00:22 +01:00
|
|
|
int ret;
|
2014-04-09 18:19:04 +03:00
|
|
|
|
2016-06-24 14:00:22 +01:00
|
|
|
ret = pci_enable_device(pdev);
|
2023-05-23 12:56:08 -07:00
|
|
|
if (ret) {
|
|
|
|
pr_err("Failed to enable graphics device: %pe\n", ERR_PTR(ret));
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
i915 = i915_driver_create(pdev, ent);
|
|
|
|
if (IS_ERR(i915)) {
|
2023-06-01 10:38:04 -07:00
|
|
|
pci_disable_device(pdev);
|
|
|
|
return PTR_ERR(i915);
|
2023-05-23 12:56:08 -07:00
|
|
|
}
|
2015-03-17 11:39:27 +02:00
|
|
|
|
2025-05-07 18:22:54 +03:00
|
|
|
display = i915->display;
|
2024-12-04 12:21:50 +02:00
|
|
|
|
2020-02-11 18:28:02 +02:00
|
|
|
ret = i915_driver_early_probe(i915);
|
2016-06-24 14:00:22 +01:00
|
|
|
if (ret < 0)
|
|
|
|
goto out_pci_disable;
|
2015-10-28 04:16:45 -07:00
|
|
|
|
2020-02-11 18:28:02 +02:00
|
|
|
disable_rpm_wakeref_asserts(&i915->runtime_pm);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2020-02-27 16:44:06 +02:00
|
|
|
intel_vgpu_detect(i915);
|
2019-06-19 18:00:21 -07:00
|
|
|
|
2022-03-19 01:39:33 +02:00
|
|
|
ret = intel_gt_probe_all(i915);
|
2016-06-24 14:00:22 +01:00
|
|
|
if (ret < 0)
|
|
|
|
goto out_runtime_pm_put;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-07 14:24:08 -08:00
|
|
|
|
2022-03-19 01:39:33 +02:00
|
|
|
ret = i915_driver_mmio_probe(i915);
|
|
|
|
if (ret < 0)
|
2023-11-15 11:54:03 +01:00
|
|
|
goto out_runtime_pm_put;
|
2022-03-19 01:39:33 +02:00
|
|
|
|
2020-02-11 18:28:02 +02:00
|
|
|
ret = i915_driver_hw_probe(i915);
|
2016-06-24 14:00:22 +01:00
|
|
|
if (ret < 0)
|
|
|
|
goto out_cleanup_mmio;
|
2015-08-28 13:10:22 +01:00
|
|
|
|
2024-12-04 12:21:50 +02:00
|
|
|
ret = intel_display_driver_probe_noirq(display);
|
2016-06-24 14:00:22 +01:00
|
|
|
if (ret < 0)
|
2017-06-21 10:28:41 +02:00
|
|
|
goto out_cleanup_hw;
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2020-02-19 15:37:56 +02:00
|
|
|
ret = intel_irq_install(i915);
|
|
|
|
if (ret)
|
|
|
|
goto out_cleanup_modeset;
|
|
|
|
|
2024-12-04 12:21:50 +02:00
|
|
|
ret = intel_display_driver_probe_nogem(display);
|
2020-09-02 17:30:23 +03:00
|
|
|
if (ret)
|
2020-02-19 15:37:56 +02:00
|
|
|
goto out_cleanup_irq;
|
|
|
|
|
2020-09-02 17:30:23 +03:00
|
|
|
ret = i915_gem_init(i915);
|
|
|
|
if (ret)
|
|
|
|
goto out_cleanup_modeset2;
|
|
|
|
|
2023-11-13 14:49:53 -08:00
|
|
|
ret = intel_pxp_init(i915);
|
2024-03-20 14:05:47 -07:00
|
|
|
if (ret && ret != -ENODEV)
|
2023-11-13 14:49:53 -08:00
|
|
|
drm_dbg(&i915->drm, "pxp init failed with %d\n", ret);
|
drm/i915/pxp: Promote pxp subsystem to top-level of i915
Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pertaining to PXP
operation (such as creating the arbitration session and session
tear-down).
PXP as a global feature is accessible via batch buffer instructions
on any engine/tile and the coherency across tiles is handled implicitly
by the HW. In fact, for the foreseeable future, we are expecting this
single-control-tile for the PXP subsystem.
In MTL, it's the standalone media tile (not the root tile) because
it contains the VDBOX and KCR engine (among the assets PXP relies on
for those events).
Looking at the current code design, each tile is represented by the
intel_gt structure while the intel_pxp structure currently hangs off the
intel_gt structure.
Keeping the intel_pxp structure within the intel_gt structure makes some
internal functionalities more straight forward but adds code complexity to
code readability and maintainibility to many external-to-pxp subsystems
which may need to pick the correct intel_gt structure. An example of this
would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
which should be viewed as a global level inquiry, not a per-gt inquiry.
That said, this series promotes the intel_pxp structure into the
drm_i915_private structure making it a top-level subsystem and the PXP
subsystem will select the control gt internally and keep a pointer to
it for internal reference.
This promotion comes with two noteworthy changes:
1. Exported pxp functions that are called by external subsystems
(such as intel_pxp_enabled/active) will have to check implicitly
if i915->pxp is valid as that structure will not be allocated
for HW that doesn't support PXP.
2. Since GT is now considered a soft-dependency of PXP we are
ensuring that GT init happens before PXP init and vice versa
for fini. This causes a minor ordering change whereby we previously
called intel_pxp_suspend after intel_uc_suspend but now is before
i915_gem_suspend_late but the change is required for correct
dependency flows. Additionally, this re-order change doesn't
have any impact because at that point in either case, the top level
entry to i915 won't observe any PXP events (since the GPU was
quiesced during suspend_prepare). Also, any PXP event doesn't
really matter when we disable the PXP HW (global GT irqs are
already off anyway, so even if there was a bug that generated
spurious events we wouldn't see it and we would just clean it
up on resume which is okay since the default fallback action
for PXP would be to keep the sessions off at this suspend stage).
Changes from prior revs:
v11: - Reformat a comment (Tvrtko).
v10: - Change the code flow for intel_pxp_init to make it more
cleaner and readible with better comments explaining the
difference between full-PXP-feature vs the partial-teelink
inits depending on the platform. Additionally, only do
the pxp allocation when we are certain the subsystem is
needed. (Tvrtko).
v9: - Cosmetic cleanups in supported/enabled/active. (Daniele).
- Add comments for intel_pxp_init and pxp_get_ctrl_gt that
explain the functional flow for when PXP is not supported
but the backend-assets are needed for HuC authentication
(Daniele and Tvrtko).
- Fix two remaining functions that are accessible outside
PXP that need to be checking pxp ptrs before using them:
intel_pxp_irq_handler and intel_pxp_huc_load_and_auth
(Tvrtko and Daniele).
- User helper macro in pxp-debugfs (Tvrtko).
v8: - Remove pxp_to_gt macro (Daniele).
- Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't
support GSC-FW on it. (Daniele).
- Leave i915->pxp as NULL if we dont support PXP and in line
with that, do additional validity check on i915->pxp for
intel_pxp_is_supported/enabled/active (Daniele).
- Remove unncessary include header from intel_gt_debugfs.c
and check drm_minor i915->drm.primary (Daniele).
- Other cosmetics / minor issues / more comments on suspend
flow order change (Daniele).
v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
through out instead of local variable newpxp. (Rodrigo)
- In the case intel_pxp_fini is called during driver unload but
after i915 loading failed without pxp being allocated, check
i915->pxp before referencing it. (Alan)
v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
because : [1] introduction of 'ctrl_gt' means we correct this
for MTL's upcoming series now. [2] Also, this has little impact
globally as its only used by PXP-internal callers at the moment.
- Change intel_pxp_init/fini to take in i915 as its input to avoid
ptr-to-ptr in init/fini calls.(Jani).
- Remove the backpointer from pxp->i915 since we can use
pxp->ctrl_gt->i915 if we need it. (Rodrigo).
v5: - Switch from series to single patch (Rodrigo).
- change function name from pxp_get_kcr_owner_gt to
pxp_get_ctrl_gt.
- Fix CI BAT failure by removing redundant call to intel_pxp_fini
from driver-remove.
- NOTE: remaining open still persists on using ptr-to-ptr
and back-ptr.
v4: - Instead of maintaining intel_pxp as an intel_gt structure member
and creating a number of convoluted helpers that takes in i915 as
input and redirects to the correct intel_gt or takes any intel_gt
and internally replaces with the correct intel_gt, promote it to
be a top-level i915 structure.
v3: - Rename gt level helper functions to "intel_pxp_is_enabled/
supported/ active_on_gt" (Daniele)
- Upgrade _gt_supports_pxp to replace what was intel_gtpxp_is
supported as the new intel_pxp_is_supported_on_gt to check for
PXP feature support vs the tee support for huc authentication.
Fix pxp-debugfs-registration to use only the former to decide
support. (Daniele)
- Couple minor optimizations.
v2: - Avoid introduction of new device info or gt variables and use
existing checks / macros to differentiate the correct GT->PXP
control ownership (Daniele Ceraolo Spurio)
- Don't reuse the updated global-checkers for per-GT callers (such
as other files within PXP) to avoid unnecessary GT-reparsing,
expose a replacement helper like the prior ones. (Daniele).
v1: - Add one more patch to the series for the intel_pxp suspend/resume
for similar refactoring
References: https://patchwork.freedesktop.org/patch/msgid/20221202011407.4068371-1-alan.previn.teres.alexis@intel.com
Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221208180542.998148-1-alan.previn.teres.alexis@intel.com
2022-12-08 10:05:42 -08:00
|
|
|
|
2024-12-04 12:21:50 +02:00
|
|
|
ret = intel_display_driver_probe(display);
|
2020-09-02 17:30:23 +03:00
|
|
|
if (ret)
|
|
|
|
goto out_cleanup_gem;
|
|
|
|
|
drm/i915: Fix harmful driver register/unregister asymmetry
Starting with commit ec3e00b4ee27 ("drm/i915: stop registering if
drm_dev_register() fails"), we return from i915_driver_register()
immediately if drm_dev_register() fails, skipping remaining registration
steps, and continue only with remaining probe steps. However, the
_unregister() counterpart called at driver remove knows nothing about that
skip and executes reverts of all those steps. As a consequence, a number
of kernel warnings that taint the kernel are triggered:
<3> [525.823143] i915 0000:00:02.0: [drm] *ERROR* Failed to register driver for userspace access!
...
<4> [525.831069] ------------[ cut here ]------------
<4> [525.831071] i915 0000:00:02.0: [drm] drm_WARN_ON(power_domains->init_wakeref)
<4> [525.831095] WARNING: CPU: 6 PID: 3440 at drivers/gpu/drm/i915/display/intel_display_power.c:2074 intel_power_domains_disable+0xc2/0xd0 [i915]
...
<4> [525.831328] CPU: 6 UID: 0 PID: 3440 Comm: i915_module_loa Tainted: G U 6.14.0-rc1-CI_DRM_16076-g7a632b6798b6+ #1
...
<4> [525.831334] RIP: 0010:intel_power_domains_disable+0xc2/0xd0 [i915]
...
<4> [525.831483] Call Trace:
<4> [525.831484] <TASK>
...
<4> [525.831943] i915_driver_remove+0x4b/0x140 [i915]
<4> [525.832028] i915_pci_remove+0x1e/0x40 [i915]
<4> [525.832099] pci_device_remove+0x3e/0xb0
<4> [525.832103] device_remove+0x40/0x80
<4> [525.832107] device_release_driver_internal+0x215/0x280
...
Moreover, that unexpected PM reference is left untouched (not released)
but overwritten, then that triggers another kernel warning at driver
release phase:
<4> [526.685700] ------------[ cut here ]------------
<4> [526.685706] i915 0000:00:02.0: [drm] i915 raw-wakerefs=1 wakelocks=1 on cleanup
<4> [526.685734] WARNING: CPU: 1 PID: 3440 at drivers/gpu/drm/i915/intel_runtime_pm.c:443 intel_runtime_pm_driver_release+0x75/0x90 [i915]
...
<4> [526.686090] RIP: 0010:intel_runtime_pm_driver_release+0x75/0x90 [i915]
...
<4> [526.686294] Call Trace:
<4> [526.686296] <TASK>
...
<4> [526.687025] i915_driver_release+0x7e/0xb0 [i915]
<4> [526.687243] drm_dev_put.part.0+0x47/0x90
<4> [526.687250] devm_drm_dev_init_release+0x13/0x30
<4> [526.687255] devm_action_release+0x12/0x30
<4> [526.687261] release_nodes+0x3a/0x120
<4> [526.687268] devres_release_all+0x97/0xe0
<4> [526.687277] device_unbind_cleanup+0x12/0x80
<4> [526.687282] device_release_driver_internal+0x23a/0x280
...
A call to intel_power_domains_disable() was already there. It triggers
the drm_WARN_ON() when it finds a reference to a wakeref taken on device
probe and not released after device registration failure. That wakeref is
then left held forever once its handle gets lost overwritten with another
wakeref, hence another WARN() is called from
intel_runtime_pm_driver_release().
The WARN() triggered by kernfs_remove_by_name_ns() from
i915_teardown_sysfs()->i915_gpu_error_sysfs_teardown(), formerly
i915_teardown_error_capture(), was also there when the return was added.
A call to intel_gt_sysfs_unregister() that triggers the WARN() from
kobject_put() was added to intel_gt_driver_unregister() with commit
69d6bf5c3754ff ("drm/i915/gt: Fix memory leaks in per-gt sysfs").
Fix the asymmetry by failing the driver probe on device registration
failure and going through rewind paths.
For that to work as expected, we apparently need to start the rewind path
of i915_driver_register() with drm_dev_unregister(), even if
drm_dev_register() returned an error.
v5: Drop unsigned keyword from ret variable declaration (Krzysztof),
- keep the "Failed to register driver for userspace access" error
message (Krzysztof),
- split PXP cleanup addition to rewind path out to a separate patch.
v4: Switch to taking an error rewind path on device registration failure
(Krzysztof, Lucas).
v3: Based on Andi's commitment on introducing a flag, try to address
Jani's "must find another way" by finding a better place and name for
the flag (in hope that's what Jani had on mind),
- split into a series of patches and limit the scope of the first (this)
one to a minimum of omitting conditionally only those unregister
(sub)steps that trigger kernel warnings when not registered.
v2: Check in _unregister whether the drm_dev_register has succeeded and
skip some of the _unregister() steps. (Andi)
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10047
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10131
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10887
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12817
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250314205202.809563-8-janusz.krzysztofik@linux.intel.com
2025-03-14 21:38:35 +01:00
|
|
|
ret = i915_driver_register(i915);
|
|
|
|
if (ret)
|
|
|
|
goto out_cleanup_gem;
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2020-02-11 18:28:02 +02:00
|
|
|
enable_rpm_wakeref_asserts(&i915->runtime_pm);
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2020-02-11 18:28:02 +02:00
|
|
|
i915_welcome_messages(i915);
|
2017-12-21 21:57:35 +00:00
|
|
|
|
2020-03-23 15:49:07 +01:00
|
|
|
i915->do_release = true;
|
|
|
|
|
2016-06-24 14:00:22 +01:00
|
|
|
return 0;
|
|
|
|
|
2020-09-02 17:30:23 +03:00
|
|
|
out_cleanup_gem:
|
2025-03-14 21:38:34 +01:00
|
|
|
intel_pxp_fini(i915);
|
2020-09-02 17:30:23 +03:00
|
|
|
i915_gem_suspend(i915);
|
|
|
|
i915_gem_driver_remove(i915);
|
|
|
|
i915_gem_driver_release(i915);
|
|
|
|
out_cleanup_modeset2:
|
|
|
|
/* FIXME clean up the error path */
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_remove(display);
|
2020-09-02 17:30:23 +03:00
|
|
|
intel_irq_uninstall(i915);
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_remove_noirq(display);
|
2020-09-02 17:30:23 +03:00
|
|
|
goto out_cleanup_modeset;
|
2020-02-19 15:37:56 +02:00
|
|
|
out_cleanup_irq:
|
|
|
|
intel_irq_uninstall(i915);
|
|
|
|
out_cleanup_modeset:
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_remove_nogem(display);
|
2016-06-24 14:00:22 +01:00
|
|
|
out_cleanup_hw:
|
2020-02-11 18:28:02 +02:00
|
|
|
i915_driver_hw_remove(i915);
|
|
|
|
intel_memory_regions_driver_release(i915);
|
|
|
|
i915_ggtt_driver_release(i915);
|
2021-06-01 09:46:41 +02:00
|
|
|
i915_gem_drain_freed_objects(i915);
|
|
|
|
i915_ggtt_driver_late_release(i915);
|
2016-06-24 14:00:22 +01:00
|
|
|
out_cleanup_mmio:
|
2020-02-11 18:28:02 +02:00
|
|
|
i915_driver_mmio_release(i915);
|
2016-06-24 14:00:22 +01:00
|
|
|
out_runtime_pm_put:
|
2020-02-11 18:28:02 +02:00
|
|
|
enable_rpm_wakeref_asserts(&i915->runtime_pm);
|
|
|
|
i915_driver_late_release(i915);
|
2016-06-24 14:00:22 +01:00
|
|
|
out_pci_disable:
|
|
|
|
pci_disable_device(pdev);
|
2020-02-11 18:28:02 +02:00
|
|
|
i915_probe_error(i915, "Device initialization failed (%d)\n", ret);
|
2015-08-28 13:10:22 +01:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
void i915_driver_remove(struct drm_i915_private *i915)
|
2010-04-07 16:15:53 +08:00
|
|
|
{
|
2025-05-07 18:22:54 +03:00
|
|
|
struct intel_display *display = i915->display;
|
2022-08-30 14:21:58 +05:30
|
|
|
intel_wakeref_t wakeref;
|
|
|
|
|
|
|
|
wakeref = intel_runtime_pm_get(&i915->runtime_pm);
|
2018-08-16 15:37:56 +03:00
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
i915_driver_unregister(i915);
|
2017-07-15 00:46:56 +02:00
|
|
|
|
2019-01-14 14:21:29 +00:00
|
|
|
/* Flush any external code that still may be under the RCU lock */
|
|
|
|
synchronize_rcu();
|
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
i915_gem_suspend(i915);
|
2013-04-05 13:12:44 -07:00
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
intel_gvt_driver_remove(i915);
|
2017-01-13 10:46:09 +08:00
|
|
|
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_remove(display);
|
2014-02-14 20:23:54 +02:00
|
|
|
|
2020-02-14 15:50:58 +02:00
|
|
|
intel_irq_uninstall(i915);
|
|
|
|
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_remove_noirq(display);
|
2020-02-14 15:50:58 +02:00
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
i915_reset_error_state(i915);
|
|
|
|
i915_gem_driver_remove(i915);
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_remove_nogem(display);
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
i915_driver_hw_remove(i915);
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2022-08-30 14:21:58 +05:30
|
|
|
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
|
2017-02-10 16:35:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void i915_driver_release(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2019-06-13 16:21:53 -07:00
|
|
|
struct intel_runtime_pm *rpm = &dev_priv->runtime_pm;
|
2022-08-30 14:21:58 +05:30
|
|
|
intel_wakeref_t wakeref;
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2020-03-23 15:49:07 +01:00
|
|
|
if (!dev_priv->do_release)
|
|
|
|
return;
|
|
|
|
|
2022-08-30 14:21:58 +05:30
|
|
|
wakeref = intel_runtime_pm_get(rpm);
|
2019-05-30 15:31:05 +02:00
|
|
|
|
2019-07-12 13:24:28 +02:00
|
|
|
i915_gem_driver_release(dev_priv);
|
2019-05-30 15:31:05 +02:00
|
|
|
|
2019-10-26 21:20:32 +01:00
|
|
|
intel_memory_regions_driver_release(dev_priv);
|
2019-07-12 13:24:28 +02:00
|
|
|
i915_ggtt_driver_release(dev_priv);
|
2020-07-29 17:42:18 +01:00
|
|
|
i915_gem_drain_freed_objects(dev_priv);
|
2021-06-01 09:46:41 +02:00
|
|
|
i915_ggtt_driver_late_release(dev_priv);
|
2019-06-19 18:00:17 -07:00
|
|
|
|
2019-07-12 13:24:28 +02:00
|
|
|
i915_driver_mmio_release(dev_priv);
|
2019-05-30 15:31:05 +02:00
|
|
|
|
2022-08-30 14:21:58 +05:30
|
|
|
intel_runtime_pm_put(rpm, wakeref);
|
|
|
|
|
2019-07-12 13:24:28 +02:00
|
|
|
intel_runtime_pm_driver_release(rpm);
|
2019-05-30 15:31:05 +02:00
|
|
|
|
2019-07-12 13:24:28 +02:00
|
|
|
i915_driver_late_release(dev_priv);
|
2010-04-07 16:15:53 +08:00
|
|
|
}
|
|
|
|
|
2016-06-24 14:00:22 +01:00
|
|
|
static int i915_driver_open(struct drm_device *dev, struct drm_file *file)
|
2012-04-05 14:47:36 -07:00
|
|
|
{
|
2017-06-20 12:05:45 +01:00
|
|
|
struct drm_i915_private *i915 = to_i915(dev);
|
2016-06-24 14:00:22 +01:00
|
|
|
int ret;
|
2012-04-05 14:47:36 -07:00
|
|
|
|
2017-06-20 12:05:45 +01:00
|
|
|
ret = i915_gem_open(i915, file);
|
2016-06-24 14:00:22 +01:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-04-05 14:47:36 -07:00
|
|
|
|
2016-06-24 14:00:22 +01:00
|
|
|
return 0;
|
|
|
|
}
|
2014-07-24 17:04:44 +01:00
|
|
|
|
2017-03-08 15:12:45 +01:00
|
|
|
static void i915_driver_postclose(struct drm_device *dev, struct drm_file *file)
|
2016-06-24 14:00:22 +01:00
|
|
|
{
|
2017-03-08 15:12:45 +01:00
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
|
|
|
|
2017-06-20 12:05:45 +01:00
|
|
|
i915_gem_context_close(file);
|
2022-04-01 15:21:58 +01:00
|
|
|
i915_drm_client_put(file_priv->client);
|
2016-06-24 14:00:22 +01:00
|
|
|
|
2019-08-23 19:14:55 +01:00
|
|
|
kfree_rcu(file_priv, rcu);
|
2019-08-02 22:21:37 +01:00
|
|
|
|
|
|
|
/* Catch up with all the deferred frees from "this" client */
|
|
|
|
i915_gem_flush_free_objects(to_i915(dev));
|
2012-04-05 14:47:36 -07:00
|
|
|
}
|
|
|
|
|
2020-10-01 18:16:35 +03:00
|
|
|
void i915_driver_shutdown(struct drm_i915_private *i915)
|
|
|
|
{
|
2025-05-07 18:22:54 +03:00
|
|
|
struct intel_display *display = i915->display;
|
2024-11-28 17:38:23 +02:00
|
|
|
|
2021-01-04 20:39:05 +00:00
|
|
|
disable_rpm_wakeref_asserts(&i915->runtime_pm);
|
2021-01-27 20:19:09 +02:00
|
|
|
intel_runtime_pm_disable(&i915->runtime_pm);
|
2024-11-28 17:38:23 +02:00
|
|
|
intel_power_domains_disable(display);
|
2021-01-04 20:39:05 +00:00
|
|
|
|
2024-12-12 18:08:42 +01:00
|
|
|
drm_client_dev_suspend(&i915->drm, false);
|
drm/i915: skip display initialization when there is no display
Display features should not be initialized or de-initialized when there
is no display. Skip modeset initialization, output setup, plane, crtc,
encoder, connector registration, display cdclk and rawclk
initialization, display core initialization, etc.
Skip the functionality at as high level as possible, and remove any
redundant checks. If the functionality is conditional to *other* display
checks, do not add more. If the un-initialization has checks for
initialization, do not add more.
We explicitly do not care about any GMCH/VLV/CHV code paths, as they've
always had and will have display.
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-3-jose.souza@intel.com
2021-04-08 13:31:50 -07:00
|
|
|
if (HAS_DISPLAY(i915)) {
|
|
|
|
drm_kms_helper_poll_disable(&i915->drm);
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_disable_user_access(display);
|
2020-10-01 18:16:35 +03:00
|
|
|
|
drm/i915: skip display initialization when there is no display
Display features should not be initialized or de-initialized when there
is no display. Skip modeset initialization, output setup, plane, crtc,
encoder, connector registration, display cdclk and rawclk
initialization, display core initialization, etc.
Skip the functionality at as high level as possible, and remove any
redundant checks. If the functionality is conditional to *other* display
checks, do not add more. If the un-initialization has checks for
initialization, do not add more.
We explicitly do not care about any GMCH/VLV/CHV code paths, as they've
always had and will have display.
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-3-jose.souza@intel.com
2021-04-08 13:31:50 -07:00
|
|
|
drm_atomic_helper_shutdown(&i915->drm);
|
|
|
|
}
|
2020-10-01 18:16:35 +03:00
|
|
|
|
2024-12-13 11:48:24 +02:00
|
|
|
intel_dp_mst_suspend(display);
|
2020-10-01 18:16:35 +03:00
|
|
|
|
2024-09-12 13:25:39 -04:00
|
|
|
intel_irq_suspend(i915);
|
2025-03-20 16:45:59 +02:00
|
|
|
intel_hpd_cancel_work(display);
|
2020-10-01 18:16:35 +03:00
|
|
|
|
2024-01-04 15:23:35 +02:00
|
|
|
if (HAS_DISPLAY(i915))
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_suspend_access(display);
|
2024-01-04 15:23:35 +02:00
|
|
|
|
2025-05-07 12:38:35 +03:00
|
|
|
intel_encoder_suspend_all(display);
|
|
|
|
intel_encoder_shutdown_all(display);
|
2021-01-04 20:39:05 +00:00
|
|
|
|
2025-05-07 12:38:35 +03:00
|
|
|
intel_dmc_suspend(display);
|
2021-03-11 16:45:29 +02:00
|
|
|
|
2022-06-17 12:06:29 -07:00
|
|
|
i915_gem_suspend(i915);
|
|
|
|
|
2021-01-27 20:19:09 +02:00
|
|
|
/*
|
|
|
|
* The only requirement is to reboot with display DC states disabled,
|
|
|
|
* for now leaving all display power wells in the INIT power domain
|
2021-03-11 16:45:29 +02:00
|
|
|
* enabled.
|
|
|
|
*
|
|
|
|
* TODO:
|
|
|
|
* - unify the pci_driver::shutdown sequence here with the
|
|
|
|
* pci_driver.driver.pm.poweroff,poweroff_late sequence.
|
|
|
|
* - unify the driver remove and system/runtime suspend sequences with
|
|
|
|
* the above unified shutdown/poweroff sequence.
|
2021-01-27 20:19:09 +02:00
|
|
|
*/
|
2024-11-28 17:38:23 +02:00
|
|
|
intel_power_domains_driver_remove(display);
|
2021-01-04 20:39:05 +00:00
|
|
|
enable_rpm_wakeref_asserts(&i915->runtime_pm);
|
2021-01-27 20:19:09 +02:00
|
|
|
|
2023-10-30 18:40:12 +01:00
|
|
|
intel_runtime_pm_driver_last_release(&i915->runtime_pm);
|
2020-10-01 18:16:35 +03:00
|
|
|
}
|
|
|
|
|
2015-11-18 17:32:30 +02:00
|
|
|
static bool suspend_to_idle(struct drm_i915_private *dev_priv)
|
|
|
|
{
|
|
|
|
#if IS_ENABLED(CONFIG_ACPI_SLEEP)
|
|
|
|
if (acpi_target_system_state() < ACPI_STATE_S3)
|
|
|
|
return true;
|
|
|
|
#endif
|
|
|
|
return false;
|
|
|
|
}
|
2014-08-13 23:07:05 +05:30
|
|
|
|
2023-01-25 00:26:37 -08:00
|
|
|
static void i915_drm_complete(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = to_i915(dev);
|
|
|
|
|
|
|
|
intel_pxp_resume_complete(i915->pxp);
|
|
|
|
}
|
|
|
|
|
2018-05-25 10:26:29 +01:00
|
|
|
static int i915_drm_prepare(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = to_i915(dev);
|
|
|
|
|
drm/i915/pxp: Promote pxp subsystem to top-level of i915
Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pertaining to PXP
operation (such as creating the arbitration session and session
tear-down).
PXP as a global feature is accessible via batch buffer instructions
on any engine/tile and the coherency across tiles is handled implicitly
by the HW. In fact, for the foreseeable future, we are expecting this
single-control-tile for the PXP subsystem.
In MTL, it's the standalone media tile (not the root tile) because
it contains the VDBOX and KCR engine (among the assets PXP relies on
for those events).
Looking at the current code design, each tile is represented by the
intel_gt structure while the intel_pxp structure currently hangs off the
intel_gt structure.
Keeping the intel_pxp structure within the intel_gt structure makes some
internal functionalities more straight forward but adds code complexity to
code readability and maintainibility to many external-to-pxp subsystems
which may need to pick the correct intel_gt structure. An example of this
would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
which should be viewed as a global level inquiry, not a per-gt inquiry.
That said, this series promotes the intel_pxp structure into the
drm_i915_private structure making it a top-level subsystem and the PXP
subsystem will select the control gt internally and keep a pointer to
it for internal reference.
This promotion comes with two noteworthy changes:
1. Exported pxp functions that are called by external subsystems
(such as intel_pxp_enabled/active) will have to check implicitly
if i915->pxp is valid as that structure will not be allocated
for HW that doesn't support PXP.
2. Since GT is now considered a soft-dependency of PXP we are
ensuring that GT init happens before PXP init and vice versa
for fini. This causes a minor ordering change whereby we previously
called intel_pxp_suspend after intel_uc_suspend but now is before
i915_gem_suspend_late but the change is required for correct
dependency flows. Additionally, this re-order change doesn't
have any impact because at that point in either case, the top level
entry to i915 won't observe any PXP events (since the GPU was
quiesced during suspend_prepare). Also, any PXP event doesn't
really matter when we disable the PXP HW (global GT irqs are
already off anyway, so even if there was a bug that generated
spurious events we wouldn't see it and we would just clean it
up on resume which is okay since the default fallback action
for PXP would be to keep the sessions off at this suspend stage).
Changes from prior revs:
v11: - Reformat a comment (Tvrtko).
v10: - Change the code flow for intel_pxp_init to make it more
cleaner and readible with better comments explaining the
difference between full-PXP-feature vs the partial-teelink
inits depending on the platform. Additionally, only do
the pxp allocation when we are certain the subsystem is
needed. (Tvrtko).
v9: - Cosmetic cleanups in supported/enabled/active. (Daniele).
- Add comments for intel_pxp_init and pxp_get_ctrl_gt that
explain the functional flow for when PXP is not supported
but the backend-assets are needed for HuC authentication
(Daniele and Tvrtko).
- Fix two remaining functions that are accessible outside
PXP that need to be checking pxp ptrs before using them:
intel_pxp_irq_handler and intel_pxp_huc_load_and_auth
(Tvrtko and Daniele).
- User helper macro in pxp-debugfs (Tvrtko).
v8: - Remove pxp_to_gt macro (Daniele).
- Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't
support GSC-FW on it. (Daniele).
- Leave i915->pxp as NULL if we dont support PXP and in line
with that, do additional validity check on i915->pxp for
intel_pxp_is_supported/enabled/active (Daniele).
- Remove unncessary include header from intel_gt_debugfs.c
and check drm_minor i915->drm.primary (Daniele).
- Other cosmetics / minor issues / more comments on suspend
flow order change (Daniele).
v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
through out instead of local variable newpxp. (Rodrigo)
- In the case intel_pxp_fini is called during driver unload but
after i915 loading failed without pxp being allocated, check
i915->pxp before referencing it. (Alan)
v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
because : [1] introduction of 'ctrl_gt' means we correct this
for MTL's upcoming series now. [2] Also, this has little impact
globally as its only used by PXP-internal callers at the moment.
- Change intel_pxp_init/fini to take in i915 as its input to avoid
ptr-to-ptr in init/fini calls.(Jani).
- Remove the backpointer from pxp->i915 since we can use
pxp->ctrl_gt->i915 if we need it. (Rodrigo).
v5: - Switch from series to single patch (Rodrigo).
- change function name from pxp_get_kcr_owner_gt to
pxp_get_ctrl_gt.
- Fix CI BAT failure by removing redundant call to intel_pxp_fini
from driver-remove.
- NOTE: remaining open still persists on using ptr-to-ptr
and back-ptr.
v4: - Instead of maintaining intel_pxp as an intel_gt structure member
and creating a number of convoluted helpers that takes in i915 as
input and redirects to the correct intel_gt or takes any intel_gt
and internally replaces with the correct intel_gt, promote it to
be a top-level i915 structure.
v3: - Rename gt level helper functions to "intel_pxp_is_enabled/
supported/ active_on_gt" (Daniele)
- Upgrade _gt_supports_pxp to replace what was intel_gtpxp_is
supported as the new intel_pxp_is_supported_on_gt to check for
PXP feature support vs the tee support for huc authentication.
Fix pxp-debugfs-registration to use only the former to decide
support. (Daniele)
- Couple minor optimizations.
v2: - Avoid introduction of new device info or gt variables and use
existing checks / macros to differentiate the correct GT->PXP
control ownership (Daniele Ceraolo Spurio)
- Don't reuse the updated global-checkers for per-GT callers (such
as other files within PXP) to avoid unnecessary GT-reparsing,
expose a replacement helper like the prior ones. (Daniele).
v1: - Add one more patch to the series for the intel_pxp suspend/resume
for similar refactoring
References: https://patchwork.freedesktop.org/patch/msgid/20221202011407.4068371-1-alan.previn.teres.alexis@intel.com
Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221208180542.998148-1-alan.previn.teres.alexis@intel.com
2022-12-08 10:05:42 -08:00
|
|
|
intel_pxp_suspend_prepare(i915->pxp);
|
|
|
|
|
2018-05-25 10:26:29 +01:00
|
|
|
/*
|
2023-04-14 12:42:01 +03:00
|
|
|
* NB intel_display_driver_suspend() may issue new requests after we've
|
2018-05-25 10:26:29 +01:00
|
|
|
* ostensibly marked the GPU as ready-to-sleep here. We need to
|
|
|
|
* split out that work and pull it forward so that after point,
|
|
|
|
* the GPU is not woken again.
|
|
|
|
*/
|
2021-09-22 08:25:22 +02:00
|
|
|
return i915_gem_backup_suspend(i915);
|
2018-05-25 10:26:29 +01:00
|
|
|
}
|
|
|
|
|
2014-10-23 19:23:25 +03:00
|
|
|
static int i915_drm_suspend(struct drm_device *dev)
|
2007-11-22 14:14:14 +10:00
|
|
|
{
|
2016-07-04 11:34:36 +01:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2025-05-07 18:22:54 +03:00
|
|
|
struct intel_display *display = dev_priv->display;
|
2021-01-28 14:31:23 +01:00
|
|
|
struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
|
2014-06-12 08:35:47 -07:00
|
|
|
pci_power_t opregion_target_state;
|
2010-02-18 23:06:27 +01:00
|
|
|
|
2019-06-13 16:21:51 -07:00
|
|
|
disable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
|
2015-12-16 02:52:19 +02:00
|
|
|
|
2013-08-19 13:18:09 -03:00
|
|
|
/* We do a lot of poking in a lot of registers, make sure they work
|
|
|
|
* properly. */
|
2024-11-28 17:38:23 +02:00
|
|
|
intel_power_domains_disable(display);
|
2024-12-12 18:08:42 +01:00
|
|
|
drm_client_dev_suspend(dev, false);
|
2024-01-04 15:23:35 +02:00
|
|
|
if (HAS_DISPLAY(dev_priv)) {
|
drm/i915: skip display initialization when there is no display
Display features should not be initialized or de-initialized when there
is no display. Skip modeset initialization, output setup, plane, crtc,
encoder, connector registration, display cdclk and rawclk
initialization, display core initialization, etc.
Skip the functionality at as high level as possible, and remove any
redundant checks. If the functionality is conditional to *other* display
checks, do not add more. If the un-initialization has checks for
initialization, do not add more.
We explicitly do not care about any GMCH/VLV/CHV code paths, as they've
always had and will have display.
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-3-jose.souza@intel.com
2021-04-08 13:31:50 -07:00
|
|
|
drm_kms_helper_poll_disable(dev);
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_disable_user_access(display);
|
2024-01-04 15:23:35 +02:00
|
|
|
}
|
2010-12-07 09:20:40 +10:00
|
|
|
|
2016-08-22 13:32:44 +03:00
|
|
|
pci_save_state(pdev);
|
2007-11-22 14:14:14 +10:00
|
|
|
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_suspend(display);
|
2014-11-19 15:30:05 +02:00
|
|
|
|
2024-09-12 13:25:39 -04:00
|
|
|
intel_irq_suspend(dev_priv);
|
2025-03-20 16:45:59 +02:00
|
|
|
intel_hpd_cancel_work(display);
|
2014-07-23 14:25:24 +10:00
|
|
|
|
2024-01-04 15:23:35 +02:00
|
|
|
if (HAS_DISPLAY(dev_priv))
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_suspend_access(display);
|
2024-01-04 15:23:35 +02:00
|
|
|
|
2025-05-07 12:38:35 +03:00
|
|
|
intel_encoder_suspend_all(display);
|
2014-05-02 14:02:48 +10:00
|
|
|
|
2021-11-01 20:35:51 +02:00
|
|
|
/* Must be called before GGTT is suspended. */
|
2025-02-25 18:49:09 +02:00
|
|
|
intel_dpt_suspend(display);
|
2022-01-05 00:35:50 +02:00
|
|
|
i915_ggtt_suspend(to_gt(dev_priv)->ggtt);
|
2013-10-16 09:21:30 -07:00
|
|
|
|
2024-11-26 12:12:22 +02:00
|
|
|
i9xx_display_sr_save(display);
|
2009-06-22 18:05:12 -07:00
|
|
|
|
2015-11-18 17:32:30 +02:00
|
|
|
opregion_target_state = suspend_to_idle(dev_priv) ? PCI_D1 : PCI_D3cold;
|
2024-08-09 17:27:05 +03:00
|
|
|
intel_opregion_suspend(display, opregion_target_state);
|
2008-08-05 19:37:25 +01:00
|
|
|
|
2014-02-25 17:11:28 +02:00
|
|
|
dev_priv->suspend_count++;
|
|
|
|
|
2024-09-06 17:33:06 +03:00
|
|
|
intel_dmc_suspend(display);
|
2015-10-28 23:59:06 +02:00
|
|
|
|
2019-06-13 16:21:51 -07:00
|
|
|
enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
|
2015-12-16 02:52:19 +02:00
|
|
|
|
2022-06-29 06:47:21 -07:00
|
|
|
i915_gem_drain_freed_objects(dev_priv);
|
|
|
|
|
2018-05-25 10:26:29 +01:00
|
|
|
return 0;
|
2010-02-07 21:48:24 +01:00
|
|
|
}
|
|
|
|
|
2016-08-22 13:32:42 +03:00
|
|
|
static int i915_drm_suspend_late(struct drm_device *dev, bool hibernation)
|
2014-10-23 19:23:15 +03:00
|
|
|
{
|
2016-08-22 13:32:42 +03:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2025-05-07 18:22:54 +03:00
|
|
|
struct intel_display *display = dev_priv->display;
|
2021-01-28 14:31:23 +01:00
|
|
|
struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
|
2019-06-13 16:21:53 -07:00
|
|
|
struct intel_runtime_pm *rpm = &dev_priv->runtime_pm;
|
2022-09-06 16:49:29 -07:00
|
|
|
struct intel_gt *gt;
|
|
|
|
int ret, i;
|
2023-05-29 13:59:00 +03:00
|
|
|
bool s2idle = !hibernation && suspend_to_idle(dev_priv);
|
2014-10-23 19:23:15 +03:00
|
|
|
|
2019-06-13 16:21:53 -07:00
|
|
|
disable_rpm_wakeref_asserts(rpm);
|
2015-12-16 02:52:19 +02:00
|
|
|
|
drm/i915/pxp: Promote pxp subsystem to top-level of i915
Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pertaining to PXP
operation (such as creating the arbitration session and session
tear-down).
PXP as a global feature is accessible via batch buffer instructions
on any engine/tile and the coherency across tiles is handled implicitly
by the HW. In fact, for the foreseeable future, we are expecting this
single-control-tile for the PXP subsystem.
In MTL, it's the standalone media tile (not the root tile) because
it contains the VDBOX and KCR engine (among the assets PXP relies on
for those events).
Looking at the current code design, each tile is represented by the
intel_gt structure while the intel_pxp structure currently hangs off the
intel_gt structure.
Keeping the intel_pxp structure within the intel_gt structure makes some
internal functionalities more straight forward but adds code complexity to
code readability and maintainibility to many external-to-pxp subsystems
which may need to pick the correct intel_gt structure. An example of this
would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
which should be viewed as a global level inquiry, not a per-gt inquiry.
That said, this series promotes the intel_pxp structure into the
drm_i915_private structure making it a top-level subsystem and the PXP
subsystem will select the control gt internally and keep a pointer to
it for internal reference.
This promotion comes with two noteworthy changes:
1. Exported pxp functions that are called by external subsystems
(such as intel_pxp_enabled/active) will have to check implicitly
if i915->pxp is valid as that structure will not be allocated
for HW that doesn't support PXP.
2. Since GT is now considered a soft-dependency of PXP we are
ensuring that GT init happens before PXP init and vice versa
for fini. This causes a minor ordering change whereby we previously
called intel_pxp_suspend after intel_uc_suspend but now is before
i915_gem_suspend_late but the change is required for correct
dependency flows. Additionally, this re-order change doesn't
have any impact because at that point in either case, the top level
entry to i915 won't observe any PXP events (since the GPU was
quiesced during suspend_prepare). Also, any PXP event doesn't
really matter when we disable the PXP HW (global GT irqs are
already off anyway, so even if there was a bug that generated
spurious events we wouldn't see it and we would just clean it
up on resume which is okay since the default fallback action
for PXP would be to keep the sessions off at this suspend stage).
Changes from prior revs:
v11: - Reformat a comment (Tvrtko).
v10: - Change the code flow for intel_pxp_init to make it more
cleaner and readible with better comments explaining the
difference between full-PXP-feature vs the partial-teelink
inits depending on the platform. Additionally, only do
the pxp allocation when we are certain the subsystem is
needed. (Tvrtko).
v9: - Cosmetic cleanups in supported/enabled/active. (Daniele).
- Add comments for intel_pxp_init and pxp_get_ctrl_gt that
explain the functional flow for when PXP is not supported
but the backend-assets are needed for HuC authentication
(Daniele and Tvrtko).
- Fix two remaining functions that are accessible outside
PXP that need to be checking pxp ptrs before using them:
intel_pxp_irq_handler and intel_pxp_huc_load_and_auth
(Tvrtko and Daniele).
- User helper macro in pxp-debugfs (Tvrtko).
v8: - Remove pxp_to_gt macro (Daniele).
- Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't
support GSC-FW on it. (Daniele).
- Leave i915->pxp as NULL if we dont support PXP and in line
with that, do additional validity check on i915->pxp for
intel_pxp_is_supported/enabled/active (Daniele).
- Remove unncessary include header from intel_gt_debugfs.c
and check drm_minor i915->drm.primary (Daniele).
- Other cosmetics / minor issues / more comments on suspend
flow order change (Daniele).
v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
through out instead of local variable newpxp. (Rodrigo)
- In the case intel_pxp_fini is called during driver unload but
after i915 loading failed without pxp being allocated, check
i915->pxp before referencing it. (Alan)
v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
because : [1] introduction of 'ctrl_gt' means we correct this
for MTL's upcoming series now. [2] Also, this has little impact
globally as its only used by PXP-internal callers at the moment.
- Change intel_pxp_init/fini to take in i915 as its input to avoid
ptr-to-ptr in init/fini calls.(Jani).
- Remove the backpointer from pxp->i915 since we can use
pxp->ctrl_gt->i915 if we need it. (Rodrigo).
v5: - Switch from series to single patch (Rodrigo).
- change function name from pxp_get_kcr_owner_gt to
pxp_get_ctrl_gt.
- Fix CI BAT failure by removing redundant call to intel_pxp_fini
from driver-remove.
- NOTE: remaining open still persists on using ptr-to-ptr
and back-ptr.
v4: - Instead of maintaining intel_pxp as an intel_gt structure member
and creating a number of convoluted helpers that takes in i915 as
input and redirects to the correct intel_gt or takes any intel_gt
and internally replaces with the correct intel_gt, promote it to
be a top-level i915 structure.
v3: - Rename gt level helper functions to "intel_pxp_is_enabled/
supported/ active_on_gt" (Daniele)
- Upgrade _gt_supports_pxp to replace what was intel_gtpxp_is
supported as the new intel_pxp_is_supported_on_gt to check for
PXP feature support vs the tee support for huc authentication.
Fix pxp-debugfs-registration to use only the former to decide
support. (Daniele)
- Couple minor optimizations.
v2: - Avoid introduction of new device info or gt variables and use
existing checks / macros to differentiate the correct GT->PXP
control ownership (Daniele Ceraolo Spurio)
- Don't reuse the updated global-checkers for per-GT callers (such
as other files within PXP) to avoid unnecessary GT-reparsing,
expose a replacement helper like the prior ones. (Daniele).
v1: - Add one more patch to the series for the intel_pxp suspend/resume
for similar refactoring
References: https://patchwork.freedesktop.org/patch/msgid/20221202011407.4068371-1-alan.previn.teres.alexis@intel.com
Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221208180542.998148-1-alan.previn.teres.alexis@intel.com
2022-12-08 10:05:42 -08:00
|
|
|
intel_pxp_suspend(dev_priv->pxp);
|
|
|
|
|
2018-05-31 09:22:46 +01:00
|
|
|
i915_gem_suspend_late(dev_priv);
|
|
|
|
|
2022-09-06 16:49:29 -07:00
|
|
|
for_each_gt(gt, dev_priv, i)
|
|
|
|
intel_uncore_suspend(gt->uncore);
|
2016-10-13 14:34:06 +03:00
|
|
|
|
2024-11-28 17:38:23 +02:00
|
|
|
intel_display_power_suspend_late(display, s2idle);
|
2019-08-06 15:22:08 +03:00
|
|
|
|
2020-02-12 16:40:57 +02:00
|
|
|
ret = vlv_suspend_complete(dev_priv);
|
2014-10-23 19:23:15 +03:00
|
|
|
if (ret) {
|
drm/i915: conversion to drm_device logging macros when drm_i915_private is present.
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Instances of the DRM_DEBUG macro were not converted due to lack of a
consensus of an analogous struct drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
2020-01-31 12:34:12 +03:00
|
|
|
drm_err(&dev_priv->drm, "Suspend complete failed: %d\n", ret);
|
2024-11-28 17:38:23 +02:00
|
|
|
intel_display_power_resume_early(display);
|
2014-10-23 19:23:15 +03:00
|
|
|
|
2015-12-16 02:52:19 +02:00
|
|
|
goto out;
|
2014-10-23 19:23:15 +03:00
|
|
|
}
|
|
|
|
|
2016-08-22 13:32:44 +03:00
|
|
|
pci_disable_device(pdev);
|
2015-03-02 13:04:41 +02:00
|
|
|
/*
|
2015-06-30 17:06:47 +03:00
|
|
|
* During hibernation on some platforms the BIOS may try to access
|
2015-03-02 13:04:41 +02:00
|
|
|
* the device even though it's already in D3 and hang the machine. So
|
|
|
|
* leave the device in D0 on those platforms and hope the BIOS will
|
2015-06-30 17:06:47 +03:00
|
|
|
* power down the device properly. The issue was seen on multiple old
|
|
|
|
* GENs with different BIOS vendors, so having an explicit blacklist
|
2025-01-20 13:45:17 +05:30
|
|
|
* is impractical; apply the workaround on everything pre GEN6. The
|
2015-06-30 17:06:47 +03:00
|
|
|
* platforms where the issue was seen:
|
|
|
|
* Lenovo Thinkpad X301, X61s, X60, T60, X41
|
|
|
|
* Fujitsu FSC S7110
|
|
|
|
* Acer Aspire 1830T
|
2015-03-02 13:04:41 +02:00
|
|
|
*/
|
2021-06-05 21:50:49 -07:00
|
|
|
if (!(hibernation && GRAPHICS_VER(dev_priv) < 6))
|
2016-08-22 13:32:44 +03:00
|
|
|
pci_set_power_state(pdev, PCI_D3hot);
|
2014-10-23 19:23:15 +03:00
|
|
|
|
2015-12-16 02:52:19 +02:00
|
|
|
out:
|
2019-06-13 16:21:53 -07:00
|
|
|
enable_rpm_wakeref_asserts(rpm);
|
2019-08-09 07:31:16 +01:00
|
|
|
if (!dev_priv->uncore.user_forcewake_count)
|
2019-07-12 13:24:28 +02:00
|
|
|
intel_runtime_pm_driver_release(rpm);
|
2015-12-16 02:52:19 +02:00
|
|
|
|
|
|
|
return ret;
|
2014-10-23 19:23:15 +03:00
|
|
|
}
|
|
|
|
|
2021-11-11 12:13:04 +02:00
|
|
|
int i915_driver_suspend_switcheroo(struct drm_i915_private *i915,
|
|
|
|
pm_message_t state)
|
2010-02-07 21:48:24 +01:00
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
drm/i915: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
command: ls drivers/gpu/drm/i915/*.c | xargs spatch --sp-file \
<script> --linux-spacing --in-place
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-10-pankaj.laxminarayan.bharadiya@intel.com
2020-01-15 09:14:53 +05:30
|
|
|
if (drm_WARN_ON_ONCE(&i915->drm, state.event != PM_EVENT_SUSPEND &&
|
|
|
|
state.event != PM_EVENT_FREEZE))
|
2014-09-10 18:16:55 +03:00
|
|
|
return -EINVAL;
|
2010-12-07 09:20:40 +10:00
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
if (i915->drm.switch_power_state == DRM_SWITCH_POWER_OFF)
|
2010-12-07 09:20:40 +10:00
|
|
|
return 0;
|
2010-09-08 09:45:11 +01:00
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
error = i915_drm_suspend(&i915->drm);
|
2010-02-07 21:48:24 +01:00
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
return i915_drm_suspend_late(&i915->drm, false);
|
2007-11-22 14:14:14 +10:00
|
|
|
}
|
|
|
|
|
2014-10-23 19:23:25 +03:00
|
|
|
static int i915_drm_resume(struct drm_device *dev)
|
2014-04-01 19:55:22 +03:00
|
|
|
{
|
2016-07-04 11:34:36 +01:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2025-05-07 18:22:54 +03:00
|
|
|
struct intel_display *display = dev_priv->display;
|
2022-11-22 12:31:26 +05:30
|
|
|
struct intel_gt *gt;
|
|
|
|
int ret, i;
|
2013-09-12 18:06:43 -03:00
|
|
|
|
2019-06-13 16:21:51 -07:00
|
|
|
disable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
|
2015-12-16 02:52:19 +02:00
|
|
|
|
2022-05-25 06:19:18 -07:00
|
|
|
ret = i915_pcode_init(dev_priv);
|
2021-07-27 23:03:38 +05:30
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2019-12-28 11:12:55 +00:00
|
|
|
sanitize_gpu(dev_priv);
|
|
|
|
|
2016-08-04 07:52:22 +01:00
|
|
|
ret = i915_ggtt_enable_hw(dev_priv);
|
2016-05-06 21:35:55 +03:00
|
|
|
if (ret)
|
drm/i915: conversion to drm_device logging macros when drm_i915_private is present.
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Instances of the DRM_DEBUG macro were not converted due to lack of a
consensus of an analogous struct drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
2020-01-31 12:34:12 +03:00
|
|
|
drm_err(&dev_priv->drm, "failed to re-enable GGTT\n");
|
2016-05-06 21:35:55 +03:00
|
|
|
|
2022-01-05 00:35:50 +02:00
|
|
|
i915_ggtt_resume(to_gt(dev_priv)->ggtt);
|
2022-11-22 12:31:26 +05:30
|
|
|
|
|
|
|
for_each_gt(gt, dev_priv, i)
|
|
|
|
if (GRAPHICS_VER(gt->i915) >= 8)
|
|
|
|
setup_private_pat(gt);
|
|
|
|
|
2021-11-01 20:35:51 +02:00
|
|
|
/* Must be called after GGTT is resumed. */
|
2025-02-25 18:49:09 +02:00
|
|
|
intel_dpt_resume(display);
|
2019-09-09 12:00:08 +01:00
|
|
|
|
2024-09-06 17:33:06 +03:00
|
|
|
intel_dmc_resume(display);
|
2016-04-18 14:48:21 +03:00
|
|
|
|
2024-11-26 12:12:22 +02:00
|
|
|
i9xx_display_sr_restore(display);
|
2024-11-13 17:50:10 -05:00
|
|
|
|
|
|
|
intel_gmbus_reset(display);
|
|
|
|
|
2024-08-30 13:15:45 +03:00
|
|
|
intel_pps_unlock_regs_wa(display);
|
2010-02-18 23:06:27 +01:00
|
|
|
|
2025-03-21 12:52:56 +02:00
|
|
|
intel_init_pch_refclk(display);
|
2012-05-09 11:56:28 +01:00
|
|
|
|
2015-05-11 08:50:45 +01:00
|
|
|
/*
|
|
|
|
* Interrupts have to be enabled before any batches are run. If not the
|
|
|
|
* GPU will hang. i915_gem_init_hw() will initiate batches to
|
|
|
|
* update/restore the context.
|
|
|
|
*
|
2016-11-29 21:40:29 +02:00
|
|
|
* drm_mode_config_reset() needs AUX interrupts.
|
|
|
|
*
|
2023-04-14 12:41:58 +03:00
|
|
|
* Modeset enabling in intel_display_driver_init_hw() also needs working
|
2015-05-11 08:50:45 +01:00
|
|
|
* interrupts.
|
|
|
|
*/
|
2024-09-12 13:25:39 -04:00
|
|
|
intel_irq_resume(dev_priv);
|
2015-05-11 08:50:45 +01:00
|
|
|
|
drm/i915: skip display initialization when there is no display
Display features should not be initialized or de-initialized when there
is no display. Skip modeset initialization, output setup, plane, crtc,
encoder, connector registration, display cdclk and rawclk
initialization, display core initialization, etc.
Skip the functionality at as high level as possible, and remove any
redundant checks. If the functionality is conditional to *other* display
checks, do not add more. If the un-initialization has checks for
initialization, do not add more.
We explicitly do not care about any GMCH/VLV/CHV code paths, as they've
always had and will have display.
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-3-jose.souza@intel.com
2021-04-08 13:31:50 -07:00
|
|
|
if (HAS_DISPLAY(dev_priv))
|
|
|
|
drm_mode_config_reset(dev);
|
2016-11-29 21:40:29 +02:00
|
|
|
|
2017-11-12 11:27:38 +00:00
|
|
|
i915_gem_resume(dev_priv);
|
2009-02-23 15:41:09 -08:00
|
|
|
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_init_hw(display);
|
2023-04-14 12:41:58 +03:00
|
|
|
|
2023-04-03 15:24:27 +03:00
|
|
|
intel_clock_gating_init(dev_priv);
|
2024-01-04 15:23:35 +02:00
|
|
|
|
|
|
|
if (HAS_DISPLAY(dev_priv))
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_resume_access(display);
|
2024-01-04 15:23:35 +02:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
intel_hpd_init(display);
|
2013-03-26 09:25:45 -07:00
|
|
|
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_resume(display);
|
2016-03-11 10:57:01 -05:00
|
|
|
|
2024-01-04 15:23:35 +02:00
|
|
|
if (HAS_DISPLAY(dev_priv)) {
|
2024-12-04 12:21:50 +02:00
|
|
|
intel_display_driver_enable_user_access(display);
|
drm/i915: skip display initialization when there is no display
Display features should not be initialized or de-initialized when there
is no display. Skip modeset initialization, output setup, plane, crtc,
encoder, connector registration, display cdclk and rawclk
initialization, display core initialization, etc.
Skip the functionality at as high level as possible, and remove any
redundant checks. If the functionality is conditional to *other* display
checks, do not add more. If the un-initialization has checks for
initialization, do not add more.
We explicitly do not care about any GMCH/VLV/CHV code paths, as they've
always had and will have display.
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-3-jose.souza@intel.com
2021-04-08 13:31:50 -07:00
|
|
|
drm_kms_helper_poll_enable(dev);
|
2024-01-04 15:23:35 +02:00
|
|
|
}
|
2025-03-20 16:45:59 +02:00
|
|
|
intel_hpd_poll_disable(display);
|
2016-11-01 21:06:30 -04:00
|
|
|
|
2024-08-09 17:27:05 +03:00
|
|
|
intel_opregion_resume(display);
|
2010-08-19 16:09:23 +01:00
|
|
|
|
2024-12-12 18:08:42 +01:00
|
|
|
drm_client_dev_resume(dev, false);
|
2012-11-02 11:13:59 -07:00
|
|
|
|
2024-11-28 17:38:23 +02:00
|
|
|
intel_power_domains_enable(display);
|
2018-08-16 15:37:57 +03:00
|
|
|
|
2020-10-27 12:54:06 +08:00
|
|
|
intel_gvt_resume(dev_priv);
|
|
|
|
|
2019-06-13 16:21:51 -07:00
|
|
|
enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
|
2015-12-16 02:52:19 +02:00
|
|
|
|
2014-04-09 09:19:43 +01:00
|
|
|
return 0;
|
2010-02-07 21:48:24 +01:00
|
|
|
}
|
|
|
|
|
2014-10-23 19:23:25 +03:00
|
|
|
static int i915_drm_resume_early(struct drm_device *dev)
|
2010-02-07 21:48:24 +01:00
|
|
|
{
|
2016-07-04 11:34:36 +01:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2025-05-07 18:22:54 +03:00
|
|
|
struct intel_display *display = dev_priv->display;
|
2021-01-28 14:31:23 +01:00
|
|
|
struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
|
2022-09-06 16:49:29 -07:00
|
|
|
struct intel_gt *gt;
|
|
|
|
int ret, i;
|
2014-10-23 19:23:24 +03:00
|
|
|
|
2014-04-01 19:55:22 +03:00
|
|
|
/*
|
|
|
|
* We have a resume ordering issue with the snd-hda driver also
|
|
|
|
* requiring our device to be power up. Due to the lack of a
|
|
|
|
* parent/child relationship we currently solve this with an early
|
|
|
|
* resume hook.
|
|
|
|
*
|
|
|
|
* FIXME: This should be solved with a special hdmi sink device or
|
|
|
|
* similar so that power domains can be employed.
|
|
|
|
*/
|
2016-04-18 14:45:54 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Note that we need to set the power state explicitly, since we
|
|
|
|
* powered off the device during freeze and the PCI core won't power
|
|
|
|
* it back up for us during thaw. Powering off the device during
|
|
|
|
* freeze is not a hard requirement though, and during the
|
|
|
|
* suspend/resume phases the PCI core makes sure we get here with the
|
|
|
|
* device powered on. So in case we change our freeze logic and keep
|
|
|
|
* the device powered we can also remove the following set power state
|
|
|
|
* call.
|
|
|
|
*/
|
2016-08-22 13:32:44 +03:00
|
|
|
ret = pci_set_power_state(pdev, PCI_D0);
|
2016-04-18 14:45:54 +03:00
|
|
|
if (ret) {
|
drm/i915: conversion to drm_device logging macros when drm_i915_private is present.
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Instances of the DRM_DEBUG macro were not converted due to lack of a
consensus of an analogous struct drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
2020-01-31 12:34:12 +03:00
|
|
|
drm_err(&dev_priv->drm,
|
|
|
|
"failed to set PCI D0 power state (%d)\n", ret);
|
2018-08-16 15:37:57 +03:00
|
|
|
return ret;
|
2016-04-18 14:45:54 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note that pci_enable_device() first enables any parent bridge
|
|
|
|
* device and only then sets the power state for this device. The
|
|
|
|
* bridge enabling is a nop though, since bridge devices are resumed
|
|
|
|
* first. The order of enabling power and enabling the device is
|
|
|
|
* imposed by the PCI core as described above, so here we preserve the
|
|
|
|
* same order for the freeze/thaw phases.
|
|
|
|
*
|
|
|
|
* TODO: eventually we should remove pci_disable_device() /
|
|
|
|
* pci_enable_enable_device() from suspend/resume. Due to how they
|
|
|
|
* depend on the device enable refcount we can't anyway depend on them
|
|
|
|
* disabling/enabling the device.
|
|
|
|
*/
|
2018-08-16 15:37:57 +03:00
|
|
|
if (pci_enable_device(pdev))
|
|
|
|
return -EIO;
|
2010-02-07 21:48:24 +01:00
|
|
|
|
2016-08-22 13:32:44 +03:00
|
|
|
pci_set_master(pdev);
|
2010-02-07 21:48:24 +01:00
|
|
|
|
2019-06-13 16:21:51 -07:00
|
|
|
disable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
|
2015-12-16 02:52:19 +02:00
|
|
|
|
2020-02-12 16:40:57 +02:00
|
|
|
ret = vlv_resume_prepare(dev_priv, false);
|
2014-10-23 19:23:24 +03:00
|
|
|
if (ret)
|
drm/i915: conversion to drm_device logging macros when drm_i915_private is present.
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Instances of the DRM_DEBUG macro were not converted due to lack of a
consensus of an analogous struct drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
2020-01-31 12:34:12 +03:00
|
|
|
drm_err(&dev_priv->drm,
|
2020-02-12 16:40:57 +02:00
|
|
|
"Resume prepare failed: %d, continuing anyway\n", ret);
|
2014-10-23 19:23:24 +03:00
|
|
|
|
2023-09-28 15:00:13 +02:00
|
|
|
for_each_gt(gt, dev_priv, i)
|
|
|
|
intel_gt_resume_early(gt);
|
2014-10-27 17:54:33 -02:00
|
|
|
|
2024-11-28 17:38:23 +02:00
|
|
|
intel_display_power_resume_early(display);
|
2014-10-27 17:54:33 -02:00
|
|
|
|
2019-06-13 16:21:51 -07:00
|
|
|
enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
|
2016-04-18 10:04:19 +03:00
|
|
|
|
2014-10-23 19:23:24 +03:00
|
|
|
return ret;
|
2014-04-01 19:55:22 +03:00
|
|
|
}
|
|
|
|
|
2021-11-11 12:13:04 +02:00
|
|
|
int i915_driver_resume_switcheroo(struct drm_i915_private *i915)
|
2014-04-01 19:55:22 +03:00
|
|
|
{
|
2014-10-23 19:23:17 +03:00
|
|
|
int ret;
|
2014-04-01 19:55:22 +03:00
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
if (i915->drm.switch_power_state == DRM_SWITCH_POWER_OFF)
|
2014-10-23 19:23:19 +03:00
|
|
|
return 0;
|
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
ret = i915_drm_resume_early(&i915->drm);
|
2014-10-23 19:23:17 +03:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
return i915_drm_resume(&i915->drm);
|
2014-10-23 19:23:18 +03:00
|
|
|
}
|
|
|
|
|
2018-05-25 10:26:29 +01:00
|
|
|
static int i915_pm_prepare(struct device *kdev)
|
|
|
|
{
|
2019-08-06 08:42:19 +01:00
|
|
|
struct drm_i915_private *i915 = kdev_to_i915(kdev);
|
2018-05-25 10:26:29 +01:00
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
if (!i915) {
|
2018-05-25 10:26:29 +01:00
|
|
|
dev_err(kdev, "DRM not initialized, aborting suspend.\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
if (i915->drm.switch_power_state == DRM_SWITCH_POWER_OFF)
|
2018-05-25 10:26:29 +01:00
|
|
|
return 0;
|
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
return i915_drm_prepare(&i915->drm);
|
2018-05-25 10:26:29 +01:00
|
|
|
}
|
|
|
|
|
2016-08-22 13:32:42 +03:00
|
|
|
static int i915_pm_suspend(struct device *kdev)
|
2009-01-04 16:55:33 -05:00
|
|
|
{
|
2019-08-06 08:42:19 +01:00
|
|
|
struct drm_i915_private *i915 = kdev_to_i915(kdev);
|
2009-01-04 16:55:33 -05:00
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
if (!i915) {
|
2016-08-22 13:32:42 +03:00
|
|
|
dev_err(kdev, "DRM not initialized, aborting suspend.\n");
|
2010-02-07 21:48:24 +01:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
2009-01-04 16:55:33 -05:00
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
if (i915->drm.switch_power_state == DRM_SWITCH_POWER_OFF)
|
2010-12-07 09:20:40 +10:00
|
|
|
return 0;
|
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
return i915_drm_suspend(&i915->drm);
|
2014-04-01 19:55:22 +03:00
|
|
|
}
|
|
|
|
|
2016-08-22 13:32:42 +03:00
|
|
|
static int i915_pm_suspend_late(struct device *kdev)
|
2014-04-01 19:55:22 +03:00
|
|
|
{
|
2019-08-06 08:42:19 +01:00
|
|
|
struct drm_i915_private *i915 = kdev_to_i915(kdev);
|
2014-04-01 19:55:22 +03:00
|
|
|
|
|
|
|
/*
|
2015-05-18 19:53:48 +01:00
|
|
|
* We have a suspend ordering issue with the snd-hda driver also
|
2014-04-01 19:55:22 +03:00
|
|
|
* requiring our device to be power up. Due to the lack of a
|
|
|
|
* parent/child relationship we currently solve this with an late
|
|
|
|
* suspend hook.
|
|
|
|
*
|
|
|
|
* FIXME: This should be solved with a special hdmi sink device or
|
|
|
|
* similar so that power domains can be employed.
|
|
|
|
*/
|
2019-08-06 08:42:19 +01:00
|
|
|
if (i915->drm.switch_power_state == DRM_SWITCH_POWER_OFF)
|
2014-04-01 19:55:22 +03:00
|
|
|
return 0;
|
2009-01-04 16:55:33 -05:00
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
return i915_drm_suspend_late(&i915->drm, false);
|
2015-03-02 13:04:41 +02:00
|
|
|
}
|
|
|
|
|
2016-08-22 13:32:42 +03:00
|
|
|
static int i915_pm_poweroff_late(struct device *kdev)
|
2015-03-02 13:04:41 +02:00
|
|
|
{
|
2019-08-06 08:42:19 +01:00
|
|
|
struct drm_i915_private *i915 = kdev_to_i915(kdev);
|
2015-03-02 13:04:41 +02:00
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
if (i915->drm.switch_power_state == DRM_SWITCH_POWER_OFF)
|
2015-03-02 13:04:41 +02:00
|
|
|
return 0;
|
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
return i915_drm_suspend_late(&i915->drm, true);
|
2009-12-16 13:36:10 +08:00
|
|
|
}
|
|
|
|
|
2016-08-22 13:32:42 +03:00
|
|
|
static int i915_pm_resume_early(struct device *kdev)
|
2014-04-01 19:55:22 +03:00
|
|
|
{
|
2019-08-06 08:42:19 +01:00
|
|
|
struct drm_i915_private *i915 = kdev_to_i915(kdev);
|
2014-04-01 19:55:22 +03:00
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
if (i915->drm.switch_power_state == DRM_SWITCH_POWER_OFF)
|
2014-10-23 19:23:19 +03:00
|
|
|
return 0;
|
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
return i915_drm_resume_early(&i915->drm);
|
2014-04-01 19:55:22 +03:00
|
|
|
}
|
|
|
|
|
2016-08-22 13:32:42 +03:00
|
|
|
static int i915_pm_resume(struct device *kdev)
|
2009-12-16 13:36:10 +08:00
|
|
|
{
|
2019-08-06 08:42:19 +01:00
|
|
|
struct drm_i915_private *i915 = kdev_to_i915(kdev);
|
2010-02-07 21:48:24 +01:00
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
if (i915->drm.switch_power_state == DRM_SWITCH_POWER_OFF)
|
2014-10-23 19:23:19 +03:00
|
|
|
return 0;
|
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
return i915_drm_resume(&i915->drm);
|
2009-12-16 13:36:10 +08:00
|
|
|
}
|
|
|
|
|
2023-01-25 00:26:37 -08:00
|
|
|
static void i915_pm_complete(struct device *kdev)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = kdev_to_i915(kdev);
|
|
|
|
|
|
|
|
if (i915->drm.switch_power_state == DRM_SWITCH_POWER_OFF)
|
|
|
|
return;
|
|
|
|
|
|
|
|
i915_drm_complete(&i915->drm);
|
|
|
|
}
|
|
|
|
|
2016-05-14 07:26:32 +01:00
|
|
|
/* freeze: before creating the hibernation_image */
|
2016-08-22 13:32:42 +03:00
|
|
|
static int i915_pm_freeze(struct device *kdev)
|
2016-05-14 07:26:32 +01:00
|
|
|
{
|
2019-08-06 08:42:19 +01:00
|
|
|
struct drm_i915_private *i915 = kdev_to_i915(kdev);
|
2016-09-21 14:51:07 +01:00
|
|
|
int ret;
|
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
if (i915->drm.switch_power_state != DRM_SWITCH_POWER_OFF) {
|
|
|
|
ret = i915_drm_suspend(&i915->drm);
|
2017-08-16 17:46:07 +03:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2016-09-21 14:51:07 +01:00
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
ret = i915_gem_freeze(i915);
|
2016-09-21 14:51:07 +01:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
return 0;
|
2016-05-14 07:26:32 +01:00
|
|
|
}
|
|
|
|
|
2016-08-22 13:32:42 +03:00
|
|
|
static int i915_pm_freeze_late(struct device *kdev)
|
2016-05-14 07:26:32 +01:00
|
|
|
{
|
2019-08-06 08:42:19 +01:00
|
|
|
struct drm_i915_private *i915 = kdev_to_i915(kdev);
|
2016-05-14 07:26:33 +01:00
|
|
|
int ret;
|
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
if (i915->drm.switch_power_state != DRM_SWITCH_POWER_OFF) {
|
|
|
|
ret = i915_drm_suspend_late(&i915->drm, true);
|
2017-08-16 17:46:07 +03:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2016-05-14 07:26:33 +01:00
|
|
|
|
2019-08-06 08:42:19 +01:00
|
|
|
ret = i915_gem_freeze_late(i915);
|
2016-05-14 07:26:33 +01:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
return 0;
|
2016-05-14 07:26:32 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* thaw: called after creating the hibernation image, but before turning off. */
|
2016-08-22 13:32:42 +03:00
|
|
|
static int i915_pm_thaw_early(struct device *kdev)
|
2016-05-14 07:26:32 +01:00
|
|
|
{
|
2016-08-22 13:32:42 +03:00
|
|
|
return i915_pm_resume_early(kdev);
|
2016-05-14 07:26:32 +01:00
|
|
|
}
|
|
|
|
|
2016-08-22 13:32:42 +03:00
|
|
|
static int i915_pm_thaw(struct device *kdev)
|
2016-05-14 07:26:32 +01:00
|
|
|
{
|
2016-08-22 13:32:42 +03:00
|
|
|
return i915_pm_resume(kdev);
|
2016-05-14 07:26:32 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* restore: called after loading the hibernation image. */
|
2016-08-22 13:32:42 +03:00
|
|
|
static int i915_pm_restore_early(struct device *kdev)
|
2016-05-14 07:26:32 +01:00
|
|
|
{
|
2016-08-22 13:32:42 +03:00
|
|
|
return i915_pm_resume_early(kdev);
|
2016-05-14 07:26:32 +01:00
|
|
|
}
|
|
|
|
|
2016-08-22 13:32:42 +03:00
|
|
|
static int i915_pm_restore(struct device *kdev)
|
2016-05-14 07:26:32 +01:00
|
|
|
{
|
2016-08-22 13:32:42 +03:00
|
|
|
return i915_pm_resume(kdev);
|
2016-05-14 07:26:32 +01:00
|
|
|
}
|
|
|
|
|
2016-08-22 13:32:42 +03:00
|
|
|
static int intel_runtime_suspend(struct device *kdev)
|
2013-12-06 20:32:13 -02:00
|
|
|
{
|
2019-08-06 08:42:19 +01:00
|
|
|
struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
|
2025-05-07 18:22:54 +03:00
|
|
|
struct intel_display *display = dev_priv->display;
|
2019-06-13 16:21:52 -07:00
|
|
|
struct intel_runtime_pm *rpm = &dev_priv->runtime_pm;
|
2023-08-16 18:22:16 +05:30
|
|
|
struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
|
|
|
|
struct pci_dev *root_pdev;
|
2022-09-06 16:49:29 -07:00
|
|
|
struct intel_gt *gt;
|
|
|
|
int ret, i;
|
2013-12-06 20:32:13 -02:00
|
|
|
|
drm/i915: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
command: ls drivers/gpu/drm/i915/*.c | xargs spatch --sp-file \
<script> --linux-spacing --in-place
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-10-pankaj.laxminarayan.bharadiya@intel.com
2020-01-15 09:14:53 +05:30
|
|
|
if (drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_RUNTIME_PM(dev_priv)))
|
2014-08-26 13:26:56 +03:00
|
|
|
return -ENODEV;
|
|
|
|
|
2022-05-11 18:34:54 +05:30
|
|
|
drm_dbg(&dev_priv->drm, "Suspending device\n");
|
2013-12-06 20:32:13 -02:00
|
|
|
|
2019-06-13 16:21:51 -07:00
|
|
|
disable_rpm_wakeref_asserts(rpm);
|
2015-12-16 02:52:19 +02:00
|
|
|
|
2014-05-07 19:57:49 +03:00
|
|
|
/*
|
|
|
|
* We are safe here against re-faults, since the fault handler takes
|
|
|
|
* an RPM reference.
|
|
|
|
*/
|
2016-10-24 13:42:18 +01:00
|
|
|
i915_gem_runtime_suspend(dev_priv);
|
2014-05-07 19:57:49 +03:00
|
|
|
|
drm/i915/pxp: Promote pxp subsystem to top-level of i915
Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pertaining to PXP
operation (such as creating the arbitration session and session
tear-down).
PXP as a global feature is accessible via batch buffer instructions
on any engine/tile and the coherency across tiles is handled implicitly
by the HW. In fact, for the foreseeable future, we are expecting this
single-control-tile for the PXP subsystem.
In MTL, it's the standalone media tile (not the root tile) because
it contains the VDBOX and KCR engine (among the assets PXP relies on
for those events).
Looking at the current code design, each tile is represented by the
intel_gt structure while the intel_pxp structure currently hangs off the
intel_gt structure.
Keeping the intel_pxp structure within the intel_gt structure makes some
internal functionalities more straight forward but adds code complexity to
code readability and maintainibility to many external-to-pxp subsystems
which may need to pick the correct intel_gt structure. An example of this
would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
which should be viewed as a global level inquiry, not a per-gt inquiry.
That said, this series promotes the intel_pxp structure into the
drm_i915_private structure making it a top-level subsystem and the PXP
subsystem will select the control gt internally and keep a pointer to
it for internal reference.
This promotion comes with two noteworthy changes:
1. Exported pxp functions that are called by external subsystems
(such as intel_pxp_enabled/active) will have to check implicitly
if i915->pxp is valid as that structure will not be allocated
for HW that doesn't support PXP.
2. Since GT is now considered a soft-dependency of PXP we are
ensuring that GT init happens before PXP init and vice versa
for fini. This causes a minor ordering change whereby we previously
called intel_pxp_suspend after intel_uc_suspend but now is before
i915_gem_suspend_late but the change is required for correct
dependency flows. Additionally, this re-order change doesn't
have any impact because at that point in either case, the top level
entry to i915 won't observe any PXP events (since the GPU was
quiesced during suspend_prepare). Also, any PXP event doesn't
really matter when we disable the PXP HW (global GT irqs are
already off anyway, so even if there was a bug that generated
spurious events we wouldn't see it and we would just clean it
up on resume which is okay since the default fallback action
for PXP would be to keep the sessions off at this suspend stage).
Changes from prior revs:
v11: - Reformat a comment (Tvrtko).
v10: - Change the code flow for intel_pxp_init to make it more
cleaner and readible with better comments explaining the
difference between full-PXP-feature vs the partial-teelink
inits depending on the platform. Additionally, only do
the pxp allocation when we are certain the subsystem is
needed. (Tvrtko).
v9: - Cosmetic cleanups in supported/enabled/active. (Daniele).
- Add comments for intel_pxp_init and pxp_get_ctrl_gt that
explain the functional flow for when PXP is not supported
but the backend-assets are needed for HuC authentication
(Daniele and Tvrtko).
- Fix two remaining functions that are accessible outside
PXP that need to be checking pxp ptrs before using them:
intel_pxp_irq_handler and intel_pxp_huc_load_and_auth
(Tvrtko and Daniele).
- User helper macro in pxp-debugfs (Tvrtko).
v8: - Remove pxp_to_gt macro (Daniele).
- Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't
support GSC-FW on it. (Daniele).
- Leave i915->pxp as NULL if we dont support PXP and in line
with that, do additional validity check on i915->pxp for
intel_pxp_is_supported/enabled/active (Daniele).
- Remove unncessary include header from intel_gt_debugfs.c
and check drm_minor i915->drm.primary (Daniele).
- Other cosmetics / minor issues / more comments on suspend
flow order change (Daniele).
v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
through out instead of local variable newpxp. (Rodrigo)
- In the case intel_pxp_fini is called during driver unload but
after i915 loading failed without pxp being allocated, check
i915->pxp before referencing it. (Alan)
v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
because : [1] introduction of 'ctrl_gt' means we correct this
for MTL's upcoming series now. [2] Also, this has little impact
globally as its only used by PXP-internal callers at the moment.
- Change intel_pxp_init/fini to take in i915 as its input to avoid
ptr-to-ptr in init/fini calls.(Jani).
- Remove the backpointer from pxp->i915 since we can use
pxp->ctrl_gt->i915 if we need it. (Rodrigo).
v5: - Switch from series to single patch (Rodrigo).
- change function name from pxp_get_kcr_owner_gt to
pxp_get_ctrl_gt.
- Fix CI BAT failure by removing redundant call to intel_pxp_fini
from driver-remove.
- NOTE: remaining open still persists on using ptr-to-ptr
and back-ptr.
v4: - Instead of maintaining intel_pxp as an intel_gt structure member
and creating a number of convoluted helpers that takes in i915 as
input and redirects to the correct intel_gt or takes any intel_gt
and internally replaces with the correct intel_gt, promote it to
be a top-level i915 structure.
v3: - Rename gt level helper functions to "intel_pxp_is_enabled/
supported/ active_on_gt" (Daniele)
- Upgrade _gt_supports_pxp to replace what was intel_gtpxp_is
supported as the new intel_pxp_is_supported_on_gt to check for
PXP feature support vs the tee support for huc authentication.
Fix pxp-debugfs-registration to use only the former to decide
support. (Daniele)
- Couple minor optimizations.
v2: - Avoid introduction of new device info or gt variables and use
existing checks / macros to differentiate the correct GT->PXP
control ownership (Daniele Ceraolo Spurio)
- Don't reuse the updated global-checkers for per-GT callers (such
as other files within PXP) to avoid unnecessary GT-reparsing,
expose a replacement helper like the prior ones. (Daniele).
v1: - Add one more patch to the series for the intel_pxp suspend/resume
for similar refactoring
References: https://patchwork.freedesktop.org/patch/msgid/20221202011407.4068371-1-alan.previn.teres.alexis@intel.com
Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221208180542.998148-1-alan.previn.teres.alexis@intel.com
2022-12-08 10:05:42 -08:00
|
|
|
intel_pxp_runtime_suspend(dev_priv->pxp);
|
|
|
|
|
2022-09-06 16:49:29 -07:00
|
|
|
for_each_gt(gt, dev_priv, i)
|
|
|
|
intel_gt_runtime_suspend(gt);
|
2015-09-30 09:46:37 -07:00
|
|
|
|
2024-09-12 13:25:39 -04:00
|
|
|
intel_irq_suspend(dev_priv);
|
2014-04-14 20:24:37 +03:00
|
|
|
|
2022-09-06 16:49:29 -07:00
|
|
|
for_each_gt(gt, dev_priv, i)
|
|
|
|
intel_uncore_suspend(gt->uncore);
|
2017-11-14 14:55:18 +01:00
|
|
|
|
2024-11-28 17:38:23 +02:00
|
|
|
intel_display_power_suspend(display);
|
2019-08-06 15:22:08 +03:00
|
|
|
|
2020-02-12 16:40:57 +02:00
|
|
|
ret = vlv_suspend_complete(dev_priv);
|
2014-04-15 16:39:45 +03:00
|
|
|
if (ret) {
|
drm/i915: conversion to drm_device logging macros when drm_i915_private is present.
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Instances of the DRM_DEBUG macro were not converted due to lack of a
consensus of an analogous struct drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
2020-01-31 12:34:12 +03:00
|
|
|
drm_err(&dev_priv->drm,
|
|
|
|
"Runtime suspend failed, disabling it (%d)\n", ret);
|
2019-03-19 11:35:37 -07:00
|
|
|
intel_uncore_runtime_resume(&dev_priv->uncore);
|
2017-11-14 14:55:18 +01:00
|
|
|
|
2024-09-12 13:25:39 -04:00
|
|
|
intel_irq_resume(dev_priv);
|
2014-04-15 16:39:45 +03:00
|
|
|
|
2022-09-15 16:26:54 -07:00
|
|
|
for_each_gt(gt, dev_priv, i)
|
|
|
|
intel_gt_runtime_resume(gt);
|
2018-01-24 21:16:57 +05:30
|
|
|
|
2019-06-13 16:21:51 -07:00
|
|
|
enable_rpm_wakeref_asserts(rpm);
|
2015-12-16 02:52:19 +02:00
|
|
|
|
2014-04-15 16:39:45 +03:00
|
|
|
return ret;
|
|
|
|
}
|
drm/i915: make PC8 be part of runtime PM suspend/resume
Currently, when our driver becomes idle for i915.pc8_timeout (default:
5s) we enable PC8, so we save some power, but not everything we can.
Then, while PC8 is enabled, if we stay idle for more
autosuspend_delay_ms (default: 10s) we'll enter runtime PM and put the
graphics device in D3 state, saving even more power. The two features
are separate things with increasing levels of power savings, but if we
disable PC8 we'll never get into D3.
While from the modularity point of view it would be nice to keep these
features as separate, we have reasons to merge them:
- We are not aware of anybody wanting a "PC8 without D3" environment.
- If we keep both features as separate, we'll have to to test both
PC8 and PC8+D3 code paths. We're already having a major pain to
make QA do automated testing of just one thing, testing both paths
will cost even more.
- Only Haswell+ supports PC8, so if we want to add runtime PM support
to, for example, IVB, we'll have to copy some code from the PC8
feature to runtime PM, so merging both features as a single thing
will make it easier for enabling runtime PM on other platforms.
This patch only does the very basic steps required to have PC8 and
runtime PM merged on a single feature: the next patches will take care
of cleaning up everything.
v2: - Rebase.
v3: - Rebase.
- Fully remove the deprecated i915 params since Daniel doesn't
consider them as part of the ABI.
v4: - Rebase.
- Fix typo in the commit message.
v5: - Rebase, again.
- Add a huge comment explaining the different forcewake usage
(Chris, Daniel).
- Use open-coded forcewake functions (Daniel).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07 20:08:05 -03:00
|
|
|
|
2019-06-13 16:21:51 -07:00
|
|
|
enable_rpm_wakeref_asserts(rpm);
|
2019-07-12 13:24:28 +02:00
|
|
|
intel_runtime_pm_driver_release(rpm);
|
2015-12-15 16:25:08 +02:00
|
|
|
|
2019-03-25 14:49:34 -07:00
|
|
|
if (intel_uncore_arm_unclaimed_mmio_detection(&dev_priv->uncore))
|
drm/i915: conversion to drm_device logging macros when drm_i915_private is present.
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Instances of the DRM_DEBUG macro were not converted due to lack of a
consensus of an analogous struct drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
2020-01-31 12:34:12 +03:00
|
|
|
drm_err(&dev_priv->drm,
|
|
|
|
"Unclaimed access detected prior to suspending\n");
|
2015-12-15 16:25:08 +02:00
|
|
|
|
2023-08-16 18:22:16 +05:30
|
|
|
/*
|
|
|
|
* FIXME: Temporary hammer to avoid freezing the machine on our DGFX
|
|
|
|
* This should be totally removed when we handle the pci states properly
|
|
|
|
* on runtime PM.
|
|
|
|
*/
|
|
|
|
root_pdev = pcie_find_root_port(pdev);
|
|
|
|
if (root_pdev)
|
|
|
|
pci_d3cold_disable(root_pdev);
|
|
|
|
|
2014-01-14 15:36:15 -08:00
|
|
|
/*
|
2014-08-21 17:09:38 -03:00
|
|
|
* FIXME: We really should find a document that references the arguments
|
|
|
|
* used below!
|
2014-01-14 15:36:15 -08:00
|
|
|
*/
|
2016-05-23 15:08:09 +01:00
|
|
|
if (IS_BROADWELL(dev_priv)) {
|
2015-07-30 18:20:29 -03:00
|
|
|
/*
|
|
|
|
* On Broadwell, if we use PCI_D1 the PCH DDI ports will stop
|
|
|
|
* being detected, and the call we do at intel_runtime_resume()
|
|
|
|
* won't be able to restore them. Since PCI_D3hot matches the
|
|
|
|
* actual specification and appears to be working, use it.
|
|
|
|
*/
|
2024-08-09 17:27:05 +03:00
|
|
|
intel_opregion_notify_adapter(display, PCI_D3hot);
|
2015-07-30 18:20:29 -03:00
|
|
|
} else {
|
2014-08-21 17:09:38 -03:00
|
|
|
/*
|
|
|
|
* current versions of firmware which depend on this opregion
|
|
|
|
* notification have repurposed the D1 definition to mean
|
|
|
|
* "runtime suspended" vs. what you would normally expect (D3)
|
|
|
|
* to distinguish it from notifications that might be sent via
|
|
|
|
* the suspend path.
|
|
|
|
*/
|
2024-08-09 17:27:05 +03:00
|
|
|
intel_opregion_notify_adapter(display, PCI_D1);
|
2014-08-21 17:09:38 -03:00
|
|
|
}
|
2013-12-06 20:32:13 -02:00
|
|
|
|
2019-03-19 11:35:35 -07:00
|
|
|
assert_forcewakes_inactive(&dev_priv->uncore);
|
2015-01-16 11:34:34 +02:00
|
|
|
|
2017-01-20 16:28:43 +02:00
|
|
|
if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
|
2025-03-20 16:45:59 +02:00
|
|
|
intel_hpd_poll_enable(display);
|
2016-06-21 17:03:44 -04:00
|
|
|
|
2022-05-11 18:34:54 +05:30
|
|
|
drm_dbg(&dev_priv->drm, "Device suspended\n");
|
2013-12-06 20:32:13 -02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-08-22 13:32:42 +03:00
|
|
|
static int intel_runtime_resume(struct device *kdev)
|
2013-12-06 20:32:13 -02:00
|
|
|
{
|
2019-08-06 08:42:19 +01:00
|
|
|
struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
|
2025-05-07 18:22:54 +03:00
|
|
|
struct intel_display *display = dev_priv->display;
|
2019-06-13 16:21:52 -07:00
|
|
|
struct intel_runtime_pm *rpm = &dev_priv->runtime_pm;
|
2023-08-16 18:22:16 +05:30
|
|
|
struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
|
|
|
|
struct pci_dev *root_pdev;
|
2022-09-06 16:49:29 -07:00
|
|
|
struct intel_gt *gt;
|
|
|
|
int ret, i;
|
2013-12-06 20:32:13 -02:00
|
|
|
|
drm/i915: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
command: ls drivers/gpu/drm/i915/*.c | xargs spatch --sp-file \
<script> --linux-spacing --in-place
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-10-pankaj.laxminarayan.bharadiya@intel.com
2020-01-15 09:14:53 +05:30
|
|
|
if (drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_RUNTIME_PM(dev_priv)))
|
2014-08-26 13:26:56 +03:00
|
|
|
return -ENODEV;
|
2013-12-06 20:32:13 -02:00
|
|
|
|
2022-05-11 18:34:54 +05:30
|
|
|
drm_dbg(&dev_priv->drm, "Resuming device\n");
|
2013-12-06 20:32:13 -02:00
|
|
|
|
drm/i915: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
command: ls drivers/gpu/drm/i915/*.c | xargs spatch --sp-file \
<script> --linux-spacing --in-place
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-10-pankaj.laxminarayan.bharadiya@intel.com
2020-01-15 09:14:53 +05:30
|
|
|
drm_WARN_ON_ONCE(&dev_priv->drm, atomic_read(&rpm->wakeref_count));
|
2019-06-13 16:21:51 -07:00
|
|
|
disable_rpm_wakeref_asserts(rpm);
|
2015-12-16 02:52:19 +02:00
|
|
|
|
2024-08-09 17:27:05 +03:00
|
|
|
intel_opregion_notify_adapter(display, PCI_D0);
|
2023-08-16 18:22:16 +05:30
|
|
|
|
|
|
|
root_pdev = pcie_find_root_port(pdev);
|
|
|
|
if (root_pdev)
|
|
|
|
pci_d3cold_enable(root_pdev);
|
|
|
|
|
2019-03-25 14:49:34 -07:00
|
|
|
if (intel_uncore_unclaimed_mmio(&dev_priv->uncore))
|
drm/i915: conversion to drm_device logging macros when drm_i915_private is present.
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Instances of the DRM_DEBUG macro were not converted due to lack of a
consensus of an analogous struct drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
2020-01-31 12:34:12 +03:00
|
|
|
drm_dbg(&dev_priv->drm,
|
|
|
|
"Unclaimed access during suspend, bios?\n");
|
2013-12-06 20:32:13 -02:00
|
|
|
|
2024-11-28 17:38:23 +02:00
|
|
|
intel_display_power_resume(display);
|
2019-08-06 15:22:08 +03:00
|
|
|
|
2020-02-12 16:40:57 +02:00
|
|
|
ret = vlv_resume_prepare(dev_priv, true);
|
2014-10-27 17:54:32 -02:00
|
|
|
|
2022-09-06 16:49:29 -07:00
|
|
|
for_each_gt(gt, dev_priv, i)
|
|
|
|
intel_uncore_runtime_resume(gt->uncore);
|
2017-11-14 14:55:17 +01:00
|
|
|
|
2024-09-12 13:25:39 -04:00
|
|
|
intel_irq_resume(dev_priv);
|
2018-01-24 21:16:57 +05:30
|
|
|
|
2014-04-15 16:39:45 +03:00
|
|
|
/*
|
|
|
|
* No point of rolling back things in case of an error, as the best
|
|
|
|
* we can do is to hope that things will still work (and disable RPM).
|
|
|
|
*/
|
2022-09-06 16:49:29 -07:00
|
|
|
for_each_gt(gt, dev_priv, i)
|
|
|
|
intel_gt_runtime_resume(gt);
|
2014-04-14 20:24:39 +03:00
|
|
|
|
drm/i915/pxp: Promote pxp subsystem to top-level of i915
Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pertaining to PXP
operation (such as creating the arbitration session and session
tear-down).
PXP as a global feature is accessible via batch buffer instructions
on any engine/tile and the coherency across tiles is handled implicitly
by the HW. In fact, for the foreseeable future, we are expecting this
single-control-tile for the PXP subsystem.
In MTL, it's the standalone media tile (not the root tile) because
it contains the VDBOX and KCR engine (among the assets PXP relies on
for those events).
Looking at the current code design, each tile is represented by the
intel_gt structure while the intel_pxp structure currently hangs off the
intel_gt structure.
Keeping the intel_pxp structure within the intel_gt structure makes some
internal functionalities more straight forward but adds code complexity to
code readability and maintainibility to many external-to-pxp subsystems
which may need to pick the correct intel_gt structure. An example of this
would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
which should be viewed as a global level inquiry, not a per-gt inquiry.
That said, this series promotes the intel_pxp structure into the
drm_i915_private structure making it a top-level subsystem and the PXP
subsystem will select the control gt internally and keep a pointer to
it for internal reference.
This promotion comes with two noteworthy changes:
1. Exported pxp functions that are called by external subsystems
(such as intel_pxp_enabled/active) will have to check implicitly
if i915->pxp is valid as that structure will not be allocated
for HW that doesn't support PXP.
2. Since GT is now considered a soft-dependency of PXP we are
ensuring that GT init happens before PXP init and vice versa
for fini. This causes a minor ordering change whereby we previously
called intel_pxp_suspend after intel_uc_suspend but now is before
i915_gem_suspend_late but the change is required for correct
dependency flows. Additionally, this re-order change doesn't
have any impact because at that point in either case, the top level
entry to i915 won't observe any PXP events (since the GPU was
quiesced during suspend_prepare). Also, any PXP event doesn't
really matter when we disable the PXP HW (global GT irqs are
already off anyway, so even if there was a bug that generated
spurious events we wouldn't see it and we would just clean it
up on resume which is okay since the default fallback action
for PXP would be to keep the sessions off at this suspend stage).
Changes from prior revs:
v11: - Reformat a comment (Tvrtko).
v10: - Change the code flow for intel_pxp_init to make it more
cleaner and readible with better comments explaining the
difference between full-PXP-feature vs the partial-teelink
inits depending on the platform. Additionally, only do
the pxp allocation when we are certain the subsystem is
needed. (Tvrtko).
v9: - Cosmetic cleanups in supported/enabled/active. (Daniele).
- Add comments for intel_pxp_init and pxp_get_ctrl_gt that
explain the functional flow for when PXP is not supported
but the backend-assets are needed for HuC authentication
(Daniele and Tvrtko).
- Fix two remaining functions that are accessible outside
PXP that need to be checking pxp ptrs before using them:
intel_pxp_irq_handler and intel_pxp_huc_load_and_auth
(Tvrtko and Daniele).
- User helper macro in pxp-debugfs (Tvrtko).
v8: - Remove pxp_to_gt macro (Daniele).
- Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't
support GSC-FW on it. (Daniele).
- Leave i915->pxp as NULL if we dont support PXP and in line
with that, do additional validity check on i915->pxp for
intel_pxp_is_supported/enabled/active (Daniele).
- Remove unncessary include header from intel_gt_debugfs.c
and check drm_minor i915->drm.primary (Daniele).
- Other cosmetics / minor issues / more comments on suspend
flow order change (Daniele).
v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
through out instead of local variable newpxp. (Rodrigo)
- In the case intel_pxp_fini is called during driver unload but
after i915 loading failed without pxp being allocated, check
i915->pxp before referencing it. (Alan)
v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
because : [1] introduction of 'ctrl_gt' means we correct this
for MTL's upcoming series now. [2] Also, this has little impact
globally as its only used by PXP-internal callers at the moment.
- Change intel_pxp_init/fini to take in i915 as its input to avoid
ptr-to-ptr in init/fini calls.(Jani).
- Remove the backpointer from pxp->i915 since we can use
pxp->ctrl_gt->i915 if we need it. (Rodrigo).
v5: - Switch from series to single patch (Rodrigo).
- change function name from pxp_get_kcr_owner_gt to
pxp_get_ctrl_gt.
- Fix CI BAT failure by removing redundant call to intel_pxp_fini
from driver-remove.
- NOTE: remaining open still persists on using ptr-to-ptr
and back-ptr.
v4: - Instead of maintaining intel_pxp as an intel_gt structure member
and creating a number of convoluted helpers that takes in i915 as
input and redirects to the correct intel_gt or takes any intel_gt
and internally replaces with the correct intel_gt, promote it to
be a top-level i915 structure.
v3: - Rename gt level helper functions to "intel_pxp_is_enabled/
supported/ active_on_gt" (Daniele)
- Upgrade _gt_supports_pxp to replace what was intel_gtpxp_is
supported as the new intel_pxp_is_supported_on_gt to check for
PXP feature support vs the tee support for huc authentication.
Fix pxp-debugfs-registration to use only the former to decide
support. (Daniele)
- Couple minor optimizations.
v2: - Avoid introduction of new device info or gt variables and use
existing checks / macros to differentiate the correct GT->PXP
control ownership (Daniele Ceraolo Spurio)
- Don't reuse the updated global-checkers for per-GT callers (such
as other files within PXP) to avoid unnecessary GT-reparsing,
expose a replacement helper like the prior ones. (Daniele).
v1: - Add one more patch to the series for the intel_pxp suspend/resume
for similar refactoring
References: https://patchwork.freedesktop.org/patch/msgid/20221202011407.4068371-1-alan.previn.teres.alexis@intel.com
Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221208180542.998148-1-alan.previn.teres.alexis@intel.com
2022-12-08 10:05:42 -08:00
|
|
|
intel_pxp_runtime_resume(dev_priv->pxp);
|
|
|
|
|
2015-08-27 23:56:08 +03:00
|
|
|
/*
|
|
|
|
* On VLV/CHV display interrupts are part of the display
|
|
|
|
* power well, so hpd is reinitialized from there. For
|
|
|
|
* everyone else do it here.
|
|
|
|
*/
|
2020-10-13 21:11:37 +03:00
|
|
|
if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
|
2025-03-20 16:45:59 +02:00
|
|
|
intel_hpd_init(display);
|
|
|
|
intel_hpd_poll_disable(display);
|
2020-10-13 21:11:37 +03:00
|
|
|
}
|
2015-08-27 23:56:08 +03:00
|
|
|
|
2025-04-08 16:38:37 +03:00
|
|
|
skl_watermark_ipc_update(display);
|
2017-08-17 19:15:28 +05:30
|
|
|
|
2019-06-13 16:21:51 -07:00
|
|
|
enable_rpm_wakeref_asserts(rpm);
|
2015-12-16 02:52:19 +02:00
|
|
|
|
2014-04-15 16:39:45 +03:00
|
|
|
if (ret)
|
drm/i915: conversion to drm_device logging macros when drm_i915_private is present.
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Instances of the DRM_DEBUG macro were not converted due to lack of a
consensus of an analogous struct drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
2020-01-31 12:34:12 +03:00
|
|
|
drm_err(&dev_priv->drm,
|
|
|
|
"Runtime resume failed, disabling it (%d)\n", ret);
|
2014-04-15 16:39:45 +03:00
|
|
|
else
|
2022-05-11 18:34:54 +05:30
|
|
|
drm_dbg(&dev_priv->drm, "Device resumed\n");
|
2014-04-15 16:39:45 +03:00
|
|
|
|
|
|
|
return ret;
|
2013-12-06 20:32:13 -02:00
|
|
|
}
|
|
|
|
|
2016-06-24 14:00:26 +01:00
|
|
|
const struct dev_pm_ops i915_pm_ops = {
|
2014-10-23 19:23:28 +03:00
|
|
|
/*
|
|
|
|
* S0ix (via system suspend) and S3 event handlers [PMSG_SUSPEND,
|
|
|
|
* PMSG_RESUME]
|
|
|
|
*/
|
2018-05-25 10:26:29 +01:00
|
|
|
.prepare = i915_pm_prepare,
|
2011-08-16 15:34:10 -04:00
|
|
|
.suspend = i915_pm_suspend,
|
2014-04-01 19:55:22 +03:00
|
|
|
.suspend_late = i915_pm_suspend_late,
|
|
|
|
.resume_early = i915_pm_resume_early,
|
2011-08-16 15:34:10 -04:00
|
|
|
.resume = i915_pm_resume,
|
2023-01-25 00:26:37 -08:00
|
|
|
.complete = i915_pm_complete,
|
2014-10-23 19:23:28 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* S4 event handlers
|
|
|
|
* @freeze, @freeze_late : called (1) before creating the
|
|
|
|
* hibernation image [PMSG_FREEZE] and
|
|
|
|
* (2) after rebooting, before restoring
|
|
|
|
* the image [PMSG_QUIESCE]
|
|
|
|
* @thaw, @thaw_early : called (1) after creating the hibernation
|
|
|
|
* image, before writing it [PMSG_THAW]
|
|
|
|
* and (2) after failing to create or
|
|
|
|
* restore the image [PMSG_RECOVER]
|
|
|
|
* @poweroff, @poweroff_late: called after writing the hibernation
|
|
|
|
* image, before rebooting [PMSG_HIBERNATE]
|
|
|
|
* @restore, @restore_early : called after rebooting and restoring the
|
|
|
|
* hibernation image [PMSG_RESTORE]
|
|
|
|
*/
|
2016-05-14 07:26:32 +01:00
|
|
|
.freeze = i915_pm_freeze,
|
|
|
|
.freeze_late = i915_pm_freeze_late,
|
|
|
|
.thaw_early = i915_pm_thaw_early,
|
|
|
|
.thaw = i915_pm_thaw,
|
2014-10-23 19:23:24 +03:00
|
|
|
.poweroff = i915_pm_suspend,
|
2015-03-02 13:04:41 +02:00
|
|
|
.poweroff_late = i915_pm_poweroff_late,
|
2016-05-14 07:26:32 +01:00
|
|
|
.restore_early = i915_pm_restore_early,
|
|
|
|
.restore = i915_pm_restore,
|
2014-10-23 19:23:28 +03:00
|
|
|
|
|
|
|
/* S0ix (via runtime suspend) event handlers */
|
2014-03-07 20:12:33 -03:00
|
|
|
.runtime_suspend = intel_runtime_suspend,
|
|
|
|
.runtime_resume = intel_runtime_resume,
|
2009-12-16 13:36:10 +08:00
|
|
|
};
|
|
|
|
|
2011-10-31 07:28:57 -07:00
|
|
|
static const struct file_operations i915_driver_fops = {
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.open = drm_open,
|
2020-01-24 12:56:26 +00:00
|
|
|
.release = drm_release_noglobal,
|
2011-10-31 07:28:57 -07:00
|
|
|
.unlocked_ioctl = drm_ioctl,
|
2019-12-04 12:00:32 +00:00
|
|
|
.mmap = i915_gem_mmap,
|
2011-10-31 07:28:57 -07:00
|
|
|
.poll = drm_poll,
|
|
|
|
.read = drm_read,
|
2020-02-27 19:00:45 +02:00
|
|
|
.compat_ioctl = i915_ioc32_compat_ioctl,
|
2011-10-31 07:28:57 -07:00
|
|
|
.llseek = noop_llseek,
|
2022-04-01 15:22:05 +01:00
|
|
|
#ifdef CONFIG_PROC_FS
|
2023-06-05 13:32:24 +01:00
|
|
|
.show_fdinfo = drm_show_fdinfo,
|
2022-04-01 15:22:05 +01:00
|
|
|
#endif
|
2024-08-09 12:38:56 +02:00
|
|
|
.fop_flags = FOP_UNSIGNED_OFFSET,
|
2011-10-31 07:28:57 -07:00
|
|
|
};
|
|
|
|
|
2016-06-24 14:00:22 +01:00
|
|
|
static int
|
|
|
|
i915_gem_reject_pin_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct drm_ioctl_desc i915_ioctls[] = {
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_INIT, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_FLUSH, drm_noop, DRM_AUTH),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_FLIP, drm_noop, DRM_AUTH),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, drm_noop, DRM_AUTH),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, drm_noop, DRM_AUTH),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, drm_noop, DRM_AUTH),
|
2019-04-17 13:25:24 +02:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam_ioctl, DRM_RENDER_ALLOW),
|
2016-06-24 14:00:22 +01:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_SETPARAM, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_INIT_HEAP, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_CMDBUFFER, drm_noop, DRM_AUTH),
|
2024-08-07 14:05:16 +01:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_DESTROY_HEAP, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_SET_VBLANK_PIPE, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GET_VBLANK_PIPE, drm_noop, DRM_AUTH),
|
2016-06-24 14:00:22 +01:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_VBLANK_SWAP, drm_noop, DRM_AUTH),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_INIT, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
|
2021-03-17 18:40:10 -05:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, drm_invalid_op, DRM_AUTH),
|
2019-04-17 13:25:24 +02:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2_WR, i915_gem_execbuffer2_ioctl, DRM_RENDER_ALLOW),
|
2016-06-24 14:00:22 +01:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_reject_pin_ioctl, DRM_AUTH|DRM_ROOT_ONLY),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_reject_pin_ioctl, DRM_AUTH|DRM_ROOT_ONLY),
|
2019-04-17 13:25:24 +02:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, DRM_RENDER_ALLOW),
|
2016-06-24 14:00:22 +01:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl, DRM_RENDER_ALLOW),
|
2019-04-17 13:25:24 +02:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, DRM_RENDER_ALLOW),
|
2016-06-24 14:00:22 +01:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, DRM_RENDER_ALLOW),
|
2021-04-29 11:30:52 +01:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_CREATE_EXT, i915_gem_create_ext_ioctl, DRM_RENDER_ALLOW),
|
2016-06-24 14:00:22 +01:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_RENDER_ALLOW),
|
2019-12-04 12:00:32 +00:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_OFFSET, i915_gem_mmap_offset_ioctl, DRM_RENDER_ALLOW),
|
2016-06-24 14:00:22 +01:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, DRM_RENDER_ALLOW),
|
2017-01-10 12:10:44 +00:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling_ioctl, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling_ioctl, DRM_RENDER_ALLOW),
|
2016-06-24 14:00:22 +01:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, DRM_RENDER_ALLOW),
|
2024-09-13 16:54:38 +03:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GET_PIPE_FROM_CRTC_ID, intel_crtc_get_pipe_from_crtc_id_ioctl, 0),
|
2016-06-24 14:00:22 +01:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl, DRM_RENDER_ALLOW),
|
2018-04-20 08:51:57 +02:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_OVERLAY_PUT_IMAGE, intel_overlay_put_image_ioctl, DRM_MASTER),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_OVERLAY_ATTRS, intel_overlay_attrs_ioctl, DRM_MASTER),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_SET_SPRITE_COLORKEY, intel_sprite_set_colorkey_ioctl, DRM_MASTER),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GET_SPRITE_COLORKEY, drm_noop, DRM_MASTER),
|
2019-04-17 13:25:24 +02:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_WAIT, i915_gem_wait_ioctl, DRM_RENDER_ALLOW),
|
2019-03-22 09:23:24 +00:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_CREATE_EXT, i915_gem_context_create_ioctl, DRM_RENDER_ALLOW),
|
2016-06-24 14:00:22 +01:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_DESTROY, i915_gem_context_destroy_ioctl, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_REG_READ, i915_reg_read_ioctl, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GET_RESET_STATS, i915_gem_context_reset_stats_ioctl, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
|
drm/i915: Add i915 perf infrastructure
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.
A stream is opened something like:
uint64_t properties[] = {
/* Single context sampling */
DRM_I915_PERF_PROP_CTX_HANDLE, ctx_handle,
/* Include OA reports in samples */
DRM_I915_PERF_PROP_SAMPLE_OA, true,
/* OA unit configuration */
DRM_I915_PERF_PROP_OA_METRICS_SET, metrics_set_id,
DRM_I915_PERF_PROP_OA_FORMAT, report_format,
DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent,
};
struct drm_i915_perf_open_param parm = {
.flags = I915_PERF_FLAG_FD_CLOEXEC |
I915_PERF_FLAG_FD_NONBLOCK |
I915_PERF_FLAG_DISABLED,
.properties_ptr = (uint64_t)properties,
.num_properties = sizeof(properties) / 16,
};
int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);
Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.
No specific streams are supported yet so any attempt to open a stream
will return an error.
v2:
use i915_gem_context_get() - Chris Wilson
v3:
update read() interface to avoid passing state struct - Chris Wilson
fix some rebase fallout, with i915-perf init/deinit
v4:
s/DRM_IORW/DRM_IOW/ - Emil Velikov
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Sourab Gupta <sourab.gupta@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-2-robert@sixbynine.org
2016-11-07 19:49:47 +00:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, DRM_RENDER_ALLOW),
|
2019-05-22 16:47:01 +01:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, i915_perf_remove_config_ioctl, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl, DRM_RENDER_ALLOW),
|
2019-05-21 22:11:25 +01:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_VM_CREATE, i915_gem_vm_create_ioctl, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_VM_DESTROY, i915_gem_vm_destroy_ioctl, DRM_RENDER_ALLOW),
|
2016-06-24 14:00:22 +01:00
|
|
|
};
|
|
|
|
|
2022-02-09 14:31:21 +02:00
|
|
|
/*
|
|
|
|
* Interface history:
|
|
|
|
*
|
|
|
|
* 1.1: Original.
|
|
|
|
* 1.2: Add Power Management
|
|
|
|
* 1.3: Add vblank support
|
|
|
|
* 1.4: Fix cmdbuffer path, add heap destroy
|
|
|
|
* 1.5: Add vblank pipe configuration
|
|
|
|
* 1.6: - New ioctl for scheduling buffer swaps on vertical blank
|
|
|
|
* - Support vertical blank on secondary display pipe
|
|
|
|
*/
|
|
|
|
#define DRIVER_MAJOR 1
|
|
|
|
#define DRIVER_MINOR 6
|
|
|
|
#define DRIVER_PATCHLEVEL 0
|
|
|
|
|
2021-11-11 12:13:03 +02:00
|
|
|
static const struct drm_driver i915_drm_driver = {
|
2011-08-25 17:55:54 +00:00
|
|
|
/* Don't use MTRRs here; the Xserver or userspace app should
|
|
|
|
* deal with them for Intel hardware.
|
2005-11-11 23:30:27 +11:00
|
|
|
*/
|
2008-07-30 12:06:12 -07:00
|
|
|
.driver_features =
|
2019-06-17 17:39:24 +02:00
|
|
|
DRIVER_GEM |
|
2020-08-04 11:59:54 +03:00
|
|
|
DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_SYNCOBJ |
|
|
|
|
DRIVER_SYNCOBJ_TIMELINE,
|
2017-02-10 16:35:21 +00:00
|
|
|
.release = i915_driver_release,
|
2008-07-30 12:06:12 -07:00
|
|
|
.open = i915_driver_open,
|
|
|
|
.postclose = i915_driver_postclose,
|
2023-06-16 11:31:47 +02:00
|
|
|
.show_fdinfo = PTR_IF(IS_ENABLED(CONFIG_PROC_FS), i915_drm_client_fdinfo),
|
2010-01-09 00:45:33 +01:00
|
|
|
|
2012-05-10 15:25:09 +02:00
|
|
|
.gem_prime_import = i915_gem_prime_import,
|
|
|
|
|
2011-02-07 12:16:14 +10:00
|
|
|
.dumb_create = i915_gem_dumb_create,
|
2019-12-04 12:00:32 +00:00
|
|
|
.dumb_map_offset = i915_gem_dumb_mmap_offset,
|
|
|
|
|
2024-12-12 18:08:51 +01:00
|
|
|
INTEL_FBDEV_DRIVER_OPS,
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
.ioctls = i915_ioctls,
|
2016-06-24 14:00:22 +01:00
|
|
|
.num_ioctls = ARRAY_SIZE(i915_ioctls),
|
2011-10-31 07:28:57 -07:00
|
|
|
.fops = &i915_driver_fops,
|
2005-11-10 22:16:34 +11:00
|
|
|
.name = DRIVER_NAME,
|
|
|
|
.desc = DRIVER_DESC,
|
|
|
|
.major = DRIVER_MAJOR,
|
|
|
|
.minor = DRIVER_MINOR,
|
|
|
|
.patchlevel = DRIVER_PATCHLEVEL,
|
2005-04-16 15:20:36 -07:00
|
|
|
};
|