Select Git revision
Search by author
- Any Author
- authors
-
Aaron Watry awatry
-
Adam Jackson ajax
-
Adela Rybak adelaryb
-
Aditya Swarup aswarup
-
Alan Previn Teres Alexi alan_previn_intel
-
Alejandro Piñeiro
apinheiro
-
Alexander Usyskin
ausyskin
-
Alexander von Gluck kallisti5
-
Alex Deucher agd5f
-
Alex Smith aejsmith
-
Alok Hota
ahota
-
Alyssa Rosenzweig
alyssa
-
Andreas Baierl rellla
-
Andreas Boll ab
-
Andres Gomez tanty
-
Andres Rodriguez lostgoat
-
Andrey Grodzovsky
agrodzov
-
Andrzej Hajda andrzej.hajda
-
AnkithaRathod AnkithaRathod
-
Anshuman Gupta anshuma1
- Jun 02, 2023
-
-
Printing HDCP feature missing log at KERN_ERR log level upsets CI. Reduce it to KERN_INFO log level. Also correct a typo in the log. Signed-off-by:
Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 241c03cc)
-
DRM_ERROR() has been deprecated in favor of pr_err(). However, we should prefer to use xe_gt_err() or drm_err() whenever possible so we get gt- or device-specific output with the error message. v2: - Prefer drm_err() over pr_err(). (Matt, Jani) v3: - Prefer xe_gt_err() over drm_err() when possible. (Matt) v4: - Use the already available dev variable instead of xe->drm as parameter to drm_err(). (Matt) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Haridhar Kalvala <haridhar.kalvala@intel.com> Reviewed-by:Gustavo Sousa <gustavo.sousa@intel.com> (cherry picked from commit 80460df6)
-
v2: - Fix doubled word. (Lucas) Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230601215244.678611-32-matthew.d.roper@intel.com Signed-off-by:
-
Now that tiles and GTs are handled separately and other prerequisite changes are in place, we're ready to re-enable the media GT. Reviewed-by:
-
Now that a higher GT count can result from either multiple tiles (with one GT each) or an extra media GT within the root tile, we need to update the query code slightly to stop looking at tile_count. FIXME: As noted previously, we need to decide on a formal direction for exposing tiles and/or GTs to userspace. v2: - Drop num_gt() function in favor of stored xe->info.gt_count. (Brian) v3: - Keep XE_QUERY_GT_TYPE_REMOTE around for now. Userspace probably doesn't actually need this, and we may remove it in the future, but for now let's avoid changing uapi. (Brian) Cc: Brian Welty <brian.welty@intel.com> Reviewed-by:
Brian Welty <brian.welty@intel.com> Link: https://lore.kernel.org/r/20230601215244.678611-30-matthew.d.roper@intel.com Signed-off-by:
-
Allow xe_device_get_gt() and for_each_gt() to operate as expected on platforms with standalone media. FIXME: We need to figure out a consistent ID scheme for GTs. This patch keeps the pre-existing behavior of 0/1 being the GT IDs for both PVC (multi-tile) and MTL (multi-GT), but depending on the direction we decide to go with uapi, we may change this in the future (e.g., to return 0/1 on PVC and 0/2 on MTL). Or if we decide we only need to expose tiles to userspace and not GTs, we may not even need ID numbers for the GTs anymore. v2: - Restructure a bit to make the assertions more clear. - Clarify in commit message that the goal here is to preserve existing behavior; UAPI-visible changes may be introduced in the future once we settle on what we really want. v3: - Store total GT count in xe_device for ease of lookup. (Brian) - s/(id__++)/(id__)++/ (Gustavo) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Cc: Brian Welty <brian.welty@intel.com> Acked-by:
-
Updates to the GGTT can happen when there are no in-flight jobs keeping the hardware awake. If the GT is powered down when invalidation is requested, we will not be able to communicate with the GuC (or MMIO) and the invalidation request will go missing. Explicitly grab GT forcewake to ensure the GT and GuC are powered up during the TLB invalidation. Reviewed-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://lore.kernel.org/r/20230601215244.678611-28-matthew.d.roper@intel.com Signed-off-by:
-
The GGTT is part of the tile and is shared by the primary and media GTs on platforms with a standalone media architecture. However each of these GTs has its own TLBs caching the page table lookups, and each needs to be invalidated separately. Reviewed-by:
-
The majority of xe_gt_irq_postinstall() is really focused on the hardware engine interrupts; other GT-related interrupts such as the GuC are enabled/disabled independently. Renaming the function and making it truly GT-specific will make it more clear what the intended focus is. Disabling/masking of other interrupts (such as GuC interrupts) is unnecessary since that has already happened during the irq_reset stage, and doing so will become harmful once the media GT is re-enabled since calls to xe_gt_irq_postinstall during media GT initialization would incorrectly disable the primary GT's GuC interrupts. Also, since this function is called from gt_fw_domain_init(), it's not necessary to also call it earlier during xe_irq_postinstall; just xe_irq_resume to handle runtime resume should be sufficient. v2: - Drop unnecessary !gt check. (Lucas) - Reword some comments about enable/unmask for clarity. (Lucas) Reviewed-by:
-
The xe_irq_postinstall() never actually gets called after installing the interrupt handler. This oversight seems to get papered over due to the fact that the (misnamed) xe_gt_irq_postinstall does more than it really should and gets called in the middle of the GT initialization. The callstack for postinstall is also a bit muddled with top-level device interrupt enablement happening within platform-specific functions called from the per-tile xe_gt_irq_postinstall() function. Clean this all up by adding the missing call to xe_irq_postinstall() after installing the interrupt handler and pull top-level irq enablement up to xe_irq_postinstall where we'd expect it to be. The xe_gt_irq_postinstall() function is still a bit misnamed here; an upcoming patch will refocus its purpose and rename it. v2: - Squash in patch to actually call xe_irq_postinstall() after installing the interrupt handler. Reviewed-by:
-
Although primary and media GuC share a single interrupt enable bit, they each have distinct bits in the mask register. Although we always enable interrupts for the primary GuC before the media GuC today (and never disable either of them), this might not always be the case in the future, so use a RMW when updating the mask register to ensure the other GuC's mask doesn't get clobbered. Reviewed-by:
-
Our only use of GUnit interrupts is to handle ASLE backlight operations that are reported as GUnit GSE interrupts. Move the enable/disable of these interrupts adjacent to display interrupts. In the future we may want to even move these inside the xe_display_irq_*() functions. But since these rely on xe_irq static functions like mask_and_disable() it's easier to keep them separate for now. Reviewed-by:
-
IRQ delivery and handling needs to be handled on a per-tile basis. Note that this is true even for the "GT interrupts" relating to engines and GuCs --- the interrupts relating to both GTs get raised through a single set of registers in the tile's sgunit range. On true multi-tile platforms, interrupts on remote tiles are internally forwarded to the root tile; the first thing the top-level interrupt handler should do is consult the root tile's instance of DG1_MSTR_TILE_INTR to determine which tile(s) had interrupts. This register is also responsible for enabling/disabling top-level reporting of any interrupts to the OS. Although this register technically exists on all tiles, it should only be used on the root tile. The (mis)use of struct xe_gt as a target for MMIO operations in the driver makes the code somewhat confusing since we wind up needing a GT pointer to handle programming that's unrelated to the GT. To mitigate this confusion, all of the xe_gt structures used solely as an MMIO target in interrupt code are renamed to 'mmio' so that it's clear that the structure being passed does not necessarily relate to any specific GT (primary or media) that we might be dealing with interrupts for. Reworking the driver's MMIO handling to not be dependent on xe_gt is planned as a future patch series. Note that GT initialization code currently calls xe_gt_irq_postinstall() in an attempt to enable the HWE interrupts for the GT being initialized. Unfortunately xe_gt_irq_postinstall() doesn't really match its name and does a bunch of other stuff unrelated to the GT interrupts (such as enabling the top-level device interrupts). That will be addressed in future patches. v2: - Clarify commit message with explanation of why DG1_MSTR_TILE_INTR is only used on the root tile, even though it's an sgunit register that is technically present in each tile's MMIO space. (Aravind) - Also clarify that the xe_gt used as a target for MMIO operations may or may not relate to the GT we're dealing with for interrupts. (Lucas) Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Reviewed-by:
Aravind Iddamsetty <aravind.iddamsetty@intel.com> Link: https://lore.kernel.org/r/20230601215244.678611-22-matthew.d.roper@intel.com Signed-off-by:
-
Display interrupts are unrelated to the GT (and are also only relevant to the root tile). Move the postinstall call up a level in the callstack. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
This media_gt pointer isn't actually allocated yet. Future patches will start hooking it up at appropriate places in the code, and then creation of the media GT will be added once those infrastructure changes are in place. Reviewed-by:
-
In preparation for re-adding media GT support, switch the primary GT within the tile to a dynamic allocation. Reviewed-by:
-
Now that tiles and GTs are handled separately, extra_gts[] doesn't really provide any useful information that we can't just infer directly. The primary GT of the root tile and of the remote tiles behave the same way and don't need independent handling. When we re-add support for media GTs in a future patch, the presence of media can be determined from MEDIA_VER() (i.e., >= 13) and media's GSI offset handling is expected to remain constant for all forseeable future platforms, so it won't need to be provided in a definition structure either. Reviewed-by:
-
The VRAM ID is always the tile ID; there's no need to track it separately within a GT. Reviewed-by:
-
There are a bunch of places in the driver where we need to perform non-GT MMIO against the platform's primary tile (display code, top-level interrupt enable/disable, driver initialization, etc.). Rename 'to_gt()' to 'xe_primary_mmio_gt()' to clarify that we're trying to get a primary MMIO handle for these top-level operations. In the future we need to move away from xe_gt as the target for MMIO operations (most of which are completely unrelated to GT). v2: - s/xe_primary_mmio_gt/xe_root_mmio_gt/ for more consistency with how we refer to tile 0. (Lucas) v3: - Tweak comment on xe_root_mmio_gt(). (Lucas) Acked-by:
-
Migration primarily focuses on the memory associated with a tile, so it makes more sense to track this at the tile level (especially since the driver was already skipping migration operations on media GTs). Note that the blitter engine used to perform the migration always lives in the tile's primary GT today. In theory that could change if media GTs ever start including blitter engines in the future, but we can extend the design if/when that happens in the future. v2: - Fix kunit test build - Kerneldoc parameter name update v3: - Removed leftover prototype for removed function. (Gustavo) - Remove unrelated / unwanted error handling change. (Gustavo) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
-
Reviewed-by:
-
Since memory and address spaces are a tile concept rather than a GT concept, we need to plumb tile-based handling through lots of memory-related code. Note that one remaining shortcoming here that will need to be addressed before media GT support can be re-enabled is that although the address space is shared between a tile's GTs, each GT caches the PTEs independently in their own TLB and thus TLB invalidation should be handled at the GT level. v2: - Fix kunit test build. Reviewed-by:
-
Reviewed-by:
-
On platforms with VRAM, the VRAM is associated with the tile, not the GT. v2: - Unsquash the GGTT handling back into its own patch. - Fix kunit test build v3: - Tweak the "FIXME" comment to clarify that this function will be completely gone by the end of the series. (Lucas) v4: - Move a few changes that were supposed to be part of the GGTT patch back to that commit. (Gustavo) v5: - Kerneldoc parameter name fix. Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
-
Reviewed-by:
-
The GGTT exists at the tile level. When a tile contains multiple GTs, they share the same GGTT. v2: - Include some changes that were mis-squashed into the VRAM patch. (Gustavo) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
-
Reviewed-by:
-
Each tile has its own register region in the BAR, containing instances of all registers for the platform. In contrast, the multiple GTs within a tile share the same MMIO space; there's just a small subset of registers (the GSI registers) which have multiple copies at different offsets (0x0 for primary GT, 0x380000 for media GT). Move the register MMIO region size/pointers to the tile structure, leaving just the GSI offset information in the GT structure. Reviewed-by:
-
As we start splitting tile handling out from GT handling, we'll need to be able to iterate over tiles separately from GTs. This iterator will be used in upcoming patches. v2: - s/(id__++)/(id__)++/ (Gustavo) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
-
Due to some mis-squashing, the changes we're fixing here actually live inside "drm/xe: keep pulling mem_access_get further back" at the moment. But using a fixup! against the display commit since that's where the changes actually need to land. Reviewed-by:
-
Rather than a backpointer to the xe_device, a GT should have a backpointer to its tile (which can then be used to lookup the device if necessary). The gt_to_xe() helper macro (which moves from xe_gt.h to xe_gt_types.h) can and should still be used to jump directly from an xe_gt to xe_device. v2: - Fix kunit test build - Move a couple changes to the previous patch. (Lucas) Reviewed-by:
Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by:
-
Create a new xe_tile structure to begin separating the concept of "tile" from "GT." A tile is effectively a complete GPU, and a GT is just one part of that. On platforms like MTL, there's only a single full GPU (tile) which has its IP blocks provided by two GTs. In contrast, a "multi-tile" platform like PVC is basically multiple complete GPUs packed behind a single PCI device. For now, just create xe_tile as a simple wrapper around xe_gt. The items in xe_gt that are truly tied to the tile rather than the GT will be moved in future patches. Support for multiple GTs per tile (i.e., the MTL standalone media case) will also be re-introduced in a future patch. v2: - Fix kunit test build - Move hunk from next patch to use local tile variable rather than direct xe->tiles[id] accesses. (Lucas) - Mention compute in kerneldoc. (Rodrigo) Reviewed-by:
-
Xe incorrectly conflates the concept of 'tile' and 'GT.' Since MTL's media support is not yet functioning properly, let's just disable it completely for now while we fix the fundamental driver design. Support for media GTs on platforms like MTL will be re-added later. v2: - Drop some unrelated code cleanup that didn't belong in this patch. (Lucas) v3: - Drop unnecessary xe_gt.h include. (Gustavo) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
-
OpenGL stack makes scanout buffers exported as well because usually it will be exported from client application to compositor. Exported buffers needs to be placed in SMEM so it can be accessed by different GPUs if needed, so in discrete GPUs it is placed in SMEM+LMEM. But this combination is causing aplications like kmscube to not be able to create framebuffers. So here doing the same handling as i915 and allowing bos that can migrate to lmem0/vram0 to be promoted to framebuffer. At least all current discrete GPUs with display only have one lmem region, so we don't need to check for vram1 but we might need to extend it in future. Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com>
-
Lucas De Marchi authored
Use a separate xe_display_driver prefix for functions dealing with the DRM driver struct or the early probe. This splits xe_display_set_driver_hooks() in 2: one to allow the driver to defer the probe if the display needs that and the other to set the additional hooks in the driver struct. Although the hooks are set by every device binding to the module, they only depend on the module param enable_display, so that is safe. Since unset_driver_hooks() is not really tweaking the driver, but rather the driver_features saved in the device, rename it to unset_display_features() to clarify that. Reviewed-by:
-
Lucas De Marchi authored
Stop the dance of enabling the display-related driver_features to later disable them on display info init if the platform doesn't have display IP. Besides being needless work, it wasn't covering the ATS-M case that is the same platform as DG2, but without display. Since now the display is created after the complete device info is populated, the new has_display flag can be consider to enable it. References: #265 Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20230510195424.3045127-4-lucas.demarchi@intel.com Signed-off-by:
-
Lucas De Marchi authored
Some platforms don't have the display IP. Currently those are PVC and ATS-M. For PVC the current initialization order works as the display initialization can check by platform. However the display side can't differentiate ATS-M from DG2 to act accordingly. Reviewed-by:
-
Of the platforms supported by Xe, only TGL and DG1 has PSR HW tracking. Signed-off-by:
-
Lucas De Marchi authored
When the device info initialization moved to the display part, one use case was left behind: platforms without display IP. In order to keep the knowledge about the display in xe_display.c, xe_display_info_init() should be the place where this is set. Remove the warning and set the info accordingly. This moves a later check from intel_device_info_runtime_init() into a very earlier one, when no HW access is being done yet. Fixes: 2a0f49c7 ("drm/xe/display: Move device info initialization to display") Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org> Link: https://lore.kernel.org/r/20230310191430.2229799-1-lucas.demarchi@intel.com
-
DG2 has cdclk squash, without which we calculate the CDCLK wrongly. Alderlake-P is LPD, not gen 12 display. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Closes: #210 Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com>
-
