platform/kernel/linux-starfive.git
2 years agodrm/i915: Define multicast registers as a new type
Matt Roper [Fri, 14 Oct 2022 23:02:37 +0000 (16:02 -0700)]
drm/i915: Define multicast registers as a new type

Rather than treating multicast registers as 'i915_reg_t' let's define
them as a completely new type.  This will allow the compiler to help us
make sure we're using multicast-aware functions to operate on multicast
registers.

This plan does break down a bit in places where we're just maintaining
heterogeneous lists of registers (e.g., various MMIO whitelists used by
perf, GVT, etc.) rather than performing reads/writes.  We only really
care about the offset in those cases, so for now we can "cast" the
registers as non-MCR, leaving us with a list of i915_reg_t's, but we may
want to look for better ways to store mixed collections of i915_reg_t
and i915_mcr_reg_t in the future.

v2:
 - Add TLB invalidation registers
v3:
 - Make type checking of i915_mmio_reg_offset() stricter.  It will
   accept either i915_reg_t or i915_mcr_reg_t, but will now raise a
   compile error if any other type is passed, even if that type contains
   a 'reg' field.  (Jani)
 - Drop a ton of GVT changes; allowing i915_mmio_reg_offset() to take
   either an i915_reg_t or an i915_mcr_reg_t means that the huge lists
   of MMIO_D*() macros used in GVT will continue to work without
   modification.  We need only make changes to structures that have an
   explicit i915_reg_t in them now.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221014230239.1023689-13-matthew.d.roper@intel.com
2 years agodrm/i915/gt: Add MCR-specific workaround initializers
Matt Roper [Fri, 14 Oct 2022 23:02:36 +0000 (16:02 -0700)]
drm/i915/gt: Add MCR-specific workaround initializers

Let's be more explicit about which of our workarounds are updating MCR
registers.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221014230239.1023689-12-matthew.d.roper@intel.com
2 years agodrm/i915/guc: Handle save/restore of MCR registers explicitly
Matt Roper [Fri, 14 Oct 2022 23:02:35 +0000 (16:02 -0700)]
drm/i915/guc: Handle save/restore of MCR registers explicitly

MCR registers can be placed on the GuC's save/restore list, but at the
moment they are always handled in a multicast manner (i.e., the GuC
reads one instance to save the value and then does a multicast write to
restore that single value to all instances).  In the future the GuC will
probably give us an alternate interface to do unicast per-instance
save/restore operations, so we should be very clear about which
registers on the list are MCR registers (and in the future which
save/restore behavior we want for them).

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221014230239.1023689-11-matthew.d.roper@intel.com
2 years agodrm/i915/gt: Always use MCR functions on multicast registers
Matt Roper [Fri, 14 Oct 2022 23:02:34 +0000 (16:02 -0700)]
drm/i915/gt: Always use MCR functions on multicast registers

Rather than relying on the implicit behavior of intel_uncore_*()
functions, let's always use the intel_gt_mcr_*() functions to operate on
multicast/replicated registers.

v2:
 - Add TLB invalidation registers

v3:
 - Switch more uncore operations in mmio_invalidate_full() to MCR
   operations for Xe_HP.  (Bala)

Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221014230239.1023689-10-matthew.d.roper@intel.com
2 years agodrm/i915: Define MCR registers explicitly
Matt Roper [Fri, 14 Oct 2022 23:02:33 +0000 (16:02 -0700)]
drm/i915: Define MCR registers explicitly

Rather than using the same _MMIO() macro to define MCR registers as
singleton registers, let's use a new MCR_REG() macro to make it clear
that these registers are special and should be handled accordingly.  For
now MCR_REG() will still generate an i915_reg_t with the given offset,
but we'll change that in future patches.

Bspec: 66673, 66696, 66534, 67609
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221014230239.1023689-9-matthew.d.roper@intel.com
2 years agodrm/i915/gt: Add intel_gt_mcr_wait_for_reg_fw()
Matt Roper [Fri, 14 Oct 2022 23:02:32 +0000 (16:02 -0700)]
drm/i915/gt: Add intel_gt_mcr_wait_for_reg_fw()

Xe_HP has some MCR registers that need to be polled for completion of
operations like TLB invalidation.  Those registers are in the GAM range,
which rolls up the status from each unit into the 'primary' instance's
value.  This makes it useful to have a dedicated 'wait for register'
function that handles this on MCR registers, similar to the
__intel_wait_for_register_fw() function we already have for regular
registers.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221014230239.1023689-8-matthew.d.roper@intel.com
2 years agodrm/i915/xehp: Check for faults on primary GAM
Matt Roper [Fri, 14 Oct 2022 23:02:31 +0000 (16:02 -0700)]
drm/i915/xehp: Check for faults on primary GAM

On Xe_HP the fault registers are now in a multicast register range.
However as part of the GAM these registers follow special rules and we
need only read from the "primary" GAM's instance to get the information
we need.  So a single intel_gt_mcr_read_any() (which will automatically
steer to the primary GAM) is sufficient; we don't need to loop over each
instance of the MCR register.

v2:
 - Update more instances of fault registers.  (Bala)

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221014230239.1023689-7-matthew.d.roper@intel.com
2 years agodrm/i915/gt: Add intel_gt_mcr_multicast_rmw() operation
Matt Roper [Fri, 14 Oct 2022 23:02:30 +0000 (16:02 -0700)]
drm/i915/gt: Add intel_gt_mcr_multicast_rmw() operation

There are cases where we wish to read from any non-terminated MCR
register instance (or the primary instance in the case of GAM ranges),
clear/set some bits, and then write the value back out to the register
in a multicast manner.  Adding a "multicast RMW" will avoid the need to
open-code this.

v2:
 - Return a u32 to align with the recent change to intel_uncore_rmw.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221014230239.1023689-6-matthew.d.roper@intel.com
2 years agodrm/i915/gt: Correct prefix on a few registers
Matt Roper [Fri, 14 Oct 2022 23:02:29 +0000 (16:02 -0700)]
drm/i915/gt: Correct prefix on a few registers

We have a few registers that have existed for several hardware
generations, but are only used by the driver on Xe_HP and beyond.  In
cases where the Xe_HP version of the register is now replicated and uses
multicast behavior, but earlier generations were singleton, let's change
the register prefix to "XEHP_" to help clarify that we're using the
newer multicast form of the register.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221014230239.1023689-5-matthew.d.roper@intel.com
2 years agodrm/i915/gt: Drop a few unused register definitions
Matt Roper [Fri, 14 Oct 2022 23:02:28 +0000 (16:02 -0700)]
drm/i915/gt: Drop a few unused register definitions

Let's drop a few register definitions that are unused anywhere in the
driver today.  Since the referenced offsets are part of what is now
considered a multicast register region, the current definitions would
not be correct for use on any future platform.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221014230239.1023689-4-matthew.d.roper@intel.com
2 years agodrm/i915/xehp: Create separate reg definitions for new MCR registers
Matt Roper [Fri, 14 Oct 2022 23:02:27 +0000 (16:02 -0700)]
drm/i915/xehp: Create separate reg definitions for new MCR registers

Starting in Xe_HP, several registers our driver works with have been
converted from singleton registers into replicated registers with
multicast behavior.  Although the registers are still located at the
same MMIO offsets as on previous platforms, let's duplicate the register
definitions in preparation for upcoming patches that will handle
multicast registers in a special manner.

The registers that are now replicated on Xe_HP are:
 * PAT_INDEX (mslice replication)
 * FF_MODE2 (gslice replication)
 * COMMON_SLICE_CHICKEN3 (gslice replication)
 * SLICE_COMMON_ECO_CHICKEN1 (gslice replication)
 * SLICE_UNIT_LEVEL_CLKGATE (gslice replication)
 * LNCFCMOCS (lncf replication)

Note that there are a couple places in selftest_mocs.c where the
gen9 version of LNCFCMOCS is still used without regards for which
platform we're on.  Those cases are just doing an offset lookup and not
issuing any CPU reads/writes of the register, so the potentially
multicast nature of the register doesn't come into play.

v2:
 - Add commit message note about the unconditional GEN9_LNCFCMOCS usage
   in selftest_mocs.  (Bala)
 - Include some additional TLB registers.

Bspec: 66534
Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221014230239.1023689-3-matthew.d.roper@intel.com
2 years agodrm/i915/gen8: Create separate reg definitions for new MCR registers
Matt Roper [Fri, 14 Oct 2022 23:02:26 +0000 (16:02 -0700)]
drm/i915/gen8: Create separate reg definitions for new MCR registers

Gen8 was the first time our hardware had multicast registers (or at
least the first time the multicast nature was exposed and MMIO accesses
could be steered).  There are some registers that transitioned from
singleton behavior to multicast during the gen7 -> gen8 transition;
let's duplicate the register definitions for those registers in
preparation for upcoming patches that will handle MCR registers in a
special manner.

The registers adjusted are:
 * MISCCPCTL
 * SAMPLER_INSTDONE
 * ROW_INSTDONE
 * ROW_CHICKEN2
 * HALF_SLICE_CHICKEN1
 * HALF_SLICE_CHICKEN3

v2:
 - Use the gen8 version of HALF_SLICE_CHICKEN3 in GVT's gen9 engine MMIO
   list.  (Bala)
 - Update to the gen8 version of MISCCPCTL in a couple new workarounds
   that were recently added for DG2/PVC.  (Bala)

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221014230239.1023689-2-matthew.d.roper@intel.com
2 years agodrm/i915/hwmon: Extend power/energy for XEHPSDV
Dale B Stimson [Thu, 13 Oct 2022 15:45:26 +0000 (08:45 -0700)]
drm/i915/hwmon: Extend power/energy for XEHPSDV

Extend hwmon power/energy for XEHPSDV especially per gt level energy
usage.

v2: Update to latest HWMON spec (Ashutosh)
v3: Fix review comments (Ashutosh)
v4: Fix review comments (Anshuman)
v5: s/hwmon_device_register_with_info/
    devm_hwmon_device_register_with_info/ (Ashutosh)
v6: Change contact to intel-gfx (Rodrigo)
    GEN12_RPSTAT1 is available for all Gen12+ (Andi)

Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: Dale B Stimson <dale.b.stimson@intel.com>
Signed-off-by: Badal Nilawar <badal.nilawar@intel.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221013154526.2105579-8-ashutosh.dixit@intel.com
2 years agodrm/i915/hwmon: Expose power1_max_interval
Ashutosh Dixit [Thu, 13 Oct 2022 15:45:25 +0000 (08:45 -0700)]
drm/i915/hwmon: Expose power1_max_interval

Expose power1_max_interval, that is the tau corresponding to PL1, as a
custom hwmon attribute. Some bit manipulation is needed because of the
format of PKG_PWR_LIM_1_TIME in
GT0_PACKAGE_RAPL_LIMIT register (1.x * power(2,y)).

v2: Update date and kernel version in Documentation (Badal)
v3: Cleaned up hwm_power1_max_interval_store() (Badal)
v4:
  - Fixed review comments (Anshuman)
  - In hwm_power1_max_interval_store() get PKG_MAX_WIN from
    pkg_power_sku when it is valid (Ashutosh)
  - KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
v5: On some of the DGFX setups it is seen that although pkg_power_sku
    is valid the field PKG_WIN_MAX is not populated. So it is
    decided to stick to default value of PKG_WIN_MAX (Ashutosh)
v6: Change contact to intel-gfx (Rodrigo)
    Fixed variable types in hwm_power1_max_interval_store (Andi)
    Documented PKG_MAX_WIN_DEFAULT (Andi)
    Removed else in hwm_attributes_visible (Andi)

Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: Badal Nilawar <badal.nilawar@intel.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221013154526.2105579-7-ashutosh.dixit@intel.com
2 years agodrm/i915/hwmon: Expose card reactive critical power
Ashutosh Dixit [Thu, 13 Oct 2022 15:45:24 +0000 (08:45 -0700)]
drm/i915/hwmon: Expose card reactive critical power

Expose the card reactive critical (I1) power. I1 is exposed as
power1_crit in microwatts (typically for client products) or as
curr1_crit in milliamperes (typically for server).

v2: Add curr1_crit functionality (Ashutosh)
v3: Use HWMON_CHANNEL_INFO to define power1_crit, curr1_crit (Badal)
v4: Use hwm_ prefix for static functions (Ashutosh)
v5: KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
v6: Change contact to intel-gfx (Rodrigo)

Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: Badal Nilawar <badal.nilawar@intel.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221013154526.2105579-6-ashutosh.dixit@intel.com
2 years agodrm/i915/hwmon: Show device level energy usage
Dale B Stimson [Thu, 13 Oct 2022 15:45:23 +0000 (08:45 -0700)]
drm/i915/hwmon: Show device level energy usage

Use i915 HWMON to display device level energy input.

v2: Updated the date and kernel version in feature description
v3:
  - Cleaned up hwm_energy function and removed unused function
    i915_hwmon_energy_status_get (Ashutosh)
v4: KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
v5: Change contact to intel-gfx (Rodrigo)
    Change return type of hwm_energy to void (Andi)

Signed-off-by: Dale B Stimson <dale.b.stimson@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
Signed-off-by: Badal Nilawar <badal.nilawar@intel.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221013154526.2105579-5-ashutosh.dixit@intel.com
2 years agodrm/i915/hwmon: Power PL1 limit and TDP setting
Dale B Stimson [Thu, 13 Oct 2022 15:45:22 +0000 (08:45 -0700)]
drm/i915/hwmon: Power PL1 limit and TDP setting

Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.

v2:
  - Fix review comments (Ashutosh)
  - Do not restore power1_max upon module unload/load sequence
    because on production systems modules are always loaded
    and not unloaded/reloaded (Ashutosh)
  - Fix review comments (Jani)
  - Remove endianness conversion (Ashutosh)
v3: Add power1_rated_max (Ashutosh)
v4:
  - Use macro HWMON_CHANNEL_INFO to define power channel (Guenter)
  - Update the date and kernel version in Documentation (Badal)
v5: Use hwm_ prefix for static functions (Ashutosh)
v6: Fix review comments (Ashutosh)
v7:
  - Define PCU_PACKAGE_POWER_SKU for DG1,DG2 and move
    PKG_PKG_TDP to intel_mchbar_regs.h (Anshuman)
  - KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
v8: Change contact to intel-gfx (Rodrigo)
    Minor change to val_sku_unit init (Andi)

Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Dale B Stimson <dale.b.stimson@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
Signed-off-by: Badal Nilawar <badal.nilawar@intel.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221013154526.2105579-4-ashutosh.dixit@intel.com
2 years agodrm/i915/hwmon: Add HWMON current voltage support
Riana Tauro [Thu, 13 Oct 2022 15:45:21 +0000 (08:45 -0700)]
drm/i915/hwmon: Add HWMON current voltage support

Use i915 HWMON subsystem to display current input voltage.

v2:
  - Updated date and kernel version in feature description
  - Fixed review comments (Ashutosh)
v3: Use macro HWMON_CHANNEL_INFO to define hwmon channel (Guenter)
v4:
  - Fixed review comments (Ashutosh)
  - Use hwm_ prefix for static functions (Ashutosh)
v5: Added unit of voltage as millivolts (Ashutosh)
v6: KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
v7: Change contact to intel-gfx (Rodrigo)
    GEN12_RPSTAT1 is available for all Gen12+ (Andi)
    Added Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
    to MAINTAINERS

Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
Signed-off-by: Badal Nilawar <badal.nilawar@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221013154526.2105579-3-ashutosh.dixit@intel.com
2 years agodrm/i915/hwmon: Add HWMON infrastructure
Dale B Stimson [Thu, 13 Oct 2022 15:45:20 +0000 (08:45 -0700)]
drm/i915/hwmon: Add HWMON infrastructure

The i915 HWMON module will be used to expose voltage, power and energy
values for dGfx. Here we set up i915 hwmon infrastructure including i915
hwmon registration, basic data structures and functions.

v2:
  - Create HWMON infra patch (Ashutosh)
  - Fixed review comments (Jani)
  - Remove "select HWMON" from i915/Kconfig (Jani)
v3: Use hwm_ prefix for static functions (Ashutosh)
v4: s/#ifdef CONFIG_HWMON/#if IS_REACHABLE(CONFIG_HWMON)/ since the former
    doesn't work if hwmon is compiled as a module (Guenter)
v5: Fixed review comments (Jani)
v6: s/kzalloc/devm_kzalloc/ (Andi)
v7: s/hwmon_device_register_with_info/
      devm_hwmon_device_register_with_info/ (Ashutosh)

Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Dale B Stimson <dale.b.stimson@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
Signed-off-by: Badal Nilawar <badal.nilawar@intel.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221013154526.2105579-2-ashutosh.dixit@intel.com
2 years agodrm/i915/uapi: expose GTT alignment
Matthew Auld [Tue, 4 Oct 2022 11:49:15 +0000 (12:49 +0100)]
drm/i915/uapi: expose GTT alignment

On some platforms we potentially have different alignment restrictions
depending on the memory type. We also now have different alignment
restrictions for the same region across different kernel versions.
Extend the region query to return the minimum required GTT alignment.

Testcase: igt@gem_create@create-ext-placement-alignment
Testcase: igt@i915_query@query-regions-sanity-check
Suggested-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Michal Mrozek <michal.mrozek@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Stuart Summers <stuart.summers@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Yang A Shi <yang.a.shi@intel.com>
Cc: Nirmoy Das <nirmoy.das@intel.com>
Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221004114915.221708-2-matthew.auld@intel.com
2 years agodrm/i915: enable PS64 support for DG2
Matthew Auld [Tue, 4 Oct 2022 11:49:14 +0000 (12:49 +0100)]
drm/i915: enable PS64 support for DG2

It turns out that on production DG2/ATS HW we should have support for
PS64. This feature allows to provide a 64K TLB hint at the PTE level,
which is a lot more flexible than the current method of enabling 64K GTT
pages for the entire page-table, since that leads to all kinds of
annoying restrictions, as documented in:

commit caa574ffc4aaf4f29b890223878c63e2e7772f62
Author: Matthew Auld <matthew.auld@intel.com>
Date:   Sat Feb 19 00:17:49 2022 +0530

    drm/i915/uapi: document behaviour for DG2 64K support

    On discrete platforms like DG2, we need to support a minimum page size
    of 64K when dealing with device local-memory. This is quite tricky for
    various reasons, so try to document the new implicit uapi for this.

With PS64, we can now drop the 2M GTT alignment restriction, and instead
only require 64K or larger when dealing with lmem. We still use the
compact-pt layout when possible, but only when we are certain that this
doesn't interfere with userspace.

Note that this is a change in uAPI behaviour, but hopefully shouldn't be
a concern (IGT is at least able to autodetect the alignment), since we
are only making the GTT alignment constraint less restrictive.

Based on a patch from CQ Tang.

v2: update the comment wrt scratch page
v3: (Nirmoy)
 - Fix the selftest to actually use the random size, plus some comment
   improvements, also drop the rem stuff.

Reported-by: Michal Mrozek <michal.mrozek@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Stuart Summers <stuart.summers@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Yang A Shi <yang.a.shi@intel.com>
Cc: Nirmoy Das <nirmoy.das@intel.com>
Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Acked-by: Michal Mrozek <michal.mrozek@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221004114915.221708-1-matthew.auld@intel.com
2 years agodrm/i915/trace: Remove unused frequency trace
Andi Shyti [Tue, 11 Oct 2022 13:59:40 +0000 (15:59 +0200)]
drm/i915/trace: Remove unused frequency trace

Commit 3e7abf814193 ("drm/i915: Extract GT render power state management")
removes the "trace_intel_gpu_freq_change()" trace points but
their definition was left without users. Remove it.

Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221011135940.367048-1-andi.shyti@linux.intel.com
2 years agodrm/i915: Fix display problems after resume
Thomas Hellström [Wed, 5 Oct 2022 12:11:59 +0000 (14:11 +0200)]
drm/i915: Fix display problems after resume

Commit 39a2bd34c933 ("drm/i915: Use the vma resource as argument for gtt
binding / unbinding") introduced a regression that due to the vma resource
tracking of the binding state, dpt ptes were not correctly repopulated.
Fix this by clearing the vma resource state before repopulating.
The state will subsequently be restored by the bind_vma operation.

Fixes: 39a2bd34c933 ("drm/i915: Use the vma resource as argument for gtt binding / unbinding")
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220912121957.31310-1-thomas.hellstrom@linux.intel.com
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.18+
Reported-and-tested-by: Kevin Boulain <kevinboulain@gmail.com>
Tested-by: David de Sousa <davidesousa@gmail.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221005121159.340245-1-thomas.hellstrom@linux.intel.com
2 years agodrm/i915/slpc: Update the frequency debugfs
Vinay Belgaumkar [Wed, 5 Oct 2022 15:59:43 +0000 (08:59 -0700)]
drm/i915/slpc: Update the frequency debugfs

Read the values stored in the SLPC structures. Remove the
fields that are no longer valid (like RPS interrupts) as
well.

v2: Move all functionality changes to this patch (Jani)
v3: Fix compile warning and if condition (Jani)

Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221005155943.34747-3-vinay.belgaumkar@intel.com
2 years agodrm/i915: Add a wrapper for frequency debugfs
Vinay Belgaumkar [Wed, 5 Oct 2022 15:59:42 +0000 (08:59 -0700)]
drm/i915: Add a wrapper for frequency debugfs

Move it to the RPS source file.

v2: Separate out code movement and functional changes (Jani)

Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221005155943.34747-2-vinay.belgaumkar@intel.com
2 years agodrm/i915/perf: remove redundant variable 'taken'
Colin Ian King [Fri, 7 Oct 2022 19:53:45 +0000 (20:53 +0100)]
drm/i915/perf: remove redundant variable 'taken'

The assignment to variable taken is redundant and so it can be
removed as well as the variable too.

Cleans up clang-scan build warnings:
warning: Although the value stored to 'taken' is used in the enclosing
expression, the value is never actually read from 'taken'
[deadcode.DeadStores]

Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221007195345.2749911-1-colin.i.king@gmail.com
2 years agodrm/i915/gem: remove redundant assignments to variable ret
Colin Ian King [Fri, 7 Oct 2022 19:47:45 +0000 (20:47 +0100)]
drm/i915/gem: remove redundant assignments to variable ret

The variable ret is being assigned with a value that is never read
both before and after a while-loop. The variable is being re-assigned
inside the while-loop and afterwards on the call to the function
i915_gem_object_lock_interruptible. Remove the redundants assignments.

Cleans up clang scan-build warnings:

warning: Although the value stored to 'ret' is used in the
enclosing expression, the value is never actually read
from 'ret' [deadcode.DeadStores]

warning: Value stored to 'ret' is never read [deadcode.DeadStores]

Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221007194745.2749277-1-colin.i.king@gmail.com
2 years agodrm/i915: restore stolen memory behaviour for DG2
Matthew Auld [Wed, 5 Oct 2022 15:31:48 +0000 (16:31 +0100)]
drm/i915: restore stolen memory behaviour for DG2

Restore the previous behaviour here where we compare the
pci_resource_len() with the actual lmem_size, and not the dsm size,
since dsm here is just some subset snipped off the end of the lmem.
Otherwise we will incorrectly report an io_size > 0 on small-bar
systems.

It doesn't looks like MTL is expecting small-bar with its stolen memory,
based on:

  GEM_BUG_ON(pci_resource_len(pdev, GEN12_LMEM_BAR) != SZ_256M)
  GEM_BUG_ON((dsm_size + SZ_8M) > lmem_size)

So just move the HAS_BAR2_SMEM_STOLEN() check first, which then ignores
the small bar part, and we can go back to checking lmem_size against the
BAR size.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7007
Fixes: dbb2ffbfd708 ("drm/i915/mtl: enable local stolen memory")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221005153148.758822-2-matthew.auld@intel.com
2 years agodrm/i915: add back GEN12_BDSM_MASK
Matthew Auld [Wed, 5 Oct 2022 15:31:47 +0000 (16:31 +0100)]
drm/i915: add back GEN12_BDSM_MASK

The mask was added in commit e5f415bfc5c2 ("drm/i915: Add missing mask
when reading GEN12_DSMBASE"), but then looks to be dropped in some
unrelated code movement in commit dbb2ffbfd708 ("drm/i915/mtl: enable
local stolen memory") without explanation. Add it back.

Fixes: dbb2ffbfd708 ("drm/i915/mtl: enable local stolen memory")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221005153148.758822-1-matthew.auld@intel.com
2 years agodrm/i915: check memory is mappable in read_from_page
Matthew Auld [Tue, 4 Oct 2022 13:19:16 +0000 (14:19 +0100)]
drm/i915: check memory is mappable in read_from_page

On small-bar systems we could be given something non-mappable here,
which leads to nasty oops. Make this nicer by checking if the resource
is mappable or not, and return an error otherwise.

v2: drop GEM_BUG_ON(flags & I915_BO_ALLOC_GPU_ONLY)

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Jianshui Yu <jianshui.yu@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221004131916.233474-5-matthew.auld@intel.com
2 years agodrm/i915/display: consider DG2_RC_CCS_CC when migrating buffers
Matthew Auld [Tue, 4 Oct 2022 13:19:15 +0000 (14:19 +0100)]
drm/i915/display: consider DG2_RC_CCS_CC when migrating buffers

For these types of display buffers, we need to able to CPU access some
part of the backing memory in prepare_plane_clear_colors(). As a result
we need to ensure we always place in the mappable part of lmem, which
becomes necessary on small-bar systems.

v2(Nirmoy & Ville):
 - Add some commentary for why we need to CPU access the buffer.
 - Split out the other changes, so we just consider the display change
   here.
v3:
 - Handle this in the dpt path.
v4(Ville):
 - Drop the intel_fb_rc_ccs_cc_plane() sanity check in
   pin_and_fence_fb_obj(), since we can also trigger this on DG1 it
   seems.

Fixes: eb1c535f0d69 ("drm/i915: turn on small BAR support")
Reported-by: Jianshui Yu <jianshui.yu@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221004131916.233474-4-matthew.auld@intel.com
2 years agodrm/i915: allow control over the flags when migrating
Matthew Auld [Tue, 4 Oct 2022 13:19:14 +0000 (14:19 +0100)]
drm/i915: allow control over the flags when migrating

In the next patch we want to move the object (if the current resource is
not compatible), to the mappable part of lmem for some display buffers.
Currently that requires being able to unset the I915_BO_ALLOC_GPU_ONLY
hint.

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Jianshui Yu <jianshui.yu@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221004131916.233474-3-matthew.auld@intel.com
2 years agodrm/i915/display: handle migration for dpt
Matthew Auld [Tue, 4 Oct 2022 13:19:13 +0000 (14:19 +0100)]
drm/i915/display: handle migration for dpt

On platforms like DG2, it looks like the dpt path here is missing the
migrate-to-lmem step on discrete platforms.

v2:
  - Move the vma_pin() under the for_i915_gem_ww(), otherwise the
    object can be moved after dropping the lock and then doing the pin.

Fixes: 33e7a975103c ("drm/i915/xelpd: First stab at DPT support")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Jianshui Yu <jianshui.yu@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221004131916.233474-2-matthew.auld@intel.com
2 years agodrm/i915: remove the TODO in pin_and_fence_fb_obj
Matthew Auld [Tue, 4 Oct 2022 13:19:12 +0000 (14:19 +0100)]
drm/i915: remove the TODO in pin_and_fence_fb_obj

The copy is async (if there even is one), but when later updating the
GGTT we always sync against the binding, which will in turn sync against
any moves.

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Jianshui Yu <jianshui.yu@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221004131916.233474-1-matthew.auld@intel.com
2 years agodrm/i915/guc: Fix revocation of non-persistent contexts
Tvrtko Ursulin [Mon, 3 Oct 2022 12:16:30 +0000 (13:16 +0100)]
drm/i915/guc: Fix revocation of non-persistent contexts

Patch which added graceful exit for non-persistent contexts missed the
fact it is not enough to set the exiting flag on a context and let the
backend handle it from there.

GuC backend cannot handle it because it runs independently in the
firmware and driver might not see the requests ever again. Patch also
missed the fact some usages of intel_context_is_banned in the GuC backend
needed replacing with newly introduced intel_context_is_schedulable.

Fix the first issue by calling into backend revoke when we know this is
the last chance to do it. Fix the second issue by replacing
intel_context_is_banned with intel_context_is_schedulable, which should
always be safe since latter is a superset of the former.

v2:
 * Just call ce->ops->revoke unconditionally. (Andrzej)

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: 45c64ecf97ee ("drm/i915: Improve user experience and driver robustness under SIGINT or similar")
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: <stable@vger.kernel.org> # v6.0+
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221003121630.694249-1-tvrtko.ursulin@linux.intel.com
2 years agodrm/i915: Document and future-proof preemption control policy
Matt Roper [Wed, 7 Sep 2022 21:24:10 +0000 (14:24 -0700)]
drm/i915: Document and future-proof preemption control policy

Intel hardware allows some preemption settings to be controlled either
by the kernel-mode driver exclusively, or placed under control of the
user-mode drivers; on Linux we always select the userspace control
option.  The various registers involved in this are not documented very
clearly; let's add some clarifying comments to help explain how this all
works and provide some history on why our Linux drivers take the
approach they do (which I believe differs from the path taken by certain
other operating systems' drivers).

While we're at it, let's also remove the graphics version 12 upper bound
on this programming.  As described, we don't have any plans to move away
from UMD control of preemption settings on future platforms, and there's
currently no reason to believe that the hardware will fundamentally
change how these registers and settings work after version 12.

Bspec: 45921, 45858, 45863
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Wayne Boyer <wayne.boyer@intel.com>
Acked-by: Tapani Pälli <tapani.palli@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220907212410.22623-1-matthew.d.roper@intel.com
2 years agodrm/i915/ttm: implement access_memory
Matthew Auld [Mon, 3 Oct 2022 17:28:19 +0000 (18:28 +0100)]
drm/i915/ttm: implement access_memory

It looks like we need this for local-memory, if we want to use ptrace.
Something more is still needed if we want to handle non-mappable memory,
which looks quite annoying.

v2:
  - ttm_bo_kmap doesn't seem to work well here, and seems to expect
    contiguous resource.
v3(Andi):
  - s/PAGE_SIZE/bytes/ when passing in the size of the mapping.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/6989
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Nirmoy Das <nirmoy.das@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221003172819.99245-1-matthew.auld@intel.com
2 years agodrm/i915/gt: Remove unused function prototype
Gwan-gyeong Mun [Mon, 3 Oct 2022 17:02:42 +0000 (20:02 +0300)]
drm/i915/gt: Remove unused function prototype

Remove unused function prototype; intel_gt_create_kobj()

Cc: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@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/20221003170242.1246830-1-gwan-gyeong.mun@intel.com
2 years agodrm/i915/huc: define gsc-compatible HuC fw for DG2
Daniele Ceraolo Spurio [Wed, 28 Sep 2022 00:41:44 +0000 (17:41 -0700)]
drm/i915/huc: define gsc-compatible HuC fw for DG2

The fw name is different and we need to record the fact that the blob is
gsc-loaded, so add a new macro to help.

Note: A-step DG2 G10 does not support HuC loading via GSC and would
require a separate firmware to be loaded the legacy way, but that's
not a production stepping so we're not going to bother.

v2: rebase on new fw fetch logic

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Acked-by: Tony Ye <tony.ye@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-15-daniele.ceraolospurio@intel.com
2 years agodrm/i915/huc: better define HuC status getparam possible return values.
Daniele Ceraolo Spurio [Wed, 28 Sep 2022 00:41:43 +0000 (17:41 -0700)]
drm/i915/huc: better define HuC status getparam possible return values.

The current HuC status getparam return values are a bit confusing in
regards to what happens in some scenarios. In particular, most of the
error cases cause the ioctl to return an error, but a couple of them,
INIT_FAIL and LOAD_FAIL, are not explicitly handled and neither is
their expected return value documented; these 2 error cases therefore
end up into the catch-all umbrella of the "HuC not loaded" case, with
this case therefore including both some error scenarios and the load
in progress one.

The updates included in this patch change the handling so that all
error cases behave the same way, i.e. return an errno code, and so
that the HuC load in progress case is unambiguous.

The patch also includes a small change to the FW init path to make sure
we always transition to an error state if something goes wrong.

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Tony Ye <tony.ye@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-14-daniele.ceraolospurio@intel.com
2 years agodrm/i915/huc: stall media submission until HuC is loaded
Daniele Ceraolo Spurio [Wed, 28 Sep 2022 00:41:42 +0000 (17:41 -0700)]
drm/i915/huc: stall media submission until HuC is loaded

Wait on the fence to be signalled to avoid the submissions finding HuC
not yet loaded.

v2: use dedicaded wait_queue_entry for waiting in HuC load, as submitq
can't be re-used for it.

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Acked-by: Tony Ye <tony.ye@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-13-daniele.ceraolospurio@intel.com
2 years agodrm/i915/huc: track delayed HuC load with a fence
Daniele Ceraolo Spurio [Wed, 28 Sep 2022 00:41:41 +0000 (17:41 -0700)]
drm/i915/huc: track delayed HuC load with a fence

Given that HuC load is delayed on DG2, this patch adds support for a fence
that can be used to wait for load completion. No waiters are added in this
patch (they're coming up in the next one), to keep the focus of the
patch on the tracking logic.

The full HuC loading flow on boot DG2 is as follows:
1) i915 exports the GSC as an aux device;
2) the mei-gsc driver is loaded on the aux device;
3) the mei-pxp component is loaded;
4) mei-pxp calls back into i915 and we load the HuC.

Between steps 1 and 2 there can be several seconds of gap, mainly due to
the kernel doing other work during the boot.
The resume flow is slightly different, because we don't need to
re-expose or re-probe the aux device, so we go directly to step 3 once
i915 and mei-gsc have completed their resume flow.

Here's an example of the boot timing, captured with some logs added to
i915:

[   17.908307] [drm] adding GSC device
[   17.915717] [drm] i915 probe done
[   22.282917] [drm] mei-gsc bound
[   22.938153] [drm] HuC authenticated

Also to note is that if something goes wrong during GSC HW init the
mei-gsc driver will still bind, but steps 3 and 4 will not happen.

The status tracking is done by registering a bus_notifier to receive a
callback when the mei-gsc driver binds, with a large enough timeout to
account for delays. Once mei-gsc is bound, we switch to a smaller
timeout to wait for the mei-pxp component to load.
The fence is signalled on HuC load complete or if anything goes wrong in
any of the tracking steps. Timeout are enforced via hrtimer callbacks.

v2: fix includes (Jani)
v5: gsc_notifier() remove unneeded ()

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-12-daniele.ceraolospurio@intel.com
2 years agodrm/i915/dg2: setup HuC loading via GSC
Daniele Ceraolo Spurio [Wed, 28 Sep 2022 00:41:40 +0000 (17:41 -0700)]
drm/i915/dg2: setup HuC loading via GSC

The GSC will perform both the load and the authentication, so we just
need to check the auth bit after the GSC has replied.
Since we require the PXP module to load the HuC, the earliest we can
trigger the load is during the pxp_bind operation.

Note that GSC-loaded HuC survives GT reset, so we need to just mark it
as ready when we re-init the GT HW.

V2: move setting of HuC fw error state to the failure path of the HuC
auth function, so it covers both the legacy and new auth flows
V4:
1. Fix typo in the commit message
2. style fix in intel_huc_wait_for_auth_complete()

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-11-daniele.ceraolospurio@intel.com
2 years agodrm/i915/pxp: add huc authentication and loading command
Tomas Winkler [Wed, 28 Sep 2022 00:41:39 +0000 (17:41 -0700)]
drm/i915/pxp: add huc authentication and loading command

Add support for loading HuC via a pxp stream command.

V4:
1. Remove unnecessary include in intel_pxp_huc.h (Jani)
2. Adjust copyright year to 2022

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-10-daniele.ceraolospurio@intel.com
2 years agodrm/i915/pxp: implement function for sending tee stream command
Vitaly Lubart [Wed, 28 Sep 2022 00:41:38 +0000 (17:41 -0700)]
drm/i915/pxp: implement function for sending tee stream command

Command to be sent via the stream interface are written to a local
memory page, whose address is then provided to the GSC.
The interface supports providing a full sg with multiple pages for both
input and output messages, but since for now we only aim to support short
and synchronous messages we can use a single page for both input and
output.

Note that the mei interface expects an sg of 4k pages, while our lmem pages
are 64k. If we ever need to support more than 4k we'll need to convert.
Added a TODO comment to the code to record this.

Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-9-daniele.ceraolospurio@intel.com
2 years agodrm/i915/pxp: load the pxp module when we have a gsc-loaded huc
Daniele Ceraolo Spurio [Wed, 28 Sep 2022 00:41:37 +0000 (17:41 -0700)]
drm/i915/pxp: load the pxp module when we have a gsc-loaded huc

The mei_pxp module is required to send the command to load authenticate
the HuC to the GSC even if pxp is not in use for protected content
management.

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-8-daniele.ceraolospurio@intel.com
2 years agomei: pxp: support matching with a gfx discrete card
Tomas Winkler [Wed, 28 Sep 2022 00:41:36 +0000 (17:41 -0700)]
mei: pxp: support matching with a gfx discrete card

With on-boards graphics card, both i915 and MEI
are in the same device hierarchy with the same parent,
while for discrete gfx card the MEI is its child device.
Adjust the match function for that scenario
by matching MEI parent device with i915.

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Vitaly Lubart <vitaly.lubart@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-7-daniele.ceraolospurio@intel.com
2 years agomei: pxp: add command streamer API to the PXP driver
Vitaly Lubart [Wed, 28 Sep 2022 00:41:35 +0000 (17:41 -0700)]
mei: pxp: add command streamer API to the PXP driver

The discrete graphics card with GSC firmware
using command streamer API hence it requires to enhance
pxp module with the new gsc_command() handler.

The handler is implemented via mei_pxp_gsc_command() which is
just a thin wrapper around mei_cldev_send_gsc_command()

Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-6-daniele.ceraolospurio@intel.com
2 years agomei: bus: extend bus API to support command streamer API
Vitaly Lubart [Wed, 28 Sep 2022 00:41:34 +0000 (17:41 -0700)]
mei: bus: extend bus API to support command streamer API

Add mei bus API for sending gsc commands: mei_cldev_send_gsc_command()

The GSC commands are originated in the graphics stack
and are in form of SGL DMA buffers.
The GSC commands are synchronous, the response is received
in the same call on the out sg list buffers.
The function setups pointers for in and out sg lists in the
mei sgl extended header and sends it to the firmware.

Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-5-daniele.ceraolospurio@intel.com
2 years agomei: adjust extended header kdocs
Tomas Winkler [Wed, 28 Sep 2022 00:41:33 +0000 (17:41 -0700)]
mei: adjust extended header kdocs

Fix kdoc for struct mei_ext_hdr and mei_ext_begin().

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-4-daniele.ceraolospurio@intel.com
2 years agomei: bus: enable sending gsc commands
Tomas Winkler [Wed, 28 Sep 2022 00:41:32 +0000 (17:41 -0700)]
mei: bus: enable sending gsc commands

GSC command is and extended header containing a scatter gather
list and without a data buffer. Using MEI_CL_IO_SGL flag,
the caller send the GSC command as a data and the function internally
moves it to the extended header.

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Vitaly Lubart <vitaly.lubart@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-3-daniele.ceraolospurio@intel.com
2 years agomei: add support to GSC extended header
Tomas Winkler [Wed, 28 Sep 2022 00:41:31 +0000 (17:41 -0700)]
mei: add support to GSC extended header

GSC extend header is of variable size and data
is provided in a sgl list inside the header
and not in the data buffers, need to enable the path.

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Vitaly Lubart <vitaly.lubart@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-2-daniele.ceraolospurio@intel.com
2 years agoMerge drm/drm-next into drm-intel-gt-next
Tvrtko Ursulin [Mon, 3 Oct 2022 16:04:02 +0000 (17:04 +0100)]
Merge drm/drm-next into drm-intel-gt-next

Daniele needs 84d4333c1e28 ("misc/mei: Add NULL check to component match
callback functions") in order to merge the DG2 HuC patches.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2 years agodrm/i915/ehl: Update MOCS table for EHL
Tejas Upadhyay [Fri, 30 Sep 2022 13:32:23 +0000 (19:02 +0530)]
drm/i915/ehl: Update MOCS table for EHL

Add these extra EHL entries back since we have
drm-tip commit 13d29c823738
("drm/i915/ehl: unconditionally flush the pages on acquire")
introduces proper flushing to make it work as expected.

Cc: Chris Wilson <chris.p.wilson@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Fixes: 046091758b50 ("Revert "drm/i915/ehl: Update MOCS table for EHL"")
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Acked-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220930133223.2757282-1-tejas.upadhyay@intel.com
2 years agodrm/i915/gt: Fix platform prefix
Lucas De Marchi [Fri, 30 Sep 2022 05:09:03 +0000 (22:09 -0700)]
drm/i915/gt: Fix platform prefix

Different handling for XeHP and later platforms should be using the
xehp prefix, not gen125. Rename them.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220930050903.3479619-4-lucas.demarchi@intel.com
2 years agodrm/i915/gt: Document function to decode register state context
Lucas De Marchi [Fri, 30 Sep 2022 05:09:02 +0000 (22:09 -0700)]
drm/i915/gt: Document function to decode register state context

It's not obvious how the encode/decode of the per platform tables is
done. Document it so while adding tables for new platforms people can be
confident they right things is being done.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220930050903.3479619-3-lucas.demarchi@intel.com
2 years agodrm/i915: Fix __gen125_emit_bb_start() without WA
Lucas De Marchi [Fri, 30 Sep 2022 05:09:01 +0000 (22:09 -0700)]
drm/i915: Fix __gen125_emit_bb_start() without WA

ce->wa_bb_page is allocated only for graphics version 12. However
__gen125_emit_bb_start() is used for any graphics version >= 12.50. For
the currently supported platforms this is not an issue, but for future
ones there's a mismatch causing the jump to
`wa_offset + DG2_PREDICATE_RESULT_BB` to be invalid since wa_offset is
not correct.

As in other places in the driver, check for graphics version "greater or
equal" to future-proof the support for new platforms.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220930050903.3479619-2-lucas.demarchi@intel.com
2 years agodrm/i915/mtl: enable local stolen memory
Aravind Iddamsetty [Thu, 29 Sep 2022 11:46:58 +0000 (17:16 +0530)]
drm/i915/mtl: enable local stolen memory

As an integrated GPU, MTL does not have local memory and HAS_LMEM()
returns false.  However the platform's stolen memory is presented via
BAR2 (i.e., the BAR we traditionally consider to be the GMADR on IGFX)
and should be managed by the driver the same way that local memory is
on dgpu platforms (which includes setting the "lmem" bit on page table
entries).  We use the term "local stolen memory" to refer to this
model.

The major difference from the traditional BAR2 (GMADR) is that
the stolen area is mapped via the BAR2 while in the former BAR2 is an
aperture into the GTT VA through which access are made into stolen area.

BSPEC: 53098, 63830

v2:
1. dropped is_dsm_invalid, updated valid_stolen_size check from Lucas
(Jani, Lucas)
2. drop lmembar_is_igpu_stolen
3. revert to referring GFXMEM_BAR as GEN12_LMEM_BAR (Lucas)

v3:(Jani)
1. rename get_mtl_gms_size to mtl_get_gms_size
2. define register for MMIO address

v4:(Matt)
1. Use REG_FIELD_GET to read GMS value
2. replace the calculations with SZ_256M/SZ_8M

v5: Include more details to commit message on how it is different from
earlier platforms (Anshuman)

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: CQ Tang <cq.tang@intel.com>
Signed-off-by: Aravind Iddamsetty <aravind.iddamsetty@intel.com>
Original-author: CQ Tang
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220929114658.145287-1-aravind.iddamsetty@intel.com
2 years agodrm/i915/mtl: Define engine context layouts
Matt Roper [Wed, 28 Sep 2022 15:55:11 +0000 (08:55 -0700)]
drm/i915/mtl: Define engine context layouts

The part of the media and blitter engine contexts that we care about for
setting up an initial state on MTL are nearly similar to DG2 (and PVC).
The difference being PRT_BB_STATE being replaced with NOP.

For render/compute engines, the part of the context images are nearly
the same, although the layout had a very slight change --- one POSH
register was removed and the placement of some LRI/noops adjusted
slightly to compensate.

v2:
 - Dg2, mtl xcs offsets slightly vary. Use a separate offsets array(Bala)
 - Add missing nop in xcs offsets(Bala)
v3:
 - Fix the spacing for nop in xcs offset(MattR)
v4:
 - Fix rcs register offset(MattR)
v4.1:
 - Fix commit message(Lucas)

Bspec: 46261, 46260, 45585
Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Cc: Licas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928155511.2379663-1-radhakrishna.sripada@intel.com
2 years agodrm/msm: Fix build break with recent mm tree
Rob Clark [Thu, 29 Sep 2022 16:14:04 +0000 (09:14 -0700)]
drm/msm: Fix build break with recent mm tree

9178e3dcb121 ("mm: discard __GFP_ATOMIC") removed __GFP_ATOMIC,
replacing it with a check for not __GFP_DIRECT_RECLAIM.

Reported-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220929161404.2769414-1-robdclark@gmail.com
2 years agoMerge tag 'drm-intel-next-fixes-2022-09-29' of git://anongit.freedesktop.org/drm...
Dave Airlie [Thu, 29 Sep 2022 23:40:29 +0000 (09:40 +1000)]
Merge tag 'drm-intel-next-fixes-2022-09-29' of git://anongit.freedesktop.org/drm/drm-intel into drm-next

- Fix release build bug in 'remove GuC log size module parameters' (John Harrison)
- Remove ipc_enabled from struct drm_i915_private (Jani Nikula)
- Do not cleanup obj with NULL bo->resource (Nirmoy Das)
- Fix device info for devices without display (Jani Nikula)
- Force DPLL calculation for TC ports after readout (Ville Syrjälä)
- Use i915_vm_put on ppgtt_create error paths (Chris Wilson)

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/YzWqtwPNxAe+r9FO@tursulin-desk
2 years agodrm/i915/gt: Flush to global observation point before breadcrumb write
Prathap Kumar Valsan [Tue, 27 Sep 2022 17:13:13 +0000 (19:13 +0200)]
drm/i915/gt: Flush to global observation point before breadcrumb write

Add flag to pipecontrol instruction to ensure in-flight writes are
flushed to global observation point. Also split the pipecontrol
instruction like we have in gen8.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/5886
Signed-off-by: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@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/20220927171313.6553-1-nirmoy.das@intel.com
2 years agodrm/i915: remove excessive i915_gem_drain_freed_objects
Nirmoy Das [Fri, 23 Sep 2022 07:35:15 +0000 (09:35 +0200)]
drm/i915: remove excessive i915_gem_drain_freed_objects

i915_gem_drain_workqueue() call i915_gem_drain_freed_objects()
so no need to call that again.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220923073515.23093-2-nirmoy.das@intel.com
2 years agodrm/i915: Fix a potential UAF at device unload
Nirmoy Das [Fri, 23 Sep 2022 07:35:14 +0000 (09:35 +0200)]
drm/i915: Fix a potential UAF at device unload

i915_gem_drain_freed_objects() might not be enough to
free all the objects and RCU delayed work might get
scheduled after the i915 device struct gets freed.

Call i915_gem_drain_workqueue() to catch all RCU delayed work.

Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220923073515.23093-1-nirmoy.das@intel.com
2 years agodrm/i915/guc/slpc: Add SLPC selftest live_slpc_power
Riana Tauro [Fri, 23 Sep 2022 11:00:43 +0000 (16:30 +0530)]
drm/i915/guc/slpc: Add SLPC selftest live_slpc_power

A fundamental assumption is that at lower frequencies,
not only do we run slower, but we save power compared to
higher frequencies.
live_slpc_power checks if running at low frequency saves power

v2: re-use code to measure power
    fixed cosmetic review comments (Vinay)

Signed-off-by: Riana Tauro <riana.tauro@intel.com>
Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220923110043.789178-4-riana.tauro@intel.com
2 years agodrm/i915/selftests: Add helper function measure_power
Riana Tauro [Fri, 23 Sep 2022 11:00:42 +0000 (16:30 +0530)]
drm/i915/selftests: Add helper function measure_power

move the power measurement and the triangle filter
to a different function. No functional changes.

Signed-off-by: Riana Tauro <riana.tauro@intel.com>
Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220923110043.789178-3-riana.tauro@intel.com
2 years agodrm/i915/guc/slpc: Run SLPC selftests on all tiles
Riana Tauro [Fri, 23 Sep 2022 11:00:41 +0000 (16:30 +0530)]
drm/i915/guc/slpc: Run SLPC selftests on all tiles

Run slpc selftests on all tiles

Signed-off-by: Riana Tauro <riana.tauro@intel.com>
Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220923110043.789178-2-riana.tauro@intel.com
2 years agodrm/i915: Remove unwanted pointer unpacking
Niranjana Vishwanathapura [Tue, 27 Sep 2022 18:13:46 +0000 (11:13 -0700)]
drm/i915: Remove unwanted pointer unpacking

In await_fence_array(), unpacking syncobj pointer is not needed.
Remove it.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220927181346.1187-1-niranjana.vishwanathapura@intel.com
2 years agoMerge tag 'amd-drm-next-6.1-2022-09-23' of https://gitlab.freedesktop.org/agd5f/linux...
Dave Airlie [Wed, 28 Sep 2022 04:56:09 +0000 (14:56 +1000)]
Merge tag 'amd-drm-next-6.1-2022-09-23' of https://gitlab.freedesktop.org/agd5f/linux into drm-next

amd-drm-next-6.1-2022-09-23:

amdgpu:
- SDMA fix
- Add new firmware types to debugfs/IOCTL version queries
- Misc spelling and grammar fixes
- Misc code cleanups
- DCN 3.2.x fixes
- DCN 3.1.x fixes
- CS cleanup
- Gang submit support
- Clang fixes
- Non-DC audio fix
- GPUVM locking fixes
- Vega10 PWN fan speed fix

amdkgd:
- MQD manager cleanup
- Misc spelling and grammar fixes

UAPI:
- Add new firmware types to the FW version query IOCTL

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220923215729.6061-1-alexander.deucher@amd.com
2 years agoMerge tag 'drm-misc-next-2022-09-23' of git://anongit.freedesktop.org/drm/drm-misc...
Dave Airlie [Wed, 28 Sep 2022 03:50:28 +0000 (13:50 +1000)]
Merge tag 'drm-misc-next-2022-09-23' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

drm-misc-next for 6.1:

UAPI Changes:

Cross-subsystem Changes:
  - dma-buf: Improve signaling when debugging

Core Changes:
  - Backlight handling improvements
  - format-helper: Add drm_fb_build_fourcc_list()
  - fourcc: Kunit tests improvements
  - modes: Add DRM_MODE_INIT() macro
  - plane: Remove drm_plane_init(), Allocate planes with drm_universal_plane_alloc()
  - plane-helper: Add drm_plane_helper_atomic_check()
  - probe-helper: Add drm_connector_helper_get_modes_fixed() and
    drm_crtc_helper_mode_valid_fixed()
  - tests: Conversion to parametrized tests, test name consistency

Driver Changes:
  - amdgpu: Fix for a VRAM eviction issue
  - ast: Resolution handling improvements
  - mediatek: small code improvements for DP
  - omap: Refcounting fix, small improvements
  - rockchip: RK3568 support, Gamma support for RK3399
  - sun4i: Build failure fix when !OF
  - udl: Multiple fixes here and there
  - vc4: HDMI hotplug handling improvements
  - vkms: Warning fix

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220923073943.d43tne5hni3iknlv@houat
2 years agoMerge tag 'drm-msm-next-2022-09-22' of https://gitlab.freedesktop.org/drm/msm into...
Dave Airlie [Wed, 28 Sep 2022 01:35:25 +0000 (11:35 +1000)]
Merge tag 'drm-msm-next-2022-09-22' of https://gitlab.freedesktop.org/drm/msm into drm-next

msm-next for v6.1

DPU:
- simplified VBIF configuration
- cleaned up CTL interfaces to accept indices rather than flush masks

DSI:
- removed unused msm_display_dsc_config struct
- switch regulator calls to new bulk API
- switched to use PANEL_BRIDGE for directly attached panels

DSI PHY:
- converted drivers to use parent_hws instead of parent_names

DP:
- cleaned up pixel_rate handling

HDMI PHY:
- turned hdmi-phy-8996 into OF clk provider

core:
- misc dt-bindings fixes
- choose eDP as primary display if it's available
- support getting interconnects from either the mdss or the mdp5/dpu
  device nodes

gpu+gem:
- Shrinker + LRU re-work:
  - adds a shared GEM LRU+shrinker helper and moves msm over to that
  - reduces lock contention between retire and submit by avoiding the
    need to acquire obj lock in retire path (and instead using resv
    seeing obj's busyness in the shrinker
  - fix reclaim vs submit issues
- GEM fault injection for triggering userspace error paths
- Map/unmap optimization
- Improved robustness for a6xx GPU recovery

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rob Clark <robdclark@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGsrfrr9v1oR9S4oYfOs9jm=jbKQiwPBTrCRHrjYerJJFA@mail.gmail.com
2 years agodrm/i915/guc: Enable compute scheduling on DG2
John Harrison [Thu, 22 Sep 2022 20:12:09 +0000 (13:12 -0700)]
drm/i915/guc: Enable compute scheduling on DG2

DG2 has issues. To work around one of these the GuC must schedule
apps in an exclusive manner across both RCS and CCS. That is, if a
context from app X is running on RCS then all CCS engines must sit
idle even if there are contexts from apps Y, Z, ... waiting to run. A
certain OS favours RCS to the total starvation of CCS. Linux does not.
Hence the GuC now has a scheduling policy setting to control this
abitration.

Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220922201209.1446343-2-John.C.Harrison@Intel.com
2 years agoMerge tag 'mediatek-drm-next-6.1' of https://git.kernel.org/pub/scm/linux/kernel...
Dave Airlie [Tue, 27 Sep 2022 21:05:38 +0000 (07:05 +1000)]
Merge tag 'mediatek-drm-next-6.1' of https://git./linux/kernel/git/chunkuang.hu/linux into drm-next

Mediatek DRM Next for Linux 6.1

1. Drop of_gpio header
2. Remove the unneeded result

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220922234804.18557-1-chunkuang.hu@kernel.org
2 years agoMerge tag 'exynos-drm-next-for-v6.1' of git://git.kernel.org/pub/scm/linux/kernel...
Dave Airlie [Tue, 27 Sep 2022 18:23:00 +0000 (04:23 +1000)]
Merge tag 'exynos-drm-next-for-v6.1' of git://git./linux/kernel/git/daeinki/drm-exynos into drm-next

Cleanup
- Use drm_display_info.is_hdmi instead of drm_detect_hdmi_monitor()
  for efficiency.
Fixup
- Correct return type of mixer_mode_valid and hdmi_mode_valid functions.
  This was reported by Dan Carpenter, https://github.com/ClangBuiltLinux/linux/issues/1703

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Inki Dae <inki.dae@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220926020723.270065-1-inki.dae@samsung.com
2 years agodrm/i915/gt: Bump the reset-failure timeout to 60s
Chris Wilson [Fri, 16 Sep 2022 20:48:23 +0000 (13:48 -0700)]
drm/i915/gt: Bump the reset-failure timeout to 60s

If attempting to perform a GT reset takes long than 5 seconds (including
resetting the display for gen3/4), then we declare all hope lost and
discard all user work and wedge the device to prevent further
misbehaviour. 5 seconds is too short a time for such drastic action, as
we may be stuck on other timeouts and watchdogs. If we allow a little
bit longer before hitting the big red button, we should at the very
least capture other hung task indicators pointing towards the reason why
the reset was hanging; and allow more marginal cases the extra headroom
to complete the reset without further collateral damage.

Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/6448
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220916204823.1897089-1-ashutosh.dixit@intel.com
2 years agodrm/i915/gt: Move scratch page into system memory on all platforms
Chris Wilson [Mon, 26 Sep 2022 15:50:18 +0000 (16:50 +0100)]
drm/i915/gt: Move scratch page into system memory on all platforms

The scratch page should never be accessed, and is only assigned as a
filler page to redirection invalid userspace access. It is not of a
performance concern and so we prefer to have a single consistent
configuration across all platforms, reducing the pressure on device
memory and avoiding the direct device access that would be required to
initialise the scratch page.

Signed-off-by: Chris Wilson <chris.p.wilson@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220926155018.109678-1-matthew.auld@intel.com
2 years agodrm/i915/gt: Use i915_vm_put on ppgtt_create error paths
Chris Wilson [Mon, 26 Sep 2022 15:33:33 +0000 (16:33 +0100)]
drm/i915/gt: Use i915_vm_put on ppgtt_create error paths

Now that the scratch page and page directories have a reference back to
the i915_address_space, we cannot do an immediate free of the ppgtt upon
error as those buffer objects will perform a later i915_vm_put in their
deferred frees.

The downside is that by replacing the onion unwind along the error
paths, the ppgtt cleanup must handle a partially constructed vm. This
includes ensuring that the vm->cleanup is set prior to the error path.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6900
Signed-off-by: Chris Wilson <chris.p.wilson@intel.com>
Fixes: 4d8151ae5329 ("drm/i915: Don't free shared locks while shared")
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: <stable@vger.kernel.org> # v5.14+
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220926153333.102195-1-matthew.auld@intel.com
(cherry picked from commit c286558f58535cf97b717b946d6c96d774a09d17)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2 years agodrm/i915: Force DPLL calculation for TC ports after readout
Ville Syrjälä [Thu, 22 Sep 2022 19:12:36 +0000 (22:12 +0300)]
drm/i915: Force DPLL calculation for TC ports after readout

We always allocate two DPLLs (TC and TBT) for TC ports. This
is because we can't know ahead of time wherher we need to put
the PHY into DP-Alt or TBT mode.

However during readout we can obviously only read out the state
of the DPLL that the port is actually using. Thus the state after
readout will not have both DPLLs populated.

We run into problems if during readout the TC port is in DP-Alt
mode, but we then perform a modeset on the port without going
through the full .compute_config() machinery, and during said
modeset the port cannot be switched back into DP-Alt mode and
we need to take the TBT fallback path. Such a modeset can
happen eg. due to cdclk reprogramming.

This wasn't a problem earlier because we did all the DPLL
calculations much later in the modeset. So even if flagged
a modeset very late we'd still have gone through the DPLL
calculations. But now all the DPLL calculations happen much
earlier and so we need to deal with it, or else we'll attempt
a modeset without a DPLL.

To guarantee that we always have both DPLLs fully cal/ulated
for TC ports force a full modeset computation during the
initial commit.

v2: Avoid bitwise operation on bool (Jani)
    Call the return variable 'fastset' to convey its meaning

Reported-by: Lee Shawn C <shawn.c.lee@intel.com>
Fixes: b000abd3b3d2 ("drm/i915: Do .crtc_compute_clock() earlier")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220922191236.4194-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit eddb4afcb6c533d3f75f5f1a77e292fece27570e)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2 years agodrm/i915: fix device info for devices without display
Jani Nikula [Fri, 16 Sep 2022 08:26:42 +0000 (11:26 +0300)]
drm/i915: fix device info for devices without display

Commit 00c6cbfd4e8a ("drm/i915: move pipe_mask and cpu_transcoder_mask
to runtime info") moved the pipe_mask member from struct
intel_device_info to intel_runtime_info, but overlooked some of our
platforms initializing device info .display = {}. This is significant,
as pipe_mask is the single point of truth for a device having a display
or not; the platforms in question left pipe_mask to whatever was set for
the platforms they "inherit" from in the complex macro scheme we have.

Add new NO_DISPLAY macro initializing .__runtime.pipe_mask = 0, which
will cause the device info .display sub-struct to be zeroed in
intel_device_info_runtime_init(). A better solution (or simply audit of
proper use of HAS_DISPLAY() checks) is required before moving forward
with [1].

Also clear all the display related members in runtime info if there's no
display. The latter is a bit tedious, but it's for completeness at this
time, to ensure similar functionality as before.

[1] https://lore.kernel.org/r/dfda1bf67f02ceb07c280b7a13216405fd1f7a34.1660137416.git.jani.nikula@intel.com

Fixes: 00c6cbfd4e8a ("drm/i915: move pipe_mask and cpu_transcoder_mask to runtime info")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Maarten Lankhort <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220916082642.3451961-1-jani.nikula@intel.com
(cherry picked from commit 86570b7b126bd516aba770d1fc4c971c55c66dca)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2 years agodrm/i915: Do not cleanup obj with NULL bo->resource
Nirmoy Das [Tue, 20 Sep 2022 17:06:28 +0000 (19:06 +0200)]
drm/i915: Do not cleanup obj with NULL bo->resource

For delayed BO release i915_ttm_delete_mem_notify()
gets called twice, once with proper bo->resource and
another time with NULL. We shouldn't do anything for
the 2nd time as we already cleaned up the obj once.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/6850
Fixes: ad74457a6b5a96 ("drm/i915/dgfx: Release mmap on rpm suspend")
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220920170628.3391-1-nirmoy.das@intel.com
(cherry picked from commit fb7818989976317cc2e78008aa2df7b9fe423c86)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2 years agodrm/i915/display: remove ipc_enabled from struct drm_i915_private
Jani Nikula [Fri, 16 Sep 2022 11:38:50 +0000 (14:38 +0300)]
drm/i915/display: remove ipc_enabled from struct drm_i915_private

The ipc_enabled member was supposed to be moved under the display wm
sub-struct, but due to a rebase fail only the new one was added and the
old one was left behind. Finish the job.

Fixes: 70296670f672 ("drm/i915/display: move IPC under display wm sub-struct")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220916113850.3712354-1-jani.nikula@intel.com
(cherry picked from commit 48176104003058e2ba540fd815ec46c350d65926)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2 years agodrm/i915/guc: Fix release build bug in 'remove log size module parameters'
John Harrison [Tue, 13 Sep 2022 01:09:29 +0000 (18:09 -0700)]
drm/i915/guc: Fix release build bug in 'remove log size module parameters'

A patch was merged to remove the GuC log size override module
parameters. That patch was broken and caused kernel error messages on
boot in non CONFIG_DEBUG_GUC|GEM builds:
[   12.085121] i915 0000:00:02.0: [drm] *ERROR* Zero GuC log crash dump size!
[   12.092035] i915 0000:00:02.0: [drm] *ERROR* Zero GuC log debug size!

So fit it.

Fixes: f54e515c9180 ("drm/i915/guc: Remove log size module parameters")
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Julia Lawall <Julia.Lawall@inria.fr>
Cc: Chris Wilson <chris.p.wilson@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220913010929.2734885-2-John.C.Harrison@Intel.com
(cherry picked from commit 01f0ce3e859619ea84104d668a87ace924bd12df)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2 years agodrm/i915: Improve debug print in vm_fault_ttm
Nirmoy Das [Fri, 23 Sep 2022 14:37:30 +0000 (16:37 +0200)]
drm/i915: Improve debug print in vm_fault_ttm

Print the error code returned by __i915_ttm_migrate()
for better debuggability.

v2: Fix kernel test robot warning.
v3: Fix dim checkpatch warning.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/6889
Acked-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220923143730.13498-1-nirmoy.das@intel.com
2 years agodrm/i915/gt: Use i915_vm_put on ppgtt_create error paths
Chris Wilson [Mon, 26 Sep 2022 15:33:33 +0000 (16:33 +0100)]
drm/i915/gt: Use i915_vm_put on ppgtt_create error paths

Now that the scratch page and page directories have a reference back to
the i915_address_space, we cannot do an immediate free of the ppgtt upon
error as those buffer objects will perform a later i915_vm_put in their
deferred frees.

The downside is that by replacing the onion unwind along the error
paths, the ppgtt cleanup must handle a partially constructed vm. This
includes ensuring that the vm->cleanup is set prior to the error path.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6900
Signed-off-by: Chris Wilson <chris.p.wilson@intel.com>
Fixes: 4d8151ae5329 ("drm/i915: Don't free shared locks while shared")
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: <stable@vger.kernel.org> # v5.14+
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220926153333.102195-1-matthew.auld@intel.com
2 years agodrm/i915/gt: Restrict forced preemption to the active context
Chris Wilson [Wed, 21 Sep 2022 13:52:58 +0000 (15:52 +0200)]
drm/i915/gt: Restrict forced preemption to the active context

When we submit a new pair of contexts to ELSP for execution, we start a
timer by which point we expect the HW to have switched execution to the
pending contexts. If the promotion to the new pair of contexts has not
occurred, we declare the executing context to have hung and force the
preemption to take place by resetting the engine and resubmitting the
new contexts.

This can lead to an unfair situation where almost all of the preemption
timeout is consumed by the first context which just switches into the
second context immediately prior to the timer firing and triggering the
preemption reset (assuming that the timer interrupts before we process
the CS events for the context switch). The second context hasn't yet had
a chance to yield to the incoming ELSP (and send the ACk for the
promotion) and so ends up being blamed for the reset.

If we see that a context switch has occurred since setting the
preemption timeout, but have not yet received the ACK for the ELSP
promotion, rearm the preemption timer and check again. This is
especially significant if the first context was not schedulable and so
we used the shortest timer possible, greatly increasing the chance of
accidentally blaming the second innocent context.

Fixes: 3a7a92aba8fb ("drm/i915/execlists: Force preemption")
Fixes: d12acee84ffb ("drm/i915/execlists: Cancel banned contexts on schedule-out")
Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Tested-by: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: <stable@vger.kernel.org> # v5.5+
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220921135258.1714873-1-andrzej.hajda@intel.com
2 years agodrm/i915: move i915_coherent_map_type() to i915_gem_pages.c and un-inline
Jani Nikula [Wed, 14 Sep 2022 16:35:14 +0000 (19:35 +0300)]
drm/i915: move i915_coherent_map_type() to i915_gem_pages.c and un-inline

The inline function has no place in i915_drv.h. Move it away, un-inline,
and untangle some header dependencies while at it.

Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220914163514.1837467-1-jani.nikula@intel.com
2 years agodrm/exynos: Fix return type for mixer_mode_valid and hdmi_mode_valid
Nathan Huckleberry [Mon, 26 Sep 2022 00:31:00 +0000 (09:31 +0900)]
drm/exynos: Fix return type for mixer_mode_valid and hdmi_mode_valid

The field mode_valid in exynos_drm_crtc_ops is expected to be of type enum
drm_mode_status (*mode_valid)(struct exynos_drm_crtc *crtc,
                                   const struct drm_display_mode *mode);

Likewise for mode_valid in drm_connector_helper_funcs.

The mismatched return type breaks forward edge kCFI since the underlying
function definition does not match the function hook definition.

The return type of mixer_mode_valid and hdmi_mode_valid should be changed
from int to enum drm_mode_status.

Reported-by: Dan Carpenter <error27@gmail.com>
Link: https://protect2.fireeye.com/v1/url?k=3e644738-5fef521d-3e65cc77-
74fe485cbff6-36ad29bf912d3c9f&q=1&e=5cc06174-77dd-4abd-ab50-
155da5711aa3&u=https%3A%2F%2Fgithub.com%2FClangBuiltLinux%2Flinux%2Fissues%2F
1703
Cc: llvm@lists.linux.dev
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2 years agodrm/exynos: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
hongao [Thu, 16 Jun 2022 07:22:33 +0000 (15:22 +0800)]
drm/exynos: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi

Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi.

This driver calls drm_detect_hdmi_monitor() to receive the same
information, which is less efficient.

Avoid calling drm_detect_hdmi_monitor() and use drm_display_info.is_hdmi
instead.

Signed-off-by: hongao <hongao@uniontech.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2 years agodrm/i915/dg2: introduce Wa_22015475538
Matt Atwood [Tue, 20 Sep 2022 20:43:59 +0000 (13:43 -0700)]
drm/i915/dg2: introduce Wa_22015475538

Wa_22015475538 applies to all DG2 (and ATSM) skus. The workaround
implementation is identical to Wa_16011620976. LSC_CHICKEN_BIT_0_UDW is
a general render register instead of rcs so adding this move to the
proper wa init function.

bspec:54077

Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220920204359.103370-1-matthew.s.atwood@intel.com
2 years agodrm/i915/selftests: Remove flush_scheduled_work() from live_execlists
Tvrtko Ursulin [Thu, 30 Jun 2022 12:57:16 +0000 (13:57 +0100)]
drm/i915/selftests: Remove flush_scheduled_work() from live_execlists

There are ongoing efforts to remove usages of flush_scheduled_work() from
drivers in order to avoid several cases of potentential problems when
flushing is done from certain contexts.

Remove the call from the live_execlists selftest. Its purpose was to be
thorough and sync with the execlists capture state handling, but that is
not strictly required for the test to function and can be removed.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220630125716.50835-1-tvrtko.ursulin@linux.intel.com
2 years agodrm/amdgpu: Fix VRAM eviction issue
Arunpravin Paneer Selvam [Thu, 22 Sep 2022 15:14:47 +0000 (08:14 -0700)]
drm/amdgpu: Fix VRAM eviction issue

A user reported that when he starts a game (MTGA) with wine,
he observed an error msg failed to pin framebuffer with error -12.
Found an issue with the VRAM mem type eviction decision condition
logic. This patch will fix the if condition code error.

Gitlab bug link:
https://gitlab.freedesktop.org/drm/amd/-/issues/2159

Fixes: ded910f368a5 ("drm/amdgpu: Implement intersect/compatible functions")
Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220922151447.265696-1-Arunpravin.PaneerSelvam@amd.com
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
2 years agoMerge tag 'du-next-20220907' of git://linuxtv.org/pinchartl/media into drm-next
Dave Airlie [Thu, 22 Sep 2022 17:34:08 +0000 (03:34 +1000)]
Merge tag 'du-next-20220907' of git://linuxtv.org/pinchartl/media into drm-next

- Misc fixes and improvements to the R-Car DU driver
- Synopsys DW HDMI bridge DT bindings update

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/YxkL+tRI8uXDCvj9@pendragon.ideasonboard.com
2 years agodrm/i915: Noop lrc_init_wa_ctx() on recent/future platforms
Lucas De Marchi [Wed, 7 Sep 2022 23:08:41 +0000 (16:08 -0700)]
drm/i915: Noop lrc_init_wa_ctx() on recent/future platforms

Except for graphics version 8 and 9, nothing is done in
lrc_init_wa_ctx(). Assume this won't be needed on future platforms as
well and remove the warning.

Note that this function is not called for anything below version 8 since
those don't use either guc or execlist, i.e. HAS_EXECLISTS() is false.

Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220907230841.1703574-1-lucas.demarchi@intel.com
2 years agodrm/i915/dgfx: Make failure to setup stolen non-fatal
Lucas De Marchi [Fri, 16 Sep 2022 17:36:08 +0000 (10:36 -0700)]
drm/i915/dgfx: Make failure to setup stolen non-fatal

There is no reason to consider the setup of Data Stolen Memory fatal on
dgfx and non-fatal on integrated. Move the debug and error propagation
around so both have the same behavior: non-fatal. Before this change,
loading i915 on a system with TGL + DG2 would result in just TGL
succeeding the initialization (without stolen).

Now loading i915 on the same system with an injected failure in
i915_gem_init_stolen():

$ dmesg | grep stolen
i915 0000:00:02.0: [drm] Injected failure, disabling use of stolen memory
i915 0000:00:02.0: [drm:init_stolen_smem [i915]] Skip stolen region: failed to setup
i915 0000:03:00.0: [drm] Injected failure, disabling use of stolen memory
i915 0000:03:00.0: [drm:init_stolen_lmem [i915]] Skip stolen region: failed to setup

Both GPUs are still available:

$ sudo build/tools/lsgpu
card1                    Intel Dg2 (Gen12)                 drm:/dev/dri/card1
└─renderD129                                               drm:/dev/dri/renderD129
card0                    Intel Tigerlake (Gen12)           drm:/dev/dri/card0
└─renderD128                                               drm:/dev/dri/renderD128

Reviewed-by: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220915-stolen-v2-3-20ff797de047@intel.com
2 years agodrm/i915: Split i915_gem_init_stolen()
Lucas De Marchi [Fri, 16 Sep 2022 17:36:07 +0000 (10:36 -0700)]
drm/i915: Split i915_gem_init_stolen()

Add some helpers: adjust_stolen(), request_smem_stolen_() and
init_reserved_stolen() that are now called by i915_gem_init_stolen() to
initialize each part of the Data Stolen Memory region.

Main goal is to split the reserved part within the stolen, also known as
WOPCM, as its calculation changes often per platform and is a big source
of confusion when handling stolen memory.

Reviewed-by: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220915-stolen-v2-2-20ff797de047@intel.com
2 years agodrm/i915: Add missing mask when reading GEN12_DSMBASE
Lucas De Marchi [Fri, 16 Sep 2022 17:36:06 +0000 (10:36 -0700)]
drm/i915: Add missing mask when reading GEN12_DSMBASE

DSMBASE register is defined so BDSM bitfield contains the bits 63 to 20
of the base address of stolen. For the supported platforms bits 0-19 are
zero but that may not be true in future. Add the missing mask.

v2: Use REG_GENMASK64()

Acked-by: Aravind Iddamsetty <aravind.iddamsetty@intel.com>
Reviewed-by: Caz Yokoyama <caz@caztech.com>
Reviewed-by: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220915-stolen-v2-1-20ff797de047@intel.com
2 years agodrm/i915: Split GAM and MSLICE steering
Matt Roper [Fri, 16 Sep 2022 01:43:45 +0000 (18:43 -0700)]
drm/i915: Split GAM and MSLICE steering

Although the bspec lists several MMIO ranges as "MSLICE," it turns out
that a subset of these are of a "GAM" subclass that has unique rules and
doesn't followed regular mslice steering behavior.

 * Xe_HP SDV:  GAM ranges must always be steered to 0,0.  These
   registers share the regular steering control register (0xFDC) with
   other steering types

 * DG2:  GAM ranges must always be steered to 1,0.  GAM registers have a
   dedicated steering control register (0xFE0) so we can set the value
   once at startup and rely on implicit steering.  Technically the
   hardware default should already be set to 1,0 properly, but it never
   hurts to ensure that in the driver.

Bspec: 66534
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220916014345.3317739-1-matthew.d.roper@intel.com
2 years agodrm/amdgpu: Fix amdgpu_vm_pt_free warning
Philip Yang [Mon, 12 Sep 2022 15:49:19 +0000 (11:49 -0400)]
drm/amdgpu: Fix amdgpu_vm_pt_free warning

Free page table BO from vm resv unlocked context generate below
warnings.

Add a pt_free_work in vm to free page table BO from vm->pt_freed list.
pass vm resv unlock status from page table update caller, and add vm_bo
entry to vm->pt_freed list and schedule the pt_free_work if calling with
vm resv unlocked.

WARNING: CPU: 12 PID: 3238 at
drivers/gpu/drm/ttm/ttm_bo.c:106 ttm_bo_set_bulk_move+0xa1/0xc0
Call Trace:
 amdgpu_vm_pt_free+0x42/0xd0 [amdgpu]
 amdgpu_vm_pt_free_dfs+0xb3/0xf0 [amdgpu]
 amdgpu_vm_ptes_update+0x52d/0x850 [amdgpu]
 amdgpu_vm_update_range+0x2a6/0x640 [amdgpu]
 svm_range_unmap_from_gpus+0x110/0x300 [amdgpu]
 svm_range_cpu_invalidate_pagetables+0x535/0x600 [amdgpu]
 __mmu_notifier_invalidate_range_start+0x1cd/0x230
 unmap_vmas+0x9d/0x140
 unmap_region+0xa8/0x110

Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2 years agodrm/amdgpu: Use vm status_lock to protect pt free
Philip Yang [Fri, 16 Sep 2022 13:30:43 +0000 (09:30 -0400)]
drm/amdgpu: Use vm status_lock to protect pt free

Use vm_status_lock to protect all vm_status state transitions to allow
them to happen without a reservation lock in unlocked page table
updates.

Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2 years agodrm/amdgpu: Use vm status_lock to protect vm evicted list
Philip Yang [Fri, 16 Sep 2022 03:21:15 +0000 (23:21 -0400)]
drm/amdgpu: Use vm status_lock to protect vm evicted list

Use vm_status_lock to protect all vm_status state transitions to allow
them to happen without a reservation lock in unlocked page table
updates.

Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>