#
326e30e4 |
| 20-Mar-2024 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: Drop dead code for pvc
PCI IDs for PVC were never added and platform always marked with force_probe. Drop what's not used and rename some places as needed.
The registers not used anymore
drm/i915: Drop dead code for pvc
PCI IDs for PVC were never added and platform always marked with force_probe. Drop what's not used and rename some places as needed.
The registers not used anymore are also removed.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://patchwork.freedesktop.org/patch/msgid/20240320060543.4034215-6-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
show more ...
|
#
48ba4a6d |
| 20-Mar-2024 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: Update IP_VER(12, 50)
With no platform using graphics/media IP_VER(12, 50), replace the checks throughout the code with IP_VER(12, 55) so the code makes sense by itself with no additional
drm/i915: Update IP_VER(12, 50)
With no platform using graphics/media IP_VER(12, 50), replace the checks throughout the code with IP_VER(12, 55) so the code makes sense by itself with no additional explanation of previous baggage.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://patchwork.freedesktop.org/patch/msgid/20240320060543.4034215-5-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
show more ...
|
#
ecab2a6e |
| 20-Mar-2024 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: Remove XEHP_FWRANGES()
Now that DG2 is the only user of this forcewake table, remove the macro and use FORCEWAKE_RENDER explicitly for range 0xd800 - 0xd87f.
Suggested-by: Matt Roper <mat
drm/i915: Remove XEHP_FWRANGES()
Now that DG2 is the only user of this forcewake table, remove the macro and use FORCEWAKE_RENDER explicitly for range 0xd800 - 0xd87f.
Suggested-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Acked-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://patchwork.freedesktop.org/patch/msgid/20240320060543.4034215-3-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
show more ...
|
#
cb4046d2 |
| 20-Mar-2024 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: Drop dead code for xehpsdv
PCI IDs for XEHPSDV were never added and platform always marked with force_probe. Drop what's not used and rename some places to either be xehp or dg2, depending
drm/i915: Drop dead code for xehpsdv
PCI IDs for XEHPSDV were never added and platform always marked with force_probe. Drop what's not used and rename some places to either be xehp or dg2, depending on the platform/IP checks.
The registers not used anymore are also removed.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://patchwork.freedesktop.org/patch/msgid/20240320060543.4034215-2-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
show more ...
|
#
6d46d09a |
| 19-Jan-2024 |
Vinay Belgaumkar <vinay.belgaumkar@intel.com> |
drm/i915/mtl: Wake GT before sending H2G message
Instead of waiting until the interrupt reaches GuC, we can grab a forcewake while triggering the H2G interrupt. GEN11_GUC_HOST_INTERRUPT is inside sg
drm/i915/mtl: Wake GT before sending H2G message
Instead of waiting until the interrupt reaches GuC, we can grab a forcewake while triggering the H2G interrupt. GEN11_GUC_HOST_INTERRUPT is inside sgunit and is not affected by forcewakes. However, there could be some delays when platform is entering/exiting some higher level platform sleep states and a H2G is triggered. A forcewake ensures those sleep states have been fully exited and further processing occurs as expected. The hysteresis timers for C6 and higher sleep states will ensure there is no unwanted race between the wake and processing of the interrupts by GuC.
This will have an official WA soon so adding a FIXME in the comments.
v2: Make the new ranges watertight to address BAT failures and update commit message (Matt R).
Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240119193513.221730-1-vinay.belgaumkar@intel.com
show more ...
|
#
d823445b |
| 01-Aug-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/uncore: fix race around i915->params.mmio_debug
Only check the conditions for unclaimed reg debug once to avoid locking problems when i915->params.mmio_debug changes between header and foot
drm/i915/uncore: fix race around i915->params.mmio_debug
Only check the conditions for unclaimed reg debug once to avoid locking problems when i915->params.mmio_debug changes between header and footer.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8749 Cc: Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a53fb0fd84c4627398ccd4304b35db05603b89b6.1690886109.git.jani.nikula@intel.com
show more ...
|
#
7afe2340 |
| 01-Aug-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/uncore: split unclaimed_reg_debug() to header and footer
Make it easier to have different logic for the two for follow-up.
Cc: Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by: Tvrtko Ursul
drm/i915/uncore: split unclaimed_reg_debug() to header and footer
Make it easier to have different logic for the two for follow-up.
Cc: Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8a0a93f08314f8d7e222a907d9aa5e0b89cb969e.1690886109.git.jani.nikula@intel.com
show more ...
|
#
fdd9b7dc |
| 27-Mar-2023 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Check for unreliable MMIO during forcewake
Although we now sanitycheck MMIO access during driver load to make sure the MMIO BAR isn't returning all 0xFFFFFFFF, there have been a few cases
drm/i915: Check for unreliable MMIO during forcewake
Although we now sanitycheck MMIO access during driver load to make sure the MMIO BAR isn't returning all 0xFFFFFFFF, there have been a few cases where (temporarily?) unreliable MMIO access has happened after GPU resets or power events. We'll often notice this on our next GT register access since forcewake handling will fail; let's change our handling slightly so that when this happens we print a more meaningful message clarifying that the problem is the MMIO access, not forcewake specifically.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.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/20230327195547.356584-3-andi.shyti@linux.intel.com
show more ...
|
#
de414973 |
| 27-Mar-2023 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Sanitycheck MMIO access early in driver load
We occasionally see the PCI device in a non-accessible state at the point the driver is loaded. When this happens, all BAR accesses will read
drm/i915: Sanitycheck MMIO access early in driver load
We occasionally see the PCI device in a non-accessible state at the point the driver is loaded. When this happens, all BAR accesses will read back as 0xFFFFFFFF. Rather than reading registers and misinterpreting their (invalid) values, let's specifically check for 0xFFFFFFFF in a register that cannot have that value to see if the device is accessible.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.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/20230327195547.356584-2-andi.shyti@linux.intel.com
show more ...
|
#
95ccb25e |
| 01-Mar-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: remove unnecessary intel_pm.h includes
As intel_pm.[ch] used to contain much more, intel_pm.h was included in a lot of places. Many of them are now unnecessary. Remove.
Signed-off-by: Jan
drm/i915: remove unnecessary intel_pm.h includes
As intel_pm.[ch] used to contain much more, intel_pm.h was included in a lot of places. Many of them are now unnecessary. Remove.
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ab9a7147b0cd63d95b9f27ed40615b9c9be18f84.1677678803.git.jani.nikula@intel.com
show more ...
|
#
0591bdad |
| 24-Feb-2023 |
Alan Previn <alan.previn.teres.alexis@intel.com> |
drm/i915/gsc: Fix the Driver-FLR completion
The Driver-FLR flow may inadvertently exit early before the full completion of the re-init of the internal HW state if we only poll GU_DEBUG Bit31 (pollin
drm/i915/gsc: Fix the Driver-FLR completion
The Driver-FLR flow may inadvertently exit early before the full completion of the re-init of the internal HW state if we only poll GU_DEBUG Bit31 (polling for it to toggle from 0 -> 1). Instead we need a two-step completion wait-for-completion flow that also involves GU_CNTL. See the patch and new code comments for detail. This is new direction from HW architecture folks.
v2: - Add error message for the teardown timeout (Anshuman) - Don't duplicate code in comments (Jani) v3: - Add get/put runtime-pm for this function. Though not functionally required during unload, its so the uncore doesn't complain. v4: - Remove the get/put runtime-pm - that was for a prior version of this patch (not needed for drm-managed callback). - Remove the fixes tag since this is only for MTL and MTL still needs force probe (Daniele). - Bit 31 of GU_CNTL should be DRIVERFLR instead of DRIVERFLR_STATUS (Daniele).
Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Tested-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230224001758.544817-1-alan.previn.teres.alexis@intel.com
show more ...
|
#
70994bec |
| 07-Feb-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/uncore: cast iomem to avoid sparse warning
drmm_add_action_or_reset() is unaware of __iomem and the pointer needs to be a plain void *. Cast __iomem away and back while the pointer goes thr
drm/i915/uncore: cast iomem to avoid sparse warning
drmm_add_action_or_reset() is unaware of __iomem and the pointer needs to be a plain void *. Cast __iomem away and back while the pointer goes through drmm.
drivers/gpu/drm/i915/intel_uncore.c:2463:17: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915/intel_uncore.c:2463:17: expected void volatile [noderef] __iomem *addr drivers/gpu/drm/i915/intel_uncore.c:2463:17: got void *regs drivers/gpu/drm/i915/intel_uncore.c:2494:16: warning: incorrect type in argument 3 (different address spaces) drivers/gpu/drm/i915/intel_uncore.c:2494:16: expected void *data drivers/gpu/drm/i915/intel_uncore.c:2494:16: got void [noderef] __iomem *regs
Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207124026.2105442-2-jani.nikula@intel.com
show more ...
|
#
449a0ef5 |
| 07-Dec-2022 |
Miaoqian Lin <linmq006@gmail.com> |
drm/i915: Fix documentation for intel_uncore_forcewake_put__locked
intel_uncore_forcewake_put__locked() is used to release a reference.
Fixes: a6111f7b6604 ("drm/i915: Reduce locking in execlist co
drm/i915: Fix documentation for intel_uncore_forcewake_put__locked
intel_uncore_forcewake_put__locked() is used to release a reference.
Fixes: a6111f7b6604 ("drm/i915: Reduce locking in execlist command submission") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221207112909.2655251-1-linmq006@gmail.com (cherry picked from commit 955f4d7176eb154db587ae162ec2b392dc8d5f27) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
show more ...
|
#
6b7cbdbe |
| 08-Dec-2022 |
Jonathan Cavitt <jonathan.cavitt@intel.com> |
drm/i915/gsc: Disable GSC engine and power well if FW is not selected
The GSC CS is only used for communicating with the GSC FW, so no need to initialize it if we're not going to use the FW. If we'r
drm/i915/gsc: Disable GSC engine and power well if FW is not selected
The GSC CS is only used for communicating with the GSC FW, so no need to initialize it if we're not going to use the FW. If we're not using neither the engine nor the microcontoller, then we can also disable the power well.
IMPORTANT: lack of GSC FW breaks media C6 due to opposing requirements between CS setup and forcewake idleness. See in-code comment for detail.
Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: John C Harrison <John.C.Harrison@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221208200521.2928378-6-daniele.ceraolospurio@intel.com
show more ...
|
#
5a44fcd7 |
| 08-Dec-2022 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded
If the GSC was loaded, the only way to stop it during the driver unload flow is to do a driver-FLR. The driver-initiated FLR is not the same
drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded
If the GSC was loaded, the only way to stop it during the driver unload flow is to do a driver-FLR. The driver-initiated FLR is not the same as PCI config space FLR in that it doesn't reset the SGUnit and doesn't modify the PCI config space. Thus, it doesn't require a re-enumeration of the PCI BARs. However, the driver-FLR does cause a memory wipe of graphics memory on all discrete GPU platforms or a wipe limited to stolen memory on the integrated GPU platforms.
We perform the FLR as the last action before releasing the MMIO bar, so that we don't have to care about the consequences of the reset on the unload flow.
v2: rename FLR function, add comment to explain FLR impact (Rodrigo), better explain why GSC needs FLR (Alan)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221208200521.2928378-5-daniele.ceraolospurio@intel.com
show more ...
|
#
801543b2 |
| 09-Nov-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: stop including i915_irq.h from i915_trace.h
Turns out many of the files that need i915_reg.h get it implicitly via {display/intel_de.h, gt/intel_context.h} -> i915_trace.h -> i915_irq.h ->
drm/i915: stop including i915_irq.h from i915_trace.h
Turns out many of the files that need i915_reg.h get it implicitly via {display/intel_de.h, gt/intel_context.h} -> i915_trace.h -> i915_irq.h -> i915_reg.h. Since i915_trace.h doesn't actually need i915_irq.h, makes sense to drop it, but that requires adding quite a few new includes all over the place.
Prefer including i915_reg.h where needed instead of adding another implicit include, because eventually we'll want to split up i915_reg.h and only include the specific registers at each place.
Also some places actually needed i915_irq.h too.
Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6e78a2e0ac1bffaf5af3b5ccc21dff05e6518cef.1668008071.git.jani.nikula@intel.com
show more ...
|
#
a10234fd |
| 09-Nov-2022 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Partial abandonment of legacy DRM logging macros
Convert some usages of legacy DRM logging macros into versions which tell us on which device have the events occurred.
v2: * Don't have s
drm/i915: Partial abandonment of legacy DRM logging macros
Convert some usages of legacy DRM logging macros into versions which tell us on which device have the events occurred.
v2: * Don't have struct drm_device as local. (Jani, Ville)
v3: * Store gt, not i915, in workaround list. (John)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221109104633.2579245-1-tvrtko.ursulin@linux.intel.com
show more ...
|
#
2d3093fd |
| 14-Oct-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/pvc: Update forcewake domain for CCS register ranges
The bspec was just updated with a correction to the forcewake domain required when accessing registers in the CCS engine ranges (0x1a000
drm/i915/pvc: Update forcewake domain for CCS register ranges
The bspec was just updated with a correction to the forcewake domain required when accessing registers in the CCS engine ranges (0x1a000 - 0x1ffff and 0x26000 - 0x27fff) on PVC; these ranges require a wake on the RENDER domain, not the GT domain.
Bspec: 67609 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221014233004.1053678-1-matthew.d.roper@intel.com
show more ...
|
#
14f2f9bf |
| 10-Sep-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/mtl: Add MTL forcewake support
MTL has separate forcewake tables for the primary/render GT and the media GT; each GT's intel_uncore will use a separate forcewake table and should only initi
drm/i915/mtl: Add MTL forcewake support
MTL has separate forcewake tables for the primary/render GT and the media GT; each GT's intel_uncore will use a separate forcewake table and should only initialize the domains that are relevant to that GT. The GT ack register also moves to a new location of (GSI base + 0xDFC) on this platform.
Note that although our uncore handlers take care of transparently redirecting all register accesses in the media GT's GSI range to their new offset at 0x380000, the forcewake ranges listed in the table should use the final, post-translation offsets.
NOTE: There are two ranges in the media IP that have multicast registers where the two register instances reside in different power wells (either VD0 or VD2). We don't have an easy way to deal with this today (and in fact we don't even access these register ranges in the driver today), so for now we just mark those ranges as FORCEWAKE_ALL which will cause all of the media power wells to be grabbed, ensuring proper operation. If we start reading/writing in those ranges in the future, we can re-visit whether it's worth adding extra steering complexity into our forcewake support.
Bspec: 67788, 67789, 52077 Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220910001631.1986601-1-matthew.d.roper@intel.com
show more ...
|
#
eefac38a |
| 08-Sep-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/uncore: Add GSI offset to uncore
GT non-engine registers (referred to as "GSI" registers by the spec) have the same relative offsets on standalone media as they do on the primary GT, just w
drm/i915/uncore: Add GSI offset to uncore
GT non-engine registers (referred to as "GSI" registers by the spec) have the same relative offsets on standalone media as they do on the primary GT, just with an additional "GSI offset" added to their MMIO address. If we store this GSI offset in the standalone media's intel_uncore structure, it can be automatically applied to all GSI reg reads/writes that happen on that GT, allowing us to re-use our existing GT code with minimal changes.
Forcewake and shadowed register tables for the media GT (which will be added in a future patch) are listed as final addresses that already include the GSI offset, so we also need to add the GSI offset before doing lookups of registers in one of those tables.
v2: - Add comment on raw_reg_*() macros explaining why we don't bother with GSI offsets in them. (Daniele)
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220908224550.821257-1-matthew.d.roper@intel.com Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
show more ...
|
#
cfb0fa42 |
| 06-Sep-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Initialize MMIO access for each GT
In a multi-GT system we need to initialize MMIO access for each GT, not just the primary GT.
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com
drm/i915: Initialize MMIO access for each GT
In a multi-GT system we need to initialize MMIO access for each GT, not just the primary GT.
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906234934.3655440-9-matthew.d.roper@intel.com Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
show more ...
|
#
9ebb80e8 |
| 06-Sep-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Drop intel_gt_tile_cleanup()
Unmapping of the MMIO range can be done as a DRM-managed action, which will take care of the unmapping on device teardown and error paths. This will also ensur
drm/i915: Drop intel_gt_tile_cleanup()
Unmapping of the MMIO range can be done as a DRM-managed action, which will take care of the unmapping on device teardown and error paths. This will also ensure proper ordering with respect to other DRM-managed actions that we'll be using to clean up non-primary GTs in upcoming patches.
We have not yet enabled any non-root GTs in the driver yet, so the kfree() of the GT structure is effectively dead code. When we do start enabling non-root GTs in upcoming patches, those are going to be using DRM-managed allocations tied to the device lifetime, so we don't need to explicitly free them (and kfree would be incorrect anyway).
Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906234934.3655440-5-matthew.d.roper@intel.com Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
show more ...
|
#
639e30ee |
| 06-Sep-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Only hook up uncore->debug for primary uncore
The original intent of intel_uncore_mmio_debug as described in commit 0a9b26306d6a ("drm/i915: split out uncore_mmio_debug") was to be a singl
drm/i915: Only hook up uncore->debug for primary uncore
The original intent of intel_uncore_mmio_debug as described in commit 0a9b26306d6a ("drm/i915: split out uncore_mmio_debug") was to be a singleton structure that could be shared between multiple GTs' uncore objects in a multi-tile system. Somehow we went off track and started allocating separate instances of this structure for each GT, which defeats that original goal.
But in reality, there isn't even a need to share the mmio_debug between multiple GTs; on all modern platforms (i.e., everything after gen7) unclaimed register accesses are something that can only be detected for display registers. There's no point in grabbing the debug spinlock and checking for unclaimed accesses on an uncore used by an xehpsdv or pvc remote tile GT, or the uncore used by a mtl standalone media GT since all of the display accesses go through the primary intel_uncore.
The simplest solution is to simply leave uncore->debug NULL on all intel_uncore instances except for the primary one. This will allow us to avoid the pointless debug spinlock acquisition we've been doing on MMIO accesses coming in through these intel_uncores.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906234934.3655440-3-matthew.d.roper@intel.com Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
show more ...
|
#
f16bfc1d |
| 06-Sep-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume}
Moving the locking for MMIO debug (and the final check for unclaimed accesses when resuming debug after a userspace-initi
drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume}
Moving the locking for MMIO debug (and the final check for unclaimed accesses when resuming debug after a userspace-initiated forcewake) will make it simpler to completely skip MMIO debug handling on uncores that don't support it in future patches.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906234934.3655440-2-matthew.d.roper@intel.com Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
show more ...
|
#
da30390b |
| 18-Aug-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/mtl: MMIO range is now 4MB
Previously only dgfx platforms had a 4MB MMIO range, but starting with MTL we now use the larger range for all platforms.
Bspec: 63834, 63830 Signed-off-by: Matt
drm/i915/mtl: MMIO range is now 4MB
Previously only dgfx platforms had a 4MB MMIO range, but starting with MTL we now use the larger range for all platforms.
Bspec: 63834, 63830 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220818234202.451742-4-radhakrishna.sripada@intel.com
show more ...
|